Cursor团队揭秘：如何在短短两小时内挑战微软的火爆AI编程应用！

共计 29208 个字符，预计需要花费 74 分钟才能阅读完成。

探索 Cursor：初创团队如何在 AI 编程领域崭露头角

智东西（公众号：zhidxcom）
编译 | 尹明顺吴浪娜
编辑 | 漠影

根据智东西在 10 月 10 日的报道，知名播客主持人 Lex Fridman 于 10 月 7 日与 Cursor 创始团队的四位成员 Michael Truell、Sualeh Asif、Arvid Lunnemark 和 Aman Sanger 展开了一场长达两个半小时的深入交流。

Cursor 是一款基于 VS Code 开发的代码编辑工具，凭借其众多强大的 AI 辅助编程功能，迅速引发了编程及人工智能社区的广泛关注。那么，作为一家初创公司，Cursor 又是如何与科技巨头微软旗下的 Github Copilot 抗衡的呢？

在播客中，几位嘉宾深入探讨了 Cursor 团队的现状及未来方向，同时也对编程的未来进行了广泛讨论，阐述了人类与 AI 在设计和构建复杂系统方面的合作潜力。

团队成员在交流中分享了 Cursor 如何解析代码库，从而预判用户的下一步需求，并以令人惊讶的速度生成代码，有效提高了编程的效率。

他们还进一步介绍了 Cursor 的多种功能，不仅能够自动完成代码，还引入了影子工作区来辅助编写代码，并通过简单的描述指令让 AI 完成更复杂的编程任务。

此外，团队成员还对 AI 编程的技术细节进行了深入探讨，讨论了人类与 AI 在编程过程中的伦理问题，并提到了将 OpenAI 的 o1 模型整合到 Cursor 中的愿景。

值得注意的是，团队成员强调了“快速就是有趣”（Fast is Fun）的理念。吸引人们在计算机上创造新内容的原因之一是迭代速度的惊人，而在其他领域或许会面临资源和能力的限制，但在编程的世界里，只要有你和计算机，就能够迅速构建出令人惊叹的作品。

在创始团队中，Aman Sanger 担任 Cursor 的首席执行官，他不仅是一名工程师，还具有企业家的背景。此前，他在 Instagram 和 Facebook 担任过高管职位。公司的首席技术官 Arvid Lunnemark 同样是一位优秀的工程师，之前曾在 Spotify 和 Google 工作。设计主管一职由 Michael Truell 负责，而 Sualeh Asif 则担任首席运营官。

▲播客现场展示 Cursor 团队（

以下是对该播客内容的详细整理（为提升可读性，智东西调整了部分问答的顺序，并在保持原意的基础上进行了适度的增删修改）。

Lex：代码编辑器的作用是什么呢？

Michael：代码编辑器是用于软件开发的重要工具，历史上它被视为一种对编程语言进行文本编辑的场所。如今，对于非程序员而言，可以将其视为程序员更加高级的文字处理器。之所以称之为“增强版”，是因为代码具有多层次的结构。因此，这种“文字处理器”实际上可以执行许多传统文字处理器无法完成的任务。

这包括为代码的不同部分提供视觉上的识别，以便快速浏览；在代码库中实现导航，便于直接跳转到当前内容的定义，就像网页中的超链接一样；同时，还能进行基础错误检查，帮助捕捉常见错误等。传统上，这就是代码编辑器的基本功能。我相信，随着软件构建方式的演变，未来十年内代码编辑器的定义会有显著的变化。

Lex：我认为代码编辑器应该具备趣味性。

Arvid：确实，这一点至关重要。这实际上是我们在选择构建什么时一个被低估的因素。我们开发的许多功能，通过实际使用和实验，最终因为缺乏趣味性而被舍弃。因此，趣味的一个重要方面就是速度，快速的过程本身就是一种乐趣。

Michael：我认为，许多人愿意在电脑上进行创作，恰恰是因为这种令人惊叹的迭代速度，而在其他领域，资源或能力往往会限制我们的创造力……即使是将一大群人聚集在一起进行编程，这也是一件不可思议的事情，而只有你和计算机时，你却能迅速创造出非常酷的作品。

Lex：对于那些不太了解的人，Cursor 是一个非常出色的新编辑器，它基于 VS Code 进行开发。我很期待你们分享自己在编辑器道路上的经历。我相信你们都对 VS Code 和 Copilot 非常热爱。你们是如何首次接触到 VS Code 的？这又是如何引导你们走向 Cursor 的呢？

Aman：我们最早都是忠实的 Vim 用户，完全没有使用 Neovim，只有传统的 Vim 和终端。至少对我而言，在 2021 年 Copilot 推出时，我迫切想要尝试它。因此，我开始使用 VS Code，因为那是唯一支持 Copilot 的代码编辑器，尽管我依然非常喜欢 Vim 的使用体验，但 VS Code 与 Copilot 的结合让我忍不住想要转变。因此，这成为了我的主要选择，直到我们开始了 Cursor 的开发。

Lex：或许应该对 Copilot 的功能做个简单介绍。它是一款出色的自动补全工具。当你开始编写代码时，它会提供一到三行的建议，这种体验非常有趣。就像你有个亲密的朋友会帮你接下去说的话一样。当它表现出色时，确实会让人感受到一种亲密感。虽然“亲密”这个词未必完全准确，但确实有种“哇，它懂我”的惊喜。然而，当它无法理解你的意图时，就会产生一些小摩擦。不过我想说，很多人觉得“它懂我”的时刻远远超过了“它不懂我”的体验。

Arvid：我觉得 GitHub Copilot 被低估的一点是，尽管它有时会犯错，但也并没有那么糟糕。只需再输入一个字符，或许它就能更好地理解你，或者再试一次，它可能会更准确。因此，即使它出现了错误，情况也不会太糟糕。

Sualeh：你可以不断进行迭代和调整。对我而言，Copilot 被低估的另一个方面是，它是第一个真正意义上的人工智能产品，首个面向消费者的语言模型产品。

Lex：因此，Copilot 几乎可以被视作语言模型领域的首个杀手级应用。

探索 Cursor 的起源与 AI 的未来

Michael：没错，Cursor 的测试版于 2021 年正式推出。

Lex：那你能否分享一下 Cursor 的起源故事呢？

Michael：大约在 2020 年，OpenAI 发表了一篇关于规模法则的论文。这一时刻十分关键，标志着该领域取得了清晰而可预见的进展。尽管我们并没有新的创意，但似乎只需增加计算能力和数据量，模型就能变得更加优秀。

Lex：顺便提一句，关于规模法则，我们可能需要花费三到四个小时来深入探讨。不过简而言之，这篇论文是众多相关论文中的一篇，提出了一个观点：在机器学习中，模型和数据的规模越大，效果越佳。

Michael：在那段时期，我们中的一些人进行了许多概念上的讨论，探讨这项技术将如何帮助各领域的专业人士提升工作效率。随着论文中所预测的理论进展开始具象化，大家逐渐意识到，实际上可以在人工智能领域进行有意义的工作，而无需攻读博士学位。我们感觉有能力构建一整套实用的系统。

我认为第一次重要的时刻是我们体验 Copilot 的早期版本，那种感觉令人振奋且神奇。

第二个关键时刻则是在 2022 年底我们获得了 GPT- 4 的早期访问权限。那时我们开始调整这个模型，能力的提升让人感到惊叹。在此之前，我们一直在研究一些不同的项目。由于 Copilot、规模法则以及我们对该技术的兴趣，我们不断改进程序员的工具，但这些工具多是针对特定需求的。

我们为需要在 Jupyter Notebook 上工作的金融专业人士开发工具，或尝试使用这些模型进行静态分析。GPT- 4 的升级使我们确信，之前的理论预见得到了验证。那一刻，感觉能够迅速创建许多应用。而且，如果我们保持这种趋势，这不仅是解决某一特定问题的方案，而是将彻底改变整个编程领域，所有的编程工作都将借助这些模型进行，这促使我们思考一种全新的编程环境和方式，从而开始构建更宏伟的愿景。

Sualeh：有一件事情让我印象深刻，我的室友是一位国际数学奥林匹克金牌得主。在美国，有个名为 Putnam 的比赛，类似于大学生的国际数学奥林匹克，也是一项精彩的数学竞赛。我记得在 2022 年 6 月，Shengtong 和 Aman 打了个赌，看看他们能否在 2024 年 6 月或 7 月的 IMO 中获得金牌。

Lex 提到，IMO 代表国际数学奥林匹克竞赛。

Sualeh 回应道，尽管他与 Arvid 也参与了其中，心中对进步有一定信心，但他认为 Aman 的追求 IMO 金牌的想法未免太过天真。诚然，他之前的看法是错误的，而这也许是团队中最具前瞻性的赌注。

Aman 说，他清晰地记得与 Michael 的一次对话，那时他尚未深入思考“缩放法则”。Michael 提出了一个问题：为何缩放法则可能是你所需的一切？或者，究竟为什么缩放法则不一定能带来显著的进步？我想我经历了悲伤的五个阶段，最终接受了这个事实。

他接着表示，从那时起，他对进步充满了希望与乐观。他补充说，进步的领域也至关重要。数学，特别是在形式化定理的证明方面，是一个出色的领域，因为它能提供有效的信号来验证事物的准确性。因此，像强化学习这样的技术可以非常成功。他认为，尽管在数学领域可以获得超越常人的系统，但在技术层面上仍未实现 AGI。

Lex 接着谈到了 Cursor。

Michael 表示，开发一个编辑器的决定对他们而言似乎是自然而然的选择。这是因为他们希望通过这些模型的持续改善，彻底改变软件构建的方式。他们相信，这不仅会显著提升生产力，还会根本性地改变软件开发的方式。若仅作为现有编程环境的插件，他们在代码编辑器方面将遭遇诸多限制，因此他们希望不受这些束缚，创造出最有价值的产品。

Lex 追问道：Cursor 是否在某种程度上与 Copilot 竞争，你们的胜算在于速度与功能的质量吗？

Aman 回应说，这个领域相当有趣，甚至独特。回顾以往的技术浪潮，通常只有一项主要创新会带来一波新公司。而每当模型能力提升时，便会开启一系列新的可能性，尤其是在编程领域。

因此，我认为，在 AI 编程中，即便只领先几个月，甚至一年，都会让你的产品变得更具价值。我预见一年后的 Cursor 会让今天的 Cursor 显得过时。他认为，微软在这方面做了许多出色的工作，但与初创公司相比，他们在继续推动创新和发展的空间上显得有限。

Cursor 的未来：创新与挑战的交汇点

Sualeh 表示，他并不确定该从功能性还是程序员的能力来分析这个问题。随着新的 o1 模型的推出，未来将会出现更多种类的模型，可能会具备更长的上下文能力，甚至更快的响应速度。他充满期待地希望尝试各种新奇的想法，期望其中 10% 的创意能够转化为有趣且实用的成果。他强调，值得注意的是，我们正在为自己创造一个崭新的未来。

当开始开发 Cursor 时，Sualeh 感到了一些挫折。他注意到虽然模型的性能在不断提升，但 Copilot 的用户体验却没有实质性的变化。令人困惑的是，为什么一些技术团队在取得如此高的成就后，依然没有推出新的创新功能？那些令人期待的 Alpha 功能究竟在哪里呢？如果新功能能够问世，他坚信这将是一个极具潜力的商业机会。他对尝试新技术充满热情，但令人失望的是，在相当长的一段时间内，市场上并没有涌现出新的产品。

Lex：当你将 Cursor 与 Copilot 进行对比时，Copilot 很快就显得有些过时了，这似乎是一个无法忽视的事实。

Arvid：是的，我认为我们的一大优势在于，我们将所有相关工作整合在一起。在提升用户体验的同时，也在探索如何改进模型的回答质量。这样一来，如何构建提示、如何获取上下文和训练模型就显得尤为重要。我认为，这使得我们能够让同一团队负责整个用户体验。

Sualeh 补充道，这就像是 UI 设计师和模型训练师在同一个空间内合作，甚至往往是同一个人。这种密切的合作使得一些创新想法得以实现，否则在缺乏交流和实验的情况下，这些想法可能永远无法形成。

Lex：你们是否利用 Cursor 来开发 Cursor 本身呢？

Arvid 回答说：“当然可以。”

Lex：让我们来探讨一下功能强大的 Tab，实际上它是增强版的自动补全。那么，Tab 是如何运作的？它的本质是什么呢？

Michael 总结道，Cursor 在两个关键领域表现优异。尽管它具备其他功能，但这两项对于程序员尤为重要。首先，Cursor 就像一个迅速反应的同事，能够在你背后观察，预测你接下来想做的事情。这个强大的自动补全功能不仅限于预测即将输入的字符，还能综合判断你接下来可能进行的整体修改、差异变化，以及需要跳转的位置。

其次，它能帮助你在某些时候先于人工智能，指引它执行特定任务，使指令转换为代码成为可能。为了实现这两项功能，我们在提升编辑体验上投入了大量精力，力求在符合人体工程学的同时，保持智能化和快速响应。

Sualeh 指出，我们的目标是让模型能够有效地为用户编辑代码。这个愿望驱动我们不断尝试，终于在拥有高质量模型后，致力于让使用体验更加流畅。我们努力提升推理速度，并开始进行系统的整合。

Michael 提到的跳转能力，实际上源自于一种直觉：当你完成编辑后，接下来要去的地方应该是显而易见的。例如，完成某个更改后，模型理应知道下一步是跳转到第 18 行。如果你是 WIM 用户，可能会使用像 18JJ 这样的快捷键，但为什么要这样呢？模型应该具备直觉能力。

所以，用户只需按下 Tab 键，就能自动跳转到第 18 行，随后显示下一个编辑建议。不断按 Tab 键，你可以轻松进行操作。内部的竞争在于，我们能让用户按多少次 Tab。一旦你有了这样的思路，考虑的更深层次的问题是，如何使得编辑过程达到零熵状态。

换句话说，当你的意图已经表述并且完成编辑，没有新的信息片段来实现你的想法时，还需要输入字符来让计算机理解你的真正意图。此时，模型理应“读懂”你的心思，所有的零熵都应通过 Tab 键来消除，这种说法虽抽象，但蕴含深意。

Aman 提到，一个有趣的现象是，观察不同领域的语言模型损失时，代码字符的比特数低于语言，这意味着代码中存在大量可预测的 token，很多字符也极具可预测性。而当我们不仅仅是自动补全代码，而是预测用户在现有代码上编辑的下一步时，这种可预测性将被进一步放大。因此，Cursor Tab 的目标是消除编辑器中的所有低熵操作。一旦意图被有效确认，我们就能直接跳转到未来的某个时间点，跨越不必要的步骤。

Lex 最后问道，那么，Tab 在不久的将来应该能实现哪些功能呢？

提升编程体验：从缓存到代码差异显示的创新探讨

Aman 提到，关于这些功能的运作细节，值得深入探讨。其延迟极低，因此在执行这项任务时，需使用小型模型进行训练。特别需要强调的是，这些模型对预填充 token 的需求很高。这意味着它们能够处理较长的提示信息，能够查看大量代码，但实际上生成的 token 却并不多。因此，MOE 模型的使用显得格外合适。这一突破显著提升了模型在处理长上下文时的表现。此外，我们还开发了一种称为投机编辑的投机解码变体，我认为这两个方面是提高质量和速度的关键。

Lex 随即询问：“那么，缓存是否发挥了作用？”

Aman 回答说，缓存的作用是巨大的。处理如此多的输入 token 时，如果每次输入的每个按键都要针对所有传入的 token 重新运行模型，首先将显著增加延迟，其次会导致 GPU 负载过高。因此，必须设计具有缓存意识的模型提示，并且需要在不同请求间重用 KV 缓存，以降低计算负担。

Sualeh 表达了希望：“能否实现文件间跳转？如果在某个文件做了编辑，可能需要转到另一个文件来完成想法，这样的功能是必要的。”

Arvid 补充道，全面的泛化是下一步行动预测。某些情况下，当你在终端运行命令时，模型应该能够建议相应的命令，或者给出建议，但有时判断其正确性很困难，因为需要更多的信息来确认。要验证正确性，了解类型是必不可少的。因此，或许应该先引导你到某个定义的地方，随后再带你回到原处，这样你就具备了接受下一个补全所需的所有知识。

Michael 认为，编程是一门独特的学科，接下来五分钟的任务，实际上是可以基于最近的操作进行预测的。那么，是否能创造一个环境，使得接下来的工作要么在你放手的情况下自动完成，要么在你确认下一步无误后，通过轻触 Tab 键迅速实现呢？

Lex 表示：“Cursor 具有一个非常炫酷且引人注目的功能，就是整个 diff 界面的展示。”模型通过红色和绿色高亮显示我们将如何修改代码，并可以在聊天窗口中应用这些修改，展示出差异，用户可以选择接受这些差异。能否谈谈这个方面的发展方向？

Sualeh 回应道：“我们可能会设计出四到五种不同的 diff 方式。我们已经为自动补全功能优化了 diff，因此它与审查大块代码时使用的 diff 接口有所不同。同时，我们正在尝试优化另一种 diff 功能，以适应处理多个不同文件的需求。从宏观角度看，关键在于，当你进行自动补全时，读取速度应当极快。实际上，所有情况下都应保持高效的读取速度，但在自动补全时，用户的注意力往往集中在特定区域，而人类难以同时关注多个不同的元素。”

提升代码审查效率：智能模型的前景与挑战

在界面设计方面，当前的框架允许用户在删除代码的同时添加新内容。当尝试此操作时，系统会在侧边显示一个提示框。

我们探索了几种不同的实现方案。一开始，我们采用了一种旁边显示带有蓝色删除线的框的方式。这种方法曾模仿 Google Docs 的风格，呈现被删除的代码，并在其上方划过一条线，接着展示新代码，这种方式确实令人分心。之后，我们不断尝试其他方案，比如删除标记和红色高亮等。

在后来的迭代版本中，用户在按住 Mac 的 option 键时，某段代码会被高亮显示，以表明 AI 为其提供了建议。在这个示例中，输入和结果区域都会标记为蓝色，暗示 AI 有推荐内容。该提示并不会直接展现建议的细节，而是让用户知道有一个建议存在。若想查看更多信息，只需按住 option 键，便能看到全新的建议，松开后则恢复显示原始代码。

Arvid：我个人非常期待在这个领域做出显著提升。我们经常提到的验证问题，对于一些小范围的修改来说非常有效。然而，当涉及到大规模修改或多个文件时，审查这些差异就显得相当繁琐。因此，我们可以考虑几种不同的思路。某些差异部分重要且信息量大，而另一些部分则可能信息量较低，存在重复内容。

因此，或许可以通过高亮显示重要内容，而将不那么重要的部分设为灰色。此外，还可以设计一个模型，分析差异并识别潜在问题，比如用红色波浪线标记出来，提示用户“此处差异需重点审查”。这种构想令我感到振奋。

而我们希望借助智能模型来实现这一目标。目前的算法仍然比较基础，缺乏智能化。算法的设计需要具备智能属性，但我们并不在意其具体内容，重点是模型能否有效地完成任务。

Sualeh：我认为一个普遍存在的问题是，随着这些模型愈发智能化，它们能够提出的改动也会越来越复杂。而这些更改的复杂性也意味着人类需要进行更多的验证工作。这使得任务变得更加繁重……我希望能够得到一些帮助，而不是将所有时间都花在代码审查上。

Aman：GitHub 试图通过代码审查来应对这一挑战。在进行代码审查时，用户需要对多个文件中的差异进行审查。然而，正如 Arvid 所言，我认为这方面还有更好的解决方案。代码审查的过程往往比较繁琐，消耗大量时间去理解那些通常不熟悉的代码，且往往无法有效捕捉潜在漏洞。

重新定义代码审查：通过语言模型提升体验

我坚信，运用语言模型能够极大地改善审查过程，例如，借助 Arvid 提到的技巧，专注于那些真正重要的部分。此外，若代码是由这些模型生成的，而非其他开发者创作的……那么审查的体验将会同时兼顾审查者和代码作者的需求。

当代码的创作主体是语言模型时，审查者的体验便成为了设计的核心，能够专注于让审查尽可能有趣、轻松和高效。我认为，若只是单纯试图模仿传统的代码审查方式，这将会导致问题的产生。我们可以更加富有创意，拓宽可能性的边界。

Arvid 还提到，顺序在审查中至关重要。通常，在查看一个拉取请求时，审查者会依次浏览文件列表，但实际上，了解某些部分的逻辑关系是更为重要的，这样才能更好地理解后续内容。理想情况下，我们应该有一个模型来引导这一过程，而不是依赖自身去理清这些逻辑。

我也认为，并非所有的编程活动都能转化为自然语言的表达。如果我与 Sualeh 进行配对编程时，Sualeh 坐在电脑前，有时我会直接告诉他应该实现某个功能。但有时，向他解释我的意图却显得过于繁琐，因此我会直接动手示范。

我会写出一段示例代码，这样他就能迅速理解，这种方式是沟通的最佳选择。我相信，对于 AI 而言，沟通的最有效方式同样是通过展示示例，这样它可以在其他地方进行相似的操作。

在某些情况下，比如构建网站，向 AI 展示需求的最简便方法可能并不是直接告知它要做什么，而是通过拖拽或绘制来表达。或许未来我们会实现脑机接口，让 AI 更好地理解我们的想法。因此，自然语言在某种程度上仍然有其存在的价值，但我确实认为，这不会成为大多数人编程的主流方式。

Lex：在使用这个编辑器时，我感受到了通用人工智能（AGI）的强大潜力，仿佛背后有复杂的机器学习在支撑着它。能否分享一些让其高效运作的机器学习知识呢？

Aman：Cursor 的真正优势在于，我们借助这组定制模型与最先进的模型共同进行训练，这些模型在需要大量推理的任务中表现尤为出色。例如，Cursor Tab 便是一个优秀的案例，你可以专门调整这个模型，使其在某些方面的表现超过现有的前沿模型。此外，Apply 领域令人惊讶的是虽需定制模型，但其必要性不容忽视，并且在实际应用中表现卓越。

这些先进的模型在起草代码结构和生成变化草图方面相当出色，但实际上，对于前沿模型来说，创建训练模型的差异是极具挑战性的。如果尝试用 Sonnet、o1 或其他前沿模型来完成这些任务，往往会在一些简单的操作上出现错误，比如行数的计算，尤其是处理大型文件时。为了解决这一问题，我们让模型勾勒出一个大致的代码块，指出将进行的变更，接着训练一个模型将这些变更实际应用到文件中。

Lex：我们可以说，Apply 模型会分析你的代码，并提出非常有效的新操作建议。然而，表面上看似简单的将这两者相结合的过程，实际上并不容易。

Sualeh：与普遍观点相反，这并不是一个确定性的算法。

Aman：确实如此，在其他地方你可能会看到 Apply 的简化版本，但在大多数情况下，它们并不奏效。你可能会尝试进行一些确定性的匹配，但大约有 40% 的时间会失败，这将严重影响用户体验。我相信，随着模型智能化程度的提升，这种情况还会继续存在。因此，Apply 可以让你用更少的 token 调用最智能的模型，这在生成这些 token 时通常会带来延迟和高昂的成本。

因此，您可以先提供一个非常粗略的草图，并让模型来实现它，因为生成这样一个初步的代码相对容易。我认为这种趋势会持续下去，您可以借助越来越智能的模型进行规划，而实现的细节则可以交给相对简单的模型来完成。或许您可以使用 o1，并且它可能具备更强大的模型来提供更高级的计划，而这个计划可以通过 sauna 递归应用，最后由 apply 模型来实现。

Sualeh：或许我们应该讨论如何提升速度。

Aman：加快速度的一个关键因素是投机编辑。投机编辑可视为一种投机解码的变体。或许在此简要介绍投机解码会有所帮助。在投机解码中，我们可以利用这样一个事实：在大多数情况下，当面临内存限制时，一次处理多个 token 的效率要高于逐个生成 token。

因此，我们的做法并不是像传统投机解码那样，使用小型模型预测草图 token，而是直接在代码编辑中，依靠对现有代码强烈的先验知识，这种先验实际上与原始代码完全相同。所以，可以将原始代码的一部分反馈给模型，通常模型会同意：“好吧，我将直接输出这段代码。”

因此，只要有足够的块，就可以并行处理所有这些行。最后，您会达到一个分歧点，此时模型将预测与原始代码不同的文本。它会生成这些 token，随后在与原始代码匹配的 token 数量达到一定程度后，我们将重新开始逐块进行预测。

这实际上就像是对代码的常规编辑进行了一次速度提升。因此，它看起来更像是模型在快速重写所有代码的过程。我们可以使用与 diff 相似的接口，但其流式传输速度会快得多。

Lex：究竟哪个大型语言模型在编程方面更为出色？GPT 和 Claude 在这方面，谁能更胜一筹？

Aman 表示，在各个重要的评估类别中，没有哪个模型能够在所有方面全面优于其他模型。这些类别包括速度、代码编辑能力、处理大量代码的能力、上下文理解以及其他几个因素和编程能力。目前，他认为 Sonnet 在整体表现上是最为出色的，这也是大家的普遍看法。

o1 同样值得关注，它在推理方面表现出色。因此，面对一些复杂的编程面试问题或代码挑战时，它能够应对自如。然而，相较于 Sonnet，它似乎在理解用户的大致意图方面稍显不足。若我们观察其他一些前沿模型，我有一个疑虑，它们的表现未必总是理想……我并不是说它们在基准测试中的训练效果不佳，但在测试中的表现确实相对突出，尤其是在中间的表现上。

因此，若你在所有这些基准测试及其评估的范畴内进行尝试，它们的表现都会相当不错。然而，一旦将它们稍微推向其他领域，Sonnet 在保持同样的能力方面则显得尤为突出。基准测试中展现的能力与在编程相关任务中实际执行的能力之间存在很大的差异。

Sualeh 补充道，基准测试与实际编程之间有一个重要且复杂的区别：真实的编程过程并不完全等同于面试中的编程。人类在交流时，有时会使用不太准确的表达，甚至会说：“请按我之前的做法来做。”有时候，他们会要求“添加这个功能，然后再做其他事情，最后制作这个 UI 元素。”这样的交流往往依赖于上下文。真正希望理解人类意图的模型，应该能够以人类的方式去执行，而不仅仅是应对那些明确具体的面试问题，后者往往依赖于清晰的指示，而人类的表达则常常模糊不清。

Aman 提到关于 Claude 的一个有趣观点，AWS 使用的芯片可能与 Nvidia GPU 在数值上存在一些差异。有人猜测 Claude 的性能下降可能与在 AWS Bedrock 上运行的量化版本与在 Anthropic 的 GPU 上使用的版本之间的差异有关。

Lex：在这一切中，优秀的提示（Prompt）究竟扮演了怎样的角色？

Arvid：这主要取决于你所使用的模型，不同模型之间存在细微的差别，它们对提示的反应也有所不同。我认为，早期的 GPT- 4 以及去年的某些模型，对提示的敏感性相当高，并且它们的上下文窗口较小。因此，我们拥有大量与代码库相关的信息，这些信息在提示中可能会极为重要。

你拥有文档、添加的文件以及对话历史，这就引出了一个问题：在空间有限的情况下，如何决定实际上需要包含哪些内容在提示中？对于如今的模型而言，即便上下文较长，若填满整个上下文窗口也可能导致处理速度变慢。这意味着有时模型会感到困惑，而某些模型比其他模型更容易产生这样的困扰。

探索 Preempt 系统：提升提示设计的灵感与方法

在我们内部，有一款名为 Preempt 的系统，它为我们在这方面提供了不少助力。我们认为这个系统是为了适应 8000 个 token 的上下文窗口而开发的，类似于网站设计时希望在不同设备上都能良好显示的需求。这就意味着，即便是在动态信息的情况下，我们也不需要一个固定不变的布局。

想象一下，设计一本印刷杂志时，你能够明确物品的摆放位置。然而，当涉及到网站或提示系统时，你面对的是大量输入数据，这些内容需要被格式化，以确保即使在信息量巨大时也能正常工作，这可能需要你对某些内容进行删减。因此，我们的想法是，从这一过程当中汲取灵感。

那么，设计网站的最佳方法是什么呢？我们对 React 及其声明式编程方式非常欣赏。在 JavaScript 中使用 JSX 后，你可以直接声明出自己的需求，比如某一部分的优先级或 Z 轴顺序。在网页设计时，你有一个渲染引擎，例如 Chrome，而在 Cursor 中则是 preempt 渲染器，它会将所有内容整齐地展示在页面上。你只需表达想要的效果，渲染器会帮你实现。这种方法对我们来说极为有效，并且随着时间的推移，其作用也在不断演变。

最初，这种方法是为了适应较小的上下文窗口而设计的，而现在它在数据拆分和生成提示词时发挥了关键作用。这使得调试变得更加容易，因为你可以对提示词进行调整，然后在旧提示上进行测试，以直接观察这些修改是否能提升整体评估效果。

Lex：那么，你们真的在提示设计中使用 JSX 吗？

Arvid：没错。我们有一个文件组件，可以接收光标。通常，在文件中光标所在的位置是极为重要的，因为它是你当前查看的内容。你可以为此设置优先级。而在涉及大量来自代码库的代码块时，你可以使用检索和嵌入等技术，依据重新排序的分数为这些组件设定优先级。

Lex：那么，当人们提问时，是否也应该尝试这种方式？这是否会导致问题变得模糊不清，还是这种系统应该促进更加清晰的表达？

Arvid：我认为我们的目标是，你应当做出最自然的选择，而我们的职责在于搞清楚如何有效地提取出相对重要的信息，以确保你的思考过程是有意义的。

探索 AI 代理的潜力与挑战

Lex 提问：模型选择的复杂性与一般应答的难度有多大？处理不确定性时，是否应该主动寻求更多信息，以减少模糊性？

Sualeh 回应：我们近期为 Cursor 增加了一项新功能，允许用户添加文件。在用户编辑代码或输入内容时，模型会尝试预测用户的意图。如果模型发现某些地方存在不确定性，它会推测用户可能在编写某个 API，并查看用户的历史记录，以判断哪些文件与当前的编辑有关联。

这其中的技术难题在于，如何从大量历史记录中提取出相关信息，并确定在当前提示下哪些文件是最为重要的。尽管该功能仍在测试阶段，我们相信会逐渐完善这一构思。你是否希望模型能够帮助你决定添加哪些文件，从而更好地进行编辑？

例如，假设你正在开发一个 API，那么你可能还需要调整使用该 API 的客户端和服务器代码。因此，若 API 发生变更，客户端和服务器的代码也需随之更新。

Cursor 的能力在于，当你撰写提示或代码时，模型可以在你按下回车之前，帮助你识别那些可能需要一同修改的部分。这样一来，可以在一定程度上消除不确定性，确保相关代码能被正确更新，而无需手动去查找和同步这些更改。

Lex：你们认为 Agent 的价值如何？Agent 究竟有多大用处？

Arvid 回答：我认为 Agent 就像是人类一样，随着我们接近 AGI 的边缘，你会感受到这种变化。在观看某些演示时，它的表现几乎与真人无异，确实令人惊叹。不过，在许多方面，Agent 仍未展现出特别显著的实用性，但我们正在逐步走向它们真正发挥作用的阶段。

我认为，在某些特定任务中，拥有 Agent 会更加高效。例如，在处理 bug 时，有时无法在输入框中使用快捷键 Command+ C 和 Command+V，这是一项非常明确的任务。我只需简洁地描述：“这个功能不能使用，请修复。”我会希望有一个 Agent 能够自动处理并修复这个 bug，随后我再回来检查修复的结果。

智能代理能够精准定位到相关文件，尝试重现问题，进行修复，并检查其有效性。这一过程可能会耗费较长的时间，因此我对这样的工作方式感到十分期待。此外，很多人常误以为智能代理会完全取代编程岗位。然而，我并不这样认为，因为在编程的许多环节中，迭代过程本身具有重要的价值。实际上，很多时候你并不清楚自己想要的结果，直到看到初步版本后，才会逐步明确方向并提供更多的反馈。

因此，在许多编程任务中，我认为真正需要的是一个高效的系统，它可以迅速生成一个原型版本，便于我们进行快速的迭代和改进。

Lex 提到，比如近期推出的 Replica Agent，它能够自动配置开发环境，解决软件包依赖问题，处理数据库设置并部署应用。这正是很多开发者梦想的功能吗？

Arvid 对此表示赞同，认为对于某些编程任务，这样的技术确实令人兴奋。

Lex 继续询问，这种功能是否在 Cursor 的开发范围内？

Arvid 回应说，虽然他们目前尚未积极研发这一功能，但毫无疑问，他们希望能够使程序员的工作更轻松、更有趣。许多工作都显得枯燥，需要经过繁琐的步骤，因此他们希望能够将这些任务交给智能代理来处理。同时，还可以利用代理在后台进行操作的方式。例如，当处理一个包含前后端的 Pull Request 时，开发者可以专注于前端工作，而将后端的处理交给代理，这样在开始处理后端部分时，开发者就能拥有一些初步的代码进行迭代，这样的工作方式想必会非常高效。

Arvid 首先强调，他们希望能在后台执行大量任务，并正在不断尝试相关技术。目前，除了进行缓存预热和寻找命令键提示所需的上下文信息外，他们还没有开展太多后台操作。然而，

如果能够实现真正的后台计算，将有助于更准确地预测未来更长时间段内的操作，而不仅仅是下一步的代码。

例如，能够预测在接下来的十分钟内，开发者可能会进行的操作。通过后台计算，我们可以利用更多的计算资源来实现这一目标。为此，他们提出了影子工作区（Shadow Workspace）的概念，正在进行内部实验，以真正发挥后台计算的优势。他们意识到，需要为模型提供某种反馈信号，才能避免只依赖短期思考而获得的成果，例如 o1 就是一个很好的实践案例。

提升模型性能的另一个有效策略是通过迭代过程获取反馈。程序员的工作中，语言服务器作为一种重要的反馈来源，广泛应用于多种编程语言中，每种语言配备独立的语言服务器。这些服务器能够指出“这里使用了不正确的类型”，提供错误提示，甚至能够跳转到定义，深入理解代码结构。例如，TypeScript 和 Rust 的语言服务器是由各自团队开发的，它们通过语言服务器协议与 VS Code 进行交互，使得 VS Code 无需集成所有语言功能，而是能够利用现有的编译器基础设施。

这种反馈机制的核心在于实现代码检查、定义跳转和类型确认。尤其是在大型项目中，类型检查与引用查找功能是不可或缺的，缺乏这些支持，将会极大地增加编写代码的难度。

Lex：在 Cursor 中是如何利用语言服务器协议进行信息交流的呢？

Arvid：在 Cursor 中，我们通过语言服务器协议向程序员传递信息，这与 VS Code 的功能相似，但我们的目标是将这些信息也提供给智能模型，并尽量让这一过程对用户透明，这意味着这些操作会在后台进行。

影子工作区的构想在于，我们能够创建一个隐藏的 Cursor 窗口，用户可以在其中设置标志并将其隐藏。尽管这个窗口不为用户所见，但它实际上是存在的。在这个环境中，AI Agent 可以自由地修改代码，只要这些更改不被保存，因为依然是在同一个文件夹内。随后，它们可以获取来自代码检查工具的反馈，进行定义跳转，并反复迭代代码。

这正是我们最终希望实现的目标，也是本博客文章的主要讨论内容，尽管实现这一目标面临一定挑战。我们希望该系统能够在用户的机器上运行，以充分模拟用户的操作环境。在 Linux 系统中，我们能够进行一些创新，比如镜像文件系统，让 AI 在文件级别进行处理，但这些操作会存储在内存中。我们可以开发类似于内核的扩展来实现这一点。不过在 Mac 和 Windows 系统上，这一过程略显复杂，但这也是一个有趣的技术难题，因此我们正在积极探索。

Aman：一个可能看似粗糙但颇具趣味的设想是对保存操作进行锁定。这样一来，语言模型在进行保存时会被锁定，用户就无需直接在磁盘上操作真实文件，而是在影子工作区处理那些未保存的内容。用户仍可获得错误提示并进行编码，然而在尝试运行代码时，系统会提示存在锁定，这时用户可选择释放锁，以便并行执行其他操作。

Lex：允许模型对文件进行修改展现了一个激动人心的未来，尽管这听起来也不乏风险。想象一下，AI 代理能够自动完成一系列任务，用户只需在第二天审查结果，仿佛 AI 正是你的同事一般。

模型在任务执行中的挑战与机遇

Aman 指出，模型在执行不同类型的任务时，其表现会有所不同。对于一些简单的操作，用户通常能够在短时间内完成，甚至在本地计算机上运行也非常方便。然而，当任务的复杂度增加，且所需时间较长时，就必须依赖于远程沙盒环境来执行。如何有效地重现用户的使用环境，并确保在远程沙盒中运行的代码能够产生一致的结果，确实是一个不小的挑战。

Sualeh：我很想知道，你们希望编码代理具备怎样的功能？是帮助识别漏洞，还是实现新功能呢？

Lex：在编码方面，关注各种级别的缺陷，特别是逻辑错误和设计方向的失误，显得尤为重要。

Aman：然而，这些模型在简单提示下并不擅长于识别和发现错误。即便是最为智能的模型 o1，其校准水平也相当有限。

Lex 对此表示好奇：“您能详细说明一下吗？”

Aman 回应称，这些模型能够较好地反映预训练数据的分布情况，随着损失函数的逐渐降低，模型的泛化能力有所提升。然而，现阶段损失函数的降低已经达到一个较高的水平，使得模型可以进行较为全面的泛化。我们主要在前沿领域利用这些模型，进行代码的生成和问题的解答。在预训练阶段，GitHub 上积累了海量代码，达到数万亿个 token，同时在 Stack Overflow 及 GitHub Issues 等平台上也积累了大量问题和答案，为任务提供了丰富的数据支持。

然而，当我们尝试推动一些较不常见的任务时，比如根据已有的编辑内容来预测下一个 Cursor Tab 的目标，模型的局限性便显露无遗。

另一个显著的例子是 bug 检测，因为实际情况是，关于检测 bug 并提出修复建议的真实案例并不多见，这使得模型在此方面面临很大的困难。

不过，我认为，这同样涉及到模型迁移的问题。我们需要将其他模型有效地迁移到 Cursor Tab 上，当我们将擅长代码的通用模型应用于 bug 检测时，预计会有良好的效果，只是需要我们给予适当的引导。

Sualeh 指出，模型对于代码的理解显而易见。在预训练阶段，它们可能已经能够初步识别出代码中的问题。这一现象的背后，部分原因在于一些人对这些错误进行了细致的校正。

然而，当使用模型进行编程时，例如在处理庞大的数据库时，即使我们设定了严格的校准机制，错误依然难以避免。

Lex 表示，人类在评估代码的重要性方面也面临挑战。若某段代码可能造成严重后果，理应附上“此行代码存在风险”的注释。

Arvid 提到，使用全大写字母并重复十次是一个可行的做法。

Lex 回应说，即便是同一位开发者也可能会遗忘某段代码的潜在危险性。

Arvid 则认为，这种情况在当今的 AI 模型中同样适用。如果在每一行中都标注“危险”、“风险”这样的字眼，模型可能会更加关注这些内容，并在相关部分更容易地发现错误。

Lex：清晰地标明代码的潜在危害是一种优秀的实践。

Arvid 补充说，不过这种方法也存在争议，像 Sualeh 就对此持有不同看法。

Sualeh 坦言，尽管从审美角度他并不喜欢这种做法，但它确实能为模型和那些可能容易遗忘代码风险的开发者提供帮助，进而防止一些小错误演变成严重问题，比如服务器崩溃。

Aman 指出，即便是在普通文档字符中，开发者在修改代码时也常常会忽视潜在风险，因此明确指出这些风险显得尤为重要。

未来编程的可能性：如何通过规范化提升代码安全性

Lex 表示，程序员在修改代码时，常常集中注意力于功能的提升，却疏忽了潜在的安全隐患。

Arvid 指出，假如能够对所有代码进行形式化的验证，就能有效避免 bug 的产生。

Aman：那么，这种理想中的未来会呈现出怎样的面貌呢？

Arvid：我认为，未来人们将不再需要手动编写测试，智能模型会自动生成规范，用户只需进行审核。与此同时，智能推理模型将评估代码的合规性。这种方法可以适用于绝大多数函数。

Michael 对此表示质疑：“生成规范真的那么简单吗？明确人类意图在软件中往往充满挑战，许多想法难以具体化，更难以验证其执行是否符合初衷。”

Arvid 追问：“您认为生成规范是艰难的吗？”

Michael 回应：“对于那些难以用规范语言表达的需求，形式化验证并不可靠。”

Arvid 继续探讨：“即使拥有大量规范文档，是否依然难以实现？”

Michael 认为：“规范有可能替代单元测试。”

Arvid 总结道：“然而，规范语言是可以不断演进的，以适应更多的需求。”

探索形式化验证的边界与未来

Lex 提出了一个重要的问题：“这种设想是否能够适用于整个代码库，而不仅仅是局限于某个函数？”

Arvid 回应说：“确实，进行整个代码库的形式化验证相对困难，但这是一个值得追求的目标，并且从理论上看是可行的。最近的一些研究已经开始对硬件进行形式化验证，这其中包括 C 语言代码、GCC 编译器以及 Verilog 硬件描述语言。大型代码库可视为多层系统，假如能够将其拆分并分别进行验证，那么形式化验证整个代码库的目标是可以实现的。不过，规范问题确实存在挑战。”

Aman 接着询问：“对于副作用和外部依赖，应该如何处理？比如调用 Stripe 的 API。”

Sualeh 则指出：“Stripe 为其 API 提供了相应的规范。”

Aman 继续提问：“是否所有的外部依赖都能提供规范？例如，如果程序中使用了语言模型作为原语，如何将其纳入形式化验证的范围？”

Arvid 表示：“这一点也是可行的。”

Aman 不禁好奇：“那该如何证明语言模型的效果呢？”

Arvid 解释道：“可以通过证明语言模型的对齐性，或者验证其能否给出正确答案来进行确认。”

Sualeh 对此表示：“这正是我们所追求的终极目标。”

Lex 总结道：“如果这一切能够实现，将极大有助于确保代码的正确性以及人工智能的安全性。”

未来编程：如何优化 AI 的 bug 检测能力

Lex 提问道：“既然在查找 bug 方面模型遇到了挑战，那么未来的希望又在哪里呢？”

Sualeh 回答：“我们期待模型能初步识别一些基本的 bug，比如越界错误或代码和注释之间的不一致。最终，我们希望它能够发现更复杂的问题。”

Michael 接着说：“强大的 bug 检测工具对于实现 AI 编程至关重要。如果 AI 可以自动编写代码，那它同样需要验证这些代码是否正确。这不仅是对人类程序员的支持，也是对 AI 生成结果的验证。”

Arvid 补充道：“是的，但具体应该如何实现呢？有一种流行的看法认为，制造 bug 比发现它们要容易，因此可以通过训练模型引入一些错误代码，接着再训练一个反向模型，利用合成数据来寻找这些错误。这确实是一个有效的方法。”

Michael 提到：“我们还可以利用大型模型以及代码以外的信息来辅助寻找 bug，例如通过执行轨迹和调试器的信息。bug 检测工具可能会有两种不同的形式：第一种是快速模型，能够在后台运行，专注于常见 bug 的发现；而第二种则是高计算量的模型，专门用于解决特定的 bug，用户需要支付费用才能使用。”

Lex 接着询问：“有没有考虑通过资金将这些机制整合在一起？如果模型能够有效地找到 bug 或生成高质量的代码，我是愿意为此付费的。”他接着说：“前几天，我用 Cursor 模型生成了三个完美的函数，主要用于与 YouTube API 进行交互，帮助我实现多语言字幕更新。”

他进一步指出：“API 文档不够完善，且存在代码交叉的问题，我在谷歌上搜索时得不到明确的信息，只有令人困惑的内容，而 Cursor 生成的则极为完美。我真希望能有一个‘打赏’按钮，写着‘5 美元’，既能支持公司发展，又能给模型发出积极的反馈，比如‘干得好’。在 bug 查找方面，是否也可以引入类似的赏金机制？你们是否考虑过？”

关于用户反馈与技术改进的探讨

Arvid：在公司内部，这个问题引发了不同看法。我认为，这在某种程度上反映了你对人性的信任。我觉得，若能够在不花费任何费用的情况下发现一个 bug，那是非常理想的。如果没有找到问题，便无需支付费用；而如果付费后找到了 bug，并点击“接受”选项，那么便会在括号中显示相关费用，比如 1 美元。

这可能会引发一些顾虑，比如我们在计算过程中投入了大量资源，或许有人会选择复制粘贴代码，另外，付费机制也有可能影响到用户的使用体验。我认为，可以考虑将付费机制与产品功能分开，用户若每月支付固定费用，则可以免费使用全部功能。

Lex：可以引入一种“打赏”的功能，而不是强制收费。

Arvid：即使是打赏，也涉及到经济因素，这可能会影响到用户的体验。

Aman：当用户分享模型时，实际上已经在体现对该模型的认可。

Michael：如果能够研发出技术手段来验证 bug 是否已经被修复，就无需依赖于基于荣誉的赏金机制了。

Lex：终端与代码之间究竟有多少交互？在终端执行代码时能获取多少信息？是否能创建一个循环，使模型能够运行代码并提出修改建议？目前，代码与其实际执行是完全分离的吗？据我了解，现阶段可以在终端使用“Ctrl+K”来辅助代码编写。

Aman：可以利用 Check 命令和 Ctrl+ K 结合终端上下文信息。但目前尚未实现循环功能，不过这个想法很有前景。关键在于，这个循环是前台执行还是像以往一样在后台运行。

Lex：后台运行的确很酷，因为它可以支持多种方式来执行代码。另外，还需关注数据库方面的问题，比如如何避免模型对数据库进行修改。

Sualeh:我们正在探索一个极具潜力的解决方案，具体来说，就是开发一个全新的 API。我相信 PlanetScale 和 Turbopuffer 这两种数据库将会支持这一功能。在功能开发并进行数据库测试的阶段，实际上并不需要对所有数据库进行广泛测试，而是可以通过创建一个分支来进行测试，避免直接修改主数据库。

这种技术的实现方法是为数据库的预写日志增添分支。数据库公司在不断推进新功能的开发，而分支功能可能会成为未来发展的重要方向，同时，AI 代理也能够利用这些数据库分支进行有效测试。

Lex：我想问一些关于基础设施的问题，Cursor 团队目前主要依赖 AWS（亚马逊云服务）吗？在使用过程中遇到了哪些具体挑战呢？

Arvid：AWS 的表现相当卓越，使用其产品时，通常都能保持稳定，尽管设置过程可能会异常复杂。坦白说，AWS确实值得信赖，若出现问题，很大程度上是由于用户自身的原因。

Lex:作为一家初创企业，Cursor 在发展过程中面临了哪些具体挑战呢？

Michael：随着请求量的不断增加，缓存和数据库等基本组件均面临性能瓶颈。例如，我们已经遭遇了数据表溢出等问题。此外，我们构建的一些定制系统，例如用于代码语义索引和问答的检索系统，回答与代码库相关的问题，我认为这也是扩展过程中相当棘手的挑战之一。

Sualeh：我的一些高级工程师朋友们提到，在扩展过程中，准确预测系统崩溃的具体位置非常困难。虽然可以提前进行尝试预测，但在增加额外内容时，总会出现一些意外情况。具体到 Cursor，我们将所有的代码分块后进行嵌入，然后将这些嵌入的代码存储在数据库中，实际上并不保存任何代码。接下来，我们必须确保不引入客户端的 bug，因为我们对此异常严格，服务器上存储了大量细节，一切均经过加密处理。

因此，技术挑战之一就是如何确保本地的代码库状态与服务器端的状态相一致。从技术角度来看，我们采取的方法是下载服务器端的哈希值，并与本地哈希值进行对比，计算出缺失的文件。然而，这样做会增加网络负担。如果您在使用 Cursor 时，没有人希望网络连接一直处于紧张状态。

优化数据库与代码管理的创新方案

显然，这将给数据库带来巨大的负担。每秒几乎需要处理 20TB 的数据，甚至是在高达数十 TB 的数据库中操作，这实在是相当不合理。

为了解决这个问题，我们引入了 Merkle 树结构，只需关注项目的根节点哈希，便可以有效地检查子项的哈希值是否匹配，从而显著减少开销。

然而，随着用户数量的增加，代码库的体量也在不断扩大。起初，我们对暗代码库进行了整理，但现在其规模已经不逊色于一些拥有庞大文件的企业。

创建一个系统并不复杂，但要扩展到更多用户和公司，这却是一个不小的挑战。我们正在不断努力来克服这些困难。

Aman 提到，确实，索引系统中有许多需要深入研究的内容。实际上，嵌入代码这一环节就是我们的瓶颈。为了防止同一代码块的重复嵌入，我们实施了一种缓存机制，将代码块的哈希值和相应的向量进行存储，这样做可以显著提升一些公司在使用 Cursor 时代码嵌入的速率，用户只需保存向量数据，而无需存储完整的代码信息。

Lex 询问道：目前您认为代码库索引最大的优势是什么？从短期来看，代码库又能带来什么呢？

Arvid 回答道，最显而易见的是，当你需要在大型代码库中找到特定内容时，可以通过模糊查询来进行搜索。例如，“我想找到实现 X 功能的代码位置。”而你并不需要明确指定搜索的语言，只需通过聊天请求来与代码库互动，通常模型能够提供准确的结果。

Lex 接着问道：为什么 Cursor 不考虑在本地进行代码嵌入等操作呢？

Arvid 解释说，我们确实考虑过这种可能性，但 实施难度非常大。尽管一些用户使用的是最新的 MacBook Pro，但超过 80% 的用户仍在使用 Windows 设备，许多机器的性能并不出色。实际上，本地模型仅适合最新的计算机，而构建过程也会带来巨大的开销。因此，即使我们有意进行这样的尝试，实际上也很难实现。

Aman 总结道：确实，庞大的数据库将消耗大量内存和 CPU 资源。此外，正如 Arvid 所提到的，本地模型的建设面临着巨大的挑战。尽管 MOE 架构在内存带宽要求上更高，且适合本地运行，但整体模型的规模也随之扩大，需要更多的机器来支撑。我认为，在编码生成方面，用户希望能够使用最优秀、最聪明的模型，但在本地实现这一目标却非常困难。

Arvid 表示，他对本地模式的替代方案持积极态度。在他看来，这一方案仍处于探索阶段，可以视为为语言模型推理引入同态加密的尝试。用户能够在本地对输入数据进行加密，随后将其发送至服务器进行推理处理。尽管服务器能够处理这些加密数据，但无法获取其具体内容。最终，服务器会将经过加密的答案发还给用户，用户需通过解密才能查看结果。尽管当前同态加密的成本较高，但如果能降低这一费用，前景将非常值得期待。

随着信息与数据日益集中于少数中心化参与者，相关的安全隐患也愈发显著。传统的黑客攻击仍然是一个严重威胁，用户的数据可能遭到监控。尽管各方正在努力防范不法分子利用 AI 模型，这也引入了监控机制，但这些机制却可能被滥用，导致用户的隐私被侵犯。因此，我们期望能找到解决同态加密的有效方案。

Lex 对此表示，这确实是任何软件所面临的普遍挑战。云服务虽然提供了便利，但也伴随了一些缺陷，因而需要有强大的安全措施来防范潜在的攻击。同时，部分大公司掌控着这些数据，这也是我们生活中的一种现实。

Sualeh 对此表达了担忧，特别提到 Anthropic 公司实施的负责任扩展政策。他指出，当模型进入更高级别时，出于合理的安全考虑，监控会变得更加严格。这种情况虽有其合理性，但如果所有信息都被监控，情况将会非常可怕。

Aman 则询问，AI 模型的监控与云服务供应商的监控有何不同？

对此，Arvid 认为，许多数据最初并不直接流向云供应商，通常用户会将更多数据提供给 AI 模型。用户在初始阶段并不会将所有信息上传至网络上，交给相关公司或模型。然而，随着 AI 模型监控变得更为集中，云服务用户能够使用加密密钥，而 AWS 对此却无能为力，最终只有中心化的 AI 模型提供商能够查看具体的文本内容。

Lex 在使用 Cursor 时遇到了一些困难，他提到在 Python 编写代码时，模型如何识别他想要提及的上下文内容，真是一个棘手的问题。

Michael 对此表示，未来我们在自动计算上下文方面有望做得更好，但需要注意的是，引入自动上下文需要权衡。模型所包含的上下文越多，其处理速度越慢，相应的请求成本也会提高，这会限制可以调用的模型数量。此外，如果提示信息过多，模型可能会感到困惑。因此，在上下文中信息的准确性和相关性标准必须非常高，我们期待能在这方面取得更好的进展。

探索语言模型与代码库的深度融合

在我们的内部研究中，尽管尝试了若干改进的策略，但仍然面临着一些挑战。如何让语言模型真正理解新的信息来源？上下文窗口的扩展是否能够无限制？模型是否能够持续关注无穷无尽的上下文，并在不重复计算的情况下进行有效缓存？这些问题仍在积极探索中，相关的想法就如同在模型权重学习过程中进行的微调。同事们对此充满期待，我们也期待能有更出色的检索系统。

Aman 提到：有一个有趣的例子是 VS Code，这是一款跨平台的源代码编辑工具。

当前我们正处在一个关键的分叉点上。VS Code 的源代码是开放的，许多大型语言模型在预训练阶段已经接触过这些代码，并通过微调及人类反馈训练，能够有效地回答与之相关的问题。因此，当用户询问有关 VS Code 的内容时，模型有时能够提供准确的答案，尽管偶尔也会出现错误。如果能专门训练一个模型并建设一个理解这些问题的代码库，那么这将是非常有价值的研究方向。

此外，我们对于开放性研究问题充满热情，但也存在一些不确定性。用户究竟希望模型在前端完成所有任务，还是将检索与代码生成分离？未来几个月，我们可能会见证一些真正强大的模型的出现，届时用户将能够独立训练一个出色的开源模型，并将其用作检索器，以便在上下文中为这些更大型模型提供必要的信息。

Lex 发问：如何为特定的代码库进行模型训练呢？

Aman 回应道：有许多方法可以尝试，需要逐步验证它们的有效性。比如，尝试复制 VS Code 及一些前沿模型所做的工作是个相对基础的思路。因此，我们应该继续进行预训练。在持续的预训练阶段，我们可以引入特定代码库的数据，并在指令微调时加入与该代码库相关的问题。我们会从指令微调开始，构建一个与代码相关的常规指令微调数据集，并提出更多关于该代码库内部的代码问题。

可以通过获取更难以获得的真实数据，或者利用合成数据来进行某些操作，从而让模型提出关于代码各种新组成部分的问题。因此，提取代码片段并让模型对此提出问题，再将其融入指令中以微调数据点，这个过程理论上可能会提升模型对该代码库问题的理解能力。

▲播客现场（

Lex：我想请教您关于 OpenAI o1 的一些问题，您认为测试计算系统在编程中的重要性如何？

Aman：我觉得测试时间计算这个概念非常引人入胜。随着数据量和模型规模的不断扩大，预训练机制将导致损失函数和下游任务的表现持续提升。然而，我们现在面临数据壁垒的挑战，这使得数据规模的进一步扩展变得愈加复杂。

因此，扩展测试时间计算作为一种创新的方法是相当有趣的 。假如我们现在增加推理时间的 flop 计算量，使用 Infer Time 时，这些模型的 flop 总量必然会增多。与此同时， 或许我们能够在保持模型大小不变的情况下，延长计算时间，以便获得与更大模型相似的效果。

有些查询可能需要高达 100 万亿参数的模型来处理，但这样的查询可能仅占所有查询的 0.1%。在这样的情况下，或许会存在资源浪费。因此，训练一个能够处理 99.9% 查询的模型，再为那些真正需要更高智能的查询延长推理时间，或许是更为高效的策略。

Lex：如何判断哪些问题需要更高的智能水平？是否可以在 GPT- 4 与 o1 之间动态切换？

探讨 AI 模型训练与决策的复杂性

Aman 指出，确实这是一个待解决的难题，目前尚缺乏有效的解决方案。在 Cursor Tab 功能中，团队已实现了基本的模型路由功能，但在 GPT- 4 与 o1 之间的切换仍较为复杂。此外，判断哪些问题对司机模型来说是否过于困难，可能需要依赖 o1 模型的能力，但这很难明确界定。

我们还需考虑如何评估某些问题对 GPT- 4 的难度，这或许需要 o1 级别的模型来进行判断。

进行测试所需的时间计算必须依赖全面的训练策略才能顺利实施。此外，除了 OpenAI，大型实验室外的相关信息仍然有限，关于其工作原理也不甚明了。有一些有趣的研究论文暗示了潜在的探索方向。因此，测试时的计算可视为后训练阶段的任务，而未来支持测试计算的模型所需算力可能会超出目前的预训练阶段。

Lex：那么，构建一个能够与 o1 相竞争的模型需要哪些步骤呢？

Aman 回应道，或许我们可以尝试训练一个流程奖励模型。在此模型中，将结果奖励模型与过程奖励模型进行区分，前者关注于最终结果，是传统的语言建模训练奖励模型，而后者则需要更细致地分析思维链。去年，OpenAI 发布了一篇关于过程奖励模型的研究，利用人工标注的数据集进行了相应的训练。

目前，过程奖励模型的主要应用是在众多模型输出中筛选出最佳解答，但其表现尚未展现出特别卓越的特性。在众多的学术成果中，研究者们通常从语言模型中提取输出数据，并利用过程奖励模型对这些数据进行评分，以选择出最佳答案。未来的研究将可能围绕流程奖励模型及其树状结构展开，探索思维链的多种分叉，并对这些分叉的质量进行评估。

Lex：当分支的质量与最终结果的质量紧密相关时，是否能帮助模型选择更优的分支？

Aman 表示，确实如此。他认为，在讨论开源模型训练流程奖励模型时，采用的方式可能更为自动化。然而，迄今为止，他并未见到任何能创造性地利用流程奖励模型来进行树状结构搜索和编码的实例。

Lex：AI 安全问题更像是哲学上的挑战。OpenAI 曾指出，他们选择隐藏思维链的决定是艰难的，他们在后台监控思维链以防模型对用户造成干扰，这的确令人震惊。你们对此隐藏思维链的做法有什么看法呢？

Michael：我猜测，OpenAI 可能出于防止他人窃取其技术而选择隐藏思维链。如果用户能清楚地查看每一步的思考过程，那么这些技术将变得更易获取。

Lex：你也可以利用这个进行训练吗？

Michael：在大语言模型的供应商之间，确实可能出现这种情况。曾经有些 API 允许访问他们的记录概率，但后来又撤回了这些权限。这或许是因为那些曾接触过记录概率的人，能够窃取模型的技术信息。

我们已将 o1 集成到 Cursor 中，对 o1 这个技术我们非常感兴趣，许多程序员对此也充满期待。但是，o1 并不是 Cursor 的默认功能，目前我们尚未找到有效的方法将其整合到编辑器中。因此，如何利用这个模型（o1）仍然是一个未知数。

Sualeh：我们有一些美好的构想，但需要找到合适的场景进行发布。

Aman：o1 模型目前仍有许多限制，例如不支持流式输出，用户无法对输出过程进行实时监督，只能等待结果的生成。此外，其技术仍处于发展的早期阶段，尚需大量改进，未来将增加预训练数据的规模，以便不断提升搜索的效率。

Lex：听说 GitHub Copilot 似乎在某种程度上集成了 o1 模型，有人担心这是否意味着 Cursor 的结束？

Michael：我认为这个领域与 2010 年代的软件行业截然不同，现在的潜力巨大，因此在未来三到四年内，最优秀的产品将迅速超越今天的顶尖产品。即使拥有强大的品牌，如果不进行创新，最终也会遭遇失败。在接下来的几年中，构建最佳产品和系统将至关重要，这将归结为建模引擎和编辑体验的提升。

Aman：确实如此，我认为 Cursor 的优势在于不仅能迅速集成新模型如 o1，同时也能深度定制，尤其重视用户体验。

Lex：您能否详细阐述一下合成数据分类法的相关内容？

Aman：合成数据是利用人工智能生成的一类数据，我认为它可以分为三种主要类型。第一种是蒸馏，这包括语言模型、输出的 token 以及 token 的概率分布，旨在训练那些能力较弱的模型。虽然这种方法无法创造出比原始模型更强的模型，但却可以将高延迟且昂贵的模型能力转移至较小或专门执行特定任务的模型中。

第二类合成数据则是利用某些问题的特性，使得某个方向的任务比另一个方向更为简单。以 bug 检测为例，发现 bug 通常比检测 bug 更为容易。在这种情况下，我们可以在一个未经完全训练的模型中添加一些 bug，然后利用这些合成数据来训练一个专注于 bug 检测的模型。

最后一种是通过语言模型生成的文本，这些文本能够被轻松验证。例如，为了验证某一系统的性能，检查其语言表达是否能达到莎士比亚的水平，可以让猴子或打字机进行随机打字，最终产生的数据可用于培养一个具备莎士比亚水平的语言模型。

关于具体的引导代码，其合格性可以通过相应的测试结果来评估。此外，我们也可以利用生成的模型和经过测试的代码来进行训练。然而，我认为这种方法在实际应用中效果有限，特别是在开放式或复杂任务中，很难找到一个完美的验证标准。

Lex：人类反馈的强化学习（RLHF）与 AI 反馈的强化学习（RLAIF）相比，有何不同？它们对 AI 模型性能提升的影响如何？

Aman：RLHF 是基于人类反馈信息进行训练的，我认为如果能为特定任务提供充分的人类反馈，那么效果会非常出色。

RLAIF 则显得更为有趣，它在执行任务时会考虑某些约束条件，比如用语言模型来验证解决方案通常比直接生成解决方案更为简单。这种方法更容易取得成功，因为 RLAIF 能够形成一种递归循环。

我们可以将这两者结合起来，寻找一个合适的平衡点。例如，当生成某种特定的代码时，加入约 50 到 100 个人工反馈的示例，或许就能使模型的先验知识与我们的设想相一致。

这种方法与传统的强化学习通过人类反馈（RLHF）有所不同，后者通常需要大量的示例来训练奖励模型。

Lex：依你所见，在生成与验证或者生成与排序之间，哪一个更为简单呢？

Aman：从直观来看…或许在既定条件下，验证会比证明更容易。

Sualeh：AI 获得菲尔兹奖的几率有多大呢？

Sualeh 和 Arvid 认为，AI 获得菲尔兹奖的机会更高。

Aman 表示，尽管人工智能已经解决了许多复杂问题，但在定理证明方面的表现仍不可知。此外，对于解决那些极其困难的开放性问题，我们的预估也并不准确。

Lex：你认为 AI 会先赢得菲尔兹奖，而不是物理学奖或其他奖项吗？

Sualeh 坚定地表示，AI 必定会获得菲尔兹奖。他指出，一些奥林匹克数学难题，如伯奇和斯温纳顿 - 戴德猜想，对 AI 来说依然极具挑战性，当前尚不清楚如何解决这些问题。

Aman：在实现通用人工智能之前，AI 有可能率先获得菲尔兹奖。

Sualeh：如果真的能实现，我会感到非常高兴。我认为这可能会在 2028 年或 2030 年前后发生。

Lex：关于缩放规律，大家可以分享一下各自的观点，尤其是对于现在的状态和未来的发展趋势。

Aman：OpenAI 最初提出的关于缩放规律的研究中确实存在一些缺陷。他们提到优化学习效率时，缺乏准确性。此后，Chinchilla 的研究提出了更为有效的版本。从那之后，研究者们的关注点逐渐从计算优化转向在有限推理预算下如何获得更优秀的结果。

Aman：我认为，缩放规律的维度远比我们最初仅用来计算参数和数据的维度要复杂得多。例如，推理计算显然是一个重要维度，而上下文长度也是一个显而易见的因素。如果我们侧重于推理计算和上下文窗口，可能会想要训练某种状态空间模型（SSM）。

在处理超长上下文时，这种模型的成本显著降低，速度也大幅提升。尽管训练时可能需要增加 10 倍的计算量，也就是说需要投入 10 倍的计算资源来训练模型，以期达到相同的能力水平，但这仍然是值得的。因为我们最为关注的是在超长上下文窗口下的推理成本预算。因此，未来的研究将会围绕这些维度展开。

Lex：你认为人们是否依然信奉“越大越好”的理念？

Aman：对于原始性能和基础 AI 而言，模型越大确实越好。但是，我认为人们会更加看重蒸馏技术。如果我们在训练过程中投入巨额资金，以实现性价比最高的模型，我们究竟能调整多少个参数呢？

这一点确实值得关注。因为在推理过程中盲目增加计算的做法，人们已经在 Llama 模型上尝试过了。或者，仅仅是对 7B（70 亿参数）模型进行过度训练，使用的 token 数量也远远超过了实际需求。

探索 AI 训练的深层次奥秘：从蒸馏到资源配置的全景分析

倘若你对这个话题颇感兴趣，那么或许我们可以借鉴 Gamma 的方法，进行更深入的研究。具体而言，除了在 token 层面进行训练，我们可以通过减少与 Gemma 27B 分布的 KL 散度来进行有效训练，这就引出了 知识蒸馏 的概念。实际上，这意味着在所有这些 token 上，消耗计算资源来训练一个包含 270 亿参数的庞大模型，并将其重要内容提炼至一个更为精简的模型中。

Lex：蒸馏会让模型变得更快吗？更小就意味着更快吗？

Aman：我认为，从理论上讲，蒸馏能够从正在训练的数据中挖掘出更多的信息。这是一种可能的策略，尽管它并非彻底解决数据壁垒的方法，但能在一定程度上帮助我们突破。由于可用于训练的数据量有限，我们可以利用这些 token 来训练一个极大规模的模型，随后将其蒸馏为一个较小的模型。相较于自主训练，蒸馏的方式能够帮助模型吸收更多的信号。

Lex：假设你们有 10 万亿美元的预算，你们会如何运用这些资金？

Aman：我认为，关于训练这些大型模型的细节和秘密，只有大型实验室才会真正了解。即使我竭尽全力去尝试，也可能会造成巨大的资金浪费。

Lex：假如你能够获取所有相关信息，包括训练参数和方法，未来五年内，你将如何投资以实现你们所追求的原始 AI 的最大化？

Sualeh：我认为，答案其实很简单。你只需要尽可能多地购买计算机，之后的每一天都在购买 GPU，这样研究人员就可以根据目标选择训练大模型或小模型。

Aman：这引出了一个问题，我们的限制真的是来自于计算能力和资金，还是有其他的约束因素？

Sualeh：更多的是受到自身观念的制约，但还有一些其他的限制因素存在。

Lex：你们会更倾向于进行大量实验，还是会将这些计算资源用于训练一个庞大的模型呢？

Arvid：我认为我们可能会选择进行实验，因为眼下我们的思维方式仍然受到限制。

Aman：我对此表示认同，因为即使拥有全球最强大的计算力和可用的数据，依然会面临诸多限制，这些限制不仅仅是源于观念，还包括更高层次的工程技术。即使资金充足，能够在这一领域有所成就的人也屈指可数。

在科研过程中，往往需要面对大量复杂且极具挑战性的工程技术工作。比如，若你仔细阅读原始的 Transformer 论文，就会发现其中融合了许多引人入胜的概念，而将这些概念付诸实践则需要一流的工程师来完成，类似于 GNOME Azure 的工作。

进一步而言，实现下一代模型的并行化工作需要巨大的工程投入。我认为，要使所有这些工作顺利进行，必须进行大量的工程技术投入。例如，若能将工程成本降低十倍，并使那些有理想的人能够真正实现他们的构想，提升 GPU 利用率 40% 至 50%，那么研究效率将会显著提高。

Sualeh：如果能够明确改进的路径，成果就会触手可及。我认为，OpenAI 和其他一些实验室的策略是正确的，它们把握住了这些成果。例如，GPT-4.25。现有的方法是有效的，因此无需追求创新，创新只在遇到瓶颈时才显得必要。我认为，如果拥有 10 万亿美元的预算，或许会优先考虑扩大规模，然后再更新观念。

在现有方法有效的情况下，没有必要去尝试新的理念。只有当遇到瓶颈时，才会需要新的思路。如果手上有 10 万亿美元的预算，首先可以尝试扩大规模，然后再重新审视当前的想法。

Aman：我们坚信，实现 AGI 需要全新的理念。同时，我们也相信可以在更小的规模上测试一些新的观念，并对此充满信心。当前实验室在将有限的研发人力投入到开发新构想上面临困难，毕竟现有方案在未来相当长的一段时间内仍然有效。

Lex：你们现在正处于编程领域的核心。你们认为编程的本质在未来几个月、几年，甚至十年内会有怎样的变化？

未来编程的趋势与挑战：程序员的角色将如何演变？

Michael 认为，我们对将来的发展充满期待，原因在于程序员在历史的舞台上占据着重要的位置。之前我们曾提到，程序员需要具备高效性、代理能力和控制能力，他们能够随意调整任何想要改变的内容，并迅速对所构建的项目进行迭代和优化。

在这里，“与计算机进行对话式编程”是一个新概念，类似于在 Slack 上与工程团队沟通，通过一个独立的文本框输入需求，AI 自动完成相关工作。然而，这种方式也存在一些缺点，比如响应延迟，以及可能会失去部分控制权。

从根本上讲，工程的实施依赖于你所做的微小决策，而人类的关键角色是 AI 无法替代的，只有让人类掌控“方向盘”，才能真正引领项目的发展。

未来的编程环境，程序员或许能够掌握代码库的抽象层次，通过查看伪代码的形式进行编辑。同时，程序员还可以调整编程软件的逻辑，保持对整个过程的控制权，这将显著提升工作效率。

尽管这个想法仍显得模糊，许多细节尚未明确，最终能否实现仍需观察。但人类的控制力、效率以及以人为中心的理念都是至关重要的。我们认为，某些编程任务，如 Arvid 之前提到的，确实可以交由聊天机器人完成。然而，大多数编程工作仍需人类深度参与。

Lex：编程的基本技能是否会经历根本性的转变？

Michael：实际上，我认为现在是软件开发的一个激动人心的时代。无论何时，许多代码仍然需要参考那些难以理解的信息。但今天的编程相比过去更加有趣，人们开始享受这一过程。如今的编程使人们能够迅速构建项目，并大幅提升了他们的控制能力。

对于程序员而言，这也是一个富有意义的时期，他们的创造力和兴趣被进一步激发。如果你是程序员，那么在今天的环境中，应该更为关注这一独特的变化。

未来编程的趋势与热情

Arvid 表示，他完全赞同当前正在进行的重大代码库迁移工作。这一过程涉及将 Node.js 中的异步本地存储替换为上下文对象。尽管借助人工智能能提高效率，但他与另一位工程师仍需花费大约五天时间才能完成这项任务。然而，未来的展望是，只需向 AI 展示几个示例，这项迁移工作就能在短短十分钟内完成。这意味着程序员能够更快地利用 AI 进行工作，而无需过分思考，任何新方法的尝试成本都相对较低。

Aman 则认为，编程中存在两种不同的思维方式。一种是深思熟虑，寻找最佳解决方案并在有限的时间内进行验证；而另一种则是直接运行代码，观察其执行结果并进行相应更新。他更倾向于后者，认为这种方法更加高效。

Lex 询问道：“那么，对于现在想学习编程的人，你们有什么建议？是学习 Java 还是 PHP？”

Aman 认为，每个人学习编程的动机各不相同。他强调，真正热爱编程的人，才会成为出色的程序员。在团队中，许多人即使在工作后仍会使用 Cursor 编写代码，有些甚至熬夜到凌晨三点去做这件事。当他们感到沮丧时，常常会说：“我需要写点代码。”以此来安慰自己。

这种对编程的热情使他们成为优秀的程序员，我相信这些人会全心投入到所研究的领域中。未来的编程者们需要更加关注“你想创造什么”。

Sualeh 补充道：“程序员可以通过更丰富的方式表达自己的意图。”

最后，Lex 引用了 Cursor 团队的宣言来总结此次讨论。在《工程天才》中，他们提到：“我们是一个应用研究实验室，致力于构建不可思议的人机协同系统。”

宣言内容指出：“我们正在培养未来的工程师，AI 程序员的效率是传统工程师的一个数量级。这种混合型工程师能够轻松驾驭代码库，无需繁琐的低熵键盘操作。即使在复杂的系统中，他们也能迅速做出判断并迭代。通过结合 AI 与人类智慧，他们将超越现有的纯 AI 系统，展现出更高的智慧与工程能力。我们是一群研究人员和工程师，专注于在有效性与可能性基础上进行创新，改善了成千上万程序员的生活。”

Lex 认为编程变得更加有趣

Lex 提到，在这次对话中，编程的乐趣得到了提升。

信息

来源：百家号

原文标题：爆火 AI 编程应用何以单挑微软？Cursor 团队 2 小时访谈揭秘

原文链接：https://baijiahao.baidu.com/s?id=1812526794643582759

声明：

文章来自网络收集后经过 ai 改写发布，如不小心侵犯了您的权益，请联系本站删除，给您带来困扰，深表歉意！