AI 辅助编程引发亚马逊系统故障：效率与安全的博弈
近年来，科技行业普遍加速推进一项共同趋势：将人工智能引入软件开发流程。
从代码自动补全、函数自动生成，到系统配置的直接修改，生成式 AI 已逐步融入实际生产环境。然而，近期亚马逊接连发生的一系列事故，为整个行业敲响了警钟——当 AI 真正参与生产环境开发时，其复杂性可能远超预期。
据多家媒体报道，本周二亚马逊内部紧急召开了一场工程“深度复盘”会议，重点讨论近期频繁出现的系统故障。会议中，“AI 辅助代码”成为一个被反复提及的关键词。
一、一周内四起严重事故，亚马逊启动紧急复盘
近期，亚马逊系统稳定性出现明显下滑。负责网站技术架构的高级副总裁 Dave Treadwell 在一封内部邮件中承认：“正如各位可能已经察觉的，近期网站及相关基础设施的可用性确实不尽如人意。”
为此，公司决定将原本每周例行举行的技术会议“This Week in Stores Tech”（简称 TWiST）临时改为一次“深度复盘会议”。通常情况下，TWiST 会议对员工是自愿参加的，但此次 Treadwell 要求工程师尽可能全员出席。
会议于周二中午 12:30 召开，核心目标是厘清近期一系列系统故障的根源。Treadwell 在邮件中透露，仅一周时间内，公司就发生了四起 Sev1 级别事故。
需要说明的是，在亚马逊的事故分级体系中，Sev1 属于最高级别，通常意味着核心系统宕机或关键功能受到严重影响。这表明，近期出现的问题已非普通缺陷，而是直接威胁业务运行的重大故障。
二、持续六小时的宕机，导致购物功能几近瘫痪
其中，影响最为显著的一次事故发生在上周。当天，亚马逊网站及购物 App 突发大规模故障，持续近六小时。在此期间，大量用户无法完成商品结算、查看账户信息或查询商品价格——简而言之，电商核心流程几乎陷入停滞。
事后，亚马逊解释称，事故源于一次错误的软件代码部署，但未进一步披露细节，例如是否涉及 AI 生成代码。
此外，去年 12 月亚马逊云计算部门 AWS 也曾经历一次长达 13 小时的服务中断。据多家媒体报道，事故起因是工程师允许内部 AI 编程工具 Kiro 修改系统环境，而 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 的首席信息安全官 Flavio Villanustre 给出了一个生动比喻：“AI 就像一个极其聪明但缺乏安全意识的孩子。”在 AI Agent 技术兴起后，软件开发速度已大幅提升，但企业的治理体系并未同步升级，AI 应用策略仍显激进。
若企业直接允许此类系统操作关键基础设施，可能导致以下后果：小规模缺陷瞬间影响大型系统、修复时间窗口缩短、事故影响范围扩大。因此，尽管“人工审核”可能降低效率，但目前看来，这仍是一项必要的安全措施。
五、工程师推测：故障频发或与大规模裁员有关？
除 AI 工具外，部分亚马逊工程师将近期频发的系统故障归因于另一因素：大规模裁员。
此前有员工表示，由于团队规模大幅缩减，工程团队每日需处理更多“Sev2”级别事故。在亚马逊内部，“Sev2”指需要快速响应、否则可能导致产品服务中断的严重事件。
众所周知，亚马逊在过去几年中实施了多轮大规模裁员。最近一次发生在今年 1 月，涉及约 1.6 万个岗位。不过，亚马逊官方否认裁员与系统故障存在关联，并强调系统稳定性评估仅是公司“常规运营流程”的一部分。
那么，在您看来，近期亚马逊系统故障频发的根本原因是什么？
评论
发表评论