簡而言之：AI 領域正大力推動「Skills」作為賦予大型語言模型（LLM）能力的標準，但我並不喜歡。Skills 對於純粹的知識傳遞以及教導 LLM 如何使用現有工具非常有用。但對於賦予 LLM 實際的服務存取權限，模型上下文協議（Model Context Protocol，MCP）是遠為優越且更務實的架構選擇。我們應該建立連接器，而不僅僅是更多的命令列介面（CLI）。
也許是花太多時間在 X（Twitter）上的緣故，最近「MCP 已死」和「Skills 是新標準」的論調不斷在我腦中迴盪。我所見之處，都有人在慶祝模型上下文協議的消亡，轉而將 SKILL.md 放入他們的儲存庫。
我是一個非常重度的 AI 使用者。我使用 Claude Code、Codex 和 Gemini 進行程式設計。我幾乎每天都依賴 ChatGPT、Claude 和 Perplexity 來管理從 Notion 筆記到 DEVONthink 資料庫，甚至我的電子郵件。
說實話？我就是不喜歡 Skills。
我希望 MCP 能繼續存在。我真的不希望未來每一個服務整合都需要一個專用的 CLI 和一個 Markdown 手冊。
以下是我認為將 Skills 推廣為通用解決方案是倒退的原因，以及為什麼 MCP 仍然在架構上是正確的。
Claude 透過 Kikuyo MCP 從 Kikuyo 提取最新的使用者回饋，無需 CLI。
MCP 的核心理念很簡單：它是一個 API 抽象層。LLM 不需要理解「如何」操作；它只需要知道「做什麼」。如果 LLM 想要與 DEVONthink 互動，它會呼叫 devonthink.do_x()，而 MCP 伺服器會處理其餘部分。
這種關注點分離帶來了一些無可匹敵的優勢：
並非所有 Skills 都相同。純知識型 Skills（教導 LLM 如何格式化提交訊息、以特定方式編寫測試，或使用內部術語）實際上運作良好。問題出現在當 Skill 需要 CLI 來實際執行某項操作時。
我對 Skills 最大的抱怨是它假設每個環境都能，或應該，執行任意的 CLI。
大多數 Skills 要求你安裝一個專用的 CLI。但如果你不在本地終端機環境中呢？ChatGPT 無法執行 CLI。Perplexity 或標準網頁版的 Claude 也不能。除非你使用的是功能齊全的計算環境（例如 Perplexity Computer、Claude Cowork、Claude Code 或 Codex），否則任何依賴 CLI 的 Skill 都會胎死腹中。
這會導致一系列惱人的使用者體驗和架構問題：
如果一個 Skill 的說明開頭是「先安裝這個 CLI」，你就已經增加了一個不必要的抽象層和額外的步驟。為什麼不直接使用遠端 MCP 呢？
Codex 載入一個純知識型 Skill 來學習 Phoenix 協同定位掛鉤（colocated hooks）的工作原理。沒有 CLI，沒有 MCP，只有上下文。
我不希望 Skills 成為將 LLM 連接到服務的預設方式。我們可以在 Skill 中解釋 API 的形狀，讓 LLM 可以透過 curl 來呼叫，但這比透過 MCP 提供一個乾淨、強型別的介面要好嗎？
以下是我認為生態系統應該如何發展：
何時使用 MCP：MCP 應該是賦予 LLM 連接某個東西（網站、服務、應用程式）介面的標準。服務本身應該決定它暴露的介面。
何時使用 Skills：Skills 應該是「純粹的」。它們應該專注於知識和上下文。
Skills 直接放在儲存庫中。LLM 在處理該專案時會自動拾取它們。
一個想法：也許術語是問題所在。Skills 應該只稱為 LLM_MANUAL.md，而 MCP 應該稱為 Connectors。
對於我擁有的服務，我已經這樣做了。以下是一些例子：
對於 microfn 和 Kikuyo，我也發布了 Skills，但它們涵蓋了 CLI，而不是 MCP。不過，寫這篇文章讓我意識到：一個解釋如何使用 MCP 伺服器的 Skill 實際上是有意義的。不是用來取代 MCP，而是讓 LLM 在開始呼叫工具之前獲得上下文。服務的作用是什麼，工具之間如何關聯，何時使用哪個工具。一個連接器層之上的知識層。這就是我想要的組合。
這實際上是我在實踐中越來越多使用的模式。當我與 MCP 伺服器互動時，我不可避免地會發現一些陷阱和不明顯的模式：一個日期格式需要是 YYYY-MM-DD 而不是 YYYYMMDD，一個搜尋功能除非你調整一個參數否則會截斷結果，一個工具名稱的行為不如預期。與其每次都重新發現這些，我乾脆請 Claude 將我們學到的所有東西包裝成一個 Skill。LLM 已經從我們的對話中獲得了上下文，所以它編寫的 Skill 包含了所有的陷阱、常見模式和修正後的假設。
在發現 NotePlan MCP 中的反向連結陷阱和日期格式怪癖後，我請 Claude 將所有內容打包成一個 Skill。現在，每一次未來的對話都從這些知識開始。
結果是一個充當 MCP 的備忘單的 Skill，而不是它的替代品。MCP 仍然負責實際的連接和工具執行。Skill 只是確保 LLM 不會浪費 token 在我已經解決的同樣的陷阱中摸索。兩者的結合才讓體驗真正順暢。
同時，我會繼續維護我的 dotfiles 儲存庫，裡面充滿了我經常使用的程序的 Skills，並且我會繼續將 .claude/skills 放入我的儲存庫中來指導 AI 的行為。
我只希望業界不要放棄模型上下文協議。無縫 AI 集成的夢想依賴於標準化的介面，而不是一個破碎的、粗糙的 CLI 生態系統。我仍然對官方的 Skyscanner、Booking.com、Trip.com 和 Agoda.com MCP 抱有希望。
說到遠端 MCP：我專門為這個問題構建了 MCP Nest。許多有用的 MCP 伺服器本質上是本地的，例如 Fastmail、Gmail 或任何在你機器上運行的服務。MCP Nest 將它們透過雲端進行隧道傳輸，使它們可以遠端存取，從 Claude、ChatGPT、Perplexity 或任何支援 MCP 的客戶端，跨越你的所有設備使用。如果你希望你的本地 MCP 在任何地方都能工作，而無需直接暴露你的機器，這就是它的用途。