Cursor 最近很火，甚至被认为可能是取代 VS Code 的下一代代码编辑器。

Cursor 一开始就没有把自己定位在 Copilot 的角色上，团队认为，大模型会颠覆软件的开发方式，「如果只是做现有编辑器的插件，你对编辑器的控制会非常有限。」

对于和 Github Copilot 的竞争，Cursor 团队认为领先和快才是关键，「一年后的 Cursor 应该让今天的 Cursor 显得过时」。

本月初，Lex Fridman 和 Cursor 团队 4 名创始成员 Michael Truell、Sualeh Asif、Arvid Lunnemark 和 Aman Sanger 进行了一场长达两个半小时的对话，聊了聊 Cursor 的技术、产品现状、未来方向以及他们所理解的编程的未来，细节干活不少，Founder Park 进行了部分编译整理。

一些有意思的点：

• 这些大模型会不断变得更好，这将彻底改变编写软件的方式。不仅生产力上有很大提升，甚至在开发软件的方式上也会产生颠覆性的变化。如果只是做现有编辑器的插件，你对编辑器的控制会非常有限。我们不想被这些限制束缚住，我们想构建最有用的东西。

• 我认为 AI 编程中，即使你只是领先几个月，甚至一年，都能让你的产品变得更加有用。我认为一年后的 Cursor 应该让今天的 Cursor 显得过时。微软做了很多很棒的事情，但我不认为他们在创新和推动这方面处于最佳位置。

• （预测上下文）最适合的架构是稀疏模型，也就是专家模型（MoE），这是我们取得突破的地方。它在处理更长上下文时能显著提高性能。

• GPT-4 在逻辑推理上特别强大，尤其是如果你给它一些非常复杂的编程面试题，它通常能处理得很好。但相比之下，它在理解大致的编程意图方面不如 Claude。

• 有人认为 Agent 将在所有编程中都大放异彩。但我们不这么认为，因为很多编程的价值在于迭代。你可能不想预先指定某些东西，因为你在看到初始版本之前并不真正知道你想要什么，然后你想迭代它，并提供更多信息。

• 我觉得如何使用 o1 的最佳方式还没有定论。我们也还没有看到明确展示其实际用例的例子。有一些明显的方向，它可以让你更容易地在后台运行一些任务，或让模型在循环中运行，赋予它们 agent 的能力。但我们还在探索中。

01 

大模型会颠覆软件开发，

所以才有了 Cursor

Lex Fridman：能聊聊你们开发编辑器的经历吗？我知道你们都是 VS Code 的忠实用户，是什么让你们走上了开发 Cursor 的路呢？

Aman Sanger： 我觉得我们团队的很多人，嗯，实际上我们所有人，最开始都是 Vim 的用户。至少对我来说，一切的转折点是在 2021 年，当时 Copilot 出现了，我特别想试试。于是我转向了 VS Code，这是当时唯一可以用 Copilot 的代码编辑器。

Lex Fridman： 也许我们应该解释一下 Copilot 的作用。它就像一个非常聪明的自动补全工具，当你开始写代码时，它会建议接下来该写什么。这个体验很有趣，就像你跟一个好朋友聊天，他能帮你把没说完的话接上，而且接得特别好。当它表现好时，你会觉得特别顺畅。但如果它没接对，那就有点儿不爽了。

不过我得说，大部分情况下，它带给人的那种「心有灵犀」的感觉，远超偶尔出错带来的不便。

Arvid Lunnemark： 我觉得 Copilot 被低估的一点是，即使它的建议错了，也不会特别糟糕，因为你只要再打一个字符，它就可能「猜」对了。即使它没猜中，你也可以很快纠正它。

Sualeh Asif： 对，完全可以调整和修正它。Copilot 对我来说是第一个真正的 AI 产品，一个语言模型驱动的消费级产品。

Lex Fridman：那 Cursor 的起源是什么呢？

Michael Truell：差不多在 2020 年，OpenAI 发布了 Scaling Laws 的论文。那时，这领域的进展非常明确，虽然我们还不完全知道未来会怎样，但看起来只要有更多计算资源和数据，这些模型就能做得更好。

我们开始讨论这项技术可能带来的改变，想象着各个领域的知识工作者如何通过这些进步变得更高效。我觉得几个时刻特别关键，其中一个就是我们玩 Copilot 早期 beta 的时候，真的觉得很震撼，像是打开了一个新世界。接下来另一个重要时刻，是我们首次接触 GPT-3，感觉未来的一切皆有可能。

2022 年底，我们在调整模型时，进展速度快得惊人。在那之前，我们一直在做一些不同的项目。因为 Copilot 和技术的进步，我们一直在为程序员开发工具，但这些工具都比较具体。比如我们为金融行业的人开发工具，你必须在 Jupyter Notebook 上操作。

然后当 GPT-4 推出时，我们突然感觉到，之前理论上预测的未来变得非常实际了。而且我们感觉，只要保持这种速度，这不仅仅是一个单一的解决方案，未来所有编程都可能依赖这些模型。

Lex Fridman：聊聊 Cursor 本身，它是 VS Code 的一个分支，而 VS Code 是长期以来最受欢迎的编辑器之一。你当时决定，仅仅为 VS Code 写个扩展是不够的，因为在很多需要 AI 进步的地方存在限制。所以你决定改良 VS Code，开始构建许多新功能。能谈谈做这个决定的背景吗？因为已经有很多扩展，像 VS Code 的 Copilot，也在做 AI 相关的事情，为什么决定直接分叉 VS Code，做个新产品？

Michael Truell： 做出这个决定其实很自然，至少对我们想做的事情来说是这样。当我们开始研究编辑器时，我们的想法是这些大模型会不断变得更好，这将彻底改变编写软件的方式。不仅生产力上有很大提升，甚至在开发软件的方式上也会产生颠覆性的变化。如果只是做现有编辑器的插件，你对编辑器的控制会非常有限。我们不想被这些限制束缚住，我们想构建最有用的东西。

Lex Fridman：那么下一个问题是，Cursor 有点像 Copilot 的竞争对手。你们如何胜出？靠的只是开发的速度和质量吗？

Aman Sanger： 是的，我认为这是一个非常有趣的领域，也许也是非常独特的。如果你回顾过去的技术浪潮，每次重大技术进步都开启了新的公司潮流。而如今，每年随着模型能力的跃升，新的功能不断解锁，尤其是在编程领域。因此，我认为 AI 编程中，即使你只是领先几个月，甚至一年，都能让你的产品变得更加有用。我认为一年后的 Cursor 应该让今天的 Cursor 显得过时。微软做了很多很棒的事情，但我不认为他们在创新和推动这方面处于最佳位置。

Arvid Lunnemark： 是的，我认为对我们有帮助的一点是，我们把所有东西都集中在一起开发。我们在开发用户体验和如何与模型交互的同时，也在改进模型如何给出更好的答案。所以我们不仅在研究如何设计提示器，还在研究如何找到上下文、如何训练模型等。这帮助我们在整个用户体验上都保持一致。

02 

Cursor 用 MoE 解决了上下文的难题

Lex Fridman：能谈谈 Cursor 的一些功能吗？比如自动补全（Tab）是怎么工作的？

Michael Truell： 简单来说，Cursor 现在在两方面特别擅长。

首先，它像是一个非常机灵的同事，能预测你下一步会做什么。传统的自动补全就是预测你接下来要输入的字符，而 Cursor 更加雄心勃勃，不仅预测下一个字符，还预测你接下来会做的整体变化、整段代码想做什么。第二，它在帮助你指导 AI 方面也很强大，能让 AI 执行你的指令转化为代码。我们在这两方面都投入了很多精力，确保这些功能的使用体验快速、智能。

Sualeh Asif： 我们的一个目标就是希望模型能够帮助我们编辑代码。这是我们的一个愿望。在拥有一个能有效编辑代码的模型之前，我们尝试了很多次。等我们有了好模型后，我们又花了大量精力去提升推理速度，优化用户体验。我们还在研究如何让模型知道你要跳转到代码中的某个地方，比如按一下 Tab 键，模型会帮你跳到下一个需要编辑的地方。

Aman Sanger： 有趣的是，代码中的字符往往比语言更可预测。当你不仅仅是在补全代码，而是预测用户在编辑现有代码时接下来会做什么时，这种预测能力会更强。Cursor 的目标就是消除用户在编辑时那些低熵的重复操作，帮助你更快完成工作。

Lex Fridman：那么，Cursor 是如何预测的？很多人可能不太理解这个过程。

Aman Sanger：让我解释一下这些技术的运作细节。首先，延迟是非常关键的，所以我们需要在这些任务上训练非常小的模型，特别是在预填充 token 时，它们可以处理非常长的上下文，但实际上生成的 token 并不多。因此，最适合的架构是稀疏模型，也就是专家模型（MoE），这是我们取得突破的地方。它在处理更长上下文时能显著提高性能。我们还设计了一种叫「推测编辑」的变体推测解码，这也是让体验既高效又高质量的关键。

Lex Fridman：专家模型能够处理大量的输入，而输出却很小。你能再谈谈缓存的作用吗？

Aman Sanger：缓存在这里非常重要，因为你在处理大量的输入 token。每次你在某一行输入字符时，模型都需要重新处理所有的输入 token。如果不优化，你会显著增加延迟，并消耗大量 GPU 资源。所以我们设计了提示框架，让模型能够充分利用缓存。同时，我们需要跨请求重用 KV 缓存，以减少计算工作量。

Lex Fridman：简而言之，Cursor 的功能是在短期内生成代码，感觉「轻盈」，并且可以跨多行进行编辑。它还能跳转到同一文件的不同位置，甚至本地文件之间对吗？

Sualeh Asif：是的，它还可以跳转到不同的文件。如果你在一个文件中编辑，可能需要去另一个文件完成思路，Cursor 也应该能自动切换到第二个文件。

Arvid Lunnemark：这个过程可以总结为「下一步动作预测」。有时候你需要在终端里运行某个命令，Cursor 会基于你的代码建议这个命令。有时候你需要更多信息才能验证代码是否正确，Cursor 会引导你去查看所需的类型定义，然后带你回来继续编辑。

Lex Fridman：这也帮助人类更好地理解代码。你们能整合这些功能吗，比如让 Cursor 帮你完成复杂的任务？

Michael Truell：编程有趣的一点是，下一步动作有时候可以根据你刚做的事情来预测。我们正在创造这样一个世界——Cursor 不仅能够预测下一步，还能通过 Tab 键帮助你顺利完成。你只需点击几下，就能完成大的代码修改。

Lex Fridman：说到这点，Cursor 的diff界面也很酷。当模型建议修改时，你能看到红色和绿色的对比，这是如何工作的？

Sualeh Asif：我们有好几种不同的diff 界面。对于较大代码块的修改，我们有一个不同的界面，让用户能够快速浏览。当处理自动完成时，diff 界面必须特别简洁，因为用户的注意力集中在一个区域，我们不希望他们在太多地方分心。

Lex Fridman：是的，这确实是一个非常迷人的领域，尤其是在用户体验设计方面。你基本上是在试图引导程序员高效阅读他们需要处理的所有内容，确保他们集中精力在关键部分。

Arvid Lunnemark：是的，必须有一个智能模型来做到这一点。当前的 diff 算法就像普通的算法一样，没有什么智能成分。虽然在设计这些算法时用了些智慧，但并没有智能地去理解用户真正关注的内容。

Sualeh Asif：对，我觉得问题在于，随着模型变得越来越智能，它们建议的变化也会越来越大。而人类程序员需要进行的验证工作也会越来越多，这让事情变得越来越复杂。所以我们需要一些工具来帮助他们，减轻他们的负担。我也不想花太多时间在审核上。

Lex Fridman：生成步骤会变得越来越自然吗？目标是语言，而不是具体代码？

Arvid Lunnemark：我不认为所有的编程都应该是自然语言编写的。我们编程时，有时候解释自己想要的功能很麻烦，我会直接接过键盘，写出一部分代码，展示给对方看，这反而最有效。AI 也是一样的道理——有时候最简单的沟通方式是提供一个示例，而不是用语言描述一切。比如当你设计一个网站时，最简单的方式可能不是告诉 AI 怎么做，而是直接拖动、绘制页面。也许最终我们会有脑机接口，但在那之前，自然语言还是会有它的作用，只是不一定是主要的编程方式。

Lex Fridman：这个编辑器让我感觉它背后有很多机器学习。能告诉我一些让这些系统顺利运转的机器学习细节吗？

Aman Sanger：Cursor 通过我们训练的一组定制模型来发挥作用，在推理密集的任务上特别出色。例如，Cursor 的标签功能就是一个很好的例子，它比最前沿的模型表现更好。我们为不同的任务和领域定制模型，这些模型虽然有点复杂，但效果非常好。比如，Cursor 可以大致勾勒出代码的变化，这些变化是通过模型规划出来的，但精确的实现则依赖于我们训练过的模型，而这对最前沿的通用模型来说是相当困难的。

03

Claude 更理解编程意图，

基准测试不靠谱

Lex Fridman：那你们是如何让模型更快处理这些任务的？

Aman Sanger：让它更快的一个关键是使用推测性编辑。推测性编辑类似于推测性编码的概念。当你在语言模型生成时受制于内存限制，批量处理多个 token 比逐个生成要快得多。因此，我们利用一个小型模型来预测草稿 token，然后用大模型验证这些 token。大部分时候，模型会与原始代码达成一致，这样我们就可以并行处理多个行，直到模型预测出与原始代码不同的部分为止。最终，这让代码编辑的整个过程变得更加流畅和快速。

Sualeh Asif：与此同时，你也可以在代码生成的过程中实时查看和审查代码，减少了等待时间。这也是它的一个优势。

Lex Fridman：所以人类可以在代码生成完成之前就开始审查它。

Sualeh Asif：是的，推测性编辑已经在许多地方应用了，不仅仅是语言模型中。我们在 CPU、数据库等领域都能看到类似的推测性技术应用。

Lex Fridman：哪种语言模型在编程时表现得更好？Claude 还是 GPT？我猜答案可能比较复杂，因为每个部分可能适合不同的模型。

Aman Sanger：是的，确实没有哪一个模型能在所有方面都表现得压倒性好。我们通常关注的一些指标包括速度、处理大量代码的能力、编辑代码的效率、长上下文处理能力等等。

如果要选一个最强的，我现在会说是 GPT-4。我觉得这是普遍的看法。它在逻辑推理上特别强大，尤其是如果你给它一些非常复杂的编程面试题，它通常能处理得很好。但相比之下，它在理解大致的编程意图方面不如 Claude。例如，Claude 在面对更复杂、模糊的任务时，似乎更能理解你想要的整体方向，而不仅仅是针对具体问题。

Lex Fridman：实际的编程体验和基准测试之间的差异如何？基准测试的时候存在哪些不足？

Sualeh Asif：这是一个非常重要也非常棘手的问题。基准测试往往是非常具体的，问题和目标都很明确，而真实的编程环境通常更混乱、上下文依赖性更强。实际的编程任务有时候非常依赖模糊的指示或者需要模型能够推断出开发者的意图，而不仅仅是处理明确的输入。

Aman Sanger：基准测试还有另一个问题，很多基础模型可能已经在训练数据中见过这些基准的具体问题。所以在评估模型时，它们可能会凭借「记忆」给出正确答案，而不是通过真正的推理能力来解决问题。这让我们很难客观地评估模型在新问题上的表现。

Michael Truell：是的，这确实是一个问题，尤其是当我们试图通过公共基准来评估模型时，因为这些基准可能已经出现在训练数据中，模型有可能会提前知道答案。

Sualeh Asif：所以，从某种意义上来说，基准测试只是部分反映了模型的真实能力，更多时候我们需要定性评估模型的实际表现，看看它们在真实的编程任务中如何应对。

04 

并非所有编程任务都需要 Agent

Lex Fridman：你们怎么看Agent？

Arvid Lunnemark：我们认为 Agent 真的很酷。就像，我认为 Agent 有点像人类。就像你能感觉到你离 AGI 越来越近了，它就像人类一样，真的很酷。

我认为 Agent 在许多事情上还不是非常有用。但我认为我们正在接近他们真正有用的地方。所以我认为我们有 Agent 会非常好地完成某些类型的任务。就像我很想有一个经纪人一样。

确实很多编程任务，Agent 将会非常有用。有人认为 Agent 将在所有编程中都大放异彩。但我们不这么认为，因为很多编程的价值在于迭代。你可能不想预先指定某些东西，因为你在看到初始版本之前并不真正知道你想要什么，然后你想迭代它，并提供更多信息。所以对于很多编程任务，我认为你实际上需要一个能够快速给你初始版本的系统，然后你可以非常快速地迭代。

Lex Fridman：这是否在 Cursor 的开发范围内？

Arvid Lunnemark：我们现在没有积极在做这件事，但肯定是想让程序员的生活更轻松、更有趣。有些任务非常乏味，你需要经历很多步骤，你想把它委托给 Agent。然后有些事情你实际上可以在工作时让 Agent 在后台处理。比如说你有一个既是后端又是前端的 PR，你在前端工作，然后你可以让 Agent 处理后端部分。当你到达 PR 的后端部分时，你就有了一些可以迭代的初始代码。所以那也会很酷。

Lex Fridman：顺便说一下，当我想到 Agent 时，我不仅仅想到编码。我会很想智能体能帮我找 bug，不只是简单的语法错误，还有结构和方向上的问题。

Aman Sanger：是的，但是这些模型在发现错误方面表现得非常不佳，往往会很天真地去寻找错误，校准得非常糟糕。

Arvid Lunnemark：即使是最聪明的模型，即使是 o1。

Lex Fridman：怎么解释这个问题？没有好的直觉？

Aman Sanger：我认为这些模型强烈地反映了它们预训练的分布。我确实认为模型的泛化能力会越来越强，但我不认为它们能像我们日常使用的那些工具一样精准。前沿的模型在真正的代码生成和问题解答方面非常出色。这些能力广泛存在，因为它们通过大量的代码和 GitHub 数据进行了预训练，规模达到数万亿个 tokens，还有来自 Stack Overflow 和 GitHub 问题的答案。所以，当你试图去处理那些线上没有现成答案的东西时，基于迄今为止的编辑记录，这种脆弱性就会显现出来。另一个例子是错误检测，这个领域没有太多实例可以用来真正检测并修复真实的错误，模型在这方面看起来相当吃力。我认为这就是迁移模型的问题。你会看到模型的泛化效果不佳，尤其是在编码和错误检测方面。

Sualeh Asif：我想强调的是，模型对代码的理解其实已经非常好了。就像它们在预训练阶段所构建的表示一样，模型能够在某种程度上「知道」大概发生了什么事。但是模型不知道什么 bug 重要、什么不重要。

所以人类需要校准哪些 bug 真的重要。这不仅仅是说「这里有一些可疑的东西」，而是判断它的实际影响。比如，这里可能代码格式比较粗糙，它不会引发重大问题。而那边的 bug 会导致直接关闭服务器，那可就严重了。这个例子比较极端，事实上一些 bug 很多程序员也很难迅速确定优先级，这需要很丰富的经验。

Lex Fridman：对于人类来说，很难理解哪一行代码重要，哪一行不重要。我看到过一个建议说如果一段代码可能造成很大的损害，那么应该添加一条评论，说明这行代码是危险的。就像是重复「_DANGEROUS_DANGEROUS_DANGEROUS_」十次。

其实对于人类程序员也是这样的，如果不加注释人们也会忘记一些功能的重要性。

Arvid Lunnemark：是的，而且对于今天的 AI 模型，如果你在重要的内容上都写上危险，模型会更加关注这部分，并且更有可能在该区域找到错误。但其实也有争议，有些人认为它很丑。

Sualeh Asif：实际上我认为这是我从 Arvid 那里学到的东西之一，我在审美上不喜欢它。但我发现这种标注确实很实用。

05 

代码同步是个大问题，

本地小模型暂时还用不了

Lex Fridman：谈谈你们遇到的挑战？你们是一个相当新的创业公司。

Michael Truell：是的，随着每秒请求的增加，每添加一个零都会遇到新的挑战。你使用用于缓存和数据库的通用组件时，会发现随着规模的增长，各种问题不断浮现。我们现在的规模已经达到了表格溢出和类似问题的地步。我们也构建了一些定制系统，比如我们的计算检索系统、代码库的语义索引以及回答代码库相关问题的系统。我一直觉得，这些是扩展过程中最具挑战性的一些问题。

Sualeh Asif：我有几个朋友是高级工程师，他们常说，当你扩展你的系统时，真的很难预测它会在哪里崩溃。你可以提前做很多预测，但当你真正扩展时，总有一些奇怪的事情会发生，尽管你已经尽力考虑了所有因素，但总有意外发生。对于我们特定的系统，具体细节是这样的：当我们上传所有代码时，我们将其分块，然后嵌入代码并将嵌入存储在数据库中，但实际上我们并不存储任何代码。我们这样做有一些原因，特别是为了防止引入客户端错误，因为我们对客户端错误非常敏感。大部分详细信息都存储在服务器上，而且所有数据都是加密的。

技术上的一个挑战是确保本地索引、本地代码库的状态与服务器上的状态保持一致。我们最终采取的做法是，对于每个文件，保留一个哈希值。对于每个文件夹，我们也保留一个哈希值，这个值是其所有子文件夹哈希值的组合。我们递归地执行这个过程，直到根目录。

为什么要这么复杂呢？我们本可以为每个文件保留一个哈希值，然后每隔一段时间尝试从服务器下载这些哈希值，检查哪些文件在服务器上不存在。

但是，这种方式会带来巨大的网络开销。没有人会希望我们的产品不停地消耗他们的 Wi-Fi。同样，这也会对数据库造成巨大负担，比如几十 TB 的数据、每秒处理接近 20 TB 的请求，这简直太疯狂了，显然你不想这样做。因此，我们采用的方式是，只协调根目录的哈希值。如果某个哈希值不匹配，你就可以确定某些地方有问题，然后查看子文件夹的哈希值，依次类推，直到找到问题所在。我们只有在检测到不匹配时才会进行这些操作。对于大多数用户来说，大多数时候这些哈希值都是匹配的。

Lex Fridman：所以这有点像分层调和。

Aman Sanger：是的，它被称为默克尔树。

Sualeh Asif：难点在于用户的数量以及有些客户拥有非常庞大的代码库。我们不像那些已经存在了 20 年并拥有大量文件的大公司，但我们正在朝着支持许多程序员之间协作的方向扩展。在这个过程中，构建一个简单的系统很容易，但将其扩展到很多人和很多公司显然是一大挑战，这也是扩展问题的一部分。我们当前的解决方案虽然有效，但也引发了很多新的想法，过去几周或几个月我们一直在扩展和探索这些想法。

Aman Sanger：在这个索引系统中，我们采用了很多优化方案和额外的机制。瓶颈并不在于矢量数据库或数据库里不断增加的数据量，真正的瓶颈其实是在代码的嵌入上。你不想让公司里每个人都为相同的代码库重新嵌入，除非他们是在不同分支上有一些不同的文件或进行了一些本地更改。嵌入代码库的过程本身是一个瓶颈，因此我们使用了一个巧妙的技巧来优化这个过程，而不必处理分支和其他复杂的数据库问题。我们只是根据每个代码块的哈希值计算出实际的向量，并对这些向量进行缓存。所以，当公司里的第 n 个人去嵌入他们的代码库时，速度会非常快。

最重要的是，我们在完成这一切时，不需要在我们的服务器上实际存储任何代码。我们不存储代码数据，而是将代码的向量存储在向量数据库和缓存中，这大大提高了效率。

Lex Fridman：你有没有想过，为什么不在本地完成更多的工作？当你转向云时，你必须面对许多额外的问题，比如缓存和许多程序员共享同一个代码库的情况。这些都是需要解决的难题。大部分软件开发实际上都是在本地完成这些繁重计算的，那么你是否考虑过在本地进行嵌入呢？

Arvid Lunnemark：是的，我们确实考虑过这个问题，我也觉得如果能在本地完成这些工作会很酷。但实际上，这非常困难。我们必须意识到的一点是，虽然有些用户使用的是最新的 MacBook Pro，但我们的绝大多数用户都在使用 Windows 机器，而且这些机器的性能并不总是很强大。因此，基于本地的模型实际上只对那些拥有高性能计算机的人适用，而开发这样的系统会带来巨大的开销。即使我们想在本地做，目前也不是我们能够优先考虑的事情。有些团队已经在尝试这样做，我觉得很棒，但随着模型规模的不断增大，尤其是当你希望用更大的模型做更复杂的事情时，在本地运行就会变得更加困难。

Sualeh Asif：问题不仅仅是计算机性能的强弱。如果你是一家大公司，你就会有非常庞大的代码库，即使在最强大的 MacBook Pro 上，处理这些大规模代码库也是非常艰难的。这并不是一个「你是否只是个学生」的问题，而是即便你是大公司里的顶尖程序员，在本地处理这些代码库的体验仍然会非常糟糕。如果你试图在本地完成所有工作，虽然勉强能行，但会非常不愉快，不再有趣了。

Aman Sanger：是的，就像最近邻算法一样，庞大的代码库会迅速耗尽你的内存和 CPU，尤其是当它需要处理这种规模的数据时。这就是问题所在。我们也谈谈模型的架构，正如 Arvid 所提到的，本地模型面临巨大阻力。其中一个趋势是向专家混合模型（MOE）发展，尽管这对本地模型带来了一些好处，例如更好的内存带宽限制，尤其是在不依赖 GPU 时。但问题在于，这些模型整体上更大，并且通常需要跨多个节点来运行，即使是性能非常强的 MacBook 也难以承载它们。

特别是在代码生成任务中，可能并不需要清除模型的所有部分，只要能够完成任务就足够了，然后我们就可以接受这个结果了。其他任务可能也有类似的情况，或许在这些场景下本地模型能发挥更大的作用。但实际上，人们总是追求最好的、最聪明的、最有能力的解决方案，而这对于几乎所有人来说，在本地实现是非常困难的。

Sualeh Asif：还有一种选择，就是在本地运行那些开源的、对环境要求更小的模型。

Arvid Lunnemark：另外，还有另一种本地模型的可能性。我觉得它现在仍然处于研究阶段，但你可以想象用同态加密来进行语言模型的推理。具体来说，用户可以在本地机器上加密输入，然后将其发送到远程服务器。服务器可以利用其强大的计算能力运行用户无法在本地处理的模型，但它们看不到加密的数据。最后，服务器会将结果发回给用户，用户解密答案，这样只有用户自己能看到结果。

我觉得这仍然是研究领域的一部分，主要是为了降低当前非常高的开销。如果能够实现这一点，应该会非常酷。我认为这将会带来非常深远的影响，因为现在随着这些模型变得越来越强大，它们也越来越具有经济价值。世界上越来越多的数据和信息都可能流经一两个集中的公司和机构，这引发了一些令人担忧的事情。

Arvid Lunnemark：另外，这还涉及到一些安全问题。传统的黑客攻击当然是一个问题，但更令人不安的是，如果所有数据以明文形式流动，通过例如 OneNote 或类似的平台，这可能导致大规模监视。这种现象往往从看似正当的理由开始，比如为了防止坏人滥用 AI 模型，加入一些监控代码。但一旦开启这个过程，其他人可能会进一步扩展这个机制，结果可能导致用这些数据做一些坏事。所以我非常希望我们能成功解决同态加密的问题，这样可以避免这些隐患。

06

o1 怎么更好集成到 Cursor，

还没搞明白

Lex Fridman：你们怎么看 OpenAI o1？这种能在测试时进行推理的系统将在编程中将扮演什么角色？

Aman Sanger：对于预训练模型模型，Scaling law 效果拨群，但我们现在已经遇到了「数据壁垒」，因此，通过增加推理时使用的 flops 来提升模型性能，是一种有趣的方法。传统上，我们必须训练更大的模型来使用更多的 flops，但现在我们或许可以在相同规模的模型上运行更长时间，来达到大型模型的质量。

我觉得还有一点很有趣，有些问题可能需要一个拥有 100 万亿参数、训练了 100 万亿 tokens 的超大模型才能解决，但这样的问题可能只占所有查询数量的 1% 甚至 0.1%。那么，你会花费大量的计算资源去训练一个如此昂贵的模型，却只为极少的查询提供服务吗？这样做感觉很浪费。

所以更好的方法是，训练一个能够处理 99.9% 查询的模型，然后对于那些需要极高智能的问题，在推理时运行更长时间，以获得更好的答案。

Lex Fridman：如果你要构建一个能和 o1 pk 的模型，你会怎么做？

Aman Sanger：肯定是要训练一个「过程奖励模型」（process reward model）。

或许我们可以深入讨论一下「奖励模型」、「结果奖励模型」与「过程奖励模型」的区别。结果奖励模型是传统用于语言建模的奖励模型，它只关注最终结果，比如一个数学问题答对了，模型就能获得对应的奖励。

而过程奖励模型则试图对「思维链」中的每一步进行评分。OpenAI 在去年夏天发表了一篇论文，他们利用人工标注员构建了一个包含几十万条「思维链」数据的大型数据集。目前来看，除了在样本选择中起作用外，过程奖励模型还有什么应用，我还没看到。

真正让人觉得有趣、也让大家期望能起作用的是结合过程奖励模型进行「树搜索」（tree search）。因为如果你能对「思维链」的每一步都进行评分，那么你就可以分支，并对这个思维链中的多条路径进行探索，再利用过程奖励模型来评估每个路径。

Lex Fridman：是的，当分支的质量在某种程度上与最终结果的质量密切相关时。所以，你就像有一个很好的模型来知道应该选择哪个品牌一样。所以不仅仅是短期的，而是长期的。

Aman Sanger：就像我认为已经完成的有趣工作是弄清楚如何正确地训练流程，或者已经开源的有趣工作，我认为人们谈论的是如何以更自动化的方式训练流程奖励模型。但我还没有看到任何超级的东西似乎非常适合创造性地使用流程奖励模型进行树搜索。

Lex Fridman：OpenAI 曾提到他们正在隐藏模型的「思维链」，并表示这是一项艰难的决策。他们选择让模型总结思维链，而不是直接展示给用户。同时，OpenAI 在后台监控这些思维链，以确保模型不会尝试操控用户，不管怎样，你对隐藏思维链怎么看？

Michael Truell：我对 OpenAI 的一个猜测，纯属臆测，可能是他们不想让人们从他们的模型中提炼出 o1 的能力。如果你能看到隐藏的思维链，复制这项技术可能会变得更容易，因为你能够看到模型为得到最终结果所采取的每一步，这可是非常重要的数据。

Lex Fridman：那你们也可以基于这些来训练模型吗？

Michael Truell：之前也有类似的情况，虽然这只是猜测：过去，这些 API 可以很方便地获取生成 tokens 及提示 tokens 的对数概率。但后来，这个功能被移除了。依然是猜测，背后的原因可能是，如果你能获取这些对数概率，就如同看到隐藏的思维链一样，这会让你更容易从这些 API 和大型模型中提炼出其能力，并将其转移到你自己的模型中。

另外，补充一点我们之前关于整合 o1 模型的讨论：我们现在还在摸索如何使用这个模型。所以我们把 o1 整合到 Cursor 中，是因为我们一拿到这个模型就非常想试试，我想很多程序员也会很感兴趣。

o1 并不属于 Cursor 默认体验的一部分，我们至今还没有找到一种每天、甚至每小时都能在编辑器中使用 o1 的方法。因此，我觉得如何使用 o1 的最佳方式还没有定论。我们也还没有看到明确展示其实际用例的例子。有一些明显的方向，它可以让你更容易地在后台运行一些任务，或让模型在循环中运行，赋予它们 agent 的能力。但我们还在探索中。

需要澄清的是，我们确实有一些想法，只是在公开之前，我们需要确保能做出真正有用的东西。

但 o1 也有一些明显的限制。暂且不谈它的能力问题，它并不支持流式输出。这意味着，当你需要监督输出时，使用起来会非常不方便，你只能等待整段文本一次性显示。此外，这感觉像是测试时计算和搜索的初级阶段，o1 更像是一个 v0 版本，还有很多需要改进的地方。我猜想，在增加预训练数据量、扩展模型规模以及探索预训练技巧的同时，还会有另一条路径来不断优化搜索功能。

Lex Fridman：最近有传言说，GitHub Copilot 可能会以某种方式整合 o1，有一些评论说：「这是否意味着 Cursor 完了？」你们怎么看呢？现在是关闭 Cursor 的时机吗？

Michael Truell：我认为这个领域与过去 2010 年左右的软件领域有些不同，因为现在的上限真的非常高。我认为再等 3-4 年，那时候最好的 AI 编程产品可能比现在的要实用得多。

当然，你可以谈论技术壁垒、品牌优势等等，但如果你在产品创新上止步不前，就会被甩在后面。这对初创公司和想进入这个市场的人来说都是好消息，因为只要你能打造出更好的产品，就有机会超越那些拥有大量用户的竞争者。因此，我认为接下来的几年关键在于打造最好的产品和系统，不仅包括模型引擎的改进，还包括优化编辑体验。

没错，我认为 Cursor 相比其他产品的额外价值不仅仅在于能快速整合 o1 这样的新模型。更重要的是，Cursor 的定制模型在各个方面提供了深入支持，这些模型可能在你不知情的情况下默默发挥作用，每个功能都为用户体验进行了精心设计。

07

上下文足够长了会产生质变

Lex Fridman：关于上下文，当我用 Python 编写代码时，会导入一堆东西。如果想知道我想在上下文中包含哪些东西，自动找出上下文有多难？

Michael Truell：这很棘手。我认为未来我们可以在自动计算上下文方面做得更好。需要注意的一点是，包含自动上下文是有代价的。

首先，为这些模型包含的上下文越多，它们的速度就越慢，请求的成本就越高，这意味着你可以减少模型调用，并在后台执行更少的花哨操作。此外，对于许多这些模型，如果提示中包含大量信息，它们会感到困惑。因此，包含的上下文的准确性和相关性标准应该相当高。

Michael Truell：我们已经在产品的某些地方做了一些自动上下文。这是我们希望做得更好的事情。我认为有很多很酷的想法可以尝试，包括学习更好的检索系统，例如更好的嵌入模型、更好的重排序器。

还有一些很酷的学术理念，我们已经在内部尝试过，你能否让语言模型达到这样一种能力，即模型本身就可以理解新的信息语料库？大家更感兴趣的是，你能否让上下文窗口无限？那么，如果你让上下文窗口无限，你能否让模型真正关注无限上下文？然后，在你让它关注无限上下文之后，让它在某种程度上切实可行，你能否对无限上下文进行缓存？这样你就不必一直重新计算。但是，还有其他很酷的想法正在尝试中，它们更类似于在模型权重中实际学习这些信息的微调。如果你在权重级别上做更多的事情，而不是在上下文学习级别上做，那么你实际上可能会获得一种定性的不同类型的理解。

Aman Sanger：我们真的对更好的检索系统和挑选与你正在做的事情最相关的代码库部分感到兴奋。一个有趣的概念证明是使用 VS Code 直接在权重中学习这些知识。所以我们在 VS Code 分支和 VS Code 中。代码都是公开的。因此，这些预训练模型已经看到了所有代码。他们可能还看到了有关它的问题和答案。然后他们进行了微调和 RLHF，以便能够回答有关代码的一般问题。因此，当你问它关于 VS Code 的问题时，有时它会产生幻觉，但有时它实际上可以很好地回答问题。但如果专门训练或后训练一个模型，使其真正构建为理解这个代码库，会怎么样？

这是一个开放的研究问题，我们对此非常感兴趣。此外，还有一个不确定性，你是否希望模型成为端到端完成所有工作的东西，即在内部进行检索，然后回答问题、创建代码，或者你是否想将检索与前沿模型分开，也许你会在几个月内得到一些真正强大的模型，这些模型比最好的开源模型要好得多？然后，需要单独训练一个非常好的开源模型作为检索器，作为将上下文输入到这些更大模型的东西。

Lex Fridman：你提到你有一个合成数据的分类法。能解释一下吗？

Aman Sanger：是的，我认为主要有三种类型的合成数据。第一个合成数据的例子是蒸馏。你可以通过语言模型生成的输出，或者是某些令牌上的概率分布，来训练一个更小、更简单的模型。虽然这个新模型可能不如原始模型强大，但如果你想从一些昂贵且高延迟的模型中提取某些功能，蒸馏非常有用，可以让你生成特定的小规模任务模型。

第二种情况是当问题的一个方向比另一个方向更容易时，引入一个看似合理的错误往往比检测它要容易得多。一个很好的例子就是 bug 检测。这种情况在人类身上也存在。所以，你可以创建一个没有经过大量数据训练的模型，它可以生成错误的代码，然后用这些生成的错误来训练一个能够很好检测错误的模型。

第三类合成数据是由大型实验室通过语言模型生成的文本，然后你可以轻松验证这些文本。例如，假设你有一个系统能验证某些生成的文本是否达到了莎士比亚级别的标准，而你通过「猴子在打字机上打字」生成了大量文本，最后挑选那些符合标准的文本用于训练模型。这在数学领域尤其明显，因为形式语言的验证相对容易。比如，通过生成大量代码或问题，再用测试来验证模型的输出，并用那些通过测试的结果进一步训练模型。

Lex Fridman：你怎么看 RLHF（强化学习与人类反馈）和 RLAIF（强化学习与 AI 反馈）？它们在提高模型性能上有什么作用？

Aman Sanger：RLHF 是通过人类反馈标签来训练奖励模型。如果你能获得大量针对你所关心任务的人类反馈，这会非常有效。而 RLAIF 更有趣的是，它依赖于验证比生成更容易的假设。语言模型输出内容，然后你用另一个语言模型来验证它的生成内容是否正确。这种递归验证有时可能会奏效。

你还可以混合 RLAIF 和 RLHF。比如当模型做得已经相当不错时，它可能只需要一点点人类的推动，在几百个例子上，模型输出会与预期非常接近。这种方法与 RLHF 的不同之处在于，它不依赖大量的训练例子来构建奖励模型。

08

未来的编程，

不会全交给 AI

Lex Fridman：从长远看，你们处于编程世界的核心位置，编程在未来几个月、一年、五年，甚至十年里会有什么变化？

Michael Truell：我们对未来编程的发展方向感到非常兴奋。程序员将继续占据主导地位，他们将掌握速度和自动化代理的控制权，能够迅速修改他们想要修改的任何内容，并且可以从他们构建的项目中快速迭代。

有些人可能希望通过与计算机「交谈」的方式来构建软件，就像在 Slack 上与工程团队对话那样。但我们对此并不太感兴趣，部分原因是这种方法让你失去了很多控制权。当你用输入框与计算机对话时，难以做到真正的细致化。与这样的系统交流，感觉就像是在与工程团队沟通，而实际工程中涉及很多关键决策，不仅仅是写代码，还包括速度、成本和系统其他权衡的复杂决定。

我们希望人类能够继续主导软件开发，并能够在抽象层次上灵活地操作，掌控编程的细节和逻辑。这不仅仅是编程的控制权问题，还关乎效率和项目的成败。不过，确实还有很多细节有待解决，目前这更像是一个愿景，时间会证明它是否有效。但我们认为，在保持人类掌控的前提下，速度和控制权是至关重要的。

Lex Fridman：那编程的基本技能呢？现在有很多年轻人喜欢编程，从事编程。但最近几年的 AI 发展让他们有点害怕。如果他们选择了这条职业道路，未来还有保障吗？你认为编程技能会从根本上改变吗？

Michael Truell：我其实认为现在是一个非常令人兴奋的时刻来构建软件。是的，就像我们记得的 2012 年、2013 年的编程一样，那时候有更多的手工艺活和重复性代码块。你知道，那些粗糙的东西至今仍然存在，绝对没有消失。

现在编程已经比那时有趣得多了。我们真正追求的是那种快乐、专注以及所有吸引人们去编程的东西。例如，能够快速构建东西的能力，以及对个人的控制，这些都得到了极大的提升。所以我觉得，对于开发软件的人来说，这是一个非常有趣的时期。

我认为技能会有所改变。我觉得人们的品味和创意会被放大，不再是仅仅处理模板文本编辑，甚至可能也不再是那么注重细致的处理，我认为这是今天程序员非常关心的事情。

Aman Sanger：编程有时候有两种方式。一种是你非常认真地、仔细地事先思考最优方案，然后花费有限的工程时间来实现它。但我更喜欢直接进入代码，试试它的布局，然后快速迭代，这样感觉更有趣。

Lex Fridman：是的，就像用生成工具自动生成一些样板代码一样，你可以专注于那些更困难、更微妙的设计决策。迁移的过程，我觉得非常酷。大型语言模型基本上可以把一种编程语言翻译成另一种，但这都是当下的技术。我的意思是，人们可能会担心，随着这些模型越来越强大，开发者的创造性决策会越来越少。你觉得会不会有一天我们进入到一种自然语言设计的编程空间，届时自然语言会成为主要的编程语言？

比如，如果有人现在对编程感兴趣，你觉得他们应该学什么？

Michael Truell：我们起步时学习了 PHP 和 Objective-C，但现在我认为年轻人应该更多地关注 JavaScript，特别是 Vanilla JS。虽然 TypeScript 也很流行，但纯粹的 JavaScript 可能在未来会占据更多的主导地位。

Aman Sanger：编程的原因因人而异，但最好的程序员通常是真正热爱编程的人。我们团队中的一些人甚至会在下班后继续编程，通宵编写他们自己的项目，直到凌晨 3 点。

这种对编程的痴迷和热爱，是真正成就优秀程序员的关键。

文章来自于微信公众号“Founder Park”，作者“Founder Park”