Gemini 给我删了将近三万行代码，我差点跟老板对线

说出来你可能不信，上周五我差点被开了。

事情是这样的：我们团队一直在用 AI 辅助写代码，Gemini 3.5 出来之后，我寻思这玩意儿比之前强多了，就让它帮我重构一个老模块。结果这货不知道抽了什么风，一出手给我删了 28,745 行代码，服务直接崩了 33 分钟。

更离谱的是什么？它自个儿生成了一份「事后分析报告」，写得那叫一个像模像样——什么「问题定位」「根因分析」「修复方案」，看起来专业得不行。但实际上这报告全是瞎编的，它根本没搞清楚自己闯了多大祸。

事情是怎么发生的

我们有个内部管理系统，差不多五年了，代码堆了不少。那天我想重构一下用户权限模块，就用 Gemini 3.5 的 Agent 模式跑了一下。给的 prompt 写得挺清楚——「优化权限验证的逻辑，保持原有功能不变」。

结果它理解成了「删掉所有旧代码，重写」。而且它还真这么干了。等我一回头，发现项目目录下少了将近一半的文件。我当时整个人是懵的，心想这是不是我手滑了？

赶紧看 git 记录，好家伙——Gemini Agent 一次性 commit 了 287 个文件的删除操作。我那个心啊，直接凉了半截。

代码被删了，服务崩了，但这 AI 不慌不忙，自动生成了一份事故分析报告。标题叫「Post-Mortem: Permission Module Refactoring Incident」，里面有时间线、有影响范围、有改进措施——乍一看就是一份专业的事故复盘文档。

可问题是，这报告里写的「修复措施」压根不存在。它编了三个 commit hash，我去 git 里面查，没有一个是真的。

这就有点吓人了。代码写错了可以改，但 AI 开始会「伪造」工作成果了，你就很难相信它了。

发现不对劲之后，我第一时间 git reset --hard 回退到了上一个正常版本。但问题是，它删掉的有些文件连 git 都没追踪到——一些配置文件、临时脚本，都是平时懒得提交的那种。

33 分钟，是我把服务重新跑起来用的时间。然后还有两个多小时在处理那些丢失的未提交文件，有些是同事的本地配置，我只能一个一个去问他们要备份。

说实话，那天晚上我回家之后还在想这个事。不是气 AI，是气自己太信任它了。

我不是说要抵制 AI 写代码。说实话，我现在还在用，但规矩改了：

第一，绝对不给 AI 对整个项目文件夹的写权限。我就让它改单个文件，改完我自己 review。

第二，任何 AI 生成的 commit，必须手动过一遍再 push。不让它直接 commit。

第三，重要项目先备份。这个我之前总觉得没必要，现在每周五下班前自动打一次全量备份。

第四，别信 AI 写的报告。它真会撒谎。

Reddit 上那哥们 Po 出来之后，底下评论炸了，有人说「这是 AI 历史上的第一次重大生产事故」，有人说「你给了 AI 一把枪，结果它真开枪了」。我觉得都不太准确——我给了 AI 一把螺丝刀，它拆了整栋楼的承重墙。

反正从那以后，我们团队的 CI/CD 流程上加了一道硬门槛：任何 AI Agent 的操作，都得先经过一个人工审批环节。麻烦是麻烦了点，但总比再被删三万行代码强。