摘要：该条款规定：“C/C++ 扩展仅可与 Microsoft Visual Studio、Visual Studio for Mac、Visual Studio Code、Azure DevOps、Team Foundation Server 以及微软后续推出的产

该条款规定：“C/C++ 扩展仅可与 Microsoft Visual Studio、Visual Studio for Mac、Visual Studio Code、Azure DevOps、Team Foundation Server 以及微软后续推出的产品和服务一起使用，以开发和测试您的应用程序。”这些限制让开发者更倾向于使用微软的官方发行版，而非其他版本。

随后，就有开发者抱怨道，微软有一些闭源扩展程序（远程访问、Pylance、C/C++、C#），这些扩展程序的最新版本已无法在 Cursor 或其他非微软编辑器中使用。其中，Cursor 1.17.62 版本可以正常使用，但 1.18.21 及更高版本无法正常工作。

另外，还有开发者称 C# Dev Kit 也遇到了一样的限制。

尝试使用 Microsoft 的 Dev Kit 扩展时 Cursor 报告的错误

对此，Cursor 社区中的开发者 Alexander Schroeder 表示，“我们已经发布了一个即时修复程序，并将很快发布一个长期解决方案。”

另外，也有开发者表示，最新版本的扩展程序阻止了它的工作，但其通过降级并禁用自动更新的方式解决了。“在扩展程序页面，‘卸载’旁边的下拉菜单中有一个“安装特定版本”。安装版本 1.23.6”。

微软发布的 Visual Studio Code 彻底改变了开发者使用 IDE 的方式，开发者可以用一个统一的工具来编写几乎所有语言和技术栈的代码。

微软不仅提供了 Visual Studio Code，还开发了许多扩展插件，比如 Python 调试器、C/C++ 语言服务、Jupyter、Pylance、Python 语言服务、Azure 工具、Data Wrangler、Jupyter 快捷键映射，甚至还有 JavaScript 和 TypeScript 的语言服务。这些还只是微软所开发的众多扩展中的一部分而已。此外，微软还拥有 GitHub 和 npm，几乎可以说是掌控了整个软件开发工具生态。

这本来挺不错的，然而，微软某些团队最近情况有点不太妙——四位麻省理工学院（MIT）的本科生利用 VSCode 的开源模式，将其分叉（fork）并打造了一个竞争产品 Cursor。当 VSCode 询问是否希望将 AI 建议合并进你正在开发的代码时，Cursor 却是反过来，询问 AI 是否希望让人类插手。

Cursor 本身并不是开源的，这一做法虽然存在争议，但在 VSCode 所采用的 MIT 许可证下是被允许的，所以我们无法查看其内部实现，也不知道它具体做了什么。

不过，Cursor 在去年年中融资了大约 6000 万美元，而在差不多的时间，他们已经拥有约 4 万名用户。Cursor 提供了一个带有限制的免费政策，还有每月 20 美元和 40 美元（按用户计费）的付费计划。

微软的 C/C++ 语言服务扩展突然停止支持 Cursor，让所有人都大吃一惊。然而，这也不是新鲜事。有网友表示，微软自己的语言扩展一直声明不能在 Visual Studio Code 之外使用它（并且 Code fork 不算数），这绝对不是一个新问题，只是他们现在决定强制执行对 C++ 扩展的限制。2018 年时，微软明确表示不允许在 Code forks 上使用 C# 扩展。

微软 vscode-cpp 工具 192 行长的许可证文件显示，它 禁止在 VSCode 和微软工具以外的环境中使用。

前端工程师 Tom Smykowski 发现，新的限制规则是在 4 月 1 日被添加进去的，还附有某位评论者的一句评论：

这个短语不仅仅是对这次变更的嘲讽，实际上它来源于微软本身：

这个策略曾在上世纪微软多次反垄断案件中被提及，如今再次被人提起，可见这一举动在开发者社区中引起了不小的反感。

具体来看，这个策略的三个阶段如下：

拥抱（Embrace） ：开发与开放标准高度兼容的软件。

扩展（Extend） ：添加开放标准未支持的新功能，从而制造互操作性问题。

消灭（Extinguish） ：当这些扩展因市场份额优势而成为事实标准后，边缘化那些无法支持这些扩展的竞争对手。

当然，微软从未公开承认这就是他们的战略。毕竟 VSCode 是在 MIT 许可证下开源的，.NET 也同样是开源的，所以并不太像微软还会执行“EEE 战略”。

不过，在这次事件中，微软确实 利用了一个存在多年的许可证条款，并在此基础上对扩展加上了限制性封锁 。过去没这么做，大概是因为没人把 VSCode 拿去 fork 并试图做成竞品。

那么，到底有多少扩展受到这种限制的影响？

Smykowski 调查后表示，还 没有发现其他扩展也存在类似封锁行为 。不过 Smykowski 还没检查完全部内容。全网搜索“extension may be used only with”这样的短语，在微软开源代码库里也没找到更多类似描述。

然而问题是，微软 可以随时添加这样的限制 。事实上，只要你使用的扩展中包含以下这段话：

那它理论上就可能在未来被微软加上访问限制。

显然，这项限制是 强制规定扩展只能与微软指定的工具一起使用，不能用于任何 fork（衍生版本） 。

Smykowski 在查找“only with Microsoft”这种措辞时，并没有找到有力证据表明其他语言服务扩展的许可证中也包含类似的限制条款。

所以 Smykowski 的结论是， 目前其他语言服务扩展中并没有类似的封锁行为 ，而且并非所有扩展都使用了这种带有限制的许可证。

Smykowski 建议，当开发者决定在 VSCode 的 fork 上使用某个扩展之前， 必须先检查它的许可证， 或者选择使用其他真正开源、许可证开放的扩展。“其实，微软的 VSCode 扩展商店并不是唯一的来源 —— 比如你可以从 Open VSX 获取扩展，它由 Eclipse 基金会托管。”

“锁定效应”促使了 Open VSX 市场的诞生，其初衷是防止官方 VS Code 专属市场“严重限制那些采用开源开发工具的组织的能力”。

尽管如此，Open VSX 市场中的扩展数量和使用率仍远低于微软的官方市场。不过，Cursor 仍然在其 IDE 中提供对 VS Code 市场扩展的访问，包括微软的 C/C++ 扩展和 C# DevKit，同时还提供一个设置选项，可以从已安装的 VS Code 中导入扩展。

看起来微软现在正在更严格地执行其使用条款。DevClass 尝试在 Cursor 中安装微软的 C/C++ 扩展，虽然安装成功，但在使用如“查找所有引用”等功能时却无法正常工作，最终弹出提示窗口，提醒用户该扩展存在使用限制。

这种情况令人困惑，因为 Cursor 仍会在识别到合适的项目时，推荐开发者安装微软的 C++ 扩展。开发者可能会考虑使用替代方案，例如 clangd 扩展，尽管它的安装量仅为 170 万次，而微软的扩展安装量已达 8100 万次。

不过问题在于：虽然微软免费提供了扩展和 VSCode，但这并不代表开发者可以随意使用它们做任何事情。他们完全可以随时更改许可协议，限制你的使用方式，甚至要求为使用付费。“这就意味着，未来充满不确定性，而 当一家公司拥有某个工具或平台的控制权时，它也就控制了规则 。”Smykowski 评价道。

对于微软的这一变化，有开发者猜测可能是由于 VS Code 稳定版中引入了“Agent Mode”这一 AI 功能，使 Cursor 成为了 VS Code 更直接的竞争对手。

VS Code Stable 在 3 月的版本中推出了代理模式（Agent mode），该模式现已全面支持 MCP。

与传统的聊天或多文件编辑功能不同，代理模式的核心在于：它不仅仅回答问题，而是 具备将开发者的想法转化为代码的实际操作能力 ：自动识别或生成所需文件，完成所有必要的子任务，确保实现开发者的主要目标；建议终端命令或工具调用，并请求开发者执行；具备运行时错误分析和自我修复能力等。

代理模式由 Claude 3.5 和 3.7 Sonnet、Google Gemini 2.0 Flash 以及 OpenAI GPT-4o 提供支持。目前，代理模式在基于 Claude 3.7 Sonnet 的 SWE-bench Verified 测试中的通过率为 56.0%。

微软一直强调，尽管 Code-OSS 的代码是基于 MIT 许可协议的开源项目，但 VS Code 是微软基于 Code-OSS 仓库定制的发行版本，并采用了传统的微软产品许可协议发布。

有评论指出，在合规性方面，Cursor 可能并未直接链接至 VS Code 扩展市场，而是通过其自有服务发布已上线扩展的链接。目前出现的问题似乎仅限于微软官方的扩展，而非第三方扩展。

来源：商财洞察君