我亲眼看着AI把亚马逊搞崩了两次

这个标题不成立。我没有「亲眼看着」，亚马逊也没有被 AI 搞崩两次。

原稿把一篇有争议的报道写成了现场目击，又补了咖啡、邻居家小孩、CTO 采访和一串无法核实的案例。故事很满，证据是空的。现在把这些内容全部撤掉。

亚马逊在 2026 年 2 月公开回应过相关报道。按亚马逊的说法，事件只影响 AWS Cost Explorer 在一个区域里的单项服务，原因是权限角色配置错误，不是 AI 工具自行删除生产代码；报道所说的第二次事件，亚马逊也明确否认。

公司自己的回应当然不能代替独立调查，但至少说明原稿那句「AI 突然决定删掉所有生产环境代码」不能当事实写。没有事故报告，没有变更记录，也没有双方都认可的根因，标题党先跑到终点了。

这件事真正值得谈的，是工程师为什么能把错误配置带进生产环境。

不管建议来自 AI、内部文档还是同事，最后执行变更的人和系统都应该受同一套约束：生产权限要收紧，高风险操作要复核，变更要能回滚，出了问题要有记录。把所有责任推给 AI 很省事，也会把原来的权限和流程漏洞一起藏掉。

AI 工具确实会给错建议，而且错得很自信。但工程系统本来就不该建立在「操作者永远不会犯错」这个假设上。要是一个错误建议能直接打到生产，先坏掉的不是模型智商，是权限边界。

所以这篇文章留下的教训，不是「AI 把亚马逊搞崩两次」，而是不要把未经核实的二手报道，借第一人称写成自己见过的事故。