一个反直觉的数字

贝恩公司十月份发了份报告，调查了近三百个高级技术负责人。结论挺有意思：AI编程工具让开发者多完成了21%的任务，但审核这些代码的时间增加了91%。

21%对91%。写的那头快了，看的那头慢了。而且不是慢一点，是几乎翻了倍。

我一开始看到这个数字觉得夸张。后来翻了翻LinearB的数据——他们分析了810万个PR、4800支团队——发现高AI采纳团队的代码评审时间确实延长了4.6倍。PR合并量涨了98%，评审耗时涨91%。产出翻了一番，审查的时间也翻了一番。

这两组数据放在一起，讲的是一个故事：瓶颈挪地方了。

写码9.8小时，审码11.4小时

Keyhole Software做了个更细的拆解。他们发现，在使用AI编码工具的团队里，开发者平均写代码花9.8小时，审代码花11.4小时。

审比写还多。

这个反转挺说明问题的。两年前可不是这样——那时候写代码是大头，review是配角。现在AI把"写"这件事变便宜了，但"看"这件事一点没便宜。每一行AI生成的代码，还是得人一行行看。不但要看逻辑对不对，还得猜AI是不是在自信地胡说八道。

Faros AI的数据更直接：他们追踪了2.2万名开发者，发现PR Review的中位耗时接近原来的5倍。注意，这不是最慢的那批，是中位数。也就是说，一般团队的代码审查时间已经膨胀到了以前的五倍。

主观觉得快了，客观其实慢了

有个实验挺有意思。METR——一个专门研究AI安全的研究机构——去年做过一次对照实验：让一批有经验的开发者分别在"有AI"和"没AI"两种条件下完成同样的任务。

结果呢？所有参与者都觉得自己变快了。但计时数据显示，整体感觉得快，整体进度反而慢了。生成那一段确实快了，慢的是后面排查漏洞、等待工具回应、反复修正的部分。

到了第二年，他们想复刻这个实验，没做成。不是方法有问题，是找不到愿意参加"必须脱离AI工作"对照组的开发者了。

这个细节比任何数据都说明问题。我们已经离不开AI写代码了，哪怕它可能并没有让我们真的变快。

产出涨了，交付没动

还有一项覆盖700多家软件公司、跨度五年的研究。结论很直白：用了AI编码助手之后，代码行数增加约30%，提交数增加约20%，PR增加约23%。但实际软件产出——也就是真正上线、真正被用户用到的功能——并没有同步增长。

与此同时，代码审查耗时增加约50%，参与审查的人数增加约14%。

产出量涨了，审查量涨了，参与的人多了。但交付没动。

这说明什么？说明"写代码"这件事在整个软件交付链条里，可能本来就不是最大的瓶颈。AI把最便宜的那个环节加速了，但真正花时间的地方——理解需求、设计方案、审查代码、测试验证、部署上线——一个都没被加速。

就像一条流水线，你给第一道工序装了台十倍速的机器，但第二道工序还是老速度。结果就是半成品在工序之间堆起来了。

我们团队踩过的坑

说实话，这事我们自己就经历过。

去年底团队开始大规模用AI编码工具。头两个月，，体感非常好。PR数量明显上来了，以前一个功能要写三天的，现在一天就出了初版。我当时还挺高兴，觉得效能终于提上来了。

第三个月开始不对劲。PR堆积速度明显加快，但review跟不上。以前每个PR半天内能审完，现在经常挂两三天没人看。不是大家偷懒——是代码量真的多了，而审代码的人还是那几个，时间还是那些。

更麻烦的是质量。AI写的代码初看很漂亮，结构清晰，命名规范。但细看经常有微妙的问题：边界条件没处理、并发场景没考虑、某个依赖的API已经废弃了。这些问题在review的时候才能发现，而review恰恰是最耗时的环节。

有个细节我记得很清楚。有次审一个PR，AI生成了一个数据处理模块，代码写得很优雅，用了最新的模式。但我花了四十分钟才搞清楚，它在处理空数组的时候会静默返回undefined，而不是抛异常。这个bug在单元测试里没暴露——因为AI写的测试用例也没覆盖空数组的场景。

最后那个PR审了两个小时。以前这种模块，自己写的话半小时就搞定了。

瓶颈从"写"挪到了"信"

贝恩那个报告的作者说了句话，我觉得挺到位："瓶颈已经从编写代码转移到了信任代码。"

信任这个词用得好。

你自己写的代码，你知道它怎么回事，你信任它。AI写的代码，你得先读懂它，然后才能信任它。读懂别人写的代码本来就比读懂自己写的费劲——何况这个"别人"还不是人。

这就引出一个尴尬的问题：如果审代码比写代码还慢，那AI帮我们省下来的时间，到底去哪了？

我目前的观察是：省下来的时间大部分被审查和修复吃掉了。净收益有，但没想象中那么大。而且这个净收益高度依赖团队的review能力——review能力强、经验丰富的团队收益明显，新人多的团队反而可能变慢。

还没想明白的事

有几个问题我自己也没想清楚。

第一个：如果AI持续加速"写"的环节，而"审"的环节没有对应的AI辅助（AI审代码目前还不靠谱），那这个剪刀差会越来越大吗？还是说团队会自然调整——比如减少PR粒度、增加自动化测试、或者改变review流程？

第二个：当"写代码"不再是瓶颈，什么才是？是理解需求的能力？是架构设计的能力？是验证和测试的能力？还是"信任"的能力——也就是判断AI产出是否可靠的能力？

第三个：如果未来大部分代码都是AI写的，那"会写代码"这件事本身的价值会怎么变？不是说写代码不重要了，而是说——当写代码的速度不再受限于人的打字速度，我们评价一个工程师的标准，是不是也得跟着变？

说实话，这些问题我现在只有模糊的直觉，没有清晰的答案。但有一件事比较确定：瓶颈确实挪地方了。只是挪到哪，我们还在找。