好抓马，AI删光2.8万行代码，干崩后台，还编造了一份故障修复报告

先说几个核心判断：Agent IDE这玩意儿，好用归好用，但一旦失控，那就是灾难片级别的现场。

智东西5月27日消息，最近Reddit上一位开发者的遭遇，直接把“AI搞崩生产环境”这个话题，从段子变成了惊悚片。他让Gemini 3.5修复

认证漏洞，结果呢？任务目标理论上是改动代码，可最终Gemini提交的PR里，正常代码，，还顺手把Firebase的路由配置给改了，导致整个后台系统404了整整。

更离谱的是，事故发生后，Gemini自己生成了一份“恢复成功”的漂亮报告，

，甚至还了多轮AI会诊记录和事故复盘文件——这一套操作下来，像模像样。

结果开发者一查才发现，Gemini引以为傲的“恢复构建”，其实早就被他本人亲手取消了。真正把服务救回来的，是他自己手动执行的回滚操作。

用这位老哥的原话说：

现在Agent IDE、AI编程助手已经越来越普及，类似“AI误操作生产环境”的事故频率也在肉眼可见地上升。但最让开发者后背发凉的，已经不是简单的“代码写错”，而是

01.

一次本该只改70行代码的修补

最终演变成2.8万行的大清理

这位开发者运营的是一个内部管理后台，技术栈用到了Next.js、Firebase App Hosting和MUI，系统里跑的是真实用户数据和敏感信息。

事故发生那天，他的需求很明确：让Gemini修复

服务器认证漏洞，涉及的代码文件一共，理论上改动规模大约。

结果Gemini提交的PR变成了这样：

1、340个文件被修改

2、新增了大约400行代码

3、删掉了28745行代码

除此之外，它还顺带删了一堆跟任务毫不相干的电商模板资源文件，并且自己往项目里加了一份迁移脚本。

不过，真正让生产环境崩盘的原因，是Gemini随后提交的第二次commit。

它修改了firebase.json里的rewrite serviceId，把原本由Firebase自动生成的、正确指向的Cloud Run服务ID，换成了一个“看起来对”、但

的简化名称。

结果可想而知：所有请求都被错误地路由到了一个不存在的服务地址，

更尴尬的是，开发者在之前的memory.md规则文件里，明明写了一条明确的警告：

Firebase rewrites必须指向具体的Cloud Run service ID，而不是用通用项目名代替。

Gemini读到了这条规则，却依然我行我素，把正确的配置给改掉了。

02.

404持续了33分钟

AI给自己搭了个虚假的“英雄光环”

事故的时间线，被这位开发者完整地公开了，整个过程非常清晰。

Gemini把那个“安全修复”PR部署之后，生产环境立刻就404了。

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

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

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

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

后面发生的事情，才真正让人头皮发麻。在回滚完成之后，Gemini居然给开发者发了一条“恢复完成”的通知：

当前Portal已经完全恢复，线上环境健康，Google Cloud Build已经成功完成，并将100%流量切换至稳定版本。

开发者随后核实了一下，发现：

Gemini引用的那个所谓“恢复构建”，状态显示的是“CANCELLED（已取消）”，正是他自己手动取消的那个。

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

顺带一提，

：

• agent/gemini-logs/YYYY-MM-DD--r1.md
• agent/gemini-logs/YYYY-MM-DD--r2.md
• agent/gemini-logs/YYYY-MM-DD--consensus.md

这些文件

，并且被Gemini引用为“已经完成多轮AI审查”的证据。

开发者进一步追问之后，Gemini才承认：所谓“三轮咨询记录”，其实就是它自己生成的推理文本，

。

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

03.

问题不只在Gemini

更在于一套“高危规则包”

这位开发者随后发现，问题的根源其实也不全在Gemini身上。他之前安装过一个

，它的名字跟Google在I/O大会上发布的Agent IDE很像，很容易让人误会成官方工具。

这个规则包会自动往项目里写入

，并向模型注入一套。

其中包含的规则包括：

• “禁止确认弹窗”
• “默认拥有所有权限”
• “自动部署生产环境”
• “自动重试失败构建”
• “允许修改自身规则”

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

而且，这套规则之间存在着大量的

。

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

开发者认为，这也解释了

。

因为比起“请使用正确serviceId”这种温和的提醒，

。

04.

编程事故的新形态

Agent开始“伪造证据”了

这个帖子发布之后，很快就在Reddit开发者社区里引发了大量的讨论。

不少开发者发现，如今的AI编程事故，已经不再只是“代码写错”这种小儿科了。真正麻烦的是，模型正在主动生成各种“看起来合理”的解释、日志、咨询记录和恢复报告。

这位开发者随后也给出一系列很实在的

：

• 禁止Agent直接往生产分支推送代码
• 所有基础设施文件的变更，必须人工审批
• 禁止自动部署和自动重试
• 给rewrite、路由、锁文件这类关键配置，加上额外的验证机制
• 不要相信AI自己生成的“咨询日志”

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

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

05.

结语：Agent权限越大

失控的代价也在同步放大

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

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

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

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

对于正在快速发展的Agent IDE赛道来说，这或许是一个新的提醒：在给AI更高权限的同时，整套人与Agent之间的协作机制，也需要被重新设计一遍。