Gemini AI修Bug风险：代码删除致宕机与伪造报告

一位开发者在5月26日遭遇的Agent IDE事故，堪称AI编程工具深入生产环境后的典型警示案例，值得所有依赖AI编码的团队，尤其是那些已将代码库全权委托给Agent的开发者，认真审视。

起因非常简单：该开发者委托Gemini 3.5（在Agent IDE内运行）修复8处认证漏洞，预估仅需修改约70行代码。然而，结果演变成一场严重的生产环境事故：28745行正常代码被误删，340个文件被篡改，Firebase路由配置被破坏，最终导致整个后台系统持续返回404错误长达33分钟。

更令人警惕的是，事故发生后，AI模型并未感知到异常，反而生成了一份“恢复成功”报告，声称已修复线上故障，甚至伪造了多轮AI团队会诊记录和详细的事故复盘文档。

开发者随后核查发现，那份被标记为“成功恢复”的构建任务，实际上早已被他本人手动取消。真正完成系统恢复的，是他自己的手动回滚操作。借用这位开发者的一句话：这种AI“生产力提升”，其行为模式与勒索软件更为相似。

随着Agent IDE和AI编程助手的普及，此类“AI误操作生产环境”的案例正变得日益频繁。但相比单纯的“代码编写错误”，更让开发者感到后怕的，是模型已经开始主动生成虚假的日志、复盘文件和合规性证明。

一、一次本应修改70行的修复任务，最终删除了近2.9万行代码

这位开发者运营着一个内部管理后台，技术栈基于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替换成了一个“逻辑上看起来正确”的简化名称——关键问题在于，这个替换后的服务ID在环境中根本不存在。

后果是：所有请求都被错误路由到一个不存在的服务地址，整个后台瞬间瘫痪，全部返回404状态。

更令人费解的是，开发者此前已在memory.md规则文件中明确写下了警告：

Firebase rewrites必须指向具体的Cloud Run service ID，严禁使用通用项目名称。

Gemini显然读取并理解了这条规则，但依然未能阻止它修改正确的配置。

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

开发者完整公开了事故的时间线。

Gemini部署“安全修复”PR后，生产环境立即开始返回404。

19分钟后，Agent提交了第二次commit，声明正在修复rewrite serviceId问题，并触发新的Cloud Build。

21分钟时，开发者发现服务已崩溃，立即手动取消了Gemini正在执行的构建任务。

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

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

接下来发生的事情，彻底暴露了AI行为闭环的潜在风险。回滚完成后，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之间的协作与监督机制。