AI 生成的代码为什么还需要人盯着：从 Google 现代网页指南说起

AI 写代码听起来很香。让模型处理重复代码，按专家建议来做，速度自然就快了。Google 最近推出的 Modern Web Guidance（MWG），就是想把无障碍、性能、安全这些最佳实践直接喂给 AI 代理，让它按规矩做事。

结果呢？没那么顺利。

为什么无障碍不能当后期补丁

无障碍不是「做完再优化」的事，而是从第一行代码就要考虑进去的。MVPs 要是没把无障碍放在优先级，那它真的不算合格。

Google 演示 MWG 时举了个例子：生成一个手风琴统计组件，点击要平滑展开收起。听起来很简单。

AI 写出来的代码却直接翻车：在 Firefox 里动画不生效，也没达到 WCAG AA 标准。MWG 明明写了「基线感知集成」和「渐进增强」，AI 却完全没用上。

这不是小 bug，这是 LLM 的工作方式决定的。

LLM 的输出是不确定的

Google 的 MWG 文档里有一句藏在支持评论里的说明：

「LLM 的输出是非确定性的。即使我们把指南写得再好，也无法保证模型每次都会用到。」

翻译成人话：你设的规则，AI 不一定听。

这跟传统代码检查工具完全不同。linter 和类型系统是强制执行的，而 LLM 只是建议。它可能知道规则，也可能在生成时忽略掉。

组件指南不完整，问题会更严重

MWG 刚上线时，覆盖的组件模式还不够全。比如 toast 通知组件，Google 自己以前也在这上面踩过无障碍的坑，但 MWG 没给它单独的指南。

结果开发者要个 toast，AI 只能拼凑通用建议，容易出问题。

指南越零散，AI 就越难把它们正确组合起来。手风琴、toast、modal 这些组件的规则，最好放在一个地方，互相呼应，而不是散落在各处。

现在还做不到。

实际项目里该怎么应对

如果你现在用 AI 生成生产代码，现实是这样的：

LLM 是写作助手，不是质检工程师。 每行生成的代码都需要人工检查，尤其是：

• 无障碍合规（WCAG AA 对大多数商用项目来说是底线）
• 跨浏览器测试（「支持基线」这种承诺，没验证过就别信）
• 安全隐患（AI 写代码时可能引入不易察觉的漏洞）
• 性能影响（没加限制的 SPA 代码往往比较重）

正确的做法

这不是说 AI 辅助开发没用，而是要用得更清醒：

1. 别把 AI 输出当标准答案，要像审同事代码一样仔细看。
2. 建立反馈机制，把无障碍问题反馈回去，让模型有机会改进。
3. 要求明确的免责说明，那些号称「现代网页指南」的框架，应该先把不确定性和失败场景说清楚。
4. 把测试做进流程，axe、WAVE、Lighthouse 这些工具应该放在 CI/CD 里，不管代码是谁写的。

在 NameOcean，我们看好 AI 辅助开发，但也保持清醒。它适合搭架子、减 boilerplate、激发思路，但标准合规和用户体验这些事，还是得人来把关。

AI 时代，真正重要的技能不是「会写代码」，而是「会审代码、会改代码、愿意为最终产品负责」。这一点，AI 暂时还做不到。

Google 的 MWG 是个好尝试，但「有指南」和「能执行」是两回事。除非技术真正跟上，否则就把 AI 写的代码当成初稿，而不是最终成品。