Claude Code上下文的正確處理方式：避免對話越長、模型越「笨」

原文標題：使用 Claude Code：會話管理與 1M 上下文
原文作者：Thariq，Claude Code 團隊成員
原文編譯：寶玉，AI 研究員

律動 BlockBeats 注：在 AI 編程工具不斷「擴窗」的當下，許多用戶誤以為上下文越大，體驗就會自然變好。但這篇來自 Claude Code 研究員的一線複盤，給出了一個更冷靜的答案：真正決定產出品質的，從來不是窗口大小本身，而是你如何管理它。

從 /usage 更新的推出，到對「繼續、回溯、壓縮、清空、子智能體」這些微操作的拆解，文章揭示了一種常被忽視的能力——上下文調度能力。它既是工程問題，也是認知問題：什麼時候保留歷史，什麼時候主動遺忘，什麼時候把任務拆出去，什麼時候重開一局。這些選擇，直接決定了 AI 是在「協作」，還是在「拖累」。以下為原文內容：

今天，我們為 /usage 命令推出了一項全新更新，旨在幫助你更清晰地了解自己在 Claude Code 中的使用情況。這個決定的背後，是我們近期與用戶進行的多次深入交流。

在這些交流中，我們反覆聽到了一個現象：大家在管理會話時的習慣可謂是五花八門。尤其是最近 Claude Code 將上下文窗口（Context Window）升級到了 100 萬大關，這種差異就更明顯了。

你是習慣在終端裡只保持一兩個開著的會話？還是每次輸入提示詞都重新開個新會話？你通常在什麼時候會用到壓縮（Compact）、回溯（Rewind）或者子智能體（Subagents）？又是什麼原因導致了一次糟糕的壓縮呢？

這裡頭其實大有學問。這些看似不起眼的細節，極大地影響著你使用 Claude Code 的體驗。而這一切的核心，都歸結於一件事：如何管理你的上下文窗口。

快速科普：上下文、上下文壓縮與上下文衰減

所謂「上下文視窗（Context Window）」，就好比模型在生成下一次回答時，眼前能同時「看到」的所有資訊。它包括了你的系統提示詞（System Prompt）、到目前為止的聊天記錄、每一次的工具調用（Tool Call）及其輸出結果，甚至還有它讀過的每一個檔案。現在，Claude Code 擁有高達 100 萬個詞元（Token）（註釋：Token 是大模型處理文字的基本單位，通常一個英文單詞約為 1 個 Token，一個漢字可能佔 1-2 個 Token） 的超大上下文視窗。

但遺憾的是，使用上下文是需要付出一點代價的，我們通常稱之為上下文衰減（Context Rot）（註釋：指隨著對話歷史越來越長，模型需要處理的資訊量過大，導致其注意力分散，遺忘早期重要資訊或被無關內容干擾的現象）。隨著上下文越來越長，模型的表現往往會變差，這是因為它的注意力被分散到了更多的 Token 上。那些早期遺留的、已經無關緊要的內容，會開始干擾模型當前正在執行的任務。

上下文視窗是有硬性容量上限的。所以，當你快要把視窗撐滿時，你必須把你正在做的任務總結成一段簡短的描述，然後帶著這段描述在一個新的上下文視窗裡繼續工作。

我們把這個過程稱為上下文壓縮（Compaction）（註釋：為了騰出記憶體空間，將超長歷史記錄提煉成精簡摘要的過程）。當然，你也可以隨時手動觸發這個壓縮過程。

想象一下，你剛剛讓 Claude 幫你做了一件事，並且它已經完成了。現在，你的上下文裡已經塞進了一些資訊（比如工具調用、工具的輸出結果、你給的指令）。

接下來該怎麼做？你可能會驚訝地發現，自己竟然有這麼多種選擇：

· 繼續（Continue）—在同一個對話中，直接發送下一條消息

· 回溯（/rewind 或連按兩次 Esc 鍵）—時光倒流，退回到之前的一條消息，從那裡重新開始嘗試

· 清空（/clear）—開啟一個全新的對話，通常帶上你從剛才對話中提煉出的簡短總結

· 壓縮（Compact）—把目前的對話做個總結，然後在這個總結的基礎上繼續幹活

· 子智能體（Subagents）—把下一階段的工作委派給另一個擁有自己乾淨上下文的 AI 智能體（AI Agent），並且只把它最終的工作結果拉取回來

雖然直接「繼續」是最順理成章的反應，但其他四個選項的設定，正是為了幫你更好地管理你的上下文。

什麼時候該開個新對話？

到底什麼時候該維持一個漫長的舊對話，什麼時候又該另起爐灶呢？我們的經驗法則是：當你開始一項新任務時，你也應該開啟一個新對話。

100 萬的上下文窗口，意味著你現在可以非常靠譜地完成更長、更複雜的任務。比如，讓 Claude 從零開始為你搭建一個全棧應用。

但有時候，你可能在做一些前後關聯的任務。這時候，你需要保留一部分之前的上下文，但不是全部。舉個例子，你剛寫完一個新功能，現在要為它寫一份使用文件。你當然可以開個新對話，但這意味著 Claude 必須把你剛才寫過的所有代碼檔案重新讀一遍——這不僅速度更慢，而且花費也更高。

用「回溯」代替「糾正」

如果非要我挑出一個能代表「優秀上下文管理能力」的好習慣，那一定是用好「回溯（Rewind）」。

在 Claude Code 裡，雙擊 Esc 鍵（或執行 /rewind 命令）能讓你穿越回之前的任意一條消息，然後從那裡重新下發提示詞。至於那個節點之後發生的所有對話，都會被從上下文中徹底抛棄。

在糾正 AI 的錯誤時，「回溯」往往是更高明的做法。舉個例子：Claude 讀了五個檔案，嘗試了一種方法，結果失敗了。你的本能反應可能是在對話框裡敲下：「這招不管用，換 X 方法試試。」但更聰明的做法是，回溯到它剛讀完那五個檔案的時刻，然後帶著你剛學到的教訓重新對它說：「別用 A 方法了，foo 模組根本不支持那個——直接去試 B 方法。」

你甚至可以使用「從這裡開始總結（summarize from here）」的功能，讓 Claude 自己把它學到的教訓總結成一段「交接信息」。這感覺就像是那個剛剛踩了坑的「未來版 Claude」，給過去那個還沒開始行動的自己留下了一張字條。

上下文壓縮 vs 全新會話

當一個對話變得越來越長時，你有兩種方法可以給它「減負」：使用 /compact（壓縮）或者 /clear（清空並從頭開始）。這兩個操作聽起來挺像，但實際表現大相徑庭。

壓縮（Compact） 是讓模型把到目前為止的對話總結一下，然後用這份摘要替換掉冗長的歷史記錄。這個過程是「有損」的，意味著你把決定「什麼內容重要」的權力交給了 Claude。

好處是你什麼都不用寫，而且 Claude 在保留重要的經驗教訓或檔案記錄時，可能比你想得更周到。你也可以通過給它下達指令來掌控壓縮的方向（比如：/compact 將重點放在身份驗證模組的重構上，丟掉那些關於測試調試的內容）。

而使用 /clear，则需要你自己写下核心要点（例如：「我們正在重構身份驗證的中介軟體，目前的限制條件是 X，相關的重要文件是 A 和 B，而且我們已經排除了方法 Y」），然後以一個無比乾淨的狀態重新開始。雖然這要費點勁，但由此產生的新上下文，百分百都是你認為真正相關的精華。

什麼樣的「壓縮」會翻車？

如果你經常掛著超長的會話，你大概率遇到過「壓縮」效果極其糟糕的情況。我們發現，這種「翻車」通常發生在一個特定的時刻：那就是大語言模型（LLM）無法預測你下一步工作方向的時候。

舉個例子，在一段漫長的程式碼除錯之後，系統觸發了自動壓縮，把之前的排查過程總結了一番。結果你緊接著發了一句：「現在，把我們之前在 bar.ts 裡看到的另一個警告也修了吧。」

可是，由於剛才的會話重點全在除錯前一個 Bug 上，那個沒來得及修的警告很可能早就被當成無關緊要的資訊，在總結時被直接丟棄了。

這是一個相當棘手的問題。因為受限於上下文衰減，模型在進行壓縮的那一刻，往往是它「智商」最不線上的時候。好在有了 100 萬的上下文容量，你現在有了更充裕的空間，可以主動帶上「我接下來想做什麼」的描述，去提前執行 /compact。

子智能體與全新的上下文視窗

子智能體也是一種管理上下文的絕佳手段。當你提前預知某一項工作會產生大量「閱後即焚」（以後再也用不上）的中間結果時，這招特別管用。

當 Claude 通過智能體工具（Agent tool）衍生出一個子智能體時，這個小傢伙會獲得一個完全嶄新的上下文視窗。它可以在裡面肆意折騰，做多少工作都行。等到大功告成，它會把結果提煉出來，只把最終的報告交還給「父級」Claude。

我們判斷是否該用子智能體的「靈魂拷問」是：以後我還需要看這些工具運行的詳細輸出嗎，還是我只想要一個最終結論？

雖然 Claude Code 會在背後自動調用子智能體，但有時候你也可以非常明確地指揮它。比如，你可以對它說：

·「派個子智能體去，根據下面這份規範文件，驗證一下我們剛才做的工作對不對」

·「派個子智能體去通讀一下另一個程式庫，總結出它是怎麼實現身份驗證流程的，然後你自己照貓畫虎，在這邊也實現一遍」

·「派個子智能體去，根據我的 Git 修改記錄，給這個新功能寫份說明文件」

總而言之，當 Claude 完成了一輪回答，而你正準備發送一條新消息時，你就站在了一個決策的路口。

我們期望在未來，Claude 能足夠聰明，自己幫你打理好這一切。但就目前而言，熟練掌握這些決策，正是你引導 Claude 產出高品質結果的必經之路。

原文連結

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia