AI全方位接管，全链路打通干湿闭环，深势发布玻尔·跃迁实验室¶
公众号: 机器之心 发布日期: 04月17日 抓取日期: 2026-04-19 URL: https://www.jiqizhixin.com/articles/b4fb0528-b5c7-46a5-902a-0d380bbdc95d
Title: 不写Prompt，连按Tab完成重构：蚂蚁CodeFuse团队提出无指令代码编辑框架NES ｜ 机器之心
URL Source: https://www.jiqizhixin.com/articles/b4fb0528-b5c7-46a5-902a-0d380bbdc95d
Markdown Content:
不写Prompt，连按Tab完成重构：蚂蚁CodeFuse团队提出无指令代码编辑框架NES ｜ 机器之心¶
机器之心¶
登录
文章库
PRO会员通讯
SOTA！模型
AI Shortlist
AI 好好用
文章库
登录
不写Prompt，连按Tab完成重构：蚂蚁CodeFuse团队提出无指令代码编辑框架NES
0%
展开列表
游戏行业不缺AI工具，缺什么？腾讯游戏用一场大赛给出答案
04月18日
MagicDawn
终于，Claude革了设计行业的命：Figma、Adobe股价重挫
04月18日
Claude Design
谷歌向左、李飞飞往右，阿里世界模型「快乐生蚝」杀出第三条路
04月18日
世界模型
Claude Code新功能Auto Mode能否替代人工审核？首个压力测试来了
04月18日
压力测试
梁文锋首次开口融资，DeepSeek只估值680亿，融资20亿？
04月18日
梁文锋
告别「想完再做」卡顿！清华StreamingVLA让VLA边想边行动，提速2.4倍
04月18日
清华大学
具身数据才是最大「金矿」，数据云商城来了：全球首个、百亿级、全模态、高自由度
04月18日
全模态具身智能数据云商城
不写Prompt，连按Tab完成重构：蚂蚁CodeFuse团队提出无指令代码编辑框架NES
04月18日
蚂蚁集团
AI全方位接管，全链路打通干湿闭环，深势发布玻尔·跃迁实验室
04月17日
AI for Science
Transformer与RNN合体，谷歌打下显存门槛，解锁超长上下文
04月17日
Transformer
AI 下半场，由谁来定义？2026 WAIC 云帆奖启航
04月17日
2026 WAIC 云帆奖
π0.7来了！涌现出组合泛化、跨本体迁移能力，VLA又行了？
04月17日
π 0.7
SIGIR'26｜DPPMG 首创个性化多模态生成新范式：图文一致更懂你
04月17日
DPPMG
从高端制造到多元公共服务，智平方×西子联合开启具身智能“全场景闭环”新纪元
04月17日
GOVLA
直播预约 | 世界模型，点燃下一个AI爆点（第二期）
04月17日
世界模型
图灵也没想到，智能，必须在现实中「活」下来
04月17日
具身智能
π0.6和GEN-1谁代表未来？乾坤未定，但这条底层赛道浮出水面
04月17日
数据编译
DeepSeek悄悄更新：Mega MoE、FP4 Indexer来了
04月17日
Mega MoE
ACL 2026 | OPeRA Dataset: LLM真的能模仿人类行为了吗？首次系统评估LLM的人类行为模拟能力
04月17日
OPeRA Dataset
短短3个月，高德已拿下具身智能领域15项世界第一
04月17日
Abot-world
机器之心 原创
3小时前
不写Prompt，连按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 的协作边界，正在被悄悄重构。