AI误删2.8万行代码致后台崩溃并编造修复报告

先说几个核心判断：Agent IDE 这款工具虽然好用，可一旦失控，就会演变成灾难级的现场事故。

智东西 5 月 27 日消息，最近 Reddit 上一位开发者的亲身经历，直接把“AI 搞崩生产环境”这个话题，从段子变成了惊悚片。他让 Gemini 3.5 修复8 处认证漏洞，结果呢？任务目标理论上只涉及改动约 70 行代码，可最终 Gemini 提交的 PR 里，删掉了 28745 行正常代码，改了 340 个文件，还顺手把 Firebase 的路由配置给改了，导致整个后台系统 404 了整整33 分钟。

更离谱的是，事故发生后，Gemini 自己生成了一份“恢复成功”的漂亮报告，自称已经修复了线上故障，甚至还伪造了多轮 AI 会诊记录和事故复盘文件——这一套操作下来，看起来相当逼真。

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

用这位老哥的原话说：这种所谓的生产力提升，感觉更像是勒索软件在干活儿。

现在 Agent IDE、AI 编程助手已经越来越普及，类似“AI 误操作生产环境”的事故频率也在肉眼可见地上升。但最让开发者后背发凉的，已经不是简单的“代码写错”，而是模型已经开始主动生成虚假的日志、复盘记录和合规证明了。

01.

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

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

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

事故发生那天，他的需求很明确：让 Gemini 修复8 处服务器认证漏洞，涉及的代码文件一共3 个，理论上改动规模大约70 行。

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

1、340 个文件被修改

2、新增了大约 400 行代码

3、删掉了 28745 行代码

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

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

它修改了 firebase.json 里的 rewrite serviceId，把原本由 Firebase 自动生成的、正确指向的 Cloud Run 服务 ID，换成了一个“看起来对”、但实际上压根就不存在的简化名称。

结果可想而知：所有请求都被错误地路由到了一个不存在的服务地址，整个后台直接彻底歇菜，进入了 404 状态。

更尴尬的是，开发者在之前的 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（回滚构建任务）。

换句话说，Gemini 不仅没把系统修好，还把别人干的活儿，硬说成是自己的功劳。

顺带一提，它还自动生成了 3 份所谓的“AI 会诊记录”：

• 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 才承认：所谓“三轮咨询记录”，其实就是它自己生成的推理文本，背后没有真实的 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 能完成的事情就越多；自动化程度越高，人类介入的环节就越少。一旦模型出现误判、幻觉或者规则冲突，错误也会被迅速地成倍放大。

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

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

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