當 AI 也會焦慮：我為什麼幫 Claude Code 設計了一張交班單
最近我對 Claude Code 的使用模式越來越像產線工頭交班。
開一個 session 從頭做到尾的工作流已經不太適合我，現在的模式比較像是：早上在 Mac Mini 上改 gmail-billing-scan skill 的 parser 以及 AI 故事機的模組，中午在筆電上回一個 coaching 相關的討論，下午切到 Gemini 跑一輪 competitive analysis 和 PM PRD 的 second option，晚上回到 Claude Code 繼續 debug。中間還可能換 subscription 帳號穿插在我自己個人帳號和公司的 team 帳號。
每次切換，我跟 AI 的 context 就都斷了（其實腦袋斷的比較厲害😂）。每次重來，都要重新解釋一遍「我在做什麼、做到哪裡、之前試過什麼」。這不是技術問題，這是工作流程的摩擦成本。
雖然 Claude Code 有 `--resume`，可以恢復 session。有 `/compact`，可以壓縮 context。有 Auto Memory，可以自動學習。但這些都沒解決我的核心痛點：跨裝置、跨 Agent、跨帳號的工作延續性。
然後我看到一篇文章，有人用一個極簡的方式解決這個問題：做了一個 handover 的 command ，也就是產生一張交班單，存在 SQLite 裡。每次對話結束寫入，每次開始注入。他的設計理念就是 /handover → /clear → /handover 回來，主要也是規避 context window 爆掉的問題。
我就好奇：這個 idea 能不能延伸到更複雜的場景？handover vs hibernate （暫存）vs resume 的差異？
Context Anxiety：AI 的焦慮是真的
在深入設計之前，我先查了一個之前看到的論文 title ，也好奇這會不會相關：LLM 在 context window 快滿的時候，行為會不會改變？
答案是：會，而且有點好笑
Cognition AI 在用 Claude Sonnet 4.5 重建 Devin 的時候發現，模型會對自己的 context window 產生焦慮。當它「認為」快要用完空間時，會開始走捷徑、跳過步驟、草草結束任務。更有趣的是，它會精確但錯誤地低估自己剩餘的 token 數。不是估不準，是估得很準但是是錯的 😂
具體的焦慮行為包括：提前開始摘要、自己偷偷寫 SUMMARY.md 把筆記外部化、提早關閉任務。Cognition 的解法之一是啟用 1M token 模式但實際只用約 200K，讓模型以為自己有更多空間（也就是，給 AI 一個「你還有很多空間」的心理安全感，它就表現得比較好。這跟管理人類團隊的道理有什麼不同嗎？😏）
除了焦慮，還有一個更根本的問題叫「context rot」。隨著 context 越塞越滿，模型對早期 token 的注意力會衰減。最近和高訊號的 token 被優先處理，前面的資訊權重降低。Chroma Research 的測試顯示，所有 18 個前沿模型都有這個現象
所以我的解讀就是「context 會不會斷」是小事，而且是「context 越大，品質越差」這才是重點！
Compact vs Handover：遺忘 vs 記憶
這讓我重新比較了兩種策略：
Compact 是遺忘：LLM 自己壓縮自己的 context，有損壓縮，你沒有控制權，不知道它丟了什麼。而且在 context anxiety 的狀態下，壓縮的品質可能更差。
Handover 是記憶：人類定義 schema，強制結構化輸出，選擇性保留。你決定保留什麼，格式固定，可跨 session、跨 Agent 取用。
它們其實可以搭配：先 handover 把重要的東西寫到資料庫，然後 compact 或 clear 釋放 context，用乾淨的環境繼續。與其讓 80k 的 context 帶著 rot 繼續跑，不如用 5k 的乾淨 context 重新開始。
設計：兩層交班單
再來對我來說另一個更重要的情景是跨機器和跨 Agent，所以我（跟cc) 開始設計 `/handover` 這個 skill。核心概念是「兩層 schema」：
Layer 1 是 Universal 層，任何人或任何 Agent 都能讀。Topic、完成了什麼、決策、blocked、下一步、lessons learned、attempted approaches。這些是純文字，不依賴任何特定 Agent 的格式。
Layer 2 是 Environment-specific metadata，只有同環境的 agent 才用得到： device、branch、working_dir、test_status、subscription_account。從 Claude 交班到 Gemini 時，Gemini 只要讀 Layer 1 就能接手。回到同環境時，Layer 2 幫你快速恢復現場。
另一個關鍵設計是 `session_type`，分成 sdd / debug / discussion / admin 四種，每種的摘要深度不同：
SDD 開發：有完整的設計文件可還原，handover 只需記進度和決測
Debug：attempted_approaches 是最有價值的欄位，記錄「試過什麼、為什麼不行」比最終解法更重
Discussion：記錄論點、共識、分歧
Admin：待辦和決策
從 Hibernate 到吸收：一個被推導掉的功能
有趣的是，我原本還想設計一個 `/hibernate` 指令，用來處理「做到一半要離開，回來接著做」的場景。
當初是想處理 cache miss 的問題，但在推導成本的過程中，我發現一個關鍵：cache miss 只是多花錢（全價重新 load context），不會丟資訊。而保留大 context 不做任何處理，反而面臨 context rot 的風險。
所以 hibernate 的存在理由消失了。不管什麼情境，handover + 乾淨 context 重啟，幾乎都比「什麼都不做讓 cache miss 自然發生」更好。最後我把 hibernate 想保留的東西（`conversation_summary`、`lessons_learned`、`attempted_approaches`）全部吸收進 handover 的 Layer 1。
一個功能被設計出來之前就被推導掉了，這也許是最好的設計決策。
為什麼 Anthropic 沒有原生做這個？
當然每次我在設計過程中，都會先問自己，為什麼官方不做？或是官方是不是的接下來就要做了？（懶惰是美德）查了一下 GitHub issues 和官方文件，Claude Code 其實已經有 `--resume`、Auto Memory、Session Mmory 等機制但它們都限於同一台機器同一個 agent，也就是說 Anthropic 沒有動機幫你把 context 帶去 Gemini。而「多 Agent、多裝置、多帳號」的 power user 族群太小？😆
不過反過來想，這正好是 Claude Code Skills 系統的設計初衷。你不需要等官方做，自己寫一個 skill 就解決了。單一 SQLite 檔案、四支 shell script、一個 SKILL.md，完工
簡樸就是美。
> 也許 AI 工具的下一個 bottleneck 不是模型能力，而是我們有沒有幫它設計好「什麼值得被記住」。
Interesting! Thanks for sharing