你感觉更快了，其实你更慢了

有一个结果，应该让每个 AI 编程的爱好者停下来想一想。在一项严谨的研究里， 有经验的开发者用自己的真实项目任务做实验，分别在有 AI 和没有 AI 的情况下工作。 他们预测 AI 会让自己快大约 24%。可测出来的结果是： 他们用 AI 反而慢了 19% —— 而且即便亲身经历了这场变慢，他们仍然相信 AI 把自己提速了 20%。

好好品一下这个落差。这不是「AI 没有想象中那么有用」。AI 让他们 更慢了， 而他们自己感觉不到。在做真实工作的有经验的人身上，感知和现实之间裂开了 大约 40 个百分点的鸿沟。而这和企业在规模化层面看到的现象正好对得上： 个人活动量爆炸，结果却原地踏步。值得琢磨的问题不是「AI 是不是假的」—— 它显然不假。而是 为什么感觉和结果指向相反的方向 ——因为答案会改变你该怎么用它。

AI 拿掉的是你感觉得到的摩擦，不是真正难的活

这是解释的前半部分。AI 极其擅长编程里那些 感觉 像在干活、但难点根本不在那儿的部分—— 样板代码、语法、繁琐的打字。当这些摩擦消失时，你感觉很快，因为讨厌的那部分变轻松了。

但样板代码从来就不是难的部分。难的部分是理解问题、把整个系统装在脑子里、 判断某个改动到底对不对。AI 并不会拿掉这些——它往往还会 增加 这些， 因为现在你还得去读、去查、去修一段不是你写的代码。按照这项研究的解读， 开发者最后把大量时间花在收拾 AI 的产出上，而不是在交付。 工作从「写」变成了「审」，而审阅别人那段看着挺像样的代码， 比人们预想的更慢、也更不爽。你感觉快，是因为看得见的摩擦没了。 你其实慢，是因为看不见的工作变多了。

光靠合并代码堆不出价值

后半部分出现在团队层面，而且更重要。Faros AI 测量了那些大量采用 AI 的团队， 发现了一个很扎眼的形态： 合并请求多了 98%，但 PR 评审时间涨了 91%，PR 体积涨了 154%，缺陷涨了 9%——而 DORA 交付指标却纹丝不动。 更多代码、更多 PR、更多活动量。实际交付却一样。

这其实就是换了身新衣服的瓶颈问题。如果你加速了流水线的某一个环节——代码生成—— 却没有加速它后面的环节——人工评审——你不会得到更高的吞吐量。 你只会在那个慢环节前堆起更大的一堆。AI 让写代码变便宜了， 这意味着现在有多得多的代码要评审，评审的还是同样数量的人， 而这些人现在成了瓶颈。AI 创造的价值在评审队列里被吸收掉，从未抵达业务。 这就是为什么 89% 的高管说 AI 让工作变快了，可只有 6% 能指出全组织层面的真实回报。 人人都更忙了。没有任何东西交付得更快。

这应该改变你的工作方式

错误不在于用 AI，而在于优化错了环节、衡量错了东西。由此能推出几条修正：

• 衡量结果，而不是产出。 合并的 PR 数、写的行数、「我感觉更快了」—— 这些现在都是虚荣指标，容易灌水，又和交付脱节。那件事到底有没有送到用户手里、 有没有真的好用？这才是唯一活下来的数字。
• 把评审当成它已经变成的那个瓶颈来对待。 如果 AI 让代码翻了三倍， 那么决定这堆代码有没有变成价值的，是你的评审和测试能力。 把力气投在那里——更小的 PR、更好的评测、自动化检查——而不是再去生成更多。
• 不要相信「快」的感觉。 这项研究最吓人的发现是，聪明人感知不到自己变慢了。 默认你「这更快」的直觉是不可靠的，拿真实的东西去校验它。
• 在 AI 真正能赢的地方用它。 同一批研究显示，AI 对新手做简单、不熟悉的任务 收益巨大，对老手处理他们早就熟悉的复杂代码则接近零甚至是负的。 把它瞄准前一种情况，对后一种情况保持怀疑。

一句话总结

一旦看清楚，AI 的生产力悖论就不再是悖论。AI 加速了生成——那个感觉像在干活的部分—— 却没碰那些真正慢的部分：理解、评审、判断。于是个人感受到一阵速度的快感， 真正的瓶颈却在悄悄恶化，而无论多少 PR 飞过，公司的数字都不动。

这和演示从来不是难的部分 其实是同一个教训的不同角度：生成变便宜了，判断没有。 如果你想让 AI 真的让你更快——而不只是感觉更快——就把它瞄准那些真正繁琐的活， 然后把省下的时间花在它做不了的部分：判断产出的东西到底好不好。 速度的感觉现在是免费的。真正的速度仍然得在那个慢环节挣来，而那个环节，就是你。