Claude Code 跨会话记忆该放在哪里

Claude Code 换个会话，就可能忘掉上次为什么回滚、哪些方案已经试过。原文给出的办法是把知识分成三层：CLAUDE.md 放工作约定，auto memory 放本机笔记，共享账本保存项目经历，让不同会话和协作者能接着往下做。

这个分工值得借鉴，但具体工具要分开评价：作者自己开发了 RepoMemory，文章没有提供效果对照或实测数据。读它最有价值的部分，是弄清哪些知识该随仓库保存，哪些需要按任务检索。

为什么配置文件装不下项目历史

据作者在 2026 年 10 月 30 日核对的 Anthropic 文档，CLAUDE.md 和自动记忆（auto memory）都会在会话开始时加载。但它们进入的是上下文，并非程序强制执行的规则。

作者转述的建议是，每个 CLAUDE.md 控制在约 200 行以内。文件越长，占用的上下文越多，指令也越难被稳定遵循。因此，构建命令、测试方式、代码约定适合放进去，所有历史决策却不适合一直往里堆。

例如「结账验证码导致订单下降 5%，所以回滚」就属于历史。这里的 5% 是原文举例，没有实验过程，不能当作作者团队的业务数据。

auto memory 还有共享边界：它留在一台机器上，不会自动同步到其他机器、云端会话或队友环境，也不会被 Codex、Cursor 等其他代理直接读取。

工作规则可以精简常驻，项目经历需要按需取回。

此外，文件里的旧结论不会自行失效。方案改变后，如果没人修改旧记录，新旧要求就可能同时存在。

共享账本怎样接上一次会话

RepoMemory 是一个 MCP server，用来存放决策、教训、约束、笔记和任务。作者设计的使用节奏很明确：

• 会话开始调用 brief，取得全部有效约束、未完成任务，以及最新决策和教训。
• 计划修改、删除看似无用的代码，或重试某个方案前，调用 recall 检索相关记录。
• 遇到回滚、复杂排障或方案取舍后，调用 record_entry，记录发生了什么、为什么，以及接下来该怎么做。

这套机制的价值在于，历史可以持续积累，每次只取当前任务相关的部分。不过，brief 仍会完整返回所有有效约束，约束数量增长后，依然需要治理。

下面的命令把 RepoMemory 接入 Claude Code：

   claude mcp add --transport http repomemory https://api.repomemory.dev/mcp \
     --header "X-API-Key: $REPOMEMORY_KEY"

要注意 --header 这一行：连接使用 X-API-Key，密钥来自环境变量 REPOMEMORY_KEY。

连接完成还不够。作者要求在仓库的 CLAUDE.md 或 AGENTS.md 写明项目名，例如 acme/shop，并约定上述调用时机；写入时用 kind 区分 lesson、decision，在 agent 中注明记录者。

这一步才让工具进入日常工作流程。代理不会因为多了一个可调用工具，就自动留下有用记录。

接入方便，检索和维护仍有边界

作者还提供了合并初始化入口，要求 Node.js 22 或更新版本：

   export REPOMEMORY_KEY=sk_live_...
   npx @plexsicity/repomemory init

注意第一行的 sk_live_... 是示例占位值，需要换成实际密钥。原文还展示了直接请求 /v1/brief 的方式，以 JSON 中的 project 指定项目。

检索能力需要打个问号。原文明确说，recall 匹配的是词，而非语义：captcha checkout 可以找到标题为 Captcha on checkout 的教训，但 why did orders drop 未必能找到。

所以，记录里最好保留稳定的模块名、功能名和失败原因。否则，人觉得相关的两段描述，工具未必能联系起来。

服务限制也要算进去：RepoMemory 仅提供托管服务，免费计划每月允许新增 300 条记录，recall、claims、retires 免费。原文没有展开后两者的具体行为，也没有说明决策冲突和过期记录如何自动处理。

我的判断

我认同三层分工。把「怎么工作」和「为什么走到今天」分开，比让 CLAUDE.md 无限增长更容易维护；多人、多代理协作时，共享项目经历也有明确用途。

但文章证明的是方案能怎样组织，没有证明 RepoMemory 比仓库里的决策文档、问题记录或普通文档检索更有效。它没有给出检索命中率、任务成功率或节省时间的对照数据，应当按作者的设计经验看待。

还要区分「记录了约束」和「保证约束生效」。配置中的「Never break a guardrail」仍是给模型的指令。涉及构建正确性和关键行为的要求，仍需由测试、CI 或权限机制落实。

能拿来做什么

• 先整理仓库的 CLAUDE.md，把构建、测试、代码约定保留下来，将长篇回滚经过移到可检索的历史记录中。
• 给反复被 AI 提议重做的方案留下教训，写清模块名、失败原因和替代做法，并约定改动前先检索。
• 如果团队混用 Claude Code、Codex 和 Cursor，先确认各客户端都能访问同一账本，并配置调用时机。
• 小团队可以先用仓库文档验证记录习惯；确实出现跨会话遗漏、多人重复踩坑后，再评估托管账本的接入成本。