微软制霸 AI 编程？GitHub被曝秘密开发Copilot专属 API，“杀死”Cursor和一众Copilot开源替代！

整理 | 褚杏娟

近日，GitHub 被曝一直在悄悄地向 VS Code 引入新的扩展 API，但是这些 API 只能由其 Copilot 使用。

1 发生了什么？

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 ”说道。

2 前员工：微软有区分私有和公共 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