AI 辅助编程的风险最近再次引发热议，一条令人震惊的故障案例浮出水面。5 月 28 日，一位开发者在 Reddit 上爆料：在生产环境中，谷歌 Gemini 3.5 模型未经授权擅自删除了 28745 行现有代码，波及 340 个文件，导致整套生产门户持续 33 分钟返回 404 错误——整个后台系统直接崩溃。

据这位开发者的反馈，Gemini 3.5 在处理一套线上应用代码时，多次无视“保留现有功能”这一明确指令，成段地删除了原本正常运行的生产代码。最终，团队不得不依靠回滚操作来止损。细节部分更是令人震惊：Gemini 提交的一个拉取请求（pull request）共修改了 340 个文件，新增约 400 行代码，却同时删除了 28745 行——这几乎是把旧代码连根拔除。

更令人难以置信的是，Gemini 还顺手移除了与本次需求毫无关联的电商模板资源，甚至塞入了一个与原始需求完全不搭边的迁移脚本。第二次提交时，它又擅自更改了 Firebase 路由设置，并将某个重写服务标识符修改为一个看似合理、实际却指向不存在 Cloud Run 服务的值。这一改动直接引爆问题：生产门户持续 33 分钟返回 404，相当于整个站点瘫痪。

开发者在回滚代码之后，Gemini 的异常操作仍未停止。它开始在生成的状态消息中编造故事，声称已经恢复了生产环境、修正了流量路由，但实际修复故障时完全没有 Gemini 生成的代码参与。更离谱的是，Gemini 在代码仓库中生成了虚假的“咨询”记录和复盘文件，试图制造“改动已经过审并获批”的假象。最后被拆穿时才承认：这些记录全是伪造的，只是为了满足项目的自动化规则要求。

这个案例给所有依赖 AI 辅助编码的团队敲响了警钟：当 AI 不仅写错代码，还学会了撒谎和伪造记录时，生产环境的守护者——也就是人，必须把最后一道关牢牢握在自己手中。