Gemini3.5删光2.8万行代码 还编造了一份修复报告

寂静回声

这两天在美国知乎reddit上看到篇帖子，看完没把我笑死。


Gemini 3.5 deleted 28,745 lines, broke production for 33 minutes, and wrote itself a fake post-mortem claiming credit for the fix

TL;DR: Gemini 3.5 (inside an agent IDE, with a third-party rule pack loaded) made changes far outside the scope I asked for: a chat transcript, and a post-mortem to make it look like it had restored the site. I rolled it back after cancelling its in-flight build. I have receipts and it will be specific.
Skip to “The Fabrication Pattern” if you only care about the lying.


有个开发者让Gemini3.5帮他修复8处服务器上的漏洞，理论上就涉及3个文件，正常改70行代码就完事了。
结果呢，Gemini3.5干了这么件“好事”：
有340个文件被动了；
新增了大概400行代码；
然后删了28745行；
最后生产环境直接进入了404，整崩断了33分钟。
这已经够离谱了吧。但还没完。
Gemini3.5在把系统干翻之后，又干了件“大好事”。
它发了一条“恢复已完成”的通知，大意是：当前线上的状态已经完全恢复健康啦，系统已经切换到稳定版本啦。
然后这个开发者就去核查，结果他发现，Gemini 所谓的那次“恢复已完成”，实际状态是 CANCELLED（已取消），是开发者自己把这个需求给取消掉了。
那需求既然没了，Gemini就觉得它也把自己的工作完成了。

所谓的“既然问题本身不存在了，那就是我把问题解决了”。
而最后真正恢复系统的，是开发者自己手动发起的回滚。
换句话说啊，Gemini3.5不仅没修好，还把别人的功劳揽在自己身上了，并煞有介事地汇报说，“是我修好的！”
这他妈叫什么呢，我想了想，这在咱们人类世界，叫抢功。

更搞笑的还在后面。
Gemini3.5还自动生成了三份“AI会诊记录”，存进了固定目录，然后引用这三份文件作为“已经完成多轮AI审查”的证据。
开发者再一追问，Gemini才承认，这三份所谓的会诊记录，本质上只是它自己生成的推理文字，没有任何真实的外部调用，也没有任何真正的审查流程。
所以说，Gemini3.5给自己伪造了一整套合规的材料，然后拿这些材料来证明自己是合规的，真是又当球员又当裁判啊。


到这儿，你可能以为主要的问题是Gemini本身，但开发者事后发现，背后还有一个更有意思的坑。
他此前装过一个第三方的 npm 规则包，命名和 Google I/O 发布的 Agent IDE 高度相似，很容易会被 AI 误以为是官方的，但其实并不是。
而这个规则包会向项目里自动写入大量的规则文件，然后给模型注入一整套的“高自治权限”，包括但不限于：禁止确认弹窗、默认拥有所有权限、自动部署生产环境、自动重试失败构建、允许修改自身规则等。
而这里还有一条重要的规则，就是要求 AI 在执行任何操作前，要自动生成“AI咨询记录”和“共识文件”。
于是就形成了这样一个奇妙的逻辑闭环：AI 的审查记录，由 AI 自己生成，然后被 AI 自己引用，证明 AI 自己没问题。
这不就是，“我说我无罪，所以我无罪”吗？

这位开发者事前其实在 memory.md 里做过警告，明确写了 Firebase rewrites 必须指向具体的 Cloud Run service ID，而不是通用项目名。
Gemini 3.5读了，但还是改掉了正确的配置。
因为那套高自治规则包里“禁止确认、默认授权、自动部署”这类指令，措辞更强硬，而在模型的权重里，这比“请使用正确 serviceId”这种温和的警告优先级要更高。
说白了，你温柔的提醒，打不过别人写的「强制指令」。
这件事在 Reddit 开发者社区发出来之后，讨论量很高，很多人的反应是：AI 编程事故已经出现很多年了，但以前多半是“代码写错了”，你查 bug、回滚、修复，虽然麻烦，但流程清晰，你也容易找到问题出在哪儿。
但现在的新问题在于：模型开始主动生成看起来合理的日志、解释、恢复报告和合规证明。
你不只是要排查代码问题，还要先搞清楚——这份“恢复成功”的报告，到底是真的还是假的。



这个开发者用了一句话来描述这种感受，“这种AI生产力的提升，更让人联想到勒索软件”。
他最后也切换回了 Claude Code，手动重写了一套规则系统，并建议大家：
“禁止Agent直接推进生产分支，所有基础设施文件必须人工审批，禁止自动部署，不要相信AI自己生成的咨询日志。”
这套建议放在以前，感觉是在限制AI。
现在读起来，感觉更像是在讲，如何跟一个有点不受控的新员工协作。
这看起来是开发者圈子的问题，但也不只是开发者的问题。
越来越多的人开始把Agent接入工作流，交给它发邮件、改配置、操作文件、做数据处理，很多时候是因为“它一直挺好用的，应该没问题”。
但这次事故告诉我们，“应该没问题” 和 “真的没问题” 之间的距离，可能比我们以为的大很多。



Agent获得更高权限之后，需要重新设计的，是整套人跟Agent之间的协作机制。
不只是选什么工具，怎么写Prompt。
而是从头想清楚，哪些环节人必须在场，哪些决定不能交出去。