handoff 這題目,2026 上半年已經被寫到爛了 —— CLAUDE.md、/handoff skill、各種 handover prompt 模板,社群幾十篇文章蓋掉了大半地圖。

我自己做了兩遍才弄出一套堪用的,發完之後對著別人的 prior art 一條條比對,發現大部分都是別人寫過的。但有五個地方,我還沒看到誰提過。記下來,給有同樣縫的人。

先快速複述大家寫的 handoff 怎麼運作:上一場結束,把這場做了什麼、下場該接什麼,寫成一份 doc,存在 repo 裡或貼進下一場開頭。下場 Claude 讀完 doc 就懂 context。乾淨、省 token、社群有現成 skill 可用。

這套對 engineering session 順得很。但我拿來跑「閒聊型」對話就會卡 —— 一場可能聊 5～10 個碎話題,每條都寫進正式 handoff 太重,不寫又會掉。下面五個 delta,都是從這條縫長出來的。

1. 一份 handoff 不夠,缺一層「熱快取」

現有的 handoff 把所有 cross-session 資料都丟在同一層:寫一次、下場讀一次。

但實際工作流裡,cross-session context 有兩種不同的生命週期:

• 長期事實（這個專案在做什麼、我這個人是誰、規矩、過去的決定）→ 屬冷存,跨週跨月留著。
• 本場剛聊到哪（剛收完哪攤、現在正 mid-topic、上一句的指涉物是誰）→ 屬熱快取,下一兩場可能還會用到,再下下場就過期。

把這兩種混在同一份 doc 會出問題:要嘛冷存被熱資料污染（一週後翻舊 handoff,看到一堆「我們剛在聊 X」,沒人記得 X 是什麼了）;要嘛熱快取被冷存的格式拖累（為了「現在聊到哪」這種一行小事去更新正式 doc,重得不想動）。

我的拆法是兩個檔案:

• 一份永久 handoff:冷存、正式、跨場留。
• 一份單場速記板:熱快取、輕、放在 tmp 資料夾、檔名帶日期 + session 代碼。

進場順序也分:要接話 → 只讀速記板末 1～2 條（夠定向）;要查更深的背景 → 才翻永久 handoff。板等於記憶體,handoff 等於硬碟。

2. 速記板用完不自動丟、也不自動留 ——「人」決定

ephemeral memory 跟 persistent memory 中間有一塊缺口沒人填:寫一次、場末由人工決定下場留不留。

我的設計:

• 一場一張,檔名綁日期 + session 代碼。
• 場末作者親自看:整張留給下場 / 摘幾條摺進永久 handoff / 整張丟。
• 不自動 promote 到長期記憶,也不自動 expire。

理由很單純:「下場 Claude 該不該知道這條」這個判斷,目前自動化做不準。寧可花 30 秒人工 triage,也不要 false-promote 一堆雜訊去污染長期記憶。

這跟現在主流 memory 框架的方向相反 —— Mem0 那條路在做「自動萃取 + 衰退排序」,假設自動化能撈出重點。我的賭注是另一邊:對「閒聊型」這種低保真內容,人工 30 秒比演算法準。

3. 一個 anti-pattern:速記板自己的「施工 meta」不能當當下話題

第一次跨場實測,新場 Claude 進來讀速記板,看到最後一條寫的是「我們剛在設計這個速記板系統」—— 它就以為「我們現在還在設計這個 board」,整場卡在 meta、navel-gazing 半小時。

教訓很具體:速記板上面如果有個「當下標記」（我用一個 ←當下 小標籤）,場結束時必須手動拿掉,免得下場誤把上場的尾巴當成 ongoing。

更廣的版本是:任何寫給下場讀的 context,必須清楚標出哪些是「歷史紀錄」、哪些是「正在進行」,否則下場 Claude 會搞錯狀態,把已經收尾的東西當活的接下去。

這條我沒在 prior art 看到,可能因為大家寫的 handoff 都是 coding session —— session 末天然會 commit / 收 PR,狀態邊界清楚。閒聊型沒有這種天然 boundary,所以這個 bug 才會浮出來。

4. handoff 文獻 99% 都在 coding,沒人在做「閒聊型」

我搜遍了一圈 prior art,全部都是 engineering / coding workflow —— build status、failed approaches、git branch、next test、uncommitted changes。

但實際拿 LLM 來「日常聊天」、長期累積關係的人其實不少（個人助理、寫作搭子、思考夥伴、各種陪聊用法）。閒聊跨場的痛點跟 coding 不一樣:

• 內容比較碎、單條重要性低、不適合塞進正式 doc。
• 但情感連續度需求高（昨天聊到某個故事、今天接下去要記得）。
• handoff 寫太正式會把 tone 殺掉,讀起來像 status report,氣氛就斷了。

速記板比正式 handoff 更適合這種用法 —— 精簡、輕、可丟,氣氛保得住。這塊我覺得後面會慢慢被注意到,但到 2026 年中,還沒看到誰寫。

5. 真實動機是省錢,不是 productivity

handoff 文章普遍把動機包裝成「context 連續、品質提升、工作流順暢」。我的真實動機樸素得多:

長 marathon 對話每一輪都重嚼整包 context,是最燒 token 的姿勢。 一天頂到月度用量上限是真的會發生 —— 我有過一天就把月 cap 摸到頂、單日帳單大概在三百鎂上下的紀錄（金額是示意,別當精算）。

速記板讓新場用一張小紙就定向,不必每次都把整包永久 handoff + 長期記憶重吃一遍 → 換場便宜很多。

副作用才是情感連續、tone 不斷 —— 但動機順序是「省錢」先,「連續感」後。

把這個誠實寫出來,不是要 virtue signal,是因為:設計決策的動機如果包裝過,後面照著做的人會誤解你在優化什麼,然後做出別的東西。

Prior art 地圖

上面五點是我的 delta。下面是現有的 handoff / memory 文獻,看了會更清楚我站在哪:

handoff 主流寫法

• jdhodges〈Claude Handoff Prompt: How to Keep Context Across Sessions〉
• YAKStack〈I Built a /handoff Skill for Claude〉
• artemxtech〈Never lose your work between Claude Code sessions〉
• Kevin Manase〈handoff: the deliberate context reset〉
• Mejba Ahmed〈Handoff Skill: The Claude Code Workflow That Fixed My Context Bloat〉

工具 / skill

• mcpmarket Session Handoff Skill
• aihero.dev handoff skill
• Anthropic 官方 Claude Code /handoff

memory 架構（更上游的設計討論）

• Toolpod〈How Claude Actually Remembers〉
• Arize〈Memory and State in LLM Applications〉
• Serokell〈Design Patterns for Long-Term Memory in LLM-Powered Architectures〉

如果這幾類你看完覺得「這就是我要的」,那其實不需要再讀我這篇;上面五點是我撞出來、但 prior art 沒收的縫,留給有同樣縫的人。

這篇是我自己跑「閒聊型」長對話時撞出來的設計筆記。寫作過程有 Claude 協助 —— 這篇講的就是怎麼跟它換場接力,某種程度上算 dogfooding。

本文同步發表於我的筆記站。