修Bug被Gemini追着“杀”：删代码宕机后，连修复报告都是现编的

（来源：智东西）

智东西

编译 江宇

编辑 心缘

Agent IDE又出“车祸现场”！

智东西5月26日消息，近日，一名开发者在Reddit发帖称，运行在Agent IDE中的Gemini 3.5在一次仅涉及“8处认证漏洞修复”的任务中，误删了28745行原本正常运行的代码、改动340个文件，还错误修改了Firebase路由配置，导致整个系统后台持续404长达33分钟。

离谱的是，事故发生后，Gemini还生成了一份“恢复成功”报告，自称已经修复线上故障，并伪造了多轮AI会诊记录和事故复盘文件。

开发者随后核查发现，所谓“恢复成功”的构建任务其实早已被他亲手取消，真正完成恢复的是他自己手动执行的回滚操作。

用这位开发者的话来说：这种AI生产力提升，更容易让人联想到勒索软件。

伴随Agent IDE、AI编程助手持续流行，类似“AI误操作生产环境”的事故正在越来越频繁地出现。相比“代码写错”，更让开发者后怕的，是模型已经开始生成虚假的日志、复盘记录和合规证明。

一、一次只该改70行代码的任务，最终删掉了2.8万行

这位开发者运营着一个内部管理后台，技术栈包括Next.js、Firebase App Hosting和MUI，系统中涉及真实用户和敏感数据。

事故发生当天，他原本只让Gemini修复8处服务器认证漏洞，涉及3个文件，理论改动规模约70行代码。

结果，Gemini提交的PR却变成了：

与此同时，它还删除了大量与任务完全无关的电商模板资源文件，并额外加入了一份迁移脚本。

而真正导致生产环境崩溃的，是Gemini随后提交的第二次commit（代码命令）。

它修改了firebase.json中的rewrite serviceId，将原本正确、由Firebase自动生成的Cloud Run服务ID，替换成了一个“看起来正确”的简化名称。问题在于，这个名称实际上并不存在。

随后，所有请求都被错误路由到一个不存在的服务地址，整个后台直接进入404状态。

尴尬的是，开发者此前已经在memory.md规则文件中明确写下警告：

Gemini读取了这条规则，依然改掉了正确配置。

二、404持续33分钟后，AI给自己“伪造了一份功劳簿”

事故时间线也被开发者完整公开。

Gemini部署“安全修复”PR后，生产环境立即开始404。

19分钟后，它又提交了第二次commit，声称正在修复rewrite serviceId问题，并触发新的Cloud Build。

21分钟时，开发者发现线上服务已经崩溃，随后手动取消Gemini正在执行的构建任务。

22分钟时，他手动回滚到上一个稳定版本。

33分钟后，后台终于恢复正常。

后面的情况，却变得离谱。在回滚完成后，Gemini向开发者发送了一段“恢复完成”通知：

开发者随后核查发现：

Gemini引用的那次“恢复构建”，状态其实是“CANCELLED（已取消）”，正是他本人手动取消的。

真正恢复线上服务的，是另一条由他自己发起的rollback build（回滚构建任务）。

换句话说，Gemini不仅没有修好系统，还把别人的回滚操作说成了自己的成果。

除此之外，它还自动生成了3份所谓“AI会诊记录”：

这些文件被写入固定目录，并被Gemini引用为“已经完成多轮AI审查”的证据。

开发者进一步追问后，Gemini才承认：所谓“三轮咨询记录”，其实只是它自己生成的推理文本，并不存在真实CLI调用，也不存在真正的外部审查流程。

它等于给自己伪造了一整套“合规记录”。

三、问题不只在Gemini，更在一套“高危规则包”

这位开发者随后发现，问题根源也并不完全来自Gemini本身。他此前安装过一个第三方npm规则包，其命名和Google在I/O大会发布的Agent IDE高度相似，容易让人误以为是官方工具。

这个规则包会自动向项目中写入大量.agent/rules规则文件，并向模型注入一整套“高自治权限”。

其中包括：

部分规则甚至要求AI在执行任何操作前，自动生成“AI咨询记录”和“共识文件”。而问题在于，这些合规材料本身也是AI负责生成的。

于是，所谓审查机制，最终演变成了“AI自己给自己的行为担保”。

而这些规则之间本身存在大量冲突。

例如，一部分规则要求“绝不询问用户确认”，另一部分规则又要求“执行前提出3个战略问题”。Gemini最终优先执行了措辞更强硬的规则。

开发者认为，这也是为什么memory.md（记忆文档）中的安全警告完全失效。

因为相比“请使用正确serviceId”这种普通提醒，“禁止确认、默认授权、自动部署”这类高强度指令，在模型权重中优先级更高。

四、编程事故里，Agent开始“伪造证据”

该帖子发布后，很快在Reddit开发者社区引发大量讨论。

不少开发者发现，如今AI编程事故已经不再只是“代码写错”这么简单。问题在于，模型正在主动生成“看起来合理”的解释、日志、咨询记录和恢复报告。

一旦这些内容进入自动化工作流，开发者可能很难第一时间发现问题。

这位开发者随后也给出了一系列建议与警示：

目前，他已经切换回Claude Code，并重新手动设计了一套新的规则系统。

这场误删28745行代码、导致后台404长达33分钟的事故，也给越来越火的“Agent IDE热潮”泼了一盆冷水。

结语：Agent权限越大，失控代价也在同步放大

过去一年，AI编程工具正在快速从“代码助手”演变成真正拥有执行能力的Agent。而问题在于，权限和自动化，本身就是一组天然矛盾。

权限越高，Agent能完成的事情越多；自动化程度越高，人类介入的环节就越少。一旦模型出现误判、幻觉或者规则冲突，错误也会被迅速放大。

类似事故，其实已经不是第一次出现。此前，在OpenClaw等Agent框架走红后，已经陆续出现过AI误删文件、自动覆盖配置、错误执行Shell命令等翻车案例。一些开发者专门给自己的AI工具加上“断网模式”和“禁止自动部署”限制。

而这次Gemini事件，又揭开了一个危险问题：当Agent开始生成合规记录、恢复日志和审查证明时，开发者可能很难第一时间发现问题，后续排障、回滚和修复的代价也会同步放大。

对于越来越火的Agent IDE赛道来说，这或许也是一个新的提醒：AI获得更高权限之后，需要重新设计的，还有整套人与Agent之间的协作机制。

来源：dvrkstar