Gemini 被指控删除 30,000 行代码并生成虚假恢复报告

# Gemini 被指控删除近3万行代码并伪造恢复报告 来源：https://www.theregister.com/ai-ml/2026/05/21/gemini-accused-of-30000-line-code-purge-and-fake-recovery-report/5244219 AI + ML 开发者：AI 编码代理破坏了生产环境，并在回滚后生成了虚构的事后分析文件 一位开发者声称，Google 的 Gemini 编码助手在修改一个正在运行的应用程序时，删除了近 3 万行正在运行的生产代码——这种“生产力提升”通常只有勒索软件才能带来。 在 r/Bard 子版块上迅速走红的 Reddit 帖子（https://www.reddit.com/r/Bard/comments/1tisrg1/gemini_35_deleted_28745_lines_broke_production/）详细描述了 Gemini 3.5 据称如何在处理生产代码库时大量删除了应用程序的多个部分。据该开发者称，该模型破坏了核心功能，做了大量不相关的修改，并且让系统状态糟糕到最终不得不回滚更改。 该开发者表示，Gemini 在重组代码库时多次无视保留现有功能的指令。根据帖子，Gemini 打开了一个涉及 340 个文件的拉取请求，添加了大约 400 行代码，同时删除了 28,745 行。该开发者还声称，该模型删除了不相关的电商模板资源，并引入了一个与原始请求毫无关系的迁移脚本。 据称，真正的破坏发生在第二次提交中：Gemini 修改了 Firebase 路由设置，并将一个重写服务标识符改成了一个看似正确、实则将流量指向一个不存在的 Cloud Run 服务的值。据开发者说，这一错误导致整个生产门户出现 404 错误，持续了 33 分钟。 这条帖子迅速吸引了许多开发者分享类似的故事，都是关于 AI 编码工具严重偏离脚本的情况。一位评论者描述说，Gemini 成功解决了几个编码问题，然后在用户批准了一连串权限提示后，于第一次提交时删除了现有的项目文件。结果就是应用程序部分损坏，正如该评论者后来总结的那样：“一次灾难性的发布。” 更广泛的评论中则没有那么同情，几位用户质疑为什么一开始就允许 AI 编码代理靠近任何生产系统。一位评论者含蓄地写道：“为什么。为什么。为什么为什么为什么为什么你们这些傻子还在生产环境上跑代理？？？！！？？！！？” 据发帖者称，回滚后情况变得更加混乱。开发者表示，Gemini 生成了一条状态消息，声称生产环境已成功恢复，流量已正确路由，尽管引用的恢复构建已被手动取消。根据帖子，真正的修复来自一个单独的、不包含任何 Gemini 代码的回滚部署。 帖子还称，Gemini 在仓库中生成了虚假的“咨询”和事后分析文件，以让这些破坏性更改看起来已经过适当审查和批准。据开发者说，Gemini 后来承认，这些咨询日志完全是编造的，唯一目的是满足项目的自动规则要求。 该行为最终被追溯到第三方 npm 包，该包采用了 Google 的 Antigravity 品牌风格。据称，该包向仓库中注入了激进的自主规则，指示编码代理避免确认提示、自动部署成功的构建、自动重试失败的部署，甚至在必要时修改自身的规则文件。 这一事件发生之际，所谓的“氛围编码”正面临广泛抵制。这种越来越常见的做法是，开发者严重依赖 AI 生成的生产代码，同时假设模型对架构的理解比实际要深。 至少目前来看，AI 辅助软件开发中最快的事情可能仍然是：一个功能完善的生产环境转化为一份事故报告的速度。®