如果你用Claude Code跑长期项目，大概已经见识过它的记忆系统有多好用——MEMORY.md索引加主题文件，能把上下文串起来。但用久了也会发现，这东西会腐烂。
几个月日常用下来，我踩到三种固定的坑。审计膨胀：你开始记录决策（"试了X，没用"）、编码规则（"推送前必须类型检查"）、背景信息。某天突然发现，写文档的时间比做决策还长。记忆文件疯长，交叉引用断裂。项目污染：随手做的元实验——"测一下这个MCP服务器"——混进真实项目的提交历史和工作区。半年后分不清哪些是信号，哪些是草稿。规则漂移：周一写的治理规则，周二就用"这次不一样"绕过去。规则本身没错，只是没人执行了。
我搭了一个小型工作台模式来对付这三件事。叫它claudelab，刻意做得很无聊：几个markdown约定，加一个Python脚本。
审计膨胀封顶——每轮会话明确限制新增记忆文件数量。触顶之后，只有正当理由（真实事故、外部审计）才能追加。逼你停止记录，去动手建东西。REJECTED归档——每个被毙掉的想法都记下理由和反转触发条件。没有新证据，不许重审死掉的方案。闭环自审——健康检查脚本找出断裂的交叉引用、孤儿文件、过期条目。系统自己保持一致，不用人眼扫描。轨道分离的治理——真实项目、元实验、研究各自遵循不同规则。该严的地方严，该松的地方松。
写到这的时候，我还不知道Anthropic刚发布了Dreaming。这是2026年5月官宣的托管功能，自动做跨会话记忆整合：回顾历史会话、修剪过期笔记、合并重复项、解决矛盾、为后续运行写结构化手册。法律AI公司Harvey reportedly采用后任务完成率涨了约6倍。
发现这事时，我的第一反应是"好吧，是同一个问题"。确实是——但两个解法坐在两端：
claudelab是手动的、有门的、小规模的。Dreaming是自动的、托管的、工业级的。我做的东西够一个人用，他们做的够一千人用。问题相同，规模不同，这是关键区别。
时间线要澄清：Dreaming官宣时，我的工具还没做完。这不是抢优先权，是独立趋同。有意思的是这个：当记忆腐烂成为普遍痛点，解法会自然分化为两条路线。一条往自动化走，让系统自己收拾残局；一条往手动约束走，用规则强制人做选择。两条路都成立，取决于你愿意交多少控制权，能承受多少复杂度。
我选手动，不是因为自动化不好，是因为我的项目还没大到需要托管方案。但那个6倍的数字会留在我脑子里。哪天我的markdown约定扛不住了，就知道该往哪边搬。
热门跟贴