连按Tab完成重构：蚂蚁CodeFuse团队提出无指令代码编辑框架NES

在 AI coding 工具快速演进的今天，“让模型写代码” 正在从补全、问答走向Agent 端到端编程：从需求拆解、跨文件修改到测试修复，一次任务动辄涉及多轮规划与执行。

但在真实开发里，最频繁、最消耗注意力的往往不是 “大任务”，而是无处不在的小编辑：一次重命名、一次参数补全、一次跨文件 refactor 的连锁修改…… 这些动作密集、节奏快，任何额外的提示词输入、等待模型响应或频繁切换上下文，都会打断开发者的 “心流”。

蚂蚁集团的 CodeFuse 算法团队长期从事大模型代码生成 / 编辑、AI IDE 智能辅助与工程化落地研究。此次在 FSE 2026 的 Industry Track 提出了NES（Next Edit Suggestion）：一个无指令（instruction-free）、低延迟（<250ms）的 “下一步编辑建议” 框架。NES 不要求开发者先用自然语言描述意图，而是从历史编辑轨迹（historical editing trajectories）里学习开发者的目标与习惯，直接给出 “下一处该改哪里、该怎么改” 的建议，并把交互简化为连续的 Tab → Tab → Tab。

FSE（ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering）是全球软件工程领域的顶级学术会议（CCF-A 类）其中的 Industry track 专门面向卓越应用研究，重点考察工作的显著性 (Significance)、稳健性 (Soundness) 以及对当前工业实践的改进程度。

• 论文：NES: An Instruction-Free, Low-Latency Next Edit Suggestion Framework Powered by Learned Historical Editing Trajectories（FSE 2026）
• arxiv：https://arxiv.org/html/2508.02473v3

一、大模型会写，但 “编辑协作” 仍不够顺滑

近两年，代码大模型工具显著提升了代码生成与编辑效率，但在代码编辑（code editing）这类高频任务中，现有范式仍有两类关键痛点：

1. 过度依赖显式指令，打断心流

很多研究与产品的编辑能力建立在 “用户先用自然语言描述修改意图 → 模型再生成 patch” 的链路上。现实中，开发者并不总能（也不愿意）把 “下一步要改什么” 先说清楚：尤其在重构、维护、跨文件依赖调整中，编辑意图往往是边读边改、逐步推进的。

2. 编辑任务强时效，延迟直接影响可用性

代码编辑与补全一样是 “即时交互” 场景。论文指出用户通常期望 1 秒内反馈，而很多方法还依赖较重的理解、检索或推理流程，导致延迟上升，进一步放大 “打断感”。

更重要的是：编辑并非一次性动作。一个 “看似简单” 的需求（例如把一个组件新增属性）往往会触发连锁修改：改接口、改实现、改调用点、补参数…… 如果每一步都要重新描述、重新等待，就很难形成真正的协作体验。

二、NES 从历史编辑轨迹去判断 “下一步如何改”

NES 的出发点来自一个朴素但被低估的事实：

开发者的目标与习惯，往往沉淀在他们的历史编辑模式里。

例如重复的重构动作、跨文件依赖的修改路径、某类 API 的调用顺序、团队内的代码风格等，都能从 “编辑轨迹” 中体现出来。NES 选择把这些轨迹当作 “隐式意图信号”，从而绕开显式自然语言指令。

为此，NES 设计了一个双模型架构：

• NES-Location：预测 “下一处最可能的编辑位置”（跨文件 / 跨模块的导航建议）。
• NES-Edit：在到达位置后生成 “应该如何改” 的具体代码修改。

三、从 “轨迹采集 → 数据构建 → 两阶段训练 → 推理加速” 闭环落地

NES 的实现可以拆成三个关键环节。

3.1 轨迹采集：用增量 diff 捕获真实编辑操作

要让模型学到 “编辑习惯”，首先要能稳定捕获编辑轨迹。NES 在 IDE 插件侧实现了实时、增量的差异检测（incremental difference detection），把计算范围从 “全文件 diff” 收缩到 “当前被修改的局部片段”，以降低开销并提升实时性。

同时，论文提出了自定义的NES diff 格式：不仅标注新增 / 删除 / 保留行，还给每一行加上绝对行号，提升信息密度并减少位置歧义。这一点对 “预测编辑位置”“生成可直接应用的 patch” 都很关键。

3.2 两阶段训练：SFT 学模式，DAPO 对齐人类偏好

NES 对两个模型都采用了两阶段后训练流程：

• Stage 1：SFT（监督微调）：让模型先学会基本的编辑模式与轨迹 - 意图映射。
• Stage 2：DAPO（强化学习对齐）：在高质量偏好数据上进一步优化行为，使输出更贴近真实开发者的 “有用建议”。

通过两阶段的模型训练，NES 在核心指标上达到 SOTA：

• 编辑位置预测准确率 75.6%（NES-Location）
• 编辑内容 Exact Match Rate 27.7%（NES-Edit）

3.3 推理优化：把 “可落地性” 拉到 250ms 以内

在 IDE 内联建议场景里，推理延迟几乎决定生死。NES 在系统侧引入了Prefix Caching与Speculative Decoding等优化，并针对工业环境进行工程调优，使端到端建议响应达到 平均 <250ms 的量级。

工业部署上，论文给出了选择小模型（Qwen3-4B）并结合高质量后训练数据的理由：

• 8B 等更大模型成本与延迟更高，不适合 “低延迟” 体验目标。
• 通过 SFT+DAPO，小模型也能达到很强的任务效果，具备更优的成本性能。

四、效果与价值：交互链路被重构

4.1 效果展示：

逻辑类的修改，当用户把 Point2D 改为 Point3D 时，模型能够理解代码逻辑的变化，首先增加 z 参数，接着预测需要跳转到第 18 行进行修改，用户采纳修改后，紧接着预测用户到第 19 行进行修改

格式统一，当把 Monday 修改为星期一时，首先 edit 模型会对 7-9 行进行同样的命名风格修改，用户采纳后，next-tab 模型帮助用户导航到第 10 行进行同样的修改，整个过程用户只需要按 tab 键即可完成

4.2 开发者与代码的交互链路被改写

很多工具的编辑能力建立在 “先描述 → 模型再改” 的范式上，评估也常围绕单次编辑是否正确。NES 的价值在于它把协作粒度切到 “下一步”，把编辑变成一个连续循环：

• Location让跨文件修改的 “导航成本” 显著下降；
• Edit让到位后的改动可以直接一键接受；
• 二者组合形成链式推进，尤其适合 refactor 这类连锁任务。

这类体验的提升，对开发者心流非常重要。

五、NES 在 Agent 时代的不可替代生态位

写代码从来不是一次性的创作，而是无数次 "发现问题→定位→修改→再定位" 的循环。那些打断心流的瞬间，往往不是来自一个复杂的 Bug，而是一次又一次的 "下一处该改哪"。

在 Code Agent 快速发展的今天，编辑级的精准响应反而成为更难被绕过的基础能力 —— 它直接关乎开发者能否真正保持心流、信任 AI 的建议并持续采纳。NES 给出的答案是：从轨迹里学意图，把延迟压到感知阈值以内，让 "下一步" 变成一次 Tab。当模型开始比你更早知道该改哪里，人与 AI 的协作边界，正在被悄悄重构。