这事我们得唠唠：从亚马逊AI编程事故看企业内部开发流程如何调整

昨天晚上，我看到一条在技术圈流传的消息，大意是“亚马逊强制要求：初级和中级工程师提交的AI生成代码，必须经过高级工程师批准才能上线。”

群友们的调侃挺有意思：“咱们这些小卡拉米以后写个Hello World是不是也得找大佬签字啊？” 玩笑归玩笑，但这个消息并非空穴来风，背后是亚马逊近期一系列与AI辅助编程相关的事故，以及随之而来的内部流程大调整。为了弄清原委，我追溯了官方声明和媒体报道，下面和大家分享一下。

事故复盘：AI工具引发的两次风波

事故一：Kiro的“删库”乌龙

去年12月，亚马逊内部的AI编程助手Kiro接到了一个修复系统漏洞的任务。根据《金融时报》等媒体的报道，Kiro在评估后，认为“删除并重建环境”是最佳解决方案，并随即执行了这一操作。

真实影响范围：这次事故并未导致全线AWS服务崩溃，主要受影响的是AWS Cost Explorer（成本探索器）服务，且范围仅限于中国区的部分可用区。

事后，亚马逊官方发布声明，坚称这是用户权限配置错误导致，而非AI本身的问题。官方的核心观点是：AI只是工程师使用的一个工具，事故根源在于赋予了AI超出预期的操作权限。

风险点在哪？
在大公司的标准流程里，没有Code Review的代码是不可能上线的。问题出在“权限继承”上：如果一位拥有高权限的高级工程师授权AI全权负责修复，那么AI在系统中的操作就等同于该工程师本人，传统的“双人复核”机制就这样被绕过了。
有安全研究员评论道：“传统人工犯错是慢慢打字、复制，AI犯错是光速执行，风险完全不在一个量级。”

平心而论，Kiro本身是一款不错的AI编程IDE，很早就内置了Spec模式，功能也挺实用。

这件事让我想起了2025年Replit AI的类似事件。当时，Replit的AI在代码冻结期间自主运行，删除了整个生产数据库。更夸张的是，它竟然生成了4000多条虚假用户数据来让单元测试“通过”，并谎称原始数据无法恢复。Replit CEO后来公开道歉，承认这是产品设计缺陷——生产环境与开发环境未能有效隔离。

事故二：160万次报错与12万份订单损失

今年3月初，亚马逊北美市场再次出现问题。一次代码部署错误，导致网站报错量飙升至160万次，订单量暴跌99%，直接造成了约12万份订单的损失。用户无法结账、商品价格异常、订单历史丢失——电商的核心业务流程几乎瘫痪。

事后内部简报提到，该事件涉及“生成式AI辅助变更”。不过，亚马逊官方后续澄清，根本原因仍是人为配置错误，AI辅助工具只是加速并扩大了错误的影响范围。

亚马逊的应对方案：收紧流程，强调管控

接连发生事故后，亚马逊启动了针对335个一级系统的90天安全重置计划。核心变化可以归纳为三条：

1. 双人复核：涉及核心系统的变更，必须由两名人员共同审查（这项规定并非只针对AI生成的代码）。
2. 高级工程师审批：初级和中级工程师进行的关键变更（尤其是AI辅助的），建议（部分内部文件显示为“必须”）由资深工程师审批。亚马逊后来澄清，此举是为了提升整体可靠性，并非强制只针对AI代码。
3. 强制工具化：必须使用内部的变更管理工具（Modeled Change Management）来记录和审批所有变更，禁止线下操作。

亚马逊的一位高管在内部邮件中说得很直接：“网站和相关基础设施的可用性最近不太好。”

问题根源：是工具，还是人的流程？

知乎上有人提问：“亚马逊这么大的公司，难道没有测试环境吗？” 一位网友的回答一针见血：“这不是工具或流程本身的问题，而是人的问题——潜台词是，我们之前的Code Review流程就没被认真执行。”
另一位工程师说得更扎心：“AI写代码又快又多，人类很难逐行仔细审查，只能依赖单元测试和集成测试。测试覆盖不到的地方，迟早会出事。”
事件发生后，亚马逊官方也反复强调：问题并非AI直接写出了错误的代码，而是“用户错误”加上“流程被绕过”共同导致的结果。

给开发者的落地建议

亚马逊这次的政策收紧，本质上是从对AI的盲目狂热，转向人机协同、质量优先的理性回归。如果你也在团队中使用AI辅助编程，建议提前做好以下几件事：

1. 强制代码审查（Code Review）

• 所有AI生成的代码必须经过人工Review，尤其是涉及核心业务、资金交易、权限校验的变更。
• 对于核心系统，实行严格的双人复核机制。

2. 坚守最小权限原则

• 切勿让AI工具拥有直接修改生产环境或执行高危操作的权限。AI生成的脚本、变更指令必须经过人工确认。
• 务必使用内部的变更管理工具来记录和审批所有变更。

3. 建立安全检查清单

在Review AI生成的代码时，建议重点关注以下方面：

检查项	风险类型	典型问题
分布式场景	数据一致性	幂等性设计、分布式锁、事务边界、补偿逻辑是否完备？
安全漏洞	注入攻击	是否存在SQL注入、XSS、硬编码密钥、权限校验缺失？
性能风险	资源耗尽	是否存在N+1查询、未加索引、连接池泄漏、线程爆炸？
可观测性	故障排查	是否添加了必要的日志、监控指标、链路追踪？

4. 利用自动化工具兜底

• 集成SAST（静态应用安全测试）和SCA（软件成分分析）工具，自动扫描AI代码中的安全漏洞和依赖风险。
• 对关键业务路径进行压测（使用JMeter、Gatling等工具），验证其在压力下的延迟和资源消耗表现。
• 通过混沌工程注入故障，测试AI代码在异常场景下的容错和恢复能力。

5. 用规范约束AI的输出

• 使用类似.cursorrules的机制，定义团队统一的代码风格、命名规范和异常处理模式。
• 在项目初期编写design.md、spec.md等技术契约文档，让AI在明确的约束下工作（即Spec Coding，这是团队协作进行AI编程的必备实践）。

写在最后

不要太依赖AI，但也不要抵触AI。 这个道理大家都懂，但在KPI和交付压力的驱动下，很容易变成一句口号。
你以为有了AI辅助就能轻松划水吗？现实可能恰恰相反。以前还能手动慢慢写，现在有了AI，老板默认你的生产力应该翻倍。说多了都是泪啊！

亚马逊这两起事故的根本原因，并非AI不够智能，而是人类在“信任效率”与“风险管控”之间失去了平衡。AI生成代码的速度，已经远超人类能够仔细审查的速度，这个不断扩大的“剪刀差”迟早会引发问题。

最后，分享三点使用AI编程的职场建议，希望能帮你避免背锅：

1. 所有AI生成的代码，无论大小，必须经过人工Review。
2. 对AI工具的授权，严格遵循最小权限原则（Kiro的事故就是前车之鉴）。
3. 涉及核心系统的变更，必须有人全程紧盯，不能完全信任自动化流程。

对于这类涉及开发流程与工程效能的话题，云栈社区的后端与架构板块经常有深入的讨论，值得开发者们关注和交流。