一份两千字的规矩文件挂在常驻位上，跟你每次提问前先把它朗诵一遍，效果是一样的。
区别只在于朗诵不要钱。
这是《省 token 故事》系列里最不需要测量的一篇。前几篇讲的省法都得先测一测才知道值不值，这一篇不用。该按需加载的东西被放进了常驻位，那就是确定在浪费，浪费多少也能直接列出来，不用估。
麻烦的地方在于，常驻位比大多数人以为的要宽。
清单有五处入口
以 Claude Code 为例。别家的同族文件（Cursor 的 rules、各种 AGENTS.md）机制一样，具体限额各家没公布，我不替它们编。
规矩文件是一条链。 从工作目录往上，每一层的 CLAUDE.md 和 CLAUDE.local.md 都会全文加载，再加上用户级那一份。在子目录里干活的时候，上面几层的规矩跟着一起进来。仓库越大、目录越深，这条链越长，而它长在哪儿你平时看不见。
@路径 导入的文件在启动时展开。 官方文档里写得很直白，拆成 import 只帮你组织文件。文件拆开之后你自己看着清楚了，上下文那边一个字都没少。这一条最容易骗到人，我见过把一份长文件拆成六个 import、然后觉得瘦身完成的。
.claude/rules/ 里没写 paths 的规则文件，启动时全进。 写了 paths 的那些才是按需，等模型碰到匹配的文件才加载。一个规则目录里混着两种文件，光看目录看不出哪些在收月租。
自动记忆每轮都进，但只读前 200 行（或前 25KB，取先到的那个）。超出的部分静静地不加载。这条有两面。一面是你为前 200 行每轮付钱，另一面是你以为写进去的东西可能根本没进来。
工具定义全量常驻。 这一项通常比想象的大。MCP 工具是个例外，默认只把工具名放进去，用到某个才加载它的完整定义。
skill 省不省，取决于命中率
顺着说一句按需加载这类能力，因为「用 skill 省 token」这个说法现在传得很广。
它的成本结构是两段：描述常驻，正文按需。平时进上下文的只有一行几十个字的描述，等模型判断这活跟它有关，才把整篇正文读进来。
所以省多少这件事，算法很朴素。一次会话为它付的钱，是那行描述的固定成本，加上正文长度乘以命中率。全写进常驻位的话，付的就是正文的全价。这两个数谁大谁小，落在命中率上。
天天触发的 skill，p 接近 1，期望成本比直接写进常驻配置还高一点点，多付的是那行描述。一个月触发一次的，p 约等于 0，成本就是那行描述，几乎可以忽略。
机制上成立，收益因人而异。谁给你一个固定的省钱百分比，你可以问他一句：你的命中率是多少。
真正确定的那一半在反方向——按需加载省下来的钱，是你没把它放进常驻位省下来的。
判据只有一句话
这条规矩，是每次开工都要用，还是碰到特定活儿才用？
前者留在常驻位，后者挪进按需加载。
判断标准是使用频率，跟重要不重要没关系，这两件事经常被混着谈。一条很重要但一个月用一次的规矩，放在常驻位上就是在替它交月租，而重要抵不掉月租。
先看单子，再减肥
这一篇的数不用估，能直接列。
Claude Code 里敲 /context，Memory files 那一栏就是实际加载的文件清单。用别家工具的，看一次请求的完整 system 段有多长。再不济，拿 token 计数接口把你那份常驻配置数一遍。
我自己那次列出来，占最大头的既不是规矩文件也不是记忆，是工具定义。这是我一次实测的结果，不是普遍规律，你那边的大头可能在别处，这恰好是要先看单子的理由。凭印象删，删掉的多半是你最近改过所以印象最深的那份，跟它有多贵没关系。
床叠得再整齐，你也只睡一张。
