在项目中使用 Claude Code 时，通常会产生两个需求：“这条规则每次都要遵守”和“记住上次发现的内容”。
前者由规则文件 CLAUDE.md 负责，后者由记忆功能负责。两者都是“会在会话结束后保留的指令”，因此容易混淆，但管理主体和性质并不相同。
本文将梳理 CLAUDE.md 的层级结构、记忆功能的工作方式，以及判断内容应放在哪里的标准。
先来看核心总结。
- CLAUDE.md 是每个会话都会自动加载的规则文件，分为全局和项目级别。
- 记忆功能会让 Claude 将工作中了解到的事实自行记录并从各项目专属文件夹中取回。
- 人制定的规则放在 CLAUDE.md，代理积累的经验放在记忆中。
- 两者都会消耗上下文，因此应根据“是否始终需要”保持精简。
CLAUDE.md：位置决定适用范围
CLAUDE.md 是会话开始时完整加载到提示词中的 Markdown 文件，用于记录编码规范、禁止事项和项目背景等“必须始终成立的规则”。
即使文件名相同，所在位置不同，适用范围也不同。
| 位置 | 范围 | 共享 |
|---|---|---|
| ~/.claude/CLAUDE.md | 所有项目 | 仅限个人 |
| project/CLAUDE.md | 该项目 | 通过 Git 与团队共享 |
| subfolder/CLAUDE.md | 在该文件夹中工作时 | 通过 Git 与团队共享 |
全局文件用于记录与项目无关的个人偏好，例如提交风格和回复语言；项目文件用于记录仓库特有的规则。如果两个层级发生冲突，明确指定更具体的项目规则优先，通常是最安全的做法。
文件变长后，可以使用 @경로/파일.md 格式导入其他文档进行拆分。不过，导入的文档同样会进入上下文，因此它是为了便于管理，而不是为了节省篇幅。
记忆：代理自行编写的笔记
如果说 CLAUDE.md 是人编写的自上而下的规则，那么记忆的方向正好相反。Claude 会把工作中了解到的事实以文件形式记录在项目专属的记忆文件夹中，并在下一次会话中再次取出使用。
结构很简单：一条记忆对应一个文件，索引文件 MEMORY.md 中会累积一行摘要。会话开始时只有索引进入上下文，单条记忆的正文则会在执行相关任务时读取。
记录内容的性质也不同于规则。例如：“这个 DB 在批处理后需要进行类型检查”或“必须在这个工作树中启动 dev 服务器，改动才会生效”。这些事实无法从文档直接得知，只有亲自经历后才会明白，是人在将其正式写成规则之前积累的经验知识。
在对话中，也可以发送以 # 开头的消息，直接指示“记住这件事”。此时 Claude 可能会询问保存到哪个文件，也可能自动分类。
判断应该放在哪里的标准
当两者的职责看起来有所重叠时，可以通过三个问题来判断。
第一，谁决定了这件事？团队或你本人制定的规则放在 CLAUDE.md，工作中发现的事实放在记忆中。
第二，违反后会产生问题吗？禁止提交密钥、部署流程等一旦违反就会导致事故的规则，必须放在 CLAUDE.md 中。因为记忆更像参考笔记，而不是能保证召回的强制机制。
第三，是否已经能从代码或文档中得知？原则上，只要阅读仓库就能知道的内容，就不要放在任何一方。它只会浪费上下文，代码变化后还会变成错误信息。
运营时需要遵守的两件事
第一，定期清理。CLAUDE.md 往往只会不断积累规则，却不会主动删除。发现已经失效的规则或一次性指令后，应立即删除，避免每个会话浪费上下文。记忆也是如此：代码变化后已经不再成立的条目，删除比保留更好。
第二，规则要简短而明确。“尽可能最好做 X”之类的句子不如“执行 X”“禁止 X”这样的短句容易遵守。加上一行示例，遵守率会明显提高。
总结
CLAUDE.md 是宪法，记忆是工作日志。人制定的不变规则自上而下传递，现场获得的经验则自下而上积累。
开始区分管理两者后，既能减少每个会话重复相同说明，也能避免再次经历上个会话踩过的坑。