Amazon 要求资深工程师审核 AI 生成代码：这不是倒退，是清醒
Amazon 最近做了一个引发争议的决定：要求初级和中级工程师提交的 AI 辅助代码变更，必须经过资深工程师审批才能上线。
这个决策的背景是一连串的生产事故。AWS 的 Kiro AI 编码工具在去年底直接「删除并重建了整个环境」，导致服务中断 13 小时。Amazon 零售技术团队的 Sev2 事故频率也在上升。VP Doug Treadwell 甚至把一个通常可选参加的周会改成了强制出席。
消息一出，社区炸了。一派认为这是对 AI 编码的打压，另一派觉得早该如此。
问题不在 AI，在于审核缺位
先说清楚：AI 生成的代码本身不是问题。问题是谁在审核这些代码，以及审核的标准是什么。
一个 junior 工程师用 Copilot 生成了 200 行代码，跑通了测试，提交了 PR。表面上一切正常。但资深工程师一眼就能看出：这段代码在并发场景下会死锁，或者在数据量到百万级时性能会断崖式下降。
AI 代码生成速度越快，人工审核的压力就越大
这不是 AI 的问题，这是工程经验的问题。AI 擅长生成「看起来对」的代码，但它不理解系统的上下文 — 不知道这个服务每秒处理多少请求，不知道下游依赖的超时设置，不知道上次类似的改动为什么被回滚。
「Verification Debt」正在吞噬团队
我之前写过 Verification Debt（验证债务）的概念。Amazon 的案例是一个教科书级别的例证。
当团队大规模裁员（Amazon 今年 1 月又裁了 16000 人），同时大规模推广 AI 编码工具，你得到的不是效率提升，而是一个危险的组合：
- 生成速度 ↑↑↑
- 审核能力 ↓↓↓
- 系统复杂度 → （没变，甚至更高）
代码生成的速度远超人类审核的速度。每一行未经充分审核就上线的代码，都在积累验证债务。债务积累到一定程度，就是生产事故。
这不是 Amazon 一家的问题
几乎所有大规模采用 AI 编码的团队都会遇到同样的挑战。区别只在于：有些团队在事故之前建立了防线，有些团队在事故之后。
Amazon 选择了事后。但至少它做了正确的调整。
资深工程师审核这个要求，本质上是在做一件事：把人类判断力重新插入到 AI 工作流中。不是禁止 AI，而是确保有人能为最终结果负责。
这其实和自动驾驶的逻辑一样 — L2 辅助驾驶再好，你也需要一个能随时接管的司机。AI 编码现在就处于 L2 阶段。
对开发者的启示
如果你是 junior 工程师：不要把 AI 审核流程看成障碍。每次资深工程师在你的 AI 生成代码上留下 comment，都是免费的技术培训。这种 review 能帮你理解 AI 看不到的系统上下文。
如果你是 senior 工程师：准备好你的审核量要上升了。建议建立 AI 代码审核的 checklist — 重点关注边界条件、并发安全、性能退化和系统兼容性。
如果你是技术管理者：现在就制定 AI 编码的治理规范，不要等到出了事故。
写在最后
AI 编码工具的能力还在快速进化。今天需要资深工程师审核的问题，也许一两年后 AI 自己就能发现。但在那一天到来之前，人类的工程判断力仍然是最后一道防线。
在多模型并存的时代，选对工具、用对流程比什么都重要。像 OfoxAI（ofox.ai）这样的多模型聚合平台，让你在不同模型之间快速切换和对比，找到最适合特定任务的那一个 — 而不是把所有赌注押在单一工具上。
Amazon 的这次调整，本质上是在告诉行业：跑得快很重要，但别忘了系好安全带。
参考来源：Ars Technica