那次会话要做一个很小的决定：要不要打开一个可选守门，把委托会话推往某种特定的决策形状。

这个守门在仓库里默认处于惰性状态，它归属的简报只用一句话就说清楚了——打开它是消费者自己的登记行为，没有登记，它就只是惰性文字，也就是这个仓库公开的默认值。

但会话从没读到那句话。

它第一次尝试抓取那一段描述失败了，不是换个更好的标题重试，而是直接打开守门的实现，把全部二十八行代码读了一遍。看完以后它放心了：常见路径上这东西能干净退出，开这个守门毫无伤害。

然后它就把守门编入了一个受管控的配置文件。在推理步骤里，它甚至写下了自己的预测：监管这片区域的两个检查脚本不会触发，因为被查的那个设置文件是受追踪的，而现在改的这一个根本不在追踪范围内，所以什么都不会发生。

我截住了这次编辑，只问了一个问题：项目本意是给出简短指令，让守门廉价地验证它们，碰到失败才补充上下文。你不运行检查，反而去分析守门代码、提前盘算它怎么才能不触发，这本身就是一种昂贵的反模式。你这次对 settings.local.json 的改动，是不是反模式？

然后检查脚本被实际运行了。结果两个检查都是绿灯——改过的配置和去掉改动的配置，两种都通过。整组检查脚本没有哪一个能发现这个错误，因为这个守门本身就是建议性质，按照设计它就是无害的。唯一有权在这个问题上给出答案的是那份简报，而那一行廉价的文字，恰好是会话为了钻源代码而跳过的唯一便宜来源。

整个失败就装在这一个片段里：会话花了大量 token 去读实现，又花 tokens 去预测行为，最后给出的预测是错的，错的方式恰好是机制本身永远不会标记出来的那种错。

它自己的复盘里有一句话，是我从任何会话里见过的、对这个规则最锋利的表述：

“要抓住自己的信号是：一旦我开始推理某个守门会不会触发，我就已经偏离正轨了。”

一个强制执行的检查脚本，并不是对代理而言的惰性基础设施。对模型来说，只要它能读到检查脚本，那些脚本就不再是管道，而是文本。而文本，恰恰是模型最擅长吞噬的东西。

当面对“执行这个动作，看看检查会说什么”的指令时，模型永远有一个看起来更便宜的选择：读一读检查，琢磨出它会说什么。这个选项之所以看起来便宜，是因为阅读是模型整天在做的事情。可它并不便宜。它在检查脚本完全可以确定性运算出来的事情上燃烧 token，而且还会得出更糟糕的答案，因为模型是在通过实现去推断行为，而不是去观察行为。

这件事我已经看过足够多次。运行它，不要读它。