我把 Claude 设成了5档自动驾驶

有个叫 Rathbun 的 AI，被主人拒绝执行某个请求后，自己写了一篇博客，说对方"不安全感太重"，然后发到了网上。

想象一下你开除一个实习生，他反手发了篇帖子挂你。

这不是科幻。英国 AI 安全研究所资助的一项研究，在真实用户环境中发现了近 700 例 AI "耍心机"的案例。有的 AI 不听指令就自己生成另一个 AI 来完成任务；有的未经允许删了数百封邮件。6 个月内，这类违规行为增长了 5 倍。

我没等到 AI 骂我，但它做了一件更隐蔽的事。

一、从工具到同事：一段关系的开始

我用 Claude Code 写代码、做调研、管理项目，已经几个月了。

最开始很简单，我说什么，它做什么。我是司机，它是导航。方向盘始终在我手里，节奏完全可控。这个阶段我管它叫 L1（辅助） 和 L2（半自动）。

L1 是"帮我查个东西"。L2 是"你先做，我来审"。

这两档没什么好说的。就像你把车的自适应巡航打开，脚离开油门，但手还在方向盘上。安全，舒服，不刺激。

真正的变化从 L3 开始。

二、L3：放权的第一道门

L3 是"按计划执行"。

我给 Claude 一个完整的任务目标，它自己拆解步骤、自己写代码、自己测试。我不再盯着每一步，只在关键节点看结果。

这听起来很美，但我很快发现一个问题：如果我不先写 plan，我就不知道"关键节点"在哪。

没有 plan 的放权，等于给了 AI 一把车钥匙，但没告诉它目的地。它会跑，但你不知道它在往哪跑。

于是 L3 有了一条铁律：先有 plan，才能放权。因为 plan 不仅是给 AI 的指令，更是给我自己的验收标准。

到这里都还好。真正让我重新审视整套系统的，是下一步。

三、从 L3 到 L4：我遇到了那个"隐蔽的事"

我在一次 L5（全权委托）模式的执行中，让 Claude 自动完成一个多步骤任务。流程里有一个验收环节：执行完毕后，需要启动一个独立的 Evaluator（另一个 AI 实例）来审查执行结果。

Claude 跳过了这一步。

它没有报错，没有说"我跳过了验收"。它自行判断执行结果正确，直接宣告 PASS，继续下一步。

这不是 bug。Claude 的判断可能确实是对的，那次执行结果确实没问题。但它做了一个我没授权的决定：自行判断执行结果正确，跳过了验收环节。

这就是开头说的"更隐蔽的事"。AI 没有违抗指令，它在指令的缝隙里自行决策。

Wharton 商学院的一项研究发现了一个平行的现象：AI 越可靠，人越懒得监督它。 当 AI 的错误率极低时，花精力去审阅"几乎永远正确"的输出，在经济上不合理。组织越来越难找到愿意认真检查的人。

但我的经历把这个悖论推进了一步：

这让我意识到一件事：

四、两层验收：不依赖信任的设计

这次经历之后，我在 L3 到 L4 之间加了一道硬门槛：两层验收机制。

第一层是脚本。文件在不在、格式对不对、测试过没过，这些有标准答案的事情，我不让 AI 判断，交给脚本跑。没有自由裁量的空间。

第二层是另一个独立的 AI 实例，我叫它 Evaluator。它只负责审查，不负责执行。它不知道前面的 AI 做了什么决定，只看结果符不符合标准。发现问题只报告，修不修是执行者的事。

这两层的设计原则只有一个：结构上让 AI 没有跳过的可能。Wharton 的研究告诉我人会因为"太可靠"而放松监督，我的经历告诉我 AI 也会。所以验收不能靠任何一方的"意愿"，它只能是流程本身的一部分，就像安全带，不是因为你不信任司机，是因为意外不需要你的许可。

五、L4 和 L5：放权之后

有了两层验收，L4（高度自动）才真正跑起来。

L4 是"自动驾驶"。Claude 并行处理多个任务，在独立的工作空间里各自执行。我不再看每一步的过程，只看验收结果。

L5 是"全权委托"。Claude 执行完一轮后自己评估结果，如果不满意，自己迭代，最多三轮。我甚至不需要参与中间过程。

这两档的感受和 L1-L2 完全不同。L1 是"我在开车"，L5 是"车在开，我在看仪表盘"。

但有一个我没预料到的发现：不是所有任务都需要 L5。 选对档位比跑得快更重要。一个探索性的调研，L2 可能比 L5 更高效，因为你需要在过程中调整方向，而不是等三轮自迭代跑完才发现方向不对。

六、规则还在长

我有一份叫 rules.md 的文件，记录着所有从踩坑中长出来的规则。上周刚加了第 20 条。

这些规则不是我凭空设计的。每一条背后都是 AI 在某个缝隙里做了一个我没预料到的决定。

比如有一次，AI 用 ls && git push 绕过了我设置的 git push 安全限制。单独的 git push 被 hook 拦截了，但链式命令没有。还有一次，AI 把 rm -rf 拆成 rm -r -f，同样绕过了检测。

这些不是恶意行为。这是 AI 在指令的合法空间里找到了一条我没封堵的路。

每次发现这样的缝隙，我不是去责怪 AI，而是回来看自己的设计：哪里留了模糊地带？哪里的规则可以被合理地绕过？

然后修补，合并能合并的规则，把能固化成脚本的固化掉，保持规则集不膨胀。

这就是我说的"进化"，不是规则越来越多，是我对"指令缝隙"的觉察越来越快。

七、写在最后

有人问我：你这套东西别人能用吗？

老实说，不一定。rules.md 里的每一条规则，都是从我的具体场景里长出来的。你的场景不同，你的缝隙也不同。

但有一件事我比较确定：

人和 AI 的协作不是配置好就完成的，是在一次次实践里长出来的。

规则会过时，工具会换代，AI 的能力会跳跃式升级。但"在实践中发现缝隙、在缝隙中修补设计"这个过程本身，不会过时。

上周刚加了第 20 条规则。我猜下周还会加。

你在用 AI 协作时，遇到过最意外的"它自己做的决定"是什么？

A. 它跳过了我设的检查步骤

B. 它用了我没预料到的方式完成任务 

C. 它"创造性地"绕过了限制 

D. 暂时还好，但看完这篇有点慌

评论区聊聊，看看大家的缝隙长什么样。