AI 写代码有多快，微软的工程师现在最有发言权。但这份发言不是炫耀，是诉苦。不到一个月，微软两个团队先后承认：AI 把上游效率拉起来了，下游却被堵死了。

第一次自曝：Bug 找到了，但修不完

打开网易新闻 查看精彩图片

8 月 13 日，Exchange 团队出面解释 Exchange SE 累积更新 CU1 为什么迟迟不发。原因听起来有点反直觉：AI 工具找到了大量 Bug。

问题出在找到之后。每个 Bug 都需要工程师确认、复现、修复、回归测试，再打包发布。与此同时，每月的安全更新还在不断插队。微软宁愿等一个没有紧急安全更新的稳定窗口，因此 CU1 的具体日期一直给不出来。

换句话说，AI 让"发现问题"这一步变得极其廉价，但"解决问题"这一步的成本一分没降。

第二次自曝：插件提交量猛涨，审核扛不住

9 月 8 日，Edge 团队承认了另一件事。AI 辅助编程让开发者更快构建浏览器扩展，提交量随之猛涨，人工审核流水线不堪重负，审核周期变长。

值得注意的是提交量的来源：开发者借助 AI，能更快构建大量以前根本不会尝试的小工具。以前嫌麻烦不做的，现在顺手就做了——于是全涌进了审核队列。

微软的应对不是单纯扩大人工规模，而是继续给审核流程加 AI：让自动化处理可重复的验证检查，人类专注复杂判断。团队强调不降低审核标准，只是让 AI 负责有标准答案的部分。

瓶颈换了位置，但没有消失

把两件事放在一起看，规律很清楚：AI 把上游生产效率拉起来了，下游没有同步提速。

当代码生成从"一个程序员一天写多少"变成"一个 Agent 几个小时能写多少"，问题就变成了另一串：

  • 谁来测
  • 谁来修
  • 谁来审
  • 谁来验证
  • 出问题谁负责

开发者可以一口气生成 10 个插件，审核团队却不能一口气审核 10 个插件。AI 可以一次找到一批漏洞，但安全工程师还是得一个个确认、复现、修复。

这也是两次自曝里最扎心的一点：AI 编码不等于代码安全。写代码变容易，和代码变安全，是两码事。审核、验证这些后续工作，目前 AI 没办法自动消除。

下游拥堵，才是真瓶颈

过去谈 AI 编程，焦点几乎都在"能不能写出来"。微软这两次表态把镜头挪到了后面：写出来之后的那条流水线，才是决定交付速度的地方。

Exchange 卡在稳定窗口，Edge 卡在审核周转，两个团队的位置不同，卡点却指向同一处——AI 放大的产出，最终都要由人来接住。