連按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” 的鏈路上?，F實中，開發者并不總能（也不愿意）把 “下一步要改什么” 先說清楚：尤其在重構、維護、跨文件依賴調整中，編輯意圖往往是邊讀邊改、逐步推進的。

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 的協作邊界，正在被悄悄重構。