AI 跨 Session 記憶斷層 — 用 HANDOFF 模式讓每次對話都能接住上次進度
每次開新 session，Claude 都像換了一個人——上次花一小時討論的架構決策，這次完全不記得。這不是 AI 的缺陷，是你缺少一份跨 session 的交接文件（Handoff Document）。本文分享我用 HANDOFF 模式解決 AI 記憶斷層的實作經驗。
- Claude Code 的記憶機制（CLAUDE.md、Memory、–resume）各自解決不同問題，但沒有一個能處理「跨 session 的結構化專案狀態」。
- HANDOFF.md 借鏡軟體團隊的值班交接（Shift Handoff）模式，用四個區塊（完成了什麼、待決定、下一步、已知問題）讓新 session 零重複溝通地接手工作。
- 記憶管理的核心不是讓 AI 記住所有事，而是設計一個系統讓 AI 不需要記住所有事。
上週討論一小時的決策，這週 AI 完全不記得
我每週只有 5-8 小時做 side project——正職加上讀 MBA，能用的時間分散在好幾天。每次打開 Claude Code 開新 session，上一次的對話歷史完全不在。
這不是偶爾的不方便，而是反覆浪費時間。gwarket-site 專案裡，我花了一個小時跟 Claude 討論為什麼選 Next.js SSG 而不繼續用 WordPress Elementor（原因是後面要嵌入 RAG demo 等互動功能，page builder 會有相容性問題）。下次開 session，Claude 不知道這個決策，又建議我用 Elementor。blog-writer 專案也一樣——轉寫過的文章觀點，下次轉寫時完全不記得，可能寫出重複的比喻或矛盾的判斷。
最浪費的是重踩已知的坑。兩個專案都試過行不通的技術方案，沒有記錄下來，新 session 又走一次同樣的彎路。
如果你讀過上一篇文章，會知道 Claude Code 在單次 session 內就有 context 管理的挑戰——200K token 的上下文窗口（Context Window）在使用率達到約 92% 時會自動壓縮，早期決策可能被摘要掉。但那篇講的是「單次 session 內的遺忘」。這篇要處理的是更根本的問題：session 之間的記憶完全斷裂。
Claude Code 四種記憶機制各自能做什麼、不能做什麼
Claude Code 其實有好幾種「記憶」機制，但每一種都有明確的局限。理解這些局限，才能知道缺口在哪裡。
CLAUDE.md：員工手冊，不是工作日誌
CLAUDE.md 是 Claude 每次 session 開頭都會讀取的設定檔。根據 Anthropic 官方最佳實踐，它的定位是放「Bash commands Claude can’t guess」和「code style rules that differ from defaults」這類持久性規則。你不會在員工手冊裡寫「目前專案進度到第三步」——那是工作日誌的事。把進度資訊塞進 CLAUDE.md，只會讓它越來越臃腫，稀釋真正重要的規則。
Memory / Auto-memory：零散的碎片，不是完整的脈絡
Claude Code 會自動記住一些 learnings，例如 build 指令、debug 技巧、使用者偏好。但這些是零散的片段，不是結構化的專案脈絡。它記得「npm run build 要加 –output export」，但不記得「我們上次討論後決定先做首頁再做文章頁」。Memory 解決的是「怎麼做」的知識延續，不是「做到哪了」的狀態追蹤。
–resume / –continue：回到過去，但過去可能已經模糊
Claude Code 支援 claude --continue（回到最近的 session）和 claude --resume（從歷史 session 中選擇）。Shrivu Shankar 的使用經驗提到，他會 --resume 幾天前的 session 來請 Claude 摘要當時怎麼克服某個錯誤。但他也指出，這些 session 在被壓縮後，早期的重要決策可能已經被摘要掉了。而且你不一定記得是哪個 session——當你有三個專案、每天開好幾次，要找到「那次討論架構的 session」本身就是一個負擔。
Skills：任務知識，不是動態狀態
Skills 解決的是「怎麼做特定任務」的知識延續，例如輸出格式規
這四種機制加起來，覆蓋了規則、碎片知識、歷史對話、任務知識。但沒有一個能處理「結構化的專案進度與決策脈絡」。這就是需要 HANDOFF 填補的缺口。
HANDOFF 模式：從軟體團隊的值班交接借來的解法
概念來源其實很直覺。軟體工程團隊的值班交接（Shift Handoff / Incident Handoff）——值班的人交班前，會留一份「發生了什麼、處理到哪、下一個人要注意什麼」的紀錄。我把同樣的邏輯套用在 AI 協作上。
四個區塊，各自解決一個問題
我的 HANDOFF.md 結構很簡單：
HANDOFF — [日期]
## 完成了什麼
## 待決定的事項
## 下一步建議
## 已知問題每個區塊的設計邏輯：
- 「完成了什麼」→ 新 session 不用問「我們做到哪了」
- 「待決定事項」→ 避免重新討論已經討論過但還沒定案的事
- 「下一步建議」→ 直接切入工作，不用花 20 分鐘暖場
- 「已知問題」→ 不踩已知的坑
這跟 Shrivu Shankar 提出的「Document & Clear」模式是同一個思路——把 Agent 的進度和策略存到 markdown 檔，/clear 重置 context，下次讓 Claude 讀那份文件就能繼續工作。他的原則是「treat every session as disposable」，把重要資訊外化到檔案系統，不依賴 session 的內部記憶。
實際效果：零暖場直接從斷點接手
gwarket-site 重構完架構後，HANDOFF.md 記了 4 個已完成頁面、IA 方案待定、WordPress API 串接待設計。下次開 session，Claude 讀完 HANDOFF.md 就能直接從斷點接手。沒有「你之前有看過這個專案嗎？」的暖場，沒有重複討論 Next.js vs Elementor 的決策，直接進入下一步工作。
以 token 成本來算，一份 HANDOFF.md 大約 200-400 token。相比之下，一個 monorepo 的 session 光是基礎載入就要 約 20K token。用不到 2% 的 context 成本，換來零重複溝通的 session 銜接，這筆帳怎麼算都划算。
同一個模式的延伸應用
同樣的「跨 session 記憶」邏輯，我套用到其他地方：
article-log.md — 每篇文章轉寫完自動追加記錄（日期、標題、來源、核心觀點、用過的比喻）。下次轉寫時 Claude 掃一眼就能避免重複觀點。不是記住整篇文章的內容，只記「寫過什麼」的索引。
writing-style Skill 的範例段落 — 解決「風格漂移」問題。Claude 不需要「記得」你的寫作風格，它每次重新讀範例就好。這比靠記憶穩定得多。
本質上都是同一個模式：把跨 session 需要延續的資訊，用最精簡的結構存下來，放在 Claude 每次都能讀到的地方。
我的觀點
做完這套機制之後，我越來越覺得人跟 AI 協作的瓶頸，正在從「AI 不夠聰明」轉移到「人不會管理 AI 的記憶」。大多數人花時間研究怎麼寫更好的 prompt，但如果你是利用碎片時間做 side project 的人——下班後學習、一邊讀 MBA 一邊轉職——記憶管理比 prompt 技巧重要十倍。因為你的工作一定會被 session 打斷，而每一次斷裂都是效率的漏洞。
HANDOFF 也不是 Claude Code 專屬的概念。任何有 session 中斷問題的 AI 工具都適用——ChatGPT 的對話會超出 context、Cursor 切換專案會丟失脈絡、Copilot 每次開 IDE 都是全新開始。只要你的 AI 工具會「失憶」，你就需要某種形式的交接文件。
跟上一篇的底層邏輯一致：好的 AI 協作不是靠 AI 記住所有事，是你設計一個系統讓 AI 不需要記住所有事。你不是在「用工具」，你是在「設計一個讓工具穩定運作的系統」。HANDOFF 只是這個系統裡最簡單、投報率最高的一塊。
HANDOFF.md 應該寫多長？
越短越好，通常 20-40 行、200-400 token。只記「下一個 session 需要知道的事」，不記過程細節。如果 HANDOFF.md 超過一頁，代表你把工作日誌和交接文件搞混了——日誌歸日誌，交接只記結論和下一步。
HANDOFF.md 要手動寫嗎？能不能讓 Claude 自動產生？
可以讓 Claude 在 session 結束前自動更新。在 CLAUDE.md 加一條規則：「每次完成重要工作後，更新 HANDOFF.md」。也可以設 Hook 在特定時機自動觸發。但建議人工快速過目確認，因為 Claude 可能漏掉你心裡還沒說出口的決策。
HANDOFF.md 跟 Claude Code 的 Memory 功能有什麼差別？
Memory 記的是零散的知識片段（build 指令、偏好設定），是「怎麼做」的知識。HANDOFF.md 記的是結構化的專案狀態（做到哪、下一步是什麼、有什麼坑），是「做到哪了」的進度。兩者互補，不是替代關係。
本文為 gwarket 原創內容，作者 Aaron Huang。本文是「Claude Code 六層架構」的續篇，聚焦跨 session 的記憶管理。