我最近發現 Claude Code 的新功能 Auto-memory，讓我驚喜不已！這個功能能夠自動記錄對話中的重要資訊，讓每次的 session 都能無縫接軌。過去我總是得手動記錄，現在 Claude Code 自己就能將記憶整理得井井有條，讓我輕鬆專注於工作。這項設計既像是人類的工作記憶與長期記憶的結合，又能自動整理出重點，真的是解決了我長久以來的痛點。我迫不及待想和大家分享這個功能的趣味與應用！
// TABLE OF CONTENTS
// TABLE OF CONTENTS
我真的受夠所謂的上下文腐爛了
最近這幾天開始任真的研究 Claude Code SDK，研究怎麼用 hooks 實作跨 session 的記憶機制，想讓 AI 每次對話結束後自動把重要資訊存下來，下次開 session 就能接著用（我知道其實很多人做了，但我都用不習慣，甚至我還裝過有點顯得臃腫的 Serena MCP ，雖然那是不一樣概念的東西 XD )。
研究到一半，看到今天最新的 release notes。
v2.1.59 寫了：
Claude automatically saves useful context to auto-memory. Manage with /memory.
又往前翻到 v2.1.32：
Claude now automatically records and recalls memories as it works.
我愣了一下。好，所以我剛才在做的事，Claude Code 自己已經做了。那我繼續幹嘛（笑）
這篇就來聊聊這個功能到底在幹麻，以及我覺得它有趣在哪裡。
它解決了什麼問題？
先講一個很真實的痛點。
用 Claude Code 工作久了，你會發現每次開新 session 或是壓縮後，Claude Code 就像得了失憶症一樣。會喪失部分的記憶，當然可以使用一些技巧，自動產生文件，每次去讀取。
是時尚，這不是 Claude 的問題，語言模型就是這樣，天生沒有跨 session 的記憶。
以前推薦的解法是靠 CLAUDE.md，把所有重要資訊手動寫進去，每個 session 開始自動載入。但這要你自己去維護，忘了更新就會過時。
Auto-memory 的概念就是：讓 Claude Code 自己記筆記。
具體它做了什麼？
工作的過程中，Claude Code 會自動把它覺得值得記住的東西寫下來，存到一個固定位置：
~/.claude/projects/<專案路徑>/memory/
├── MEMORY.md ← 索引，每次 session 開始自動載入前 200 行
├── debugging.md ← 主題分類的詳細筆記
└── patterns.md ← 其他主題
MEMORY.md 就像一本書的目錄，把重要的事情整理成索引放在前面。如果某個主題資訊量很大，它會另開一個主題檔案（比如 debugging.md）把細節放進去，MEMORY.md 只留一個連結。
每次新 session 開始，前 200 行的 MEMORY.md 會自動被載入，Claude Code 就有了「上次工作留下的脈絡」。
它會記什麼？大概是這幾類：
這個專案的 build / test / deploy 指令
常踩的坑和解法
架構上的重要決定（「這個 module 不要動，因為...」）
你的工作習慣和偏好
我覺得很有趣的地方
這個設計讓我想到一個概念：工作記憶 vs 長期記憶的分工。
人類在工作的時候，有一塊「工作記憶」負責處理當下的資訊，同時大腦也在背後偷偷整理，把重要的東西慢慢寫進長期記憶。隔天起床，你不記得昨天開會說的每一個字，但你記得「那個 bug 是 race condition 造成的」這個結論。
Auto-memory 在做的事情很像這個。context window 是工作記憶，session 結束後寫下來的筆記是長期記憶，下次 session 讀進來的前 200 行是「提取出來使用」的過程。
有點迷你的認知科學模擬，感覺蠻好玩的 XD
而且這個設計有一個我很喜歡的細節：上限是 200 行。就是逼你筆記要精簡，不然超過部分根本不會被載入。Claude Code 會自己把重要的事情整理成摘要，細節才放到分類檔案裡。
這跟人類的長期記憶很像，我們記住的通常是「事件的本質和教訓」，不是「所有細節的逐字稿」。
怎麼管理？
用 /memory 指令會跳出一個選單（這個指令其實在 v1.0.94 就有了，當時是用來手動編輯 CLAUDE.md，比 auto-memory 早很多），可以：
直接編輯
MEMORY.md和其他記憶檔案切換 auto-memory 的開/關
記憶檔案都是普通的 Markdown，你可以直接改。也可以直接跟 Claude Code 說：「把這個記下來」「把 XX 從記憶裡刪掉」，它會自己去改檔案。
想關掉的話，有幾種方式：
全域關閉（所有專案都關）：
// ~/.claude/settings.json
{ "autoMemoryEnabled": false }
單一專案關閉：
// .claude/settings.json
{ "autoMemoryEnabled": false }
環境變數（適合 CI 環境）：
export CLAUDE_CODE_DISABLE_AUTO_MEMORY=1
等等，那 CLAUDE.md 跟 auto-memory 到底什麼關係？
這個問題我自己也搞混過，實際測了一輪才搞清楚。
簡單說：CLAUDE.md 可以是你寫的指令，auto-memory 是 Claude Code 寫的筆記。 兩個是完全獨立的東西，存在不同的地方，載入的方式也不一樣。
CLAUDE.mdauto-memory MEMORY.md誰寫的你自己手動維護Claude Code 自動記錄存在哪裡~/.claude/CLAUDE.md 或專案根目錄~/.claude/projects/<專案>/memory/載入方式每次 session 全部載入只載入前 200 行定位系統指令，模型當作規則遵守工作筆記，模型當作參考資料
那如果兩邊寫了矛盾的東西呢？
我實際測過，答案是：沒有明確的優先順序。兩邊都會被載入 context，模型看到矛盾的指令，行為就不可預測了，看它當下怎麼解讀。
所以我自己的結論是這樣分工：
硬規則放
CLAUDE.md（比如「commit message 用英文」「不准用某個 API 之類的 」）工作筆記讓 auto-memory 處理（比如「這個專案的 build 指令是 pnpm dev」「上次那個 bug 是 race condition」）
舉個我自己踩到的例子：我有一條規則是「公開文章裡不准出現私人暱稱」。一開始我寫在 auto-memory 裡，後來想想不對，這是硬規則，不是工作筆記，萬一哪天 auto-memory 被整理掉了就沒了。最後搬到 CLAUDE.md 才安心。（對啦，我自己開始用 Claude Code 做的第一件事情當然是給它暱稱，還有叫我的暱稱，怎樣 XD ）
一個簡單的判斷方法：如果這條規則被忽略會造成困擾，放 CLAUDE.md。如果只是「知道比較好」的背景資訊，讓 auto-memory 記就好。
那 /resume 和 JSONL 又是什麼？
研究 auto-memory 的過程中，我一度搞混了好幾個「記東西」的機制。Claude Code 裡面至少有三層東西都在存資料，但它們做的事情完全不一樣。
先講 JSONL。每次你跟 Claude Code 對話，所有的來回（你說了什麼、模型回了什麼、用了多少 tokens、什麼時間點）都會被存成一個 .jsonl 檔案，放在 ~/.claude/projects/<專案>/<session-id>.jsonl。這是最底層的原始紀錄，你平常不會去碰它，但它是其他功能的基礎。
然後是 /resume。當你想接續之前的對話（比如「昨天討論到一半的那個 bug，我要接著聊」），/resume 會從 JSONL 裡面把那次 session 的對話 context 還原回來，讓你繼續。
最後是 auto-memory。它不是還原對話，是從工作過程中萃取知識。不管你開哪個 session，這些知識都會自動帶著走。
用一個比喻來說：
JSONL 是監視器錄影，完整記錄了所有事情，但你不會每天回去看
/resume是倒帶播放，回到某一天的錄影繼續看auto-memory 是看完錄影之後寫的重點摘要，不管看哪段新的錄影都會帶在身上
JSONL 對話紀錄/resumeauto-memory記什麼API 來回的原始資料從 JSONL 還原對話 context從工作中萃取的知識存在哪<session-id>.jsonl讀取 JSONL（不另外存）memory/MEMORY.md誰用系統內部你手動選 session 接續每次 session 自動載入生命週期跟著 session 走跟著 session 走跨所有 session
搞清楚這三層之後就會發現，auto-memory 是唯一一個「跨 session 自動帶著走」的機制。JSONL 和 /resume 都是綁定特定 session 的，離開那個 session 就沒了。
SDK 呢？
如果是用 Claude Agent SDK 開發，auto-memory 的機制跟 CLI 一樣，但有一個很容易忽略的地方。
SDK 預設不會自動載入 CLAUDE.md 或記憶檔案，要明確指定：
for await (const message of query({
prompt: "...",
options: {
systemPrompt: { type: "preset", preset: "claude_code" },
settingSources: ["project"] // 沒這行記憶就不會被載入
}
})) {
// ...
}
settingSources 可以放三個值："user"（使用者全域設定）、"project"（專案共享）、"local"（本地 gitignored）。要讀取 CLAUDE.md 和記憶檔案，最少要有 "project"。
這個細節我自己第一次用的時候就漏掉了，然後搞了一陣子才發現為什麼記憶沒有被載入 XD
我的實際觀察
坦白說，這個功能我用的時間還不長，auto-memory 的資料夾在我的主目錄下還是空的（因為這個「專案」就是 home 目錄，平常工作比較分散）。
但我覺得真正有感的應該是：長期在同一個專案工作的時候。
每天都在同一個 repo 裡開發，Claude Code 就會慢慢累積這個 repo 的知識，知道哪些函式不能動、知道你喜歡怎麼命名、知道這個服務的架構邏輯是什麼。不用每次都從頭交代。
這有點像是雇了一個新員工，前幾週什麼都要解釋，但待了半年之後，很多事情不說也懂了。只是 Claude Code 版本的「待了半年」可能是「開了一百個 session」的意思。
至於那個原本打算用 hooks 做記憶機制的計畫呢？
大部分場景不用了。內建的已經夠用，不用自己重造輪子（ 雖然我有時候是享受自己做東西的感覺 ）。
除非你有很特殊的需求，比如「記憶要同步到 Notion」或「session 結束後要把 summary 發到 Telegram，那才需要用 hooks 另外做。不然就直接用內建的就好。
說真的，我覺得 Claude Code 更新的速度有時候很讓人哭笑不得。你覺得自己想到了一個很聰明的解法，花時間研究，然後發現 Anthropic 三個月前就已經把這個功能做進去了，只是你沒注意到。
這大概就是跟上 AI 工具的代價吧：release notes 要勤讀，不然會一直在發明已經有輪子的東西，但我還是繼續再重複重複造輪子吧。（笑）
// RELATED POSTS
地端 AI 值不值得？九個講者給了九個答案：2026/8/19 AI 小聚心得
我參加了一場AI小聚，主題是「企業地端」，原本以為會聽到一個標準答案，結果九位講者給了九種互相碰撞的答案。有人把成本攤成試算表，有人發現硬體三個月漲七成，有人算漏了管線每一節都在收錢，也有人直接說地端不是首要重點。最讓我震撼的是臺大醫院的資訊工程師，他買GB10的理由很單純：因為對外線路被挖斷過，他不想再等35分鐘。那一晚我才真正理解，地端AI從來不是技術選擇題，而是你站在哪裡、看見什麼問題的視角差異。九個答案沒有對錯，只有位置不同。
Jackle 太變態了：七月 AI 小聚全對談心得
七月AI小聚讓我印象最深的，不是任何技術方案，而是一個畫面：每個人都在畫一條線——AI做到哪裡，人從哪裡接手。Jackle用六個Claude Max帳號、每天螢幕十八小時，一個人扛起整間公司的AI導入，甚至說Fable出來後不再請人；小馮靠矩陣合併讓六機剪片從四小時變二十三分鐘。但下半場Sunny問「起床第一件事是什麼」，又把焦點拉回人的本質。那條線每個人畫的位置都不一樣，而且一直在動。我開始反思自己的那條線畫在哪裡。
退回 4.6 的那天晚上，我其實有點不甘心
退回4.6那晚，我其實很不甘心。不是因為工具不好用，而是我分不清那個讓參數蒸發的bug，到底是模型沒生成，還是在我電腦上被組裝壞了。前者我無能為力，後者則有機會親手修復。於是我從binary裡挖出那段解析程式，終於確認：是客戶端的VH1在串流接縫處丟失了半截字串，導致工具參數整包變成空的{}。改兩個byte就能解決——我測試了760個案例，0個回歸。但改執行檔可能違反條款，每次更新還會被蓋掉。這不是教學，而是一個不甘心的人，親手把刀切下去的故事。
Opus 的 tool_use 蒸發 bug：9 天調查實錄，然後我退回了 4.6
在使用 Claude Code 的過程中，我遭遇了嚴重的 tool_use 蒸發 bug，讓我忍不住深入調查。從 4.7 到 4.8 版本，問題不斷出現，數據顯示故障率反而上升。最終，我選擇退回到 4.6，因為這個版本在多輪對話中沒有故障。這次調查讓我意識到，真正的問題出在模型變體的切換上，影響了思考到執行的過程。