1. 当“impeccable”成为前端交付的硬指标我们到底在讨论什么第一次看到“impeccable”这个词被拿来形容前端产出是在一个做设计系统的朋友嘴里。他说他们团队现在评审页面不再说“好看”“能用”而是问一句这个交付算不算 impeccable当时我愣了一下——这个词直译是“无可挑剔的”听起来像句客套话但在前端语境里它其实指向一套非常具体的东西视觉还原度、交互一致性、边界状态覆盖、可访问性、性能预算全都得在线缺一项就谈不上无可挑剔。而把“impeccable”和 AI coding agents、frontend design、CLI、browser extension 这几个词放在一起事情就变得有意思了。它描述的其实是一种新的工作流你不再纯手工从零写页面而是让 AI 编码代理coding agent承担大量重复性的前端实现工作同时用命令行工具CLI和浏览器扩展browser extension把“检查、验证、修正”这条链路自动化最终让 AI 产出的前端代码达到接近人工精修的水准。这套思路解决的核心问题是AI 写前端快是快但默认产出往往“能跑但糙”——间距不对、状态缺失、响应式塌陷、语义标签乱用。impeccable 要做的就是把这个“糙”给磨平。这篇文章适合谁看如果你已经在用 AI 辅助写前端但每次生成完还得手动改半天那这篇就是写给你的如果你是团队里负责前端质量的那个人正在琢磨怎么把 AI 产出纳入可验收的流程那更值得往下读。我会围绕“怎么让 AI 前端产出变得无可挑剔”这条主线把 CLI 工具链、浏览器扩展验证、代理协作模式、以及我踩过的坑一层层拆开讲。需要先说明的是输入里除了标题和几个热词之外没有更多原始材料所以文中涉及的具体工具用法、参数配置都是基于当前主流 AI 编码代理和前端工程实践的合理补全你可以把它当成一套可落地的参考方案而不是某个特定产品的官方文档。2. 拆解 impeccable 在前端语境下的四层含义2.1 视觉层像素级还原不是强迫症是验收标准很多人对“像素级还原”有误解觉得那是设计师的执念。但在 AI 生成前端代码的场景里视觉还原度直接决定了你要不要返工。AI 代理拿到一份设计稿或者一段描述它默认会按“最省事”的方式实现——比如用固定像素写死宽度、用 margin 硬顶间距、忽略设计系统里的 spacing token。结果就是页面在标准视口下看着还行一换分辨率就散架。impeccable 在视觉层的要求本质是要求 AI 产出必须遵循设计系统的约束而不是自由发挥。具体来说间距要用 token比如 4px 基准的倍数颜色要走变量字号要落在 type scale 上圆角和阴影要有统一来源。我自己的做法是在给 AI 代理的上下文里永远附上一份精简的 design token 清单明确告诉它“只能用这些值”。这一步看起来多余但实测下来能砍掉至少一半的视觉返工。2.2 交互层状态覆盖才是 AI 最容易漏的地方AI 写前端最大的短板不是布局是状态。你让它写一个按钮它给你默认态你让它写一个列表它给你有数据的样子。但真实产品里按钮有 hover、active、focus、disabled、loading列表有空态、加载态、错误态、超长内容态。这些 AI 默认不写因为它没见过你的业务边界。所以 impeccable 的第二层含义是状态完备性。我在实际项目里总结了一个“状态清单法”每让 AI 生成一个组件就在 prompt 里附上这个组件需要覆盖的状态列表生成完再逐项核对。这个动作很机械但它是把 AI 产出从“demo 级”拉到“生产级”的关键分水岭。没有这一步你的页面永远停留在“演示能看、上线就崩”的阶段。2.3 语义层可访问性和 SEO 的隐性成本第三层是语义。AI 生成 HTML 时特别喜欢用 div 套 div因为这样最“安全”不会出错。但代价是语义丢失——屏幕阅读器读不懂搜索引擎抓不到重点键盘导航一团糟。impeccable 要求 AI 产出使用正确的语义标签导航用 nav主内容用 main按钮就用 button 而不是 div 加 onClick表单控件必须有关联的 label。这一层最容易被忽略因为它在视觉上完全看不出来。但它的成本是隐性的、后置的等到要做无障碍适配或者 SEO 优化时你会发现整个结构都得重写。我的经验是在 AI 代理的系统提示里就把语义规则写死让它从第一次生成就带上正确的标签比事后补救便宜得多。2.4 性能层AI 不会主动帮你省字节第四层是性能。AI 代理生成代码时倾向于“功能优先”它不会主动考虑这个组件会不会导致布局抖动、这张图会不会拖慢首屏、这段逻辑会不会让包体积膨胀。impeccable 在性能层的要求是给 AI 产出设定预算图片必须带尺寸属性、非关键资源延迟加载、避免不必要的客户端渲染。这四层叠在一起才是完整的 impeccable。它不是某一个工具能搞定的而是一套“生成—验证—修正”的闭环。接下来的章节我会讲怎么用 CLI 和浏览器扩展把这个闭环搭起来。3. CLI 工具链把 AI 前端产出纳入可验证的流水线3.1 为什么 CLI 是这套工作流的中枢在 AI 编码代理的生态里CLI 扮演的角色经常被低估。很多人觉得 CLI 就是敲命令跑脚本但在 impeccable 这套思路里CLI 是唯一能把“AI 生成”和“自动验证”串起来的粘合剂。原因很简单浏览器扩展能看页面但不好批量跑IDE 插件能补全但不好做流水线只有 CLI既能被 AI 代理调用又能被 CI 调用还能被你自己在终端里手动触发。我现在的习惯是任何让 AI 代理生成的前端代码落地后第一件事不是打开浏览器看而是在终端里跑一遍检查命令。这个顺序很重要——先让机器告诉你哪里不合格再用人眼判断哪里不好看。机器能查的东西语义、可访问性、未使用变量、图片尺寸缺失就别浪费眼睛。3.2 一条典型的检查命令长什么样假设你用某个 AI 编码代理生成了一个页面组件落地到项目里。一个可参考的检查流程是这样的# 1. 静态检查语义、可访问性、潜在错误 npx eslint src/components/GeneratedPage.tsx --ext .tsx # 2. 样式约束检查是否用了设计系统外的值 npx stylelint src/**/*.css --config .stylelintrc.json # 3. 构建体积检查对比基线看有没有异常膨胀 npx bundlesize # 4. 可访问性快扫基于静态分析 npx axe src/components/GeneratedPage.tsx这几条命令的价值在于它们把“impeccable”里那些抽象的形容词翻译成了可执行的规则。eslint 管语义和潜在 bugstylelint 管设计系统约束bundlesize 管性能预算axe 管可访问性。你不需要一次全上但每加一条AI 产出的下限就抬高一点。提示这些命令的具体包名和参数会随工具版本变化落地前先确认你项目里实际安装的版本别直接照抄。3.3 把检查结果喂回给 AI 代理CLI 检查真正的威力不在于“发现问题”而在于“把问题结构化地喂回给 AI 代理”。我试过两种方式效果差别很大。第一种是人工看报错然后手动改 prompt 让 AI 重写。这种方式慢而且容易漏。第二种是把 CLI 的输出直接作为上下文追加到 AI 代理的下一轮 prompt 里让它自己根据报错修正。比如 eslint 报了一堆可访问性错误我就把报错原文贴给代理说“根据这些报错修正组件不要引入新问题”。实测下来第二种方式的修正准确率明显更高因为 AI 拿到的是具体的、带行号的反馈而不是我转述的模糊描述。这里有个细节值得注意喂回去的报错要过滤。有些报错是项目配置问题不是 AI 产出的问题混在一起会让代理困惑。我的做法是先用--quiet或者规则白名单只保留和本次生成相关的报错。3.4 常见 CLI 工具的选型对比工具类型代表工具在 impeccable 流程里的作用上手成本代码检查ESLint语义、潜在 bug、可访问性规则低样式约束Stylelint设计系统 token 一致性中体积监控bundlesize / size-limit性能预算守门低可访问性axe-core CLI无障碍静态扫描中格式化Prettier统一代码风格减少 diff 噪音低选型的原则是优先选能被 AI 代理理解和调用的工具也就是输出格式清晰、报错信息具体的。那些报错含糊、需要人工解读的工具放进自动化链路里反而添乱。4. 浏览器扩展AI 前端验证里最被低估的一环4.1 浏览器扩展补上了 CLI 看不到的那一半CLI 很强但它有个天然盲区它看不到真实渲染结果。一个组件在静态分析里完全合格渲染出来可能间距错位、层级混乱、响应式塌陷。这时候就需要浏览器扩展出场。浏览器扩展在 impeccable 流程里的定位是“运行时验证”。它能做几件 CLI 做不到的事实时查看 DOM 结构和计算样式、模拟不同视口、检查对比度、录制交互流程。对于 AI 生成的前端这些能力尤其关键因为 AI 最容易在“运行时表现”上翻车——它写的代码静态看没问题一跑起来就露馅。4.2 用扩展做视觉回归的实操思路视觉回归是浏览器扩展最实用的场景之一。我的做法是在 AI 生成组件后用扩展截取标准视口下的截图和设计稿或者上一版截图做对比。差异超过阈值的地方就是需要人工确认或者让 AI 修正的地方。具体操作上很多浏览器扩展支持“元素级截图”和“全页截图”两种模式。元素级适合检查单个组件全页适合检查整体布局。我一般先用全页截图快速扫一遍发现异常区域再用元素级放大看。这个流程比逐个组件检查快得多尤其是在 AI 一次生成多个组件的时候。注意视觉回归的对比阈值要调太严会把抗锯齿差异也报出来太松会漏掉真实问题。我的经验是先从宽松阈值开始稳定后再逐步收紧。4.3 交互状态录制的价值AI 生成的前端交互状态是最容易出问题的地方。浏览器扩展的交互录制功能可以帮你把 hover、focus、点击、展开这些状态逐个走一遍并记录每一步的 DOM 变化和样式变化。这比手动点一遍靠谱得多因为手动操作容易漏状态而且不好复现。我通常会在录制前先列一个状态清单就是 2.2 节提到的那个然后按清单逐个触发用扩展记录。录完之后回放重点看两件事状态切换时有没有布局抖动以及状态样式有没有正确应用。这两类问题在静态检查里基本查不出来只有运行时录制才能抓到。4.4 扩展和 CLI 的分工边界这里要说清楚一个容易混淆的点浏览器扩展和 CLI 不是替代关系是分工关系。CLI 负责“代码层面能查的”扩展负责“运行时才能看的”。两者覆盖的检查项基本不重叠所以理想状态下应该都跑。检查维度CLI 能否覆盖浏览器扩展能否覆盖语义标签正确性能能辅助验证设计 token 一致性能部分运行时布局抖动不能能交互状态样式不能能对比度部分能响应式断点表现不能能包体积能不能这张表基本说明了为什么两者都得有。只跑 CLI你会漏掉所有运行时问题只用扩展你会漏掉代码层面的规范和体积问题。5. 让 AI 代理真正“理解”impeccable 的提示词设计5.1 系统提示里必须写死的几条规则AI 代理的产出质量八成取决于你给它的约束。我现在的做法是在系统提示或者项目级配置里写死几条不可协商的规则让代理每次生成都默认遵守。这几条规则对应前面讲的四层含义所有间距、颜色、字号必须来自提供的 design token 清单禁止硬编码具体数值。每个交互组件必须覆盖默认、hover、focus、active、disabled、loading 六种状态缺一不可。HTML 结构必须使用语义标签禁止用 div 模拟按钮、链接、表单控件。所有图片必须带 width 和 height 属性非首屏图片必须标记懒加载。这四条看起来简单但能挡掉 AI 产出里最常见的几类问题。关键是“写死”——不要指望代理自己想起来它不会。5.2 用示例驱动代替规则堆砌规则写多了代理会疲劳生成时反而顾此失彼。我的经验是规则控制在十条以内剩下的用示例驱动。具体做法是在上下文里放一两个“标杆组件”也就是你自己手写的、完全符合 impeccable 标准的组件然后告诉代理“新组件按这个标准来”。示例驱动的好处是代理能从具体代码里推断出隐含的规范比如命名习惯、文件组织方式、注释风格这些用规则描述很啰嗦但看一个例子就懂了。我试过纯规则和规则加示例两种方式后者的产出明显更接近“能直接用”的状态。5.3 分轮生成别指望一次到位还有一个反直觉的经验不要指望 AI 代理一次生成 impeccable 的代码。我的做法是分轮——第一轮只生成结构和语义第二轮补状态和样式第三轮根据 CLI 和扩展的反馈修正。每轮的目标单一代理的注意力集中产出质量反而更高。分轮生成还有个附带好处每轮的 diff 小review 起来快。如果一次生成一大坨出了问题很难定位是哪部分逻辑的锅。分轮之后哪轮引入的问题一目了然。6. 实测中反复出现的坑与修正方案6.1 设计 token 被“聪明地”绕过这是最常见的坑。你明明给了 token 清单代理还是会在某些地方硬编码数值理由是“这里用 token 不合适”。比如它会给某个特殊间距写个 13px说“这个位置需要微调”。这种“聪明”的绕过是 impeccable 的大敌。修正方案有两个一是用 stylelint 的规则强制禁止硬编码数值让它在检查阶段就暴露二是在提示词里明确说“任何偏离 token 的值都必须先问我不许自己决定”。我两个都用双保险。6.2 状态覆盖的“假完备”代理有时候会假装覆盖了状态比如给按钮写了 hover 样式但 hover 和默认态视觉上没区别等于没写。这种“假完备”比不写还危险因为它骗过了你的检查清单。我的应对是在验证阶段用浏览器扩展逐个触发状态截图对比。如果两个状态的截图完全一样就说明状态没真正实现。这个检查很机械但能抓出所有假完备。6.3 语义标签的“过度使用”另一个极端是代理过度使用语义标签比如把整个侧边栏塞进一个 nav或者给每个 section 都加 aria-label。这会让可访问性树变得臃肿反而降低体验。修正的关键是给代理明确的语义层级示例告诉它“nav 只用于主导航section 只在有明确标题时使用”。语义标签不是越多越好是越准越好。6.4 性能预算被无声突破AI 生成代码时很容易引入体积膨胀比如为了一个小功能引入整个工具库或者重复引入同一份依赖。这种问题在开发阶段不明显上线后才暴露。我的做法是在 CI 里挂 bundlesize设定基线超过就报警。同时定期用依赖分析工具扫一遍看有没有冗余依赖。这个动作不频繁但每次都能抓到几个“AI 顺手引入”的多余包。7. 把 impeccable 变成团队习惯而不是个人技巧7.1 从个人流程到团队规范一个人用 impeccable 这套流程效果有限变成团队规范威力才出来。关键是把前面讲的检查项固化成团队的前端交付标准CLI 检查进 CI浏览器扩展检查进 code review 清单AI 代理的提示词模板进项目仓库。我见过最有效的做法是把“impeccable 检查清单”做成一个 PR 模板每个前端 PR 提交时自动带上reviewer 逐项打勾。这个动作看起来形式主义但它把隐性的质量标准变成了显性的、可追踪的流程。7.2 让 AI 代理的产出可追溯团队协作里AI 生成的代码必须可追溯——哪部分是代理生成的哪部分是人工改的改了什么。我的做法是要求代理生成的代码带特定注释标记比如// ai-generated人工修改后在旁边加// human-edited: 原因。这样 review 时能快速定位需要重点看的部分。这个习惯一开始会有人嫌麻烦但等到出问题需要回溯时它的价值就体现出来了。尤其是当多个代理、多轮生成混在一起时没有标记根本理不清。7.3 定期回顾代理的“翻车模式”AI 代理的翻车是有规律的而且会随模型版本变化。我的团队每两周做一次回顾把这段时间代理产出里反复出现的问题列出来然后针对性调整提示词或者检查规则。比如有段时间代理老是漏掉空态我们就在提示词里把空态单独拎出来强调问题就少了。这个回顾机制的价值在于它让 impeccable 从“一次性配置”变成“持续优化”。代理在进化你的约束也得跟着进化。8. 关于这套流程我自己的几点体会用 impeccable 这套思路管 AI 前端产出最深的体会是AI 不会自动变得无可挑剔无可挑剔是被约束出来的。你给的约束越具体、越可验证产出就越接近标准。反过来如果你只是说“帮我写个好看的页面”那产出的上限就是“能看”。另一个体会是CLI 和浏览器扩展的组合本质上是在给 AI 产出建一道“质量闸门”。闸门越密漏过去的次品越少。但闸门也不能太密否则代理每生成一点就被拦效率反而下降。找到那个平衡点是这套流程能不能长期跑下去的关键。最后一点别把 impeccable 当成终点。它是个动态标准——今天无可挑剔的产出明天可能因为设计系统升级、性能预算收紧、可访问性要求提高而变得不够看。所以这套流程里最重要的不是某条具体规则而是“持续检查和修正”这个机制本身。机制在标准就能跟着涨机制不在再漂亮的规范也是纸上的。
1. 当“impeccable”成为前端交付的硬指标我们到底在讨论什么第一次看到“impeccable”这个词被拿来形容前端产出是在一个做设计系统的朋友嘴里。他说他们团队现在评审页面不再说“好看”“能用”而是问一句这个交付算不算 impeccable当时我愣了一下——这个词直译是“无可挑剔的”听起来像句客套话但在前端语境里它其实指向一套非常具体的东西视觉还原度、交互一致性、边界状态覆盖、可访问性、性能预算全都得在线缺一项就谈不上无可挑剔。而把“impeccable”和 AI coding agents、frontend design、CLI、browser extension 这几个词放在一起事情就变得有意思了。它描述的其实是一种新的工作流你不再纯手工从零写页面而是让 AI 编码代理coding agent承担大量重复性的前端实现工作同时用命令行工具CLI和浏览器扩展browser extension把“检查、验证、修正”这条链路自动化最终让 AI 产出的前端代码达到接近人工精修的水准。这套思路解决的核心问题是AI 写前端快是快但默认产出往往“能跑但糙”——间距不对、状态缺失、响应式塌陷、语义标签乱用。impeccable 要做的就是把这个“糙”给磨平。这篇文章适合谁看如果你已经在用 AI 辅助写前端但每次生成完还得手动改半天那这篇就是写给你的如果你是团队里负责前端质量的那个人正在琢磨怎么把 AI 产出纳入可验收的流程那更值得往下读。我会围绕“怎么让 AI 前端产出变得无可挑剔”这条主线把 CLI 工具链、浏览器扩展验证、代理协作模式、以及我踩过的坑一层层拆开讲。需要先说明的是输入里除了标题和几个热词之外没有更多原始材料所以文中涉及的具体工具用法、参数配置都是基于当前主流 AI 编码代理和前端工程实践的合理补全你可以把它当成一套可落地的参考方案而不是某个特定产品的官方文档。2. 拆解 impeccable 在前端语境下的四层含义2.1 视觉层像素级还原不是强迫症是验收标准很多人对“像素级还原”有误解觉得那是设计师的执念。但在 AI 生成前端代码的场景里视觉还原度直接决定了你要不要返工。AI 代理拿到一份设计稿或者一段描述它默认会按“最省事”的方式实现——比如用固定像素写死宽度、用 margin 硬顶间距、忽略设计系统里的 spacing token。结果就是页面在标准视口下看着还行一换分辨率就散架。impeccable 在视觉层的要求本质是要求 AI 产出必须遵循设计系统的约束而不是自由发挥。具体来说间距要用 token比如 4px 基准的倍数颜色要走变量字号要落在 type scale 上圆角和阴影要有统一来源。我自己的做法是在给 AI 代理的上下文里永远附上一份精简的 design token 清单明确告诉它“只能用这些值”。这一步看起来多余但实测下来能砍掉至少一半的视觉返工。2.2 交互层状态覆盖才是 AI 最容易漏的地方AI 写前端最大的短板不是布局是状态。你让它写一个按钮它给你默认态你让它写一个列表它给你有数据的样子。但真实产品里按钮有 hover、active、focus、disabled、loading列表有空态、加载态、错误态、超长内容态。这些 AI 默认不写因为它没见过你的业务边界。所以 impeccable 的第二层含义是状态完备性。我在实际项目里总结了一个“状态清单法”每让 AI 生成一个组件就在 prompt 里附上这个组件需要覆盖的状态列表生成完再逐项核对。这个动作很机械但它是把 AI 产出从“demo 级”拉到“生产级”的关键分水岭。没有这一步你的页面永远停留在“演示能看、上线就崩”的阶段。2.3 语义层可访问性和 SEO 的隐性成本第三层是语义。AI 生成 HTML 时特别喜欢用 div 套 div因为这样最“安全”不会出错。但代价是语义丢失——屏幕阅读器读不懂搜索引擎抓不到重点键盘导航一团糟。impeccable 要求 AI 产出使用正确的语义标签导航用 nav主内容用 main按钮就用 button 而不是 div 加 onClick表单控件必须有关联的 label。这一层最容易被忽略因为它在视觉上完全看不出来。但它的成本是隐性的、后置的等到要做无障碍适配或者 SEO 优化时你会发现整个结构都得重写。我的经验是在 AI 代理的系统提示里就把语义规则写死让它从第一次生成就带上正确的标签比事后补救便宜得多。2.4 性能层AI 不会主动帮你省字节第四层是性能。AI 代理生成代码时倾向于“功能优先”它不会主动考虑这个组件会不会导致布局抖动、这张图会不会拖慢首屏、这段逻辑会不会让包体积膨胀。impeccable 在性能层的要求是给 AI 产出设定预算图片必须带尺寸属性、非关键资源延迟加载、避免不必要的客户端渲染。这四层叠在一起才是完整的 impeccable。它不是某一个工具能搞定的而是一套“生成—验证—修正”的闭环。接下来的章节我会讲怎么用 CLI 和浏览器扩展把这个闭环搭起来。3. CLI 工具链把 AI 前端产出纳入可验证的流水线3.1 为什么 CLI 是这套工作流的中枢在 AI 编码代理的生态里CLI 扮演的角色经常被低估。很多人觉得 CLI 就是敲命令跑脚本但在 impeccable 这套思路里CLI 是唯一能把“AI 生成”和“自动验证”串起来的粘合剂。原因很简单浏览器扩展能看页面但不好批量跑IDE 插件能补全但不好做流水线只有 CLI既能被 AI 代理调用又能被 CI 调用还能被你自己在终端里手动触发。我现在的习惯是任何让 AI 代理生成的前端代码落地后第一件事不是打开浏览器看而是在终端里跑一遍检查命令。这个顺序很重要——先让机器告诉你哪里不合格再用人眼判断哪里不好看。机器能查的东西语义、可访问性、未使用变量、图片尺寸缺失就别浪费眼睛。3.2 一条典型的检查命令长什么样假设你用某个 AI 编码代理生成了一个页面组件落地到项目里。一个可参考的检查流程是这样的# 1. 静态检查语义、可访问性、潜在错误 npx eslint src/components/GeneratedPage.tsx --ext .tsx # 2. 样式约束检查是否用了设计系统外的值 npx stylelint src/**/*.css --config .stylelintrc.json # 3. 构建体积检查对比基线看有没有异常膨胀 npx bundlesize # 4. 可访问性快扫基于静态分析 npx axe src/components/GeneratedPage.tsx这几条命令的价值在于它们把“impeccable”里那些抽象的形容词翻译成了可执行的规则。eslint 管语义和潜在 bugstylelint 管设计系统约束bundlesize 管性能预算axe 管可访问性。你不需要一次全上但每加一条AI 产出的下限就抬高一点。提示这些命令的具体包名和参数会随工具版本变化落地前先确认你项目里实际安装的版本别直接照抄。3.3 把检查结果喂回给 AI 代理CLI 检查真正的威力不在于“发现问题”而在于“把问题结构化地喂回给 AI 代理”。我试过两种方式效果差别很大。第一种是人工看报错然后手动改 prompt 让 AI 重写。这种方式慢而且容易漏。第二种是把 CLI 的输出直接作为上下文追加到 AI 代理的下一轮 prompt 里让它自己根据报错修正。比如 eslint 报了一堆可访问性错误我就把报错原文贴给代理说“根据这些报错修正组件不要引入新问题”。实测下来第二种方式的修正准确率明显更高因为 AI 拿到的是具体的、带行号的反馈而不是我转述的模糊描述。这里有个细节值得注意喂回去的报错要过滤。有些报错是项目配置问题不是 AI 产出的问题混在一起会让代理困惑。我的做法是先用--quiet或者规则白名单只保留和本次生成相关的报错。3.4 常见 CLI 工具的选型对比工具类型代表工具在 impeccable 流程里的作用上手成本代码检查ESLint语义、潜在 bug、可访问性规则低样式约束Stylelint设计系统 token 一致性中体积监控bundlesize / size-limit性能预算守门低可访问性axe-core CLI无障碍静态扫描中格式化Prettier统一代码风格减少 diff 噪音低选型的原则是优先选能被 AI 代理理解和调用的工具也就是输出格式清晰、报错信息具体的。那些报错含糊、需要人工解读的工具放进自动化链路里反而添乱。4. 浏览器扩展AI 前端验证里最被低估的一环4.1 浏览器扩展补上了 CLI 看不到的那一半CLI 很强但它有个天然盲区它看不到真实渲染结果。一个组件在静态分析里完全合格渲染出来可能间距错位、层级混乱、响应式塌陷。这时候就需要浏览器扩展出场。浏览器扩展在 impeccable 流程里的定位是“运行时验证”。它能做几件 CLI 做不到的事实时查看 DOM 结构和计算样式、模拟不同视口、检查对比度、录制交互流程。对于 AI 生成的前端这些能力尤其关键因为 AI 最容易在“运行时表现”上翻车——它写的代码静态看没问题一跑起来就露馅。4.2 用扩展做视觉回归的实操思路视觉回归是浏览器扩展最实用的场景之一。我的做法是在 AI 生成组件后用扩展截取标准视口下的截图和设计稿或者上一版截图做对比。差异超过阈值的地方就是需要人工确认或者让 AI 修正的地方。具体操作上很多浏览器扩展支持“元素级截图”和“全页截图”两种模式。元素级适合检查单个组件全页适合检查整体布局。我一般先用全页截图快速扫一遍发现异常区域再用元素级放大看。这个流程比逐个组件检查快得多尤其是在 AI 一次生成多个组件的时候。注意视觉回归的对比阈值要调太严会把抗锯齿差异也报出来太松会漏掉真实问题。我的经验是先从宽松阈值开始稳定后再逐步收紧。4.3 交互状态录制的价值AI 生成的前端交互状态是最容易出问题的地方。浏览器扩展的交互录制功能可以帮你把 hover、focus、点击、展开这些状态逐个走一遍并记录每一步的 DOM 变化和样式变化。这比手动点一遍靠谱得多因为手动操作容易漏状态而且不好复现。我通常会在录制前先列一个状态清单就是 2.2 节提到的那个然后按清单逐个触发用扩展记录。录完之后回放重点看两件事状态切换时有没有布局抖动以及状态样式有没有正确应用。这两类问题在静态检查里基本查不出来只有运行时录制才能抓到。4.4 扩展和 CLI 的分工边界这里要说清楚一个容易混淆的点浏览器扩展和 CLI 不是替代关系是分工关系。CLI 负责“代码层面能查的”扩展负责“运行时才能看的”。两者覆盖的检查项基本不重叠所以理想状态下应该都跑。检查维度CLI 能否覆盖浏览器扩展能否覆盖语义标签正确性能能辅助验证设计 token 一致性能部分运行时布局抖动不能能交互状态样式不能能对比度部分能响应式断点表现不能能包体积能不能这张表基本说明了为什么两者都得有。只跑 CLI你会漏掉所有运行时问题只用扩展你会漏掉代码层面的规范和体积问题。5. 让 AI 代理真正“理解”impeccable 的提示词设计5.1 系统提示里必须写死的几条规则AI 代理的产出质量八成取决于你给它的约束。我现在的做法是在系统提示或者项目级配置里写死几条不可协商的规则让代理每次生成都默认遵守。这几条规则对应前面讲的四层含义所有间距、颜色、字号必须来自提供的 design token 清单禁止硬编码具体数值。每个交互组件必须覆盖默认、hover、focus、active、disabled、loading 六种状态缺一不可。HTML 结构必须使用语义标签禁止用 div 模拟按钮、链接、表单控件。所有图片必须带 width 和 height 属性非首屏图片必须标记懒加载。这四条看起来简单但能挡掉 AI 产出里最常见的几类问题。关键是“写死”——不要指望代理自己想起来它不会。5.2 用示例驱动代替规则堆砌规则写多了代理会疲劳生成时反而顾此失彼。我的经验是规则控制在十条以内剩下的用示例驱动。具体做法是在上下文里放一两个“标杆组件”也就是你自己手写的、完全符合 impeccable 标准的组件然后告诉代理“新组件按这个标准来”。示例驱动的好处是代理能从具体代码里推断出隐含的规范比如命名习惯、文件组织方式、注释风格这些用规则描述很啰嗦但看一个例子就懂了。我试过纯规则和规则加示例两种方式后者的产出明显更接近“能直接用”的状态。5.3 分轮生成别指望一次到位还有一个反直觉的经验不要指望 AI 代理一次生成 impeccable 的代码。我的做法是分轮——第一轮只生成结构和语义第二轮补状态和样式第三轮根据 CLI 和扩展的反馈修正。每轮的目标单一代理的注意力集中产出质量反而更高。分轮生成还有个附带好处每轮的 diff 小review 起来快。如果一次生成一大坨出了问题很难定位是哪部分逻辑的锅。分轮之后哪轮引入的问题一目了然。6. 实测中反复出现的坑与修正方案6.1 设计 token 被“聪明地”绕过这是最常见的坑。你明明给了 token 清单代理还是会在某些地方硬编码数值理由是“这里用 token 不合适”。比如它会给某个特殊间距写个 13px说“这个位置需要微调”。这种“聪明”的绕过是 impeccable 的大敌。修正方案有两个一是用 stylelint 的规则强制禁止硬编码数值让它在检查阶段就暴露二是在提示词里明确说“任何偏离 token 的值都必须先问我不许自己决定”。我两个都用双保险。6.2 状态覆盖的“假完备”代理有时候会假装覆盖了状态比如给按钮写了 hover 样式但 hover 和默认态视觉上没区别等于没写。这种“假完备”比不写还危险因为它骗过了你的检查清单。我的应对是在验证阶段用浏览器扩展逐个触发状态截图对比。如果两个状态的截图完全一样就说明状态没真正实现。这个检查很机械但能抓出所有假完备。6.3 语义标签的“过度使用”另一个极端是代理过度使用语义标签比如把整个侧边栏塞进一个 nav或者给每个 section 都加 aria-label。这会让可访问性树变得臃肿反而降低体验。修正的关键是给代理明确的语义层级示例告诉它“nav 只用于主导航section 只在有明确标题时使用”。语义标签不是越多越好是越准越好。6.4 性能预算被无声突破AI 生成代码时很容易引入体积膨胀比如为了一个小功能引入整个工具库或者重复引入同一份依赖。这种问题在开发阶段不明显上线后才暴露。我的做法是在 CI 里挂 bundlesize设定基线超过就报警。同时定期用依赖分析工具扫一遍看有没有冗余依赖。这个动作不频繁但每次都能抓到几个“AI 顺手引入”的多余包。7. 把 impeccable 变成团队习惯而不是个人技巧7.1 从个人流程到团队规范一个人用 impeccable 这套流程效果有限变成团队规范威力才出来。关键是把前面讲的检查项固化成团队的前端交付标准CLI 检查进 CI浏览器扩展检查进 code review 清单AI 代理的提示词模板进项目仓库。我见过最有效的做法是把“impeccable 检查清单”做成一个 PR 模板每个前端 PR 提交时自动带上reviewer 逐项打勾。这个动作看起来形式主义但它把隐性的质量标准变成了显性的、可追踪的流程。7.2 让 AI 代理的产出可追溯团队协作里AI 生成的代码必须可追溯——哪部分是代理生成的哪部分是人工改的改了什么。我的做法是要求代理生成的代码带特定注释标记比如// ai-generated人工修改后在旁边加// human-edited: 原因。这样 review 时能快速定位需要重点看的部分。这个习惯一开始会有人嫌麻烦但等到出问题需要回溯时它的价值就体现出来了。尤其是当多个代理、多轮生成混在一起时没有标记根本理不清。7.3 定期回顾代理的“翻车模式”AI 代理的翻车是有规律的而且会随模型版本变化。我的团队每两周做一次回顾把这段时间代理产出里反复出现的问题列出来然后针对性调整提示词或者检查规则。比如有段时间代理老是漏掉空态我们就在提示词里把空态单独拎出来强调问题就少了。这个回顾机制的价值在于它让 impeccable 从“一次性配置”变成“持续优化”。代理在进化你的约束也得跟着进化。8. 关于这套流程我自己的几点体会用 impeccable 这套思路管 AI 前端产出最深的体会是AI 不会自动变得无可挑剔无可挑剔是被约束出来的。你给的约束越具体、越可验证产出就越接近标准。反过来如果你只是说“帮我写个好看的页面”那产出的上限就是“能看”。另一个体会是CLI 和浏览器扩展的组合本质上是在给 AI 产出建一道“质量闸门”。闸门越密漏过去的次品越少。但闸门也不能太密否则代理每生成一点就被拦效率反而下降。找到那个平衡点是这套流程能不能长期跑下去的关键。最后一点别把 impeccable 当成终点。它是个动态标准——今天无可挑剔的产出明天可能因为设计系统升级、性能预算收紧、可访问性要求提高而变得不够看。所以这套流程里最重要的不是某条具体规则而是“持续检查和修正”这个机制本身。机制在标准就能跟着涨机制不在再漂亮的规范也是纸上的。
