最近两拨声音同时在冒：一拨说某些项目的 CLAUDE.md 又涨回三百行了，另一拨干脆主张把这文件删了。听着对立，其实是同一个抱怨的两头——一头嫌没地方放，一头嫌放不下。把这两拨读成"大家写文档的纪律不行"，是最省事也最没用的读法；把镜头拉远一点看，这从来不是纪律问题。
有人扫了 28,721 个真实仓库，统计出一个数字：指令文件的中位数大约五十条，其中只有十二条算得上真正的指令，剩下的全是模型每轮还得跟着读一遍的脚手架。七成多是脚手架，值得停一秒。它说明的不是写的人懒，是这个配置面在很长一段时间里只有一个格子——根目录一个文件，或者按文件夹嵌套一层，所有想说的话都得往里塞。任何只有一个格子的配置面最后都会长成这样：Makefile、.bashrc、nginx 的主配置、几年前那批越来越离谱的 Neovim 配置，一个都没跑掉。没有加载条件，就没有东西会主动离开。
这个类比得先打个补丁。构建系统里配错了会当场报错，一个 target 依赖到错误的文件，make 立刻停下；上下文不是这么运转的——一条不该出现的规则被加载进来，不会有任何报错，你只是在这一回合拿到一个略微更差的答案，而且大概率不知道原因。所以配置管理史能给的只有修法的形状（给规则加加载条件，再配一个能打印实际展开结果的东西，nginx -T 那一类），给不了验证方法。这点后面还得回来。
按三层棋盘摆一下：模型层负责推理本身；壳层负责把裸模型包装成能用的工作流；场景层是开发者每天真实打交道、习惯被锁住的地方。指令文件、按路径的作用域配置、技能、hook，都属于壳层自己的配置面，而这个配置面正在长出运行时的特征——规则带加载条件；内容先躺在每日日志里，跨过几个会话证明自己确实相关，才被提升成常开；不再值得注意的再降回可检索状态。这是缓存层级那套东西，有缓存就得有淘汰策略，有淘汰策略就得有理由。评论里有人提得很准：一年后被静默降级回去的那条规则，对发现它的人只像一堆杂物，所以每条被提升的规则旁边最好留一行当初为什么升它。
这里先认个错。按文件夹摆放规则这套玩法，我此前归进了壳层的"组织能力"，判断是"这只是工作流整合，不构成新护城河"。格子放错了。规则摆在哪、什么时候进场、目录怎么分，是壳层少有的自己能说了算、又能被真实使用习惯沉淀下来的东西，用"组织能力"去概括太轻，它更像是壳层给自己修的一套路由。分错格子的代价是连带的，那次我连"这类工具能不能留住人"的方向都判得偏保守。
但"路由"这个词一旦用出来，就得承认它有一条甩不掉的边界。有人观察得很到位：文件拆成前后端两层之后，问题解决了大约六成，剩下四成是那些不属于任何单一文件夹的跨切内容，编辑后端认证代码时把前端规则一起拉进来，输出就明显变差。另一位说得更狠：路径作用域回答的是"代理在哪里"，可很多重要规则回答的是"代理接下来要做什么"——写迁移的时候该加载迁移规则，跟迁移文件躺在哪个目录里没关系，所以他主张按动作类型触发，而不是只看路径。
这条线我认可，而且它指向的东西比那篇文章本身更有意思。层级（文件夹、路径）天然擅长处理"有家可归"的那六成；没家可归的四成要的是语义匹配，而语义匹配恰好是模型层的主场。所以推演得分层来：壳层吃掉有归属的规则，模型层慢慢吃掉跨切的规则——不是模型厂商伸手抢过去的，是这类规则的形状本来就长在语义检索那一边。中间那个"按动作类型触发"，只是过渡形态。
至于加载多少，作者和一位长期维护代理工作区的人对不上。对方说自己核心上下文的上限大约 6k token，超过去指令遵循就明显退化；作者回的是这让他意外，在他的经验里结构良好的起始上下文能到 70k 到 90k 还不明显掉，遵守度反而更好，关键看这段上下文是为什么造的。这个分歧现在没法调和，我也不认为该急着调和。它实际上承认了一件事：多少 token 算多，不是常数，是结构形状和用途的函数。这跟参数榜单那套的失效是同一个机制，规格表上的数字只有在没有结构差异时才可比——一个平铺的 6k 和一个分了三层、带加载路径的 90k，不是同一个量纲。
真正没解决、也更值钱的是另一端：规则老老实实加载了，代理没照做。文章自己承认了这一点。反馈里有人提的方案是这堆材料里最像样的一段：每回合记一份 context manifest，写明来源路径或技能、为什么进来、版本或哈希、token 估算，挂到工具调用或动作的 trace 上；再配一个 canary matrix，把"应该加载""不应该加载""跨边界检索"三类任务分开测；如果检索发生在任务中途，就把当时的规则集冻结并记录，或者在风险编辑之前强制重新验证；指标别只看省了多少 token，要看受控任务下的遵循率和返工率。那个免费的读文件工具能看你规则体系的形状、哪些还在加载、哪些在打架，但它明确说了不碰运行中的代理，差距就在这。
企业采购不买"少花了多少 token"，买的是出事之后能不能说清楚代理当时手上有哪些规则、它们有没有被遵守——这是审计和合规的活儿，采购预算里本来就有一块留给它，切换成本也就落在这一层。而"指令文件该怎么写"会很快商品化：三个加载维度、技能怎么打包、根文件指向技能，一两个季度内变成常识，没人会为常识付钱。更要紧的是，加载策略本身不证明被加载的规则充分，更不证明它们被遵守。
分野推演三条路径，各自带前提。A，各家把加载路径和触发条件做成自己的一套格式，各自长出一套能打印实际展开结果的工具链；团队一旦把自己的路由决策沉淀进去，迁移就不再是复制文本，而是重写路由，切换成本陡增，模型在下面变得可换，壳层变厚。B，路由层重新收敛出一套跨厂商的约定，就像根文件那一层已经发生过的那样；那样配置面保持可移植，护城河退回观测层，乃至于被模型层顺手吃掉。C，模型厂商把整套东西收上去，做成模型侧的自动检索，手写的路由像手写分词器一样进博物馆。
我压 A，把 C 当尾部风险。前提是模型能力继续拉平，模型本身不再是把人留住的那一层——这个前提到现在还在成立。证伪条件摊在这：如果接下来两个季度内真出现一套跨厂商的加载路径和触发声明规范，Cursor、Claude 再加一家同时支持，那 A 就该当场扔掉，价值会全部退回观测层，谁能让企业说清楚"当时手上有什么、照做了没有"，谁就站在下一层地基上。