评审队列里压着一个 AI 写的合并请求（PR），四百多行，挂了三四天没人点开。它前面还排着五六个一样的大块头。同一周，团队看板很漂亮：合并请求数创了新高，每个人都觉得今年明显更快了。
这两件事同时成立，就是 2026 年大多数工程团队的真实处境。
不是你没在进步，而是你把劲都使在了一个不再卡你的地方。写代码这一步被 AI 打到接近免费之后，决定团队真实交付速度的，已经不是谁写得快，是谁审得动。
问题不在「AI 没用」，问题在你押错了边。
瓶颈搬家了
软件工程效能分析平台 LinearB 发布的 2026 年基准报告，扒了 810 万个合并请求、涉及 4800 多个组织，结论很直接：瓶颈已经从「写代码」搬到了「评审与验证」（LinearB Benchmarks）。
最刺眼的是这两个对比。
第一，AI 写出来的合并请求，平均要在评审入口外排 4.6 倍的队，才有人点开。有意思的是，一旦被人捡起来，反而审得更快——评审动作本身审得动，是前面那段队太长。
第二，同一批 AI 合并请求里偏大的那些（75 分位，即从大到小排在前 25% 的），体量是普通合并请求的 2.6 倍：一个 408 行，一个 157 行。AI 一次能吐出更多代码，但接得住代码的人没多。
还有一条最扎心：AI 合并请求最后真正被合并的比例只有 32.7%，人写的有 84.4%（LinearB Build vs. Buy）。AI 端写出来的「产出」，有将近七成根本没走通。
AI 在写代码这一头把水龙头开到最大，下游那根「人来评审」的水管口径没变。水越积越多，每一滴在管口等的时间越来越长。你看板上涨的「合并数」，看着像产能，其实只是水龙头开大的流量，不一定是真正流过管子的水。
你以为买到的是产能，其实买到的是积压。
不堵的地方使劲，堵的地方只会更堵
如果卡的是评审，那你再给「写代码」加第二个、第三个 AI 工具，会发生什么？
不会变成更多交付。只会变成更长的队、更大的代码块、更多需要人脑去判断的上下文。
这件事有个朴素的道理：来的活越接近能处理的上限，队伍不会慢慢变长，会突然失控。生产管理里有一个叫约束理论的老说法，《目标》那本书把它讲透了——一个系统的产出，由它最卡的那个环节决定。你在不卡的地方使再大的劲，多出来的东西不会变成产出，只会堆在那儿，反过来还会拖累那个真正卡住的环节。
LinearB 那个 4.6 倍的排队，就是这个道理跑出来的结果，不是哪个团队不努力。
所以有一个反直觉但站得住的结论：在「写代码」这一头，再加第 N 个 AI 工具，多出来的产出基本是零，弄不好还是负的。 它不增交付，只增积压；积压回头还会压垮你评审本来就紧张的余量。
AI 真正坑你的，是让你心安理得地一次提交太多代码
DORA（一个研究软件开发效率的组织）发布的 2025 年报告，样本铺得很广：九成技术从业者在用 AI，超过八成觉得自己更高效了（DORA 2025）。但 DORA 给 AI 下的定性不是「提速器」，是**「放大器」**。
放大器的意思是：AI 不会替你养成工程纪律。你团队原来什么样，它就放大什么样。纪律也好，混乱也好，照单全收。
数据里也是这样：AI 用得越多的团队，产出在涨，交付出问题的概率也在涨。这两条曲线一起往上走，就是你最近常听到的那种撕裂感——感觉是更快了，可交付却更脆了。
DORA 的对策直接指向一个老规矩：小批量提交——一次别改太多，让每次合并请求都小到能被一个人独立看完、独立合进去（Balancing AI tensions）。原因不复杂：以前你自己写 400 行会累，会自然停下来拆一拆；现在 AI 工具几分钟就能甩出 500 行，那条「累了就拆」的本能不再触发。LinearB 那个 2.6 倍的体量，和 DORA 这条机制，其实是同一件事。
AI 没逼你放低标准，是你顺手把它放低了。
解法不是审得更狠，是少塞东西给人审
最直觉的反应是「让评审更快」：加人、加班、上一个 AI 评审工具。这些都没切中要害。
破解卡点的办法，从来不是让瓶颈跑得更快，是减少流过瓶颈的东西。三件事，方向都在「减」。
前面讲的是为什么评审变成了瓶颈——AI 把水龙头开大了，管道还是那根。下面三件事，按你回去之后动手的顺序排：先做一件今天就能一个人拍板的，再做一件需要写进日常习惯的，最后做一件要动 CI 配置的。
第一件事：锁死 PR 的体量上限。 打开你的仓库设置，把合并请求的 diff 行数上限锁在一个具体数字——400 行是个能用的起点。超了这条线的 PR，让 CI 直接拦下来，不进评审队列。这不是「建议团队写小一点」，这是机器帮你挡门。它直接对冲前面讲的 2.6 倍膨胀：AI 一次甩出来的 500 行，不管多整齐，拆成两到三份再进来。每份小到一个人能在一次专注里装得下，敢点开、敢看完、敢合并。
第二件事：在你给 AI 下任务之前，先把验收条件写成一个 checklist。 AI 代码最难审的地方，不是它看着不像代码，是它常常看起来很对。所以你不能问「这看着对吗」——AI 最擅长生成的就是「看着对」的东西。要问的是：它做了哪些假设？这些假设安不安全？ 应用安全平台 Bright Security 把这条总结得最干脆。实操上就一步：每次给 AI 下任务，花三分钟写出三到五条验收条件——接受什么输入、不能碰什么数据、边界情况怎么处理。评审的时候不看代码漂不漂亮，就对着这五条打勾。全绿就过，剩下的都是第二优先级。
第三件事：把机器检查配进 CI，配到人看不到不合格 PR 的程度。 类型检查挂一个 step、核心路径的单元测试挂一个 step、再加一个 AI 一审的 step——让机器先过一遍表层问题（未处理异常、空指针、明显的逻辑漏洞），修完了才轮到人看。这几样配完之后的效果：进入人工评审的 PR，机器已经把能自动化的活全干完了。人的精力留给机器判断不了的——业务逻辑对不对、架构契不契合、权限和数据该不该这样走。
三件事做下来，你团队里的人干的活会变：从「硬着头皮审一堆 AI 生成的代码」，变成「在机器铺好的路面上做最后一道判断」。瓶颈还是那个人，但流过他的东西变少了——而且是少在正确的地方。
别再用「合了多少 PR」自我感动
如果卡在评审，那你向上汇报的那套指标，大半都在量错的地方。
合了多少 PR、写了多少行、PR 总数——这些全是写代码那一头的产能。它们涨，只说明水龙头开得更大，不说明真正流过管子的水更多。数字本身是真的，但它在让你看错地方。
该盯的就这几件事：评审队列等多久、改了多少次才合进去、从写完到上线一共要花几天。现成的预警灯前面就有：AI PR 接受率 32.7%、人写的 84.4%。这个差距本身就在说，你的 AI 产出里有一大半没走通。它越大，你写代码那一头那些漂亮产能就越假。
顺便提一句 ROI。DORA 2026 年初那份报告，给一个 500 人的工程组织算过一笔：八个月回本，年回报率大约 39%。但 DORA 自己在报告里就标了——这是「示意性测算」，不是实测，回报很大程度上取决于你团队本来的工程地基（DORA ROI）。换句话说，AI 的回报不是买工具自动来的，是看你的流程能不能接得住它。
繁忙不是产出。在错的那一头，越忙越亏。
什么时候这招不灵
也得提一下边界，不然就成了另一种贩卖焦虑。
它确实有不灵的时候。三五个人的高信任小团队、一次性脚本、还在做原型的项目——这些场景里最卡的地方可能本来就不是评审，硬上小批量和规格只是给自己加镣铐。这套逻辑是用来帮你找到自己真正卡在哪的，不是套模板。先确认你的瓶颈真在评审，再谈后面。
AI 评审能不能把这个问题解决掉？能解决一部分。让 AI 先过一道，确实能把人从一堆表层问题里解放出来。但 DORA 那条提醒得记住：用了 AI，关键交付指标未必跟着改善。AI 评审让瓶颈窄一点，不让瓶颈消失。 把它当免责金牌，迟早出事。
也别把这篇读成「少用 AI」。恰恰相反，该用就往狠里用，只是要砸在评审、验证、规格这一头，不是再砸在「再多写一点」上。同一笔预算，投到瓶颈上是给整条路松绑；继续投到没卡的地方，只是在堵死的路口继续加车。
真正拉开差距的，是能审好代码的人
2026 年真正拉开差距的，不是写得更快的团队，是审得了代码的团队。继续往写代码这一头加 AI，等于给一个已经堵死的路口继续发车——车更多了，路更堵了，看板更好看了。
本周就能验一件事：打开你团队的 PR 列表，量一下评审队列的平均等待时间，再看一眼 AI PR 和人写 PR 的接受率差多少。
如果 AI PR 等得明显更久、接受率明显更低，先别再加写代码工具了——把预算和精力调到评审、验证、规格这一头。