AI说零Bug，QA闸门却抓出47个：一次前端验收实验

当AI自信地说「一切正常」

一个团队让AI代理构建了两个电商店铺前端。构建完成后，AI给出了令人安心的总结：「所有组件渲染完美。」这是典型的模型式自信——语法正确、数值合理、结构完整，从文本层面看确实无可挑剔。

但团队没有止步于阅读这份总结。他们写了一个脚本，在真实浏览器中打开真实页面，逐项断言检查。结果：47次失败。每一个失败，对写代码的模型来说都是不可见的。

这不是模型能力不足的偶发案例，而是一个结构性盲区的必然暴露。

为什么模型看不见这些问题

模型评判的是文本，不是结果。当一个模型审查自己产出的CSS时，它看到的是合法的语法和看似合理的取值——但它看不到购买栏在360px宽度下飘出屏幕外，看不到某个<img>路径在两张正常图片后面悄悄404，也看不到手风琴组件的唯一动画恰好是prefers-reduced-motion: reduce，也就是说，它恰恰在那些最需要减少动效的用户面前失效。

原文用了一个精准的比喻：自我审查就是模型用自己写的答案给自己批改作业。

更深层的问题在于反馈回路。模型生成代码时，隐式优化的目标是「文本看起来正确」，而不是「页面在真实设备上表现正确」。这两者之间的鸿沟，只有真实浏览器和可执行的断言才能跨越。

十项硬性检查：让退出码说话

团队最终固化的QA闸门包含十项检查，每项都是通过/失败二值判定，没有灰色地带：

1. 零水平溢出：在360、768、1024、1440、1920五个断点下检测
2. 每张图片真实加载：在网络层验证，不靠alt文本猜测
3. 对比度≥4.5:1：基于计算后的背景色判断所有文本
4. 触控目标≥44px：主流程上的可点击元素
5. 键盘可达的焦点环：每个交互元素都检查
6. 禁用JS后核心内容可见：保证基础可访问性
7. 减少动效模式仍能传达状态：或者干脆不做动画
8. 禁止slop指纹：无emoji项目符号、无靛蓝渐变、无玻璃拟态卡片——这些都可以用grep检测
9. 单一字体比例与间距比例：计算样式必须来自声明的token
10. 文案通过特异性测试：没有一句话可以原封不动出现在竞品网站上

关键的设计哲学是：代理无法与退出码争辩。 检查结果是客观的，不依赖审美判断，也不给模型留下自我辩护的空间。

**退出码（exit code）**是Unix/Linux进程结束时返回给父进程的一个0-255整数，0通常表示成功，非0表示某种失败。在CI/CD和自动化脚本中，退出码是判断步骤成败的唯一客观依据。文章强调「代理无法与退出码争辩」，正是因为退出码不包含任何自然语言解释或主观判断——它只有通过或失败两种状态。将QA检查实现为返回退出码的脚本，意味着模型生成的代码一旦触发任何一项失败，构建流水线就会立即中断，模型没有机会用「看起来没问题」来为自己辩护。这与依赖模型自评或人工审查有本质区别：前者是确定性的，后者是可被语言说服的。

对比度≥4.5:1中的4.5:1源自WCAG（Web内容可访问性指南）2.1的AA级标准，用于衡量文本与其背景之间的亮度对比是否足够。计算方式基于相对亮度公式，将RGB值转换为线性亮度后求比值。文章特别指出「基于计算后的背景色判断」，是因为背景可能由多层元素叠加或渐变构成，仅看CSS声明值并不可靠，必须在真实浏览器中获取最终渲染后的计算样式（computed style）才能准确判断。对于AI生成的UI，模型常选择低对比度的柔和配色，而这种偏好在文本层面难以察觉，只有通过自动化对比度检测才能暴露。

prefers-reduced-motion是一个CSS媒体查询，用于检测用户操作系统是否开启了「减少动画」辅助功能设置。对于前庭功能障碍或对动效敏感的用户，这一设置至关重要。文章中提到手风琴组件的唯一动画恰好在该模式下失效，意味着当用户明确要求减少动效时，组件反而无法传达状态变化。正确的做法是：在减少动效模式下，要么移除动画但保留即时状态切换，要么用非动画方式（如颜色、图标）传达状态。AI生成代码时往往只考虑默认模式，忽略媒体查询的降级分支，导致可访问性缺陷。

47个Bug的具体账本

原文披露了失败清单的部分细节，信息量很大：

• 购买栏在360px下飘出屏幕：两个构建中累计出现3次，不同原因导致同一症状。这说明窄屏适配是AI生成的系统性弱点——模型往往在桌面视口下「看起来对」，但移动端布局逻辑断裂。
• 图片路径断裂：只发生一次，但恰好发生在最关键的那张图上。概率低，杀伤力高。
• 间距值偏离比例：47个失败中有29个属于此类。模型「妥协」到了一个不存在任何比例体系的散乱间距上。这是AI生成UI最普遍、也最容易被肉眼忽略的问题：页面不会崩，但视觉节奏全无。
• Slop指纹命中：11次。全部在发布前修复，没有一次能被基于品味的评审发现——因为它们藏在细节里，不是风格问题，而是模式化生成的痕迹。

Slop指纹指AI生成内容中反复出现的模式化视觉痕迹，例如用emoji作为项目符号、默认使用靛蓝到紫色的渐变、以及滥用玻璃拟态（glassmorphism）卡片效果。这些特征本身并非错误，但大量出现会暴露内容由模型批量生成，缺乏品牌特异性。文章提出用grep检测，是因为这些痕迹在代码中表现为固定的CSS类名、颜色值或字符模式，可以通过文本搜索直接命中。将slop指纹纳入二值检查，实质上是把「品味」问题转化为可自动化的模式匹配问题，从而避免依赖主观评审。

提示词策略的转变：把闸门写进任务书

团队最重要的改变不在工具层，而在提示词层。他们不再要求AI「做得精致」，而是把十项检查随任务说明一起交给代理。

代理在写第一行代码之前就看到了验收标准，如果它「撒谎」——即产出无法通过检查——构建就会失败。同一个模型，不同的契约。

这个转变的意义在于重新定义了人与AI的协作关系：不是信任模型的自我报告，而是预先声明可验证的验收条件。模型仍然负责生成，但判断权完全交给了可执行的检查脚本。

原文还提到，完整的方法论、可运行的闸门代码以及每个bug的拆解都放在aiclub1.gumroad.com上，并给出了限时折扣码。免费版的「十项识别清单」也可单独获取。

对AI编程工作流的启示

这个案例的核心教训并不复杂：AI生成代码的可靠性，取决于验证机制的客观性，而非模型的自评质量。

对于正在把AI代理引入前端工作流的团队，有三点可以直接借鉴：

第一，把验收标准前置到提示词中，让模型知道它会被怎样检查。第二，用真实浏览器和退出码替代文本审查，这是唯一能捕获布局、资源和可访问性问题的层面。第三，把检查项做成二值断言，拒绝「看起来还行」这种模糊判断。

47这个数字之所以有说服力，不在于它大，而在于每一个失败都是模型声称不存在的问题。这正是QA闸门存在的理由。