用 Claude Code 久了以后，最影响体验的往往不是它代码写得好不好，而是另一个问题：

昨天刚跟你讲明白的项目规则，今天为什么又要重新解释？

比如一个项目里，你可能已经反复说过：

这是 Spring Boot 3 项目
统一使用 MyBatis Plus
集成测试前必须启动 Redis
不要写 SELECT *
改完代码必须跑对应测试

如果这些信息一直只存在聊天记录里，那新开会话以后确实可能丢掉。

Claude Code 解决这个问题，主要依靠三层东西：

CLAUDE.md
→ 长期规则

Auto Memory
→ Claude 工作过程中积累的经验

Context Window
→ 当前这次会话正在使用的信息

这三个东西看起来都叫“记忆”，底层其实完全不是一回事。

---

一、先说底层：Claude 并没有一个无限大的“脑子”

Claude Code 每次回答问题，本质上都是把当前能看到的信息装进一个 Context Window，也就是上下文窗口。

可以粗略理解成：

系统指令
+
CLAUDE.md
+
Auto Memory 中加载的记忆
+
当前读取的代码
+
终端输出
+
这次会话的聊天记录
        ↓
   Context Window
        ↓
      模型推理

所以 Context Window 更像程序运行时的内存。

今天正在改哪个接口、刚才出现什么报错、我们刚刚决定采用方案A还是方案B，这些信息主要活在当前上下文里。

它不是某个 context.md 文件，也不是永久存储。

这也是为什么一个会话聊得特别长以后，早期细节可能逐渐变得不那么突出。

真正需要跨会话长期保存的信息，应该落到磁盘上的记忆文件里。

---

二、CLAUDE.md：相当于项目的“入职手册”

如果一件事属于：

无论哪次会话，只要开发这个项目，都应该知道。

最适合放到 CLAUDE.md。

项目根目录可以这样放：

order-system/
├── CLAUDE.md
├── pom.xml
└── src/

也可以放：

order-system/
└── .claude/
    └── CLAUDE.md

这两个位置都是官方支持的项目级配置。Claude Code 会在会话中加载这些项目指令。

例如：

# 项目开发说明

这是一个订单交易系统。

## 技术栈

- Java 21
- Spring Boot 3
- MySQL 8
- Redis
- RocketMQ

## 开发约定

- Controller 不直接调用 Mapper
- SQL 禁止使用 SELECT *
- 修改业务代码后运行对应单元测试
- Redis Key 使用 `业务:模块:id` 格式

## 常用命令

- 测试：mvn test
- 启动：mvn spring-boot:run

第一次接手一个陌生项目，也没必要完全手写。

可以进入项目执行：

/init

Claude Code 会分析代码库，生成一个初始的 CLAUDE.md；如果文件已经存在，它会给出改进建议，而不是简单覆盖。

我比较喜欢把它理解成：

CLAUDE.md 不是聊天记录，而是给 Claude 的项目 README。

---

三、个人习惯不要全部塞进项目

假设你自己的习惯是：

解释代码时先讲原理
Java 优先构造器注入
修改完成后告诉我改了哪些文件
SQL 默认不要 SELECT *

这些并不属于某一个项目，而属于“你这个开发者”。

可以放到：

~/.claude/CLAUDE.md

它是用户级配置，会作用于你的不同项目。

所以可以这样记：

./CLAUDE.md
→ 这个项目有什么规矩


~/.claude/CLAUDE.md
→ 我这个人有什么习惯

如果只是某个项目里的个人设置，而且不希望提交 Git，还可以使用：

./CLAUDE.local.md

例如：

# 我的本地开发习惯

- 本地数据库使用 localhost:3307
- 调试订单时优先使用用户 10001
- 不要自动提交 Git

这种文件适合加入 .gitignore，避免影响团队其他人。

---

四、Auto Memory：这才更像“Claude 自己做的工作笔记”

CLAUDE.md 主要是你告诉 Claude 应该记什么。

Auto Memory 则反过来：

Claude 在工作过程中，自己判断哪些经验以后可能还有用。

比如你和它排查半天发现：

OrderService 的集成测试失败，不是代码错了，而是本地 Redis 没启动。

这种东西不一定值得写成项目强制规范，但下一次遇到类似问题时非常有价值。

Auto Memory 默认开启，官方明确说明 Claude 会根据未来是否可能有用，自行决定要不要保存诸如构建命令、调试经验、架构信息和工作习惯等内容。

它默认存放在：

~/.claude/projects/<project>/memory/

例如：

~/.claude/projects/<project>/memory/
├── MEMORY.md
├── debugging.md
├── api-conventions.md
└── testing.md

这些都是真实存在的普通 Markdown 文件，可以自己打开、修改甚至删除。

---

五、MEMORY.md 为什么不直接把所有经验都写进去？

因为 MEMORY.md 更像一本笔记的目录。

例如：

# MEMORY.md

- Redis 集成测试注意事项见 debugging.md
- API 命名规范见 api-conventions.md
- 项目测试约定见 testing.md

详细内容再放：

# debugging.md

## Redis

Order 模块集成测试依赖本地 Redis。

常见异常：

Connection refused localhost:6379

出现该问题时，先检查 Redis 是否启动，
不要第一时间修改业务代码。

这里有一个很有意思的底层设计：

Claude Code 每次新会话启动时，只自动加载 MEMORY.md 的前200行或者前25KB， whichever comes first；像 debugging.md 这样的详细文件，不会每次一股脑塞进上下文，而是需要时再读取。

这其实很好理解。

就像程序员工作时：

先记得“这个坑以前踩过”，真遇到了再翻详细笔记。

而不是每天上班先把过去两年的排障记录全部背一遍。

---

六、怎么让 Claude 主动帮你总结记忆？

Auto Memory 会自己工作，但实际开发里，我不太建议完全靠它“自己悟”。

复杂任务做完以后，可以直接说：

请总结这次排查过程中值得长期保留的经验。

只保存以后还可能复用的信息，
不要保存这次临时需求和一次性数据。

如果有必要，请整理到 Auto Memory，
调试经验和项目规范分开记录。

或者更简单：

记住：这个项目执行 API 集成测试之前，
必须先启动本地 Redis。

官方目前明确支持这种自然语言操作：当你要求 Claude “remember that...” 时，它会把信息保存到 Auto Memory。

如果这不是“经验”，而是一条以后必须遵守的规则，那就应该明确说：

把“禁止直接修改生产数据库”
加入项目 CLAUDE.md。

这两个动作最好分开：

以后可能有用的经验
→ Auto Memory

以后必须遵守的规则
→ CLAUDE.md

---

七、怎么知道它到底记了些什么？

直接执行：

/memory

这是最实用的命令之一。

它可以查看：

CLAUDE.md
CLAUDE.local.md
Auto Memory
其他记忆文件位置

也可以打开 Auto Memory 目录，查看、修改或者删除里面的内容，并控制 Auto Memory 是否开启。

如果你的问题不是：

“Claude 保存了什么？”

而是：

“这次会话到底加载了哪些记忆？”

应该执行：

/context

这两个命令可以这样记：

/memory
→ 管记忆文件


/context
→ 看这次会话实际吃进去了什么

官方也建议通过 /context 检查当前哪些 Memory files 真正加载成功。

---

八、为什么 CLAUDE.md 也不能写成一本小说？

假设你把项目所有资料全部塞进去：

CLAUDE.md

数据库设计
历史Bug
全部接口文档
部署手册
100条编码规范
项目发展史
几十页需求
……

technically 能加载，但并不是好事。

因为 CLAUDE.md 本身也要占 Context Window。

官方目前建议保持内容简短、具体，项目 CLAUDE.md 最好控制在大约200行以内；文件越大，占用上下文越多，规则执行效果反而可能下降。

所以我更喜欢：

CLAUDE.md
→ 只放高频、重要、必须知道的规则


.claude/rules/
→ 按代码范围拆规则


docs/
→ 放完整架构文档和业务资料


Auto Memory
→ 放实际工作积累出来的经验

.claude/rules/ 还可以按照文件路径生效，比如只有 Claude 操作 src/api/** 时才加载 API 规则，避免无关内容一直占着上下文。

---

九、我自己更推荐的项目结构

一个长期项目可以整理成：

order-system/
│
├── CLAUDE.md
│
├── CLAUDE.local.md
│
├── .claude/
│   └── rules/
│       ├── code-style.md
│       ├── testing.md
│       └── security.md
│
├── docs/
│   ├── architecture.md
│   └── database.md
│
└── src/

然后 Claude 自己积累的经验在用户目录：

~/.claude/projects/<project>/memory/
├── MEMORY.md
├── debugging.md
├── testing.md
└── api-conventions.md

这样就比较清楚了：

团队规则
→ 项目 CLAUDE.md


个人习惯
→ ~/.claude/CLAUDE.md
或 CLAUDE.local.md


细粒度规则
→ .claude/rules/


Claude自己总结的经验
→ Auto Memory


今天正在做什么
→ 当前 Context Window

---

十、实际使用时，一套比较顺手的流程

第一次进入老项目：

/init

让 Claude 先生成基础 CLAUDE.md。

然后人工补充：

架构约束
代码规范
测试命令
明确禁止事项

平时正常开发。

遇到复杂 Bug 并最终解决后，可以补一句：

把这次排查中以后还能复用的经验总结一下，
有价值的内容写入 Auto Memory。

隔一段时间执行：

/memory

检查它到底记了什么。

如果某条 Auto Memory 慢慢从“经验”变成了团队必须遵守的规则，例如：

所有订单写操作必须经过 OrderDomainService。

就把它从经验升级成：

CLAUDE.md

这才是比较健康的记忆管理。

---

总结

Claude Code 所谓的“记住项目”，并不是把你的所有历史聊天永久背下来。

它更像一套分层存储：

CLAUDE.md
→ 长期规则


Auto Memory
→ 工作过程中积累的经验


Context Window
→ 当前任务的工作内存

对应的位置也很清楚：

项目规则
./CLAUDE.md


个人全局习惯
~/.claude/CLAUDE.md


项目个人规则
./CLAUDE.local.md


Claude自动记忆
~/.claude/projects/<project>/memory/


当前上下文
没有固定Markdown文件

真正好用的方式，不是拼命往 Prompt 里塞背景，也不是把 CLAUDE.md 写成一本项目百科。

而是：

规则写下来，经验让 Claude 自己总结，当前任务留在上下文。

这样用久以后，它才不会像一个每天重新入职的新人，而更像一个：

知道项目规矩、记得以前踩过什么坑，还会自己整理工作笔记的开发同事。