更新：我们还写了更多问题。

一份未排序的简短、具体问题清单：

• 更好的上下文： 在代码编辑器中有大量信息来源：已打开的文件、语义相似的代码片段、符号关联的类、lint 输出、执行追踪、git 历史、键入历史、外部文档，等等。我们希望模型能够即时理解对用户问题最相关的内容，当前正训练一个自定义且高速的重排序模型来解决这个问题。对于每个请求，我们会从各类来源汇集 500k 个 token，并使用我们的重排序器将其过滤到最相关的 8k 个 token。这个问题既是模型层面的，也是（而且越来越多地）基础设施层面的问题。
• “编辑协作助手”：GitHub Copilot 在编写新代码时能极大减少低熵按键，但当你需要对现有代码块进行小而简单的修改时，它并不能帮助你同样地节省这些低熵操作。想想重命名这种仅比按下 F2 进行符号重命名稍微复杂一点的场景中，你需要的光标移动、删除与输入按键。我们在 UX（在你编码时以不打扰的方式展示 diff）和模型侧都需要创新（仅靠提示不够，因为存在成本、延迟与智能上的问题）。
• 受约束的、顺序执行的代理：可把它理解为用于大型代码库工程化的 OpenAI code interpreter。你向一个受约束、少步数的代理下达指令，它会为你搜索、编写并运行代码，并且会不时征求你的反馈。实现这一点的第一步（我们正在进行）是打造一个可在几十万 token 级别的文件夹上工作的代理。如果这一步成功，我们将把它扩展到覆盖整个代码库。
• 缺陷定位： 这里有两种模式：(1) 在后台，Cursor 会持续被动扫描你的文件，为你发现潜在缺陷；(2) 当你深入调试时，Cursor 会在你的协助下主动定位缺陷。这里有大量值得开展的有趣数据收集工作。
• 更大范围的编辑：Cursor 应该能够替你修改整个文件，甚至整个目录。这在能力与用户体验两方面都是挑战。为提升速度，模型需要足够聪明地只挑出需要修改的部分，而不是重写全部内容。为确保良好的体验，变更需要以可解析的实时形式展示。
• 规模：截至 2023 年 10 月 12 日，我们已索引 14 亿个向量和 15 万个代码库。到年底这可能会增长 10 倍。我们已经用 Rust 构建了一个非常快速的基于 Merkle 树的代码库同步引擎，且很可能很快需要构建一个自定义索引系统。

未来构想：

• Time warp：预测并展示你在接下来的 15 分钟内将进行的跨文件代码更改。按下一个快捷键即可接受所有插入/删除。
• 理解：我们的模型应在其权重中深度掌握任何代码库中的所有概念。
• 阅读模式：借助可按任意细化程度呈现的文档与引导你浏览相关代码路径的智能助手，让理解代码变得轻而易举，并在需要时提供讲解。
• 伪代码模式：编辑代码的“纲要”表示，并将更改自动应用到源代码层。
• 再也不为堆栈追踪烦恼：IDE 应该直接理解问题，并为你自动修复代码。

我们尝试把当下正在思考的所有问题都汇总起来。不过——这也是每天用上自己产品 12 小时的美妙之处之一——我们不断会冒出新想法并调整优先级，所以这不应被视为一份面面俱到的路线图。话虽如此，我们希望它能让你了解我们每天把大脑算力花在了哪些事情上。

另外，你已经读到这里了，看来你对我们关心的问题也挺感兴趣 :)。如果是这样，欢迎加入我们！以下是我们认为你会喜欢与我们一起工作的几个理由：

• 大家喜欢使用 Cursor。 我们对最初的增长表现感到非常满意。
• 你将在这里与非常聪明的人共事。 我们坚定相信高人才密度。你在这里合作的每个人都将非常非常出色。
• AI 编码是一个巨大的市场。而我们有能力赢得它。
• 这很有趣。 这对我们来说非常重要！和喜欢的同事一起工作很有趣，构建一款产品也很有趣：你按下 Cmd-Shift-R 就能立刻获得用户反馈，因为在编码时你自己就是目标用户；而且，每天都能朝着把编程中所有无聊部分自动化推进一点点，这也很有趣。
• 我们全力以赴。 能有幸投入到这些问题中令我们倍感幸运，我们也乐于尽其所能去解决它们。