夜雨聆风AI 也需要"做梦"。
不是飞天遁地那种。是像你考试前一晚，大脑自动把白天背的单词重新整理归档的那种。
2026 年 3 月，Anthropic 在 Claude Code 里偷偷上线了一个功能，内部代号 "Dream: Memory Consolidation"。你不用它的时候，它会在后台启动一个进程，回顾最近的对话，把零散的记忆去重、修剪、重新归档。
跟人类睡觉整理记忆，一个逻辑。
但先说个更实际的问题——知道这个，对你有什么用？
知道这些，你能干什么
如果你现在用 AI 编程助手——Claude Code、CodeBuddy、Cursor、Copilot，随便哪个——大概率遇到过这些情况：
每次开新对话，要重新说一遍"我们项目用 TypeScript，包管理器是 pnpm，测试框架用 Vitest" AI 明明上次帮你调通了一个 bug，这次又犯同样的错 你改了三次"别用 Redux，用 Zustand"，它第四次还是给你生成 Redux 代码
根源就一个：AI 没有记忆。
每次新会话，上下文窗口是空的。你跟它说过的话、达成的共识、踩过的坑，全部清零。
理解记忆系统能干什么呢？
最直接的——项目规范不用反复说了。 把编码规范写进记忆文件，AI 每次启动自动加载。新来个同事，clone 项目就自带全套规范，AI 读完就知道怎么写代码。
然后是 AI 不会重复犯错。你上次告诉它"数据库连接要用连接池，别每次新建"，它记住了。下次自动用对的方式。不用你第三次、第四次纠正。
团队协作也受益。项目级的记忆文件提交到 Git，等于给 AI 写了一份"员工手册"。每个人打开项目，AI 行为都一致。
而且这不只是 Claude 一家在搞。你看现在主流 AI 编程助手的记忆方案：
记忆系统是 AI 编程助手的下一个竞争维度。 模型能力大家都在追，但谁能让 AI "更懂你的项目"，谁就留得住用户。
好，先看看这套记忆系统是怎么一步步走到今天的，然后再说你怎么用。
最早的记忆——手写 CLAUDE.md
2025 年 5 月，Claude Code 正式发布。记忆机制简单粗暴：项目根目录放一个 CLAUDE.md 文件，AI 每次启动读一遍。
就是一个纯文本文件。你手动往里写规则：
# 项目规范- 使用 TypeScript，严格模式- 包管理器用 pnpm- 测试框架用 Vitest- commit message 用 Conventional Commits 格式- 组件命名用 PascalCaseAI 读完这些，就知道在这个项目里该怎么干活了。
Anthropic 设计了一套多级层次，从大到小：
/Library/Application Support/ClaudeCode/CLAUDE.md | |||
~/.claude/CLAUDE.md | |||
./CLAUDE.md | |||
./CLAUDE.local.md |
项目级的 CLAUDE.md 提交到 Git，团队共享；个人的 .local.md 加进 .gitignore，只有自己能看到。团队规范和个人偏好分开管理，不冲突。
但问题很明显：全靠人记着往里写。
你调了两小时 bug，发现 webpack 的某个配置有坑——你会记得把这个写进 CLAUDE.md 吗？大概率不会。你已经累了，修完 bug 就想关电脑了。
而且写多了 AI 也吃不下。CLAUDE.md 塞了 500 行，AI 每次启动要读完这 500 行，上下文窗口直接被吃掉一大块。不划算。
进化——AI 自己记笔记
2025 年底到 2026 年初，Claude Code 上线了 Auto Memory。
AI 开始自己往记忆文件里写东西了。
每次对话结束，Claude Code 在后台启动一个独立的子进程（源码里叫 extractMemories），回顾刚才的对话，判断哪些信息"值得记住"，自动写进 MEMORY.md。
它会记什么呢？源码里定义了 4 种类型：
这里有个巧妙的地方：它只存"不可推导的知识"。
代码结构、文件路径这些不存——AI 随时可以 grep 代码库拿到。Git log、git blame 是权威来源，不用重复记。debug 修复方案也不存——修复已经写在代码里了。
只存那些代码里看不出来，但对干活有帮助的东西。
打个比方：CLAUDE.md 是你给 AI 写的员工手册，Auto Memory 是 AI 自己的工作笔记本。
手册告诉它"公司规定 9 点上班"。笔记本记的是"张经理不喜欢在邮件里用感叹号"。都有用，来源不同。
到这一步，开发者不用再操心"我该记什么"了。AI 自己判断。
但新问题来了——只增不删。
用了两个月，MEMORY.md 膨胀到几百行。里面有重复的条目，有过时的信息（项目早就从 webpack 迁到 vite 了，记忆里还写着 webpack 的配置踩坑），有几条记忆互相矛盾。
AI 每次启动加载这些乱糟糟的记忆，反而被误导。
做梦——AI 学会整理记忆
2026 年 3 月 26 日，AutoDream 上线。
源码里的 prompt 标题写得很直白："Dream: Memory Consolidation"。
你白天接收一大堆碎片——同事说的一句话、报错日志里的一行、Stack Overflow 上看到的一个技巧。晚上你睡觉，大脑进入 REM 阶段，自动把这些碎片归类、压缩，不重要的丢掉，重要的固化成长期记忆。
AutoDream 干的就是这个事。它分四步走：
触发条件：距上次整理超过 24 小时，且期间至少积累了 5 个新会话。两个条件同时满足才启动。
先是定向——看看现有的记忆文件都有什么，理解当前知识结构。然后收集信号——扫最近几个会话的记录，找有价值的新信息，顺便检查哪些旧记忆跟代码库现状矛盾了。
接下来是关键的整合：新信息合并到已有的主题文件里，"昨天"转换成具体日期"2026-04-03"，被推翻的旧事实直接删。
最后修剪索引：更新 MEMORY.md，保持在 25KB 以内。冗长的条目压缩，过时的链接删掉，互相矛盾的记忆——修掉错的那条。
整个过程跑在后台，不卡你干活。底部状态栏会显示 "dreaming"，按 Shift+Down 看进度，按 x 随时打断。你也可以手动触发——输入 /dream 立刻开始。
为什么记忆整理这么重要？
想想你手机里的照片。你每天拍，从来不整理。半年后想找去年那张合照，翻了 20 分钟没找到。AI 的记忆也一样，堆得越多，检索效率越低，干扰越大。
不整理的记忆不是资产，是负债。
六层记忆，拼出完整的"大脑"
Claude Code 的记忆系统到今天，早就不是一个配置文件了。六层架构：
前四层是持久化的——写在文件里，跨会话保留。后两层是临时的——这次对话结束就没了。
Auto Memory + AutoDream 这一层最有意思。它是唯一一个"AI 自主管理"的层次。其他层要么是人写的，要么是系统生成的。只有这一层，AI 自己决定记什么、忘什么、怎么组织。
AI 编程助手第一次有了自己的"长期记忆"。
演进讲完了。接下来说实际的——知道了这些，日常开发怎么用？自己做 Agent 怎么设计？
日常开发：记忆文件不是越长越好
很多人的第一反应是往记忆文件里猛塞内容。CLAUDE.md 写了 500 行，.cursorrules 写了 800 行，恨不得把整个项目文档都塞进去。
不行。
有人拿 60 多个项目、1500 多次会话的数据做了统计：指令文件超过 200 行之后，AI 的表现反而开始下降。
原因很简单——上下文窗口是有限的，记忆文件越长，留给真正干活的空间就越少。而且大模型有个已知毛病：长文本中间部分的指令容易被忽略，学术界叫 Lost in the Middle 效应。
记忆文件要小而精准，按需加载。
那具体怎么写呢？
五层记忆架构：该放哪就放哪
前面讲的六层是 Claude Code 自己的系统设计。但你在实际项目里用的时候，不用管它底层怎么分层——你只需要管好自己能控制的部分。
有个分层方案，我自己在用，觉得挺好。不管你用 Claude Code、Cursor、CodeBuddy 还是 Copilot，逻辑都一样：
第一层：宪法层——硬规则
大小控制在 200 行以内，每次会话都加载。
写什么？两样东西：硬性规则 和 路由表。
硬性规则就是项目里绝对不能违反的约定：
- 使用 TypeScript 严格模式- 测试中绝不 mock 数据库，用真实测试库- commit message 用 Conventional Commits- 组件命名 PascalCase，工具函数 camelCase路由表是这一层的灵魂——不存知识本身，只告诉 AI 知识在哪：
## 参考索引- 数据库 schema → docs/schema.md- API 设计规范 → docs/api-conventions.md- 部署流程 → docs/deploy-guide.md- 已知踩坑记录 → .claude/memory/gotchas.mdAI 需要某个知识的时候，顺着路由表自己去读。不需要的时候，不占上下文。
第二层：活记忆——AI 反复犯错的纠正
大小控制在 50 行以内，每次会话都加载。
这一层只放一种东西：你纠正过 AI 的记录。
## 踩坑纠正- orders 表存的是增量值，不是累计值。别再搞混了- 这个项目的 Redis 连接池上限是 20，不要用默认值- 前端路由用 hash 模式，不是 history 模式，因为部署在子路径下- 测试环境的数据库地址跟生产不一样，看 .env.test这是见效最快的一层。 每条记录直接防止一个重复错误。你花 30 秒写一行，以后每次会话都省 5 分钟纠正。
第三层：项目大脑——业务知识
大小不限，但只在对应项目目录工作时加载。
比如你有 5 个项目，80% 的知识只跟其中一个有关。没必要每次都全部加载。
这一层放业务规则、架构决策日志、关键的 schema 说明：
## 订单系统- 订单状态机：created → paid → shipped → delivered → completed- 退款只允许在 shipped 之前，shipped 之后走售后流程- 金额全部用分（整数），展示时再除以 100## 架构决策- 2026-03-15：从 webpack 迁移到 vite，原因是构建速度- 2026-04-20：用户认证从 session 切到 JWT，因为要支持移动端第四层：知识库——按需查询
大小无限制，AI 需要时自己搜索。
完整的数据库 schema、API 文档、第三方服务的对接说明，都放这一层。用 Markdown 文件按主题组织就行，不用上向量数据库那么重。
第五层：会话记忆——上次干到哪了
每次新会话开始时，自动生成一份简报：最近几次会话做了什么、有哪些决策、还有什么没解决的。
Claude Code 的 Auto Memory + AutoDream 就是自动化这一层。Cursor 的 Memory 功能也类似。如果你的工具没有自动化，手动维护一个 session-log.md 也行。
分层效果
前两层加起来不超过 250 行，永远加载。后三层按需加载，用多少拉多少。
上下文窗口省下来了，AI 的准确率也上去了。
记什么，不记什么
这个很关键。我见过不少人往记忆文件里写这种东西：
- src/components/ 目录存放所有 React 组件- utils/format.ts 里有日期格式化函数- package.json 里的 scripts 字段定义了构建命令别写。 这些信息 AI 自己能从代码里读到。写了等于浪费上下文。
前面提到的"只存不可推导的知识"原则，翻译成人话就是：
如果 AI 能通过读代码、grep 搜索、查 git log 得到的信息——不存。
只存这些：
左边这些，不写在记忆里 AI 就会搞错。右边这些，AI 扫一眼 package.json 就知道了。
记忆文件不是文档，是"不告诉它就会犯错"的速查卡。
团队怎么协作
项目级记忆文件提交到 Git，个人级加 .gitignore。这一点前面讲过。
实操中有几个细节：
1. 指定一个记忆管理员。 不用专职，但要有人定期（比如每两周）Review 一下记忆文件，清掉过时的条目。不然三个月后文件里一半是废话。
2. 用 PR 管理记忆变更。 记忆文件跟代码一样走 Code Review。有人往里加了一条"API 返回的时间戳是 UTC"，别人 review 时发现"不对啊，我们上周改成北京时间了"——抓到一个潜在 bug。
3. 新人入职就看记忆文件。 比看 Wiki 快多了。50 行活记忆 + 200 行宪法层，10 分钟读完，这个项目的坑全知道了。
好，日常开发讲完了。接下来说另一个场景——你自己做 Agent 的时候，记忆系统怎么设计。
Agent 记忆：四种类型，各有各的活
如果你在做 Agent 开发——不管是用 LangChain、LangGraph、还是自己搭——记忆系统是绕不过去的。
先搞清楚四种记忆类型：
| 短期记忆 | |||
| 情景记忆 | |||
| 语义记忆 | |||
| 程序记忆 |
一个例子。用户对你的客服 Agent 说："上次那个订单超时的问题解决了吗？"
Agent 需要做什么：
短期记忆告诉它：用户这轮对话的语境 情景记忆告诉它：上周三用户反馈过订单 #12345 超时 语义记忆告诉它：这个用户对性能问题很敏感 程序记忆告诉它：查订单状态要先调 order-service 的 /status接口
四种记忆一起上，Agent 才能给出靠谱的回答。缺了情景记忆，它忘了上次的事。缺了语义记忆，它不懂用户的脾气。缺了程序记忆，它不知道该调哪个接口。
记忆系统的四步流水线
不管用什么技术栈，Agent 记忆系统的数据流都是这四步：
编码（Encode）→ 存储（Store）→ 检索（Retrieve）→ 注入（Inject）编码——把对话变成可存储的结构
对话结束后，跑一个异步任务，用 LLM 从对话里提取"值得记住的信息"。
不是存聊天记录。 是提炼。
原始对话："帮我把订单表的 amount 字段从 float 改成 decimal(10,2)" ↓ 编码提炼后的记忆：{ "type": "project_decision", "content": "订单表 amount 从 float 改为 decimal(10,2)，防止浮点精度问题", "timestamp": "2026-05-11", "source": "session_42"}存储——选对后端
小项目不用这么复杂。SQLite + 一个嵌入模型就够了。甚至像 Claude Code 那样用 Markdown 文件都行——透明、可版本控制、零运维。
到了百万级用户、多租户场景，再上 Redis + pgvector + Reranker 的组合。
检索——只拉相关的
这一步最值得花时间优化。
新会话开始时，把用户的输入向量化，去记忆库里做语义搜索，只拉 Top 5 最相关的记忆注入 prompt。
不要把所有记忆都塞进去。100 条记忆全部注入 = 回到"500 行 CLAUDE.md"的老路。
检索策略推荐：
向量相似度检索（召回） ↓BM25 关键词检索（补充） ↓Cross-encoder 重排序（精排） ↓Top-K 结果注入 prompt为什么要两路并行？只用向量检索容易漏掉精确匹配（用户说"订单 #12345"，向量可能匹配不上）。只用关键词又缺语义理解（用户说"上次那个超时的事"，关键词搜不到）。两路召回取并集，Reranker 统一排序，效果最好。
注入——塞进 system prompt
把检索到的记忆格式化后塞进 system prompt 的指定位置。
system_prompt = f"""你是一个客服助手。## 用户画像{semantic_memories}## 相关历史{episodic_memories}## 操作规则{procedural_memories}"""放在 system prompt 的前面。前面说了，大模型对首尾位置的信息利用率最高。
记忆也会过期
不整理的记忆不是资产，是负债——这一点不管是日常开发还是 Agent 开发都一样。
Agent 开发里怎么实现遗忘呢？一个简单的衰减公式：
分数 = 相关度 × 重要性 × 衰减因子(时间)衰减因子通常用指数衰减：decay(t) = e^(-λt)。λ 越大，遗忘越快。
实操建议：
30 天没被检索过的记忆，降低权重 两条记忆互相矛盾时，保留时间更近的那条，旧的标记"废弃" 定期跑一个离线任务（就像 AutoDream），清理废弃记忆、合并重复条目
Zep 的做法值得参考：它在知识图谱的边上加了"失效标记"。新事实跟旧事实冲突时，旧边标记失效，但不删除——既保留最新认知，也支持历史回溯。
像 Git 一样管理记忆：新版本覆盖旧版本，但旧版本还能查。
记忆安全：这个真别忽略
最后一条尤其关键。GDPR 和隐私法规要求"被遗忘权"。你的 Agent 如果做不到按需删除特定用户的记忆，上线就是合规风险。
选型速查：开源记忆框架
如果不想从零搭，现在有不少开源方案：
| Mem0 | ||
| Zep | ||
| Letta | ||
| LangMem |
选型建议：小项目先用 Mem0 跑通，验证记忆对你的业务有没有用。确认有用了，再根据规模和需求换 Zep 或 Letta。
别一上来就搭最复杂的架构。先证明记忆有价值，再优化记忆的实现。
写在最后
从 2025 年的手写 CLAUDE.md，到 2026 年的 AutoDream，三代进化：人写给 AI → AI 自己写 → AI 自己整理。
你先手写了一份员工手册，后来员工学会了自己记笔记，再后来员工每天晚上还会把笔记本整理一遍，扔掉过时的、合并重复的。
日常开发——管好记忆文件，分层存储，控制大小，定期清理。Agent 开发——分清四种记忆类型，搭好编码→存储→检索→注入的管道，别忘了加遗忘机制。
不管以后用什么 AI 助手，记忆机制的底层逻辑都是这一套～
你在项目里用了记忆系统吗？效果怎么样？评论区聊聊。
📌 关注公众号，不错过下一篇拆解。
觉得有收获？点赞 + 在看 + 转发，是对我最大的支持 🙏
