为什么你的智能体提交的 pull request 被拒了

一组研究者拉取了 33000 个由 AI 编程智能体撰写的 pull request，问了一个很简单的问题：哪些被合并了，哪些胎死腹中？最抢眼的数字是 大约 29% 的智能体 PR 没能合并。但真正有用的发现，是这背后的规律——因为它跟大多数人想当然的并不一样。

人的第一反应是：那些被拒的 PR 里一定是代码有问题。有时候确实是。但这项研究发现，失败的案例集中在另一件完全不同的事情上：被拒的 PR 往往代码改动更大、动到更多文件、而且过不了项目的 CI， 而在相关研究里，功能上正确的代码也照样被拒——理由是 太大、把不相关的改动捆在一起、自己又解释不清楚。 换句话说，智能体常常已经把问题解决了，却还是被挡在门外，因为这个 PR 是一种很糟糕的请求变更的方式。

写出代码，从来都不是合并它的难点

换个角度看。合并不是一次代码事件，而是一次社交事件。一个人类维护者得读懂这个改动、理解它、信任它，并为它负起责任。所有让这件事变容易的东西——一个小而聚焦的 diff；一个连贯的改动；测试通过；一段说清楚改了什么、为什么改的描述——才是让 PR 被接受的关键。一个写出了正确代码、却交出一个庞杂、没解释、CI 还不过的 PR 的智能体，干完了容易的那一半，跳过了真正决定结果的那一半。

而且这不是 AI 才有的规矩。维护者照样会拒掉人类提交的那种又大、范围蔓延、没有解释的 PR。研究只是表明，智能体把这件事做得更频繁、更快、规模更大，因为智能体优化的目标是「拿出一个能跑的方案」，而不是「拿出一个忙碌的人类愿意接受的改动」。这是两个不同的目标，而第二个才是那个合并按钮真正在乎的。

研究找出的那些破绽

其中几个规律具体到可以直接照着办：

• 大就是死。 一个注定失败的 PR，最清晰的信号就是它又大、又动了很多文件。智能体顺手就爱把旁边的东西也重构一遍；评审者最讨厌这个。
• CI 是闸门，不是建议。 失败的 PR 更常构建不过。一个开 PR 前都没先跑测试的智能体，等于在给评审者发出一个信号：「我没检查过。」
• 任务类型能预测成败。 文档、CI、构建配置类的改动合并率最高； 性能优化和 bug 修复合并率最低。 合并率跟着改动有多可验证、多收得住走——而这恰恰是复杂修复所缺的。
• 解释也是工作的一部分。 描述含糊或 对不上号的 PR 更不容易被接受，也拖得更久—— 这就是规格才是产物这件事在评审环节的体现。如果评审者没法很快看清改了什么、为什么改，他就没法低成本地信任它，于是他就不信。

还有一个更安静、值得停下来想想的发现：大多数智能体 PR 其实 几乎得不到什么真正的人类评审，而它们得到的那点评审，越来越多来自其他智能体。当智能体 PR 以百万计的规模涌进来时，人类的评审注意力才是稀缺资源——一个评审起来昂贵的 PR，会输给一个评审起来便宜的 PR，不管谁的代码更好。

拿这个怎么办

如果你正在把编程智能体对准真实的代码仓库，教训很具体：

• 把智能体限制在小而单一目的的 PR 上。 一次只做一个改动，文件尽量少，不要顺手重构。这就是可靠性是会复利的那套逻辑在工作流层面的体现：一个小改动，是人类真的能验证的改动。
• 让它在开 PR 之前就过 CI，而不是之后。 跑测试是产出这个改动的一部分，不是别人另外去做的一个步骤。
• 让它写出评审者需要的那段描述。 改了什么、为什么改、该检查什么。把解释当成一项交付物，因为在评审环节它就是一项交付物。
• 把它对准容易合并的，在难合并的上面盯紧它。 文档、配置、小而收得住的修复，可以放它跑得松一点；性能优化和棘手的 bug 修复，得攥紧手——这些地方正确性难看出来，信任也难挣到。

归根结底

这项研究是一面有用的镜子。我们一直在用「能不能写出能跑的代码」来衡量编程智能体，而它们也确实越来越能。但「能跑」从来都不是被合并的标准——「小、有测试、有解释、好信任」才是。那失败的 29% 大多不是栽在正确性上，而是栽在协作上，而协作是一项模型当初没去优化、得由你来补上的技能。

所以当你的智能体的 PR 被打回来时，别只问「代码对不对」。问那个评审者真正在问的问题：这是不是一个忙碌的人类能够很快看懂、验证、并愿意为之负责的改动？让智能体产出那样的东西，合并率自然就上来了。跳过这一步，你就会一直在交付那种正确、却没人接受的代码——而在一个团队里，这跟没交付是一回事。