AI 编程下一阶段的几个令人兴奋的问题领域。
作为我们原始问题文章的后续,这里是我们认为对 AI 编程下一阶段最重要的一些问题。
下一步动作预测
Cursor 配备了 Copilot++,这是一个更智能的 copilot 版本,可以预测你的下一步编辑。我们能否将这个想法推向极限?
在编码时,你不仅仅是进行低熵的_编辑_。在整个编辑器中,你会进行低熵的按键、点 击、动作。我们能否构建一个模型来低延迟地预测每一个动作?
首先,我们已经扩展了 Copilot++ 来预测你的下一个位置。将这个与下一步编辑预测结合起来,模型就可以播放一系列低熵的更改:
我们按下 tab 键 11 次,其他键 3 次。我们称之为 Cursor Flow(原因显而易见)。
我们正在努力预测你将移动到的下一个文件。你将运行的下一个终端命令。基于你之前的终端命令的下一次编辑!一个下一步动作预测模型。
此外,模型应该在你需要的那一刻就呈现信息。无论是正确的代码片段还是文档。
Cursor 应该_感觉_像是你意志的延伸。当你想到一个更改时,语言模型只需要最小的意图就能立即执行它。
有前途的方向
- 关于整个代码库中_动作预测_的基础研究。
- 在约 5-13B 活跃参数的代码模型上继续进行预训练和后训练(用于预填充绑定的低延迟预测)。
- 类似于推测性编辑的额外推理技巧。
- 以非侵入式方式呈现"动作"的巧妙用户体验。(如何提出用户应该移动到的下一个文件?或当前视图之外的下一个位置?)
完美编辑
我们能否通过扩大推理时间的计算来产生更高质量、更大规模的编辑?我们如何补偿增加的延迟?
可能需要在_后台_执行编辑。生成一个可以信任智能模型的工作单元。
我们需要具有强大编 辑器特定工具使用能力、更智能的代码库范围上下文和改进的长期推理能力的模型。
而且,我们如何使异步代码生成_保持流畅_。这听起来像是一个矛盾,但我们相信通过在模型能力和用户体验方面的巧妙研究可能会使这成为可能。
幻想的伪代码
我们实现不存在的函数/代码,然后模型在后台为我们创建它们。
用户将编写描述所需更改的伪代码。然后我们可以信任 Cursor 在后台将伪代码编译成完整的更改。
多文件编辑
Cmd-k 已经很棒了,但如果你可以在整个代码库中请求一个通用编辑呢?特别是,一个准确跨越多个文件的编辑?
有前途的方向
- 扩展推理时间计算。我们知道奖励模型和拒绝采样会带来快速且简单的改进,但我们还能走多远?
- 更好的推理模型(gpt-5、claude-4、gemini 2.0)
- 为给定的用户工作区运行多个语言服务器/文件系统副本。这将需要模型工具使用和远程复制运行时环境。
- 在代理轨迹上训练/改进模型性能
- 对流内异步编辑进行大量用户体验实验
最优上下文
可能有数百万个文档标记、数千万个源代码标记、另外数千万个提交历史标记,所有这些都可能是解决单个查询的有用标记。
更不用说,你的 UI 中的像素、生产和本地主机中的日志、Slack 中的消息等...
我们相信最好的编码系统将使用检索、递归和长上下文注意力的混合来摄取所有这些信息。
我们强调系统,因为在短期内,这可能是一个模型和基础设施的集合,构成了编码的无限上下文引擎。从长远来看,我们期望它被烘焙到架构中。
当创造性地思考检索的未来时,我们特别兴奋。超越嵌入,给定昂贵的索引步骤和廉价的查询步骤(在语料库大小中是次线性的)的原语,可能的最佳性能是什么?
也许它看起来像某种变体的 transformer 内存作为可微搜索索引。也许是完全不同的东西。这是一个未被充分探索的研究方向。
多跳上下文
在我的代码库中,我想计算两个字符串之间的差异。使用嵌入,我得到了这个代码块:
function computeDiff(
firstModel: ITextModel,
secondModel: ITextModel,
): string {
//...
}
要满足原始查询,我必须确定如何从字符串创建 ITextModel
。这是一个需要两跳才能解决的查询。
代码库中最难的问题和查询需要多个跳跃。普通的检索只适用于一跳。
有前途的方向
- 专门化/改进的代码库嵌入和重排序器。
- 训练多跳嵌入器。给定查询和我们到目前为止找到的相关代码,确定下一个要跳转到的代码片段。
- 巧妙的前缀缓存,也许还有更适合代码库的自定义注意力掩码。
- 关于代码库级检索的新颖研究。
- 教模型在权重中_学习_代码库,类似于作为搜索索引的 transformers。
错误检测和调试
现有的错误检测系统在校准和充分理解代码库方面存在困难。
模型足够聪明,可以正确识别错误,但受到误报的困扰。识别最棘手的错误需要对代码库有更深入的理解。而且看起来有错误的代码在看到更大的图景后可能是良性的。
这可能以使用语言模型进行代码审查的更好体验的形式出现:
在 AI 审查中检测错误
"AI 审查"的好处是用户对误报更宽容,因为他们是在请求审查。缺点是它需要改变用户行为。
AI 代码检查
错误检 测的最佳版本是一个始终在线的代码检查器,可以在后台捕获你的错误。它需要是一个比 AI 审查更便宜、更快的模型,因为我们每分钟都会运行它多次。它还必须调整为更低的误报率。
更智能的调试
也许比错误检测更令人印象深刻的是调试困难的问题。
我们需要超越基于 LLM 的静态分析。例如,我们已经构建了一个 cursor/debug
包。当注入到你的代码中时,它会跟踪运行时信息。
在后台,我们甚至可以使用它来跟踪额外的变量状态(类似于打印调试,相关输出被输送到 Cursor 的上下文中)。
有前途的方向
- 巧妙的数据集策划(可能是合成数据)和在前沿代码模型上的强化学习以改进校准。
- 从其他表面(浏览器或非集成终端)跟踪相关信息。
- 改进前沿模型在调试器特定工具使用和链条上的性能。
- 无限上下文和近乎完美的代码库理解。
- 扩展我们的
cursor/debug
库的范围以跟踪所有有用的程序状态信息。
如果这些问题中的任何一个让你感兴趣,请通过 hiring@anysphere.inc 联系我们。