上个月写代码写到一半，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 写得天花乱坠，逻辑自洽得像一篇论文，但代码根本跑不通。
大模型非常擅长给自己的改动编造合理的解释，而且这种解释往往写得极具说服力。让一个没有运行环境的大模型去静态审查另一个大模型，大部分时候只是两个人在对着幻觉互相签字。
硬规则负责把门，LLM 只有否决权
PostHog 去年主仓每个月要吞掉上千个 PR，他们内部最早也在 Slack 开了个 #dev-stamp-exchange 频道让人肉互刷印章。后来扛不住了，做了一个叫 StampHog 的机器人。
它最有参考价值的地方不是用了什么牛逼的大模型，而是把权限倒了过来：放行的决定权在确定性的硬规则手里，大模型从头到尾只有否决权。
一个 PR 想被自动合并，先看它有没有踩雷：
- 路径命中了
auth、billing、公共 API、环境变量或者迁移脚本？直接出局，必须由 CODEOWNERS 里指定的人肉眼看。 - 有冲突、CI 报错、或者测试覆盖率掉了？直接出局。
- 改动规模太大？StampHog 在主仓里根据 90 天的历史数据把阈值压在 800 行（去掉了测试快照和生成文件），超标的一律交给人。
只有这些死规则全绿了，后面的审查 Agent 才会出来挑刺。Agent 只要看出一处坏味道或者逻辑破绽，就把 PR 挂起转人工。如果它也挑不出毛病，系统才给这个改动盖章。
大模型永远不能拍板说“这块代码虽然碰了支付，但我觉得写得挺好可以合”。它只能在安全的沙盒里帮你收紧口子，不能替你放行危险的改动。
别看 Agent 说了什么，看真实请求返回了什么
面对大改动，审查者最容易犯的错误就是去读散文。Agent 写了一大段结构说明、贴了各种 ASCII 架构图，你就觉得它靠谱了。
PostHog 的 Daniel 讲过一个很朴素的原则：Observation scales better than review（看一次真实运行，比人肉读几千行 diff 顶用得多）。
三千行的 diff，人看五分钟就会走神，但看一次真实请求的返回值只需要几秒。
与其逼自己去脑内模拟复杂的数据流，不如把大改动逼着拆成一叠单一职责的小 PR（Stacked PRs）。底层改动加一个字段，跑一次 curl 看返回是不是 200；中层改动加一个接口，看 Datadog 上的耗时分布正不正常。
每一层改动都能独立验证、能独立回滚，早期的问题就没机会在后面层层放大。
照搬别人的规则，会把别人的风险偏好当成你的安全线
去看 PostHog 的 pr-approval-agent 源码，你会发现他们给自动审批放的口子其实相当大（800 行、30 个文件）。
但你千万别直接把这套数字抄进自己的仓库。
PostHog 敢这么玩，前提是他们整个产品几乎所有功能都套在 Feature Flag 里，配了完备的 Sentry 监控和秒级灰度发布机制。出了线上故障，点一下开关就把流量切断了，他们团队愿意承受“先合并上线、踩坑了再修”的代价。
如果你的系统改坏一次要发全量更新包，或者每次部署都要跑半小时流水线，那这个 800 行的上限会直接送你进 ICU。
落地自己的放行管道，别一上来就建一堆花里胡哨的 Agent：
- 先去翻翻自己仓库最近三个月回滚过的 PR，看看当时是改了哪几个目录翻的车，老老实实把这些路径写进黑名单；
- 行数上限先从 30 行、50 行开始试水，只让机器人自动放行纯文档、类型修复、打字错误这类改动；
- 别盯着“机器人今天帮我们合了多少个 PR”，多盯一盯“自动合并之后触发了多少次紧急回滚”。
没有回滚兜底的自动化，只是在用更高的速度制造生产事故。把安全的体力活交给规则，把清醒的大脑留给真正关键的架构。
我在持续整理 AI 辅助研发中的流水线治理与防线设计。后面会继续探讨质量守门、自动化放行管道、依赖瘦身与系统可观测性的一手实践。欢迎关注。