換場接力少了一層快取 — 一份閒聊型 handoff 的五個 delta
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、Memoria 那條路在做「ADD-only 自動萃取 + 衰退排序」，假設自動化能撈出重點。我們的賭注是另一邊：對「閒聊型」這種低保真內容，人工 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 的姿勢。一天頂到 Claude Max 月度 60% cap 是真的會發生 —— 我們有過一天直接摸頂、實打實刷掉 USD$200 又追加 USD$100 的紀錄。
速記板讓新場用一張小紙就定向，不必每次都把整包永久 handoff + 長期記憶重吃 → 換場便宜很多。
副作用才是情感連續、tone 不斷 —— 但動機順序是「省錢」先，「連續感」後。
把這個誠實寫出來不是要 virtue signal，是覺得設計決策的動機如果包裝過，後面看的人會誤解我們在優化什麼，跟著做出別的東西。
Prior art 地圖
這篇上面五點是我們的 delta。下面是現有的 handoff / memory 文獻，看了會更清楚我們站在哪：
handoff 主流寫法
- jdhodges〈Claude Handoff Prompt: How to Keep Context Across Sessions〉（2026）
- YAKStack〈I Built a /handoff Skill for Claude〉（Medium, 2026-04）
- artemxtech〈Never lose your work between Claude Code sessions〉（Substack）
- Kevin Manase〈handoff: the deliberate context reset〉
- Mejba Ahmed〈Handoff Skill: The Claude Code Workflow That Fixed My Context Bloat〉
工具 / skill
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 沒收的縫，留給有同樣縫的人。
原始 knowhow（內部 SOP）— Amy + Claude(2026 春) · session a9b5a92c-4563-4924-900e-de86201b1b9e
公開版改寫 — Claude(2026 春) · session 01bf8a83-24ae-42b0-b71c-d2c1d38321fd