03 · 怎么记住你的习惯

上一篇我们聊了上下文——一张很大但会清空的桌子。翔宇当时的第一个念头是：那每次启动 Claude Code，它岂不是什么都不记得？翻文档发现 Anthropic 给的方案比想象中精妙——两套记忆并行，一套你写、一套它写，把每天都是第一天这个问题彻底解决了。——翔宇

1. 一个新员工的麻烦

假设你雇了一个超级聪明的助手。什么都会，反应飞快，解决问题一流。

但他每天早上来上班，不记得昨天发生过什么。

你得重新告诉他：项目用的是 Next.js，数据库是 PostgreSQL，代码风格遵循这套规范，构建命令是 pnpm build，部署走 Vercel，CI 在 GitHub Actions 里……

第一天你觉得还行。第二天开始烦了。第三天你想辞退他。

这就是上一篇结尾提到的问题：上下文窗口是一次性的，会话结束就清空。如果 Claude Code 只有上下文，每次启动它对你的项目一无所知——你得反复解释技术栈、构建命令、代码规范、架构决策……这些解释本身还要占上下文空间，挤掉了本来可以用来做正事的位置。

换个设定：同样这个助手，但桌上放着一本你写好的手册——《新员工必读》。每天来上班先翻一遍，五分钟后进入状态。你再也不需要重复解释任何事。

这本手册就是 Claude Code 的 CLAUDE.md。

2. 一份手册，先解决最痛的问题

CLAUDE.md 是一个普通的 Markdown 文件，任何文本编辑器都能打开。

每次 Claude Code 启动，它做的第一件事就是读这个文件。读完之后，文件内容变成这次会话的背景信息——Claude 回答你的每个问题时，都知道手册里写的东西。

那应该写什么？想象你给一个聪明但对你的项目一无所知的新同事写一份备忘录。你不会写公司全部历史，不会贴 500 行源代码，不会把所有制度从头抄一遍。你只会写他上班第一天最需要知道的那些事。

具体三类：

• 这是什么（WHAT）：项目一句话介绍、技术栈、核心目录结构
• 为什么这样设计（WHY）：关键架构决策（如选 Next.js 因为需要 SSR）—— 这类信息 Claude 从代码里看不出来，必须你告诉它
• 怎么操作（HOW）：构建命令、测试命令、部署流程

3. 一份手册不够：4 层 scope

如果记忆只有一个 CLAUDE.md，你很快会碰到一个具体的麻烦：个人偏好和项目规范混在一起。

你喜欢中文回复——这是个人偏好，跟项目无关。 项目用 TypeScript——这是项目规范，跟你个人无关。

在多个项目之间切换时，个人偏好每个项目都要写一遍？团队多个人时，每人偏好都要写进项目 CLAUDE.md？

显然得分层。Anthropic 的方案是 4 层 scope，按位置自动判断属于哪一层：

每一层各管各的，按官方加载顺序拼起来：

sequenceDiagram
    participant CWD as 你的工作目录
    participant Claude as Claude Code 启动
    participant Ctx as 上下文窗口

    Claude->>CWD: 从项目根往上一路走
    CWD-->>Claude: 找到所有 CLAUDE.md / CLAUDE.local.md
    Claude->>Ctx: ① Managed policy（系统级）注入
    Claude->>Ctx: ② Project（项目根 ./CLAUDE.md）注入
    Claude->>Ctx: ③ User（~/.claude/CLAUDE.md）注入
    Claude->>Ctx: ④ Local（./CLAUDE.local.md）注入
    Note over Ctx: 离工作目录越近的越晚注入<br/>越容易影响最终行为
    Claude->>Ctx: 也加载 MEMORY.md 前 200 行
    Note over Ctx: Auto Memory 索引（详见 §5）

加载机制底层：Claude Code 从工作目录往上逐层查找 CLAUDE.md，全部拼接注入上下文（不是覆盖）。同目录下 CLAUDE.local.md 接在 CLAUDE.md 之后。子目录的 CLAUDE.md 只在 Claude 实际读取那个目录下的文件时按需加载。详见官方加载顺序文档。

日常使用中，你只需要关注两个文件：

• ~/.claude/CLAUDE.md —— 你的个人偏好（跨项目）
• 项目根/CLAUDE.md —— 项目规范（团队共享，进 git）

到这里手册系统已经很完整了。但还有一类信息，手册装不下。

4. AI 还得自己记笔记

CLAUDE.md 解决了一个问题：你把规则写下来，Claude 每次启动都看得见。

但工作中还有一些东西不太适合写进正式手册。

比如你纠正了 Claude 一次：测试不要 mock 数据库，用真实数据库。这条信息很有价值——下次写测试时应该记住。但它不是项目规范，不太适合写进 CLAUDE.md（团队 review 时也奇怪）。

再比如 Claude 在帮你调试时发现，某类错误的根因总是缓存没清。这是经验教训，对未来有用，但你不会主动写进手册。

这就是 Auto Memory 的角色。

通俗讲：CLAUDE.md 是你写的员工手册，Auto Memory 是员工自己带的工作笔记本。手册写公司规章，笔记本记工作中积累的经验教训。你不需要告诉它什么时候该记——它自己判断。

Auto Memory 是 Claude Code 自己维护的项目笔记系统（v2.1.59+ 默认开启）。你什么都不用做——Claude 在对话中自动识别哪些信息值得记住，分类存到持久文件里。下次启动新会话时，这些笔记自动可用。

存放位置：

<项目标识> 由 Claude Code 根据 git 仓库自动推导——同一个仓库的不同 worktree、子目录共享同一份 Auto Memory。Auto Memory 机器本地（不跨机同步）。

5. 怎么判断什么放哪？

现在两套系统都清楚了。判断标准很简单——这条信息是规则还是经验？还是Claude 直接看代码就能知道？

6. 完整的画面

把前面所有内容串起来，Claude Code 启动时的信息架构是这样的：

7. 排障：Claude 不听 CLAUDE.md 怎么办

CLAUDE.md 是上下文不是强制配置。Claude 会读它、尝试遵守，但不保证严格服从——尤其是模糊或冲突的指令。

8. 检验你真懂了吗

费曼说，检验你是不是真的理解一件事，试试能不能解释给朋友听。

接下来去哪

不用按顺序全读。挑你最好奇的那条线走就行。