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 條裡已經看到幾個可以動的地方。你的幾條呢?