引言:
从“代码补全”到“编辑预测”
在过去的两年中,大语言模型(LLMs)从根本上重塑了软件开发的工作流程。“智能体编码”(Agentic Coding)等新范式使开发者能够根据高层指令快速生成整个代码仓库级别的代码,显著提升了开发速度。然而,社区中逐渐流行起一个说法——“AI 善后工程师”:Agentic Coding 虽能迅速完成 80%的任务,但剩下的 20%——那些涉及逻辑校准、边界处理、跨模块协调与工程细节打磨的部分——往往仍需人工介入。
尽管如此,传统的代码补全工具仍局限于“中间填充”(Fill-In-the-Middle, FIM)范式。这类模型通常仅基于局部上下文,在光标位置预测一段连续的代码片段,缺乏对整体编辑意图的全局理解。这种单步、静态的方法在现实场景中表现不足——例如多行代码修改、函数重构或跨文件依赖调整——无法支持连贯且结构化的开发操作序列。
我们推出了 Qoder NEXT 模型。Qoder NEXT 的核心理念是:代码开发本质上是一系列连续的、上下文感知的编辑动作(Action Sequence),而非孤立的 Fill-In-the-Middle 生成任务。
为解决这一局限性,我们提出一个端到端的框架,其建立在三大关键组件之上:
- 冷启动训练:通过抽象语法树(AST)精确模拟真实世界的代码编辑轨迹;
- 数据飞轮机制:从高探索性部署的原型模型中捕获真实的编辑行为;
- ActionRL:一种新颖的偏好对齐算法,确保在序列化决策层面深度契合开发者的意图。
破局 FIM:
基于 AST 解析的编辑轨迹模拟
传统的 FIM 训练模式通常是将代码随机掩盖一段,让模型预测空缺内容。这种方式学习到的是代码的“静态概率分布”,而非“动态修改逻辑”。为了让 Qoder NEXT 模型学会“如何编辑”,我们放弃了随机掩码,转而利用 AST(抽象语法树) 来逆向构造真实的编辑轨迹。
结构化意图的抽象
在真实开发中,一个意图往往关联着多处改动。我们利用 AST 解析器(如 Tree-sitter)在数百万行高质量代码库中识别出核心编辑场景,并自动化地模拟用户的操作链条。
以标识符重命名(Identifier Renaming)为例,这不仅是文本替换,而是一个典型的结构化编辑动作:
- 动作触发(Trigger Action) :我们定位到一个变量、函数或类的声明位置,并模拟用户对其进行重命名。
- 联动推荐(Ripple Effect) :利用 AST 的作用域分析(Scope Analysis)和引用链(Reference Chain),自动找出该标识符在当前项目中的所有调用点。
- 轨迹构建:我们将后序的系列改动转化为有序的动作序列:[Edit Action 1] -> [Edit Action 2] -> ...。
模拟复杂的真实编辑
除了标识符重命名,Qoder NEXT 的冷启动数据还涵盖了以下高阶场景:
- Signature Change(签名变更) :当用户在函数定义中增加一个参数时,模型在所有调用处,自动插入占位符或匹配局部变量;
- Logic Extraction(逻辑提取) :将一段代码块重构为独立变量/函数,模型在原位置调用独立变量/函数;
- Type Refinement(类型细化) :从接口类型到接口的具体实现;
- Method Override(方法覆写) :在父类或接口中新增一个方法签名时,自动识别子类并生成符合语义的覆写实现;
- Error Refactoring(错误重构) :将LSP暴露的异常或错误代码片段,重构为逻辑正确的代码片段;
- Automatic Import(自动导入) :引用一个尚未导入的类型、函数或常量时,在正确作用域插入符合项目风格的导入语句。
通过 AST 模拟,Qoder NEXT 模型在预训练阶段接触的就是“有因果关系的修改”,这奠定了它处理跨行、跨语义编辑的基础。
构建数据飞轮:
从原型模型到偏好捕获
轨迹模拟解决了“从 0 到 1”的问题,但真实的开发场景远比 AST 模拟复杂。开发者的长程历史编辑是什么?他们为什么拒绝某个补全?这些信息只能从真实交互中获取。
高探索性的交互设计
我们将 Qoder NEXT 原型模型集成到 IDE 中,作为一个高探索性(High Exploration)的功能组件。Qoder NEXT 始终在预测开发者的“下一步动作”。当用户进行一次编辑后,模型会立即计算出潜在的后续编辑点,并及时展示给用户。
这种设计允许我们收集(在用户隐私策略允许的情况下)到极高质量的用户行为日志:
- 显式采纳(Explicit Accept) :用户通过Tab键接受了整串编辑建议。
- 局部修正(Partial Edit) :用户接受了前两个动作,但对第三个动作进行了手动微调。
- 显式拒绝(Explicit Reject) :用户直接忽略建议继续输入,或者按下 Esc 键。
信号收集与偏好建模
通过对原型模型的数据标注,我们将显式行为转化为 (Context, Response_Accepted 1, Response_Accepted 2, ..., Response_Rejected 1, Response_Rejected 2, ...) 的多元组。
传统的模型优化只关注“采纳”的正例,但在 Qoder NEXT 的进化中,“拒绝”信号蕴含的信息量更大。如果模型推荐了 obj.getName(),而用户手动改成了 obj.getDisplayName(),这说明模型在特定语义场景下缺乏对业务逻辑的判断。这种细微的偏好差异,正是提升模型“准确率”的关键。
突破对齐困境:
ActionRL 的诞生
在利用用户反馈进行 RLHF(强化学习)时,传统的对齐算法展现出了明显的副作用。在连续动作序列中,正例和负例往往高度耦合,这要求我们必须进行更细粒度的损失计算。
序列耦合带来的“过度抑制”
在代码编辑中,一组对齐序列中,正例序列y^w和负例序列y^l通常具有极长的公共子串。一个案例如下:
- Context: user = User.find(id)
- 用户真实意图 y^w: user.update(name: "New"); user.save(); print("Done");
- 模型错误预测 y^l: user.update(name: "New"); user.delete(); print("Done");
在这里,第一个动作 user.update(name: "New")和第三个动作print("Done")是完全正确的,分歧点出现在第二个动作。
- 朴素对齐算法的局限:它将 y^l作为一个整体进行惩罚。由于y^l包含了正确的 user.update; print,模型在优化过程中会降低对这部分正确动作的概率分配。
- 结果:模型变得“畏缩”,甚至不敢给出任何建议,因为它害怕后续某个微小的错误导致整个补全路径被否定。
ActionRL 的方案设计
为解决这一问题,我们提出 ActionRL,一种聚焦于关键分歧动作的细粒度偏好优化算法。其核心思想是:将学习目标从“整个序列的优劣”细化为“在首个错误决策点上做出更优选择” 。
A. 定位关键分歧动作
给定一组偏好样本——其包含标注为“采纳”的轨迹(chosen trajectory)与标注为“拒绝”轨迹(rejected trajectory),ActionRL 首先对每条轨迹进行逐 action 对齐,识别出它们首次出现差异的位置。该位置即为行为分歧点(Behavioral Divergence Point, BDP),代表模型在该时刻做出了不同的动作选择。
值得注意的是,分歧点之前的上下文完全一致,意味着模型在此前的推理路径上并无偏差。因此,性能差异可归因于该点的动作选择。
B. 截断似然估计
不同于朴素对齐算法对整条序列计算似然,ActionRL 将优化目标局部化至分歧点处的条件分布。模型被鼓励在共享上下文条件下,赋予采纳或修正动作更高的概率,同时抑制拒绝动作的似然。这一设计确保梯度更新直接作用于导致结果分化的决策节点,而不会被后续action所干扰。
C. 损失函数重构
在许多实际场景中,拒绝轨迹在分歧点之后包含部分正确的子序列,ActionRL 通过截断损失计算范围,有效屏蔽了此类后置信息的干扰,使对齐训练信号更加聚焦且鲁棒。通过这种形式化处理,ActionRL 确保了:
分歧点惩罚:模型明确感知到y_{<t^}(共有前缀)是中性的或受保护的,真正的惩罚集中在 y^l_{t^}这个错误的决策点上。
后缀忽略:对于 t > t^*的部分,由于负例序列已经偏离意图,其后续内容(即便可能包含正确动作)也不会对模型产生错误的干扰。
实验结果与工程思考
在实践中,Qoder NEXT 模型展现出了显著优越的灵活性。
模型效果优化
经过 ActionRL 对齐后,Qoder NEXT 模型的关键性能指标显著提升:
- 代码生成比例提升超过 53% ;
- 执行一致性显著增强:模型能够遵循“启动重构即完成全套动作”的内在逻辑,显著减少不完整执行的问题。
这些技术进步直接转化为实际的用户价值:
- 代码采纳率提高 65% ;
- 细粒度推理准确率持续稳步提升。
实验结果验证 Qoder NEXT 在应对专业软件开发中复杂、精细需求方面的可靠性与实用性显著提升。
避免过度保守的预测
在对比实验中,我们观察到,采用朴素对齐算法训练的模型虽在首Action准确率上略有提升,但其在多样化场景下的覆盖率显著下降,模型表现出为避免生成错误输出而倾向于抑制预测行为。相比之下,ActionRL 在维持高准确率的同时,显著提升了模型的预测活跃度与场景覆盖能力,避免了因局部错误惩罚而导致的全局保守行为。
实时反馈循环
目前,Qoder NEXT 模型的数据飞轮每 24 小时循环一次。我们从原型环境日志中提取分歧样本,经过自动化的 ActionRL 训练后,次日便能观察到模型在真实场景下的效果改进。
总结与未来展望
从 FIM 到 Qoder NEXT 的转变,是从“代码补全”走向“编辑预测”的关键一步。Qoder NEXT 模型不只是在帮你写代码,它是在理解编辑逻辑,并基于理解进行预测。
通过 AST 注入结构化知识,再通过 ActionRL 在序列层面精细化地对齐用户偏好,我们正在构建一个能够真正理解“下一步该做什么”的 AI 伙伴。在未来,随着动作空间的进一步扩展,Qoder NEXT 将具备完整覆盖研发流程(如完整的功能编写、测试用例生成及执行、代码提交、Bug修复)的能力。
立即更新至Qoder AI IDE 版本至0.2.28体验Qoder NEXT全新升级能力
关注我,掌握Qoder最新动态并且观看视频