Claude Code Skills 與 MCP，差在哪裡？我現在會怎麼分
前言
Claude Code 這一年真的很紅，紅到很多原本不太碰 CLI agent 的人，也開始想試看看。
但我後來發現，新手最常卡住的地方不是安裝，而是這一句：
Skills 跟 MCP 到底差在哪？
這兩個東西看起來都像在幫 Claude 長出新能力，可是真的用起來，差滿多的。我一開始也有點把它們混在一起，後來才慢慢分清楚：一個比較像是在教它照你的習慣做事，另一個是真的把外部工具接進來。
對小白來說，重點不是背定義，而是你現在卡的是哪種問題。你只是想讓它做事比較穩？還是你真的要它去碰 GitHub、資料庫、瀏覽器？這兩種需求，走的路完全不同。
最短版本其實就兩句
- Skills：比較像「教它照某種方式做事」
- MCP：比較像「真的給它一隻外接的手」
如果你只是想規範它的做事流程、口氣、專案習慣，大多數情況下先從 Skills 開始就夠了。
如果你是要讓它去碰外部世界，例如 GitHub、Slack、資料庫、設計稿、雲端服務，那才輪到 MCP 上場。1
Claude Code 本體其實已經很夠用了
現在的 Claude Code 官方文件，已經把它定位成可以直接讀專案、改檔、跑指令、串接開發工具的 agentic coding tool。1 換句話說，很多人以為一定要額外裝一堆東西才算能用，其實不是。
你光是把 Claude Code 裝起來，進到專案目錄，很多基本工作就已經能做：
- 讀 codebase
- 找 bug
- 改檔
- 跑測試
- 幫你整理 PR / commit 流程
所以 Skills 跟 MCP 不是拿來補「本體太弱」，而是拿來把它調成比較像你的工作方式。
Skills 這東西，我比較把它當成工作習慣
官方現在把這類自訂能力講得很實際：你可以透過自訂指令、記憶檔、規則文件，把你平常的習慣固定下來。1
如果用更白話的方式講，Skills 很像這種東西：
- 幫 AI 建一份 SOP
- 告訴它這個專案有什麼規矩
- 把重複做的流程包成一個可重用的工作方法
例如你可以寫一份 skill，要求它：
- 先探索再修改
- 修改後一定要跑測試
- commit message 要照某個格式
- 回覆不要太官腔
它不一定直接去打 API，但會很明顯地改變 Claude 做事的手感。
我自己最常先寫的，其實都是 Skills
我覺得 Skills 最有價值的地方，不是功能突然變超多，而是穩定度會拉起來。
因為很多時候，AI 不是不會寫，而是每次做法不一致。
今天它可能先跑測試，明天可能直接改；今天它會先看專案規則，明天又忘記。這種時候，你就會發現：與其每次重新講一遍，不如把習慣固定成一份 skill。
所以第一次碰這類工具，我幾乎都會先勸人從 Skills 開始。門檻低，效果也很直接。
那 MCP 呢
MCP 全名是 Model Context Protocol，這個你可能已經聽到耳朵長繭了。
但你不用急著背協議細節，只要先記一件事：它是把外部工具用標準方式接進來。2
也就是說，當你裝了一個 GitHub MCP、資料庫 MCP、檔案系統 MCP，Claude 不只是「知道怎麼做」，而是真的有機會去讀資料、打 API、操作服務。
這跟 Skill 最大的差別就在這裡。
Skill 是教它規矩。 MCP 是真的給它手。
哪些情況我會先動 Skills
下面這幾種情況，我幾乎都先用 Skills 解：
1. 專案有固定流程
像是：
- 先 grep 再改
- 一定要跑 typecheck
- API route 要放哪裡
- 測試命名規則
這些都不需要碰外部世界，只要讓 AI 做事更像團隊成員就好。
2. 你想把口氣和輸出格式固定住
這點很多人一開始不會想到。
如果你常讓 AI 幫你寫文件、整理變更、產生教學內容，Skills 很適合拿來固定輸出風格。不然它今天像工程師，明天像客服，後天又突然像新聞稿。
3. 你想把重複流程包起來
例如「修 bug 時一律先讀 log，再找 call site，最後補測試」，這就很適合寫成 skill。
什麼情況下，我就不會再靠 prompt 撐了
1. 你真的需要外部資料
例如：
- 讀 GitHub PR
- 查設計稿
- 讀 Notion / Slack / Jira
- 查雲端資源狀態
這些事情不是靠 prompt 可以硬撐過去的。
2. 你要的是即時資料，不是模型記憶
像「幫我看目前這個 issue 狀態」這種事，如果沒有 MCP，模型就只能猜。接了 MCP 之後，它才是真的去拿最新資料。2
3. 你要把 Claude 接到團隊實際流程裡
當你要它不只是幫你寫 code，而是真的幫你碰 GitHub、票務、文件、知識庫，那就進入 MCP 的世界了。
兩個會不會一起用？會，而且很常
我的答案很直接：會，而且這才是自然的用法。
舉個簡單例子。
你可以有一個 skill，規定它在處理 bug 時的步驟；再搭配一個 GitHub MCP，讓它可以真的去看 issue、PR 和 commit。
這樣它既知道「應該怎麼做」，也真的有東西可以去碰。這時候整體手感才會比較完整。
小白怎麼起步，比較不會第一天就亂掉
我自己會走這個順序：
- 先安裝 Claude Code，確認基本功能正常
- 先寫 1 到 2 份最常用的 Skills
- 用一週看看哪些地方還需要外部工具
- 再接一個最需要的 MCP，不要一口氣裝十個
因為你一開始就把 MCP 裝滿，最後很容易連自己都不知道現在到底是哪一層在壞。
我自己現在的選法
如果今天是一個個人專案，我通常會這樣分：
- Skills：專案規範、輸出格式、測試流程、寫作習慣
- MCP：GitHub、文件查詢、瀏覽器、自訂資料來源
也就是說，凡是「應該怎麼做」，我盡量寫到 skill。
凡是「要去拿什麼資料、碰什麼系統」，我才放 MCP。
這樣分久了會很清楚，也比較不會混在一起。
這兩個東西最容易被講得很玄，實際上沒有那麼神祕。
如果你現在剛接觸，我覺得先這樣記就夠了：
- Skill 是你寫給 AI 的工作習慣
- MCP 是你接給 AI 的外部工具
先把這個差別吃透，後面很多東西就不會混在一起。
而且我自己用到現在，最大的感想也不是「哇，功能好多」，而是工具越強，邊界越要講清楚。不然它一下太保守，一下太亂衝，你最後反而更累。
所以如果你問我新手先學哪個，我還是會先說：先 Skill，再 MCP。