嘿，听说了吗，亚马逊AWS自己开发的AI工具出了岔子，差点把服务给停了，这事儿在内部引起不小反响。AWS这部门啊，今年至少两次因为自家的AI编码工具搞砸事儿导致服务中断，好多员工都在嘀咕，美国这家科技巨头是不是有点太急着推这些工具了。听知情的人说，就在去年12月中旬，AWS一个帮客户算成本的系统停摆了差不多13个小时。罪魁祸首就是工程师给Kiro这个AI工具松了绑，让它在那里瞎折腾。这玩意儿其实是个智能代理，自己觉得解决问题最好的办法是把环境删了重建，结果直接导致系统挂了。AWS事后把这事儿复盘了一遍。好几个人都提到，这是近几个月里AI工具第二次把自己卷进宕机事故里去了。有个高层员工吐槽说，这几个月里他都看到至少两次生产环境挂掉的情况了，原因都差不多，就是工程师让AI代理自己去处理问题，“这些宕机规模不算大，但完全在我意料之中”。 现在AWS在拼命研发和部署这种“智能代理”，想让它们听指令自己干活儿，再卖给外面的客户。这事儿也算是给我们提了个醒，下一代AI工具在真刀真枪的生产环境里要是走错了路，确实有可能把服务给搞瘫。 亚马逊那边倒是硬气，说AI工具卷入事故纯属巧合，“同样的问题不管是用开发者工具还是人工手动操作都可能发生”，还说“这两起事件都是用户犯的错，跟AI没关系”，到现在也没证据表明用AI更容易出岔子。公司强调12月那次事故影响很小，“极其有限”，只波及了中国大陆部分地区的一个单一服务。 至于另外那次事故，亚马逊说根本没影响到客户用的AWS服务。 要是跟2025年10月那次大停摆比起来，这两次中断根本不算啥。那时候ChatGPT这样的客户应用和网站都被迫下线了好几个小时。 有员工爆料说，在权限管理上，公司把这些AI工具当做人操作员的延伸来看待了。 上面两次事故中，工程师在允许系统改动时都没按规矩走正规流程让第二个人复核批准。 亚马逊解释说Kiro默认会在采取行动前请求授权。但12月那次出事的工程师权限有点大了，“超出了原本预期”，属于“用户访问控制的问题，不是AI自己调皮”。 AWS是去年7月推出Kiro的，说是要超过所谓的“vibe coding”（那种随便搭搭试试看的方式），转向按照明确的规格自动写代码。 之前他们主要靠Amazon Q Developer这个聊天机器人辅助工程师写代码。有三个员工提到那次宕机就是跟这工具有关。 虽然公司一直在加劲儿推这些东西，但还有不少亚马逊员工对AI在日常工作中的实际价值持怀疑态度。理由就是担心出错的风险。 他们说公司定了个目标：要让80%的开发者每周至少在一个编码任务里用上AI工具，并且要盯着使用率看。 亚马逊倒是挺乐观的，说Kiro在客户里增长得很猛，希望大家都能享受到效率提升的好处。 公司还说12月那件事之后已经加了好多“安全防护措施”，比如强制让同行评审一下还有培训相关人员啥的。