[Paper] 关于在开源 Android 与 iOS 开发中采用 AI Coding Agents

Source: arXiv - 2602.12144v1

概览

本文首次大规模实证考察了 AI 驱动的编码助手（如 GitHub Copilot、Code Llama、Claude）在真实开源 Android 和 iOS 项目中的使用情况。通过从 193 个代码库中挖掘 2,901 个 AI 编写的拉取请求（PR），作者揭示了平台特定的采用模式、接受率以及 AI 贡献成功或受挫的任务类型。

关键贡献

• 数据集创建 – 整理了 AIDev 数据集，这是一个经过验证的 AI 生成的 Android（1,721 个 PR）和 iOS（1,180 个 PR）开源应用的 PR 集合。
• 跨平台比较 – 表明 Android 项目收到的 AI PR 大约是 iOS 的两倍，且接受率更高（71 % 对比 iOS 的 63 %）。
• 代理层面分析 – 显示 Android 上不同编码代理之间存在显著差异，强调并非所有助手表现相同。
• 任务类别细分 – 发现常规任务（功能添加、错误修复、UI 调整）最容易被合并，而结构性更改（重构、构建系统编辑）接受率较低且审查周期更长。
• 时间演变 – 跟踪 2023‑2025 年的 PR 解决时间，发现 Android 在 2025 年中期达到改进峰值，随后略有回落。
• 未来研究基线 – 提供了首个用于评估移动 OSS 中 AI 生成贡献的量化基准，为平台感知的代理设计铺平道路。

方法论

1. 数据收集 – 查询 GitHub 的 REST API，获取在描述或提交元数据中明确注明使用 AI 工具的 PR。
2. 验证 – 采用两步人工审查流程，确保这些 PR 真正由 AI 创作（例如，检查生成的代码片段、工具特定标签）。
3. 分类 – 使用关键词启发式和人工标记相结合的方式，将每个 PR 映射到任务类别（功能、缺陷修复、UI、重构、构建、文档等）。
4. 统计分析 – 使用卡方检验和生存分析比较不同平台、代理和类别的接受率、合并时间以及审阅者评论，分析解决时间趋势。
5. 时间切片 – 将数据按季度划分，以观察 AI 贡献动态随时间的演变。

该方法保持轻量，便于开发者遵循，同时提供严格、可复现的结果。

结果与发现

含义：

• Android 开发者更愿意接受 AI 生成的更改，可能是因为工具生态更大、社区规范更成熟。
• 常规、范围明确的更改是 AI 代理的强项；更深层的架构编辑仍需人工监督。
• AI 贡献速度的“最佳点”出现在 2025 年中期，表明近期模型改进提升了审查周期的速度——直至出现饱和或质量下降。

实际影响

• 工具选择： 当面向 Android 平台时，团队可以优先使用在 Android 上表现出更高接受度的代理（例如 Agent A），而在 iOS 上则需要更为谨慎。
• 工作流设计： 鼓励开发者使用 AI 进行增量功能、界面微调和 bug 修复，但对重构和构建系统的更改应通过更严格的审查关卡或“人工优先”的方式进行。
• CI/CD 集成： 由于 AI PR 在 Android 上的解决速度更快，CI 流水线可以在进行简短的自动验证后，自动合并低风险的 AI 贡献，从而加速发布周期。
• 社区指南： 开源维护者可以采用要求明确 AI 归属并进行简短人工检查清单的政策，以提升审稿人的信任度和接受率。
• 产品路线图： 构建 AI 编码助手的公司可以利用这些基准对模型进行基准测试，重点提升结构性变更建议，以缩小接受度差距。

限制与未来工作

• 数据集偏差： 该研究仅覆盖自愿披露 AI 使用的公共 GitHub 仓库，可能遗漏私有或未披露的 AI 贡献。
• 代理粒度： 某些 PR 列出了多个代理或通用的 “AI assistant”，导致难以将性能归因于单一模型。
• 时间范围： 分析止于 2025 年底；此后快速的模型发布可能会显著改变趋势。
• 人为因素： 论文未深入探讨审稿人专业水平或项目成熟度，这些因素可能会影响接受决策。

未来的研究可以扩展到其他移动生态系统（例如 Flutter、React Native），加入对审稿人评论的情感分析，并尝试混合人‑AI 审核流水线，以量化生产力提升。

作者

• Muhammad Ahmad Khan
• Hasnain Ali
• Muneeb Rana
• Muhammad Saqib Ilyas
• Abdul Ali Bangash

论文信息

• arXiv ID: 2602.12144v1
• 分类: cs.SE, cs.AI
• 出版日期: 2026年2月12日
• PDF: 下载 PDF