想像一下,建立一個可以在任何地方運作的 API 伺服器,就像 LSP 為程式設計師所做的那樣,MCP 會是下一個嗎?
在 2016 年之前,在 IDE 中支援程式語言非常麻煩。
每個編輯器都必須為其想要支援的每種語言建立自己的一套工具。
語法高亮、自動完成、程式碼檢查,它們都是客製化的。
這導致了體驗的碎片化。
像 JavaScript 這樣的語言在一個編輯器中可能感覺很順暢,但在另一個編輯器中則不完整。
如果你使用像 VIM 這樣的基於終端的編輯器,
你通常會發現工具非常有限,或者根本沒有。
當 @Microsoft 引入 Language Server Protocol (LSP) 時,這種情況發生了改變。
LSP 建立了一種標準的溝通方式,而不是讓編輯器和語言從頭開始建立整合。
現在,語言可以提供單一的 LSP 伺服器,
任何具有 LSP 客戶端的編輯器都可以連接。
因此,你只需要建立一個 Go LSP 伺服器,它就可以在任何地方運作,而不必建立一個「VSCode 的 Go 外掛程式」和一個「Sublime 的 Go 外掛程式」。對於開發人員來說,這意味著在不同的編輯器中,功能更加一致。
對於語言維護者來說,這簡化了支援新工具的工作。
對於編輯器來說,這在一夜之間解鎖了長長的一串語言列表。
今天,LSP 使語法高亮和自動完成等工具感覺無縫,
無論你使用哪種語言,或你喜歡哪個編輯器。
這是一個簡單的視覺圖,顯示了 pre-LSP 和 post-LSP 設定之間的差異:
今天,LSP 已經悄悄地改變了開發工具的工作方式。
即使是小眾的程式語言,現在也可以在流行的編輯器中提供出色的開發人員體驗。
它們不需要與像 VSCode 或 Cursor 這樣的 IDE 達成直接協議,
它們只需要建立一個 LSP 伺服器,就可以加入了。
在開發人員方面,這種轉變也很重要。
我們不再根據語言支援來選擇 IDE。
我們根據編輯器的優勢來選擇,
例如 Cursor 的介面或其 AI 功能。
也就是說,LSP 的採用並非普遍。
像 JetBrains 或 Apple 的 Xcode 這樣的一些生態系統仍然偏愛它們自己的協議。
但對於大多數人來說,LSP 正在成為編輯器和語言工具連接的標準方式。
現在,在 2025 年,MCP 正在進入對話。
對我們來說,它感覺非常熟悉。
如果 LSP 的結構有助於激發它,這並不奇怪。
以下是比較:
將「程式語言」替換為像 Stripe 或 Supabase 這樣的第三方 API,
並將「IDE」替換為 AI 聊天客戶端,@Cursor、Claude、@OpenAI、@vercel 或 @LangChainAI。
這就是 MCP 的樣子。
如果 MCP 取得成功,其影響可能是巨大的。
Supabase 不需要為每個 AI 客戶端進行單獨的整合。
它只需要建立一個 @supabase MCP 伺服器,
任何與 MCP 相容的客戶端都可以連接。
這也可能成為小型團隊的遊戲規則改變者。
他們可以在任何 AI 平台上向使用者提供全功能的工具,
而無需維護五種不同的整合。
它甚至可能使整合市場變得過時。
如果體驗在各個平台上都是原生的,
為什麼還需要手動瀏覽和安裝外掛程式?
最終使用者將受益最多。
無論他們使用哪種 AI 工具,他們都會獲得一致的體驗。
我們認為 MCP 具有真正的潛力。
在 @AnthropicAI 與 @State_Of_Mika 的共同領導下。
它可能成為將第三方 API 與 LLM 連接的新標準。
如果你好奇 LSP 如何解決類似的挑戰,
留言 gMika,我們將向你發送指南。