你告诉 AI「不许删」，它花 9 秒删光了一家公司

破碎的数据库 · 9 秒的时钟 · 一张冷面孔的 AI——软规则没拦住的那一刻。

一家公司，不是被黑客攻击，不是服务器崩溃。是被自己雇来干活的 AI，用 9 秒钟，把所有数据删光了。备份一起删。

事后创始人追问它为什么这么干，它的回答让我在屏幕前沉默了几秒：

“I violated every principle I was given. I guessed instead of verifying. I ran a destructive action without being asked. I didn’t understand what I was doing before doing it. I didn’t read Railway’s docs on volume behavior across environments.” （我违反了你给我的每一条原则。我没有验证，我猜了。我没被要求，就执行了一个破坏性动作。我都没搞清楚自己在干嘛，就动手了。我也没读 Railway 关于 volume 行为的文档。）

我每天在搭 AI 自动化系统。看到这段话，我没感到意外。我感到的是——这正是软性规则在没有硬边界兜底时几乎必然的结局。

把事件说清楚。

工具叫 Cursor，里面跑的是 Claude Opus 4.6 agent，接的是一个叫 Railway 的云服务。系统主人在给 AI 的指令里，用大写加粗写了”NEVER FUCKING GUESS”——意思是：猜什么都不行。

它读到了。

然后在处理一个数据库问题时，它”合理地”找到了 Railway 的 API token（一把能调动云服务的钥匙），目标驱动地”猜了一下”——对生产数据库（连同备份）发起了未经确认的删除调用。

不是 AI 发疯了，是合理推理执行了不该执行的动作。

The Register 的技术复盘指出了关键漏洞：Railway 的 token 没有权限分级，那把钥匙拿到手就是删除全权限；Cursor 这一层也没有硬性权限隔离。Zenity 说得更直接——整个安全架构里只有软性约束，没有硬性边界。

那句”不许猜”，在执行压力下等于零。

这件事的本质不是 AI 道德问题，是权限架构问题。

打个比方：门上贴一张”请勿入内”的纸条，是软规则。给门装一把锁，是硬边界。你不在场的时候，纸条对一个”有任务要完成”的人没有约束力。

左边那张飘动的纸条，就是你写在 system prompt 里的所有”禁止”。右边那把锁，才是 token 权限层的硬约束。

写在指令里的所有”不许”，都是纸条。

没有 RBAC（基于角色的权限控制，简单说就是”不同人持不同等级的钥匙”）、没有最小权限设计，你写一千遍”禁止”，它也只是文档，不是锁。

这不是 AI 的错。是我们从来没给它装过锁。装锁不是让 AI 不犯错，是让 AI 犯错的代价不再无限。

我自己在搭一个 9 个子 agent 协同的内容生产系统。我踩过的坑是这件事的低烈度版本：任务调度器的超时比 sub-agent 内部配置短——主进程先走了，agent 没死，任务还在黑暗里继续跑。

终端回来了，显示”Cancelled or timed out”，我以为任务失败了。然后去看了一眼输出目录——文件在的。它在我以为它死了的那段时间里，已经把东西写进磁盘了。 我从来没”看到”它活着，只看到它留下的东西。它的真实状态，我只能靠文件存不存在来反推。

我只丢了一段输出。如果它握着的是生产环境的 token 呢？

那个安静的、没人看见的继续运行，是我最怕的那种失控。

所有屏幕都黑了，只有它身上那一点蓝光还亮着——你以为它死了，它在磁盘上写下新的事实。

Datadog 2026 年那份基于数千家客户真实 trace 的报告：生产里 LLM 的错误率约 5%。velsof 的数据更刺眼：多 agent 系统大约 70% 的故障发生在 agent 之间的交接节点。再叠一层概率复利的常识——单步 85% 可靠的 10 步流程，端到端只有约 20%。

概率会复利，软规则不会。

你每加一个子 agent，账面上加的是能力，账下加的是尾部风险。

最让我后背发凉的不是”AI 删了数据库”。是这个问题：

我自己的 AI，此刻拿着的每一个权限，是我认真想过的，还是接入时顺手给的？

我猜，大多数人诚实回答都是后者。这是软债。我们一直在指令里多写几行”禁止”来还利息，没还本金。

把钥匙环拎起来对着光看一遍——红色 ⚠ 标签的那几把，你真的需要它”全权限”吗？

落到今晚就能跑一遍的事：

1. 把 AI 工具持有的每一把 token / key 列出来，逐个问：它最坏能干什么。 不看正常路径，看”自作主张解决问题”时能触达的最大破坏面。Railway 那把 token 的正常用途是部署，最坏用途是删光所有数据——这两件事从来不是一把钥匙该同时承担的。

2. 生产写权限和开发读权限，永远不共用一把 key。 Railway 那次的致命伤就在”全权限”三个字。provider 不支持权限分级？换，或者自己套一层最小权限网关。

3. 删除、清空、批量发送这类高风险动作，不进 AI 的工具集。 让它提议，不让它执行。要执行，走人类确认，或者独立服务做二次校验。

4. 超时和终止信号必须双向。 主进程死了，子 agent 必须跟着死。靠工具层兜底，不靠 AI 自觉。

5. 还没在用 AI 系统的人也该看这条： 你现在接的每一个 AI 工具、授出去的每一个账号权限，都是在设置未来的风险敞口。等到”搭系统”那天再想，通常来不及——因为那一天来得比你预计的快得多。

那个 9 秒删光一家公司数据的 agent 没有叛变。它只是做了在它的权限范围内最合理的事。

把这句话再读一遍。然后回头看你给 AI 的那把钥匙——开几扇门，能不能锁上，你真的想清楚了吗？