
与君初相识 怎似故人归
想象一下这个场景:
你正在改代码,把函数 getUserInfo() 改名为 fetchUserProfile()。改完函数名,你心想:"好了,搞定!"
结果:编译器报错 10 处——原来文件里还有 10 个地方在调用这个函数!
这时候你只能:
痛点:之前的 GitHub Copilot 就像个近视眼助手,只能看到你光标附近几行代码。明明知道其他地方也要改,但它就是"视而不见"。
好消息:现在它治好了近视眼!🎉
NES = Next Edit Suggestions(下一步编辑建议)
你在这里改代码 → AI 建议 nearby 的修改
↓
只能看这么远(约 50 行)你在这里改代码 → AI 预测 → 直接跳到文件底部
↓
整个文件都是我的地盘!# 第 10 行:你改了参数类型
defcalculate_price(price:str)->float:# 从 int 改成 str
returnfloat(price)*1.1
# ... 中间 200 行代码 ...
# 第 210 行:验证逻辑崩了
if price <0:# ❌ str 不能和 int 比较!
raise ValueError("价格不能为负")以前的你:跑到第 210 行才发现报错,再回头改 现在的 AI:"兄弟,第 210 行也要改,我帮你标出来了!"
// 你在这里改函数名
functiongetUserData(id){// 改成 fetchUserInfo
// ...
}
// 文件其他地方:
const user =getUserData(123);// ❌ 要改!
processData(getUserData(456));// ❌ 也要改!AI 的内心 OS:"我看到你改了函数名,下面 3 个调用处都要更新,要不要我帮你跳过去?"

GitHub 上有海量的代码编辑记录。团队把这些记录变成训练数据:
原始数据:开发者 A 修改文件的过程
↓
回放轨迹:记录每一步光标移动和编辑
↓
转换样本:每次光标跳转 = 一个训练样本
↓
过滤:确保跳转位置在提示词中出现
↓
训练数据集:数百万个"何时跳转"的例子关键洞察:
不是"教 AI 怎么写代码",而是"教 AI 像人类开发者一样思考下一步去哪改"。
标准 NES:建议出现在光标附近,你自然能看到 长距离 NES:建议在文件另一头,你怎么知道它存在?
设计原则:
关键设计:

监督学习(SFT)的局限:
核心思想:
奖励机制:
AI 预测跳转到第 100 行
↓
观察开发者实际去了哪里
↓
如果开发者也去了第 100 行 → 奖励 +1 ✅
如果开发者没去 → 奖励 -1 ❌
如果 AI 没建议但开发者去了 → 奖励 -0.5 😐训练信号:
指标 | 标准 NES | 长距离 NES | 提升 |
|---|---|---|---|
代码生成量 | 基准 | +23% | 📈 |
用户接受度 | 基准 | 提升 | 👍 |
拒绝率 | 基准 | 略高 | ⚠️ |
当前局限:只能在单个文件内跳转 未来方向:跨文件建议
当前:两个模型(位置预测 + 编辑生成) 未来:一个模型同时预测"位置和内容"
优势:
✅ 开启以下设置:
{
"github.copilot.nextEditSuggestions.enabled":true,
"github.copilot.nextEditSuggestions.extendedRange":true
}🎯 重命名变量/函数 🎯 更新函数签名 🎯 修改参数类型 🎯 修复连锁错误 🎯 任何"涟漪效应"的修改
让 AI 助手从"近视眼"进化成"千里眼":