AIDev：基于 GitHub 研究 AI 编程智能体 AIDev: Studying AI Coding Agents on GitHub
大规模 GitHub AI 编程智能体 PR 数据集，涵盖 93 万条记录
前置知识
Pull Request (PR)
Pull Request 是 GitHub 等代码托管平台上的协作机制，开发者通过 PR 向项目提交代码变更请求，供维护者审查、讨论并决定是否合并到主分支。一个完整的 PR 通常包含标题、描述、代码差异（diff）、评论、审查意见和事件时间线等元数据。在本文语境中，AI 编程智能体自动生成的 PR 被称为 Agentic-PR，是衡量智能体实际贡献的核心单元。
本文的核心数据对象就是 Agentic-PR，理解 PR 的结构和生命周期是理解数据集组织方式的基础。
AI 编程智能体 (Coding Agent)
AI 编程智能体是基于大语言模型（LLM）的自主系统，能够接收自然语言任务描述，自主规划代码变更方案，执行文件读写、测试运行、版本控制等操作，并迭代修复问题直至完成任务。与传统的代码补全工具不同，智能体具备工具调用、环境感知和长期规划能力，能够完成从问题分析到 PR 提交的端到端流程。本文研究的五个智能体包括 OpenAI Codex、Devin、GitHub Copilot、Cursor 和 Claude Code。
理解 AI 编程智能体的工作方式和能力边界，是理解本文研究动机和数据集设计的关键前提。
Conventional Commits
Conventional Commits 是一种提交信息规范，通过前缀（如 feat:、fix:、docs:、refactor:）标注代码变更的目的和类型。本文利用 GPT 对 Agentic-PR 的任务类型进行自动分类，遵循的就是 Conventional Commits 的分类体系，包括功能开发、Bug 修复、文档、重构等类别。这种分类方式使得研究者可以按任务类型维度分析智能体的行为模式。
数据集中 pr_task_type 表使用此规范对 PR 进行自动标注，理解该规范有助于理解数据集的标注体系。
SE 3.0（软件工程 3.0）
SE 3.0 是本文作者团队提出的软件工程演进愿景，描述从 SE 1.0（个人编程）到 SE 2.0（团队协作与 DevOps）再到 SE 3.0（人机深度协作）的范式转变。在 SE 3.0 时代，AI 智能体不再是辅助工具，而是作为 AI 队友深度参与开发流程，包括需求分析、代码编写、测试和代码审查等环节。本文的数据集正是为了支撑对这一新兴范式的系统性研究。
本文的研究动机植根于 SE 3.0 范式，理解该概念有助于把握论文的宏观定位和学术贡献。
研究动机
尽管 AI 编程智能体正在快速改变软件工程实践——它们每天贡献数千个 Pull Request，成为协作开发中的常规参与者——但研究社区缺乏一个全面的数据集来捕捉这些智能体在真实世界项目中的使用方式。现有研究主要依赖受控实验、基准测试或小规模部署，无法反映智能体在多样化真实仓库中的实际表现。以 SWE-bench 为代表的基准测试虽然推动了智能体能力评估，但其评测场景相对单一，无法覆盖采纳模式、代码质量、审查动态和潜在风险等多维度问题。同时，早期关于开发机器人（bot）的研究表明，自动化 PR 往往面临较低的接受率、较慢的交互速度和通知疲劳等问题，但 LLM 驱动的智能体与传统机器人存在本质区别——它们能够处理更大、更复杂的变更，这使得已有研究结论不能直接迁移。
本文的目标是本文的具体目标是构建 AIDev——一个大规模、结构化的数据集，系统性地记录 AI 编程智能体在真实 GitHub 项目中产生的 Pull Request 及其关联元数据。该数据集不仅要涵盖 PR 本身的元信息（标题、状态、时间戳），还要关联仓库信息、开发者信息，并为高质量子集提供审查评论、提交差异、事件时间线和关联 Issue 等丰富工件。通过这一数据集，作者旨在为研究社区提供基础设施，支撑对 AI 采纳、开发者生产力和人机协作的系统性研究。
与已有工作不同的是，本文的独特切入角度在于规模化真实数据。与受控实验不同，AIDev 直接从 GitHub 抓取真实世界的 Agentic-PR，覆盖 932,791 条 PR、116,211 个仓库和 72,189 名开发者，提供了前所未有的规模和多样性。数据集不仅记录了发生了什么（PR 元数据），还通过精心筛选的子集（33,596 条来自 2,807 个高星仓库的 PR）提供了为什么发生的上下文（审查评论、提交差异、事件时间线）。这种两层结构——全量元数据加精选深度数据——是本文区别于现有工作的核心设计决策，使得研究者既可以在宏观尺度分析采纳趋势，也可以在微观尺度深入理解审查动态和失败模式。
核心方法
本文的方法论并非提出新的算法或模型，而是设计并构建了一个大规模数据集 AIDev。整体思路是：首先确定五个具有代表性的 AI 编程智能体（OpenAI Codex、Devin、GitHub Copilot、Cursor、Claude Code），然后通过 GitHub API 系统性地抓取这些智能体产生的 Pull Request 及其关联数据。数据采集分为两个层次：第一层是全量元数据层，覆盖所有 932,791 条 Agentic-PR 及其对应的仓库和开发者信息；第二层是精选子集层，从拥有超过 100 个 GitHub Stars 的 2,807 个仓库中筛选出 33,596 条 PR，并额外采集审查评论、提交差异、事件时间线和关联 Issue。此外，还利用 GPT 模型对所有精选 PR 进行任务类型自动标注，遵循 Conventional Commits 分类体系。
本文的核心创新点在于数据集的两层结构设计和生态级覆盖理念。与以往聚焦于单一智能体或特定任务的研究不同，AIDev 同时覆盖五个主流编程智能体，使得跨智能体的对比分析成为可能。全量层（932,791 条 PR）提供了宏观统计分析的基础，而精选层（33,596 条 PR）则通过添加审查工件和深度元数据支持细粒度研究。另一个关键创新是将 PR 数据与仓库、开发者、Issue 和事件时间线关联起来，形成了一个完整的关系型数据模型。这种设计使得研究者可以回答诸如哪些类型的开发者更倾向于采纳智能体、审查过程中哪些方面最受关注等跨实体的复杂问题，而不仅仅停留在 PR 级别的表面分析。
方法步骤详情
数据集的构建过程包含以下关键步骤：第一步，确定目标智能体，选择 OpenAI Codex、Devin、GitHub Copilot、Cursor 和 Claude Code 五个在 GitHub 上产生显著 PR 流量的智能体。第二步，通过 GitHub API 批量抓取这些智能体产生的所有 PR，提取标题、描述、状态、时间戳、仓库和用户等元数据，形成 all_pull_request（932,791 条）、all_repository（116,211 个）和 all_user（72,189 名）三个核心表。第三步，基于仓库 Stars 数量筛选，从拥有超过 100 Stars 的仓库中提取 33,596 条 PR 形成精选子集 pull_request 表，同时提取对应的 repository（2,807 个）和 user（1,796 名）信息。第四步，对精选子集采集深度工件，包括 PR 评论（pr_comments，39,122 条）、审查意见（pr_reviews，28,875 条）、行内代码审查评论（pr_review_comments，19,450 条）、提交记录（pr_commits，88,576 条）和提交差异详情（pr_commit_details，711,923 条）。第五步，采集关联数据，包括 PR 与 Issue 的关联映射（related_issue，4,923 条）、相关 Issue 详情（issue，4,614 条）和完整事件时间线（pr_timeline，325,500 条）。第六步，使用 GPT 模型对所有精选 PR 进行任务类型自动标注（pr_task_type，33,596 条），分类体系遵循 Conventional Commits 规范。最终数据集的数据截止日期为 2025 年 8 月 1 日。
技术新颖性
AIDev 的技术新颖性体现在三个维度。首先是规模突破：此前最大的相关数据集通常只覆盖单一智能体或数千条 PR，而 AIDev 以 932,791 条 Agentic-PR 的规模实现了数量级的跃升。其次是多智能体覆盖：同时收录五个主流智能体的数据使得跨智能体对比研究首次成为可能，研究者可以分析不同智能体在 PR 质量、审查响应和任务类型上的差异。第三是关系型数据建模：数据集不是简单的 PR 列表，而是通过外键关联形成了 PR-仓库-开发者-Issue-事件的完整关系网络，这种设计直接支持 JOIN 查询和多表分析，降低了研究者的入门门槛。此外，数据集同时提供 Hugging Face 和 Zenodo 两个下载渠道，并配套 Jupyter Notebook 示例和 Colab 链接，进一步提升了可复现性和易用性。
实验结果
作为数据集论文，本文的核心贡献不在于实验结果，而在于数据集本身的统计特征和研究潜力的展示。AIDev 数据集包含 932,791 条 Agentic-PR，覆盖 116,211 个仓库和 72,189 名开发者，数据截止日期为 2025 年 8 月 1 日。精选子集包含 33,596 条来自 2,807 个高星仓库（超过 100 Stars）的 PR，并附带 39,122 条 PR 评论、28,875 条审查意见、19,450 条行内代码审查评论、88,576 条提交记录和 711,923 条文件级提交差异。此外，数据集还包含 4,923 条 PR-Issue 关联映射、4,614 条相关 Issue 详情和 325,500 条事件时间线记录。这些数字表明 AIDev 在数据规模和深度上均达到了前所未有的水平。论文还提出了五个维度的研究问题框架——采纳与实践、代码补丁特征、测试行为、审查动态和失败模式与风险——每个维度包含 2-5 个具体研究问题，总计 17 个研究问题，为后续研究提供了清晰的路线图。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 数据集规模（全量 PR） | Agentic-PR 数量 | 932,791 条 | 此前最大规模为数千条 | 数量级提升 |
| 数据集覆盖（智能体数量） | 覆盖智能体种类 | 5 个主流智能体 | 通常仅 1-2 个 | 多智能体跨对比首次可行 |
| 数据集覆盖（仓库数量） | 涉及仓库数 | 116,211 个 | 通常为数十至数百个 | 生态级覆盖 |
| 精选子集深度 | 关联工件类型数 | 7 类（PR、仓库、用户、评论、审查、提交、Issue、时间线、标注） | 通常仅 PR 元数据 | 支持多维度深度分析 |
局限与改进
本文存在以下局限性。首先，数据集的智能体识别依赖于 GitHub 账户标识，可能存在误判或遗漏——某些智能体可能通过开发者个人账户提交 PR，无法被自动识别。其次，数据截止日期为 2025 年 8 月 1 日，无法反映此后新出现的智能体或已有智能体的重大更新。第三，精选子集的筛选标准（超过 100 Stars）可能引入偏差——高星仓库通常更成熟、有更好的审查流程，其结论不一定能推广到小型或新兴项目。第四，任务类型标注依赖 GPT 模型，存在标注错误的风险，且标注质量未经过系统性验证。第五，数据集仅覆盖 GitHub 平台，无法反映 GitLab、Bitbucket 等其他平台上的智能体使用情况。最后，作为数据集论文，本文未提供基于该数据集的实证研究结果，所有研究问题均为开放性问题，需要后续工作来回答。
独立分析的弱点
本文的主要弱点包括以下几个方面。第一，智能体识别的可靠性问题：论文未详细说明如何区分智能体提交的 PR 和人类开发者提交的 PR，特别是在 GitHub Copilot 等智能体可能与人类协作的场景下，PR 的归属判定可能存在模糊地带。改进方向是引入多信号验证机制，结合提交信息、账户类型和 PR 描述中的智能体标识进行交叉验证。第二，数据质量问题未充分讨论：论文未提供数据清洗流程的细节，例如如何处理重复 PR、如何验证 PR 是否真正由智能体生成、如何处理包含混合提交（既有智能体生成又有手动修改）的 PR。改进方向是增加数据质量评估指标和清洗规则的透明度。第三，标注验证不足：GPT 标注的任务类型缺乏人工验证的准确率报告，研究者无法评估标注噪声对分析结果的影响。改进方向是抽样进行人工验证并报告准确率指标。
未来方向
论文提出了五个维度共 17 个研究问题，为后续研究提供了丰富的方向。在采纳与实践维度，研究者可以分析不同类型开发者（新手 vs 资深）的智能体使用模式差异，以及 PR 大小、任务类型和提交粒度与 PR 质量的关联。在代码补丁特征维度，可以研究 Agentic-PR 中原创代码与复用代码的比例，以及智能体代码与人类代码在变更模式上的差异。在测试行为维度，可以量化智能体贡献测试的频率和类型，以及缺失测试时开发者的干预行为。在审查动态维度，可以分析审查关注的维度（正确性、风格、安全性）和智能体处理审查评论的能力。在失败模式维度，可以识别常见失败模式并探索早期信号对 PR 拒绝的预测能力。此外，基于数据集的多智能体覆盖特性，跨智能体的系统性对比研究也是一个重要方向。
复现评估
本文在可复现性方面做得较好。数据集同时提供 Hugging Face（https://huggingface.co/datasets/hao-li/AIDev）和 Zenodo（https://doi.org/10.5281/zenodo.16899501）两个下载渠道，确保长期可访问性。作者还在 GitHub（https://github.com/SAILResearch/AI_Teammates_in_SE3）提供了示例 Jupyter Notebook 和 Google Colab 链接，降低了数据获取和分析的门槛。Hugging Face 平台的 Data Studio 接口支持浏览器内 SQL 查询，进一步降低了探索数据的技术门槛。然而，数据集的构建过程（API 调用策略、数据清洗规则、智能体识别逻辑）的文档化程度有待提升，研究者若要从零复现数据采集过程可能面临挑战。此外，精选子集的筛选标准（100 Stars 阈值）的选择缺乏敏感性分析，研究者无法评估不同阈值对数据集特性的影响。
论文图表