不到一个月，微软连发两篇团队博客，主题一模一样：被 AI 淹了，快顶不住了。
8月中旬，Exchange 团队承认：AI 找 Bug 找得太猛，工程师全压在验证和修复上，答应了一整年的累积更新 CU1 无限期推迟。9月8日，Edge 团队接着承认：用 AI 写出来的浏览器扩展提交量暴涨，Add-ons 商店的审核周期被越拉越长。9月15日，这两件事被 CSDN 汇总成一篇稿子发出，36氪等科技媒体同日跟进——最大的 AI 编程布道者，这次先被 AI 堵了自家商店。36氪
我把两篇博客原文、同期报道和本周知乎上的几场争论一起翻完，先把事实摆清楚，再算真正关系到每个人的那部分：AI 让写代码变容易之后，收尾的活儿归谁。
第一件事：Exchange 不是没人写代码，是没人"验"得过来
先补一句背景：Exchange SE 是微软邮件服务器的订阅版，CU（累积更新）是把一段时间内的所有修复打包在一起的大版本更新，管理员装一次顶多次，所以不少人等着 CU1 一步到位。
微软最初的承诺是"2026 上半年结束前发布 CU1"；后来悄悄改成"2026 下半年"；到现在，官方博客里只剩一句话：会来，但没有日期可以给你。微软技术社区
延迟的理由，出自 Exchange 团队 8 月 13 日那篇《Where is Exchange SE CU1 anyway?》：过去几个月，微软多位高管公开介绍过用 AI 工具扫描产品漏洞的举措，这是全公司级别的行动，Exchange 团队也不例外。问题在于，AI 找到 Bug 只是开始，不是结束——每一个报告都得有人确认是不是真实安全问题、复现、修复、跑回归测试（确保修一个 Bug 不会顺手造出三个新的），再打包进每月的安全更新。
于是出现了很反常识的一幕：安全更新照常按月发（5、6、7、8 月一次没落下，官方博客原话是"安全优先于一切"），反倒是包含所有修复的 CU 大版本被堵死了。微软不敢发：CU1 刚落地紧接着又来紧急安全漏洞，管理员就得连续吃两个大更新，更新工作量直接翻倍。他们的计划是"等到足够稳定、并且碰上一个没有紧急安全更新的月份"再发——听上去稳妥，唯一的问题是：哪个月没有紧急安全更新？没人知道。
第二件事：Edge 商店被 AI"踩油门"挤爆
9 月 8 日，Edge 团队的博客画风几乎相同：AI 辅助编程普及之后，开发者能做扩展的速度比过去快太多了——以前写个插件要自己码代码、调 Bug、一点点迭代，现在让模型生成再改改就能提交。结果就是 Edge Add-ons 商店的提交量猛涨，微软自己承认，之前专门给"高质量高价值扩展"开的加速审核通道，已经顶不住压力，周转时间肉眼可见地变长。36氪
有意思的是微软给审核瓶颈开的药方：继续上 AI。把审核流程里可重复的验证检查自动化，人只处理"需要判断"的复杂案例，并且强调不降低标准、不减少检查项。
而生产侧有多猛，本周知乎上就有现场样本：一位开发者用 Edge 内置的 AI API 做了个视频翻译加网页摘要插件，帖子标题就叫"6 天从 0 到发布"。一个人 6 天做出一个插件是真的，但审核队列表明：插件做得越快，排队等着被看的那双人工眼就越不够用。知乎
两件事是同一条公式：瓶颈没消失，只是搬家了
把两个案例的链条并排放：
Exchange：AI 找漏洞 → 报告变多 → 工程师逐个确认、复现、修复、回归 → 每月安全更新不停插队 → 大版本卡死。
Edge：AI 写代码 → 提交变多 → 审核员逐个把关 → 审核积压 → 插件更新卡死。
同一个断点：AI 把生产环节的成本砍了一个量级，验证环节还是纯人力，于是瓶颈整体上移到了"验、审、收尾"这一层。过去程序员的烦恼是写不出来，现在变成了：一口气能生成 10 个插件，审核团队不能一口气看 10 个；AI 一批找出几十个疑似漏洞，安全工程师还得一个个确认复现。
这不是微软独有的体感，也不是2026年才出现的新病。"人审代码"这套质量体系，在纯人写代码的年代就有过积压曲线：维基百科引擎（MediaWiki）代码库2009—2010年那张著名的待审修订（unreviewed revisions）统计图，积压量一度冲到近三千条、几周才被清一波——进单速度快过人眼速度的形状，和今天一模一样，只是当年没有AI把流量放大一个量级。
本周讨论里被反复引用的 Stack Overflow 2025 开发者调查显示：84% 的专业开发者在用或计划用 AI 工具，微软和谷歌此前也披露过新代码中由 AI 撰写的比例达到两成以上。而 66% 的人对 AI 代码最大的抱怨是"几乎正确，但不完全正确"——产量按两成放大，"几乎正确"的坑也就按两成放大回来了。国内的参照是信通院 2025 年 3 月对 15 款主流国产代码大模型的安全基准测试：没有一款达到最高安全等级。生成侧在狂飙，验证侧的家底就这么厚。知乎知乎知乎
本周评论区的共识与分歧：两派其实没吵起来
微软这两篇博客，本质上是知乎这周两场争论的企业级版本。知乎
一边是"换审查对象"派。热帖《AI 写的代码还需要 Review 吗》吵了 52 条评论，高赞回答的态度很直接：现在的问题已经不是"要不要 Review"，而是"不借助 AI 就没办法 Review"——古法时代一个 PR 一百行，人逐行看成立；AI 时代一个 PR 几千行，人审代码这一层塌了，质量保障要转向验收标准和运行证据。 另一场讨论里也有人泼冷水：让 AI 来 review AI 写的代码，最好的 AI review 工具，采纳率也不到人类的三分之一。知乎知乎
另一边是"仍然逐行看"派。《你们 codereview 时，AI 生成的大 diff 是怎么看的》下面的实务经验同样有人气：动钱的、动权限的、动事务边界的，一行不放过，因为这类地方 AI 最爱一本正经地写出让资金重复扣的代码——编译器挑不出毛病，测试还可能恰好覆盖不到。知乎
两派看着对立，其实回答的是同一个问题的两半：一派管"量"，所以要让 AI 和自动化去扛重复检查——Edge 的对策一字不差就是这个思路；一派管"险"，所以高风险点必须留人——Exchange 宁可压着 CU 不发也不肯放松回归测试，同样是这个逻辑。知乎上关于"Vibe-Coding 是不是让开发更累"的讨论里有一张四象限散点图把这笔账画得很直白：早期尝鲜的小团队落在"低组织瓶颈、低焦虑"区，而一旦进入大规模普及——DORA 2024 均值、Faros 样本均值、Klarna 案例——整体漂移到"高瓶颈、高焦虑"区。写代码的速度是 AI 给的，验证的瓶颈和焦虑，是自己的。知乎
微软的"自曝"，只是把每个认真用 AI 写代码的人每天在做的小心翼翼，第一次用官方博客的形式承认了。
现在用 AI 写代码的人，先把这三本账算完
第一本账，给自己的流程：补"人肉关卡"的位置。不用删 AI 环节，只加一步分流：拿到 AI 的产出先问三个问题——动没动钱、动没动权限、动没动对外接口。有，人逐行看；没有，看骨架和边界条件，中间实现扫一眼。Exchange 那篇博客的潜台词是：AI 产出的量不是免费的，验证成本只是延期支付了。
第二本账，给推工具进团队的人：效率要算总账。别只统计"写代码的时间省了多少"，同步看三个数：PR 合并时长、回滚次数、回归 Bug 数。如果这三个数没变好，省下的写作时间只是搬进了审核和修复的队列——这正好是 66% 那个数字的团队版本。
第三本账，看你站在哪一侧。
企业 IT、尤其还等着 Exchange SE CU1 一步到位的管理员：结论很直接，别等大包，跟住每月的安全更新就行，官方"没有日期"四个字已经说透了。微软技术社区
爱装浏览器扩展的普通用户：审核积压意味着商店里"还没被人看过"的新插件平均变多了。装之前多看三样：申请的权限（一个文本工具要读你所有网站数据，直接走）、作者主页和更新历史、发布时间是不是刚冒出来的批量新品。AI 插件洪峰摊薄的，恰恰是存量老插件攒下来的信任。
接下来盯三个信号
Exchange CU1 到底哪个月落地。官方条件是"等一个没有紧急安全更新的月份"——盯每月 Patch Tuesday 里 Exchange 高危项的密度，密度降不下来，CU1 就出不来，也就说明 AI 找漏洞这台发动机没打算熄火。
Edge 的"AI 审核"会不会放水换周转。博客承诺了不降标准，但验证办法是商店侧的质量投诉——投诉涨起来，就说明自动化替掉了不该替的人工线。
会不会有第三篇、第四篇"自曝"。Exchange 和 Edge 只是最早开口说话的两个团队，AI 扫描是全公司行动。接下来一个季度，其他产品团队跟进承认验证压力的概率不低——真出现了，别意外，验证层从来是投入最少的那一层。
回到 Exchange 博客的原话：“In short: Exchange SE CU1 is coming; we do not have a date to give you.”——会来，但没有日期。这句话放在 AI 编码的当下同样成立：效率是确定会来的，但"不用人看也能放心合并"的那一天，目前没有日期。在那之前，你逐行看过的那几行，就是全部的安全感。
