微软重磅开源 Copilot！64 岁 VS Code 创始人亲口承认：眼红 Cursor，但真正价值在后端，它“抄”不过去！

整理 | Tina、褚杏娟

在昨晚的 Build 2025 开发者大会上，微软正式开源了 GitHub Copilot Extension for VS Code 项目，并采用 MIT 许可证。全球开发者将可免费访问其完整源码，并参与功能优化。

根据微软 VSCode 团队的声明，微软计划先开源 GitHub Copilot Chat 扩展的代码库，随后会将该扩展的相关组件重构整合至 VS Code 核心代码中。微软为此制定了一个为期 4 周的迭代计划，新的 VSCode 将于 6 月初发布。

GitHub Copilot 自 2021 年起就作为 VS Code 的插件存在，后者是其最早、最主要的运行平台之一。对于今天的开源公告，Eric 强调，Copilot 的服务端不会开源。 但 VS Code 的所有客户端逻辑，包括模型返回的 diff 渲染、inline chat、Agent UI 等都是开源的。

在官方宣布开源的同时，VS Code 创建者 Erich Gamma 和 Copilot 负责人 Kai Maetzel 接受了 Syntax 的独家专访。

两人都是 VS Code 项目的早期成员，多年来一直在推动这个项目的发展。其中，Eric 在 15 年前加入微软时启动了 VS Code 项目并长期领导该项目，最近几年开始退居一线，变成了一个独立贡献者。如今，Kai 负责主导整个 VS Code 项目，他大约在 10 年前加入了这个项目。两人在这档节目中，围绕 Copilot 开源进行了一系列独家分享。

为何开源：真正的“护城河”不在客户端

VS Code 此前架构是“开源核心 + 闭源扩展”的模式。VS Code 本身是开源的，里面有一些 AI 支持功能是开源的，但 Copilot 本身是一个闭源扩展。这背后是有原因的，也有一个发展过程。

最初 Copilot 是从代码补全功能开始的。当时 VS Code 和 GitHub Next 的团队有非常紧密的合作，后者主要在探索这类新交互方式的 UI。于是 VS Code 引入了“Ghost Text”补全功能，这在当时是全新体验——在此之前，编辑器里只有提示窗口。

早期的 Copilot 主要依赖一个定制化、精调过的 GPT-3.5 模型，很多“智能”其实都是在扩展中完成的，比如 prompt 构造等。总体上，Copilot 是一个巨大成功，用户反馈是“太神奇了”。当然也会有用户指出它偶尔会出错、建议不准确等问题。

之后，随着 ChatGPT 和 GPT-4 的发布，每个人几乎都开始重新思考“AI 还能做什么”。

微软团队意识到，AI 的 UI 部分必须深入嵌入用户的工作流中。而问题是，当时 AI 要真正有用，代价是非常高的：prompt 需要大量处理，数据需要预处理，结果还得后处理，模型回复的格式也常常不理想。得写很多代码去构建 prompt、控制上下文、处理各种用例的问题。

“从业务角度看，当时也没人知道该怎么用这玩意赚钱。运行成本极高，我们又不想轻易把东西免费送出去，市场趋势也不明朗。于是我们采取了‘开源核心 + 闭源功能’的策略，UI 和部分功能进入核心，我们必须通过例如 API 来启动一些元素，所以我们创建了更多 API，但核心内容还是在 Copilot 中。”Kai 说道。

而如今，整个 AI 工具链已经变得成熟了很多，比如 OpenAI 的 cookbook、Anthropic 的教程、Google 那份 68 页的 prompt 指南等。像 CodeX 这样的开源项目也展示了如何构建完整的 prompt 流程。

过去两年，情况发生了很大的变化。prompt 工程本身已经不再神秘，也更易掌握了。

另外一个重要因素是，现在微软对商业模式的理解也更清晰了。Kai 表示，真正的“护城河”其实在服务端，而客户端更多是交互逻辑，这部分其实很适合开源。因此，微软认为现在是时候将 AI 功能也开源，让大家能够：

• 克隆 VS Code；
• 自行构建并运行；
• 使用开源的 Code OSS 版本体验完整流程；
• 调试所有从输入到服务端响应的过程；
• 优化逻辑、提交问题、贡献代码。

换句话说，微软希望复制 VS Code 本身开源成功的路径。在一个市场逐渐成熟的时候，开源能帮助开发者更深入地参与讨论、提出想法，而不只是等着项目发起团队实现。微软认为，这一时机现在已经成熟。

原生 AI 编辑器是什么样的

“像 Cursor 这样的新对手让我有点‘眼红’。”如今已经 64 岁的 VS Code 创始人 Eric 在采访中不止一次提到。

Eric 认为，一个原生 AI 编辑器不应该把 AI 功能“挂载”在 VS Code 上，而应该是核心的一部分。用户编写开源软件时，它就在那里，不需要安装任何东西。因此，团队现在要做的就是把 AI 彻底变成核心的一部分，而不是额外安装的插件。

现在所有关于 prompt 构造、模型交互的逻辑都还藏在 Copilot 扩展中，Eric 希望将这些开源后能吸引更多开发者的关注和贡献。这样也更安全，对开发者来说也更透明。

“我喜欢这个变化的另一个原因是，我们之前在开源和闭源之间来回切换其实挺痛苦的。”Eric 补充道，“项目属性不同，我们的说话方式也不同。开源社区友好热情，而闭源产品的用户则更像‘客户’，要求多、没啥耐心。能把整个工作流程都统一为开源，对我们开发团队本身来说也是一种‘解压’。”

Eric 还提到，将 AI 部分开源的一个原因是从一些组织那里听到的反馈——他们真的不喜欢闭源的 IDE。将其他部分也开源就满足了这些企业的需求，他们可以选择闭源，也可以选择开源。

值得注意的是，Copilot 是有免费选项的，开发者可以直接注册并免费使用，但会受到调用高级模型的请求次数等限制。Copilot 中有一个没有调用限制的基础模型。如果用户有自己的 API Key，也可以用“Bring Your Own Key”（BYOK）方式接入，直接使用指定的模型服务，而非通过 GitHub 后台服务，费用开发者自己承担。

如果用户付费使用更高级的 Copilot 功能，那就和开源没有直接关系了。“总得有人为模型的计算资源买单，这和是否开源是两码事。”Kai 说道。

所谓开源，是用户可以看到所有客户端上发生的内容，也能看到团队发送到服务器的内容。而客户最终所支付的费用，基本上就是后端运行大模型所产生的计算费用。对于企业用户来说，还有一些附加服务，比如免责保障（indemnification）之类。

Copilot 开源后的一些变化

开源后，上下文是公开的

Copilot 的一个重要组成部分就是确定要将哪些信息发送给模型。如果 Copilot 开源，我们就能清楚地看到究竟哪些内容被发送给了模型，以及这些数据是如何被处理的，进而能够进行改进。

最开始时候，模型还不支持像样的工具调用（tool calling），所以 Copilot 团队几乎必须把所有需要的信息预先打包好，一起发给模型。但那时也会遇到“干草堆里找针”的问题——发得太多反而会让模型困惑。

现在，Copilot 对于生成补全的请求，还是会尽可能地将上下文预先打包，然后让模型去补全。但这里面还是有很多思考，比如该发哪些东西。比如说，打开的标签页会被用来计算额外的上下文，如果语言服务器支持的话，我们会以某种精简形式把类型信息等也一并发过去。

但也有些场景并不再那么依赖这些了，比如 Agentic 流程。

在 Agentic 流程中，Copilot 用的是内部称之为“面包屑提示”（breadcrumb prompts）的方式。比如现在问题面板里有个问题，终端里也有输出，那就只是告诉模型这些信息存在于哪里，并且给模型提供检索这些信息的工具，然后模型自己判断它是否需要这些信息。这种方式更简单。当然有时候也需要用合适的提示方式来引导，比如告诉模型在思考时该优先考虑哪些方面。但总体来说，引入工具调用之后，整个上下文处理过程简单了许多。

生成提示词方面，Copilot 现在用类似 tsx 的结构来描述提示语，而不是简单的字符串拼接。这种方式带来了灵活性，比如可以给树结构中的节点分配不同优先级，按需要添加或减少内容，这些都能根据上下文窗口灵活调整。

但提示词本身也可以告诉模型优先使用哪些工具。比如可以写明：先检查问题面板里是否有错误信息，不要一开始就看终端输出之类的。用户可以引导模型按照希望的顺序去处理上下文信息。不过，Copilot 仍然面临上下文窗口的限制。有的限制是模型本身的技术约束，有的则是希望通过控制窗口大小来提高吞吐量，这些都需要权衡。

Copilot 团队的一个明确经验法则是：用尽可能短的提示语得到尽可能好的结果。所以如果你把整个上下文窗口都填满了，然后得到了一个不错的结果，问题就变成了：能不能删减一些内容，依然得到同样好的结果？

这也正是 Copilot 整套提示语渲染逻辑的关键：要知道在什么时间点可以删掉哪些内容。比如“历史记录”这一部分，如果不希望把所有历史记录都灌进去把上下文窗口填满，那就得有一个自然的截断方式，比如判断对话是从什么时候开始转到与之前无关的新话题的。

实际上，提示词本身并没有太强的语言特异性。

在早期阶段，Copilot 确实有一种被称之为 “cookbooks”的方式，比如不同的 linter（代码检查器）会抛出不同的错误和错误信息，然后团队就会针对这些情况创建一些“cookbooks”。像是出现了类似在 Python 文件中使用了 PyLint 的错误，“cookbooks”会给出一些修复方式、错误的含义，以及如何可以解决等。这种做法是强语言相关的，有时甚至需要提供语法方面的提示。

但随着系统的成熟，这些特定语言的“cookbooks”变得不那么必要了。

当然，在处理补全上下文（completions context）的时候，仍需考虑语言的特性。例如，支持某个语言支持类型，比如接口（interfaces），那就需要编写一些逻辑代码去找出你想包含的合适接口。

另一个有点语义性质但并不属于语言特异性的部分，是关于工作区知识的处理方式。整个流程中，如何找出最相关的代码片段添加到提示词，这背后有一个非常复杂的索引基础设施。这个系统是基于一个类似树结构的数据库，具有范围（ranges）等的语法结构知识，然后再去计算嵌入（embeddings）。但这一套逻辑是在语法级别上完成的，而不是语言特定的。

Copilot 服务端有哪些“秘密武器”？

Copilot 在某些场景下用的是微调后的模型，而且不只用一个模型，而是好几个。

“我们会越来越多地看到这种趋势：虽然一个大模型很聪明，能做很多事，但它既昂贵又慢。你希望给用户提供的是一个快速体验，给自己减少基础设施负担——这就意味着你需要不断‘蒸馏’，一步步缩小模型，直到针对每个特定任务都有一个足够小但效果很好的模型。”Kai 说道。

虽然用户能用 BYOK，但 GitHub Copilot 服务本身其实还附加了一些其他能力。

比如，GitHub 团队会对所有开源仓库做索引（也可以选择让你的私有仓库被索引）。这个“索引”的实际含义是把代码分块（chunking），然后对每个代码块计算 embedding。查找相关代码时，比如用户输入了某个查询，Copilot 就会对这个查询计算 embedding，然后去代码库中查找距离这个 embedding 最近的代码块。这就是 GitHub 提供的服务之一。

这是否算是“秘密武器”呢？或许可以这么说，但 Kai 拒绝了用“秘密武器”这个词。在他看来，这更准确地说是规模化能力，要支撑 GitHub 仓库的数量级，需要很强的基础设施。

现在的新模型还在编辑文件方面表现特别好。比如 set 命令的替换功能，用户可以搜索某个字符串并替换成其他内容。新出的 OpenAI GPT-4.1 之类的模型支持 apply_patch 功能，能以 diff 的形式返回补丁，非常精准。

但也有很多场景下，模型并不擅长直接做 diff 操作。这时团队会用另一种方法：告诉模型，“请给我一个这个文件的重写版本”，保持没改的地方一致，明确哪些地方是旧代码，然后再把原文件和新文件一起送给模型，让它拼出一个合理的合并版本。

这就是一个自定义模型的例子，Copilot 团队每天都要用很多次。要支持高频调用，就得足够便宜。而要便宜，就需要定制化的模型，即能很好完成任务的最小模型。

“再如代码补全的模型肯定是定制的，还有类似‘下一步编辑建议’功能（比如你在某处改了代码，它提示你后面也要同步修改），这个功能也需要定制模型。当然用户也可以什么都不做，直接用大模型处理所有任务，但那会非常昂贵且缓慢。”Kai 说道。

对 Cursor 和 Windsurf 意味着什么？

VS Code 一经发布就“引燃”了整个圈子。当时虽然已经有 Atom 和 Sublime 等编辑器，但社区里很大一部分人都迅速转向了 VS Code。

“当时我们注意到出现了一批新型开发者，我们常称之为‘纯粹的 Web 开发者’。我们希望为他们提供工具，让我们对他们也具有吸引力。虽然我们当时已有 Visual Studio 这样一个功能强大的集成开发工具，但我们想打破这种一体化的传统模式，吸引那些更喜欢命令行、喜欢自定义工具、使用多种语言的 Web 开发者。就是在这样的初衷下，我们创建了 VS Code。”Eric 追忆了 15 年前建立 VS Code 项目的时候。

Eric 将 VS Code 归为“十年磨一剑”后的一夜成名。“在发布前，我们其实已经按照每月迭代的节奏持续开发了五年。真正的增长是逐步发生的，不是一蹴而就的。”

VS Code 一直是渐进式增长的，现在有大约 4000 万用户。从 Github 上看，VS Code 目前已经有了 3.2 万个分叉项目。

业内基本认为，Cursor 也属于 VS Code 的众多分叉项目中的一个，其保留了 VS Code 的核心架构、界面布局和扩展生态。这也是与 Cursor 初期最为人道的一点。

别人是否可以拿 VS Code 所有的东西，如整个系统，然后重新贴一个标签说“这是我们的”，并以他们的名义推广？Kai 的答案是“当然可以”。但他会对这些项目不回馈上游社区、不回馈整个开发者生态的做法表示质疑。

“ 现在很多人做 VS Code 的 Fork（分支版本），但我觉得他们中的一些已经偏离了 VS Code 原本的设计精神，用 VS Code 的精神误导人们。”作为项目创建者，Eric 直白地说出了自己的担忧，“比如在某些 Fork 中，随处都能看到一个蓝色的 AI 按钮，承诺 AI 无处不在。当然，你可以这样做，但我们一直强调的是平台思维，要为更多人服务，而不是垄断一切。”

Eric 还提到了一致性的问题。“我们非常重视 VS Code 中的一致性，但在很多 Fork 中，这一点被忽略了。比如，Cursor（一个 VS Code 的衍生项目）已经改变了 UI，把活动栏放到了顶部，这个设计挺好的，我们也引入了类似功能。但我很难理解，为什么他们没有回馈这个功能到主项目中？”

“ 更令人沮丧的是，我们注意到他们实现这个功能时，他们给用户的实现并不完整。比如我们在 Git 视图中还会显示有多少文件发生了变更的徽章（badge），他们就没有实现。这种对一致性的忽视让我挺受伤的。”Eric 表示，“我们做每一个功能都非常认真地考虑一致性，而 Fork 项目有时会为了短期目的而忽略平台整体性。我们关注的是长期发展，而不是某一波 AI 热潮。”

Kai 认为，竞争将越来越多地集中在围绕这些东西所提供的服务上，即真正运行在后端的那些部分。

在他看来，和很多情况一样，真正重要的地方是在服务器端——如何构建服务、如何扩展、如何真正为客户提供持久价值。而人们希望能够信任客户端上的东西，特别是对于大型企业用户来说，他们希望能够看到、审计客户端到底做了什么，并确保一切合规、可靠。

“我无法准确说这对 Cursor 的业务意味着什么——那是他们的事情，不是我的。 但我可以从刚才提到的角度去思考：竞争的核心已经转移到服务器端了。客户端的设计也影响了我们的决策——比如我之前提到的 prompt 设计、上下文处理等，这些已经越来越成熟了。”Kai 说道。

“对于我们这些开源项目维护者来说，看到别人 fork，当然不是令人愉快的经历。”Eric 则坦诚道。

根据 Eric 的说法，那些 fork 项目之所以要 fork VS Code，是因为 VS Code 的 API 不够强大，无法支撑他们想要的 AI 创新。“ 这确实是事实——我们现在的 API 不允许开发者用它做很复杂的 UI，这是有意为之，因为我们很注重稳定性和性能。比如，你不能用我们的扩展 API 来构建一个像 Copilot 那样的联合补全（co-completion）UI，那根本不支持。”

“但我也要强调一点：虽然这些 API 不支持深度创新，但社区还是在现有 API 基础上做出了很多创新。比如很多不错的 AI 编辑器扩展。但确实，想做更底层的创新会面临挑战。当然这也是我一直‘嫉妒’的原因。”Eric 说道。

Eric 补充称，“另一点，那些 fork 直接内置了 AI。fork 允许他们做我们没有做的事情。而我们团队因为各种结构原因，一直要把 AI 功能封装在一个闭源扩展里。现在不用这么做了，对我和开发团队来说是种解脱。我们终于可以采用真正‘AI 优先’的思维方式去构建产品，这意味着别的扩展也可以……”

“毕竟，真正的价值最终还是在后端。”Eric 说道。

而 UI 交互形式上，Eric 指出，客户端的某些 UI 交互形式已经开始趋同了，比如 inline chat、如何展示 diff（差异）、如何流式展示内容等已经有了一定的共识和统一趋势。

如何运营开源社区

根据 Eric 的说法，AI 部分开源后，VS Code 的整个思路没有改变：在 VS Code 里用户可以通过写一个扩展来参与，通过扩展 API 来贡献功能；也可以通过提 Pull Request 的方式参与，比如发现某个 AI prompt 有问题想改进它。

新的变化是：第一，开源社区有了源码访问权限，如果扩展有问题，可以直接去看源码更深入地理解；第二，社区可以通过 Pull Request 的方式参与，也就是说“写一个扩展”其实就是在做贡献。

宣布开源后，整个团队还有很多工作要做。这和当年开源 VS Code 的模式不一样。那时候是一个完全闭源的项目，我们准备好后直接切换为开源。而这次是从已经开源的 core 出发，要继续“调优”和“重构”，以开放 AI 的相关能力。

“这意味着社区会看到我们对 core 的一些改动，”Eric 说道。“大家也会有疑问：发生了什么？大家真的会盯着每一条 commit 看。我们当然不能靠写假的 commit message 糊弄过去，而是真的是在做有意义的改进。”

此外还有需要考虑很多因素。首先是法律问题，比如要确保每段代码都有合适的版权声明、没有引用内部问题单或者泄露内部信息等等。这些听起来都是“显而易见的”，但确实需要处理。

然后是代码质量的问题。如果没人看代码，代码质量可能就不太行；但如果全世界都在看，写代码的心态就完全不同了，有人可能会因此感到压力。不过 Kai 明确表示，现阶段不会把“代码质量”作为开源门槛的重点考虑因素，反而更关心的是诸如内部已经有的那些 issue 怎么处理等问题。

另外，还有测试用例本身的问题。好用的测试用例往往来自我们内部的 flight（测试回归运行），我们会看到一些真实的 prompt、源代码片段，观察失败的案例，然后把它们加入到 S 测试套件中。

但现在我们需要把这些内容清洗掉，才能对外发布。这又是一个工作量不小的过程。

“今天我们从‘宣布开始’这件事正式起步，然后我们会一步一步推进。我们最重要的承诺是：我们不会‘扔下包袱’就走人了，这不是我们的风格。”Eric 说道。

Eric 给出了承诺：“我们会确保整个过程是完全透明的。你可以清楚地看到我们每一步在做什么，未来计划是怎样的。我们的变更计划是公开的，每个月的计划甚至都固定贴在 GitHub 的 Issue 上。你可以随时关注，可以提出问题，这就是我们的运作方式。我们会确保整个过程完全透明。”

不过，开发者现在还看不到所有内容，“因为我们前面也提到了——有很多工作还没做完。”

参考链接：

https://www.youtube.com/watch?v=GMmaYUcdMyU

声明：本文为 InfoQ 翻译整理，不代表平台观点，未经许可禁止转载。