Claude Code 藏了一个还没发布的功能：Auto Dream，它让 AI 学会了"做梦"

来源：https://www.51cto.com/article/839254.html

作者：田歌

发布时间：2026-03-27 15:51:44

作者 | 田歌审校 | 重楼不久前，Twitter 上有人贴出了一张截图："just found out Claude Code has a new (unreleased?) feature called 'Auto-dream' under /memory. according to reddit, this basically runs a subagent periodically to consolidate Claude's memory files for better long-term storage".很多人打开自己的/memory去找，果然在那里：复制Plain TextMemory

Auto-memory: on

Auto-dream: off · never1.2.3.toggle 显示在那里，但点不开。Anthropic 把它藏好了，还没有给大多数用户。这不是一个边缘功能。

Auto Dream 是 Claude Code 记忆体系里缺失的那一半：没有它，整套记忆架构就像只有进水管没有排水管。这篇文章从"记忆为什么会腐烂"说起，把四层架构、四阶段流程、三个工程决策、学术背景、以及社区已经发现的三个缺口，完整讲一遍。

一、记忆为什么会"腐烂"：Auto Memory 的写即遗忘问题你用 Claude Code 写了一个月的项目。前几周配合默契：它记得你用 pnpm 不用 npm，记得 API 模块在哪里，知道哪个目录有坑不要乱动。

但到了第 30 次会话，它开始犯奇怪的错误。建议你用 npm，把文件建到你一直不用的位置，或者把上周刚改回来的配置又改成了你不想要的样子。你的第一反应是：模型更新了？

prompt 没写好？其实都不是。Claude Code 记了 30 次会话的笔记，但从来没整理过。Claude Code 从 v2.1.59 开始有了 Auto Memory：每次会话结束后自动写笔记，存进~/.claude/projects//memory/MEMORY.md。

笔记内容包括：发现的 build 命令特殊情况、你纠正过它的行为、有效的调试路径。这个功能上线时，很多人觉得：终于，AI 有记忆了。问题在于，Auto Memory 只会写，不会整理。

几周之后，MEMORY.md 里堆满了："昨天发现 API 模块有问题"，"昨天"是哪天？时间锚点已经失效三条关于同一个 build 命令的记录，内容互相矛盾项目从 Express 换成了 Fastify，但记忆里还写着"用 Express"一个调试方案指向一个已经在重构中删掉的文件 MEMORY.md 有200 行的硬上限，超出的部分启动时不加载。

空间有限，内容一直堆。最终，这本应该帮助 Claude 记住项目的笔记，变成了它的噪声来源。信息越多，模型越难找到有用的那条。Auto Memory 制造了一个会自我劣化的记忆系统。

二、Auto Dream 是什么：给 AI 加上"睡眠"Auto Dream 是 Anthropic 对这个问题的回答：给 Claude Code 加一个整合层，专门处理 Auto Memory 积累的噪声。

命名不是噱头，而是一个精准的类比。人类大脑在 REM 睡眠阶段会做一件关键的事：把白天零散吸收的短期记忆，重组成结构清晰的长期记忆，清除矛盾，强化有用的，丢掉没用的。

睡眠不足的人记忆力差，不是因为没有吸收信息，而是因为信息没有被整合过。Claude Code 之前的状态，就像一个长期睡眠被剥夺的助手：一直在记东西，从没整理过。

Auto Dream 就是给它补上"REM 睡眠"。定位很清楚：Auto Memory 是写入阶段，Auto Dream 是整理阶段。两者是一对，不是两个独立功能。

只有 Auto Memory 没有 Auto Dream，就像只有进水管没有排水管，时间一长，系统就堵了。三、四阶段工作机制：一次整合周期具体做什么Auto Dream 不是简单地压缩内容。

它分四个阶段进行一次结构化整合：Phase 1：定向（Orient）—> 先摸清家底读取 MEMORY.md，扫描整个记忆目录，建立当前记忆状态的全局视图。核心问题是"我现在知道什么，这些东西怎么组织"。

没有这一步，后续的整合就是盲人摸象。这也是社区反映的第一个已知缺陷所在：如果项目改过名，Auto Dream 在这一步可能无法正确识别项目身份，把新记忆写入错误的路径，旧路径的孤儿文件也无人清理。

Phase 2：收集信号（Gather Signal）—> 精准捞取，而不是全量扫描这一步是整个流程中最值得关注的设计。Auto Dream 不会逐条读取所有会话记录，那样 token 成本太高，在有 913 次会话记录的项目上根本跑不动。

它做的是窄范围搜索：通过 grep 有针对性地寻找几类高价值信号：用户的纠正行为、明确的"记住这件事"指令、跨多次会话反复出现的主题。精准打捞，不是全网撒。这个策略让整合成本可控，但也带来了准确性风险：当它在日志里看到"18 of 21 items resolved"这样的具体数字时，如果不去读对应文件核实，就直接写入了一个未经验证的断言。

Phase 3：整合（Consolidate）—> 三件具体的事这是核心阶段，做三件事：时间绝对化：把"昨天""上周"这类相对时间改成绝对日期："2026-03-15"。

相对时间随着项目推进会失去意义，转成绝对时间才能在几个月后依然可读。矛盾清理：删除被新信息推翻的旧条目。从 Express 换成 Fastify 之后，旧条目就该删了，不是让两条记录并存让 Claude 自己猜哪个对。

重复合并：把三条说同一件事的记录合并成一条干净的记录。整合遵循"外科手术式"原则：不需要修改的文件一律不动，只处理有变化的部分。Phase 4：剪枝与重建索引（Prune and Index）—> 维护 200 行边界更新 MEMORY.md，确保它严格保持在 200 行以内。

超过这个边界的内容，下次启动时不会被加载，等于自动失效。Auto Dream 在这一步删除失效链接，添加新主题文件的入口，按相关性和时间重新排序。整个流程在后台运行，不阻塞用户会话。

根据社区观察的案例，整合 913 次会话的记忆大约需要 8-9 分钟。四、四层记忆架构：Auto Dream 在整套体系中的位置理解了 Auto Dream 是什么，再来看它在 Claude Code 完整记忆体系里的位置。

四层各司其职，但分工逻辑不是对称的：1.CLAUDE.md CLAUDE.md 是体系里唯一由人主动写的层，优先级最高。它分三个范围：组织级（IT/DevOps 管理，无法被个人排除）、项目级（通过版本控制共享给团队）、用户级（个人跨项目偏好）。

CLAUDE.md 无论多长都完整加载，这是它和 Auto Memory 本质的不同。它不是"Claude 记住了什么"，而是"你要求 Claude 必须遵守什么"。

权威性来自人的主动写入，不依赖 Claude 的判断。2.Auto MemoryAuto Memory 是 Claude 的学习日记，有两个关键约束：第一，MEMORY.md 严格限制 2

本文由 AI 自动从 51CTO 抓取整理