规则生效性的验证方法

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

这个判断多半站不住。

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

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

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

它们不是彼此独立的：

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

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

污染从哪里进来

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

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

一份规则至少要测五件事

「跑通了」是个含糊的说法。拆开至少有五个独立维度：

① 该触发的时候触发了吗

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

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

② 触发之后照做了吗

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

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

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

③ 换个模型还成立吗

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

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

④ 换个环境还成立吗

有没有 CLAUDE.md，行为漂移大不大？

漂移大说明你的规则不够稳健，是在借环境的力。

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

⑤ 和别的规则冲突时谁赢

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

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

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

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

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

日常的简化版

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

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

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

③ 跑三次，不是一次。 三次里有一次不对，那不是「偶尔的意外」——是你的规则本来就不稳定，只是你运气好。

一个能帮你的工具

写完规则之后跑一次：

/doctor

它会检查配置文件有没有写错、有哪些技能装了从来没被调用过、有没有慢钩子，并会建议精简过长的 CLAUDE.md。

「从来没被调用过」这一条特别有用。 它常常说明的不是「用不上」，而是描述写得不对，触发不了。

一句话

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

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

本节为 HiBridge 整理的验证方法，非官方文档内容。 其中涉及的自动记忆存放位置、CLAUDE.md 叠加规则与 /doctor 的能力依据官方 How Claude remembers your project 与 Commands，查证日期 2026-08-05。