Cursor 的崛起：年经常性收入 3 亿美元、工程师们爱不释手的 AI 工具 | Michael Truell

Michael Truell 2025-05-01

Cursor 的崛起：年经常性收入 3 亿美元、工程师们爱不释手的 AI 工具 | Michael Truell

文字记录

开场预览

Michael Truell： 我们的目标是用 Cursor 发明一种全新的编程，一种截然不同的软件构建方式。可以说是某种”代码之后”的世界。我认为，做工程师会越来越多地开始像做逻辑设计师——真正核心在于精确表达你希望一切如何运转的意图。

Lenny Rachitsky： 迄今为止，在构建 Cursor 的过程中你学到的最反直觉的事情是什么？

Michael Truell： 我们完全没想到自己会做任何模型开发。而到了现在，Cursor 中每一个令人惊叹的时刻，在某种程度上都离不开自定义模型。

Lenny Rachitsky： 进入这个角色之前，你希望自己早就知道的是什么？

Michael Truell： 很多人说招聘要快，但我认为我们一开始实际上招得太慢了。

Lenny Rachitsky： 你们在一年半内从零做到一亿美元年经常性收入，这是历史性的。是否有一个拐点，一切开始真正起飞？

Michael Truell： 增长基本上一直沿着指数曲线走。指数增长在数字很低的时候感觉很慢，一开始并没有一飞冲天的感觉。

Lenny Rachitsky： 你认为成功的秘诀是什么？

Michael Truell： 我觉得是……

嘉宾介绍

Lenny Rachitsky： 今天的嘉宾是 Michael Truell。Michael 是 Anysphere 的联合创始人兼 CEO，也就是 Cursor 背后的公司。如果你与世隔绝还没听说过 Cursor——它是目前领先的 AI 代码编辑器，正处于改变工程师和产品团队构建软件方式的最前沿。它也是有史以来增长最快的产品之一，推出仅 20 个月就达到一亿美元年经常性收入，推出仅两年就达到三亿美元年经常性收入。

Michael 在 AI 领域工作了十年。他在 MIT 学习计算机科学和数学，在 MIT 和 Google 做过 AI 研究，同时也是科技和商业史的学生。正如你即将看到的，Michael 对事物的发展方向有着深刻的思考，对软件构建的未来有着清晰的判断。我们聊了 Cursor 的起源故事、他对”代码之后”会怎样的预测、在构建 Cursor 过程中最反直觉的教训、他对软件工程师前景的看法，以及更多内容。

Michael 很少做播客。他唯一做过的另一档播客是 Lex Fridman 的节目，所以能邀请到 Michael 是真正的荣幸。如果你喜欢这档播客，别忘了在你常用的播客应用或 YouTube 上订阅关注。接下来，为你带来 Michael Truell。

“代码之后”的愿景

Lenny Rachitsky： Michael，非常感谢你来参加节目。欢迎来到播客。

Michael Truell： 谢谢，很高兴来到这里。感谢邀请。

Lenny Rachitsky： 我们之前聊天时，你提到了一个很有趣的说法——“代码之后”会是什么这个想法。能谈谈吗？就你的愿景，从代码走向也许是别的东西，事情会怎样发展。

Michael Truell： 我们的目标是用 Cursor 发明一种全新的编程，一种截然不同的软件构建方式。它浓缩到本质就是，你以尽可能简洁的方式向计算机描述你的意图，真正归结到只是定义你认为软件应该如何运作、应该如何呈现。凭借我们今天拥有的技术，并且随着它的成熟，我们认为可以发明一种比现有方式层次更高、效率更高的软件构建方法，在某些情况下也更容易上手。

这个过程将是逐步远离今天软件构建的模样。我想把它与几种流行的未来软件愿景做个对比——至少有一些愿景，我们并不完全认同。一派人认为未来的软件构建会和今天非常相似，主要还是文本编辑、正式的编程语言，比如 TypeScript、Go、C、Rust。还有另一派人，基本认为你只需要在一个机器人里打字，让它帮你构建东西，然后让它修改正在构建的某些内容，就像聊天机器人、Slack 机器人那样——你在跟你的工程部门对话。

我们认为这两种愿景都有问题。在聊天机器人那一端……我们认为实际情况会比这两种都更出人意料。聊天机器人方式的问题在于，它缺乏很多精确性。如果你想让人类对软件的外观和行为有完全的控制权，就需要让他们以一种比”改一下我应用里的这个”更精确的方式来指向自己想要修改什么——在一个脱离整体的文本框里描述是不够的。而那种什么都不变的版本，我们认为是错的，因为我们认为技术会变得非常、非常、非常好。

代码之后的世界

Michael Truell： 所以，代码之后的世界，我认为它会是这样一种状态：你对软件逻辑有一种表示形式，看起来更接近英语，你写下来的是……你可以想象某种形式上的演进，你可以想象编程语言朝伪代码方向的一种进化。你写下了软件的逻辑，你可以在高层面上编辑它，也可以指向它。它不会再是那种密不透风的几百万行代码，而是会更加简洁，更容易理解，更容易导航。那个把疯狂的、难以理解的符号开始向更人类可读、人类可编辑的方向演进的世界，正是我们正在努力迈向的方向。

Lenny Rachitsky： 这是一个非常深刻的观点。我想确保大家不会错过你在这里说的——你设想的未来，基本上从明年开始事情就会开始转变，人们会逐渐远离看到代码、不得不用 JavaScript 和 Python 的方式去思考代码，而会出现一种抽象层，本质上就是伪代码，用更接近英语的句子来描述代码应该做什么。

Michael Truell： 没错。我们认为最终的方向就是这样，而且我们有一个很坚定的看法：这条路径必须经过现有的专业工程师，它看起来像是代码的一种渐进式远离。而且人类一定仍然坐在驾驶位上，人类对所有软件层面都拥有大量控制权，并且不会放弃这些控制权。同时人类还能非常快速地做出修改，拥有一个快速的迭代循环，而不是在后台放一个超级缓慢、要花几周时间的东西来替你做所有工作。

哪些技能会越来越有价值

Lenny Rachitsky： 这就引出了一个问题——对于那些现在是工程师、或者正在考虑成为工程师的人，以及设计师、产品经理来说，在这个代码之后的世界里，你觉得哪些技能会越来越有价值？

Michael Truell： 我认为品味（taste）会越来越重要。人们往往在软件领域谈论品味时，想到的是视觉方面——流畅的动画、配色、UI、UX 等等视觉设计上的东西。视觉层面确实是定义一款软件的重要组成部分，但如前所述，定义一款软件的另一半是它的逻辑，是这个东西怎么运作。

我们已经有非常出色的工具来定义视觉部分，但一旦涉及到软件运作的逻辑，目前我们最好的表示方式实际上就是代码。你可以用 Figma 大致示意一下，也可以写写笔记来描述，但真正让你有一个可运行的原型的还是代码。所以我认为，越来越多地，做工程师会开始感觉像做逻辑设计师，核心将是指定你的意图——你到底想让一切怎么运作。它会更关注”做什么”，而不是”底层具体怎么做”。

我认为品味会越来越重要。软件工程中有一个方面——我们现在离那个状态还差得很远——网上有很多搞笑的梗，说的是人们过于信任 AI 做工程工作后遭遇的各种磨难，比如做出的应用有明显的缺陷、问题和功能故障。但我认为我们最终会到达这样一个阶段：作为软件工程师，你可以不那么小心谨慎——而现在，小心谨慎是一项极其、极其重要的技能。我们会稍微从谨慎中移开一点，更多地转向品味。

与 Vibe Coding 的关系

Lenny Rachitsky： 这让我想到了 vibe coding——你说不用再那么关注细节、顺着感觉走，是不是就是在描述这个？

Michael Truell： 我认为有关联。我觉得 vibe coding 目前描述的正是这种颇具争议的创作状态——你生成了大量代码，但并不真正理解其中的细节。这种创作状态随后会带来很多问题——因为不了解底层细节，你很快就会到达一个瓶颈，你创造的东西大到你自己已经无法修改了。所以我认为我们感兴趣的一些想法——如何在人们不太理解代码的情况下，让他们继续对所有细节保持控制——我认为这些解决方案对于现在正在 vibe coding 的人来说非常相关。我认为目前我们还无法让有品味的人真正对软件拥有完全的控制权。vibe coding 的另一个问题，也是让品味真正从人身上闪耀出来的障碍，在于你可以创造东西，但其中很多是 AI 在做决策，那些决策难以驾驭，而你没有控制权。

Lenny Rachitsky： 沿着这条线再问一个问题。你刚才抛出了”品味”这个词。你说品味的时候，你指的是什么？

Michael Truell： 我指的是对”应该构建什么”有正确的想法。它将越来越成为这样一种状态：毫不费力地将”我想要构建的精确内容”翻译出来——你想要一切怎么运作、你想要它看起来什么样，然后你就能在计算机上把它做出来。而不再那么需要这个翻译层——你和你的团队脑海中有想构建的东西的图景，然后你必须极其辛苦、极其费力地把它铺展成一种计算机可以执行和解读的格式。所以比起 UI 层面的东西，也许”品味”这个词有点不太准确，它更是关于对”应该构建什么”有正确的想法。

Cursor 的起源故事

Lenny Rachitsky： 太好了。好的。这些问题我之后还会回来聊，但现在我想先把镜头拉回到 Cursor 的起点。我从来没听过这个创始故事，我觉得很多人也不知道这一切是怎么开始的。基本上你们在打造的是人类历史上增长最快的产品之一，它正在改变人们构建产品的方式，改变职业、专业，改变很多东西。这一切是怎么开始的？早期旅程中有什么难忘的时刻吗？

Michael Truell： Cursor 最初有点像是先有了方案再去寻找问题，很大程度上源于对 AI 在未来十年会如何变好的反思。有两个决定性的时刻。一个是使用 Code Pilot 的第一个测试版时感到非常兴奋。那是我们第一次使用一款真正、真正、真正有用的 AI 产品——它不仅仅是有些用处，而且完全不是那种只有演示效果的空中楼阁。

除了是我们用过的第一款真正有用的 AI 产品之外，Code Pilot 也是我们采用过的最有用的开发工具之一，甚至没有之一，这让我们非常兴奋。另一个让我们兴奋的时刻，是一系列来自 OpenAI 和其他地方关于规模化（scaling）的论文，这些论文表明即使没有新的想法，AI 也会变得越来越好，只需要拉动一些简单的杠杆，比如扩大模型的规模，以及扩大输入模型的数据规模。

从机械工程到编程

Michael Truell： 因此，在 2021 年底、2022 年初，我们开始对 AI 产品的可能性感到兴奋——这项技术在未来会逐渐成熟。而当我们环顾四周时，发现很多人在谈论如何制造模型，但似乎没有人真正选定一个知识工作领域，去思考随着 AI 越来越强，这个领域会变成什么样子。这让我们开始了一场构思创意的探索：随着这项技术不断成熟，这些知识工作领域在未来会发生怎样的变化？工作的终态会是什么样子？我们用来完成工作的工具会如何改变？模型又需要在哪些方面变得更强才能支撑这些工作方式的变化？当 scaling 和预训练的收益耗尽后，如何继续推动技术能力的提升？

Cursor 最初走了一段弯路。我们其实做了这么一场宏大的分析，然后决定选一个我们认为相对没有竞争、沉闷乏味、没人关注的领域。因为我们觉得：“编程当然很好，AI 当然会彻底改变编程，但已经有人在做了。“所以最开始有四个月的时间，我们其实在做一个完全不同的方向——帮助自动化和增强机械工程，为机械工程师打造工具。

这个方向从一开始就问题重重。我和我的联合创始人都不是机械工程师。我们有朋友是做机械工程的，但我们对这个领域非常陌生。所以从一开始就有点盲人摸象的感觉。问题还包括：如何将现有的模型真正用在机械工程上？我们的结论是，你必须从一开始就开发自己的模型。而要做到这一点非常棘手，互联网上关于各种工具和零部件的 3D 模型数据少之又少，构建这些 3D 模型的步骤描述更是稀缺，然后从拥有这些数据的源头去获取它们本身也是一件困难的事。

但最终，我们清醒了过来。我们意识到自己对机械工程并没有那么兴奋，那不是我们想要为之奋斗一生的事业。我们重新环顾四周，发现在编程领域，尽管过去了相当一段时间，却并没有发生太大的变化。而且我们感觉，那些正在这个领域耕耘的人可能跟我们之间存在某种脱节——他们对未来一切的走向、对整个软件开发将被这些模型所颠覆的图景，似乎没有足够的雄心。正是这一点，把我们推上了打造 Cursor 的道路。

Lenny Rachitsky： 有意思。首先我很喜欢这一点——人们常常听到的建议是去选择一个无聊的行业，因为没人会去竞争，机会就在那里。有时候这确实奏效，但在这段经历中，你们的结论反而是：“不，要去追逐最热门、最受关注的领域——AI 编程、应用构建。“而且你们成功了。你刚才的说法是，你没有看到足够多的雄心，你认为还有更多事情可以做。这感觉是一个很有意思的启示。即使某个领域看起来像是”太晚了，GitHub 在那里，Code Pilot 已经发布了”，还有其他产品——如果你注意到它们只是没有达到应有的雄心水平，或者没有你那么有雄心，或者你发现了它们方法中的缺陷，那仍然存在巨大的机会。这个总结准确吗？

Michael Truell： 完全准确。其中一部分原因在于，你需要存在可以实现的跨越式突破，你需要有可以去做的事情。而我认为 AI 令人兴奋的地方在于——在很多领域都是如此，在我们的领域尤为明显，后面可以谈谈我们如何思考这个问题、如何应对这个问题——天花板真的非常高。是的，如果你环顾四周，即使取每个领域最好的工具，未来几年仍然有大量工作要做。拥有这样的空间、拥有这样高的天花板，我认为在软件领域中是独特的，至少在 AI 领域这种天花板的高度是独一无二的。

为什么选择 IDE 路线

Lenny Rachitsky： 我们回到 IDE 这个问题。你们当时有几条路可以走，其他公司也在走不同的路线。一种是构建一个供工程师在其中工作的 IDE，并在其中添加 AI 的能力；另一种是做一个完全由 AI 代理驱动的开发产品；还有一种是专注于构建最好的编程模型。是什么让你认定 IDE 这条路是最好的选择？

Michael Truell： 那些从一开始就只做模型的人，做的是端到端的自动化编程。我认为他们试图构建的东西跟我们截然不同——我们关心的是让人类对所构建工具中的所有决策保持掌控。而那些人很大程度上设想的未来是：端到端，整个过程由 AI 完成，也许连所有决策也由 AI 来做。所以，一方面是出于个人的兴趣取向。另一方面，我认为我们始终努力对技术目前所处的位置保持强烈的现实主义态度——我们对 AI 在未来几十年将如何成熟感到非常、非常、非常兴奋，但我觉得人们有时会有一种本能反应：看到 AI 在某个领域展现了神奇的能力，就开始将这些模型拟人化，觉得它在这个领域比聪明人强，那它在那个领域一定也比聪明人强。

但这些模型有巨大的缺陷。而我们从一开始的产品开发流程就是围绕 dogfooding 进行的——每天高强度地使用自己的工具。我们绝不想发布任何对自己没用的东西，而我们有条件这么做，因为我们自己就是我们产品的终端用户。我认为这会让你对技术目前的真实水平产生一种清醒的认知，所以这 definitely 让我们意识到必须让人类坐在驾驶位上，AI 无法包办一切。同时，我们出于个人原因也希望把控制权交给人类——这就让你不会只做一家模型公司，也让你不会只做那种没有人类掌控的端到端自动化产品。

至于为什么选择做一个 IDE，而不是现有编程环境的插件，原因在于我们相信编程将会流经这些模型，实际的编程活动在未来几年会发生很大变化。而现有编程环境提供的可扩展性实在、实在、实在太有限了。所以如果你认为 UI 可能会发生很大变化，如果你认为编程的形式会发生很大变化，你就必然需要对整个应用程序拥有控制权。

Lenny Rachitsky： 我知道你们现在有一个 IDE，这大概也会让你对未来走向有一种偏向。但我很好奇，你认为未来的一个重要组成部分是否也会是那些坐在 Slack 里帮你干活的 AI 工程师？有一天这会融入 Cursor 吗？

Michael Truell： 我觉得你会希望能够相当轻松地在所有这些形态之间切换。有时候你可能想让 AI 自己跑一段时间，然后你把它的成果拉回来，非常快速地和它协作，然后再让它自己去跑。所以这种后台与前台形态之间的切换，我认为你会希望它们在一个地方都能顺畅运行。而我认为后台模式特别适合一类编程任务——就是那种不需要太多描述就能精确说明你要什么、以及正确性标准是什么的任务。

Bug 修复就是一个很好的例子，但这显然不是编程的全部。所以我认为 IDE 的形态会随着时间彻底改变，我们打造自己编辑器的做法，前提假设就是它必须随着时间不断演进。我认为这既包括你可以从不同的界面入口派发任务，比如 Slack、你的 issue tracker 或其他什么工具；也包括你盯着看的那块”玻璃板”本身会发生很大变化。我们主要把 IDE 看作是你构建软件的地方。

编程变管理：AI 时代的工程师角色

Lenny Rachitsky： 我觉得人们在谈论 agent 和那些将替你干活的 AI 工程师时，有一件事说得不够，那就是：我们所有人都在变成工程管理者，手底下管着一堆没那么聪明的下属，你得做大量的 review、审批和需求说明。我想听听你对此的想法——有没有什么办法能让这件事变得更容易？因为这听起来真的很难。任何带过大团队的人都会有这种感觉：“天哪，这些初级员工不停地来找我，一遍又一遍地交出质量不高的工作。“就像，“这什么日子啊，太糟了。”

Michael Truell： 是的。也许你得跟它们做一对一……

Lenny Rachitsky： 太多一对一了。

Michael Truell： 是的。我们看到在 AI 上取得最大成功的客户，实际上在使用方式上仍然相当保守。所以我认为今天最成功的用户确实很依赖像我们的 next edit prediction 这样的功能——你的编码流程是正常的，而系统把你接下来要做的动作预测出来。他们也很依赖把交给 AI 的任务范围缩小。在你用来 review 代码的时间比例固定的情况下，对于来自 agent 或整体来自 AI 的产出，有两条路径：一条是，你可以在前期花大量时间把需求写清楚，AI 去干活，然后你去 review AI 的工作成果，然后就完成了。这就是整个任务。

或者你可以把任务切得很碎。先指定一点，AI 写一点，review 一下，再指定一点，AI 再写一点，再 review。自动补全就处在这个谱系的某个位置上。而我们仍然看到，目前使用这些工具最成功的人，往往就是把任务切得很碎，让事情保持相当可控的状态。

Lenny Rachitsky： 听起来没那么糟糕了。我很高兴这里有解决方案。我想回到你们最初构建 Cursor 的时候。你意识到”它准备好了”的那个节点是什么？有没有一个时刻让你觉得”好吧，是时候把它放出去了，看看会发生什么”？

Cursor 的诞生与早期构建

Michael Truell： 我们刚开始构建 Cursor 的时候，对于一直闭门造车而不对外发布这件事相当警惕。而且一开始，我们其实……Cursor 的第一个版本是完全从零手写的。现在我们以 VS Code 作为基础，就像许多浏览器以 Chromium 作为基础一样，然后在此基础上构建。但一开始我们没有这样做，而是从零构建了 Cursor 的原型，这涉及大量工作。我们必须自己搭建……一个现代代码编辑器包含很多东西，包括对多种语言的支持、在语言之间跳转的导航支持、错误追踪支持等。还有像集成命令行、使用远程服务器、连接远程服务器来查看和运行代码的能力。所以我们就进入了这种疯狂快速建造的模式，从零搭建自己的编辑器，同时还要做 AI 部分。

大概五周之后，我们就已经完全在这个编辑器上生活了，抛弃了之前用的编辑器，开始使用新的。等它到了让我们觉得有点好用的程度，我们就把它交到了其他人手上，经历了一个非常短的 beta 阶段。然后从写下第一行代码算起，大概两三个月内我们就向全世界发布了，我觉得大概三个月左右。这绝对是一种”赶紧把东西放到人们面前，然后快速在公开环境中迭代”的思路。让我们意外的是，我们原以为会在很长一段时间内只为几百人构建。但从一开始就涌现了大量关注，以及大量的反馈。那非常有帮助，我们从中学到了很多。那其实也是我们转向基于 VS Code 而不是继续手写编辑器的原因。很大程度上是被早期用户反馈推动的，之后就一直公开迭代至今。

从 $0 到一亿年经常性收入的增长

Lenny Rachitsky： 我喜欢你轻描淡写你们的增长势头的样子。我记得你们大概在一年、一年半左右的时间里从零做到了一亿美元的年经常性收入，这是历史性的。你觉得这种成功的关键是什么？你刚才谈到了 dogfooding 是其中很重要的一部分。你们三个月就做出来了，这太疯狂了。你觉得你们成功的秘诀是什么？

Michael Truell： 三个月那个版本其实不太好，所以我认为一直以来是一种持续的危机感——这个东西有太多可以改进的地方了。最终目标真的是发明一种全新的编程形式，大量自动化我们今天所知的编码工作。无论 Cursor 发展到什么阶段，我们都觉得自己离那个终极目标非常非常远，总有大量事情要做。很多进展并不在于最初那一下冲刺，而在于这个工具持续的演进，让它不断变得更好。

Lenny Rachitsky： 在那三个月之后有没有一个拐点，让一切真正开始起飞？

Michael Truell： 说实话，一开始感觉相当缓慢，也许这源于我们自己的一些急躁。我觉得整体的增长速度至今仍在让我们感到意外。其中最令人惊讶的事情之一是，增长一直相当稳定地遵循一条指数曲线，就是持续的月环比增长，有时会因为我们发布新产品或其他事情而加速。但一条指数曲线在初期看起来其实相当缓慢，数字真的很低，所以一开始并没有那种一飞冲天的感觉。

Lenny Rachitsky： 在我看来这就像是”做好了，他们就会来”真正应验了。你们就是做了一个自己作为工程师也热爱的优秀产品，放到外面，人们就爱上了它，然后口口相传。

产品聚焦与取舍

Michael Truell： 本质上这一切都只靠我们自己——团队专注于打磨产品，用产品本身的质量来替代那些你可以花时间去做的事情。我们确实也花了很多时间在其他方面，比如组建团队就极其重要，做轮值客服支持也很重要。但有些在创业初期人们通常会去做的事情，我们真的任由那些火烧了很久，尤其是在销售和市场营销方面。

所以就只是专注于产品，先做一个你自己喜欢、团队也喜欢的产品，然后再针对一部分用户去做调整。这听起来可能很简单，但你也知道，要真正做好很难。而且有很多不同的方向可以跑，很多不同的产品方向。我认为保持专注、战略性地选择正确的东西去构建、有效地排列优先级，这些都是棘手的。我觉得这个领域另一个棘手之处在于，它是一种新形式的产品构建——它非常有跨学科色彩，我们处于一家普通软件公司和一家基础模型公司之间的某个位置。我们在为数百万人开发产品，这一方面必须做到卓越；但与此同时，产品质量的另一个重要维度是在科学层面越做越多，在模型层面越做越多——在那些合理的领域。所以把这一部分也做好一直很棘手。整体来说我想指出的是，也许有些事情听起来很简单、很容易描述，但做好它很难，而且有很多不同的方向可以跑。

[广告部分已跳过]

反直觉的认知：自研模型

Lenny Rachitsky： 到目前为止，你在构建 Cursor、构建 AI 产品方面学到的最反直觉的事情是什么？

Michael Truell： 我觉得一件对我们来说很反直觉的事情——前面稍微提过一点——就是我们一开始绝对没预料到自己会做任何模型开发。如前所述，当我们进入这个领域时，有些公司从一开始就专注于从零训练模型。而我们之前算过训练需要多少成本，很清楚那不是我们能做的事。而且这也感觉有点像是把注意力放错了地方，因为当时已经有很多出色的模型，为什么要花大量精力去重复别人已经做过的工作？尤其是在预训练方面——把一个什么都不懂的神经网络拿来，然后教它整个互联网。

所以我们一开始认为自己完全不会做这件事。对我们来说从一开始就很清楚的是，现有的模型有很多它们可以为我们做但还没做的事情，因为没有为它们构建合适的工具。然而事实上，我们做了大量的模型开发，在内部这是我们招聘方向上的一个重点，也组建了一支非常出色的团队。

这在产品质量方面对我们来说也是一个很大的胜利。到了现在，Cursor 中每一个令人惊艳的时刻都以某种方式涉及定制模型。所以这确实是反直觉的、令人惊讶的，而且是一个渐进的过程——最初有一个需要自研模型的使用场景，在那个场景下用任何最大的基础模型都真的不合适，那次尝试极其成功，然后我们转移到另一个使用场景，效果也很好，就从那里一步步推进。在做这种模型开发时，一个有帮助的原则是精心选择切入点，不要试图重新发明轮子，不要试图把精力放在那些最好的基础模型已经做得很好的地方，而是聚焦在它们的弱点上，思考如何补充它们。

Lenny Rachitsky： 我觉得这会让很多听到的人感到惊讶——你们居然有自己的模型。当人们谈论 Cursor 和这个领域的所有参与者时，他们往往会称其为 GPT 套壳——只是坐在 ChatGPT 或 Sonnet 之上。你现在的意思是你们有自己的模型，能聊聊背后的技术栈吗？

Michael Truell： 当然可以。我们确实在很多不同方面使用最大的基础模型，它们是给用户带来 Cursor 体验的重要组件。我们使用自研模型的场景，有时候是为了覆盖那些基础模型因成本或速度原因完全无法服务的使用场景。其中一个例子就是自动补全方面。对于不写代码的人来说这可能有点难以理解，但代码是一种很奇特的工作形式——有时候，你接下来 5 分钟、10 分钟、20 分钟、30 分钟要做的事情，完全可以通过站在你身后看一眼就预测出来。

我拿写作来对比一下。很多人熟悉 Gmail 的自动补全，以及在发短信、写邮件等场景中出现的各种自动补全。它们能提供的帮助很有限，因为通常情况下，光看你之前写了什么，确实很难判断你接下来要写什么。但在代码中就不一样了——有时候你编辑了代码库的某一部分，你就需要在代码库的其他部分做相应改动，而你需要怎么改是完全可以预见的。

自研模型与自动补全

所以 Cursor 的一个核心功能就是这种真正量身定制的自动补全体验——预测你接下来要做的编辑操作，跨越多个文件、文件内的多个位置。让模型在这个用例上表现出色，一方面是速度要求——这些模型必须非常快，需要在 300 毫秒内给出补全结果。另一方面是成本因素——我们每次按键都要运行大量、大量、大量的模型推理，不断调整对你下一步操作的预测。此外，这也是一个非常专门的用例——你需要的模型不是擅长补全下一个 token、一段普通文本序列，而是擅长自动补全一系列 diff——查看代码库中已发生的变化，然后生成接下来将要变化的内容，包括删除和新增等所有操作。我们专门针对这个任务训练模型，取得了巨大成功。

模型协作的输入输出管线

所以这是一个不涉及基础模型的领域，基本是我们自己的东西。我们在应用里对此没有太多标注或品牌宣传，但它是 Cursor 非常核心的一部分。另一个使用自研模型的场景是辅助 Sonnet、Gemini 或 GPT 等模型，它们位于这些大模型的输入端和输出端。在输入端，这些模型在整个代码库中进行搜索，试图找出代码库中应该展示给这些大模型的部分。你可以把它想象成一个专门构建的迷你 Google 搜索，用于找到代码库中与这些大模型相关的部分。

在输出端，我们拿到这些模型建议的变更草图——与你这个代码库相关的变更。然后我们有模型去填充细节——高层次思考由最聪明的模型完成，它们花少量 token 做这件事，然后这些更小、更专业、速度极快的模型，配合一些推理技巧，把这些高层次变更真正转化为完整的代码 diff。所以这对提升那些需要专门任务的场景的质量非常有帮助，对提升速度也非常有帮助——速度对我们来说也是产品质量极其重要的一个维度。

Lenny Rachitsky： 这太有意思了。我之前请了 Kevin Weil 上播客，他是 OpenAI 的 CPO（首席产品官），他称这种方式为模型组合（ensemble of models）——同样的思路——

Michael Truell： 是的。

Lenny Rachitsky： ——利用每个模型最擅长的部分，而且正如你所说，使用更便宜的模型还有成本优势。这些其他模型是基于 Llama 之类的开源模型吗？就是你们接入并在此基础上构建的开源模型？

Michael Truell： 是的。再强调一下，我们非常务实地选择做这件事的方式，不想重复造轮子。所以我们会从现有的最好的预训练模型开始，通常是开源模型，有时也会与那些不对外公开权重的大模型提供商合作。因为我们最不关心的就是逐行读取权重矩阵并从中得到某个输出的能力——我们关心的是训练这些模型的能力，对它们进行后训练（post-training）的能力。所以总体而言，是的，开源模型，有时也会与闭源提供商合作进行调优。

护城河与长期防御性

Lenny Rachitsky： 这就引出了很多 AI 创始人和投资者经常思考的一个话题——护城河（moats），以及 AI 领域的防御性。看起来自研模型是这个领域的一个护城河。考虑到正如你所说，不断有人涌入试图抢占你们的份额，你怎么看待这个领域的长期防御性？

Michael Truell： 我认为确实有办法建立惯性和传统意义上的护城河，但我认为总体而言，我们处于一个必须靠持续构建最好的产品来立足的行业，行业中的每个人都是如此。我真心认为天花板如此之高，以至于无论你建立了什么样的壁垒，都可能被超越。我认为这类似于一些跟正常的软件市场、过去正常的企业市场有点不同的市场。我想到的一个是 1999 年底，或者说 90 年代末到 2000 年代初的搜索引擎市场。我想到的另一个在很多方面类似这个市场的，其实是 70、80、90 年代个人电脑和众多计算机的发展。

是的，在每个这样的市场中，天花板都极高，有可能实现飞跃。你可以在很长一段时间内，把一个聪明人的每一小时、每一美元 R&D 投入都持续转化为价值，有用可做的东西不会枯竭。而且在搜索领域（不是个人电脑那个案例），增加分发量也有助于让产品变得更好，因为你可以根据用户数据和反馈来调优算法、调优学习过程。我认为所有这些动态也存在于我们的市场中。所以我认为，也许对我们这样的人来说令人沮丧的事实，但对世界来说令人惊叹的事实是——我认为存在很多可以超越的空间，还有更多有用的东西可以构建。我们距离 5 年、10 年后能竞争的水平还很远，保持这种势头是我们的责任。

Lenny Rachitsky： 所以我听到的是，这听起来更像是一种消费级的护城河——就是持续做最好的产品让人们愿意留下来——而不是通过制造锁定之类的方式，比如 Salesforce 那样——整个公司签了合同，你就必须用这个产品。

Michael Truell： 是的。我觉得重要的是要注意，如果你处于一个很快就用完了有用可做之事的领域，那这不是一个好的处境。但如果你处于这样一个领域——大量投资，以及越来越多优秀的人朝着正确方向努力，能持续给你带来价值——那你就能获得 R&D 的规模经济，深入沿着正确方向打磨技术，达到一个具有防御性的位置。但确实，这有消费级产品的倾向，我真心认为关键就是构建最好的产品。

市场格局：一家独大还是百花齐放

Lenny Rachitsky： 你认为未来这个领域会有一个赢家，还是一个多产品并存的格局？

Michael Truell： 我认为这个市场极其庞大。你之前问过 IDE 的事情。我觉得一些思考这个领域的人有一个误区——他们回顾了过去 10 年的 IDE 市场，然后说”谁在编辑器上赚到钱了？“这是一个极度碎片化的市场，每个人各有各的东西、各有各的配置，只有一家公司真正靠做优秀的编辑器赚到了钱，但那家公司规模也就那样。于是他们得出的结论是，未来也会是这个样子。但我认为人们忽略的是，在 2010 年代为程序员做编辑器，你能做的事情就那么多，而那家靠编辑器赚钱的公司做的是诸如让代码库导航更方便、做一些错误检查和类型检查、提供好的调试工具之类的事。

市场规模与赢家格局

Michael Truell： 这些东西都非常有用，但我认为能为程序员构建的东西——为许多不同领域的知识工作者能构建的东西——可以走得很远、很深。我们所有人面前的核心问题，是大量琐碎工作和知识工作的自动化，是真正把知识工作的方方面面都推向更高层次、更高效率。

所以说了这么多，我想表达的是，我认为我们所处的市场真的非常非常庞大。我认为它比人们过去为开发者构建工具时所意识到的要大得多。我认为会有很多不同的解决方案。我认为会有一家公司——是否能是我们还不确定——但我确实认为会有一家公司构建出通用工具，构建出几乎全世界所有的软件，这将是一门极其具有时代意义的大生意。但我也认为，在这个市场里你可以占据一些细分领域，为特定的市场群体或软件开发周期中非常特定的环节做些事情。但当通用编程从仅仅编写形式化编程语言转向某种层次高得多的东西时，这就是你购买和使用的那个应用。我认为在那个领域一般只会有一个赢家，而且会是一门非常大的生意。

微软与 Copilot 的处境

Lenny Rachitsky： 有意思。顺着这个思路，有趣的是，微软其实最初处在这个领域的中心，拥有出色的产品、出色的分发渠道，你也说过 Copilot 是让你跨过”哇，这里可能真的有大事”这个门槛的东西。但现在感觉他们并没有在赢，反而感觉他们在落后。你怎么看这件事？

Michael Truell： 我认为 Copilot 至今未能达到一些人对它的预期，有一些具体的历史原因，然后也有一些结构性原因。我认为结构性原因是——先说清楚，微软在 Copilot 这个案例上显然是我们工作的重要灵感来源，总体而言我认为他们做了很多了不起的事情，我们自己也在用很多微软的产品——但我认为这个市场对在位者并不太友好。一个对在位者友好的市场，可能是那种能做的事情就那么多、很快就变得同质化，你可以把它和其他产品打包销售，不同产品之间的投资回报率差距很小的市场。在那种情况下，也许没必要买创新方案，买那个和其他东西打包在一起的就行了。

另一个对在位者特别有利的市场结构，可能是一开始你的东西就都在一个地方，切换成本极其痛苦，无论好坏。但我觉得在我们的领域，你可以试用不同的工具，可以自己判断哪个产品更好。这对在位者不太友好，而对你认为会拥有最具创新性产品的一方更友好。至于具体的历史原因，据我了解，最初开发 Copilot 第一版的那个团队的人基本上都已经离开了，去了其他地方做其他事情。我认为在协调所有可能参与这类产品的不同部门和各方之间，也有一定困难。

新用户的 Cursor 使用建议

Lenny Rachitsky： 我想回到 Cursor 的话题。我喜欢问每个构建这类工具的人一个问题：如果你能坐在每个第一次使用 Cursor 的新用户旁边，在他们耳边低语几条建议，帮助他们更成功、最大化地用好 Cursor，你会给出哪一两条建议？

Michael Truell： 我认为现在——我们也希望在产品层面解决这个问题——用好 Cursor 的关键很大程度上在于对模型能力有一种品味，既要了解模型能处理多复杂的任务，也要了解你需要给模型多少说明；同时对模型的质量、它在哪里有缺陷、能做什么不能做什么有一种品味。目前我们在产品中并没有很好地教育用户了解这些，也没有给用户一些明确的操作边界和指引。

但要培养这种品味，我会给两条建议。第一条，如前所述，不要倾向于一次性告诉模型”这是我想要你做的全部”，然后看输出，接着要么失望要么整个接受一个大型任务。相反，我会把事情拆成小块，你可以花基本相同的时间来描述需求，只是拆得更碎。所以你描述一点，得到一点成果，再描述一点，再得到一点成果，而不是写一大段话告诉模型具体该做什么。我认为现在这样做多少有点是灾难的配方。

所以要倾向于把事情拆碎。同时——也许在副项目上做而不是在专业工作上做——我会鼓励人们，尤其是习惯了现有软件开发工作流的开发者，有意识地去摔摔跟头，在一个安全的环境中（比如副项目）去尝试发现这些模型的极限，大胆地把 AI 用到极致。因为我们经常遇到一些人，他们还没有真正给 AI 一个公平的机会，就低估了它的能力。所以总体上倾向于把事情拆小，但要发现你能在多大程度上放手，就在安全环境里刻意去试探极限，培养一种感觉——你可能会对模型在某些地方没有崩溃感到惊讶。

培养对模型能力的直觉

Lenny Rachitsky： 我本质上听到的是，建立一种对模型能做什么、能把一个想法推进多远的直觉，而不是仅仅一步步引导它。而且我猜每次有新模型发布时你都需要重建这种直觉——比如我不知道，4.0 出来的时候你得重新来一遍。这个理解大致对吗？

Michael Truell： 是的。过去几年里，这种变化没有人们最初接触一些大型模型时那么大。这也是我们希望能为用户解决得更好的问题，减轻他们的负担。但这些模型每一个都有略微不同的特性和不同的”个性”。

Lenny Rachitsky： 顺着这个思路，人们一直在争论 Cursor 这类工具到底是更能帮助初级工程师还是高级工程师？是让高级工程师变成十倍工程师，还是让初级工程师更接近高级工程师？你认为今天谁从 Cursor 中受益最多？

Michael Truell： 我觉得两方面都有。这两个群体都以重大方式从中受益。要说谁受益更多，排名有点难。我会说，他们各自陷入的”反模式”不同。初级工程师我们看到的倾向是一刀切地全面依赖，什么都交给 AI，而我们目前还不到那个阶段——在一个专业工具里、与几十上百人协作、在一个长期维护的代码库中，还不能完全端到端地做到这一点。而高级工程师……对很多人来说是这样，当然并非所有人，而且我们其实经常……这些工具被采纳的方式之一是，公司内部有开发者体验团队，这些团队通常由非常资深的人组成，因为他们的工作往往是为组织内其他工程师构建工具、提升效率。

我们也看到一些非常前沿的、在第一线全力尝试采用这项技术的人。但总体而言，我会说，作为一个群体，高级工程师平均来说低估了 AI 能为他们做什么，倾向于固守已有的工作流程。所以相对排名确实有点难说，我觉得他们各自陷入不同的反模式，但总体而言，双方都能从这些工具中获得巨大的收益。

Lenny Rachitsky： 这完全说得通。我喜欢这种两端光谱的描述——一端期望过高，一端期望不足。就像金发姑娘的寓言一样。

Michael Truell： 对。

Lenny Rachitsky： 好的。

Michael Truell： 也许那种资深但还没到 staff 级别的，正好在中间的人。

回望创业初期

Lenny Rachitsky： 有意思。好，还剩几个问题。有什么是你希望在开始这个角色之前就知道的事情？如果你能回到 Cursor 刚起步时的 Michael——其实也没过多久——给他一些建议，你会告诉他什么？

Michael Truell： 这个问题的难处在于，感觉太多来之不易的知识是隐性的，不太容易用语言传达。生活中有一个令人沮丧的事实是，在人类努力的某些领域，你确实需要摔个跟头才能学到正确的东西，要么你就得待在一个在该领域表现出色的典范人物身边。我们在招聘方面就深有体会。我觉得我们其实……我们在招聘方面试图做到极其耐心。

对我们来说非常重要的一点是——无论出于个人原因，还是我认为实际上出于公司战略考虑——拥有一群世界级的工程师和研究员来和我们一起打造 Cursor，是至关重要的。此外，还要找到合适的人——一种智力好奇心和实验精神的特定组合，因为我们需要构建太多新东西；同时还需要一种智识上的诚实，也许还有一种微观层面的悲观和直言不讳，因为噪音太多了……尤其是随着公司成长、业务壮大，保持清醒冷静的头脑也变得极其重要。

把对的人引入公司，这也许是除了打造产品之外，我们最最用心的事情。正因如此，我们实际上等了很久才扩充团队。很多人说招人太快，我觉得我们初期其实是招得太慢了。我认为这是可以改善的，我们本可以做得更好。

我们最终找到的、对我们非常有效的招聘方式——其实并不算新颖——就是去追求我们认为真正世界级的人才，有时候花好几年时间去招募他们。这个方法最终奏效了，但我们一开始其实并不擅长。所以我觉得有很多来之不易的经验教训：关于什么样的人是合适的画像，谁真正适合那个团队，优秀是什么样的，然后是如何与对方沟通这个机会，如何在对方完全没在找工作的情况下让他们兴奋起来。这里面有太多关于如何做好这件事的经验需要学习，而我们花了一些时间才掌握。

Lenny Rachitsky： 对于现在正在招人的团队，有哪些经验教训？你错过了什么或学到了什么？

Michael Truell： 首先，我觉得我们一开始可能过于偏重某个模板——寻找知名院校毕业、非常年轻、在那些知名院校环境中做过高含金量事情的人。而实际上，我们很幸运早期就找到了一些非常优秀、愿意和我们一起做这件事的人，他们其实是职业生涯更晚期的阶段。我觉得我们花了不少时间在一个可能不太对的画像上，其中一部分是资历问题，一部分也是兴趣和经验方面的问题。我们也招到了一些非常非常优秀且很年轻的人，但他们在某些情况下可能不太像是标准模板出来的。

另一个经验是，我们的面试流程在不断演进。现在，我们有一套量身定制的面试题，而且我们面试方式的核心之一是，我们让候选人来公司待两天，和我们一起做一个项目——一个工作测试项目。这个方式效果非常好，越来越多公司在采用这种方式。如何了解别人感兴趣什么，如何展现我们最好的一面，在对方完全没在找工作的时候让他们了解这个机会、展开那些对话——我们在这些方面确实随着时间的推移做得越来越好。

Lenny Rachitsky： 你有最喜欢的面试问题吗？

Michael Truell： 我觉得这个两天工作测试——我们本以为它过了几个人之后就无法扩展了——却出人意料地延续了下来。它的好处在于，它让一个人像真实项目一样端到端地完成。这不是我们会用的工作成果，是一组预先准备好的项目列表。但它让你能看到两天真实的产出，而且不需要耗费其他团队大量时间。你可以把原本半天或一天 onsite 面试的时间分散到两天里，给候选人充裕的时间去做他们的项目，这样反而有助于规模化。

它还能起到一种”你想不想和这个人待在一起”的测试效果，因为你确实要和这个人相处两天，一起吃好几顿饭。我们没想到这个方式会留下来，但它对我们的招聘流程变得极其重要，而且在公司非常早期的阶段，对激发候选人的热情也至关重要。因为在人们使用产品、了解产品之前，当产品还比较初级的时候，你唯一能打动人的就是一群让人觉得特别、想要共事的团队成员。这两天给了我们机会让候选人认识我们，在某些情况下，希望说服他们愿意和我们一起干。这个方式是意料之外的。不完全是面试问题，但有点像一种前置面试。

Lenny Rachitsky： 终极面试题。那为了说清楚你描述的内容，你给他们一个任务，比如”在我们的实际代码库里构建这个功能，和团队一起编码并发布”。大概是这样吗？

团队规模与构成

Michael Truell： 对。我们不会使用真正的 IP，不是完全端到端的正式工作，而是模拟的……但经常是在我们的真实代码库里，“这是一个真实的迷你两天项目。你要端到端地完成它。” 大部分时间让候选人自己动手，也有协作的部分。而且我们是一家比较”封闭”的公司，几乎所有情况下，候选人其实就是和我们坐在同一个办公室里。

Lenny Rachitsky： 你刚才说这个方式一直沿用到现在，那你们现在团队有多大了？

Michael Truell： 我们马上就到 60 人了。

Lenny Rachitsky： 对于你们的规模和影响力来说，这太小了。我原以为会比这大很多。

Michael Truell： 是的。

Lenny Rachitsky： 我猜其中大部分是工程师？

Michael Truell： 是的。需要说明的是，摆在我们面前的一项重要工作是建立一个更大、更优秀的团队，能够持续改进产品，提升我们为客户提供的服务。所以我们并不打算长期保持这么小的规模，也不希望如此。但这个数字之所以小，部分原因是公司内部工程师、研究人员和设计师的占比非常高。许多软件公司如果有大约 40 名工程师，总人数就会超过 100 人，因为有大量的运营工作，而且很多公司从一开始就是以销售为主导的，这非常耗费人力。而我们起步时极其精简，以产品为主导，现在服务于大量的市场客户，在这方面的体系也搭建起来了，但还有很多事情要做。

在 AI 热潮中保持专注

Lenny Rachitsky： 我想问你一个问题。AI 领域现在发生了太多事情，每隔……有各种 newsletter，很多 newsletter，它们唯一的功能就是每天告诉你 AI 领域发生了什么。你经营着一家处于这个行业中心——白热中心的公司，你怎么保持专注？你怎么帮助团队保持专注、埋头苦干、持续构建，而不被那些闪亮的东西分心？

Michael Truell： 我觉得招聘在其中起到了很大作用，如果你招到了态度正确的人。所有这些话都要加个星号——我认为我们在这方面做得不错，但我认为我们也可以做得更好，这也是公司内部应该更多讨论的话题。不过我认为，招聘具有正确倾向的人——那些不太关注外部认可、更专注于构建真正优秀的产品、更专注于做出高质量工作的人，以及那些总体上比较沉稳的人——也许情绪高点不会太高，低点也不会太低。我认为招聘可以帮你解决很多问题。我觉得这其实是整个公司的一个认知：对于任何……你需要流程，需要层级架构，需要很多东西，但对于你引入公司的任何一种组织工具，你想要通过它获得的结果——你其实可以通过招聘具备你期望的那种行为的人，在没有那种组织工具的情况下也走得很远。

一个具体的例子是，我们在工程方面至今没有太多流程也能运转。我觉得我们需要再增加一些流程，但就我们目前的规模来说，不需要太多。这靠的是招聘真正优秀的人。一是招沉稳的人。二是反复讨论这个问题。三是以身作则。对我们个人而言，我们从 2021、2022 年就开始专业地做这件事，一直从事 AI 相关工作，亲眼目睹了各种技术和理念的来来去去。如果你把自己带回到 2021 年末、2022 年初，那时候是 GPT-3 的时代，InstructGPT 还不存在，没有 DALL·E，没有 Stable Diffusion。然后我们经历了所有这些图像技术的出现，ChatGPT 的崛起，GPT-4，所有这些新模型，各种不同模态，所有视频相关的技术，但其中只有极少数真正影响了我们的业务。

所以我觉得我们已经建立了一定的”免疫系统”，知道当某个事件出现时，它是否真的会对我们产生重要影响。这种动态——大量的喧嚣，但真正重要的可能只有少数几件事——我觉得在 AI 领域过去十年中也有类似的映射。学术界发表了海量的深度学习论文、海量的 AI 论文，但奇妙的是，AI 的进步很大程度上可以归功于一些非常简单、优雅且经久不衰的想法，而绝大多数被提出的想法并没有持久的影响力，也没有产生太大影响。这种动态与深度学习作为一个领域的整体演进有几分相似。

人们对 AI 最大的误解

Lenny Rachitsky： 最后一个问题。你认为人们对 AI 的发展方向、对构建方式、对世界将如何改变，最大的误解或尚未完全理解的是什么？

Michael Truell： 人们仍然有点过于偏向光谱的两端——要么认为这一切都会非常快地发生，要么认为这一切全是吹嘘、炒作和骗局。我认为我们正处于一场将产生极其深远影响的技术变革之中。我认为它将比互联网更具影响力，比计算机问世以来我们见过的任何技术变革都更具影响力。我认为这需要时间，这将是一个持续数十年的过程，许多不同的群体都将在推动其前进中发挥重要作用。

要达到一个计算机能够越来越多、越来越多地为我们做事的世界，有各种独立的问题需要逐一攻克，需要在这些问题上取得进展。其中一些是科学层面的——让这些模型理解不同类型的数据、变得更快、更便宜、更智能、适应我们关心的模态、在现实世界中采取行动。还有一些是关于我们如何与它们协作，人类在计算机上应该看到和控制的体验是什么，如何与这些东西共事。

但我认为这需要几十年的时间。将会有大量了不起的工作要做。另外，我认为一种将特别重要的模式——不是在为自己说话——就是在一个特定的知识工作领域进行自动化和增强的公司，既构建底层技术，整合来自各供应商的最佳成果，有时也自主研发，同时又构建面向用户的产品体验。我认为做这件事的人……我们在软件领域尝试这样做，其他人在其他领域做这件事，这些人将产生极其、极其深远的影响。不仅在于用户最终看到的价值，而且我认为随着他们达到一定规模，他们对于推动技术进步也将非常重要，因为我认为他们中最大的赢家将能够建立非常非常庞大的业务。所以，我很期待看到其他领域出现类似的公司。

招聘信息

Lenny Rachitsky： 我知道你们在招人。对于那些感兴趣、想说”嘿，我想去那里工作，参与构建这类东西”的人，你们目前在招什么样的岗位？有没有什么你们特别想尽快招到的角色？好奇的人应该知道些什么？

Michael Truell： 这个团队需要做的事情太多了，很多我们目前还无法胜任。总体来说，首先，如果你觉得我们没有某个岗位，也许你应该主动联系我们——实际情况可能并非如此。也许我们反而能从你身上学到东西，然后发现我们需要一些之前没意识到的东西。但总的来说，我认为我们今年最重要的两件事是：做出这个领域最好的产品，然后让它增长。我们现在基本处于跑马圈地的阶段，全世界几乎所有人要么没有使用我们这类工具，要么使用的是一个发展速度可能较慢的工具。所以增长 Cursor 也是一个大目标。我会说，我们一直在寻找优秀的人才……优秀的工程师、设计师、研究人员，但商业各个方向的人我们也都在找。

Lenny Rachitsky： 既然你提到了工程师，我忍不住想问这个问题——大家都在说”AI 要替我们写所有代码了”，但每家公司仍在疯狂招工程师。所有的基础模型公司，都有大量空缺岗位。

Michael Truell： 没错。我们可不是那种到处鼓吹”大家都可以学会编程”的人。

Lenny Rachitsky： 你觉得工程岗位会不会出现一个拐点，开始放缓增长？我知道这是个很大的问题，但……你觉得这些公司对工程师的需求会越来越大，还是说终有一天满世界都是 Cursor 的 agent 在替我们写代码？

工程师的未来需求

Michael Truell： 我再说一遍，我们的观点是，中间会有一段漫长的过渡期——不会一跃跳到那种你只需要退后一步、把你所有需求说出来，工程部门就帮你搞定的状态。我们非常希望从编程的现状出发逐步演进，我们希望人类始终坐在驾驶位上。而且我们认为，即使在最终状态下，让人们掌控一切仍然非常重要，你需要专业人士来做这件事，来决定软件应该是什么样子。

所以我认为，是的，工程师绝对是需要的。工程师将能够做到比现在多得多的事情。我认为对软件的需求是非常持久的——这不算什么新鲜观点——但我觉得想想现在的情况就很离谱：构建一些相当简单、容易描述的东西——在外人看来应该很简单——却需要耗费巨大的成本和人力，而目前要做好这些事情实在太难了。

现在所有存在的东西，其成本和需求都由当前的水平所决定。如果你能把成本降低一个数量级，我认为我们会有大量的、大量的、更多的东西可以在电脑上做，会有多得多的工具。我有过这种亲身感受……我早期的工作之一实际上是在一家生物技术公司上班，为他们构建内部工具。市面上现成的工具糟糕透顶，完全不适合他们的使用场景。而我当时在构建的内部工具，那边的需求量确实巨大，远远超过了我任职期间能构建的范围。

在电脑上做事的物理条件太好了——你应该基本上能够随心所欲地移动一切、做你想做的一切。但仍然有太多的摩擦。我认为对软件的需求远远超过我们今天能构建的数量——现在做个简单的生产力软件成本堪比一部大片。所以我认为，在很长的未来里，对工程师的需求实际上会更大。

最后的话

Lenny Rachitsky： 还有什么我们没聊到的你想提的吗？有没有什么最后的金玉良言想留给听众的？你也可以说没有，因为我们已经聊了很多了。

Michael Truell： 我们花了很多心思思考如何组建一个团队，既能不断做出新东西，又能持续改进现有的东西。我认为如果我们成功了，IDE 必须发生巨大的变化，未来的样子也必须发生巨大的变化。如果你环顾四周，在我们尊敬的公司中，确实有一些公司能够持续驾驭一波又一波的跨越式创新，不断推动前沿。但这样的公司也很少见，这是一件很难做到的事。所以，一方面是持续思考这个问题，在我们的状态好的时候从第一性原理出发进行反思；另一方面也是深入研究过去那些伟大的先例——这也是我们非常重视的事情。

Lenny Rachitsky： 是的。是的。在开始录制之前，你身后摆了好多书，我就问”那边是什么？“是一本关于某个老牌计算机公司的历史书，在很多方面都很有影响力，但我之前从没听说过。我觉得这很能说明你的特点——很多创新的源泉就是研究过去、研究历史，看什么有效、什么无效。

好的。如果有人想联系你们、可能想应聘的话，在哪里能找到你们？你说过可能有些岗位他们甚至都不知道有，去哪里看，然后听众怎么能帮到你们？

Michael Truell： 好的。如果有人对做这些东西感兴趣，非常乐意聊聊。他们可以去 cursor.com，既能找到产品，也能找到联系我们的方式。

Lenny Rachitsky： 简单明了。Michael，非常感谢你能来。这次对话太棒了。

Michael Truell： 非常愉快。谢谢。

Lenny Rachitsky： 大家再见。

感谢大家的收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅。也请考虑给我们打分或留下评论，这真的能帮助其他听众找到这个播客。你可以在 lennyspodcast.com 找到所有往期节目或了解更多关于这个节目的信息。下期再见。

术语表

原文中文
ARR (Annual Recurring Revenue)年经常性收入
ChromiumChromium（保持原文，开源浏览器引擎项目）
Code PilotCode Pilot（保持原文，可能指 GitHub Copilot 的早期版本）
CursorCursor（保持原文，知名 AI 代码编辑器）
DALL·EDALL·E（保持原文，OpenAI 的图像生成模型）
deep learning深度学习
dogfoodingdogfooding（保持原文，指团队使用自己开发的产品）
end-to-end automation端到端自动化
ensemble of models模型组合（ensemble of models）
FigmaFigma（保持原文，知名设计工具）
IDE (Integrated Development Environment)IDE（集成开发环境，保持原文缩写）
InstructGPTInstructGPT（保持原文，OpenAI 的指令微调模型）
issue trackerissue tracker（保持原文，指问题追踪系统）
Kevin WeilOpenAI CPO（首席产品官），播客嘉宾
Lenny Rachitsky播客主持人、newsletter 作者
LlamaLlama（Meta 的开源大语言模型）
Michael TruellAnysphere 联合创始人兼 CEO，Cursor 背后公司
moats护城河（moats）
next edit predictionnext edit prediction（Cursor 的一项功能，预测程序员下一步的编辑操作）
plug-in插件
post-training后训练（post-training）
SalesforceSalesforce（保持原文，知名企业软件公司）
scaling laws规模化定律
Stable DiffusionStable Diffusion（保持原文，开源图像生成模型）
taste品味（指对”应该构建什么”的正确判断力）
vibe codingvibe coding（保持原文，指一种依赖 AI 生成代码、不太关注底层细节的编程风格）

此文档由 AI 分片翻译（translate_long_document）