返回主博客

更多问题

人工智能编程下一阶段的几个令人兴奋的问题领域。

发布者Aman

5分钟阅读


作为对我们最初的问题帖子的后续,这里是我们认为对人工智能编程下一阶段最重要的更多问题。

下一步行动预测

Cursor 配备了 Copilot++,它是 Copilot 的更智能版本,可以预测您的下一步编辑。我们能否将这个想法发挥到极致?

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

首先,我们扩展了 Copilot++ 以预测您的下一个位置。将其与下一步编辑预测结合起来,模型可以完成一系列低熵更改

我们按下 Tab 键 11 次,所有其他键 3 次。我们称之为 Cursor Flow(原因显而易见)。

我们正在努力预测您将要移动到的下一个文件。您将要运行的下一个终端命令。下一步编辑,以您之前的终端命令为条件!一个 下一步行动预测模型

此外,模型应在您需要信息的那一刻浮现信息。无论是正确的代码片段还是文档。

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

有前景的方向

  • 在整个代码库中进行关于行动预测的基础研究。
  • 继续对约 5-13B 活跃参数代码模型进行预训练和后训练(用于预填充绑定的低延迟预测)。
  • 类似于 推测性编辑 的额外推理技巧
  • 巧妙的 UX,以不突兀的方式呈现“操作”。(您如何建议用户应该移动到的下一个文件?或者当前视口之外的下一个位置?)

完美编辑

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

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

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

以及我们如何使异步代码生成保持流程。这听起来像是一个矛盾修辞,但我们相信在模型能力和 UX 方面的巧妙研究可能会使之成为可能。

幻觉伪代码

我们实现不存在的函数/代码,然后模型在后台为我们创建它们。

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

多文件编辑

Cmd-k 已经很棒了,但是如果您可以要求对整个代码库进行通用编辑呢?特别是,一个可以准确跨越多个文件的编辑?

有前景的方向

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

最佳上下文

可能存在数百万个文档 tokens、数千万个源代码 tokens、另外数千万个提交历史 tokens,所有这些都可能是解决单个查询的潜在有用 tokens。

更不用说,您 UI 中的像素、生产环境和本地主机中的日志、Slack 中的消息等等...

我们相信,最好的编码系统将结合检索、复现和长上下文注意力来摄取所有这些信息。

我们强调 系统,因为在短期内,这可能是一个模型和基础设施的集合,构成用于编码的无限上下文引擎。从长远来看,我们希望它能融入架构中。

当我们创造性地思考检索的未来时,我们尤其兴奋。超越嵌入,在昂贵的索引步骤和廉价的查询步骤(语料库大小的亚线性)的原语下,可能的最佳性能是什么?

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

多跳上下文

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

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

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

代码库中最困难的问题和查询需要多次跳转。原始检索仅适用于一次跳转。

有前景的方向

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

错误检测与调试

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

模型足够智能,可以正确识别错误,但受到误报的困扰。识别最棘手的错误需要对代码库有更深入的理解。并且在看到更大的图景后,看起来有错误的代码可能实际上是良性的。

这可能出现的一种方式是使用语言模型进行代码审查时获得更好的体验

在 AI 审查中检测错误

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

AI 代码检查

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

更智能的调试

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

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

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

有前景的方向

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

如果您对这些问题中的任何一个感兴趣,请通过 hiring@anysphere.inc 联系我们