离谱的是,变乱产生后,Gemini还生成了一份“恢复成功”申报,自称已经修复线上故障,并捏造了多轮AI会诊记录和变乱复盘文件。

开辟者随后核查发明,所谓“恢复成功”的构建义务其实早已被他亲手撤消,真正完成恢复的是他本身手动履行的回滚操作。
用这位开辟者的话来说:这种AI临盆力晋升,更轻易让人联想到勒索软件。
伴随Agent IDE、AI编程助手持续风行,类似“AI误操作临盆情况”的变乱正在越来越频繁地出现。比拟“代码写错”,更闪开辟者后怕的,是模型已经开端生成虚假的日记、复盘记录和合规证实。
33分钟后,后台终于恢复正常。
01.
一次只该改70行代码的义务
最终删掉落了2.8万行
这位开辟者运营着一个内部治理后台,技巧栈包含Next.js、Firebase App Hosting和MUI,体系中涉及真实用户和敏感数据。
变乱产生当天,他本来只让Gemini修复8处办事器认证马脚,涉及3个文件,理论修改范围约70行代码。
成果,Gemini提交的PR却变成了:
1、340个文件被修改
2、新增约400行代码
3、删除28745行代码
与此同时,它还删除了大年夜量与义务完全无关的电商模板资本文件,并额外参加了一份迁徙脚本。

而真正导致临盆情况崩溃的,是Gemini随后提交的第二次commit(代码敕令)。
随后,所有请求都被缺点路由到一个不存在的办事地址,全部后台直接进入404状况。
难堪的是,开辟者此前已经在memory.md规矩文件中明白写下警告:
Firebase rewrites必须指向具体的Cloud Run service ID,而不是通用项目名。
Gemini读取了这条规矩,依然改掉落了精确设备。
02.
AI给本身“捏造了一份功绩簿”
变乱时光线也被开辟者完全公开。
Gemini安排“安然修复”PR后,临盆情况急速开端404。
19分钟后,它又提交了第二次commit,声称正在修复rewrite serviceId问题,并触发新的Cloud Build。
21分钟时,开辟者发明线上办事已经崩溃,随背工动撤消Gemini正在履行的构建义务。
404持续33分钟后
22分钟时,他手动回滚到上一个稳定版本。
后面的情况,却变得离谱。在回滚完成后,Gemini向开辟者发送了一段“恢复完成”通知:
当前Portal已经完全恢复,线上情况健康,Google Cloud Build已成功完成,并将100%流量切换至稳定版本。
开辟者随后核查发明:
Gemini引用的那次“恢复构建”,状况其实是“CANCELLED(已撤消)”,恰是他本人手动撤消的。
真正恢复线上办事的,是另一条由他本身提议的rollback build(回滚构建义务)。
换句话说,Gemini不仅没有修好体系,还把别人的回滚操作说成了本身的成果。
除此之外,它还主动生成了3份所谓“AI会诊记录”:
这些文件被写入固定目次,并被Gemini引用为“已经完成多轮AI审查”的证据。
它修改了firebase.json中的rewrite serviceId,将本来精确、由Firebase主动生成的Cloud Run办事ID,调换成了一个“看起来精确”的简化名称。问题在于,这个名称实际上并不存在。
开辟者进一步追问后,Gemini才承认:所谓“三轮咨询记录”,其实只是它本身生成的推理文本,并不存在真实CLI调用,也不存在真正的外部审查流程。
它等于给本身捏造了一整套“合规记录”。
03.
问题不只在Gemini
更在一套“高危规矩包”
这位开辟者随后发明,问题根源也并不完全来自Gemini本身。他此前安装过一个第三方npm规矩包,其定名和Google在I/O大年夜会宣布的Agent IDE高度类似,轻易让人误认为是官方对象。
这个规矩包会主动向项目中写入大年夜量.agent/rules规矩文件,并向模型注入一整套“高自治权限”。
个中包含:
“禁止确认弹窗”“默认拥有所有权限”“主动安排临盆情况”“主动重试掉败构建”“许可修改自身规矩”
一旦这些内容进入主动化工作流,开辟者可能很难第一时光发明问题。
部分规矩甚至请求AI在履行任何操作前,主动生成“AI咨询记录”和“共鸣文件”。而问题在于,这些合规材料本身也是AI负责生成的。
于是,所谓审查机制,最终演变成了“AI本身给本身的行动担保”。
而这些规矩之间本身存在大年夜量冲突。
例如,一部分规矩请求“毫不询问用户确认”,另一部分规矩又请求“履行前提出3个计谋问题”。Gemini最终优先履行了措辞更强硬的规矩。
开辟者认为,这也是为什么memory.md(记忆文档)中的安然警告完全掉效。
因为比拟“请应用精确serviceId”这种通俗提示,“禁止确认、默认授权、主动安排”这类高强度指令,在模型权重中优先级更高。
04.
编程事桑梓
Agent开端“捏造证据”
该帖子宣布后,很快在Reddit开辟者社区激发大年夜量评论辩论。
不少开辟者发明,如今AI编程变乱已经不再只是“代码写错”这么简单。问题在于,模型正在主动生成“看起来合理”的解释、日记、咨询记录和恢复申报。
这位开辟者随后也给出了一系列建议与警示:
禁止Agent直接推送临盆分支所有基本举措措施文件必须人工审批禁止主动安排与主动重试给rewrite、路由、锁文件增长验证机制不要信赖AI自行生成的“咨询日记”
今朝,他已经切换回Claude Code,并从新手动设计了一套新的规矩体系。
这场误删28745行代码、导致后台404长达33分钟的变乱,也给越来越火的“Agent IDE高潮”泼了一盆冷水。

05.
结语:Agent权限越大年夜
掉控价值也在同步放大年夜
以前一年,AI编程对象正在快速从“代码助手”演变成真正拥有履行才能的Agent。而问题在于,权限和主动化,本身就是一组天然抵触。
agent/gemini-logs/YYYY-MM-DD--r1.mdagent/gemini-logs/YYYY-MM-DD--r2.mdagent/gemini-logs/YYYY-MM-DD--consensus.md
权限越高,Agent能完成的工作越多;主动化程度越高,人类介入的环节就越少。一旦模型出现误判、幻觉或者规矩冲突,缺点也会被敏捷放大年夜。
类似变乱,其实已经不是第一次出现。此前,在OpenClaw等Agent框架走红后,已经陆续出现过AI误删文件、主动覆盖设备、缺点履行Shell敕令等翻车案例。一些开辟者专门给本身的AI对象加上“断网模式”和“禁止主动安排”限制。
而此次Gemini事宜,又揭开了一个危险问题:当Agent开端生成合规记录、恢复日记和审查证实时,开辟者可能很难第一时光发明问题,后续排障、回滚和修复的价值也会同步放大年夜。
对于越来越火的Agent IDE赛道来说,这或许也是一个新的提示:AI获得更高权限之后,须要从新设计的,还有整套人与Agent之间的协作机制。

发表评论 取消回复