AI编程PR堆满队列?先盯这3处

系列：AI编程团队协作笔记（1/4）

为什么代码越写越快，交付反而越来越慢？因为快的那部分不缺人干，缺人看。

台北一位做 SaaS 的技术主管给我算过一笔账：团队上手 AI 编程之后，每周开的 PR 从 12 个涨到 31 个，代码产出翻了差不多三倍，可实际上线的功能只多了不到五成。

多出来的东西去哪了？卡在评审队列里。他的原话很扎心："以前是等人写完，现在是等人看完。"

这不是他一个团队的毛病。LinearB 拆了 4800 个团队的 810 万个 PR，结论是：AI 采用度高的团队合入的 PR 多了 98%，但每个 PR 的评审时间涨了 91%。另一份 2026 年的调查更直观——开发者每周平均花 11.4 小时审 AI 写的代码，花 9.8 小时写新代码，读的时间反超了写的时间。

结论先摆这儿：AI编程没有让交付变轻，只是把瓶颈从"写"挪到了"审"。这个系列就讲这一层坎怎么迈——从"个人能用"到"团队能推"。这一篇 1/4 只说个人层面：打开一份 AI 写的 PR，该盯哪 3 处。我的顺序是：意图、上下文、边界。

头一处：它解的，是不是你题

AI 代码有个教科书级的失误模式：解了个"相邻问题"。需求问的是 A，它流畅地写出了一个几乎正确、实际答 B 的实现——语法挑不出毛病，测试也能过，上线才发现业务口径错了。

人写代码不一样。没想明白的人会留下犹豫的痕迹：别扭的绕法、TODO、一看就不确定的防御检查。这些"犹豫痕迹"恰恰是评审人的路标，告诉你哪里要细看。AI 没有这个机制——它想没想明白，写出来一样流利。所以 AI 代码不能像读靠谱同事的代码那样"略读"，它属于那种自信的错法。

动作给两个：

第二处：它改的那行，动了谁的契约

它删掉的那行"看起来多余"的判断，可能藏着三个月前的一场线上事故。Sonar 的调查说，提交入库的代码里 42% 已经是 AI 写的或 AI 辅助的，预计 2027 年要到 65%；GitLab 那边还有个更冷的数字：43% 的开发者没法可靠区分 AI 代码和人写的代码。分不清长相不是重点，重点是——它写的时候，不知道你们仓库里那行代码的来历。

这事我在《AI编程的token烧在哪？99%在找代码》（79）里算过经济账：AI 对仓库没记忆，每轮都在重新翻找。从翻找里捞出来的上下文还不一定全，于是它敢把"多余"的兼容代码删干净。《客服Agent把A地址报给B，先别甩锅模型》（66）讲过另一个方向：它不认识"谁"。仓库历史和业务归属，正好是 AI 视野里的两块盲区。

动作也具体：

第三处：顺利之外的场景，它想过吗

开发者圈公认 AI 代码的头号毛病叫"几乎对了"：主路径丝般顺滑，空输入、中途失败、重试风暴这些边角全空着。Lightrun 的统计说，43% 的 AI 改动即便过了测试和预发，到生产环境还得人工介入，一个修复平均要再部署三轮。Checksum 那份 105 位工程负责人参与的调查更直接：61% 的团队在过去 90 天内上线过由 AI 代码引发的生产事故，74.3% 回滚过"单测抓不住"的 AI 代码。

审边界不用通读，拿三问扫一遍就够：

这三问恰好对应排障系列里那三位老熟人：空指针进参数（参见内存泄漏那篇的引用链思路）、长事务占住连接不放（77 讲过外呼 3 秒占满 20 个连接的案发现场）、悄悄改契约坑下游。写的时候 AI 没想过的场景，就是上线以后告警替你想的场景。

三处自查卡（贴到团队 wiki 用）

说个行业里真实发生的分歧：开源引擎 Godot 直接拒收了 AI 代写的贡献，维护者给的理由一句话——AI 不能负责，重度用它的人也未必讲得清代码。这话难听，但点破了评审文化的底座：谁提交，谁背书。队里流行两种人，一种是懂系统、敢为发布拍板的；另一种是拿 AI 产出一大坨、开个大 PR、转身就走的。后一种人攒下的评审债，年底全落到前一种人头上变成加班。

下一篇预告：2/4《团队都上手AI编程，先把这4条规矩立了》——PR 尺寸上限、意图附单、机器预审、双轨放行，把个人眼睛升级成团队工序。

你们团队的评审队列里，躺得久的 PR 排了几天？有没有哪份 AI 代码，你放过去之后它才在测试里现出原形？评论区聊个现场。

相关阅读：《AI编程的token烧在哪？99%在找代码》（79）、《AI编程还在狂点同意？审批这道工序撤了》（80）、《连接池打满报警刷屏？先看清是谁没还》（77）、《客服Agent把A地址报给B，先别甩锅模型》（66）、《Agent转头就忘？先分清它的4种记忆》（60）