智能体代码审查中的人机协同研究 Human-AI Synergy in Agentic Code Review
分析27.8万次代码审查对话，对比AI与人类审查者的反馈差异、协作模式和建议质量。
前置知识
代码审查（Code Review）
代码审查是软件工程中的核心实践，指开发者在代码合并到主分支之前，由其他开发者或自动化工具检查代码变更的过程。审查者会提供反馈意见，包括潜在缺陷、代码改进建议、设计问题等，通过多轮讨论达成共识。现代代码审查通常通过 Pull Request 或 Merge Request 的形式进行，审查可以发生在 PR 级别（整体变更）或内联级别（针对具体代码块）。
本文研究对象就是代码审查对话，理解代码审查的基本流程和价值才能读懂论文的研究动机和发现。论文主要关注内联审查（Inline Code Review），因为这种审查直接附着在具体的代码变更上，可以精确追踪反馈对代码的影响。
代码块（Code Hunk）
代码块是指代码变更中的连续修改区域，通常以 diff 格式显示，包含被删除的行（以 - 开头）和新增的行（以 + 开头）。例如，在 Git diff 输出中，`@@ -45,7 +45,7 @@` 标记了一个代码块的起始位置，表示从第45行开始有7行被替换为7行新行。代码块是代码审查的最小粒度单位，每个内联审查评论都针对一个特定的代码块。
论文中的所有审查对话都是基于代码块的，Comment-to-Code Density 指标（评论长度与代码块大小的比值）就是基于代码块的行数计算的。理解代码块的概念有助于理解论文如何精确度量 AI 和人类审查者的评论详尽程度。
有限状态机（Finite State Machine, FSM）
有限状态机是一种数学模型，用于描述系统在不同状态之间转换的规律。FSM 由状态集合、转换函数和终止条件组成。在软件工程过程挖掘中，FSM 常用于建模重复出现的序列模式，例如工作流中的审批流程。每个状态代表系统的一种配置，转换表示状态之间的合法变迁。
论文使用 FSM 来建模代码审查中的交互模式，将人类评论（H）、AI 评论（A）、接受（ACC）和拒绝（REJ）作为状态，分析评论如何在参与者之间流转直至最终结果。这种建模方法使研究者能够量化不同协作模式的成功率和交互复杂度。
圈复杂度（Cyclomatic Complexity）
圈复杂度是一种软件度量指标，由 Thomas McCabe 提出，用于量化代码中的线性独立路径数量。计算公式为 $CC = E - N + 2P$，其中 $E$ 是边数（控制流边），$N$ 是节点数（基本块），$P$ 是连通分量数。在实际应用中，圈复杂度通常等于代码中分支语句（如 if、switch、while、for）的数量加一。高圈复杂度意味着代码包含更多条件分支，测试和维护难度增加。
论文使用圈复杂度作为代码质量的关键指标之一，发现被采纳的 AI 建议会导致圈复杂度平均增加 0.085-0.106，而人类建议的增加幅度较小。这个发现对评估 AI 代码建议的质量影响至关重要，因为过度增加复杂度会损害代码的可维护性。
研究动机
随着生成式 AI 的广泛采用，开发者越来越多地使用 AI 工具生成代码，GitHub 报告 2025 年有近 10 亿次提交，生成式 AI 项目激增 178%。然而，AI 生成代码的质量仍然不确定，需要在合并前进行验证。代码审查作为关键的质量保证机制，承担着确保代码质量、检测缺陷和提高可维护性的职责。但代码生成速度的加快超出了人工审查的容量，软件团队面临越来越大的质量保证压力。虽然 AI 代理（如 GitHub Copilot、Claude Code 等）已被集成到代码审查流程中，但目前缺乏实证证据来比较 AI 代理和人类审查者在协作工作流中的有效性。
本文的目标是本文的目标是通过大规模实证分析，系统性地比较 AI 代理和人类审查者在代码审查中的反馈特征差异、人机协作模式，以及代码建议对代码质量的影响。具体而言，研究试图回答三个核心问题：第一，AI 代理和人类审查者的评论在内容、焦点和讨论强度上有何异同？第二，不同的人机交互模式如何影响代码审查的结果（接受或拒绝）？第三，AI 代理和人类审查者提供的代码建议的采纳率如何，被采纳的建议如何影响代码质量？这些发现旨在为从业者提供可操作的指导，帮助他们根据 AI 代理和人类审查者的各自优势分配审查任务，最大化人机协作的收益。
与已有工作不同的是，本文的独特切入角度在于首次在大规模数据集上系统性比较 AI 代理和人类审查者在真实代码审查流程中的协作行为和效果。虽然已有工作研究了 AI 生成代码的能力（如缺陷检测、生成评论），但缺乏对人机协作模式的深入分析。本文不仅关注单条评论的有用性，还建模了多轮对话的交互序列，使用有限状态机捕捉人类与 AI 之间的协商过程。更重要的是，本文将交互模式与下游的代码变更和质量结果直接联系起来，超越了仅关注评论采纳或评论质量的研究范式，为理解 AI 代理在软件工程中的实际影响提供了更全面的视角。
核心方法
本文采用实证研究方法，从 300 个开源 GitHub 项目中收集了 278,790 个内联代码审查对话，时间跨度为 2022 年至 2025 年。首先，通过 GitHub API 和手动验证识别 16 个基于 AI 的代码审查机器人，确定参与者的身份（人类或 AI 代理）。然后，根据 PR 作者和首次评论者的身份将审查对话分为四类：人类审查人类编写的代码（HRH）、人类审查 AI 生成的代码（HRA）、AI 审查人类编写的代码（ARH）、AI 审查 AI 生成的代码（ARA）。接下来，使用 GPT-4.1-mini 根据 Bacchelli 和 Bird 的反馈分类法将每条评论自动分类为九种反馈类型之一，并通过人工验证确保分类可靠性。对于交互模式分析，使用有限状态机建模评论序列，分析审查努力、自环强度和状态转换概率。最后，通过 SciTools Understand 工具测量代码建议采纳前后的 111 个代码指标，评估建议对代码质量的影响。
本文的核心创新点在于首次在真实的大规模代码审查数据集上系统性对比 AI 代理和人类审查者的协作行为。与已有研究仅关注单条评论的质量或采纳率不同，本文从三个维度展开：反馈内容差异（使用标准化的反馈分类法）、交互模式分析（使用有限状态机建模多轮对话）、以及对代码质量的量化影响（使用全面的静态分析指标）。这种多维度的分析框架使研究者能够揭示 AI 代理在代码审查中的独特优势（如规模化缺陷筛选）和局限性（如缺乏上下文理解），并为实践者提供了基于证据的协作模式建议。另一创新在于将审查对话与实际的代码变更结果关联起来，使用代码指标（如圈复杂度、代码行数）直接度量被采纳建议的质量影响，这是对仅评估评论文本质量的研究的重要补充。
方法步骤详情
方法步骤如下：第一步，项目选择和数据收集。通过 GitHub 高级搜索选择 300 个符合以下标准的项目：至少 100 个星标、2022 年至 2025 年每月至少有一个关闭的 PR、至少有 100 个由 AI 代理审查的 PR。第二步，识别 AI 代理审查者。通过 GitHub API 识别机器人账户，并手动搜索官方文档确认是否为基于 AI 的代理，最终确定 16 个 AI 代码审查机器人（如 GitHub Copilot、Claude Code、CodeRabbit、Devin 等），并根据官方公告确定代理能力的引入时间。第三步，提取审查对话并分类。从 54,330 个关闭的 PR 中提取内联审查对话，根据 PR 作者和首次评论者身份将对话分为 HRH、HRA、ARH、ARA 四类。第四步，评论分类和内容分析。使用 GPT-4.1-mini 根据反馈分类法将每条评论分类为九种类型之一（Code Improvement、Defect Detection、External Impact、Knowledge Transfer、Misc、No Feedback、Social、Testing、Understanding），并通过人工验证 383 条评论确保分类可靠性（Cohen's κ = 0.85）。计算 Comment-to-Code Density（CD）指标衡量评论详尽程度，公式为 $CD = \frac{\#Tokens(1st\ comment)}{LOC(hunk)}$。第五步，交互模式分析。提取每条对话的评论序列，建模为有限状态机，计算平均评论数、自环强度和转换概率。第六步，代码建议采纳和质量评估。静态提取代码建议（被 ```suggestion 标记的代码块），通过修改的 Jaccard 相似度判断是否被采纳，公式为 $s(f1, f2) = \frac{|f1 \cap f2|}{max(|f1|, |f2|)}$。使用 SciTools Understand 测量采纳前后 111 个代码指标，计算指标增量 $\Delta M = M_{after} - M_{before}$，并通过 Mann-Whitney U 检验比较人类和 AI 建议的差异。
技术新颖性
本文的技术新颖性体现在多个方面。首先，数据集的规模和完整性是前所未有的：278,790 个内联审查对话来自 300 个真实的开源项目，涵盖了四类不同的审查组合（HRH、HRA、ARH、ARA），这为研究人机协作提供了丰富的实证基础。其次，方法上的创新在于将软件工程中的过程挖掘技术（有限状态机建模）应用于代码审查的交互序列分析，这种方法能够捕捉多轮对话中的协作模式，超越了仅关注单条评论的研究范式。第三，代码建议采纳的识别方法结合了静态分析和相似度度量，使用修改的 Jaccard 指标过滤假阳性，确保了采纳判断的准确性。第四，代码质量评估使用了 111 个全面的静态分析指标，不仅包括圈复杂度，还包括耦合度、内聚度、可执行语句数等多个维度，能够全面反映代码质量的变化。最后，本文对未采纳的 AI 建议进行了分类分析，揭示了 AI 代理在实际应用中的具体局限性（如 28.7% 的建议不正确、24.0% 的建议与开发者意图不匹配），这为改进 AI 代理设计提供了明确的方向。
实验结果
研究发现 AI 代理和人类审查者在代码审查中扮演着根本不同的角色。AI 代理的评论显著更长，平均每行代码 29.6 个 token，而人类审查者仅为 4.1 个 token。AI 代理的评论高度集中在代码改进和缺陷检测上（超过 95%），而人类审查者提供更丰富的反馈类型，包括理解（31% 的 HRH 评论）、测试（5-6%）、知识转移（4-6%）和社交沟通。人类发起的审查在不同反馈类型之间显示出显著差异的后续讨论轮次，而 AI 代理发起的审查则始终产生极少的多轮讨论。在交互模式方面，人类审查者在审查 AI 生成代码时比审查人类编写代码时多交换 11.8% 的评论轮次，表明 AI 生成的代码增加了审查负担。当 AI 代理发起审查时，85.2%-86.7% 的对话在 AI 代理的第一轮评论后就终止，没有后续讨论。以 AI 代理响应结束的对话显示出显著更高的拒绝率（7.1%-25.8%），而以人类贡献者响应结束的对话拒绝率仅为 0.9%-7.8%。在代码建议方面，虽然 AI 代理生成了更多代码建议（88,011 vs 25,673），但人类审查者的建议采纳率显著更高（56.5% vs 16.6%）。超过一半未被采纳的 AI 建议要么不正确（28.7%），要么被开发者通过其他修复方式解决（24.0%）。当被采纳时，AI 代理的建议比人类审查者的建议产生更大的代码复杂度和代码大小增加，圈复杂度增加范围在 0.085-0.106 之间，而人类建议的增加幅度较小。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 代码建议采纳率 | 采纳率（采纳建议数/总建议数） | AI代理 16.6%，人类审查者 56.5% | 无直接基线，但人类审查者显著优于AI代理 | 人类审查者比AI代理高39.9个百分点 |
| 缺陷检测建议采纳率 | 采纳率 | AI代理 16.7%，人类审查者 53.7% | 无直接基线 | 人类审查者比AI代理高37.0个百分点 |
| 代码改进建议采纳率 | 采纳率 | AI代理 16.8%，人类审查者 59.2% | 无直接基线 | 人类审查者比AI代理高42.3个百分点 |
| 圈复杂度增加 | 平均指标增量（ΔM） | AI代理 0.085-0.106，人类审查者 -0.002 到 0.009 | 无直接基线 | AI代理建议导致复杂度增加显著更大 |
| 可执行语句增加 | 平均指标增量（ΔM） | AI代理 0.176-0.216，人类审查者 0.099-0.108 | 无直接基线 | AI代理建议导致代码大小增加显著更大 |
| 评论详尽程度 | Comment-to-Code Density（tokens/LOC） | AI代理 29.6（ARH），11.3（ARA），人类审查者 4.1（HRH），3.8（HRA） | 无直接基线 | AI代理评论长度是人类的7.2倍（ARH vs HRH） |
局限与改进
作者在研究中承认了几个局限性。首先，对于 AI 代理的识别依赖于官方框架发布日期和 PR 记录中的账户标识，官方网站可能在实际工具发布或开始使用后才更新，因此分类可能遗漏早期或未被识别的 AI 代理交互。其次，对于反馈类型的自动标注使用了 GPT-4.1-mini 对 278,790 个对话进行分类，LLM 基于标注可能由于对提示设计的敏感性或多个反馈类型都适用的模糊评论而产生不一致的分类。为此，研究者手动验证了 383 条评论的统计显著样本，获得了 0.85 的 Cohen's kappa，表明分类过程具有强可靠性。第三，对于代码指标测量，过滤掉了 SciTools Understand 不支持的编程语言（如 Go 和 Rust），如果这些语言有可比较的工具，质量影响可能会显示不同的结果。此外，指标评估仅在文件级别进行，项目级别的架构影响和质量属性（如系统范围的复杂性或安全漏洞）不在分析范围内。最后，本研究分析了 GitHub 上拥有超过 100 个星标和持续开发历史的公共开源项目，因此结论可能无法推广到专有企业系统或较小的专业存储库。虽然研究包含了多种当前的 AI 代理，但发现 specifically 关注于智能体框架，因此结果可能无法推广到传统的机器学习或深度学习工具。
独立分析的弱点
论文的主要弱点在于缺乏对建议质量影响因素的深入因果分析。研究发现 AI 建议的采纳率远低于人类建议（16.6% vs 56.5%），但没有确定这是由于建议的相关性、呈现格式还是开发人员对自动变更的偏见造成的。另一个弱点是缺乏对不同 AI 代理之间的比较分析，论文将所有 AI 代理作为一个整体进行分析，没有区分不同工具（如 GitHub Copilot vs Claude Code vs CodeRabbit）在行为和效果上的差异。这限制了发现对特定工具改进的针对性。第三个弱点是缺乏对长期影响的评估，代码质量指标仅在采纳前后立即测量，没有跟踪代码在长期维护过程中的演变。此外，研究没有考虑 AI 代理的上下文窗口限制如何影响其对大型项目的理解，这是一个实际部署中的重要因素。最后，研究没有分析 AI 代理的误报率（错误标记为缺陷的评论）和漏报率（实际缺陷但未检测到），这些指标对于评估审查工具的实用性至关重要。
未来方向
作者提出了一些未来研究方向，包括改进 AI 代理的上下文意识、探索多代理机制以共享项目知识，以及减少不正确建议以弥合人类和 AI 代理代码审查之间的质量差距。基于本文的成果，可以延伸几个研究方向：第一，研究提供 AI 代理项目特定上下文（如构建配置、先前审查决策、代码历史）如何提高建议采纳率。第二，设计多代理验证系统，其中第二个 AI 代理评估第一个代理标记的问题是否有效且值得解决。第三，开发能够识别开发人员设计意图的 AI 代理，在生成建议之前询问作者解释意图，确保代理反馈反映作者的实际设计决策而非表面假设。第四，研究如何改进 AI 代理的提示工程，使其生成有针对性、可操作的反馈而非详尽的解释，减少开发者的认知负担。第五，调查采纳率差距是否源于建议相关性、呈现格式或开发人员对自动变更的偏见，这可能需要结合用户研究进行。第六，扩展研究范围包括更多编程语言（如 Go、Rust）和项目级别的影响，如系统范围的复杂性和安全漏洞。
复现评估
论文提供了完整的复现包，发布在 GitHub 上（https://github.com/Software-Evolution-Analytics-Lab-SEAL/AI_Vs_Human_Codereview.git），包含了数据集、分析代码和详细的文档。数据集包括 278,790 个内联代码审查对话，来自 300 个 GitHub 项目，涵盖了 2022 年至 2025 年的时间段。研究使用了开源工具 SciTools Understand 进行静态分析，这是一个广泛认可的软件工程研究工具。代码指标分析包括了 111 个全面的指标，确保了分析的全面性。自动标注过程使用了 GPT-4.1-mini，并通过人工验证确保了分类可靠性（Cohen's kappa = 0.85）。统计分析使用了 Scott-Knott ESD 检验和 Mann-Whitney U 检验，并应用了 Bonferroni 校正以控制多重假设检验的错误率。复现难度中等，主要挑战在于访问 SciTools Understand（商业工具）和可能的 GitHub API 访问限制。总体而言，论文提供了充分的透明度和可复现性资源，其他研究者可以验证发现或在不同数据集上重复实验。
论文图表
这个表格展示了四类审查对话的分布情况。HRH（人类审查人类编写的代码）占 41.9%，是传统审查方式的代表。HRA（人类审查 AI 生成的代码）占 2.3%。ARH（AI 审查人类编写的代码）占 55.4%，反映了 AI 审查代理的广泛采用。ARA（AI 审查 AI 生成的代码）占 0.3%，其中 94.0% 涉及同一个代理审查自己的代码，6.0% 涉及不同代理。总共有 278,790 个对话。
这个表格对理解论文的数据基础至关重要。它展示了数据集的构成，说明大部分对话涉及 AI 审查人类编写的代码（ARH），反映了当前 AI 代理的主要使用场景。HRH 仍然是第二大类别，表明人类驱动的审查流程在长期项目中仍然占主导地位。HRA 和 ARA 的低比例表明 AI 生成代码和 AI-AI 审查仍然处于早期阶段。这个分布解释了为什么某些分析（如 ARA）的样本量有限。
这个表格列出了九种反馈类型及其描述：Code Improvement（建议增强代码清晰度、风格、结构或可维护性而不修复缺陷）、Defect Detection（识别功能、逻辑或正确性问题）、External Impact（关于超出局部代码 diff 的更广泛系统级后果的评论）、Knowledge Transfer（审查者解释概念、约定、最佳实践或提供学习资源）、Misc（不符合任何定义类别或与上下文无关的评论）、No Feedback（审查者没有提供实质性技术反馈的对话）、Social（不直接与技术内容相关的人际陈述，如感谢、鼓励）、Testing（关于添加、更新或修复测试和测试覆盖率的评论）、Understanding（澄清问题以理解上下文、理由、设计决策或实现意图）。
这个表格对理解论文的分析框架至关重要。它定义了用于分类所有 278,790 条评论的反馈类型。这些类型来自 Bacchelli 和 Bird 的经典代码审查研究，确保了研究的理论基础和可比较性。理解每种类型的定义对于解释 Figure 4、Table 3 和 Figure 7 的结果至关重要。
这个表格展示了每类审查中不同反馈类型引发的后续讨论轮次的 Scott-Knott ESD 排名。表格包括每个反馈类型的排名（R，1 表示最高轮次）、平均评论数和超过一条评论的对话百分比。在人类发起的审查（HRH 和 HRA）中，Understanding 反馈始终排名第一，69-79% 的对话超过第一轮交换，平均 2.1-2.3 轮。External Impact、Defect Detection 和 Testing 形成第二层。相比之下，AI 代理审查（ARH 和 ARA）的所有反馈类型都有相同的排名，平均 1.2-1.3 轮。
这个表格对理解论文关于交互模式的重要发现至关重要。它展示了人类审查者在反馈类型之间显示出显著差异，理解反馈触发最多的讨论，而 AI 代理审查则均匀地产生极少的多轮讨论。这个发现支持了论文的结论：AI 代理跳过了澄清步骤，无论设计意图是否清晰都给出直接建议，而人类审查者在意图不明确时会询问作者。
这个表格展示了各反馈类型的建议采纳率。人类审查者的总采纳率为 56.5%，而 AI 代理为 16.6%，差距为 -39.9%。对于知识转移，人类审查者的采纳率为 75.8%，AI 代理不提供此类建议。对于代码改进，人类为 59.2%，AI 为 16.8%（差距 -42.3%）。对于缺陷检测，人类为 53.7%，AI 为 16.7%（差距 -37.0%）。对于理解，人类为 51.0%，AI 不提供此类建议。对于 Misc，人类仅为 1.2%。对于外部影响，AI 为 6.5%。对于测试，AI 为 7.6%。
这个表格是论文的核心结果之一，直接回答了 RQ3（代码建议的采纳率和质量影响）。它展示了人类审查者的建议采纳率显著高于 AI 代理，在所有反馈类型中都如此。特别值得注意的是知识转移类型的采纳率（75.8%），这类建议涉及项目特定知识（如重命名类、存储库约定），AI 代理很少提供。这个发现支持了论文的结论：AI 代理缺乏项目上下文是采纳率低的主要原因之一。
这个表格定义了未采纳 AI 代码建议的类别：Incorrect（AI 建议是错误的或破坏代码）、Alternative Fix（参与者应用不同的修复）、Not Needed（建议是不必要的或已经处理）、Claimed Fixed（显示"已修复"但没有提交到代码库）、Preference（参与者偏好不同的编码风格）、Deferred（参与者计划在未来工作中解决）、Others（不清楚或模棱两可的响应）。
这个表格对理解论文关于未采纳 AI 建议原因的分析至关重要。它提供了分类框架，用于分析 383 个随机采样的未采纳 AI 建议。了解这些类别有助于解释为什么 AI 建议的采纳率如此低（16.6% vs 人类 56.5%），并为改进 AI 代理设计提供明确的方向。例如，如果 28.7% 的建议不正确，那么 AI 代理需要更好的验证机制。
这个表格展示了被采纳建议的代码质量影响，列出了所有 6 个统计显著指标的平均指标增量（ΔM），按类别分组并按 p 值排序。对于复杂度指标：Sum Strict Modified CC 人类增量为 0.003，AI 为 0.106；Sum Strict CC 人类增量为 -0.002，AI 为 0.106；Sum Modified CC 人类增量为 0.009，AI 为 0.086；Sum CC 人类增量为 -0.002，AI 为 0.085。对于代码大小指标：Executable Statements 人类增量为 0.099，AI 为 0.176；Statements 人类增量为 0.108，AI 为 0.216。
这个表格是论文的关键结果之一，展示了被采纳的 AI 建议对代码质量的实际影响。它清楚地显示，当被采纳时，AI 建议比人类建议产生更大的复杂度和代码大小增加。圈复杂度增加范围在 0.085-0.106 之间，而人类建议实际上减少了复杂度或增加很少。可执行语句增加：AI 为 0.176-0.216，人类为 0.099-0.108。这个发现对实践者很重要，因为它表明即使被采纳，AI 建议也可能损害代码可维护性。