VS Code 如何利用 AI 进行构建

2026年3月13日 作者：Pierce Boggan

我们每天都在使用人工智能来发布 VS Code。它让我们的速度变得如此之快，以至于在经历了十年的每月发布后，我们刚刚改为了每周发布。AI 智能体（Agents）是打开这一局面的关键，不仅体现在编写代码上，还贯穿于团队工作的方方面面。

为了拉开 Agent Sessions Day（智能体分享日）的序幕，我与 VS Code 团队的工程经理吕鹏（Peng Lyu）坐在一起，详细探讨了 VS Code 团队如何在日常工作中实际使用 AI。不仅用于实现功能（这部分是不言而喻的），还涵盖了围绕功能构建的一切：问题分类（triage）、代码审查、版本说明（release notes）、验证，以及如何在会议密集的日程中保持高效。

在那场分享中，我们大概只涵盖了团队在任何特定日子里使用智能体所做工作的 5%。但这代表了一个被数百万开发者使用的产品是如何构建的。因此，我们希望分享更多关于近期工作流的重大变革，以及我们对未来发展的设想。

经历了十年的每月发布后，我们转向了每周发布

我们每月发布一次 VS Code，坚持了十年。每个月，我们都要经历我们那套运作良好的周期：规划、构建、测试、收尾（endgame）、发布。团队中的每个成员轮流扮演不同的角色，这种节奏已经融入了团队的文化中。

最近，我们决定开始以每周的节奏发布 VS Code。并且我们希望保持同样严格的严谨性和质量标准。一个月的周期给了你喘息的空间，有时间去规划、有时间进行完整的收尾周（团队在这一周交叉测试彼此的功能）、有时间编写详尽的版本说明。转向每周的节奏意味着所有这些都必须加快或者实现自动化。这是一个巨大的改变，一年前我们是绝对做不到的。这一转变之所以成为可能，完全是因为智能体改变了我们的工作方式。

每周发布并不只是为了追求更快的发布速度本身，而是为了更快地将改进交付给开发者。一个过去需要等待三周才能随下一个稳定版本发布的错误修复，现在几天内就能发布。周一合并的功能，当周就能出现在开发者的编辑器中。这种发布 > 学习 > 迭代的反馈循环变得快得惊人。

我们从这次转变中学到了什么

随着不断学习和适应，我们的工作流和流程每天都在演变。但有一些核心经验依然经得起考验：

1. 实现自我并行化。养成在进行上下文切换之前启动多个智能体（agent）会话的习惯。工作树（Worktrees）、云端智能体、多个 VS Code 会话……把它们全用起来。
2. 跳过中间产物。过去是“会议纪要 → 问题（issues） → 规格说明（specs） → 代码”，现在实际上变成了“会议 → 智能体会话 → 代码 → PR（拉取请求）”。
3. 将随着速度增加而增加的开销自动化。我们使用 Copilot CLI、Copilot SDK 和 GitHub Actions，构建了基于智能体的流水线，用于问题分类、提交总结、版本说明和代码 review。工程师仍然是这些工作流的另一端，但智能体有助于更快地将正确的内容呈现给正确的人。
4. 在追求速度之前投资于保障机制（harnesses）。测试、黄金场景（golden scenarios）和代码审查关卡可以防止由智能体驱动的速度演变成由智能体驱动的代码倒退（regression）。
5. 所有权正在演变。当产品经理（PM）、来自其他领域的工程师、社区贡献者以及智能体都可以为任何组件做出贡献时，传统的所有权模式必须随之调整。但对结果的问责制仍然落在工程师身上。
6. 让人类参与进来以把控“格调与品味”。智能体检查正确性，人类评估愉悦感。

让我们更详细地看看这些原则如何在我们的团队中发挥作用。

并行工作

保罗·格雷厄姆（Paul Graham）曾写过一篇著名的文章，探讨了创作者日程（maker schedule）与管理者日程（manager schedule）如何从根本上水火不容。直到最近，这基本上都是事实。但智能体正在改变这一点。

以下是典型的一天可能会发生的情景：

• 在开会前，启动 3-4 个智能体会话来修复 bug、制作功能原型或分类问题。
• 在开会期间，智能体在多个 VS Code 会话、工作树或云端并行运行。
• 会议结束后，审查智能体的输出，在本地进行验证，合并代码或重新提示（re-prompt），然后再次启动。

管理者仍然需要参加会议并处理其他管理任务，但他们现在可以利用智能体来承担一些创作者的工作——这在以往会议满满的日程中是不可能完成的。

让我举一个真实的例子。鹏（Peng）每天早晨从更新 VS Code Insiders 开始。大多数日子里，我们一天发布两次 Insiders 构建版本，以便尽早获得对我们正在开发内容的反馈。接着，他运行一个自定义智能体，通过 Work IQ 获取他的会议安排，并生成他当前待办事项的快照。

由此，鹏决定什么需要他亲自关注，什么委托给智能体，以及团队应该优先处理什么。智能体负责收集上下文的繁琐工作，这样他就能直接切入有趣的问题。当他参加第一次电话会议时，各项任务已经处于并行运行状态了。

“以前，你总是在按顺序工作。你写下笔记，把它们变成 issues，然后由别人或你自己以后再来处理。现在，你被赋能了，能够并行做事。这是一种你必须养成的习惯。所以，我不再写会议纪要了。我直接启动智能体。” — 吕鹏（Peng Lyu）

这确实是一种新技能。开会时如果有人提到我们需要做某事，我当场就会启动智能体。我们还为 Teams 中的大多数会议启用了转录功能，因此事后获取上下文非常容易。过去“会议纪要变成 issues，再变成工作”的流程，现在变成了当场发出的一条提示词（prompt）。

让开销自动化

更高的速度固然很好，但它也会带来相应的开销：需要分类更多的 issues、需要追踪更多的 commits、需要编写更多的版本说明。以下是我们如何将那些随速度规模化增长的环节实现自动化的。

提交总结（Commit summarization）。我们构建了一个自定义斜杠命令（slash command），可以跨多个代码仓库获取过去 24 小时的所有提交，并使用一个快速模型对它们进行总结。过去，执行 `git fetch` 后可能会有 20 或 30 个提交；而现在，可能会有 100 多个提交在等着你。整个功能领域可以在一天内落地。同样的流水线会输入到我们的 Insiders 变更日志（changelog）中，并为我们发布每日更新的自动 X（原 Twitter）账号提供支持。这一切都构建在 Copilot CLI 和 Copilot SDK 之上，作为由主干（main）提交触发的 GitHub Actions 运行。

问题分类（Issue triage）。VS Code 是 GitHub 上最大的开源项目之一。我们热爱我们的社区，收到的 issues 数量反映了有多少人关心这款产品：每天都有数百个涌入。过去我们有一个轮流担任的“收件箱追踪器”角色，一个人负责分类一周内所有的内容。这在现在已经无法规模化了。

现在，每当开启一个新的 issue 时，它都会在 GitHub Actions 中触发一个智能体循环，该循环会检测重复项（带有置信度分数）、确定合适的负责人并建议标签。智能体会读取我们的所有权文档并查看历史分配模式，因为所有权会随着时间推移而发生变化。

你可以从仓库的公开数据中看到这一点：将 1 月到 3 月的数据进行年同比比较，提交量增加了一倍以上，团队关闭的 issues 数量接近过去的 3 倍。更好的分类帮助工程师更快地找到并修复正确的问题，从而腾出更多时间进行实际的软件开发。

“既然那段代码是由 Copilot 编写的，谁才是它的真正所有者？我认为依然是由结果负责的工程师。但你确实需要合适的保障机制来欢迎其他人为你的组件做贡献。” — 吕鹏（Peng Lyu）

团队还构建了一个 Chrome 扩展程序，可以直接在 GitHub issues 上显示分类建议，例如重复项、负责人和标签。它包含一个显示整个团队 issue 状态的仪表板。在 VS Code 内部，自定义斜杠命令让工程师无需离开编辑器即可整理（groom）issues 并查找重复项。

我们已经看到团队的发布速度有了实质性的提升。随着这些工作流的成熟，我们还有很多东西可以继续自动化、简化和学习。

每个人都在交付代码

这是让我最兴奋的部分，因为它对我的工作方式产生的改变超过了其他任何东西。

传统的产品经理循环是这样的：编写规格说明或 PRD → 创建 issues → 移交给工程团队。没有人喜欢读那些规格说明，其根本问题在于它们是基于假设的。你写的是你认为体验应该是什么样的，但在它构建出来之前，你其实并不知道。因此，功能验证的周转时间可能会很长。

改变的是，我不再去创建规格说明，而是创建一个原型——一个真实的 PR（拉取请求）！

借助 VS Code 中的智能体，我可以从某人在 X 或 Reddit 上给我们反馈，直接进展到一个可工作的原型，在 Insiders 上自托管并体验它，然后继续迭代。我上个月合并了一个 PR，实现了 Copilot Chat 中的对话分叉（forking conversations）。我和我们的工程师之一 Justin 一起审查了这个 PR，在办公室里一起解决了一些 CSS 更改并将其合并。现在这个功能已经在 VS Code 里了。

这并不意味着所有这些原型最终都会进入产品中。工程师仍然对代码质量和架构负责。如果鹏看了我的 PR 并说“这个架构不对”，那很公平，我完全可以接受我的 PR 被抛弃并重新构建。但这个 PR 推动讨论前进的速度比任何文档都要快。第一个 PR 不一定非要完美。它能取得实质性进展，并开启与拥有该功能领域的工程师的对话。

这种工作流也是检验你的代码库是否“就绪智能体（agent-ready）”的试金石。智能体能找到正确的组件吗？它能发现回归错误吗？它能找到正确的修复方案吗？如果一个产品经理可以向智能体抛出一个问题并得到一个合理的 PR，这就说明该代码库的结构、文档和测试覆盖率都相当不错。如果智能体感到吃力，那也是一个信号。

在速度提升的同时保持高品质

更快的速度意味着更高的回归风险。

“如果没有正确的保障机制，头一两周你的生产力会非常高。然后你会迅速触及天花板，陷入不断出现回归错误的泥潭。” — 吕鹏（Peng Lyu）

如果一个新组件没有良好的防护栏（guardrails），智能体驱动的开发就会高开低走，质量迅速下降。基础知识依然重要，而借助 AI，我们实际上可以进一步改进它们：

• 自动化验证。当你同时运行 5-10 个智能体时，手动验证每一个智能体带来的不仅是能编译的代码，还有正确的体验，成本是非常高昂的。我们的团队构建了一个自定义智能体，它使用 Playwright MCP 服务器启动 VS Code、导航到测试中的功能、截取屏幕截图，并评估更改是否符合预期行为。因为它在一个智能体循环内运行，如果截图显示某个地方坏了，智能体会去修复它。屏幕截图会被保存供人工审查。

• 测试。全面的测试套件、单元测试、集成测试以及运行它们的底层基础设施是基本要求。除此之外，我们还记录了黄金场景（golden scenarios）：核心用户流预期行为的规格说明。传统上，我们会在每月的收尾周期间手动测试这些场景。现在，我们将这些场景交给智能体，作为合并后的自动化验证运行。我们还在探索使用此流水线自动生成演示录屏：一个 PR 落地，系统就会生成一段演示视频，并将其用作变更日志或推文的内容。

• 代码审查。每个 PR 都会自动获得一次 Copilot 代码审查，工程师在请求人工审查之前会先解决 Copilot 的意见。六个月前，我们没有强制执行这一点，因为反馈噪音太大。在过去几个月中，模型质量显著提高，通常在第一轮就能发现安全、性能和代码质量问题。在请求人工审查之前解决这些意见已成为我们工作流的自然组成部分。我们通过一个 Slack 频道进行协调，其中有一个机器人会发布带有 CI 和 Copilot 代码审查状态指示器的 PR，随着检查完成，两者都会就地更新。我们的文化是“付出换取回报（give one, take one）”：提交一个 PR，顺便接下一个审查任务。

• 评估格调与品味。人工审查不会消失，反而变得更加重要。当智能体编写更多代码并且 PR 落地更快时，人类审查员需要检查该更改对产品而言是否真的合理。这是否符合长期的架构？用起来感觉对不对？智能体可以捕获 bug，但它们无法告诉你某个功能是否会让开发者感到愉悦。

传统上，我们有收尾周，工程师、产品经理和设计人员会在这一周测试彼此的功能。我们并没有废除这一做法，而是将其在时间上进行了压缩。在产品经理这一侧，我一直在探索我所认为的基于品味的评分：写下我希望某个功能具备的定性体验，然后使用智能体来评估实现是否符合预期。也许智能体 80% 的观察结果是有用的，20% 我会忽略，但这 80% 已经能让你取得很大的进展。比如：我们的模型选择器是只显示模型名称和乘数，还是有用户实际上会想要的更多信息？

我们认为，这种方法同样可以帮助我们检查已发布的文档是否真的符合使用产品的实际体验。我们所有的 VS Code 文档基本上都是由一个人编写的，考虑到我们的节奏，这简直不可思议，但当产品变化如此之快时，文档很容易过时。我们正在探索智能体如何帮助我们自动捕获这种偏差。

下一步计划

更广泛地说，这一切都归结为我们所认为的“就绪智能体的代码库评估”：你的代码库是否具备让智能体有效贡献所需的结构、文档和测试覆盖率？

我们由衷地好奇：你团队的版本是什么样的？有没有什么是我们漏掉的工作流？有没有什么是你们已经自动化了而我们还没想到的？在 VS Code 仓库中给我们提一个 issue，或者在 X 上找到我们——我们正在与你一起构建这一切，你的反馈将塑造我们的未来。

我们在 Agent Sessions Day 上还有许多其他精彩的分享，如果你还没看过，不妨去看看。

编码愉快！ 💙