VS Code 如何靠 AI 从月更变成周更——Harald Kirschner(Microsoft)

• 讲者身份：Harald Kirschner，微软 VS Code 团队的 Principal Product Manager（首席产品经理）。注意他是产品经理、不是工程负责人，后面好几处都是以「我作为一个 PM」的身份讲自己写代码、提 PR。他说这场是前一天楼上那场的重讲（字幕此处听不清，按上下文理解）。→ 详细
• 定题：别人都在讲怎么把 agent 做进产品，这场讲用 agent 做产品本身（VS Code，以及按上下文推断的 Copilot CLI 等），外加 agent 真管用之后哪些东西会坏、得怎么重想干活方式。幻灯片标题页上的现场原题是「Agents All the Way Down — How the VS Code team builds with what it ships」，与 YouTube 片名不同。→ 详细
• 规模与口径：口述是「一支非常小的团队，面对超过 5000 万用户」，幻灯片上写着约 40 人。画面外框标着 2026 年 7 月 1 日、PRESENTED BY Microsoft；下文数字都是讲者口述或幻灯片所写的自家数据。→ 详细

▲ 幻灯片 03/28：三张数字卡——GPT-4.1 约一年前 55%、Claude Opus 4.6 今天 86%、+31 pts。是数字卡，不是曲线。

• 指标定义：code survival（代码存活率）指 agent 写的代码里最后真正被提交进去的比例；反过来看，就是 agent 产出了多少被你转手扔掉、信不过、撤回废掉的垃圾。团队很早就在 VS Code 里追踪它。→ 详细
• 数字：GPT-4.1 起步时 55%，如今 Claude Opus 4.6 是 86%。他归因于 harness（套在模型外面的那层工具与流程）改进加上新模型，并说这说明开发者更敢、更快地发 AI 写的代码。幻灯片这页是三张数字卡而不是曲线，第三张写「+31 pts · DEVELOPER TRUST」，底下强调是体系在变好、不只是模型。→ 详细

▲ 幻灯片 04/28：自一月以来 open issues +3.4K、open PRs +850，月更十年后于 Feb 2026 改为周更；前两个数和这个时间点口述都没说。

• 积压与改节奏：VS Code 是 GitHub 上最大的开源项目之一。AI 帮人提 issue，高质量的和自动生成的低质量的都变多；没合的 PR 也变多（团队提速加社区），但社区 PR 的合并数同样在涨，并非都是垃圾。于是从 1.0 起坚持了 10 年的月更（冷知识：「一月版」其实二月才发，只是记账方式）在「几个月前」改成周更。幻灯片上写着口述没报的三样：自一月以来 open issues +3.4K、open PRs +850，改周更的时间点是 Feb 2026，并配一句「节奏必须匹配速度」。→ 详细
• 核心论点：重点不是让每个人日常多用 AI、去 tokenmaxxing（刷 token 用量）——很多公司在推这个；而是让发布软件的整套体系进化，速度才跑得起来，不只是多产出代码。幻灯片的说法：采用 AI 是容易的部分，在自己的速度下活下来才是正事。→ 详细
• 三段框架：① 发得更快——容易的部分，总有位「100 倍工程师」搭好 skill、MCP、插件体系狂发代码，团队慢慢跟上；② 守住质量——发快了就撞上代码评审，且 VS Code 是把二进制装到用户机器上，出问题恢复更贵；③ 学得更快——怎么知道发的是对的、该不该发，他说很多人代码越写越多，恰恰漏了把产品品味用上去。幻灯片管这叫「loop engineering，不只是 harness engineering」：好 harness 只磨利一步，每一步外面的回路都得闭上，解决一个就露出下一个。（Uber 的 agent 化开发流程见 ep195；同批 267 从卖工具的一方讲同一处境。）→ 详细

• AGENTS.md 是活文档：他说这页「不用动脑子」、大家早该在做：给 agent 一份够轻量的代码库地图，告诉它去哪儿找东西。每个 agent 都有 /init 命令能出初稿，之后不断迭代——「这些是活的文档，应该随着 agent 犯错、随着 agent 干活而不断演进」。在开发者体验上下过功夫的团队收获最大，因为给人写的文档和上手指引，agent 同样会读。幻灯片标题：agent-ready 是一套活的系统，不是一次性的设置步骤。→ 详细
• 把专家写成 skill：VS Code 一直重投入无障碍（accessibility，让视障等用户也能用好产品）。很早加的一个 skill，就是把全部无障碍最佳实践、连同团队思考无障碍的方式灌进去，人人都会用。以前这事卡在一个人身上，得拉他进来或等他反馈；现在这个 skill 由无障碍领域的负责人评审并维护。幻灯片上还有口述没提的两点：性能专家也这样做成了 skill，上个月新增约一打；并称之为「会复利、而不是成瓶颈的判断力」。→ 详细
• 他留给听众的问题：想一想，你能把哪些专家知识编码成 skill，好给那少数几个总被人追着要意见的人松绑。→ 详细
• 试金石：「我作为一个 PM，能不能在 VS Code 的仓库里有效地 vibe code？」他说自己确实在这么干。紧跟着四个追问：工程团队接不接受、要花掉多少功夫、是不是开箱即用、是只在我本地能跑还是发出去迟早出问题。幻灯片的版本是：一个非工程师能从 agent 那里拿到像样的 PR，代码库质量才是真的，这个装不出来。→ 详细

▲ 幻灯片 09/28：8 分钟的构建、每个会话 20 次、160 分钟的阻塞，脚注写 TS-Go 构建快 10 倍；这笔账只在幻灯片上。

• 为什么慢会复利：构建、lint、CI/CD（代码一提交就自动构建测试的流水线）慢，对人只是烦，人会趁它跑着去评审 PR、干别的；可 10 个、20 个 agent 同时跑、撞同一个瓶颈时，任何一处慢都会层层叠加，而 agent 恰恰靠这条循环拿反馈改代码。切到 TypeScript Go 后构建有 10 倍提升，他称这是非常大的一项改进。→ 详细
• 幻灯片上那笔口述没算的账：8 分钟的构建以前不碍事，开发者会切上下文、倒杯咖啡再回来；agent 不切上下文，一个会话跑 20 次构建，于是「那点烦人变成了 160 分钟的阻塞」。页眉是「每一处让开发者烦的地方，都是 agent 的一堵墙」，脚注说 TS-Go 对 agent 的收益比对人更大。→ 详细

• 来龙去脉：能在仓库里 vibe code 的直接后果，是他自己开始提大 PR。今年年初，他认定产品确实需要 ask questions 工具，就自己做了一个「非常粗糙」的 PR，带给团队，让大家直接在产品里试。几周之内，团队在这个粗糙版本上做出了打磨到位、设计完整的体验。→ 详细
• 他点明的真正作用：价值不在那份代码，而在打开了局面——地基铺好了，想法和体验都摆在眼前，讨论才展得开，其他所有人才参与得进来。→ 详细
• 幻灯片上的 PR 截图：页眉是「PM as builder — the surfaces opened up」；PR 为 microsoft/vscode-copilot-chat 的 #2937「feat: add AskQuestions tool for agent clarifications」，1 月 16 日合并，提交人 digitarald 即讲者本人；摘要写的用途是让 agent 在做有风险或含糊的决定之前，先向用户要澄清。→ 详细

▲ 现场打开的 PR #310881：机器人评论里列着 Changed (33)，按组件路径逐个排出 Before / After 截图，深色、浅色各一组。

• 痛点与主张：agent 做完 UI 说「看起来很完美」，一打开全是错位，用 SVG、用最新模型都一样。他说这是近来逢人就讲的头号大事：让 agent 能直接操作你的产品、拿到「到底能不能用」的反馈，是每次做 UI 都能回本的大投入。→ 详细
• 组件截图对比（他叫 component browser，也叫 component explorer，同一个东西）：每次 VS Code 有改动就跑一遍的自动化构建，给每个组件截图并标出差异。现场例子是给 AI 自定义设置界面加返回按钮的那个 PR。用处有二：抓连锁反应，比如只改一个组件、别处却挪了位置或少了图标；让评审一眼看到 PR 干了什么——以前靠要求开发者附视频或截图，现在自动完成。→ 详细
• 自纠正循环：VS Code 说到底是跑在 Electron 里的网页，能用 Playwright（浏览器自动化工具）驱动。他们做了个 /launch skill：打开 VS Code，按给定场景一路点过去，沿途拿日志，修复前后各验一遍；人敲完 launch 就去做下一件事，等 agent 验证跑通再回来。幻灯片上还写着：这套对没法自己构建的社区 PR 也管用。→ 详细
• 不是 web 应用也有路：他最喜欢的例子是 Xcode MCP——业余做 iOS 应用时，看着它在 VS Code 里不碰 Xcode 就把应用做出来、打开、点一遍、截图；Android 那边也有对应工具。→ 详细

▲ 幻灯片 12/28：从「太吵、被工程师无视」到「mandatory on every PR」的三句话；底部一行是 71%、>1 in 5、12,000+ 三个数，贴着窗口底边。

• 从不信到强制：他把代码评审称作下一个重点投入。早先在 GitHub 上启用 Copilot 自动评审时，团队「还没被说服」；之后几个月它大幅改进，如今只要有人开 PR 就必须过一遍。幻灯片压成三句：六个月前 AI 评审太吵，工程师直接无视；后来信噪比跨过一道阈值；现在每个 PR 强制。→ 详细
• 真正起作用的那条规矩：「评审跑完之后，在所有评论都被处理、解决掉之前，人根本不会去看这个 PR。」人的注意力排在机器评审之后，评审就从靠人自觉变成流水线上的卡点；页眉写的正是「代码评审是质量闸门，不是瓶颈」。（主张干掉代码评审的另一派见 ep188。）→ 详细
• 力度可调：后续改进是按仓库风险把评审力度调成低、中、高三档，成本与收益自己拿捏。→ 详细
• 幻灯片上有、口述没说的三个数：「71% ｜ surface actionable feedback」「>1 in 5 ｜ code reviews on GitHub」「12,000+ ｜ orgs auto-run it on」。这一行贴着窗口底边，标签可能被截掉后半句，这里只照录原文，不替它补主语。→ 详细

• 为什么要分诊：issue 是量很大、质量也很好的信号。有了 AI，不同语言背景的人也能提出很好的 issue，但数量确实太多；以前靠工程师手动分诊（triage，给新进来的问题筛选、去重、派人）。→ 详细
• 三层流水线：现在由 AI 筛掉垃圾、补充信息并翻译、最后给每个 issue 分配领域负责人（area owner），把信噪比提上去。幻灯片写得更细：每天数百个 issue、跨 20 多个仓库，跑在 GitHub Actions 上；Filter 筛垃圾、重复、meta-issue 和 prompt injection（藏在文本里骗 agent 的指令）；Enrich 翻译、索要复现步骤、语义去重；Assign 依据 git 历史加声明的归属。→ 详细
• 人工反馈层：「agent 会犯错，而它犯错的时候我们需要那个反馈循环。」他们做了一个 Chrome 扩展，人进到 issue 里就能修正重复判定，纠正结果再带回前面 agent 的工作里。他特意强调：让 agent 干活时，怎么拿到人的反馈是必须想清楚的事。→ 详细
• 幻灯片补充：页眉是「扩展而不是替换——一个我们希望 GitHub 自带的功能」；扩展把疑似重复按 certain / uncertain 两档列出，并给出标签与指派人建议；还有一句口述没说的话：在监控分诊质量上的投入，比搭建它本身更多。→ 详细

▲ 幻灯片 17/28 的五层漏斗：18–51B events/day → 53–127M → 18–34K → ~300 → ~10 issues filed；口述只说了 510 亿和 10 个 issue。

• 错误漏斗：每次异常上报一条错误栈（error stack，出错那一刻的调用路径）；数据和工具全是自家的、大多早就有，原先靠一层 ML 排序。现在是采集原始遥测、只留带完整调用栈的、分组归桶（打指纹），最后提出 10 个 issue 分给领域负责人，并自动开 PR 先试着修。幻灯片上五层都是区间：每天 180 亿到 510 亿条事件（口述取了上限 510 亿）→ 5300 万到 1.27 亿条错误 → 1.8 万到 3.4 万个桶 → 约 300 个过阈值 → 约 10 个 issue（各层下限画面略糊）；一天跑很多次，由 Copilot SDK 加 vscode-errors MCP server 驱动，阈值还在调。→ 详细
• 现场例子与分工：错误页面列着每条错误栈的命中次数和受影响用户数。演示的 issue 自动建好并附初步诊断，agent 查清原因和引入者（口述：一次与 find symbols 相关的改动，「on cancellation request 没有在 RPC 协议里」）并开好 PR，「我们直接合并就行」。整条链路是 agent 加确定性系统（按写死规则跑的程序）分诊、多 agent 系统修、人只批准 PR；他的说法是你不想操心这些错误，只想要更稳定的代码库。幻灯片上写着口述没说的：起点只有一条 stack trace，bug 横跨两个进程；修复 PR #319018 标的模型是 claude-opus-4.6，由人（@roblourens）评审批准；约 40 人对几千万用户，长尾 bug 修不过来，所以让 agent 做第一遍。→ 详细
• 分阶段发布：以前是 YOLO 式，发布日测完直接推给 100% 用户；有了 agent 要降风险（他承认「大概早就该这么做了」），改成分阶段放量（staged rollout），边放边盯错误日志和 issue——装在用户机器上的应用回滚太贵。幻灯片上写着：有个构建放到 8% 时因检测到问题被冻结；自动化了什么就监控什么（代码、分诊、发布说明），「回归率是北极星」，没有护栏的话头两周感觉很好、之后回归累积；要像运营服务那样运营 agent（SLO、看板、告警）。（上生产之后的排障，同批 268 专讲。）→ 详细

▲ 幻灯片 23/28「Same 5-character file. Up to 70× the tokens.」：从 Ideal floor 到红色 Worst case 的五根横条；条末小数值看不清，不引用。

• 自家 eval 怎么养：做的是 agentic 产品，手边就得随时有针对自家产品的 eval（评测集），还要极易扩展。全在 GitHub 上：提个 issue 说要加新场景，agent 接手、按模板搭好，issue 和客户交流里冒出来的开发者场景就都能回流进去。然后对着它做 hill climbing（盯着分数一点点往上优化），先线下确认变好，再做线上实验。幻灯片补了判定规则：公开基准不够用，所以每天跑自己的；每次 harness 改动同时看任务成功率和 token 成本，任一回归就否决，靠数据而不是 vibes；线上部分是生产环境里的 A/B prompt 实验。→ 详细
• 70 倍的教训：为了把 eval harness 端到端测一遍、顺带看各模型的反应，他们用了一个极简场景：写一个文件（口述先说内容是 hello world，随后与幻灯片都称「5 个字符的文件」）。最贵的那个模型多花了 70 倍 token，而且不是高推理档；他们没点名模型。幻灯片注释行写着 50,974 次运行、30 个模型、6 个月（后两项字很小，略存疑），结论是输出同样正确，差距在 effort calibration（模型对该花多大力气的拿捏），会体现在账单上，模型大小预测不了。他的落点：「理解你自己的 eval 至关重要」。→ 详细

• 为什么不落 PR：他原型做得很多，因为发现自己「其实并不想把大部分工作都落成 VS Code 本身的 PR」。PR 适合开启一场讨论，但他更常要的是一次很快的讨论。团队现在每天碰头：「想法是这样的，它大概可以长成这样，要是我们这么做呢」，第二天带着更新过的原型回来接着聊。反馈周期从按月、到每周、再到每日冲刺；原型的作用是打开更深的讨论，把体验到底该长什么样聊清楚。→ 详细
• 幻灯片上的说法与例子（口述没讲）：「The prototype IS the spec」——别去描述它该是什么感觉，做出来，再问一句「这感觉对吗」。例子是 Agent Permissions 功能：2 到 3 个月的设计压到 2 周，流程是 Signal → Analysis → Prototype → Team Reaction → Iterate 再绕回起点；原型挂在 GitHub Page 上，agent 在内置浏览器里对照 spec 审设计、再迭代。→ 详细
• 组织跟着变：口述只有一句：每日冲刺、更小的小队、更小的工作流，各自排优先级、推更小的一组领域，并提到 durable ownership（持久的归属，转写存疑）。幻灯片标题却是「Durable ownership → ephemeral workstreams」，即从长期领域转向临时工作流，两边不完全一致，照录。旧模式：钉死的月度计划、长期领域（workbench、chat、agents、MCP）、收尾周统一对账、没人说得出三个月后发什么。新模式：2 到 3 人的临时小队、各有一名 DRI（直接负责人）、按优先级组建和解散、早上说意图下午做回顾、每日会议只做决定不报进度。自评：两个月下来敏捷得多，但也带来了它自己的问题。→ 详细

• 口述的结论：去试这些做法，找出你的瓶颈——发得质量更高、更快、学得更快——然后找到并解决下一个。别只调你和 agent 的协作方式，还要调它们在哪里、怎么拿到反馈，这些回路怎么搭；每次成功之后，再问下一个卡住你的是什么。这是贯穿所有环节、不断迭代的循环。→ 详细
• 幻灯片上的三条原句：① 瓶颈一直在移动，旧的也不会消失——写代码、安全地发布、知道发的是对的东西，三者叠加；② 别只调 harness，要把回路闭上——这里每一次赢都是一个端到端闭环（一个 eval、一道护栏、可观测性），不是换个模型；③ 成功才是考验——问一句「成功之后会发生什么」，找到你最长的那条反馈回路，那就是杠杆最高的 agent。结束页写着「Build agents for your team, not just your users.」（相关：ep192 讲编码 agent 不会自己规模化，ep247 / ep249 讲 Warp 的软件工厂。）→ 详细

讲者只留了一句「欢迎来 VS Code 展位找我」，没有给个人联系方式。→ 详细 幻灯片上能核对到的线索有两条：PR 截图里他的 GitHub 账号是 digitarald；70 倍 token 那页注明出处是 VS Code 博客 2026 年 6 月的文章「What 50,000 Runs Taught Us」。