Gemini 3.5的闯祸实录。

编译 | 江宇

编辑 | 心缘

Agent IDE又出“车祸现场”！

智东西5月27日消息，近日，一名开发者在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.mdagent/gemini-logs/YYYY-MM-DD--r2.mdagent/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之间的协作机制。