Claude Code 中的 Skills、Subagents、MCP 與 Plugins：該選哪一種

目前在 Claude Code 中，有五種方法可以做同一件程式碼審查：斜線指令、skill、subagent、plugin，或直接在聊天中輸入 prompt。這些方法沒有哪一種預設就比其他方法好；選擇取決於任務、token 預算，以及除了你之外還有哪些人會使用它。

這篇指南是我希望一年前就有人交給我的內容：一棵由 4 個問題組成的判斷樹、一份可直接使用的「任務 → 層級」矩陣，以及我合作過的 vibe coder 每隔一個就會犯、浪費 token 的 5 種常見錯誤。

關於如何使用這項服務，請參閱 Ailoot 文件。

用一句話說明 skills、subagents、MCP 和 plugins 是什麼？#

在選擇之前，先釐清這些名詞。這四種層級的目標都是擴充 Claude 開箱即用的能力，但各自的性質不同。

Skill 是一個包含 SKILL.md 檔案的目錄，檔案中說明何時以及如何套用特定方法。Anthropic 把 skill 比喻成給新進員工的操作程序：你不會每天逐步交代他們每件事，而是提供一套流程。

Subagent 是從主要對話啟動、擁有自己 context 的獨立 Claude 工作階段。它有一個關鍵特性：隔離。subagent 可以讀取 30 個檔案、整理出摘要，並只把摘要傳回主聊天。主要對話的 context 便能保持精簡。

MCP（Model Context Protocol） 是 Anthropic 制定、用來連接 Claude 與外部系統的開放標準。Anthropic 在 2025 年 11 月 13 日的一篇部落格文章中，清楚說明了兩者的差異：

Plugin 是別人準備好的一套 skills、subagents、hooks 和指令，並透過市集包裝發佈。使用 /plugin install 就能用一行指令安裝，一次取得所有內容。如果 skill 是你自己的流程，plugin 就是向另一家公司購買的流程。

簡單來說，skills 是食譜，subagents 是專業同事，而 MCP 則提供外部工具，讓 Claude 能連上服務和資料。token 成本各有不同：skill 最便宜（只有觸發時才載入），MCP 則相對昂貴（每個連線中的伺服器都會持續占用 context window 空間）。

如果有一份 CLAUDE.md，為什麼還需要 4 種層級？#

在前面提到的專案中，CLAUDE.md 是一份大型規則地圖：東西要放在哪裡、如何發佈，以及有哪些協議。沒有這個檔案，Claude 每次開始新工作階段時都得從頭來過。

不過，CLAUDE.md 有其上限。以下說明它在三種情況下會失效。

情況 1：規則只有時好時壞。 CLAUDE.md 寫著「git push 前一律執行 npm run build」。Claude 在工作階段開始時讀過、點頭，接著聊了 25 則訊息後開始寫程式，然後就忘了。我已經抓到自己有 3 次沒跑 build 就 push；那些 push 都在正式環境中失敗了。設定正確且經測試的 hook，可執行確定性的 build 檢查並拒絕涵蓋的操作。涵蓋範圍取決於事件與工具路徑；Claude Code hook 本身不會攔截其他終端機或 app 的每次 push。請故意讓 build 失敗，驗證實際使用路徑確實遭阻擋。

情況 2：重複執行 15 個步驟的流程。 在前述例子中，每篇指南都會經過 14 個階段：研究 → 架構 → MDX → 7 項平行 QA 檢查 → 正式環境發佈 → IndexNow。如果我每次都寫一個 prompt，要求「執行第 1 階段，再做第 2 階段，然後第 3 階段」，還沒開始就先浪費 token。因此，我把整套工作流程封裝成 build-masterskaya-guide skill，只要說「我們來為這個專案做一份新指南」就能啟動。這是一套 34 KB 的指示。

情況 3：任務耗盡 context。 若要檢查已發佈的指南是否仍然最新，Claude 必須讀取一份 30 KB 的直播逐字稿、20 份各 5 KB 的回顧資料，並與目前網站比對。如果我在主聊天中做這件事，審查結束時 context 裡就會堆滿 200K token 的雜訊。subagent 做同樣的工作，只把 300 字的摘要傳回主要對話，然後結束。

情況 4：我希望團隊取得和我相同的範本。 前端設計的現成規則、透過 Coolify 發佈的 hooks、用於 Playwright 檢查的 MCP。這就是 plugin：我打包自己的設定，在市集發佈，同事就能用一行指令安裝。

CLAUDE.md 負責基本原則：「我們在這裡怎麼做事。」上面的 4 種層級則處理 CLAUDE.md 實際上做不到的事：透過觸發條件重複執行、隔離 context、存取外部世界，以及分享。

什麼時候該用 skill，而不是 CLAUDE.md？#

判斷是否該做成 skill 很簡單：你發現自己不斷把筆記裡同一段長 prompt 複製到聊天中。第三次就已經是訊號。

我目前在 ~/.claude/skills/ 有 7 個目錄：build-masterskaya-guide、build-vc-spoke、build-reel-script、build-practicum-instruction、update-config、simplify 和 keybindings-help。使用最頻繁的是 build-masterskaya-guide（這篇指南就是用它撰寫的）。裡面有 34 KB 的方法說明：要經過哪些階段、要執行哪些多代理 QA 檢查、哪些閘門條件應該中止流程，以及要將哪些產出存到 /tmp/。

不該建立 skill 的情況。

• 「用使用者偏好的語言回答」這類規則應該放在 CLAUDE.md，而不是 skill。skill 只會在觸發時載入，但這項規則應該時時適用。
• 「現在執行重構」這類一次性指示應該放在聊天中，而不是 skill。
• 需要獨立 context 的任務可用 subagent；若也遵循重複流程，方法仍應保留在 skill。

主要反模式。 vibe coder 最常犯的錯，是把原本該做成 skill 的流程塞進 subagent。subagent token 成本較高（因為它有自己的 context）、啟動較慢，而且常常大材小用。如果一項任務的方法說明可以在不讀取外部檔案的情況下寫成 1,500–2,000 個字，那它就適合做成 skill。

至於如何規劃 skill 的結構、frontmatter 要放什麼，以及哪些觸發詞有效，請參閱指南 2026 年的 Claude Code Skills：如何建立個人 Skills 資料庫。

什麼時候該用 subagent，而不是 skill？#

skill 儲存方法，subagent 執行工作。兩者都是「從聊天中」啟動，因此常被混淆，但它們是不同的層級。

只有在需要隔離 context 時，subagent 才有意義。主要 Claude 工作階段的預算是 200,000 token（beta 版為 100 萬）。如果你在主聊天中要求它讀取 30 個檔案並逐一分析，光是中間的閱讀過程就會耗掉一半的視窗。subagent 會在獨立工作階段執行相同工作，只把結果傳回主聊天。

具體的專案範例。 每篇指南都會經過多項平行 QA 檢查：風格、對照一手來源的引文和事實、搜尋引擎適用的結構，以及內外部連結的完整性。每項檢查都需要自己的 context：規則詞彙表、透過 WebFetch 讀取數十個 URL，以及對文字執行 grep。

如果我在同一個聊天中執行所有檢查，第一項還沒完成，context 就會把我淹沒。使用 run_in_background: true 平行啟動 subagents 就能解決：它們在背景工作，主聊天繼續進行，4–6 分鐘後我就會收到精簡報告並套用修改。

第二個範例——繁重的研究。 為新指南選主題時，我會讓 4 個 subagents 平行蒐集訊號：

• V1 - 過去 14 天的論壇與社群
• V2 - 社群網路
• V3 - 影音平台 + Anthropic 部落格
• V4 - SEO 缺口

每個 subagent 都會回傳 30–40 個項目，並附上話題傳播分數。我會把它們彙整成候選清單，依照 9 個面向加權，然後挑選最佳主題。若沒有 subagents，這個階段會拉長到 2–3 小時，並耗用主要 context。

不該建立 subagent 的情況。

• 不需要讀檔或使用 WebFetch 的任務，應該在主聊天中處理。
• 重複流程適合 skill，但需要隔離時，也可在 subagent 內執行。
• 外部存取需要 MCP 或 CLI 等已授權工具，受委派的 subagent 也能使用。

主要反模式。 建立名為 backend-engineer 或 qa 的 subagent，期待 Claude 自己判斷何時使用。具體的 subagents（例如 migration-test-writer 或 api-route-reviewer）品質好得多。subagent 的名稱和指示越精確，Claude 就越能準確選對。

至於如何建立特定任務用的 subagents、frontmatter 語法，以及 5 個現成範例，請參閱指南 2026 年的 Claude Code Subagents：逐步指南。

什麼時候該用 MCP，而不是 skill 或 subagent？#

Anthropic 在一篇部落格文章中用最精簡的說法概括兩者差異：MCP 將 Claude 連接到資料，skills 則教 Claude 如何使用那些資料。

例如 GitHub issue 審查 skill 需要 issue 內容，可以透過已授權 MCP、CLI 或直接提供文字取得。skill 再定義如何審查與組織發現，MCP 存取本身不會規定流程。

我實際使用的 MCP 組合。

• Playwright MCP - 每篇指南的視覺 QA。開啟桌面版和行動版頁面，檢查容器寬度和區塊是否正確呈現。
• Stitch MCP - 存取設計系統，並以品牌風格產生元件。
• vidIQ MCP - 趨勢分析，以及檢查想法是否有話題傳播力。
• Railway MCP - 管理部署基礎設施。

這 4 個都是連接外部系統的橋梁。沒有 MCP，我就得自己寫包裝程式，或改用瀏覽器。有了 MCP，所有事情都能在 Claude 工作階段中完成。

Token 成本。 MCP 是成本最高的層級。每個連線中的伺服器都會持續占用 context window 空間，包括工具宣告、引數 schema 和說明文字。我有 4 個 MCP 伺服器，所以每次新工作階段還沒問任何問題，就會先占用約 8–12K token。

因此，只有在大多數工作階段中真的需要時，我們才連接 MCP。如果你一週只用一次 Sentry MCP，最好用 --mcp sentry 旗標在需要時才啟用，而不是永遠把它列在清單中。

不該使用 MCP 的情況。

• 「如何處理資料」的方法應該放在 skill，而不是 MCP。
• 長時間讀檔任務可能適合 subagent；若部分檔案或紀錄在外部，該子代理也可能需要 MCP 存取。
• 若要用一個指令發佈，應該用 hook 或 plugin，而不是 MCP。

主要反模式。 為了原本用 skill 就能處理的事情建立 MCP 伺服器。我在一則 HN 討論中看到一個例子（就是 5 月 27 日那篇有 422 點的討論串）：作者建立了一個提供「程式碼審查指示」的 MCP 伺服器。但這不是存取外部世界，而是一套流程。skill 做同一件事，token 用量只有十分之一。

資源衝突事件。 有一次 Playwright MCP 因為「Browser is already in use」錯誤而卡住：當時我也開著 Chrome 視窗，MCP 無法接管瀏覽器。這件事帶來一項重要教訓：MCP 伺服器會使用共用的系統資源。如果資源（瀏覽器、連接埠或檔案）發生競爭，從一開始就要考慮隔離。

連接 7 個可用 MCP 的現成指南，請參閱 2026 年的 Claude Code MCP Servers：7 種可直接使用的設定。

什麼時候該用 plugin，而不是 skill 或 subagent？#

Skills、subagents 和 MCP 關乎你自己的方法。plugin 則是匯入設定中的、由別人準備好的方法。

2025 年 10 月，Anthropic 推出 Claude Code Plugins，作為官方發佈管道。plugin 是一個目錄，可以包含：

• 自己的斜線指令
• 自己的 skills
• 自己的 subagents
• 自己的 hooks
• 自己的 MCP 設定
• 自己的輸出樣式

所有內容都會透過 plugin.json 封裝成一個套件。安裝時，只要在 ~/.claude/settings.json 加上一行，或執行 /plugin install <name> 指令即可。

我實際使用的 plugin 組合。

• frontend-design 來自官方的 claude-plugins-official，包含 67 種風格、96 種配色、57 種字型組合和 13 種框架。我要為網站製作新區塊或電子郵件範本時，就載入這個 plugin，一次取得整個資料庫。
• playwright 來自同一個官方市集，是一套用於瀏覽器測試的 skills 和 MCP 設定。
• telegram 是一套透過 Claude Code 管理 Telegram 帳號的現成組合（政策、allowlist、配對）。
• trailofbits/skills 是 Trail of Bits 提供的一套安全 skills；在安全議題上，我信任這家公司。

這 4 個只占 settings.json 的三行。沒有 plugins，我得花好幾個小時手動打造相同的資料庫。

不該使用 plugin 的情況。

• 如果方法完全是你自己的，也不打算擴展給別人使用，就保留為 skill。
• 如果還不確定誰會使用，先把它做成自己的 skill 試用。
• 如果只是要快速把 3 個檔案放到新機器上，用 cp ~/.claude/skills/X /new/machine/.claude/skills/ 就可以。

主要反模式。 用 plugin 取代 CLAUDE.md，例如建立一個包含「這個專案的工作方式」規則的 plugin。plugin 是為了發佈和重複使用而設計。如果規則只適用於一個 repository，就應該放在 CLAUDE.md，而不是 plugin。

展望 2026 年：Anthropic 顯然正朝團隊用 plugin 市集發展。這表示企業可以把內部方法以 plugins 形式發佈、管理版本，並用一個指令為所有員工更新。對獨立創業者來說，這代表：安裝現成的東西，不要重新發明。

判斷樹：每項任務開始前要問的 4 個問題#

問題 1：是否有值得保存的重複流程？

若有，把方法整理成 skill 的 SKILL.md，清楚說明何時使用。它提供流程，本身不提供外部存取或獨立上下文。

問題 2：工作是否需要獨立上下文或聚焦的委派角色？

若有，使用 subagent，提供精確任務與工具。同一任務也可在獨立上下文遵循 skill 的方法。

問題 3：是否需要工具或外部資料存取？

若有，透過 MCP 或適當工具提供已授權存取，例如已設定的 CLI。skill 說明如何使用，子代理則可以是執行它的角色。

問題 4：是否要將設定封裝發布並維護？

若有，使用 plugin 發布相關 skills、代理定義、hooks 或 MCP 設定；套件可以由你自己或其他作者提供。

組合範例：定期 GitHub issue 審查。 skill 定義審查方法與輸出格式；已設定的 GitHub MCP 或 CLI 提供授權存取；子代理在自己的上下文讀取長討論串並回傳發現；plugin 將整個組合發給團隊。四題都可回答「是」，彼此不會抵銷。

vibe coder 常犯的 5 種層級選擇錯誤#

我每週都會在合作的 vibe coder 身上看到這 5 種模式。每兩個人就有一個至少會在第一週犯其中一種錯誤。

錯誤 1：用 subagent 取代 skill。

症狀：有人為「撰寫一篇新的部落格文章」建立 subagent。每次執行時，subagent 都會啟動、讀取 2 KB 的方法說明、產生文章，然後結束。一週後，作者發現每次執行都會多花 5K token 載入 subagent。

正確做法：「如何寫文章」是一套方法，應該做成 skill。觸發詞是「新部落格文章」。skill 會載入主聊天，不會另開工作階段。成本低 3–5 倍。

錯誤 2：用 MCP 伺服器取代 skill。

症狀：有人寫了一個 MCP 伺服器，提供「如何進行程式碼審查」的指示。工具宣告、引數 schema 說明和文件一直占用 context。每次請求都會白白浪費 2–3K token。

正確做法：「如何進行程式碼審查」是一套流程，不是存取外部系統。應該使用 skill。只有在需要即時存取時，MCP 才有用，例如連上 Sentry 取得最新錯誤。

錯誤 3：用 plugin 取代 CLAUDE.md。

症狀：有人把專案規則（「一律使用 TypeScript strict mode」、「不要使用任何破折號」、「只用 pnpm，不用 npm」）封裝進 plugin 並安裝。現在每個新工作階段都會載入 plugin，重複了原本該寫在 CLAUDE.md 的內容。

正確做法：單一專案的規則應該放在該專案的 CLAUDE.md。plugin 適合能擴展到多個人或多個 repository 的方法。

錯誤 4：試圖透過 hook 建立 skill。

症狀：有人看到 hook 會在某個事件發生時自動執行（例如儲存檔案前），就決定打造「透過 hook 執行的 skill」，讓 Claude 每次編輯時都自動套用方法。結果出現無止盡的觸發迴圈、浪費 context，行為也變得難以預測。

正確做法：hook 是確定性程式碼，用來執行指令、格式化結果或阻止操作。hook 不會載入 skill，也不會呼叫 Claude。如果你需要「一律套用方法 X」，就使用帶有觸發條件的 skill，或在 CLAUDE.md 中加入一項規則。

錯誤 5：根本不需要時，卻多加一個層級。

症狀：有人聽說 skills、讀了指南，決定「我需要把這套方法封裝起來」，然後花一個晚上為每月只會遇到一次的任務建立 skill。

正確做法：一次性任務就臨時在聊天中處理。只有每天執行不只一次的事才值得做成 skill。否則就是過度設計，之後還得維護。

這些例子的共同做法，是獨立檢查流程、上下文或角色隔離、工具存取與套件發布需求。每個層級都應有具體用途；需要多項時就組合。

Anthropic 如何看待層級分散：Claude Code 在 2026 年的發展方向#

接下來 6 個月至 1 年會如何發展？

第一：skills 正成為程序性任務的主要層級。 Anthropic 顯然押注這個層級，因為它成本最低、也最容易預測。如果你不懂為什麼 2026 年需要 skill，就先研究 skill。其他層級都會圍繞它發展。

第二：subagents 正走向專業化。 subagents 的主要用途是為繁重任務隔離 context。qa-engineer 這類通用 subagents 會消失；migration-test-writer 和 api-route-reviewer 這類具體 subagents 則會保留下來。

第三：Anthropic 在 14 天內的新公告——用於協調數十個 subagents 的 /workflows 指令（2026 年 5 月 28 日），以及從 6 月 15 日開始將 Agent SDK 費用分開計算——表示程式化使用正移往獨立的資源池。 這代表 Anthropic 正在為由 10+ 個代理組成的自動化系統打造基礎設施，而不是只服務個別工作階段。

對 2026 年的 vibe coder 來說，意思很簡單：這四種層級至少還會存在 6 個月，之後其中一些可能會合併。但即使合併後，這棵由四個問題組成的判斷樹仍然有用，因為它看的是任務本質，而非層級的具體名稱。

現成矩陣：10 種常見任務 → 適合的層級#

使用這張表的主要原則是，不要試圖「一次做完全部 10 項」。大多數個人 vibe coder 使用 CLAUDE.md + 5–7 個 skills + 2–4 個 MCP 伺服器就夠了。隨著專案成長，再加入 subagents 和 plugins。

接下來：如何在 Claude Code 中打造你的工作環境#

這五種層級不是一個接一個排列，而是彼此嵌套。CLAUDE.md 是專案的基礎，其他四種則會隨著任務需求逐步加入。

認識 Ailoot。