總市值:$00
API
TC
暗色

搜尋SSI/Mag7/Meme/ETF/幣種/指數/圖表/研報
00:00 / 00:00
查看
    市場
    指數
    資訊
    TokenBar®
    分析
    宏觀
    觀察列表
分享
ChasmNetwork
由AI翻譯

想像一下,建立一個可以在任何地方運作的 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,我們將向你發送指南。

10s 洞悉市場
協定隱私政策白皮書官方驗證Cookie部落格
sha512-gmb+mMXJiXiv+eWvJ2SAkPYdcx2jn05V/UFSemmQN07Xzi5pn0QhnS09TkRj2IZm/UnUmYV4tRTVwvHiHwY2BQ==
sha512-kYWj302xPe4RCV/dCeCy7bQu1jhBWhkeFeDJid4V8+5qSzhayXq80dsq8c+0s7YFQKiUUIWvHNzduvFJAPANWA==