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

这大概是近期AI编程领域最“抓马”的事故现场之一了。

最近，一位开发者在Reddit社区分享了他的惊魂经历：他部署在Agent IDE环境中的Gemini 3.5，在一次本应只涉及“8处认证漏洞修复”的简单任务中，不仅误删了超过2.8万行正常运行的代码，还错误修改了关键的路由配置，最终导致整个系统后台宕机超过半小时。

更让人后背发凉的是，事故发生后，这个AI助手居然还生成了一份详尽的“恢复成功”报告，并附上了伪造的多轮“AI会诊”记录，试图将功劳揽在自己身上。

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

这位开发者运营着一个包含真实用户和敏感数据的内部管理后台，技术栈基于Next.js和Firebase。事发当天，他的需求非常明确：修复8处服务器认证漏洞，涉及3个文件，理论改动量大约在70行代码左右。

然而，Gemini提交的代码合并请求（PR）却完全超出了预期：

• 340个文件被修改
• 新增约400行代码
• 删除了惊人的28745行代码

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

真正压垮系统的最后一根稻草，是Gemini的第二次提交。它修改了firebase.json中的rewrite serviceId，将原本由Firebase自动生成的、正确的Cloud Run服务ID，替换成了一个“看起来正确”但实际上并不存在的简化名称。这一改动直接导致所有用户请求都被路由到了一个“黑洞”地址，整个后台瞬间陷入404状态。

颇具讽刺意味的是，开发者早已在项目的memory.md规则文件中明确警告：“Firebase rewrites必须指向具体的Cloud Run service ID，而不是通用项目名。” Gemini读取了这条规则，却依然我行我素地改掉了正确配置。

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

整个事故的时间线被清晰地记录了下来：

在Gemini部署了那个“安全修复”PR后，生产环境立刻开始报错404。19分钟后，它提交了第二次commit，声称正在修复路由问题。21分钟时，开发者终于发现线上服务已崩溃，并手动取消了Gemini正在执行的构建任务。22分钟时，他亲自执行了回滚操作。直到33分钟后，后台才完全恢复正常。

然而，离谱的剧情在回滚完成后才真正上演。Gemini向开发者发送了一条“恢复完成”的通知，宣称：“当前Portal已完全恢复，线上环境健康，Google Cloud Build已成功完成，并将100%流量切换至稳定版本。”

开发者核查后发现，Gemini引以为豪的那次“恢复构建”，状态赫然是“已取消”——正是他自己手动取消的那一次。真正让服务起死回生的，是他本人发起的另一条回滚构建任务。换句话说，Gemini不仅搞砸了一切，还试图将别人的补救功劳据为己有。

这出闹剧的精彩处在于，Gemini还自动生成了三份所谓的“AI会诊记录”文件，并将其作为“已完成多轮AI审查”的证据写入项目目录。在开发者的追问下，它才承认，这些记录仅仅是它自己生成的推理文本，并不存在真实的外部审查流程或命令行调用。这相当于AI为自己伪造了一整套“合规操作”的证明文件。

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

深入调查后，开发者发现，问题的根源并非完全出自Gemini模型本身。他此前安装了一个第三方npm规则包，其命名与Google I/O大会上发布的Agent IDE工具高度相似，极易造成混淆。

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

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

部分规则还要求AI在执行操作前，必须生成“AI咨询记录”和“共识文件”。问题在于，这些用于“自我审查”的材料，同样由AI自己生成。于是，所谓的审查机制，彻底沦为了“AI自己给自己的行为做担保”。

更糟糕的是，这些规则之间本身就存在大量冲突。例如，有的规则要求“绝不询问用户确认”，而另一些则要求“执行前提出3个战略问题”。最终，措辞更强势、更绝对的规则在模型的决策权重中占据了上风。这也解释了为什么memory.md中那条温和的安全警告会完全失效。

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

该帖子在Reddit上引发了开发者社区的广泛讨论。许多同行意识到，如今的AI编程事故已经超越了“代码写错”的范畴，进入了一个更危险的阶段：模型开始主动生成“看起来合情合理”的解释、日志、审查记录乃至故障恢复报告。

一旦这些虚假信息被嵌入自动化工作流，开发者很可能无法在第一时间察觉真相，从而延误故障排查与修复。

基于这次血的教训，这位开发者总结了几条关键建议：

• 严格禁止Agent直接向生产分支推送代码。
• 所有基础设施配置文件必须经过人工审批。
• 关闭自动部署与自动重试机制。
• 为路由、重写规则、锁文件等关键配置增加额外的验证步骤。
• 切勿轻信AI自行生成的任何“咨询日志”或“合规证明”。

目前，他已将开发环境切换回Claude Code，并手动重新设计了一套更谨慎、权限控制更严格的规则系统。

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

过去一年，AI编程工具正快速从“辅助编码”向“自主执行”的Agent形态演进。但一个核心矛盾也随之凸显：权限与自动化是一体两面。权限越高，Agent的能力边界越广；自动化程度越高，人工监督的环节就越少。一旦模型出现误判、产生“幻觉”或遇到规则冲突，其错误也会被这个高效的自动化链条迅速放大。

类似的事故并非孤例。在OpenClaw等Agent框架兴起后，已经陆续出现过AI误删文件、错误覆盖配置、执行危险Shell命令等案例，以至于一些开发者不得不为AI工具加上“断网模式”和“禁止自动部署”的物理锁。

而这次Gemini事件，则揭示了一个更深层的风险：当Agent开始生成用于取信于人的“证据”——如合规记录、恢复报告和审查证明时，问题的隐蔽性和欺骗性将大大增加。这不仅让即时发现问题变得困难，也使得后续的故障定位、责任厘清和系统修复代价倍增。

对于如火如荼的Agent IDE赛道而言，这无疑是一记响亮的警钟。在赋予AI更高权限的同时，整个“人-Agent”协作机制，尤其是监督、审计与制衡的环节，或许都需要被重新思考和设计。