记忆分层：公开的、私人的、别再加新的
团队结论进 git，个人判断留私人记忆，不要让存储越来越多
记忆只分两层：团队要遵守的结论进 git（ops 仓和代码仓的 docs/，走 PR 审查）；个人的判断和偏好留在私人记忆（自动记忆、ops agent 的 memory/）。现有的五个存储已经够用，不要再引入第六个。同一个组织的所有仓库，共用一个自动记忆目录。
五个存储，各放什么
| 层 | 存储 | 谁写 | 放什么 |
|---|---|---|---|
| 公开 | ops 仓 | 人和 agent，经 PR 审查 | ADR、playbook、复盘、红线 |
| 公开 | 代码仓 docs/ | 人和 agent，经 PR 审查 | spec、plan、跟代码绑定的 runbook |
| 私人 | 自动记忆 | Claude 自己 | 你纠正过它的事、你的偏好、项目里的小经验 |
| 私人 | ops agent 的 memory/ | ops agent | 你对组织事务的个人判断 |
| 可选 | 一个跨项目的记忆 MCP | 视工具而定 | 需要跨组织检索的东西 |
自动记忆是 Claude Code 内置的：每个项目一个目录，默认在 ~/.claude/projects/<项目>/memory/。索引文件 MEMORY.md 每次会话开始时只加载前 200 行或 25KB，超出的部分不会加载；具体的主题文件按需读取（见官方文档）。
公开还是私人：问一句
这条结论，别人也需要遵守吗？ 需要，就进 git：写成 ADR、playbook 或 runbook，经过审查。不需要，只是你的判断、倾向或还没验证的猜测，就留在私人记忆。
几个例子：
- “生产发布必须人工确认”：公开。写进 ops 仓的红线，再落成 ask 规则
- “方案只给一个推荐、一个替代，不要平铺三四个”：私人。这是我的偏好，不是团队规则
- “这个上游项目每次大版本都会改 Makefile”：先放私人记忆；同样的事出现第二次，就升级成 runbook 和 CI 检查
私人记忆不经审查，里面可能有过时甚至错误的结论。这对个人无所谓，但不能拿它来约束团队。
别再加第六个存储
工具总在给你新的地方存东西：gstack 的 /learn 记项目经验，Matt Pocock skills 会在仓库里维护术语表 GLOSSARY.md 和 ADR，各种记忆插件也各有一套。每多一个存储，就多一个要搜的地方、多一份会过时的副本。同一条经验散落在三处，谁也说不清哪份是对的。
规则是：要么不用，要么明确它替代谁。 比如决定用 GLOSSARY.md 当领域术语表，ops 仓里就不再另写一份术语表。
经验的复利只走一条路：
反馈记忆（私人） → playbook / runbook（公开，经审查） → hook / CI（自动生效）每往上走一级，就把下一级那条删掉，或者改成一句指针。
同一个组织，统一一个记忆目录
自动记忆按 git 仓库区分：同一个仓库的所有子目录和 worktree 共用一个；不在 git 仓库里时，按启动目录区分。这意味着，在组织的父目录启动和在某个子仓库里启动，看到的是两套完全不同的记忆。
我就是这样踩的坑：在组织父目录启动，有 200 多条自动记忆；在子仓库里启动，只有 8 条。两边互相看不到，同一个坑反复踩（见同一个组织的记忆不要按目录分裂）。
做法：在这个组织每个仓库的 .claude/settings.local.json 里，把 autoMemoryDirectory 指向同一个目录。路径必须是绝对路径，或者以 ~/ 开头：
{
"autoMemoryDirectory": "~/.claude/org-memory/<组织名>"
}放 settings.local.json，而不是进 git 的 .claude/settings.json，有两个原因：这是你本机的路径，不该强加给协作者；而且较早的版本不接受项目级 .claude/settings.json 里的这个设置（新版文档已改为信任目录之后生效）。
切换之前，先把几处已有的记忆合并到新目录：主题文件直接拷过去，MEMORY.md 手动合并、去重。合并时顺手清理一遍，因为索引只有前 200 行会被加载，条目越多，排在后面的越容易被截掉。
记忆和 runbook 双写的代价
同一条经验，如果既在记忆里、又在 runbook 里，迟早会不一致：runbook 随代码更新了，记忆里还是旧说法。更麻烦的是，MEMORY.md 每次会话都会加载，runbook 只在需要时才读，两边冲突时，agent 更容易照着过时的记忆做。
所以经验升级成 runbook 之后，把记忆里那条改成指针：
- 本地数据库恢复：以 docs/runbooks/db-restore.md 为准，这里不再记步骤有人说“之前是这样的”，道理也一样：记忆可能是错的，git 历史才是事实（见“之前是这样的”先查 git）。
可选：一个跨项目的记忆 MCP
如果你需要跨组织检索，比如“另一个组织遇到过类似的问题吗”，可以加一个跨项目的记忆 MCP。它算五个存储之一，不是第六个，前提是分工清楚：它负责跨项目检索，不和自动记忆存两份一样的东西。