往 CLAUDE.md 里追加一行规矩，这个动作我一天要做三四次。
看到 agent 把 migration 命名错了，加一行。看到它忘了我们不用 default export，再加一行。三个月攒到一百八十多行，我还挺得意，觉得自己调教有方。
上周翻到 Giulio D'Erme 那个实验，第一反应不是信不信，是后背发凉。
他跑了 72 组配对，三配置对照：什么都不给的纯净 Claude Code、带一份静态项目 CLAUDE.md 的、再加一层记忆的。结果里有这么一条——静态那份 36.1%，纯净那份 50.0%。
低了 13.9 个百分点。一个专门用来教 agent 项目规矩的文件，比不教还差。
我不打算替这个数字背书。一个作者、一个模型、二十四个任务，够不上定论。我看完只干了一件事：打开自己那份，从头读到尾。毛病一模一样。
病根不是内容写错了，是这份文件没有失效机制。
上个月我把 migration 的命名从 {date}_{slug} 改成 {seq}_{slug}，CLAUDE.md 第一屏还写着旧的。Agent 很听话，照着旧的做，我改回来，它道个歉，下一次继续照旧的做。
我加进去的每一行，写下那一刻都是对的。问题是它永远不消失。加一行是零成本的，删一行的成本是"我得想起来它还在那儿"。所以它只会涨。
报告评论区里有人建议把检索失败拆成四类，作者回了一句：被标成过期的那些文档，有 45% 的会话压根没被翻出来过。
一半的时候那条规矩等于没写，agent 自己编了个差不多的。我手动改回去的那些 rename，多半就是这么来的。
改法很简单——把这份文件当索引写，别当知识库。
## 迁移文件命名
规则见 docs/migrations.md（最后核对 2026-08-12）
## 构建
pnpm build:web（2026-08-30 核对）
规则住在它该住的地方，挨着代码，改代码的时候顺手就改了。CLAUDE.md 里只留一个指针，加一行"最后一次核对"的日期。
⚡ 真正起作用的是"别在这儿写第二份"这一句。一条规则只剩一个副本的时候，它就没法跟我对峙了。
再狠一点的：给每节挂上日期，超过两个月没核对过的直接删。删不掉的说明它其实是文档，那它就不该待在这个文件里。
一百八十行削到四十一行。这周用下来，被 agent 命名错、然后我手动改回去的次数，原来一天一次，现在两三天碰上一回。没归零，但那种"又来了"的烦躁少了很多——省下来的不只是那两三分钟，是不被打断。
有件事得老实交代。
作者回复那条评论的时候说，这 13.9 个点里，"内容错"和"上下文太长"两个因素混在一起，他自己也分不开。有人提议再加一个长度匹配的安慰剂臂来区分，他认了，说新对照臂已经加进去了。
那我这份文件从一百八变成四十一行之后变好，有一部分功劳可能压根不是"内容更新了"，纯粹是它变短了。上下文这东西是有配额的，你塞得越多，每一条分到的注意力越少，哪怕每一条都写得对。我这次到底是哪种，说不清，可能两个都有。
那要不要干脆上记忆层？报告里那套叫 RE-call，效果是有的。但成本那一栏我特意多看了两眼：带记忆那份烧掉的 token 差不多是静态提示那份的四倍。换成钱三毛左右，不贵。
我在意的不是钱，是这件事的结构。记忆层的开销按会话摊，每开一次新会话就要检索一遍；删文件是免费的、一次性的，删完永久生效。
所以顺序应该反过来：先把文件删到不能再删，等真出现了"这条我不敢删、可它又老是过时"的地方，再考虑加东西。
删是免费的，加是续费的！
这招也有不灵的时候。团队共用一份 CLAUDE.md，你想删得先说服所有人，删了别人也不知道。那种情况我倾向于不删，但每一节必须挂 owner 和核对日期，过期了在 CI 里冒一条提示出来。这条我还没落地，只在脑子里转过，等真在团队里试过再写。
削这一遍花了我二十分钟，大头是读那一百八十行、一条条回忆"这个还算数吗"。按现在这个频率，一周多回本。
要是你那份 CLAUDE.md 也是从别人仓库里抄来的，给个更省事的版本：先整个删掉，跑三天，看哪些坑真的又踩了，再把那几条加回去。要加回来的，多半比你以为的少。
别处也这么悄悄烂着的地方——各种 agent 的 rules 文件、Cursor 那套 .cursorrules——你要有更快的删法，教教我。