連按Tab完成重構(gòu)：螞蟻CodeFuse團隊提出無指令代碼編輯框架NES

在 AI coding 工具快速演進的今天，“讓模型寫代碼” 正在從補全、問答走向Agent 端到端編程：從需求拆解、跨文件修改到測試修復(fù)，一次任務(wù)動輒涉及多輪規(guī)劃與執(zhí)行。

但在真實開發(fā)里，最頻繁、最消耗注意力的往往不是 “大任務(wù)”，而是無處不在的小編輯：一次重命名、一次參數(shù)補全、一次跨文件 refactor 的連鎖修改…… 這些動作密集、節(jié)奏快，任何額外的提示詞輸入、等待模型響應(yīng)或頻繁切換上下文，都會打斷開發(fā)者的 “心流”。

螞蟻集團的 CodeFuse 算法團隊長期從事大模型代碼生成 / 編輯、AI IDE 智能輔助與工程化落地研究。此次在 FSE 2026 的 Industry Track 提出了NES（Next Edit Suggestion）：一個無指令（instruction-free）、低延遲（<250ms）的 “下一步編輯建議” 框架。NES 不要求開發(fā)者先用自然語言描述意圖，而是從歷史編輯軌跡（historical editing trajectories）里學(xué)習(xí)開發(fā)者的目標(biāo)與習(xí)慣，直接給出 “下一處該改哪里、該怎么改” 的建議，并把交互簡化為連續(xù)的 Tab → Tab → Tab。

FSE（ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering）是全球軟件工程領(lǐng)域的頂級學(xué)術(shù)會議（CCF-A 類）其中的 Industry track 專門面向卓越應(yīng)用研究，重點考察工作的顯著性 (Significance)、穩(wěn)健性 (Soundness) 以及對當(dāng)前工業(yè)實踐的改進程度。

• 論文：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

一、大模型會寫，但 “編輯協(xié)作” 仍不夠順滑

近兩年，代碼大模型工具顯著提升了代碼生成與編輯效率，但在代碼編輯（code editing）這類高頻任務(wù)中，現(xiàn)有范式仍有兩類關(guān)鍵痛點：

1. 過度依賴顯式指令，打斷心流

很多研究與產(chǎn)品的編輯能力建立在 “用戶先用自然語言描述修改意圖 → 模型再生成 patch” 的鏈路上。現(xiàn)實中，開發(fā)者并不總能（也不愿意）把 “下一步要改什么” 先說清楚：尤其在重構(gòu)、維護、跨文件依賴調(diào)整中，編輯意圖往往是邊讀邊改、逐步推進的。

2. 編輯任務(wù)強時效，延遲直接影響可用性

代碼編輯與補全一樣是 “即時交互” 場景。論文指出用戶通常期望 1 秒內(nèi)反饋，而很多方法還依賴較重的理解、檢索或推理流程，導(dǎo)致延遲上升，進一步放大 “打斷感”。

更重要的是：編輯并非一次性動作。一個 “看似簡單” 的需求（例如把一個組件新增屬性）往往會觸發(fā)連鎖修改：改接口、改實現(xiàn)、改調(diào)用點、補參數(shù)…… 如果每一步都要重新描述、重新等待，就很難形成真正的協(xié)作體驗。

二、NES 從歷史編輯軌跡去判斷 “下一步如何改”

NES 的出發(fā)點來自一個樸素但被低估的事實：

開發(fā)者的目標(biāo)與習(xí)慣，往往沉淀在他們的歷史編輯模式里。

例如重復(fù)的重構(gòu)動作、跨文件依賴的修改路徑、某類 API 的調(diào)用順序、團隊內(nèi)的代碼風(fēng)格等，都能從 “編輯軌跡” 中體現(xiàn)出來。NES 選擇把這些軌跡當(dāng)作 “隱式意圖信號”，從而繞開顯式自然語言指令。

為此，NES 設(shè)計了一個雙模型架構(gòu)：

• NES-Location：預(yù)測 “下一處最可能的編輯位置”（跨文件 / 跨模塊的導(dǎo)航建議）。
• NES-Edit：在到達位置后生成 “應(yīng)該如何改” 的具體代碼修改。

三、從 “軌跡采集 → 數(shù)據(jù)構(gòu)建 → 兩階段訓(xùn)練 → 推理加速” 閉環(huán)落地

NES 的實現(xiàn)可以拆成三個關(guān)鍵環(huán)節(jié)。

3.1 軌跡采集：用增量 diff 捕獲真實編輯操作

要讓模型學(xué)到 “編輯習(xí)慣”，首先要能穩(wěn)定捕獲編輯軌跡。NES 在 IDE 插件側(cè)實現(xiàn)了實時、增量的差異檢測（incremental difference detection），把計算范圍從 “全文件 diff” 收縮到 “當(dāng)前被修改的局部片段”，以降低開銷并提升實時性。

同時，論文提出了自定義的NES diff 格式：不僅標(biāo)注新增 / 刪除 / 保留行，還給每一行加上絕對行號，提升信息密度并減少位置歧義。這一點對 “預(yù)測編輯位置”“生成可直接應(yīng)用的 patch” 都很關(guān)鍵。

3.2 兩階段訓(xùn)練：SFT 學(xué)模式，DAPO 對齊人類偏好

NES 對兩個模型都采用了兩階段后訓(xùn)練流程：

• Stage 1：SFT（監(jiān)督微調(diào)）：讓模型先學(xué)會基本的編輯模式與軌跡 - 意圖映射。
• Stage 2：DAPO（強化學(xué)習(xí)對齊）：在高質(zhì)量偏好數(shù)據(jù)上進一步優(yōu)化行為，使輸出更貼近真實開發(fā)者的 “有用建議”。

通過兩階段的模型訓(xùn)練，NES 在核心指標(biāo)上達到 SOTA：

• 編輯位置預(yù)測準(zhǔn)確率 75.6%（NES-Location）
• 編輯內(nèi)容 Exact Match Rate 27.7%（NES-Edit）

3.3 推理優(yōu)化：把 “可落地性” 拉到 250ms 以內(nèi)

在 IDE 內(nèi)聯(lián)建議場景里，推理延遲幾乎決定生死。NES 在系統(tǒng)側(cè)引入了Prefix Caching與Speculative Decoding等優(yōu)化，并針對工業(yè)環(huán)境進行工程調(diào)優(yōu)，使端到端建議響應(yīng)達到 平均 <250ms 的量級。

工業(yè)部署上，論文給出了選擇小模型（Qwen3-4B）并結(jié)合高質(zhì)量后訓(xùn)練數(shù)據(jù)的理由：

• 8B 等更大模型成本與延遲更高，不適合 “低延遲” 體驗?zāi)繕?biāo)。
• 通過 SFT+DAPO，小模型也能達到很強的任務(wù)效果，具備更優(yōu)的成本性能。

四、效果與價值：交互鏈路被重構(gòu)

4.1 效果展示：

邏輯類的修改，當(dāng)用戶把 Point2D 改為 Point3D 時，模型能夠理解代碼邏輯的變化，首先增加 z 參數(shù)，接著預(yù)測需要跳轉(zhuǎn)到第 18 行進行修改，用戶采納修改后，緊接著預(yù)測用戶到第 19 行進行修改

格式統(tǒng)一，當(dāng)把 Monday 修改為星期一時，首先 edit 模型會對 7-9 行進行同樣的命名風(fēng)格修改，用戶采納后，next-tab 模型幫助用戶導(dǎo)航到第 10 行進行同樣的修改，整個過程用戶只需要按 tab 鍵即可完成

4.2 開發(fā)者與代碼的交互鏈路被改寫

很多工具的編輯能力建立在 “先描述 → 模型再改” 的范式上，評估也常圍繞單次編輯是否正確。NES 的價值在于它把協(xié)作粒度切到 “下一步”，把編輯變成一個連續(xù)循環(huán)：

• Location讓跨文件修改的 “導(dǎo)航成本” 顯著下降；
• Edit讓到位后的改動可以直接一鍵接受；
• 二者組合形成鏈?zhǔn)酵七M，尤其適合 refactor 這類連鎖任務(wù)。

這類體驗的提升，對開發(fā)者心流非常重要。

五、NES 在 Agent 時代的不可替代生態(tài)位

寫代碼從來不是一次性的創(chuàng)作，而是無數(shù)次 "發(fā)現(xiàn)問題→定位→修改→再定位" 的循環(huán)。那些打斷心流的瞬間，往往不是來自一個復(fù)雜的 Bug，而是一次又一次的 "下一處該改哪"。

在 Code Agent 快速發(fā)展的今天，編輯級的精準(zhǔn)響應(yīng)反而成為更難被繞過的基礎(chǔ)能力 —— 它直接關(guān)乎開發(fā)者能否真正保持心流、信任 AI 的建議并持續(xù)采納。NES 給出的答案是：從軌跡里學(xué)意圖，把延遲壓到感知閾值以內(nèi)，讓 "下一步" 變成一次 Tab。當(dāng)模型開始比你更早知道該改哪里，人與 AI 的協(xié)作邊界，正在被悄悄重構(gòu)。