Claude Code 越用越亂，通常不是模型變差，而是 context 被雜訊占滿。先看結論：同一個任務仍需要前文時用 /compact；切換任務或脈絡已被錯誤嘗試污染時，用 /clear 或開新 session；跨 session 只把每次都需要的專案規則放進 CLAUDE.md。
| 你現在的情況 | 優先動作 | 原因 |
|---|---|---|
| 仍在同一個任務，前文決策還有價值 | /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）。
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 越寫越短
反直覺的觀察：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 體系也是同樣的成熟過程，差別在你抽的不是程式碼、是規範。
我的觀點：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 指南。文章內容為作者自身實作筆記與判斷，非官方文件翻譯；介面與指令行為可能隨版本更新。