开场白：你的 AI 助手终于治好了"近视眼"

想象一下这个场景：

你正在改代码，把函数 getUserInfo() 改名为 fetchUserProfile()。改完函数名，你心想：“好了，搞定！”

结果：编译器报错 10 处——原来文件里还有 10 个地方在调用这个函数！

这时候你只能：

1. 疯狂 Ctrl+F 搜索
2. 一行行翻找
3. 祈祷别漏掉任何一个

痛点：之前的 GitHub Copilot 就像个近视眼助手，只能看到你光标附近几行代码。明明知道其他地方也要改，但它就是"视而不见"。

好消息：现在它治好了近视眼！🎉

---

什么是长距离 NES？

NES = Next Edit Suggestions（下一步编辑建议）

以前的 NES：

你在这里改代码 → AI 建议 nearby 的修改
                    ↓
               只能看这么远（约 50 行）

现在的长距离 NES：

你在这里改代码 → AI 预测 → 直接跳到文件底部
                    ↓
               整个文件都是我的地盘！

---

典型使用场景：你肯定遇到过这些崩溃时刻

场景 1：改参数类型，连锁反应爆炸 💥

# 第 10 行：你改了参数类型
def calculate_price(price: str) -> float:  # 从 int 改成 str
    return float(price) * 1.1

# ... 中间 200 行代码 ...

# 第 210 行：验证逻辑崩了
if price < 0:  # ❌ str 不能和 int 比较！
    raise ValueError("价格不能为负")

以前的你：跑到第 210 行才发现报错，再回头改
现在的 AI：“兄弟，第 210 行也要改，我帮你标出来了！”

---

场景 2：重构函数名，调用处全挂 📛

// 你在这里改函数名
function getUserData(id) {  // 改成 fetchUserInfo
    // ...
}

// 文件其他地方：
const user = getUserData(123);  // ❌ 要改！
processData(getUserData(456));  // ❌ 也要改！

AI 的内心 OS：“我看到你改了函数名，下面 3 个调用处都要更新，要不要我帮你跳过去？”

---

训练数据：从"开发者行为"中学习

数据来源：真实的代码编辑轨迹

GitHub 上有海量的代码编辑记录。团队把这些记录变成训练数据：

原始数据：开发者 A 修改文件的过程
    ↓
回放轨迹：记录每一步光标移动和编辑
    ↓
转换样本：每次光标跳转 = 一个训练样本
    ↓
过滤：确保跳转位置在提示词中出现
    ↓
训练数据集：数百万个"何时跳转"的例子

关键洞察：

不是"教 AI 怎么写代码"，而是"教 AI 像人类开发者一样思考下一步去哪改"。

---

UX 设计：如何让"隔空建议"不被忽略？

挑战：看不见的建议 = 没用的建议

标准 NES：建议出现在光标附近，你自然能看到
长距离 NES：建议在文件另一头，你怎么知道它存在？

解决方案：智能小部件（Widget）

设计原则：

1. 紧凑：不占太多空间
2. 可读：一眼看懂要改什么
3. 不遮挡：尽量不挡住你的代码

实现方式：

你在这里写代码...
│
│  [💡 建议跳到第 210 行]
│  ↓
│  if price < 0:  ← 预览代码片段
│      raise...   ← 带 diff 高亮
│
└─ Widget 智能出现在空白处

关键设计：

• 不渲染完整 diff：只给预览片段
• 提供足够上下文：让你判断"值不值得跳"
• 自主选择：有用就跳，没用就忽略

---

强化学习 ：学会"克制"的艺术

问题：监督学习不够用

监督学习（SFT）的局限：

• 只能学习"标注过的正确行为"
• 难以捕捉"真实编辑场景的细微差别"

解决方案：RLVR（带验证奖励的强化学习）

核心思想：

• 不只看"标注答案"
• 还看"实际开发者行为"

奖励机制：

AI 预测跳转到第 100 行
    ↓
观察开发者实际去了哪里
    ↓
如果开发者也去了第 100 行 → 奖励 +1 ✅
如果开发者没去 → 奖励 -1 ❌
如果 AI 没建议但开发者去了 → 奖励 -0.5 😐

训练信号：

• 预测与实际行为越接近 → 奖励越高
• 不必要的跳转 → 惩罚
• 该跳没跳 → 轻微惩罚

成果展示：数字说明一切

关键指标对比

指标	标准 NES	长距离 NES	提升
代码生成量	基准	+23%	📈
用户接受度	基准	提升	👍
拒绝率	基准	略高	⚠️

解读：

• 23% 的代码增长 = 开发者少写近 1/4 的代码
• 拒绝率略高 = 新交互模式需要适应
• 整体成功 = 值得大规模推广

---

未来规划：跨文件编辑 + 统一模型

下一步：打破文件边界

当前局限：只能在单个文件内跳转
未来方向：跨文件建议

终极目标：统一模型

当前：两个模型（位置预测 + 编辑生成）
未来：一个模型同时预测"位置和内容"

优势：

• 更好的整体相关性
• 更简洁的架构
• 更低的延迟

---

如何使用

✅ 开启以下设置：

{
  "github.copilot.nextEditSuggestions.enabled": true,
  "github.copilot.nextEditSuggestions.extendedRange": true
}

最佳使用场景

🎯 重命名变量/函数
🎯 更新函数签名
🎯 修改参数类型
🎯 修复连锁错误
🎯 任何"涟漪效应"的修改

使用建议：

下次重构代码时，留意 AI 的建议。

当你改完一处，看到小部件提示"建议跳转到第 X 行"，不妨点过去看看。

可能会发现：“卧槽，这里确实要改！”

---

总结：AI 助手的新境界

技术亮点

1. 双模型架构：位置预测 + 编辑生成，各司其职
2. 强化学习：学会"何时跳，何时忍"
3. 智能 UX：紧凑预览，不打扰工作流
4. 数据驱动：从真实开发者行为中学习

最终目标

让 AI 助手从"近视眼"进化成"千里眼"：

• 看到你当前的修改
• 预见远处的连锁反应
• 在合适的时间提醒你
• 在你不需要时保持沉默

---