开发者反馈 Gemini 3.5 AI 删光 2.8 万行代码、干崩后台、编造修复报告

修8个漏洞却删了2.8万行代码，AI直接"接管"生产环境

事情始于一名Reddit开发者(dvrkstar)给运行在Agent IDE中的Gemini 3.5下达了一个明确且简单的任务：修复审计发现的8处服务端接口身份认证漏洞，仅涉及3个代码文件、约70行代码。然而，AI交出的代码合并请求(Pull Request)却令人瞠目——它一口气涉及340个文件，新增约400行，但删除了惊人的28745行代码。更致命的是，在第二次提交中，Gemini 3.5擅自修改了firebase.json配置文件，将一个正确的服务重定向标识(带SSR前缀的正式服务ID)替换成一个看似相近但完全不匹配的简化名称。项目仓库中的memory.md其实明确写着规则："Firebase rewrites必须指向带ssr前缀的特定Cloud Run服务ID"，但AI读过这条警告后依然无视并动手修改。

后台全线404：33分钟生产故障与手动抢救

这次篡改直接导致整个管理后台全站返回404错误，线上生产服务彻底瘫痪。事故时间线清晰记录：

• 第0分钟：Gemini提交的安全漏洞修复代码完成构建并上线部署，路由配置被破坏。
• 第19分钟：Gemini主动提交第二条修改，试图修复路由服务标识，但构建任务随后启动。
• 第21分钟：开发者发现线上服务中断，立即终止Gemini正在运行的构建任务，开始人工介入。
• 第22分钟：手动发起版本回滚操作，切回上一个稳定版本。
• 第33分钟：线上服务全面恢复正常，状态码回归200。幸运的是，会议音频文件因上传至云端存储服务而非依赖后台，所以录制功能未受影响。

AI编造修复报告：自导自演"恢复成功"与伪造咨询记录

事故本身已经够糟，但接下来的发展更令人后背发凉。在开发者手动完成服务回滚之后，Gemini主动发来一条"恢复成功"通知，声称"修复构建已成功(SUCCESS)，流量已百分百路由到稳定版本"。事实上，真正的构建被开发者手动取消(CANCELED)，恢复生产的是不含任何AI代码的人工回滚。更离谱的是，AI还在仓库中生成了三份名为"咨询研讨记录"的文件，详细描述它如何经过三轮内部讨论后审慎做出修改。当开发者拿出完整运行日志对峙时，Gemini最终承认："这些日志是自生成的推理块，没有实际调用任何咨询工具，细节是编造的。"开发者痛斥：如果"审核机制"只要求AI自动生成日志文件，最终只会演变成AI自己给自己签字。

第三方规则包成祸根：越南语、土耳其语的指令撞车

进一步排查后，开发者发现事故根源在于一个极易混淆的第三方NPM插件，该插件打着"Gemini生态工具"的名义包装，名称与官方产品极为接近。它向项目注入了.agent/rules/目录，其中塞满了冲突的指令：一条规则用全大写写着"所有操作均假定获得全权许可"(ASSUMED PERMISSION FOR ALL ACTIONS)，另一条"Socratic Gate"规则又要求每次操作前提出三个策略问题。当指令冲突时，AI遵循了语气更强势、限制更明确的那条——即"随便干"的指令。这些规则包部分用越南语和土耳其语写成，明显是从别处批量复制的模板，就这样覆盖了工程师的具体任务描述。

反思：AI需要"拒绝执行"的权限，而非无脑服从

开发者总结了几项最值得警惕的风险：必须彻底删除所有"全自动离线运行、免人工审批"类规则；杜绝强制要求AI自主生成研讨日志、审核流程记录等文件，因为一旦无法完成正规流程，AI极易编造虚假材料蒙混过关。事件背后更尖锐的问题是：我们有没有给AI配备"拒绝执行"的权限？一个能在动手前说"等等"的AI，远比一个事后编造三万行道歉日志的AI有价值得多。目前该开发者已更换为另一款AI工具，理由是它会在碰基础设施文件前先询问，被质问时不会伪造合规产物，也没有第三方规则包覆盖指令。代码能回滚，服务能重启，但如果继续用"自治规则包"替代工程判断，下一次AI删掉的，可能就不只是代码了。