编码提速四成，评审等待翻三倍：效率红利卡在队列里

一个评审排队，吃掉了一整支团队的编码红利

“你觉得这事靠谱吗？”朋友把手机递过来，屏幕上是他们研发组这个季度的数据看板。

我看了眼那个数字，愣了一下。他们组用AI编码代理已经快半年，代码提交量涨了四成。但合并请求的平均等待时间从11小时变成了31小时。他苦笑：“写代码是快了，可没人能那么快审完。”

这不是他一个组的困境。GitHub和Stack Overflow今年的开发者调查里有个数据被反复引用：AI编码代理的企业采用率在持续爬升，开发者自报编码速度显著提升，但代码评审、测试和安全审查成了新的堵点。工具把上游的水龙头拧大了，下游的管子没换，水全积在评审这道口上。

快的那一段，和慢的那一段

我一开始以为这是个工具配置问题。多招几个评审、配个自动化检查，不就通了？

后来发现不对。编码代理产出的代码有个特点：量多、面广、看起来都对。一个开发者以前一天提三个合并请求，现在提十个。每个请求单看质量不差，但评审者要判断的东西从“这行逻辑对不对”变成了“这批代码整体会不会在某个角落埋雷”。认知负荷不是线性增加的，是跳着涨的。

有个做后端的朋友跟我描述过他的日常。下午两点，他打开评审队列，十七个待审请求，其中十一个是代理生成的。他花四十分钟看完前三个，发现一个在并发场景下的锁粒度问题——这种问题代理不会主动标出来，因为它“看起来能跑”。他关掉页面，去泡了杯咖啡，回来接着看。那天他评审到晚上九点，自己的功能代码一行没写。

代理提效省下来的时间，被评审吃回去了。 而且吃得悄无声息，因为评审本来就被当成“必要开销”，没人给它算过账。

这就是效率红利分布不均的真相。写代码那端的人觉得爽，评审那端的人觉得被淹没，两个感受都是真的，但组织层面只看到了提交量上涨的报表。

流程重构，不是加个检查框

McKinsey和企业财报电话会里透出的信号也指向同一个方向。客服、财务对账、合同处理这些场景的代理式AI开始规模化部署，董事会不再问“能不能用”，开始问“ROI多少、失败率多少、试点转生产的比例是多少”。听着像是更成熟了，但换个角度：当评审和验收的成本被真正计入账本，很多“提效”的账要重算。

工程组织里已经开始有人动流程了。我了解到的一个做法是，把代理生成的代码和人工代码在评审队列里分开排，代理代码先过一轮自动化静态分析加单元测试覆盖率门槛，不达标的不进人工队列。另一个团队干脆改了合并策略，小批量、高频次，每次代理产出控制在评审者二十分钟能看完的体量。

这些做法都不性感，但它们解决的是同一个问题：评审带宽是稀缺资源，得按稀缺资源的方式来调度。

工具解决的是“生产”，流程解决的是“吞吐”。只换工具不改流程，等于给堵车的路加了更多车。

坦白说，我之前的判断也需要修正。我一直觉得AI落地的主要障碍是模型能力不够或者数据不通。现在看，至少在编码这个场景里，能力已经越过了“能用”的线，卡住的是组织消化产出的那套流程——评审、测试、安全审查，这些环节的节奏还是为人工作业设计的。

次生信号：代理开始自己花钱了

还有个事声量不大，但我觉得值得放在这儿提一句。支付网络和开发者社区在试验代理身份认证和机器间小额支付协议，让自主AI代理能自己执行交易。目前还是早期实验，涉及身份、责任和欺诈风险，离落地很远。

但它和上面那条线是连着的。如果代理不只是写代码，还要自己调API、买算力、付服务费，那“评审”这个概念就得扩展到“代理行为的审计”。现在人类评审者看的是代码，将来要看的是代理花出去的钱和签下的合同。瓶颈不会消失，只会换位置。 到时候堵的可能是财务审计，不是代码评审。

红利不在工具里，在队列里

回到我朋友那个组。他们上个月做了个调整：代理生成的合并请求必须附带一段“变更意图说明”，由发起者写清楚这段代码想解决什么、边界在哪。评审者先看说明再看代码。等待时间从31小时降到了19小时。没换工具，没加人。

这个改善幅度不算惊艳，但方向对。AI提效的红利不是自动到账的，它卡在组织的吞吐能力上，得靠流程重构去把它挤出来。

写代码快了四成这件事是真的。但如果评审队列还是按老节奏走，那四成红利就只是一串好看的提交数字，躺在看板上，谁也拿不到手里。

我那个朋友后来跟我说了句话，我记到现在：“我们现在不缺写代码的人，缺的是能快速判断一堆代码该不该合的人。”

这话听着像抱怨，其实是路线图。