Cursor博客 - 面临的挑战 - 2024

本文翻译自Cursor官方博客Our problems - 2024，原文发布于2024年5月25日，通过这篇文章可以看到 Cursor 对未来的规划。

作为Cursor 2023年面临的挑战的后续内容，以下是我们认为在下一阶段 AI 编程中最重要的一些问题。

下一步动作预测

Cursor 配备了加强版的 Tab 功能，这是 Copilot 的更智能版本，它可以预测你的下一次编辑。我们能否将这个功能做到极致呢？

在编程时，你不仅会进行低复杂度形式的编辑。在整个编辑器中，你的每一次按键、点击、操作也是低复杂度的。我们能否构建一个模型来低延迟地预测每一次这样的操作呢？

首先，我们扩展了 Tab 功能来预测你的下一个光标位置。将其与下一次编辑预测相结合，模型可以在一系列低复杂度的操作中顺畅运行：

我们正在研究预测你将要移动到的下一个文件、将要运行的下一个终端命令，以及基于之前的终端命令预测下一次编辑的可能性！这是一个“下一步动作预测”模型。

此外，模型应该在你需要的时候立即提供信息，无论是正确的代码片段还是相关的文档。

Cursor 应该像是你的延伸工具。当你想到一个更改时，语言模型几乎不需要明确指令就能立即执行它。

有前景的方向

• 对代码库中的动作预测进行基础性研究。
• 针对拥有约 50 亿到 130 亿个活跃参数的代码模型，持续进行预训练和后训练（以便在代码补充环节进行低延迟预测）。
• 类似“推测性编辑”的其他推理技巧。
• 智能化的 UX 设计，用于在不打扰用户的情况下呈现“操作”（例如，如何推荐用户应移动到的下一个文件或当前视图之外的下一个位置？）。

完美编辑

我们能否增加推理时的计算量以产生更高质量的、更大范围的编辑？我们如何应对延迟的增加？

也许需要在后台执行编辑。将任务交给可以信任的智能模型来处理。

我们需要模型具备强大的工具使用能力、更智能的代码库范围上下文理解能力，以及改进的长期推理能力。

此外，如何让异步代码生成与用户代码流程同时运行？这听起来像是自相矛盾的，但我们相信通过对模型能力和用户体验的深入研究，这可能成为现实。

幻觉伪代码

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

多文件编辑

Cmd-k 已经非常强大，但如果你可以请求跨整个代码库进行的通用编辑呢？特别是能够准确跨多个文件的编辑？

有前景的方向

• 提升推理时的计算能力。我们知道奖励模型和拒绝采样能带来快速而直接的改进，但我们还能走多远？
• 更强的推理模型（如 GPT-5、Claude-4、Gemini 2.0）。
• 在用户工作区中运行多个语言服务器和文件系统副本。这将需要模型的工具使用能力，以及远程复现运行时环境。
• 针对Agent行为轨迹训练和提升模型性能。
• 对异步编辑流程进行大量的 UX 设计实验。

最佳上下文

文档可能包含数百万个 Token，源码可能包含数千万个 Token，提交历史也可能包含数千万个 Token，所有这些 Token 都可能对解决某个查询有所帮助。

此外，还有 UI 界面中的像素、生产环境和本地环境中的日志、Slack 消息等……

我们相信，最好的代码系统将结合检索、循环和长上下文注意力机制来吸收所有这些信息。

我们特别强调“系统”这一概念，因为在短期内，这可能是一个由模型和基础设施组成的集合，构成一个用于编码的无限上下文引擎。从长远来看，我们期望它会被融入到架构中。

我们对未来检索技术的创造性思考感到格外兴奋。超越嵌入式技术，如果我们假设索引步骤代价高昂，而查询步骤代价低廉（相对于语料库规模而言呈亚线性增长），那么最佳性能会是什么样的？

也许它看起来像是某种变体的 Transformer 内存，作为可微分的搜索索引。也许是完全不同的东西。这是一个尚未被充分探索的研究方向。

多跳上下文

在我的代码库中，我想计算两个字符串之间的差异。通过嵌入模型，我可以得到这样的代码块：

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

为了满足最初的查询，我必须确定如何创建一个 ITextModel 对象。这是一个需要两跳才能解决的查询。

代码库中最难的问题和查询需要多跳推理。普通的检索只能解决一跳问题。

有前景的方向

• 针对代码库的专用/改进的嵌入和重排序器。
• 训练多跳嵌入器。给定一个查询和目前找到的相关代码，确定下一段要跳到的代码。
• 智能前缀缓存，也许还有更适合代码库的自定义注意力掩码。
• 关于代码库级别检索的新颖研究。
• 教模型在权重中学习代码库，类似于将 Transformer 作为搜索索引。

错误检测与调试

现有的错误检测系统在校准和对代码库的理解上存在不足。

虽然模型足够智能，能够正确识别错误，但仍然受到误检的困扰。要识别最棘手的错误，需要对代码库有更深入的理解。而看似有问题的代码，在更大的上下文中可能是无害的。

一种改进体验的方法是通过语言模型为代码审查提供更好的支持：

在 AI 代码审查中检测错误

“AI 代码审查”的优势在于用户对误检的容忍度较高，因为他们主动请求审查。缺点是它需要用户改变现有的操作习惯。

AI 代码检查

最理想的错误检测方式是始终开启的代码检查器，它能够在后台自动捕捉你的错误。这样的工具需要比 AI 代码审查模型更高效、更快速，因为它每分钟会运行多次。同时，它必须经过优化，以降低误检率。

更智能的调试

相比错误检测，更为令人印象深刻的是如何调试复杂问题。

我们需要超越基于大语言模型的静态分析。例如，我们已经开发了一个 Cursor/Debug 调试包。当它被注入代码时，它能够跟踪运行时的信息。

在后台运行时，我们甚至可以利用它来跟踪更多变量的状态（类似于 print 调试，将相关输出导入到 Cursor 的上下文中）。

有前景的方向

• 策划高质量的数据集（可能是合成数据）并在前沿代码模型上应用强化学习，以改进模型的校准能力。
• 从其他界面（如浏览器或非集成的终端）跟踪相关信息。
• 提升前沿模型在使用调试器工具和执行链式操作时的表现。
• 实现无限上下文和接近完美的代码库理解。
• 扩展 Cursor/Debug 库的功能范围，以便更全面地跟踪有用的程序状态信息。