本篇文章更新時間：2026/04/11
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
我為什麼仍偏好 MCP：一篇從使用者角度出發的深度解析
副標題：讀〈I Still Prefer MCP Over Skills〉後，談我對 Skills 與 MCP 的真正差異理解
編輯前言：這篇文章非常適合理解近期 AI 開發圈的爭論：LLM 的能力擴展到底該用「Skills」還是「MCP（Model Context Protocol）」？原文作者以重度使用者角度切入，觀點務實、犀利，也讓我重新思考 LLM 與服務整合的「正確姿勢」。
核心觀點（Key Takeaways）
- Skills 適用於「知識型」用途，但不適合真正的系統整合。
- MCP（Model Context Protocol）在架構、部署、維護與安全性上明顯更成熟、更實用。
- 服務整合應該建立「Connector」，而不是無止境增加 CLI 與 SKILL.md。
深入解析
原文提出一個我非常有感的觀察：近來大家瘋狂宣稱「MCP 已死」、「Skills 才是未來」，但實際使用後，作者——也是一位重度 AI 生產力使用者——明確說出：「我真的不喜歡 Skills。」這不是情緒，而是架構層面的思考差異。
「Skills 很適合傳授知識，但要讓 LLM 實際操作服務？MCP 才是更務實的選擇。」
下面我整理文章中最關鍵的洞察。
MCP 的真正價值：它是 API 抽象層，而不是使用說明書
作者強調 MCP 的哲學很簡單：LLM 不需要理解內部細節，只要知道有什麼工具可用。例如：
若要叫 DEVONthink 做事，只需呼叫 devonthink.do_x()，其餘交給 TCP/Server 處理。
這種分工帶來多個現代開發者應該重視的優勢：
- 零安裝、零摩擦：透過 remote MCP 直接連線，不需要在本地裝任何 CLI。
- 即時更新：MCP server 更新後，每個 client 都立即使用新版，沒有「重新安裝」、「升級 CLI」的痛苦。
- 更合理的授權流程：OAuth 手續跑完，你就能用。不需要把 token 散落在環境變數或明碼文件。
- 跨設備可攜：Mac、手機、網頁，只要有 MCP 客戶端就能用。
- 天然沙箱化：MCP 只暴露安全接口，而不是讓 LLM 直接跑本地指令。
這些優點基本上就是「我希望所有 AI 服務整合都能具備的特性」。
Skills 問題的核心：它假設每個人都有可執行 CLI 的環境
原文點出我一直覺得怪的地方：Skills 之所以不實用，是因為它經常要求你先安裝 CLI。
但：
ChatGPT 無法跑 CLI（除非你用 Code Interpreter）。
Claude、Perplexity 的網頁版也不能跑 CLI。
這代表 80% 的 Skills 在最常見的 LLM 使用場景中根本無法使用。
於是就出現一系列問題：
- CLI 部署與安裝碎片化，還要管理二進位或 npm 套件
- API 密鑰要放哪？.env？明碼？會不會每次 session 都消失？
- 每家工具對 Skills 的支援都不同，完全沒有標準
- 每次使用就得把整份 SKILL.md 貼進 context，十分浪費 token
這些痛點，我自己在用各家 LLM 時也感受得很明顯。
MCP vs Skills：作者給的清楚分工
我很喜歡原文的這段歸納，因為它將兩者的用途切得非常乾淨：
什麼時候該用 MCP？
- 需要讓 LLM 連接服務、網站、應用程式時
- 涉及 OAuth、狀態管理、API 呼叫、真正的動作執行時
- 任何需要跨平台、跨設備可用的整合
像是：
- Google Calendar 應該有官方 MCP，而不是要求 LLM 裝 gcal CLI。
- Chrome 應該直接暴露 MCP endpoint，而不是依賴奇怪的 chrome-cli。
- Hopper/Xcode/Notion 都適合走 MCP（而 Notion 真的已推出）。
什麼時候該用 Skills？
Skills 應該是純知識性或操作指導：
- 解釋如何用 git、curl、gcloud
- 提供團隊內部流程、溝通風格、術語指引
- 傳授 PDF 或資料處理技巧（如 Anthropic 的 PDF Skill）
- 充當某 MCP 的「使用手冊」
作者甚至說 Skills 應該叫：
LLM_MANUAL.md
我非常同意。
筆者心得與啟發
這篇文章對我最大的提醒是：
我們其實不需要讓 LLM「會操作 CLI」，我們需要的是乾淨、標準化的「連接器」。
MCP 提供的是「能力」，Skills 提供的是「知識」。
兩者不是替代關係，而是分工關係。
尤其是作者提到用 Claude 寫 Skill 來記錄 MCP 的習慣，我覺得非常值得學習：
在 MCP 上運作的細節、常見錯誤、日期格式、參數 gotcha，都可以抽出變成一個 Skill，讓未來的 session 不會重複踩雷。
這種模式其實就像在開發框架上建立補充文件——但是給 LLM 用的。
我相信未來的成熟 AI 生態一定會需要這樣的上下層分工：
- 底層：MCP（Connector）提供即時、跨端、可靠的動作能力
- 上層：Skills（Manual）提供知識、上下文、規則、最佳實務
當這兩者能搭配成熟，我們才真的能看到「AI 與服務無縫整合」的世界。
如果你正在思考要為服務打造 Skill 還是 MCP，這篇文章會是非常好的參考框架。