微軟製霸AI編程？GitHub被曝秘密開發Copilot專屬API，「殺死」Cursor和一眾Copilot開源替代
近日，GitHub 被曝一直在悄悄地向 VS Code 引入新的擴展 API，但是這些 API 只能由其 Copilot 使用。
發生了什麼？
VS Code 提供了一種發佈新 API 的機制，稱為「Proposed APIs」。這些 Proposed APIs 是一組尚未穩定的 API，它們在 VS Code 中已經實現，但不會像穩定 API 那樣公開給所有用戶。這些 API 可能會發生變動，目前僅在 Insider 版本中可用，並且不能在正式發佈的擴展中使用。
這是非常有意義的，因為 Proposed APIs 為社區提供了一種使用新 API、收集反饋以及快速迭代 API 的途徑，同時不會破壞現有的穩定擴展。
不過，開發者只能在開發模式下使用這些 API，不能將包含這些 API 的擴展發佈到商店。「儘管你不能使用市場上的 Proposed APIs 來發佈擴展，但你仍然可以通過打包和共享的方式與同行共享擴展。」VS Code 官網上 這樣寫道。
然而，近日網民「kannthu」對 GitHub Copilot Chat 擴展進行了反編譯，並查看了它的 package.json 文件，結果得到了以下內容：
「這是一個已發佈且已啟用 ApiProposals 的擴展。」kannthu 說道。
「怎麼可能呢？哦，對，他們是微軟……」kannthu 表示，「這看起來像是一種反競爭策略。VS Code 的擴展 API 非常有限，這就是為什麼像 Cursor 這樣的初創公司選擇分叉 VS Code 並直接應用更改的原因。GitHub 正在引入許多變化，這些變化也會使 Continue 等開源 Copilot 替代品受益，但他們只讓自己使用。」
VS Code 是微軟在 2015 年發佈的一個運行於 Mac OS X、Windows 和 Linux 之上的，針對編寫現代 Web 和雲應用的跨平台源代碼編輯器，可在桌面上運行，並且可用於 Windows，macOS 和 Linux。它有對 JavaScript，TypeScript 和 Node.js 的內置支持，並具有其他語言和運行時擴展的生態系統。
網民稱，這並不是 VSCode 第一次這樣做。
網民「rty32 」也在最近發帖稱，「我發現 VSCode 有一組用於添加 SSH 隧道的 API，正常情況下，你必須使用特殊的標誌啟動 VS Code 才能使用它們。但不知為何，他們的內置 JavaScript 調試擴展竟然也能暢通無阻地使用這些 API。」
「而且，你幾乎找不到關於這些 API 的任何公開信息。除非有人問起——截至兩年前，他們還沒有計劃‘最終確定’這些 API 並公開它們。建議你尋找其他解決方案。」「rty32 」說道。
前員工：微軟有區分私有和公共 API 的文化和技術
對於微軟的行為，網上也有兩種不同的聲音。
網民 geoffreyhuntley 表示，「正如 Geoffrey Huntley 所說，一旦 VS Code 編譯成 MIT 許可的其他版本時，生態系統就會以一種糟糕的方式分裂（商標），包括無法運行大多數微軟的擴展（如語言 LSP、Copilot、遠程開發）。如果你是生產 MIT 分支的供應商，那麼你需要更新圖表並說服第三方擴展作者不要將微軟的擴展作為依賴項，而是在 open-vsx.org 上發佈。」
「這就是 Cursor 在中長期內受到破壞的原因。編碼代理？很酷，但你不能將它與 Pylance 一起使用。VS Code 被降班為 notepad.exe。微軟利用 Cursor 進行產品研究，然後將學習成果推廣到 Copilot，因為只有 Copilot 支持用戶期望的所有 VS Code 功能（這是有意為之的設計）。」geoffreyhuntley 說道。
Cursor 是 VS Code 的分支。Cursor 代碼編輯器一半是開發環境，一半是 AI 聊天機器人，將人工智能整合到了開發人員工作流程中的功能，目前備受開發者好評。這裏的背景是，OpenAI 是 Cursor 的主要投資者，而是 OpenAI 的主要投資者。所以，有網民認為「微軟也控制著（儘管不是完全控制）Cursor 的開發。」
此外，也有網民表示，「每個人都將此解讀為故意的反競爭行為。雖然這可能是真的，但另一個合理的解釋難道不是 Copilot 開發團隊正在儘可能快地行動、而變通辦法則是以團隊名義強行推行的嗎？推廣公共 API 需要花費更多的時間和精力，而且它可能與開發 Copilot 擴展的團隊完全不同。」
還有網民指出，其目的可能不是為了競爭，但「給予一個客戶其他客戶無法享受的特殊待遇仍然會具有反競爭性。」「大多數公司都有內部 API，這些 API 通常不可用。」
然後，有自稱曾在微軟工作的開發者 Arainach 明確表示，「微軟擁有區分私有和公共 API 的文化和技術，並在整個公司內檢查代碼以確保只調用公共 API。這是司法部同意並要求的數十年規定，公司的每一款產品都配有掃瞄工具，以檢查它們是否使用了任何私有 API（或類似的黑客手段來訪問它們，例如私下搜索 Windows DLL 文件中的符號）。這一點已經深入每個人的心中，包括我認為的目前公司 90% 的高級副總裁及以上人員，而且這已經持續了很長時間。他們這樣做是有意識的反競爭決策。」
當然，也有網民覺得這並不是什麼事，「這並沒有什麼奇怪的，也不是那麼糟糕。他們投入了時間、精力和金錢來開發 VS Code。它是開源的，所以如果你想使用這些 API，你可以在一個分叉版本中使用它們。當然，如果你正在開發一些每個人都能免費使用的東西，而且不強迫人使用它，我認為使用私有 API 沒有什麼問題。雖然有些人將其與 IE 瀏覽器類比，但兩者並不相同，因為它並非預裝在每台機器上，也不會強迫你使用它。因此，儘管它們確實擁有很大的市場份額，但它們也阻止不了你自行分叉或使用不同的編輯器。」
實際上早在 2022 年，就有網民注意到，微軟在 90 年代的反壟斷調查中被指控，「Windows 系統包含了一些實用的 API，但微軟對對此保密，僅供自己的應用程序使用，從而為它們在與競爭對手的競爭中提供了不公平的優勢。因此，這可能意味著 Microsoft Word 比 WordPerfect 更出色，因為 Word 能夠調用一些 WordPerfect 開發人員所不瞭解的、未公開記錄的 Windows API 函數。」
對此，網民「davidbak」表示，「微軟文檔中的「Windows 協議規範」部分起源於最初的歐盟訴訟。如果你查看保存這些規範的地點，就會發現微軟最初發佈的一組「秘密」API。我清楚地記得其中包含了一份詳盡的 NT 本地 API 文檔，這些 API 實際上是‘妥協’的產物。它們大多是內部團隊使用的 API，例如 SQL Server 以及一些桌面應用程序，但 NT 團隊並未將其公開，因為它們「不適宜」——這些 API 用於特殊情況，或難以正確使用，或者不能完成整個工作流程。各個項目團隊通過各種方式（有時甚至是副總裁施壓）說服 NT 團隊提供這些 API 以完成他們的工作，但 NT 團隊認為它們不適合公開使用和長期支持。當你查看這些列表時，原本以為會看到微軟的絕密優勢，但實際上卻會感到失望和困惑。」
也有網民指出，「不支持客戶使用」並不意味著某種邪惡的秘密陰謀。「在我目前開發的軟件中，有幾十個這樣的情況；它們沒有記錄下來，因為我把它們視為實現細節，而不是保證接口。」
參考鏈接：
https://retrocomputing.stackexchange.com/questions/25955/did-microsoft-really-reserve-secret-apis-in-windows?newreg=392a25a5992b43b2910e44e339cfb623
https://old.reddit.com/r/ChatGPTCoding/comments/1g8xrub/microsoft_is_introducing_hidden_apis_to_vs_code/
https://news.ycombinator.com/item?id=41907350
本文來自微信公眾號「AI前線」，作者： 褚杏娟，36氪經授權發佈。
