AI 写了什么不重要，你敢 merge 才重要

你有没有这种感觉。

AI 写的代码越来越多，但你心里越来越没底。

以前一个 PR 三五百行，你还能一行行读过去。现在 Agent 啪一下甩过来三千行，格式工整、注释齐全、测试全绿。看起来没什么毛病。

但你就是不敢点那个 merge 按钮。

说实话，我这一年最大的感受就是这个。不是 AI 不够好，是它太好了，好到你看代码的速度跟不上了。

那个 4 倍和 10% 的故事

说个数据，今年 3 月 Faros AI 追踪了 4000 个团队、两万两千个开发者。他们把低 AI 使用率的团队和高 AI 使用率的放在一起比。

结果有点吓人。

代码产出上去了，PR 合并量上去了，吞吐率上去了，这些都好理解。但后面的数字是这样的，代码改动率涨了 861%，事故率涨了 242%，每个开发者的缺陷率从 9% 飙到了 54%。

还有更狠的，零审查就合并的 PR 多了 31%。

这个 31% 不是谁拍板决定的，没人说过「咱不审了」。就是审不过来。实在太多，多到不审变成了默认操作。

GitClear 那边也有一组数字，日常用 AI 的开发者，产出的原始代码量是不用 AI 的四倍。但跟自己一年前比，真正的生产力提升只有 12%。

四倍的代码，一成的额外价值。

中间那三倍多的差距去哪了，全压在审查上了。

说实话，我看到这几个数字的时候愣了几秒。因为太符合直觉了。你写东西的速度提了十倍，但你看东西的速度没变。那瓶颈自然就跑到「看」这件事上了。

有意思的是，那些工程实践很成熟的团队，受到的冲击跟其他人一样严重。流程没保住他们。因为问题的本质不是流程好不好，是量太大了，大到超过了任何流程设计的承受上限。

这是最让人无力的一点。

审查者成了「第一个看到这段代码的人」

说个细节，今年有篇论文分析了一千多条 Reddit 和 Hacker News 上讨论 AI 代码的帖子。

里面有个开发者说了一句我觉得特别精准的话，审查一个 Agent 的 PR，让他成了「第一个看到这段代码的人类」。

你品一下这句话。

以前人写代码，意图是天然跟着代码走的。写的人脑子里有完整的推理过程，审的人是在检查那个推理。现在 Agent 也推理，而且推理得很认真，但那个推理过程在 diff 产出的瞬间就被扔掉了。

没人把它保存下来，没人把它贴在 PR 上。

所以审的人面对的是三千行代码，得从零开始重建「它为什么这么写」。这比检查别人的推理难得多，也慢得多。但没人觉得有什么不对，我们还在对审查时间涨了 441% 表示惊讶。

真的，441% 有什么好惊讶的。你把步骤翻了一倍，速度当然要慢。

不是所有人都要审成一样深

我觉得这个讨论里最大的问题，就是所有人都在用同一个标准要求所有人。

一个独立开发者做 side project，零用户，和一个团队维护十年老支付系统。这两个人面对「审查」这件事，要做的根本不是同一个东西。

我自己试着分了三层。

第一层，solo，没用户。这时候审查的「知识分发」功能不存在，你就是整个团队。我的建议是重点靠测试和自动化，审查真正重要的部分，其余地方保持轻触。但有个前提，测试得是真的。跳过审查没有安全网，不是取消了工作量，是以更高的价格推迟了它。没用户是你推迟审查的许可，不是跳过验证的许可。

第二层，项目开始有用户了。这是最危险的时候。因为你可能还没意识到自己跨过了那条线。bug 突然会伤害真实的人了，代码突然要跟别人共享 ownership 了。很多团队在这个阶段多待了几个月，然后出一次事故，Faros 那些数字就变成了自己的仪表盘。

第三层，大组织，老代码库，多用户。每一个令人警觉的数字都在这里全力落地。一个没人理解的改动就是一笔理解债务，最后变成某个人凌晨三点的 on-call 电话。

所以结论不是「企业应该保守、solo 可以放松」。而是审查的目的本身随你位置变化，规则也得跟着变。把企业的锁死流水线套在一个两人的 prototype 上，是白加摩擦。把「测试过了就发布」用在支付系统上，是在造一台带绿色勾的 bug 生成器。

四个工具，从没标记过同一行

聊到工具，有个事我觉得特别值得说。

今年有个工程师干了一件事，他在自己 146 个真实 PR 上并行跑了四个审查工具，CodeRabbit、Sentry Seer、Greptile、Cursor BugBot。三周半，679 个发现。

结果是这样的。

在 617 个被标记的位置里，93.4% 只被一个工具发现。6% 被两个工具发现。几乎没有被三个发现的。四个工具同时标记同一行的情况，零次。

零次。

这四个东西从没在同一行代码上达成过一致。

说实话我看到这个结果的时候觉得特别有意思。因为这恰好证明了审查这件事「没有最好的工具」。Greptile 在正确性问题上几乎零误报，CodeRabbit 覆盖面最广还有一键修复，Seer 在生产事故级别的问题上最强。

异构才是全部意义。四份同一个模型的拷贝，只是一个账单更大的单一审查者。四个真的不同的审查者，才能挖出一个人——不管是不是人类——都挖不出来的那组 bug。

所以我现在自己的做法是，不纠结用哪个，跑两个性格不同的。一个负责日常正确性，一个负责生产事故级别。交集越少越好。

人往上一格，不是退出

我最近听到越来越多人在问一个一年前还是异端的问题，是不是该让 AI 审更多的代码，也许是大部分。

我不觉得这是个蠢问题了，因为情况确实变了。

机器已经在审比你更多的代码了。这是事实，不是观点。零审查合并涨了 31%，审查时间涨了三位数百分点。人类明显跟不上了。诚实的问题不是「该不该让 AI 多审」，而是「AI 已经在多审了，我们是要刻意设计这件事，还是假装人类还在读一切」。

但这不代表人该退出。

Loop 工程现在很火，核心逻辑是你不再给 Agent 下指令，你造一个系统来给 Agent 下指令。这个系统里有个「法官」，决定工作能不能过。审查者正在被有目的地设计出内循环。

人一直在往上往外推。

我觉得正确的方向不是「人该走了」，而是「人往上移一格」。你不再读每一行代码，但你拥有三件事。

第一，判断这到底是不是该做的改动。模型可以告诉你代码对不对，但它判断不了方向。这个判断还在你手里。

第二，高爆炸半径的门禁。错了会很贵的地方，人必须在。

第三，那个没人想到的需求。模型审查的是代码，不是需求。那个「没人记得写下来但真的很重要」的东西，只能靠人。

怎么落地，我自己现在的做法是，让 Claude Code 或 Codex 对一批 incoming PR 做第一轮 triage。哪些看起来安全，哪些需要更多工作，哪些真的高危。我不对结果自动合并，也不对它批准的直接点 merge。它给我的是一种注意力分配方式，花几分钟确认低风险的，把真正认真的时间放在高危的那些上。

这不是我原来那一个小时审查的加速版，这是一个完全不同形状的一小时。但在我现在处理的工作量下，这是整个队列还能撑住的唯一原因。

七件事，能做一件算一件

说点具体的吧。我自己踩过的坑和现在在用的方法。

第一，按风险分层，不按作者分层。 一个配置改动，linter 加扫一眼就过。一个核心业务逻辑的修改，类型检查、测试、两个不同的 AI 审查者、一个拥有这个系统的真人、再加一次安全检查。不要在样板代码上花重审查，也别因为测试绿了就放过大改动。

第二，快速淘汰那些贵的 PR。 Agent 在小改动上很强，大约 28% 几乎可以立刻合并。但它们一旦收到主观反馈就容易失联。别让人在一小时内耗在一个 Agent 会放弃的 PR 上。前置 triage，快放琐碎的，把时间留在真正需要人的改动上。

第三，提高你愿意审的门槛。 拒绝审那些没带证据的改动。审之前要求，改动说明、不是三千五百行的 diff、测试输出、证明它跑过的证据。把意图重建的工作推回给提交者，那里便宜，你这里贵。

第四，故意保持 PR 小。 Agent PR 平均大 51%。大的直接被打回，或者更糟，被橡皮图章。指示你的 Agent 产小 commit。一个人类真的能读完的 diff，现在是一个设计约束。

第五，比代码更仔细地读测试的改动。 这是 Agent 最要命的失败模式。它改行为，然后「修」测试，把断言改成匹配新的错误行为。两百个被编辑的测试上的绿色对勾，什么都不是。先把测试 diff 读一遍。

第六，把 CI 当一堵搬不动的墙。 被删的测试、被跳过的 lint、被降低的覆盖率、不受信任的输入流进 prompt。Agent 也会弱化 CI 让自己通过，不是恶意，就是梯度下降找最便宜的通向绿色的路。确定性门禁是唯一不能被一段自信的文字说服的部分。

第七，merge 按钮归你。 模型不能被报警叫起来，不能为它发布的东西担责。谁点 merge，谁拥有它。AI 审查说「看起来不错」，那是数据，不是决定。

最后

写到这，其实想说的就一句话。

我们花了一年把「写」变便宜了，但「理解」的价格，一分没降。

那些接下来几年跑得好的团队，不是产出代码最多的那群人。是那些建了一个自己真能信的审查系统的人，是那些永远不会把「测试过了」和「我懂这段代码在干什么」搞混的人。

Simon Willison 有句话我一直记得，你的工作是交付你证明过能工作的代码。Agent 没改变这个，它只是把「证明」从边角料变成了核心。

把一件事理解到能站台的程度，可能是软件行业里最持久也最值钱的本事。

现在，是最好的时候。

---

以上，觉得有收获，点个赞、在看、转发支持一下；想不错过更新，记得星标⭐。下次见。
搜索公众号:"知悟之旅"关注我看更多