VS Code 如何利用 AI 进行构建

2026年3月13日，作者：Pierce Boggan

我们每天都在使用 AI 来发布 VS Code。它极大地提升了我们的速度，以至于在经历了十年的月度发布周期后，我们刚刚改为了每周发布。智能体（Agents）是实现这一突破的关键，它不仅用于编写代码，还贯穿了我们团队工作的方方面面。

为了启动智能体会议日 (Agent Sessions Day)，我与 VS Code 团队的工程经理 Peng Lyu 进行了一次深入交流，探讨 VS Code 团队实际上是如何在日常工作中利用 AI 的。这不仅涵盖了功能实现（这部分是不言自明的），还包括构建功能所需的“周边”工作：分类处理 (triage)、代码审查、发布说明、验证以及如何在会议密集的日程中保持高效。

在那次会议中，我们可能只涵盖了团队日常使用智能体所做工作的 5%。但这代表了一个被数百万开发者使用的产品是如何构建的。因此，我们希望分享更多关于我们工作流程中近期发生的重大变革，以及我们认为未来的发展方向。

在经历了十年月度发布后，我们改为了每周发布

十年来，我们一直以月为单位发布 VS Code。每个月，我们都会经历一套成熟的流程：规划、构建、测试、收尾、发布。随着团队成员轮换担任不同角色，这种节奏已成为团队文化的一部分。

最近，我们决定开始以周为单位发布 VS Code。我们希望保持同样严格的质量标准。月度周期给了我们喘息的机会，有时间去规划、进行完整的收尾周（团队成员互相测试彼此的功能），并撰写详尽的发布说明。转向每周周期意味着所有这些工作都必须加快速度或实现自动化。这是一个巨大的变化，一年前我们是无法做到的。这种转变之所以成为可能，完全归功于智能体改变了我们的工作方式。

改用每周发布周期并不是为了单纯追求速度，而是为了更快地将改进提供给开发者。以前需要等待三周才能在下一个稳定版中修复的 Bug，现在几天内就能发布。周一合并的功能，当周就能出现在开发者的编辑器中。这种“发布 > 学习 > 迭代”的反馈循环速度大大加快了。

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

随着我们的学习和适应，我们的工作流和流程每天都在不断演进。但有一些关键的经验教训始终适用：

1. 实现自我并行化。养成在切换上下文之前启动多个智能体会话的习惯。利用工作树 (Worktrees)、云端智能体、多个 VS Code 会话……充分利用它们。
2. 跳过中间产物。过去的工作流程是：会议记录 → 问题单 → 规格说明书 → 代码；现在的流程正演变为：会议 → 智能体会话 → 代码 → PR（拉取请求）。
3. 自动化随吞吐量增加而增加的额外工作。我们利用 Copilot CLI、Copilot SDK 和 GitHub Actions，为问题分类、提交总结、发布说明和代码审查构建了由智能体驱动的流水线。工程师仍然处于这些工作流的终点，但智能体能帮助将正确的内容更快地推送给正确的人。
4. 在提升速度之前，先投入构建护栏。测试、黄金场景（Golden scenarios）和代码审查门禁可以防止由智能体驱动的速度演变成由智能体驱动的回归问题。
5. 所有权正在演变。当产品经理 (PM)、其他领域的工程师、社区贡献者和智能体都可以为任何组件做出贡献时，传统的权属模型需要进行调整。但成果的问责制仍由工程师承担。
6. 让人类参与评估体验。智能体检查正确性，人类评估满意度。

让我们更详细地了解这些准则在我们的团队中是如何运作的。

并行工作

有一篇著名的 Paul Graham 文章讲述了“创造者日程”与“管理者日程”是如何从根本上不兼容的。在最近之前，这基本属实。但智能体正在改变这一点。

以下是典型的一天可能的样子：

• 在参加会议之前，启动 3-4 个智能体会话，用于修复错误、原型设计功能或进行问题分类。
• 会议期间，智能体在多个 VS Code 会话、工作树或云端并行运行。
• 会议结束后，查看智能体的输出，在本地进行验证，合并代码或重新提示，然后再次启动。

管理者依然需要参加会议和处理其他管理任务，但他们可以利用智能体承担一些以前在会议密集日程中无法完成的创造性工作。

让我举一个真实的例子。Peng 每天早上都会先更新 VS Code Insiders。大多数时候，我们一天发布两次 Insiders 构建版本，以便能对正在进行的工作获得早期反馈。然后他运行一个自定义智能体，通过 Work IQ 获取他的会议安排，并生成一份他手头任务的快照。

在此基础上，Peng 决定哪些需要他重点关注，哪些可以委派给智能体，以及哪些需要优先考虑。智能体处理了收集背景信息的琐碎工作，使他能够直击核心问题。当他开始第一次通话时，任务已经在并行运行了。

“过去，你总是按顺序工作。你写笔记，把它们变成问题单，然后由别人或你自己稍后再处理。现在，你拥有了并行工作的能力。这是一种必须培养的习惯。所以，我不再记会议笔记了。我直接启动智能体。” —— Peng Lyu

这确实是一种新的“肌肉记忆”。会议中有人提到我们需要做某事，我当场就会启动智能体。我们还为大多数 Teams 会议启用了转录功能，因此事后获取上下文非常容易。过去那些“会议笔记转成问题单再转成工作”的流程，现在只需在当时启动一个提示词即可。

自动化琐碎工作

速度提升固然好，但也会带来额外的琐碎工作：需要分类的问题更多了，需要追踪的提交更多了，需要撰写的发布说明也更多了。以下是我们如何将这些随速度增长的部分实现自动化的。

提交总结。我们构建了一个自定义斜杠命令，可以获取过去 24 小时内跨多个仓库的所有提交，并使用快速模型进行总结。过去，你可能需要 `git fetch` 后面对 20 或 30 个提交。现在，可能有 100 多个提交在等着你。整个功能区可能在一天内就会合并。同一个流水线会汇总到我们的 Insiders 更新日志中，并驱动我们自动化的 X (原 Twitter) 账号发布每日更新。这一切都基于 Copilot CLI 和 Copilot SDK 构建，并作为由提交触发的 GitHub Actions 运行。

问题分类。VS Code 是 GitHub 上最大的开源项目之一。我们热爱我们的社区，我们收到的问题数量反映了有多少人关心这个产品：每天有数百个问题涌入。我们过去有一个轮换的“收件箱追踪”角色，一个人负责一周内所有的分类工作。这已经无法适应现状了。

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

你可以在仓库的公开数据中看到效果：对比 1 月至 3 月的同比数据，提交量增长了一倍多，团队解决问题的数量增加了近 3 倍。更好的分类帮助工程师更快地找到并修复正确的问题，从而腾出更多时间进行真正的软件开发。

“既然那部分代码是由 Copilot 编写的，谁是合适的负责人？我认为负责成果的仍然是我们的工程师。但你确实需要合适的机制来欢迎其他人为你的组件做出贡献。” —— Peng Lyu

团队还开发了一个 Chrome 扩展程序，可以直接在 GitHub 问题上显示分类建议，例如重复项、负责人和标签。它包含一个显示整个团队问题状态的仪表板。在 VS Code 内部，自定义斜杠命令允许工程师在不离开编辑器的情况下梳理问题并查找重复项。

我们已经看到了团队交付速度的显著提升。而且，随着这些工作流程的成熟，我们还有很多地方可以继续自动化、简化和改进。

人人皆可交付代码

这是让我最兴奋的部分，因为它改变了我工作的方式，远超其他任何事情。

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

改变的是，现在我不再创建规格说明书，而是创建原型，一个实际的拉取请求 (PR)！

借助 VS Code 中的智能体，我可以从有人在 X 或 Reddit 上给我们反馈开始，直接进入到一个可工作的原型，自我托管并在 Insiders 上体验，然后继续迭代。上个月我合并了一个 PR，实现了 Copilot Chat 中的分叉对话。我和我们的工程师 Justin 一起审查了该 PR，在办公室一起处理了几个 CSS 更改并合并了它。现在它已经在 VS Code 中了。

这并不意味着所有这些原型都会进入产品。工程师仍然对代码质量和架构负责。如果 Peng 查看我的 PR 并说“架构不对”，那是合理的，我不介意我的 PR 被废弃并重写。但 PR 比任何文档都能更快地推动对话。第一个 PR 不必完美，它能推动进展，并与负责该功能区的工程师开启对话。

这个工作流程也是测试你的代码库是否“智能体就绪”的试金石。智能体能找到正确的组件吗？它能找到回归问题吗？它能找到正确的修复方法吗？如果产品经理可以将问题抛给智能体并获得一个合理的 PR，这说明代码库的结构、文档和测试覆盖率做得不错。如果智能体感到吃力，那也是一个信号。

在提高速度的同时保持高质量

提高速度意味着回归风险增加。

“如果没有合适的机制，前一两周你的生产力确实很高。但随后你很快就会达到一个上限，不断出现回归问题。” —— Peng Lyu

如果一个新组件没有良好的护栏，智能体驱动的开发开始时很强，但质量会迅速下降。基本功依然重要，而有了 AI，我们实际上可以进一步提升这些基本功。

• 自动化验证。当你同时运行 5-10 个智能体时，手动验证每一个智能体是否提供了正确的体验（不仅仅是代码能编译）是非常昂贵的。我们的团队构建了一个自定义智能体，使用 Playwright MCP 服务器启动 VS Code，导航到受测功能，截屏并评估更改是否符合预期行为。因为它运行在智能体循环中，如果截屏显示出了问题，智能体会自动去修复它。截屏会被存储以供人工审查。

• 测试。全面的测试套件、单元测试、集成测试以及运行它们的基础设施是必备条件。除此之外，我们记录了黄金场景 (golden scenarios)：核心用户流程的预期行为规格说明。我们过去习惯在月度收尾周手动测试这些。我们现在将这些场景交给智能体，作为自动化的合并后验证来运行。我们还在探索使用该流水线自动生成演示录音：PR 合并后，自动生成演示视频，这成为了更新日志或推文的内容。

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

• 品味评估。人工审查不会消失，反而变得更加重要。当智能体编写了更多代码且 PR 合并速度更快时，人工审查员需要检查更改是否真的对产品有意义。这是否符合长期架构？用起来感觉对吗？智能体可以捕获错误，但它们无法告诉你一个功能是否会让开发者感到愉悦。

传统上，我们有收尾周，工程师、产品经理和设计师会测试彼此的功能。我们并没有取消它，而是将其时间压缩了。在产品经理方面，我一直在探索我所谓的“基于品味的评分”：写下我希望一个功能所具有的定性体验，然后使用智能体来评估实现是否相符。智能体的观察中可能有 80% 是有用的，20% 我会忽略，但那 80% 已经能让你走得很远了。比如：我们的模型选择器是否只显示了模型名称和倍数，还是包含了用户真正想要的其他信息？

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

下一步计划

更广泛地说，所有这些都回到了我们所谓的“智能体就绪代码库评估”：你的代码库是否具备了智能体能够有效贡献的结构、文档和测试覆盖率？

我们真心好奇：你们团队的版本是什么样的？我们遗漏了哪些工作流程？你们自动化了哪些我们没想到的事情？请在 VS Code 仓库中给我们提个 Issue，或者在 X 上找到我们——我们正在与你们并肩构建，你们的反馈将塑造未来。

我们在智能体会议日 (Agent Sessions Day) 上还有许多其他很棒的会议，如果您还没有看过，请务必查看。

编码愉快！ 💙