想了解AWS如何在短短三周内两次通过博客文章反驳《金融时报》的报道吗？从AI工具的责任归属到工程师的权限管理，这些公关策略揭示了亚马逊在AI叙事中的优先级与潜在危机。
本文译自 2 Ways to Correct the Financial Times at AWS (So Far) - Last Week in AWS Blog[1]
亚马逊发货最快的产品，现在或许是对《金融时报》报道的博客文章更正。
我已经观察AWS足够长的时间，能够察觉到一家公司的沟通何时从“告知”转变为“应对”。这条分界线大约出现在2月20日左右，当时亚马逊在其官方网站上发布了一篇博客文章[2]，标题直白——“纠正《金融时报》关于AWS、Kiro和AI的报道”。三周后（3月11日），他们发布了另一篇[3]：“纠正《金融时报》关于最近亚马逊服务事件和AI的报道”。
三周，两次“纠正《金融时报》”。这更新频率，比大多数AWS服务的发布节奏还要快。
第一篇：Kiro事件与“用户错误”
去年12月，AWS的AI编码助手Kiro（去年7月高调推出，但由于自身容量问题，当时据说仅有约七名活跃用户）在一个生产环境中执行了CloudFormation的拆除和替换操作。这直接导致了其中国大陆分区的Cost Explorer服务中断。《金融时报》对此进行了报道。
亚马逊的官方回应核心是：“报道中提到的短暂服务中断是由于用户错误——具体来说是配置错误的访问控制——而非报道所指的AI。”他们还试图将影响范围淡化为“39个区域中的一个”，而非“整个分区的Cost Explorer”，原因不明。
翻译一下，亚马逊的逻辑是：AI完全按照指令行事，问题在于人类本不该下达这样的指令，更不该拥有下达指令的权限。这一切都不是AI的错。并且，你为什么要一直追问AI的问题？
我此前在《The Register》上报道过此事[4]。简而言之：亚马逊宁愿牺牲自家工程师的声誉，也不愿承认其AI工具可能在事故中扮演了某种角色。而他们提出的修复方案——对AI生成的生产变更实施强制性同行评审——恰好需要那些已被裁员的成千上万名员工。这就像是解雇了所有救生员，然后转身责怪溺水者。
第二篇：零售宕机与“错误建议”
三周过去，新事件来了。据报道，亚马逊的零售网站（非AWS）在短短一周内遭遇了一系列宕机。当然，这只是“据报”；我当时正在阿巴拉契亚小径徒步度假，根本不关心亚马逊在做什么。不过，看起来确实发生了多起严重程度不一的事件。《金融时报》的报道再次提及了AI编写的代码。
于是，亚马逊发布了另一篇博客文章。这次他们想澄清的是：“最近的事件中，只有一个与AI工具有关，并且在那次事件中，根本原因与AI无关。”那么，这唯一相关的事件是什么？一名工程师遵循了AI工具提供的不准确建议，而该工具摄入了一份过时的内部文档。亚马逊极其明确地强调：没有任何事件涉及“AI编写的代码”。
所以，故事变成了：AI并没有编写糟糕的代码。它只是读取了过时文档，给出了错误建议，工程师照做了，最终因缺乏足够的保障措施而引发连锁反应，破坏了生产环境。
这……似乎并不是亚马逊以为的那种有力辩护。
模式：防御性公关与叙事优先
我认为真正有趣的地方在于模式。当AWS发生一次普通的、人为引起的宕机时，你通常只会在服务健康仪表板上看到简短通知，严重时可能有一份事后分析报告。仅此而已。据我所知，AWS从未就一次常规服务中断，专门发布博客文章要求《金融时报》进行更正。他们通常能专业地承担起自己的失败。
但是，一旦有报道暗示AI可能牵涉其中？三周内两篇博客文章。企业公关机器全速运转，进入全面防御状态。“纠正记录。”“虚假指控。”“完全错误。”
宕机本身或许不是故事，但对宕机的反应才是故事。
亚马逊似乎对“AI引发生产事故”的舆论如此恐惧，以至于他们仿佛开发了一套全新的事件响应流程：宕机发生，服务恢复，记者闻讯而来，公关团队蜂拥而上，最后亚马逊发布博客解释为什么AI绝对无辜、一切都是工程师的错，并反问“你们为什么总揪着AI不放？”
不堪的数学：裁员、AI与归咎
以下是亚马逊可能不希望公众串联起来的事件链条。在过去一年多的时间里，亚马逊：
- 裁掉了公司数千名员工。
- 积极推动剩余团队采用AI编码工具，态度之坚决堪比家长逼孩子吃蔬菜。
- 其CEO在全员大会[5]上表示，AI将助力AWS在2036年实现年收入6000亿美元的目标——这是此前预测的两倍。
- 经历了一系列生产事故，其中至少有一部分涉及AI工具。
- 发表防御性博客文章，坚称问题不在于AI，而在于人类。
请再读一遍这个列表。他们一边削减人力，一边强制推行AI，而当事情出错时，却指责人类没有正确监督AI。
这展现了一家渴望享受AI辅助开发的生产力红利，却不愿承担任何相关风险的公司心态。成功时，这是AI驱动的创新；失败时，这是人为失误。AI成了薛定谔的工程师：它既是软件开发的未来，又与任何事故毫无干系。
真正令人担忧的是什么？
我并不认为AI编码工具本身特别危险。亚马逊的宕机频率或严重性或许也不异常——任何大公司都可能经历糟糕的一周。真正让我担忧的，是这种条件反射式的反应模式。
一个健康的工程文化，在面对“你的AI工具是否导致了事故”的质疑时，会回应：“是的，有可能。这是我们为预防再次发生所做的改进。”而不健康的工程文化，则会发布居高临下的声明，试图教育记者他们错了，甚至可能暗示记者愚蠢，并将责任完全归咎于人类。
构建和运营这些系统的工程师是富有才华的群体，他们在日益苛刻的条件下努力工作。他们需要的，是在事态失控时给予支持的管理层，而非那些为了保护产品叙事而将他们推出去担责的领导。
亚马逊的AI工具可能很棒，也可能平庸。我没有大规模使用过Kiro，无法下定论。但我知道的是：这家公司花费更多精力去捍卫AI的声誉，而非其工程师的声誉。这足以说明他们的优先事项排序。
下次再有问题发生时，我会密切关注aboutamazon.com的博客。照这个趋势，“纠正《金融时报》”或许会成为一个固定栏目。也许他们该让AI来维护这个系列的RSS订阅源。关于云计算巨头如何平衡技术创新与责任归属的讨论，在云栈社区这样的技术社区中也常引发深思。
引用链接
[1] 2 Ways to Correct the Financial Times at AWS (So Far) - Last Week in AWS Blog: https://www.lastweekinaws.com/blog/2-ways-to-correct-the-financial-times-at-aws-so-far/
[2] 发布了一篇博客文章: https://www.aboutamazon.com/news/aws/aws-service-outage-ai-bot-kiro
[3] 另一篇: https://www.aboutamazon.com/news/company-news/amazon-outage-ai-financial-times-correction
[4] 报道了此事: https://www.theregister.com/2026/02/24/amazon_blame_human_not_ai/
[5] 全员大会: https://www.reuters.com/business/amazon-ceo-sees-ai-doubling-his-prior-aws-sales-projections-600-billion-by-2036-2026-03-17/
发表于 4 小时前
|
查看: 1|
回复: 0
