更多问题 · Cursor

作为对our original problems post的跟进，以下是我们认为对下一阶段 AI 编程最为重要的更多问题。

下一步动作预测

Cursor 自带Copilot++，这是更智能的 copilot 版本，能够预测你的下一次编辑。我们能把这个想法推向它的自然极限吗？

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

首先，我们已将 Copilot++ 扩展为可预测你的下一个定位位置。将其与“下一次编辑”预测结合使用，模型即可演示一系列低熵更改：

我们按下 Tab 键 11 次，其他按键 3 次。我们称之为 Cursor Flow（原因不言自明）。

我们正在研发预测你将要跳转的下一个文件、你将要运行的下一个终端命令，以及基于你此前终端命令所进行的下一步编辑！一个下一步动作预测模型。

此外，模型应在你需要的那一刻即时呈现信息——无论是合适的代码片段还是相关文档。

Cursor 应该让你感觉像你意志的延伸。你一想到要改动，语言模型就几乎不需要额外指令即可立刻执行。

值得期待的方向

围绕整个代码库开展有关动作预测的基础研究。
对约 5–13B 活跃参数的代码模型进行持续的预训练与后训练（用于受预填充限制的低延迟预测）。
与Speculative Edits

通过巧妙的用户体验，在不打扰用户的情况下呈现“操作”。（你如何建议用户接下来应跳转到哪个文件？或者视口之外的下一个位置？）

精确编辑

我们能否扩大推理阶段的计算投入，以产出更高质量、更大范围的编辑？我们如何弥补由此带来的延迟增加？

有时可能需要在后台执行该编辑。将一项可交由智能模型可信处理的工作单元拆分并启动。

我们需要具备更强编辑器专用工具使用能力、更智能的全代码库上下文理解，以及更出色的长期推理能力的模型。

另外，我们如何让异步代码生成实现流程保真？这听起来像是自相矛盾，但我们相信，通过在模型能力和用户体验上的巧妙研究，这有可能实现。

幻觉式伪代码

我们先调用尚不存在的函数/代码，随后模型会在后台为我们自动创建它们。

用户将编写描述期望更改的伪代码。然后，我们可以信任 Cursor 在后台将这些伪代码编译为完整的更改。

多文件编辑

Cmd-k已经很强大了，但如果你能针对整个代码库发起一次通用的编辑请求呢？尤其是那种能准确覆盖多个文件的编辑？

值得期待的发展方向

扩展推理时计算资源。我们知道奖励模型和拒绝采样会带来快速且容易的改进，但还能走多远？
更强的推理模型（gpt-5、claude-4、gemini 2.0）
为某个用户工作区同时运行多个 language-server/文件系统实例。这将需要模型的工具使用能力，并在远程复现运行时环境。
基于代理轨迹训练/提升模型性能
针对流程内异步编辑的大量用户体验实验

最佳上下文

文档可能包含数百万个 token，源代码包含数千万个 token，提交历史也包含数千万个 token——这些 token 都可能对解决单个查询有用。

更不用说，你的 UI 中的像素、生产环境与本地环境的日志、Slack 里的消息，等等……

我们相信，最出色的编码系统将结合检索、递归以及长上下文注意力来吸收整合所有这些信息。

我们强调系统，因为在短期内，它可能是由多个模型和基础设施组成的，用于编码的无限上下文引擎。在长期，我们期望它融入到架构之中。

当我们以创造性的方式思考检索的未来时，格外让人兴奋。超越 embeddings 之后，在“昂贵的索引步骤”和“低成本的查询步骤”（相对于语料库规模为次线性）这一原语设定下，能够达到的最佳性能是什么？

也许它类似于某种将 transformer 的记忆用作可微分的搜索索引的变体。也可能完全是别的东西。这是一个尚未被充分探索的研究方向。

多跳上下文

在我的代码库中，我想计算两个字符串之间的差异。借助嵌入（embeddings），我得到如下片段：

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

要满足最初的问题，我需要确定如何从字符串创建一个ITextModel。这是一个需要两步推理才能解决的查询。

代码库中最棘手的问题与查询需要多跳推理。普通检索仅适用于单跳。

前景方向

面向代码库的专业化/增强型向量嵌入与重排序器。
训练多跳嵌入模型。给定一个查询以及我们迄今找到的相关代码，确定下一段要跳转的代码。
巧妙的前缀缓存，以及（或许）更适合代码库的自定义注意力掩码。
关于代码库级检索的前沿研究。
让模型在权重中学习一个代码库，类似于将 transformers 用作搜索索引。

缺陷检测与调试

现有的缺陷检测系统在校准和对代码库的充分理解方面表现欠佳。

模型足够智能，通常能正确识别缺陷，但也常被误报所困扰。要找出最棘手的缺陷，需要对代码库有更深入的理解。而且，看起来有问题的代码，在放到更大的整体上下文中审视后，可能其实并无大碍。

这可能体现为：借助语言模型，代码评审体验将大幅提升。

在 AI 审查中检测漏洞

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

AI 代码规范检查

最佳的缺陷检测方式是始终开启的 linter，在后台捕捉你的错误。由于我们每分钟会运行多次，它需要比 AI-review 更便宜、更快速的模型。同时，它还必须调校到更低的误报率。

更智能的调试

比起发现漏洞，更令人印象深刻的是能够调试棘手的问题。

我们需要超越仅基于 LLM 的静态分析。举例来说，我们构建了一个 cursor/debug 包。将其注入到你的代码后，它会跟踪运行时信息。

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

值得期待的方向

巧妙的数据集策划（可能使用合成数据）以及在前沿代码模型上进行强化学习，以提升校准效果。
从其他界面（浏览器或未集成的终端）追踪相关信息。
提升前沿模型在调试器特定的工具使用与链式操作上的表现。
无限上下文，几乎完美理解代码库。
扩展我们的 cursor/debug 库的适用范围，以跟踪所有有用的程序状态信息。

如果这些问题中的任何一个引起了你的兴趣，请通过hiring@anysphere.inc

作为对our original problems post的跟进，以下是我们认为对下一阶段 AI 编程最为重要的更多问题。

下一步动作预测

Cursor 自带Copilot++，这是更智能的 copilot 版本，能够预测你的下一次编辑。我们能把这个想法推向它的自然极限吗？

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

首先，我们已将 Copilot++ 扩展为可预测你的下一个定位位置。将其与“下一次编辑”预测结合使用，模型即可演示一系列低熵更改：

我们按下 Tab 键 11 次，其他按键 3 次。我们称之为 Cursor Flow（原因不言自明）。

此外，模型应在你需要的那一刻即时呈现信息——无论是合适的代码片段还是相关文档。

Cursor 应该让你感觉像你意志的延伸。你一想到要改动，语言模型就几乎不需要额外指令即可立刻执行。

值得期待的方向

围绕整个代码库开展有关动作预测的基础研究。
对约 5–13B 活跃参数的代码模型进行持续的预训练与后训练（用于受预填充限制的低延迟预测）。
与Speculative Edits

通过巧妙的用户体验，在不打扰用户的情况下呈现“操作”。（你如何建议用户接下来应跳转到哪个文件？或者视口之外的下一个位置？）

精确编辑

我们能否扩大推理阶段的计算投入，以产出更高质量、更大范围的编辑？我们如何弥补由此带来的延迟增加？

有时可能需要在后台执行该编辑。将一项可交由智能模型可信处理的工作单元拆分并启动。

我们需要具备更强编辑器专用工具使用能力、更智能的全代码库上下文理解，以及更出色的长期推理能力的模型。

另外，我们如何让异步代码生成实现流程保真？这听起来像是自相矛盾，但我们相信，通过在模型能力和用户体验上的巧妙研究，这有可能实现。

幻觉式伪代码

我们先调用尚不存在的函数/代码，随后模型会在后台为我们自动创建它们。

用户将编写描述期望更改的伪代码。然后，我们可以信任 Cursor 在后台将这些伪代码编译为完整的更改。

多文件编辑

Cmd-k已经很强大了，但如果你能针对整个代码库发起一次通用的编辑请求呢？尤其是那种能准确覆盖多个文件的编辑？

值得期待的发展方向

扩展推理时计算资源。我们知道奖励模型和拒绝采样会带来快速且容易的改进，但还能走多远？
更强的推理模型（gpt-5、claude-4、gemini 2.0）
为某个用户工作区同时运行多个 language-server/文件系统实例。这将需要模型的工具使用能力，并在远程复现运行时环境。
基于代理轨迹训练/提升模型性能
针对流程内异步编辑的大量用户体验实验

最佳上下文

文档可能包含数百万个 token，源代码包含数千万个 token，提交历史也包含数千万个 token——这些 token 都可能对解决单个查询有用。

更不用说，你的 UI 中的像素、生产环境与本地环境的日志、Slack 里的消息，等等……

我们相信，最出色的编码系统将结合检索、递归以及长上下文注意力来吸收整合所有这些信息。

我们强调系统，因为在短期内，它可能是由多个模型和基础设施组成的，用于编码的无限上下文引擎。在长期，我们期望它融入到架构之中。

也许它类似于某种将 transformer 的记忆用作可微分的搜索索引的变体。也可能完全是别的东西。这是一个尚未被充分探索的研究方向。

多跳上下文

在我的代码库中，我想计算两个字符串之间的差异。借助嵌入（embeddings），我得到如下片段：

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

要满足最初的问题，我需要确定如何从字符串创建一个ITextModel。这是一个需要两步推理才能解决的查询。

代码库中最棘手的问题与查询需要多跳推理。普通检索仅适用于单跳。

前景方向

面向代码库的专业化/增强型向量嵌入与重排序器。
训练多跳嵌入模型。给定一个查询以及我们迄今找到的相关代码，确定下一段要跳转的代码。
巧妙的前缀缓存，以及（或许）更适合代码库的自定义注意力掩码。
关于代码库级检索的前沿研究。
让模型在权重中学习一个代码库，类似于将 transformers 用作搜索索引。

缺陷检测与调试

现有的缺陷检测系统在校准和对代码库的充分理解方面表现欠佳。

这可能体现为：借助语言模型，代码评审体验将大幅提升。

在 AI 审查中检测漏洞

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

AI 代码规范检查

更智能的调试

比起发现漏洞，更令人印象深刻的是能够调试棘手的问题。

我们需要超越仅基于 LLM 的静态分析。举例来说，我们构建了一个 cursor/debug 包。将其注入到你的代码后，它会跟踪运行时信息。

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

值得期待的方向

巧妙的数据集策划（可能使用合成数据）以及在前沿代码模型上进行强化学习，以提升校准效果。
从其他界面（浏览器或未集成的终端）追踪相关信息。
提升前沿模型在调试器特定的工具使用与链式操作上的表现。
无限上下文，几乎完美理解代码库。
扩展我们的 cursor/debug 库的适用范围，以跟踪所有有用的程序状态信息。

如果这些问题中的任何一个引起了你的兴趣，请通过hiring@anysphere.inc

作为对our original problems post的跟进，以下是我们认为对下一阶段 AI 编程最为重要的更多问题。

下一步动作预测

Cursor 自带Copilot++，这是更智能的 copilot 版本，能够预测你的下一次编辑。我们能把这个想法推向它的自然极限吗？

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

首先，我们已将 Copilot++ 扩展为可预测你的下一个定位位置。将其与“下一次编辑”预测结合使用，模型即可演示一系列低熵更改：

我们按下 Tab 键 11 次，其他按键 3 次。我们称之为 Cursor Flow（原因不言自明）。

此外，模型应在你需要的那一刻即时呈现信息——无论是合适的代码片段还是相关文档。

Cursor 应该让你感觉像你意志的延伸。你一想到要改动，语言模型就几乎不需要额外指令即可立刻执行。

值得期待的方向

围绕整个代码库开展有关动作预测的基础研究。
对约 5–13B 活跃参数的代码模型进行持续的预训练与后训练（用于受预填充限制的低延迟预测）。
与Speculative Edits

通过巧妙的用户体验，在不打扰用户的情况下呈现“操作”。（你如何建议用户接下来应跳转到哪个文件？或者视口之外的下一个位置？）

精确编辑

我们能否扩大推理阶段的计算投入，以产出更高质量、更大范围的编辑？我们如何弥补由此带来的延迟增加？

有时可能需要在后台执行该编辑。将一项可交由智能模型可信处理的工作单元拆分并启动。

我们需要具备更强编辑器专用工具使用能力、更智能的全代码库上下文理解，以及更出色的长期推理能力的模型。

另外，我们如何让异步代码生成实现流程保真？这听起来像是自相矛盾，但我们相信，通过在模型能力和用户体验上的巧妙研究，这有可能实现。

幻觉式伪代码

我们先调用尚不存在的函数/代码，随后模型会在后台为我们自动创建它们。

用户将编写描述期望更改的伪代码。然后，我们可以信任 Cursor 在后台将这些伪代码编译为完整的更改。

多文件编辑

Cmd-k已经很强大了，但如果你能针对整个代码库发起一次通用的编辑请求呢？尤其是那种能准确覆盖多个文件的编辑？

值得期待的发展方向

扩展推理时计算资源。我们知道奖励模型和拒绝采样会带来快速且容易的改进，但还能走多远？
更强的推理模型（gpt-5、claude-4、gemini 2.0）
为某个用户工作区同时运行多个 language-server/文件系统实例。这将需要模型的工具使用能力，并在远程复现运行时环境。
基于代理轨迹训练/提升模型性能
针对流程内异步编辑的大量用户体验实验

最佳上下文

文档可能包含数百万个 token，源代码包含数千万个 token，提交历史也包含数千万个 token——这些 token 都可能对解决单个查询有用。

更不用说，你的 UI 中的像素、生产环境与本地环境的日志、Slack 里的消息，等等……

我们相信，最出色的编码系统将结合检索、递归以及长上下文注意力来吸收整合所有这些信息。

我们强调系统，因为在短期内，它可能是由多个模型和基础设施组成的，用于编码的无限上下文引擎。在长期，我们期望它融入到架构之中。

也许它类似于某种将 transformer 的记忆用作可微分的搜索索引的变体。也可能完全是别的东西。这是一个尚未被充分探索的研究方向。

多跳上下文

在我的代码库中，我想计算两个字符串之间的差异。借助嵌入（embeddings），我得到如下片段：

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

要满足最初的问题，我需要确定如何从字符串创建一个ITextModel。这是一个需要两步推理才能解决的查询。

代码库中最棘手的问题与查询需要多跳推理。普通检索仅适用于单跳。

前景方向

面向代码库的专业化/增强型向量嵌入与重排序器。
训练多跳嵌入模型。给定一个查询以及我们迄今找到的相关代码，确定下一段要跳转的代码。
巧妙的前缀缓存，以及（或许）更适合代码库的自定义注意力掩码。
关于代码库级检索的前沿研究。
让模型在权重中学习一个代码库，类似于将 transformers 用作搜索索引。

缺陷检测与调试

现有的缺陷检测系统在校准和对代码库的充分理解方面表现欠佳。

这可能体现为：借助语言模型，代码评审体验将大幅提升。

在 AI 审查中检测漏洞

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

AI 代码规范检查

更智能的调试

比起发现漏洞，更令人印象深刻的是能够调试棘手的问题。

我们需要超越仅基于 LLM 的静态分析。举例来说，我们构建了一个 cursor/debug 包。将其注入到你的代码后，它会跟踪运行时信息。

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

值得期待的方向

巧妙的数据集策划（可能使用合成数据）以及在前沿代码模型上进行强化学习，以提升校准效果。
从其他界面（浏览器或未集成的终端）追踪相关信息。
提升前沿模型在调试器特定的工具使用与链式操作上的表现。
无限上下文，几乎完美理解代码库。
扩展我们的 cursor/debug 库的适用范围，以跟踪所有有用的程序状态信息。

如果这些问题中的任何一个引起了你的兴趣，请通过hiring@anysphere.inc