建構長距離「下一次編輯建議」(Next Edit Suggestions)
2026 年 2 月 26 日，作者：Vikram Duvvur、Gaurav Mittal、Benjamin Simmonds
去年二月，我們在 GitHub Copilot 中發布了下一次編輯建議 (NES)。NES 不僅會在您的游標處插入程式碼，還能預測您接下來可能進行的修改並提供建議，從而擴展了幽靈文字 (ghost text) 的功能。這是一個強大的進步，但它僅適用於游標周圍的小範圍內。在實際的編輯工作流程中，您需要進行的下一個變更往往在好幾頁之外。
這正是我們致力於解決長距離下一次編輯建議問題的原因：將 NES 擴展到預測並建議檔案中任何位置的編輯，而不僅僅是您目前游標位置附近。
從鄰近編輯到檔案中任何位置
試想一個典型的重構會話。您重新命名了一個函式，檔案中其他地方的所有函式呼叫也需要更新；或者您更改了一個參數型別，導致 200 行之後的驗證邏輯變得不正確。這些正是您期望 NES 能提供協助的時刻，但遺憾的是，下一個有意義的編輯往往超出了其有效範圍。
這帶來了一個艱鉅的建模問題。搜尋空間從少量鄰近的程式碼行擴大到檔案中的每一行。且出錯的代價並不對等：正確的跳轉能節省實際精力，但錯誤的跳轉會打斷您的思緒，讓您更難信任下一次建議。系統不僅必須學習何時該移動，還必須學習何時不該移動。
與其修改現有的編輯生成模型，我們決定採用多模型方法。我們訓練了一個專用的位置模型，其唯一職責是預測下一次編輯應該發生在何處。一旦選定有效的目標位置，原始的 NES 模型便會生成編輯建議。
這種分離帶來了兩個好處。首先，每個模型都可以專注於單一任務：一個模型學習空間意圖（跳轉到哪裡），另一個模型則在局部範圍內生成高品質的編輯。此外，這使我們能夠獨立迭代位置預測，而不會干擾核心 NES 模型的持續改進。
透過評估框架衡量成功
在訓練位置模型之前，我們需要一種方法來衡量它是否真的適用於真實世界的編輯場景。
我們設計了一個結構化的三步驟評估流程：
- 識別常見的多重編輯工作流程
- 構建具有代表性的游標跳轉範例
- 同時衡量跳轉與不跳轉的準確度
我們首先分析開發人員如何在真實場景中串聯編輯——例如重新命名、簽章變更、文件更新——而不是將每次編輯視為孤立事件。其共同點是：編輯會在檔案中多個不相鄰的位置產生連鎖反應。
根據這些工作流程，我們建立了一個評估資料集，其中每個範例都包含作為基準的下一個跳轉行、近期編輯歷史記錄以及游標上下文。
關鍵在於，我們同時衡量了跳轉與不跳轉的準確度。雖然許多範例需要預測新位置，但仍有很大一部分需要停留在目前行。一個跳轉過於頻繁的模型，與一個錯過重要變更的模型一樣令人困擾。試想一下，每當您打到變數名稱一半時，就跳出一個跳轉建議，會是什麼感受。
透過將評估建立在真實的工作流程中並衡量跳轉與不跳轉的情況，我們確保了離線指標反映的是開發人員實際的編輯方式，而非人為設定的場景。
構建訓練資料集
有了評估基準後，我們開始準備訓練資料。雖然評估資料集可以手動構建，但訓練需要更大規模的資料。我們首先使用為訓練核心 NES 模型所整理的同一資料集，其中包含了開發人員如何在檔案中移動與編輯的軌跡。
透過回放這些軌跡，我們將每一次游標移動轉換為一個訓練樣本。在應用過濾器（例如確保跳轉位置出現在提示詞中）之後，我們就擁有了訓練資料集。
透過監督式微調進行訓練
為了訓練位置模型，我們使用了監督式微調 (SFT) 並配合針對性的超參數搜尋。我們最強的結果來自於圍繞現有 NES 模型超參數的結構化網格搜尋。透過將搜尋空間限制在已知在相關環境中表現良好的數值，我們能夠有效地探索組合並找出高效能的配置。
在決定此方法之前，我們也嘗試過貝葉斯最佳化 (Bayesian Optimization)，這是一種專為最佳化昂貴的黑盒函數而設計的技術。在我們的案例中，每次評估都需要從頭開始訓練模型，這使得實驗成本極高。雖然在理論上很有吸引力，但這種方法並未比更集中的網格搜尋產生更好的改進。
最終，結構化網格搜尋產生了我們效能最好的監督式模型，並為後續的迭代提供了穩定的基礎。
設計長距離編輯的使用者體驗 (UX)
如果使用者從未注意到或不信任建議，再好的模型也沒用。使用標準 NES 時，建議會出現在游標附近且在視野範圍內，因此很容易發現。但對於長距離 NES，最相關的編輯可能不在您目前的視野中。因此，UX 必須解決一個更困難的問題：在不打斷工作流的情況下呈現遠處的編輯。
這歸結為平衡三個考量：保持建議簡潔、確保易讀性，以及盡量減少遮擋程式碼的範圍。
這不僅僅是發現問題，更是信任問題。當系統建議將游標移到其他地方時，您需要快速判斷該跳轉是否相關且值得注意。UI 必須提供足夠的背景資訊來評估建議，而無需強制進行完整的上下文切換。
我們設計了一個小型視窗，會出現在游標附近，並優先選擇空白空間呈現，而不是直接在行內渲染大型差異對照 (diff) 或強制切換視覺焦點。該視窗會適應周圍的編輯器佈局，透過收縮或擴展，自然地融入如行尾或程式碼區塊之間的空白區域。
由於完整的編輯可能距離遙遠且內容龐大，該視窗不會嘗試渲染全部內容。相反，它提供了一個輕量級的預覽，擷取受影響的其中一行，並使用 diff 風格的醒目提示進行渲染。這足以讓您判斷相關性並決定是否採取行動。
如果預覽看起來很有幫助，您可以選擇跳轉到建議的位置並在那裡檢查或套用完整編輯。如果沒有，您可以繼續編輯而不會受到打擾。
驗證：從內部使用到 A/B 測試
在推出新功能前，我們總是會先進行內部使用 (dogfooding)，長距離 NES 也不例外。早期的反饋揭示了一個明顯的模式：模型太急於跳轉了。即使其預測的方向正確，頻繁的建議也會讓人分心。根本原因是資料集不平衡：不跳轉的範例遠少於跳轉的範例。模型學會了自信地跳轉，卻沒學會何時該保持不動。
我們透過擴展正確操作為「保持當前位置」的樣本來重新平衡資料集，例如部分輸入的識別字，在這種情況下跳轉並無意義。重新訓練後，跳轉與不跳轉的準確度都有所提升，建議也明顯感覺更有意圖性。
為了大規模驗證，我們進行了長距離 NES 與標準 NES 的 A/B 測試。結果令人鼓舞：透過 NES 撰寫的程式碼增加了 23%，其他參與度指標也有所改善。但實驗也顯現出了一種取捨。遠距離建議被拒絕的頻率比標準 NES 高。考慮到這是一種新的互動模式，部分結果在預期之內，但也顯示模型在何時該建議跳轉的問題上仍需更具選擇性。
這不僅僅是建模問題或單純的 UX 問題，而是兩者皆是。改進長距離 NES 需要收斂模型的跳轉預測，同時確保介面能讓使用者輕鬆評估並接受相關建議。
強化學習：學習何時不該跳轉
驗證結果指向一個明確的結論：監督式模型需要更多的克制。
為了處理這個問題，我們引入了一個使用驗證獎勵強化學習 (RLVR) 的強化學習階段。我們不再僅僅依賴監督式標籤，而是增加了一個評分訊號，該訊號基於模型的預測跳轉位置與最終游標移動的吻合程度。與實際編輯行為高度一致的預測會獲得更高的獎勵，而不必要或時機不當的跳轉則會受到懲罰。
這使得模型能夠直接針對真實的編輯條件進行最佳化，而無需新的手動註解或 UX 工具。
結果是在主動性與克制之間取得了更好的平衡。更新後的模型改善了離線指標，並將這些收益轉化為線上效能，在減少拒絕率的同時增加了透過 NES 撰寫的程式碼。在這些訊號到位後，我們便於次月開始發布改進版本。
後續計畫
展望未來，我們計畫透過跨檔案建議來擴展這項工作，使模型能夠超越當前檔案進行推理。我們也在探索一個統一模型，能同時預測下一次編輯的位置與內容，這將有助於提高整體建議的相關性。
立即試用
長距離下一次編輯建議現已在 VS Code 中提供給擁有 GitHub Copilot 訂閱的用戶——只需確保您已在 VS Code 中啟用下一次編輯建議與擴展 NES 範圍 github.copilot.nextEditSuggestions.extendedRange 。下次進行重構工作時（例如重新命名變數、更新函式簽章，或進行會引發檔案連鎖反應的變更）請試試看。我們非常期待您的回饋！
祝開發愉快！ 💙
致謝
衷心感謝開發者社群持續提供的回饋，推動我們在 VS Code 和 GitHub Copilot 中提供最佳的體驗。同時，非常感謝 GitHub 和 Microsoft 的研究人員、工程師、產品經理和設計師，他們整理了訓練資料、建構了訓練管道、評估套件和伺服端架構，也感謝 VS Code 和 GitHub Copilot 團隊確保了模型的順利發布。