AI 開發趨勢：CLI + Skills 正在取代 MCP？
近一年在 AI 開發圈裡，MCP（Model Context Protocol）幾乎每天都被提到。隨著實際落地經驗增加，越來越多開發者開始討論另一個更務實的方向：CLI + Skills。不少人甚至認為：MCP 可能被高估，而 CLI + Skills 才是 AI 工作流真正的基礎。
這篇文章整理幾個核心觀點：MCP 為什麼會遇到瓶頸、CLI + Skills 為什麼開始流行、用 Git 當貫穿全文的實際案例，以及 MCP 在什麼情境下仍然必要。最後收斂到一個結論：與其說「取代」，不如說 CLI + Skills + MCP 會形成三層架構，各自負責不同的事。
1. MCP 的理想與現實
MCP 的核心理念其實很好：讓模型透過統一協議調用工具與資源。例如資料庫、API、SaaS 系統、內部工具——模型只需要知道工具的 schema，就能呼叫。理論上非常漂亮。
但在實務上，很多團隊遇到幾個問題：token 成本暴漲、tool routing 不穩定、tool schema 的開發與維護成本過高。下面分開說。
2. MCP 的主要問題
2.1 Token 成本
MCP 最大問題之一是 context injection。每個 tool 都需要描述：description、parameters、schema。工具數量一多，prompt 就會快速膨脹。常見情況是：prompt 動輒數萬 tokens，實際任務可能只佔幾百 tokens，在 production 環境成本非常高。工具越多、schema 越細，context 就越肥，模型每次推理都要背著這一大包，效率與成本都吃不消。
2.2 Tool routing 不穩定
MCP 的典型流程是：LLM → 決定用哪個 tool → 呼叫 tool。但 LLM 的 routing 其實不穩定。例如使用者說「deploy staging」，模型可能選錯工具、或傳錯參數。最後很多團隊只好改成 LLM + hardcoded routing（例如特定關鍵字就固定走某個 tool），這樣一來，MCP 的「動態發現、統一調用」抽象層價值就下降了。
2.3 Tool schema 開發成本高
MCP 通常需要 OpenAPI、JSON schema、function definitions 等，才能讓模型正確呼叫。但很多時候開發者其實只需要「執行一個 script」或「跑幾條指令」。對這類簡單任務來說，MCP 的整套約定與實作顯得過重，開發與維護門檻都高，生態也容易碎片化（各家用各家的 schema、版本不一）。
3. CLI + Skills 為什麼變成趨勢
CLI 本質上就是 開發者世界最成熟的介面。幾乎所有開發與維運的基礎設施都提供 CLI：git、docker、kubectl、terraform、npm……。AI 其實只是在模仿開發者的行為：人類怎麼下指令、看輸出、再決定下一步，AI 就怎麼做。因此 CLI 對 AI 非常自然，不需要再發明一層「工具協議」——契約就是「指令 + stdout / stderr + exit code」。
Skills 則是 可組合的 CLI workflow：把一連串指令包成一個有名字的「技能」，AI 只需要呼叫 skill，不必自己拆解每一步。例如 skill「prepare-release」背後可能是：git pull → git status / git diff → 請 AI 生成 commit message → git add → git commit → git push。AI 只負責「在對的時機觸發 prepare-release」，底層由系統執行。這樣既降低 token（不用把每個 git 子指令都塞進 context），又讓行為 deterministic（同一個 skill 永遠跑同一套流程）。
還有一點常被忽略：寫 MCP 工具，背後一樣要有腳本或程式在執行——打 API、查資料、跑邏輯，都是那段 code 在做。所以 執行層 其實一樣：真正做事的是 script 或 binary。差別只在 介面層：用什麼方式觸發、用什麼契約呼叫。在多數情境下，這層介面正被 Skill 取代：AI 只須說「執行 prepare-release」或「執行 sync-branch」，底下直接跑 CLI／腳本就好，不必再經過 MCP 的 schema 與 JSON 協議。也就是說，介面層由 Skill 擔綱（一個名字對應一個流程），執行層就是 CLI／script；MCP 的介面層只留在真的需要 server 端權限控管或即時雙向通訊的情境。
4. 用 Git 看 CLI + Skills 怎麼運作
我們用 Git CLI 當一個從頭到尾的案例，說明「CLI 當介面、Skills 當流程」長什麼樣子。
4.1 CLI 當介面：AI 只產出指令
AI 不需要理解 Git 的內部實作，只需要會組出正確的指令並解析輸出。例如：
- 使用者說「幫我看看現在改了什麼」→ AI 產出
git status、git diff，再根據 stdout 回報給使用者。 - 使用者說「幫我 commit 並 push」→ AI 產出
git add .、git commit -m "..."、git push。commit message 可以由 AI 根據 diff 生成。
這裡的 token 成本幾乎為 0：AI 不需要載入一大份「Git tool 的 schema」，只需要知道「要查狀態就呼叫 git status、要提交就呼叫 git commit」。契約就是指令字串與終端機輸出，簡單、穩定、到處都能跑。
4.2 Skill 當流程：把多步包成一個動作
實務上我們不會讓 AI 每次都「自由發揮」一連串 git 指令，而是把常見流程包成 skill。例如：
- skill: sync-branch
實際執行：git fetch→git checkout main→git pull→git checkout <feature-branch>→git merge main。AI 只需要在「要同步分支」時觸發這個 skill，並傳入 branch 名稱，不必自己決定每一步。 - skill: prepare-release
實際執行：git status/git diff→ （可選）請 AI 根據 diff 生成 commit message →git add→git commit→git push。AI 只負責「在 release 前觸發 prepare-release」，底層是腳本或固定流程。
這樣做有幾個好處：deterministic（同一個 skill 永遠跑同一套步驟）、符合既有 DevOps workflow（工程師本來就在用 git，AI 只是透過同一套介面操作）、易於權限與審核（human 可以規定「只有這些 skill 可以跑」或「push 前要經過審核」）。
4.3 對比：若用 MCP 做「版控」
若我們用 MCP 來讓 AI 做版控，通常會需要：定義「Git 相關 tools」的 schema（例如 read_status、commit、push），每個 tool 都要 description 與 parameters，全部灌進 context。工具一多，token 就爆；而且 LLM 可能選錯 tool（例如該用 commit 卻選成 merge）。反觀 Git CLI + 一個「prepare-release」skill：AI 只須知道「要準備 release 就呼叫 prepare-release」，skill 內部怎麼跑 git 由系統決定。開發成本低、行為可預期、token 省很多。
5. CLI 的三個優勢（小結）
從 Git 的例子可以收斂出 CLI 的三個優勢：
- Token 幾乎為 0
AI 只需要輸出指令（例如git commit -m "..."），而不是複雜的 JSON tool call。不需要把整份 tool schema 塞進 context。 - Deterministic
Skill 背後是固定流程（例如 scripts/deploy.sh 或一組 git 指令），AI 不需要「理解」底層基礎設施，只要在對的時機觸發對的 skill。 - 符合既有 DevOps workflow
開發者日常工作就是 git、docker、npm、kubectl……。AI 使用 CLI 幾乎可以無縫融入現有 workflow，不需要另建一層「AI 專用」的介面。
6. MCP 真正必要的情境
雖然 CLI + Skills 很強，但 MCP 不會因此消失。要說「什麼情境下一定要 MCP」：SaaS 整合、結構化輸出這兩類，用 CLI 也做得到（例如用 curl 或自包 script 打 API、用 jq 解析 JSON）。真正難以用 CLI 取代的，是下面兩類。
6.1 權限與安全控制
MCP 可以在 server 端 集中控制：哪些 tool 可被呼叫、誰能呼叫、rate limit、audit log。CLI 若直接交給 AI 執行，等於把主機上的執行權交給模型——能跑什麼指令、改哪些檔案、連哪些網路，都由 AI 當下的輸出決定，風險高、事後也難審計。在需要 細粒度權限、合規、審計 的環境（例如企業內、多租戶、付費 API），必須有一層「受控的執行層」：只開放白名單內的 tool、紀錄每次呼叫、必要時阻擋。這類情境 MCP 比 CLI 適合，因為執行發生在 server，權限與 log 都在同一端控管；CLI 多半假設「誰能登入主機誰就能跑」，難以做到同等級的控管。
6.2 即時／雙向通訊
CLI 的模型是「發出一條指令 → 等執行完 → 拿到一次 stdout/stderr」。若任務需要 streaming 結果（例如長時間 build 的即時 log、LLM 邊生成邊輸出）、或 server 主動推事件（例如任務完成通知、檔案變更觸發），CLI 的「一次執行、一次輸出」就不夠用。MCP 可以設計成雙向、長連線：server 可以持續推送訊息給 client，client 也可以在中途發送新指令或取消。這類 即時、雙向、長連線 的場景，本質上需要協議層支援，會需要 MCP 或類似的協議，而不是單純「AI 產出指令、執行、讀輸出」的 CLI 模式。
7. 未來可能的架構：CLI + Skills + MCP 三層
所以更合理的結論不是「MCP 被取代」，而是 三層分工：
- LLM reasoning layer：AI 負責思考、決策、何時觸發哪個 skill 或哪個 MCP tool。
- Skills / workflow layer（介面層）：可組合的流程，例如「prepare-release」「deploy-staging」。AI 只認得 skill 的名字，不必碰 MCP 的 schema。介面層在多數情境下由 Skill 擔綱——一個名字對應一個流程，底下就是 CLI 或腳本。
- 執行層：真正跑的是 script、CLI、binary。MCP 工具背後也是同一套：要有程式或腳本在執行。所以執行層沒有「CLI vs MCP」的對立，都是「有東西在跑」；差別在於要不要多一層 MCP 協議來觸發。只有在需要 server 端權限控管、審計，或 即時／雙向通訊（streaming、server 主動推送）時，才需要 MCP 那一層；其餘時候，Skill 叫 CLI／腳本就夠了。
AI 負責思考，Skill 負責介面（叫什麼、跑什麼流程），系統負責執行。CLI + Skills 負責「開發者日常最常見的那一塊」，MCP 只補「非用不可」的兩塊：權限與審計、即時雙向。
8. 一個更重要的問題：Tool Discovery
真正困難的往往不是「用哪種協議」，而是：AI 不知道有哪些工具、哪些 skill 可用。很多團隊最後都會限制「少量 tools、固定 workflow」，而不是讓 AI 自由探索所有工具。因此，與其糾結 MCP 要不要用，不如先把手上的 CLI 與 Skills 整理好：哪些指令可以交給 AI、哪些流程包成 skill、邊界與權限怎麼設。Tool discovery 與 governance 會是接下來更關鍵的課題。
結論
AI 開發工具鏈的下一步，很可能不是「MCP vs CLI」二選一，而是 CLI + Skills + MCP 並存：用 CLI 當通用、低門檻的執行介面，用 Skills 把流程包成可重複、可管控的動作；在需要 server 端權限與審計、或 即時／雙向通訊 時再動用 MCP。CLI + Skills 正在取代 MCP？ 更精準的說法是：在大多數「讓 AI 執行開發與維運任務」的場景裡，CLI + Skills 會成為主流；MCP 則會留在「非用不可」的情境——權限控管與即時雙向——與 CLI 互補而非互斥。
