Cursor：AI编程工具的崛起与未来

编辑：佳琪、蛋酱

最近，AI编程工具Cursor在全球范围内引发了广泛关注，成为热门话题。

这款基于VS Code的代码编辑器为人工智能辅助编程注入了强劲的功能，吸引了编程界和AI领域的极大兴趣。

不久前，著名播客主持人Lex Fridman与Cursor团队的四位成员进行了深入的技术讨论，分享了他们的探索进展及未来方向。

视频链接：https://youtu.be/oFfVt3S51T4?si=pCvBgWm5X-W8xt4n

以下是Lex Fridman与Cursor创始成员Michael Truell、Sualeh Asif、Arvid Lunnemark和Aman Sanger的对话精华，由机器之心进行了整理：

Cursor的起源

那么，Cursor的诞生故事究竟是怎样的呢？

技术进步与未来愿景：Cursor的启示

在2020年左右，OpenAI发布了关于缩放损失的新论文。此时，整个领域似乎在预测性进展上迈出了显著一步。尽管当时我们没有更多的想法，但显然，拥有更多的计算能力和数据能显著提升模型的表现。

顺便提到，关于缩放损失这个主题，我们可以深入探讨三到四个小时。然而，简单总结一下，这篇论文是众多相关研究中的一部分，提出了一个观点：在机器学习的世界里，模型和数据的规模越大，效果就越理想。

确实，模型越庞大，表现通常也越佳，但这一点并不总是显而易见。这实际上是一个值得进一步讨论的话题。

是的，这确实是一个值得深入探讨的新话题。

在那个时期，我们中的一些人进行了大量的概念讨论：这项技术的未来会是什么样子？对于各类知识工作者而言，技术的进步将如何提升他们的工作效率？随着时间的推移，那些理论上的收益逐渐变得非常具体，我们意识到，如果想在人工智能领域有所作为，实际上无需攻读博士学位，完全可以直接动手，这样就能够建立起一套真正有用的系统。

接下来，一个重要的时刻是我们提前获得了GPT-IV的使用权限。大约在2022年末，我们开始对这一模型进行调整，提升其能力，感觉其强大的能力令人振奋。在此之前，我们一直在进行多项项目。由于Copilot、缩放损失的研究，以及我们对这项技术的浓厚兴趣，我们在为程序员开发工具，但这些工具的应用非常具体。因此，我们还为需要在Jupyter Notebook中工作的金融专业人士，或希望进行静态分析的用户，构建了相应的工具。

而GPT-IV的升级让我们感受到，之前的理论收益确实得到了验证。那个时刻，我们意识到可以立即开发出更多的应用。如果我们继续保持一致，这不仅仅是一个点状的解决方案，而是许多编程活动都将依赖于这些模型，形成不同类型的编程环境和方式。因此，我们开始构建一个更加宏大的愿景。

代码的演变

重塑代码审查体验：智能模型如何改变编程方式

Cursor 具备一种引人注目的功能，那就是其差异（diff）接口的整体表现。通过红色和绿色的标记，模型清晰地展示了代码修改的方式。用户可以在聊天窗口中直接应用这些修改，并查看差异，选择是否接受。

我们大致设想了四到五种差异展示方式。特别是为了优化自动完成功能，我们调整了差异接口，使其在处理较大代码块时表现出色。此外，我们也在探索新的差异功能，以便更好地应对多个不同文件的情况。从整体来看，使用自动完成功能时，读取速度应当极快。虽然在各种情况下都要促进快速读取，但在自动完成的场景中，用户的注意力会高度集中，无法一次性处理过多信息。

经过多次尝试后，我们终于让这一功能正常运作。最初，我们使用蓝色划线来标识需要删除的代码，这种方式曾以 Google Docs 风格呈现，用户可以看到被划掉的旧代码和新的替代品，然而，这种展示方式容易导致分心。因此，我们进行了多次实验，尝试了不同的删除方式和红色突出显示。

在下一个迭代中，情况变得有趣起来。用户在 Mac 上按住选项键时，特定代码段会被高亮，展示出可能的修改建议。在这种情况下，输入和返回值均会变成蓝色，意在提醒用户人工智能提出的建议。用户若想查看这些建议，只需按住选项键，释放后则可见原始代码。

无疑，这是用户体验设计领域极具吸引力的一部分。我们的目标是有效引导程序员获取所需的信息，这就是我们努力追求的最佳效果。

实现这一目标的关键在于智能模型。目前的算法与传统算法并无太大区别，缺乏智能化。虽然算法设计需要某种程度的智能，但用户并不关心具体的实现方式，他们希望模型能够高效完成任务。

随着模型智能程度的提升，能够提出的修改建议也将越来越多。因此，伴随这些变化，人类需要承担更多的审查工作。

程序员并不希望将所有时间投入到代码审查上。我认为，语言模型的应用可以显著改善审查体验，例如，某种技术可以帮助用户聚焦于真正重要的部分。此外，如果代码是通过这些语言模型生成的，而非由人类编写，那么审查体验将更为优化。此时，审查者的体验需要被优先考虑，使得整个过程尽可能有趣、轻松和高效。

机器学习的深入探讨

在使用 Cursor 编辑器时，我感受到了一种接近通用人工智能（AGI）的体验。能否分享一下支撑其运作的机器学习细节呢？

Cursor 的运行依赖于我们所训练的定制化模型与前沿技术的综合体。许多备受欢迎的功能，如 Tab 和 Apply，正是通过微调实现的。

这些前沿模型在生成代码修改建议和草稿方面表现出色，但在处理具体代码改动时，尤其对于大型文件（如 Sonnet 和 o1）时，往往会出现低级错误，比如序列混乱。

因此，我们采用了一种新策略：首先生成一个初步的代码块，以简要说明所需的修改；然后，训练另一个模型将这些建议实际应用到文件中。

顺便提一下，Apply 功能会分析代码并提出新的修改建议。虽然对人类来说，代码的调整似乎相对简单，但对模型而言，这个过程却并非易事，是不是？

很多人可能认为 Apply 的算法是基于“确定性”的，也就是说有一套固定的规则，但实际上并非如此。

确实，其他AI编程工具也提供类似的Apply功能，但它们常常会出现崩溃的情况。许多人以为仅靠确定性匹配就能实现这些功能，然而，现实是至少有40%的情况会失败。

总体来看，模型的智能水平将不断提升。而 Apply 功能的一个显著优点在于，它能够让最先进的模型在生成代码时，使用更少的 tokens，从而有效降低延迟和成本。

具体而言，你可以给模型提供一个大致的代码框架，接下来则由模型进行详细的实现。与让模型从头开始编写完整代码相比，提供一个粗略的草图让模型去细化显然更为简便。我坚信这一趋势将继续演化，随着规划模型的智能化程度不断提高，具体实现的复杂性可能会交由相对简化的模型来负责。或许未来会出现更高级别的模型来制定高层次的规划，而定制模型则负责逐步执行这些任务。

如果你对此感兴趣，我们可以交流一下如何加速这一过程。

那么，提升 Cursor 处理速度的具体方法是什么呢？

加速的一个关键在于“投机编辑”，这一概念源于投机解码。利用投机解码的好处，在大多数情况下，尤其是当语言模型的生成受限于内存时，同时处理多个 tokens 通常比逐个生成更为快速。因此，当你观察每秒生成的 tokens 数量时，会发现处理提示 tokens 的速度明显快于逐一生成的效果。

我们的方法与传统的投机解码有所不同。传统方式是利用一个较小的模型进行代码预测，然后由更大模型进行验证。由于我们对现有代码的样式、格式和逻辑拥有足够的理解，因此可以直接将原始代码片段输入模型，让其判断哪些部分需要调整。在绝大多数情况下，模型会认为：“这段代码没有问题，可以直接使用。”

因此，你能够并行处理所有代码行，并对足够多的代码段进行相同的操作。最终，当模型预测生成的文本与原始代码不一致时，它将产生新的 tokens，我们可以根据其匹配程度来决定何时重新对代码块进行推测。

GPT 与 Claude 的对比

在编码方面，哪个大型语言模型更具优势？GPT 与 Claude，谁更胜一筹？

大型语言模型编程能力的评估与比较

在众多大型语言模型中，似乎没有哪个模型能够在所有方面独占鳌头。这表明在我们认定的重要领域中，Pareto模型表现优异。涉及的领域包括响应速度、代码编辑能力、处理大量代码的能力、长上下文理解以及其他相关的编码技能。在我看来，Sonnet模型是目前表现最佳的选择。Sonnet的推理能力非常强大，尤其在面对复杂的编程面试问题或引导代码的任务时，它能够出色地完成这些挑战。然而，它在理解用户意图方面，似乎不如Sonnet那样精准。

如果我们观察其他一些前沿模型，它们在基准测试中的表现确实相当出色。但当我们将它们推向更高的挑战时，我认为Sonnet在保持稳定性能方面更具优势。

那么，标准编程体验与基准测试之间究竟存在哪些差异呢？评估这些模型时，基准测试又有哪些不足之处呢？

这是一个复杂而重要的细节，揭示了基准测试与真实编码之间的差别。真实编码并非只是面试中常见的编程题。人类有时会表达得不够清晰，甚至会说：“就照我之前的方式做。”或者可能会说：“加上这个，然后帮我做别的，再制作这个UI元素。”许多情况都依赖于上下文，而抽象的面试问题往往太过具体，过于依赖规范，相较于人类的表达则显得灵活性不足。

在基准测试与实际编程之间，存在着很大的偏差。有时很难总结，因为实际编程环境相对混乱，且很难明确什么是对的，什么是不对的。同时，公共基准测试的问题使得这一过程更加复杂，因为获取这些基准测试数据的难度非常高。

例如，SWE-Bench作为最受欢迎的基准之一，确实受到基础模型训练数据的影响。如果要求这些基础模型解决SWE-Bench中的问题，而不提供代码库的上下文，它们可能会产生错误的文件传递或虚假的函数名称。

在这种情况下，这些模型可能会根据文字描述或拉取请求本身进行训练。或许实验室会在这个领域有所突破，改善模型的表现，或者它们已经在净化这些数据方面做得相当出色。然而，它们绝不应忽视存储库本身的实际训练数据。这些存储库中有许多是最流行的Python库，例如SimPy。我认为他们不会仅仅依赖SimPy和其他流行的Python库来为这些基准测试提供真实的评估分数。

优化模型提示的艺术与实践

在基准测试中发现的不足之处，使得构建系统或模型时，开发者往往会采用一些巧妙的“辅助工具”，以判断其发展方向是否正确。实际上，许多情况下，人们会让用户参与到这些模型的测试中，从而收集定性反馈。特别是在一些基础模型公司，专门的团队负责这类工作。在我们的内部流程中，我们同样进行定性评估，除了依赖于私人电子邮件，评估结果对我们也至关重要。

提示工程的意义

一个有效的提示词究竟能发挥怎样的作用呢？你曾撰写过关于提示词设计的相关博文。

这要视具体使用的模型而定。不同模型对提示的反应各异，例如，GPT-4对提示词非常敏感。然而，当面临信息量有限的情况时，如何筛选出应包含在提示中的信息呢？

为了解决这一问题，我们内部创建了一个名为Preempt的系统。这个系统的设计理念有些像网页制作：无论是在移动设备还是桌面环境中，网页都需良好展示。但需考虑到动态信息的影响，网页设计与杂志排版的固定性是不同的。提示词的输入和网站一样，都是动态的，因此确保格式适应性变得至关重要，尤其是在信息量庞大时，可能需要对内容进行裁剪。因此，我们从网站设计中获得了宝贵的启示。

我们尤其欣赏React及其声明式编程方式。在JavaScript中，使用JSX可以直接声明：“这正是我所期望的，我认为这个部分比其他部分更为重要，优先级更高。”

在网页设计的过程中，渲染工作是由渲染引擎完成的，而在Cursor系统中，这项任务由Preempt渲染器承担，负责将所有内容合理布局在页面上。用户只需描述想要的效果，渲染器便会自动实现。

我们发现这种方法极具实用性，且其功能也在不断发展：最初，它是为了适应较小的上下文窗口，而如今，它在提示词数据的拆分与实际生成中发挥着重要作用。因此，调试过程变得更加简单，用户可以修改提示词并在旧版本上进行测试，直观地看到修改是否真正提升了整体评估的表现。

用 JSX 提升提示词效率的思考

难道你们真的在运用 JSX 来撰写提示词吗？

确实如此！Preempt 的结构让人想起了 React。它拥有一些独特的组件，例如文件组件，能够获取光标的具体位置。在代码编辑器中，光标所在的行通常是最关键的，因为你正在对此行代码进行分析。因此，可以根据不同代码行的优先级进行设置。光标所在的行优先级最高，而与之距离越远的行，优先级则逐渐降低。最终，在渲染过程中，系统会计算出可以显示的代码行数，并围绕光标位置进行展示。

这真是太令人兴奋了！

此外，用户还能实现更复杂的功能。例如，当代码库中包含众多代码块时，可以通过检索、嵌入和按照得分重新排序等方式，为这些组件设定不同的优先级。

那么，在提问时，人类是否也应尝试这种方法呢？在提示中使用 JSX 是否会带来好处，或是随意提问的方式更为有效？

我认为我们应当追求的目标是，用户能够自由提问，而我们的职责则是找到合适的方式来检索出与用户意图相关的信息。

我曾和 Perplexity 的首席执行官 Aravind Srinivas 讨论过这个话题，他认为提问者越懒越好。这种观点非常有趣，但我认为对于程序员来说，应该可以有更高的期望，对吧？

确实如此。如果你说「随意提问」，人们往往会变得懒惰。这就形成了一种矛盾：一方面，人们可以随意提问，另一方面又鼓励他们在提示词中表达更深层次的思考。

我的看法是，尽管 AI 已经变得相当智能，但仍然无法传达足够明确的意图来指导模型的行为。可以通过几种方式来解决这种不明确的意图问题。一种方式是让模型询问用户：「基于你的查询，我对某些部分不太确定，你能否进一步明确一下？」另一种方式是，如果存在五六种潜在的生成方式，「考虑到当前查询的不确定性，我们可以将这些生成的结果一并展示给你，由你来做出选择。」

模型主动提问的挑战与上下文处理的复杂性

模型在主动提问方面的难度到底有多大呢？

最近，我们为Cursor引入了一项新功能，允许用户添加文件。在编辑代码或进行内容输入时，模型会尝试预测用户的意图。如果模型感到不确定，它可能会推测你正在编写某种API。接着，它将查阅用户的历史记录，以判断哪些文件与当前的编辑内容最为相关。

在这里，存在一个技术性难题：如何在众多历史记录中筛选出相关信息，以识别当前提示词下最重要的文件。尽管这一功能仍在开发阶段，但我们坚信会不断完善。我们希望能够引导用户思考：“你是否想要添加这个文件或那个文件，以便模型能够协助你进行编辑？”

例如，假设你正在开发一个API，同时还需要调整使用该API的客户端和服务器端代码。那么，当API发生更改时，客户端和服务器端的代码也必须随之更新。

Cursor的能力在于，当你正在输入提示或代码时，在按下“回车”之前，模型能够协助你识别出需要同时修改的部分。这种做法的好处在于，能够提前消除一些不确定性，以确保所有相关代码都得到适当更新，而无需手动查找和同步这些更改。

上下文的挑战

谈及上下文，当我用Python编写代码时，通常会导入许多模块。如果想要准确识别我在上下文中需要包含哪些内容，自动识别这一过程有多困难？

这一问题确实相当棘手。我相信未来在自动计算上下文方面我们能够取得更大的进展。但需要注意的是，自动上下文的引入是有代价的。

首先，模型中包含的上下文越多，其处理速度就越慢，同时请求的成本也会增加，这意味着你可能需要减少模型的调用频率，并减少后台复杂操作的执行。此外，对于许多模型而言，如果提示信息过于冗杂，它们可能会感到困惑。因此，所包含上下文的准确性和相关性标准必须非常高。

在我们的产品中，已开始实施某种程度的自动化上下文处理。这是我们希望进一步改进的领域。我们有许多创新的构想待探索，例如开发更高效的检索系统，包括优化嵌入模型与重排序器。

同时，我们也在内部尝试一些有趣的学术概念。是否能够将语言模型提升到一种境地，使其能够自我理解新的信息资源？更进一步，如果上下文窗口能够无限扩展，模型是否能够在这种情况下真正关注无限的上下文？在实现这一点之后，能否让模型对这些无限的上下文进行有效的缓存，而无需每次都重新计算？此外，还有一些创新的想法正在探索中，这些想法更倾向于在模型权重层面上进行微调，以便让模型实际学习新信息。如果在权重上进行更深层次的操作，而非仅仅在上下文层面上，那么我们可能会获得一种全新的理解方式。

我们对更出色的检索系统充满期待，尤其是在挑选与当前任务最相关的代码库部分时。一个引人注目的概念是利用 VS Code 在权重中直接学习这些知识。因此，我们在 VS Code 的分支中进行实验，所有代码均为公开可用。这些预训练模型已接触到所有相关代码，甚至包括与其相关的问题和答案，并通过微调和强化学习进行优化，以便能有效回答代码相关的问题。虽然在询问 VS Code 相关问题时，模型有时会产生错误，但在某些情况下，它的回答也是相当准确的。如果我们能专门训练或后续训练出一个模型，专注于理解这个特定的代码库，结果会如何呢？

这无疑是一个开放的研究课题，引发了我们的浓厚兴趣。此外，另一个待解答的问题是，您希望模型是一个端到端的解决方案，能够在内部完成检索、回答问题以及生成代码，还是希望将检索功能与先进模型分开？也许在不久的将来，我们会看到一些性能优于现有开源模型的强大新模型。在这种情况下，一个优秀的开源模型可以专门用作检索器，将上下文输入到更大型的模型中。

关于训练模型如何理解代码库的问题，我们可以进一步展开讨论。这是否指向合成数据的方向？

确实，有许多方法可以进行尝试，构思几乎是无穷无尽的。关键在于实施各种方法，并通过实践来判断其有效性。一个初步的想法是模仿 VS Code 及其前沿模型的做法。我们可以继续进行预训练，进行一种持续的预训练，包含一般代码数据，同时引入特定存储库的数据。在后续训练阶段，我们可以从指令微调开始，使用针对代码的标准指令微调数据集，并在该存储库中提出大量与代码相关的问题。

因此，我们可以获取基础的事实数据，这一过程可能颇具挑战，或者我们还可以利用合成数据来执行您所提及的操作，让模型针对不同的代码片段提问。通过这种方式，我们可以获取特定代码片段，并提示模型对其提出问题，将这些问题整合为指令微调的数据点。这理论上将开启模型回答关于特定代码库问题的能力。

探讨 OpenAI o1：未来编程的关键角色

关于 OpenAI o1，大家有什么看法呢？这种能够在测试中进行计算的系统将如何影响编程的未来呢？

在涉及预训练模型时，Scaling law 显示出显著效果。然而，目前我们面临着“数据壁垒”的挑战。因此，提升模型性能的一种有趣策略是增加推理过程中使用的浮点运算次数。传统上，我们必须通过训练更庞大的模型来提升浮点运算能力，而现在我们或许能够在相同规模的模型上通过延长运行时间，来实现大型模型所具备的质量。

还有一点非常值得关注的是，某些问题可能需要一个具备 100 万亿参数并训练了 100 万亿 tokens 的超大型模型来解决。然而，这类问题可能只占总体查询的 1%甚至 0.1%。那么，是否值得为了极少数的查询消耗如此庞大的计算资源去训练一个成本高昂的模型呢？这样的做法似乎显得有些奢侈。

所以，或许更合理的方案是，构建一个可以处理 99.9% 查询的模型，而对于那些需要极高智能的问题，则可以在推理过程中延长运行时间，以获取更优质的答案。

假如你要开发一个能够与 o1 竞争的模型，你会如何着手呢？

其中一个必须完成的任务无疑是训练一个“过程奖励模型”。

或许我们可以进一步探讨“奖励模型”、“结果奖励模型”与“过程奖励模型”之间的差异。结果奖励模型是传统的语言建模奖励机制，仅关注最终输出，例如在解决数学问题时，只有回答正确才能获得相应的奖励。

过程奖励模型的探索与应用前景

过程奖励模型旨在对“思维链”中的每个环节进行评估。去年夏天，OpenAI发布了一篇研究论文，利用人工标注者创建了一个包含数十万条“思维链”数据的庞大数据集。至今为止，除了在样本选择方面，关于过程奖励模型的其他潜在应用尚未显现。

结合过程奖励模型进行“树搜索”（tree search）的想法，的确引人入胜且充满期待。如果能够为“思维链”的每一步进行评分，便能实现分支探索，从而对多条思维链路径进行评估，并利用过程奖励模型对每条路径的有效性进行考量。

OpenAI曾透露，他们选择隐藏模型的“思维链”，并指出这是一个艰难的决定。他们决定让模型对思维链进行总结，而非直接展示给用户。同时，OpenAI在后台监控这些思维链，以确保模型不会误导用户。你对这种隐藏思维链的做法有何看法？

我对OpenAI做出这一选择的猜测是，他们可能不希望外界轻易提取出模型的能力。如果能够看到隐藏的思维链，复制这种技术的难度会降低，因为可以清晰地了解模型在获得最终结果时所采取的每一个步骤，这无疑是极为重要的信息。

那么，是否可以基于这些信息训练新的模型呢？

类似的情况在过去也曾发生，虽然这些也只是猜测：早前，这些API能够方便地提供生成tokens及提示tokens的对数概率，但该功能后来被移除。我的猜测是，这背后的原因在于，如果能够获取这些对数概率，无异于窥见隐藏的思维链，这将使得从这些API和大型模型中提炼出其能力变得更加容易，并将其迁移至自己的模型中。

另外，补充一下我们之前关于整合o1模型的讨论：我们目前依然在摸索如何有效使用这个模型。因此，我们决定将o1整合到Cursor中，因为一获取到这个模型便迫不及待想要尝试，相信许多程序员也会对此充满兴趣。

需要指出的是，o1并不构成Cursor默认体验的一部分，我们至今尚未找到一种方法，能够在编辑器中每天甚至每小时持续使用o1。因此，我认为关于如何最佳利用o1的方式尚未有明确结论。目前，我们也尚未见到具体展示其实际应用的案例。虽然有一些显而易见的方向，比如它有可能简化后台任务的运行，或使模型在循环中运作，从而赋予其代理能力，但我们仍在不断探索之中。

首先，我们确实拥有一些构思，但在公开之前，我们必须确保这些构思切实可行，能够为用户带来真正的价值。

然而，o1也存在一些显著的短板。首先，它的能力尚待提升，尤其是它不支持流式输出，这就导致在监督输出时相当不便，用户必须等待整个文本一次性呈现。此外，这种情况让人感觉o1更像一个初级版本，类似于v0阶段，很多功能依然需要改进。我认为，在增加预训练数据量、扩大模型规模的同时，还需要探索更多的预训练技巧来持续优化搜索功能。

最近有传闻称，GitHub Copilot可能会某种程度上整合o1。对此，有评论者提出：“这是否意味着Cursor的终结？”对此，大家有什么看法呢？

也许是时候考虑关闭Cursor了。

毫无疑问，Cursor确实到了需要关闭的时刻。

你们真的认为是时候结束Cursor的运营了吗？

我认为，当前的技术领域与2010年左右的软件行业相比，已发生了显著变化。如今，技术的上限非常高。我相信，若再过3到4年，最优秀的人工智能编程工具将会比现在更加实用。

当然，关于护城河、品牌和竞争优势等话题总是可以讨论的，但如果在产品创新上停滞不前，最终将被市场淘汰。这对初创企业和想要加入这个领域的新玩家来说是个好消息，只要能够推出更优质的产品，就有机会超越那些已经拥有庞大用户群的竞争对手。因此，我认为未来几年内，关注产品和系统的优质打造至关重要，这不仅涉及模型引擎的提升，还包括编辑体验的优化。

确实如此，我认为Cursor相较于其他产品的独特之处在于其不仅能够迅速整合像o1这样的新模型，更为重要的是，Cursor的定制模型在多个方面为用户提供深入的支持。这些模型可能在用户未察觉的情况下默默运作，每个功能都经过精心设计，以提升用户体验。