瓶颈已经移动了。你还在优化那个旧的。

每个系统都有一个设定其节奏的约束。三十年来在软件里，那个约束是产出代码——写它、敲它、把它从你脑子里搬进编辑器。 于是我们把整个手艺都围绕这件事来打造：打字更快、更好的自动补全、代码片段、框架、更高的吞吐。然后 AI 让产出代码几乎变得免费 ——瓶颈就移动了。几乎没人跟着它一起移动。

漏斗的颈现在是评审

当生成变得便宜，真正卡住交付的是验证：读懂产出、理解它、决定要不要信任它、并为它负责。数据显示的正是这个转变。据报道， 采用 AI 之后，代码评审时间上涨了大约 91%， 哪怕单个任务的完成率在上升。大多数开发者并不完全信任 AI 产出的正确性，可很大一部分人还是不总是验证就直接提交 ——这不过是瓶颈在下游以 bug 的形式爆发出来，而不是在评审时把账付掉。正如 DevOps.com 所说： 「瓶颈不再是写代码了。是验证。」

让那个不受约束的步骤变快，并不能加速整个系统。它只会在约束前面堆起库存。

这是《约束理论》第一课，而 AI 把我们径直带进了它。现在去优化代码的生成——更多的 agent、更快的模型、更多的产出—— 就是在优化那个不是瓶颈的步骤。所有那些额外生成的代码并不会更快地交付；它排在一个人类面前，而这个人现在要读、要信任、 要担起的东西比以往任何时候都多。

为什么你的速度指标在撒谎

陷阱在这里：我们继承下来的那些指标，衡量的全是旧的约束。交付的行数、完成的任务、开出的 PR、「到第一版草稿的时间」—— 当生成变快时它们全都亮起绿灯，而那恰恰是已经不再是问题的那一半。与此同时，真正的问题——一个人能多快地有信心接受这个？ ——不会出现在任何仪表盘上，因为它不是一个吞吐量数字。它是一个信任数字。而信任不会靠加算力来扩展。

优化真正的瓶颈是什么样子

• 让产出易于验证，而不只是易于产出。 更小的 diff、被解释清楚的改动、可复现的步骤。一个你两分钟就能评审完的改动， 胜过一个大一倍、要花二十分钟的。
• 在「接受」这一步上投入。 测试、类型、给合并把关的 evals、确定性的检查—— 任何能让人类信任产出、而不必手动重新推导一遍的东西。吞吐量现在真正住在那里。
• 衡量「到有信心接受」的时间。 不是你生成得多快，而是要过多久才有人能把它扛下来。如果那个数字没在改善， 你的「更快」就是一种错觉。
• 像对待稀缺资源那样保护评审者的注意力。 用看似合理的 AI 产出把你最好的人淹没，不是杠杆——那是把工作推到下游， 压到那个你无法靠并行化甩掉的唯一步骤上。

底线

AI 没有消除瓶颈；它重新安置了瓶颈——从写代码搬到了验证——却把我们的习惯和指标留在了那个空荡荡的车站前。生成得更多、更快， 只会让那个真正设定你节奏的步骤前面的堆积更深。

别再优化键盘了。约束现在是信任——让产出验证起来便宜，并衡量一个人能多快有信心地说「行」。