# Claude Code 中的 Skills、Subagents、MCP 與 Plugins：該選哪一種 > Skills、subagents、MCP 和 plugins 是 Claude Code 的四種擴充層。我會說明各自的適用時機，並提供可直接使用的判斷矩陣和專案範例。 Source: https://ailoot.ai/blog/zh-hant-tw/skills-subagents-mcp-plugins-claude-code/ Canonical: https://ailoot.ai/blog/zh-hant-tw/skills-subagents-mcp-plugins-claude-code/ Language: zh-Hant-TW Publisher: Ailoot (https://ailoot.ai/) Translation: guide-214 Revision: sha256-4bc2b2a715ff4b9c6673e9eecfaca3d73b3f89f741eeb91ea56eed58a66020b8 目前在 Claude Code 中，有五種方法可以做同一件程式碼審查：斜線指令、skill、subagent、plugin，或直接在聊天中輸入 prompt。這些方法沒有哪一種預設就比其他方法好；選擇取決於任務、token 預算，以及除了你之外還有哪些人會使用它。 這篇指南是我希望一年前就有人交給我的內容：一棵由 4 個問題組成的判斷樹、一份可直接使用的「任務 → 層級」矩陣，以及我合作過的 vibe coder 每隔一個就會犯、浪費 token 的 5 種常見錯誤。 關於如何使用這項服務，請參閱 [Ailoot 文件](https://ailoot.ai/docs/)。 ## 用一句話說明 skills、subagents、MCP 和 plugins 是什麼？
重點摘要 skill 是一套封裝好的方法，Claude 會在觸發時載入。subagent 是一位擁有獨立 context、負責長時間任務的隔離「同事」。MCP 是連接外部系統（資料庫、GitHub、Notion）的橋梁。plugin 則是別人準備好、包含上述項目的套裝，只要一行指令就能安裝。
在選擇之前，先釐清這些名詞。這四種層級的目標都是擴充 Claude 開箱即用的能力，但各自的性質不同。 **Skill** 是一個包含 `SKILL.md` 檔案的目錄，檔案中說明何時以及如何套用特定方法。Anthropic 把 skill 比喻成給新進員工的操作程序：你不會每天逐步交代他們每件事，而是提供一套流程。 **Subagent** 是從主要對話啟動、擁有自己 context 的獨立 Claude 工作階段。它有一個關鍵特性：隔離。subagent 可以讀取 30 個檔案、整理出摘要，並只把摘要傳回主聊天。主要對話的 context 便能保持精簡。 **MCP（Model Context Protocol）** 是 Anthropic 制定、用來連接 Claude 與外部系統的開放標準。Anthropic 在 2025 年 11 月 13 日的一篇部落格文章中，清楚說明了兩者的差異：

MCP 將 Claude 連接到資料；Skills 則教 Claude 如何使用那些資料。如果你是在說明如何使用工具或遵循程序，例如「查詢我們的資料庫時，務必先用日期範圍篩選」，那就是 Skill。如果你需要讓 Claude 先能存取資料庫或 Excel 檔案，那就是 MCP。

— Anthropic Engineering, https://claude.com/blog/skills-explained
**Plugin** 是別人準備好的一套 skills、subagents、hooks 和指令，並透過市集包裝發佈。使用 `/plugin install` 就能用一行指令安裝，一次取得所有內容。如果 skill 是你自己的流程，plugin 就是向另一家公司購買的流程。 簡單來說，skills 是食譜，subagents 是專業同事，而 MCP 則提供外部工具，讓 Claude 能連上服務和資料。token 成本各有不同：skill 最便宜（只有觸發時才載入），MCP 則相對昂貴（每個連線中的伺服器都會持續占用 context window 空間）。 ## 如果有一份 CLAUDE.md，為什麼還需要 4 種層級？
重點摘要 CLAUDE.md 是一項請求：Claude 會在工作階段開始時讀取它，但 20 則訊息之後可能就會忽略。Skills、subagents、MCP 和 plugins 能處理 CLAUDE.md 無法做到的事：擴充規模、隔離 context、存取外部世界，以及和團隊分享方法。
在前面提到的專案中，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。和 CLAUDE.md 不同，skill 只會在需要時載入，不會在每個工作階段耗用基礎 context。
判斷是否該做成 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 資料庫](https://ailoot.ai/blog/zh-hant-tw/claude-code-skills-library/)。 ## 什麼時候該用 subagent，而不是 skill？
重點摘要 subagent 會把繁重工作移到自己的 context，只把摘要傳回主聊天。如果任務需要讀取許多檔案、進行長時間分析，或平行執行 5 項相同檢查，而且你不需要在主要對話中看到所有中間雜訊，就該使用它。
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：逐步指南](https://ailoot.ai/blog/zh-hant-tw/claude-code-subagents/)。 ## 什麼時候該用 MCP，而不是 skill 或 subagent？
重點摘要 MCP 為資料庫、GitHub、Sentry 或瀏覽器等系統提供工具與資料存取。工作流程需要這些存取時就使用；skill 可提供使用同一批工具的方法，兩個層級互補。
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 種可直接使用的設定](https://ailoot.ai/blog/zh-hant-tw/mcp-servers-claude-code/)。 ## 什麼時候該用 plugin，而不是 skill 或 subagent？
重點摘要 plugin 是別人準備好的一套 skills、subagents、hooks 和指令，只要透過市集用一行指令安裝。若你不想從頭打造所有東西，也信任套件作者，就可以使用 plugin，例如用於前端設計、Playwright 測試或 Telegram 整合。
Skills、subagents 和 MCP 關乎你自己的方法。plugin 則是匯入設定中的、由別人準備好的方法。 2025 年 10 月，Anthropic 推出 Claude Code Plugins，作為官方發佈管道。plugin 是一個目錄，可以包含： - 自己的斜線指令 - 自己的 skills - 自己的 subagents - 自己的 hooks - 自己的 MCP 設定 - 自己的輸出樣式 所有內容都會透過 `plugin.json` 封裝成一個套件。安裝時，只要在 `~/.claude/settings.json` 加上一行，或執行 `/plugin install ` 指令即可。 **我實際使用的 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 種層級選擇錯誤
重點摘要 成本最高的錯誤包括：用 subagent 或 MCP 取代 skill、用 plugin 取代 CLAUDE.md，以及透過 hook 執行 skill。這些做法都會浪費 token 或破壞行為。以下用具體例子說明發生了什麼事，以及正確做法應該是什麼。
我每週都會在合作的 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 年的發展方向
重點摘要 Claude Code 正在整合程式碼審查的五種方法：指令、skill、subagent、plugin 或聊天，逐步匯聚為內建的 `/code-review` skill。也就是說，不必擔心「層級太多」；這些界線正在變得模糊，整體也會更精簡。
接下來 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 種常見任務 → 適合的層級
重點摘要 表格標出各情境的主要需求，資料列彼此互補；同一任務可符合多列，並組合所列層級。
| \# | 觸發情況 | 適合的層級 | 為什麼選它 | |----|----|----|----| | 1 | Claude 在同一個工作階段中，2–3 次漏掉同一條規則 | **CLAUDE.md** | 被動生效、一直存在於 context 中，而且不需要觸發條件 | | 2 | 我每天輸入不只一次相同的長 prompt | **Skill** | 需要時才載入，不會耗用基礎 context | | 3 | 第三次把 1,500 字的操作手冊貼到聊天中 | **Skill** | 屬於程序性方法，由觸發詞載入 | | 4 | 讀取 20 個以上檔案的任務耗盡主聊天 | **Subagent** | 隔離 context；只有摘要會回到主聊天 | | 5 | 需要平行執行 5 項相同檢查（QA、審查、lint） | **Subagents** | 以 `run_in_background` 啟動；總時間縮短為五分之一 | | 6 | 我想讀取 GitHub issues 或 Sentry 的最新錯誤 | **MCP** | 透過標準協定直接存取外部系統 | | 7 | 我想自動檢查所涵蓋的 push 操作 | **經測試的 Hook** | 確定性檢查；須驗證實際觸發與阻擋行為 | | 8 | 我想把設定移到第二個 repository 或新機器 | **Plugin** | 透過市集發佈，並有 namespace | | 9 | 10 人團隊需要遵守相同規則 | **團隊市集中的 Plugin** | 有版本管理，一次安裝、集中更新 | | 10 | 需要回應外部服務的 webhook（Telegram、GitHub Actions） | **MCP channel 或 Agent SDK** | 從外部把 push 訊息送進工作階段 | 使用這張表的主要原則是，不要試圖「一次做完全部 10 項」。大多數個人 vibe coder 使用 CLAUDE.md + 5–7 個 skills + 2–4 個 MCP 伺服器就夠了。隨著專案成長，再加入 subagents 和 plugins。 ## 接下來：如何在 Claude Code 中打造你的工作環境
重點摘要 CLAUDE.md 保存專案基本規則，skills 封裝方法，subagents 分擔繁重的 context，MCP 連接外部世界，而 plugins 則發佈別人準備好的套裝。這些就是 2026 年 Claude Code 設定的五個基礎構成。
這五種層級不是一個接一個排列，而是彼此嵌套。CLAUDE.md 是專案的基礎，其他四種則會隨著任務需求逐步加入。
### 來源 - [Anthropic Engineering: Skills explained (2025 年 11 月 13 日)](https://claude.com/blog/skills-explained) - [Claude Code docs: Skills overview](https://code.claude.com/docs/en/skills) - [Claude Code docs: Subagents](https://code.claude.com/docs/en/subagents) - [Claude Code docs: MCP overview](https://code.claude.com/docs/en/mcp) - [Claude Code docs: Plugins](https://code.claude.com/docs/en/plugins) - [Claude Code releases on GitHub](https://github.com/anthropics/claude-code/releases) - [Anthropic news: blog updates 2026](https://www.anthropic.com/news) - [Sentry MCP cookbook](https://sentry.io/blog/sentry-mcp-server-for-claude-code/) - [Trail of Bits skills repository](https://github.com/trailofbits/skills) - [Claude Plugins official marketplace](https://github.com/anthropics/claude-plugins-official)
認識 [Ailoot](https://ailoot.ai/)。 ## 常見問題：Claude Code 中的 Skills、Subagents、MCP 與 Plugins：該選哪一種 ### 一次 GitHub 審查，可以同時需要 skill、子代理與 MCP 嗎？ 可以。skill 定義流程，MCP 或已授權 CLI 提供 issue 資料，子代理可在獨立上下文進行長審查，plugin 則能發布整個組合。 ### 四問題清單應怎麼使用？ 每題獨立回答：是否需要流程、上下文隔離、工具存取或套件發布？每個「是」都新增一項具體需求，第一個「是」不代表決策結束。 ## Ailoot · 公司及其專案組合 Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。 公司及其專案組合：數百萬客戶，每月銷售額達數十億。 Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。