作为对 我们最初那篇“问题”博文 的后续补充，这里列出了一些我们认为对下一阶段 AI 编程最为关键的新问题。
Cursor 内置了 Copilot++，这是一个更智能的 copilot 版本，能够预测你的下一次编辑。我们能不能把这个想法推向极致？
在编码时，你做的并不只是低熵的编辑。在整个编辑器中，你在进行的是低熵的按键、点击和各种操作。我们能不能构建一个模型，以极低的延迟预测每一步操作？
作为起点，我们已经扩展 Copilot++ 来预测你的下一个光标位置。把这和下一次编辑预测结合起来，模型就可以「播放」一系列低熵的变更：
我们正在研究预测你接下来会切换到的文件、会运行的终端命令，以及在你之前的终端命令基础上，你下一次要做的编辑！一个下一步动作预测模型。
此外，这个模型应该在你需要的那一刻就把信息呈现给你——无论是正确的代码片段还是文档。
Cursor 应该让人感觉像是你意志的延伸。当你刚产生某个改动想法时，语言模型几乎不需要你多加说明，就能立刻帮你执行。
关于在整个代码库范围内进行 动作预测 的基础研究。
持续对约 50～130 亿有效参数的代码模型进行预训练和后训练（用于 prefill 受限场景下的低延迟预测）。
类似于 Speculative Edits 的更多推理技巧
为以不打扰用户的方式呈现「动作」设计巧妙的用户体验（UX）。 （比如，如何智能推荐用户下一步应该跳转到哪个文件？或者当前视口之外的哪个位置？）
我们能否通过增加推理阶段的计算量，来生成质量更高、幅度更大的修改？又该如何弥补由此带来的延迟增加？
可能有必要在后台执行编辑。也就是发起一段你可以放心交给智能模型处理的独立任务。
我们需要具备更强编辑器工具使用能力的模型、更智能的全代码库上下文理解，以及更好的长期推理能力。
此外，我们如何让异步代码生成仍然能够保持代码/开发流程的连贯性？这听起来有点自相矛盾，但我们相信，在模型能力和用户体验上的巧妙探索，可能让这成为现实。
用户只需编写描述期望更改的伪代码。然后，我们就可以放心让 Cursor 在后台将这些伪代码转化为完整的改动。
Cmd-k 已经非常强大了，但如果你能对整个代码库发起一次通用的修改指令呢？尤其是那种能精准覆盖多个文件的编辑？
扩展推理阶段的算力规模。我们知道奖励模型和拒绝采样会带来快速且轻松的提升，但我们还能将这一方向推进到什么程度？
更强的推理模型（GPT-5、Claude 4、Gemini 2.0）
为单个用户工作区运行多个语言服务器 / 文件系统实例。这将需要模型的工具调用能力，并在远程环境中复现运行时环境。
在代理轨迹上进行训练 / 提升模型性能
围绕流程中的异步编辑进行大量 UX 试验
文档可能有数百万个 token，源代码有上千万个 token，提交历史又有上千万个 token，这些 token 都可能对解决单个查询有用。
更不用说，你的界面里的像素、生产环境和本地环境中的日志、Slack 里的消息等等……
我们认为，最好的编程系统会综合运用检索、递归（recurrence）和长上下文注意力，来吸收和利用所有这些信息。
我们特意强调系统，因为在短期内，这可能是由多个模型和基础设施组成的集成体系，为编程提供一个“无限上下文引擎”。从长期来看，我们预计这会被直接烘焙进模型架构之中。
当我们以更具创造性的方式思考检索的未来时，尤其让人感到兴奋。超越 embeddings 之后，在“昂贵的索引步骤”和“廉价的查询步骤（相对于语料库大小是次线性的）”这一基础设定下，究竟还能做到怎样的性能上限？
也许会是某种变体形式的 transformer memory as a differentiable search index，也可能是完全不同的路径。这仍然是一条尚未被充分探索的研究方向。
在我的代码库中，我想计算两个字符串之间的 diff。使用嵌入向量后，我得到的片段是：
function computeDiff(
firstModel: ITextModel,
secondModel: ITextModel,
): string {
// ...
}为了真正满足原始查询，我必须确定如何从一个字符串创建一个 ITextModel。这是一个需要两跳才能解决的查询。
代码库中最难的问题和查询需要多跳推理。普通的检索方式只适用于单跳。
面向代码库的专用/改进型向量嵌入和重排序模型。
训练多跳嵌入模型：在给定一个查询以及当前已找到的相关代码的情况下，决定下一段要跳转的代码。
更巧妙的前缀缓存策略，以及可能更适合代码库的自定义注意力掩码。
关于代码库级别检索的全新研究。
让模型在参数中学习整个代码库，类似将 Transformer 用作搜索索引。
现有的缺陷检测系统在结果校准和对代码库的深入理解方面表现不佳。
模型已经足够智能，可以正确识别缺陷，但也会被大量误报所困扰。定位最棘手的缺陷，需要对代码库有更深层次的理解。而那些看起来像是有问题的代码，在放到更大的整体上下文中审视后，其实可能是无害的。
这其中一个重要的应用场景，就是借助语言模型显著提升代码审查体验：
“AI 评审”的好处在于，用户对误报会更宽容，因为是他们主动请求一次评审。缺点是，这需要改变用户的既有行为习惯。
最佳的 Bug 检测方式，是一个始终开启、在后台持续运行、自动捕获问题的 linter。它所使用的模型需要比 AI-review 更便宜、更快速，因为我们会在每分钟内多次运行它。同时，它还必须经过调优，以尽可能降低误报率。
也许比起发现 Bug，更令人印象深刻的是对棘手问题的调试能力。
我们需要做的不仅仅是基于 LLM 的静态分析。例如，我们构建了一个 cursor/debug 包。将它注入到你的代码中后，就可以跟踪运行时信息。
在后台运行时，我们甚至可以用它来跟踪额外的变量状态（类似于通过打印日志进行调试，只是把相关输出注入到 Cursor 的上下文中）。
通过精心的数据集构建（很可能是合成数据）以及在前沿代码模型上进行 RL（强化学习）来提升校准能力。
从其他界面/环境（浏览器或未集成的终端）中跟踪相关信息。
提升前沿模型在与调试器相关的工具调用和调用链方面的表现。
实现无限上下文和近乎完美的代码库理解。
扩展我们的 cursor/debug 库的适用范围，以跟踪所有有用的程序状态信息。
如果你对这些问题中的任何一个感兴趣，请发送邮件至 hiring@cursor.com
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。