从以人为中心到智能体化代码审查：不同代际生成式AI对审查质量的影响 From Human-Centric to Agentic Code Review: The Impact of Different Generations of Generative AI Technology on Review Quality
百万级PR实证研究：LLM/Agent代码审查的采纳实践、协作模式与质量权衡
前置知识
Modern Code Review（现代代码审查）
指基于 Pull Request（PR）的轻量级代码审查范式：开发者在合并前把代码变更提交为 PR，由其他开发者（或机器人）逐行评论、要求修改，最终决定接受（merge）或拒绝（close）。GitHub、GitLab 等平台是其典型载体。审查评论、审查者身份、提交时间和最终决策都会被平台记录，因而可被大规模挖掘分析。
本文的全部数据来自 GitHub PR 的审查对话，理解「PR + 评论 + 决策」这一基本单元是读懂后续所有分析（协作序列、坏味道、效率）的前提。
Code Review Smells（代码审查坏味道）
类比代码坏味道，指审查流程中可观测的反模式，可能降低审查有效性、引入质量风险。本文沿用 Doğan 和 Tüzün 的分类并改造出 6 类可机器判定的坏味道：Sleeping Review（PR 创建到最终决策超 2 天）、Review Buddies（同一审查者审查某作者 ≥50% 的 PR）、Large Changeset（变更超 500 行）、Ping-Pong（超过 3 轮 change-request 来回）、Missing Context（PR 描述为空或缺少关联 issue）、Lack of Review（除作者外无人参与）。
坏味道是本文衡量「审查质量」的核心指标之一（另一个是审查效率）。所有关于「AI 是否让审查变好/变差」的结论，本质都是在比较各实践/各时代下坏味道的流行率变化。
LLM Reviewer vs AI Agent Reviewer（LLM 审查者 vs 智能体审查者）
LLM 审查者指仅根据代码变更生成自然语言评论的早期生成式 AI（如 LlamaPReview），本质是「单轮文本生成」。AI Agent 审查者（如 Claude Code、GitHub Copilot coding agent）则能自主检索项目上下文、运行开发工具、执行提交动作并验证发现后再产出反馈，具备规划-检索-执行-验证的完整闭环。本文通过对 384 个 Agent 时代 PR 的人工抽样（95% 置信度、5% 误差）验证了这一区分。
本文提出的「三时代」（Pre-LLM / LLM / Agent）划分正是基于这两类审查者的首次参与时间。理解 LLM 与 Agent 在能力边界上的本质差异，才能解释为什么「智能体时代」效率提升而坏味道也上升。
soft-DTW 时间序列聚类
Dynamic Time Warping（动态时间规整，DTW）是一种衡量两条时间序列相似度的方法，允许时间轴非线性对齐。soft-DTW 是其可微分、更平滑的变体。本文用每个项目「各时代 GenAI 审查者参与率」序列（先用线性插值重采样为每时代 10 个点再拼接），用 soft-DTW 距离做 k-means 式聚类，把 207 个项目归为三类采纳实践。
RQ1 的「三种 AI 采纳实践」就是这套聚类的产物。聚类质量用轮廓系数 0.40 评估（属于「尚可分离」）。理解这一点才能判断分类是否可信，以及结论是否依赖这一步。
Markov 链 + EM 协作模式挖掘
把每个 PR 表示成「审查者类型按时间顺序排列」的序列（如 Human→Agent→Human→accepted），用 Markov 链建模「首类审查者分布 + 类别间转移概率」。期望最大化（EM）同时拟合多条 Markov 链，把每条序列分配给最能解释其转移的那条链，从而把成千上万条序列归并为若干「协作模式」。模式数量用 BIC（贝叶斯信息准则）选取，本文选 10 个。
RQ2 的核心创新就是把「谁、何时、以什么顺序审查」抽象成可复用的协作模式。这是本文区别于以往「AI 是否参与」二元判断的关键，读者必须理解 Markov+EM 才能看懂 Table V 和 RQ2 的全部结论。
研究动机
随着生成式 AI 大规模进入软件开发，代码审查正从纯人工流程转向「人 + LLM + 智能体」协作流程。Google 报告其新代码中已有 75% 由 AI 生成，GitHub 称 2025 年开发者推送近 10 亿次提交、使用 LLM SDK 的公开仓库同比增长 178%。Google Cloud 与 Amazon 的技术博客都已警告：代码生成变快反而会淹没人类审查者和交付流水线，审查与集成正成为新的瓶颈。然而既有研究存在三块空白：第一，大多数 LLM 审查研究只评估单一工具在特定场景的表现，Cihan 等人甚至发现 LLM 辅助审查反而增加了 PR 审查时间；第二，几乎没有工作刻画「团队在时间维度上如何采纳 LLM 与智能体审查者」「人/LLM/Agent 在单个 PR 内究竟如何协作」；第三，缺乏把「AI 协作模式」与「传统审查因素」（如变更规模、审查者经验）放在一起、判断谁更能解释审查效率与质量的实证证据。因此业界在决定「要不要上 AI 审查、怎么上」时几乎没有大规模量化依据。
本文的目标是本文要在 207 个开源 GitHub 项目、102 万条已审查 PR 的大规模纵向数据上，回答三个递进的研究问题。RQ1：识别常见的 AI 审查者采纳实践，并量化每种实践与审查质量（效率 + 坏味道）的关系。RQ2：刻画单个 PR 内「人-LLM-智能体」的协作模式，比较各协作模式在效率与坏味道上是否优于纯人工审查。RQ3：在传统审查因素（PR 特征、审查活动、参与者经验）的背景下，判断 AI 协作模式是否仍是解释审查质量的强因素，从而为团队设计「既提速又不掉质量」的 AI 审查流程提供经验依据。整体目标是用可量化的数据指导实践者按 PR 上下文选择性地引入 AI 审查者，而不是一刀切。
与已有工作不同的是，本文的独特切入点有三层。其一是「纵向三时代」视角：以每个项目首个 LLM 审查者、首个智能体审查者的参与时间为锚，定义 Pre-LLM/LLM/Agent 三个时代，使不同项目之间可在同一相对时间轴上比较，而不是简单按日历时间切分。其二是「序列即模式」：以往研究只用「AI 是否参与」这种二元变量，本文把 PR 内审查者类型按时间戳排成有序序列，再用 Markov 链 + EM 抽象为可复现的协作模式，捕捉到「Agent 先发言-人补一句-接受」这类被二元变量完全丢掉的结构。其三是「联合建模」：把 AI 协作模式与 pull request 特征、审查活动、参与者经验一起塞进逻辑回归，用似然比卡方与 Impact Score（Imp%）剥离出 AI 协作本身的净效应，这是首次对「智能体化代码审查」进行的大规模定量研究。
核心方法
可以把它想象成「给 207 个项目拍一部审查史纪录片，再用统计方法逐帧打分」。直觉上：先从 GitHub 高级搜索筛出 2490 个候选项目，按「每时代 ≥400 条已审查 PR」的严格标准留下 207 个、共 102 万条 PR；接着给每条评论打上审查者类型标签（人/规则机器人/传统ML/LLM/智能体），并为每个项目划定三个时代；然后从两条线分析——项目级用 soft-DTW 聚类找「采纳实践」，PR 级用 Markov 链 + EM 找「协作模式」；最后用逻辑回归把协作模式与传统因素一起建模，用 Impact Score 量化每个因素对效率与坏味道的相对贡献。整条流水线的产出同时服务于三个 RQ，效率与坏味道指标在三个 RQ 间共享。
全文最核心的洞见是：评估 AI 审查不能只看「AI 参与了没有」，而要看「谁、何时、以什么顺序参与」——也就是把审查者类型序列化。基于此，本文用 Markov 链把「人→Agent→人→accepted」「人→LLM→人→人→…」这类序列聚成 10 个协作模式（如 Agent-Init、Multi-Agent、LLM-Assist、Human-Bot 等），再比较各模式相对 Human-Only 的效率与坏味道差异。这一序列化视角让作者能发现「Agent 先发起或多个 Agent 协作时审查更快」「但 AI 参与的模式坏味道流行率系统性更高」这类二元变量无法揭示的结论。和以往「拿某工具在样本上跑指标」的孤立评估相比，本文是在真实项目的纵向演化里看协作结构本身的质量含义，这是本质区别。
方法步骤详情
第一步项目筛选：GitHub 高级搜索得到 2490 个 2022-05 至 2026-02 持续活跃、≥100 star、ChatGPT 发布前已创建的候选项目。第二步数据采集与审查者标注：用 GitHub REST API 拉取审查事件、评论与决策；按 API 区分人/bot，再人工核对工具文档把 bot 细分为规则机器人（GitHub Actions）、传统 ML（CodeGuru Reviewer）、LLM（LlamaPReview）、智能体（Claude Code），并用 384 条抽样（95% 置信度、5% 误差）验证 Agent 行为。第三步定义三时代：每个项目按「首个 LLM/首个 Agent 参与的 PR」切分 Pre-LLM/LLM/Agent，仅留每时代 ≥400 条 PR 的项目，最终 207 个、102 万条。第四步 PR 分类：用 GPT-4.1-mini 按 11 类打标签，Cohen's κ=0.91。第五步构造质量指标：效率 $\text{Review Efficiency}=(T_{\text{decision}}-T_{\text{creation}})/\#\text{KLOC}$，坏味道用 6 条规则判定。最后 RQ1 用 soft-DTW 聚类得采纳实践，RQ2 用 Markov 链+EM（BIC 选 10 模式）+ Scott-Knott ESD 排效率，RQ3 对每个「实践×时代」训练逻辑回归（VIF<5、10% 留出测 AUC），用似然比卡方筛选变量，用 $\text{Imp}\%=(P_{\text{changed}}-P_{\text{base}})/P_{\text{base}}\times 100\%$ 量化相对影响。
技术新颖性
新颖性体现在三方面。首先是研究对象：本文自称是「首个对智能体化代码审查的大规模定量研究」，明确把 Pre-LLM/LLM/Agent 三个时代放在一起纵向比较，而既有工作要么只看人类审查、要么只评估某个 LLM 工具。其次是建模单元：用 Markov 链 + EM 把审查者类型序列抽象为协作模式，捕捉交互顺序结构，这在软件工程流程挖掘（trace clustering）之外几乎是首次系统用于 AI 审查。第三是解释力设计：用 Impact Score（Imp%）把量纲不同的变量（评论数、commit 数、是否 Agent-Init）放到同一百分比标尺上直接比较，并用似然比卡方逐变量评估边际贡献，从而能把「AI 协作的净效应」与「传统因素的净效应」分离。不过方法整体仍属经验分析，依赖 GitHub 公开数据与既有坏味道/PR 分类体系，没有提出新算法。
实验结果
RQ1 识别三种采纳实践：Gradual AI Adoption（46%/95 项目，Agent 时代参与率 36%）、Rapid LLM Adoption（22%/45 项目，参与率 91%、93%）、Rapid AI Agent Adoption（32%/67 项目，含 Microsoft 12、Google 3 个）。效率上，从 Pre-LLM 到 Agent 时代 Gradual AI 提速 2.5 days/KLOC、Rapid AI Agent 提速 4.5，而 Rapid LLM 无显著变化——早期重度依赖 LLM 不带来效率红利。坏味道上 Rapid LLM 显著上升（LLM 时代 +8.0、Agent 时代 +4.4 个百分点），Review Buddies 涨 26%、23.2%；另两种实践无显著恶化。RQ2 得 10 个协作模式：Agent 时代 Agent-Init、Multi-Agent 在 Gradual AI 与 Rapid AI Agent 下显著快于 Human-Only（Agent 在 75%–95% 此类 PR 中先给摘要、人仅回一句即合并），但 Rapid LLM 下 Human-Only 最快（61% 两轮内解决）。代价是坏味道：Human-Only 69%–76%，含 AI 模式高达 78%–94%，主因 Review Buddies（16%→53%–60%）。RQ3 显示传统因素（author experience、commit 数、inline 线程）三时代持续重要；agent 模式在 Gradual/Rapid AI Agent 下把 Review Delay 降 37%–50%、Sleeping Review 降 16%–48%，却把 Review Buddies 推高 200%–678%、Large Changeset 推高 20%–54%。核心结论：效率红利并不等于质量红利。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 审查效率（Agent 时代相对 Pre-LLM 基线） | days/KLOC 变化 | Gradual AI Adoption -2.5；Rapid AI Agent Adoption -4.5 | Pre-LLM 时代同项目（Gradual 8.5、Rapid AI Agent 10.4 days/KLOC） | Gradual AI 与 Rapid AI Agent 显著提速，最高 4.5 days/KLOC；Rapid LLM Adoption 无显著变化 |
| 整体审查坏味道流行率变化 | smell 百分点变化（Wilcoxon + Bonferroni） | Rapid LLM：LLM 时代 +8.0、Agent 时代 +4.4 个百分点 | Pre-LLM 同项目基线（约 81%–84%） | 负面：仅 Rapid LLM Adoption 显著恶化；Gradual AI、Rapid AI Agent 无显著上升 |
| Review Buddies 坏味道变化 | Review Buddies 百分点变化 | Rapid LLM：LLM 时代 +26.0、Agent 时代 +23.2 个百分点 | Pre-LLM 同项目基线 | 负面：反复依赖同一 LLM 审查者窄化视角，是质量恶化的主因 |
| 协作模式的坏味道流行率（PR 级） | 至少一种 smell 的 PR 比例 | 含 AI 的协作模式 78%–94%（Review Buddies 平均 53%–60%） | Human-Only 69%–76%（Review Buddies 16%） | 负面：AI 参与模式坏味道系统性更高，效率与质量出现权衡 |
| Agent 时代协作模式对 Review Delay 的净效应（RQ3） | Impact Score Imp% | Multi-Agent -50（Gradual）、-13（Rapid Agent）；Agent-Init -37（Gradual）、-16（Rapid Agent） | Rapid LLM Adoption 下 +37（Multi-Agent）、+39（Agent-Init），反而变慢 | 在 Gradual/Rapid AI Agent 下净降审查延迟最高 50%；Rapid LLM 下恶化 |
| PR 类型自动分类可靠性 | Cohen's κ（人工 vs GPT-4.1-mini） | 0.91 | 384 条人工标注（95% 置信度、5% 误差） | 「几乎完美一致」，支撑后续 PR 类型分析的可靠性 |
局限与改进
作者在 Threats to Validity 中明确承认：第一，构念效度上「Agent 时代」只表示项目在该时段首次出现了智能体审查者，并不保证此后每条评论都来自智能体，部分 PR 仍可能含 LLM 审查者，因此时代标签是时间维度的近似而非严格分类。第二，RQ3 的逻辑回归是解释性而非因果性，Imp% 只反映统计关联，改变某因素未必直接改变结果。第三，外部效度上 AI 工具能力演化极快，当前观察到的协作模式与质量关联可能随工具升级而漂移。我额外观察到的局限：坏味道只是流程层代理指标，并不直接度量「抓到了多少缺陷」「评论是否有用」；坏味道分类本是为人类审查设计的，套用到 AI 审查上可能漏掉 AI 特有的反模式（如幻觉式评论、无意义套话）；数据未区分 PR 是被接受还是被拒绝，而拒绝的 PR 与接受的 PR 在效率/质量上的含义本就不同；样本虽大但偏向「活跃且 star≥100」的成熟开源项目，对闭源企业代码、小众项目的代表性有限。
独立分析的弱点
第一个弱点是「质量」指标过窄：只有效率（days/KLOC）和六类坏味道，没有度量审查评论的有用性、缺陷检出率或 post-merge 缺陷密度，因此「效率提升但坏味道上升」能否真正等价于「质量没掉」其实存疑。改进方向是引入评论有用性打分（如被采纳/触发代码修改的比例）与 post-release 缺陷数据做三角验证。第二个弱点是「为什么」缺位：本文只观察到协作模式的统计关联，没解释开发者为何选某模式（是出于工具默认配置、还是主动策略）。改进方向是结合访谈或配置文件分析挖掘决策动因。第三个弱点是单快照聚类：soft-DTW 把整段时间序列压成一个簇标签，忽略了同一项目内部采纳路径的非单调波动（如先用后弃、反复切换）。改进方向是引入变点检测或分段聚类。第四个弱点是时代边界依赖「首次参与」这一离散事件，对偶发试验性评论很敏感。改进方向是改用连续的参与率阈值或贝叶斯变点检测。第五个弱点是未区分接受/拒绝 PR，二者在效率与坏味道上的语义差异被掩盖，建议分层重做分析。
未来方向
作者明确提出的方向有三：一是研究开发者选择不同人-AI 审查实践背后的决策动因（访谈/问卷）；二是构建反映 PR 上下文（维护、修 bug、重构、大变更）的基准，避免只用通用「找问题」能力评估 AI 审查者；三是探索智能体审查如何在提速的同时保持人类审查建立的质量标准。基于本文成果可延伸的方向还包括：把 Review Buddies 的发现转化为「审查者多样性」约束，设计多智能体分工的审查流水线；用本文公开的纵向数据集训练「何时该让 Agent 先发言」的策略模型；跟踪工具升级（如更强的 coding agent）对协作模式分布的漂移，定期重跑本文流水线作为行业基线。
复现评估
复现门槛中等偏友好。作者已发布复现包（anonymous.4open.science 上的 CodeReviewEvolve 仓库），并承诺包含纵向数据集。数据源是公开的 GitHub REST API，PR/评论/决策字段都可重新抓取；项目筛选规则（≥100 star、每时代 ≥400 PR、2022-05 至 2026-02 持续活跃）公开透明，2490→207 的过滤可复算。关键依赖是 GPT-4.1-mini 做 PR 分类与 reviewer 标注的人工核对（κ=0.91 可对照），需要付费 API 与一定人工标注成本。统计方法（soft-DTW、Markov+EM、Scott-Knott ESD、逻辑回归、似然比卡方、Imp%）均有成熟开源实现，算力需求很低（无需 GPU）。主要不确定性在于「Agent 时代」标签依赖对 Claude Code 等工具的逐项目人工识别，以及 GitHub 评论数据的去重与清洗细节是否在复现包中完整披露。
论文图表
列出本文采用的 6 类坏味道（Sleeping Review、Review Buddies、Large Changeset、Ping-Pong、Missing Context、Lack of Review）及其潜在副作用和可机器执行的检测规则（如 Sleeping Review = PR 创建到决策 >2 天；Review Buddies = 同一审查者审查某作者 ≥50% PR；Large Changeset = 变更 >500 行）。
坏味道是本文衡量审查质量的核心维度之一，所有「质量变好/变差」的结论都依赖这张表里的判定规则，读者必须据此才能验证 Table IV、Table V、Table VI 的数字。
按三种采纳实践 × 三时代，给出含 AI 的 PR 比例、审查效率（days/KLOC）、坏味道流行率（Smell%）、Review Buddies%（RevBud%），以及哪些 PR 类型显著增多（如 Gradual AI 的 Agent 时代 feat↑refac↑fix↑；Rapid LLM 的 LLM 时代 docs↑build↑perf↑style↑）。星号标记 Wilcoxon 显著变化。
这是 RQ1 的主结果表，集中回答「不同采纳实践在各时代的效率与坏味道如何变化」，是判断「该不该、怎么上 AI 审查」最直接的证据来源。
对 10 个协作模式（Human-Only、Human-Bot、LLM-Assist、Multi-LLM、LLM-Bot-Assist、Agent-Init、Agent-Assist、Multi-Agent、Agent-ML-Assist 等），在三种实践 × 三时代下给出 Scott-Knott ESD 效率排名（R1 最快）、坏味道流行率（Smell%），以及相对 Human-Only 显著多/少的 PR 类型。
这是 RQ2 的核心表，直接展示「哪些协作模式更快、哪些坏味道更高」，是理解「效率与质量权衡」这一全文主旨的关键，也是 Table VI 解释性建模的输入。
RQ3 的逻辑回归 Impact Score（Imp%）矩阵，覆盖四个结果（Lack of Efficiency、Review Buddies、Sleeping Review、Large Changeset）× 三实践 × 三时代，绿色=显著变好、红色=显著变差、空白=不显著。例如 Agent 时代 Multi-Agent 对 Review Delay 的 Imp% 为 -50（Gradual）、+37（Rapid LLM）、-13（Rapid Agent）。
这张表回答了全文最具决策意义的问题——「AI 协作的净效应到底有多大、传统因素还重不重要」，是作者给出「AI 与传统实践应平衡使用」建议的定量依据，也是读者判断结论是否被混淆因素驱动的主要证据。