1. 从“impeccable”这个词说起它到底在解决什么问题第一次看到“impeccable”这个词是在一个前端开发者的讨论串里。有人贴了一张截图说“这个 AI 写出来的页面终于有点 impeccable 的意思了”。当时我愣了一下——impeccable无懈可击、无可挑剔这个词放在前端设计语境里分量其实很重。因为做过前端的人都知道让一个页面“能跑”和让一个页面“无可挑剔”中间隔着的可能是几十个小时的像素级调整。后来我花了不少时间去研究这个词背后的东西发现它并不是某个具体产品的名字而更像是一个评价标准或者说是一类工具想要达到的目标状态。围绕它出现的几个关键词——AI coding agents、frontend design、CLI、browser extension——拼在一起其实勾勒出了一个很清晰的场景用 AI 编程代理来辅助前端设计通过命令行工具和浏览器扩展来落地。这个场景解决的核心痛点是什么我自己的体会是前端开发里最耗时的从来不是写业务逻辑而是那些“说不清道不明但一眼就能看出不对”的视觉细节。间距差 2px、圆角不统一、阴影层次混乱、响应式断点处理得生硬——这些问题 AI 以前很难帮你搞定因为它不理解“好看”的标准。但现在情况变了一批新的工具开始尝试把“设计品味”这件事拆解成可执行的规则和检查项。这篇文章适合谁看如果你是一个前端开发者或者正在用 AI 辅助写代码又或者你对“怎么让 AI 生成的界面不那么像 AI 生成的”这个问题感兴趣那接下来的内容应该对你有用。我会从实际使用的角度把这类工具的工作方式、配置细节、踩坑经验都摊开来讲尽量做到你看完就能上手试。提示本文讨论的“impeccable”是一个设计质量标准的概念不特指某一个商业产品。文中涉及的工具和方法论均基于公开可查的技术实践整理。2. AI coding agents 在前端设计里的真实能力边界2.1 为什么通用代码生成搞不定前端视觉我最早用 AI 写前端代码的时候最大的感受是它能给你一个“结构正确”的页面但离“视觉正确”还差得远。比如你让它写一个卡片组件它会给你一个 div里面有标题、描述、按钮CSS 也写得有模有样。但你把它放到真实项目里就会发现一堆问题卡片的内边距和项目里其他卡片不一致、按钮的 hover 状态没有过渡、文字的行高在移动端看起来太挤。这些问题的根源在于通用代码生成模型训练时看到的“好代码”和“好设计”是两回事。代码质量可以靠语法、结构、命名规范来衡量但设计质量涉及到视觉层次、对齐、留白、色彩对比度这些更主观的东西。一个模型可以写出完全符合 ESLint 规范的 CSS但依然做出一个看起来“很不对劲”的界面。AI coding agents 在这方面的进步主要体现在它们开始引入设计系统的约束。也就是说它不再凭空生成样式而是从你项目里已有的设计 token颜色变量、间距变量、字体层级里取值。这个转变很关键相当于把“设计品味”这件事从模型的能力问题转化成了工程问题——只要你的设计系统是 impeccable 的AI 生成的东西就不会太离谱。2.2 从“生成代码”到“审查代码”的转变我观察到的一个明显趋势是这类工具的重心正在从“帮你写”转向“帮你查”。这个转变其实很符合实际工作流——写代码这件事AI 已经做得够好了但审查代码尤其是审查视觉相关的代码才是真正稀缺的能力。举个例子你写了一个按钮组件AI 审查工具会告诉你这个按钮的点击区域高度是 36px低于移动端推荐的 44px 最小触控区域按钮文字和背景的对比度是 3.2:1低于 WCAG AA 标准的 4.5:1按钮的 focus 状态没有可见的轮廓线键盘用户无法感知焦点位置。这些检查项每一个都有明确的标准依据不是主观判断。这种“审查”能力之所以重要是因为它把前端设计里那些“老师傅才知道”的经验变成了可自动化执行的规则。你不需要在一个团队里待三年才能学会这些工具会直接告诉你哪里不对、为什么不对、怎么改。2.3 当前阶段的实际局限当然我也得说清楚这类工具目前做不到什么。它们能检查对比度、间距、触控区域这些可量化的指标但对于“这个页面的视觉节奏是否舒服”“这个动效是否自然”这类需要审美判断的问题还是无能为力。我试过让 AI 审查一个我做的落地页它指出了所有技术层面的问题但当我问它“这个页面的视觉重心是不是偏了”的时候它给的建议就很泛泛什么“可以尝试调整布局”之类的废话。所以我的经验是把 AI 当成一个极其严谨的初级设计师它能帮你守住底线但天花板还得靠你自己。还有一个现实问题是这类工具对项目上下文的依赖很强。如果你的项目没有统一的设计 token样式都是硬编码的那 AI 审查出来的结果就会很碎片化今天说这个按钮圆角不对明天说那个卡片阴影不一致但你没有一个统一的参照系去批量修复。所以我在实际项目里会先花时间把设计 token 整理清楚再让 AI 介入审查效率会高很多。3. CLI 工具在 impeccable 工作流里的角色3.1 为什么是命令行而不是图形界面说到 CLI很多人第一反应是“这不是倒退吗现在什么工具不都是图形界面”。但我在实际用下来之后发现 CLI 在前端设计审查这个场景里反而有它独特的优势。第一个优势是可集成性。你可以把 CLI 工具直接挂到 CI/CD 流程里每次提交代码的时候自动跑一遍设计审查有问题就阻断合并。这个在图形界面里很难做到你总不能让设计师每次提交前都手动打开一个网页去点检查按钮。第二个优势是批量处理能力。前端项目里动辄几十上百个组件用图形界面一个个检查是不现实的。CLI 工具可以一次性扫描整个目录输出一份完整的报告你拿着报告去批量修复就行。第三个优势是可配置性。CLI 工具通常支持配置文件你可以把团队的规范写进去比如“所有按钮的最小高度是 44px”“所有文字的对比度不低于 4.5:1”“间距只能取 4 的倍数”。这些规则一旦配置好就是团队共享的资产新人进来直接跑一遍就知道哪里不符合规范。3.2 一个典型的 CLI 工作流拆解我拿一个实际项目举例说说我是怎么把 CLI 工具嵌到工作流里的。假设你有一个 React 项目用的是 Tailwind CSS团队有一套自己的设计 token。第一步是安装和初始化。通常这类工具会提供一个 init 命令让你生成一个配置文件。配置文件里你会定义几个关键东西设计 token 的来源比如从 tailwind.config.js 里读、审查规则的严格程度warning 还是 error、要忽略的文件或目录。# 以某个设计审查 CLI 为例的初始化流程 npx design-audit init # 生成的配置文件大致长这样// design-audit.config.js module.exports { tokens: { spacing: [0, 4, 8, 12, 16, 24, 32, 48, 64], radius: [0, 4, 8, 12, 16, 9999], colors: ./src/styles/colors.js }, rules: { min-touch-target: error, color-contrast: error, consistent-spacing: warn, focus-visible: error }, ignore: [**/*.test.tsx, **/node_modules/**] }第二步是跑审查。你可以在本地开发的时候手动跑也可以挂到 pre-commit hook 里。我个人的习惯是本地手动跑因为有些警告我需要判断是不是误报不想让它阻断我的提交。npx design-audit scan ./src/components第三步是看报告。好的 CLI 工具会输出结构化的报告告诉你哪个文件、哪一行、什么问题、严重程度、建议怎么改。我见过做得比较好的还会直接给出修复后的代码片段你复制粘贴就行。第四步是修复和验证。修完之后再跑一遍确认问题都解决了。如果是挂到 CI 里的就等 CI 跑完看结果。3.3 配置文件的几个关键字段怎么填配置文件是 CLI 工具的灵魂填得好不好直接决定了审查结果有没有用。我踩过的坑主要集中在这几个字段上。tokens.spacing这个字段我建议你从项目实际用的间距值里提取不要照搬什么“8 的倍数”这种通用规则。因为每个项目的设计系统不一样有的用 4 的倍数有的用 5 的倍数你强行套一个通用规则只会得到一堆误报。我一般会写个脚本把项目里所有 CSS 的 margin 和 padding 值统计一遍取出现频率最高的那些值作为白名单。rules 的严格程度我的经验是分阶段来。刚开始用的时候全部设成 warn先看看工具能查出什么问题心里有个数。等你确认它的判断是靠谱的再把关键规则比如对比度、触控区域设成 error其他的保持 warn。不要一上来就全设 error不然你会被淹没在报错里最后干脆把工具关了。ignore 字段这个一定要认真配。测试文件、storybook 的 stories 文件、第三方组件库的包装文件这些通常不需要审查。如果你不忽略它们报告里会混入大量噪音真正的问题反而被淹没了。注意不同 CLI 工具的配置字段名可能不一样上面给的是示意。实际使用时请以你所用工具的官方文档为准。但配置的思路是通用的定义 token 来源、设置规则严格程度、排除不需要审查的文件。4. Browser extension 如何补足 CLI 看不到的视觉问题4.1 CLI 的盲区在哪里CLI 工具再强它本质上是在静态代码层面做分析。它能读你的 JSX、你的 CSS、你的配置文件但它看不到渲染后的实际效果。这就导致了一些问题它查不出来。比如你的 CSS 里写了一个color: #666CLI 工具会检查这个颜色和背景色的对比度。但如果这个元素被一个父级的opacity: 0.5影响了呢实际渲染出来的对比度可能只有 2:1但 CLI 不知道因为它不执行渲染。再比如响应式布局的问题。CLI 可以检查你有没有写媒体查询但它没法知道在 375px 宽度下你的导航栏是不是真的会换行、文字是不是真的会溢出。这些只有真正在浏览器里渲染出来才能看到。还有交互状态的问题。hover、focus、active、disabled 这些状态CLI 只能检查你有没有定义但定义得对不对、视觉效果好不好它判断不了。而 browser extension 可以直接在页面上模拟这些状态让你看到实际效果。4.2 浏览器扩展的典型使用场景我日常用得最多的 browser extension 功能是实时审查当前页面。打开一个页面点一下扩展图标它就会在当前页面上叠加一层标注把有问题的元素高亮出来旁边显示问题描述。这个功能在几个场景下特别有用。第一个是验收 AI 生成的页面。你用 AI 生成了一个页面代码看起来没问题CLI 也跑过了但你还是不放心。这时候用扩展在浏览器里打开一眼就能看出有没有视觉上的硬伤。第二个是检查响应式断点。好的扩展会提供一个断点切换器你可以在 320px、375px、768px、1024px、1440px 这些常见宽度之间快速切换看页面在不同尺寸下的表现。这个比你在开发者工具里手动拖拽要方便得多而且它会自动重新跑一遍审查规则。第三个是模拟交互状态。你可以强制一个元素进入 hover 或 focus 状态然后看它的样式是否符合预期。这个在检查键盘可访问性的时候特别有用——你按 Tab 键遍历页面上的可聚焦元素扩展会实时告诉你当前焦点在哪个元素上、它的 focus 样式是否可见。4.3 扩展和 CLI 怎么配合使用我的工作流是这样的CLI 管代码提交前的批量检查扩展管开发过程中的实时反馈。具体来说我在写组件的时候会开着浏览器扩展边写边看。每写完一个组件就在浏览器里刷新一下点扩展看看有没有新问题。这个阶段的反馈是即时的我改起来也快。等到一个功能模块写完了准备提交了我再跑一遍 CLI 审查。这时候 CLI 会从代码层面做一次全面扫描包括那些我在浏览器里可能没注意到的文件。如果 CLI 报了问题我再回到浏览器里确认一下然后修复。这个配合方式的好处是把审查分成了两个层次扩展负责“看得见”的问题CLI 负责“看不见”的问题。两者结合基本能覆盖前端设计质量的大部分检查项。还有一个技巧是我会把扩展的审查结果和 CLI 的审查结果做对比。如果扩展发现了 CLI 没发现的问题那说明这个问题是渲染层面的我需要去检查是不是有动态样式或者继承样式在作怪。如果 CLI 发现了扩展没发现的问题那说明这个问题在静态代码里存在但当前页面没有触发到可能是某个条件分支下的样式。5. 把 impeccable 标准落地到日常开发的具体做法5.1 先建立设计 token 的单一事实来源我见过很多项目设计 token 散落在各个地方有的在 CSS 变量里有的在 JS 常量里有的直接硬编码在组件里。这种情况下你让 AI 去审查设计质量它连个参照系都没有只能瞎猜。所以我的第一步永远是统一设计 token。具体做法是在项目里建一个tokens目录里面用 JSON 或 JS 文件定义所有的基础值颜色、间距、圆角、字体大小、行高、阴影、动画时长。然后通过构建工具把这些 token 转换成 CSS 变量、Tailwind 配置、JS 常量供不同场景使用。// tokens/index.js export const spacing { xs: 4px, sm: 8px, md: 16px, lg: 24px, xl: 32px, 2xl: 48px }; export const radius { none: 0, sm: 4px, md: 8px, lg: 12px, full: 9999px }; export const colors { primary: { 50: #eff6ff, 500: #3b82f6, 700: #1d4ed8 }, neutral: { 0: #ffffff, 100: #f5f5f5, 500: #737373, 900: #171717 } };这个文件一旦建好后面所有的审查工具都从这里读数据。CLI 工具读它来判断你的样式值是否在允许范围内浏览器扩展读它来判断渲染出来的颜色和间距是否符合规范。单一事实来源这个原则在设计系统里怎么强调都不过分。5.2 给 AI agent 写一份“设计约束说明书”如果你在用 AI coding agent 帮你写前端代码我强烈建议你给它准备一份设计约束说明书。这份说明书不用很长但要把关键规则写清楚让 AI 在生成代码的时候有据可依。我自己的说明书大概包含这几块内容。第一块是间距规则所有 margin 和 padding 只能取 token 里定义的值不允许出现 13px、17px 这种随意值。第二块是颜色规则文字颜色只能用 neutral 系列主色只能用于交互元素不允许用纯黑 #000 和纯白 #fff 做文字和背景的对比。第三块是组件规则按钮最小高度 44px输入框最小高度 40px卡片圆角统一用 md弹窗圆角统一用 lg。第四块是响应式规则移动端优先断点用 640px、768px、1024px、1280px不允许自定义断点。这份说明书你可以直接放在项目根目录命名成DESIGN_CONSTRAINTS.md然后在给 AI 的 prompt 里引用它。我实测下来有了这份说明书之后AI 生成的代码需要返工的比例明显下降。因为它不再需要猜你的设计偏好而是直接按照你给的规则来。5.3 建立审查结果的优先级处理机制审查工具跑出来的问题不是每一个都值得立刻修。我一般会把问题分成三个优先级。P0 级别是必须马上修的主要是可访问性问题对比度不达标、触控区域过小、focus 状态不可见、图片没有 alt 文本。这些问题直接影响用户能不能用你的产品不能拖。P1 级别是应该尽快修的主要是设计一致性问题间距不在 token 范围内、圆角值不统一、颜色用了非 token 值。这些问题不影响功能但影响产品的专业感积累多了会让整个界面看起来很乱。P2 级别是可以排期修的主要是优化类问题动画时长可以更合理、阴影层次可以更丰富、留白可以更舒服。这些问题属于“锦上添花”有时间就改没时间也不影响大局。我一般会在 CI 里把 P0 设成阻断P1 设成警告P2 只记录不阻断。这样既保证了底线又不会因为一些细枝末节的问题卡住整个团队的进度。5.4 一个完整的检查清单下面这张表是我自己整理的前端设计质量检查清单你可以直接拿去用也可以根据项目情况增删。检查项标准检查方式优先级文字对比度正文不低于 4.5:1大号文字不低于 3:1CLI 扩展P0触控区域移动端可点击元素不小于 44x44pxCLI 扩展P0焦点可见所有可聚焦元素有可见的 focus 样式扩展P0图片替代文本所有 img 有 alt 属性CLIP0间距一致性所有间距值来自 token 集合CLIP1圆角一致性同类组件圆角值统一CLIP1颜色一致性所有颜色值来自 token 集合CLIP1响应式断点使用项目定义的断点不自定义CLI 扩展P1动画时长在 150ms 到 400ms 之间CLIP2阴影层次不超过 3 个层级CLIP2这张表的好处是它把“impeccable”这个模糊的标准拆解成了可执行、可验证的具体条目。你不需要去争论“这个页面够不够完美”只需要对着表一项项检查全部通过就是 impeccable。6. 实际项目里踩过的坑和对应的解法6.1 误报太多导致团队放弃使用这是我遇到的最大的坑。刚开始推设计审查工具的时候我兴冲冲地配了一堆规则结果跑出来几百个警告团队里的人一看就烦了说“这工具净报些没用的”然后就不了了之。后来我反思了一下问题出在我没有做规则的渐进式启用。正确的做法应该是第一周只开 P0 规则让团队先适应第二周加上 P1 规则同时把第一周发现的误报规则调成忽略第三周再考虑加 P2。每一步都要给团队消化的时间不能一口气全上。还有一个减少误报的技巧是给规则加例外机制。比如对比度检查有些装饰性的文字确实不需要满足 4.5:1你可以在代码里加一个注释/* design-audit-disable-next-line */让工具跳过这一行。这个机制很重要因为没有任何一套规则能覆盖所有情况必须给开发者留一个“我知道我在做什么”的出口。6.2 设计 token 和实际代码脱节第二个坑是我建好了设计 token但团队里的人还是习惯直接写硬编码的值。你问他为什么不用 token他说“我不知道有这个 token”或者“这个 token 名字太长了懒得打”。这个问题的解法有两个层面。技术层面我在 ESLint 里加了一条规则禁止在样式文件里出现硬编码的颜色值和间距值必须用 token 变量。这条规则一加硬编码的情况立刻少了很多。文化层面我在团队里定了一个规矩新增 token 需要经过设计评审但使用 token 不需要任何审批。降低使用门槛提高新增门槛这样大家就愿意用现成的 token 了。6.3 浏览器扩展和 CLI 结果不一致第三个坑是同一个组件浏览器扩展说没问题CLI 说有问题。这种情况通常是因为两者的检查逻辑不一样扩展检查的是渲染后的计算样式CLI 检查的是源码里的声明样式。比如你在 CSS 里写color: #666但父元素有opacity: 0.8扩展计算出来的实际对比度是达标的因为它把 opacity 算进去了但 CLI 只看#666和背景色的对比度可能就不达标。这种不一致不是 bug而是两个工具的检查维度不同。我的处理方式是以扩展的结果为准来判断用户实际看到的效果以 CLI 的结果为准来判断代码层面的规范性。如果两者冲突说明这个样式有动态因素需要人工判断。我一般会去检查一下这个 opacity 是不是必要的如果是必要的就在 CLI 里给这一行加例外如果不是必要的就把它去掉让两边一致。6.4 AI 生成的代码绕过审查规则第四个坑是AI coding agent 生成的代码有时候会“巧妙”地绕过审查规则。比如规则要求间距必须是 4 的倍数AI 就写margin: calc(4px * 3.25)算出来是 13px但字面上看是 4 的倍数。这种写法能骗过简单的正则检查但实际效果还是不对。解法是让审查工具做计算而不是做匹配。好的工具会解析 CSS 的 calc 表达式算出最终值再判断。如果你的工具不支持这个那就需要在 AI 的 prompt 里明确禁止使用 calc 来做间距计算只允许直接写 token 值。还有一个更隐蔽的绕过方式是AI 用内联样式style{{ marginTop: 13px }}来写样式这样就不会被 CSS 文件的审查规则覆盖到。解法是在 CLI 配置里把 JSX 文件也纳入扫描范围检查内联样式里的值。7. 我对这套方法论的一些个人体会用了大半年这套工具链之后我最大的感受是impeccable 不是一个终点而是一个持续逼近的过程。你不可能一次性把所有问题都修完也不应该追求一次性修完。更现实的做法是把审查工具当成一个“设计质量的温度计”定期量一量看看是在变好还是变差。另一个体会是工具能帮你守住底线但突破上限还得靠人。对比度、间距、触控区域这些工具可以帮你检查但一个页面有没有“灵魂”能不能让用户觉得“这个产品很用心”还是取决于做产品的人有没有审美追求。工具只是把你的审美追求变得更容易执行、更不容易遗漏。还有一点我想说的是不要被工具绑架。我见过有人为了通过审查把设计改得四平八稳结果页面变得很无聊。审查规则是死的设计是活的。当规则和你的设计直觉冲突的时候先问问自己这个规则背后的原理是什么我的设计是不是真的违反了这个原理如果确认是规则太死板那就大胆地加例外甚至改规则。工具是为你服务的不是反过来。最后分享一个我最近在用的技巧我会定期把审查报告导出然后对比上个月的数据看看哪类问题在减少、哪类问题在增加。这个趋势比单次的审查结果更有价值因为它反映的是团队习惯的变化。如果某类问题持续增加说明要么是规则不合理要么是培训没到位需要针对性处理。这个做法让我把设计质量管理从“救火”变成了“防火”效果好了很多。
1. 从“impeccable”这个词说起它到底在解决什么问题第一次看到“impeccable”这个词是在一个前端开发者的讨论串里。有人贴了一张截图说“这个 AI 写出来的页面终于有点 impeccable 的意思了”。当时我愣了一下——impeccable无懈可击、无可挑剔这个词放在前端设计语境里分量其实很重。因为做过前端的人都知道让一个页面“能跑”和让一个页面“无可挑剔”中间隔着的可能是几十个小时的像素级调整。后来我花了不少时间去研究这个词背后的东西发现它并不是某个具体产品的名字而更像是一个评价标准或者说是一类工具想要达到的目标状态。围绕它出现的几个关键词——AI coding agents、frontend design、CLI、browser extension——拼在一起其实勾勒出了一个很清晰的场景用 AI 编程代理来辅助前端设计通过命令行工具和浏览器扩展来落地。这个场景解决的核心痛点是什么我自己的体会是前端开发里最耗时的从来不是写业务逻辑而是那些“说不清道不明但一眼就能看出不对”的视觉细节。间距差 2px、圆角不统一、阴影层次混乱、响应式断点处理得生硬——这些问题 AI 以前很难帮你搞定因为它不理解“好看”的标准。但现在情况变了一批新的工具开始尝试把“设计品味”这件事拆解成可执行的规则和检查项。这篇文章适合谁看如果你是一个前端开发者或者正在用 AI 辅助写代码又或者你对“怎么让 AI 生成的界面不那么像 AI 生成的”这个问题感兴趣那接下来的内容应该对你有用。我会从实际使用的角度把这类工具的工作方式、配置细节、踩坑经验都摊开来讲尽量做到你看完就能上手试。提示本文讨论的“impeccable”是一个设计质量标准的概念不特指某一个商业产品。文中涉及的工具和方法论均基于公开可查的技术实践整理。2. AI coding agents 在前端设计里的真实能力边界2.1 为什么通用代码生成搞不定前端视觉我最早用 AI 写前端代码的时候最大的感受是它能给你一个“结构正确”的页面但离“视觉正确”还差得远。比如你让它写一个卡片组件它会给你一个 div里面有标题、描述、按钮CSS 也写得有模有样。但你把它放到真实项目里就会发现一堆问题卡片的内边距和项目里其他卡片不一致、按钮的 hover 状态没有过渡、文字的行高在移动端看起来太挤。这些问题的根源在于通用代码生成模型训练时看到的“好代码”和“好设计”是两回事。代码质量可以靠语法、结构、命名规范来衡量但设计质量涉及到视觉层次、对齐、留白、色彩对比度这些更主观的东西。一个模型可以写出完全符合 ESLint 规范的 CSS但依然做出一个看起来“很不对劲”的界面。AI coding agents 在这方面的进步主要体现在它们开始引入设计系统的约束。也就是说它不再凭空生成样式而是从你项目里已有的设计 token颜色变量、间距变量、字体层级里取值。这个转变很关键相当于把“设计品味”这件事从模型的能力问题转化成了工程问题——只要你的设计系统是 impeccable 的AI 生成的东西就不会太离谱。2.2 从“生成代码”到“审查代码”的转变我观察到的一个明显趋势是这类工具的重心正在从“帮你写”转向“帮你查”。这个转变其实很符合实际工作流——写代码这件事AI 已经做得够好了但审查代码尤其是审查视觉相关的代码才是真正稀缺的能力。举个例子你写了一个按钮组件AI 审查工具会告诉你这个按钮的点击区域高度是 36px低于移动端推荐的 44px 最小触控区域按钮文字和背景的对比度是 3.2:1低于 WCAG AA 标准的 4.5:1按钮的 focus 状态没有可见的轮廓线键盘用户无法感知焦点位置。这些检查项每一个都有明确的标准依据不是主观判断。这种“审查”能力之所以重要是因为它把前端设计里那些“老师傅才知道”的经验变成了可自动化执行的规则。你不需要在一个团队里待三年才能学会这些工具会直接告诉你哪里不对、为什么不对、怎么改。2.3 当前阶段的实际局限当然我也得说清楚这类工具目前做不到什么。它们能检查对比度、间距、触控区域这些可量化的指标但对于“这个页面的视觉节奏是否舒服”“这个动效是否自然”这类需要审美判断的问题还是无能为力。我试过让 AI 审查一个我做的落地页它指出了所有技术层面的问题但当我问它“这个页面的视觉重心是不是偏了”的时候它给的建议就很泛泛什么“可以尝试调整布局”之类的废话。所以我的经验是把 AI 当成一个极其严谨的初级设计师它能帮你守住底线但天花板还得靠你自己。还有一个现实问题是这类工具对项目上下文的依赖很强。如果你的项目没有统一的设计 token样式都是硬编码的那 AI 审查出来的结果就会很碎片化今天说这个按钮圆角不对明天说那个卡片阴影不一致但你没有一个统一的参照系去批量修复。所以我在实际项目里会先花时间把设计 token 整理清楚再让 AI 介入审查效率会高很多。3. CLI 工具在 impeccable 工作流里的角色3.1 为什么是命令行而不是图形界面说到 CLI很多人第一反应是“这不是倒退吗现在什么工具不都是图形界面”。但我在实际用下来之后发现 CLI 在前端设计审查这个场景里反而有它独特的优势。第一个优势是可集成性。你可以把 CLI 工具直接挂到 CI/CD 流程里每次提交代码的时候自动跑一遍设计审查有问题就阻断合并。这个在图形界面里很难做到你总不能让设计师每次提交前都手动打开一个网页去点检查按钮。第二个优势是批量处理能力。前端项目里动辄几十上百个组件用图形界面一个个检查是不现实的。CLI 工具可以一次性扫描整个目录输出一份完整的报告你拿着报告去批量修复就行。第三个优势是可配置性。CLI 工具通常支持配置文件你可以把团队的规范写进去比如“所有按钮的最小高度是 44px”“所有文字的对比度不低于 4.5:1”“间距只能取 4 的倍数”。这些规则一旦配置好就是团队共享的资产新人进来直接跑一遍就知道哪里不符合规范。3.2 一个典型的 CLI 工作流拆解我拿一个实际项目举例说说我是怎么把 CLI 工具嵌到工作流里的。假设你有一个 React 项目用的是 Tailwind CSS团队有一套自己的设计 token。第一步是安装和初始化。通常这类工具会提供一个 init 命令让你生成一个配置文件。配置文件里你会定义几个关键东西设计 token 的来源比如从 tailwind.config.js 里读、审查规则的严格程度warning 还是 error、要忽略的文件或目录。# 以某个设计审查 CLI 为例的初始化流程 npx design-audit init # 生成的配置文件大致长这样// design-audit.config.js module.exports { tokens: { spacing: [0, 4, 8, 12, 16, 24, 32, 48, 64], radius: [0, 4, 8, 12, 16, 9999], colors: ./src/styles/colors.js }, rules: { min-touch-target: error, color-contrast: error, consistent-spacing: warn, focus-visible: error }, ignore: [**/*.test.tsx, **/node_modules/**] }第二步是跑审查。你可以在本地开发的时候手动跑也可以挂到 pre-commit hook 里。我个人的习惯是本地手动跑因为有些警告我需要判断是不是误报不想让它阻断我的提交。npx design-audit scan ./src/components第三步是看报告。好的 CLI 工具会输出结构化的报告告诉你哪个文件、哪一行、什么问题、严重程度、建议怎么改。我见过做得比较好的还会直接给出修复后的代码片段你复制粘贴就行。第四步是修复和验证。修完之后再跑一遍确认问题都解决了。如果是挂到 CI 里的就等 CI 跑完看结果。3.3 配置文件的几个关键字段怎么填配置文件是 CLI 工具的灵魂填得好不好直接决定了审查结果有没有用。我踩过的坑主要集中在这几个字段上。tokens.spacing这个字段我建议你从项目实际用的间距值里提取不要照搬什么“8 的倍数”这种通用规则。因为每个项目的设计系统不一样有的用 4 的倍数有的用 5 的倍数你强行套一个通用规则只会得到一堆误报。我一般会写个脚本把项目里所有 CSS 的 margin 和 padding 值统计一遍取出现频率最高的那些值作为白名单。rules 的严格程度我的经验是分阶段来。刚开始用的时候全部设成 warn先看看工具能查出什么问题心里有个数。等你确认它的判断是靠谱的再把关键规则比如对比度、触控区域设成 error其他的保持 warn。不要一上来就全设 error不然你会被淹没在报错里最后干脆把工具关了。ignore 字段这个一定要认真配。测试文件、storybook 的 stories 文件、第三方组件库的包装文件这些通常不需要审查。如果你不忽略它们报告里会混入大量噪音真正的问题反而被淹没了。注意不同 CLI 工具的配置字段名可能不一样上面给的是示意。实际使用时请以你所用工具的官方文档为准。但配置的思路是通用的定义 token 来源、设置规则严格程度、排除不需要审查的文件。4. Browser extension 如何补足 CLI 看不到的视觉问题4.1 CLI 的盲区在哪里CLI 工具再强它本质上是在静态代码层面做分析。它能读你的 JSX、你的 CSS、你的配置文件但它看不到渲染后的实际效果。这就导致了一些问题它查不出来。比如你的 CSS 里写了一个color: #666CLI 工具会检查这个颜色和背景色的对比度。但如果这个元素被一个父级的opacity: 0.5影响了呢实际渲染出来的对比度可能只有 2:1但 CLI 不知道因为它不执行渲染。再比如响应式布局的问题。CLI 可以检查你有没有写媒体查询但它没法知道在 375px 宽度下你的导航栏是不是真的会换行、文字是不是真的会溢出。这些只有真正在浏览器里渲染出来才能看到。还有交互状态的问题。hover、focus、active、disabled 这些状态CLI 只能检查你有没有定义但定义得对不对、视觉效果好不好它判断不了。而 browser extension 可以直接在页面上模拟这些状态让你看到实际效果。4.2 浏览器扩展的典型使用场景我日常用得最多的 browser extension 功能是实时审查当前页面。打开一个页面点一下扩展图标它就会在当前页面上叠加一层标注把有问题的元素高亮出来旁边显示问题描述。这个功能在几个场景下特别有用。第一个是验收 AI 生成的页面。你用 AI 生成了一个页面代码看起来没问题CLI 也跑过了但你还是不放心。这时候用扩展在浏览器里打开一眼就能看出有没有视觉上的硬伤。第二个是检查响应式断点。好的扩展会提供一个断点切换器你可以在 320px、375px、768px、1024px、1440px 这些常见宽度之间快速切换看页面在不同尺寸下的表现。这个比你在开发者工具里手动拖拽要方便得多而且它会自动重新跑一遍审查规则。第三个是模拟交互状态。你可以强制一个元素进入 hover 或 focus 状态然后看它的样式是否符合预期。这个在检查键盘可访问性的时候特别有用——你按 Tab 键遍历页面上的可聚焦元素扩展会实时告诉你当前焦点在哪个元素上、它的 focus 样式是否可见。4.3 扩展和 CLI 怎么配合使用我的工作流是这样的CLI 管代码提交前的批量检查扩展管开发过程中的实时反馈。具体来说我在写组件的时候会开着浏览器扩展边写边看。每写完一个组件就在浏览器里刷新一下点扩展看看有没有新问题。这个阶段的反馈是即时的我改起来也快。等到一个功能模块写完了准备提交了我再跑一遍 CLI 审查。这时候 CLI 会从代码层面做一次全面扫描包括那些我在浏览器里可能没注意到的文件。如果 CLI 报了问题我再回到浏览器里确认一下然后修复。这个配合方式的好处是把审查分成了两个层次扩展负责“看得见”的问题CLI 负责“看不见”的问题。两者结合基本能覆盖前端设计质量的大部分检查项。还有一个技巧是我会把扩展的审查结果和 CLI 的审查结果做对比。如果扩展发现了 CLI 没发现的问题那说明这个问题是渲染层面的我需要去检查是不是有动态样式或者继承样式在作怪。如果 CLI 发现了扩展没发现的问题那说明这个问题在静态代码里存在但当前页面没有触发到可能是某个条件分支下的样式。5. 把 impeccable 标准落地到日常开发的具体做法5.1 先建立设计 token 的单一事实来源我见过很多项目设计 token 散落在各个地方有的在 CSS 变量里有的在 JS 常量里有的直接硬编码在组件里。这种情况下你让 AI 去审查设计质量它连个参照系都没有只能瞎猜。所以我的第一步永远是统一设计 token。具体做法是在项目里建一个tokens目录里面用 JSON 或 JS 文件定义所有的基础值颜色、间距、圆角、字体大小、行高、阴影、动画时长。然后通过构建工具把这些 token 转换成 CSS 变量、Tailwind 配置、JS 常量供不同场景使用。// tokens/index.js export const spacing { xs: 4px, sm: 8px, md: 16px, lg: 24px, xl: 32px, 2xl: 48px }; export const radius { none: 0, sm: 4px, md: 8px, lg: 12px, full: 9999px }; export const colors { primary: { 50: #eff6ff, 500: #3b82f6, 700: #1d4ed8 }, neutral: { 0: #ffffff, 100: #f5f5f5, 500: #737373, 900: #171717 } };这个文件一旦建好后面所有的审查工具都从这里读数据。CLI 工具读它来判断你的样式值是否在允许范围内浏览器扩展读它来判断渲染出来的颜色和间距是否符合规范。单一事实来源这个原则在设计系统里怎么强调都不过分。5.2 给 AI agent 写一份“设计约束说明书”如果你在用 AI coding agent 帮你写前端代码我强烈建议你给它准备一份设计约束说明书。这份说明书不用很长但要把关键规则写清楚让 AI 在生成代码的时候有据可依。我自己的说明书大概包含这几块内容。第一块是间距规则所有 margin 和 padding 只能取 token 里定义的值不允许出现 13px、17px 这种随意值。第二块是颜色规则文字颜色只能用 neutral 系列主色只能用于交互元素不允许用纯黑 #000 和纯白 #fff 做文字和背景的对比。第三块是组件规则按钮最小高度 44px输入框最小高度 40px卡片圆角统一用 md弹窗圆角统一用 lg。第四块是响应式规则移动端优先断点用 640px、768px、1024px、1280px不允许自定义断点。这份说明书你可以直接放在项目根目录命名成DESIGN_CONSTRAINTS.md然后在给 AI 的 prompt 里引用它。我实测下来有了这份说明书之后AI 生成的代码需要返工的比例明显下降。因为它不再需要猜你的设计偏好而是直接按照你给的规则来。5.3 建立审查结果的优先级处理机制审查工具跑出来的问题不是每一个都值得立刻修。我一般会把问题分成三个优先级。P0 级别是必须马上修的主要是可访问性问题对比度不达标、触控区域过小、focus 状态不可见、图片没有 alt 文本。这些问题直接影响用户能不能用你的产品不能拖。P1 级别是应该尽快修的主要是设计一致性问题间距不在 token 范围内、圆角值不统一、颜色用了非 token 值。这些问题不影响功能但影响产品的专业感积累多了会让整个界面看起来很乱。P2 级别是可以排期修的主要是优化类问题动画时长可以更合理、阴影层次可以更丰富、留白可以更舒服。这些问题属于“锦上添花”有时间就改没时间也不影响大局。我一般会在 CI 里把 P0 设成阻断P1 设成警告P2 只记录不阻断。这样既保证了底线又不会因为一些细枝末节的问题卡住整个团队的进度。5.4 一个完整的检查清单下面这张表是我自己整理的前端设计质量检查清单你可以直接拿去用也可以根据项目情况增删。检查项标准检查方式优先级文字对比度正文不低于 4.5:1大号文字不低于 3:1CLI 扩展P0触控区域移动端可点击元素不小于 44x44pxCLI 扩展P0焦点可见所有可聚焦元素有可见的 focus 样式扩展P0图片替代文本所有 img 有 alt 属性CLIP0间距一致性所有间距值来自 token 集合CLIP1圆角一致性同类组件圆角值统一CLIP1颜色一致性所有颜色值来自 token 集合CLIP1响应式断点使用项目定义的断点不自定义CLI 扩展P1动画时长在 150ms 到 400ms 之间CLIP2阴影层次不超过 3 个层级CLIP2这张表的好处是它把“impeccable”这个模糊的标准拆解成了可执行、可验证的具体条目。你不需要去争论“这个页面够不够完美”只需要对着表一项项检查全部通过就是 impeccable。6. 实际项目里踩过的坑和对应的解法6.1 误报太多导致团队放弃使用这是我遇到的最大的坑。刚开始推设计审查工具的时候我兴冲冲地配了一堆规则结果跑出来几百个警告团队里的人一看就烦了说“这工具净报些没用的”然后就不了了之。后来我反思了一下问题出在我没有做规则的渐进式启用。正确的做法应该是第一周只开 P0 规则让团队先适应第二周加上 P1 规则同时把第一周发现的误报规则调成忽略第三周再考虑加 P2。每一步都要给团队消化的时间不能一口气全上。还有一个减少误报的技巧是给规则加例外机制。比如对比度检查有些装饰性的文字确实不需要满足 4.5:1你可以在代码里加一个注释/* design-audit-disable-next-line */让工具跳过这一行。这个机制很重要因为没有任何一套规则能覆盖所有情况必须给开发者留一个“我知道我在做什么”的出口。6.2 设计 token 和实际代码脱节第二个坑是我建好了设计 token但团队里的人还是习惯直接写硬编码的值。你问他为什么不用 token他说“我不知道有这个 token”或者“这个 token 名字太长了懒得打”。这个问题的解法有两个层面。技术层面我在 ESLint 里加了一条规则禁止在样式文件里出现硬编码的颜色值和间距值必须用 token 变量。这条规则一加硬编码的情况立刻少了很多。文化层面我在团队里定了一个规矩新增 token 需要经过设计评审但使用 token 不需要任何审批。降低使用门槛提高新增门槛这样大家就愿意用现成的 token 了。6.3 浏览器扩展和 CLI 结果不一致第三个坑是同一个组件浏览器扩展说没问题CLI 说有问题。这种情况通常是因为两者的检查逻辑不一样扩展检查的是渲染后的计算样式CLI 检查的是源码里的声明样式。比如你在 CSS 里写color: #666但父元素有opacity: 0.8扩展计算出来的实际对比度是达标的因为它把 opacity 算进去了但 CLI 只看#666和背景色的对比度可能就不达标。这种不一致不是 bug而是两个工具的检查维度不同。我的处理方式是以扩展的结果为准来判断用户实际看到的效果以 CLI 的结果为准来判断代码层面的规范性。如果两者冲突说明这个样式有动态因素需要人工判断。我一般会去检查一下这个 opacity 是不是必要的如果是必要的就在 CLI 里给这一行加例外如果不是必要的就把它去掉让两边一致。6.4 AI 生成的代码绕过审查规则第四个坑是AI coding agent 生成的代码有时候会“巧妙”地绕过审查规则。比如规则要求间距必须是 4 的倍数AI 就写margin: calc(4px * 3.25)算出来是 13px但字面上看是 4 的倍数。这种写法能骗过简单的正则检查但实际效果还是不对。解法是让审查工具做计算而不是做匹配。好的工具会解析 CSS 的 calc 表达式算出最终值再判断。如果你的工具不支持这个那就需要在 AI 的 prompt 里明确禁止使用 calc 来做间距计算只允许直接写 token 值。还有一个更隐蔽的绕过方式是AI 用内联样式style{{ marginTop: 13px }}来写样式这样就不会被 CSS 文件的审查规则覆盖到。解法是在 CLI 配置里把 JSX 文件也纳入扫描范围检查内联样式里的值。7. 我对这套方法论的一些个人体会用了大半年这套工具链之后我最大的感受是impeccable 不是一个终点而是一个持续逼近的过程。你不可能一次性把所有问题都修完也不应该追求一次性修完。更现实的做法是把审查工具当成一个“设计质量的温度计”定期量一量看看是在变好还是变差。另一个体会是工具能帮你守住底线但突破上限还得靠人。对比度、间距、触控区域这些工具可以帮你检查但一个页面有没有“灵魂”能不能让用户觉得“这个产品很用心”还是取决于做产品的人有没有审美追求。工具只是把你的审美追求变得更容易执行、更不容易遗漏。还有一点我想说的是不要被工具绑架。我见过有人为了通过审查把设计改得四平八稳结果页面变得很无聊。审查规则是死的设计是活的。当规则和你的设计直觉冲突的时候先问问自己这个规则背后的原理是什么我的设计是不是真的违反了这个原理如果确认是规则太死板那就大胆地加例外甚至改规则。工具是为你服务的不是反过来。最后分享一个我最近在用的技巧我会定期把审查报告导出然后对比上个月的数据看看哪类问题在减少、哪类问题在增加。这个趋势比单次的审查结果更有价值因为它反映的是团队习惯的变化。如果某类问题持续增加说明要么是规则不合理要么是培训没到位需要针对性处理。这个做法让我把设计质量管理从“救火”变成了“防火”效果好了很多。
