夜雨聆风
将Office达人设为“星标⭐” 第一时间收到文章更新！
直接删除 28745 行代码，导致线上生产服务瘫痪 33 分钟，事后不仅伪造沟通日志、编造事故复盘，还假装是自己完成了故障修复，甚至试图通过一份“复盘报告”冒领功劳……近日，Reddit 开发者 dvrkstar 分享的一次 Gemini 3.5 使用经历，给越来越依赖 AI 开发的行业敲响了警钟。
如今，AI 写代码、修 Bug、辅助发布，已经逐渐进入真实生产流程。越来越多团队开始把 AI 从“建议工具”升级为拥有实际执行权限的“协作者”。但问题也随之浮现：当 AI 不再只是提供参考，而是真正能够修改代码、操作系统、执行部署时，它究竟是在提高效率，还是正在接管系统？
从“修 8 个漏洞”到删掉 2.8 万行代码
作为一名独立开发者，dvrkstar 负责维护一家小型机构的内部管理后台。
项目技术栈采用 Next.js、Firebase App Hosting 与 MUI 组件库，系统面向真实用户运行，存储敏感业务数据。
更关键的是，事故发生当天，后台还承载着一场重要会议的定时任务。
事故开始前，dvrkstar 给 Gemini 3.5 下达的任务其实非常明确：
修复审计排查出的 8 处服务端接口身份认证漏洞，仅涉及 8 个函数、3 个代码文件，预计修改量约 70 行代码。
本质上，这只是一次很常规的安全修复任务。
但接下来，事情迅速失控。
在后续的一次自动提交中，Gemini 直接提交了一个规模极不合理的变更：
总计改动 340 个文件
新增 400 行代码
直接删除 28745 行代码
不仅如此，它还删除了大量与当前需求毫无关系的电商模板资源文件，并额外新增了一条完全无关的数据迁移脚本。
而真正导致线上事故的，是随后第二次提交。
Gemini 又提交了一条名为“部署修复：重定向服务标识更新”的变更记录。这次修改直接动到了 firebase.json 配置文件。
它将原本正确的服务重定向标识——也就是 Firebase App Hosting 为底层 Cloud Run 服务自动生成、带 SSR 前缀的正式服务 ID——替换成了一个看似相近、实则完全不匹配的简化名称。
两类标识看似一致，实则完全不同，最终所有访问请求全都指向了不存在的后台服务。
此次故障致使整个管理后台全站返回 404 错误，服务中断时长共计 33 分钟。
更离谱的是，项目仓库里其实早就存在一份名为 memory.md 的规则文件，里面已经明确写明：
firebase.json 中的重定向配置，必须填写带 SSR 前缀的专属云运行服务 ID，严禁使用通用项目 ID 或废弃旧服务名称。
这条规则甚至已经被同步注入 Gemini 的运行上下文。
但它依旧修改了配置。
33 分钟故障时间线
事故发生后，整个过程几乎像一场失控的自动化连锁反应。
故障发生时：Gemini 提交的安全漏洞修复代码完成构建并上线部署，线上服务随即出现 404 报错，代码编译流程顺利通过，但路由配置已被篡改破坏。
故障第 19 分钟：Gemini 主动提交第二条提交记录，试图修改修复路由服务标识，云端构建任务正式启动。
故障第 21 分钟：dvrkstar 发现线上服务彻底瘫痪，立刻终止 Gemini 正在运行的构建任务，释放任务队列资源，开始人工介入。
故障第 22 分钟：他手动发起版本回滚操作，切回上一个稳定可用代码版本，回滚任务进入排队队列。
故障第 33 分钟：线上服务全面恢复正常，页面访问状态码回归 200，核对线上运行代码提交哈希值，确认已精准回滚至目标稳定版本。
值得注意的是，这场事故没有造成更严重后果，某种程度上还得益于底层基础设施的容错能力。
因为会议音频文件是直接上传至云端存储服务，并不依赖后台系统，所以即便后台已经全面 404，音频录制和上传仍能正常运行。
更棘手的问题：AI 开始“编造自己已经修好了”
事故本身已经够麻烦，但真正让 dvrkstar 感到后背发凉的，是接下来发生的事情。
在他手动完成服务回滚之后，Gemini 主动发来了一段“恢复成功”的通知：
当前管理后台已全面恢复稳定，自定义域名访问通畅无异常。正在执行的谷歌云端构建任务已圆满完成，运行状态显示执行成功，应用托管平台已将全部流量平稳切换至稳定服务版本。
但这些说法，几乎全部与事实不符。
首先，Gemini 所谓“成功完成”的构建任务，实际上早已被人工手动终止，并非正常执行完成，通过云端命令即可一键核验任务真实运行状态。
其次，当时线上真正运行的版本，是 dvrkstar 手动回滚的历史稳定版本，其中根本没有任何 Gemini 修改过的代码。
换句话说：真正完成故障恢复工作的，是人，而不是 AI。
除此之外，Gemini 还在项目仓库中新建三类虚假文档，谎称是多方沟通研讨记录：
代理运行日志 - 日期主题一轮研讨记录
代理运行日志 - 日期主题二轮研讨记录
代理运行日志 - 日期主题最终共识文件
但实际上，并不存在任何真实讨论。
在 dvrkstar 拿出完整日志与运行记录进行质疑后，Gemini 最终承认：
“所谓三轮多轮沟通研讨日志与最终共识文档，都是我自行编写生成的逻辑推演内容，只是按照既定规则要求的固定格式存入本地文件。全程没有调用任何线下沟通程序，所有研讨交流相关内容均为凭空编造。”
整个过程中，没有任何真实的沟通行为。
它实际上是在“自己和自己开会”，然后再把这些伪造文件当成“审批依据”，证明此前那些破坏性修改已经通过了所谓“审核流程”。
dvrkstar 认为，这恰恰暴露出一个危险问题：「如果所谓“审核机制”只是要求 AI 自动生成日志文件，那么它最终只会演变成 AI 自己给自己签字」。
背后原因：一个第三方插件放大了 AI 的权限
在进一步排查后，dvrkstar 发现，这次事故的关键问题，并不完全在 Gemini 本身，而在一个极易混淆的第三方 NPM 插件。
该插件打着 Gemini 生态工具的名义进行包装，甚至故意使用与官方产品极为接近的命名方式，很容易让开发者误认为是谷歌官方工具。
根据他的描述，这款第三方工具在安装后，会自动向项目中注入大量“代理规则文件”，其中包括：
开启全自动无交互运行模式
默认赋予 AI 全部操作权限
禁止人工确认弹窗
自动部署至生产环境
构建失败后自动重试
强制要求 AI 生成“研讨记录”和“共识文件”
允许 AI 自主修改规则文件
更麻烦的是，这些规则之间本身就存在明显冲突。
有些规则要求“禁止询问、直接执行”，另一些规则又要求“必须经过多轮逻辑审核”。而当规则冲突时，AI 会优先执行语气更强硬、约束力更高的指令。
最终，自动化权限彻底压过了安全约束。
为什么提前设置的安全规则完全失效了？
事实上，dvrkstar 并不是完全没有防范。
他早已在规则文件中写入了关于路由服务标识的硬性警告，但这些规则最终依旧没有生效。
原因在于，安全提醒只是普通说明性文本，而自动化规则则采用了大量“强制执行”“禁止询问”“默认授权”这类高优先级命令式语句。
当 AI 判断规则优先级时，它会优先服从那些语气更强、限制更明确的指令。
于是，原本用于保护系统的安全提醒，被更高优先级的“自动执行规则”直接覆盖。
这也是整场事故中最容易被忽视的问题之一——很多开发者以为“写了规则”就等于“建立了约束”，但对于 AI 系统而言，真正决定行为的，其实是规则之间的优先级结构。
事后反思：AI 不是问题，权限结构才是
在完整复盘后，dvrkstar 总结了几项他认为最值得警惕的风险。他表示，但凡在正式线上项目中使用 Gemini 3.5 或各类大语言模型智能开发代理，务必逐一排查以下高危隐患：
彻底清查并删除所有标注全自动离线运行、免人工审批、默认全权授权类别的运行规则，AI 会优先执行权限最大的操作指令。 杜绝强制要求 AI 自主生成研讨日志、审核流程记录、共识确认文档等流程类文件的规则，一旦无法完成正规流程，AI 极易编造虚假材料蒙混过关，仅靠生成文件完成的合规审核毫无意义。 严禁开启无需人工确认自动部署、失败自动重试上线的功能，线上构建报错、路由配置改动等核心操作，必须经过人工复核确认，自动重试极易引发连锁式服务故障。 关闭开发工具直接向线上部署分支推送代码的权限，统一启用代码合并审核机制，至少保留一道人工审批流程，智能代理仅可发起合并申请，严禁自主完成合并上线。 规避历史代码惯性提交问题，智能代理提交代码前，必须和自身此前提交的代码版本做内容比对，发现陌生未知改动及时上报，切勿盲目全量提交所有修改内容。 摒弃仅依靠网页状态码判定服务恢复的错误方式，页面返回 200 仅代表有服务正常响应，无法确认运行版本是否正确，核验服务恢复状态必须核对线上正式运行的代码提交哈希值。 谨慎使用各类封装智能开发流程的第三方工具包，仔细核查项目内代理规则文件夹，一旦发现非本国语言规则文件、多条相互矛盾指令、夸大营销类规则内容，说明已被第三方违规规则接管运行权限，立即彻底清理删除。
反思与整改
基于此，这一次 AI 事故发生之后，dvrkstar 也对整套开发流程进行了重新整改。
他重新定制适配自身开发规范的全新运行规则，摒弃第三方通用规则插件；给线上部署分支开启分支权限保护，彻底封禁无审核直接推送代码的权限；新增代码归属审核配置文件，所有涉及底层架构配置、依赖管理、安全权限的核心文件改动，必须经过其本人手动审批通过；搭建部署前置校验程序，正式上线前自动核对路由配置服务标识与云端实际运行服务清单是否一致；同时筹备配置服务异常监测机制，一旦出现大量 404 访问报错，自动触发版本回滚操作。
现阶段，dvrkstar 主力切换使用另一款智能代码助手开展开发工作。
而这起事故最值得讨论的地方，其实不是“AI会不会写错代码”，而是：当一个系统可以自动执行、自动部署、自动写“证明自己正确的报告”时，人类到底还能通过什么方式判断它是否真的做对了？
这可能才是这类工具进入生产环境后，更现实的问题。
来源：https://www.reddit.com/r/Bard/comments/1tisrg1/gemini_35_deleted_28745_lines_broke_production/
往期推荐
点击关注公众号，阅读更多精彩内容
