微软VS Code团队十年磨一剑，AI助力实现每周发布

微软VS Code团队利用AI技术，成功从十年月度发布转向每周发布。AI赋能产品经理直接定义和原型化功能，模糊了产品与开发角色界限。这显著提升了开发效率、提交速度，并改善了产品质量，减少了回归。团队认为，构建“代理就绪的代码库”是当前工程团队最重要的元技能，预示着未来开发流程的深刻变革。

今年早些时候，Microsoft 的 VS Code 和 GitHub Copilot 产品负责人 Pierce Boggan，悄然向产品管理界抛出了一个重磅消息：他的团队正在构建工具，让产品经理们（而非工程师）能够使用 AI 代理来定义、原型化和评估面向用户的功能。他在 1 月 9 日的 LinkedIn 帖子中写道：“真正的力量在于这如何改变了产品经理的工作流程”，他描述了一个循环：产品经理定义一个场景，交给 GitHub Copilot 实现，然后自行托管构建几天，并迭代直到原型可以投入生产。

反响迅速而尖锐。一些人充满热情。事实上，一位微软的同事产品经理称这是一种拥有“超能力”的感觉。另一些人则提出了异议。前微软工程师 Alnur Ismail 写道：“我认为你们的方向错了。你们的工程师才应该使用这个工具。他们了解代码库，所以这里的优势是帮助他们更接近客户。”

两个月后，《The New Stack》采访了 Boggan，了解这个实验在实践中是如何进行的。他的回答坦诚、具体，有时还令人惊讶——谈到了 AI 如何打破了长达十年的发布周期、一个由产品经理编写并已发布给数千万用户的 PR，以及为什么他认为“代理就绪的代码库”是每个工程团队现在都需要掌握的元技能。

本次采访经过编辑，以提高清晰度和简洁性。

VS Code 团队目前正在使用哪些特定的 AI 工具、模型或内部代理来协助产品经理和工程师的日常工作？

Pierce Boggan: VS Code 团队的核心原则一直是“我们用 VS Code 来构建 VS Code”。现在对于 AI 也是如此——作为一名产品经理，我总是尝试使用 VS Code 和 GitHub Copilot 进行自托管。VS Code 是最大的开源仓库之一，每周向数千万用户发布稳定版本。

我的早晨从一个提示文件开始，它使用 Work IQ 调取我的日历、电子邮件和 Teams 消息，并使用 GitHub MCP 获取有关产品和工程更新的相关上下文。我依赖这个提示文件来总结过去 24 小时内 VS Code 中的所有新内容。

我们大部分核心的产品经理工作流程也都在 VS Code 和 Copilot 中运行——专用提示来分析我们的反馈仓库，专门构建的 Web 应用来分析社交媒体，以及由 AI 驱动的自动化来保持文档和发布说明的最新状态。

在工程方面，VS Code 首席软件工程经理 Peng Lyu 和其他同事构建了针对他们工作流程的自定义代理和斜杠命令——总结过去 24 小时的提交，无需离开 VS Code 即可整理和去重问题。我们对每个 PR 都使用 Copilot Code Review 作为人工审查前的强制性第一遍。团队还构建了一个名为“demonstrate”的自定义代理，它允许 GitHub Copilot 通过实际启动 VS Code、导航到某个功能、截取屏幕截图并评估更改是否按预期工作来进行自我验证。

在模型方面，我们有自己的内部基准测试——vsc-bench——用于评估不同模型在 VS Code 框架中的表现。对于提交摘要，我们使用速度更快的模型。对于代码生成或审查，我们将使用功能最强大的模型。有时我们会并行生成多个子代理模型，并让它们相互评分。

工具发展迅速，所以我们今天使用的可能与一个月后使用的不同——这就是重点所在！

您能详细说明如何为 PR 制作原型解决方案吗？

对我来说，这种转变是根本性的：规范或 PRD 的等效物现在是一个原型，而这个原型就是一个 PR。

有人向我们提供反馈——无论是在 X、Reddit、GitHub 问题，还是其他任何地方——我不再写一份关于我们认为体验应该如何的文档，而是打开 VS Code 中的计划模式，开始构建它。规范在我使用产品时变得更加清晰，而不仅仅是写下来。

例如，在我们的 代理会话日 录制前一天，我提交了一个 PR，用于在 Copilot Chat 中分叉对话。我们的一位工程师给了我反馈，我们一起解决了几个 CSS 更改，然后合并了它。现在它已经在 VS Code 中了。

这最适用于 UI 和交互级别的更改——那些“这是否正确？”的问题真正关乎体验，而非深层的架构决策。但我需要明确一点：工程师仍然对代码质量和架构负责。如果 Peng 看到我的 PR 并说“这架构不对”，那完全没问题——我乐意我的代码被废弃并重新构建。

真正发生的是角色界限正在瓦解。我一直有产品思维，但受限于构建技能——现在这不再是瓶颈。

团队正在跟踪哪些具体指标来量化 AI 采用的直接影响？

最具体的证据之一，对每个 VS Code 用户都可见：在经历了十年的每月发布后，我们转向了每周发布。发布周期的开销——分类、测试、发布说明、稳定化——过去需要整整一个月的节奏。现在，其中足够多的部分实现了自动化或由代理辅助，使我们能够维持每周发布，并仍然保持质量。

提交速度出现了真实而持续的增长——以前你 git fetch 时会有 20 或 30 次提交。现在每天通常超过 100 次。PR 周期时间也已缩短。我们基于代理的分类管道处理了初步排序、重复检测和所有者分配，而这些过去每周都需要专人轮班处理。

在质量方面，我们密切关注回归率，因为如果不小心，速度可能会带来问题。我们最关心的指标是：“我们发布到稳定版的回归数量是否比以前少了？”到目前为止，答案是肯定的——但这需要持续的关注。

随着 AI 工具更深入地融入开发过程，团队如何设想未来一两年内角色的演变？

“思考产品的人”与“构建产品的人”之间的界限正在真正模糊。每个人都在成为对结果贡献更多的全栈贡献者。

在工程方面，当代理可以帮助任何人贡献任何组件时，传统的“这是我的领域，请勿介入”模式就不再成立。你需要安全机制——测试、文档、清晰的所有权界限——不是为了将人们排除在外，而是为了安全地欢迎他们加入。

工作中机械的部分——编写样板代码、处理例行问题、在审查中发现常见错误——正越来越多地由代理处理。更有价值的是品味、判断力，以及评估某个东西是否真正令用户愉悦的能力。投资于使其代码库“代理就绪”的团队将看到复合回报。这是每个工程团队现在都需要培养的元技能。