智东西（公众号：zhidxcom）编译 | 尹明顺 吴浪娜裁剪 | 漠影
智东西10月10日音讯，当地时期10月7日，着名播客主抓东谈主Lex Fridman和Cursor团队4名首创成员Michael Truell、Sualeh Asif、Arvid Lunnemark和Aman Sanger进行了一场长达两个半小时的对话。
Cursor是一个基于VS Code的代码裁剪器，它为AI辅助编程添加了许多遒劲的功能，它引起了编程和AI社区的关注和得意，风头正盛。那么Cursor看成一个初创团队，如何能够与科技巨头微软的Github Copilot一战呢？
在播客中，几东谈主深度筹谋了Cursor团队咫尺的发展以及将来的探索场地，还庸碌褒贬了编程的将来，以及东谈主类与AI在诡计和构建复杂而遒劲的系统方面达成息争的各式可能。
团队成员在博客中详确共享了Cursor如何会通你的代码库并以此为依据瞻望你下一步要作念什么，然后以惊东谈主的速率生成代码，从而有用普及了编程效率。
他们还先容了Cursor更多功能，不仅擅长自动补全代码，它还引入了影子使命区辅助编写代码，并能通过粗略的形容来敕令AI编写更复杂的代码，完成更多的任务。
此外，团队成员还对AI编程的技巧要领进行了深入分析，并对东谈主与AI编程之间的伦理问题张开探讨，提到了但愿将OpenAI o1模子集成的愿景。
值得一提的是，团队成员认为，快速就是敬爱（Fast is Fun）。招引东谈主们在电脑上创造新内容的原因之一就是惊东谈主的迭代速率，而在其他领域，你可能会受到资源或智商的适度，但在编程的天下，只消有你和筹备机，你就能相等快速地构建出相等酷的东西。
首创团队中，Aman Sanger担任Cursor的CEO，是一位工程师和企业家，此前他曾在Instagram和Facebook担任携带职位。Arvid Lunnemark是公司的CTO，是一位工程师，曾在Spotify和Google使命。Michael Truell担任诡计驾驭，Sualeh Asif担任公司COO。
▲播客现场先容Cursor团队成员（来源：YouTube）
以下是对该播客内容的完整编译（为提高可读性，智东西调节了部分问答的设施，并在不不屈快乐的前提下进行了一定的增删修改）。
一、类似增强版翰墨处理器，代码裁剪器可处理更多任务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有点像语言模子的第一个杀手级应用。
Michael：是的，它的beta版在2021年发布。
Lex：那么Cursor的发源故事是什么样的？
Michael：简陋在2020年，OpenAI发布了scaling laws论文，这是一个要道时刻，这个领域似乎取得了澄莹可瞻望的进展，即使咱们莫得任何新想法，看起来只消有更多的筹备智商和更多的数据，就可以让这些模子变得更好。
Lex：趁便说一下，咱们可能需要花三到四个小时来筹谋scaling laws这个话题。但简而言之，这是一系列论文中的一篇，这些论文忽视了一系列不雅点，认为在机器学习领域，模子的大小和数据的大小，越大越好。
Michael：是以在那段时期，咱们中的一些东谈主有好多对于这会是什么神色的主张性筹谋。对于统共这些不同常识领域的使命者来说，这项技巧的发展将如何让他们变得更好？然后我认为有几个时刻，那篇论文中瞻望的表面进展入手变得相等具体，入手认为你可以在AI领域作念施行上有用的使命，而不需要去攻读博士。嗅觉咫尺可以构建一整套真确有用的系统。我认为第一个时刻是玩转Copilot的早期测试版，那种嗅觉很棒，很神奇。
我认为第二个要害时刻是提前获取了GPT-4的早期拜谒权限。简陋在2022年底，咱们入手修改这个模子，智商的升级嗅觉相等巨大。在此之前，咱们一直在研究一些不同的名堂。因为Copilot，因为scaling laws，因为咱们之前对这项技巧的风趣，咱们一直在修改轨范员使用的用具，但这些都是相等具体的用具。是以咱们正在为必须在Jupyter Notebook上使命的金融专科东谈主士构建用具，或者尝试使用这些模子进行静态分析。
而GPT-4的升级让咱们嗅觉这如实证实了咱们之前瞻望的表面进展。嗅觉就像在阿谁时期点你可以立即构建好多东西。而且，如果咱们保抓一致，这确实嗅觉不单是是一个点处分决策，这将波及统共这个词编程领域，统共编程都将通过这些模子进行，而且嗅觉这需要一种不同类型的编程环境，一种不同的编程方式，是以咱们入手构建那种更大的愿景。
Sualeh：有一件事我印象相等深入，我的室友是IMO金牌得主，好意思国有一个叫Putnam的比赛，这有点像是大学生的IMO，亦然一个数学竞赛，它相等精彩。我铭记Shengtong和Aman在2022年6月阁下打赌，赌能否在2024年6月或7月的IMO中获取金牌。
Lex：IMO是海外数学奥林匹克竞赛。
Sualeh：Arvid和我也参加了，尽管我在某种进度上相信进步，但我认为想拿下IMO金牌，Aman是在浮想联翩。但诚挚说我绝对错了，但这可能是团队中最有预知之明的赌注。
Aman：我明晰地铭记我和Michael有一次对话，在那之前我还莫得相等深入和批判性地念念考过scaling laws，他忽视了一个问题，为什么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的东谈主和西席模子的东谈主坐在一齐，相距18英尺远，致使频繁是吞并个东谈主。你可以创造出一些如果不交谈、伪善验就不可能已毕的东西。
Lex：你们用Cursor来写Cursor？
Arvid：天然。
Lex：咱们聊聊无所不可的Tab，号称加强版自动补全的功能。Tab是若何使命的？它是什么？
Michael：详细来说，我认为Cursor咫尺在两个方面发达可以。天然，它还有其他功能，但这两项功能对轨范员来说相等有匡助。一是它就像在你死后不雅察，是一个速率很快、可以抢在你前边输入并瞻望你下一步要作念什么的共事。这亦然一个好的自动补全功能的初志，瞻望你下一步要作念什么，但咱们可以更进一步，不仅瞻望Cursor后头的字符，还能瞻望你要进行的下一个全体改革、下一个相反、接下来要跳转的位置。
第二个是，能匡助你有时开始于AI，告诉它该作念什么，已毕从指示到代码的调节。为了作念好这两件事，咱们在提高裁剪体验险峻了好多功夫，让它们既得当东谈主体工程学，又饱和智能和快速。
四、加强版自动补全功能Cursor Tab，摒除裁剪器中的低熵操作Sualeh：咱们真确想要已毕的是，让模子能够为咱们裁剪代码。这是咱们的愿望，在领有能够裁剪代码的优质模子之前，咱们进行了屡次尝试。有了优质模子后，为了让使用体验愈加灵通，咱们付出了好多起劲来加速推理速率，并也曾入手整合。
Michael刚才也提到了这种跳转到不同位置的智商，我认为这种跳转源于一种嗅觉，即一朝你接受了裁剪，下一步要去那处应该相等显着。比如，我作念了这个改革，模子应该顺利知谈下一步要跳转到第18行。如果你是WIM用户，你可能会按18JJ之类的快捷键，但为什么我要这样作念呢？模子应该顺利知谈。
是以，你只需要按Tab键，它就会跳到第18行，然后炫耀下一个裁剪，你再按Tab键，你只需一直按Tab键，就能一直这样操作下去。是以里面竞争就变成了，咱们能让东谈主按些许次Tab键？一朝你有了这个想法，更抽象地说，要酌量的是如何使裁剪达到零熵景况。
也就是说，一朝你抒发了意图况兼裁剪，莫得新的信息片断来完成你的想法，但你仍然需要输入一些字符来让筹备契机通你真确的想法，那么模子巧合应该“读懂”你的心念念，统共零熵位都应该只是被Tab键摒除，这就是比较抽象的说法。
Aman：一个敬爱的时局是，如果你看不同领域的language model loss，我相信每字节的比特数，这是一种对代码字符圭臬化失掉的揣度，比语言低，这意味着代码中有好多token是相等可瞻望的，好多字符亦然相等可瞻望的。而且，当你不单是是试图自动补全代码，而是瞻望用户在裁剪现有代码时的下一步操作时，这种可瞻望性会被进一步放大。因此，Cursor Tab的方针是摒除裁剪器中统共低熵操作。一朝意图得到有用细则，就让咱们顺利跳转到将来的某个时期点，上前跳过。
Lex：那么，Tab在近期内应该能够作念什么？
Aman：我可以讲讲让这些功能表露作用的一些细节。它们的延长极低，是以你需要在这个任务上西席袖珍模子。绝顶是，它们相等需要预填充token。这意味着它们有相等长的教唆，能看到好多代码，但施行上生成的token并未几。因此，使用MOE模子是最合适的。这是咱们取得的一项冲突，极地面提高了模子在长险峻文中的性能。另一个冲突是咱们构建的投契解码的变体，称为投契裁剪。我认为，这两点是使其质料高、速率快的要害身分。
Lex：那么缓存起作用了吗？
Aman：缓存起到了巨大的作用。因为你要处理这样多输入token，如果你在给定行中输入的每个按键都要针对统共传入的token从头运行模子，那么一是会大大缩小延长，二是会让GPU负载过高。因此，你需要诡计用于模子的施行教唆，使其具有缓存禁闭。然后，你需要跨央求重用KV缓存，以减少筹备量。
Sualeh：但愿能跳转到不同的文献。是以，如果你在一个文献中进行了裁剪，可能需要转到另一个文献来完成你的想法，它也应该转到第二个文献。
Arvid：完整的泛化是下一步举止瞻望。有时你需要在终局中运行敕令，它应该能够字据你编写的代码来建议敕令，或者有时它会给出建议，但你很难判断它是否正确，因为你需要更多信息来学习。你需要知谈类型能力考证其是否正确。是以它巧合应该先带你到某个界说的地方，然后再带你总结，这样你就有了接受下一个补全所需的统共必要常识。
Michael：编程是一门奇特的学科，有时你接下来五分钟要作念什么，施行上是可以字据你最近所作念的事情瞻望出来的。那么，咱们能否创造一个天下，让这接下来的五分钟要么在你结果的情况下自动完成，要么在你看到下一步要作念什么并证实无误后，通过轻触Tab键就能快速已毕。
五、增多炫耀框教唆代码相反，围绕审查者体验作念诡计Lex：Cursor有一个相等酷且引东谈主注宗旨功能，那就是统共这个词diff界面情况。是以，模子用红色和绿色炫耀咱们将如何修改代码，然后可以在聊天窗口中应用它，它会向你炫耀diff，你可以接受diff。那么，你能讲讲这方面的发展场地吗？
Sualeh：咱们可能会有四五种不同的diff。咱们为自动补全功能优化了diff，因此它具有与审查大块代码时不同的diff接口。然后，咱们正在尝试优化另一个diff功能，以得当处理多个不同文献的情况。从高等次来看，相反在于，当你进行自动补全时，读取速率应该相等快。施行上，在统共情况下它的读取速率都应该相等快，但在自动补全功能中，你的防御力汇积贮在一个区域，东谈主类无法同期关注太多不同的地方。
在界面方面，咱们有刻下框，如果你试图在某个地方删除代码并尝试添加其他代码，它会尝试在侧面炫耀一个框。
咱们尝试了三四种不同的方法来已毕这个功能。最初的方法是在阁下炫耀一个带有蓝色删除线的框。它往日会以Google Docs的立场炫耀要删除的代码，你会看到一条线穿过，然后看到新代码，这相均分散防御力。然后咱们尝试了好多不同的方法……有删除、红色高亮等。
之后的迭代版块有点敬爱，你会按住Mac上的option键。是以它会高亮炫耀一段代码，以炫耀AI有建议给你。在这个例子中，输入和值都会变成蓝色，蓝色是用来高亮炫耀AI对你有一个建议。它不会顺利炫耀建议的内容，而只是教唆你AI有一个建议。如果你确实想看到它，就按住option键，然后你会看到新的建议，削弱option键后，你又会看到原始代码。
Arvid：我个东谈主相等期待在这个领域作念出好多矫正。咱们频繁把它称为考证问题，这些相反对于小范围修改来说很好用。但如果是大范围修改，或者波及多个文献等情况，审查这些相反就有点费力了。是以这里有几个不同的想法。一个想法是，相反中的某些部分很要害，包含了好多信息。而有些部分的信息熵很低，就是近似的内容。
是以，巧合可以高亮炫耀要害的部分，而将不那么要害的部分灰度炫耀。或者，你可以有一个模子，它稽查相反并发现，“哦，这里可能有个随意。”我会用红色波浪线象征出来，并教唆你，“你应该要点审查这部分相反。”我认为这类想法很令东谈主得意。
而且，你但愿用一个智能模子来完成这项使命。咫尺的算法只是普通算法，莫得智能性。算法的诡计需要智能，但你并不关注它是对于这个如故阿谁，你只但愿模子能作念到这一丝。
Sualeh：是以我认为一个遍及的问题是，跟着这些模子变得越来越智能，它们能够忽视的改革也会越来越大。而跟着改革越来越大，东谈主类需要作念的考证使命也越来越多。这变得越来越……你需要匡助他们。我可不想把统共的时期都花在代码审查上。
Aman：GitHub试图通过代码审查来处分这个问题。当你进行代码审查时，你正在审查多个文献中的多个相反。但就像Arvid之前说的，我认为你可以作念得比代码审查更好。代码审查有点厄运。你花了好多时期去会通那些平日对你来说很生疏的代码，而且它致使并不可真确捕捉到好多随意。
我认为，使用语言模子可以权贵改善审查体验，举例，使用Arvid之前形容的那种技巧，即可能指向施行要害的区域。我还认为，如果代码是由这些语言模子生成的，而不是由其他东谈主生成的……代码审查体验是同期为审查者和代码编写者诡计的。
在代码编写者是语言模子的情况下，你就不必那么关注他们的体验了，你可以绝对围绕审查者来诡计统共这个词体验，让审查者的使命尽可能敬爱、大意、高效。我认为，如果只是生动地试图让这些东西看起来像代码审查，那就会出现问题。我认为你可以更有创造力，并鼓动可能性的界限。
Arvid：还有一个想法是，我认为设施很要害。平日，当你审查一个拉取央求（Pull Request）时，你会看到一个文献列表，况兼从上到下交替审查，但施行上，你可能需要先会通这个部分，因为这部分在逻辑上是先发生的，然后你重逢通下一部分，而你不但愿我方弄明晰这一丝，你但愿有一个模子来率领你。
我认为，并不是统共的编程都会变成天然语言。如果我正在和Sualeh结对编程，Sualeh在电脑前和键盘上，有时如果我来主导，我会对Sualeh说，嘿，已毕这个功能，这样就行了。但有时，向Sualeh解释我想让他作念什么太吃力了，是以我会接过键盘，给他展示一下。
我写一部分示例，然后他就明白了，这是最容易的调换方式。是以我认为，对AI来说亦然这样。有时，与AI调换的最粗略方式就是展示一个示例，然后它就会在其他地方履行这个操作。
或者，有时如果你在作念网站，举例，向AI展示你想要什么最容易的方式不是告诉它要作念什么，而是拖动或绘图东西，也许最终咱们会已毕脑机接口之类的，你就可以让它会通你在想什么。是以我认为天然语言会有方寸之地。但我战胜地认为，它不会是大多数东谈主大部分时期编程的方式。
▲播客现场（来源：YouTube）
Lex：我在使用这个裁剪器时，确实感受到了通用AI（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雷同的接口，但它的流式传输速率会快得多。
七、GPT和Claude在编程上哪个更胜一筹？Lex：哪个大语言模子更擅长编程？GPT和Claude，在编程方面，哪个更胜一筹？
Aman：我认为莫得哪个模子能在统共咱们认为要害的类别中都优于其他模子，这些类别包括速率、裁剪代码的智商、处理大都代码的智商、长文本险峻文，以过火他几个身分和编程智商。我咫尺会说总体上最好的是Sonnet。我认为这是民众的共鸣。
o1也相等敬爱，它相等擅长推理。是以，如果你给它一些很难的编程口试立场的问题或者携带代码问题，它能作念得很好，但它似乎不如Sonnet那样能会通你的大致敬图。如果你望望其他好多前沿模子，我有一个疑虑，那就是嗅觉它们不一定好……我不是说它们在基准测试上西席，但它们在基准测试中的发达如实相等好，相对于统共中间的东西。
是以如果你尝试统共这些基准测试和它们评估的散布中的东西，它们会作念得很好。但是，当你把它们稍许推离这个范围时，Sonnet是我认为在保抓雷同智商方面作念得最好的。你在基准测试中领有的智商与尝试指示它履行任何与编程联系的事情时领有的智商雷同。
Sualeh：趁便说一下，这是一个相等迂曲且至关要害的细节，基准测试与真确的编程之间的区别在于，真确的编程并不是口试立场的编程。东谈主类有时会说半吊子的英语，有时你会说，“哦，按照我之前作念的那样作念。”有时你会说，“添加这个东西，然后为我作念这个其他事情，然后制作这个UI元素。”但好多事情都是依赖于险峻文的。你确实想要会通东谈主类，然后按照东谈主类的意愿去作念，而不是……也许抽象地说，口试问题是相等明确具体的。它们在很猛进度上依赖于明确说明，而东谈主类的东西则不那么明确。
Aman：对于Claude，我听到过一个敬爱的不雅点，我认为AWS有不同的芯片，我怀疑它们与Nvidia GPU的数值略有不同，有东谈主推测Claude性能着落可能与在AWS Bedrock上使用的量化版块与Anthropics GPU上运行的版块不同关系。
八、Preempt系统可自动已毕预生效果Lex：在这一切中，一个好的教唆（Prompt）演出着什么脚色？
Arvid：我认为这取决于你使用的是哪个模子，它们都有细微的离别，对不同的教唆反应也不同。但我认为，最初的GPT-4和客岁的某些模子，它们对教唆极度明锐，而且它们的险峻文窗口也很小。是以咱们有好多与代码库联系的信息，这些信息可能在教唆中会很有用。
你有文档、你添加的文献、你有对话历史，然后问题就来了，你如何决定施行上要把什么放进教唆里，绝顶是当你的空间有限时？对至今天的模子，即使你有长险峻文，填满统共这个词险峻文窗口就意味着它会变慢。这意味着有时模子施行上会感到困惑，而且有些模子比其他模子更容易困惑。
咱们里面有一个系统叫作念Preempt，它在这方面对咱们有一些匡助。我认为它是为咱们有8000个token险峻文窗口的时期建立的，它有点类似于当你在制作一个网站时。你但愿它在手机上能正常使命，你但愿它在桌面上也能正常使命，而你有这些动态信息，但你莫得固定的布局。
举例，如果你诡计一册印刷杂志，你知谈你可以把东西放在那处，但是当你有一个网站或者一个教唆时，你有这些输入，然后你需要形式化它们，以便它们能老是正常使命，即使输入相等大，你可能必须削减一些内容。是以咱们的想法是，好吧，让咱们从中获取一些启发。
诡计网站的最好方式是什么？咱们相等心爱的是React以及它的声明式方法，你在JavaScript中使用JSX，然后顺利声明：这就是我想要的，我认为这个部分比其他部分具有更高的优先级或更高的Z轴设施。在网页诡计中，你有一个渲染引擎，就像Chrome一样，在Cursor中它是一个preempt渲染器，它会将统共内容都放在页面上。你只需说明你想要的效果，渲染器会自动帮你已毕。咱们发现这钟方法相等有匡助，而且它的作用跟着时期的推移也曾发生了变化。
最初它是为了得当较小的险峻文窗口，而咫尺它在拆分进入教唆词的数据和施行生成方面表露了很大作用。因此，它更容易调试，因为你可以修改教唆词，然后在旧的教唆上进行测试，顺利稽查你的修改是否确实普及了统共这个词评估集的发达。
Lex：是以你们是确实用JSX来教唆吗？
Arvid：是的。咱们有一个文献组件，它吸收光标。平日在你的文献中有一转光标所在的位置，那可能是最要害的一转，因为那是你正在稽查的一转。然后你可以给出优先级。而且，如果你有好多来自统共这个词代码库的代码块，你可以使用检索和镶嵌等从头排序分数来为这些组件添加优先级。
Lex：那么当东谈主类发问时，也应该尝试使用那样的东西吗？这是否意味着问题会变得松散和衰败，如故这样的系统应该饱读舞东谈主们更澄莹地抒发？
Arvid：我认为咱们的方针是，你应该只作念对你来说最天然的事情，然后咱们的使命就是弄明晰如何施行检索到相对要害的事情，以便你的念念考是有真理的。
Lex：模子遴聘修起与一般修起有多难？这很难，如何处理不细则性。我是否遴聘磋议更多信息以减少歧义？
Sualeh：咱们最近为Cursor添加了一个加入文献的功能。当你在裁剪代码或输入内容时，模子会尝试瞻望你正在作念什么，如果模子发现有不细则的地方，它会预计你可能在编写某种API。然后，模子会稽查你的历史记载，推测哪些文献与刻下的裁剪内容联系。
这里有一个技巧上的难题，就是如安在统共历史记载中找到联系的信息，判断在刻下的教唆词下哪些文献最要害。诚然这个功能还处于检会阶段，但相信咱们会拖拉完善它，但咱们想展示出这个想法：你是否想添加这个文献、阿谁文献，以便模子帮你裁剪？
也许你在编写一个API，你也应该需要裁剪使用这个API的客户端和做事器代码，那么API发生变化时，客户端和做事器代码也需要相应更新。
Cursor可以作念的是，当你在编写教唆或代码时，在你按下回车之前，模子可以帮你找到这些可能需要一齐修改的部分。这样作念的平正是，可以提前处分一些不细则性，确保统共联系的代码都被正确更新，而不需要手动去查找和同步这些改革。
九、咱们正在接近AGI时期，但AI Agent还伪善用Lex：你们若何看Agent？Agent有多有用？
Arvid：我认为Agent就像是东谈主类，你能嗅觉到你正在接近AGI，因为你能看到一个演示，它发达得就像一个真东谈主，这确实很酷。我认为Agent在好多事情上还不是绝顶有用，但咱们也曾越来越接近它们真确变得有用的阶段了。
是以我认为有些类型的任务，有Agent的话会更好。举例，如果咱们有一个bug，有时你不可在聊天输入框中使用Command+C和Command+V，这是一个相等明确的任务，我只需要用两句话来说：“这个不可用，请拓荒它。”然后我会很乐意有一个Agent，它会自动行止理，拓荒这个bug，然后我总结查验拓荒情况。
它会找到正确的文献，尝试重现bug，拓荒它，然后考证它是否正确。这可能是一个需要很永劫期的过程。是以我认为我会很心爱这样。而且我认为在编程中，频繁有东谈主认为Agent会取代统共的编程使命。我不认为咱们这样认为，因为好多编程使命，好多价值在于迭代，或者说你其实不想一入手就明确指定什么，因为你确实不知谈你想要什么，直到你看到了启动版块，然后你想在此基础上进行迭代，然后提供更多的信息。
是以在好多编程使命中，我认为你施行上想要的是一个即时的系统，它能立即给你一个启动版块，然后你可以相等快速地进行迭代。
Lex：比如最近推出的Replica Agent，它可以缔造开发环境，处分软件包问题，确立一切，包括确立数据库和部署应用。这亦然你瞎想中的一部分吗？
Arvid：我认为是的，对于某些类型的编程使命，这确实很酷。
Lex：这在Cursor的范围内吗？
Arvid：是的，咱们咫尺并莫得积极地在作念这件事，但可以战胜的是咱们想让轨范员的生存更大意、更敬爱，有些事情确实很乏味，你需要经过一系列方法，你想把这些事情交给Agent去作念。然后有些事情，你可以让一个Agent在后台使命，同期你也在使命。比如说，你有一个同期波及后端和前端的PR（Pull Request），你在前端使命，然后你可以让一个后台Agent行止理后端部分，当你入手处理后端部分的PR时，你就也曾有了一些启动代码可以迭代了。是以这也会很酷。
十、影子使命区，在后台运行代码Arvid：开始，咱们要明确的是，咱们但愿在后台进行大都的操作，况兼咱们正在尝试好多内容。咫尺，除了缓存预热或找出敕令键教唆所需的正确险峻文除外，咱们并莫得太多其他后台操作。但咱们的想法是，如果能确实在后台进行筹备，那么就可以匡助你瞻望更永劫期范围内的操作，而不单是是瞻望你接下来要写的几行代码。
而是瞻望在接下来的10分钟里，你可能会作念什么。通过在后台进行筹备，咱们可以花更多的筹备资源来作念这件事。是以咱们实施的影子使命区（Shadow Workspace）的主张，并在里面进行实验，是为了真确利用后台筹备的上风，咱们需要给模子提供某种反馈信号，否则可以通过让模子念念考更永劫期来获取更高的性能，比如o1就是一个很好的例子。
但另一种提高性能的方法是让模子进行迭代并获取反馈。对于轨范员来说，一个相等要害的反馈来源是语言做事器。它存在于大多数不同的语言中，况兼每种语言都有一个单独的语言做事器。它可以告诉你“你在这里使用了诞妄的类型”，并给出诞妄教唆，或者它还可以跳转到界说，并会通你的代码结构。TypeScript语言做事器是由TypeScript团队开发的，Rust语言做事器是由Rust团队开发的，它们都通过语言做事器条约与VS Code进行交互。这样，VS Code就不需要内置统共不同的语言，而是可以使用现有的编译器基础结构。
这是为了代码查验、跳转到界说以及稽查你正在使用的正确类型。当你在处理一个大型名堂时，类型查验和援用查找功能都是必不可少的。如果莫得这些功能，就很难在大型名堂中编写代码。
Lex：在Cursor中是如何使用语言做事器条约进行通讯的吗？
Arvid：在Cursor中，咱们使用语言做事器条约向轨范员展示信息，就像在VS Code中一样，但咱们的想法是，咱们还想将这些信息展示给智能模子，况兼咱们想在不影响用户的情况下作念到这一丝，也就是说，咱们想在后台进行这些操作。
影子使命区的想法是，咱们可以创建一个荫藏的Cursor窗口这样你就可以在它里面缔造这个标志，然后把它荫藏起来。诚然你看不到它，但它如实存在。在这个窗口中，AI Agent可以大意修改代码，只消它们不保存修改，因为这仍然是吞并个文献夹。然后，它们可以从linters（代码查验用具）中获取反馈，跳转到界说，并对代码进行迭代。
这是咱们最终想要已毕的方针，亦然咱们博客著述主要筹谋的内容，因为已毕这一丝有点辣手。咱们但愿它在用户的机器上运行，以便绝对模拟用户的环境。在Linux上，咱们可以作念一些很酷的事情，比如镜像文献系统，并让AI在文献级别上进行操作，但施行上，这些操作是存储在内存中的。咱们可以创建一个类似于内核的扩展来已毕这一丝。而在Mac和Windows上，这有点难，但这是一个敬爱的技巧问题，是以咱们在进行这项研究。
Aman：一个可能有些约略但很敬爱的想法是，对保存操作进行锁定。这样，你可以让语言模子在保存到磁盘时锁定，然后你就不必在保存到磁盘的文献的真实版块上操作，而是在操作影子使命区中的那些未保存的内容。你仍然可以获取诞妄教唆，并可以在其中编写代码。然后，当你尝试运行代码时，会出现一个小劝诫，教唆有锁存在，这时你可以从语言做事器或影子使命区中开释锁，以便并发地履行其他操作。
十一、模子查询bug仍有迂曲，Open o1也不例外Lex：允许模子修改文献是一个令东谈主得意的将来，诚然这听起来也有些吓东谈主。设计AI agent可以自动履行一系列任务，用户第二天只需对结尾进行审查，AI就好像你的共事一样。
Aman：我认为，模子在可运行性方面会有不轸恤况。履行一些粗略任务时，用户可以在几分钟内顺利完成，在腹地机器上运行亦然合理的。而履行一些需要更永劫期以及更大变动的任务时，则需要在辛苦的沙盒环境中完成。如何精确将用户环境重咫尺辛苦沙盒中，并能确保代码运行结尾的一致性是极具挑战的。
Sualeh：我很好奇，你们（用户）想要什么样的编码agent？匡助你们找到随意？如故已毕一些新的功能？
Lex：编码方面，我认为应该去关注查找各式级别的bug，尤其是逻辑诞妄，以及已毕方朝上的诞妄。
Aman：这些模子在粗略地教唆下并不善于寻找和发现诞妄。它们的校准相等差，即即是最贤慧的模子o1亦然如斯。
Lex：您能解释一下吗？
Aman：我认为这些模子都能够很好地响应预西席数据的散布，跟着失掉函数的缩小，模子的泛化智商也在增强。但咫尺失掉函数的缩小已饱和多，以至于模子能够已毕全面的泛化。咱们主要在前沿领域使用模子，用他们进行代码生成并对问题进行回答。在预西席阶段，GitHub上的大都代码，数目高达数万亿个token，Stack Overflow和GitHub Issues等平台上也有大都问题和谜底，都为任务提供了丰富的数据。
但当你尝试鼓动其中一些在汇集上并不常见的事情时，比如字据已有的裁剪来瞻望下一个裁剪的Cursor Tab方针，模子的脆弱性就会泄清楚来。
另一个很好的例子是bug检测，因为施行上并莫得太多真实的检测bug并忽视拓荒建议的例子，是以模子在这方面会遭遇很大的迂曲。
但我认为，这同样是一个模子迁徙的问题，咱们需要将其他模子迁徙到Cursor Tab上，在将相等擅长代码的通用模子迁徙到bug检测任务时，效果应该也可以，只是需要咱们稍作念率领。
Sualeh：很显着，我认为模子相等了解代码。当它们在预西席过程中，巧合也曾能够粗陋地察觉到代码的问题所在。这是因为有些东谈主也曾对这些诞妄进行了严格的校准。
但当用模子编程的时候，比如编写数据库，这是很浩大的数据信息，即便缔造了好多严格的校准轨范，可能诞妄也如故很难被修正。
十二、危急代码标注存争议，开发团队并不看好赏金轨制Lex：东谈主类也很难判断代码的要害性。如果某行代码可能形成严重后果，应该添加“这行代码是危急的”这一注视。
Arvid：全部大写，近似十次
Lex：是的，即使是吞并个东谈主也可能会健忘单个代码的危急性。
Arvid：我认为在一定进度上这也适用至今天的AI模子，如果你确实在每一转中都标注dangerous，dangerment，dangerous的话，模子也会愈加关注这些，况兼更有可能在该区域发现诞妄。
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的安全性。
Lex：既然模子在bug查找方面存在迂曲，那么将来的但愿在那处？
Sualeh：但愿模子开始能够匡助发现一些粗略的bug，举例off-by-one诞妄或注视与代码不一致的情况。最终，模子应该能够发现更复杂的bug。
Michael：遒劲的bug查找模子对于已毕AI编程至关要害。如果AI能够自动生成代码，那么也需要能够考证代码的正确性。这不仅是为了匡助东谈主类轨范员，亦然为了考证AI生成的代码。
Arvid：是的，但施行上是若何作念到的呢？有一个流行的想法是这样的，引入bug比找到bug更容易，因此可以西席一个模子并引入一些诞妄代码，然后就可以西席一个反向诞妄的模子，并用其中的合成数据去寻找诞妄。这是一个可以的例子。
Michael：还可以利用大型模子和代码除外的信息来辅助查找bug，举例通过代码履行轨迹和调试器信息。bug查找用具可能会有两种不同的居品形态，其一是在后台运行的快速模子，用于发现常见的bug。其二是用于处分特定bug的高筹备量模子，用户可以支付一定的用度去使用。
Lex：是否酌量过用资金将这些整合起来？如果模子能够找到bug或生成高质料的代码，我风物付费。前几天，我用Cursor模子生成了三个齐全的函数，主要用于与YouTube API交互，为我提供多语言字幕更新功能。
API文档不是很好，而且有代码交叉时局，我用谷歌搜索得不到的确信息，只消一些令东谈主困惑的内容，而Cursor生成得则相等齐全。我想，真但愿能有一个“打赏”按钮，写着“5好意思元”既可以援助公司发展，也可以向模子发送积极反馈信号比如“Good Job”。在bug查找中，也可以引入类似的赏金机制。你们有酌量吗？
Arvid：公司里面对此存在争议。我认为在某种进度上，这取决于你对东谈主性的信仰进度。我认为，如果你不花任何钱就找到一个bug那相等棒。如果没发现诞妄，你就无用费钱，而如果你费钱并找到了一个bug，况兼你要点击的“接受”，那么它会炫耀在括号中，比如1好意思元。
这会存在一种担忧，比如，咱们在筹备中干预了好多，也许东谈主们会复制粘贴代码，或者付费机制会影响用户的体验。我认为，可以酌量把付费机制与居品进行分离，如果用户每月支付一定的用度，就可以免费获取统共的功能。
Lex：可以添加一个“打赏”功能，而不是强制收费。
Arvid：即使是打赏也波及到钞票，可能会影响用户体验。
Aman：用户在共享模子时，东谈主们就也曾在抒发对模子的招供了。
Michael：如果能够开发出一种技巧技能来考证bug是否已被拓荒，那么就可以不必依赖那些依赖于荣誉系统的赏金机制了。
十三、AWS基础设施相等可靠，出现问题的概率聊胜于无Lex：终局和代码之间有些许交互？在终局中运行代码可以获取些许信息？是否可以已毕一个轮回，让模子运行代码并建议如何对代码进行改革？咫尺代码过火施交运行是绝对分离的吗？咫尺，据我所知是可以在终局中使用“Ctrl+K”来辅助进行代码编写。
Aman：可以在Check敕令和Ctrl+K中使用终局险峻文信息。但咫尺还莫得已毕轮回功能，不外这很有真理。要道问题在于，这个轮回是在前台进行如故像之前那样在后台进行。
Lex:后台运行的确很酷，因为它可以援助不同的方式运行代码。此外，还需要酌量数据库方面的问题，举例如何退却模子修改数据库。
Sualeh:有一个可以的处分决策。即正在开发一个新的API，我认为PlanetScale和Turbopuffer数据库都会援助这种功能。当你正在开发一个功能并对数据库进行测试时，施行上你并不想针对庸碌的数据库进行测试，你可以向数据库添加一个分支，而不是去修改主数据库。
这种技巧的已毕方式是为数据库的预写日记添加分支。数据库公司需要连接开发新功能，而分支功能可能成为将来的一个趋势，AI agent也可以利用数据库分支进行测试。
Lex：在此可以对基础设施联系信息忽视一些问题，Cursor团队咫尺是主要使用AWS（亚马逊云科技）吗？在使用AWS的过程中，都遭遇了什么挑战？
Arvid：AWS相等出色，不管在何时使用它的居品老是能够正常使命，诚然完成其缔造过程可能超等吃力。真话说，AWS如实值得相信，如果出现问题，那很可能是你我方的问题。
十四、扩展问题是公司发展难关，隐讳保护也亟待冲突Lex:Cursor看成一家初创公司，在发展中遭遇了哪些挑战？
Michael：跟着央求量级的连接普及，缓存和数据库等通用组件都会遭遇瓶颈。举例，咱们咫尺也曾遭遇遭遇了数据表溢出等问题。此外，咱们构建的一些定制系统，举例用于代码语义索引和问答的检索系统回答关系代码库的一些问题，我也一直认为这是比较辣手的扩展问题之一。
Sualeh：我的超等高级工程师一又友们说，在扩展过程中很难瞻望系统会在那处崩溃。您可以提前尝试瞻望，但是在添加这些特等的内容时，总会发生一些奇怪的事情。具体而言，Cursor将统共的代码进行分块，然后发送代码进行镶嵌，然后将镶嵌代码储存在数据库中，但施行上，并不储存任何代码。尔后就是咱们要确保不引入客户端bug，因为咱们对这些bug相等严格，做事器上存储了许多细节，一切都是加密的。
因此，技巧挑战之一就是如何确保腹地代码库景况与做事器端景况保抓一致。技巧层面上来说，咱们的作念法是将对做事器端的哈希值进行下载，并对比腹地的哈希值，筹备差额，来细则勤劳的文献是什么。但这会增多汇集支拨。如果您使用了Cursor，莫得东谈主但愿有东谈主一直对WiFi施加操作。
而且，这也会对数据库形成巨大支拨。它将读取数十TB的数据库，每秒钟接近20TB或者更早的数据库。这太荒诞。为此，咱们收受了Merkle树结构，只需要息争单个哈希，即名堂的根节点，去稽查哈希值不匹配的子项，并依此类推，可以极地面缩小支拨。
但跟着使用东谈主数的增多，代码库也变得格外浩大。最初，咱们对暗代码库进行了从头胪列，但如今其限制也曾远不如一些领有浩大文献的公司的限制了。建构一个东西很粗略，但扩展到更多东谈主、更多公司，这是个难题。咱们也在起劲处分这些问题。
Aman：的确，索引系统有好多需要琢磨的东西。施行上镶嵌代码才是瓶颈。为了幸免近似镶嵌同样的代码块，咱们收受了一种缓存机制，行将代码块的哈希值与对应的向量缓存起来，这会使得一些公司，在使用Cursor时，代码镶嵌的速率会大大普及，用户不需要储存代码数据，只存储向量数即可。
Lex：咫尺，您认为代码库索引带来的最大受益是什么？短期来看，代码库有什么用呢？
Arvid：最显着的一丝是，当你向找出大型代码库中特定的一些东西时，你可以通过微辞性的发问来进行搜索。比如“我想找到履行X功能的地方。”但是你并不知谈在文本搜索中要输出什么语言。你只需要央求聊天，按照enter敕令来磋议代码库进行聊天。好多时候，模子平日都能够给你提供正确位置。
Lex：为什么Cursor不酌量在腹地进行代码镶嵌等操作？
Arvid：咱们也酌量过这种决策，但已毕起来很迂曲。一些用户使用的是最新的MacBook Pro，但超越80%的用户用的是Windows机器，其中许多机器功能并不是相等遒劲，施行上，腹地模子施行仅适用于最新的筹备机，况兼构建过程也会出现很大的支拨。因此，即使咱们向这样作念，但也如故很难作念得到。
Aman：是的，浩大的数据库只会消耗大都的内存与CPU。此外，正如Arvid所说的那样，腹地模子建设存在着巨大阻力，其中似乎都执政着MOE架构发展，诚然MOE模子对内存带宽的要求更高，况兼有意于腹地运行，但全体模子的限制也会变得更大，需要更多台机器能力运行。我认为，对于编码生成而言，用户但愿能够用到最好、最贤慧、最有智商的模子，但在腹地已毕却很迂曲。
Arvid：施行上我很心爱腹地模式的替代决策。我认为，它仍然处于研究阶段，可以把它假想成，为语言模子推理进行同态加密。用户可以在腹地加密输入的数据，然后发送给做事器进行推理。做事器可以可以对加密数据进行处理，但无法读取数据的具体内容，尔后做事器会把谜底发还给用户并进行加密处理，用户只可通过解密稽查返还的内容。咫尺同态加密的本钱依然很大，如果能够缩小本钱，我相信这会相等值得期待。
天下上有越来越多的信息和数据将流经两个中心化的参与者，但这会有些令东谈主担忧，比如传统黑客的入侵，这是相等可怕的。用户可能会被黑客监控。东谈主们起劲退却不良入侵者使用AI模子，继而引入一些监控机制，但这些监控机制又可能被滥用，比如用户的数据可能会被监控。是以咱们但愿，咱们可以处分同态加密问题。
Lex：我想说，这是统共软件都面对的挑战。就像云可以提供好多便利的功能，东谈主们就越来越依赖它，但是它也存在舛错，这就是为什么需要依靠遒劲的安全措施来反抗一些挫折。但是也又一些具有影响力的公司抑制着这些数据，这就是咱们存在着的现实生存。
Sualeh：是的，我相等记挂。举例Anthropic公司有这种负背负的扩展策略，其中咱们是初级别的，当咱们进入高级别时，任何模子都会出于合理的安全原因，都会但愿对监控有所教唆。我认为这是合理的，但也存在一些时弊，如果统共信息都被见监控，那会相等可怕。
Aman：您认为它（AI模子监控）与云做事供应商有何不同？
Arvid：我认为好多数据一入手并不会流向云供应商，而平日你会把更多的数据提供给AI。一入手用户并不会把我方的数据都放在汇集上，给那些公司或者模子。但咫尺AI模子的监控愈加积贮，云做事中的用户都可以使用加密密钥，而AWS对此却窝囊为力，但在这里只消中心化AI模子提供商能力够看到的确的文本内容。
十五、对于险峻文西席中对于险峻文和模子西席的探讨Lex：在使用Cursor时遭遇的一个问题，当我在Python中写代码的时候，会导入一些内容，模子若何知谈我想在险峻文中提到哪些内容，弄明晰这一丝有多迂曲？
Michael：我认为咱们将来可以在自动筹备险峻文方面作念的更好。需要防御的是，包含自动险峻文需要量度弃取。因此，你为这些模子包含的险峻文愈多，其速率就越慢，这些央求的本钱的就越高，这意味着，你可以调用的模子就会越来越少。此外，对于这类模子来说，如果教唆中包含了太多信息，它们会认为困惑。因此，在险峻文中呈现出的信息准确性和联系性的圭臬要十分高，咱们也但愿能够作念得更好。
咱们在里面也尝试过一些矫正措施，但咫尺该领域还存在一些问题。让语言模子真确达到会通新信息语料库？险峻文窗口能否无穷扩展？模子能够真确作念到关注无穷的险峻文吗？能够对这些险峻文进行缓存而不必近似筹备吗？还有好多想法都在尝试中，这些想法类似于在模子权重学习过程中进行微调。共事看成一家公司，咱们很陶然可以领有更好的检索系统，也但愿可以作念的更好。
Aman：一个敬爱诠释是VS Code（跨平台源代码裁剪器）。
咱们处于一个分叉节点。VS Code的代码是开源的，大型语言模子在预西席过程中也曾见过这些代码，况兼经过微统一RLHF（东谈主类反馈）西席，能够回答与代码联系的问题。因此，当用户磋议对于VS Code的问题时，模子有时能够给出正确的谜底，尽管有时也会出现过失。如果能够西席一个挑升的模子并成立一个会通这些问题的代码库，这会很有研究价值。
另外，咱们对于一个怒放性的研究问题充满风趣，同期也存在着不细则性，即用户是但愿模子在前端履行完统共任务，如故将检索与代码生成进行分离？将来的几个月，可能会出现一些真确有智商的模子，尔后用户可以单独西席一个相等优秀的开源模子并将其看成检索器，在险峻文中为这些更大的模子提供信息。
Lex：如何针对特定代码库进行模子西席？
Aman：有好多方法可以尝试，需要通过尝试细则效果。一件相等稚子的事情，是尝试复制VS Code和一些前沿模子作念过的事情。是以咱们应该赓续进行预西席。某种抓续的预西席，在赓续预西席阶段加入特定代码库的数据，并在指示微调阶段加入对于该代码库的问题。咱们从指示微调入手，建立一个对于代码的成例指示微调数据集，继而抛出更多对于该存储库中的代码问题。
你可以获取更多难以获取的真实数据，或者可以使用合成数据来履行一些操作，让模子对代码各式新组成部分忽视问题。因此，获取代码片断，并让模子对此忽视问题，再将其添加到指示中对数据点进行微调，从表面上讲，这一过程可能会解锁模子会通该代码库问题的智商。
▲播客现场（来源：YouTube）
Lex：想问一些对于OpenAI o1的问题，您认为测试筹备系统在编程中的作用是什么？
Aman：我认为测试时期筹备相等敬爱。因此，跟着数据量和模子大小的蔓延，预西席轨制将使失掉函数和下流任务中的发达越来越好。但是，咱们正在面对一些数据壁垒。这意味着，赓续扩大数据限制变得愈加迂曲。
因此，扩大测试时期筹备是一种敬爱的方法，如果咫尺增多咱们使用推理时期的flop筹备数目，使用Infer Time时，这些模子老是会有更多的flop，但咫尺，咱们也许可以使用雷同大小的模子并运行更永劫期，并获取与更大模子限制极度的薪金。
某些查询可能需要100万亿参数限制的模子能力处理，但这类查询可能只占统共查询的0.1%。在这种情况下，也许有些挥霍元气心灵。而西席一个能够处理99.9%查询的模子，然后可以收受一种方法为那些真确想要更高智能查询的东谈主延长推理时期。
Lex：如何判断哪些问题需要更高水平的智能？是否能够动态地在GPT-4与o1使用之间进行切换？
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：合成数据是可以从AI中获取的一些数据，我认为合成数据主要有三种。第一类是蒸馏，包括语言模子、输出token或token的概率散布，可以用来西席智商较弱的模子。这种方法无法生成比原始模子更遒劲的模子，但可以将上流的高延长模子的智商索要到较小或履行特定任务的模子中。
第二类是合成数据利用了某些问题中一个场地比另一个场地更容易的特色。举例，在bug检测问题中，引入bug比检测bug更容易。咱们需要作念的是，在一个未经充分西席的模子中引入一些bug，然后用这些合成数据西席一个擅长检测bug的模子。
临了一类，是使用语言模子生成可以大意考证的文本。比如，想对系统进行考证，检测语言是否能够达到莎士比亚的水平，你可以让山公或者打字机去打字，最终就能够获取充分的西席数据来培养一个莎士比亚级别的语言模子。
对于具体的率领代码的代码，可以通过测试结尾来判断这个测试代码是否及格，咱们也可以使用模子生成、通过测试的代码来对模子进行西席。但我认为这种方法很难产生施行效力，在怒放式任务或者发杂任务中，很难找到齐全的考证器。
十八、东谈主类反馈联动AI反馈，共同普及模子西席效果Lex：东谈主类反馈的强化学习（RLHF）和AI反馈的强化学习（RLAIF）比较而言如何？对AI模子性能普及都有什么作用？
Aman：RLHF是字据东谈主类反馈信息来进行西席的，我认为，如果能够为专注的任务提供充分的东谈主类反馈那么效果会相等可以。
RLAIF则比较敬爱，它字据敛迹条目履诓骗命，比如使用语言模子来考证处分决策比生成一个处分决策要容易，它更容易奏效，因为RLAIF可以已毕一种递归轮回。
咱们可以将二者进行诱惑，在两者之间遴聘一个均衡点，比如在某型生成的正确代码中，加入极少的东谈主工反馈，不祥50-100个示例，就能够让模子的先验内容与咱们的构想已毕一致。
这看起来与普通的RLHF不同，普通的RLHF平日需要大都的示例对奖励模子进行西席。
十九、AI会在已毕AGI前获菲尔茨奖？Lex：字据你的直观，生成与考证或者生成与排序哪个更容易呢？
Aman：字据直观而言…可能是这样的…既定情况下考证更容易，而非找到诠释。
Sualeh：AI获取菲尔兹奖的可能性有多大？
Sualeh和Arvid：AI更容易获取菲尔茨奖。
Aman：诚然AI也曾处分了许多难题，但咫尺还不细则定理诠释领域中AI效力如何。其次，对于咱们距离处分这些相等相等难的怒放性问题还有多远，我的直观也不那么准确了。
Lex：你认为AI会先获取菲尔兹奖吗？而不是物理学或其他的什么。
Sualeh：我认为百分之一百是会获取菲尔茨奖的。我认为，一些奥数难题，比如伯奇和斯温纳顿-感恩（Birch and Swinnerton-Dyer conjecture）猜度对于AI而言如故相等难的，咫尺还并不知谈如何去处分这些问题。
Aman：AI可能会在已毕AGI之前就获取菲尔茨奖。
Sualeh：如果能获取，我会相等欢快的，我认为，可能在2028或者2030年就会已毕吧。
二十、谈缩放规则的将来，“模子越大越好”不雅念已失效Lex：谈到缩放规则（scaling laws）的话题，民众可以就此谈一下我方看法，对于近况以及将来的发展有何看法？
Aman：最初OpenAI对于缩放规则的论文存在一些诞妄。他们提到了对于优化学习效率的问题。自后，Chinchilla的论题提到了一个更准确的版块。自当时起，东谈主们入手不再专注于筹备优化，而是愈加关注在有限的推理预算下获取更优异的效果。
Aman：我认为，这些缩放规则弧线的维度远比咱们最初仅用于筹备参数数目和数据的维度要丰富得多。比如，推理筹备就是一个不言而谕的维度。我认为，险峻文长度是另一个显着的维度。假定咱们关注推理筹备和险峻文窗口这两个方面，也许咱们想要西席的是某种景况空间模子（SSM）。
它们在处理超长险峻文时，本钱要低得多，速率也要快得多。即使西席时的扩展属性可能需要10倍的筹备量，也就是说，需要虚耗10倍的筹备资源来西席模子，以达到雷同的智商水平，但这亦然值得的。因为咱们最关注的是超长险峻文窗口下的推理本钱预算。因此，东谈主们将来将会这些维度上进行探索。
Lex：你认为民众是否还在相信“越大越好”这一理念？
Aman：对于原始性能和原始AI来说，更大的模子战胜更好。我认为，东谈主们如故会更看好蒸馏技巧。如果咱们干预大都、大都的资金进行西席，以获取最具性价比的模子，那么咱们可以调节些许个参数呢？
这一丝如实值得关注。因为只是在推理时期上尽可能多地干预筹备，这种生动的作念法，东谈主们也曾在Llama模子上尝试过了。或者，只是是对7B（70亿参数）模子进行过度西席，使用的token数目也远远超越了最优需求。
但是，如果你确实留心这件事，也许咱们可以像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。
进一步说，让下一代模子进行并行化使命，这需要浩大的工程量，我认为要让统共这些事情都奏效，需要干预大都的工程技巧使命。比如，能够将工程干预本钱缩小10倍，让那些领有好意思好想法的东谈主真地已毕那些结构，普及40%到50%的GPU的利用率，那研究使命的效率可能会大幅普及。
Sualeh：如果能够看到一个澄莹的矫正道路，那么结尾就会随手可取。我认为，可能OpenAI和其他一些实验室的作念法是对的，它们收拢了这些后果。比如，GPT-4.25。现有方法是有用的，那就不需要酌量翻新，只消当咫尺遭遇瓶颈时，才需要翻新。我认为，如果领有10万亿好意思元的预算，也许施行上会先去扩大限制，然后再对自身的不雅念进行更新。
只消现有的方法有用，就莫得必要尝试新的想法。只消当现有方法遭遇瓶颈时，才需要新的想法。如果领有10万亿好意思元的预算，那么可以先尝试扩大限制，然后从头评估想法。
Aman：咱们都相信，去已毕AGI需要全新的不雅念。咱们也相信，可以在更小的限制内去测试一些新的不雅念，而且咱们有信心这会奏效。对于刻下的实验室而言，将有限的研究和开发东谈主才投注到开发其他的新想法之中是十分迂曲的，毕竟现有决策在将来较永劫期都有用。
二十一、谈编程将来，仍需轨范员领航Lex：你们咫尺处于编程天下的中心。你们认为编程，编程的实质在将来几个月，在将来几年，致使十年会发生什么变化？
Michael：我认为，咱们对将来充满期待，因为轨范员在很长一段时期内都坐在“历史的驾驶座”上。咱们曾谈到过这个问题，这需要轨范员有着高效、代明智商与抑制智商，他们可以修改任何你想修改的东西，况兼对你构建的内容进行快速迭代优化。
此处，与“同筹备机对话形的编程”有离别，与筹备机对话，就好比你在Slack上与工程部门或工程师进行交谈一样，输入需求到一个孤苦的文本框，AI就会自动为你完成这些使命。但这也有些问题，开始会有延长性，其次这也意味着毁灭了一些抑制力。
从根蒂上说，工程施行的履行情况，是字据你构建的细微决策来进行的，其中东谈主的要道作用是不可被AI取代的，要让东谈主类坐在“驾驶位”来掌舵。
而将来编程的情况，很可能是轨范员可以抑制代码库的抽象级别，可以通过不雅察伪代码的姿色对代码库进行裁剪。而且轨范员也可对编程软件的逻辑进行修改，保留其抑制权，这样可以大幅度普及分娩力。
但这只是一个微辞的想法，还需要好多细节需要处分，最终能否已毕还有待不雅察。但是东谈主自己的抑制力、效率以及以东谈主为中心不雅念是相等要害的。咱们认为，对于一些像Arvid之前提到一样，某些编程，可以把它交给聊天机器东谈主。但大多数编程任务东谈主需要东谈主深度参与。
Lex：编程的基本技能是否会发生根人道的变化？
Michael：施行上，我认为咫尺是开发软件相等令东谈主得意的时刻。不管什么时候，好多代码依然如故需要查阅好多难以会通的信息。但今天的编程比往日敬爱多了，东谈主们入手享受编程。咫尺的编程让东谈主具备快速构建事物的智商，东谈主们的抑制力也被极大普及了。
对于那些编程东谈主员来说，这亦然个充满真理的时期，东谈主们的创意和道理道理会被放大，如果你是轨范员，那今天应该愈加防御这部分的特殊性。
Arvid：我也同意，最近咱们正对代码库进行一次比较大的迁徙，将Node.js中的Async Local Storage替换为 Context对象。即使可以借助AI，这个使命也依然需要我与另一个工程师虚耗不祥五天的时期。不外将来，咱们可能只需要给AI展示几个例子，然后这个迁徙任务，就可以在10分钟内完成。轨范员可以借助AI更快的使命，而不需要在预先就酌量太多，而且任何事情，其实都可以先去尝试新方法，尝试的本钱并不高。
Aman：我认为在编程中有两种方式，其一是起劲念念考，仔细寻找处分问题的最好方法然后用有限时期来考证。其二是顺利履行代码，看是如何履行的并就此进行更新。我也更认同后一个决策。
Lex：那对于咫尺想要学习编程的东谈主而言，你们有什么建议呢？应该学习什么？比如Java亦或者PHP？
Aman：我认为，每个东谈主都有学习编程的自身原因。但我认为，施行上那些确实珍惜编程的东谈主，会是最好的轨范员。在咱们团队里面，好多东谈主在使命后依然会用Cursor编写我方的编程，有的东谈主致使会熬到凌晨三点去作念这件事。当他们酸心的的时候，还会说“我需要写点代码。”来宽慰我方。
这种对编码的珍惜，趋势他们成为了最好的轨范员，我也认为这些东谈主将会讲求干预到那些他们研究的事物之中。我认为，将来的编程者们需要会更多地关注“你想要创造什么”。
Sualeh：轨范员可以通过更丰富的方式抒发我方的意图。
结语：共建东谈主机协同体系，改善轨范员生存Lex临了运用Cursor团队的宣言为本次说话作念出总结，在《工程天才》中他们说“咱们是一个应用研究实验室，构建不可念念议的分娩性东谈主机协同系统。”
宣言中写谈：“开始，咱们正在培养将来的工程师，即东谈主类AI轨范员这比任何一个工程师的效率都高出一个数目级。这种搀杂型工程师可以大意地抑制代码库，况兼无需进行低熵键盘操作。即使在最复杂的系统中，他们也会以判断的速率迭代。通过诱惑AI和东谈主类聪敏，他们将比最好的纯AI系统更贤慧、更工程化。咱们是一群研究东谈主员和工程师。咱们构建软件和模子，在有用性和可能性基础上进行发明。咱们的使命也曾改善了斗量车载轨范员的生存。”
Lex称，在这个说话中，至少让编程更敬爱了。
来源：YouTube