# 为什么你的智能体提交的 pull request 被拒了 研究者分析了 33000 个由 AI 编程智能体写的 pull request，大约 29% 始终没能合并。有意思的是原因：多数不是因为代码写错了，而是因为这个 PR 是个糟糕的协作产物——太大、改动太多文件、把不相关的改动捆在一起、CI 不过、自己又解释不清楚。让代码被接受，原来是一项和写代码完全不同的技能，而这恰恰是智能体默认不具备的技能。这对我们怎么用它们意味着什么，下面就讲。 - **Author:** Fedor Chishchin - **Published:** 2026-06-10 - **Tags:** methodology, agents - **Source:** https://fedorthinks.com/zh/blog/why-your-agents-pr-gets-rejected --- 一组研究者拉取了 33000 个由 AI 编程智能体撰写的 pull request，问了一个很简单的问题：哪些被合并了，哪些胎死腹中？最抢眼的数字是 [大约 29% 的智能体 PR 没能合并](https://arxiv.org/abs/2601.15195)。但真正有用的发现，是这背后的规律——因为它跟大多数人想当然的并不一样。 人的第一反应是：那些被拒的 PR 里一定是代码有问题。有时候确实是。但这项研究发现，失败的案例集中在另一件完全不同的事情上：被拒的 PR [往往代码改动更大、动到更多文件、而且过不了项目的 CI](https://arxiv.org/abs/2601.15195)， 而在相关研究里，功能上*正确*的代码也照样被拒——理由是 [太大、把不相关的改动捆在一起、自己又解释不清楚](https://arxiv.org/pdf/2602.00164)。 换句话说，智能体常常已经把问题解决了，却还是被挡在门外，因为这个 PR 是一种很糟糕的*请求*变更的方式。 ## 写出代码，从来都不是合并它的难点 换个角度看。合并不是一次代码事件，而是一次社交事件。一个人类维护者得读懂这个改动、理解它、信任它，并为它负起责任。所有让这件事变容易的东西——一个小而聚焦的 diff；一个连贯的改动；测试通过；一段说清楚改了什么、为什么改的描述——才是让 PR 被接受的关键。一个写出了正确代码、却交出一个庞杂、没解释、CI 还不过的 PR 的智能体，干完了容易的那一半，跳过了真正决定结果的那一半。 而且这不是 AI 才有的规矩。维护者照样会拒掉*人类*提交的那种又大、范围蔓延、没有解释的 PR。研究只是表明，智能体把这件事做得更频繁、更快、规模更大，因为智能体优化的目标是「拿出一个能跑的方案」，而不是「拿出一个忙碌的人类愿意接受的改动」。这是两个不同的目标，而第二个才是那个合并按钮真正在乎的。 ## 研究找出的那些破绽 其中几个规律具体到可以直接照着办： - **大就是死。** 一个注定失败的 PR，最清晰的信号就是它又大、又动了很多文件。智能体顺手就爱把旁边的东西也重构一遍；评审者最讨厌这个。 - **CI 是闸门，不是建议。** 失败的 PR 更常构建不过。一个开 PR 前都没先跑测试的智能体，等于在给评审者发出一个信号：「我没检查过。」 - **任务类型能预测成败。** 文档、CI、构建配置类的改动合并率最高； [性能优化和 bug 修复合并率最低](https://arxiv.org/abs/2601.15195)。 合并率跟着改动有多*可验证、多收得住*走——而这恰恰是复杂修复所缺的。 - **解释也是工作的一部分。** 描述含糊或 [对不上号的 PR 更不容易被接受，也拖得更久](https://arxiv.org/pdf/2602.17084)—— 这就是[规格才是产物](/blog/specs-are-the-artifact)这件事在评审环节的体现。如果评审者没法很快看清改了什么、为什么改，他就没法低成本地信任它，于是他就不信。 还有一个更安静、值得停下来想想的发现：大多数智能体 PR 其实 [几乎得不到什么真正的人类评审](https://arxiv.org/pdf/2602.19441)，而它们得到的那点评审，越来越多来自其他智能体。当智能体 PR 以百万计的规模涌进来时，人类的评审注意力才是稀缺资源——一个评审起来昂贵的 PR，会输给一个评审起来便宜的 PR，不管谁的代码更好。 ## 拿这个怎么办 如果你正在把编程智能体对准真实的代码仓库，教训很具体： - **把智能体限制在小而单一目的的 PR 上。** 一次只做一个改动，文件尽量少，不要顺手重构。这就是[可靠性是会复利的](/blog/smarter-but-not-more-reliable)那套逻辑在工作流层面的体现：一个小改动，是人类真的能验证的改动。 - **让它在开 PR 之前就过 CI，而不是之后。** 跑测试是产出这个改动的一部分，不是别人另外去做的一个步骤。 - **让它写出评审者需要的那段描述。** 改了什么、为什么改、该检查什么。把解释当成一项交付物，因为在评审环节它就是一项交付物。 - **把它对准容易合并的，在难合并的上面盯紧它。** 文档、配置、小而收得住的修复，可以放它跑得松一点；性能优化和棘手的 bug 修复，得攥紧手——这些地方正确性难看出来，信任也难挣到。 ## 归根结底 这项研究是一面有用的镜子。我们一直在用「能不能写出能跑的代码」来衡量编程智能体，而它们也确实越来越能。但「能跑」从来都不是被合并的标准——「小、有测试、有解释、好信任」才是。那失败的 29% 大多不是栽在正确性上，而是栽在协作上，而协作是一项模型当初没去优化、得由你来补上的技能。 所以当你的智能体的 PR 被打回来时，别只问「代码对不对」。问那个评审者真正在问的问题：这是不是一个忙碌的人类能够很快看懂、验证、并愿意为之负责的改动？让智能体产出*那样*的东西，合并率自然就上来了。跳过这一步，你就会一直在交付那种正确、却没人接受的代码——而在一个团队里，这跟没交付是一回事。