memory 到底该记什么——把我的 5 条摊开 audit 一遍

上一篇讲 CLAUDE.md 只放 Claude 看代码看不出来的东西。有读者立刻问：那 memory 呢？memory 也是上下文，和 CLAUDE.md 到底什么区别？

很多人用着用着就把 memory 当 CLAUDE.md 的"补充备份"——想到什么就塞一条。时间一长，memory 越堆越多，Claude 每个 session 都读一遍，结果基于过时信息做判断。

这篇不讲抽象定义，我把这个项目当前真实运行的 5 条 memory 打开，逐条 audit——哪些该留、哪些该删、哪些根本不该进 memory。顺便回答 CLAUDE.md vs memory 这个问题。

一句话区别

• CLAUDE.md 进每个 session 的 system prompt，静态，适合不变量。
• memory 由 Claude 主动读写，动态，适合会变的事实 / 单次事件的沉淀。

真正有用的判断不是"放哪"，是"这条信息寿命多长、谁会改它"。

我的 5 条清单

feedback_commits               — 等我说 commit 再 commit
feedback_article_authenticity  — 实战文章不能编
project_i18n_strategy          — 所有语言同时上线的战略
project_howdev_plan            — how2claude.dev 未完成的实现方案
project_article_workflow       — 发文章流水线

按类型分组审一遍。

A 类：一次纠正换永久规则（feedback_commits）

内容很短："don't auto-commit, wait for user to confirm."

这是 memory 最高 ROI 的类型。单次纠正 → 跨 session 永久生效。

为什么不进 CLAUDE.md？ 它不是项目规则，是我个人工作习惯。别的贡献者加入项目，他们不一定要遵守同样的规则。CLAUDE.md 是团队级的，memory 是"我和 Claude 之间"的。

为什么不每次对话开头说一遍？ 因为跨 session 保留。Claude 下周帮我改代码时还记得。

触发条件很清晰：我纠正过一次，且希望永久生效。

B 类：带日期的事故档案（feedback_article_authenticity）

这条 body 里特别具体：

2026-04-16 写 multi-agent 收尾文章时，我凭想象编了一个"3 个 Agent 做 webhook 功能"的故事⋯⋯全是伪造。用户问"是真实的还是编的"——这和前两篇方法论文章不同⋯⋯

关键：Why 字段不是抽象原则，是具体事件 + 日期 + 当时发生了什么。

为什么这么写？六个月后回来看"实战文章要有真实素材"这种抽象规则会疑惑——啥时候定的、为什么定。看到"4-16 我编了个 agent 故事被抓"能立刻想起来，也立刻能判断这规则还适不适用。

这是我 5 条里最"重"的一条。它不仅是规则，还是供 Claude 和我都能查的事故档案。

C 类：策略决策背景（project_i18n_strategy）

内容：这个项目为什么激进上线所有语言——翻译成本通过 Claude 趋近于零，官方文档只有英文是核心机会窗口。

代码里看不出来。代码里只有 19 个 locale 文件。为什么是 19 个、为什么同时上、日语韩语为什么优先度高，全在我脑子里。

memory 把"脑子里的决策"沉淀下来，让 Claude 将来建议功能时能判断「这个提议和 i18n 战略冲突吗」。

不是操作规则（不进 CLAUDE.md），是战略背景（进 memory）。

D 类：跨 session 任务交接（project_howdev_plan）

这条最临时：how2claude.dev 开发者站 9 个待改文件的详细方案，结尾写着「待下次会话继续」。

memory 最危险的类型——容易变成僵尸 memory。实现完忘了删，下次 Claude 还拿它当 todo，基于过时计划建议"还没做 step 3"。

这类 memory 需要明确的退场机制：how2claude.dev 上线后，我必须立即手动删掉。

E 类：该删的那一条（project_article_workflow）

这条信息密度最高，我一度以为是最有用的——直到仔细看：

• /write-article 和 /publish-article 的存在 → 看 .claude/commands/ 就知道
• draft 目录结构（meta.json + lang.md）→ 看 docs/drafts/ 一眼就懂
• API URL → .claude/publish-config.json 里有
• Category/series slug 列表 → seed 文件里有

Claude 看代码全部能推出来。

真正 memory 能提供的只有最后一段「Accounts (production): zh → @how2claude, en → @howtoclaude」——而这条已经过时了，上个 session 发现生产实际是 zh=@howtoclaude。memory 记录的是几天前的状态，已经漂移。

结论：这条要删掉 90%，必要的部分（"用 kamal 查实时账号"）写进 CLAUDE.md 更合适，或者干脆不写——反正 memory 里写死的账号迟早过时。

4 个规律

1. memory 的真正作用是"给 Claude 开它进不了的房间"

• 进不了我的大脑 → 策略、偏好、为什么
• 进不了上周的 session → 我上次纠正过你什么
• 进不了三个月前的失败 → 具体事件 + 日期

2. Claude 能从代码看出来的，别进 memory

这和上一篇 CLAUDE.md 的原则一致。文件路径、API URL、目录结构——都是代码能回答的问题。懒得让 Claude grep 一次就塞进 memory，等于在赌这信息永远不变。

3. memory 会衰变

project_article_workflow 就是例子——几天前写的，账号信息已经不对了。memory 越老越不可信。定期 audit > 一直加。

4. Why 字段救命

对比我的两条 feedback 就看得出来：

• feedback_article_authenticity 的 Why 是「4-16 我写 multi-agent 文章编了故事」——6 个月后我能立刻判断还适不适用
• feedback_commits 的 Why 只有「user wants to review」——6 个月后我不确定这是哪次纠正的产物

后者比前者弱得多。抽象原则没人记得为什么要守。

决策树：CLAUDE.md vs memory vs 不写

新信息出现时，问三个问题：

1. 这条从代码能看出来吗？ 能 → 不写
2. 所有贡献者都要遵守吗？ 要 → CLAUDE.md
3. 随时间会变吗？ 会 → memory（带具体 Why + How to apply）

第三个问题是陷阱。大部分你想记的"不会变"的东西代码里能看出来，你只是懒得让 Claude 再 grep。

audit 之后看到的

过完一遍我看到几件事：

• project_article_workflow 里 90% 的内容 Claude 看代码能推出来，这条最该动
• project_howdev_plan 是临时任务交接，理论上该有退场机制
• project_i18n_strategy 是战略判断，过段时间值得回头审
• feedback_commits 的 Why 写得比较弱，补一个具体事件会更保险

顺带观察：我 5 条的 type 分布是 feedback×2 + project×3，一条 user 或 reference 类型都没有——这代表我还没跟 Claude 说过"我是谁、我从哪些外部系统读状态"。可能是下一批要补的。

结尾

memory 最大的陷阱不是「该记的没记」，是「记了一堆过时的」。5 条里只要 1 条漂移，Claude 就会基于过时信息做判断——而且它不会提醒你这条过时了。

我这 5 条里已经看到几个可以动的地方。你的几条呢？