企业官网建设流程全解析

ECC Web 设计质量标准：以反模板策略构建具有产品个性的前端界面

【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC

导读

本文基于 ECC 仓库中的docs/ja-JP/rules/web/design-quality.md（Web 设计质量标准规则，英文原版位于 rules/web/design-quality.md）展开，系统讲解 ECC 对前端输出的核心设计约束：禁止产出"看起来像通用模板"的 UI，并要求每个有意义的界面至少具备 4 项可验证的设计品质。你将掌握 ECC 的"反模板策略"具体禁止哪些模式、10 项必需品质如何逐条落地、写代码前应完成哪些设计决策，以及仓库内置的design-quality-checkhook 如何用启发式信号在每次编辑时自动拦截"模板化漂移"——这是一套从规则、技能到自动化检查的完整前端设计治理链路。

一、规则定位：design-quality 在 ECC 规则体系中的角色

design-quality.md本身不是孤立文档，它是对 ECC 通用规则的 Web 化扩展。日语版规则首行明确指出：

このファイルは common/patterns.md を Web 固有のデザイン品質ガイダンスで拡張します。

即：该文件以 common/patterns.md 为基础，扩展出 Web 特有的设计质量指导。common/patterns.md 中给出的是与具体技术无关的通用模式（如骨架项目复用、Repository 模式、API 响应信封格式），而 design-quality 则聚焦于"前端界面长得什么样、给人什么感受"这一类视觉与交互层面的质量约束。

在仓库中，这条规则并不是纸面文章，它通过三条路径真正进入开发流程：

1. 规则文件：rules/web/design-quality.md（英文规范源）与 docs/ja-JP/rules/web/design-quality.md（日语翻译），供 Agent 在编码时作为约束读取；
2. 自动检查 hook：scripts/hooks/design-quality-check.js，在每次编辑前端文件时输出设计质量提醒；
3. 配套技能：skills/frontend-design-direction/SKILL.md，提供"如何为具体产品选定设计方向"的操作方法。

下面按规则本身的骨架逐节展开，并穿插这三条落地路径的源码证据。

二、反模板策略（Anti-Template Policy）

规则的第一原则只有一句话：不要把看起来像通用模板的 UI 交付出去。前端输出应当"看起来是有意为之的、有明确主张的、且为该产品量身定制的"（intentional, opinionated, specific to the product）。

这条原则的底层逻辑是：LLM 生成前端代码时，天然倾向于输出训练数据中出现频率最高的"安全形态"——居中的 hero、三列卡片、渐变背景、默认字体。这些形态本身没有错，但它们没有传达任何产品判断，因此在 ECC 的质量标准中被视为需要主动规避的默认倾向。

2.1 禁止模式清单（Banned Patterns）

规则明确列出了 8 类禁止出现的模式：

注意第 3 条和第 8 条的对象：默认值本身不是罪，未经审视就采用默认值才是问题。规则要求每个视觉选择都有理由，这与 ECC 强调的"有意为之"（intentional）一脉相承。

2.2 hook 如何识别"模板化信号"

禁止模式从纸面走向自动化，靠的是 scripts/hooks/design-quality-check.js 中的启发式信号表（GENERIC_SIGNALS）。该 hook 不调用任何远程模型、不安装任何依赖包，纯本地运行，专为捕捉"一眼可见的通用 UI 漂移"而设计：

const GENERIC_SIGNALS = [ { pattern: /\bget started\b/i, label: '"Get Started" CTA copy' }, { pattern: /\blearn more\b/i, label: '"Learn more" CTA copy' }, { pattern: /\bgrid-cols-(3|4)\b/, label: 'uniform multi-card grid' }, { pattern: /\bbg-gradient-to-[trbl]/, label: 'stock gradient utility usage' }, { pattern: /\btext-center\b/, label: 'centered default layout cues' }, { pattern: /\bfont-(sans|inter)\b/i, label: 'default font utility' }, ];

这些正则与规则文本的禁止模式一一对应："Get Started"/"Learn more" 对应"通用 CTA"，grid-cols-3/4对应"均匀多卡片网格"，bg-gradient-to-*对应"库存渐变工具类"，text-center对应"居中默认布局"，font-sans|font-inter对应"默认字体工具类"。从源码结构可以推断，hook 采用"启发式字符串检测"而非完整视觉评估，因此它的定位是"提醒器"而非"裁判"——输出的是[Hook] DESIGN CHECK: ...形式的提醒（stderr），不会阻止编辑（exitCode 恒为 0）。

hook 只对前端文件生效，文件过滤规则定义在文件顶部：

const FRONTEND_EXTENSIONS = /\.(astro|css|html|jsx|scss|svelte|tsx|vue)$/i;

三、10 项必需品质：每个界面至少具备 4 项

规则对"合格"给出了可操作的最低门槛：每个有意义的（meaningful）前端界面，应当至少展示下列 10 项品质中的 4 项。

1. 通过尺度对比形成清晰层级（clear hierarchy through scale contrast）——用字号、字重、面积大小拉开主次，而不是靠一律加粗。
2. 间距的有意节奏，而非处处统一 padding（intentional rhythm in spacing）——间距是排版的呼吸，应该有大有小、有聚有散。
3. 通过重叠、阴影、表面或动效制造深度/分层（depth or layering through overlap, shadows, surfaces, or motion）。
4. 有性格且具备真实配对策略的排版（typography with character and a real pairing strategy）——正文字体与标题字体成体系，而非随机组合。
5. 语义化用色，而非纯装饰（color used semantically, not just decoratively）——颜色承担"状态、层级、数据、操作"等语义职责。
6. 精心设计的 hover、focus、active 状态（hover/focus/active states that feel designed）——交互反馈是设计的一部分，不是浏览器默认值。
7. 在合适时打破网格的编辑/便当（bento）式构图（grid-breaking editorial or bento composition where appropriate）。
8. 贴合视觉方向的纹理、颗粒或氛围（texture, grain, or atmosphere）——当视觉方向需要时，用质感而非纯色填充。
9. 澄清流程而非分散注意力的动效（motion that clarifies flow instead of distracting）——动效服务于导向，不服务于炫技。
10. 数据可视化作为设计系统的一部分，而非事后补丁（data visualization treated as part of the design system）——图表与 UI 共用同一套 token 和视觉语言。

"至少 4 项"的设计意图值得注意：它不是要求每个界面堆满全部 10 项（那会走向过度设计），而是设置一个"明显高于模板默认"的及格线——默认卡片网格 + 居中 hero + 灰白配色 + 默认字体这类模板组合，通常连 4 项都凑不齐。

hook 内置的CHECKLIST数组正是这 10 项的浓缩版，每次编辑前端文件都会随提醒输出：

const CHECKLIST = [ 'visual hierarchy with real contrast', 'intentional spacing rhythm', 'depth, layering, or overlap', 'purposeful hover and focus states', 'color and typography that feel specific', ];

四、编写前端代码之前的 5 个准备步骤

规则要求：不要直接动手写代码，先完成设计决策。5 个步骤缺一不可：

1. 选定具体的风格方向——避免"简洁干净"（clean minimal）这类模糊默认。方向必须具体到能指导每一个像素级决策。
2. 有意地定义调色板——不是随手取几个色值，而是从产品气质推导出色彩体系。
3. 有意地选择排版——字体选择基于可读性、气质与配对策略，而非默认栈。
4. 收集至少一小批真实参考——用真实产品截图/竞品/灵感来源锚定方向，避免凭感觉发散。
5. 使用相关的 ECC 设计/前端技能——即调用仓库内沉淀的设计类 skill 来指导落地。

第 5 步在仓库中有直接落点：skills/frontend-design-direction/SKILL.md。该技能（源自社区 PR #1659 的 ECC 化整理）把"选定方向"进一步拆解为 5 个显式问题，与规则步骤 1 形成互补：

• Purpose：这个界面要完成什么任务？
• Audience：谁在重复使用这个工作流？他们最先要扫视什么？
• Tone：工具型、编辑型、玩味、工业、精致、技术、极繁、极简、密集、平静……明确指定一种基调。
• Memorable detail：一个让结果显得有意为之的核心设计想法。
• Constraints：框架、无障碍、性能、响应式、既有设计系统。

技能还强调"方向必须匹配领域"：SaaS 运维工具通常应该密集、安静、易扫读；作品集、发布页、游戏、编辑类内容可以更富表现力；不要把落地页式的构图硬套在需要日常高频操作的工具上。这与规则"每个视觉选择都要有理由"的立场完全一致。

五、值得投入的风格方向（Worthwhile Style Directions）

规则给出了 9 个被认可的、足以支撑高质量输出的风格方向，供 Agent 在步骤 1 中选用：

规则特别附加了一条容易踩坑的告诫：不要自动默认启用暗色模式。暗色不是默认项，而是一种需要与产品气质匹配的视觉方向选择——如果产品真正需要的视觉方向是亮色，就老老实实做亮色。

六、组件检查清单（Component Checklist）

规则以 5 个自检问题收尾，作为交付前的最终把关：

• 它看起来像默认的 Tailwind 或 shadcn 模板吗？（必须回答"不像"）
• 它有精心设计的 hover / focus / active 状态吗？
• 它用的是层级（hierarchy）而不是均匀强调（uniform emphasis）吗？
• 把它放进真实产品的截图中，看起来可信吗？
• 如果同时支持两种主题，亮色和暗色都显得是有意为之的吗？

第 4 条"真实性测试"尤其实用：在脑中把界面截图放进真实产品上下文，是快速识别"模板感"的有效手段——模板 UI 经不起这种移情想象，而真正有产品个性的设计能站稳。

七、自动化落地：design-quality-check hook 的完整工作机制

规则文本 + 技能指导构成"人的约束"，而 hook 构成"流程的约束"。从源码可以完整还原这条自动检查链路的四个环节。

7.1 文件范围过滤

hook 只关心前端文件（.astro/.css/.html/.jsx/.scss/.svelte/.tsx/.vue）。输入可以是tool_input.file_path（单文件写入），也可以是tool_input.edits[]（MultiEdit 批量编辑）——getFilePaths函数同时兼容这两种 payload 形态：

function getFilePaths(input) { const toolInput = input?.tool_input || {}; if (toolInput.file_path) { return [String(toolInput.file_path)]; } if (Array.isArray(toolInput.edits)) { return toolInput.edits .map(edit => String(edit?.file_path || '')) .filter(Boolean); } return []; }

7.2 信号检测与提醒输出

对命中的前端文件，hook 读取内容并运行GENERIC_SIGNALS正则检测，然后输出两段信息到 stderr：一段是设计质量提醒（"Review for generic/template drift. Frontend should have: ..."），一段是命中的启发式信号列表；若未命中任何信号则提示 "no obvious canned-template strings detected"。

7.3 在 dispatcher 中注册

hook 通过 scripts/hooks/posttooluse-dispatcher.js 注册为 PostToolUse 钩子，注册项完整定义了它的触发范围：

{ id: 'post:edit:design-quality-check', matcher: 'Edit|Write|MultiEdit', profiles: 'standard,strict', script: 'scripts/hooks/design-quality-check.js', run: runDesignQualityCheck },

也就是说：任何 Edit / Write / MultiEdit 工具调用后，只要落在 standard 或 strict 配置档，且编辑的是前端文件，检查就会自动触发——规则因此成为每次编辑的"隐形评审员"。

7.4 测试验证

仓库为 hook 提供了完整的单元测试 tests/hooks/design-quality-check.test.js，可直接运行验证：

node tests/hooks/design-quality-check.test.js

测试覆盖 4 个关键行为：

1. 非前端文件静默透传——编辑.py文件时，不产生任何 stderr 提醒；
2. 前端文件触发提醒——写入含text-center+Get Started的.tsx文件，stderr 中出现DESIGN CHECK和Get Started；
3. MultiEdit edits[] payload 支持——批量编辑中包含.css文件时正确识别并提醒；
4. 无效 JSON 容错——输入无法解析时返回原始 stdout，保证 hook 异常不会阻塞流程。

结合这些测试可以确认：hook 的职责边界是**"提醒"而非"阻断"**（所有路径 exitCode 均为 0），它是一道低侵入的设计守门员——既不打断开发流程，又持续把设计标准锚定在每一次编辑中。

八、把规则用起来：一份可执行的落地路径

综合规则、技能与 hook 三者的分工，ECC 的前端设计质量流程可以归纳为一条完整链路：

1. 编码前：按规则的 5 个准备步骤，结合frontend-design-direction技能回答 Purpose / Audience / Tone / Memorable detail / Constraints，选定一个具体风格方向（优先从 9 个推荐方向中选），明确定义调色板与排版配对，收集参考素材；
2. 编码中：围绕 10 项必需品质逐项自查，确保至少满足 4 项；规避 8 类禁止模式；不让暗色模式"自动默认"；
3. 编码后：对照组件检查清单完成 5 个自检问题（尤其"真实产品截图可信度"测试）；此时design-quality-checkhook 已在后台基于正则信号输出提醒，可将其作为最后一道兜底，确认是否存在"Get Started"/"Learn more" 通用 CTA、grid-cols-3/4均质网格、库存渐变、居中默认布局、默认字体等模板化信号。

需要说明的适用前提：design-quality 规则是 ECC 对 Agent 输出前端代码时的质量约束与提醒机制，hook 的启发式检测只能捕捉字符串级信号，无法替代真实的设计评审——对于"是否有产品个性"这类主观判断，仍需回归规则文本中 10 项品质与检查清单的人工/模型综合评估。

总结

ECC 的 Web 设计质量标准回答了前端开发中一个常被忽略的问题："不像模板"到底意味着什么。它给出了可执行的答案——8 类禁止模式划定底线，10 项必需品质（至少满足 4 项）设定及格线，5 个准备步骤保证设计先行，9 个风格方向提供备选，5 项检查清单负责最终把关；而design-quality-checkhook 与frontend-design-direction技能，则把这条标准从文档注入了每次编辑与每个设计决策的流程之中。对于任何希望摆脱"AI 模板感"的团队，这套"规则 + 技能 + 自动化检查"的三层治理模式都值得直接借鉴。

【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC