Cursor创始人兼CEO最新访谈：品味会越来越重要，开发技能不是重点
2025年5月3日
来源：@AI产品阿颖。转载
原文链接：点这里
难以置信，短短四个月，Cursor 的年经常性收入（ARR）从 1 亿美元飙升至 3 亿美元。现在可以毫不夸张地说，Cursor 是当前行业内增速最快的公司，没有之一。
为什么它能增长得如此迅猛？X 上有人一语道破：当用户清楚知道自己要解决的问题时，他们会直接购买；而如果还需要帮用户意识到问题，就得依赖销售团队不断推动。显然，AI 工具属于前者，优秀的产品也属于前者。
五一假期，我翻译了 Cursor 创始人 Michael Truell 最新一期播客。相信这期内容，能帮大家更好地理解 Cursor 的崛起之谜。虽然不是原创，但翻译也不容易，如需转载，请注明出处。
我全文有 20,000 多字，我先摘录一些关键信息。
- 随着技术的不断成熟，我们将逐步进入一个全新阶段，我称之为后代码阶段。我觉得，肯定会有一套逻辑表示方法，这种逻辑表达更像是英语那样的自然语言，而不是传统的代码。
- “品味” 会变得越来越重要。未来工程师的感觉会越来越像是 “逻辑设计师”。也就是说，他们真正的职责是：明确表达出你希望每一个部分如何工作。
- 我们现在还缺少一种能力，就是让那些通过提示词驱动的用户也能对软件有 “完整的掌控感”。而 “Vibe Coding” 也有个很大的问题：你能做出东西，但很多时候这些东西都是 AI 决定的，而你自己其实不太知道它做了什么、怎么做的。
- 最关键的是要有一个正确的想法，知道要去构建什么。之后的一切，越来越像是一种不费力的实现过程。你说出你想要的东西，然后它就会被构建出来。
- 我们确实会以多种方式使用一些最强大的基础训练模型，它们在打造用户第一次体验的一些关键环节中扮演了重要角色。而在一些我们自己构建的部分，我们会用上自研模型。
- 在我们有一整套核心的面试问题，围绕我们最看重的能力进行评估。我们还设置了 “试用两天” 的环节，让候选人参与一个真实的项目，做一次工作测试。这个方式效果非常好，我们越来越发现这对我们判断很关键。
下面是全部译文。
01 Cursor 创始人的 “后代码时代” 愿景
主持人：谢谢你接受采访。我们刚才聊天时你说了一个很有意思的概念：就是 “后代码时代” 的世界。能不能谈谈你对这个愿景的理解？从 “写代码” 到其他构建方式这个转变，会往什么方向发展？
Michael Truell：我们的目标是用 Cursor 发明一种新的编程方式，一种非常不同的方式来构建软件，这种方式的核心是你用尽可能简洁的方式向系统描述你的意图。
本质上，依然是由用户来定义，他们希望软件如何运作，它应该呈现什么样子。而背后的实现则由我们所拥有的技术完成。
随着技术的不断成熟，我们将逐步进入一个全新阶段。在这个阶段，用户能够用更高效、更高级的方式表达自己的意图，软件的创造过程也将变得更加迅速和富有表现力。整个过程，将逐步摆脱我们今天所理解的软件构建方式，迈向一种全新的演变。
我想把这种方式和未来软件会是什么样子的一些主流观点做个对比，因为我们对其中一些观点其实是有不同看法的。
一种观点认为，未来的软件开发方式其实会和现在差不多，也就是说，主要还是靠文本编辑、用正式的编程语言来写代码，比如 TypeScript、Go、C、Rust 这些。
另一种观点认为，未来你只需要对着一个对话框打字，说你想做什么，它就会帮你把东西构建出来，然后你再对它说你想怎么改，它就再帮你改。有点像你在和一个工程师对话一样，用聊天的方式完成开发。
我们认为，这两种看法其实都有问题。
“聊天式” 开发的最大问题是它缺乏精确性。如果你希望人类能完全掌控软件长什么样、怎么运作，那你就需要允许他们用比 “请把我的 App 改一下” 这种模糊描述更精准的方式来表达修改。
对于那些认为编程方式不会有什么大变化的观点，我也不赞同。我觉得，肯定会有一套逻辑表示方法，这种逻辑表达更像是英语那样的自然语言，而不是传统的代码。
你可以把它想象成某种文档格式的进化版本，也就是说，这个 “语言” 更像是在写文档一样描述软件逻辑，而你可以在更高层次上进行编辑。
你可以对它进行指向式的修改，不再是面对数百万行代码那样令人望而生畏的东西，而是面对一种更容易看懂、更易于导航的结构。
在这个世界里，那些复杂难懂的编程符号会逐渐演变成一种更加适合人类书写和修改的表达方式，而这正是我们正在努力实现的方向。这是一种深刻的转变。
主持人：我想确保大家不要错过你刚才说的重点，那就是：我们设想，在接下来的一年里，事情会开始发生转变。也就是说，人们会开始远离 “看代码、“用 JavaScript 和 Python 去思考” 的方式，取而代之的，是一种新的抽象层出现了。基本上你是用接近英语的句子来描述代码应该做什么。
Michael Truell：是的，我们认为事情最终会发展成这个样子。我们非常坚定地相信，这条路会先从现有的专业人士那里开始过渡。这将是一个逐步 “远离代码” 的演变过程。
但这仍然是一个由人类主导的世界。人类依然会完全掌控软件的各个方面，而不是把这些权力让出去。人类还会具备快速修改软件的能力，比如说想换个界面就能立刻实现，而不是像过去那样，在后台运行一堆超级慢的流程，要等上几个星期来帮你把工作做好。
02 “品味” 越来越重
主持人： 这就引出了一个问题，对于那些现在是工程师、或者正在考虑成为工程师、设计师或产品经理的人来说，在 “后代码时代” 的世界里，你觉得哪些技能会变得越来越重要？
Michael Truell：我认为，“品味” 会变得越来越重要。过去当人们在软件领域谈论 “品味” 时，他们通常指的是视觉层面的，比如界面美感、动画流畅性，或 UI/UX 设计等视觉设计方面的东西。我认为这些视觉方面的能力依然是定义一个软件的重要组成部分。
但就像我之前提到的，我认为定义一个软件的另一半，是它的 “逻辑”，也就是它的运作方式。我们已经有很棒的工具，用来设计视觉界面。
但当你开始涉及 “这款软件是怎么运作的” 这种逻辑层面的问题时，我们现在能用的最好的表达方式，其实还是写代码。
你当然可以用 Figma 之类的工具来 “阅读” 一个界面，你也可以用写笔记的方式来 “描述” 它。但只有当你有一个实际可以运行的原型时，它才真正有意义。
所以我认为，未来工程师的感觉会越来越像是 “逻辑设计师”。也就是说，他们真正的职责是：明确表达出你希望每一个部分如何工作。
以后工程的重心会更多地偏向 “你希望实现什么”，而不是 “你要怎么在底层实现它”。所以，我认为 “品味” 会变得越来越关键。这其实也是工程的一部分，尽管我们现在还远远没有做到这一点。
现在网上有很多关于这个的段子或梗，讲的就是如果你太过依赖 AI 来生成两三行代码，结果会出现各种离谱的问题。比如生成的东西根本用不了，或者有严重漏洞。
但我认为，我们终将会走到一个阶段，在那里你可以 “没那么小心” 地做事。也就是说，我们会从 “事事小心” 逐步过渡到……
主持人： ……更注重 “品味”。这让我想到了 “Vibe Coding”。你刚才说的那种 “不用太纠结细节、顺着流程走” 的方式，是不是类似这种 “Vibe Coding” 的感觉？
Michael Truell：我觉得差不多。现在 “Vibe Coding” 的确描述了我们目前的某种状态，也就是说，你在生成代码时，其实并不真正理解那些细节。
这是一个创造的过程，但这种方式的问题是：因为你不了解底层逻辑，很快你就会遇到限制或瓶颈，到最后你创建的东西可能变成了一个你根本改不动的 “黑箱”。
所以我们现在感兴趣的一些方向在于：如何让用户在 “不了解代码” 的情况下，依然拥有持续控制细节的能力？我认为，这些解决方案对现在正在 “Vibe Coding” 的人来说是非常有意义的。
我们现在还缺少一种能力，就是让那些通过提示词驱动的用户也能对软件有 “完整的掌控感”。而 “Vibe Coding” 也有个很大的问题：你能做出东西，但很多时候这些东西都是 AI 决定的，而你自己其实不太知道它做了什么、怎么做的。
主持人：你不必再过于纠结线上那些实现层面的细节。你刚才提到了“品味”这个词，那在你看来，什么是品味？你是怎么理解它的？
Michael Truell：最关键的是要有一个正确的想法，知道要去构建什么。之后的一切，越来越像是一种不费力的实现过程。你说出你想要的东西，然后它就会被构建出来。
你只需要说出你希望一切该如何运作，你希望它呈现什么样子，然后你就能在电脑上把它实现出来。这样一来，就不再需要那种繁琐的“翻译”过程了。
过去是你和你的同伴有一个想法，然后你得非常费力地手动去排版，把它转换成一种电脑可以理解和执行的格式。所以，我觉得这最终就是要有一个正确的想法，知道该构建什么。
主持人：好，我之后会回到这些话题，但现在我想把我们拉回到 Cursor 的起点。我其实从来没听你讲过它的起源故事，我想很多人现在也不知道这整个事情是怎么开始的。
基本上，你们正在构建的是世界上增长最快的产品之一。它正在改变人们构建产品的方式。这一切是怎么开始的？有没有什么印象深刻的时刻？
Michael Truell：在早期的日子里，Cursor 是一种 “为了解决问题而寻找问题” 的方式开始的。某种程度上，它源自于我对未来十年该如何进步的反思。那时候有两个关键的时刻。一个是，我第一次使用一个最早期版本的 Copilot 时感到非常兴奋。
那其实是我第一次用到一个真正有用的 AI 产品，它并不是为了展示或者娱乐而存在的。它不是用来做那种炫技式的事情。而且，它也是我们第一次用的、会真正去复制粘贴的 AI 代码之一，而且可能是我们用过的最有用的一个，甚至可以说是最有用的一个。
这让我们非常兴奋。另一个让我们兴奋的时刻，是当时一系列关于大模型扩展性的论文发布了，这些论文来自 OpenAI 和其他地方。
它们表明，即使我们没有提出任何新的想法，只是通过做一些简单的事情，比如把模型变大、拓展输入的思路，AI 依然能够变得更强大。
所以到 2021 年底、2022 年初，我们就开始讨论，从现在开始，AI 技术如何一步步走向成熟。
当时我们的感觉是，虽然到处都有人在谈论如何构建模型，但很少有人真正挑出一个具体领域去深挖。而我们当时就在思考，如果 AI 越来越强大，未来会是什么样子？
这让我们进入了一种 “头脑风暴” 的状态，像是一个创意生成的过程。我们在想，每个工作领域在未来 AI 越来越强的时候会发生什么变化？那个最终形态会是什么样子？我们用来工作的工具会怎么变？模型需要进步到什么程度，才能支持这些工作方式的变化？
于是我们就从 “扩展” 和 “预训练” 出发，继续推动技术能力。在一开始的几轮尝试中，我们真的做了一个很完整的头脑风暴，最后我们决定先从一个知识工作领域入手，一个我们认为竞争不激烈、比较冷门、甚至有些无聊的领域。
我们觉得不会有人在意它。我们觉得做编程已经被 Codex 做得差不多了，不该碰。
所以最初那四个月里，我们其实在做一个完全不同的想法：我们想帮助机械工程师自动化、增强他们的工作流程，构建适用于机械工程的工具。
当然，刚开始就遇到了很多问题。比如，我和我的联合创始人请朋友吃饭，一起讨论、学习，但我们对这个领域本身非常不熟悉，有点像“盲人摸象”的状态。还有问题是，怎么才能把现有的模型真正用在机械工程中？
我们发现，其实必须从头开始构建自己的工具。而我们所用的方法也相当复杂。而且，网上并没有很多关于各种工具和零件的 3D 模型资料。你要把这些模型一步步构建出来，从源头找到并整理它们，是一个非常棘手的过程。
但最终，我们还是清醒过来了。我们意识到自己并没有特别想做机械工程这件事。
我们环顾四周，发现编程这个领域其实还没怎么变，尽管大家在这里花了很多时间和精力。
我们感觉那些在做这方面的人，可能跟我们的理解有点脱节。他们似乎对未来的走向并没有足够的野心，没意识到所有软件的创建方式会因为 AI 的发展而发生巨大变化。
于是这就让我们走上了创建 Cursor 的道路。
主持人：太有意思了。首先我很喜欢你们用的这个方式，你经常会听到人们说要去做那些 “无聊行业”，因为机会就在那儿。
有时候确实会奏效。但我特别喜欢你们的这个经历不是去追逐最火、最热门的领域，而是 AI 编码和应用构建这块，结果它却成了。你刚才的表述也很棒，就是你们觉得市场上还没有人展现出足够的野心，而你们认为这里面还有很多事可以做。
所以这给人一个很有价值的启发，即便一个领域看起来好像已经晚了，比如已经有了 Copilot，有了其他产品，但如果你注意到它们的视野还不够远、还不够有雄心，或者你看到它们方法里有些盲点，那这里面依然是有巨大机会的。
Michael Truell：是的，这一点我非常认同。我觉得这确实是一部分原因。有时候会出现 “弯道超车” 的机会，而你需要做的就是找到那些你能做得更好的地方。
我觉得 AI 令人兴奋的一点是，在很多领域里，它都有非常高的上限。我之后可以详细讲讲我们是怎么思考这些事情、怎么做的。
但我觉得，整个 AI 领域的 “天花板” 真的很高。是的，你看看周围，就算拿目前最好的工具来说，在任何一个领域，未来几年里都还有很多事可以做。所以，这个领域的上限之高，是很多其他行业难以相比的。
03 产品的路径思考
**主持人：**回到刚才关于 IDE 的问题。你们可以选择几种不同的路径，其他公司也在走不同的路：有的是在现有开发工具上加插件，把 AI 能力嵌进去；也有的是打造纯 AI 驱动的 “Agent 式” 产品；还有的是专注于构建最强大的编码模型。那你们为什么决定走 IDE 这条路？你们是怎么认为这条路才是最适合的？
Michael Truell：有些团队从一开始就专注于只做一个模型，或者是做端到端的 AI 编程体验。我觉得他们试图构建的东西和我们完全不同。我们更在意的是，让人类保留对每一个决策的控制权，尤其是在他们构建内容的过程中。
而我觉得那些团队更多是在思考一个未来，在那个未来里，整个过程可能全部由 AI 完成，甚至所有的决策也都由 AI 来做。所以当涉及到 “个人 Agent” 这类内容时，我们总是非常现实地看待今天技术的发展阶段。我们对 AI 未来几十年的发展感到非常兴奋。
但我也觉得，有时候人们会有一种本能的冲动：当他们在某个领域看到 AI 做出了神奇的成果，就很容易夸大这些模型的能力，然后就会认为它比这个领域里最聪明的人还强，甚至在另一个领域也会更强。但其实这些模型还是有很大的局限。
从一开始，我们的整个项目流程就是围绕着自己每天密集使用这个工具来展开的。
我们从来不会发布一个对我们自己都没有用的东西。我们有幸可以这样做，因为我们本身就是这个工具的最终用户。我觉得这也让我们更加脚踏实地，清楚知道技术到底发展到了哪一步。
所以，我们确实认为人类必须掌握方向盘，AI 无法包办一切。我们也希望人类保有控制权，这是出于非常重要的原因。
正因为如此，我们既不只是一个 “模型公司”，也不会走那种 “端到端、完全没有人类控制” 的路线。
你之所以要去构建一个 IDE，而不是只是插件式接入现有系统，是因为我们相信，编程将会完全通过这些模型来完成，在未来几年会发生巨大变化。而现在的编码环境，它们的扩展能力太有限了。
所以，如果你认为编程方式会发生巨变，交互形式也会变化，那你就需要拥有对整个应用的完整控制。
主持人：我知道你们现在确实有一个 IDE，这可能也会带来一点偏见，让你们觉得未来就是朝这个方向去的。但我想问的是，你觉得未来很大一部分会不会也包括那种 AI 工程师坐在 Slack 里，替你完成任务？这个模式有可能成为 Cursor 的一部分吗？
Michael Truell：我认为你会希望在这些不同的使用方式之间自由切换，而不需要额外操作。有时候你想让 AI 自己先跑一段，自己去完成一些任务；而有时候你又希望把它生成的内容拿过来，快速参与协作，然后再把结果导出来。
所以，“后台运行” 模式和 “前台交互” 模式，你会希望这些全部整合在一个地方。而后台这部分，确实有一类编程任务特别适合，比如那些你可以很清楚地描述你想要什么，也能很清楚描述正确结果是什么的场景。
比如修 bug 就是个很典型的例子。但显然这只是编程的一部分。所以我觉得 IDE 的形态会发生彻底变化。我们迈出的第一步就是拥有自己的编辑器，这是我们整个构想的基础。
我觉得，未来还会包括能从 Slack、Sentry 之类的服务中启动任务，当然也会包括你盯着屏幕操作的那部分。而这个 “屏幕” 的形式本身也会发生巨大变化。对我们来说，IDE 就是你真正进行构建的地方。
主持人：我觉得在我们谈论 Agent 系统和这些 AI 工程师的时候，有一个问题没有被充分讨论，那就是你其实会变成一个工程经理，手下有一堆 “下属”，但他们并不是很聪明。你得不断去审查、批准、说明需求……你对这件事怎么看？
有没有什么办法可以让这个过程更轻松一些？听起来这就像是很多管理大团队的人都会经历的情况：我手下有一堆初级员工，工作质量不高，我就得不停地检查、修正，一遍又一遍，感觉真的很糟糕。
Michael Truell：也许这真的就是你未来的生活。
主持人：对，说不定有人还真的想要这样的生活。
Michael Truell：我们观察到，使用 AI 最成功的客户，在某些使用方式上其实还是相当保守的。我认为，现在最成功的用户往往会侧重于一些明确的应用场景，比如：“下一个动作是什么？” 或者说，“你正在写的代码，AI 只是帮你把你本来就要执行的动作更快地完成。”
同时，他们也特别善于控制哪些任务是可以交给 AI 的。比如，你可能要花 60% 的时间去审查代码。这个过程中，AI 或者像 Copilot 这样的工具，其实可以带来两种模式的优化：
第一种是，你在开始阶段花很多时间把需求说清楚，然后让 AI 去执行，最后你回来做审查，这样整个任务就完成了。
第二种是，改变你的工作方式，只写一点说明、做一点审查，然后继续往前推，这种方式更像是一个流水线，逐步推进。
我们发现，最成功的用户往往就是用这种方式：把任务分解、交给 AI 一步步完成，同时自己保持对整体流程的掌控。
主持人：听起来没那么糟糕，其实是有解决方案的。那我想回到你们第一次构建 Cursor 的过程。你们是在什么时刻觉得：好，现在可以发布了，看看市场反应？有没有一个明确的时刻让你们有这种感觉？
Michael Truell：我们一开始在做 Cursor 的时候，其实挺焦虑的，不太敢花太长时间不发布就闷头开发。所以最初的时候，我们其实是手工搭了第一个版本。
虽然我们现在是基于 VS Code 构建的，就像很多团队一样把它当作基础框架，但一开始我们没有那样做，而是从头构建了一个自己的编辑器。
这涉及大量工作，比如我们得构建完整的代码编辑器：支持多种语言的解析、跨语言跳转导航、类型检查、内置命令行，支持连接远程服务器，支持查看和运行代码的功能……
我们本可以用一个现成的编辑器框架来迅速搭个东西，但我们决定从零开始自己写一个，然后再在里面加入 AI 元素。大概用了五周，我们就开始全职使用这个新的编辑器，把旧的完全替代了。
等我们发现这个工具 “有点用” 之后，我们就开始让外部用户试用。短暂测试后，我们就在几个月内把它推向了公开市场。从写下第一行代码到发布，也就三个月左右。
我记得大概三个月左右吧。那时候我们的想法是：“赶快发布，让用户来用。” 但我们没想到的事情是，我们本来以为这会是一个面向几百人的小产品，结果刚上线就获得了非常大的关注，还有大量用户反馈。
这些反馈对我们帮助巨大。实际上，正是因为这些早期反馈，我们才决定放弃最初手写的编辑器框架，改为基于 VS Code 开发。这是一个非常明确的转折点，也是我们开始在公众视野中快速迭代产品的起点。
04 Cursor 快速增长的秘籍
**主持人：**我觉得你刚才说得挺低调的，但你们的实际增长非常惊人。我记得你们从零收入增长到一亿美元年化收入，只用了大概一年半时间，这已经可以载入史册了。
你认为像 Cursor 这样的项目取得成功的关键是什么？你之前提到过团队自用是很重要的一部分，比如你们用了三个月就让团队自己上手了，这太疯狂了。那你觉得真正的成功秘诀是什么？
Michael Truell：其实我们最初的版本，也就是那三个月的版本，并不算很好。所以我觉得，成功并不是靠那个最初的冲刺，而是靠持续不断的改进，把产品一点点变得更好。
我们的终极目标是发明一种全新的编程方式，让我们今天熟悉的大量编码流程实现自动化。无论我们现在已经取得了什么成果，Cursor 依然还离这个目标非常远，还有很多很多事情要做。
所以说，那种 “初期冲一下” 的想法，其实被高估了。真正重要的是：工具的持续进化，把它一点点打磨得更好。
主持人：那三个月之后，有没有一个 “转折点”？某个时刻你们感觉：哦，事情真的开始起飞了。
Michael Truell：一开始其实感觉增长还是挺慢的，可能是我们自己也有点不耐烦吧。但从整体来看，增长其实一直都在，只是是那种持续扩展的、稳定的增长。
有时候我们发布新功能会带来一波提速，但总体来说，开始阶段其实没有那种 “爆发性” 的感觉，早期的数字也都很小，所以我们并没有觉得 “一鸣惊人” 或者 “起飞” 了。
主持人：在我看来，这听起来像是 “只要做出一个好产品，用户就会自己来” 的典范。你们做了一个你们自己作为工程师都很喜欢的工具，然后把它发布出去，结果大家也都喜欢上了它。
Michael Truell：确实，从某种意义上说，这一切都是我们团队自己做出来的。大家就是专注在产品上，不去做那些其他可能会分散注意力的事情。当然我们也会花时间处理团队建设、值班支持之类的事，这些对人来说确实也很重要。
但很多人早期在创业时需要做的那些事，比如销售和市场，我们其实有很长一段时间都没怎么碰。我们只是专注在产品上，构建出一个我们自己和团队都喜欢的工具，然后再针对某一类用户去做一些调整。这听起来好像很简单，但实际上要把它做得好是非常难的。
而且一开始你可以走很多不同的方向，甚至是多个正确的方向。我觉得其中一个难点在于：如何专注，如何在战略上挑选最该做的事情，然后有效地设定优先级，这真的很难。
在这个领域，还有一个特别棘手的问题是：我们现在其实是在进行一种全新的产品构建方式。它本身就非常复杂，因为我们处在两种角色之间。一方面像一家普通的软件公司，另一方面又像一个做基础模型研发的研究机构。
我们一方面是在为数百万人开发产品，这就要求用户端的体验必须做到极致。另一方面，我们还必须在科学和模型层面不断深入，在合适的地方持续提升底层能力。
所以，要把这两方面都做好，其实是非常困难的。不过，你也可以说，我们做的这些事听起来可能很简单、讲起来也很好讲，但真正把它们做好是非常困难的，总会遇到各种问题。
主持人：你在构建 Cursor 或 AI 产品的过程中，到目前为止学到的最反直觉的一点是什么？
Michael Truell：我觉得我们到目前为止学到的一件最反直觉的事，我们最初根本没打算做自己的模型开发，但现在这反而成了我们产品里的关键部分。
就像我之前提到的，当我们刚开始做这个项目时，其实已经有一些公司从一开始就专注于从零训练自己的模型。我们当时做过这方面的评估，也很清楚：我们不具备这个条件去做这件事。
我当时还觉得，如果把注意力放在模型训练这块，可能反而是关注错了重点。因为市面上已经有很多很棒的模型了，没必要再重复别人已经做过的事情，尤其是在 “预训练” 这件事上。
那是指你要从一个对世界一无所知的模型开始，然后教它整个互联网的内容。
所以我们当时就觉得，根本不会去做那种（从零训练模型的）事情。而且从一开始我们就很清楚，现有的模型本来就已经能做很多事情了，只不过没有发挥出来，因为工具链还不够完善。
不过话说回来，我们现在确实也在内部做模型开发了，这也成为我们招聘方面的一个重点方向，我们已经组建了一支非常出色的团队。这方面也给我们的产品带来了很大的提升。
所以情况发生了变化。现在我们做的几乎每一个关键部分其实在某种程度上都涉及到了自定义模型。所以这点确实是个转变，也挺出乎意料的。
它是一个逐渐演进的过程：一开始我们有一个很清晰的用例，在那个场景下训练模型是有意义的，后来我们在另一个场景上也取得了很好的效果，然后从那以后就不断扩展。
而在进行这类模型开发时，一件很重要的事是要选择好你的切入点。不要试图重新发明轮子，也不要去做那些已经有特别优秀基础模型的领域；而是要专注于你独特的需求，以及你如何去强化这些模型来满足那些需求。
主持人：我觉得很多人听到你们有自己的模型可能会感到惊讶。因为当人们谈论 Cursor，或者这个领域的其他团队时，常常会说他们只是 GPT 的 “套壳” 而已，也就是只是搭在 ChatGPT 或类似模型之上。
而你刚刚说的是，你们有自己的模型。能不能谈谈一下背后整个技术堆栈是怎样的？
Michael Truell：当然可以。我们确实会以多种方式使用一些最强大的基础训练模型，它们在打造用户第一次体验的一些关键环节中扮演了重要角色。而在一些我们自己构建的部分，我们会用上自研模型。
有时候，我们使用自研模型，是因为某些用例用基础模型来处理根本行不通，可能是因为成本太高，或者速度不够快。
其中一个例子是，这个例子可能对不写代码的人来说有点难理解。代码其实是一种很特别的工作形式。有时候你接下来五分钟、十分钟，甚至二三十分钟的工作，完全是围绕着理解某一个代码片段的上下文展开的。
我可以拿写作来对比一下。大家对写作比较熟悉，比如写博客、写邮件之类的，它们基本上都是完整的表达形式。哪怕只是写短信或邮件，通常你写的每一部分都是相对独立的。
而在写代码时，很多时候你改动了代码的一个部分，接下来你就必须在另一个地方做出相应的改动。而且你一眼就能看出来你应该怎么改。
所以我们在 Cursor 的一个核心设计，是想要让这个过程完整流畅。比如它要能预测你接下来在多个文件、多个地方要进行的系列操作。我们也努力让模型在这个用例上变得非常优秀。
首先，它必须非常快，要能够在 300 毫秒以内给你一个反应。
其次还有成本问题。因为我们要运行大量模型推理，每一次你按下键盘，我们都需要提供一个预测建议，所以这是一个非常频繁、资源密集的任务。
再者，这还是一个非常特殊的场景。我们不是要它去完成一般的文本续写，而是要它完成一系列具体的代码任务。看出代码哪里改动了，然后准确地预测接下来会加什么、删什么，所有这一切。
我们在专门为这个任务训练模型这件事上收获非常大。所以这是我们完全不用基础模型、而是采用自研模型的场景之一。我们在 App 里其实也没有特别去做标注或品牌宣传，但它是我们核心产品体验中非常关键的一部分。
还有一些场景下，我们的模型也会配合像语义检索或 GPT 一起使用。
这些模型会在大模型的输入和输出两端发挥作用。在输入端，它们会去搜索和整理哪些代码片段是最该展示给大模型看的。
你可以把它想象成一个专门针对代码的 “小型 Google 搜索”，它负责找到和你当前任务最相关的代码部分，然后再交给大模型处理。
而在输出端，当大模型给出了一些修改建议或草稿版本后，我们的模型会进一步细化这些修改建议，比如说，大模型只是用少量 Token 提出了些粗略的修改思路，那我们的小模型就会用极快的速度，配合一些推理优化，把这些高层建议真正变成可以执行的代码改动。
这种方式不仅在需要处理专业任务的场景下显著提升了结果质量，同时也大幅提高了响应速度，而速度本身就是我们产品中一个非常关键的维度。
主持人：这真的很有意思。我之前在播客里采访 OpenAI 的 Kevin Weil 时，他也说过类似的观点：他们也是采用多模型组合的方式，在不同任务中选用最合适的模型。
就像你刚才提到的那样，使用便宜模型的成本优势。那么你们这些便宜的模型，是否也是基于 LLaMA 那类模型？就是开源模型，或者是其他团队构建的模型？
Michael Truell：是的，我们会非常有意识地选择在哪些地方使用自研模型。我们不想重复造轮子，所以我们会从现有最优秀的预训练模型开始，通常是一些开源模型。有时候我们也会和那些大型模型的研发者合作，尽管他们不会开放模型的权重。
但我们关心的不是能不能直接拿到那些矩阵权重去运行，我们关心的是能不能在这些模型的基础上继续训练、微调。所以大多数情况下，我们会使用开源模型，有时也会和那些不开源但提供合作机会的模型团队一起做一些事情。
05 Cursor 的护城河
主持人：那这就引出了一个很多 AI 创始人和投资人常常会思考的问题：护城河以及 AI 的防御能力。在这个领域，成本控制是不是一种护城河？你怎么思考长期的竞争防御能力？毕竟你也提到有很多团队一直在快速发布新东西，竞争很激烈。
Michael Truell：是的，确实有各种方式可以构建惯性和传统意义上的护城河。但我觉得，从根本上来说，在这个领域里，我们每个人都有责任持续去打造最好的产品。
我认为这个行业的 “上限” 非常高。也就是说，无论你现在建立了多强的护城河，都远远不够。我甚至觉得，这个市场的格局和传统软件市场、传统企业软件市场都有很大的不同。
我脑海中想到的一个类比是：搜索引擎市场，大概是在 90 年代末到 2000 年代初的那段时间。另外一个可以类比的市场，甚至是 18 世纪 90 年代个人电脑的发展，那种感觉也很像我们现在这个 AI 市场。
这些市场的共同点是，它们的潜力非常巨大。你可以持续地从每一位优秀人才投入的一小时中创造价值，也可以长期不断地从每一笔研发投入中产出新的成果。能做的、有价值的事情一直都还有很多，我们从来没有真正遇到 “已经没有什么可做了” 的那一刻。
特别是在搜索市场，通过更好的分发、获取用户反馈等机制，不断迭代产品，是一种非常有效的方式。
无论是产品分发，还是学习机制，还是从用户行为中获取反馈，我觉得这些机制也同样适用于我们现在所处的 AI 市场。
所以，我觉得也许对我们这些创业者来说是个 “悲哀的现实”，但对整个世界来说却是个 “令人兴奋的现实” 因为这个行业还有很多层的潜力没有被挖掘，还有很多更有用的东西等待我们去构建。
未来五年、十年都还有巨大的空间，而我们要做的就是不停地往前推进。
主持人：听你这样说起来，这更像是一个 “消费级产品” 的护城河逻辑，只要你持续做出最好的产品，用户就会留下来，而不是那种 “锁定用户” 的方式，比如 Salesforce 那样通过和大企业签合同来绑定客户使用产品。
Michael Truell：对，我觉得有一点很重要，如果你是在一个发展停滞、很快就会 “做完该做的事” 的 AI 领域，那其实是个挺糟糕的情况。
但如果你是在一个可以持续投入、不断产出价值的方向，比如投入更多资金、招到更优秀的人才，并让他们专注在对的事情上，那你就可以形成一种 “研发规模效应”。你可以深入打磨技术，往正确的方向推进，并最终打造出具有竞争壁垒的东西。
从消费端来说，我认为这个空间的本质就是：持续把产品做到最好。
主持人：你觉得未来这个领域会出现一个赢家通吃的局面吗？还是说会出现多个类似的产品共存？
Michael Truell：我觉得这个市场实在太大了。你刚刚问我一开始为什么会有这个想法，其实也跟这点有关。有些人一开始对这个领域的看法，是基于过去十年开发工具领域的经验。
他们会问：谁从代码编辑器里赚到了钱？代码编辑器市场非常碎片化，每个人都有自己喜欢的一套工具。
但如果你看商业化真正成功的代码编辑器公司，可能就只有一家，它靠做出优秀代码编辑器赚钱，虽然那家公司确实做得很大。但当时很多人的结论是：未来也会是类似的格局。
我认为他们忽略的一点是，二十世纪的代码编辑器你能做的事情其实是很有限的。
那些能赚钱的代码编辑器公司做的事情，比如让你能更轻松地在代码里跳转，做一些基础的错误检测和类型检查，这些功能虽然有用，但就那么多。
但现在我们能为程序员、为知识工作者构建的工具，覆盖的范围要广得多、深得多。我觉得我们这一代人的任务，就是去自动化那些重复的、低效的工作，把很多行业的 “前端” 重新塑造成更流畅、更高效的工作体验。
所以这就是我绕了一大圈想说的：这个市场真的非常大。
它的潜力远超人们之前对 “为开发者构建工具” 这个领域的理解。我相信未来会有很多整合发生。
我认为最终会出现一家公司，我不确定是不是我们，它会构建出一个通用平台，几乎承担起全球大部分软件的构建工作。这家公司将会成为一代人级别的巨大企业。
但与此同时，也会有很多做 “垂直方向” 或 “某个特定阶段工具” 的公司存在。比如专门为某类用户群体、某个应用场景打造产品的公司。
而从更宏观的角度来说，“编程” 将从过去写正式编程语言的模式，转向一个更高层次的抽象表达。这种变化将带来一整套全新的应用工具。
最终会有一家公司成为这个转变中的 “头号赢家”，而它会是一个非常非常庞大的企业。
主持人：太劲爆了。我觉得有意思的一点是，微软其实最早就站在了这场变革的核心。他们推出了非常出色的产品，拥有强大的分发能力的 Copilot。你曾经也说过，正是 Copilot 让你意识到 “这个方向真的有点东西”。
但现在看起来，他们好像并没有胜出，反而有点被落下了。你怎么看？你觉得发生了什么？
Michael Truell：我觉得有一些具体的历史原因，导致 Copilot 没有达到人们的预期。有些人觉得它挺好用的，但也有些人觉得没有达到预期。
还有一些结构性原因。我想明确一点，像 GitHub Copilot 当然是一个很大的创新，它在很多方面都表现得很好，而且我们自己其实也在用很多微软的产品。
但我认为这个市场对 “老玩家” 其实并不那么友好。
什么是对老玩家友好的市场？比如那种没什么创新空间的市场，很容易变成同质化竞争，你可以把某项产品打包进更大的系统里，反正差异也不大。在那种市场里，你不一定需要买最创新的解决方案，只要买一个集成进去的就行了。
或者还有一种情况是，从一开始用户就完全绑定在某个平台里，很难迁移，那对老玩家也有利。但在我们这个市场里，并不是这样。
在我们的场景下，用户可以随时试用不同的工具，可以很容易判断哪个产品更好。所以这并不是一个对传统玩家特别有利的环境，而是更适合那些能打造出更好产品的团队。
至于历史上的具体原因，据我了解，第一代 Copilot 的核心团队后来基本上都去了别的地方。而且在微软内部，要把这种跨多个部门协作的项目推进，也不是件容易的事。
06 怎么高效使用 Cursor？
主持人：我想回到 Cursor 本身。我很喜欢问每一个在做这类工具的人一个问题：如果你能坐在每一个新用户旁边，看着他们第一次使用 Cursor，轻声在他们耳边提醒一两句话，让他们更容易上手、更成功，你会说什么？
Michael Truell：我觉得目前这个问题，我们希望从产品层面去解决。现在的情况是，要想用好 Cursor，很大程度上取决于用户对模型能力的 “感觉”，也就是你要有判断力，知道它能处理多复杂的任务，知道你到底需要给它多少上下文，知道它什么时候能做成事，什么时候做不到。
而目前我们在产品里并没有很好地引导用户建立这种 “感觉”，也没太多辅助提示、引导路径。所以我们想要改进这点。
如果只能给两个建议的话，我会说：第一个建议是：不要指望你一次性就能给模型一个完美的指令，然后它就能一次性输出你想要的完整结果。这样做你可能会失望，或者干脆就接受了一个完全不理想的结果。
相反，我建议把任务 “切碎” 来处理。你花的总时间可能一样多，但每一步更明确。你先给一点输入，让模型做一点事，再继续给下一步输入，如此反复。不要试图一次性让模型“搞定一切”。
现在试图 “一步到位” 让 AI 全部搞定，这通常会导致糟糕的结果。所以更好的方式是把任务分块处理。
同时，我也建议开发者可以用一个 “副项目” 来练手，而不是直接在主业上尝试。尤其是那些习惯传统工作流的开发者，我鼓励你们勇敢地去尝试、去失败，主动探索这些模型的边界。
在这种 “安全” 的副项目环境中，大胆去试错、去冲一把。你可能会惊讶于这些模型能做到的事情有多少。因为我们确实碰到很多用户，其实还没有真正“给 AI 一个机会”，就轻易下了结论。
所以总结就是：一方面要学会把任务切小分步处理，另一方面也要敢于大胆尝试，在安全环境中探索模型的极限。你可能会发现，它比你想象得强大很多。
主持人：所以我听下来，关键是你得慢慢培养出一种 “直觉”，判断模型到底能做到什么、一个想法可以走多远，什么时候你该引导它一下。而且我猜，每次有新模型发布，比如一旦 GPT-4.0 推出来，你都得重新适应一次？差不多是这样吗？
Michael Truell：是的。过去几年可能不像早期那种新模型带来的冲击那么大，但每次大的模型发布确实会有类似的 “重新适应” 过程。这也是我们希望能为用户更好解决的问题，因为每个模型确实都有不同的 “核心特性” 和 “个性”。
主持人：顺着这个话题，关于像 Cursor 这样的工具，人们总在争论它对哪类工程师更有帮助：是更适合初级工程师，还是能帮助高级工程师效率更高？是让高级工程师如虎添翼，还是让初级工程师更像高级工程师？你怎么看，谁从 Cursor 中受益最大？
Michael Truell：我觉得这两类人都能从中获益，而且是很大的帮助。要让我硬说出个 “谁更受益” 其实挺难的。但我可以说，他们会陷入不同的 “反面模式”。
比如初级工程师，我们看到的倾向是他们会 “全盘依赖” 模型。但目前我们还没达到可以完全依赖模型工作的程度，特别是在专业场景下，涉及到成百上千个协作开发者的大项目中，这种做法并不现实。
而对高级工程师来说（当然并非所有人都这样），我们注意到这些工具最早被大公司采用时，往往是由资深工程师推动的。因为他们通常会负责构建工具，帮助团队提高效率。
这些资深工程师往往走在技术最前沿，他们很敢于尝试，也很懂怎么把工具用到极致。但我们也发现，他们有时会低估这些工具对自己的帮助，坚持沿用原有的工作方式。
所以这两个群体各有各的问题倾向，但总的来说，他们都从中得到了显著好处。
主持人：完全说得通，我很喜欢你说的那种 “两极效应”，一边期待太多，一边又期望太少。感觉就像 “三只小熊” 的故事。
Michael Truell：对，确实（笑）。
主持人：好的。
Michael Truell：或许最适合的是那些 “资深但还没升到架构师” 的工程师。这个群体真的蛮有意思。
07 对创业者的建议
主持人：来到了我最后几个问题。如果你能回到刚开始创业的那个时候，跟那时候的 Michael 说一句话，有没有什么你希望早点知道的事、想对自己说的建议？
Michael Truell：这问题有点难，因为很多宝贵的经验都是 “摔出来” 的，很难直接传授。有些事情就像人类的某些学习方式一样，你要么亲身摔一跤学会，要么你得刚好身边有一个在某方面非常优秀的榜样，跟着他学习。
有一个我们特别深有体会的点，就是 “招聘”。我们从一开始就对招聘非常认真。不只是出于个人情感，更是出于公司战略的考虑：能不能找到一支世界级的工程师和研究员团队，和我们一起做 Cursor，这一点极其重要。
我们需要的人不仅得有智力上的好奇心和探索精神（因为我们要做很多新的东西），还需要有智识上的诚实，以及某种 “微观层面的悲观主义”。因为随着公司发展、业务复杂度增加，保持冷静和判断力真的很重要。
所以，除了构建好产品之外，找到一群真正合适的团队成员，可能是我们做得最对、也最重要的事了。我们在团队扩张这件事上其实拖了很久，因为我们太在意招到对的人。很多人可能觉得我们一开始就扩张很快，但其实我们前期是很刻意地 “放慢了节奏”。
当然我们也可以做得更好。比如后来我们摸索出来一套对我们特别有效的招聘方式，就是专门去接触我们认为非常优秀的人选，虽然它并不新颖。有时候这个过程可能要花上好几年，最后可能不一定能成功合作，但这套方法确实对我们很有用。
但我们在这方面一开始做得并不好，走了很多弯路。比如：你怎么判断某个人是否 “非常优秀”？你怎么和对方沟通机会、激发兴趣，尤其是当对方其实并没有主动找工作的时候？
这些都是我们后来慢慢学会的，而一开始我们确实不太懂怎么做。这些经验是我们一点一点摸索出来的。
主持人：那你现在在招聘上有哪些具体的心得？有没有什么你们当初忽略了、后来才学到的东西？
Michael Truell：我觉得首先要说的是，我们一开始可能在某些方面 “用力过猛” 了。比如我们太倾向于寻找那些在 “传统标准” 上符合某种模板的人。就是那种特别年轻、在名校或科研体系里表现非常突出的人，我们会觉得这些人很有 “可信度”，在那类环境里也能脱颖而出。
但后来我们发现，我们很幸运地在早期就找到了几位非常棒的合作者，他们虽然和这些传统标准有些出入，但却非常出色。所以回头看，我们最初可能把太多时间花在了 “并不完全合适” 的候选人类型上。部分原因是我们对资历的认知，另一个原因是我们对 “经验” 本身的理解。
我们确实招到了一些非常非常优秀、而且非常年轻的人才，但他们在某些方面的背景，跟大家印象中 “理想候选人” 的样子并不完全一样。
另一个重要的教训是，我们后来对面试流程做了很多优化。现在我们有一整套核心的面试问题，围绕我们最看重的能力进行评估。我们还设置了 “试用两天” 的环节，让候选人参与一个真实的项目，做一次工作测试。这个方式效果非常好，我们越来越发现这对我们判断很关键。
还有一点，就是你要学会去了解对方真正感兴趣的是什么，懂得把你的机会展示出来，尤其是当对方并没有主动在找工作的时候。这种对话，我们现在确实比以前做得更好了。我们逐渐掌握了其中的诀窍。
主持人：有没有什么你特别喜欢问的 “面试问题” 之类的？
Michael Truell：我觉得我们那个 “两天工作测试” 的方式，其实原本我们以为只能在早期、招几个人时用一用，但没想到它居然能长期用下去，效果还一直非常好。
它最大的好处是可以让候选人真正从头到尾地做一个真实项目。我们并不会出那种 “像糖果一样的演示题”（意思是轻巧但不实际的 demo 任务），而是给他们一个和现实产品贴近的任务。
而且它并不一定要花非常多时间。比如你原本可能用半天或一天去外面面试，现在用这两天换个方式，反而可以让候选人花更多时间沉下心来做真正的项目。这其实让整个流程更可扩展，也能真正帮你判断这个人是否合适。
这个方式还能帮助你判断一个很关键的问题：你到底想不想和这个人一起共事？因为你会真的和他相处两天，一起吃几顿饭、一起合作。我们当时根本没想到这一点，但它后来变成了我们文化中非常重要的一部分。
而且在公司非常早期的时候，这个过程特别关键。因为那个时候产品还没什么用户，也不是很成熟。那个阶段你能拿出来吸引别人的，可能就只是团队本身。
所以这个两天测试会成为我们让对方 “认识我们” 的一个机会，有些人就是因为和我们相处之后，觉得 “哇，我很想和这帮人共事”，于是就加入了我们。这个方式虽然不算是一个面试问题，但确实是一个非常有力的 “信号”。
主持人：这个可以说是终极面试题了。为了更清楚一点，你的意思是：你们会给候选人一个任务，比如 “在我们真实的代码库里实现一个功能”，让他们和团队一起编码，并把它上线，大概是这样吗？
Michael Truell：对，差不多是这样。虽然我们不会用真实的用户数据，确保不会泄露隐私，但项目本身通常是基于我们实际的代码库。
我们会说：“这是一个真实的小项目，你需要用两天时间完成。” 大多数时候他们是自己做的，但过程中也会有一些合作。
我们公司氛围也挺紧凑的，所以大部分时候，候选人就是坐在我们办公室里，和我们一起度过这两天。
主持人：你刚才说你们现在还在用 “两天工作测试” 这个流程，那你们公司现在规模有多大了？
Michael Truell：我们现在大概 60 人左右，所以从这个规模来说还算很小。
主持人：但你们的影响力远比这个大得多，我本以为你们团队早就更大了。我猜你们大部分人是工程师？
Michael Truell：对，确实是这样。而且要说清楚的是，我们当前的一大重点工作就是继续扩大团队规模，找更多优秀的人，把产品和服务继续做得更好。所以我们也不打算长期维持这么小的规模，我们也在计划增长，希望能发展下去。
现在我们团队人数不多，一个主要原因是：公司内部工程、研究、设计相关人员的占比非常高。很多软件公司如果也有这么多工程师，那整体人数可能早就破百了。因为他们的运营、销售团队很大，那类工作人力密集。
而我们一开始就是非常精干、以产品为导向的团队。虽然我们现在已经服务了大量客户，但能做到这一点，其实靠的就是这种极简、高效的团队模式
主持人：我一直很想问你一个问题：现在 AI 领域每天都在发生新事，更新极快，甚至都出现了专门的新闻通讯来告诉你 “今天 AI 又发生了什么”。而你们又是在这个行业的 “核心地带”，你自己是怎么保持专注的？你又是怎么让团队别被这些 “闪亮的新玩意” 分散注意力，而是专注于埋头做事？
Michael Truell：我觉得 “招聘” 其实是最关键的一环。如果你找到了拥有正确心态的人，那你就已经成功了一半了。我们在这方面做得还不错，但我觉得我们可以做得更好。这也是我们在公司内部越来越多讨论的话题。
我发现，如果你招来的人本身就不太在意外部的评价、更专注于把事情做好、追求高质量的工作输出，而且他们本身就是比较理性冷静、不容易被情绪左右的人，那整个团队就能在嘈杂的信息环境中保持稳定。
其实很多组织管理上的 “制度工具”，比如流程、层级、制度等等，目的就是想让组织更稳定。但如果你能招到那些天然就具备这些行为模式的人，很多问题压根就不会出现，组织管理的压力也会小很多。
举个例子，我们现在在工程团队中还没有特别复杂的流程安排，但这并不是说我们不需要流程，而是因为我们招来的人本身执行力、纪律性都很强。所以我们可以靠着人的素质来 “少走流程”。
我们努力做到的，一是招到对的人，二是作为管理者以身作则，三是希望通过长期文化的塑造去引导整个团队。
对我们来说，自从 2021、2022 年开始就一直在做这件事。我们见证了一个又一个 “新技术” 的兴起与退潮。
如果你回到 2021 年或 2022 年初，那时 GPT-3 还没有指令微调，DALL·E 也没有发布，Stable Diffusion 更是没影，完全没有视频生成这些东西。但后来这一切都出来了。
我们一路经历了这些技术的发布、迭代、消退，也学会了判断：哪些新技术真正对我们的业务有影响，哪些只是热闹。
我们逐渐建立起了一种 “免疫系统”，面对每一个热点时，我们更清楚地知道：它到底是不是我们需要关心的事情。
这种情况在过去十年也出现过。那时候，深度学习领域每年都有大量论文发表。活跃研究者越来越多。
但你会发现，真正推动 AI 进步的，往往是一些非常简单、优雅的核心思想。它们能够长期存在，而大多数提出的想法，其实既不够有力，也撑不过时间的考验。所以这其实是一种 “演化式的筛选过程”，这也是整个深度学习领域演进中的自然规律。
08 什么样的公司会崛起？
主持人：最后一个问题，你觉得大家在理解 AI 的发展方向，或它如何改变世界这件事上，还有哪些误解或者没有真正意识到的地方？
Michael Truell：我觉得很多人现在还陷在一个 “光谱的两端” 上：一端是觉得这一切会发生得非常快，另一端是认为这全是炒作、是骗人的、是泡沫。
而我认为我们正处在一场技术变革的中间阶段，这场变革有可能比过去任何一次都更深远、更重要，无论是对医院、法庭，还是整个社会而言，它都可能产生巨大影响。
我觉得这场变革确实已经开始起飞了，但它会是一个持续几十年的过程。会有很多不同的群体、从不同方向推进这项技术，把我们带到一个全新的世界，在那里，计算机会逐渐能为我们做更多的事。
但要实现这个目标，我们还有很多独立的问题需要一个个去解决，需要在很多方向上持续取得进展。
有些问题属于科学层面，比如如何让模型理解不同类型的数据、如何让模型更快速、更聪明、不再局限于我们人类目前所定义的输入输出方式，甚至是它们如何在现实世界中采取行动。
还有一些问题则跟人类的使用体验有关，人到底该如何与这些模型协作？人类应该在屏幕上看到什么样的界面、体验什么样的交互方式？
我觉得这场变革会持续数十年，也会有无数激动人心的事情出现。我还认为，有一类非常关键的人群将在这个过程中扮演重要角色。
这不是在为我们自己打广告，但我确实觉得：那些致力于自动化和增强 “特定知识工作场景” 的公司，会非常关键。
这些公司会做两件事：一是构建底层技术，包括集成不同的模型、可能部分自研；二是打造真正可用的产品体验，把这些技术变成用户能真正使用起来的工具。
我觉得这些人、这些公司，不仅会给用户带来巨大的价值，而且当他们做到一定规模时，也会推动整个技术的进步。他们会拥有最强的测试平台，也有潜力构建出非常非常大的企业。所以我很期待看到越来越多这样的公司崛起。
主持人：说到这里，你们现在确实也在招人。如果有人对你们感兴趣、想加入这样一个 “做第一批产品” 的地方，你们现在在招什么岗位？有没有特别想招的人？有没有专门面向中国的岗位？现在你最希望补哪些角色？
Michael Truell：我们现在确实有很多事情要做，而我们当前的团队规模，根本不具备去做所有这些事的能力。
所以说实话，我们基本上 “全线开放招聘”。哪怕你没看到我们公开发布的岗位，如果你愿意主动联系，我们可能会发现：你能做的事，正是我们还没意识到我们需要的。
所以我们确实在 “广撒网” 阶段。现在几乎全世界的人，不是已经在用类似我们的工具，就是在用一个更新迭代更慢的版本。我们的目标是快速扩大用户群。
目前我们最核心的两件事是：打造这个领域里 “最好的产品”，然后把它推广到尽可能多的用户那里。我们尤其在寻找优秀的工程师和研究人员，所有相关方向我们都在招人。所以我忍不住要说：如果你对这个领域感兴趣，非常欢迎来找我们聊聊。
主持人：你刚才提到工程师，我也在想这个问题：现在大家都说 AI 将要取代我们所有的代码工作，但与此同时，每家公司又都在疯狂招聘工程师，特别是做基础模型的公司。这怎么解释？
Michael Truell：对，很多事的核心其实还是工程师。
主持人：你觉得我们会不会迎来某个转折点，就是工程师这个角色的需求开始放缓？我知道这是个很大的问题，但现在看起来每家公司都在招工程师。你觉得未来是不是会变成很多代理在帮我们 “自动写软件”？
Michael Truell：是的，我们还是得回到 “那个复杂但真实的中间地带”：不是说你退后一步就能让 AI 全部搞定，不是说你告诉它 “我想做个 App”，然后整个工程部门就能被取代。我们真正想要的，是让人类仍然坐在驾驶位上，让他们来掌控软件的设计、逻辑和目标。
即使在自动化程度很高的未来，我们依然需要专业人士来定义软件该长什么样。所以从这个角度讲，我们还是非常需要工程师的。
不过未来工程师会变得更高效，能完成更多事。因为对软件的需求几乎是无限的，这不是个新观点，但真的想一想，现在即便是那些看上去很简单、很好描述的功能，也要花费大量的人力和资源来开发，成本很高、周期很长。
所以一旦你把开发成本和门槛降下来，我们就可以释放出大量被压抑的 “潜在需求”。
那会带来海量的新软件、工具和服务。比如我之前的工作是在一家生物技术公司做内部工具开发。现成的商业工具根本不适配他们的场景，完全没法用。
而我当时做的那些定制工具，其实有着非常强烈的需求，而且那些需求远远超过了我当时一个人所能完成的工作量。
所以我觉得这方面还有非常大的空间，我们在电脑上的操作，理论上应该可以像 “搬东西” 一样简单灵活。但现实是，这当中还有很多很多摩擦和阻力。
对软件的需求远大于我们当前能构建出来的东西。很多非常简单的工具，因为开发成本太高，现在根本没人去做。所以我觉得在未来很长一段时间内，我们会比现在更需要工程师。
主持人：那还有什么我们没谈到，但你觉得很值得补充的吗？有什么想留给听众的最后一句话？当然你也可以说没有。
Michael Truell：我们最近一直在思考这样一个问题：除了持续改进已有产品，我们怎样搭建一支能持续 “做出全新产品” 的团队？你得改变团队的时间结构，不仅是看现在要做什么，还要看未来该如何配置资源、如何保持创造力。
如果你去看我们很尊敬的一些公司，会发现它们在多个阶段都能不断 “跳上下一波浪潮”，持续推动行业前进。但那真的很难。所以我们也在反思、在思考：用第一性原理去拆解“我们真正该怎么做”，研究历史上哪些公司在这方面做得好。
主持人：就像你刚才在我们开始录音前提到的，你背后那排书架，有很多我从没听说过的早期计算机公司的故事，这其实就说明了一个问题，很多创新，其实都能从过去的历史中找到影子。
我们能从这些 “成功的路径” 里学到很多。那如果有人听完这个播客对你们感兴趣，想了解你们公司、或者看看有没有合适的岗位，他们应该去哪儿找你们？
Michael Truell：如果有人想加入我们、想和我们一起打造下一代 AI 产品，可以直接去 cursor.dev 看看，那里可以找到我们产品，也能找到联系方式，联系非常简单。