Day 06：能力不是裝越多越好——token 有成本，「候選池」也有

昨天結尾我說，「裝上所有能力」反而會拖累 AI。今天講清楚為什麼。這件事牽涉一個很多人沒意識到的成本——不是錢，是注意力。

先講那個看得見的成本：token

用 Claude 的人大概都對「token」有點模糊的焦慮。它是計費和運算的基本單位，輸入的每個字、輸出的每個字、載入的每份文件，都在消耗它。

我自己有很長一段時間只用某個中階模型，不敢隨便升級，原因很直白——怕 token 一下子燒完。要它讀一個大檔案前，我會先想一下值不值得；一個 session 拖太長，我會考慮開新的。這種「省著用」的習慣，本身就是一種紀律。

但 token 消耗只是最表層的成本。今天真正想講的，是一個更隱蔽、也更重要的成本。

看不見的成本：你給它的每個「能力」，都在稀釋它的注意力

事情的起點是這樣：我在考慮要不要把兩個新工具，固化成 Skill（Skill 是什麼，昨天講過——把重複流程固化成一套指引）。

我當下的直覺反應，其實已經包含了答案。我對 AI 說：

「我想先試用看看再決定是否納入 Skill，東西載越多，token 就燒越快不是嗎？」

它的回答補上了我沒說完的那半：

Skill 本身是「按需載入」的，平常不會常駐佔用 context——所以它不太吃 token 的常駐成本。但它有另一種成本：每多一個 Skill，系統在判斷「這次該用哪個工具」時，要掃描、比對的候選池就多一份。

換句話說，你裝的每個 Skill、每個工具，都會出現在 AI「決定下一步做什麼」的選單裡。選單越長，它每次做選擇時要過濾的雜訊就越多。裝十個工具、但這次只需要用到一個，另外九個不會幫你，只會在它判斷時增加干擾。

這是一個很反直覺的點：能力多，不等於表現好。 就像一個工具箱塞了三百種工具，你反而更難快速找到需要的那把；一個選單有五十個選項，你點餐反而更慢。AI 也一樣——給它一個乾淨、只裝了當前任務真正需要的工具的環境，它的判斷會更準、更快。

三種擴充，三種成本型態

不過要公平地說，不是所有擴充都用同一種方式吃成本。搞清楚這點，你才知道該優先清理什麼。昨天講的三種擴充機制，成本型態其實不一樣：

• Skill：按需載入，主要成本是「候選池」。 它平常不常駐佔用 context，只有在系統判斷「這次可能要用」時才載入內容。所以它的 token 常駐成本很低（往往只有十幾到幾十），真正的代價是前面講的——每多一個，判斷時要過濾的選項就多一個。
• CLAUDE.md：常駐載入，是實打實的固定成本。 這是最該注意的一種。CLAUDE.md（還有它拆出去的 rules 檔）每次啟動都會被讀進去、常駐在 context 裡，不管你這個 session 用不用得到。它是你每次開場就先付掉的開銷。這也是為什麼官方會建議 CLAUDE.md 控制在一定行數內——不是為了好讀，是因為每一行都是每個 session 的固定稅。（怎麼寫得精簡又夠用，後面 CLAUDE.md 專章會談。）
• MCP：看設計，有的延遲載入、有的常駐。 像瀏覽器控制那類 MCP 通常是延遲載入，用到才啟動；但有些會常駐。裝之前值得確認它是哪一種。

一句話總結：Skill 佔的是「注意力」，CLAUDE.md 佔的是「每次啟動的固定額度」。 前者讓判斷變鈍，後者直接從你每個 session 的預算裡先扣一筆。兩者都要顧，但固定成本因為「每次都付」，往往是更值得先優化的地方。

有個工具能幫你算這筆帳：/doctor

前面講的都是「感覺」——感覺裝太多會拖累。但這件事其實可以量化，靠的是 Claude Code 一個很少人提的內建指令：/doctor。

你在 Claude Code 裡輸入 /doctor，它會產一份健檢報告，掃描你過去一段時間的使用狀況，然後告訴你：你裝了哪些 Skill、外掛、MCP，每一個實際被用過幾次、估計佔用多少常駐 token、以及它建議你「保留」還是「移除」。

我實際跑過一次，報告長這樣（節錄，數字是真的）：

掃描範圍：16 個專案、37 個 session，約 32 天。
發現：6 個自訂 Skill 和 1 個外掛從未被使用過，移除後每個 session 約可省下 640 個 token，且全部可還原。

它列出的「建議移除」清單，全部是安裝以來使用次數 0 次的 Skill——有的估計佔 ~91 token、有的 ~82 token。相對地，它建議保留的，都是真的常態在用的：一個合併用的 Skill「累計用了 13 次」、一個 Playwright MCP「這段期間呼叫了 155 次以上」。

這份報告把我前面講的「候選池成本」從一句感覺，變成了一個數字：那六個我裝了卻從沒用過的 Skill，每個 session 都在默默佔用 640 token 的注意力預算。 它們不是中性地「放在那裡」，是實實在在有成本的。

報告還印證了前面講的「固定成本」——它指出我那份常駐載入的 CLAUDE.md 加上幾個 rules 檔，每次啟動固定佔用約 811 token，並建議把其中一段不常用的內容抽成「按需載入」的 Skill，能把這個固定開銷降到約 448 token。這正是「常駐 vs 按需」的差別：同一段內容，從「每次都付」變成「用到才付」，固定稅就省下來了。

看完報告，我做的取捨很直接：那些零使用、/doctor 也建議移除的，我就移除了——移除前確認都有備份，隨時能放回來。判斷標準很簡單：「就算不用、放著也不影響開發」不是留下的理由，「不影響」不等於「有幫助」。

但這份報告，我沒有照單全收

這裡有個轉折，也是我覺得整件事最重要的部分。

報告裡有一個外掛，它同樣判定「0 次使用，建議移除」。但我一看就知道這條建議不能聽——因為那個外掛是我上週五才裝的，那天是週一，中間只隔了一個週末。

/doctor 用的判斷邏輯是「安裝以來使用次數為 0」，但它不知道安裝時間。上週五裝、今天週一、0 次使用，這不是「沒用到所以該刪」的訊號，而是樣本不足——它根本還沒有機會被用到。這條建議背後的邏輯有個盲點，而那個盲點，只有握著「我上週五才裝的」這個脈絡的我才看得出來。

你發現了嗎——這又是這個系列一直在講的同一件事。/doctor 是個好工具，它給的數據大多正確、也真的幫我省了 token。但它給的每一條建議，我都還是用自己的脈絡驗證過一遍：這條「省 640 token」是對的，我採納；那條「刪掉上週五的外掛」是盲點,我否決。工具負責算帳、給建議，人負責用工具沒有的脈絡做最後裁決。

關鍵心態是：「裝著」的預設不該是「留著」，而該是「證明它值得留」。 但「值得不值得」的最終判斷，不能全交給工具的啟發式規則——它會告訴你數字，你得帶著它不知道的脈絡去讀那些數字。

一個延伸的觀察：連「怎麼載入」都有講究

順帶一提，這個「總量」的直覺，也讓我對官方的一個建議產生過疑問。官方建議 CLAUDE.md 控制在 200 行內，超過就拆成多個 rules 檔。我當時問：如果這些 rules 是無條件載入的，那拆歸拆，載入的總量不變，到底有沒有改善？

這個問題的答案牽涉更細的載入機制（哪些是常駐、哪些是按需），這裡先不展開。但我想點出的是那個思考的方向——不要只看「我給了 AI 什麼」，要看「這些東西是怎麼被載入、什麼時候佔用它的注意力」。同樣一份規則，常駐載入和按需載入，成本天差地別。

這一天的分工：工具負責算帳，人負責裁決

今天的分工，/doctor 這個例子講得最清楚。

過去你可能以為「哪些能力多餘」這種事 AI 幫不上忙——但 /doctor 證明它幫得上，它能掃描、統計、算出每個工具的真實使用率和成本，甚至直接給你「保留還是移除」的建議。這是工具的強項，該用就用，別自己土法盤點。

但工具的建議是基於它看得到的資料下的，而它看不到全部。它不知道某個外掛是你上週五才裝的、不知道某個 Skill 雖然這個月沒用但下個月的專案一定會用到、不知道你的業務接下來要往哪走。這些脈絡只有你有。所以正確的用法是：讓工具算帳、給建議，你帶著它不知道的脈絡，逐條裁決該不該採納。

這跟前幾天的主軸是同一件事。工具（和 AI）能把事情算得又快又準，那是它的「1」；但讓這些數字真正做出好決定——分辨哪條建議該聽、哪條是盲點——需要人補上脈絡。裝什麼、不裝什麼，最終是人貢獻的那一份判斷。

明天談 human-in-the-loop——這個詞常被講成口號，但它其實是一套很具體的分工設計。我會用一個真實流程說明：怎麼讓 claude.ai 做分析、Claude Code 做實作，而人站在中間那個最關鍵的位置。