MCP 已死？Skill 和 CLI 取代不了的三個場景
2026 年 2 月底，一篇「MCP is dead. Long live the CLI」登上 Hacker News 首頁，瞬間炸開鍋。一邊說 MCP 是多餘的抽象層，一邊說所有大廠都已押注。如果你也在 Claude Code 或 Cursor 裡糾結「到底要不要裝 MCP server」，這篇文章用實測數據幫你在 30 秒內做出判斷。
TL;DR
- MCP 沒死，但它解決的是「多用戶、跨平台工具分發」的問題，不是你個人寫 code 的問題
- CLI 在 token 效率上贏 MCP 10-32 倍，成功率接近 100%
- Skill 是流程知識（教 AI 怎麼做），MCP 是工具能力（讓 AI 能做什麼），兩者互補不互斥
- 個人開發者：CLI + Skill 先行，需要接 Notion/Figma 等無 CLI 服務時再用現成 MCP server
- MCP 的安全風險不容忽視：CoSAI 白皮書列出 40+ 種威脅類別，24% 的公開 server 零認證
「MCP 已死」論戰始末
MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月推出的開源協議，讓 AI 系統透過統一介面連接外部工具和數據源。業界常用的比喻是「AI 的 USB-C」，寫一次 MCP server，所有支援的 AI client 都能接。
2025 年是 MCP 的爆發年。OpenAI 3 月宣布支援、Google DeepMind 4 月跟進、Microsoft 在 Build 大會上整合進 Windows 生態系。到了 12 月，Anthropic 更直接把 MCP 捐贈給 Linux Foundation 的 Agentic AI Foundation，OpenAI、Google、Microsoft、AWS、Cloudflare 全數加入成為創始成員。
然後，反轉來了。
2026 年 2 月，Eric Holmes 丟出那篇文章，核心論點簡單粗暴：LLM 已經夠聰明了，給它 CLI 工具加文件就能完成任務，何必多一層 MCP 的抽象？Pieter Levels（levelsio）也在 X 上附和：「MCP 跟 llms.txt 一樣，都是 AI 根本不需要的多餘抽象。」
但這場論戰的答案不是非黑即白。MCP 不是死了，是從 hype peak 掉進了 Gartner 幻滅谷（trough of disillusionment）。真正的問題不是「MCP 好不好」，而是「什麼時候該用 MCP」。
三層架構拆解：MCP vs Skill vs CLI 到底差在哪
很多人把 MCP、Skill、CLI 混為一談，覺得「都是讓 AI 用工具的方式」。但它們其實在架構中處於完全不同的層級，理解這一點是做出正確選擇的前提。
能力層：MCP
MCP 解決的是「AI 能做什麼」。它是一個標準協議，讓 AI 透過統一介面連接資料庫、API、雲端服務。與傳統 API 的關鍵差異在於：AI 可以在執行期間動態發現可用工具，而不是在 prompt 裡硬寫每個工具的用法。
流程層：Skill
Skill 解決的是「AI 該怎麼做」。它本質上是 markdown 格式的工作流程指令，定義了做事的順序、品質標準、判斷邏輯。根據實際使用經驗，我用 Skill 定義了一整套內容產出 pipeline（從選題到翻譯），AI 只要讀取 Skill 就知道每一步該做什麼、產出什麼格式。
執行層：CLI
CLI 是最直接的方式，AI 透過 Bash 直接呼叫你電腦上已有的命令列工具。git、curl、npm、gh，這些工具你本來就在用，AI 也能直接用。
一張表看清差異
| 維度 | MCP | Skill | CLI |
|---|---|---|---|
| 本質 | 工具連接協議 | 流程指令（prompt） | 命令列工具 |
| 解決什麼 | AI 能做什麼 | AI 該怎麼做 | AI 直接執行 |
| 載體 | Server process | Markdown 檔案 | 既有系統工具 |
| 跨平台 | 所有 MCP client | Claude Code 為主 | 任何有 shell 的環境 |
| 維護成本 | 高（server 運維） | 極低（純文字） | 幾乎為零 |
| 最佳比喻 | USB-C 插頭標準 | SOP 手冊 | 你口袋裡的瑞士刀 |
關鍵洞察：這三者不是互斥的。最聰明的做法是三層並用，Skill 定義流程、CLI 執行大部分任務、MCP 只在需要跨平台分發或企業治理時才啟用。
Benchmark 實測：CLI 到底贏多少
數據比觀點有說服力。我自己的 content pipeline 每天跑數十次 CLI 呼叫（git、curl、file system 操作），從來沒碰過 MCP 那種 Schema 膨脹或連線逾時的問題。但光講體感不夠，來看硬數據。根據 Scalekit 的 75 次 benchmark 測試，CLI 在效率指標上全面碾壓 MCP：
| 指標 | CLI | MCP（直連） | 差距 |
|---|---|---|---|
| Token 消耗（GitHub 查詢） | 1,365 | 44,026 | 32 倍 |
| 月成本（1 萬次操作） | $3.20 | $55.20 | 17 倍 |
| 成功率 | 100% | 72% | CLI 勝 |
為什麼差這麼多？問題出在「Schema 膨脹」。每次 AI 呼叫 MCP server，server 都會把所有工具的定義塞進 context window。以 GitHub MCP server 為例，它有 43 個工具，光是 Schema 就佔掉大量 token，不管你實際只想用其中 1 個。
不過，這不代表 MCP 在所有場景都不堪用。如果在 MCP 前面部署 API Gateway 做 Schema 過濾和連線池管理，成本可以降到約 $5/月，可靠度提升到 99% 以上。只是這又增加了架構複雜度，對個人開發者來說很可能不值得。
30 秒決策框架
不想看完整篇文章？用這個決策樹：
你的 AI 需要代表多個不同用戶操作嗎？（OAuth 授權、租戶隔離、稽核需求）
- 是 → 用 MCP。這是 MCP 真正無可取代的場景。
你只是要自動化自己的工作流程？
- 是 → CLI + Skill。你的 agent 繼承本機權限就夠了。
你要接的服務有 CLI 嗎？
你只是要教 AI 一套做事方式？
- 是 → 用 Skill（或你平台對應的 prompt 設定檔）
三種典型場景
場景 A：個人開發者用 Claude Code 寫 side project → CLI + Skill。Bash 能做的事不需要 MCP，Skill 定義 code review 標準和 commit 規範。成本最低、最可靠。
場景 B：SaaS 產品讓用戶透過 AI 管理自己的 Stripe 帳戶 → MCP 必要。每個用戶有自己的 OAuth token，需要租戶隔離和存取權限控制。這是 CLI 做不到的。
場景 C：團隊想讓 Cursor 和 Claude Code 都能查內部 wiki → MCP 合理。寫一次 MCP server，兩個 client 都能接，避免重複整合。
安全風險揭露：用 MCP 前你必須知道的事
MCP 的便利性帶來了真實的安全風險，這不是理論假設。
Coalition for Secure AI（CoSAI）在 2026 年的白皮書中列出了超過 40 種 MCP 專屬的威脅類別。根據 Zuplo 的 MCP 調查報告，目前 24% 的公開 MCP server 完全沒有認證機制。
已發生的真實攻擊
- Prompt Injection 劫持：攻擊者在公開 GitHub Issue 中埋入惡意指令，AI agent 讀取後被劫持，將企業私有儲存庫的資料外洩
- 供應鏈攻擊：npm 上出現假的 Postmark MCP server，表面功能正常，實際上將所有電子郵件密件抄送給攻擊者
- SQL 注入：Supabase MCP 被利用支援工單中的 SQL 注入，外洩高權限整合權杖
想深入了解 AI Agent 的安全防禦框架，可以參考這篇完整指南。
使用 MCP 前的防禦清單
- 最小權限原則：只授予 MCP server 完成任務所需的最小存取範圍
- 獨立輸入驗證：不要盲目信任 LLM 的工具呼叫決策，在敏感操作前加入獨立驗證層
- 來源查驗：安裝 MCP server 前確認來源可信，避免使用來路不明的第三方 server
結論
MCP 沒死，但它的真正價值在「分發」和「治理」，不在「效率」。
如果你是個人開發者或數位工作者，最務實的策略是：CLI + Skill 為主，MCP 按需取用。先用 CLI 處理有命令列工具的任務，用 Skill 定義工作流程，只有在需要跨平台分發或接無 CLI 的雲端服務時，才動用 MCP。
這不是三選一的問題，是三層架構各司其職。搞清楚每層解決什麼問題，你就不會被「MCP 已死」或「MCP 必學」的極端聲音帶著跑。
想動手試試 Skill 怎麼用？我們有一篇 Claude Code Skills 完整指南，從零開始帶你建立自己的工作流程。
FAQ
MCP 都被大廠支持了，怎麼還有人說它死了？
因為「死了」指的不是採用率，而是效率。MCP 在個人開發場景下的 token 消耗是 CLI 的 4-32 倍，失敗率也更高。大廠押注 MCP 是看中它在企業治理、多租戶授權、跨平台分發上的價值，這跟個人開發者的日常使用是完全不同的場景。所以「MCP 已死」反映的是開發者對過度 hype 的反彈，不是協議本身的消亡。
我是個人開發者，現在到底要不要花時間學 MCP？
短期內不需要投入大量時間建置自己的 MCP server。CLI 搭配 Skill 的成功率接近 100%，token 效率是 MCP 的 10-35 倍，而且免除 OAuth 認證與 server 維運負擔。唯一的例外是當你需要串接 Notion、Figma 這類完全沒有 CLI 的雲端服務時，直接取用社群已有的 MCP server 是合理做法。
Skill 只能在 Claude Code 用，那其他平台怎麼辦？
沒錯，Skill 目前綁定 Claude Code 生態系（Gemini CLI 有部分相容性）。如果你需要讓工具能力跨平台使用（Cursor、ChatGPT、Windsurf 都能接），MCP 是正確選擇。但如果只是要定義工作流程和規範，多數平台都有類似機制：Cursor 有 .cursorrules、GitHub Copilot 有 .github/copilot-instructions.md，概念相同，只是格式不同。
