🤖 machine learning

Learning from 53.6K Real-World Developer Edits of AI-Generated Code

本文介绍了 DECODE，这是一个包含来自 1,000 多名开发者的 53,600 次真实 IDE 内 AI 生成代码编辑的数据集，该数据集揭示了大多数修改都发生在接受后的 15 分钟内，并证明了在此数据上进行微调的小型模型在预测代码编辑方面显著优于前沿大语言模型。

原作者： Jenny T. Liang, Mihika Bairathi, Wayne Chi, Ameet Talwalkar, Nishant Subramani, Valerie Chen

发布于 2026-07-29

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Jenny T. Liang, Mihika Bairathi, Wayne Chi, Ameet Talwalkar, Nishant Subramani, Valerie Chen

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

想象一下你正在教一个机器人做饭。你给它展示一本食谱，它尝试做一道菜。有时，它做得非常完美。但经常，它会放太多盐、忘了加蒜，或者用勺子而不是搅拌器。在计算机科学的世界里，这个机器人就是一个“AI 编程助手”，而那些菜肴就是代码行。长期以来，科学家们试图通过向这些机器人展示完成好的食谱（称为“Git commit”）来教它们——即那些最终进入食谱中的完美成品。但这就像仅仅通过观察盘子里的食物来学习烹饪一样，忽略了混乱的厨房、烤焦的面包以及厨师慌乱的修正。

真正的魔力（以及真正的混乱）发生在中间过程。当人类厨师尝了一口汤并说：“不，这需要再加点胡椒，”或者“实际上，把这个扔掉重新开始吧，”这就是一次“代码编辑”。直到现在，我们还没有好的方法来观察厨师是如何进行这些操作的。此前，我们只能看到最终的结果。这篇论文深入研究了这个混乱而美丽的厨房。它提出了疑问：人类究竟是如何修复 AI 错误的？他们是进行微调，还是直接把它扔进垃圾桶？我们能否教会机器人预测这些修复行为，甚至在它们发生之前就预判出来？

伟大的代码侦探：DECODE

这项研究背后的研究人员意识到，要让 AI 更擅长编写代码，他们必须停止只看成品，而是开始观察过程。他们创建了一个庞大的新数据集，名为 DECODE（开发者代码编辑数据集）。把 DECODE 想象成安装在 1,000 多名真实开发者 IDE（数字工作空间）中的一套大型高清监控系统。该系统不仅保存最终的代码，还记录了开发者在接受一段 AI 建议后所做的每一次点击、删除和重写。

他们收集了 53,600 次这类真实的编辑会话，主要涉及 Python、TypeScript 和 JavaScript。这就像拥有一个由 53,600 个关于人类与机器人如何争论、妥协以及协作构建软件的故事组成的图书馆。

他们的发现：“15 分钟法则”与“垃圾桶”

当团队分析数据时，他们发现了关于人类如何对待 AI 建议的一些惊人模式。

首先，他们发现了一个严格的 15 分钟法则。大多数编辑都发生得非常快。如果开发者打算修改 AI 的代码，他们通常会在接受建议后的前 15 分钟内完成。在那之后，代码通常就不会再被改动了。

其次，他们发现人类出奇地严苛。在约 31% 的案例中，开发者并不仅仅是微调代码，而是直接删除了 AI 的整个建议并从头开始。这就像 AI 递给你一个三明治，而你立刻把它扔进了垃圾桶，因为面包稍微有点不对劲。数据表明，如果 AI 的建议不能立即完美契合开发者的意图，它往往注定会被放弃。

然而，当人类保留这些代码时，他们改动并不大。数据表明，对于那些幸存下来的代码，开发者通常会保留原 AI 建议中约 63% 的内容。他们倾向于添加极少的原创代码（人类新添加的内容仅占最终代码的约 20%）。这意味着开发者高度依赖 AI，但他们对初始质量的要求非常挑剔。

研究人员还注意到人们修复事物的特定顺序。这就像一份清单：

“这玩意儿能用吗？”检查： 首先，他们决定是否要保留这段代码。如果不想保留，就删除它。
“修复 Bug”阶段： 接下来，他们修复语法错误或可读性问题。
“把它变成我的”阶段： 然后，他们重命名变量或更改数值以适应特定的需求。
“改变计划”阶段： 最后，如果他们仍在继续处理，可能会改变代码实际执行的功能。

教会机器人读心术

论文的第二个重点是一个测试：我们能否教会一个较小的开源 AI 模型，使其比那些巨大的、超级智能的“前沿”模型更好地预测这些编辑行为？

通常，最大的、最昂贵的 AI 模型被认为是全能的。但在本研究中，研究人员拿出了一个较小的模型（拥有 30 亿个参数，与那些巨头相比微不足道），并专门针对 DECODE 数据集对其进行了训练。他们教这个小模型观察一段 AI 建议，并进行猜测：“人类会删除它吗？他们会微调它吗？还是会 그대로 留下它？”

结果令人震惊。经过真实世界编辑数据的学习，这个小模型的表现变得显著更好，甚至超过了从未见过此类特定数据的庞大、最先进的模型。

对于预测最终代码会是什么样子的，该小模型的准确度提升了 0.17（这在这一领域是一个巨大的飞跃）。
对于预测代码是否会被修改，它的表现也提升了 0.17。

这表明，拥有正确的“经验”（真实世界的编辑数据）比单纯拥有更大的大脑更为重要。这就像一位看过数千场烹饪节目的年轻厨师，可能比一位只在实验室里烹饪完美餐点的名厨更懂得如何改进一道菜。

总结：核心在于人，而非仅仅是代码

论文得出结论，我们不应再将 AI 代码生成视为一个只追求“正确性”的数学问题。真正的目标是“对齐（Alignment）”。代码需要符合人类的意图，否则人类就会直接把它扔掉。

作者建议，未来的 AI 助手不应仅仅尝试在第一次尝试时就写出完美的代码。相反，它们应该被训练去理解“编辑的过程”。它们需要明白人类通常会快速删除内容，会在改变功能之前先修复错误，并且更容易接受那些易于微调的代码。

通过使用像 DECODE 这样的数据集，我们可以构建出不仅仅是编写代码，而且是编写“人类真正想要保留的代码”的 AI。这是一种从询问“这段代码是否正确？”到询问“这段代码是否能让一个人类轻松将其变为己用？”的转变。数据表明，如果我们教会 AI 理解那段混乱的、15 分钟的编辑窗口期，我们或许终于能得到一个能做出让我们满意享用的佳肴的机器人。

技术摘要：从 5.36 万次真实世界的 AI 生成代码开发者编辑中学习

问题陈述

尽管 AI 编程助手已被广泛采用，但生成的代码往往并不完美，存在漏洞或与特定的编码风格不匹配的问题。因此，开发者必须通过直接编辑或重新向模型发送提示（re-prompting）来手动修改 AI 生成的代码。目前的语言大模型（LLMs）主要是在公开的 Git 数据（如提交和拉取请求）上进行训练以学习代码编辑。然而，Git 数据仅代表了代码最终成功的状态，缺乏实际编辑过程中的中间步骤、时间顺序和上下文。这一差距限制了 LLM 预测或建模开发者如何实时与 AI 生成内容进行交互并对其进行修改的能力。此外，现有的数据集通常依赖于合成数据、实验室设置或指令式编辑，无法捕捉到真实世界中针对 AI 生成内容的各种手动代码编辑的细微差别。

研究方法

1. 数据集构建：DECODE

为了解决缺乏现实主义编辑数据的问题，作者引入了 DECODE（开发者代码编辑数据集），这是一个包含 5.36 万次真实世界中 IDE 内 AI 生成代码编辑的集合。

来源： 数据收集自一个被超过 1,000 名开发者使用的 Visual Studio Code (VS Code) 扩展程序。该扩展程序会捕获 AI 生成的内容，并在开发者停顿一秒钟时捕获工作文件的快照。
范围： 该数据集涵盖 Python、TypeScript 和 JavaScript，跨越 20 种不同的 LLM 以及多样化的开发场景（例如 Web 开发、数据分析、机器学习）。
提取流程：
1. 识别： 将包含接受的 AI 生成内容（ $y_0$ ）的代码文件与随后的快照（ $y_t$ ）进行匹配。
2. 提取： 使用 git diff --histogram 来隔离相对于原始生成内容的特定新增、删除或修改的行。这使得原始数据从 650 万行减少到与编辑直接相关的 77.22 万行。
3. 清洗： 使用 CodeBERTScore（阈值 0.68）验证轨迹以确保相关性，并移除格式错误的数据。
4. 隐私： 应用 PII 脱敏流水线（Starcoder/Stack 和 OpenAI Privacy Filter）以移除个人身份信息。
统计数据： 最终数据集包含来自 1,141 名开发者的 5,831 条编辑轨迹，其中轨迹持续时间的平均值为约 50 分钟，每条轨迹的平均编辑次数（Levenshtein 编辑）为 329 次。

2. 开发者行为分析

作者利用 DECODE，通过衡量剩余 AI 代码比例、开发者新增代码以及总编辑量等指标，分析了开发者在何时、为何以及如何编辑 AI 代码。

时间模式： 50% 的编辑发生在接受后的前 50 分钟内，并在 15 分钟后出现大幅下降。
编辑类型： 编辑被分为四类：定制化代码 (10%)、提高质量 (14%)、改变功能 (56%) 和移除生成内容 (9%)。
结果： 31% 的轨迹导致 AI 生成内容的完全移除。剩余代码的分布呈双峰分布：开发者要么保留代码并进行少量修改，要么将其完全丢弃。

3. 基准测试 LLM

研究评估了 LLM 在两个任务上预测代码编辑的能力：

分类： 预测 AI 生成的内容会被删除、保持不变还是被修改。
生成： 在给定初始 AI 生成内容（ $y_0$ ）的情况下，预测代码的最终状态（ $y_t$ ）。
测试模型： 测试了前沿模型（如 GPT-5.2, Claude Sonnet 4.6）和开源模型（如 Qwen2.5-Coder, Llama3.2）在少样本（few-shot）设置下以及使用 LoRA 在 DECODE 上进行微调后的表现。

关键结果

1. 对开发者行为的洞察

快速放弃： 如果 AI 生成的内容不符合开发者的意图，开发者往往会迅速放弃。23% 的轨迹涉及立即移除，随后通常由开发者编写自己的实现。
低增加率： 开发者很少向 AI 生成内容中添加大量新代码；AI 生成内容的最终占比中，开发者新增的部分仅占 20%，且 36% 的轨迹包含的开发者新增代码少于 5%。
顺序编辑： 呈现出一种常见的模式，即开发者首先决定是否保留代码（移除），然后修复错误（质量），接着适应需求（定制），最后修改功能。

2. 通过微调实现的性能提升

微调小模型的优越性： 在 DECODE 上对开源模型（3B 和 7B 参数）进行微调，在分类和生成任务上的表现显著优于前沿模型。
- 分类： 微调后的 3B 模型实现了 0.42–0.45 的 F1 分数，超过了像 Claude Sonnet 4.6 (0.37) 和 GPT-5.2 (0.32) 这样的前沿模型。
- 生成： 微调后的模型在 Levenshtein 相似度上比其基础版本提升了 +0.15 到 +0.22，并且显著优于前沿基准模型（例如，比前沿基准提升了 +0.17）。
数据量： 随着模型在训练过程中接触到更多的编辑步骤（最多 4 步），性能得到了提升，这表明捕捉编辑的顺序性质至关重要。
无性能退化： 在 DECODE 上进行微调并未降低模型在标准基准测试（HumanEval, MBPP）上的代码生成能力；在某些情况下（如 Qwen2.5-Coder-3B），性能甚至略有提升。

重要性与主张

论文认为，以开发者为中心的机器学习方法对于下一代 AI 编程助手是必要的。核心结论如下：

对齐优于正确性： 标准基准测试关注代码的正确性（pass@k），但现实世界的实用性取决于代码与开发者意图及上下文的对齐程度。如果代码不易于适配，即使是“正确”的代码，开发者也会将其丢弃。
可编辑性作为一项指标： AI 生成代码是否易于编辑（可编辑性）是一个关键但尚未得到充分衡量的因素。未来的模型应该能够检测出那些很可能被丢弃的生成内容。
时间建模： LLM 必须捕捉开发者编辑的顺序性和时间特性（例如，移除操作发生在早期，功能修改发生在后期）。仅在原始 Git 提交上进行训练无法捕捉到这种动态过程。
数据质量： 对于训练处理手动代码编辑的模型而言，真实世界的交互数据（如 DECODE）优于合成数据或基于 Git 的数据。即使是经过高质量、真实世界编辑数据微调的小型模型，也能在性能上超越许多庞大的前沿模型。

作者总结道，未来的 AI 编程助手需要新的建模和评估范式，这些范式必须明确考虑开发者交互、个性化以及代码编辑的迭代性质。