我们的问题（续）

作为对我们最初的问题文章的后续，以下是一些我们认为对 AI 编程下一阶段最重要的问题。

下一个操作预测

Cursor 附带了Copilot++，这是一个比 Copilot 更智能的版本，可以预测您的下一个编辑。我们能否将这个想法发挥到极致？

在编码时，您不仅会进行低熵的编辑。在整个编辑器中，您会进行低熵的按键、点击、操作。我们能否构建一个模型以低延迟预测每个操作？

首先，我们将 Copilot++ 扩展到预测您的下一个位置。将此与下一个编辑预测相结合，模型就可以执行一系列低熵更改

我们正在研究预测您将要移动到的下一个文件。您将运行的下一个终端命令。下一个编辑，以您之前的终端命令为条件！一个下一个操作预测模型。

此外，模型应该在您需要时立即显示信息。无论是正确的代码段还是文档。

Cursor 应该感觉像您意志的延伸。当您想到一个更改时，语言模型只需要最少的意图即可立即执行它。

有希望的方向

• 对代码库中的操作预测进行基础研究。
• 继续对约 50-130 亿个活动参数代码模型进行预训练和后训练（用于预填充绑定的低延迟预测）。
• 类似于推测编辑的其他推理技巧
• 巧妙的用户界面，以不显眼的方式显示“操作”。（您如何建议用户应该移动到的下一个文件？或者当前视口之外的下一个位置？）

---

完美的编辑

我们能否扩展推理时间计算以生成更高质量、更大的编辑？我们如何弥补延迟增加？

可能需要在后台执行编辑。生成一个您可以信任智能模型的工作单元。

我们需要具有强大的特定于编辑器的工具使用能力、更智能的代码库范围上下文以及改进的长期推理能力的模型。

以及我们如何使异步代码生成保持流程。这听起来像是一个自相矛盾的说法，但我们相信在模型功能和用户界面方面进行巧妙的研究可能会使这成为可能。

幻觉伪代码

用户将编写描述所需更改的伪代码。然后，我们可以信任 Cursor 在后台将伪代码编译成完整的更改。

多文件编辑

Cmd-k 已经非常棒了，但是如果您可以在整个代码库中请求通用编辑会怎么样？特别是跨多个文件准确扩展的编辑？

有希望的方向

• 扩展推理时间计算。我们知道奖励模型和拒绝采样将显示快速且简单的改进，但我们还能走多远？
• 更好的推理模型（gpt-5、claude-4、gemini 2.0）
• 为给定的用户工作区运行多个语言服务器/文件系统副本。这将需要模型工具使用和远程复制运行时环境。
• 在代理轨迹上训练/改进模型性能
• 对流式异步编辑进行重大用户体验实验

---

最佳上下文

可能有数百万个文档标记、数千万个源代码标记，以及另外数千万个提交历史标记，所有这些都可能是解决单个查询的有用标记。

更不用说 UI 中的像素、生产和本地主机中的日志、Slack 中的消息等等……

我们认为，最佳的编码系统将使用检索、递归和长上下文注意力相结合的方法来摄取所有这些信息。

我们强调系统，因为在短期内，这可能是一组模型和基础设施，这些模型和基础设施构成了一个用于编码的无限上下文引擎。从长远来看，我们预计它将融入架构。

在创造性地思考检索的未来时，我们尤其兴奋。超越嵌入，在昂贵的索引步骤和廉价的查询步骤（在语料库大小方面为次线性）的基元给定的情况下，可能的最佳性能是什么？

也许看起来像是将 Transformer 内存用作可微搜索索引的某些变体。也许是其他东西。这是一个未充分探索的研究方向。

多跳上下文

在我的代码库中，我想计算两个字符串之间的差异。使用嵌入，我得到了块

function computeDiff(
  firstModel: ITextModel,
  secondModel: ITextModel
): string {
  //...
}

为了满足原始查询，我必须确定如何从字符串创建ITextModel。这是一个需要两跳才能解决的查询。

代码库中最困难的问题和查询需要多跳。普通的检索只能用于单跳。

有希望的方向

• 代码库的专用/改进嵌入和重新排序器。
• 训练多跳嵌入器。给定一个查询和我们迄今为止找到的相关代码，确定要跳到的下一段代码。
• 巧妙的前缀缓存，以及可能更适合代码库的自定义注意力掩码。
• 关于代码库级检索的新研究。
• 教一个模型学习代码库的权重，类似于 Transformer 作为搜索索引。

---

错误检测和调试

现有的错误检测系统在校准和足够的代码库理解方面存在困难。

模型足够智能，可以正确识别错误，但容易出现误报。识别最棘手的错误需要更深入地了解代码库。在看到更大的图景后，看起来像错误的代码也可能是良性的。

一种方法可能是使用语言模型获得更好的代码审查体验

在 AI 审查中检测错误

“AI 审查”的好处是用户对误报的容忍度更高，因为他们正在请求审查。缺点是它需要改变用户行为。

AI 代码风格检查

错误检测的最佳版本是一个始终开启的代码风格检查器，它可以在后台捕获您的错误。它需要比 AI 审查更便宜、更快的模型，因为我们会每分钟运行几次。它还必须调整到更低的误报率。

更智能的调试

也许比错误检测更令人印象深刻的是调试困难的问题。

我们需要超越基于 LLM 的静态分析。例如，我们构建了一个cursor/debug包。当注入到您的代码中时，它会跟踪运行时信息。

在后台，我们甚至可以使用它来跟踪其他变量状态（类似于打印调试，并将相关的输出管道传输到 Cursor 的上下文中）。

有希望的方向

• 巧妙的数据集整理（可能是合成数据）以及前沿代码模型上的强化学习，以改进校准。
• 跟踪来自其他界面的相关信息（浏览器或未集成的终端）。
• 提高前沿模型在特定于调试器的工具使用和链中的性能。
• 无限上下文和接近完美的代码库理解。
• 扩展我们cursor/debug库的范围，以跟踪所有有用的程序状态信息。

---

如果您对这些问题有任何兴趣，请通过[email protected]与我们联系