Claude Code Context 管理：/context、/compact、/clear 與 CLAUDE.md

Claude Code 越用越亂，通常不是模型變差，而是 context 被雜訊占滿。先看結論：同一個任務仍需要前文時用 /compact；切換任務或脈絡已被錯誤嘗試污染時，用 /clear 或開新 session；跨 session 只把每次都需要的專案規則放進 CLAUDE.md。

先選對 Context 操作

查目前 context 用量：/context
同一任務要繼續，但 context 太長：/compact
開始完全不同的任務：/clear
跨 session 保留一直都要用的規則：CLAUDE.md

這四項是工作選擇，不是保證所有版本都以相同方式呈現；以你目前 Claude Code 的指令與文件為準。

你現在的情況	優先動作	原因
仍在同一個任務，前文決策還有價值	`/compact`	保留摘要後繼續，減少重新建立脈絡的成本
切換到不同任務	`/clear` 或新 session	避免舊假設與殘留 plan 干擾新任務
剛走錯方向，但前面大部分脈絡仍正確	`/rewind`	回到分岔點，比在錯誤脈絡上持續修正乾淨
不知道 context 被什麼占滿	`/context`	先查看檔案、工具與對話各自占用，再決定怎麼清理
每個 session 都需要同一條專案規則	CLAUDE.md	讓規則跨 session 重載，但仍要保持精簡

更新於 2026 年 8 月 10 日：本文依 Claude Code 現行官方文件補入 /rewind、新 session 的選擇，並修正 CLAUDE.md 仍會占用 context 的說明。

我剛開始用 Claude Code 的時候，總覺得它有時候很神、有時候很笨。同一個任務，session 開頭做得行雲流水，跑到後面開始漏掉需求、混淆檔案、給出我已經叫它別再做的事。我以為是模型不穩、是某些 prompt 寫得不夠好——後來才發現，多半都是同一件事：context window 用爆了。

當你把這件事看清楚，會對 Claude Code 的使用方式有完全不同的理解。它不是個越用越熟、越用越懂你的工具，它是一個有工作桌面預算的 Agent，桌面有多大決定它能同時記住多少。怎麼管那塊桌面，就是這篇要談的事。

為什麼 context 是預算、不是容量

Claude Code 官方文件把 context window 說明為 Claude 在目前 session 能使用的全部資訊：你的對話、它讀過的檔案、tool call 與輸出、CLAUDE.md、auto memory、載入的 Skills 和系統指令。每一次互動與檔案讀取都在消耗預算（Claude Code：Explore the context window）。

比起「記憶」，我更喜歡用「工作桌面」這個比喻。記憶聽起來像越多越好；桌面則明確讓你知道——東西堆太多會擠掉新的、會找不到、會出錯。Context window 就是那塊桌面，桌面有限，東西不能無限堆。

另一個關鍵差別是：context 不是「容量」、是「預算」。一個 session 結束，對話脈絡不會原封不動帶到下一次。要跨 session 保留的專案規則與狀態，必須寫到對話之外，例如 CLAUDE.md、auto memory 或專案文件。這篇聚焦的是 CLAUDE.md：它不是無限記憶，而是一份每次啟動都會重新載入的專案說明。

當預算快用完，Claude Code 會自動 compact：先清理較舊的 tool output，再把對話壓縮成摘要，騰出空間繼續。這個機制很方便，但摘要不可能保留所有原始細節。若任務依賴完整需求、修改檔案與測試指令，應把它們寫進專案文件或在 /compact 時明確指定要保留的內容（Claude Code：How Claude Code works）。

檢查當前用量的指令是 /context。它會告訴你目前 context 用了多少、什麼東西吃最多空間。我自己會在覺得 Claude 開始反應變慢、變笨的時候先打這個——通常一看就知道問題在哪。

Session 內怎麼管：/compact、/clear 與新 session

Context 管理的核心不是記住更多指令，而是判斷現在該延續、回到分岔點，還是重新開始。最常用的是 /compact 與 /clear；現行 Claude Code 也提供 /rewind，讓你能回到較早的決策點，而不是把修正訊息繼續堆進已污染的脈絡。

/compact 會把目前所有對話做摘要、移除不必要的 tool call 結果，然後保留摘要繼續往下做。適用於：你還在做同一個 feature、卡在 context 上限、但需要繼續用前面建立的脈絡。它幫你延長同一條脈絡的壽命。

/clear 完全相反——把整個對話清空、Claude 不記得任何前面發生的事，從零開始。適用於：你要切換到新 feature，前一個任務的脈絡不該帶過來。

我自己的判斷準則簡單：同 feature 卡 context 就 compact、換 feature 就 clear。後者特別重要——很多人習慣性把所有任務都塞在同一個 session 裡，理由是「不想重新解釋」。但前一個任務的脈絡會變成新任務的偏見：你在 debug 的時候建立的某個檔案結構假設、你剛剛叫 Claude 別做的某件事、上一輪沒做完的殘留 plan。這些東西帶進新 feature 只會干擾它，不會幫忙。

所以我比較常用的反而是 /clear，不是 /compact。寧可花 30 秒重新給 Claude 一個乾淨的 onboarding，也不要讓它帶著一堆雜訊做新事。這也符合 Anthropic 現行建議：開始新任務時，通常也應開始新的 session；若只是走錯一個分支，可以先用 /rewind（Using Claude Code: session management and 1M context）。

Context 指令選擇圖：先用 /context 查看目前佔用；同一任務仍需要前文時用 /compact，保留摘要後繼續；切換不同任務時用 /clear，重新提供必要材料，避免舊脈絡干擾。 — Gwarket 自製圖解，整理本文的主要選擇：先看 `/context`，同一任務用 `/compact` 延續，換任務用 `/clear`。圖解查證：2026-11-05；參照 Claude Code 官方 session 管理。接著可了解 Claude Code 的 Agent 迴圈。

CLAUDE.md 是跨 session 的 context

Session 內預算管得再好，每次重新開始都還是要把專案資訊重新解釋一次——這就是 CLAUDE.md 要解決的問題。它是 Claude Code 會自動讀取的專案說明，可以放在不同層級並依作用範圍載入。換句話說，它是一份能跨 session 穩定重載、但仍會占用 context 的文件。價值在持久與一致，不在免費。

但這個工具有個誤解：CLAUDE.md 不是 prompt 樣板，也不是「越多越好的設定檔」。它是給 Agent 的 onboarding 文件——讓 Agent 不需要每次重新探索同樣的東西。我自己寫過好幾個（gwarket-site、blog-writer、publish-tools、insidewriter、outsidewriter），慢慢摸出三個判斷準則。

該寫什麼、不該寫什麼：寫 Agent 重複問你的東西

CLAUDE.md 的最佳內容，是「Agent 重複問你、或重複犯錯的東西的答案」。例如：這個專案的 stack 是什麼、常用指令長怎樣、commit 規範是什麼、有哪些不可違反的安全規則。這些東西如果不寫，每次新 session 都要重新解釋，純粹浪費。

反過來，不要寫 Agent 已經會的東西。寫「請使用 React 寫前端」是廢話——Claude 本來就會 React，你需要寫的是「我們的 React 專案用 Server Components + Server Actions、不要用 API routes」這種專案特有的取捨。前者佔 context 預算卻沒資訊量；後者才是 CLAUDE.md 該存在的原因。

我的 publish-tools CLAUDE.md 就是這種思維的產物。它幾乎沒寫工具怎麼用、怎麼寫程式，整份檔案只寫了四條「發布鐵律」：不准新增 WordPress 分類或標籤、預設發草稿、密碼只能從 .env 讀、安全字 confirm 必須完整輸入。這四條每一條都是 Agent 反覆會犯的錯——必須寫死。

shared-rules 是 CLAUDE.md 的進化版

當你寫過幾個 CLAUDE.md，會遇到一個尷尬：多個專案需要同一份規範。例如 insidewriter 跟 outsidewriter 都需要同一套寫作風格規範、同一套 FB 貼文規則、同一套 Threads 演算法事實。如果各自在自己的 CLAUDE.md 裡寫一份，改一次就要改兩處——遲早會分裂。

解法是把共用規範抽出來成一個獨立 layer。我的目錄裡有個 shared-rules/，裡面放 writing-style.md、fb-writing.md、threads-writing.md、reading-protocol.md。各專案的 CLAUDE.md 不重複這些內容、只 reference：「寫作前必讀：../shared-rules/reading-protocol.md」。

同樣的話寫第三次的時候，就該抽出來。這個原則放在 CLAUDE.md 上意外好用——它不只是減少重複，是讓「規範變動」這件事只發生在一個地方。改 writing-style.md 一次，所有 writer 自動套用新規範，不需要手動同步。

本文的專案規則分層圖：專案獨有且反覆需要的內容放在 CLAUDE.md；多專案共用規範抽到作者的 shared-rules 並由專案引用；特定情境才需要的多步驟流程放在 Skill，按需載入。 — Gwarket 自製圖解，整理本文的規則分層；`shared-rules` 是作者的目錄組織方式。圖解查證：2026-11-05；參照官方記憶與指示文件及 Skills 說明。接著可用 Skill 客製化判斷整理適合封裝的流程。

CLAUDE.md 越寫越短

反直覺的觀察：CLAUDE.md 寫得久了會越來越短。一開始踩坑加一條、再踩坑再加一條，看起來會無限長下去。但當你踩到某個規範是「第三個專案都需要」的，它就會被抽到 shared-rules——CLAUDE.md 反而變短。

結果是各個專案的 CLAUDE.md 越來越精簡，只留「這個專案獨有」的部分。gwarket-site CLAUDE.md 大約 76 行，全是 Next.js 工作流跟部署細節；publish-tools 大約 56 行，全是發布安全規則。寫作風格規則完全不在這兩份檔案裡——全在 shared-rules 那層。

這個演化很像軟體架構：一開始把所有東西塞在一個 file，慢慢抽出 shared module、再抽出 utility、再抽出 design system。CLAUDE.md 體系也是同樣的成熟過程，差別在你抽的不是程式碼、是規範。

切目錄後 Skill 找不到？先查載入範圍

切到子目錄後找不到 Skill，不一定是 context 滿了；先分清技能是否被發現，以及 paths 是否匹配。v2.1.312 修正的是 Git repo 內 Bash cd 更深入後，找不到 per-directory 與 paths: skills 的問題，不代表所有 symlink 或載入問題都已解決。現行 paths 以 Claude 的目前工作目錄為相對基準，目錄外檔案不匹配，即使 /add-dir 已允許存取也一樣。版本修正、paths 與排錯

Claude Code 切目錄後的技能檢查：確認目前工作目錄、技能所在層級與是否已被發現，再核對目標檔案位於目錄內且符合 paths；技能可用後，仍需分開確認是否採用所需規則及文稿是否可接受。版本修正不等於所有載入問題都已解決。

原創載入範圍圖；依官方 Skills 與 v2.1.312 紀錄整理，2026-11-06 查證，非產品畫面。

先依序核對三件事：

位置與發現。 Skill 放在專案根層還是巢狀 .claude/skills/？啟動點下面的巢狀技能不在開場清單；官方說第一次讀取或編輯該子目錄檔案時才載入。目錄探索
匹配基準。 比較 Claude 現在的工作目錄、目標檔案相對路徑與 paths。不要把 glob 當成永遠相對 Skill 自己的資料夾，也不要把檔案能讀取當成已通過條件。frontmatter 定義
可用與採用。 官方建議確認可用技能；若可供使用者呼叫，可直接呼叫來縮小問題。若名稱也找不到，回頭查發現、名稱和匹配，別先把所有規則搬進全域檔。官方排錯

整理判斷一：版本修正不取代範圍設計。 例如把台灣慣用的「專案、資料夾」整理成某個寫稿流程的詞表，是本文的應用示例，不是官方中文品質功能。先確認它適用的目錄與檔案，再決定放哪一層；不要用搬到全域掩蓋載入範圍錯誤。

整理判斷二：分開記錄「技能可用、產出採用詞表、人工接受文字」。 前一項通過，不保證後兩項成立；這比只問「Claude 為什麼又忘了」更容易找到修正位置。

使用者議題 #103776 在2026-10-20回報 v2.1.304 的 CSS paths-gated skill：原先可用，後續檔案／registry與 Bash cd 變動後出現 Unknown skill，再讀匹配檔案後恢復。回報同時涉及 symlink target 更新，且未縮成最小重現；查證時仍開啟。不能由 v2.1.312 的一般修正推斷這個個案全部原因已被處理。

下一步可用Skill 客製化判斷決定哪些規則值得封裝，或看Prompt、Skill、Tool 與 Subagent 的分工；這裡處理載入範圍，不重複檔名、Shell 或剪貼簿的編碼排錯。

我的觀點：context 預算思維比 prompt 技巧重要

多數 Claude Code 教學會把重點放在「怎麼寫好的 prompt」、「怎麼用 plan mode」、「怎麼跟 subagent 互動」。這些都重要，但我覺得真正分水嶺在更前面一層——有沒有把 context 當成稀缺資源來管理。

一個會背一堆 prompt 模板的使用者，不一定比一個會管 context 的使用者強。前者解決的是「怎麼讓 Claude 一次答對」，後者解決的是「怎麼讓 Claude 一直保持答對的能力」。session 跑越久越笨的問題不是 prompt 解的，是 context 預算思維解的。

從這個角度想，CLAUDE.md 就不只是「給 Claude 看的設定檔」，而是值得在每個 session 支付 context 成本的持久規則。寫 CLAUDE.md 變成一種設計練習——哪些東西是高頻共用、值得占 context 的？哪些是低頻特例、不該每次都載入的？這個 trade-off 思維，才是 Claude Code 真正的學習曲線。

而當你開始這樣想，會發現下一個問題自然浮現：「那哪些東西不該寫進 CLAUDE.md、改用 Skill 比較划算？」這是系列第 3 篇要處理的題目。

常見問題

CLAUDE.md 該寫多長？

沒有絕對答案，但我自己的標準是：裡面每一條都要每次 session 都被用到，不然就是浪費 context。長度不重要，重要的是密度。如果某條規則只有特定情境才用得到（例如「上架文章時要做的 5 個檢查」），它放進 CLAUDE.md 就是每次 session 都繳一次 context 稅卻很少回收——這種規則應該寫成 Skill 或工作流文件、按需載入。

哪些東西寫進 CLAUDE.md、哪些用 Skill？

簡單分法是：永遠該載入的寫 CLAUDE.md、按需才該載入的寫 Skill。CLAUDE.md 在每次 session 開始就吃進 context；Skill 只在 Claude 判斷要用的時候才完整載入（先看名稱跟描述、再決定要不要展開）。Stack 描述、不可違反的安全規則、commit 規範這類「無論做什麼都該知道」的內容寫 CLAUDE.md。某個特定情境才需要的多步驟流程（例如「上架文章」「跑事實查核」）放 Skill 比較划算。系列第 3 篇會深入這條 trade-off。

這是 Claude Code 101 系列的第 2 篇：

第 1 篇：Claude Code 不是更強的補全——本質是 Agentic Loop（待發布）
第 2 篇：Context 才是 Claude Code 的稀缺資源（本篇）
第 3 篇：我為什麼把這 7 個東西都寫成 Skill——一個 PM 的客製化判斷（待發布）

本文部分觀念基於 Anthropic 公開課程 Claude Code 101、Context window 文件、How Claude Code works 與 Session management 指南。文章內容為作者自身實作筆記與判斷，非官方文件翻譯；介面與指令行為可能隨版本更新。

本節補充來源與查證日期：2026-11-06；官方 Skills 載入與 paths 規格、v2.1.312（2026-10-27 UTC發布）、使用者回報 #103776。此日期限本節與新增圖解；原圖查證日期各自保留。

資料來源與查證日期：Claude Code session 管理、Memory、Skills及 Context window。本次圖解與必要更正查證：2026-11-05。