更新：我们撰写了关于更多问题的文章。

一系列简短、具体的待解决问题

• 更好的上下文理解： 代码编辑器中有许多信息来源：打开的文件、语义相似的代码块、符号连接的类、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 小时的产品的美妙之处之一——我们不断有新的想法并重新确定优先级，因此这不应被视为最终的路线图。 也就是说，我们希望它能让您了解我们每天花费脑力在哪些方面。

另外，您阅读了很远，所以您似乎很可能对我们感兴趣的问题感兴趣 :)。 如果是这样，您应该考虑加入我们！ 以下是我们认为您会喜欢与我们一起工作的其他几个原因

• 人们喜欢使用 Cursor。 我们对最初的增长感到非常满意。
• 您将在这里与真正聪明的人一起工作。 我们深信人才密度。您在这里合作的每个人都会非常优秀。
• AI 编码是一个巨大的市场。 我们可以赢得它。
• 这很有趣。 这对我们来说很重要！ 与您喜欢的人一起工作很有趣，构建一个您按下 Cmd-Shift-R 即可获得即时用户反馈的产品很有趣，因为您自己在编码时就是目标用户，并且每天朝着自动化编程所有无聊部分的方向迈进一小步也很有趣。
• 我们努力工作。 我们很幸运能够解决这些问题，并且我们喜欢全力以赴地解决它们。