Claude Code session 越用越笨？何時該重開、怎麼交接的實戰手冊

瀏覽次數: 1

你一定遇過這種場面：早上開了一個 Claude Code session 修登入 bug，修完順手加個 API，又順手重構一個 util，到了下午，它開始把你兩小時前否決的寫法又寫回來，CLAUDE.md 裡寫明「測試用 pnpm」它卻跑 npm，你糾正一次、兩次，它道歉、然後再犯一次。

r/ChatGPTCoding 上有一串討論，標題就是「你們怎麼判斷一個 Claude Code session 該收掉了？」。這個問題問得很好，因為多數人處理它的方式是憑感覺：覺得怪了就硬撐，撐不下去才重開，重開之後又花 20 分鐘重新解釋背景。

這篇把它拆成三件可以照做的事：怎麼看出 session 在變差、該用哪一招止血（Esc、rewind、compact、clear 各管什麼）、以及重開時怎麼交接才不會從零開始。所有指令與行為都以 Claude Code 官方文件為準，版本相依的地方會標出來。

本文大綱

一、為什麼 session 越久越笨：這不是錯覺

先把機制講清楚，後面的招式才知道為什麼有效。

Claude Code 的官方 Best Practices 開宗明義寫了一句：「大部分最佳實踐都基於一個限制：Claude 的 context window 很快就會填滿，而且填得越滿，表現越差。」文件接著說，context 快滿時，Claude 可能會「忘記」較早的指令或犯更多錯，context window 是你「最重要、需要管理的資源」。

這背後有研究支撐。Chroma 的 Kelly Hong、Anton Troynikov、Jeff Huber 在 2025 年 7 月發表技術報告〈Context Rot: How Increasing Input Tokens Impacts LLM Performance〉，測了 18 個模型（包含 GPT-4.1、Claude 4、Gemini 2.5、Qwen3），結論是：模型並不會均勻地使用整段 context，即使任務很簡單，輸入一變長，表現就下滑，而且下滑的方式常常不規則、難預測；跟正確答案語意相近的「干擾資訊」越多，掉得越兇。

Anthropic 自己在〈Effective context engineering for AI agents〉（2025/9/29）也用同一個詞：context rot。文章把它比喻成「注意力預算」，每多一個 token 就消耗一點預算。

把這套機制套到 coding session，你就知道長 session 為什麼特別容易出事：

失敗嘗試本身就是干擾資訊。 你否決過的三種寫法、跑爆的測試輸出、走錯方向的探索，全都還留在 context 裡，而且跟正確解法語意高度相似，正好是 Chroma 報告裡最傷的那種干擾。
你的糾正被稀釋。 「不要用 npm」這句話在第 15 輪講的，到第 80 輪時已經被幾萬 token 的 log 埋住了。
無關任務互相污染。 修 bug 的脈絡和重構 util 的脈絡混在一起，模型得自己分辨哪些還算數。

所以重點不是「session 太長」，而是 context 裡的雜訊比例太高。這也決定了止血手段：不是每次都要重開，有時候只要把雜訊切掉。

二、五個訊號：session 該處理了

以下訊號是把官方文件列出的失敗模式，轉成你在終端機前看得到的徵兆：

同一件事糾正超過兩次。 這是官方給的明確門檻：「如果你在同一個 session 裡就同一個問題糾正 Claude 超過兩次，context 已經被失敗的嘗試塞滿了。」
它開始違反 CLAUDE.md 或你早先講好的規則。 對應文件說的「忘記較早的指令」。
它把你否決過的方案又提出來。 代表舊的失敗路徑正在干擾它。
一個 session 做了好幾件不相干的事。 官方稱為「kitchen sink session」（大雜燴 session）。
出現 auto-compact 警告，或 /context 顯示大半被工具輸出吃掉。 官方 Costs 文件說明：這個警告不是用量上限，而是對話快到 auto-compact 門檻了。

第 5 點可以量化。直接打：

/context

它會用彩色格子畫出目前 context 被什麼佔用（system prompt、CLAUDE.md、MCP 工具、訊息），還會給優化建議。如果你發現一大塊是某次 npm test 的完整輸出或某次大範圍 grep，那就是該清的雜訊。想一直看到用量，可以把它設到 status line（官方 Costs 文件建議的做法）。

三、四種止血手段：分清楚各管什麼

很多人只知道 /compact 跟 /clear，其實 Claude Code 有一整組工具，粒度由細到粗：

1. `Esc`：當下就停

Claude 正在往錯的方向走時，按一次 Esc 中斷。官方說明：context 會保留，已完成的工作也會保留，你可以直接改指示。越早按越便宜，因為錯誤路徑還沒寫進太多 context。

2. `Esc Esc` 或 `/rewind`：退回去，連失敗紀錄一起丟掉

這是最被低估的一招。輸入框是空的時候連按兩次 Esc（或打 /rewind），會開出 rewind 選單。每個你送出的 prompt 都是一個 checkpoint，選單提供：

Restore code and conversation：程式碼和對話一起退回
Restore conversation：只退對話，保留現在的程式碼
Restore code：只退程式碼，保留對話
Summarize from here：把這個點之後的對話壓成摘要，前面保持原樣
Summarize up to here：把這個點之前的對話壓成摘要，後面保持原樣

為什麼這招比糾正好用？因為糾正是在 context 裡疊加「錯誤＋更正」，rewind 是直接把錯誤刪掉。模型看不到那條死路，就不會再被它吸過去。實戰建議：在送出關鍵 prompt 之前，先在心裡記一下「這是個好的回退點」。

兩個要注意的限制（官方 Checkpointing 文件）：checkpoint 只追蹤 Claude 用檔案編輯工具做的修改，透過 Bash 執行的 rm、mv、cp 退不回來，外部手動修改也不追蹤；Claude Code 只保留最近 100 個 checkpoint 的檔案快照。所以它不能取代 git，重要節點還是要 commit。

3. `/compact <指示>`：同一個任務，但要騰出空間

任務還沒做完、前面的脈絡仍然有價值，只是太長了，就用 compact。關鍵是一定要帶指示，告訴它要保留什麼：

/compact 保留：已修改的檔案清單、目前失敗的測試名稱與錯誤訊息、我們已否決的方案及原因。丟掉：探索過程與完整 log。

你也可以把壓縮規則寫進 CLAUDE.md，讓自動 compact 也照做。官方文件給的例子是：

# Compact instructions

When you are using compact, please focus on test output and code changes

或像 Best Practices 寫的：「When compacting, always preserve the full list of modified files and any test commands」。

兩件 compact 的事實要知道：

**compact 本身不便宜。**官方 Costs 文件明講，/compact 要讀過整段它要摘要的對話，所以壓縮一個很大的 context 本身就是一個大請求；而 /clear 不花錢。
只在對話裡講過的規則，壓縮後可能消失。官方 Memory 文件說明，專案根目錄的 CLAUDE.md 在 compact 後會從磁碟重新讀取注入；但如果某條指令只在對話中講過，壓縮後就可能不見。所以重要的規則要寫進 CLAUDE.md，不要只講在對話裡。

自動 compact 的門檻可以調。新版提供 /autocompact（官方文件標註需 v2.1.221 以上），例如 /autocompact 500k 讓它在 500K token 時就壓縮，而不是等到逼近 1M 的上限。對 1M context 的模型來說，提早壓縮可以避免在最「爛」的那段長度裡工作，這是值得實測的設定。

4. `/clear`：換任務，或這條路已經爛掉

兩種情況直接 clear：

**換到不相關的任務。**官方建議「在不相關的任務之間頻繁使用 /clear」。
**糾正兩次還是錯。**官方原話：「兩次糾正失敗後，/clear 並寫一個融入你學到東西的更好初始 prompt。一個乾淨的 session 加上更好的 prompt，幾乎總是勝過一個累積大量糾正的長 session。」

clear 不等於丟掉。官方 Costs 文件建議先用 /rename 幫 session 取名，之後可以用 /resume 回來；/clear 也可以直接帶名字（/clear login-bug-v1），在 resume 選單裡標記上一段對話。如果是同一個 Claude Code 程序裡剛 clear 掉的，rewind 選單最上面也會出現一個「previous session」項目可以救回來。

補充：兩個讓 context 少長雜訊的預防招

/btw <問題>：問個旁支問題（例如「這個 regex 什麼意思」），答案不會進對話歷史。
**用 subagent 做探索。**官方建議把大範圍的程式碼調查交給 subagent，冗長的過程留在 subagent 的 context，只有摘要回到主對話。在 prompt 裡直接說「用 subagent 調查 auth 模組怎麼處理 token refresh，回報結論就好」即可。

四、交接：重開 session 不該從零開始

決定 clear 之後，最常見的痛是：新 session 什麼都不知道，你又要花 20 分鐘解釋。解法是把「交接」變成固定動作。概念上就是 Anthropic 在 context engineering 文章裡講的 structured note-taking：讓 agent 把筆記寫到 context window 之外的檔案，之後再讀回來。

步驟 1：clear 之前，讓舊 session 寫交接文件

舊 session 雖然變笨了，但它仍是最清楚「發生過什麼」的那個。在 clear 前送出這段 prompt：

我要結束這個 session，換一個乾淨的 session 接手。請寫 HANDOFF.md，內容只要：
1. 目標：這個任務最終要達成什麼（一句話）
2. 目前狀態：已完成什麼、改了哪些檔案（列路徑）
3. 卡在哪：目前失敗的測試或錯誤訊息（貼原文，不要轉述）
4. 已否決的方案：試過什麼、為什麼不行（每項一行）
5. 下一步：接手的人第一件事該做什麼
不要寫過程敘事，不要寫你的推理，控制在 60 行以內。

「已否決的方案」是整份文件最值錢的部分。它讓新 session 知道哪些路不用再走，但只用一行描述，不會像原本的 context 那樣帶著幾千 token 的失敗細節。

步驟 2：把通用規則升級進 CLAUDE.md

交接文件寫的是「這個任務」的狀態；但如果這次 session 裡你學到了「這個專案的通則」，例如「測試要用 pnpm test --filter」、「不要動 generated/ 資料夾」，就該寫進 CLAUDE.md，因為它在每個新 session 開頭都會被載入。可以直接跟 Claude 說「把這條加進 CLAUDE.md」，或用 /memory 開檔案自己編輯。

注意別塞爆：官方 Memory 文件建議每個 CLAUDE.md 控制在 200 行以內，太長會吃 context 而且降低遵守度。Best Practices 說得更直白：CLAUDE.md 太長，Claude 會忽略一半。

步驟 3：commit 一個乾淨的回退點

git add -A && git commit -m "wip: 交接前狀態"。新 session 改壞了，你有地方退；checkpoint 不追 Bash 修改，git 是唯一可靠的安全網。

步驟 4：新 session 用一句話接手

/clear

然後：

讀 @HANDOFF.md，先用三句話跟我確認你理解的目標、現況、下一步，確認後再動手。

讓它先複述再動手，是一個便宜的檢查點：如果它理解錯，你在零行程式碼的時候就能抓到。

進階：把「規劃」和「執行」切成兩個 session

官方 Best Practices 有一個值得照抄的模式：先在一個 session 裡跟 Claude 訪談需求、寫出 SPEC.md，然後開一個新的 session 執行它，理由是新 session 的 context 乾淨、完全聚焦在實作，而且你手上有書面規格可以對照。同理，code review 也建議開新 session，因為官方說「新的 context 能改善 code review，Claude 不會偏袒自己剛寫的程式碼」。

也就是說，主動重開不只是止血手段，也是一種工作流設計：規劃、實作、審查各用一個 session，中間用檔案交接。

五、Trade-off：什麼時候不該重開

重開不是萬靈丹，官方也承認例外：「有時候你應該讓 context 累積，因為你正深入一個複雜問題，而歷史紀錄是有價值的。」

判斷原則：

情境	建議	理由
剛走錯一步	`Esc` 或 `/rewind`	把錯誤直接刪掉，比糾正乾淨
同一任務、脈絡仍有用、只是太長	`/compact <保留什麼>`	保留連續性；但它本身是一個大請求
換不相關的任務	`/rename` 後 `/clear`	舊脈絡只是雜訊；clear 免費
同一問題糾正兩次還錯	寫 HANDOFF.md 後 `/clear`	context 已被失敗嘗試污染
深入除錯中、每一步都依賴前面的發現	繼續，必要時用 Summarize up to here	歷史就是資產
想試另一條路但不想丟掉現在的	`/branch`	分岔對話，原本的保留

還有一個成本面的考量。官方 Costs 文件指出，費用偏高「通常可以追溯到從未清除的長 session」。如果你在用 API 或用量額度，養成 clear 的習慣本身就是省錢。

六、給團隊的可操作清單

如果你要把這套做法推給團隊，建議落地成這幾件事：

CLAUDE.md 加一段 # Compact instructions，指定壓縮時必須保留的東西（修改過的檔案清單、測試指令、已否決方案）。
把 HANDOFF.md 的 prompt 做成 custom slash command 或 skill，讓「交接」變成一個指令，而不是每次手打。
status line 顯示 context 用量，讓訊號 5 變成看得到的數字。
團隊約定「兩次糾正規則」：同一問題糾正兩次還錯，就交接重開，不要硬撐。這直接來自官方建議，推起來沒有爭議。
重要節點一定 commit，不要依賴 checkpoint。
HANDOFF.md 加進 .gitignore（或放進固定的暫存資料夾），它是工作筆記，不是專案文件。

最後一個心法：把 context window 當成要管理的資源，而不是一個越用越熟的同事。一個乾淨的 session 加一份好的交接文件，通常比一個「什麼都記得但記得亂七八糟」的長 session 更可靠。

來源

Anthropic，Claude Code Docs：Best practices（context 管理、兩次糾正規則、SPEC 與 review 用新 session）https://code.claude.com/docs/en/best-practices
Anthropic，Claude Code Docs：Manage costs effectively（/clear、/compact 成本、Compact instructions）https://code.claude.com/docs/en/costs
Anthropic，Claude Code Docs：Commands（/clear、/compact、/context、/rewind、/branch、/btw、/autocompact）https://code.claude.com/docs/en/commands
Anthropic，Claude Code Docs：Checkpointing（rewind 選單、100 個 checkpoint、Bash 修改不追蹤）https://code.claude.com/docs/en/checkpointing
Anthropic，Claude Code Docs：Memory（CLAUDE.md、200 行建議、compact 後重新載入）https://code.claude.com/docs/en/memory
Anthropic Engineering，〈Effective context engineering for AI agents〉，2025/9/29 https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Kelly Hong、Anton Troynikov、Jeff Huber（Chroma），〈Context Rot: How Increasing Input Tokens Impacts LLM Performance〉，2025/7/14 https://www.trychroma.com/research/context-rot
討論起點：r/ChatGPTCoding〈When do you guys decide a Claude Code session has…〉https://www.reddit.com/r/ChatGPTCoding/comments/1x795qw/when_do_you_guys_decide_a_claude_code_session_has/