當 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