构建远程下一次编辑建议 (Long-Distance 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 模型超参数的结构化网格搜索。通过将搜索空间限制在已知在相关设置中表现良好的数值范围内，我们能够高效地探索组合并确定高性能的配置。
在确定该方法之前，我们还尝试了贝叶斯优化，这是一种旨在优化昂贵黑盒函数的技术。在我们的案例中，每次评估都需要从头开始训练模型，这使得实验在计算上成本高昂。虽然从理论上讲很有吸引力，但这种方法并没有比更聚焦的网格搜索带来提升。
最终，结构化网格搜索产生了我们表现最好的监督模型，并为后续迭代提供了稳定的基础。
为远程编辑设计用户体验 (UX)
如果用户从未注意到或不信任建议，那么再好的模型也不够用。使用标准 NES 时，建议会出现在光标附近且处于视野范围内，因此具有天然的可发现性。而远程 NES 最相关的编辑可能不在您的视野内。因此，UX 必须解决一个更难的问题：在不打断工作流的情况下呈现远程编辑内容。
这归结为平衡三个关注点：保持建议简洁、确保其可读性，以及尽量减少对代码的遮挡。
这不仅仅是一个可发现性问题，更是一个信任问题。当系统建议将光标移至别处时，您需要快速评估该跳转是否相关且值得注意。UI 必须传达足够的上下文以供评估建议，而无需强制进行完整的上下文切换。
我们没有在行内渲染大型差异 (diff) 或强制转移注意力，而是设计了一个紧凑的微件，它会出现在光标附近，并优先占据空白空间。微件会适应周围的编辑器布局，缩小或扩展以自然地融入空白区域，例如行尾或代码块之间。
由于完整的编辑可能很遥远且内容庞大，微件不会尝试渲染整个建议。相反，它提供了一个轻量级的预览，即受影响行之一的片段，并以差异风格高亮显示。这为您提供了足够判断相关性和决定是否采取行动的上下文。
如果预览看起来有用，您可以选择跳转到建议位置并检查或应用完整的编辑内容。如果不有用，您可以继续无干扰地编辑。
验证：从内部试用到 A/B 测试
在发布新功能之前，我们总是进行内部试用 (dogfooding)，远程 NES 也不例外。早期的反馈揭示了一个明显的模式：模型过于渴望跳转。即使其预测方向正确，频繁的建议也会变得令人分心。根本原因是数据集不平衡：与跳转示例相比，“不跳转”示例太少了。模型学会了自信地跳转，却没学会何时原地不动。
我们通过扩展“正确操作是留在当前行”的样本（例如部分键入的标识符，此时跳转毫无意义）来重新平衡数据集。重新训练后，跳转和不跳转的准确性都有所提高，建议感觉明显更有意图。
为了进行大规模验证，我们运行了 A/B 测试，比较远程 NES 与标准 NES。结果令人鼓舞：通过 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 团队实现了平稳的模型发布。