一份泄露的内部备忘录显示，亚马逊在内部将AI辅助代码变更导致的事故描述为     「高爆炸半径（High Blast Radius）」趋势——     而官方对外的口径，是「此次宕机与AI工具无关」。     两个版本，你信哪个？   

事情是怎么发生的

     2026年初，亚马逊电商平台发生了一次严重宕机事故。全站服务中断长达数小时，用户无法正常下单，卖家后台瘫痪，全球各地的消费者看到的只有无限转圈的加载画面。   

     与此同时，亚马逊的云服务产品 AWS Cost Explorer（成本管理工具）也出现故障——据内部人士透露，这次故障与亚马逊内部AI编码助手 Kiro 推送的一次代码变更直接相关。   

5分钟回复，暴露了什么

     媒体向亚马逊发出问询后，不到5分钟便收到了官方回复。这个速度在科技行业的公关圈里极为罕见——通常一份官方声明需要经过法务审核、公关打磨、高管审批，最短也要几个小时。   

     如此迅速的回应，只能说明一件事：他们早就准备好了。问题是，为什么要提前准备？如果AI真的没有问题，为什么需要一份随时待命的危机公关稿？   

内部文件vs官方声明：两个平行世界

     这种割裂并非偶然。大型科技公司在AI问题上的公关逻辑是一致的：对外保持信心，对内追踪风险。因为一旦承认AI造成了生产级故障，就会引发监管、投资人、客户的连锁反应。   

     但「高爆炸半径」这个词本身就很说明问题。这是工程团队的术语，用于描述一次变更可能影响范围极广、难以快速回滚的风险场景。用这个词来描述AI代码变更，说明亚马逊内部工程师已经认识到问题的严重性。   

Kiro：亚马逊的内部AI编码助手

     Kiro是亚马逊内部开发并推广使用的AI编程助手，类似于GitHub Copilot在微软内部的定位。亚马逊一直在积极向内部工程师推广使用AI辅助编程，以提升开发效率。   

     然而，效率和安全性之间的平衡，始终是AI编码工具面临的核心矛盾。当AI可以在几秒钟内生成数百行代码时，人类工程师的审查能力是否还能跟上？代码测试和回归验证是否还够充分？   

这不只是亚马逊的问题

• AI代码缺乏「意图理解」：AI生成的代码在语法上可能完全正确，但不理解业务上下文，可能在边缘情况下导致灾难性故障。
• 审查流程被加速压缩：引入AI工具的本意是提速，但这往往导致人工审查时间被压缩，风险把关趋于形式化。
• 责任归属模糊化：出了问题，是AI的错还是写Prompt的工程师的错？还是批准上线的Tech Lead的错？没有清晰的答案。
• 事故模式正在形成：亚马逊内部备忘录中提到的是「趋势」，而非单次事故——说明类似问题已经多次发生。
• 监管尚未跟上：目前全球没有任何监管机构对AI生成代码导致的服务中断制定明确的问责标准。

接下来会怎样

     亚马逊不会是最后一家面对这个问题的公司。随着AI编码工具在科技行业的快速普及，类似的「高爆炸半径」事故将会越来越频繁地出现在各大平台的故障复盘报告中——无论这些报告是否会对外公开。   

     真正的问题在于：当事故发生时，公司的第一反应是面向外部的形象管理，还是真正面向内部的技术反思？从亚马逊这次5分钟极速回应来看，答案似乎是前者。