ARTICLE · 1025566
这份文档解读,把Claude Code的核心记忆机制:“做梦dream”讲清楚了
昨晚，我把一份 21KB 的英文文档读完了。
读完的第一反应， 这不就是Claude Code的做梦机制的拆解吗？赶紧Mark到收藏夹。
它整理记忆的方式，叫做「做梦」。
一、以前的「记性」，是人替它管的
用编码 agent 的人都干过同一件事。
在项目根目录放一个文件，写满约定：测试怎么跑、命名怎么起、提交信息怎么写、这个模块别动。
名字换过好几轮。有的叫 README，有的叫 AGENTS.md，有的叫 CLAUDE.md。
本质上都是同一件事：给一个记性为零的新同事，写一份入职文档。
问题也跟新人入职一模一样。
写的人认真写，看的人不看。半年后代码变了，文档没变。真正管用的那些约定，从来没写进文件里，都在老人脑子里——包括那句「用 just test，不是 cargo test」。
然后，这个 agent 上线了记忆功能。
它决定自己写。
二、它记住的，是你顺口纠正它的那一次
官方公告里放了一段终端实录，我看了三遍。
一个叫 orbit 的项目里，它先跑了 cargo test。
报错：连不上 localhost:5432 的 postgres。143 个测试过了，5 个失败。
用户没写文档，没建规范，只是顺口补了一句：用 just test，不是 cargo test，它会先把测试数据库起起来。
再跑一次。148 个测试全过。
然后这句话变成了一个文件：topics/testing.md。
里面写着三条：跑套件用 just test，它会先启动测试数据库再跑 cargo test，直接跑 cargo test 会让集成测试失败；跑单个 crate 用 just test ；集成测试从 tests/fixtures/seed.sql 播种。
没有一个字是用户写的。
再往下翻，是另一个会话。
用户只说了一句「给 webhook 发送器加一个带退避的重试」。
它改完 src/webhooks.rs，思考了 1.9 秒，说了一句话：
「测试主题说，测试套件走 just test。」
然后直接跑对了。151 个测试全过。
……
看到这里的感受，跟看到新人第一次独立上手，是同一种。
它记住的不是你说的话，是你顺口纠正它的那一次。
三、记什么不难，不记什么才难
机制本身很朴素：每一轮对话完成后，它在后台回看这一轮，把「值得留下的东西」写成笔记。
注意三个细节。
第一，它跑在每一轮完成的对话上，不打断会话，也不阻塞。 你不是在对话中间等它记账；你在干活，它顺手记。
第二，会话结束的时候它还有一层自动保存。 记下消息条数、最多五条有价值的用户提示、UTC 时间。这份摘要不调模型、不增加延迟。
第三，琐碎的会话它直接跳过。 少于三条实质提示，或者用户输入累计不到 50 个字节，不记。
真正有意思的是它不记什么。
官方文档列得很清楚：任务状态、临时的结论、机密信息，以及「仓库或文档里已经写过的任何内容」，一律不记。
最后那一条，我盯着看了很久。
它是把「新人入职文档」这个比喻，反过来用了。
一份好的入职文档，不该把代码讲一遍——代码自己能讲自己。它只补那些代码里没有、但干活必须知道的东西。
团队怎么审代码，当时为什么这么选，这个子系统藏在哪，哪条命令能一次跑通。
用人话说：它写的是 wiki 永远写不好的那一部分。
（你回想一下你们公司那个 wiki。开头很完整，中间开始散，最后没人打开。它缺的从来不是内容，是取舍。）
四、它不是一坨笔记，是一个小柜子
存的格式是 Markdown，一个主题一个文件。
项目一份，全局一份。全局那份放跨项目的偏好，项目那份放这个仓库自己的事。
有个细节我很喜欢：目录名不是按文件夹起的，是按仓库身份起的。 它取 git 的 origin 远程，用「组织/仓库」这个名字生成目录。
后果是：同一个仓库，你 clone 几份、开几个 worktree，它们共享同一份记忆。
这个设计比表面上更重要。它意味着记忆跟着项目走，不跟着某台电脑的路径走。
浏览也是一个命令。打开之后是左边文件列表、右边只读预览，按作用域分组，每一条都带着文件大小和「多久之前」。
列表里有一种文件叫 MEMORY.md。
它头上写着一行字：由 Grok 生成，不要直接编辑本文件。
我读到这句的时候笑了。
因为它里面存的是绝对路径——它是索引，不是内容。你要改，去改下面的主题文件。
一个自己会写笔记的系统，第一条守则是「别手改我的目录」。
（说真的，这比很多人写文档的自觉性高。）
五、整理笔记这件事，它管它叫「做梦」
散落的笔记多了就是噪音。所以它有一个整理动作，名字叫 /dream。
梦做的事：把散在各处的碎片合并进对应的主题文件，去重、归类、收敛。
流程用人话讲一遍。
它会在带围栏的租约下，先领取一份固定的收件箱快照——也就是把这一轮要处理的笔记冻住。然后用一个不带工具的模型算一遍整理计划，原子地更新主题文件，再把已经处理过的观察归档。
关键在最后半句：整理期间新产生的笔记，不参与这一轮，排队等下一次。
先冻结，再整理。不边写边改。
我一个做了十几年工程的人，看到这里是真的服气。
因为这正是绝大多数数据整理脚本翻车的地方：一边读一边写，改到一半崩了，谁也不知道停在哪。
梦也不是你叫它才做。默认门槛是：距上次整理至少 24 小时，且期间至少攒够 5 个会话，然后每小时检查一次。
……
等一下。睡觉、做梦、把白天的碎片整理成长期记忆。
这不就是人脑干的事吗。
哺乳动物睡觉的时候，海马体会把白天发生过的事重放一遍，挑出该留下的，慢慢写进皮层。整理记忆这个动作，本来就是睡着的时候做的。
它给这个功能取名叫「做梦」，不是玩梗。它是在承认：记忆不是写下来的，是睡出来的。
（只不过它的梦，是每小时检查一次有没有到 24 小时。这个作息，比我健康。）
六、你说「加个重试」，它已经知道该跑哪条命令
做完整理，最难的一步是「什么时候把它读出来」。
读得太早全是噪音，读得太晚等于没记。
它的做法有几个触发点。
新会话的第一轮，它先检索一遍跟当前项目相关的内容，塞进上下文——你还没开口提醒，它已经在那里了。
上下文被自动压缩、裁掉一截之后，它再检索一次，把丢掉的东西捞回来。
你回到某个项目时，它读「覆盖你即将动手那块领域」的主题。官方文档特意加了一句：包括那些在这次会话里从来没被提起的场合。
还有一条纪律：当前对话里的指令，优先级高于任何笔记。
检索本身是两套打分合并的：向量相似度权重 0.7，全文关键词权重 0.3；结果要过一个最低分门槛，首轮注入那道门槛还更高。
重排的时候它会惩罚重复内容，怕你把同一个知识点看五遍。
时间上，只有会话记忆会衰减，默认半衰期 30 天。项目和全局的记忆不衰减——因为那两份是「被整理过的长期知识」。
用人话：聊天记录会忘，约定不会。
这里有个反过来的问题。
如果它记得越准，你还愿不愿意去核对它记错了什么？
我先把这个问题放在这，后面回答。
七、忘掉一件事，先交证据
记忆系统里最难写的功能，从来不是「记」，是「忘」。
老实的做法我先说：它的删除指令是尽力而为——搜一遍，删掉匹配上的条目。要保证删干净，文档说得很直接：自己去改文件。
（翻译一下就是：我们尽力了，但你别全信。）
然后是新版的遗忘接口。我看到这段的时候，是真的愣住了。
要显式遗忘一条记忆，调用方必须提供两样东西：
一个精确的 Markdown 路径，以及「你亲手读过的那些字节」的哈希。
满足之后，系统在删除之前，先写一条不含内容的墓碑和审计记录。
宽泛的请求、过期的证据、路径穿越、符号链接、受保护文件、未知归档、正在被整理占用或租约过期的条目——一律拒绝。
翻译成人话。
你说：把这条忘掉。
它说：请你先证明，你看过你要删的那一条。
我第一次读到这里，觉得它别扭。想删就删，为什么要交哈希？
再想一层，就想通了。
因为这个东西要防的不是你，是另一个会说话的模型。
如果一句自然语言就能触发删除，那么一个被注入、被误导、或者单纯理解偏了的模型，就能顺手删掉不该删的东西。而「路径 + 字节哈希」这个门槛，逼着删除动作必须建立在一份被真实读过的证据上。
同一条设计思路，还在另外两个地方出现。
一个是开关：「记忆」是实验性功能，默认关着。要开，配置里写一行；而且它分了四档放量——完全不记、只记不用、只算不落、正式启用。
远程下发的管理设置只能让本地更严格。开关是「任何一个说不，就是不」；放量取更保守的那一档；保留期取更短的那个。
另一个是遥测：这个功能上报的数据里，只允许有固定的枚举、布尔值、计数和时长。提示词、记忆内容、主题名、关键词、路径、模型输出，一样都不许出现。
一个做记忆的产品，先想清楚了自己不许看什么。
八、我不想把它写成软文
问自己一句：那我是不是在夸它。
不是。先把缺点摆出来。
/dream 的整理质量、检索的阈值、30 天这个半衰期，官方文档里没有一个字提到评测数据。它们都是工程经验值。这套东西仍然是实验功能、默认关闭、分阶段放量——这几条加在一起，意思很明白：团队自己对稳定性也没底。
还有更实在的一条：记忆一旦准了，人就不核对了。
你上一次认真打开公司 wiki 是什么时候？
所以我把自己的三个土判断写在这，供你参考：
- 记忆的第一性问题是「不记什么」。
判断一个记忆系统好不好，别问它能记多少，去看它的排除清单。 - 能被你打开检查的记忆，才叫你的记忆。
全是 Markdown，一个主题一个文件，可以看、可以改、可以删、可以扔进 git。 - 忘掉的成本，决定你敢不敢让它记。
一个删东西不要证据的系统，你用的时候会本能地少说话。
最后一条是我这些年最实在的经验。
我的记忆会骗人，所以我一直把要紧的事写成文件。写过的人都知道，写下来这件事真正的价值不在记住，在于你能回去核对。
写在最后
我们这一代做技术的，都经历过同一件事。
知识曾经是存在人身上的。
师傅带徒弟，口传心授。一个人的价值，有一半是「他知道多少别人不知道的事」。后来有了文档、有了 wiki、有了知识库，我们想把记忆从人身上搬下来。
搬得都不算成功。因为写文档是额外的活儿，而人天生不愿意干额外的活儿。
这一次不一样的地方在于：写文档这件事，被交给了那个直接受益的人。
它边干活边记，记完自己整理，整理完自己读回去，读错了还有一套苛刻的删除流程。
它不是把知识从人身上搬下来。
它是长出了自己的那一份。
那还剩下什么，是人必须自己拿着的？
我想了很久，答案可能有点扫兴：
把记忆交给文件。把判断留给自己。
文件可以交接，判断不能。一份主题文件能写清楚哪条命令能跑通，写不清楚什么时候不该跑那条命令。
那部分，至今没有格式。
以上。既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章，我们，下次再见。