CLAUDE.md 要分放三处，而不是塞进一个文件

CLAUDE.md 是什么

先说这个文件。使用 Claude Code 时，为了不必每次从头解释，你把「希望它知道的事」写进一个叫 CLAUDE.md 的 markdown 文件。每开一个新对话，它都会被自动一起读入。

通常写进去的是这些：这个项目是做什么的、用什么命令运行和测试、哪些库不要用、回答是否要用某种语言。

这里容易产生一个误解：以为这个文件像配置文件一样会被强制执行。并不是。CLAUDE.md 是与提示一起被读入的指令集合，被读到和被遵守是两回事。所以文件越长，规则之间越是互相抢位置，真正重要的指示反而被琐碎的指示埋掉。

本站此前的《怎样写出 Claude 真正会遵守的 CLAUDE.md》讲的就是这件事。那篇说的是一个文件怎么写，这篇说的是文件该放在哪。

三个位置 —— 放在哪里，决定管到哪里

推荐的布局分三层。文件名相同，位置不同，作用范围就不同。

三者都会被读入 —— 冲突时更具体的一方胜出

这三个文件不是二选一，凡是适用的都会被加载并合并。

所以规则之间确实会出现矛盾，此时最具体的文件胜出。文件夹里的 CLAUDE.md 压过项目根目录，项目根目录压过家目录。

这个顺序为什么自然，用公司制度来比就很清楚：有公司层面的规定、部门规定和团队规则，三者不一致时，照最近的那一层走。

重点不在于「存在优先级」，而在于只有把文件分开放，优先级才有可排的对象。全在一个文件里，连排序的轴都没有。

全塞进一个文件会坏在哪 —— 无声的冲突

这是这个反模式的核心。问题不在规则多，而在规则离开了自己的地盘。

举例来说，只在前端文件夹才需要的「不要写内联样式，用工具类」这条指令，被放在了项目根目录。那么你写数据清理脚本时，这句话也会跟过来。数据脚本里没有样式，看似不会有事，其实不然：无关的指令照样被读入，读入多少，就削掉多少其他指令的相对分量。

更糟的是真的互相矛盾的时候。根目录写着「所有函数都要显式标注类型」，而某个文件夹刻意依赖自动推断，这两条每次都会撞上。

而且这种冲突不会以失败的形式浮现。构建不会挂，也不会有警告，只会表现为结果微妙地偏掉，而哪一行跟哪一行打架，任何地方都没有记录。所以它会一直持续。

哪些行该搬到哪 —— 一个判定问题

真要整理时，每条规则只问一个问题就够了：「这条规则适用于本仓库的所有文件夹吗？」

适用就留着。不适用，就搬到它真正生效的那个文件夹的 CLAUDE.md 里。没有就新建一个，文件名在哪儿都是 CLAUDE.md。

还可以再往上问一层：「这条规则适用的是我的所有工作，而不只是这个项目吗？」如果是，就提升到家目录。回答语言、提交信息习惯之类属于这里。

关键是搬，而不是删。这不是主张少写规则，而是主张别让它们在不该被读到的地方被读到。

~/.claude/CLAUDE.md          # 适用于所有项目

my-project/
├── CLAUDE.md                # 适用于整个仓库
├── src/
│   ├── api/
│   │   └── CLAUDE.md        # 仅在 api/ 中工作时
│   └── web/
│       └── CLAUDE.md        # 仅在 web/ 中工作时
└── scripts/

今天可以试的一件事

打开你的 CLAUDE.md，从上往下逐行读，问一句「这条规则适用于整个仓库吗」。如果文件超过二十行，一定会有三四行回答是否定的。

把那几行剪下来，贴进对应文件夹的 CLAUDE.md。文件不存在就新建。今天要做的就这些。

效果从下一次对话开始显现。无关的指令不再被拖进不相干的工作，而你真正希望被遵守的规则，相对地被读得更响。

下一篇是第三个反模式：一个智能体最多能挂多少个工具。