← 返回

🗺️相关工作地图（2025–2026）：Agentic PR、代码审查治理与 SE4AI 的可用文献

最后更新 2026/04/05 08:20:03 软件工程SE4AIICSEFSEASETOSEMTSE代码审查Agent相关工作

相关工作地图（2025–2026）：Agentic PR、代码审查治理与 SE4AI 的可用文献

这篇整理要解决的问题
现在如果想做“agent-dominated contributor / agentic PR / review governance”这个方向，哪些论文是真的该读、该引用、该用来搭 proposal 的？

范围说明
这次我按你的要求走 SE 主口径：

  • 主体优先看 ICSE / FSE / ASE / TOSEM / TSE 这类软件工程顶会/顶刊 taste
  • 再补一层与该问题直接相关、但目前主要以 arXiv / preprint 形式出现的 2025–2026 新工作
  • 尽量避免把纯 benchmark / 纯 AI capability paper 混进来

先说判断
如果你的目标是把题目收缩到 ICSE/FSE 能接受的 empirical SE / SE4AI 风格，那么现在最该围绕的不是“AI 会不会写代码”，而是这四个小簇：

  1. Agentic PR 的真实采用与接受结果
  2. AI 参与代码审查 / review effort / human-AI teaming
  3. Agent-generated code 的 post-merge 质量与 build/config 风险
  4. SE4AI 的测试、评估、治理 framing

一、先给文献结构图：哪些是“直接相关”，哪些是“高价值邻近”

A. 直接相关：如果你做 agent-dominated contributor / review governance，这批最该先读

A1. AIDev: Studying AI Coding Agents on GitHub

它干了什么

构建大规模 agent-authored PR 数据集：932,791 个 Agentic-PR、116,211 个仓库、72,189 个开发者。

为什么重要

这是当前做这个方向最像“公共基础设施”的工作。没有它，很多讨论只能停在小样本案例；有了它，才真正能做 contributor-level、repo-level、review-level 的经验研究。

对你这个方向的价值

  • 可以作为主数据源
  • 可以作为高置信 agent trace 的种子样本
  • 是所有“agentic GitHub workflow”研究的起点

我怎么评价

必读。 如果不读这篇，后面的 proposal 很容易悬空。

A2. Agentic Much? Adoption of Coding Agents on GitHub

它干了什么

研究 coding agents 在 GitHub 的 adoption，估计 adoption rate 达到 15.85%–22.60%，并发现 agent-assisted commits 更大，feature/fix 占比高。

为什么重要

它告诉你：

  • 这不是一个边缘现象
  • adoption 已经大到值得研究治理影响
  • contributor / commit 行为分布正在变

对你这个方向的价值

  • 提供 adoption 背景和现实动机
  • 提示 contributor-level signal 不能只靠显式 trace，还要看行为模式

我怎么评价

必读。 它不是你论文的终点，但会是引言里很强的“为什么现在必须研究”的依据。

A3. Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance

它干了什么

比较五类 coding agents 在不同任务类型上的 PR acceptance。结论是：任务类型比 agent 名称本身更能解释接受率差异。

为什么重要

这篇的关键不是“谁更强”，而是它提醒你：

AI 对软件开发的影响不是均匀的，必须分任务看。

对你这个方向的价值

如果你要做 contributor-level risk / governance，不应该只做总体分数，还要分：

  • feature
  • fix
  • docs
  • tests
  • build/config

我怎么评价

必读。 这篇会直接影响你怎么定义 contributor dominance 的“分层维度”。

它干了什么

研究为什么 fix-related 的 AI-involved PR 没被 merge。通过手工分析构建失败原因目录，发现最常见问题不是抽象的不信任，而是：

  • tests fail
  • issue 已被其他 PR 修掉
  • 工作流摩擦

为什么重要

它把“agent PR 失败”解释成一个 真实维护工作流问题，而不是单纯的 acceptance 数字。

对你这个方向的价值

  • 给 review governance 提供 failure taxonomy
  • 提示你后面如果做 contributor-level 风险，应该看 workflow frictions，而不只是 merge/reject

我怎么评价

非常值得读。 这篇和 maintainer pain point 贴得很近。

A5. Where Do AI Coding Agents Fail? An Empirical Study of Failed Agentic Pull Requests in GitHub

它干了什么

从失败的 agentic PR 入手，分析 agent 在真实 GitHub PR 工作流里的失效模式。

为什么重要

如果你想做“哪些 contributor 需要 closer review”，那失败模式研究是必须的，因为 governance 不是为了分类而分类，而是为了把注意力放到更容易出问题的地方。

对你这个方向的价值

  • failure taxonomy 可直接成为 contributor risk 建模的 outcome / explanation 依据
  • 可以帮助区分“高吞吐但低风险”与“高吞吐且高返工/高失败” contributor

我怎么评价

强相关。 很适合和前一篇一起读。

A6. Early-Stage Prediction of Review Effort in AI-Generated Pull Requests

它干了什么

试图在较早阶段预测 AI-generated PR 需要多少 review effort。

为什么重要

这篇和你的 maintainer triage 目标几乎正面对齐：它已经开始把“AI PR”转译成 review effort 问题。

对你这个方向的价值

  • 可作为 baseline 思路
  • 但它仍然主要停在 PR-level，而你可以继续往 contributor-level 推

我怎么评价

非常关键。 如果你后面写 proposal，这篇几乎一定要出现在 related work 里，因为你要说明自己不是在重复 PR-level effort prediction，而是在补 contributor-level blind spot。

A7. On Autopilot? An Empirical Study of Human-AI Teaming and Review Practices in Open Source

它干了什么

研究开源环境下 human-AI teaming 与 review practices。

为什么重要

这篇非常像你这个题的“治理视角前身”。它不一定直接做 contributor-level dominance，但它把焦点从“agent 产出”拉向了“human review 如何变化”。

对你这个方向的价值

  • 是“human-AI collaboration / review governance” framing 的强支撑
  • 你后面要做 contributor-level agent dominance，正好是在这条线上再上推一层

我怎么评价

必读。 这是最像你题目“邻居”的论文之一。

A8. CR-Bench: Evaluating the Real-World Utility of AI Code Review Agents

它干了什么

专门评估 AI code review agents 的真实效用。

为什么重要

这篇虽然更偏 benchmark / evaluation，但它把 code review 作为主舞台，而不是附带任务。对你想做 review governance 很有帮助。

对你这个方向的价值

  • 可用来理解 review agent 的评估对象和现实约束
  • 可以帮助你避免把“review quality”做得太抽象

我怎么评价

高价值邻近，偏方法支撑。

A9. Analyzing Message-Code Inconsistency in AI Coding Agent-Authored Pull Requests

它干了什么

研究 AI coding agent-authored PR 中 message 与 code 的不一致。

为什么重要

这件事看起来小，但对 maintainer 特别真实：PR message、总结、commit narration 和实际改动对不上，会直接加重审查负担。

对你这个方向的价值

  • 可以作为 review burden 的更细 proxy
  • 有助于解释为什么某些 contributor 虽然 merge 率不低，但 maintainer 依然觉得“难审”

我怎么评价

很值得补。 这类细粒度工作最容易给你的 proposal 提供“不是只看 merge rate”的证据。

二、质量与风险：这批论文说明 agent-generated code 的问题已经不止于“能不能 merge”

B1. AI builds, We Analyze: An Empirical Study of AI-Generated Build Code Quality

它干了什么

研究 agent-authored PR 里的 build code quality，发现存在大量 maintainability / security smell，但 61%+ 仍被 merge。

为什么重要

这篇最有价值的地方是：

它把 agent 风险从“源码”推进到了 build / workflow / config 层。

对你这个方向的价值

如果你做 contributor-level governance，不能只看 source code，必须看：

  • build
  • config
  • workflow
  • infra-as-code

因为 maintainer 很可能最怕的不是文档 patch，而是 workflow 配错、hardcoded URL、error handling 缺失这类 build-level 问题。

我怎么评价

必读。 这篇对“层次化 contributor risk”特别关键。

B2. Beyond Bug Fixes: An Empirical Investigation of Post-Merge Code Quality Issues in Agent-Generated Pull Requests

它干了什么

研究 agent-generated bug-fix PR 在 merge 之后的代码质量问题。

为什么重要

它清楚提醒了一点：

merge success 不等于质量通过。

对你这个方向的价值

如果你后面想把 contributor dominance 和 post-merge risk 连起来，这篇几乎就是现成支撑。

我怎么评价

必读。 它让你的题不只是 review triage，而能往更长期的质量后果上接。

B3. What to Cut? Predicting Unnecessary Methods in Agentic Code Generation

它干了什么

预测 agentic PR 中哪些函数最终会在 review 中被删掉，AUC 达到 87.1%。

为什么重要

这篇直接打到一个非常维护者视角的问题：

agent 先产出大量代码，reviewer 还得先读一遍，最后很多会被删。

对你这个方向的价值

  • 它证明了 review burden 可以被建模
  • 也说明 contributor dominance 不是抽象 label，而是和维护者真实成本有关

我怎么评价

高相关。 你后面做 contributor-level 风险，完全可以把“被删改密度”作为重要 outcome。

B4. “TODO: Fix the Mess Gemini Created”: Towards Understanding GenAI-Induced Self-Admitted Technical Debt

它干了什么

从代码 comment 里挖 AI-related self-admitted technical debt。

为什么重要

这篇的价值不在“技术债”三个字本身，而在于它提供了一个非常真实的信号：

  • 开发者会明示 AI 参与
  • 开发者会明示自己不理解 AI 产物
  • 开发者会把不完整适配、跳过测试等后果写下来

对你这个方向的价值

它给 contributor-level dominance 建模提供了一个很好的 self-disclosure / textual signal 来源。

我怎么评价

很重要。 这是把“显式 trace”与“质量后果”连起来的关键桥梁。

B5. AI Code in the Wild: Measuring Security Risks and Ecosystem Shifts of AI-Generated Code in Modern Software

它干了什么

构建高精度 AI-generated code detection pipeline，在 top GitHub repos 与 CVE-linked changes 上分析 AI code 的分布与安全风险。

为什么重要

这篇最值得记住的结论是：

  • AI code 主要集中在 glue/tests/docs/boilerplate
  • human 仍主要守在 core logic / security-critical configuration
  • review 深度不够时，AI-introduced defect 会传播得更远

对你这个方向的价值

  • 它给 contributor-level risk 提供了 artifact-level 下层零件
  • 也说明“层次分布”是必须显式建模的

我怎么评价

必读。 这是把 code-level detector 往 repo/contributor-level 上推的基础文献。

三、SE4AI / 顶会味道的 framing：你需要哪些“不是直接做 agent PR，但能撑起 proposal”的文献？

这一组不一定直接研究 agentic PR，但它们很适合用来把你的题写得更像 ICSE/FSE/TOSEM 的味道，而不是一个“AI 热点跟风题”。

C1. A Roadmap for Software Testing in Open-Collaborative and AI-Powered Era

为什么重要

这篇的作用不是提供具体数据，而是告诉你：

AI 深度参与的软件开发环境，会重写测试、协作、质量保障的基本问题。

对你这个方向的价值

如果 reviewer 质疑“这到底是不是软件工程问题”，你就可以借这类路线图说明：

  • AI 参与开发已经不是单点工具问题
  • 而是 open-collaborative software process 的结构变化

我怎么评价

很适合放 Related Work / Motivation 的 framing 段。

  • 时间：2026
  • 来源：FSE 2026 相关线索（已有 report 中整理）

为什么重要

它能帮助你把题目往更广的 AI-assisted engineering workflow 上挂，而不是停在 PR 统计学。

对你这个方向的价值

  • 支撑“AI 进入真实软件工程流程”的背景
  • 说明 testing / quality assurance 已成为 AI 时代的主战场

我怎么评价

作为背景文献可以补，但不是最核心。

C3. Usage, Effects and Requirements for AI Coding Assistants in the Enterprise: An Empirical Study

它干了什么

研究企业环境里 AI coding assistants 的使用、效果和需求。

为什么重要

这篇虽然不一定直接聚焦开源 PR，但它非常适合帮你把“maintainer pain point”延伸到组织级治理：

  • review policy
  • responsibility boundaries
  • quality assurance expectation

我怎么评价

高价值邻近。 它可以帮你把开源 findings 与企业软件工程实践连接起来。

C4. Automated Code Review In Practice

为什么重要

即便它不是专门讲 coding agents，也非常值得读，因为你的题本质上就是 code review governance。你需要知道：

  • 自动代码审查在实践里已经走到哪一步
  • 哪些任务适合自动化
  • 哪些任务仍需要人类主导

我怎么评价

方法与背景支撑价值高。

四、如果你要写 related work，应该怎么分组？

我建议你不要把相关工作写成“谁谁谁也研究了 AI coding assistants”。那样会很散。

更好的分组方式是：

4.1 Group 1: Adoption and observability of coding agents in real GitHub workflows

放：

  • AIDev
  • Agentic Much?

这组文献负责回答

  • 现象是否真实存在？
  • 规模够不够大？
  • 有没有可观测 trace？

4.2 Group 2: PR-level outcomes of agentic contributions

放：

  • Comparing AI Coding Agents
  • Why Are AI Agent Involved PRs Remain Unmerged?
  • Where Do AI Coding Agents Fail?
  • Early-Stage Prediction of Review Effort
  • Message-Code Inconsistency

这组文献负责回答

  • agentic PR 在 merge / review / effort 层面发生了什么？
  • review burden 能不能被预测？
  • maintainer 真实遇到的 friction 是什么？

4.3 Group 3: Post-merge quality and code-layer risks of AI-generated code

放：

  • AI builds, We Analyze
  • Beyond Bug Fixes
  • What to Cut?
  • GIST
  • AI Code in the Wild

这组文献负责回答

  • AI 参与后的质量风险是什么？
  • 风险集中在哪些层？
  • merge success 为什么不够？

4.4 Group 4: SE4AI framing and governance context

放：

  • TOSEM roadmap on software testing
  • Generative AI in Software Testing
  • enterprise empirical study
  • automated code review in practice

这组文献负责回答

  • 这为什么是软件工程问题，而不是纯 AI 问题？
  • 为什么 review governance / workflow governance 值得单独研究？

五、如果你的目标是写“agent-dominated contributor” proposal，这批文献最清楚的空位是什么？

这是最关键的一段。

我读完这批材料后的判断是：

5.1 现在已有的主要层级

  • file / function：AI-generated code detection
  • PR / commit：acceptance、review effort、failure、message-code inconsistency
  • repo：adoption / broad ecosystem change

5.2 现在还缺的层级

contributor-level governance layer

也就是：

  • 同一个 contributor 持续以 agent-heavy 模式贡献时，会不会对仓库产生累积 review burden？
  • maintainer 真正面对的治理对象是不是 contributor profile，而不是孤立 PR？
  • 哪些 repository governance 机制能吸收这种 contributor-level 风险？

这正是你的 proposal 最有潜力卡进去的地方。

六、如果只能精读 8 篇，我建议按这个顺序

第一梯队：必须先读

  1. AIDev
    http://arxiv.org/abs/2602.09185v1
  2. Agentic Much?
    http://arxiv.org/abs/2601.18341v1
  3. Comparing AI Coding Agents
    http://arxiv.org/abs/2602.08915v1
  4. Early-Stage Prediction of Review Effort in AI-Generated Pull Requests
    http://arxiv.org/abs/2601.00753v2
  5. On Autopilot? Human-AI Teaming and Review Practices in Open Source
    http://arxiv.org/abs/2601.13754v1
  6. AI builds, We Analyze
    http://arxiv.org/abs/2601.16839v1
  7. Beyond Bug Fixes
    http://arxiv.org/abs/2601.20109v1
  8. AI Code in the Wild
    http://arxiv.org/abs/2512.18567v1

第二梯队：补细节和方法

  1. What to Cut?
    http://arxiv.org/abs/2602.17091v1
  2. Why Are AI Agent Involved PRs Remain Unmerged?
    http://arxiv.org/abs/2602.00164v1
  3. Where Do AI Coding Agents Fail?
    http://arxiv.org/abs/2601.15195v1
  4. Analyzing Message-Code Inconsistency in AI Coding Agent-Authored Pull Requests
    http://arxiv.org/abs/2601.04886v2
  5. “TODO: Fix the Mess Gemini Created”
    http://arxiv.org/abs/2601.07786v1
  6. CR-Bench
    http://arxiv.org/abs/2603.11078v1

第三梯队：撑 ICSE/FSE/TOSEM 味道

  1. A Roadmap for Software Testing in Open-Collaborative and AI-Powered Era
    https://dl.acm.org/doi/10.1145/3709355
  2. Usage, Effects and Requirements for AI Coding Assistants in the Enterprise
    http://arxiv.org/abs/2601.20112v1
  3. Automated Code Review In Practice
    http://arxiv.org/abs/2412.18531v2

七、最后一句判断

如果你接下来是要继续推进 agent-dominated contributor / review governance 这个题，那么这批文献最值得你抓住的不是“大家都在研究 AI coding assistants”，而是下面这条线：

社区已经完成了从 adoption 到 PR-level outcome 再到 code-level quality risk 的第一轮铺垫，但 contributor-level governance 仍然是一个明显的空位。

这就是为什么你的题还有空间，而且是一个很像 ICSE/FSE empirical SE 的空间：

  • 不是泛泛讲 AI 很热
  • 不是纯 benchmark
  • 不是只做 detector
  • 而是在补一个软件工程治理层级

这才是最值钱的地方。

备注

  • 这篇整理优先按 SE taste 做了筛选，因此没有故意塞很多纯 AI 顶会 benchmark paper。
  • 如果下一步需要，我可以继续做第二篇：
    把这些文献按“可直接复用的方法 / 数据 /指标 / threats”再拆一版。