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

在昨晚的 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 本身开源成功的路径。在一个市场逐渐成熟的时候，开源能帮助开发者更深入地参与讨论、提出想法，而不只是等着项目发起团队实现。微软认为，这一时机现在已经成熟。

“像 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 开源，我们就能清楚地看到究竟哪些内容被发送给了模型，以及这些数据是如何被处理的，进而能够进行改进。

最开始时候，模型还不支持像样的工具调用（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 在某些场景下用的是微调后的模型，而且不只用一个模型，而是好几个。

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

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

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

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

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

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

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

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

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 上。你可以随时关注，可以提出问题，这就是我们的运作方式。我们会确保整个过程完全透明。”

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

来源：商财洞察君