人工介入越多，智能体代码回滚越多？

人工介入越多，Agent 写的代码反而越容易被回滚。Jellyfish 给出的数据看起来支持这个结论，但作者的解释是：工程师把更多精力投入了高风险变更，不能把风险差异算成人工介入的副作用。

这篇值得读的地方，是它把「人是不是瓶颈」改成了一个更具体的问题：既然团队已经会判断哪些代码需要严查，能不能把这些判断提前写进流程，减少每个 PR 都靠人临场把关的成本？

回滚率翻倍，能证明人工审查有害吗

Jellyfish 分析的 AI 遥测和工程流程数据覆盖 1,300 家公司的 300,000 名开发者。作者观察已合并的 Agent PR，统计它们在一个月内被回滚的比例：

• 无人介入的 PR，回滚率为 0.5%。
• 有人批准的 PR，回滚率为 1.2%。
• 有人深入介入，包括评论、要求修改或提交代码的 PR，回滚率为 2.2%。

每增加一级人工参与，回滚率大约翻倍。但这不是把同一批任务随机交给三种流程的实验。

作者认为，工程师会给变更做风险分流：简单的直接放行，中等风险的看过再批准，危险的才深入处理。最后一组即便有人帮助，仍然更容易出问题，因为它们原本就更难。

人工介入与回滚同时增加，不等于人工介入导致回滚。

作者还表示，在同一家公司、相同 PR 大小的比较中，差距仍然存在。这排除了部分规模和组织差异的解释，却还不能证明各组任务的复杂度、业务风险完全一致。

另一组比较更接近读者真正关心的问题：把无人审查的 Agent PR 与经过审查的相似 PR 对比，回滚、后续修复和缺陷都没有统计显著差异。它支持的是「工程师挑出来放行的那部分工作，质量没有明显下降」，不能直接推广成「所有 Agent PR 都可以免审」。

为什么加一个 AI reviewer，还没省掉人工

原文称，在排名前 10% 的公司中，Agent 已经编写了多数已合并 PR，但其中绝大多数仍需人工签字。这里的排名标准没有说明，不宜自行理解成某种统一的工程能力排名。

压力也在增加。自 2025 年初以来，典型开发者每周的代码审查量增加了 26%，增量几乎全部来自有编程 Agent 参与的工作。注意，这是 Agent 参与编写，不必然代表整份 PR 都由 Agent 独立完成。

AI reviewer 目前也没有明显接走这部分责任。作者观察到，仓库启用 AI reviewer 后，每个 PR 仍有约两次人工审查，合并仍需约三小时。机器人增加了一份意见，人工还是要做决定。

这不等于 AI 审查毫无价值。原文没有给出它对缺陷发现率的对照数据，也没说明不同工具和配置的效果。能确认的结论更窄：在这些观察中，启用它没有明显减少人工审查次数和合并等待。

把风险判断提前，具体要改哪一步

作者提出的路径有三步。

先记录工程师实际怎么分流。什么改动通常直接通过，什么改动一定要追问，什么情况需要亲自检查？把这些经验写下来，才有机会复用。

再把风险判断放进 ticket 或 spec，在 Agent 开始工作前明确。这样，风险可以影响任务范围和验收条件，不必等代码写完、进入 review 才暴露。

最后，按工作类型逐步把判断变成检查。先让检查跟着人工一起跑，记录人工推翻检查结论的频率；等这个频率接近零，再让检查决定这一类工作是否通过。

这里的「接近零」是作者提出的晋级思路。原文没有提供具体阈值、观察周期或实施后的收益数据，也没有证明这条路径已经在他们团队完整跑通。

我的判断

我赞同把反复出现的风险判断沉淀到流程里。相比继续往 PR 上叠机器人评论，它至少直接触及了责任分配：什么情况下可以自动通过，什么情况下必须找人。

但这篇的数据更适合反驳「人越参与，代码越差」，还不足以证明作者提出的改造方案一定能提效。前半段是观察数据，后半段是流程建议，两者要分开看。

尤其不能只看「人工很少推翻检查」。检查和人也可能共同漏掉问题，还需要观察通过后的回滚、修复和缺陷。原文没有披露相似 PR 的匹配细节、各组样本量与显著性检验方法，因果判断仍要保留余地。

对一般团队，现有人工审查可以作为起点。先把重复判断变得明确，再决定哪些责任交给自动检查，比直接取消审批更有依据。

能拿来做什么

• 从近期 Agent PR 中整理实际分流规则，记录哪些改动通常放行、哪些总会触发追问，先形成一份可讨论的标准。
• 给 AI 编程任务写 ticket 时，提前补上风险点和验收条件，让 Agent 开始前就知道哪些约束必须满足。
• 选一类重复出现的工作试跑自动检查，同时记录人工推翻率，以及合并后的回滚和修复情况，再决定是否开放自动通过。
• 评估 AI reviewer 时，把人工审查次数和合并耗时也纳入指标，确认它究竟接走了多少工作。