一个工程师的 CLAUDE.md，本质上是一份私人文档。它服务于一个人的仓库、一个人的代码风格，以及一个人对解释详略程度的偏好。它之所以有效，是因为唯一的读者就是写下它的那个人。
但同一个项目里一旦加入第二位工程师，这份文件的职责就变了 —— 而大多数团队往往几个月后才意识到。到第 5 位工程师时，它已经开始反向误导模型；到第 10 位工程师时，它通常已经变成一层没人敢删的规则化石。
这篇文章写给已经从“团队里有一个人在用 Claude”走到“大家都在用 Claude”的工程经理和技术负责人。下面是规模化之后常见的失效方式、我们最常看到的症状，以及四个能真正修复它的习惯。
规模化之后会坏在哪里
漂移
最先出现的是规则漂移。工程师 A 因为 Claude 反复给 React 组件文件起错名，于是加了一条规则。两周后，工程师 B 在同一个仓库里工作，却没有读到这条新规则，因为她已经在文件更靠上的位置写了自己版本的说明。两个人都不知道对方那条规则存在。三个月后，文件里已经有六条关于文件命名的提示，而且彼此冲突，模型只能从里面随机挑一条执行。
项目配置和个人配置混在一起
CLAUDE.md 可以存在于两个地方：用户的 home 目录（~/.claude/CLAUDE.md，全局生效），以及任意项目树里（<repo>/CLAUDE.md，只对该仓库生效）。一个人使用时通常不用思考这件事 —— 项目文件叠加个人文件，一切看起来都自然成立。
到了团队里，问题就不同了：项目文件会通过 git 共享，个人文件不会。于是，一个依赖个人规则的工程师，可能两周后才发现队友在“同样”的 session 里得到了完全不同的输出。修法并不复杂，但容易被忽略：所有团队共享的规则，都必须从个人配置里搬到仓库文件里。大多数团队从来没有做过这次审计。
静默的 token 税
大多数团队并不衡量每位工程师的 token 花销。真正量过的团队，几乎都会被结果吓到。一份臃肿的 CLAUDE.md —— 比如 1200 个词、里面塞了三个“示例”，模型还会在每次 prompt 时把它们带进上下文 —— 会悄悄把全队每个 session 的 token 成本抬高 30–60%。
8 个工程师，每人每天使用 $20 的 Claude Code，这就意味着每天额外 $40–$60 的纯开销，没有任何收益。文件看起来很全面，账单看起来也很正常，于是没人把两件事联系起来。
Session 里的纠正没人沉淀
Claude Code 的 session 里会不断积累临场纠正 —— “不要这样做”、“用 tab，不要用空格”、“复用现有 helper，不要再写一个新的”。一个人使用时，这些纠正最终往往会被写回文件。团队里则不同：纠正发生在各自的私人 session 里，跨多个仓库，最后很少回到共享文件。
于是模型一次次犯同样的错。第 5 位工程师发现后，又写了一条新规则；而第 1 位工程师最早做过的那次纠正，仍然埋在他的 session telemetry 里，没有被制度化。
四个修复习惯
下面这些做法并不新奇 —— 真正解决过这个问题的团队，最后都会收敛到差不多的几条。关键不在于它们是否原创，而在于什么时候启动。
1. 一个 owner，每月 review
指定一个人负责 CLAUDE.md，像负责关键配置文件一样负责它。这个人通常是团队里最重度使用 Claude Code 的资深 IC。每月 review 一次：从头到尾读完整个文件，并对每条规则问一句：“我会把这条告诉一个刚入职的新人吗？”如果答案是否定的，就删掉。
大多数团队第一次 review 时，文件长度会减少 30–40%。Claude 的输出也会明显变好，因为信噪比提高了。
2. 新人入职时审计个人配置
新工程师加入时，花 15 分钟检查他的 ~/.claude/CLAUDE.md。所有项目相关内容（文件命名、代码风格、仓库约定）都应该搬进项目文件；只有纯个人偏好（简洁程度、语言偏好、工具快捷方式）才应该留在个人配置里。
这是你能和新人进行的最高 ROI 对话之一，通常第一周就能回本。
3. 给 session 纠正一个“毕业”机制
在私人 session 里有效的纠正，必须有路径进入共享文件。最简单的机制是：每个工程师在纠正 Claude 某个可复现问题时，记下一行笔记，并在月度 review 时带过来。owner 决定哪些纠正应该“毕业”进文件。
这听起来像额外流程，但实际每人每月只需要 5 分钟，却能避免同一条纠正在团队里被重复输入 40 次。
4. 盯住一个预算数字
为每位工程师设定一个 Claude Code 月度预算，并持续观察。这个数字的意义更多在于捕捉回归，而不是控制绝对支出 —— 如果一周内上涨 30%，通常说明 CLAUDE.md 变胖了，或者有人在错误使用 sub-agent。
很多团队正是通过这种方式发现了静默 token 税，最后得到了一份更短、更有效的文件。
Codex / Cursor / Aider 团队怎么办
上面这些问题同样适用，只是文件名不同。Codex 读 AGENTS.md，Cursor 读 .cursor/rules/*.mdc，Aider 读 CONVENTIONS.md。错误模式一样，团队规模化后的失效方式一样，四个修复习惯也一样。
最难的是混合工具栈团队 —— 工程师同时使用两三个 agent —— 同一条规则需要出现在两三个文件里。在 agent 生态真正收敛到统一配置格式之前（目前还看不到迹象），最好的做法是保持共享文件足够短，从它生成其他文件，并像对待“代码的真理源”一样认真对待“规则的真理源”。
什么时候需要外部帮助
大多数团队一旦把问题命名清楚，就能自己修好。少数团队修不动，通常是因为：
- 代码库太大，没有任何一个工程师能掌握全貌，而
CLAUDE.md也反映了这种碎片化。 - 团队已经尝试修过两次但都失败了，大家对这份文件的信心很低。
- token 花销已经高到不能再用“下季度再说”来拖延。
如果你处在这种情况，外部 review 通常很有价值：新鲜视角、对当前文件没有政治负担，一般 90 分钟就能完成，并在几周内通过节省 token 成本回本。我在本站把这件事做成了 CLAUDE.md 审计 服务：$299 个人版，$799 适用于 2–10 人团队。每个档位的前三个名额免费，用作案例研究。
更难的是制度问题。世界上最好的文件，如果没人负责，也会腐烂。上面四个习惯比任何审计都便宜，也是在 80% 项目里我们最终会推荐的做法。先从那里开始。
配套阅读
- CLAUDE.md 中 5 个偷烧 token 的坏习惯 —— 解构具体哪些写法贵
- 如何写好 CLAUDE.md —— 文件工艺的同期指南
- AI 编程代理到底往你磁盘写了什么 —— 完整的目录地图
这篇对你有帮助吗?