Claude Code 上下文管理：像冰箱一樣，只放會壞的東西

我很喜歡我的冰箱，它能裝很多美味的食物。但它的空間有限，裝得越滿，運作效率就越差，食物會被推到後面，直到發臭才被發現。我買的巧克力麻糬甜甜圈，就這樣在角落待了兩週，最後只好丟掉。當冰箱太滿時，我會忘記裡面放了什麼。我買的大部分東西都可以放進冰箱，但這不代表它們都應該放進去。

我的 Pocky 可以放冰箱，但沒必要，所以它會放在儲藏室，讓牛奶有更多空間。Claude Code 的運作方式也是如此。主對話就是冰箱，上下文就是牛奶。許多任務會帶入大量不需要「冷藏」的東西。

牛奶要放冰箱。在之前的牛奶文章中，我曾說上下文最好是新鮮且精簡的。然而，每個任務都會消耗上下文，這是無法避免的開銷。你可以選擇的是在哪裡花費它。你需要你的甜點，儲存每份甜點都會佔用空間，但並非所有甜點都必須放進冰箱。需要冷藏的甜點，像是巧克力牛奶、珍珠奶茶和起司蛋糕，它們會放進冰箱。

不易腐壞的零食，例如 Pocky、巧克力椒鹽脆餅和巧克力派，則會放在儲藏室，為冰箱騰出空間。在 Claude Code 中，有四個地方會使用上下文，並且可以進行最佳化：主對話、子代理、第二個會話或無頭迴圈。一個冰箱，三個儲藏室。

冰箱。主對話是你與 Claude 互動的地方。所有在這裡說過的話都會保留，直到你使用 /clear 指令清除，或者它被壓縮（透過 /compact 指令或在冰箱快滿時自動壓縮）。此外，/rewind 也可以移除或總結上下文。什麼樣的提示詞適合放在主對話中呢？

需要來回互動的工作，例如：「不，把按鈕縮小一點。好，現在把它往左移。」或者「這裡的策略模式有什麼優缺點？」這類你無法交給別人處理，因為你需要主導的提示詞。快速、有針對性的修改。啟動一個會話，進行修改，然後結束。任何需要速度的場合。一個全新的子代理會從零開始，必須先收集上下文才能做任何有用的事情，而主對話已經具備這些上下文。這些就是你的「易腐品」。其他所有東西，請仔細挑選，它們可以放進儲藏室。

子代理儲藏室。子代理適用於「你去搞清楚這件事然後告訴我」這類任務。它是一個獨立的 Claude 實例，擁有自己的全新上下文和一套允許使用的工具。它會自行完成工作，然後回傳一份摘要。雜亂的內容會留在它的上下文裡，而不是你的。子代理中發生的事情，就留在子代理中。

子代理讀取了 1,000 行雜亂的輸出，而你只會得到三行結論。當任務產生大量你不需要看到的輸出時，例如讀取數十個檔案、搜尋日誌、執行測試套件，或者當工作足夠獨立，可以作為摘要回報時，就委派給子代理。或者當你想限制其工具時，例如一個只能讀取檔案但不能編輯的審閱者。

我以前會告訴 Claude「調查為什麼 X 很慢」並讓它執行。它會乖乖地讀取數百個檔案，然後我的上下文就充滿了我不在乎的內容。在這種情況下，你可以這樣做：限定任務範圍：「只查看 src/cache/。」將整個調查交給子代理。「去調查 X」是儲藏室的工作。

那麼，如何啟動子代理呢？這個主題可能值得單獨寫一篇部落格文章，所以我只會簡要提及。有多種方法。一種是明確要求：「使用子代理調查為什麼 X 很慢。」如果你已經在 .claude/agents/ 中定義了子代理，可以透過名稱提及：「@agent-code-architect 規劃快取變更。」

你也可以使用 /subtask 指令，例如 /subtask 為身份驗證控制器編寫單元測試。子任務（subtask）是一個子代理，它會繼承目前為止的整個對話，而不是從零開始，這樣你就不必重新解釋任何事情。它會在背景執行，而你可以繼續工作，它的工具呼叫會留在你的「冰箱」之外，只有結果會回到你的對話中。

你也可以執行 /fork，例如 /fork 為使用者控制器編寫單元測試。/fork 會將你的對話複製到一個獨立的背景會話中，該會話會自行繼續工作。與子任務不同，它不會向你回報。所以，/subtask 就像請你的助理完成一項任務：當他完成後，會帶著簡短的報告回來。

/fork 就像請你的助理完成一項任務，然後他自行去工作，完成後就回家了。你需要自行檢查他的工作或指派更多任務給他。請注意，如果你關閉了代理視圖，或者你使用的是舊版 Claude Code，則 /subtask 不可用，而 /fork 的行為會像上述的子任務一樣。

新會話儲藏室。第二個儲藏室是新會話。這是指你啟動一個新的 Claude 會話，使用其主對話，而不是在你目前的會話基礎上繼續。例如，當你使用 Claude 編寫程式碼並想審查它時，最好啟動一個新會話。讓 Claude 在同一個會話中審查它剛寫的程式碼，就像我校對自己的文章一樣，我會看到我「想寫的」，而不是我「實際寫的」。

一個全新的上下文不會對程式碼有任何依戀，它只會看到實際存在的內容。Claude Code 的文件也說了同樣的話：全新的上下文能改善程式碼審查，因為 Claude 不會偏向於它剛寫的程式碼。擁有兩個會話，一個負責編寫，另一個負責審查，然後第一個會話再進行修正。

會話 A（編寫者）會話 B（審閱者）為我們的 API 端點實作一個速率限制器。審查 @src/middleware/rateLimiter.ts 中的速率限制器。尋找邊緣案例、競爭條件以及與我們現有中介軟體的一致性。以下是審閱回饋：{會話 B 的輸出}。

解決這些問題。你甚至不需要複製貼上。讓會話 B 將其審閱寫入 review.md，然後告訴會話 A 處理 review.md。不想同時處理兩個會話？子代理審閱者也適用。它也會從全新的上下文開始，其發現會直接回報給編寫者。如何執行多個會話？你可以開啟多個分頁。我使用 Tmux，喜歡用窗格同時查看所有內容。

打包 3000 個便當。假設你有 3,000 個檔案需要從一個框架遷移到另一個框架。如果你嘗試在一個會話中完成，請不要這麼做。到第 100 個檔案時，你可憐的「牛奶」會被擠到冰箱最深、最暗的角落，因為你的冰箱已經塞滿了。不要使用一個會話。給每個檔案一個全新的 Claude。

如果你要為你的班級打包，不要為整個班級打包一個巨大的容器！相反地，為每個孩子打包一個便當盒。這就是無頭迴圈（claude -p）的用途！這是一種做法：讓 Claude 列出檔案：列出所有需要遷移的 React 元件 → files.txt。

在非互動模式（-p）下迴圈處理它們。# claude_migrate.sh for file in $(cat files.txt) ; do claude -p "將 $file 從 React 遷移到 Angular。回傳 SUCCESS 或 FAIL。

" --allowedTools "Edit,Bash(git commit *)" --permission-mode dontAsk done。先在 2-3 個檔案上執行。根據出現的問題修正你的提示詞。然後再對所有檔案執行。每次執行都是乾淨的。

一個失敗不會污染其餘的。處理數千個檔案也沒問題。如果你希望它們盡可能自主，請使用這些旗標：--allowedTools 預先批准每次執行所需的工具，這樣你就不必批准一千次。--permission-mode dontAsk 會拒絕其他所有請求，而不是停下來詢問批准。

反正你也不會在場回應。如果沒有 dontAsk，一個嘗試使用你未列出工具的執行可能會停滯或行為不可預測。有了它，該執行只會被告知「不」，然後繼續進行，你會在 SUCCESS/FAIL 輸出中看到結果。保持允許列表小巧，你不會希望一千個 Claude 不小心破壞東西。

你也可以將輸出導向到現有的工具：claude -p "<提示詞>" --output-format json | your_command。如果你的 Bash 腳本技能像我一樣差，無法在不詢問 Claude 或查詢的情況下編寫簡單的迴圈，別擔心！

Claude 可以透過 /batch 原生做到這一點。它會將一個變更分散到 5-30 個平行子代理中。

乾淨的冰箱，快樂的你。把這個貼在你的冰箱門上。它需要與我來回互動，或者與我們現在正在做的事情共享大量上下文嗎？├，是 → 主對話。└，否。├，它是一個獨立的區塊（調查、搜尋、讀取大量檔案）嗎？│ └，是 → 子代理（以摘要形式回報）。├，我想對 Claude 剛完成的工作尋求第二意見嗎？

│ └，是 → 第二個會話或審閱者子代理（全新視角，沒有偏見）。└，它是針對許多項目重複相同的任務嗎？└，是 → 無頭迴圈（每個項目使用 claude -p，或 /batch）。在你放入任何東西之前，先問問它是否真的需要「冷藏」。你會驚訝地發現有多少東西不需要放進冰箱。把 Pocky 放在儲藏室，為牛奶騰出空間。