上篇开篇文章里打过一个比方：CLAUDE.md 相当于新员工的入职手册。这一篇就把这本手册拆开来讲——它到底被谁在什么时候读、写多长合适、为什么你明明写了"必须遵守"它还是装没看见，以及现在 AI 是怎么开始自己记笔记的。
先从一个所有人都熟悉的场景开始。
"再说一遍，我们用的是 pnpm"
你让 Claude Code 装个依赖，它熟练地敲下 npm install。你提醒：我们项目用的是 pnpm。它道歉，改过来。第二天，新会话，它又是一句 npm install。
你没法生气——它是真不记得。对它来说，每一次新对话都是第一天上班，之前所有沟通一张纸都没留下。重复得多了，你甚至会有种错觉：这 AI 是故意的。
解法其实早就有，就是那个一直躺在项目根目录、你可能从没认真写过的 CLAUDE.md。但多数人对它只有两种态度：要么空着，要么往死里堆——堆到几千行，再回头抱怨 AI 不看。
想写好它，得先想通一件事：AI 的记性不是一个筐，而是分层的。
AI 的记性，其实是分层的
Claude Code 的记忆系统不是一个文件，而是一套各管一段的层级结构。从大到小画出来是这样：
从上往下，每一层管的事不一样：
- 全局层
~/.claude/CLAUDE.md——写你个人的习惯偏好，比如"回复用中文""commit 信息用英文"。放在这里，你机器上所有项目、所有会话都生效。 - 项目层
CLAUDE.md——项目根目录的这份是主角。团队共享，提交进 git，写项目本身的规矩：用什么包管理器、测试怎么跑、目录怎么组织。 - 个人层
CLAUDE.local.md——只属于你的那份项目笔记，不进 git，记得加 .gitignore。 - 子目录层
frontend/CLAUDE.md——大项目里给每个模块配的小手册。它有个特点：平时不加载，碰到才加载（下面细说）。 - 规则抽屉
.claude/rules/*.md——把指令拆成一个个主题文件，像抽屉一样分类存放，还支持"碰到某类文件才加载"。 - AI 自己的笔记 agent memory——最新的变化：Claude Code 从 v2.1.33 开始，允许子代理拥有自己的持久记忆，它会在干活中自己记、自己翻。
分层的意义在哪？在于不同范围的信息放在不同层，互不打架。你的个人偏好不该污染同事的项目配置，项目的规矩也不该跟着你跑到别的项目里去。就像真实的公司：员工手册归员工手册，部门规范归部门规范，个人笔记本归你自己。
写它的正确姿势：当成交接文档，不是百科全书
确定了放哪层，下一个问题是写什么。
Claude Code 的作者 Boris Cherny 给过一个很具体的数字：CLAUDE.md 每个文件控制在 200 行以内。HumanLayer 的工程师更狠，他们建议 60 行。两个数字差得不小，方向却一致——文件的带宽是有限的，塞得越满，每条指令的权重就越低。
那什么才配占这 200 行？HumanLayer 的 Dex Horthy 给了一个特别朴素的检验标准：
任何一个新同事，打开 Claude Code 说一句"run the tests"，第一次就能跑通——如果你的项目做不到，说明 CLAUDE.md 里缺了最要命的东西。
反过来说，最该写进去的就是这类"不做就转不动"的信息：构建和测试命令、代码风格的硬约定、目录结构的导览、以及那些一脚就踩进去的坑。
一个容易被忽略的点：那些一次性的任务说明不该进来。"本周三之前把登录页改版"——这种话写在 CLAUDE.md 里，三个月后它会变成污染上下文的陈年旧账。交接文档写的是"这个团队长期怎么做事"，不是"这周要干嘛"。
写了它为什么还是不听话？
这可能是 CLAUDE.md 相关的最高频抱怨。Reddit 上有个经典帖子，标题大意是"我 CLAUDE.md 里写了 MUST，它 80% 的时候装没看见"。
要理解这件事，要回到上篇讲的那个模型：CLAUDE.md 只是模型推理时看到的一大摞上下文中的一小条。指令一多，注意力就被摊薄了——不是它叛逆，是你的声音在人群里不够大。几个被验证有效的对策：
第一，能自动化的规矩别写成文字。 "永远不要在 commit 里加 Co-Authored-By"这种话写在 CLAUDE.md 里是「建议」；在 settings.json 里配 attribution.commit: "" 是「制度」。前者的执行依赖模型每次都想起来，后者是程序保证的。社区里 davila7 把这个原则总结得很准：harness 能强制的事，就别劳烦提示词。
第二，长文档里给关键指令加"聚光灯"。 HumanLayer 还贡献了一个小技巧：在变长的 CLAUDE.md 里，用 <important if="..."> 标签把领域相关的指令圈起来，比如 <important if="正在修改支付模块">。它相当于告诉模型：这条规则不是背景音，是特定场景下的高优先级指令。
第三，接受它有覆盖不了的时候。 200 行是权重和覆盖面的平衡点，不是银弹。真有一堆无法精简的规矩，出路不是把一个文件撑爆，而是拆——这就要说到 rules 和多层级结构了。
大项目怎么管：一层管不住就多几层
如果你维护的是一个 monorepo——前端、后端、API 都在一个仓库里——把所有规矩写进根目录一个 CLAUDE.md，很快就会撞上 200 行红线。
Claude Code 的解法是多级文件，配合一套很聪明的加载时机：
- 祖先层，启动即加载。 你在哪个目录启动 Claude Code，从那里往上走到仓库根，沿途所有 CLAUDE.md 立刻生效。
- 后代层，碰到才加载。 子目录里的 CLAUDE.md 启动时不加载。当 Claude 在干活中读到
frontend/下面的文件时，frontend/CLAUDE.md才会被拉进来。官方管这个叫懒加载（lazy loading）。 - 兄弟层，永不加载。 你在 frontend 干活时，backend 和 api 的手册永远不会进来。
这套机制的价值，站在上下文的角度就明白了：monorepo 里各模块的指令加起来可能几十万字符，如果全部在启动时塞进上下文，绝大多数都是当下用不上的噪音。懒加载让"什么时候需要什么知识"变成自动的——你不用做任何配置，按目录结构放好文件就行。
.claude/rules：给说明书装个抽屉柜
多级 CLAUDE.md 解决的是"按目录分"，还有一个正交的问题：同一个目录下，指令怎么按主题分？
这就是 .claude/rules/ 的用处。把指令拆成一个个主题文件——code-style.md、testing.md、api-conventions.md——它们默认和 CLAUDE.md 一样每次自动加载。真正好用的是给文件加上 paths 声明：
---
paths:
- "src/api/**"
---
涉及 API 改动时：所有接口返回统一用 { code, data, message } 结构……
加了 paths 之后，这份规则只在 Claude 碰到匹配路径的文件时才加载。效果和子目录 CLAUDE.md 的懒加载一样，但组织维度从"目录"变成了"主题"，两者可以叠加使用。
给新手的建议是循序渐进：先老老实实写好一份 200 行以内的 CLAUDE.md，等它真的装不下了，再拆 rules。一上来就搭一套精细的规则体系，维护成本会先于收益到来。
现在，AI 开始自己记笔记了
前面讲的都是"你写给 AI 看"。2026 年 2 月的 v2.1.33 版本加了个新东西，方向反过来：AI 自己写给自己看。
在子代理定义里加一个 memory 字段，它就有了自己的持久记忆目录。工作流程是这样：启动时它先读自己的 MEMORY.md（前 200 行注入），干活途中随时读写，遇到MEMORY.md 装不下的细节，就自己归档成主题文件。用社区里流行的说法，你得在提示词里叮嘱它一句：“开工前先翻笔记，收工后把学到的记回去。”
存储位置也分三档，和配置文件的层级完全同构：user 存在用户目录下跨项目通用（推荐默认），project 进 git 团队共享，local 本地私有。
拿一个代码审查代理来说：没有记忆时，它每次审查都是从零开始的通才；有了记忆，它会记住”这个仓库的 PR 常漏空值检查”、“作者 X 的代码要重点看边界条件”——审得越多，越懂这个仓库的脾气。
收工前，过一遍这份清单
把这篇的内容压缩成 8 条，动手写或改 CLAUDE.md 时逐条对照：
- 写之前先问：这条信息是"长期有效"的吗？一次性的任务说明，放计划文档里去
- 目标 200 行以内；做不到就说明该拆了，不是该删了
- 构建、测试、lint 命令必须写——用"新人一句 run the tests 能跑通"来验收
- 团队共享的进根目录 CLAUDE.md，个人偏好进
~/.claude/CLAUDE.md，私密配置进CLAUDE.local.md并加 gitignore - 能在 settings.json 里配置的行为，别用文字写（比如 commit 归属、权限规则）
- 长文档里，场景相关的关键指令用
<important if="...">圈出来 - monorepo 按目录拆多级 CLAUDE.md，模块特有指令放模块里，别全堆在根上
- 装不下的时候优先拆
.claude/rules/，需要按文件路径触发加载的就加paths
最后留一个诚实提醒：这 8 条能解决八成问题，但「AI 为什么忽略指令」至今还是社区里的开放问题——连 Claude Code 团队自己也没给出百分百的答案。记忆系统是这个工具迭代最快的部分之一，写这篇文章时依据的是 v2.1.278 前后的状态，等你读到时某些细节可能又变了。骨架大概率不变，细节以官方文档为准。
下一篇，我们回答一个更基础的选择题：Subagents、Commands、Skills 这三样东西名字看着都差不多，到底什么时候该用哪个？