过去几年，科技公司纷纷加速拥抱一件事：让 AI 参与编写代码。
从代码自动补全、自动生成函数，到直接修改系统配置，生成式 AI 正逐步深入真实的生产环境。然而，亚马逊近期接连发生的事故，却给整个行业敲响了警钟——当 AI 真正参与核心系统的开发与运维时，带来的挑战可能远比想象中复杂。
近日，据多家媒体披露，亚马逊内部紧急召开了一场工程“深度复盘”会议，专门讨论近期频繁出现的系统故障。会议中，一个被反复提及的关键词是：AI 辅助代码。
一周内4起最高级别事故，内部召开紧急复盘会
事件的起因是亚马逊网站及相关基础设施的稳定性出现明显下滑。负责技术架构的高级副总裁 Dave Treadwell 在一封内部邮件中坦言：“正如大家可能已经知道的，最近网站及相关基础设施的可用性确实不太理想。”
为此，公司决定将每周例行的技术会议“This Week in Stores Tech”临时改为一次“深度复盘会议”。通常此会议是自愿参加的，但这一次 Treadwell 要求工程师尽量全部出席。
会议在周二中午召开，核心目标只有一个：厘清近期一系列系统故障的根本原因。Treadwell 在邮件中透露，仅在一周内，公司就发生了 4 起 Sev1 级别事故。
这里需要说明一下：在亚马逊的事故分级体系中，Sev1 属于最高级别，通常意味着核心系统宕机或关键业务功能受到严重影响。也就是说，这已不是普通 Bug，而是直接影响业务运行的重大问题。
一次长达6小时的宕机，电商核心流程近乎瘫痪
其中最严重的一次事故发生在上周。当天，亚马逊网站和购物 App 突然出现大规模故障，持续时间接近 6 小时。在此期间，大量用户无法完成商品结算、查看账户信息或查询商品价格，整个电商核心流程几乎停摆。
事后，亚马逊给出的官方解释是：事故源于一次错误的软件代码部署，但并未进一步披露细节，例如是否涉及 AI 生成代码。
不仅如此，去年 12 月亚马逊云计算部门 AWS 也曾发生一次持续 13 小时的服务中断。根据多家媒体报道，那次事故的原因是工程师允许内部 AI 编程工具执行修改系统环境的任务，而 AI 选择了一个极端操作——删除并重建了整个运行环境。不过，亚马逊后续回应称，那次问题本质上是人为操作失误，并非 AI 本身造成。
内部文件曾点名：GenAI代码变更是事故趋势之一
但据《金融时报》报道，在此次复盘会议的筹备材料中，亚马逊的一份内部文档曾明确指出：过去几个季度，公司出现了一种“事故趋势”，其中一个因素便是“GenAI 工具辅助的代码变更”。
该文档还指出了一个关键问题：一些新的生成式 AI 使用方式，目前尚缺乏成熟的工程规范和安全防护机制。不过，根据 CNBC 获得的更新版本文件，在会议开始前，涉及 GenAI 的这条内容被删除了——知情人士表示，此举可能与内部信息敏感性有关。
在媒体报道发酵后，亚马逊发言人进一步回应称，近期的事故中只有一起与 AI 相关，且没有任何事件是 AI 直接编写代码导致的。发言人强调，这次会议只是“常规运营”的一部分：“TWiST 是零售技术负责人每周举行的例会，我们会在会上评估网站和应用的运行情况，并持续改进系统可用性。”
AI辅助开发被“踩下刹车”：新增高级别人工审批
尽管亚马逊试图淡化 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 万个岗位。不过，亚马逊官方否认了裁员与系统故障之间的关联，并再次强调系统稳定性评估只是公司的“常规运营流程”。
亚马逊的这一系列事件，为整个技术行业提供了一个重要的反思案例：在追求开发效率与自动化的同时，如何为 AI 设定合理的安全边界、建立与之匹配的工程流程与运维治理体系，已成为确保系统长期稳定性的关键。关于 AI 在生产环境中的应用边界与最佳实践，也欢迎在云栈社区展开更多技术讨论。
发表于 3 小时前
|
查看: 4|
回复: 0
