2.5 万个 Agent PR 说明了什么：项目流程比模型能力更决定结果

大量 Agent PR 指向一个很朴素的结论：AI 编码能不能稳定合入，更多取决于项目流程，而不是某一次模型输出有多漂亮。仓库有没有清晰测试，任务边界是否足够小，代码风格是否能自动检查，评审者能不能快速看懂改动，这些因素会直接决定 PR 是被合入、被反复要求修改，还是被关闭。

模型可以写代码，但它不能替团队补工程纪律。没有复现步骤、没有验收标准、没有测试命令的任务，交给人也容易失控，交给 Agent 只会把失控速度放大。

适合 Agent 的任务通常足够具体：修一个明确 bug、补一个小功能、迁移一个清楚接口、补一组测试、改一段结构明确的文案。这类任务有输入、有预期输出，也有自动化验证。Agent 即使走错一步，也比较容易通过测试、diff 和人工评审纠正。

不适合的任务往往是“把这个模块优化一下”“重构体验”“提升质量”这种大而模糊的要求。模型会开始猜需求、扩散改动，最后 PR 看起来很努力，但评审成本很高，合入风险也大。

• 把任务拆到一个 PR 内可以审完。
• 给出失败日志、复现命令和目标文件范围。
• 让 lint、typecheck、unit test、build 能稳定运行。
• 要求 PR 写清楚真实验证结果，而不是只描述改动。
• 对支付、权限、数据删除和部署脚本设置人工审批。

这些准备听起来普通，却决定 Agent 是工程工具还是随机贡献者。项目越能把需求写清楚、把验证自动化、把边界限制住，AI 编码越容易产生可合入的增量。

Agent PR 的价值不是取消评审，而是把一部分机械实现、重复排查和测试补全前移。评审者仍然要看业务意图、边界条件、安全影响和长期维护成本。好的流程会让 Agent 提供证据，坏的流程只会让 Agent 提供更多需要人猜的 diff。

所以，2.5 万个 PR 最值得看的不是“AI 写了多少代码”，而是哪些仓库让 AI 改动变得可审、可测、可回滚。模型能力会继续提高，但没有项目纪律的仓库，仍然很难从 Agent 身上拿到稳定收益。