VS Code官方：AI在自身开发流程中的应用

VS Code官方：AI在自身开发流程中的应用 | 前端进阶之旅

Full translation

完整中文译文

我们每天都在用 AI 发布 VS Code。这让我们的速度快了很多，在十年的月度发布之后，我们现在改成周度发布了。AI 智能体是解锁这一切的关键，不仅用于写代码，还涉及团队工作的方方面面。

为了启动 AI 智能体会议日，我与 VS Code 团队的工程经理彭律进行了一次深入交谈，探讨 VS Code 团队如何在日常工作中实际运用 AI。不仅仅是用于实现功能（那部分不言而喻），还包括构建功能的方方面面：问题分类、代码审查、发布说明、验证，以及在会议繁忙的日程中保持工作效率。

在那次会议中，我们可能只涵盖了团队每天使用 AI 智能体工作的 5%。但这代表了一个被数百万开发者使用的产品是如何构建的。因此，我们想分享更多关于我们工作流程的这些重大变化，以及我们认为接下来会走向何方。

十年月度发布后，我们改成了周度发布

十年来，我们每月发布一次 VS Code。每个月我们都要经历精心协调的周期：计划、构建、测试、收尾、发布。团队成员轮流承担不同的角色，这种节奏成为了团队文化的一部分。

最近，我们决定开始按周度节奏发布 VS Code。我们希望保持同样高的严谨性和质量标准。月度周期为你提供了喘息的空间：有时间规划，有时间进行完整的收尾周，让团队互相交叉测试对方的功能，还有时间编写全面的发布说明。切换到周度节奏意味着所有这些都必须加快或自动化。这是一个巨大的变化，一年前我们不可能做到。这种转变之所以可能，完全是因为 AI 智能体改变了我们工作的方式。

周度节奏不是为了单纯地更快地发布。而是为了更快地将改进交付给开发者。一个曾经要等三周才能随下一个稳定版发布的 bug 修复，现在几天内就能发布。周一合并的功能可以在同周进入开发者的编辑器。"发布 > 学习 > 迭代"的反馈循环快了许多。

这一转变中的关键经验

我们的工作流程和流程在不断演变，随着我们的学习和适应。但有一些关键经验仍然成立：

自我并行化。 养成在上下文切换前启动多个 AI 智能体会话的习惯。使用 Worktree、云智能体、多个 VS Code 会话……全部用上。

跳过中间产物。 过去是会议记录 → 问题 → 规范 → 代码，现在变成了会议 → AI 智能体会话 → 代码 → PR。

自动化随着速度增长而增长的开销。 我们使用 Copilot CLI、Copilot SDK 和 GitHub Actions 构建了由 AI 智能体驱动的管道，用于问题分类、提交总结、发布说明、代码审查等所有工作。工程师仍然在这些工作流的另一端，但 AI 智能体帮助更快地将正确的信息呈现给正确的人。

在追求速度之前投资护栏。 测试、黄金场景和代码审查门禁防止了由 AI 智能体驱动的速度变成由 AI 智能体驱动的回归。

所有权正在演变。 当 PM、来自其他领域的工程师、社区贡献者和 AI 智能体都可以对任何组件进行贡献时，传统的所有权模型需要适应。结果的责任仍然由工程师承担。

让人类参与品味决策。 AI 智能体检查正确性。人类评估是否令人满意。

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

有一篇著名的 Paul Graham 论文讨论了创作者日程和管理者日程如何根本不兼容。这在最近还大多是真的。但 AI 智能体正在改变这一点。

典型的一天可能看起来像这样：

进入会议前，启动 3-4 个 AI 智能体会话来修复 bug、原型化功能或对问题进行分类。

会议期间，AI 智能体在多个 VS Code 会话、Worktree 或云中并行运行。

会议后，审查 AI 智能体的输出、本地验证、合并或重新提示，然后再次启动。

经理仍然参加会议和其他管理工作，但他们可以使用 AI 智能体来承担一些创作者工作，这些工作在会议繁忙的日程中过去是不可能完成的。

让我给你一个真实的例子。彭每天早上开始时都会更新 VS Code Insiders。大多数时候，我们每天发布两次 Insiders 构建，以便我们可以获得关于我们正在处理的内容的早期反馈。然后他运行一个自定义 AI 智能体，通过 Work IQ 获取他的会议，并生成他手上的任务快照。

从那里，彭决定什么需要他的关注，什么要委派给 AI 智能体，以及为团队优先处理什么。AI 智能体处理收集上下文的杂务工作，这样他可以直接切入有趣的问题。到他进行第一通电话时，任务已经在并行运行。

以前，你总是按顺序工作。你写笔记，把它们变成问题，然后其他人或你稍后会处理它。现在你有权力能够并行做事。这是一个你必须养成的习惯。所以，我不再写会议记录。我直接启动 AI 智能体。——彭律

这真的是一个新的能力。会议中有人提到我们需要做的事情，我会立即启动 AI 智能体。我们还为 Teams 中的大多数会议启用了转录功能，所以事后获取上下文很容易。过去会议记录变成问题再变成工作的流程，现在只是当场启动的一个提示。

自动化开销

更快的速度很棒。它也会产生自己的开销：更多的问题要分类、更多的提交要跟踪、更多的发布说明要编写。以下是我们如何自动化随着速度增长而增长的部分。

提交总结。 我们构建了一个自定义斜杠命令，从过去 24 小时内跨多个仓库获取所有提交，并使用快速模型对其进行总结。过去你会进行 git fetch，然后有 20 或 30 个提交。现在可能有 100 多个等待你。整个功能区域可以在单日内合并。同一个管道流入我们的 Insiders 变更日志，并为我们自动化的 X 账户提供支持，该账户每天发布更新。一切都是使用 Copilot CLI 和 Copilot SDK 构建的，作为由提交到主分支触发的 GitHub Actions 运行。

问题分类。 VS Code 是 GitHub 上最大的开源项目之一。我们热爱我们的社区，我们获得的问题数量反映了有多少人关心这个产品：每天有数百个问题到达。我们过去有一个轮转的"收件箱跟踪器"角色，一个人在一周内对所有事项进行分类。这已经无法扩展了。

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

你可以在仓库的公开数据中看到这一点：按年比较 1 月至 3 月，提交量翻了一番多，团队正在关闭近 3 倍的问题。更好的分类帮助工程师更快地找到并修复正确的问题，这释放了更多时间用于实际的软件开发。

现在这段代码是由 Copilot 编写的，谁是正确的所有者？我会说仍然是我们的工程师要对结果负责。但你确实需要正确的护栏来欢迎其他人对你的组件做出贡献。——彭律

团队还构建了一个 Chrome 扩展，直接在 GitHub 问题上显示分类建议，如重复项、所有者和标签。它包括一个显示团队中问题状态的仪表板。在 VS Code 内部，自定义斜杠命令让工程师无需离开编辑器就能整理问题并查找重复项。

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

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

传统的 PM 循环看起来像这样：编写规范或 PRD → 创建问题 → 移交给工程。没有人喜欢阅读这些规范，根本的问题是它们基于假设。你在写你认为体验应该是什么样的，但直到构建完成你才真正知道。所以，功能验证的周转时间可能很长。

改变的是，我不再创建规范，而是创建一个原型，一个实际的拉取请求！

借助 VS Code 中的 AI 智能体，我可以从某人在 X 或 Reddit 上给我们的反馈出发，创建一个可工作的原型、自行托管并在 Insiders 中体验它，然后继续迭代。上个月我有一个 PR 合并，它实现了在 Copilot Chat 中分叉对话的功能。和我们的工程师之一 Justin 一起，我们审查了 PR，在办公室里一起处理了一些 CSS 更改并合并了它。现在这已经在 VS Code 中了。

这并不意味着所有这些原型最终都会进入产品。工程师仍然要对代码质量和架构负责。如果 Peng 看了我的 PR 后说：“这个架构不对”，这很合理；我的 PR 被弃用并重新构建，我也完全可以接受。但相比任何文档，PR 都能更快地推动讨论。第一个 PR 不必尽善尽美。它能推动事情取得进展，并开启与该功能领域负责工程师的对话。

这套工作流也是检验代码库是否适合 AI 智能体的一块试金石。AI 智能体能找到正确的组件吗？能发现回归问题吗？能找到正确的修复方案吗？如果产品经理可以把一个问题交给 AI 智能体，并得到一个合理的 PR，那么这在一定程度上说明代码库的结构、文档和测试覆盖率都做得不错。如果 AI 智能体处理起来很困难，这同样也是一个信号。

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

速度越快，出现回归问题的风险就越高。

“如果没有合适的配套机制，最初一两周你的生产力会非常高。接着，你很快就会触及上限，因为系统会不断出现回归问题。”——Peng Lyu

如果一个新组件没有良好的护栏，AI 智能体驱动的开发在开始时会进展迅速，但质量很快就会下降。基础工作仍然至关重要，而借助 AI，我们实际上可以把这些工作做得更好：

自动化验证。当你同时运行 5～10 个 AI 智能体时，逐一手动验证它们交付的是正确的体验，而不只是能够编译的代码，成本会很高。我们的团队构建了一个自定义 AI 智能体，它使用 Playwright MCP server 启动 VS Code、导航到待测试的功能、截取屏幕截图，并评估变更是否符合预期行为。由于它运行在 AI 智能体循环中，如果截图显示存在问题，AI 智能体就会着手修复。截图会被保存下来，供人工审核。

测试。完备的测试套件、单元测试、集成测试，以及运行这些测试所需的基础设施，都是必备条件。在此基础上，我们还会记录黄金场景：针对核心用户流程预期行为的规范。过去，我们通常会在每月的收尾周手动测试这些场景。现在，我们开始把这些场景交给 AI 智能体执行，作为自动化的合并后验证。我们还在探索使用这套流水线自动生成演示录像：PR 合并后，系统生成一段演示视频，随后可以将其用作更新日志或推文的内容。

代码审查。每个 PR 都会自动接受 Copilot 代码审查，工程师会先处理 Copilot 的意见，再请求人工审查。六个月前，我们没有强制执行这一流程，因为当时的反馈噪声太大。在过去几个月里，模型质量有了显著提升，通常能在第一轮审查中发现安全、性能和代码质量问题。在请求人工审查前先解决这些意见，已经成为我们工作流中自然而然的一部分。我们通过一个 Slack 频道进行协调，机器人会在其中发布 PR，并附上 CI 和 Copilot Code Review 的状态指示；随着检查完成，这两项状态都会在原位置实时更新。我们的文化是“提交一个，审查一个”：提交一个 PR，就主动接手一项审查。

品味评估。人工审查不会消失，甚至变得更加重要。当 AI 智能体编写更多代码、PR 的合并速度更快时，人工审查者需要判断这项变更对产品而言是否真正合理。它是否长期符合整体架构？使用体验是否自然？AI 智能体可以发现缺陷，却无法告诉你某项功能能否真正取悦开发者。

过去，我们会安排收尾周，让工程师、产品经理和设计师相互测试彼此负责的功能。我们并不会取消这一环节，而是会压缩它所需的时间。在产品经理这一侧，我一直在探索一种我称为“基于品味的评分”的方法：先写下我希望某项功能具备的定性体验，再使用 AI 智能体评估其实现是否符合预期。AI 智能体的观察中可能有 80% 是有用的，另外 20% 会被我忽略，但仅凭这 80% 依然可以取得相当大的进展。例如：我们的模型选择器是否只显示模型名称和倍率，还是提供了用户真正想了解的更多信息？

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

更广泛地说，这一切最终都会回到我们所说的“适合 AI 智能体的代码库评估”：你的代码库是否具备相应的结构、文档和测试覆盖率，让 AI 智能体能够有效地参与贡献？

我们确实非常好奇：你们团队采用的是怎样的方式？是否有我们遗漏的工作流？你们是否自动化了某些我们还没想到的事情？欢迎在 VS Code 仓库中向我们提交 issue，或者在 X 上联系我们——我们正在与你们共同构建这一切，而你们的反馈将影响我们接下来的方向。

Agent Sessions Day 上还有许多其他精彩的分享，如果你还没有看过，也请去看看。