更新：我们又写了一篇，介绍了 更多问题。

一份不分先后的、简短而具体的问题清单：

• 更好的上下文： 在代码编辑器里有很多信息来源：打开的文件、语义上相似的代码片段、符号上关联的类、lint 输出、执行轨迹、git 历史、输入历史、外部文档等等。我们希望模型能立即理解对用户问题来说最相关的内容，因此目前正在训练一个自定义且高速的重排序模型来解决这个问题。对于每个请求，我们会从所有不同来源收集 50 万个 token，然后用我们的重排序器把它们过滤到最相关的 8k 个 token。这既是一个模型问题，而且正越来越多地成为一个基础设施问题。

• “面向编辑的 copilot”： 虽然 GitHub Copilot 在你编写新代码时，对于消除低熵按键极其有用，但当你需要对现有代码块做一些小而简单的改动时，它并不能帮你节省这些低熵按键。想象一下，比简单的符号级 F2 重命名稍微复杂一点的重命名操作时，你需要进行的导航、删除和输入按键。我们需要在 UX（在你写代码时，向你展示不打扰你的 diff）和模型侧两方面进行创新（仅靠 prompting 是不够的，因为会有成本、延迟和智能上的问题）。

• 受约束的、流内 Agent： 想象一下 OpenAI 的 code interpreter，但用于大型代码库里的工程工作。你给一个受约束、步骤不多的 Agent 下达指令，它为你搜索、编写并运行代码，同时时不时征求你的反馈。实现这一点的第一步（我们现在正在做）是构建一个能在包含几十万 token 的文件夹上正常工作的 Agent。如果这一步成功，我们会把它扩展到可以处理整个代码库。

• 找 Bug： 这里有两种模式：（1）在后台，Cursor 会一直被动地扫描你的文件，为你发现潜在的 bug；（2）当你正深入调试时，Cursor 会在你的帮助下主动寻找这个 bug。这里有很多有趣的数据收集工作可以做。

• 更大规模的编辑： Cursor 应该能为你修改整个文件，甚至整个目录。这在能力和 UX 上都是一个挑战。为了速度，模型需要足够聪明，只挑出需要修改的部分，而不是重写全部内容。为了让体验更好，变更需要以一种可解析的、实时的形式展示出来。

• 规模： 截至 2023 年 10 月 12 日，我们已经索引了 14 亿个向量和 15 万个代码库。到年底这很可能会再增长 10 倍。我们已经用 Rust 构建了一个非常快速的、基于 Merkle 树的代码库同步引擎，并且很可能很快就需要构建一个自定义的索引系统。

未来的一些想法：

• 时间扭曲（Time warp）：预测并展示你在接下来 15 分钟里会做的跨文件代码修改。通过一个快捷指令即可接受所有插入/删除操作。

• 理解（Understanding）：我们的模型应当能在权重中深刻理解任意代码库里的所有概念。

• 阅读模式（Reader mode）：通过任意粒度层级的文档，以及一个带你走过相关代码路径、按需解释的 Bot，让理解代码变得毫不费力。

• 伪代码模式（Pseudo-code mode）：编辑你代码的“纲要”表示，并让这些修改自动应用到源码层面。

• 再也不用担心 stack trace： IDE 应该自己就能看懂，并自动为你修好代码。

我们试图把当前在思考的所有问题都收集起来，但——这也是每天用自己产品 12 小时的一个美妙之处——我们不断迸发新想法并重新排优先级，所以这不应被视为一份面面俱到的路线图。话虽如此，我们也希望这能让你大致了解我们每天把脑力花在了哪些事情上。

另外，你已经读到这里了，看起来你很可能对我们感兴趣的问题也有点兴趣 :)。如果是这样，你应该考虑加入我们！以下是我们认为你会喜欢和我们一起工作的另外一些理由：

• 人们喜欢使用 Cursor。 我们对自己的早期增长势头非常满意。

• 你会在这里和非常聪明的人一起工作。 我们非常相信“高人才密度”。你在这里合作的每一个人都非常非常优秀。

• AI 编码是一个巨大的市场。 而且我们有机会赢得这个市场。

• 这件事本身就很好玩。 这对我们非常重要！和你喜欢的人一起工作很开心，打造一个产品、按下 Cmd-Shift-R 就能立刻获得用户反馈也很有趣，因为当你自己在写代码时，你就是目标用户；而且每天都能在“把编程中所有无聊的部分自动化掉”这件事上前进一小步，也很有成就感。

• 我们会非常拼。 能够解决这些问题，我们觉得非常幸运，也享受为了解决它们而全力以赴的过程。