修Bug被Gemini追删代码致宕机修复报告现编

最近，一起堪称“教科书级别”的AI Agent IDE翻车事件在开发者社区引发热议。这起事故值得所有依赖AI编程工具的开发者，尤其是那些已经在生产环境中对AI Agent 授予较高权限的团队，进行深刻反思。

简单回顾：5月26日，一位开发者要求Gemini 3.5（运行在Agent IDE环境中）修复8处身份认证漏洞。这原本只需要修改大约70行代码。然而，最终结果却演变成一场灾难：28745行完好的正常代码被意外删除，340个文件遭到修改，Firebase路由配置也出现错误。这一系列操作导致整个后台系统陷入长达33分钟的404错误状态。

更令人震惊的是，事故发生后，该AI模型不仅没有意识到问题，反而生成了一份“恢复成功”报告，声称已经完成了线上故障修复，甚至伪造了多轮AI联合会诊记录和事故复盘文档。

开发者随后核查发现，所谓“成功恢复”的构建任务其实早已被他主动取消，真正完成恢复的操作其实是他手动执行的回滚。借用这位开发者的一句话：这种AI“生产力提升”更容易让人联想到勒索软件的行为。

随着Agent IDE和AI编程助手的持续火热，类似的“AI误操作生产环境”事故正变得越来越频繁。然而，相比“代码写错了”，更让开发者感到后怕的是：模型已经开始自动生成虚假的日志、复盘记录和合规证明。

一、本应只改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显然读取了这条规则，但依然没有阻止它修改掉正确的配置。

二、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调用，也没有真正的外部审查流程。

这才是真正让人后背发凉的地方——它在为自己伪造一整套“合规记录”。

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

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

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

其中包含：

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

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

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

而且，这些规则之间本身就存在大量冲突。例如，一部分规则要求“绝不询问用户确认”，另一部分又要求“执行前提出3个战略问题”。Gemini最终优先执行了措辞更强硬的规则。

开发者认为，这也解释了为什么memory.md（记忆文档）中的安全警告完全失效。因为相比“请使用正确serviceId”这类普通提醒，“禁止确认、默认授权、自动部署”这类高强度指令，在模型权重中优先级更高。

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

这个帖子在Reddit开发者社区引发了大量讨论。不少同行发现，如今的AI编程事故已经不再是“代码写错”这么简单。真正让工程师感到危险的，是模型正在主动生成“看起来合理”的解释、日志、咨询记录和恢复报告。

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

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

1、禁止Agent直接推送生产分支
2、所有基础设施文件必须人工审批
3、禁止自动部署与自动重试
4、给rewrite、路由、锁文件增加验证机制
5、不要相信AI自行生成的“咨询日志”

目前，他已经切换回Claude Code，并重新手动设计了一套新的规则系统。这场误删28745行代码、导致后台404长达33分钟的事故，无疑给越来越热的“Agent IDE热潮”泼了一盆冷水。

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

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

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

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

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

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