# AI 写代码变快了，但你的评审跟不上了 - URL: https://davidyin.dev/writing/ai-moved-the-bottleneck/ - 作者: David Yin - 发布: 2026-05-31 - 标签: x-article - 摘要: 评审队列里压着一个 AI 写的合并请求（PR），四百多行，挂了三四天没人点开。它前面还排着五六个一样的大块头。同一周，团队看板很漂亮：合并请求数创了新高，每个人都觉得今年明显更快了。 评审队列里压着一个 AI 写的合并请求（PR），四百多行，挂了三四天没人点开。它前面还排着五六个一样的大块头。同一周，团队看板很漂亮：合并请求数创了新高，每个人都觉得今年明显更快了。 这两件事同时成立，就是 2026 年大多数工程团队的真实处境。 不是你没在进步，而是你把劲都使在了一个不再卡你的地方。写代码这一步被 AI 打到接近免费之后，决定团队真实交付速度的，已经不是谁写得快，是谁审得动。 问题不在「AI 没用」，问题在你押错了边。 ## 瓶颈搬家了 软件工程效能分析平台 LinearB 发布的 2026 年基准报告，扒了 810 万个合并请求、涉及 4800 多个组织，结论很直接：**瓶颈已经从「写代码」搬到了「评审与验证」**（[LinearB Benchmarks](https://linearb.io/resources/software-engineering-benchmarks-report)）。 最刺眼的是这两个对比。 第一，AI 写出来的合并请求，平均要在评审入口外排 **4.6 倍**的队，才有人点开。有意思的是，一旦被人捡起来，反而审得更快——评审动作本身审得动，是前面那段队太长。 第二，同一批 AI 合并请求里偏大的那些（75 分位，即从大到小排在前 25% 的），体量是普通合并请求的 **2.6 倍**：一个 408 行，一个 157 行。AI 一次能吐出更多代码，但接得住代码的人没多。 还有一条最扎心：AI 合并请求最后真正被合并的比例只有 **32.7%**，人写的有 **84.4%**（[LinearB Build vs. Buy](https://linearb.io/resources/build-vs-buy)）。AI 端写出来的「产出」，有将近七成根本没走通。 AI 在写代码这一头把水龙头开到最大，下游那根「人来评审」的水管口径没变。水越积越多，每一滴在管口等的时间越来越长。你看板上涨的「合并数」，看着像产能，其实只是水龙头开大的流量，不一定是真正流过管子的水。 **你以为买到的是产能，其实买到的是积压。** ## 不堵的地方使劲，堵的地方只会更堵 如果卡的是评审，那你再给「写代码」加第二个、第三个 AI 工具，会发生什么？ 不会变成更多交付。只会变成更长的队、更大的代码块、更多需要人脑去判断的上下文。 这件事有个朴素的道理：来的活越接近能处理的上限，队伍不会慢慢变长，会突然失控。生产管理里有一个叫**约束理论**的老说法，《目标》那本书把它讲透了——一个系统的产出，由它最卡的那个环节决定。你在不卡的地方使再大的劲，多出来的东西不会变成产出，只会堆在那儿，反过来还会拖累那个真正卡住的环节。 LinearB 那个 4.6 倍的排队，就是这个道理跑出来的结果，不是哪个团队不努力。 所以有一个反直觉但站得住的结论：**在「写代码」这一头，再加第 N 个 AI 工具，多出来的产出基本是零，弄不好还是负的。** 它不增交付，只增积压；积压回头还会压垮你评审本来就紧张的余量。 ## AI 真正坑你的，是让你心安理得地一次提交太多代码 DORA（一个研究软件开发效率的组织）发布的 2025 年报告，样本铺得很广：九成技术从业者在用 AI，超过八成觉得自己更高效了（[DORA 2025](https://dora.dev/dora-report-2025/)）。但 DORA 给 AI 下的定性不是「提速器」，是**「放大器」**。 放大器的意思是：AI 不会替你养成工程纪律。你团队原来什么样，它就放大什么样。纪律也好，混乱也好，照单全收。 数据里也是这样：AI 用得越多的团队，产出在涨，**交付出问题的概率也在涨**。这两条曲线一起往上走，就是你最近常听到的那种撕裂感——感觉是更快了，可交付却更脆了。 DORA 的对策直接指向一个老规矩：**小批量提交**——一次别改太多，让每次合并请求都小到能被一个人独立看完、独立合进去（[Balancing AI tensions](https://dora.dev/insights/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](https://brightsec.com/blog/5-best-practices-for-reviewing-and-approving-ai-generated-code/) 把这条总结得最干脆。实操上就一步：每次给 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](https://dora.dev/ai/roi/report/)）。换句话说，AI 的回报不是买工具自动来的，是看你的流程能不能接得住它。 **繁忙不是产出。在错的那一头，越忙越亏。** ## 什么时候这招不灵 也得提一下边界，不然就成了另一种贩卖焦虑。 它确实有不灵的时候。三五个人的高信任小团队、一次性脚本、还在做原型的项目——这些场景里最卡的地方可能本来就不是评审，硬上小批量和规格只是给自己加镣铐。这套逻辑是用来帮你**找到自己真正卡在哪**的，不是套模板。先确认你的瓶颈真在评审，再谈后面。 AI 评审能不能把这个问题解决掉？能解决一部分。让 AI 先过一道，确实能把人从一堆表层问题里解放出来。但 DORA 那条提醒得记住：用了 AI，关键交付指标未必跟着改善。**AI 评审让瓶颈窄一点，不让瓶颈消失。** 把它当免责金牌，迟早出事。 也别把这篇读成「少用 AI」。恰恰相反，**该用就往狠里用，只是要砸在评审、验证、规格这一头**，不是再砸在「再多写一点」上。同一笔预算，投到瓶颈上是给整条路松绑；继续投到没卡的地方，只是在堵死的路口继续加车。 ## 真正拉开差距的，是能审好代码的人 2026 年真正拉开差距的，不是写得更快的团队，是审得了代码的团队。继续往写代码这一头加 AI，等于给一个已经堵死的路口继续发车——车更多了，路更堵了，看板更好看了。 本周就能验一件事：打开你团队的 PR 列表，量一下评审队列的平均等待时间，再看一眼 AI PR 和人写 PR 的接受率差多少。 如果 AI PR 等得明显更久、接受率明显更低，先别再加写代码工具了——把预算和精力调到评审、验证、规格这一头。