1. 从“impeccable”说起：一个被低估的前端设计关键词

第一次看到“impeccable”这个词，是在一个前端项目的代码注释里。当时团队里有人在 review 一段 CSS，写了句/* keep this spacing impeccable */，意思是“这个间距要保持无可挑剔”。后来我慢慢发现，这个词在前端圈子里出现的频率越来越高，尤其是在 AI coding agents 开始大规模介入前端开发之后——它几乎成了一个隐性的质量标准：不是“能用”，不是“好看”，而是无可挑剔。

这个词背后对应的，其实是一整套关于前端设计质量的方法论。它涉及 AI coding agents 如何理解设计意图、CLI 工具如何辅助开发者做设计决策、浏览器扩展如何实时校验页面质量，以及一个前端工程师在面对“差不多就行”和“必须 impeccable”之间如何做取舍。如果你是一个正在用 AI 辅助写前端代码的人，或者你正在搭建一套前端质量保障流程，那这个话题值得你花时间看完。

我自己的背景是做了十多年前端，从 jQuery 时代一路写到现在的组件化框架，中间经历过设计系统从零搭建、组件库从混乱到规范、AI 代码生成从玩具到生产力的全过程。最近半年我花了不少时间研究 AI coding agents 在前端设计场景下的实际表现，也试过用各种 CLI 工具和浏览器扩展来辅助设计质量检查。这篇文章就是把这些经验整理出来，给同样在这个方向上摸索的人一个参考。

文章会从设计意图的拆解开始，讲到 AI coding agents 在前端设计中的实际能力边界，再落到 CLI 工具和浏览器扩展的具体用法，最后给出一套可复现的 impeccable 前端质量保障流程。不管你是刚接触 AI 辅助开发的新手，还是已经在用 codex cli、zcode cli 这类工具的老手，应该都能从中找到一些能直接抄作业的东西。

2. 拆解 impeccable：前端设计质量的核心维度

2.1 什么是“无可挑剔”的前端设计

在前端语境下，“impeccable”不是一个模糊的赞美词，它对应的是几个可以量化、可以检查、可以自动化的维度。我把它拆成五个层面：

视觉一致性。同一个页面里，按钮的圆角是 4px 还是 6px，间距是 8 的倍数还是随意写的 13px，颜色是设计系统里的 token 还是硬编码的 hex 值——这些细节单独看都不起眼，但累积起来就是“精致”和“粗糙”的分界线。AI coding agents 在生成代码时，如果没有明确的约束，很容易在不同组件里写出不一致的值。

响应式完整性。一个 impeccable 的页面，在 320px 到 2560px 的宽度范围内都不应该出现布局崩坏、文字溢出、点击区域过小的问题。这需要开发者在写代码时就考虑到各种断点，而不是等测试阶段才发现。

交互反馈的及时性。按钮点击有没有 loading 状态，表单提交有没有成功/失败提示，异步加载有没有骨架屏——这些交互细节决定了用户对产品“靠谱程度”的感知。

可访问性达标。对比度是否满足 WCAG 标准，键盘导航是否完整，屏幕阅读器能否正确朗读——这些不是“加分项”，而是 impeccable 的底线。

性能与体验的平衡。动画是否流畅（60fps），首屏加载是否在可接受范围内，图片是否做了懒加载和格式优化——设计质量不只是“看起来好”，还要“用起来顺”。

这五个维度合在一起，才构成“impeccable”的完整含义。而 AI coding agents 在前端设计中的价值，恰恰在于它可以帮助开发者系统性地检查这些维度，而不是靠人肉 review 去发现遗漏。

2.2 为什么 AI coding agents 需要“设计约束”

我用过不少 AI coding agents 来生成前端代码，从最早的 Copilot 到后来的各种 CLI 工具。一个很明显的感受是：如果不给约束，AI 生成的前端代码在视觉上往往是“能跑但不好看”。

原因很简单。AI 模型在训练时见过大量的前端代码，但这些代码的质量参差不齐。它学到的是“统计上最常见的写法”，而不是“最佳实践”。比如间距，它可能在这个组件里写margin: 12px，在那个组件里写margin: 0.75rem，虽然数值一样，但写法不统一，后续维护就会很痛苦。

所以我在实际项目中会做一件事：在让 AI 生成代码之前，先把设计约束以配置文件的形式喂给它。这个配置文件通常包括：

• 设计 token 清单（颜色、间距、圆角、阴影、字体大小）
• 组件命名规范
• 响应式断点定义
• 可访问性检查规则
• 禁止使用的 CSS 属性或写法

有了这些约束，AI 生成的代码质量会有一个质的提升。这也是为什么现在很多 CLI 工具都支持“项目级配置”——它们需要知道你的项目规范是什么，才能生成符合规范的代码。

2.3 浏览器扩展在 impeccable 流程中的角色

CLI 工具擅长的是代码生成和静态检查，但它看不到“运行时”的效果。一个页面在代码层面看起来没问题，实际渲染出来可能因为字体加载、图片尺寸、动态内容等原因出现视觉问题。这时候浏览器扩展就派上用场了。

我常用的几类浏览器扩展包括：

• 设计审查类：可以实时标注页面上的间距、颜色、字体，检查是否使用了设计 token
• 可访问性检查类：自动扫描页面的对比度、ARIA 属性、键盘导航
• 响应式测试类：快速切换不同视口尺寸，检查布局是否崩坏
• 性能分析类：查看动画帧率、资源加载时间、布局偏移

这些扩展和 CLI 工具配合使用，就形成了一个从“代码生成”到“运行时验证”的完整闭环。AI coding agents 负责按规范生成代码，CLI 负责静态检查，浏览器扩展负责运行时验证——三者缺一不可。

3. AI coding agents 在前端设计中的实际能力边界

3.1 AI 能做什么：从代码补全到设计决策

先说 AI coding agents 在前端设计场景下确实能做好的事情。

组件级代码生成。给一个明确的需求描述，比如“一个带图标和加载状态的提交按钮，主色调用 primary，圆角 6px，hover 时加深 10%”，AI 可以很快生成可用的代码。这个能力在重复性高的组件开发中特别有价值。

设计 token 的批量应用。如果你有一个设计 token 文件，AI 可以帮你把硬编码的值替换成 token 引用。这个工作人工做很枯燥，AI 做起来又快又准。

响应式代码的补全。你写好了桌面端的布局，AI 可以帮你补全移动端的适配代码，包括断点、栅格调整、字体缩放等。

可访问性属性的添加。AI 可以帮你给交互元素加上合适的 ARIA 属性、键盘事件处理、焦点管理。

代码审查建议。把一段前端代码丢给 AI，它可以指出潜在的视觉不一致、响应式问题、可访问性遗漏。

这些能力在实际项目中已经足够产生价值。我自己的团队现在会把一些重复性的前端工作交给 AI 处理，比如批量修改组件样式、生成基础布局代码、补充响应式断点等，效率提升很明显。

3.2 AI 做不好什么：设计判断与上下文理解

但 AI coding agents 在前端设计上也有明显的短板，而且这些短板在短期内不太可能完全解决。

审美判断。AI 可以告诉你“这个间距是 12px”，但它没法告诉你“这个间距在这个场景下应该更大一点才舒服”。审美是高度依赖上下文和经验的，AI 目前还做不到。

品牌一致性。每个产品都有自己的视觉语言，有些规则是写在设计系统里的，有些是隐性的“我们一直这么做”。AI 如果不了解这些隐性规则，生成的代码可能在技术上是正确的，但看起来“不像我们的产品”。

复杂交互的状态管理。一个多步骤表单、一个拖拽排序列表、一个实时协作编辑器——这些复杂交互涉及大量的状态转换和边界情况，AI 生成的代码往往只能覆盖主流程，边缘情况需要人工补全。

性能优化的取舍。什么时候用 CSS 动画、什么时候用 JS 动画、什么时候用 will-change、什么时候避免重排——这些取舍需要结合实际场景判断，AI 给出的建议往往是“通用最佳实践”，不一定适合你的具体情况。

所以我的做法是：把 AI 当作一个执行力很强但判断力有限的初级工程师。它适合做明确、重复、有规范可循的工作，不适合做需要审美判断、上下文理解、复杂取舍的工作。把这两类工作分开，AI 的价值才能最大化。

3.3 人机协作的最佳分工模式

基于上面的分析，我总结了一个在前端设计场景下比较有效的人机分工模式：

这个分工模式的核心逻辑是：把“确定性高、重复性高、有明确规范”的工作交给 AI，把“需要判断、需要经验、需要上下文”的工作留给人。这样既发挥了 AI 的效率优势，又避免了它在不擅长的地方产生低质量输出。

4. CLI 工具链：让 impeccable 成为可执行的流程

4.1 为什么 CLI 是前端质量保障的关键一环

前端开发有一个特点：很多质量问题是在代码提交之后才发现的。设计师 review 时发现间距不对，测试同学发现某个断点布局崩了，上线后用户反馈对比度太低看不清——这些问题如果能在代码提交前就自动检查出来，能省下大量返工时间。

CLI 工具的价值就在这里。它可以集成到 Git hooks 里，在每次提交前自动运行检查；可以集成到 CI/CD 流程里，在合并请求时给出质量报告；也可以手动运行，在开发过程中随时检查。

我目前用的 CLI 工具链主要包括几类：

• 代码规范检查：ESLint、Stylelint、Prettier
• 可访问性检查：axe-core CLI、pa11y
• 视觉回归测试：BackstopJS、Percy CLI
• 性能检查：Lighthouse CI
• 设计 token 校验：自定义脚本 + Stylelint 插件

这些工具单独用都有价值，但组合起来才能形成完整的质量保障体系。下面我会讲具体怎么配置和使用。

4.2 配置一个可复用的前端质量检查 CLI 流程

先给一个我实际在用的配置方案。假设你的项目是 React + TypeScript + CSS Modules，目录结构大概是：

project/ src/ components/ styles/ tokens.css pages/ .stylelintrc.json .eslintrc.json .pa11yci.json package.json

第一步：配置 Stylelint 检查设计 token 使用

.stylelintrc.json：

{ "extends": ["stylelint-config-standard"], "rules": { "color-no-hex": true, "declaration-property-value-allowed-list": { "color": ["/^var\\(--color-/"], "background-color": ["/^var\\(--color-/"], "margin": ["/^var\\(--space-/", "0", "auto"], "padding": ["/^var\\(--space-/", "0"], "border-radius": ["/^var\\(--radius-/", "0", "50%"] } } }

这个配置的核心逻辑是：禁止硬编码颜色和间距，强制使用设计 token。color-no-hex禁止直接写 hex 颜色值，declaration-property-value-allowed-list限制 margin、padding、border-radius 只能使用 token 变量或特定值。

这样配置之后，如果 AI 生成的代码里写了color: #3b82f6，Stylelint 会直接报错，提示你应该用var(--color-primary)。这就把“设计一致性”从人工 review 变成了自动化检查。

第二步：配置 ESLint 检查可访问性

.eslintrc.json里加上 jsx-a11y 插件：

{ "extends": [ "plugin:jsx-a11y/recommended" ], "plugins": ["jsx-a11y"], "rules": { "jsx-a11y/alt-text": "error", "jsx-a11y/aria-props": "error", "jsx-a11y/aria-role": "error", "jsx-a11y/click-events-have-key-events": "error", "jsx-a11y/no-static-element-interactions": "error" } }

这些规则会在代码层面检查可访问性问题，比如图片缺少 alt、点击事件没有键盘对应、ARIA 属性使用错误等。AI 生成的代码如果遗漏了这些，ESLint 会直接拦截。

第三步：配置 pa11y 做运行时可访问性检查

.pa11yci.json：

{ "defaults": { "standard": "WCAG2AA", "timeout": 30000, "wait": 1000, "chromeLaunchConfig": { "args": ["--no-sandbox"] } }, "urls": [ "http://localhost:3000/", "http://localhost:3000/components/button", "http://localhost:3000/components/form" ] }

pa11y 会启动一个无头浏览器，访问指定页面，按照 WCAG2AA 标准检查可访问性问题。这个检查比 ESLint 更全面，因为它能看到实际渲染后的 DOM 结构和样式。

第四步：把检查集成到 package.json scripts

{ "scripts": { "lint:css": "stylelint 'src/**/*.css'", "lint:js": "eslint 'src/**/*.{ts,tsx}'", "lint:a11y": "pa11y-ci", "lint:all": "npm run lint:css && npm run lint:js && npm run lint:a11y", "precommit": "npm run lint:all" } }

配合 husky 的 pre-commit hook，每次提交前自动运行所有检查。这样 AI 生成的代码如果有质量问题，在提交阶段就会被拦截，不会进入代码库。

4.3 用 CLI 做视觉回归测试的实操步骤

视觉回归测试是 impeccable 流程里比较容易被忽略但非常重要的一环。它的逻辑是：给页面截图，和上一次的基准截图对比，如果像素差异超过阈值就报警。这样可以发现那些“代码没问题但视觉变了”的情况。

我用的是 BackstopJS，配置步骤如下：

第一步：安装

npm install -g backstopjs

第二步：初始化配置

backstop init

这会生成一个backstop.json文件。我通常会修改几个关键配置：

{ "id": "frontend_visual_test", "viewports": [ { "label": "phone", "width": 375, "height": 667 }, { "label": "tablet", "width": 768, "height": 1024 }, { "label": "desktop", "width": 1440, "height": 900 } ], "scenarios": [ { "label": "Homepage", "url": "http://localhost:3000/", "selectors": ["document"], "delay": 1000, "misMatchThreshold": 0.1 }, { "label": "Button Component", "url": "http://localhost:3000/components/button", "selectors": [".button-showcase"], "delay": 500, "misMatchThreshold": 0.1 } ], "engine": "puppeteer", "engineOptions": { "args": ["--no-sandbox"] } }

几个关键参数说明：

• viewports：定义要测试的视口尺寸，我一般会覆盖手机、平板、桌面三个典型尺寸
• misMatchThreshold：像素差异阈值，0.1 表示允许 0.1% 的差异，超过就报警
• delay：截图前等待时间，给页面加载和动画完成留出时间
• selectors：指定要截图的区域，可以是整个文档也可以是某个组件

第三步：生成基准截图

backstop reference

第四步：修改代码后做对比测试

backstop test

如果测试不通过，BackstopJS 会生成一个 HTML 报告，展示基准截图、当前截图和差异图。你可以根据报告判断是“预期内的变化”还是“意外的回归”。如果是预期内的变化，运行backstop approve更新基准截图。

这个流程在 AI 辅助开发中特别有用。因为 AI 生成的代码有时候会“顺手”改掉一些它认为不重要的样式，这些改动在代码 review 时容易被忽略，但视觉回归测试会直接把它揪出来。

5. 浏览器扩展：运行时设计质量的最后一道防线

5.1 设计审查类扩展的实战用法

CLI 工具检查的是代码和静态渲染结果，但有些问题只有在真实浏览器环境里才能发现。比如：

• 字体加载后导致的布局偏移
• 动态内容导致的容器高度变化
• 第三方组件注入的样式覆盖
• 不同浏览器下的渲染差异

这时候浏览器扩展就是最后一道防线。我常用的设计审查类扩展有几个，这里不具体点名，只说它们的功能类型和使用方法。

间距和尺寸标注类。这类扩展可以在页面上悬停时显示元素的 margin、padding、尺寸、位置信息。我在做设计走查时经常用，可以快速发现“这个间距是 12px 但设计稿写的是 16px”这类问题。

颜色取色和对比度检查类。可以吸取页面上的颜色，自动计算对比度，判断是否满足 WCAG AA 或 AAA 标准。这个在检查文字可读性时特别有用。

字体和排版检查类。可以显示页面上使用的字体、字号、行高、字重，检查是否和设计系统一致。

响应式预览类。可以快速切换不同设备尺寸，检查布局在不同视口下的表现。有些扩展还支持自定义尺寸，方便测试特定断点。

使用这些扩展的时机很重要。我一般会在两个阶段用：

1. 开发阶段：写完一个组件后，用扩展快速检查间距、颜色、字体是否符合规范
2. 走查阶段：整个页面完成后，用扩展做一次全面检查，记录问题并修复

5.2 可访问性检查扩展的自动化流程

可访问性是我认为最值得用浏览器扩展做自动化检查的领域。因为可访问性问题往往很隐蔽，人工检查容易遗漏，但扩展可以快速扫描整个页面并给出详细报告。

我常用的可访问性检查扩展通常基于 axe-core 引擎，可以检查：

• 颜色对比度是否达标
• 图片是否有 alt 文本
• 表单元素是否有 label
• 按钮和链接是否有可访问名称
• 页面结构是否使用了正确的标题层级
• ARIA 属性是否使用正确
• 键盘导航是否完整

使用流程一般是：

1. 打开目标页面
2. 点击扩展图标，运行扫描
3. 查看报告，按严重程度排序
4. 修复 critical 和 serious 级别的问题
5. 重新扫描确认修复

我自己的经验是，在开发阶段就把可访问性检查纳入流程，比上线后再补要省力得多。因为很多可访问性问题涉及到组件结构，后期修改成本很高。比如一个自定义下拉框如果没有正确的 ARIA 属性和键盘支持，后期补起来可能要重写整个组件。

5.3 把浏览器扩展检查结果反馈到 AI coding agents

浏览器扩展发现的问题，最终还是要回到代码里修复。这时候可以借助 AI coding agents 来提高修复效率。

我的做法是：把扩展报告里的问题描述复制给 AI，让它生成修复代码。比如扩展报告说“按钮的颜色对比度不足，当前对比度 3.2:1，需要达到 4.5:1”，我可以把这句话和按钮的 CSS 代码一起丢给 AI，让它调整颜色值。

但这里有一个注意事项：AI 修复后一定要用扩展重新检查。因为 AI 可能只解决了表面问题，比如把颜色调深了但引入了新的不一致，或者修复了对比度但破坏了 hover 状态。所以“扩展检查 → AI 修复 → 扩展复检”这个循环是必要的。

另外，我建议把常见的可访问性问题整理成一个 checklist，每次 AI 生成新组件后对照检查。这个 checklist 可以包括：

• 所有图片是否有 alt
• 所有表单元素是否有 label
• 所有交互元素是否支持键盘
• 所有文字对比度是否达标
• 所有动态内容是否有 ARIA live region
• 所有弹窗是否有焦点管理

这个 checklist 可以直接作为 prompt 的一部分喂给 AI，让它在生成代码时就考虑到这些问题。

6. 常见问题与排查技巧实录

6.1 AI 生成代码的视觉一致性问题排查

问题：AI 生成的组件间距不一致，有的用 8px 有的用 12px。

排查思路：先检查项目里有没有设计 token 文件。如果没有，AI 只能凭“感觉”写间距，不一致是必然的。如果有 token 文件但 AI 没用到，检查 token 文件的命名是否清晰、是否在 prompt 里明确告诉了 AI。

解决方法：建立一套完整的 spacing token，比如--space-1: 4px、--space-2: 8px、--space-3: 12px、--space-4: 16px，然后在 Stylelint 里配置declaration-property-value-allowed-list强制使用这些 token。同时在给 AI 的 prompt 里明确说“所有间距必须使用 var(--space-*) 变量”。

问题：AI 生成的颜色值不符合品牌规范。

排查思路：检查 AI 是否知道品牌色是什么。很多时候 AI 会使用“通用好看的颜色”，而不是你的品牌色。

解决方法：在项目根目录放一个design-tokens.json或tokens.css，把品牌色、辅助色、语义色都定义清楚。然后在 prompt 里引用这个文件。Stylelint 的color-no-hex规则可以强制 AI 使用 token 而不是硬编码颜色。

问题：AI 生成的响应式代码在某个断点下布局崩坏。

排查思路：检查 AI 是否知道你的断点定义。很多 AI 默认使用 768px 和 1024px 作为断点，但你的项目可能用的是 640px 和 960px。

解决方法：在项目配置文件里明确定义断点，并在 prompt 里告诉 AI。同时用浏览器扩展在不同视口下测试，发现崩坏后把具体问题描述给 AI 修复。

6.2 CLI 工具链的配置陷阱与解决方案

陷阱一：Stylelint 规则太严格导致开发效率下降。

我一开始把 Stylelint 配得非常严格，结果 AI 生成的代码几乎每条都要报错，修复成本很高。后来我调整了策略：先配置核心规则（颜色、间距、圆角），其他规则设为 warning 而不是 error。这样既保证了关键设计维度的一致性，又不会因为过度检查拖慢开发速度。

陷阱二：pa11y 在 CI 环境里跑不起来。

pa11y 依赖 Chrome 无头浏览器，在 CI 环境里经常因为缺少依赖或权限问题跑不起来。解决方案是在 CI 配置里加上--no-sandbox参数，并确保安装了必要的系统依赖。如果还是不行，可以考虑用 Docker 镜像来跑。

陷阱三：BackstopJS 的截图差异太多，无法判断哪些是真正的回归。

这个问题很常见，尤其是在页面有动态内容（比如时间戳、随机推荐）的时候。解决方案是：

• 在截图前用脚本固定动态内容
• 对动态区域使用selectors只截取静态部分
• 适当调高misMatchThreshold，比如从 0.1 调到 0.5
• 对已知会变化的区域使用hideSelectors隐藏

6.3 浏览器扩展与 CLI 检查结果冲突的处理

有时候 CLI 检查通过了，但浏览器扩展发现了问题。这种冲突通常是因为两者检查的层面不同。

比如 Stylelint 检查的是 CSS 代码里有没有用 token，但浏览器扩展检查的是实际渲染后的颜色对比度。一个元素可能用了正确的 token，但 token 本身的颜色值对比度不够。这种情况下，问题不在代码层面，而在设计 token 定义层面。

处理这类冲突的原则是：以运行时检查结果为准。因为用户看到的是渲染后的页面，不是代码。如果浏览器扩展报告了可访问性问题，即使 CLI 通过了，也要修复。

另一个常见冲突是：CLI 报告了问题但浏览器扩展没报告。这通常是因为 CLI 检查了浏览器扩展覆盖不到的场景，比如某个组件在当前页面没用到但代码里有问题。这种情况下，CLI 的报告仍然有效，应该修复。

我的一般流程是：CLI 检查作为第一道防线，在提交前拦截明显问题；浏览器扩展作为第二道防线，在运行时发现遗漏问题；两者结果都作为修复依据，以运行时结果优先。

7. 一套可复现的 impeccable 前端质量保障流程

7.1 项目初始化阶段的配置清单

如果你要从零开始搭建一套 impeccable 前端质量保障流程，可以按这个清单来配置：

设计 token 层：

• 创建tokens.css，定义颜色、间距、圆角、阴影、字体、断点
• 颜色 token 至少包括：primary、secondary、success、warning、error、neutral 系列
• 间距 token 使用 4px 基准，定义 1-12 的倍数
• 圆角 token 定义 sm、md、lg、full 四档
• 断点 token 定义 sm、md、lg、xl 四档

代码检查层：

• 配置 Stylelint，强制使用设计 token
• 配置 ESLint + jsx-a11y，检查可访问性
• 配置 Prettier，统一代码格式
• 配置 husky + lint-staged，提交前自动检查

运行时检查层：

• 配置 pa11y-ci，做可访问性扫描
• 配置 BackstopJS，做视觉回归测试
• 安装浏览器扩展，做手动走查

AI 协作层：

• 准备一份 prompt 模板，包含设计规范和检查清单
• 在项目根目录放design-tokens.json，方便 AI 读取
• 建立“AI 生成 → CLI 检查 → 扩展验证 → 人工确认”的流程

7.2 日常开发中的检查节奏

配置好了之后，日常开发中的检查节奏大概是这样的：

写代码时：AI 生成代码后，先跑npm run lint:all，修复所有 error 级别的问题。

提交前：husky 会自动运行 lint 检查，确保提交的代码符合规范。

组件完成后：用浏览器扩展做一次设计审查和可访问性检查，记录问题并修复。

页面完成后：跑一次 BackstopJS 视觉回归测试，确认没有意外的视觉变化。

合并请求时：CI 会自动运行所有检查，生成质量报告。

发布前：做一次完整的 pa11y 扫描和人工走查，确保所有页面都达标。

这个节奏的关键是把检查分散到开发过程中，而不是集中在最后。每次只检查一小部分，修复成本低，也不会因为问题积累太多而放弃修复。

7.3 团队协作中的规范落地经验

最后分享几个在团队里落地这套流程的经验。

第一，规范要写下来，不能只存在于某个人脑子里。我见过太多团队，设计规范全靠“问那个老员工”，新人来了要花几个月才能摸清楚。把 token、组件规范、检查规则都写成文件，放在项目里，新人可以直接看。

第二，自动化检查要循序渐进。不要一上来就把所有规则都设为 error，那样会让团队产生抵触情绪。先从最关键的几条开始，比如颜色和间距的 token 使用，等大家习惯了再逐步加规则。

第三，AI 生成的代码要有人 review。自动化检查能发现很多问题，但发现不了所有问题。特别是涉及设计判断、交互逻辑、边界情况的地方，还是需要人来把关。我的做法是：AI 生成的代码必须经过至少一个人 review 才能合并，review 的重点是“设计意图是否正确”而不是“代码能不能跑”。

第四，定期回顾和更新规范。设计系统不是一成不变的，随着产品迭代，可能会有新的颜色、新的间距、新的组件。定期（比如每个季度）回顾一次规范，把新的模式纳入进来，把不再使用的规则清理掉。

这套流程我自己用了大半年，最大的感受是：impeccable 不是一次性的目标，而是一个持续的过程。你不可能一次性把所有细节都做到完美，但你可以建立一套机制，让每一次提交、每一个组件、每一个页面都比上一次更接近 impeccable。AI coding agents、CLI 工具、浏览器扩展都是这个机制里的工具，真正重要的是背后的质量意识和持续改进的习惯。

最后再分享一个小技巧：我会在项目里放一个IMPECCABLE.md文件，记录当前项目在 impeccable 方面的已知问题和改进计划。每次发现新的问题就加进去，每次修复了就标记完成。这个文件不仅是团队的质量看板，也是给 AI 的上下文——在让 AI 生成代码时，我会把这个文件的内容作为 prompt 的一部分，让它知道当前项目在哪些方面还需要特别注意。实测下来，这个做法能明显提升 AI 生成代码的“贴合度”，减少反复修改的次数。