在使用 Claude Code 進行開發時，Context Window（上下文視窗）是你最重要的資源。它決定了 Claude 能夠「記住」多少對話內容、讀取多少檔案、以及處理多複雜的任務。本篇教學將帶你深入了解 Context Window 的運作原理，學會使用 /compact 和 /clear 等指令來有效管理 Token 用量，並分享大型專案中的 Context 管理策略，讓你的 Claude Code 體驗更加流暢高效。
什麼是 Context Window（上下文視窗）
Context Window 是指語言模型在產生回應時能夠參考的所有文字內容，你可以把它想像成 Claude 的「工作記憶」。在 Claude Code 中，Context Window 包含了以下這些內容：
- 系統提示詞（System Prompt）：Claude 的核心行為指令，約佔 4,200 tokens
- 自動記憶（MEMORY.md）：前次工作階段 Claude 記錄的筆記，約 680 tokens
- 環境資訊：工作目錄、平台、Shell、Git 狀態等，約 280 tokens
- MCP 工具描述：已連接的 MCP Server 工具清單
- Skill 描述：可用技能的一行摘要，約 450 tokens
- CLAUDE.md 檔案：全域與專案層級的指令設定，約 320 + 1,800 tokens
- 對話歷史：你的提問、Claude 的回應、檔案讀取內容、指令輸出等
目前 Claude Code 預設提供 200K tokens 的 Context Window。如果使用 Opus 4.6 或 Sonnet 4.6 模型，還可以選擇啟用 1M tokens 的擴展視窗。不過要注意的是，一個全新的工作階段在你還沒輸入任何內容之前，系統提示詞、CLAUDE.md 和環境資訊等就已經消耗了約 8,000 到 10,000 tokens。
Token 用量的視覺化理解
為了更好地管理 Context，你需要理解哪些操作會消耗大量 Token。以下是一個典型工作階段中各類操作的 Token 消耗概況：
| 操作類型 | 大約 Token 消耗 | 說明 |
|---|---|---|
| 系統提示詞 + 環境資訊 | ~5,000 | 每次工作階段自動載入 |
| CLAUDE.md（全域 + 專案） | ~2,100 | 每次工作階段自動載入 |
| 讀取一個中型檔案 | 1,000 ~ 3,000 | 依檔案大小而定 |
| 執行 Bash 指令並取得輸出 | 500 ~ 2,000 | 依輸出長度而定 |
| grep 搜尋結果 | 300 ~ 1,000 | 依匹配數量而定 |
| Claude 的分析與回應 | 400 ~ 1,200 | 依回應長度而定 |
| 每個 MCP Server 工具描述 | 100 ~ 500 | 連接越多 Server 消耗越大 |
從上表可以看出，檔案讀取是最大的 Context 消耗來源。當 Claude 進行程式碼探索、debug 或大規模重構時，可能會讀取數十個檔案，很快就會填滿 Context Window。
如何查看目前的 Token 用量
Claude Code 在終端機底部會顯示目前的 Token 使用百分比，這是你最直接的監控指標。養成習慣在每次開始新任務前瞄一眼這個數字，可以幫助你及時做出 Context 管理決策。
除了底部的百分比指示器，你還可以使用以下方式查看更詳細的 Token 資訊：
使用 /context 指令
/context 指令可以顯示你的 Token 詳細分配情況，包括系統提示詞、工具描述、記憶檔案、Skills 和對話歷史各佔多少空間。這對於了解「Token 都花到哪裡去了」非常有幫助。
使用 /cost 指令
/cost 指令可以查看當前工作階段的累計費用和 Token 使用量。如果你使用的是 API 付費方案，這個指令能幫助你追蹤開銷。
自訂狀態列（Status Line）
你可以透過設定自訂狀態列，在終端機底部持續顯示 Context 使用量。在 .claude/settings.json 中設定：
{
"statusLine": "context: {context_percent}% | tokens: {context_tokens}/{context_max} | cost: {cost}"
}這樣你就能隨時掌握 Context 的使用狀況，不需要額外執行指令。
/compact：壓縮對話歷史
當你的 Context Window 逐漸填滿，/compact 是最重要的管理工具。它會將目前的對話歷史摘要壓縮，用精簡的摘要取代完整的對話記錄，同時保留重要的程式碼變更、決策和檔案狀態。
基本用法
# 直接壓縮
/compact
# 帶有指示的壓縮（告訴 Claude 壓縮時要保留什麼）
/compact Focus on the API changes
/compact 保留所有修改過的檔案清單和測試指令帶有指示的壓縮特別有用，你可以告訴 Claude 哪些資訊是重要的，確保壓縮後這些關鍵資訊不會遺失。
自動壓縮（Auto Compaction）
當你的對話接近 Context 上限時，Claude Code 會自動觸發壓縮。以 200K 的 Context Window 為例，Claude Code 會保留約 33K~45K tokens 的緩衝區，當使用量達到約 83.5%（約 167K tokens）時就會觸發自動壓縮。如果使用 1M 的 Context Window，你有大約 5 倍的可用空間才會觸發壓縮。
自動壓縮會保留最重要的內容，包括程式碼模式、檔案狀態和關鍵決策，但一些細節可能會在壓縮中遺失。因此，最佳實踐是在完成一個子任務後主動執行壓縮，而不是等到系統自動壓縮。
/compact 的最佳時機
- 完成一個子任務後：就像存檔一樣，在自然的斷點進行壓縮
- Context 使用量超過 60% 時：提前壓縮比被迫自動壓縮更好
- 進行大量檔案讀取後：探索程式碼庫後，壓縮掉不需要的檔案內容
- 切換到不同功能的開發前：壓縮前一個功能的 Context，為新功能騰出空間
在 CLAUDE.md 中自訂壓縮行為
你可以在 CLAUDE.md 中加入壓縮指示，確保每次壓縮都保留你認為重要的資訊：
# Compaction Rules
When compacting, always preserve:
- The full list of modified files
- All test commands and their results
- Architecture decisions made during this session
- Any error patterns we identified/clear：完全重設 Context
與 /compact 不同，/clear 會完全清除目前的對話歷史，讓你回到一個乾淨的起點。這在以下情境中特別有用：
- 切換到完全不相關的任務：前一個任務的 Context 只會佔用空間、降低效能
- 修正 Claude 超過兩次都失敗：Context 中充滿了錯誤的嘗試，不如重新開始
- Context 已經嚴重混亂：對話中累積了太多無關內容，影響 Claude 的判斷
# 完全清除對話歷史
/clear重要提醒：/clear 不會刪除任何檔案或你已經做過的程式碼修改，它只會清除對話記錄。Claude 在下次對話中仍然可以讀取檔案來了解之前的變更。
/compact 與 /clear 的差異比較
| 特性 | /compact | /clear |
|---|---|---|
| 對話歷史 | 壓縮為摘要 | 完全清除 |
| 保留關鍵資訊 | 是（程式碼變更、決策等） | 否 |
| 檔案修改 | 不受影響 | 不受影響 |
| 適用情境 | 同一任務持續進行中 | 切換到不相關的任務 |
| Token 釋放量 | 中等（保留摘要） | 最大（全部清除） |
| 使用頻率 | 經常使用 | 任務切換時使用 |
其他實用的 Context 管理指令
/rewind：回溯到特定檢查點
每當 Claude 執行操作時，都會自動建立一個檢查點（Checkpoint）。你可以使用 /rewind 或連按兩次 Esc 來開啟回溯選單，選擇要恢復到哪個時間點。回溯選單提供以下選項：
- 僅恢復對話：回到特定對話狀態，但保留程式碼變更
- 僅恢復程式碼：回到特定程式碼狀態，但保留對話
- 兩者都恢復：同時回到特定的對話和程式碼狀態
- 從此處摘要：從選定的訊息開始壓縮，保留之前的完整 Context
「從此處摘要」選項特別實用——它可以只壓縮對話的後半段，保留前面的完整 Context。這比 /compact 提供了更精細的控制。
/btw：不佔用 Context 的快速提問
有時候你只是想快速問一個小問題，不想讓它佔用寶貴的 Context 空間。/btw 指令正好適合這種情況——它的回應會顯示在一個可關閉的浮動視窗中，不會進入對話歷史，因此不會消耗任何 Token。
# 快速查詢，不佔用 Context
/btw TypeScript 中 Record 和 Map 的差異是什麼？
/btw 這個 regex 是什麼意思？/^\d{3}-\d{4}$/使用 Subagent 節省 Context
Subagent（子代理）是 Context 管理中最強大的工具之一。當 Claude 需要大量讀取檔案來研究某個問題時，這些檔案內容都會佔用你的主要 Context。但如果委託給 Subagent，所有的檔案讀取都發生在獨立的 Context Window 中，最後只有精簡的摘要結果回到你的主要對話。
舉例來說，如果 Subagent 讀取了 6,100 tokens 的檔案內容，最後只會回傳一個約 420 tokens 的摘要。這就是 Subagent 的 Context 節省效果——節省了超過 90% 的 Token。
# 委託研究任務給 Subagent
使用 subagent 調查我們的認證系統如何處理 token 刷新，
以及是否有現成的 OAuth 工具可以重用。
# 委託程式碼審查
使用 subagent 審查這段程式碼的邊界情況和潛在問題。適合使用 Subagent 的情境
- 程式碼庫探索：需要讀取大量檔案來理解架構或依賴關係
- 程式碼審查：讓 Subagent 在獨立 Context 中審查，不會受到實作過程的偏見影響
- 文件搜尋：搜尋整個專案中的特定模式或用法
- Bug 調查：追蹤複雜的錯誤來源，可能需要讀取多個檔案
大型專案的 Context 管理策略
在大型專案中，Context 管理的挑戰更加嚴峻。以下是經過實戰驗證的策略，幫助你在複雜的程式碼庫中高效使用 Claude Code。
策略一：分階段工作法
不要試圖在一次對話中完成研究、規劃和實作。將工作拆分為獨立的階段，每個階段使用乾淨的 Context：
# 階段 1：探索（使用 Plan Mode）
進入 Plan Mode，讀取 /src/auth 目錄，了解認證流程。
→ 完成後執行 /compact 或記錄筆記
# 階段 2：規劃（使用 Plan Mode）
根據探索結果，制定 Google OAuth 的實作計畫。
→ 完成後將計畫存入 SPEC.md
# 階段 3：實作（開新工作階段）
claude --continue 或開啟新對話
根據 SPEC.md 的計畫開始實作。策略二：精確指定檔案路徑
模糊的提示會導致 Claude 讀取大量不相關的檔案。越精確地指定範圍，Token 消耗就越少：
| 避免這樣說 | 改為這樣說 |
|---|---|
| 「修復登入的 bug」 | 「修復 src/auth/login.ts 中 session timeout 的 bug」 |
| 「加一些測試」 | 「為 src/utils/validator.ts 的 email 驗證加上邊界測試」 |
| 「重構這段程式碼」 | 「重構 src/api/users.ts 中的 getUserProfile 函式」 |
策略三：善用 @ 符號引用檔案
使用 @ 符號直接引用檔案，而不是用文字描述檔案位置。Claude 會在回應前先讀取被引用的檔案：
# 使用 @ 引用特定檔案
請看 @src/components/Header.tsx 和 @src/styles/header.css，
將 Header 元件改為響應式設計。
# 搭配管線輸入
cat error.log | claude "分析這個錯誤日誌，找出根本原因"策略四：控制 MCP Server 數量
每個 MCP Server 都會在 Context 中加入工具描述。如果你連接了 5 個以上的 Server，Claude 在開始處理你的任務之前就需要處理 50 個以上的工具描述。實際可用的 MCP Server 數量建議控制在 5 到 8 個以內。
Claude Code 預設使用延遲載入策略——只列出 MCP 工具名稱，在實際需要時才載入完整的 Schema。你可以透過環境變數 ENABLE_TOOL_SEARCH 來控制這個行為：
# 預設：延遲載入（推薦）
ENABLE_TOOL_SEARCH=auto # 當 Schema 能放入 10% Context 時才預載
# 關閉延遲載入（不推薦，會佔用大量 Context）
ENABLE_TOOL_SEARCH=false # 一次載入所有工具 Schema策略五：不同任務使用不同工作階段
在不相關的任務之間切換時，開啟新的工作階段比在同一個工作階段中使用 /clear 更好。你可以使用 /rename 為工作階段命名，方便日後繼續：
# 為工作階段命名
/rename oauth-migration
/rename debug-memory-leak
# 繼續之前的工作階段
claude --continue # 繼續最近的工作階段
claude --resume # 從最近的工作階段中選擇常見的 Context 管理錯誤
避開這些常見陷阱，可以讓你的 Claude Code 體驗更加順暢：
| 錯誤模式 | 問題描述 | 解決方案 |
|---|---|---|
| 廚房水槽式工作階段 | 在同一個對話中處理多個不相關的任務，Context 充滿無關資訊 | 在不相關的任務之間使用 /clear |
| 反覆修正循環 | Claude 做錯了，修正後又錯，再修正又錯，Context 充滿失敗嘗試 | 修正超過兩次後，/clear 並重新撰寫更好的提示詞 |
| 無限探索 | 請 Claude「調查」某件事但沒有限定範圍，Claude 讀取了數百個檔案 | 限定探索範圍或使用 Subagent |
| 過度膨脹的 CLAUDE.md | CLAUDE.md 太長，Claude 開始忽略其中的規則 | 嚴格精簡，只保留必要的指令 |
| 忽略 Token 用量 | 不注意 Token 百分比，直到自動壓縮才發現 | 養成查看 Token 百分比的習慣 |
1M Context Window 的使用時機
自 2026 年 3 月起，Claude Opus 4.6 和 Sonnet 4.6 已正式支援 1M tokens 的 Context Window，且不需要額外費用。這為大型專案的開發帶來了顯著的便利，但並不代表你可以忽略 Context 管理。
1M Context Window 最適合以下情境：
- 大規模程式碼重構：需要同時理解和修改大量檔案
- 複雜的跨模組 debug：錯誤涉及多個檔案和模組的互動
- 完整功能開發：從設計到實作到測試的完整流程
- 程式碼庫遷移：例如從 React 遷移到 Vue，或從 JavaScript 遷移到 TypeScript
即使有 1M 的空間，本文介紹的所有 Context 管理技巧仍然適用。更大的 Context Window 只是讓你有更多的緩衝空間，但 LLM 在 Context 填滿時效能下降的問題依然存在。
總結
Context Window 是 Claude Code 中最重要的資源。掌握 Token 管理技巧不僅能讓你的對話更順暢，還能提升 Claude 的回應品質和準確度。以下是本文的核心要點：
- 主動監控：養成查看 Token 使用百分比的習慣，使用 /context 和自訂狀態列
- 及時壓縮：在完成子任務後主動使用 /compact，不要等到自動壓縮
- 果斷重設：切換不相關任務時使用 /clear，修正失敗超過兩次時重新開始
- 善用 Subagent：將研究和探索任務委託給 Subagent，節省主要 Context
- 精確提示：指定具體的檔案路徑和範圍，減少不必要的檔案讀取
隨著你使用 Claude Code 的經驗累積，你會逐漸發展出自己的 Context 管理直覺——知道什麼時候該壓縮、什麼時候該清除、什麼時候該開新工作階段。這些技巧會讓你從一個 Claude Code 使用者，成長為一個高效的 AI 輔助開發者。
延伸閱讀
- Claude Code 是什麼？完整介紹與安裝教學
- Claude Code 新手上路：第一次使用就上手
- CLAUDE.md 專案記憶：讓 Claude 記住你的專案規範
- Claude Code CLI 指令完整參考
- Slash Commands 與快捷鍵完整指南
