An Empirical Study of Proactive Coding Assistants in Real-World Software Development 精读

论文链接： arXiv:2605.05700

开源代码： 论文暂未提供公开代码仓库链接。但作者提供了受控访问评估平台，研究者可凭机构信息申请访问 ProCodeBench 并提交模型/Agent 系统获得评估结果。

发表机构： Lehui Li*（山东大学软件专业本科生）、Ruixuan Jia*、Guo-Ye Yang、Jia Li†（通讯作者）。其中 Jia Li 疑似隶属清华大学（其多篇论文代码托管于 TsinghuaISE 组织），长期合作者包括北京大学的 Ge Li（李戈）和 Zhi Jin（金芝）。本文是高校（山东大学 + 清华）与企业工业开发者合作采集数据的典型案例——1246名志愿者均来自工业界，涵盖后端、前端、全栈、算法和数据库五大开发场景。

投稿状态： arXiv 预印本，2026年5月7日提交，学科分类 cs.SE（软件工程）、cs.AI（人工智能）。

* 表示共同第一作者，† 表示通讯作者。

一、论文背景

1.1 编码助手的演进：从"你问我答"到"我替你想"

在过去两三年里，大语言模型（LLM）驱动的编码助手经历了一场飞速的能力跃迁。从最早的代码补全（编辑器里按 Tab 自动补全一行代码），到多轮对话编程（在聊天框中用自然语言描述需求，AI 帮你写代码），再到仓库级自主 Agent（给定一个 GitHub Issue，AI 自动浏览代码库、定位问题、编写修复并提交 PR），这些工具已经深度融入了现代软件开发的工作流。

然而，几乎所有现有的编码助手——无论是商业产品（GitHub Copilot、Cursor、Windsurf）还是学术系统（SWE-Agent 等）——都遵循一个共同的交互范式：被动式交互（Reactive Interaction）。所谓"被动"，就是只有当开发者明确发出指令后，助手才提供帮助。比如你在聊天框里输入"帮我写一个排序函数"，它才会生成代码；你不说，它就不动。

这种"你问我答"的模式存在两个现实痛点：

1. 认知负担重：开发者必须在编码过程中不断构思和编写详细的指令（Prompt）。比如你想让 AI 帮你"给所有 API 调用函数添加错误重试机制"，你需要用非常精确的语言描述这个意图——需要修改哪些文件、重试几次、退避策略是什么——这本身就需要花费不少心力。

2. 意图难以表达：更关键的是，在很多复杂开发场景中，开发者可能自己也难以清晰表达当前在做什么。软件开发是一个高度非线性的过程——你可能在看一个文件时突然发现另一个文件的 bug，然后去修复它，再回到原来的任务。这种"在多个任务间跳转、穿插着试错和探索"的工作方式，很难用一句简单的自然语言指令概括。

1.2 主动式编码助手：一个新方向

为了解决这些问题，研究者们提出了主动式编码助手（Proactive Coding Assistant）的概念。它的核心思想是：不等你开口，先猜你要做什么。

具体来说，主动式编码助手持续监控你在 IDE（集成开发环境）中的一系列操作——比如你打开了哪些文件、编辑了什么代码、在终端执行了什么命令、复制粘贴了什么内容——然后从这些操作序列中推断你当前的隐含意图（Latent Intent），并在你需要之前主动提供建议。

举个例子：假设你正在开发一个 Python 项目，你先复制了一段文本 “handle API call error and retry”，然后打开 utils.py 定义了一个 retry_with_backoff 装饰器，接着打开 alpha_vantage_common.py 添加了 import time，又切回 utils.py 检查装饰器代码…… 主动式编码助手看到这些操作序列后，可以推断出你的意图：“将新定义的 retry_with_backoff 装饰器应用到 dataflow 模块中所有 API 调用函数上”——然后主动提供相关的帮助，比如自动帮你找到所有需要添加装饰器的函数。

已有用户研究表明，这种主动式辅助能将开发者的任务性能平均提升 12%–18%。

1.3 一个核心困境：没有真实数据怎么办？

主动式编码助手听起来很美好，但面临一个根本性的困境：缺乏大规模的真实开发者行为数据。

为什么数据这么难获取？因为主动式辅助需要在真实开发过程中持续记录开发者的 IDE 操作——你打开了什么文件、编辑了什么代码、光标在哪里、终端执行了什么命令——这些数据包含大量敏感信息（商业代码、内部项目结构、个人工作习惯），涉及严重的隐私问题。收集成本高、法律风险大。

于是，现有研究普遍采用了一个"退而求其次"的方案：用 LLM 模拟开发者的行为数据。具体做法是用一个 LLM 扮演"虚拟开发者"（User Agent），让它模拟在 IDE 中的操作序列（打开文件、编辑代码、执行命令等），然后生成对应的意图标签。这些模拟数据被用于训练和评估主动式编码助手。

但这里有一个悬而未决的核心问题：LLM 模拟的"假数据"能忠实反映真实开发者的行为吗？如果模拟数据与真实行为之间存在显著差距（即"Sim2Real Gap"），那么在模拟数据上训练和评估的主动式编码助手，到了真实场景中可能完全不可靠。

本文正是为了回答这个问题而展开的大规模实证研究。

二、论文定位和关联工作

2.1 研究脉络：从被动到主动的范式跃迁

主动式编码助手是 LLM Agent 研究中一个新兴且快速发展的方向。本文在这个研究脉络中处于关键位置——它是第一个用大规模真实数据系统性检验模拟数据可靠性的工作。

核心关联工作包括：

2.2 本文的独特定位

本文的独特定位可以用三个"第一"来概括：

1. 第一个大规模真实世界主动式代码辅助数据集（1246名工业开发者，463万条操作事件）
2. 第一个真实世界开发场景中的主动式意图预测基准（ProCodeBench）
3. 第一个系统性比较模拟数据、真实数据和混合数据训练效果的研究

在主动式辅助的研究图谱中，本文位于"数据真实性检验“这一关键节点——它不提出新模型，而是通过扎实的实证分析，揭示现有研究范式的局限性，为后续研究指明方向。

三、问题定义

3.1 从"如何让AI主动帮你编程"到"模拟数据到底靠不靠谱”

这篇论文面对的核心问题，本质上不是一个算法设计问题，而是一个实证验证问题。但为了理解这个实证问题，我们需要先理解主动式编码助手的任务定义。

主动式意图预测任务可以形式化地描述为：

给定开发者在 IDE 中产生的一连串操作记录（IDE 交互轨迹），以及当前代码仓库的上下文信息，预测开发者当前的隐含意图（用自然语言描述）。

其中，每个 IDE 操作表示为一个四元组：o_i = (操作类型, 目标实体, 操作内容, 时间戳)。比如"在 auth.js 的第 42 行添加了 if (user === null) return;“就是一个操作。

但本文要回答的不是"如何更好地预测意图”，而是三个更深层的实证研究问题：

• RQ1：LLM 生成的模拟 IDE 交互轨迹能否忠实捕捉真实开发者的行为模式和潜在意图？（即：模拟数据靠不靠谱？）
• RQ2：在真实的 IDE 交互轨迹上，现有的主动式编码助手实际表现如何？（即：当前最先进的方法在真实数据上到底行不行？）
• RQ3：用模拟数据训练能否改善真实世界场景下的意图预测？模拟数据和真实数据的关系是什么？（即：模拟数据能用吗？怎么用？）

3.2 问题的本质抽象

如果剥离掉"主动式编码助手"这个具体场景，本文研究的问题可以抽象为：

在一个需要从人类行为序列中推断隐含意图的任务中，当缺乏大规模真实人类行为数据时，研究者普遍使用 AI 模拟数据作为替代。问题是：AI 模拟的行为数据与真实人类行为数据之间的差距有多大？基于模拟数据训练和评估的模型，能否在真实场景中可靠工作？

这是一个在 AI 研究中具有广泛适用性的问题——不仅在编程助手领域，在对话系统、推荐系统、自动驾驶等需要理解和预测人类意图的领域都同样存在。

四、问题解法

4.1 整体研究设计：三个阶段回答三个问题

本文的研究方法论包含三个阶段，每个阶段回答一个研究问题：

阶段1: 数据收集与差距分析 → 回答RQ1（模拟数据靠谱吗？）
阶段2: 基准构建与模型评估 → 回答RQ2（现有方法在真实数据上行不行？）
阶段3: 训练方案比较         → 回答RQ3（模拟数据怎么用？）

4.2 阶段1：大规模数据收集与差距分析

真实数据怎么收集？

研究团队开发了一个 VS Code 扩展，安装在志愿者的 IDE 中持续记录八种类型的开发者操作：

他们招募了 1,246名经验丰富的工业开发者（不是学生！），覆盖后端（33.1%）、前端（23.0%）、全栈（16.7%）、算法（14.7%）和数据库（12.5%）五大场景。每位志愿者在连续三天内正常工作于自己的工业项目，扩展全程后台记录。最终收集了约 463万条 操作事件。

模拟数据怎么构建？

为了进行公平的对比，研究团队为每条真实轨迹构建了一条配对的 LLM 模拟轨迹。模拟器获得的信息包括：

• 与真实开发者相同的个人档案（工作背景、开发经验、技术栈）
• 约束模拟轨迹的长度与配对的真实轨迹一致
• 使用相同的八种操作类型

这确保了对比的公平性——模拟器知道"这个人是谁、在做什么类型的项目"，只需要模拟"这个人在 IDE 里会怎么操作"。

差距分析的三个维度

研究团队从三个角度对比了真实数据和模拟数据：

（1）行为多样性

真实开发者的操作类型分布呈现明显的长尾模式——虽然 cursor_selection（~40%）和 view switching（~13%）占比最大，但所有八种操作类型都有可观的分布。这说明开发者在写代码之前，会花大量时间阅读、浏览、检查和导航代码。

而 LLM 模拟数据集中在少数操作类型上（主要是编辑和导航），缺乏真实开发中的操作多样性。

（2）时间模式

真实开发者操作间的时间间隔呈现显著的双峰分布：

• 一个峰在约 0.1秒（快速连续操作，如连续点击、快速滚动）
• 另一个峰在 数十秒（停顿思考、阅读代码、查找资料）

这反映了真实开发中"短时间密集操作"与"长时间思考停顿"交替出现的节奏。

而 LLM 模拟数据呈现以约 1秒 为中心的单峰分布——操作间隔非常均匀和规律，完全不像人类的工作节奏。

（3）探索和噪声模式

真实开发过程中充满了"看起来无关"的操作——试探性地打开一些文件、冗余的页面切换、写了又撤销的代码。论文称之为噪声模式，这些操作与最终意图只弱相关，但它们是真实开发过程的自然组成部分。

LLM 模拟轨迹则几乎不包含这种探索性行为，总是沿着一条从目标到实现的直线行进，表现出论文所说的"过度简化偏差"。

用一个对比例子来直观感受：

真实开发者的轨迹（意图：修复登录处理函数中的空指针崩溃）

[1] 打开 auth.js → [2] 导航到 handleLogin() → [3] 设置断点 → [4] 运行 npm run dev → [5] 打开 config.js（无关！）→ [6] 打开 README.md（无关！）→ [7] 返回 auth.js（冗余！）→ [8] 导航到 userService.js → [9] 返回 auth.js（冗余！）→ [10] 编辑：添加 null guard → [11] 撤销编辑（试错！）→ [12] 重新编辑：添加带 fallback 的 guard → [13] 运行测试 → [14] 选择测试输出 → [15] 修复边界情况 → [16] 再次运行测试

LLM 模拟的轨迹（意图：给 API 请求添加重试逻辑）

[1] 打开 api.js → [2] 导航到 fetchData() → [3] 编辑：添加重试 wrapper → [4] 编辑：添加最大重试配置 → [5] 打开测试文件 → [6] 编辑测试用例 → [7] 运行测试

可以看到，真实轨迹中充满了"绕路"（步骤5-9）和"试错"（步骤10-11），而模拟轨迹则像一台精准的机器，直奔目标。

核心发现❶：LLM 模拟数据无法忠实捕捉真实开发者行为——行为多样性低、时间模式过于规律、缺乏探索性和试错行为。

4.3 阶段2：构建 ProCodeBench 基准并评估现有方法

数据标注流程

原始的 IDE 操作轨迹不能直接用于评估——需要从中提取出标准化的"意图预测实例"。研究团队设计了三步标注流程：

1. 意图识别：用滑动窗口（每次取50个连续操作），让 LLM 从中识别可能的意图、定位起止操作、生成初始的意图描述。
2. 意图过滤：先通过启发式规则保留有大量代码编辑或明确 AI 请求的段落，再用 LLM 检查保留的段落是否连贯且与意图一致。
3. 人工审查：两位领域专家独立检查候选，纠正错误的意图描述，恢复被错误过滤的有效候选。

最终得到 5,492个 有效评估样本，按时间顺序划分（避免数据泄漏）为训练集（65.1%）、验证集（20.8%）和测试集（14.1%）。

评估方案：Pass@K

评估采用 LLM-as-a-Judge 策略——用一个独立的 LLM 判断模型生成的意图描述与开发者的真实意图是否语义等价。核心指标是 Pass@K：对每个样本，模型独立生成 K 个意图描述，如果至少有一个被判定为等价，就算预测正确。

实验结果：现有方法"远未达标"

论文评估了13个基线方法，包括7个当前最强的 LLM、4个检索增强方法和2个基于 Agent 的方法：

纯 LLM 表现（Pass@1）：

即使是最强的 Claude Sonnet 4.6，Pass@1 也仅有 13.57%——也就是说，给真实开发者的操作序列，最好的 AI 模型也只能在不到七分之一的情况下正确猜出开发者的意图。

值得注意的是，模型排名与通用软件工程基准上的排名不一致——例如 GPT-5.4 在通用基准上是顶级模型，但在这个任务上仅达到 6.59%，落后于 Claude Sonnet 4.6 和 Gemini 3.1 Pro。这说明主动式意图预测是一个与通用代码生成能力不同的能力维度。

检索增强和 Agent 方法有改善，但仍然有限：

加入仓库级代码上下文（通过 RepoCoder、CodeRAG、GraphCoder、RepoGraph 等检索方法）后性能持续提升，表明仓库信息有助于理解 IDE 操作背后的目的。基于 Agent 的方法（SWE-Agent、A-RAG）通过多轮工具调用取得了最强结果（A-RAG + GPT-5.4 达到 35.57%），但代价是每次预测平均需要 23次工具交互——效率极低。

核心发现❷：现有方法在真实世界数据上远未达到可靠水平，基于模拟的评估可能高估了模型的真实意图预测能力。

4.4 阶段3：训练研究——模拟数据怎么用？

研究团队比较了三种训练方案：

三个关键发现：

1. 仅用模拟数据反而有害：+Sim. 方案在所有模型上都降低了性能（低于原始基线），说明模拟数据的分布与真实数据差距太大，直接在上面训练会导致"负迁移"。

2. 真实数据有效但提升有限：+Real 方案显著提升了性能（如 Qwen-3-8B 从 2.53% 提升到 5.84%），但绝对值仍然很低。

3. 混合方案最优：先在模拟数据上训练、再在真实数据上微调的 +Sim.→Real 方案取得了最好的结果，比 +Real 分别提升了 1.79、1.59 和 1.45 个百分点。训练损失曲线也显示，使用模拟数据初始化的模型在真实数据微调期间收敛更快、达到更低的最终损失。

核心发现❸：模拟数据不能替代真实数据，但可以作为真实数据训练前的有效初始化——两者是互补的，而非可互换的。

五、必要知识反推

如果我们假设一个完全不了解这个领域的人要从零开始完成这篇论文，他需要掌握哪些必要的知识和信息？

5.1 领域知识

1. LLM 编码助手的工作原理：需要理解当前编码助手（如 Copilot、Cursor）的基本架构——它们如何与 IDE 集成、如何获取上下文、如何生成建议。否则无法理解"被动式"和"主动式"的区别。

2. IDE 交互轨迹的数据结构：需要知道现代 IDE（如 VS Code）提供了哪些扩展 API 来监控用户行为，以及这些行为数据如何被结构化存储。这是设计数据收集方案的基础。

3. 主动式意图预测任务的形式化定义：需要将"让 AI 猜你在做什么"这个模糊想法，抽象为输入（IDE 轨迹 + 仓库上下文）→输出（自然语言意图描述）的机器学习任务。

5.2 方法论知识

4. Sim2Real Gap 的概念：来自机器人学和具身智能领域的 Sim2Real（Simulation-to-Reality）问题——在模拟环境中训练的策略能否迁移到真实环境。本文将这个概念引入了代码智能领域。

5. 受控实验设计：需要知道如何设计公平的对比实验——为每条真实轨迹构建配对的模拟轨迹，控制变量（相同的开发者档案、相同的操作类型集、相同的轨迹长度），才能得出可靠的差距分析结论。

6. LLM-as-a-Judge 评估策略：当标准指标（如 BLEU、ROUGE）无法衡量"语义等价性"时，使用 LLM 作为评判者的方法。需要理解其优势和局限性。

7. Pass@K 指标的设计动机：意图预测存在"一对多"的特性——同一个隐含意图可能有多种合理的自然语言表述。Pass@K 允许模型生成多个候选，只要有一个匹配就算正确，这比严格的精确匹配更公平。

5.3 工程知识

8. VS Code 扩展开发：需要能够开发一个能持续后台记录八种 IDE 操作的扩展，并确保对开发者工作流的影响最小化（否则志愿者会拒绝使用或行为失真）。

9. 大规模数据收集的隐私与合规：工业开发者的 IDE 操作可能包含商业机密。需要设计完善的数据收集协议、匿名化处理和受控访问机制。

10. 标注流程设计：从原始轨迹到标准化评估样本的三步标注流程——需要平衡自动化（LLM 辅助）和人工审查的质量与效率。

5.4 知识融合

以上知识和信息的融合路径是：

领域洞察（编码助手存在被动式局限 + 缺乏真实数据）→ 问题抽象（Sim2Real Gap 是否存在？）→ 工程实现（VS Code 扩展收集数据）→ 实验设计（配对比较 + 受控分析）→ 基准构建（三步标注 + Pass@K 评估）→ 模型评估（13个基线全面测试）→ 训练分析（三种方案对比）→ 结论提炼（模拟数据的局限性和互补性）

关键的知识融合点在于：将"Sim2Real Gap"这个来自机器人学的概念，与"主动式编码助手"这个软件工程问题结合起来——认识到在用户行为模拟领域同样存在模拟到真实的迁移问题。

六、论文中可以提取的通用性灵感

6.1 AI 模拟人类行为的"过度简化偏差"

灵感：当 LLM 被用来模拟人类行为时，会产生系统性的简化——行为更规律、更线性、缺乏试错和探索。

这个发现不仅适用于 IDE 操作模拟，在任何需要 AI 模拟人类行为序列的场景中都可能成立——比如对话系统中的用户模拟、推荐系统中的用户行为模拟、自动驾驶中的人类驾驶行为模拟等。研究者在使用 AI 模拟数据时，应该警惕这种系统性的简化偏差。

6.2 模拟数据的"预训练范式"——不能替代但可以补充

灵感：领域不匹配的模拟数据直接用于微调会损害性能，但作为预训练/初始化阶段却有益。

这类似于大模型预训练的思路——在"不太准确但大量"的数据上先学到大致的模式，再在"准确但少量"的数据上精调。这个范式可以推广到任何缺乏真实数据但可以低成本获取模拟数据的 AI 应用场景。

6.3 评估基准的数据模态至关重要

灵感：基于模拟数据的评估可能系统性地高估模型的真实能力。一个在模拟基准上表现很好的方法，可能在真实场景中完全不可用。

这提醒所有 AI 研究者：基准测试的数据来源和数据真实性，与模型架构和算法同样重要。在论文中报告高性能时，应该明确说明评估数据的来源和局限性。

6.4 “噪声"是有价值的信息

灵感：真实人类行为中的"噪声”（无关浏览、冗余导航、试错）不是应该被过滤掉的干扰，而是理解人类认知过程的重要信号。

论文的消融实验表明，移除终端执行信息导致显著性能下降——而终端输出（如测试失败信息）恰恰是真实开发中"试错"过程的关键组成部分。这意味着在设计 AI 系统理解人类行为时，不应简单地追求"干净"的数据，而应该学会从"噪声"中提取信息。

6.5 通用能力 ≠ 专用能力

灵感：在通用基准上表现最强的模型，在特定任务上未必最优。

GPT-5.4 在通用软件工程基准上是顶级模型，但在主动式意图预测上仅排第六（Pass@1 = 6.59%）。这说明"理解人类隐含意图"是一种与"生成高质量代码"不同的能力维度。在选择模型时，应该在目标场景的真实数据上评估，而不是仅参考通用排行榜。

6.6 受控访问评估平台：隐私与开放的科学折中

灵感：当数据因为隐私原因不能公开发布时，“受控访问评估平台"是一个平衡隐私和可复现性的有效方案。

研究者不能下载完整数据集，但可以提交模型并获得在真实数据上的评估结果。这个设计模式可以推广到其他涉及敏感数据的 AI 研究领域（如医疗、金融、法律）。

七、总结与展望

这篇论文通过一项大规模的实证研究，揭示了一个在主动式编码助手研究中被广泛忽视的问题：我们用来训练和评估 AI 的"假数据”，和真实开发者的行为之间存在显著差距。这个差距不是微小的偏差，而是系统性的——模拟数据更简单、更规律、更线性，而真实开发过程充满了复杂性、非线性和噪声。

论文提出的 ProCodeBench 基准为后续研究提供了一个真实的评估标准，而训练研究则为如何有效利用模拟数据提供了实用指南：不要用模拟数据替代真实数据，但可以在真实数据之前用它做初始化。

对于未来的研究方向，论文暗示了几个重要的开放问题：

• 如何让 LLM 模拟出更真实的开发者行为（包含探索、试错和非线性时间模式）？
• 如何高效地利用仓库级代码上下文（当前 Agent 方法效果好但效率极低）？
• 如何设计更有效的意图标注方法（当前的三步流程仍依赖 LLM 和人工）？
• 能否从"被动式+主动式"的混合范式中获益？

这些问题的答案，将决定主动式编码助手能否从学术原型走向真正实用的开发工具。

参考文献

[1] Li, L., Jia, R., Yang, G.-Y., & Li, J. (2026). An Empirical Study of Proactive Coding Assistants in Real-World Software Development. arXiv:2605.05700.

[2] Lu, Y. et al. (2024). Proactive Agent: Shifting LLM Agents from Reactive Responses to Active Assistance. ICLR 2025.

[3] Zhao, Z. et al. (2025). CodingGenie: A Proactive LLM-Powered Programming Assistant. FSE 2025.

[4] Kim, J. et al. (2025). ProPerSim: Developing Proactive and Personalized AI Assistants through User-Assistant Simulation. ICLR 2026.

[5] Tang, R. et al. (2025). ProAgentBench: Evaluating LLM Agents for Proactive Assistance with Real-World Data. arXiv:2602.04482.

[6] Yang, J. et al. (2024). SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. NeurIPS 2024.

[7] Zhou, H. et al. (2026). Mind the Sim2Real Gap in User Simulation for Agentic Tasks. arXiv:2603.11245.