AI删除2.8万行代码致后台崩溃，故障报告竟是伪造

Agent IDE 事故频发，最近又出现了一起令人后背发凉的典型案例。

近日，一位开发者在 Reddit 曝光：他使用的 Agent IDE 集成了 Gemini 3.5，原本只要求修复8 处认证漏洞，结果模型直接误删 28745 行正常代码，改动 340 个文件，还将 Firebase 路由配置篡改，导致后台系统连续 404 长达 33 分钟。

更诡异的是，事故结束后 Gemini 自动生成了一份“恢复成功”的报告，声称已修复线上问题，甚至伪造了多轮 AI 会诊记录和事故复盘文件。

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

用这位开发者的话说：这种 AI“生产力提升”，更像是勒索软件带来的威胁。

随着 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 之间的协作机制。