在程式開發的領域中，擁有 100 萬 Token 上下文視窗的 Claude Code 無疑是開發者夢寐以求的強大武器。這意味著它可以自主運行更長的時間，甚至從零開始建立一個全端應用程式。然而，Anthropic 官方團隊近期特別指出：這龐大的記憶體其實是一把雙面刃。如果不刻意管理對話進程，AI 的效能反而會被過載的資訊拖垮。
什麼是「上下文衰退 (Context Rot)」？
上下文視窗包含了模型在生成下一個回應前所能「看見」的所有資訊，包含系統提示、對話紀錄、工具呼叫結果以及讀取過的所有檔案。
雖然 Claude Code 具備 100 萬 Token 的乘載力，但隨著上下文不斷堆疊，模型會開始出現上下文衰退 (Context Rot)。這意味著 AI 的注意力被過多標記（Tokens）分散，早期或不相關的內容會開始干擾當前任務。根據官方觀察，在 100 萬 Token 的模型中，效能通常在累積至 30 萬到 40 萬 Token 時就會開始出現衰退跡象。
為了解決這個問題，精準的「上下文管理」成為了每位 AI 開發者的必修課。以下是五個能讓 Claude Code 隨時保持高智商的工作流策略：
善用「回溯」(/rewind) 取代來回糾正
這是判斷一個使用者是否具備良好上下文管理習慣的最關鍵指標。
當 Claude 讀取了五個檔案並嘗試了一種無效的解法時，多數人的直覺反應是打字告訴它：「這樣不行，改成嘗試 X 方法」。 但更聰明的做法是連按兩次 Esc（或輸入 /rewind），將對話狀態倒退回 AI 讀取檔案之後、採取錯誤行動之前的節點，然後直接給予新指令：「不要使用 A 方法，foo 模組不支援這個，直接使用 B 方法。」這樣能直接把錯誤的嘗試從記憶中抹除，避免浪費寶貴的 Token 與運算資源。
知道何時該斷捨離開啟新對話 (/clear)
有了百萬 Token，你或許會想把所有開發任務塞進同一個視窗中，但這並不明智。官方的經驗法則是：當你開始一個全新任務時，就應該開啟一個新的對話視窗。
唯一可以妥協的灰色地帶，是當你需要進行「高度關聯性」的延續任務。例如，剛寫完一段新功能，接著要求 AI 幫忙撰寫說明文件。此時保留對話紀錄可以省去 AI 重新讀取程式碼的時間與成本，且寫文件並非極度要求邏輯運算的任務，稍微妥協一點「上下文衰退」來換取效率是划算的。
壓縮記憶 (/compact) 的時機與風險
當對話過長時，你有兩種減輕負擔的方式：
- /clear（清除並手動總結）： 由你親自寫下目前重要的進度（例如：我們正在重構 auth，限制條件是 X，相關檔案是 A，已經排除 Y 方法），這能確保留下的資訊百分之百精準。
- /compact（自動濃縮）： 讓 AI 自動總結目前的對話並替換掉冗長的歷史紀錄。這是「有損壓縮」，你必須相信 AI 能抓對重點。
為何有時 /compact 會讓 AI 變笨？ 因為 AI 是根據「過去」的任務脈絡來濃縮對話。如果剛結束一場漫長的 Debug，AI 濃縮出來的重點全都是 Debug 相關資訊；若你下一秒突然要求「修復 bar.ts 裡的另一個警告」，AI 可能早就把這個無關 Debug 的警告給「濃縮」掉了。因此，在執行 /compact 時，主動提供後續方向（例如：/compact 將重點放在 auth 重構，捨棄測試相關資訊），能有效避免重要資訊遺失。
運用子代理 (Subagents) 隔離龐雜任務
當你知道某個任務會產生大量「中間過程」且後續不再需要時，呼叫 Subagents 是最優雅的解法。
當 Claude 透過代理工具啟動一個 Subagent 時，這個子代理會獲得一個全新且乾淨的上下文視窗。它可以無限制地進行工作，最後只把「最終報告或結論」回傳給主視窗。你可以直接下達這樣的指令：
- 「建立一個子代理，根據此規格檔驗證剛完成的工作結果。」
- 「建立一個子代理去閱讀另一個程式碼庫，總結其 Auth 流程的實作方式，然後你在這裡照樣實作出來。」
把 AI 當作團隊夥伴來管理
在未來，Claude 系統或許會自動幫我們完美處理這些記憶管理，但在那之前，把每一次 AI 的產出當作一個「決策分支點」，有意識地選擇該 Continue、Rewind 還是 Compact，將能讓你的 AI 開發夥伴隨時保持在最高效率與智力狀態。
