猛裁1.6万人后，网站再崩6小时、一周4次重大事故，官方“紧急复盘”：跟裁员无关，也不是AI写代码的锅

CSDN·2026年03月11日 20:30

工程师猜测：故障变多可能和大裁员有关？

过去几年里，科技公司几乎都在同一件事上加速：让 AI 参与写代码。

从自动补全、自动生成函数，到直接修改系统配置，生成式 AI 已经逐渐走进真实生产环境。但最近发生在亚马逊的一连串事故，却给整个行业泼了一盆冷水——当 AI 开始真正参与生产环境开发时，事情可能远比想象复杂。

最近，多家媒体披露，本周二亚马逊内部紧急召开了一场工程“深度复盘（deep dive）”会议，专门讨论最近频繁出现的系统故障——其中，一个被反复提及的关键词是：AI 辅助代码。

一周 4 次严重事故，亚马逊内部紧急复盘

事情的起点，是最近一段时间亚马逊系统稳定性明显下降。

负责亚马逊网站技术架构的高级副总裁 Dave Treadwell 在一封内部邮件中坦言：“各位，正如大家可能已经知道的，最近网站及相关基础设施的可用性确实不太理想。”

为此，公司决定把原本每周例行举行的技术会议 “This Week in Stores Tech”（简称 TWiST）临时改成一次“深度复盘会议”。通常来说，TWiST 会议对员工是自愿参加的，但这一次，Treadwell 要求工程师尽量全部参加。

这场会议在周二中午 12:30 召开，主要目标只有一个：弄清楚最近这一连串系统故障到底是怎么发生的——Treadwell 在内部邮件中透露，仅仅在一周时间内，公司就发生了 4 起 Sev1 级别事故。

这里解释一下：在亚马逊的事故分级体系中，Sev1 即最高级别事故，通常意味着核心系统宕机或关键功能严重受影响。

也就是说，这已经不是普通的小 Bug，而是直接影响业务运行的大问题。

其中，最明显的一次事故就发生在上周。

当天，亚马逊网站和购物 App 突然出现大规模故障，持续时间接近 6 小时。在这段时间里，大量用户无法完成商品结算、查看账户信息、查询商品价格……简单来说，整个电商核心流程几乎停摆。

事后，亚马逊对此给出的解释是：这次事故源于一次错误的软件代码部署。不过并没有进一步披露细节，比如是否涉及 AI 生成代码等。

不仅如此，去年 12 月亚马逊云计算部门 AWS 也曾发生一次持续 13 小时的服务中断。

根据多家媒体报道，那次事故发生的原因是：工程师允许内部 AI 编程工具 Kiro 修改系统环境，而 AI 在执行任务时选择了一个极端操作——删除并重新创建了整个运行环境。

不过，亚马逊后来回应称，那次问题本质上是人为操作失误，并非 AI 本身造成的。

但事实上，据《金融时报》报道，在此次会议的准备材料中，亚马逊的一份内部文档曾提到：过去几个季度，公司出现了一种“事故趋势”，其中一个因素就是“GenAI 工具辅助的代码变更”。

这份文档还指出了一个关键问题：一些新的生成式 AI 使用方式，目前还没有成熟的工程规范和安全防护机制。

不过，根据 CNBC 获得的更新版本文件显示，在亚马逊内部会议开始前，涉及 GenAI 的那一条内容被删除了——知情人士表示，该调整可能与内部信息敏感性有关。

在媒体报道发布后，亚马逊发言人进一步回应称：近期的事故中只有一起与 AI 相关，没有任何事件是 AI 直接编写代码导致的。发言人还强调，这次会议本身只是“常规运营”的一部分：

“TWiST 是零售技术负责人每周举行的例会，我们会在会上评估网站和应用的运行情况，并持续改进系统可用性。”

虽然亚马逊试图淡化 AI 的直接责任，但内部仍然决定采取新的工程措施，而最核心的一条规则就是：今后任何 AI 辅助生成的代码修改，都需要更高级别工程师审批。

换句话说：初级工程师可以用 AI 改代码，但不能直接上线，必须由资深工程师签字确认——某种意义上，这相当于给 AI 生成代码增加了一层“人工安全阀”。

但对于这项新规定，一些分析师也提出了担忧。例如，Constellation Research 首席分析师 Chirag Mehta 就表示：“如果每次 AI 改代码都需要高级工程师去逐行审核，那么企业很可能把 AI 带来的效率优势又还回去了。”

而真正的风险也并不是 AI 会犯错，毕竟人类工程师同样会犯错——真正的问题在于：AI 会把错误放大。正如 Info-Tech Research Group 的研究总监 Manish Jain 所说，AI 最大的危险是它压缩了人类干预和纠正问题的时间。

LexisNexis Risk Solutions 的 CISO Flavio Villanustre 给出了一个很形象的比喻：“AI 就像一个非常聪明但没有安全意识的孩子。”在 AI Agent 技术出现之后，软件开发速度已经大幅提升，企业的治理体系却没有同步升级，AI 策略还过于激进。

如果企业直接让这样的系统操作关键基础设施，结果就是：小 Bug 可能瞬间影响大规模系统、修复时间窗口变得更短、事故影响范围更大——因此，虽然“人类审核”会降低效率，但目前看来，这仍是必要的安全措施。

除了AI工具，一些亚马逊工程师还把最近频发的系统故障指向另一个原因——大裁员。

此前有多名员工表示，由于团队规模大幅缩减，工程团队每天需要处理更多“Sev2”级别事故。亚马逊内部，“Sev2”指的是：需要快速响应，否则可能导致产品服务中断的严重事件。

众所周知，亚马逊在过去几年中确实进行了多轮大规模裁员。最近一次是在今年 1 月，裁掉了约 1.6 万个岗位。不过，亚马逊官方否认裁员与其系统故障有关，并表示系统稳定性评估只是公司的“常规运营流程”。

那么，在你看来，最近亚马逊频发的系统故障是什么原因导致的呢？

参考链接：https://arstechnica.com/ai/2026/03/after-outages-amazon-to-make-senior-engineers-sign-off-on-ai-assisted-changes/

本文来自微信公众号“CSDN”，整理：郑丽媛，36氪经授权发布。

该文观点仅代表作者本人，36氪平台仅提供信息存储空间服务。