关于 AI 提升效率的说法，大多是感受层面的：写代码快了、查资料快了、做原型快了。但感受和交付之间还隔着一段距离。Faros AI 最近给出了一份偏冷的数据：他们分析了一万多名开发者、1255 个软件工程团队的工作流，结论是 AI 采用率与企业关键交付指标之间，没有显著相关性。

数据里最扎眼的两组对比

报告里有两个数字放在一起看很刺眼：PR 合并量增加了 98%，代码审查时间增加了 91%。也就是说，代码产出几乎翻了一倍，但审查环节的负担也几乎翻了一倍，两者几乎同步上涨。

这解释了为什么很多团队觉得“更忙了但没更快”。AI 把写代码的门槛降下来，进入审查队列的代码量随之暴涨，而审查这件事仍然要靠人。人没有变快，队列变长了，交付周期自然没有改善。

瓶颈从“写”挪到了“审”

软件工程的瓶颈一直在移动。十几年前是编译和部署，DevOps 把这部分压缩了；后来是测试覆盖，自动化测试把这部分压缩了；现在轮到代码审查。

审查之所以难被自动化，是因为它的价值不在于“代码能不能跑”，而在于“这个改动该不该存在”。命名是否表达意图、边界条件有没有漏、这个抽象是不是过度设计——这些判断依赖对业务和历史上下文的理解，恰好是当前工具最薄弱的环节。AI 可以帮你写出一段能跑的代码，但很难替你判断这段代码在三个月后会不会变成负担。

Gartner 的另一份调查说了同一件事

Gartner 调研了全球 203 位 CEO，44% 表示说不清 AI 到底带来了多少财务回报，但 75% 仍计划增加技术投资。算不清账，也不肯停手，这大概是 2026 年企业最真实的心态。

这种心态可以理解。不投入的风险看起来比投入的风险更大，而且在竞争里“慢一步”是可见的，“多花一笔钱”是隐性的。但当 44% 的一把手承认算不清回报时，说明行业还缺一套衡量 AI 收益的方法，而不只是缺更好的模型。

对团队来说，这意味着什么

如果审查真的是新瓶颈，那么继续给工程师加 AI 编码工具，边际收益会越来越低。更有效的做法可能是在审查侧补人、补流程、补工具：把大 PR 拆小、要求提交者附带变更意图说明、把静态检查前置到提交前，让人的注意力集中在真正需要判断的地方。

另一个容易被忽略的点是，AI 生成的代码需要不同的审查视角。人会写错逻辑，AI 更常犯的是“看起来很合理但不符合这个项目约定”的错——风格漂移、重复造轮子、悄悄引入新依赖。这类问题传统 review 习惯不一定能抓到。

结论不必太悲观

这份数据不是说 AI 没用，而是说收益没有落在最容易衡量的地方。写代码变快是真实的，但它只是交付链条上的一环；当这一环被压缩，压力会转移到下一环，整体吞吐量不一定上升。真正拿到收益的团队，往往是那些同时改造了审查和测试环节的团队。

所以更值得问的问题不是“要不要用 AI”，而是“用了之后，瓶颈挪到哪里去了”。找到那个新瓶颈，比再换一个更强的模型更有价值。

来源：Faros AI 工程效能报告、Gartner CEO 调研

相关阅读：OpenAI 一天推进三个调和分析猜想，发布流程也一起改了；Kimi K3.1 Pro 押上 3 万亿参数，全球智能指数进前四；最新AI大事 · 10月27日