从”AI 辅助编码”到”AI 自主提交 PR”
2025 年是 AI 编码工具爆发的一年——Copilot、Cursor、Claude Code 成为开发者的标配。但到了 2026 年，行业已经走到了下一步：AI Agent 不再只是补全代码片段，而是独立完成整个 Pull Request。从理解 Issue、编写代码、生成测试到提交 PR，全流程自主完成。
这引出了一个关键问题：AI Agent 写的代码，到底靠不靠谱？
过去我们只能凭个人经验和零散案例来判断。但现在，MSR 2026（Mining Software Repositories）会议的 Mining Challenge 给出了迄今最大规模的实证数据。多个研究团队基于同一个数据集，从不同角度拆解了 AI Agent 代码的真实质量。
这篇文章就带你深入这些研究成果，看看 24000 多个 Agentic PR 背后藏着什么。
AIDev 数据集：目前最大的 AI 代码质量研究基础
MSR 2026 Mining Challenge 使用的 AIDev 数据集，是目前公开可用的最大规模 Agentic PR 数据集。先看核心数字：
| 维度 | 数值 |
|---|---|
| Agentic PR 数量 | 24,014 个（已合并） |
| 总 Commit 数 | 440,295 个 |
| 人类 PR 对照组 | 5,081 个 |
| 覆盖 Agent | Claude、Copilot、Cursor、Devin、Codex |
| 数据来源 | GitHub 公开仓库 |
| 时间范围 | 2025 年初至 2026 年初 |
数据集的构建方式值得关注：研究团队通过 PR 中的 bot 标签、commit message 模式、以及 Agent 特有的签名信息来识别 Agentic PR，并与人类 PR 进行配对对照。这种设计让研究结论具备了对比基准，而不是孤立地评价 AI 代码。
💡 为什么这个数据集重要：过去关于 AI 代码质量的讨论大多基于个人体感或小样本测试。AIDev 数据集覆盖了多个主流 Agent、多种项目类型和长达一年的时间跨度，让我们第一次可以用数据说话。
五大 Agent 横评：谁在写更多的 PR？
先看各 Agent 的 PR 数量和增长趋势。
PR 数量分布
| Agent | PR 总数 | 峰值月份 | 峰值数量 | 增长趋势 |
|---|---|---|---|---|
| Codex | 最多 | 2025 年 9 月 | 9,089 | 爆发式增长后回落 |
| Copilot | 中等 | — | — | 稳步增长 |
| Claude | 快速增长 | 2026 年 1 月 | 244 | 持续上升 |
| Devin | 中等 | — | — | 稳定 |
| Cursor | 较少 | — | — | 波动 |
Codex 在 2025 年 9 月的爆发非常显眼——单月 9,089 个 PR。这与 OpenAI 在当时加大了 Codex Agent 模式的推广有关。但需要注意的是，PR 数量多不等于质量高，后面的测试覆盖和回退率数据会给出更完整的画面。
Claude 的增长曲线则更稳健：从 2025 年 8 月开始出现在数据集中，到 2026 年 1 月已增长到月均 244 个 PR。虽然总量不大，但增速在五个 Agent 中是最快的。
测试覆盖率对比
测试覆盖是衡量代码质量的核心指标之一。研究论文 “An Empirical Study of Tests in Agentic Pull Requests” 对五大 Agent 的测试生成能力做了详细分析：
| Agent | 测试生成比例 | 变异区间 | 评价 |
|---|---|---|---|
| Devin | 31-34% | 窄 | 最稳定，测试行为可预测 |
| Copilot | 35-44% | 中等 | 上限较高，但波动明显 |
| Codex | 31-58% | 宽 | 差异最大，取决于项目类型 |
| Claude | — | — | 数据量较少，趋势向好 |
| Cursor | — | — | 数据量较少 |
几个关键发现：
Devin 的测试行为最稳定。不管是什么类型的项目，Devin 生成测试的比例都在 31-34% 的窄区间内波动。这说明 Devin 的测试生成策略比较一致——但也意味着它在需要高测试覆盖的场景下不会自动调整策略。
Codex 的变异性最大。31% 到 58% 的区间意味着 Codex 的测试行为高度依赖于上下文。在已有完善测试框架的项目中，Codex 会生成更多测试；在缺乏测试基础设施的项目中，测试比例显著下降。
Copilot 的上限较高。44% 的测试生成比例在五个 Agent 中是最高的，但其波动也不小。结合 Copilot 长期深耕 GitHub 生态的背景，这个成绩算是预期之内。
人类如何审查 AI 代码：一个令人担忧的发现
论文 “These Aren’t the Reviews You’re Looking For” 研究了人类审查 AI PR 时的行为差异，结论令人警醒。
审查松懈效应
研究发现，人类在审查 AI 生成的 PR 时，审查强度普遍低于审查人类 PR。具体表现包括：
- 审查时间更短：对同等规模的 PR，审查 AI 代码的平均时间明显短于审查人类代码
- 评论数更少：AI PR 收到的审查评论数量少于人类 PR
- 一次通过率更高：AI PR 更容易在首次审查后直接合并
这看起来是好事？恰恰相反。研究团队进一步分析发现，审查松懈与后续的代码回退之间存在显著关联——审查越宽松的 AI PR，后续被回退的概率越高。
“形式化审查”陷阱
为什么会这样？研究提出了”形式化审查”假说：
AI 生成的代码通常在表面质量上表现优秀——一致的代码风格、规范的命名、完整的注释、清晰的 PR 描述。这些特征恰好是人类审查者首先关注的维度。当这些维度都”看起来不错”时，审查者倾向于快速通过，而忽略了更深层的问题：
- 逻辑正确性：代码真的实现了预期功能吗？
- 边界条件：极端输入下会不会出问题？
- 架构一致性：新代码和现有系统的设计理念一致吗？
- 隐式依赖：有没有引入不明显的耦合关系？
⚠️ 核心警示：AI 代码的”表面质量高”可能是一把双刃剑。它让代码更易读，但也让审查者放松警惕。团队需要意识到这一点，建立针对 AI 代码的专项审查清单。
失败分析：AI PR 为什么被拒绝
论文 “Where Do AI Coding Agents Fail?” 聚焦于被关闭或拒绝的 Agentic PR，归纳出了几类典型的失败模式。
常见失败模式
| 失败类型 | 典型表现 | 影响程度 |
|---|---|---|
| 需求理解偏差 | 实现了 Issue 字面描述但不符合实际意图 | 高 |
| 边界条件遗漏 | 正常输入工作正常，边界情况崩溃 | 高 |
| 集成冲突 | 单独看没问题，但与现有代码不兼容 | 中 |
| 过度修改 | 改动范围远超需求，引入不相关变更 | 中 |
| 测试不充分 | 测试只覆盖 happy path，缺少异常路径 | 中 |
| 依赖引入不当 | 引入不必要的新依赖或版本冲突 | 低 |
需求理解偏差是最常见也是影响最大的问题。AI Agent 擅长把 Issue 的文字描述转化为代码，但往往缺乏对项目上下文和”言外之意”的理解。一个典型的例子：Issue 描述”优化搜索性能”，AI Agent 可能重写了整个搜索模块，而维护者的实际期望只是加一个缓存层。
过度修改也值得关注。部分 Agent 倾向于在实现需求的同时”顺手”重构周边代码，导致 PR 的改动范围远超预期。对审查者来说，这增加了审查负担；对项目来说，这增加了引入回归的风险。
代码回退的原因
被合并的 AI PR 中，也有一部分后续被回退（revert）。回退的主要原因包括：
- 生产环境暴露问题：本地测试和 CI 通过，但在真实流量下出现性能下降或异常行为
- 隐藏的兼容性问题：与某些特定版本的依赖或运行环境不兼容
- 业务逻辑错误：代码在技术层面正确，但业务逻辑不符合预期
- 副作用未被发现：改动引发了看似不相关的功能异常
这些回退原因有一个共同特征：它们很难通过常规的代码审查发现。这也解释了为什么即使有人工审查，AI PR 的回退率仍然高于人类 PR。
数据背后的深层洞察
把三篇论文的发现串起来看，可以提炼出几个跨维度的洞察。
Agent 特性画像
结合所有数据，我们可以大致勾勒出各 Agent 的特性画像：
| 维度 | Codex | Copilot | Devin | Claude | Cursor |
|---|---|---|---|---|---|
| 产出量 | 极高 | 高 | 中 | 中（快速增长） | 低 |
| 测试稳定性 | 波动大 | 中等 | 稳定 | 数据积累中 | 数据积累中 |
| 适用场景 | 批量任务 | 日常开发 | 端到端交付 | 复杂推理 | 交互式开发 |
| 主要风险 | 质量不均 | 审查依赖 | 上下文边界 | 样本量少 | 数据不足 |
测试覆盖 ≠ 测试质量
一个容易被忽视的点：研究中统计的是测试生成比例（PR 中是否包含测试文件的变更），而不是测试质量。一个 Agent 可以在每个 PR 中都生成测试代码，但如果测试只是在验证最基本的功能而忽略边界条件和异常路径，这样的测试覆盖在实际意义上是打了折扣的。
规模效应与质量的博弈
Codex 的数据揭示了一个有趣的张力：当 Agent 被大规模采用时，代码质量的方差会显著增大。这可能是因为大规模使用场景更加多样化，Agent 在不熟悉的领域表现自然会下降。这对依赖 AI Agent 进行批量代码生产的团队是一个重要警示。
最佳实践：如何安全地使用 AI Agent
基于研究发现，以下是面向开发团队的实操建议。
建立 AI 代码专项审查清单
既然人类在审查 AI 代码时容易”被表面质量蒙蔽”，就需要一个强制性的审查清单来对抗这种倾向：
AI PR 审查清单（建议嵌入 PR Template）：
□ 需求对齐：实现是否匹配 Issue 的实际意图（不仅是字面描述）？
□ 改动范围：是否存在超出需求的"顺手重构"？
□ 边界条件：输入为空、极大值、负值时的行为是否合理？
□ 测试质量：测试是否覆盖了异常路径和边界条件？
□ 集成影响：改动是否影响了其他模块的行为？
□ 依赖变更：是否引入了新依赖？版本是否兼容？
□ 性能影响：是否存在潜在的性能回退？渐进式采用策略
不建议一步到位地让 AI Agent 处理所有类型的任务。推荐的渐进路径如下：
第一阶段：低风险任务
- 文档更新、依赖升级、代码格式化
- 目标：团队熟悉 AI PR 的审查流程
第二阶段：标准功能开发
- 有明确规范的 CRUD 操作、API 端点
- 目标：建立质量基准线，收集回退率数据
第三阶段：复杂功能开发
- 涉及业务逻辑的功能实现
- 目标：评估 Agent 在复杂场景下的表现
配套基础设施
AI Agent 不能孤立使用。必须配套的基础设施包括：
- CI/CD 强制门禁：所有 AI PR 必须通过完整的自动化测试流水线
- 回退率监控：定期统计 AI PR 的回退率，设置告警阈值
- Agent 标签：在 PR 中明确标注使用了哪个 Agent，便于后续分析
- 审查轮次追踪：记录每个 AI PR 的审查轮次和评论密度
总结与展望
MSR 2026 的这批研究论文，第一次用大规模数据回答了”AI Agent 代码质量到底怎么样”这个问题。答案不是简单的好或坏，而是一幅复杂的图景：
- AI Agent 已经能产出大量可合并的代码，但质量方差显著
- 人类审查者在面对 AI 代码时存在系统性的审查松懈
- 测试覆盖在不同 Agent 之间差异巨大，且覆盖率不等于质量
- 代码回退仍然是一个需要持续关注的问题
对开发团队来说，核心启示是：AI Agent 是强大的生产力工具，但不是无需监管的自动化系统。建立针对性的审查流程、监控回退率、渐进式扩展使用范围——这些才是让 AI Agent 真正发挥价值的关键。
随着 Agent 能力的持续进化和更多实证数据的积累，我们有理由期待这些问题会逐步改善。但在当下，数据驱动的审慎乐观是最合理的态度。