周三下午三点，老陈点了提交。五十行，加一个筛选条件，就是给订单列表多一个按日期筛的口子。AI 三小时前就把这段写完了，他扫了一遍，只改了两处变量名。
他等了四天没动静，周一早上去问老吴。老吴把屏幕转过来，拿鼠标往上翻了两屏：你前面还压着两千四百行。我一天看三百行，你这批得排到下周三。
他回头翻了自己的提交记录：隔壁组小赵周一早上交的五十行，周二就合进去了。同一份活，两个人用的工具一样，写的行数一样，一个等一天，一个等八天。
为什么会这样
AI 只让"写"这一段变快了，"看"这一段还是人的速度。写的人一多，活就堆在门口。
老吴一天能认真看三百行，还得跑一遍测试。这是人的速度，AI 帮不上他。团队八个人，以前每人一天交一次，一次五十行，一共四百行，门口勉强过得去。
现在每个人三小时就写完一段，一天交三次。八乘三再乘五十，一天涌上来一千二百行。门口只能过三百行，剩下的九百行就在那儿排队。
周一早上交的人，前面是空的，当天就轮到。周三下午交的人，前面已经堆了两天的九百行。加上当天上午的六百行，两千四百行，除以三百是八天。
这就像一个小区驿站。以前一天一百个件，一个人分得过来，取件码当天就发；现在一天四百个件，人没加，件堆在货架上，码发得越来越晚。件没变重，是件变多了。
怎么解决
交之前自己删一遍——打开 AI 给的改动，把没人要求改的行划掉。一千二百行里通常有八九百行是它顺手加的，压到一百五十行再交就是半天。排队从八天回到一天，花二十分钟。
一天固定在两个点交——上午十点、下午四点各一次。一天从一千二百行降到八百行，涨势止住了。离三百行还差一截，花半小时改习惯。
加一个评审的人——门口一天能过的从三百变六百，积压当天转负。一周内能定，代价是多一份人力，要老板点头。
别踩的三个坑——多发消息插不了队，老吴的消息越多他看得越慢；拆成十二个一百行连着交也没用，门口一样宽。只看平均等多久听着还行，最长那个等了八天。
平台怎么管这些问题
提交入口按人按次记账，谁交了多少行、几点交的，都留在上面。队列看板把每个人排第几位、前面还压着多少行摊开。评审负载看老吴这周接了多少行，超了就标红。
机器先把格式和明显的错挡掉，人工只看逻辑，行数砍掉三成。合并前那道关卡卡单次体积，超过两百行必须拆或两个人看。周报表列出谁等得最长、哪个环节最堵。
改规则的是技术负责人，两百行这条线写在他手上。批减免要值班评审和技术负责人双签，紧急修复可以超，但得留记录。
倒查靠每次提交带的人和时间，回退时能看到是哪一批、谁交的。队列堵了告警发给值班评审，超五百行再发给技术负责人。
这笔钱值不值
按八个人、人均月薪两万算，二十二个工作日。一天九百零九元，一小时一百一十四元，这是假设。
每人每天等两小时，八个人十六小时，一天一千八百二十四元；压到一小时，一天省九百一十二元，一个月两万零六十四元。
这两小时是估的，各家能自己回算。一周交多少行，除以评审一天看多少行，就是最少等几天。
工具钱按每人每月两百元算，八个人一千六百元。净省一万八千多元，头一个月就回来。
行业规则怎么管这件事
Google 的工程实践文档里有一篇《Speed of Code Reviews》，2019 年公开。它写得很清楚：回应一次评审请求，最长一个工作日。
但同一篇里还有一句：我们关心的是响应时间，不是一次改动走完整个流程要多久。
所以老吴当天回了"收到"，合规。老陈等八天，也合规。规则管住了回话，没管住看完。
老陈最后还是在下周三合进去了，交付日一天没提前。他现在交之前先自己删一遍，五十行的活就交五十行。门口的宽度他改不了，能改的是自己排在哪儿。
Codex、Claude Code、Trae、Qoder 要用的模型 token，统一接入、统一计费。