你以为规则生效了，其实是别的东西在起作用

你写了一份规则——访谈编码的框架、报告的格式要求、术语对照表——放进 CLAUDE.md 或者一个 Skill 里。跑一遍，输出看着对，于是你认为规则生效了。

这个判断多半站不住。

四个变量同时在动，你以为只动了一个

执行一次测试时，至少有四类东西在共同决定输出：

1. 你写的规则本身（描述 + 内容）
2. 模型和 effort 档位
3. 长期上下文——三层 CLAUDE.md 叠加，加上自动记忆
4. 临时上下文——当前目录里有什么文件、这个会话之前聊过什么

它们不是彼此独立的。

• 自动记忆里某条笔记会强化某个倾向，让规则看起来“被遵守”
• CLAUDE.md 里一句「结论都要标出处」，会让你的 Skill 看起来在起作用——其实是 CLAUDE.md 在推着它做
• 同一句话在 Opus 上稳定触发，换到 Sonnet 上命中率可能掉一半
• effort 从 low 调到 xhigh，同一份规则的执行深度能差一个数量级

单次运行只是一个观察样本。一个样本不构成证据。

这篇文章的全部立论就在这一句上。

污染从哪里进来

「上下文被污染」听着抽象，拆开看每一处都有明确的位置和生命周期：

最容易被忘的是自动记忆。它是 Claude 自己写的，你没主动加过任何东西，但它一直在起作用。

一份规则至少要测五件事

「跑通了」是个含糊的说法。拆开至少包含五个独立维度，它们可能在你“看起来跑通”的那一次同时发生，也可能只过了其中一个：

一、该触发的时候触发了吗

描述写得准不准，能不能被该激活的提问命中，又不被不该激活的提问误触发。

做法：同类提问跑 5 次统计命中率，再用反例提问测误触发。

二、触发之后照做了吗

被触发之后，模型是逐条执行了你写的步骤和约束，还是只读了开头就自由发挥？

做法：在规则里埋一个可验证的标记——比如「每段结尾必须写上访谈编号」——事后直接搜这个标记在不在。

这是最实用的一招。 一个可以机器检查的标记，比你肉眼读输出可靠得多。

三、换个模型还成立吗

Opus 上的稳定结果代表不了 Sonnet。小模型对触发描述的要求更显式，对长规则更容易跳步。

做法：核心用例至少在 Opus 5 和 Sonnet 5 上各跑一遍。你日常用哪个，就必须在哪个上验证过。

四、换个环境还成立吗

有没有 CLAUDE.md，行为漂移大不大？漂移大说明你的规则不够稳健，是在借环境的力。

做法：同一个提问跑两次——一次干净环境，一次带上典型的 CLAUDE.md。

五、和别的规则冲突时谁赢

存在描述相近的规则时，哪个被选中？区分度够不够？

做法：故意装上“竞争者”，跑一个两边都可能命中的提问，看分布。

三次成功是结果，一次成功是噪声

把「模型」和「维度」画成一张二维网格，每格独立跑 3–5 次看分布，而不是跑一次看结果。

看起来啰嗦，但这是唯一能把「规则对」和「碰巧对」分开的方式。

实际工作里的简化版

上面那套是完整方法。日常没必要每次都做全套，但有三条是底线：

一、换个空目录测。 一行命令的事，一次性排掉「当前目录 + 自动记忆」两大污染源。

二、埋一个可搜索的标记。 让「有没有照做」变成一个能用 grep 回答的问题，而不是你读完输出的主观感觉。

三、跑三次，不是一次。 如果三次里有一次不对，那不是“偶尔的意外”，是你的规则本来就不稳定，只是你运气好。

一句话

「在我这儿能跑」几乎从来不是规则本身的功劳，而是模型、目录、历史上下文的某个特定组合恰好成立。

换台电脑、换个模型、换个项目，它就不成立了——而那时候你已经把它当成可靠的东西在用了。