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

关于Cursor团队与AI编程的深度对话

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

在10月10日的更新中，智东西提到，10月7日那天，知名播客主持人Lex Fridman与Cursor团队的四位创始人，Michael Truell、Sualeh Asif、Arvid Lunnemark和Aman Sanger，进行了一个长达两个半小时的深入对话。

你可能感兴趣：程序员如何巧妙运用 cursor 编写高效代码？- 老久 的分享

Cursor是一个基于VS Code的代码编辑工具，它为AI编程带来了不少强大的新功能，最近在编程和AI圈子里引起了不少关注和讨论。那么，作为一家初创公司，Cursor怎么能够在微软的GitHub Copilot面前立足呢？

在这期播客中，几位创始人深入探讨了Cursor的发展情况以及未来的计划，还聊到了编程的未来，以及人类与AI之间在设计和构建复杂系统时的合作潜力。

他们详细分享了Cursor如何分析用户的代码库，从而预测下一步的操作，并迅速生成代码，大大提高了编程的效率。

此外，团队还介绍了Cursor的其他功能，不仅能自动补全代码，还引入了影子工作区，辅助编写代码。用户只需简单描述，AI就能帮助完成更复杂的任务。

更有意思的是，团队成员对AI编程的技术要点进行了深入分析，并探讨了人类与AI编程之间的伦理问题，还提到希望能将OpenAI的o1模型集成进来。

最后，值得注意的是，团队成员强调了“快速就是有趣”（Fast is Fun）的理念。他们认为，吸引人们在电脑上创作新内容的原因之一，就是那种惊人的迭代速度。在编程的世界里，只要你有计算机，就能迅速创造出令人惊叹的成果，而不会受到其他领域的资源或能力限制。

快来了解Cursor团队和代码编辑器的有趣之处！

在Cursor的创始团队中，Aman Sanger是CEO，他是一位工程师兼企业家，之前在Instagram和Facebook担任过重要职务。公司的CTO是Arvid Lunnemark，他同样是一位工程师，曾在Spotify和Google工作。此外，Michael Truell负责设计，而Sualeh Asif则是公司的首席运营官。

▲在播客中介绍Cursor团队的成员（

接下来，我们将为大家带来这期播客内容的完整整理。为了让大家更好理解，智东西对部分问答进行了调整，也进行了适当的增删修改，但没有偏离原意哦。

一、代码编辑器的功能远超文字处理器

Lex：那代码编辑器到底有什么用呢？

Michael：其实，代码编辑器就是用来构建软件的地方。过去很久，这个工具主要是针对正式的编程语言进行文本处理。对于不太熟悉编程的人来说，可以把代码编辑器看作是程序员的升级版文字处理软件。之所以称它为升级版，是因为代码的结构相对复杂，因此这个“文字处理器”能做的事情远远超过传统软件的能力。

例如，它可以让代码中的不同元素通过视觉效果区分开，方便快速浏览；用户可以直接在代码库中进行导航，快速定位到正在使用的内容，类似于浏览网页时点击超链接；还可以进行错误检查，及时发现基本问题。传统上，这就是代码编辑器的功能。不过，我认为，随着未来软件构建方式的变化，代码编辑器的定义也会大幅度演变。

Lex：我觉得代码编辑器的设计也应该充满趣味性啊！

构建有趣工具的秘密：快速迭代和灵感来源

Arvid：没错，这点非常关键。其实，这也是我们在决定要开发什么时常常被忽视的一环。很多时候，我们试用一些东西，实验后发现它们没什么趣味，于是就把它们淘汰了。因此，能让人觉得有趣的一个重要因素就是速度。快速的过程本身就充满了趣味。

Michael：基本上，我认为让很多人愿意在电脑上创造内容的原因之一，就是这种惊人的迭代速度。在其他领域，你可能会受到资源或能力的限制……而且，能够单独与电脑配合编程，迅速创造出很酷的东西，真是太神奇了。

二、从Copilot的粉丝到开发Cursor，Cursor起源的两个重要时刻

Lex：对于不太了解的人来说，Cursor其实是一个超级棒的新编辑器，基于VS Code开发的。听你们讲述自己在编辑器上的经历一定很有趣。你们都是VS Code和Copilot的忠实粉丝吧？你们是怎么接触到VS Code的？这又是如何引导你们迈向Cursor的呢？

Aman：其实，我们最开始都是Vim的死忠粉。没有Neovim，只有纯粹的Vim和终端。至少对我来说，当Copilot在2021年发布时，我特别想试试。于是我开始使用VS Code，因为那是唯一可以用Copilot的编辑器。尽管我非常喜欢Vim，但VS Code和Copilot的使用体验让我决定转变，所以这就成了我默认的选择，直到我们开始开发Cursor。

Lex：也许我们该简单介绍一下Copilot的功能。它是一款非常棒的自动补全工具，当你开始写代码时，它会给出一到三行的建议，体验相当有趣。就像和好朋友聊天时，他们会帮你接下去一样。当它理解你时，会有种很亲密的感觉。虽然“亲密”这个词可能用得不太准确，但确实有种“哇，它懂我”的酷炫体验。然而，当它不能理解你的意思时，可能就会让人有些失望。但我觉得，对很多人来说，那种“它懂我”的感觉是压倒性的，远超过“它不懂我”的不快。

Arvid：我觉得GitHub Copilot常常被低估的一点是，尽管它偶尔会出错让人有点烦，但其实也没那么糟糕。因为你只需再输入一个字符，或许它就能明白你的意思。所以，即便它偶尔出错，也不会让人太失望。

Sualeh：你可以进行迭代和修正。我想说，Copilot还有一个被低估的地方，就是它是第一个真正的AI产品，还是消费者第一款语言模型产品。

Lex：所以说，Copilot的确是语言模型领域的首个杀手级应用。

关于Cursor的起源故事，你知道多少？

Michael：没错，它的beta版本是在2021年推出的。

Lex：那Cursor的起源是怎么回事呢？

Michael：大约在2020年，OpenAI发布了一篇关于“规模法则”的论文。这是一个转折点，那个时候这个领域似乎开始有了可预见的进展。即使没有新的创意，只要计算能力和数据量增加，模型就能变得更优秀。

Lex：顺便提一下，这个“规模法则”的话题我们可以聊上三四个小时。不过简单来说，这篇论文是众多研究中的一部分，它提出了一个观点：在机器学习中，模型和数据越大，效果越好。

Michael：在那个时期，我们中间有很多关于这项技术如何影响不同领域工作的讨论。对于各行各业的人来说，这项技术的进步会怎样改善他们的工作呢？我认为有几个时刻，那篇论文里提到的理论进展逐渐变得具体化，让人感觉在AI领域可以实际做出有用的成果，而不必非得攻读博士。就像是构建一个完整的、真正有用的系统的感觉。我觉得最初的时刻是试用Copilot的早期版本，那种体验真是令人惊艳。感觉太棒了！

第二个重要时刻则是我们提前体验了GPT-4。大约在2022年底，我们开始对这个模型进行调整，能力的提升让人感到震撼。在那之前，我们一直在尝试不同的项目。因为有了Copilot，结合“规模法则”和我们对这项技术的浓厚兴趣，我们在修改程序员使用的工具，但那些工具都很具体。我们甚至为需要在Jupyter Notebook上工作的金融专业人士开发工具，或者尝试用这些模型进行静态分析。

而GPT-4的更新确实证实了我们之前的理论预判。那一刻，感觉你可以立刻构建许多东西。而且，如果我们继续保持这个势头，这不仅是某个小问题的解决方案，而是将改变整个编程领域，所有的编程都将与这些模型紧密结合。这也让我们意识到，未来需要一种全新的编程环境和方式，因此我们开始构思更广阔的愿景。

Sualeh：我记得有件事特别让我印象深刻，我的室友是IMO金牌得主。在美国有个叫Putnam的比赛，类似于大学生版的IMO，也是个数学竞赛，真的是精彩无比。我记得在2022年6月左右，Shengtong和Aman还打了个赌，赌能否在2024年6月或7月的IMO中赢得金牌。

关于IMO和数学竞赛的那些事儿

Lex：你知道吗，IMO其实是国际数学奥林匹克的简称。

Sualeh：我和Arvid也参加过这项赛事。虽然我一度对进步保持信心，但说实话，我觉得Aman想赢得IMO金牌有点天方夜谭。不过，后来我发现我错了，这可能是团队中最具远见的赌注了。

Aman：我记得和Michael有一次聊天，之前我对scaling laws的理解还不够深入。他问我，为什么scaling laws是你所需的一切，或者说，它们为何不会引领重大的突破？这让我经历了五个悲伤的阶段，最后终于接受了这个事实。

从那以后，我对未来的进步充满了期待和乐观。值得一提的是，进步的方向也非常关键。数学领域尤其适合这一点，特别是在进行定理的形式化证明时，这样你能清楚地验证结果是否正确。这意味着像强化学习这样的技术可能会非常有效，尽管在技术层面上，可能还无法实现真正的AGI。

三、Cursor的未来：或将改变软件构建方式

Lex：接下来，我们来聊聊Cursor吧。

Michael：我们决定开发一个编辑器，这对我们来说是显而易见的选择，尤其是考虑到我们想要达成的目标。因为当我们开始做这个编辑器时，我们的想法是，这些模型会不断进步，能力会提升，从而彻底改变软件的构建方式。这样不仅能大幅提高生产力，还会在根本上改变开发软件的方式。如果你只是现有编程环境的一个插件，受限于代码编辑器的功能，那就太不自由了，我们希望拥有更大的创造空间。

Lex：听说Cursor和Copilot在某种程度上是竞争对手，你们打算如何取胜呢？是靠速度和功能的质量吗？

Aman：没错，这确实是一个相当有趣且独特的领域。看看以往的技术浪潮，通常只有一项技术会引发一波新公司的崛起。但每年模型能力的提升，都会开启一系列新的功能，尤其是在编程领域，可以实现的可能性大大增加。

我觉得在AI编程的世界里，即使只领先几个月，也能让你的产品变得更有价值。我相信，一年后的Cursor会让今天的版本显得过时。虽然微软做了很多出色的工作，但他们的创新空间不如初创公司那么灵活，推动发展的能力也会有限。

聊聊Cursor的未来和创新

Sualeh：我一直在想，我是从功能方面考虑，还是从程序员的能力出发呢？随着新o1模型的发布，我相信会出现更多类型的模型，比如那些上下文更长的，或者反应更快的。其实你可以尝试各种疯狂的点子，希望其中10%能变成一些既酷又实用的东西，我们希望大家能更快地获得这些新技术。换句话说，其实我们正是在为自己创造这些可能性。

当我们开始打造Cursor的时候，真的会让人感到沮丧。你会看到模型在不断进步，但Copilot的使用体验却没有太大变化。就像是，这些大公司在技术上越来越高，但为什么不去创造一些新东西呢？那些Alpha功能到底在哪儿？结果却是没有。如果真的推出了新功能，我相信这会是一门好生意。我确实非常想尝试和使用新事物，但很久没有看到什么新鲜的东西了。

Lex：说到Cursor和Copilot的比较，Copilot最近给人感觉有些过时了，可能是因为某些原因。

Arvid：我觉得我们做的一件很棒的事情就是把所有的工作都整合在一起。在开发用户体验和与模型互动的过程中，我们也在想办法让模型给出更好的答案。这就包括了如何构建提示，如何找到上下文，以及如何训练Cursor Tab的模型。我认为这让我们能够把同一团队负责整个体验。

Sualeh：没错，就像是做UI的和训练模型的人，实际上距离很近，甚至常常是同一个人。这样的话，可以创造出很多如果不进行沟通和实验就无法实现的东西。

Lex：你们是不是用Cursor来写Cursor本身呢？

Arvid：当然可以。

Lex：我们来聊聊那个无所不能的Tab，简直是增强版的自动补全。这个Tab到底是怎么工作的呢？它是什么？

让Cursor Tab助你轻松编程，告别繁琐操作

Michael提到，Cursor在某些方面做得相当不错。虽然它还有其他功能，但这两项对程序员特别有用。首先，它就像一个随时在你身边的同事，能迅速预测你接下来想做什么，帮助你加快输入速度。这其实是自动补全功能的本质，不仅能猜测你后面要输入的字符，还能预见你需要修改的整体内容、下一步的变化以及要跳转的具体位置。

其次，它能帮你在某些情况下领先于AI，明确指示它该执行什么，从而实现指令到代码的顺利转换。为了达成这两点，我们在提升编辑体验上下了不少功夫，确保它既符合人机工程学，又足够智能和迅速。

Cursor Tab：强大的自动补全功能，减少编辑器操作的繁琐性

Sualeh表示，我们的目标是让模型能独立为我们编写代码。为了实现这个愿望，我们在拥有高质量的代码编辑模型之前经历了多次尝试。现在有了这样的模型，我们致力于加快推理速度，以确保使用体验更加流畅，并已开始进行整合。

Michael刚才提到的跳转能力，其实源自一种直觉：一旦你做出编辑，接下来要去的地方应该是显而易见的。例如，如果我做了某个更改，模型就应该知道我接下来要去第18行。如果你是WIM用户，可能会用一些快捷键来跳转，但为什么不让模型直接知道呢？

所以，你只需按一下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界面的展示。模型用红色和绿色来显示我们将如何修改代码，然后可以在聊天窗口中应用这些修改，系统会向你展示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展示你想要的最简单方式，可能不是直接告诉它该做什么，而是通过拖动或绘制东西。也许未来我们会有脑机接口这样的技术，可以直接让AI理解我们的想法。所以我认为，虽然自然语言会有它的位置，但我敢肯定，它不会成为大多数人编程的主要方式。

六、定制模型的应用差异，优化token使用让模型更聪明

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达到一定量后，我们会重新开始按代码块进行预测。

这实际上就像是一个更快的代码编辑版本。看起来好像模型在快速重写所有代码。因此，我们可以使用与diff相同的接口，但流传速度会快得多。

七、GPT和Claude在编程上哪个更胜一筹？

Lex：那么，哪个大语言模型在编程上更厉害一些呢？是GPT还是Claude？

编程模型的对比与提示的重要性

Aman：其实啊，我觉得没有哪个模型能在我们认为重要的方面完全压倒其他，比如速度、代码编辑能力、大量代码处理、长文本理解等等。综合来看，我认为Sonnet是目前表现最好的，大家都差不多这么认为。

o1也挺有意思的，它在推理方面特别强。你有没有发现，给它一些难度较大的编程面试题或者复杂的代码问题时，它能应对得很好，但在理解你的整体意图上，似乎没有Sonnet来得灵活。如果把目光放在其他很多前沿模型上，我有个小疑虑，就是感觉它们的表现并不一定如预期……我并不是说它们在基准测试下的训练不好，实际上它们在这些测试中表现得相当出色，相比之下，它们在其他方面的表现就有些不稳定。

所以说，如果你尝试所有这些基准测试，结果往往都不错。不过，一旦把这些模型稍微推向其他领域，Sonnet在保持能力方面做得相对更好。你在测试中看到的能力，跟让它执行任何编程相关任务时的能力，其实是不一样的。

Sualeh：顺便提一句，这里有个很重要的点，基准测试和真实编程之间的差别，其实是很大的。真正的编程可不是那种面试时的风格。人类有时候说话不太标准，有时候会说：“就像我之前做的那样。”或者“加上这个，然后帮我做点别的，再做个UI元素。”很多时候，事情都得依赖上下文。你希望能理解人类的意图，并按他们的想法去做，而不是……面试问题往往是很明确的，而人类的表达却不那么清晰。

Aman：关于Claude，我听说过一个有趣的观点，AWS的芯片和Nvidia的GPU似乎有些不同，有人猜测Claude性能不如预期可能与在AWS Bedrock上用的量化版本和Anthropic的GPU版本不同有关。

八、Preempt系统的自动化效果

Lex：在这个过程中，提示的作用到底有多重要呢？

Arvid：这其实要看你用的是哪个模型，它们在对待不同提示时的反应差别很大。不过，我觉得最初的GPT-4和去年的一些模型对提示是非常敏感的，而且它们的上下文窗口相对较小。因此，我们有很多与代码库相关的信息，这些信息在提示中可能会很有帮助。

你有文档、添加的文件、对话历史，这些内容都在，而问题是，你该如何决定到底哪些信息要放进提示里，特别是当你空间有限的时候？在如今的模型中，即使有较长的上下文，填满整个窗口也可能导致速度变慢。有时模型甚至会因此感到困惑，而有些模型比其他模型更容易陷入这种困境。

如何在有限空间内优化信息提示

其实，我们有一个叫做Preempt的内部系统，它在这方面给了我们不少帮助。可以这么说，它是为我们那种拥有8000个token的上下文窗口而设计的。就像你在做网站时，希望它在手机和电脑上都能正常使用，但又没有一个固定的布局，得灵活应对各种动态信息。

打个比方，如果你在设计一本杂志，版面是固定的，你清楚每个元素该放在哪里。然而，当你在构建一个网站或者提示时，输入的信息可能会很多，这时候就得想办法把这些信息格式化，确保它们始终能够正常显示。你可能还得删减一些内容，所以我们想，何不从这种情况中寻找灵感呢？

那么，设计网站的最佳方式是什么呢？我们特别喜欢使用React的声明式方法。你可以在JavaScript中使用JSX，直接声明你想要的效果，比如哪个部分更重要，或者在Z轴上的优先级。在网页设计中，有个渲染引擎，比如Chrome中的preempt渲染器，它会把所有内容呈现在页面上。你只需告诉它你想要的效果，渲染器就会自动帮你实现。我们发现这种方法非常实用，而且随着时间的推移，它的应用效果也在不断变化。

最开始，这种方法是为了适应较小的上下文窗口而设计的，现在它在处理提示词的数据和实际生成上也变得更加重要。这样一来，调试也变得更简单了。你可以修改提示词，然后在旧的设置上进行测试，直接看到你的修改是否真的提升了效果。

Lex：你们是用JSX来做提示的吗？

Arvid：没错！我们有一个文件组件，它会接收光标的位置。通常在文件中，光标所在的那一行是最重要的，因为那是你正在查看的内容。通过这种方式，你可以设定优先级。如果你有很多来自代码库的代码块，你还可以通过检索和嵌入等方式，重新排序来提升这些组件的优先级。

Lex：那么，当人类提问时，也应该尝试用这样的方式吗？这是否意味着问题会变得模糊和混乱，还是说这样的系统反而能鼓励人们更清晰地表达？

Arvid：我觉得我们的目标是让你做最自然的事情，而我们的任务就是找出如何有效检索到相对重要的信息，这样你的思考才会有意义。

探索AI助手的潜力与挑战

Lex：模型选择和一般回应之间的差别有多大呢？其实这还真不简单，我们要如何处理那些不确定的情况？我是不是应该再多问点信息，以避免产生歧义呢？

Sualeh：最近我们为Cursor增加了一个新功能，可以加入文件。当你在编辑代码或者输入内容时，模型会尝试猜测你在做什么。如果它发现有些地方不太确定，它会推测你可能是在编写某种API。接着，模型会查看你的历史记录，找出哪些文件和你目前的编辑内容相关。

这其中有个技术难题，就是如何从所有历史记录中筛选出关键的信息，判断哪些文件在当前提示下最为重要。虽然这个功能现在还在测试阶段，但我们有信心会逐步改进它。你有没有想过，是否希望模型帮助你编辑的时候加入这些文件？

假设你在写一个API，那么你也得考虑同时编辑使用这个API的客户端和服务器代码。API一旦有变化，客户端和服务器的代码也得跟着调整。

Cursor可以在你编写提示或代码时，提前帮你找到那些可能需要一起修改的部分。这么做的好处在于，可以在你按下回车前就解决一些不确定性，确保所有相关代码都得到正确更新，而不需要你一个个去查找和同步这些改动。

接近AGI时代，但AI助手尚待实用

Lex：你们觉得AI助手怎么样？它们的实用性到底如何？

Arvid：我觉得AI助手就像是人类的缩影，你会感觉到我们越来越接近AGI，因为看到它们的演示时，仿佛在和真人交流，真的很酷。不过，我认为AI助手在很多场合下还不是特别实用，但我们正在逐步迈向它们能真正发挥作用的那一天。

所以，对于某些特定的任务，AI助手能派上用场。举个例子：如果有个bug，有时候你在聊天框里无法用Command+C和Command+V，这就是个很明确的任务。我只需要说两句话：“这个有问题，请修复。”那时候我会非常希望有个AI助手，它能自动去修复这个bug，然后我再回来查看修复的结果。

想象一下，AI助手能帮你搞定编程烦恼

你能想象吗？一个AI助手会帮你找到正确的文件，重现那些烦人的bug，修复完再检查一下结果。听起来挺不错吧，但这个过程可能耗费不少时间。说实话，我觉得这样的助手能让我大大减轻负担。

很多人都觉得这些智能Agent会把编程工作全盘接手，但我可不这么认为。其实，编程的很多价值在于不断的迭代。你一开始也许并没有明确的目标，直到看到第一个版本后，才会明白自己想要什么，然后再逐步完善。

所以在不少编程任务中，我觉得你需要的是一个能快速生成初始版本的系统，这样你就能迅速进行修改和优化。

Lex：最近推出的Replica Agent可是个好例子，它能帮你设置开发环境，解决软件包问题，甚至配置数据库和部署应用。这是不是你梦想中的助手呢？

Arvid：是啊，尤其是对某些编程任务来说，这简直太酷了。

Lex：那这和Cursor的功能相关吗？

Arvid：嗯，虽然我们现在并没有专门在做这方面的工作，但我们的目标是让程序员的生活更轻松、更有趣。毕竟，很多任务都挺无聊的，需要经过一系列繁琐的步骤，为什么不让Agent来处理呢？这样你就可以在后台处理一些事情，比如说同时管理前后端的Pull Request（PR），在你忙着前端的同时，后台的Agent已经开始处理后端部分，等你转到后端时，初步的代码就已经准备好了，真是太棒了。

十、影子工作区，让代码在后台运行

Arvid：首先，我们希望能在后台完成更多的任务，实际上我们正在尝试各种新方法。目前除了缓存预热和找出命令键提示需要的上下文外，后台操作还不算多。但是

如果能够在后台进行计算，那将有助于你预测更长时间内的任务，而不仅仅是你即将编写的几行代码。

我们希望能够预测你接下来10分钟内可能会做的事情。通过后台计算，我们可以利用更多计算资源来实现这一点。所以我们正在实施影子工作区（Shadow Workspace）的概念，并在内部进行实验，目的是充分利用后台计算的优势。我们需要给模型反馈信号，这样才能通过让模型在思考更长时间来提高性能，比如o1就是个很好的例子。

让AI更聪明：如何通过语言服务器提升编程体验

其实，有一种方法可以让模型变得更有效，那就是让它们进行反复练习并及时获得反馈。对程序员而言，语言服务器是个非常重要的反馈工具。几乎所有编程语言都有自己的语言服务器，它能告诉你“这里的类型用错了”，还可以提供错误提示，甚至帮你跳转到定义，理解代码结构。比如，TypeScript和Rust的语言服务器分别是由它们各自的团队开发的，它们都通过语言服务器协议与VS Code互动。这就意味着，VS Code不需要内置每种语言，而是可以利用已有的编译器架构。

这样做的目的是为了确保代码的质量，比如检查代码、跳转到定义以及确认你使用的类型是否正确。尤其是在处理复杂的大型项目时，类型检查和引用查找功能是必不可少的。缺少这些工具，编写和维护代码会变得相当麻烦。

Lex：那么，在Cursor中，我们是如何利用语言服务器协议进行交流的呢？

Arvid：在Cursor中，我们用语言服务器协议向程序员提供信息，就像在VS Code那样，但我们还想把这些信息展示给智能模型，并且希望在后台完成这一切，让用户在操作时不受干扰。

我们设想的影子工作区就是这么一个地方，你可以在里面设置一些标志，然后把这个窗口隐藏。虽然你看不见它，但它确实在那儿。AI Agent可以在这个窗口中自由修改代码，只要不保存这些更改，因为它依然处于同一个文件夹内。这样，它们就可以从代码检查工具那里得到反馈，跳转定义，并对代码进行不断迭代。

这正是我们想要达成的目标，也是我们这篇博客的核心讨论内容，尽管实现起来有些挑战。我们的理想是让这一切能够在用户的机器上运行，完美模拟用户的环境。在Linux上，我们可以做一些很酷的事情，比如镜像文件系统，允许AI在文件级别操作，尽管这些操作其实都是存在于内存中的。我们甚至能开发出类似内核的扩展来实现这些功能。而在Mac和Windows上，情况就复杂得多，但这也是个有趣的技术挑战，因此我们仍在积极研究。

Aman：一个或许有点粗糙但很有趣的想法是对保存操作进行锁定。这样一来，语言模型在保存文件时会被锁定，从而让你不必直接操作真实文件，而是跟影子工作区中的未保存内容打交道。你依旧可以接收错误提示，并在其中进行代码编写。当你尝试运行代码时，会弹出一个小提示，告诉你有锁存在，这时你可以选择从语言服务器或影子工作区中释放锁，以便进行其他操作。

模型调试依旧艰难，Open o1也面临挑战

Lex：让模型能够修改文件，这确实是一个令人兴奋的未来，尽管也有些令人紧张。想象一下，AI Agent能自动完成一系列任务，第二天你只需审核结果，AI就像你的得力助手一样。

关于编码助手的思考

Aman：我觉得模型在运行时的表现会有很多不同的情况。简单的任务用户通常能在几分钟内搞定，甚至在本地机器上运行也是很方便的。但如果是一些耗时长、变动大的任务，那就得在远程的沙盒环境中处理了。要想在远程沙盒里准确重现用户的操作环境，并确保代码输出一致性，这可真是个挑战。

Sualeh：我很好奇，你们希望这个编码助手能做些什么呢？是帮你们找漏洞，还是实现新功能呢？

Lex：在编码方面，我觉得最重要的是关注各种bug的查找，尤其是逻辑错误和方向性错误。

Aman：不过说实话，这些模型在简单提示下并不擅长发现错误。它们的校准效果很差，就连最先进的o1模型也是如此。

Lex：能给我详细说说吗？

Aman：我认为这些模型能很好地反映出预训练数据的分布，随着损失函数的降低，它们的泛化能力也在不断增强。但现在损失函数降得足够低，以至于模型能够实现全面的泛化。我们主要是在前沿的领域使用这些模型，进行代码生成和问题回答。在预训练阶段，GitHub上有大量的代码，数量达数万亿个token，Stack Overflow和GitHub Issues上也有很多问题和答案，为我们的任务提供了丰富的数据。

不过，当你想尝试一些不常见的事情，比如根据已有的编辑来预测下一个Cursor Tab目标时，模型的缺陷就会暴露出来。

再比如bug检测的例子，实际上很少有真实的bug检测和修复建议的案例，所以模型在这方面会面临很大的挑战。

我认为，这其实也是个模型迁移的问题。我们需要将其他模型迁移到Cursor Tab上，而把那些在代码上表现优秀的通用模型转移到bug检测任务上，效果应该会不错，只是需要我们稍微引导一下。

代码安全与标注：专家们的看法

苏莱赫：我觉得这些模型对代码的理解还是蛮深刻的。在预训练的时候，它们或许就已经能够大概识别出代码里的问题。这也得益于一些人对这些错误进行了细致的校准。

不过，当我们使用模型来编程，像是写数据库那样庞大的信息时，即使有严格的校准措施，错误的修正依然可能很棘手。

关于危险代码的标注，开发团队似乎不太买账

莱克斯：人类自己在判断代码的重要性上也常常感到困难。如果某行代码可能引发严重后果，那就应该在旁边加个注释，告诉大家“这行代码是危险的”。

阿维德：就这样全大写写十遍，大家都知道了。

莱克斯：对啊，就算是同一个人，也可能会忘记某些代码的潜在危险性。

阿维德：我觉得这种情况在今天的AI模型中也同样适用。如果我们在每一行代码旁边都标注上“危险”，那么模型会更关注这些部分，发现错误的几率也会增加。

莱克斯：明确标注代码的潜在风险其实是个不错的做法。

阿维德：可是这方面也存在一些争议，比如苏莱赫就不太赞成这种做法。

苏莱赫：从美观的角度来看，我并不太喜欢这样做，但确实能帮助模型以及那些容易忘记代码风险的人，避免小错误导致大问题，比如服务器宕机。

阿曼：没错，即使是普通的文档字符，在修改代码时，人们也常常会忽略潜在风险，所以我们还是需要明确指出这些风险。

关于代码修改和规范生成的对话

Lex：说实话，很多人在改代码的时候，往往只想着怎么把功能做得更好，却很少关注背后可能隐藏的风险。

Arvid：如果我们能对所有代码进行形式化的验证，那就能够确保不会引入任何错误。

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的安全性。

未来的代码检查：希望与挑战

Lex：既然我们在找bug这方面遇到了一些麻烦，那接下来的希望在哪里呢？

Sualeh：我觉得，首先模型应该能帮我们发现一些简单的bug，比如那种常见的“少加一”错误，或者注释和代码不一致的情况。最终目标是让模型能够捕捉到更复杂的bug。

Michael：要实现AI编程，强大的bug检测模型是不可或缺的。如果AI能自动写代码，那同样也得有能力验证这些代码的准确性。这不仅是为了辅助人类程序员，同时也为了确保AI生成的代码没问题。

Arvid：没错，但具体该怎么做呢？听说一个流行的观点是，制造bug比找bug简单得多。于是可以先训练一个模型，故意引入一些错误的代码，然后再用这些“错误”的数据去训练一个能找出bug的模型。这听起来是个不错的思路。

Michael：我们还可以利用大型模型和其他信息来帮助查找bug，比如通过代码的执行轨迹和调试器的信息。其实，bug查找工具可能会有两种不同的形式：一种是运行在后台的快速模型，用来发现常见的bug；另一种是针对特定bug的高计算量模型，用户可以为此支付一定的费用。

Lex：有没有想过用资金把这些整合起来呢？如果模型能帮我找bug或者生成高质量的代码，我是愿意付费的。前几天，我用Cursor模型生成了三个非常完美的函数，专门用来和YouTube API互动，帮我提供多语言的字幕更新功能。

API文档其实不太好用，代码之间还有交叉问题，我通过谷歌搜索也没找到准确的信息，只有一些混乱的内容，而Cursor生成的代码则非常靠谱。我真希望能有个“打赏”按钮，标注“5美元”，既能支持公司发展，又能给模型发个积极反馈，比如“干得不错”。在bug查找方面，也可以引入这种赏金机制。你们考虑过吗？

讨论程序付费机制与用户体验

Arvid：公司内部对此有不同看法。我觉得这其实和你对人性的信任程度有关。如果你能在不花钱的情况下发现一个bug，那真是太好了！不过如果没发现，那也就没必要掏钱。要是你花了钱却找到了bug，点了“接受”后，系统就会在括号里显示，比如说1美元。

当然，大家可能会担心，我们在这个过程中投入了不少精力，也许有些人会选择复制粘贴代码，或者是付费机制影响了用户体验。我觉得可以考虑把收费和产品功能分开，用户每个月支付一定的费用，就能享受所有功能。

Lex：其实可以考虑搞个“打赏”功能，不一定要强制收费。

Arvid：打赏也是涉及金钱，可能会对用户体验产生影响。

Aman：当用户分享模型时，实际上他们已经在表达对模型的认可。

Michael：如果能研发出一种技术手段来确认bug是否已经修复，那就不必依赖荣誉制度的赏金机制了。

十三、AWS基础设施的可靠性几乎无可挑剔

Lex：终端和代码间的互动有多少呢？在终端运行代码能获取多少信息？能否建立一个循环，让模型运行代码并提供修改建议？目前代码和实际运行之间是否完全分开了？据我了解，可以在终端使用“Ctrl+K”来帮助编写代码。

Aman：在Check命令和Ctrl+K中可以利用终端的上下文信息。不过目前还没有实现循环功能，这个想法挺不错的。关键是，这个循环是前台进行还是像以前那样在后台进行。

Lex：后台运行确实很有趣，因为它能支持多种代码运行方式。另外，还得考虑数据库的问题，比如怎么防止模型对数据库进行修改。

聊聊Cursor的挑战与解决方案

Sualeh：我觉得有个不错的解决方案正在酝酿中，正在开发的新API可能会让PlanetScale和Turbopuffer这两种数据库都支持这项功能。其实，当你在开发新功能并测试数据库时，不想每次都去搞大动干戈地修改主数据库，倒不如给它加个分支，这样就能省去不少麻烦。

这种技术的实现方式其实是为数据库的预写日志添加分支，听起来是不是很酷呢？数据库公司总要不断创新，而这种分支功能未来可能会成为一种趋势，甚至AI代理也能通过这些分支来进行测试。

Lex：我想问问，Cursor团队现在主要是依赖AWS（亚马逊云科技）吗？在使用过程中遇到了什么难题呢？

Arvid：AWS真的很不错，无论什么时候用它的服务，基本上都能顺利运行，虽然设置过程可能搞得人有点崩溃。说实话，AWS非常可靠，如果有什么问题，那大概率是你这边的原因。

十四、扩展问题成了公司成长的隐患，隐私保护也亟需突破

Lex:你们作为一家初创公司，在发展过程中遇到了哪些挑战呢？

Michael：随着请求量的不断增加，像缓存和数据库这样的通用组件难免会遇到瓶颈。比如说，现在我们已经碰到了数据表溢出的问题。而且，我们自己设计的一些系统，例如用于代码语义索引和问答的检索系统，回答代码库相关的问题，这也是扩展过程中相当棘手的一块。

Sualeh：我有一些超级厉害的工程师朋友，他们常常说，扩展过程中最难的就是预测系统会在哪里出问题。你可以提前做些预测，但当开始添加新内容时，总会有意想不到的事情发生。具体来说，Cursor会把所有代码分块，然后发送这些块进行嵌入，最后把嵌入后的代码存储在数据库中，实际上并不保留任何原始代码。接下来，我们还得确保不引入客户端的bug，因为这可是我们非常重视的。服务器上存储了很多细节，而且都是加密的。

所以，技术挑战之一就是要保证本地代码库的状态和服务器端是一致的。从技术上讲，我们的方法是下载服务器端的哈希值，然后和本地的哈希值对比，计算出差异，以确定哪些文件是缺失的。不过，这样会增加网络负担。如果你用Cursor，谁也不想让网络一直处于紧张状态，对吧？

探索代码库的奥秘与挑战

说到代码库的管理，其实我们得确保本地的代码和服务器上的状态是一致的。技术上，我们的做法是先下载服务器的哈希值，然后和本地的哈希进行对比，这样才能找到哪些文件缺失。不过，这样一来，网络负担可就大了。你用Cursor的时候，谁愿意让网络一直处于紧绷状态呢？

随着用户越来越多，代码库的规模也变得越来越庞大。起初，我们对这个暗代码库进行了整理，但现在它的体量已经无法和某些大型公司的文件库相比了。说白了，建立一个系统不难，但要扩展到更多用户和公司，这可真是个挑战。我们也在不断努力解决这些难题。

Aman提到，的确，索引系统里有许多需要打磨的地方。其实，嵌入代码才是个瓶颈。为了避免重复嵌入相同的代码块，我们引入了一种缓存机制，把代码块的哈希值和对应的向量一并缓存。这样一来，很多公司在使用Cursor时，嵌入代码的速度就能大幅提升，用户只需存储向量数据，而不用担心代码数据的存储问题。

Lex问道：目前你觉得代码库索引最大的好处是什么？短期来看，它有什么实际的用处呢？

Arvid回答，最显著的一点是，当你想从庞大的代码库中找出某些特定内容时，可以通过模糊的提问来进行搜索。比方说，你想找到执行某个功能的代码，但不知道具体的语言怎么写。这时候，你只需要发起一个聊天请求，按下回车，就可以询问代码库。往往，模型能够给你提供准确的位置。

Lex又问了一个问题：为什么Cursor不考虑在本地进行代码嵌入等操作呢？

Arvid说，我们确实考虑过这个方案，但实现起来并不容易。很多用户用的是最新的MacBook Pro，但其实超过80%的用户都是在Windows上操作，其中很多机器的性能并不强大。实际上，本地模型主要适合最新的电脑，而且构建过程的开销也很大。因此，即便我们想尝试这样的方案，实际操作起来还是困难重重。

Aman接着补充，确实，庞大的数据库会消耗大量的内存和CPU。如Arvid所提到的，本地模型的构建面临巨大挑战。虽然MOE架构正在逐渐被采纳，它在内存带宽方面要求更高，也适合本地运行，但模型的规模也因此变得更庞大，需要更多的机器来支撑。我觉得，用户希望能用到最先进、最聪明的模型，但在本地实现这个目标可不是件容易的事。

关于AI模型与数据安全的深入对话

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和一些前沿模型的做法。所以，我们应该继续进行预训练。可以在持续的预训练阶段加入特定代码库的数据，在指令微调阶段则加入关于该代码库的相关问题。我们的起点是从指令微调开始，建立一个关于代码的常规指令微调数据集，然后再抛出更多关于该存储库中的代码问题。

你还可以尝试获取一些难以获得的真实数据，或者利用合成数据来进行某些操作，让模型对代码的新构成部分提出问题。因此，获取代码片段，让模型对此提问，并将这些问题加入到指令中进行微调，理论上，这个过程可能将解锁模型理解该代码库问题的能力。

▲播客现场（

十六、OpenAI o1的竞争策略是什么？

Lex：我想了解一下OpenAI o1，您觉得测试计算系统在编程中有什么样的作用呢？

Aman：测试时间计算的确挺有趣的。随着数据和模型越来越大，预训练机制能让模型在损失函数和后续任务上表现得更加出色。不过，我们现在面对一些数据壁垒，让进一步扩展数据变得更有挑战性。

所以，扩大测试时间计算是一个有趣的方向。如果我们现在增加推理时间的flop计算，使用Infer Time时，模型的flop总是会更多。但现在，我们也许能用同样大小的模型运行更久，从而得到接近更大模型的效果。

有些查询可能需要达到100万亿参数的模型才能处理，但这类请求可能只占整体的0.1%。在这种情况下，可能会显得有些浪费资源。我们可以考虑训练一个能处理99.9%查询的模型，同时为那些真正需要高智能查询的人延长推理时间。

Lex：那怎么判断哪些问题需要更高的智能呢？能否在GPT-4和o1之间动态切换？

关于AI模型切换与训练的深度探讨

Aman：这确实是个棘手的问题，至今都没有人能找到好的解决办法。其实，在Cursor Tab功能上，团队已经实现了一种基本的模型路由，但在GPT-4和o1之间切换，依然面临着不少挑战。对于判断哪些问题需要更高级的AI，这还得靠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的模型。

最后一种则是利用语言模型生成容易验证的文本。比如说，如果你想测试某个系统的语言能力是否可以达到莎士比亚的水平，理论上可以让一只猴子或者一台打字机随意敲打，最终也能得到足够的数据来培养一个“莎士比亚级”的语言模型。

对于具体的引导代码，我们可以通过测试结果来评估这段代码是否合格，同时也可以利用模型生成的、通过测试的代码来对模型进行训练。不过，我觉得这种方法在实际应用中可能不太管用，特别是在开放式任务或复杂任务中，找出完美的验证器真的很难。

人类反馈与AI反馈的结合，共同提升模型的训练效果

Lex：人类反馈的强化学习（RLHF）和AI反馈的强化学习（RLAIF）相比，有什么不同？它们对提升AI模型的性能又有什么帮助呢？

Aman：RLHF是基于人类的反馈来进行训练的。我认为如果能为某些专注的任务提供充分的人类反馈，那效果会特别好。

Aman：而RLAIF就比较有趣了，它是在特定约束条件下进行工作的，比如用语言模型来验证方案，这比自己生成方案要简单得多，这种方法更容易有效，因为RLAIF能够实现一种递归的循环。

AI能否在实现通用人工智能前拿下菲尔兹奖？

其实，我们可以把人类反馈和生成模型结合起来，找到一个合适的平衡点。就拿生成的代码来说，如果我们能在其中加入大约50到100个人工反馈的示例，模型就能更好地对齐我们的设想和预期，效果会更好。

这和传统的强化学习人类反馈（RLHF）有点不同哦，普通的RLHF通常需要大量的示例来训练奖励模型。

Lex：你觉得，生成内容和验证内容，哪一个更简单呢？

Aman：从直觉上看…我感觉在特定情况下，验证会更容易，而不是去发现证明。

Sualeh：AI获得菲尔兹奖的可能性有多大呢？

Sualeh和Arvid：AI更有机会获得菲尔兹奖。

Aman：虽然AI在解决很多问题上已经表现出色，但在定理证明方面，AI的实用性还有待观察。另外，对于我们距离解决那些极其复杂的开放性问题还有多远，我的直觉也不是很靠谱了。

Lex：你认为AI会先拿到菲尔兹奖吗？而不是物理学奖或其他领域的奖项。

Sualeh：我觉得AI拿到菲尔兹奖是百分之百的可能性。像伯奇和斯温纳顿-戴德猜想这样的数学难题，对AI来说仍然是个挑战，目前我们也还不知道怎么去解决这些问题呢。

人工智能的未来：菲尔兹奖与缩放规律的思考

Aman：我觉得AI可能会在实现广义人工智能（AGI）之前，先获得菲尔兹奖。

Sualeh：如果真能实现，那我会超级兴奋！我觉得大概在2028年或者2030年就有可能看到这样的成果。

二十、关于缩放规律的未来：大模型不再是唯一标准

Lex：聊聊缩放规律吧，大家怎么看现状和未来的发展呢？

Aman：最开始OpenAI在缩放规律方面的论文里有些不准确。他们讨论了优化学习效率的问题，但之后Chinchilla的研究给我们带来了更清晰的视角。从那以后，大家开始不再只关注计算的优化，而是转向在有限的推理预算下，如何取得更好的效果。

Aman：我认为，缩放规律的维度远比我们之前只关注参数数量和数据量要复杂得多。举个例子，推理计算就是一个明显的维度。我觉得上下文长度也是一个重要的方面。如果我们关注推理计算和上下文窗口，或许我们希望训练一种状态空间模型（SSM）来应对。

这些模型在处理超长上下文时，能够显著降低成本并提高速度。即便训练时可能需要花费十倍的计算资源来达到同样的能力，这也是值得的，因为我们最看重的是在超长上下文窗口下的推理成本。因此，未来的研究将会在这些维度上深入探索。

Lex：你觉得大家是否还在坚持“越大越好”的信念呢？

Aman：从原始性能和基础AI的角度来看，确实更大的模型能够带来更好的效果。但我认为，大家还是会对蒸馏技术保持关注。如果我们投入巨额资金进行训练，以获得性价比最高的模型，那我们能调整多少个参数呢？

这个问题确实值得我们深思。因为仅仅在推理时间上大量投入计算，这种简单粗暴的做法，大家已经在Llama模型上尝试过了。或者对7B（70亿参数）的模型进行过度训练，使用的token数量远超出最优需求。

聊聊模型训练中的蒸馏技术与投资思路

其实呢，如果你真的重视这个问题，我们可以借鉴Gamma的做法，不光是盯着token进行训练，而是通过缩小与Gemma 27B模型的KL散度来训练。这就引出了一个重要概念——知识蒸馏。简单来说，就是在这270亿参数的模型上投入大量计算资源，然后把这些知识提炼到一个更小的模型里。

Lex：那么，蒸馏的结果就是让模型变得更快？越小的模型是不是就越快呢？

Aman：我觉得，蒸馏技术理论上是从正在训练的数据中提取出更多有价值的信息。这并不是说完全解决了数据不足的问题，而是部分帮助我们突破这个瓶颈。由于可用的数据有限，我们可以先用这些token对大型模型进行训练，再把它蒸馏成小模型。这样一来，模型能够获取到更多有用的信号，比起自己从头训练要好得多。

Lex：如果给你们一个超级大的预算，比如10万亿美元，你们会怎么做呢？

Aman：关于训练这些大型模型，其实有很多秘密和细节，只有那些大实验室才掌握。即便我使劲儿去做，往往也会浪费不必要的资金。

Lex：假设你能掌握所有信息，包括训练参数和方法，未来五年内你会如何投资，以最大化你们所追求的原始AI呢？

Sualeh：我觉得，答案其实很简单。你只需尽可能多地购买计算机，接下来的每一天，都在买GPU，研究人员就可以根据目标选择训练大模型还是小模型。

Aman：这就引出了一个问题，我们究竟是受到计算资源和资金的限制，还是还有其他因素在制约我们呢？

Sualeh：更多的还是受限于我们自己的观念，当然，也存在一些外部限制因素。

未来编程的变革：技术与观念的碰撞

Lex：你们更倾向于进行大量实验，还是把计算资源用来训练一个超大的模型呢？

Arvid：我觉得我们可能会选择实验，毕竟目前的想法还是有些局限。

Aman：我同意你的观点。即便我们拥有顶尖的计算能力和海量的数据，还是会面临许多限制。而这些限制不仅仅是思维上的，实际上更依赖于更先进的工程技术。即使资金充足，真正能有所作为的人还是不多。

说到研究，里面包含了大量复杂且艰辛的工程工作。拿原始的Transformer论文来举例，许多有趣的概念都需要工程师们通力合作才能实现，就像GNOME Azure一样。

再进一步说，要让下一代模型实现并行处理，那可是一项庞大的工程量。我认为，要把这些想法落到实处，必须投入大量的工程技术。比如，若能将工程成本降低十倍，让那些伟大的想法得以实现，同时提升40%到50%的GPU利用率，那研究的效率肯定会大幅提升。

Sualeh：如果能看到明确的改进路线，成果就会触手可及。我觉得OpenAI和一些其他实验室的做法是对的，它们抓住了这些机会。比如，像GPT-4.25这样。现有方法有效时就没必要去创新，只有在遇到瓶颈时，才需要新的思路。如果手头有10万亿美元的预算，或许可以先扩大规模，再来更新观念。

只要现有的方法有效，就没有必要去尝试新的想法。只有当现有方法遭遇瓶颈时，新的想法才会显得必要。如果有10万亿美元的预算，或许可以先扩大规模，然后再重新审视现有的理念。

Aman：我们都相信，要实现AGI，需要一些全新的观念。我们也坚信可以在较小的规模上测试新的想法，且我们对这会成功抱有信心。对于当前的实验室来说，把有限的研发人才投入到新想法的开发中是非常困难的，毕竟现有的方法在未来相当长一段时间内都是有效的。

Lex：你们现在正处于编程世界的中心。你们认为编程的本质在未来几个月、几年，甚至十年会有什么变化呢？

未来编程的无限可能

Michael：说实话，我们对未来充满期待，程序员在这个时代可谓是“历史的驾驶员”。我们之前也讨论过，程序员需要具备高效的能力和掌控力，他们不仅能做出任何想要的修改，还能迅速对自己的创作进行优化和迭代。

这里面，其实和“与计算机对话式编程”不太一样。想象一下，就像你在Slack上和工程师沟通，输入需求到一个文本框里，AI就会替你完成任务。不过，这样也有些问题，比如会有一定的延迟，而且你也会失去一些控制权。

其实，真正的工程执行是基于你做出的细微决策来完成的。人类的作用是AI无法替代的，依然需要让人类坐在“驾驶位”上来掌舵。

展望未来，程序员可能能够掌控代码库的抽象层次，通过查看伪代码的方式来进行编辑。同时，程序员还可以调整编程软件的逻辑，保留对过程的控制，这样一来，生产力将大幅提升。

不过，这只是一个模糊的想法，很多细节还有待解决，能否实现也还有待观察。我们认为，人类的控制力、效率和以人为中心的理念是至关重要的。正如Arvid提到的，某些编程任务可以交给聊天机器人，但大多数任务仍需要人类深度参与。

Lex：那编程的基本技能会发生根本性的变化吗？

Michael：其实现在正是软件开发的激动人心时刻。虽然有些代码还是需要参考很多复杂的信息，但如今的编程比以往有趣多了，人们开始享受这个过程。现在，编程让人们能够快速构建事物，控制力也得到了极大的提升。

对于程序员来说，这也是一个充满意义的时期，人们的创造力和乐趣被放大。如果你是一名程序员，今天的环境将更加特别，值得好好把握。

编程的未来：热爱与创造的结合

Arvid：我完全赞成，最近我们正在进行一次大规模的代码迁移，把Node.js中的异步本地存储换成上下文对象。即使有AI的帮助，这项工作依然需要我和另一个工程师花费大约五天的时间。不过，未来我们可能只需给AI几个示例，然后这项迁移就能在短短十分钟内完成。实际上，程序员可以借助AI更高效地工作，不必事先考虑太多，尝试新方法的成本也相对较低。

Aman：我觉得编程的方式主要有两种。一种是深入思考，努力寻找最佳的解决方案，然后在有限的时间内进行验证；另一种则是直接动手执行代码，看看结果如何，然后进行调整。我更倾向于后者。

Lex：那对于现在想学习编程的人，你们有什么建议呢？是选择学习Java还是PHP呢？

Aman：我认为每个人学习编程的动机都不一样。实际上，热爱编程的人往往能够成为最优秀的程序员。在我们团队里，很多人在工作之余仍然会用Cursor编写代码，有的人甚至会熬夜到凌晨三点来做这件事情。当他们感到不快时，常常会说“我需要写点代码”来安慰自己。

这种对编程的热爱，推动他们成为顶尖的程序员。我相信，这些人会非常认真地投入到他们所研究的领域。未来的程序员们需要更加关注“你想要创造什么”。

Sualeh：程序员可以通过更加多样化的方式来表达自己的意图。

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

宣言中提到：“首先，我们正在培养未来的工程师，这种人类与AI合作的程序员效率比任何单一工程师高出一个数量级。这种混合型工程师能够轻松掌控代码库，无需低效的键盘操作。即便在最复杂的系统中，他们也能快速迭代。通过结合AI与人类的智慧，他们将比最优秀的纯AI系统更聪明、更具工程能力。我们是一群研究人员和工程师，致力于在有效性和可能性基础上进行创新，改善成千上万程序员的生活。”

### 编程其实可以更有趣！

Lex说啊，这次的对话至少让编程变得没那么无聊了。