之前，元总发给我 Yusen 老板在 AI Code 分享中 Cursor 团队的两篇文章。一直没时间阅读，今天抽了点时间看了一下：
OCTOBER 12, 2023
[Our Problems] - (https://www.cursor.com/blog/problems-2023)
MAY 25, 2024
[More Problems] - (https://www.cursor.com/blog/problems-2024)
更好的上下文：在代码编辑器中，有很多信息来源：打开的文件、语义上相似的代码块、符号上相关的类、lint 输出、执行轨迹、git 历史、输入历史、外部文档等。我们希望模型能够即时理解用户问题的相关内容，目前我们正在训练一个定制的快速重排序模型来解决这个问题。每个请求时，我们会从所有不同来源收集 50 万个 tokens，使用重排序模型将其筛选为最相关的 8k tokens。这不仅是一个模型问题，越来越成为一个基础设施问题。
“编辑助手”：虽然 GitHub Copilot 对于消除新代码编写时的低熵击键非常有帮助，但它并不擅长在需要对现有代码块做小的、简单修改时，节省低熵击键。比如重命名时，操作就比简单的 F2 重命名更复杂，涉及更多的导航、删除和输入。我们需要在 UX（编码过程中不打扰的差异展示）和模型端（提示式方法无法解决，原因包括成本、延迟和智能问题）上进行创新。
受限的流程代理：类似 OpenAI 的代码解释器，但应用于大规模代码库的工程中。你给一个受限的、少步骤的代理指令，它会帮你搜索、编写并运行代码，同时不断地征求你的反馈。实现这个目标的第一步是让这个代理能在包含几十万个 tokens 的文件夹中工作。目前我们正在朝这个方向努力。如果成功，我们会将其扩展到整个代码库。
Bug 查找：这里有两种模式：（1）在后台，Cursor 会始终被动扫描你的文件，寻找潜在的 bug；（2）当你处于调试过程中时，Cursor 会主动协助你寻找 bug。这方面有很多有趣的数据收集工作可以做。
更大规模的编辑：Cursor 应该能够为你修改整个文件，甚至整个目录。这是一个能力和 UX 的挑战。为了提升速度，模型需要足够智能，能挑选出需要修改的部分，而不是重写整个文件。为了让体验更好，修改过程需要以可解析的实时形式呈现给用户。
规模扩展：截至 2023 年 10 月 12 日，我们已经索引了 14 亿个向量和 15 万个代码库，预计到年底这一数字将增长 10 倍。我们已经在 Rust 中构建了一个非常快速的基于 Merkle 树的代码库同步引擎，并且可能很快需要构建一个定制的索引系统。
- 时间穿梭：预测并展示未来 15 分钟内您将做出的跨文件代码修改。通过一个命令接受所有插入/删除操作。
- 理解能力：我们的模型应该能够深入理解任何代码库中的所有概念，并将这些理解体现在权重中。
- 阅读模式：通过任何层次的文档和一个引导您理解相关代码路径的机器人，使代码理解变得轻松。
- 伪代码模式：编辑代码的“概要”表示形式，并让修改自动应用到源代码中。
- 再也不担心堆栈追踪：IDE 应该自动识别堆栈错误，并为您自动修复代码。
我们尝试收集目前正在考虑的所有问题，但——这也是构建一个您自己每天使用 12 小时的产品的其中一个美妙之处——我们不断有新的想法，并且会重新优先排序。因此，这不应视为一份终极路线图。不过，我们希望它能让您了解我们每天思考的方向。
1. 下一步动作预测
Cursor 配备了 **Copilot++**，这是 Copilot 的更智能版本，能够预测您的下一次编辑。我们能否将这一想法推向极限？
在编码过程中，您不仅仅是做低熵的编辑。在整个编辑器中，您进行的是低熵的击键、点击和操作。我们能否构建一个模型，低延迟地预测每一个操作？
首先，我们扩展了 Copilot++ 来预测您的下一个位置。将其与下一次编辑预测相结合，模型可以顺利地执行一系列低熵变化：
例如，我们按下 Tab 键 11 次，其他按键 3 次。我们称之为 Cursor Flow（显而易见的原因）。
我们正在努力预测您将要移动到的下一个文件。您将运行的下一个终端命令。根据您之前的终端命令，预测下一次编辑！这就是 下一步动作预测模型。
此外，模型应在您需要时即时呈现相关信息。不论是相关的代码片段还是文档。
Cursor 应该像您的意图延伸一样。当您想到一个变化时，语言模型只需要最小的意图即可立即执行。
有前景的方向：
- 在 ~5-13B 活跃参数的代码模型上进行持续的预训练和后训练（用于预填充的低延迟预测）。
- 类似于 Speculative Edits 的推理技巧。
- 设计巧妙的用户体验，以非侵入性的方式呈现“操作”（例如，如何建议用户移动到下一个文件？或者如何提出下一个视口外的位置？）。
2. 完美的编辑
我们能否通过扩大推理时间计算，来生成更高质量、更大规模的编辑？我们如何弥补由此带来的延迟？
或许有必要在后台执行编辑。通过启动一项您可以信任的工作单元，由智能模型来完成。
我们需要具备强大编辑器专用工具使用能力的模型，能够理解更广泛的代码库上下文，并提升长期推理能力。
另外，我们如何确保异步代码生成能够保持流程一致性？这听起来像是自相矛盾，但我们相信，通过在模型能力和用户体验上的巧妙研究，这一目标是可以实现的。
幻觉伪代码
我们实现一些不存在的函数/代码，接着模型在后台为我们创建这些代码。
用户将编写伪代码，描述所需的变化。然后，我们可以信任 Cursor 在后台将伪代码编译成完整的变更。
多文件编辑
Cmd-k 已经非常出色，但如果您能要求在整个代码库中进行通用编辑呢？尤其是能够准确跨多个文件进行修改？
有前景的方向：
- 扩展推理时计算：我们知道奖励模型和拒绝采样会带来快速且简便的改进，但我们还能走多远？
- 更好的推理模型（例如 GPT-5、Claude-4、Gemini 2.0）
- 为特定用户工作区运行多个语言服务器/文件系统副本：这需要模型的工具使用能力，并能够远程复制运行时环境。
3. 最佳上下文
在解决一个查询时，可能涉及到数百万个文档 tokens、数千万个源代码 tokens，以及另数千万个提交历史 tokens，所有这些都可能对解决问题有所帮助。
更不用说，UI 中的像素、生产环境和本地环境中的日志、Slack 中的消息等等……
我们相信，最好的编程系统将会结合检索、递归和长上下文注意力机制，来处理和利用这些信息。
我们强调 系统，因为在短期内，这可能是一个由多个模型和基础设施组成的集合体，构成一个无限上下文引擎，用于编程。而从长远来看，我们预期这将会被融入到架构中。
当我们富有创意地思考检索的未来时，我们尤其感到兴奋。超越嵌入技术，考虑在昂贵的索引步骤和廉价的查询步骤（与语料库大小呈亚线性关系）下，能达到的最佳性能是什么？
也许这会类似于某种变种的 Transformer memory 作为一个可微分的搜索索引。也有可能是完全不同的东西。这是一个尚未充分探索的研究方向。
多跳上下文
在我的代码库中，我想计算两个字符串之间的差异。使用嵌入技术，我得到的片段是：
function computeDiff(
firstModel: ITextModel,
secondModel: ITextModel,
): string {
//...
}
为了满足最初的查询，我必须确定如何从一个字符串创建一个 ITextModel。这是一个需要两次跳跃才能解决的查询。
在一个代码库中，最难的问题和查询通常需要多个跳跃。普通的检索方法只能解决单跳问题。
有前景的方向
- 训练多跳嵌入器：给定一个查询和我们目前找到的相关代码，确定接下来需要跳转到的代码片段。
- 智能前缀缓存，或许可以采用定制的注意力掩码，更适合代码库的处理。
- 教会模型在权重中学习代码库，类似于将 Transformer 用作搜索索引。
4.错误检测与调试
现有的错误检测系统在校准和对代码库的理解方面仍存在困难。
模型足够智能，能够正确识别错误，但仍然容易产生假阳性。识别最棘手的错误需要对代码库有更深入的理解。而看似有问题的代码，在看到更大范围的上下文之后，可能是无害的。
一种可能的方式是，通过使用语言模型来显著提升代码审查的体验：
AI 审查中的错误检测
“AI 审查”的好处是，用户对假阳性的容忍度更高，因为他们是在请求审查。而缺点是，它要求用户行为发生变化。
AI Linting
最好的错误检测方式是一个始终在线的 Linter，它能在后台捕捉到您的错误。它需要比 AI 审查模型更便宜、更快，因为我们可能会每分钟运行几次。它还必须调优以减少假阳性率。
更智能的调试
或许比错误检测更令人印象深刻的，是调试困难问题的能力。
我们需要超越基于 LLM 的静态分析。例如，我们已经构建了一个 cursor/debug 包。当注入到代码中时，它能够追踪运行时信息。
在后台，我们甚至可以用它来追踪额外的变量状态（类似于打印调试，通过将相关输出传递到 Cursor 的上下文中）。
有前景的方向：
- 巧妙的数据集策划（可能是合成数据）和基于强化学习的前沿代码模型校准。
- 追踪来自其他表面的信息（如浏览器或非集成的终端）。
- 提升前沿模型在调试器特定工具使用和链式操作上的表现。
- 扩展我们的 cursor/debug 库，追踪所有有用的程序状态信息。
粤ICP备14082021号
免费POC，
零成本试错
