AI Agent 應用2026.05.08

Context 才是 Claude Code 的稀缺資源

用 Claude Code 用一陣子之後常會發現它越用越笨——但多半不是模型變差，是 context window 用爆了。Context 不是無限的容量，是有預算的稀缺資源。學會在 session 內用 /compact 跟 /clear、跨 session 用 CLAUDE.md，比背更多 prompt 技巧重要太多。

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

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

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

課程把 context window 描述成 Claude Code 的「working memory」——所有輸入它的東西都會吃掉這塊空間：你打的 prompt、它讀過的檔案、它跑過的 tool call 結果、它收到的回應。每一次互動都在消耗預算。

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

另一個關鍵差別是：context 不是「容量」、是「預算」。一個 session 結束，整塊桌面就清空了。下次打開，Claude 不記得上次你聊過什麼。要長期記住的東西，必須寫到 session 之外的地方——這也是 CLAUDE.md 存在的理由（後面會講）。

當預算快用完，Claude Code 會自動 compact——把前面的對話、tool call 結果做摘要，騰出空間繼續。這個機制很方便，但代價是會丟細節。原本完整保留的指令可能變成兩句摘要，原本記得的檔案內容可能只剩標題。如果你的任務需要完整脈絡，auto-compact 之後常會出現「Claude 突然忘了什麼」的感覺——其實不是它忘了，是被它自己摘要掉了。

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

Session 內怎麼管：/compact 跟 /clear 的差別

Session 內 context 管理只有兩個指令真的重要：/compact 跟 /clear。差別不是技術細節，是適用情境。

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

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

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

所以我比較常用的反而是 /clear，不是 /compact。寧可花 30 秒重新給 Claude 一個乾淨的 onboarding，也不要讓它帶著一堆雜訊做新事。

CLAUDE.md 是跨 session 的 context

Session 內預算管得再好，每次重新開始都還是要把專案資訊重新解釋一次——這就是 CLAUDE.md 要解決的問題。它是放在專案根目錄的 Markdown 檔，每次 Claude Code 啟動會自動讀取，內容會被 append 到你的 prompt 前。換句話說，它是一份不耗費 session context 預算就能讓 Claude 記住的東西。

但這個工具有個誤解：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 篇：