1. 当"impeccable"成为前端交付的硬指标，我们到底在讨论什么
第一次看到"impeccable"这个词被拿来形容前端代码，是在一个做设计系统的朋友嘴里。他说他们团队现在 review 代码，不看"能不能跑"，只看"够不够 impeccable"——像素级对齐、状态覆盖完整、边界情况不崩、动效不抖。这个词本身是"无可挑剔"的意思，放在前端语境里，它其实指向一个很具体的东西：交付质量的下限被抬高了。
过去我们评价一个前端页面，标准往往是"功能对不对""在主流浏览器上能不能正常显示"。但现在不一样了。AI coding agents 大量介入开发流程之后，代码的产出速度被拉到了一个前所未有的高度，一个下午生成十几个组件是常态。问题随之而来：生成得快，不等于生成得好。大量 AI 产出的前端代码存在共性问题——间距靠猜、颜色硬编码、响应式断点缺失、loading 和 error 状态直接忽略、hover 和 focus 样式随手一写。这些东西单看每一处都不致命，但堆在一起，页面就是"能用但不好用"，离 impeccable 差着十万八千里。
所以这篇内容我想聊的，不是某个具体框架的 API，而是围绕 impeccable 这个目标，怎么把 AI coding agents、CLI 工具链、浏览器扩展这几样东西串起来，形成一套能真正提升前端交付质量的工作流。关键词里出现的 CLI、browser extension、frontend design、AI coding agents，本质上都是为这个目标服务的工具。适合谁看？如果你正在用 AI 辅助写前端，或者团队里已经开始大规模引入代码生成工具，但发现产出质量参差不齐，那这篇就是写给你的。如果你还是纯手写前端，这里面的检查思路和工具用法同样适用，因为 impeccable 的标准对人和对 AI 是一样的。
我自己的判断是：impeccable 不是一个可以靠"更努力地写代码"达成的状态，它是一个需要靠工具链和流程去兜底的状态。人会有状态起伏，AI 会有幻觉，唯一可靠的办法是把"挑剔"这件事本身工程化。下面我按这个思路，从工具链的搭建讲到具体的检查项，再讲到实际踩过的坑。
2. 把 AI coding agents 拉进前端工作流：它擅长什么，又在哪里翻车
2.1 AI coding agents 在前端场景的真实能力边界
先说结论：AI coding agents 在前端领域的能力，呈现出非常明显的"两极分化"。它极其擅长的是结构化的、有明确模式的代码生成——比如给你一个设计稿的描述，生成一个 React 组件的骨架；比如把一段重复的列表渲染逻辑抽成可复用的组件；比如根据已有的样式规范，批量生成一组按钮的变体。这些任务有清晰的输入输出，模式固定，AI 的准确率相当高。
但它翻车的地方同样明显，而且往往翻在"impeccable"最在意的地方。我总结了几类高频问题：
- 间距和尺寸靠"感觉"：AI 生成
padding: 13px这种非规范值的情况非常普遍，因为它没有你的设计 token 体系的概念，除非你明确喂给它。 - 状态覆盖不全：默认只写"正常态"，loading、empty、error、disabled、focus-visible 这些状态要么不写，要么写得敷衍。
- 响应式是事后补的：很多 AI 生成的组件默认按桌面宽度写死，断点逻辑是后来硬塞进去的，导致中间尺寸下布局错乱。
- 可访问性基本靠运气：
aria-label、语义化标签、键盘导航顺序，这些 AI 经常漏。
理解这个边界很重要，因为它决定了你应该把 AI 放在工作流的哪个位置。我的做法是：让 AI 负责"从 0 到 0.7"的骨架生成，把"从 0.7 到 1"的打磨交给工具链和人工 review。指望 AI 一步到位产出 impeccable 的代码，目前还不现实，但把它当成一个高效的初稿生成器，配合后面的检查工具，整体效率能提升一大截。
2.2 给 AI 喂对上下文，比换更强的模型更管用
很多人抱怨 AI 生成的前端代码质量差，第一反应是换个更强的模型。但我实测下来，上下文的质量对产出质量的影响，远大于模型本身的差异。同样一个组件生成任务，你给 AI 的上下文里有没有设计 token、有没有现有的组件范例、有没有明确的约束条件，结果天差地别。
我一般会在项目根目录放一个专门给 AI 看的约束文件，内容大致包括：
# 前端代码约束 ## 间距体系 只允许使用 4 的倍数：4, 8, 12, 16, 24, 32, 48, 64 禁止出现 13px、15px、18px 这类非规范值 ## 颜色 必须引用 CSS 变量，禁止硬编码 hex 可用变量：--color-primary, --color-text, --color-border, --color-bg-subtle ## 组件必须覆盖的状态 default / hover / focus-visible / active / disabled / loading / error / empty ## 响应式 断点：640px / 768px / 1024px / 1280px 移动优先，禁止只写桌面样式 ## 可访问性 交互元素必须有可见的 focus 样式 图标按钮必须有 aria-label这份文件不需要多复杂，但它把"impeccable"的标准显式化了。AI 拿到这份约束之后，生成padding: 13px的概率会大幅下降，因为它知道有规则在管着。这背后的逻辑很简单：AI 不会主动追求 impeccable，除非你告诉它 impeccable 长什么样。
2.3 用 CLI 把"生成"和"校验"串成一条流水线
光有约束文件还不够，因为 AI 依然会犯错。这时候 CLI 工具的价值就体现出来了——它能把校验这一步自动化。我目前的工作流是这样的：
- AI agent 生成组件代码
- 通过 CLI 跑一遍 lint 和自定义规则检查
- 检查不通过的地方，把错误信息回喂给 AI，让它自己修
- 修完再跑一遍，直到通过
这个循环听起来简单，但关键在于第 3 步的自动化。如果每次都要人工把错误信息复制粘贴给 AI，那效率提升有限。我用的方式是把 CLI 的输出直接管道给 agent，让它读取错误并修正。不同 CLI 工具的具体命令不一样，但核心思路是一致的：让机器去发现机器的问题，人只负责定义标准。
这里有个细节值得说：自定义规则比通用 lint 规则更重要。ESLint 的默认规则集管的是语法和常见错误，它管不了"你的间距是不是 4 的倍数"这种业务规范。所以我会写一些针对性的检查脚本，比如扫描所有 CSS/样式文件，找出不符合间距体系的值。这类脚本用 Node 写几十行就能搞定，但收益很大。
3. 浏览器扩展在 impeccable 检查里的独特位置
3.1 为什么静态检查不够，必须上浏览器
CLI 和 lint 能查的是代码层面的问题，但 impeccable 的很多问题只有在真实渲染之后才暴露。举个最典型的例子：两个元素在代码里看起来间距是对的，但实际渲染出来因为 margin collapse 或者 line-height 的影响，视觉上就是歪的。这种问题静态检查永远发现不了。
浏览器扩展在这里的价值就凸显了。它能在真实 DOM 上做检查，看到的是用户最终看到的东西。我常用的几类扩展功能包括：
- 间距和尺寸的可视化标注：直接在页面上画出元素的盒模型，一眼看出哪里对不齐。
- 颜色对比度检查：自动标出对比度不达标的文字，这对可访问性至关重要。
- 响应式预览：快速切换不同视口宽度，看断点行为。
- 状态模拟：强制元素进入 hover、focus、disabled 状态，检查这些平时看不到的样式。
这些功能单独看都不新鲜，但把它们组合进日常 review 流程之后，发现问题的效率完全不一样了。以前是"上线后用户反馈才发现"，现在是"提交前自己就能看到"。
3.2 把浏览器检查结果反馈回代码的闭环
浏览器扩展查出来的问题，怎么高效地回到代码里修？这是很多人忽略的一环。如果只是"看到了问题"，然后手动去代码里找对应位置，中间会浪费大量时间。
我的做法是：在开发环境下给每个组件加上可识别的标记，比如>
