🤖 AI

Will It Survive? Deciphering the Fate of AI-Generated Code in Open Source

与人工智能生成的代码是可丢弃的这一假设相反，对 201 个开源项目的生存分析表明，智能体编写的代码实际上比人类编写的代码持续时间更长，尽管它面临着略高的修正修改率，这表明组织实践而非生成质量才是其长期演化的主要瓶颈。

原作者： Musfiqur Rahman, Emad Shihab

发布于 2026-01-26

📖 1 分钟阅读☕ 轻松阅读

原作者： Musfiqur Rahman, Emad Shihab

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下软件开发是一个繁忙、喧闹的建筑工地，建筑物（代码库）正在不断地被建造、翻修和维修。多年来，施工经理（软件工程师）一直有一个挥之不去的担忧：如果他们开始使用“机器人建筑工”（AI 智能体）来铺设砖块，这些砖块会很脆弱。人们担心机器人会随手拼凑出一面墙，而人类监工为了赶进度会迅速批准它，然后，一旦机器人走开，这面墙就会坍塌或需要立即拆除。这种想法被称为**“一次性代码”假设（disposable code hypothesis）**——即认为 AI 生成的代码只是临时的填充物，无法持久。

这篇题为《它能生存吗？解读开源领域 AI 生成代码的命运》的论文，来到了这个建筑工地，去检查那些已经铺好的砖块。研究人员不仅观察了机器人在施工时墙面盖得如何，还观察了这面墙数月之久，以测试它能否经受住时间的考验。

以下是他们的发现，通过简单的故事进行了解析：

1. “幽灵砖块”现象（生存能力）

迷思： 人们认为 AI 砖块会被很快拆除或更换。
现实： AI 砖块实际上比人类的砖块更持久。

研究人员追踪了 201 个不同项目中的超过 20 万行代码（单个砖块）。他们发现，由 AI 编写的代码行比人类编写的代码行更不容易被修改或删除 16%。

原因何在？“别碰我的代码”规则。
论文提出了一个有趣的心理学原因：人类通常会对他们没有亲手编写的代码感到犹豫。这就像租客搬进一栋房子后，因为不知道隐藏的电线在哪里，所以不敢重新布置家具一样。

人类代码： 当一个人写下一行代码时，他们会产生所有权感。如果稍后发现一个小问题，他们会觉得有义务立即修复它。
AI 代码： 当 AI 写下一行代码时，没有单个人类会对它负责。它变成了一种“幽灵砖块”。除非它彻底坏了，否则人类不太愿意去动它，因此它会在那里静静地放置很久，无人问津。

注：这并不适用于所有的机器人。那些“Copilot 式”的机器人（辅助人类编写代码的机器人）产生的砖块最稳定。然而，全自动机器人（如试图独立完成整个工作的“Devin”）产生的砖块实际上比人类的砖块更容易被修改，这可能是因为它们更具实验性。

2. 修理背后的“动机”（意图）

当这些砖块最终被修改时，研究人员询问了：为什么？
他们查看了“维修订单”（提交信息/commit messages），以查看这些变化是在修复错误、添加新功能，还是仅仅在更新旧工具。

人类砖块： 人类倾向于通过修改代码来适应新环境（比如因为新的锁系统需要，而更换门把手）。这被称为“适应性”（Adaptive）维护。
AI 砖块： 当 AI 代码被修改时，它更有可能是为了修复 Bug（纠错性/Corrective）或安全补丁（预防性/Preventive）。
陷阱： 这种差异并不大。并不是说 AI 代码“更差”或“更好”；它只是有着略微不同的维修特征。此外，不同的 AI 工具表现迥异。一种 AI 工具生成的代码可能需要 44% 的 Bug 修复，而另一种可能只需要 13%。具体的工具比“它是 AI”这一事实更为重要。

3. 我们能预测未来吗？（预测）

研究人员尝试建立一个水晶球，来预测两件事：

哪些砖块会坏？（我们能识别出脆弱的代码行吗？）
它们什么时候会坏？（我们能预测时间吗？）

识别弱点（成功）： 他们取得了中等程度的成功。通过观察代码的“词汇表”（使用的特定单词和命令），他们可以猜测哪些行可能会被修改。例如，连接到特定且多变的外部服务（如云 API）的代码会被标记为“高风险”，容易在未来发生变更。
预测时间（失败）： 他们无法预测变更何时发生。知道一块砖可能会坏很容易；但要通过代码本身来预测它是在明天还是在六个月后坏掉，是不可能的。
- 隐喻： 这就像知道一个汽车零件容易磨损（代码内容），但你无法预测修理工会在下周还是明年去修理它（时间）。这个时间取决于修理工的日程安排（组织动态），而不是零件本身。

核心结论

论文得出结论，对“一次性 AI 代码”的恐惧在很大程度上是一个迷思。AI 生成的代码实际上比人类代码存活时间更长，主要是因为人类不敢轻易触碰它。

然而，真正的瓶颈不在于 AI 编写的代码质量，而在于组织机构如何管理它。如果一家公司没有为 AI 的工作分配一个人类“所有者”，那么这些代码可能会在很长一段时间内无人问津，并不是因为它完美无缺，而是因为没有人对此负责。让 AI 代码持久的关键不仅仅在于更好的机器人，更在于更好的管理制度和明确的所有权归属。

技术摘要：它能生存吗？解读 AI 生成代码在开源领域的命运

问题陈述

将大型语言模型（LLM）和自主 AI 智能体集成到软件开发中，引发了人们对它们生成的代码长期生命力的担忧。软件工程界存在一种流行的假设，即 AI 生成的代码是“一次性的”——虽然被快速合并，但在部署后不久就会被丢弃或进行大量修改。如果这一假设成立，这将使维护负担从代码生成转向部署后的修复，从而可能抵消生产力的提升。现有的文献主要通过即时正确性指标（如 Pass@k、BLEU 分数）或聚合变更率来评估 AI 代码，但缺乏追踪生产环境仓库中单个 AI 编写代码单元存活情况的纵向证据。本研究旨在填补这一空白，探讨以下问题：智能体编写的代码是否比人类编写的代码存活时间更长？如果是，在什么条件下以及呈现出怎样的修改模式？

研究方法

作者采用了**生存分析（survival analysis）**框架，这是一种传统上用于医学和可靠性工程，用于对处理右删失观测值的“时间-事件”数据进行建模的统计方法。

数据集： 本研究利用 AIDev 数据集，将其过滤为包含人类编写和智能体编写 Pull Request（PR）的 201 个开源仓库最终样本集。这种在仓库内的对比控制了项目特定的混杂因素（如编码标准、领域复杂度）。最终数据集包含 5,171 个 PR（3,003 个智能体编写，2,168 个人类编写）以及超过 200,000 个代码单元。
粒度： 分析在两个层面进行：
- 文件级： 追踪整个源文件。
- 行级（主要）： 追踪单行代码。这是主要的分析单元，用以解决“混合作者身份”问题，即单个文件中可能同时包含 AI 和人类的代码。
操作化定义：
- 诞生事件（Birth Event）： 当其父 PR 被合并时，代码单元被视为“诞生”。
- 死亡事件（Death Event）： 当代码单元被后续提交修改时，被视为“死亡”。
- 删失（Censoring）： 在观察截止日期（2025 年 12 月 31 日）前未被修改的代码单元被视为右删失。
研究问题 (RQs)：
- RQ1（生存率）： 智能体编写的代码是否比人类编写的代码存活时间更长？（使用 Kaplan-Meier 估计量、Log-Rank 检验和 Cox 比例风险回归模型）。
- RQ2（意图）： 当发生修改时，其意图是什么？（使用 Swanson 维护分类法对修改进行分类：纠正性、完善性、适应性、预防性）。
- RQ3（预测）： 能否在诞生时预测智能体代码的命运？（使用文本特征进行定位，以及使用元数据特征进行时间预测）。

核心结果

RQ1：生存分析

与“一次性代码”的叙事相反，智能体编写的代码存活时间明显更长。

行级统计数据： 智能体编写的代码行的死亡率显著较低（53.9%，而人类代码为 69.3%，差距为 15.4 个百分点）。
风险比（Hazard Ratio）： Cox 回归模型显示，风险比 (HR) 为 0.842 ( $p < 0.001$ )，这意味着在控制了 PR 和仓库特征后，智能体编写的代码行在任何给定时间的修改风险比人类代码低 16%。
工具差异： 生存优势因智能体类型而异。“Copilot 式”助手（如 Cursor、Claude Code、GitHub Coppilot、OpenAI Codex）的死亡率比人类低 20–30 个百分点。相反，Devin（一种全自主智能体）的死亡率（71.7%）略高于人类代码。

RQ2：修改意图

虽然智能体代码存活时间较长，但其修改特征与人类代码略有不同，尽管效应量较小（Cramér's V = 0.116）。

纠正性 vs. 适应性： 智能体编写的代码表现出略高的纠正性速率（26.3% vs. 23.0% 对于人类），这表明当被触及时，它更有可能被修复。人类编写的代码则表现出显著更高的适应性速率（12.8% vs. 7.7%），表明其更多是为了环境变化（如依赖项更新）而被修改。
单智能体异质性： 不同 AI 智能体之间的修改意图差异（例如，Claude Code 的纠正率为 44.4%，而 Cursor 为 13.8%）超过了 AI 与人类之间的整体差距，这表明工具模态和使用场景比“AI 对人类”的二元区分更为关键。

RQ3：预测

定位 (RQ3a)： 使用文本特征（词袋模型）可以实现对易被修改的代码行进行预测。表现最好的模型（XGBoost）实现了 0.671 的 AUC-ROC，比随机预测提高了 34.2%。LIME 分析显示，领域特定标记（如 SDK 集成）是强有力的预测因子，而通用标记往往会在稳定的工具类代码上产生假阳性。
时间预测 (RQ3b)： 预测代码何时会被修改则困难得多。表现最好的模型（逻辑回归）实现的 Macro F1 仅为 0.285（仅比随机基准高出 14%）。
驱动因素： 特征重要性分析显示，文件修改历史和文件年龄是预测时间的最强预测因子，而贡献者特征（包括作者身份）的影响微乎其微。这表明修改时机是由组织动态和项目活跃度驱动的，而非代码质量或作者身份。

贡献与意义

本文做出了四个主要贡献：

首次对 AI 代码进行生存分析： 这是首次应用时间-事件方法，追踪生产环境中单个智能体生成的代码单元从诞生到修改的过程。
差异化的修改特征： 经验性地证明了虽然 AI 代码存活时间更长，但其修改意图与人类代码存在差异（更高的纠正性，更低的适应性）。
建立预测基准： 它确立了代码内容可以预测修改可能性（AUC-ROC 0.671），为 AI 代码提供了超越 Pass@k 等即时正确性指标的新维度评估。
可复现的制品： 作者发布了一个包含数据和分析脚本的复现包。

意义与启示

该研究挑战了“AI 生成的代码本质上脆弱或一次性”的假设。相反，作者认为，生存优势可能源于代码所有权动态：开发者可能不愿修改他们未曾编写的代码（“别碰我的代码”），且 AI 代码往往缺乏明确的人类所有者。

作者得出结论，智能体生成代码的瓶颈可能不在于生成质量，而在于管理其长期演进的组织实践。他们建议：

组织应明确为智能体生成的代码指定人类所有者，以防止其成为“孤儿代码”。
工具选择应取决于上下文；Copilot 式助手可能更适合稳定的基础设施，而自主智能体可能更适合探索性原型设计。
长寿并不等同于鲁棒性；代码之所以持续存在，可能仅仅是因为它们处于低活跃区域或难以理解。

论文强调，未来对 AI 代码的评估必须超越生成时的指标，转向包含部署后演进过程的纵向研究。