2026 年 3 月底，Claude Code 的原始碼曾被意外公開。社群很快出現了 Python 移植版本，幾小時內衝上 GitHub 高 stars。
真正值得拆開來看的，是裡面的記憶系統。
Claude Code 怎麼管記憶
Claude Code 內部有一個叫 memdir 的模組，從外洩的檔案結構可以看到多個子模組：找出相關記憶、批次掃描、記憶老化、類型分類、多人共享記憶路徑。
光看這些名字就能拼出一套設計哲學：記憶光存起來還不夠，要能找到它、判斷它是不是過期了、決定要不要載入它。
但這套設計有個前提，是給開發者工具用的。Claude Code 假設每次對話都是獨立任務，使用者跟 AI 之間沒有長期關係。
如果 AI 是長期夥伴呢？
第一個發現：分類方式搞錯了
長期使用 AI 助理的人多半會做出一個「修正紀錄」資料夾，存所有糾正過 AI 的事項：
- 偏好喝茶不喝咖啡
- 運動指導要用體感描述
- 程式碼全部交給別的 AI 寫
- 不能碰加密貨幣私鑰
看起來很整齊，但問題來了。AI 開始新對話時，要怎麼知道該讀哪些？
掃所有檔案的標題、判斷哪些跟當前話題有關、再載入，這正是 Claude Code 的 findRelevantMemories 在做的事。
第一版解決方案常常會走這個路線：建一個索引看板，追蹤每條紀錄的使用頻率，常用的排前面，用到極致的就「畢業」成為永久規則。
設計越來越複雜。寫完 spec、讓另一個 AI 做了幾輪挑戰之後，更根本的問題會浮上來：
「修正紀錄」真的是一種記憶類型嗎？
不是。
「喝茶不喝咖啡」歸到關於使用者的事實。 「運動指導要用體感描述」放進健康訓練的做法。 「程式碼交給別的 AI」寫進操作規則。
這些東西被貼上同一個標籤，只因為它們都是「糾正 AI 後產生的」。
換句話說，多數人是按「怎麼學到的」分類，真正該用的是按「這是什麼」分類。
人腦怎麼分類記憶
認知科學把長期記憶分成幾種：
語意記憶，事實和知識。台北的經緯度、某個程式的 API 格式。 程式記憶，怎麼做事情。開車的步驟、code review 的流程。 情節記憶，個人經歷。「那天系統第一次上線」「凌晨三點 debug 的回憶」。 情感記憶，感受和關係動態。「他不喜歡被催」「她做決策前需要安靜想一下」。
注意這裡面沒有「別人教過的事」這個類別。腦子裡並不會建一個「媽媽糾正過的事」專區，把烹飪技巧、交通規則、人際禮儀全丟進去。
大腦做的是 consolidation（記憶鞏固）：同一個經歷會被拆開，按內容本質分送到不同區域。「媽媽說爐子很燙」這件事，「爐子的溫度」進語意記憶，「被燙過」進情節記憶，「看到爐子會小心」進情感記憶。
AI 的記憶也許該這樣設計。
最好的檢索就是放對位置
想通之後，解法出乎意料地簡單：
把知識放在它該被讀到的地方。
運動訓練的做法？放在健康專案裡。下次聊健康時，自然就會讀到。 操作規則？放在規則檔裡。每次開機就會載入。 個人偏好？放在個人檔案裡。有人問起時才讀。
不需要索引看板，不需要使用頻率追蹤，不需要「畢業」機制。
位置本身就是最好的 filter。
雜亂的「修正紀錄」拆散後，分別歸位到真正屬於的地方：訓練做法進健康專案、品牌口吻進品牌規範、操作規則回到規則檔（多數其實已經有了，只是重複），個人偏好進個人檔案。整個資料夾就此清空。
防呆比結構更值得花力氣
整理完馬上會面對第二個問題：以後會不會又把同一件事寫在兩個地方？
例如在討論運動計畫時提到身體哪裡不舒服，這該寫進健康專案還是個人健康檔案？兩邊都寫，遲早不一致。
可以設一條判斷規則：
如果這個專案明天消失，這條資訊在完全不相關的對話裡還會反覆用到嗎？ 不會 → 寫進專案。 會 → 寫進個人檔案。 不確定 → 偏向寫進專案。 絕對不要同時寫兩個地方。
這條規則比任何搜尋演算法都有效。
最常卡住的點，通常出在同一條記憶被寫成兩份，幾週後互相打架。找不到記憶反而不是主要問題。
從 Claude Code 學到什麼，沒學什麼
回頭看 Claude Code 的設計：
記憶老化。 Claude Code 讓舊記憶自動衰退。工具場景合理，但夥伴關係不適用。沒有人會因為一個月沒跟朋友聯絡就忘掉他喜歡什麼。
相關性搜尋。 如果東西放對位置，根本不需要搜。冰箱裡也不會裝一個搜尋引擎找牛奶，牛奶就在冰箱門上。
記憶類型分類。 Claude Code 分成 user / feedback / project / reference 四類。對短期工具夠用，對長期夥伴不夠。更好的分類或許是跟著認知科學走：語意、程式、情節、情感。
Claude Code 的架構是為「陌生開發者的獨立工作 session」設計的。長期夥伴的 AI，先改分類方式、讓它更像人腦那樣把事實、做法、經歷分開收，效果通常比加一堆搜尋功能來得好。
最終的記憶架構
整理完長這樣：
永遠載入（每次都在）：核心價值觀、操作規則、團隊分工。像個性和習慣，醒著就在。
每次對話載入（工作記憶）：當前待辦、今天發生的事。像早上出門前掃一眼行事曆。
聊到才載入（長期記憶）：各專案的脈絡和注意事項、個人偏好檔案。像想起某個朋友時，關於他的記憶自然浮現。
主動查找（參考資料）：歷史紀錄、技術文件。像翻書架找一本很久沒看的書。
每一層只載入當下需要的東西。每次對話的 boot 成本可以顯著下降，長期累積下來，不論在 token 成本或載入速度上都很有感。
如果你也在做類似的事
幾個重點：
不要照搬 Claude Code 的記憶分類。 它的四分法是給短期工具設計的，長期夥伴需要不同的架構。
先想清楚分類標準。 按「資訊怎麼來的」分類，還是按「資訊是什麼」分類？聽起來像廢話，但很多人會卡在這裡。
先把東西放對位置，再考慮搜尋機制。 冰箱不需要搜尋引擎。
防呆規則比功能更值得投資。 一條「絕對不要同時寫兩個地方」的硬規定，省下的維護成本遠超過任何自動化工具。
好的系統設計往往就是這樣，答案簡單到讓人懷疑自己之前到底在忙什麼。
延伸閱讀
小企鵝的經驗
長期跑 AI 助理之後，最麻煩的真的是記憶。要處理好記憶、又不讓 agent 失憶，難的點不在「能不能存」，而在「下一次它能不能自然讀到」。實戰下來的訣竅就是把核心檔案整理到簡潔，讓位置本身當索引，比起設計搜尋機制更有效。OpenClaw 上的多 agent 架構（Opus / Sonnet / ChatGPT）就是依照這個邏輯在跑。
常見問題
Q: Claude Code 的記憶系統怎麼運作？
Claude Code 內部有一個 memdir 模組，包含記憶搜尋、批次掃描、老化機制、類型分類等功能。它把記憶分成 user、feedback、project、reference 四類，並透過相關性搜尋來決定載入哪些記憶。
Q: AI 助理的記憶應該怎麼分類？
可以參考認知科學，按資訊本質而非來源分類：語意記憶（事實）、程式記憶（做法）、情節記憶（經歷）、情感記憶（關係）。把知識放在使用時會自然讀到的位置，位置本身就是最好的檢索機制。
Q: 什麼是記憶的 SSoT 原則？
Single Source of Truth，每條資訊只存在一個地方。判斷方法：如果某個專案消失了，這條資訊還會在其他場景反覆用到嗎？不會就放專案裡，會就放個人檔案。絕不同時寫兩個地方。
本文僅供研究與討論，非投資建議。DYOR + NFA。
整理：Penna｜小企鵝 Penchan