VS Code 团队用 AI 实现周更，十年月更终结

今年初，微软 VS Code 和 GitHub Copilot 的产品负责人 Pierce Boggan 在 LinkedIn 上透露，他的团队正在开发一套工具，让产品经理（而非工程师）能用智能体（AI Agents）定义、原型化和评估面向用户的功能。他在 1 月 9 日的帖子中写道：“真正的威力在于这如何改变产品经理的工作流。”他描述了一个循环：产品经理定义场景，交给 GitHub Copilot 实现，自托管构建数天，迭代直到原型达到生产就绪状态。

反应迅速而尖锐。有人热情支持，一位微软同事称这感觉像拥有“超能力”。也有人反对，前微软工程师 Alnur Ismail 写道：“我认为你需要反其道而行。你的工程师才应该使用这个工具。他们了解代码库，所以这里的杠杆作用是帮助他们更接近客户。”

两个月后，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 执行框架（Harness）中的表现。对于提交总结，我们使用更快的模型。对于代码生成或审查，我们使用可用的最强大模型。有时我们并行生成多个模型的子智能体，让它们互相评分。

工具演进很快，我们今天使用的可能下个月就不同了——而这正是关键！

如何用 AI 原型化 PR 解决方案？

对我来说，转变是根本性的：规格说明或产品需求文档（PRD）的等价物现在是原型，而原型就是 PR。

有人给我们反馈——在 X、Reddit、GitHub 问题等地方——我不是写文档描述体验应该怎样，而是打开 VS Code 的 plan 模式开始构建。规格在使用产品中变得清晰，而不仅仅是写出来。

例如，在我们 Agent Sessions Day 录制前一天，我提交了一个关于在 Copilot Chat 中分叉对话的 PR。一位工程师给了我反馈，我们一起处理了几个 CSS 更改，然后合并了。现在这已在 VS Code 中。

这种方法最适合 UI 和交互层面的更改——那些“这正确吗？”的问题真正关乎体验，而非深层架构决策。但我想明确：工程师仍对代码质量和架构负责。如果 Peng 看我的 PR 说“这架构不对”，那完全合理——我不介意我的代码被丢弃重建。

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

团队如何量化 AI 采用的影响？

最具体的证明点对每个 VS Code 用户可见：在十年月更后，我们转向了周更。发布周期的开销——分类、测试、发布说明、稳定化——过去需要整整一个月的节奏。现在，足够多的部分被自动化或智能体辅助，我们能维持周更节奏并保持质量。

提交速度有真实且持续的增长——过去 git fetch 时是 20 或 30 次提交，现在每天经常 100+。PR 周期时间压缩了。我们的基于智能体的分类管道处理初始排序、重复检测和负责人分配，这些过去每周需要专人轮值。

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

团队如何看待未来一两年角色演变？

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

在工程方面，当智能体能帮助任何人贡献到任何组件时，传统的“这是我的领域，别碰”模式不再成立。你需要执行框架（Harness）——测试、文档、清晰的拥有权边界——不是为了把人挡在外面，而是为了安全地欢迎他们进来。

工作的机械部分——写样板代码、分类常规问题、在审查中捕捉常见错误——越来越多由智能体处理。变得更有价值的是品味、判断力，以及评估某物是否真正让使用者愉悦的能力。投资让代码库智能体就绪的团队将看到复合回报。这是每个工程团队当前需要发展的元技能。