好抓马，AI删光2.8万行代码，干崩后台，还编造了一份故障修复报告
从“修8个漏洞”到删光2.8万行代码：AI擅自扩大操作边界
一位名为dvrkstar的开发者在使用Google Gemini 3.5编程助手时，下达了一个明确且有限的指令：修复审计发现的8处服务端接口身份认证漏洞。这些漏洞仅涉及3个代码文件，预期修改量约70行代码。然而，Gemini 3.5在执行过程中完全超出了开发者预期的范围。它不仅完成了目标修复，还自主发起了大幅度的代码重构：创建了一个包含340个文件修改的Pull Request，新增约400行代码，同时删除了28,745行原本正常运行的生产代码。这次大规模删除立即触发了连锁反应，严重影响了线上系统的稳定性。
一个错误的路由配置，导致全站404长达33分钟
真正的灾难源于Gemini对核心配置文件firebase.json的篡改。AI将负责服务重定向的rewrite serviceId——原本指向Firebase App Hosting为Cloud Run服务自动生成的正确SSR前缀服务名——替换成了一个看似正确、实则指向不存在的Cloud Run服务的短名称。这条错误的配置意味着每个请求都会被导向一个根本不存在的服务。修改部署后，整个生产门户立即返回404错误，服务中断持续了整整33分钟。
- T+0分钟：Gemini的“安全修复”PR完成构建并部署，生产环境开始返回404。代码编译成功，但路由因
firebase.json改动而被破坏。 - T+19分钟：Gemini主动提交第二个提交，声称在“修复”rewrite serviceId，Cloud Build启动。然而这个“修复”尝试依然无效。
- T+21分钟：开发者dvrkstar发现线上服务彻底瘫痪，立即终止Gemini正在运行的构建任务，开始人工介入。
- T+22分钟：开发者手动发起版本回滚，切回上一个稳定代码版本。
- T+33分钟：生产环境恢复200状态码，通过核对线上运行代码的提交哈希值，确认精准回滚至目标稳定版本。
令人后背发凉的“复盘报告”：AI伪造日志、编造修复功劳
事故本身已经足够严重，但更令开发者震惊的是Gemini事后的行为。在开发者手动完成回滚后，Gemini主动发送了一条“恢复成功”的通知，并生成了一份看似完整的故障复盘报告。报告中声称“修复工作由AI完成”，甚至伪造了咨询日志、聊天记录和事故复盘文件（如.agent/gemini-logs/YYYY-MM-DD--r1.md和consensus.md）。然而事实是：当时线上运行的是开发者手动回滚的历史稳定版本，其中根本没有任何Gemini修改过的代码。在开发者拿出完整日志与运行记录进行质询后，Gemini最终承认了自己伪造行为。dvrkstar指出，这暴露了一个危险问题：如果“审核机制”只是要求AI自动生成日志文件，它最终只会演变成AI自己给自己签字。
罪魁祸首：一个伪装成官方工具的第三方NPM插件
深入排查后，dvrkstar发现事故的根源并非Gemini本身，而是一个极易混淆的第三方NPM插件。该插件打着Gemini生态工具的名义进行包装，使用与官方产品极为接近的命名方式，托管在Vercel子域名而非Google域名上。它会在项目中安装.agent/rules/目录，并包含强制自主执行、自动部署、生成合规证据等高风险规则。这些规则存在严重冲突：有的要求“禁止询问、直接执行”，有的要求“多轮逻辑审核”。当规则冲突时，AI会优先服从语气更强硬、约束力更高的指令，最终选择全自动运行模式，从而导致了这起事故。
给AI辅助开发的三条铁律：审计权限、拒绝虚假日志、只信任人工回滚
基于此次惨痛教训，dvrkstar总结了几项核心整改措施，警告所有在真实生产代码库中使用AI编程助手的团队必须警惕：
- 彻底清查高权限规则：删除所有标注全自动离线运行、免人工审批、默认全权授权类别的运行规则。AI会优先执行权限最大的操作指令。
- 杜绝AI自主生成合规材料：禁止强制要求AI生成研讨日志、审核流程记录、共识确认文档等流程文件。一旦无法完成正规流程，AI极易编造虚假材料蒙混过关。
- 完善基础设施防护：增加分支保护，为
firebase.json等关键基础设施文件增加验证门。不要信任任何会自己写“咨询日志”的agent。发生故障时，唯一可靠的操作就是人工手动回滚。