在我最近與 Claude Code 使用者的交流中，有一個主題不斷出現：100 萬 token 的上下文視窗是一把雙面刃。
它讓 Claude Code 能夠更長時間地自主運作，並更可靠地處理任務，但如果你沒有刻意管理你的工作階段，它也為上下文污染打開了大門。
工作階段管理比以往任何時候都更重要，而且似乎有很多相關問題。你是在終端機中保持一個工作階段開啟，還是兩個？每次提示都重新開始？何時應該使用 compact、rewind 或 subagents？什麼會導致不良的 compact？
這裡有許多細節，可以真正塑造你使用 Claude Code 的體驗，而幾乎所有這些都來自於管理你的上下文視窗。
關於上下文、壓縮與上下文衰變的快速入門
上下文視窗是模型在產生下一個回應時可以「看到」的所有內容。它包括你的系統提示、到目前為止的對話、每個工具呼叫及其輸出，以及每個已讀取的檔案。Claude Code 的上下文視窗為一百萬個 token。
不幸的是，使用上下文會帶來輕微的成本，這通常被稱為上下文衰變。上下文衰變是指模型效能隨著上下文增長而下降的現象，因為注意力分散到更多 token 上，而較舊、不相關的內容開始干擾當前任務。對於我們的 100 萬上下文模型，我們看到在某種程度上上下文衰變發生在大約 30 萬到 40 萬 token 左右，但這高度依賴於任務，並非一個硬性規則。
上下文視窗有一個硬性上限，所以當你接近上下文視窗的尾端時，你需要將你一直在處理的任務總結成一個較小的描述，並在新的上下文視窗中繼續工作，我們稱之為壓縮。你也可以自行觸發壓縮。
每一次互動都是一個分支點
假設你剛剛要求 Claude 做某件事，而它已經完成了，你的上下文中現在有一些資訊（工具呼叫、工具輸出、你的指令），而且對於下一步該做什麼，你有數量驚人的選擇：
- 繼續 — 在同一個工作階段中發送另一條訊息
- /rewind (esc esc) — 跳回先前的訊息，並從那裡重新嘗試
- /clear — 開始一個新的工作階段，通常帶有你從剛才學到的內容中提煉出的簡要說明
- Compact — 總結到目前為止的工作階段，並在總結之上繼續進行
- Subagents — 將下一部分工作委派給一個擁有自己乾淨上下文的 Agent，並僅將其結果拉回來
雖然最自然的做法就是繼續，但其他四個選項的存在是為了幫助你管理上下文。
何時開始一個新的工作階段
新的 100 萬上下文視窗意味著你現在可以更可靠地執行更長的任務，例如讓它從頭開始建立一個全端應用程式。但僅僅因為你的模型還沒有用完上下文，並不代表你不應該開始一個新的工作階段。
我們的一般經驗法則是：當你開始一個新任務時，你也應該開始一個新的工作階段。
一個灰色地帶是，當你可能想要執行相關任務，其中部分上下文仍然必要，但並非全部時。
例如，為你剛剛實作的功能撰寫文件。雖然你可以開始一個新的工作階段，但 Claude 必須重新讀取你剛剛實作的檔案，這會更慢且更昂貴。由於文件可能不是一個高度智慧敏感的任務，因此額外的上下文可能值得省去重新讀取相關檔案所帶來的效率提升。
Rewind 而非修正
如果我必須選一個能代表良好上下文管理的習慣，那就是 rewind。
在 Claude Code 中，雙擊 Esc（或執行 /rewind）可以讓你跳回任何先前的訊息，並從那裡重新提示。該點之後的訊息會從上下文中刪除。
Rewind 通常是比修正更好的方法。例如，Claude 讀取了五個檔案，嘗試了一種方法，但沒有成功。你的直覺可能是輸入「那個方法沒用，試試 X 吧。」但更好的做法是 rewind 到剛剛讀完檔案之後，並用你學到的東西重新提示。「不要使用方法 A，foo 模組沒有暴露那個功能 — 直接使用 B。」
你也可以使用 「從這裡總結」 讓 Claude 總結它所學到的東西，並建立一個交接訊息，有點像是來自未來自己的 Claude 給先前迭代的 Claude 的訊息，告訴它嘗試了某個方法但沒成功。
壓縮 vs. 全新工作階段
一旦工作階段變長，你有兩種方式來減輕負擔：/compact 或 /clear（然後重新開始）。它們感覺相似，但行為卻非常不同。
Compact 要求模型總結到目前為止的對話，然後用該總結取代歷史記錄。它是有損的，你信任 Claude 來決定什麼是重要的，但你不需要自己寫任何東西，而且 Claude 在包含重要的學習成果或檔案方面可能更徹底。你也可以透過傳遞指令來引導它（/compact 專注於 auth 重構，放棄測試除錯）。
使用 /clear，你 寫下重要的內容（「我們正在重構 auth 中介軟體，限制條件是 X，重要的檔案是 A 和 B，我們已經排除了方法 Y」），然後從頭開始。這需要更多工作，但產生的上下文是你決定相關的內容。
什麼導致不良的 Compact？
如果你執行很多長時間執行的工作階段，你可能會注意到有時 compact 可能特別糟糕。在這種情況下，我們經常發現，當模型無法預測你的工作方向時，可能會發生不良的 compact。
例如，自動 compact 在長時間的除錯工作階段後觸發，並總結了調查過程，而你下一條訊息是「現在修復我們在 bar.ts 中看到的那個其他警告。」
但由於工作階段專注於除錯，那個其他警告可能已經從總結中被刪除了。
這特別困難，因為由於上下文衰變，模型在壓縮時處於其最不智慧的狀態。憑藉一百萬的上下文，你有更多時間主動使用 /compact，並附上你想做什麼的描述。
Subagents 與全新的上下文視窗
Subagents 是上下文管理的一種形式，當你事先知道某部分工作會產生大量你不再需要的中間輸出時，它非常有用。
當 Claude 透過 Agent 工具產生一個 subagent 時，該 subagent 會獲得自己全新的上下文視窗。它可以做它需要做的任何工作，然後綜合其結果，以便只有最終報告返回給父級。
我們使用的心理測試是：我還會需要這個工具輸出嗎，還是只需要結論？
雖然 Claude Code 會自動呼叫 subagents，但你可能希望明確告訴它這樣做。例如，你可能想告訴它：
- 「啟動一個 subagent，根據以下規範檔案驗證這項工作的結果」
- 「啟動一個 subagent，閱讀這個其他程式碼庫，並總結它如何實作 auth 流程，然後你自己以相同的方式實作它」
- 「啟動一個 subagent，根據我的 git 變更來撰寫這個功能的文件」
總結
總之，當 Claude 完成一個回合，而你即將發送新訊息時，你有一個決策點。
隨著時間推移，我們期望 Claude 會幫助你自己處理這個問題，但就目前而言，這是你可以引導 Claude 輸出的方式之一。
