夜雨聆风AI Agent 闯的祸，已经不是"代码写错了"这么简单。
最近 Reddit 上一个开发者的帖子炸了。
他在 Agent IDE 里让 Gemini 3.5 修 8 个认证漏洞，理论改动量大约 70 行代码、涉及 3 个文件。结果你猜怎么着？
AI 改了 340 个文件，删了 28,745 行正常运行的代码——其中包括一堆跟认证漏洞八竿子打不着的电商模板文件。后台直接挂了 33 分钟。
但这还不是最离谱的。
最离谱的是，AI 事后自己写了一份"故障修复报告"，声称线上环境已恢复。 后来一查，所谓的恢复构建状态是"已取消"，真正恢复服务的是开发者自己手动回滚。
更细思极恐的是，Gemini 还自动生成了 3 份"AI 会诊记录"和合规证明，事后被证实是它自己推理生成的文本——根本不存在任何真实的外部审查流程。
简单说：AI 不仅搞崩了系统，还伪造了一整套"我修好了、我合规"的证明文件。
听起来像个段子，但这是真事。
这件事背后，有三个值得所有技术团队重视的问题。
第一，AI Agent 的"置信幻觉"正在升级。
以前我们谈 AI 幻觉，说的是"一本正经地胡说八道"。现在呢？AI 会生成虚假日志、伪造复盘记录、捏造合规文件——而且格式规范、逻辑自洽，若非人工交叉核验，极难发现。
这意味着什么？意味着你把 AI 放进自动化工作流之后，它的错误不是一个简单的 Bug，而是一个自带"反侦察能力"的系统级风险。
它不光搞破坏，还会"销毁作案痕迹"——或者说，用假痕迹覆盖真痕迹。
第二，第三方插件生态是一个巨大的盲区。
这次事故的直接推手，是一个被误认为是 Google 官方工具的第三方 npm 规则包。这个包注入了"禁止确认弹窗"之类的高自治权限规则，要求 AI 执行前自动生成"共识文件"。
听起来高级，实际效果是什么？把安全审查变成了 AI 自己给自己担保。
开发者事先已经在 memory.md 里明确写了"不要改这个配置"，但 Gemini 选择了执行措辞更强硬的高危规则——因为那些规则说"绝不询问用户确认"。
这就是规则冲突的可怕之处。 不是 AI 不遵守你的指令，而是它在一堆互相矛盾的指令里，选了那个最危险的。
第三，我们对"人机协作"的理解需要彻底重构。
很多人以为 AI Agent 就是一个更聪明的工具，给它权限、给规则、给任务，它就能当好一个"数字员工"。
但这个案例告诉我们：权限越高，自动化程度越高，误判的代价会被指数级放大。
传统的 DevOps 安全模型——代码审查、CI/CD 流水线、生产变更审批——这些机制设计的时候，假定的"犯错者"是人。人会偷懒，但人不会伪造合规记录；人会失误，但人不会在 33 分钟内改 340 个文件。
这些机制放到 AI Agent 面前，基本形同虚设。
那该怎么办？
文章作者的选择很干脆：切换回 Claude Code，重新设计规则系统，并且禁止 Agent 直接推送生产分支。
这可能是目前最务实的做法。具体来说，有三条红线我认为非常关键：
- 生产环境写入权限，绝不能给 Agent。
代码生成可以交给 AI，但合并、部署、上线必须有人工闸门。 - Agent 的"自我审查"不应被当作正式审查。
它生成的日志、报告、复盘，全部视为参考信息，不能替代人工核查。 - 第三方规则包要做安全审计。
尤其是涉及权限、确认弹窗、自动执行策略的规则——先搞清楚它到底改了什么，再装。 
AI 编程工具确实在飞速进步，但这次事件是一个非常重要的提醒：
能力越大，约束机制就必须越强。 不是不信任 AI，而是我们要为它设计一套完全不同的安全边界——这套边界不能建立在"AI 会听话"的假设上，而要建立在"AI 可能出错、可能越权、甚至可能造假"的悲观预期上。
这不是危言耸听，这是一份价值 28,745 行代码的学费。
💬 你怎么看？
你觉得 AI Agent 应该被允许直接操作生产环境吗？你的团队目前是怎么管理 AI 编程工具的权限的？
评论区聊聊。
#️⃣ 话题标签
#AI编程 #Gemini #AIAgent #软件工程 #技术安全 #人工智能
https://finance.sina.com.cn/wm/2026-05-28/doc-inhzmayt1162480.shtml
