---
title: "每个 PR 都要人工 Approve，你就是流水线上最慢的工序 | 行开心的颠倒世界"
description: "Code Review 正在成为 Agent 产码时代的瓶颈。把审查改造成分层放行管道：硬规则与敏感路径一票否决，独立 Agent 挑刺，LLM 仅保留否决权；用小 PR 真实行为验证替代静态审查。先盯住回滚率与漏审率，再逐步放开自动放行。"
canonical: "https://xingkaixin.me/posts/review-bottleneck-pipeline/"
language: "zh-CN"
---

# 每个 PR 都要人工 Approve，你就是流水线上最慢的工序

Code Review 正在成为 Agent 产码时代的瓶颈。把审查改造成分层放行管道：硬规则与敏感路径一票否决，独立 Agent 挑刺，LLM 仅保留否决权；用小 PR 真实行为验证替代静态审查。先盯住回滚率与漏审率，再逐步放开自动放行。

2026年8月26日·1,637 字·5 分钟

[Code Review](https://xingkaixin.me/tags/Code%20Review/)[AI Agent](https://xingkaixin.me/tags/AI%20Agent/)CI/CD工程效能

![每个 PR 都要人工 Approve，你就是流水线上最慢的工序](https://xingkaixin.me/cover/review-bottleneck-pipeline.webp)

![封面：一分钟批准打断二十分钟思路](https://xingkaixin.me/posts/images/review-bottleneck-pipeline/review-bottleneck-pipeline-cover.webp)

上个月写代码写到一半，Slack 弹出来一条：“哥，顺手帮我点个 approve，改动很小。”

我点开 GitHub diff：改了一个枚举名字，顺便在两处调用点加了类型断言。确实很小。没有上下文，但看着合情合理，我点了批准。前后花了不到一分钟。

回到 IDE，我盯着刚才写到一半的 Goroutine 状态机，思路断了，在那儿愣了二十分钟才把上一段逻辑捡起来。

更滑稽的是下午测试群里炸了锅：那个“人畜无害”的枚举改动，在反序列化旧版 Redis 缓存数据时直接抛了空指针。

这就是过去我们很多人的 Code Review 日常：**在毫无上下文的情况下被叫去当人肉橡皮图章，打断了自己的心流，放过了真正的暗坑，出了事故还得在 blame 记录里替那次随手的点击背锅。**

当团队里开始有人（或者 Agent）批量产出 PR 的时候，这个机制就彻底撑不住了。

## 两个 Agent 互审，很容易变成互相糊弄

被 PR 堆死之后，多数人想到的第一招就是“用魔法打败魔法”——起一个 Review Agent，专门去审 Coding Agent 提上来的代码。

我以前拿一个 Python 的 CLI 工具试过这套玩法，让两个 Agent 开着不同 Prompt 在一个 PR 里互掐。

结果相当讽刺。第 1 轮 Reviewer 提意见说异常处理不够优雅，Coding Agent 马上写了个全局 hook；第 2 轮换了个 Reviewer 上下文，嫌 hook 影响吞吐，Coding Agent 又自作聪明地改成递归重试；到第 3 轮，本地一跑直接 `RecursionError` 栈溢出。

连跑了 10 轮，前 9 轮两个 Agent 都在用极其专业的术语互相吹捧和打补丁，PR description 写得天花乱坠，逻辑自洽得像一篇论文，但代码根本跑不通。

![两个 Agent 互相补丁，最后跑出 RecursionError](https://xingkaixin.me/posts/images/review-bottleneck-pipeline/review-bottleneck-pipeline-02.webp)

大模型非常擅长给自己的改动编造合理的解释，而且这种解释往往写得极具说服力。让一个没有运行环境的大模型去静态审查另一个大模型，大部分时候只是两个人在对着幻觉互相签字。

## 硬规则负责把门，LLM 只有否决权

PostHog 去年主仓每个月要吞掉上千个 PR，他们内部最早也在 Slack 开了个 `#dev-stamp-exchange` 频道让人肉互刷印章。后来扛不住了，做了一个叫 StampHog 的机器人。

它最有参考价值的地方不是用了什么牛逼的大模型，而是把权限倒了过来：**放行的决定权在确定性的硬规则手里，大模型从头到尾只有否决权。**

![硬规则先筛选，LLM 只能收紧](https://xingkaixin.me/posts/images/review-bottleneck-pipeline/review-bottleneck-pipeline-01.webp)

一个 PR 想被自动合并，先看它有没有踩雷：

-   路径命中了 `auth`、`billing`、公共 API、环境变量或者迁移脚本？直接出局，必须由 CODEOWNERS 里指定的人肉眼看。
-   有冲突、CI 报错、或者测试覆盖率掉了？直接出局。
-   改动规模太大？StampHog 在主仓里根据 90 天的历史数据把阈值压在 800 行（去掉了测试快照和生成文件），超标的一律交给人。

只有这些死规则全绿了，后面的审查 Agent 才会出来挑刺。Agent 只要看出一处坏味道或者逻辑破绽，就把 PR 挂起转人工。如果它也挑不出毛病，系统才给这个改动盖章。

大模型永远不能拍板说“这块代码虽然碰了支付，但我觉得写得挺好可以合”。它只能在安全的沙盒里帮你收紧口子，不能替你放行危险的改动。

## 别看 Agent 说了什么，看真实请求返回了什么

面对大改动，审查者最容易犯的错误就是去读散文。Agent 写了一大段结构说明、贴了各种 ASCII 架构图，你就觉得它靠谱了。

PostHog 的 Daniel 讲过一个很朴素的原则：**Observation scales better than review（看一次真实运行，比人肉读几千行 diff 顶用得多）。**

![小 PR 与真实请求结果更容易观察](https://xingkaixin.me/posts/images/review-bottleneck-pipeline/review-bottleneck-pipeline-03.webp)

三千行的 diff，人看五分钟就会走神，但看一次真实请求的返回值只需要几秒。

与其逼自己去脑内模拟复杂的数据流，不如把大改动逼着拆成一叠单一职责的小 PR（Stacked PRs）。底层改动加一个字段，跑一次 curl 看返回是不是 200；中层改动加一个接口，看 Datadog 上的耗时分布正不正常。

每一层改动都能独立验证、能独立回滚，早期的问题就没机会在后面层层放大。

## 照搬别人的规则，会把别人的风险偏好当成你的安全线

去看 PostHog 的 `pr-approval-agent` 源码，你会发现他们给自动审批放的口子其实相当大（800 行、30 个文件）。

但你千万别直接把这套数字抄进自己的仓库。

PostHog 敢这么玩，前提是他们整个产品几乎所有功能都套在 Feature Flag 里，配了完备的 Sentry 监控和秒级灰度发布机制。出了线上故障，点一下开关就把流量切断了，他们团队愿意承受“先合并上线、踩坑了再修”的代价。

如果你的系统改坏一次要发全量更新包，或者每次部署都要跑半小时流水线，那这个 800 行的上限会直接送你进 ICU。

落地自己的放行管道，别一上来就建一堆花里胡哨的 Agent：

1.  先去翻翻自己仓库最近三个月回滚过的 PR，看看当时是改了哪几个目录翻的车，老老实实把这些路径写进黑名单；
2.  行数上限先从 30 行、50 行开始试水，只让机器人自动放行纯文档、类型修复、打字错误这类改动；
3.  别盯着“机器人今天帮我们合了多少个 PR”，多盯一盯“自动合并之后触发了多少次紧急回滚”。

没有回滚兜底的自动化，只是在用更高的速度制造生产事故。把安全的体力活交给规则，把清醒的大脑留给真正关键的架构。

* * *

我在持续整理 AI 辅助研发中的流水线治理与防线设计。后面会继续探讨质量守门、自动化放行管道、依赖瘦身与系统可观测性的一手实践。欢迎关注。

## 版权声明

作者

XingKaiXin

标题

每个 PR 都要人工 Approve，你就是流水线上最慢的工序

发布时间

2026年8月26日

文章链接

[https://xingkaixin.me/posts/review-bottleneck-pipeline/](https://xingkaixin.me/posts/review-bottleneck-pipeline/)

本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。

导览

展开导览