发明新型编程：Cursor 背后的愿景

今天的嘉宾是 Michael Tru。Michael 是 Any Sphere 的联合创始人兼 CEO，也就是 Cursor 背后的公司。如果你一直与世隔绝，还没听说过 Cursor，它是领先的 AI 代码编辑器，正处于改变工程师和产品团队构建软件方式的最前沿。它也是有史以来增长最快的产品之一，上线仅 20 个月就达到了 1 亿美元的年经常性收入（ARR），上线仅 2 年就达到了 3 亿美元 ARR。Michael 从事 AI 工作已有 10 年。他在 MIT 学习计算机科学和数学，在 MIT 和 Google 做过 AI 研究，并且是科技和商业历史的学生。你很快就会看到，Michael 对未来的发展方向以及构建软件的未来形态有着深刻的思考。我们聊了 Cursor 的起源故事、他对代码之后会发生什么的预测、他从构建 Cursor 中学到的最反直觉的教训、他对软件工程师未来走向的看法，以及更多内容。Michael 很少上播客。他唯一上过的其他播客是 Lex Freedman 的。所以，能请到 Michael 真是莫大的荣幸。如果你喜欢这个播客，别忘了在你最喜欢的播客应用或 YouTube 上订阅和关注。另外，如果你成为我通讯的年度订阅者，你可以免费获得一年的 Perplexity、Linear、Superhuman、Notion 和 Granola。请访问 lenny'snewsletter.com 并点击 bundle。接下来，有请 Michael Truell。

Today my guest is Michael Tru. Michael is co-founder and CEO of Any Sphere, the company behind Cursor. If you've been living under rock and haven't heard of Cursor, it is the leading AI code editor and is at the very forefront of changing how engineers and product teams build software. It's also one of the fastest growing products of all time, hitting 100 million ARR just 20 months after launching and then 300 million ARR just 2 years since launch. Michael's been working on AI for 10 years. He studied computer science and math at MIT, did AI research at MIT and Google, and is a student of tech and business history. As you'll soon see, Michael thinks deeply about where things are heading, and what the future of building software looks like. We chat about the origin story of Cursor, his prediction of what happens after code, his biggest counterintuitive lessons from building Cursor, where he sees things going for software engineers, and so much more. Michael does not do many podcasts. The only other podcast he's ever done is Lex Freedman. So, it was a true honor to have Michael on. If you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. Also, if you become an annual subscriber of my newsletter, you get a year free of Perplexity, Linear, Superhuman, Notion, and Granola. Check it out at lenny'snewsletter.com and click bundle. With that, I bring you Michael Truell.

本期节目由 EPO 赞助。EPO 是新一代 AB 测试和功能管理平台，由 Airbnb 和 Snowflake 的校友为现代增长团队打造。Twitch、Miro、ClickUp 和 DraftKings 等公司依赖 EPO 来驱动他们的实验。实验对于推动增长和理解新功能的性能越来越重要。EPO 帮助你提高实验速度，同时以其他商业工具无法做到的方式解锁严谨的深度分析。当我在 Airbnb 时，我最喜欢的事情之一是我们的实验平台，我可以轻松地设置实验、排查问题并自行分析性能。EPO 做到了这一切，甚至更多，它采用先进的统计方法，可以帮助你缩短数周的实验时间，并提供易于使用的界面来深入分析性能，以及开箱即用的报告，帮助你避免烦人的长时间分析周期。EPO 还让你轻松地与团队分享实验见解，为 AB 测试飞轮激发新想法。EPO 支持各种用例的实验，包括产品增长、机器学习、变现和电子邮件营销。请访问 geto.com/lenny 查看 EPO，将你的实验速度提升 10 倍。网址是 get epo.com/lenny。

This episode is brought to you by EPO. EPO is a next generation AB testing and feature management platform built by alums of Airbnb and Snowflake for modern growth teams. Companies like Twitch, Miro, ClickUp, and DraftKings rely on EPO to power their experiments. Experimentation is increasingly essential for driving growth and for understanding the performance of new features. And EPO helps you increase experimentation velocity while unlocking rigorous deep analysis in a way that no other commercial tool does. When I was at Airbnb, one of the things that I loved most was our experimentation platform where I could set up experiments easily, troubleshoot issues, and analyze performance all on my own. EPO does all that and more with advanced statistical methods that can help you shave weeks off experiment time and accessible UI for diving deeper into performance and out-of-the-box reporting that helps you avoid annoying prolonged analytic cycles. EPO also makes it easy for you to share experiment insights with your team, sparking new ideas for the AB testing flywheel. EPO powers experimentation across every use case, including product growth, machine learning, monetization, and email marketing. Check out EPO at geto.com/lenny and 10x your experiment velocity. That's get epo.com/lenny.

本期节目由 Vanta 赞助。当涉及到确保你的公司拥有顶级安全实践时，事情很快就会变得复杂。现在，你可以通过一个平台 Vanta 来评估风险、赢得客户信任，并自动化 SOC 2、ISO 27,01、HIPPA 等合规性。Vanta 市场领先的信任管理平台帮助你持续监控合规性，同时报告和跟踪风险。此外，你可以使用 Vanta AI 完成安全问卷，节省数小时。加入数千家使用 Vanta 自动化证据收集、统一风险管理和简化安全审查的全球公司。访问 vanta.com/lenny 即可获得 Vanta 的 1000 美元折扣。网址是 vanta.com/lenny。

This episode is brought to you by Vanta. When it comes to ensuring your company has top-notch security practices, things get complicated fast. Now you can assess risk, secure the trust of your customers, and automate compliance for SOC 2, ISO 27,01, HIPPA, and more with a single platform, Vanta. Vanta's market leading trust management platform helps you continuously monitor compliance alongside reporting and tracking risk. Plus, you can save hours by completing security questionnaires with Vanta AI. Join thousands of global companies that use Vanta to automate evidence collection, unify risk management, and streamline security reviews. Get $1,000 off Vanta when you go to vanta.com/lenny. That's vanta.com/lenny.

Michael，非常感谢你来到这里。欢迎来到播客。

Michael, thank you so much for being here. Welcome to the podcast.

谢谢。很高兴来到这里。感谢你的邀请。

Thank you. It's great to be here. Thank you for having me.

我们之前聊天时，你提到了一个非常有趣的短语，就是“代码之后”这个概念。谈谈这个吧，就像你对未来发展的愿景，从代码转向其他东西。

When we were chatting earlier, you had this really interesting phrase, this idea of what comes after code. Talk about that just like the vision you have of where you think things are going in terms of moving from code to maybe something else.

我们做 Cursor 的目标是发明一种新的编程方式，一种非常不同的构建软件的方法，本质上就是让你以最简洁的方式向计算机描述你的意图。真正归结为，你只需定义你认为软件应该如何工作、应该是什么样子。是的，凭借我们今天拥有的技术，以及随着它的成熟，我们认为你可以达到一个境界，发明一种构建软件的方法，其层级更高、生产力更强，在某些情况下也更容易上手。而且这个过程将逐渐远离今天构建软件的样子。我想把它与未来软件形态的愿景进行对比。我认为大众意识中有几个愿景，我们至少对其中一些持不同意见。一种是，有一群人认为未来的软件构建方式会非常像今天，主要是文本编辑正式的编程语言，比如 TypeScript、Go、C 和 Rust。然后另一群人则认为，你只需向机器人输入内容，让它为你构建东西，然后让它修改你正在构建的东西。这有点像聊天机器人或 Slackbot 的风格，你在和你的工程部门对话。我们认为这两种愿景都有问题。我认为在聊天机器人风格的一端，它缺乏很多精确性。

Our goal with Cursor is to invent sort of a new type of programming, a very different way to build software that's kind of just distilled down into you describing the intent to the computer for what you want in the most concise way possible. And really distilled down to you just defining how you think the software should work and how you think it should look. And yeah, with the technology that we have today and as it matures, we think you can get to a place where you can invent a method of building software that's legions higher level and more productive, in some cases more accessible too. And that process will be a gradual moving away from what building software looks like today. And I want to contrast it with maybe like the vision of what software looks like in the future. I think a couple visions that are in the popular conscious that we at least have some disagreement with. One is there's a group of people who think that software building in the future is going to look very much like it does today, which mostly means text editing formal programming languages like TypeScript and Go and C and Rust. And then there's another group that kind of thinks like, you're just going to type into a bot and you're going to ask it to build you something and then you're going to ask it to change something about what you're building. And it's kind of like this chatbot Slackbot style where you're talking to your engineering department. And we think that there are problems with both of those visions. I think that on the chatbot style end of things, it lacks a lot of precision.

如果你想让人类完全控制软件的外观和工作方式，你需要让他们以比在文本框中输入“改改我的应用”更精确的方式，来示意他们想要改变什么。然后，我们认为那种什么都不改变的世界是错误的。所以我们认为技术会变得好得多。因此，在代码之后的世界，我认为会是这样：你拥有一个软件逻辑的表示，它看起来更像英语。你写下来，可以想象成文档形式，也可以想象成编程语言向伪代码的演进，你写下了软件的逻辑，可以在高层编辑并指向它。它不再是难以理解的数百万行代码，而是更简洁、更易于导航的东西。但那个让疯狂难懂的东西变得更可读、更可编辑的世界，正是我们努力的方向。

If you want humans to have complete control over what the software looks like and how it works, you need to let them gesture at what they want to be changed in a form factor that's more precise than just typing 'change this about my app' in a text box removed from the whole thing. And then the version of the world where nothing changes, we think is wrong. So we think the technology is going to get much, much better. And so a world after code, I think, looks like a world where you have a representation of the logic of your software that looks more like English. You have written down, you can imagine in documentation form, you can imagine in an evolution of programming language towards pseudo code, you have written down the logic of the software, and you can edit that at a high level and point at it. It won't be the impenetrable millions of lines of code; it'll instead be something that's much terser and easier to navigate. But that world where the crazy hard-to-understand thing becomes a little bit more human-readable and human-editable is one we're working toward.

这是一个深刻的观点。我想确保人们不会错过你在这里说的内容，那就是你在未来一年所设想的，本质上就是当事情开始转变时，人们甚至不再看到代码，不再需要以 JavaScript 和 Python 这样的代码来思考，会出现这种抽象，本质上是用英语句子描述代码应该做什么的伪代码。

This is a profound point. I want to make sure people don't miss what you're saying here, which is that what you're envisioning in the next year essentially is when things start to shift, people move away from even seeing code, from having to think in code like JavaScript and Python, and there's this abstraction that will appear, essentially pseudo code describing what the code should be doing more in English sentences.

是的，我们认为最终会是这样。而且我们非常坚定地认为，这条路径要经过现有的专业工程师，看起来就像是从代码中演进出来。而且它肯定看起来像是人类仍然坐在驾驶座上，对软件的各个方面拥有大量控制权，并且不会放弃这种控制权。同时，人类还要有能力快速做出改变，就像拥有一个快速的迭代循环，而不是在后台有一个超级慢、需要几周才能完成所有工作的东西。

Yes, we think it ends up looking like that. And we're very opinionated that that path goes through existing professional engineers, and it looks like this evolution away from code. And it definitely looks like the human still being in the driver's seat, having a ton of control over all aspects of the software and not giving that up. And also the human having the ability to make changes very quickly, like having a fast iteration loop, and not just having something in the background that's super slow and takes weeks to do all your work for you.

这就引出了一个问题，对于当前是工程师或考虑成为工程师、设计师或产品经理的人来说：在代码之后的世界里，你认为哪些技能会越来越有价值？

This begs the question for people who are currently engineers or thinking about becoming engineers or designers or product managers: what skills do you think will be more and more valuable in this world of what comes after code?

我认为品味会越来越有价值。而且我认为，当人们想到软件领域的品味时，他们通常会想到视觉效果，或者对流畅动画、配色、UI/UX 等方面的品味，也就是事物的视觉设计。我认为越来越多地，视觉方面是定义软件的重要组成部分，但如前所述，定义软件的另一半是事物运作的逻辑。我们有很棒的工具来指定视觉效果。但当涉及到软件如何运作的逻辑时，目前我们最好的表示就是代码。你可以用 Figma 或写笔记来示意，但真正的是当你有一个实际可用的原型时。所以我认为，越来越多地，成为一名工程师会开始感觉像成为一名逻辑设计师。实际上，这将关乎指定你的意图，即你希望一切如何精确运作。这将更多关乎“是什么”，而少一点关乎“如何”在底层实现。所以，是的，我认为品味会越来越重要。我认为软件工程的一个方面，我们现在离这个还很远，而且互联网上有很多有趣的梗，关于人们在工程方面过度信任 AI 时可能遇到的考验和磨难，比如构建出有明显缺陷和功能问题的应用。但我认为我们会达到一个地方，在那里你作为软件工程师可以不必那么小心，而目前这是一项极其重要的技能。而且，是的，我们会从小心谨慎稍微转向品味。

I think taste will be increasingly more valuable. And I think often when people think about taste in the realm of software, they think about visuals or taste over smooth animations, coloring things, UI/UX, the visual design of things. And I think more and more, the visual side is an important part of defining a piece of software, but as mentioned before, the other half of defining a piece of software is the logic of how the thing works. And we have amazing tools for speccing out the visuals. But when you get into the logic of how a piece of software works, really the best representation we have of that is code right now. You can gesture at it with Figma and with writing down notes, but it's when you have an actual working prototype. So I think more and more, being an engineer will start to feel like being a logic designer. And really it will be about specifying your intent for how exactly you want everything to work. It will be more about the 'what' and a little bit less about the 'how' exactly you're going to do things under the hood. So yeah, I think taste will be increasingly important. I think one aspect of software engineering, and we're very far from this right now, and there are lots of funny memes going around the internet about the trials and tribulations people can run into if they trust AI for too many things when it comes to engineering, around building apps that have glaring deficiencies and functionality issues. But I think we will get to a place where you will be able to be less careful as a software engineer, which right now is an incredibly important skill. And yeah, we'll move a little bit from carefulness and a little bit more towards taste.

这让我想到了“氛围编程”。你谈到不必过多考虑细节，只是顺其自然，这是否就是你所描述的？

And this makes me think of vibe coding. Is that kind of what you're describing when you talk about not having to think about the details as much and just kind of going with the flow?

我认为这是相关的。我认为“氛围编程”现在描述的正是这种相当有争议的创作状态，你生成大量代码，但并不真正理解细节。这种创作状态随后会带来很多问题，因为如果不理解底层细节，你很快就会达到一个受限的点，你创造的东西大到无法改变。所以我认为我们感兴趣的一些想法，关于如何让人们在不真正理解代码的情况下持续控制所有细节，我认为这些解决方案对现在进行“氛围编程”的人非常相关。我认为目前我们缺乏让创造者真正完全控制软件的能力。所以“氛围编程”的一个问题，以及让品味真正从人们身上闪耀出来，就是你可以创造东西，但很多是 AI 在做你不知情且无法控制的决定。

I think it's related. I think vibe coding right now describes exactly this state of creation that is pretty controversial, where you're generating a lot of code and you aren't really understanding the details. That is a state of creation that then has lots of problems, because by not understanding the details under the hood, you very quickly get to a place where you're limited at a certain point, where you create something that's big enough that you can't change. And so I think some of the ideas we're interested in, around how do you give people continued control over all the details when they don't really understand the code, I think solutions there are very relevant to the people who are vibe coding right now. I think right now we lack the ability to let the makers actually have complete control over the software. And so one of the issues with vibe coding and letting taste really shine through from people is you can create stuff, but a lot of it is the AI making decisions that you are unaware of and you don't have control over.

沿着这个思路再问一个问题。你提到了“品味”这个词。当你说品味时，你在想什么？

One more question along these lines. You throw out this word taste. When you say taste, what are you thinking?

我在想的是，对于应该构建什么有正确的想法。然后，这将越来越多地关乎“这就是你想要构建的，这就是你希望一切如何运作，这就是你希望它看起来如何”的轻松转换。然后你将能够在计算机上实现它，而不再那么关乎这种转换层，即你和你的团队对要构建的东西有一个构想，然后必须费力地、劳动密集地将其布局成计算机可以执行和解释的格式。所以，是的，我认为这更多不在 UI 方面。

I'm thinking having the right idea for what should be built. And then it will become more and more about the effortless translation of 'here's exactly what you want built, here's how you want everything to work, here's how you want it to look.' And then you'll be able to make that on a computer, and it will less be about this translation layer of you and your team having a picture of what you'd want to build and then having to painstakingly, labor-intensively lay that out into a format that a computer can then execute and interpret. And so yeah, I think it's less on the UI side of things.

也许“品味”这个词有点用词不当，但其实就是对应该构建什么有正确的想法。太棒了。好的，我稍后会回到这些话题，但我想先把我们拉回到 Cursor 的起源。我从来没听过创始故事。我觉得没多少人知道这一切是怎么开始的。基本上，你们正在打造世界历史上增长最快的产品之一。它正在改变人们构建产品的方式，改变职业、行业。它改变了很多东西。这一切是怎么开始的？早期旅程中有哪些难忘的时刻？

Maybe taste is a little bit of a misnomer, but just about having the right idea for what should be built. Awesome. Okay, I'm going to come back to these topics, but I want to actually zoom us back out to the beginnings of Cursor. I've never heard the origin story. I don't think many people know how this whole thing started. Basically, you guys are building one of the fastest growing products in the history of the world. It's changing the way people build products. It's changing careers, professions. It's changing so much. How did it all begin? Any memorable moments along the journey of the early days?

Cursor 一开始有点像在寻找问题的解决方案。它很大程度上源于对 AI 在未来 10 年将如何进步的思考。有两个决定性时刻。一个是使用 GitHub Copilot 第一个测试版时非常兴奋。实际上，那是我们第一次使用一个真正非常有用、而不是空谈或演示的 AI 产品。除了是我们用过的第一个有用的 AI 产品之外，Copilot 也是我们采用过的最有用的开发工具之一，甚至可以说没有之一。这让我们非常兴奋。另一个让我们兴奋的时刻是来自 OpenAI 和其他地方的一系列 Scaling（规模扩张）论文，它们表明即使我们没有新想法，AI 也会通过拉动简单的杠杆（比如扩大模型规模、扩大输入模型的数据规模）而变得越来越好。所以在 2021 年底、2022 年初，这让我们兴奋地看到 AI 产品现在成为可能。这项技术将在未来成熟。而且当我们环顾四周时，感觉有很多人在谈论构建模型，但感觉人们并没有真正选择一个知识工作领域，去思考随着 AI 越来越好，这个领域会变成什么样。这让我们走上了一条构思练习的道路。就像，随着这项技术越来越成熟，这些知识工作领域中的每一个将如何变化？工作的最终状态会是什么样子？我们用来做这些工作的工具将如何变化？模型需要如何变得更好以支持工作的变化？一旦 Scaling（规模扩张）和预训练用完了，我们如何继续推进技术能力？而一开始的失误肯定是我们做了这个宏大的练习，然后我们决定研究一个我们认为相对没有竞争、沉闷无聊的知识工作领域，没人会关注它，因为我们想，哦，编程很棒，编程因为 AI 完全可以互换，但人们已经在做这个了。所以一开始有大约四个月的时间，我们实际上在研究一个非常不同的想法，即帮助自动化和增强机械工程，为机械工程师构建工具。从一开始就有问题，因为我和我的联合创始人不是机械工程师。我们有朋友是机械工程师，但我们对该领域非常不熟悉。所以从一开始就有盲人摸象的问题。关于如何真正利用现有的模型并让它们对机械工程有用，存在一些问题。我们的总结是，你需要从一开始就开发自己的模型，而我们这样做的方式很棘手，而且互联网上没有太多关于不同工具和零件的 3D 模型以及构建这些 3D 模型所采取的步骤的数据。而且从拥有这些数据的来源获取它们也是一个棘手的过程。但最终发生的是我们清醒过来了。我们意识到我们对机械工程并不特别兴奋。这不是我们想奉献一生的事业。我们环顾四周，在编程领域，感觉尽管过了一段时间，但变化不大。而且感觉在这个领域工作的人可能与我们脱节，感觉他们对未来一切将走向何方以及所有软件创作将如何通过这些模型爆发没有足够的雄心。这就是让我们走上构建 Cursor 之路的原因。

Cursor kind of started as a solution in search of a problem. And it very much came from reflecting on how AI was going to get better over the course of the next 10 years. And there were two defining moments. One was being really excited by using the first beta version of GitHub Copilot. Actually, this was the first time we had used an AI product that was really, really useful, and wasn't just vaporware or a demo thing. In addition to being the first AI product that we used that was useful, Copilot was also one of the most useful, if not the most useful, dev tools we'd ever adopted. And that got us really excited. Another moment that got us really excited was the series of scaling papers coming out of OpenAI and other places that showed that even if we had no new ideas, AI was going to get better and better just by pulling on simple levers like scaling up the models and also scaling up the data that was going into the models. So at the end of 2021, beginning of 2022, this got us excited about how AI products were now possible. This technology was going to mature into the future. And it felt like when we looked around, there were lots of people talking about making models, but it felt like people weren't really picking an area of knowledge work and thinking about what it was going to look like as AI got better and better. And that set us on the path to an idea generation exercise. It was like, how are each of these areas of knowledge work going to change in the future as this tech gets more mature? What is the end state of the work going to look like? How are the tools that we use to do that work going to change? How are the models going to need to get better to support changes in the work? And once scaling and pre-training ran out, how are we going to keep pushing forward technological capabilities? And the misstep at the beginning for sure is we actually did this whole grand exercise, and we decided to work on an area of knowledge work that we thought would be relatively uncompetitive and sleepy and boring, and no one would be looking at it, because we thought, oh, coding's great, coding is totally interchangeable because of AI, but people are already doing that. So there was a period of four months to begin with where we were actually working on a very different idea, which was helping to automate and augment mechanical engineering, and building tools for mechanical engineers. There were problems from the get-go in that me and my co-founders, we weren't mechanical engineers. We had friends who were mechanical engineers, but we were very much unfamiliar with the field. So there's a little bit of a blind man and the elephant problem from the get-go. There were problems around how you would actually take the models that exist today and make them useful for mechanical engineering. The way we net it out is you need to actually develop your own models from the get-go, and the way we did that was tricky, and there's not a lot of data on the internet of 3D models of different tools and parts and the steps that it took to build up to those 3D models. And getting them from the sources that have them is also a tricky process too. But eventually what happened was we came to our senses. We realized we're not super excited about mechanical engineering. It's not the thing we want to dedicate our lives to. And we looked around, and in the area of programming, it felt like despite a decent amount of time ensuing, not much had changed. And it felt like the people that were working on the space maybe had a disconnect with us, and it felt like they weren't being sufficiently ambitious about where everything was going to go in the future and how all of software creation was going to blow through these models. And that's what set us off on the path to building Cursor.

好的，真有趣。首先，我喜欢这个建议，你经常听到“去追求无聊的行业”，因为那里没人，有机会，而且有时确实有效。但我喜欢这段旅程，它实际上是说，不，去追求最热门、最受欢迎的领域，AI 编码应用开发，而且它成功了。而且你刚才的表述是，你没有看到足够的雄心，可能你认为还有更多事情要做。所以感觉这是一个有趣的教训：即使某件事看起来，好吧，太晚了，已经有 GitHub Copilot 和其他产品了，如果你注意到它们没有达到应有的雄心，或者没有你那么有雄心，或者你几乎看到他们方法中的缺陷，那么仍然有巨大的机会。你同意吗？

Okay, so interesting. So first of all, I love that this is advice that you often hear of go after boring industry because no one's going to be there and there's opportunity, and sometimes it works. But I love that this journey, it's like no, actually go after the hottest, most popular space, AI coding app building, and it worked out. And the way you phrased it just now is you didn't see enough ambition, potentially that you thought there was more to be done. So it feels like that's an interesting lesson: even if something looks like, okay, it's too late, there's GitHub Copilot out there, there are other products, if you notice that they're just not as ambitious as they could be, or as you are, or you see almost a flaw in their approach, that there's still a big opportunity. Does that resonate?

我完全同意。我认为部分原因是你需要有可以实现的飞跃。你需要有你能做的事情。我认为 AI 令人兴奋的地方在很多地方，而且我认为在我们的领域仍然如此，你可以谈谈我们如何看待这一点以及如何处理。但我认为天花板真的很高。而且，如果你环顾四周，即使你拿这些领域中最好的工具，未来几年也应该有更多事情要做。所以，那个领域有如此高的天花板，我认为在软件领域是独一无二的，至少在与 AI 相关的高度上是如此。

That totally resonates. And I think part of it is you need there to be leaps that can happen. And you need there to be things that you can do. And I think the exciting thing about AI is in a bunch of places, and I think this is very much still true of our space, and you can talk about how we think about that and how we deal with that. But I think that just the ceiling is really high. And yes, if you look around, probably even if you take the best tool in any of these fields, there should be a lot more that needs to be done over the next few years. And so that space having that high ceiling, I think, is unique amongst areas of software, at least the degree to which it is high with AI.

让我们回到 IDE 的问题。所以你们本可以走几条不同的路线，其他公司也在走不同的路线。所以有一种是构建一个供工程师在其中工作的 IDE，并在其中添加 AI 魔法。

Let's come back to the IDE question. So there's kind of a few routes you could have taken, and other companies are doing different routes. So there's building an IDE for engineers to work within and adding AI magic to it.

还有另一条路，就是做一个完整的 AI 智能体式开发产品，或者只是一个非常擅长编程的模型，专注于打造最好的编程模型。是什么让你决定并认为 IDE 这条路是最好的选择？

There's another route of just a full AI agentic devon sort of product and then there's just like a model that is very good at coding and focusing on building the best possible coding model. What made you decide and see that the ID path was the best route?

从一开始就只做模型的人，是在做端到端的自动化编程。我觉得他们试图构建的东西和我们非常不同——我们关心的是让人类对最终工具中的所有决策保持控制。而那些人更多是在设想一个未来，整个事情都由 AI 完成，也许所有决策也由 AI 来做。所以第一，有个人的兴趣成分；第二，我觉得我们一直努力对当前技术所处的位置保持强烈的现实主义态度。我们对 AI 在未来几十年里如何成熟感到非常非常兴奋。但有时候，人们会本能地看到 AI 在一个领域做出神奇的事情，然后把这些模型拟人化，认为它在某方面比聪明人强，所以在其他方面也一定比聪明人强。但这些模型有巨大的问题。而且从一开始，我们的产品开发过程就是真正的“吃自己的狗粮”，每天高强度地使用这个工具，我们从来不想发布任何对我们自己没用的东西。我们有这个优势，因为我们就是自己产品的终端用户。我觉得这让你对当前技术的真实状态保持清醒。所以这确实让我们认为，人类必须坐在驾驶座上。AI 不能做所有事情。我们也出于个人原因，对赋予人类这种控制权感兴趣。所以这让你既不是单纯的模型公司，也不是那种没有人类控制的端到端方案。然后，你选择通过 IDE 而不是现有编码环境的插件，是因为你相信编程会通过这些模型流动，编程行为本身在未来几年会发生巨大变化，而现有编码环境的可扩展性非常有限。所以如果你认为 UI 会发生很大变化，如果你认为编程的形态会发生很大变化，你就必须对整个应用拥有控制权。

The folks who were from the get-go working on just a model were working on end-to-end automation programming. I think they were trying to build something very different from us, which is we care about giving humans control over all the decisions in the end tool that they're building. And I think those folks were very much thinking of a future where the whole thing is done by AI and maybe the AI is making all the decisions too. So one, there was kind of a personal interest component. Two, I think we always try to be intense realists about where the technology is today. Very, very excited about how AI is going to mature over the course of many decades. But sometimes people have an instinct to see AI do magical things in one area and then anthropomorphize these models and think, it's better than a smart person here, so it must be better than a smart person there. But these things have massive issues. And from the very start, our product development process was really about dogfooding and using the tool intensely every day, and we never wanted to ship anything that wasn't useful to us. We had the benefit of doing that because we were the end users of our product. And I think that instills a realism in you around where the tech is right now. So that definitely made us think that we need the humans to be in the driver's seat. The AI cannot do everything. We're also interested in giving humans that control for personal reasons. So that gets you away from just being a model company, and also away from this end-to-end stuff without the human having control. And then the way you get through an IDE versus maybe a plugin to an existing coding environment is the belief that programming is going to flow through these models and the act of programming is going to change a lot over the next few years, and that the extensibility that existing coding environments have is so limited. So if you think the UI is going to change a lot, if you think the form factor of programming is going to change a lot, you necessarily need to have control over the entire application.

我知道你们今天有一个 IDE，这可能是你们的偏见，认为这也许是未来的方向，但我只是好奇，你觉得未来很大一部分会不会是 AI 工程师坐在 Slack 里，直接帮你做事？这会不会有一天融入 Cursor？

I know that you guys today have an IDE and that's probably the bias you have that this is maybe where the future is heading, but I'm just curious, do you think a big part of the future is also going to be AI engineers that are just sitting in Slack and just doing things for you? Is that something that fits into Cursor one day?

我觉得你会希望能在所有这些形式之间相当轻松地切换。有时候你会希望让某个东西自己独立运行一段时间，然后你希望能把 AI 的工作拉进来，然后非常快速地与之协作，对吧？然后也许再让它独立运行。所以这些后台与前台的形式，我认为你希望它们都能在一个地方很好地工作。而后台的东西对某类编程任务特别有用，这类任务很容易精确指定你想要什么，不需要太多描述，也很容易指定正确性是什么样的，通常 bug 修复就是一个很好的例子，但绝对不是所有编程都这样。所以我觉得 IDE 的定义会随着时间彻底改变，而我们拥有自己的编辑器的做法，就是基于它必须随着时间演进的假设。我认为这既包括从不同的界面（比如 Slack 或你的问题追踪器）发起任务，也包括你盯着的那块玻璃面板会发生很大变化。我们基本上就是把 IDE 看作你构建软件的地方。

I think you'll want the ability to move between all of these things fairly effortlessly. Sometimes you'll want the thing to go spin off on its own for a while, and then you'll want the ability to pull in the AI's work and then work with it very quickly, right? And then maybe have it go spin off again. So these background versus foreground form factors, I think you want that all to work well in one place. And the background stuff is especially useful for a segment of programming tasks where it's very easy to specify exactly what you want without much description, and exactly what correctness looks like without much description. Often bug fixes are a great example of that, but it's definitely not all of programming. So I think that what the IDE is will totally change over time, and our approach to having our own editor was premised on it having to evolve over time. I think that will both include spinning off things from different surface areas like Slack or your issue tracker, and also the pane of glass that you're staring at is going to change a lot. We just mostly think of an IDE as the place where you are building software.

我觉得人们在谈论智能体和这些 AI 工程师会为你做事时，很少提到的一点是，我们基本上都变成了工程经理，手下有很多不太聪明的下属，你得做大量的审查、批准和明确指示。我想听听你的看法，有没有什么办法能让这变得容易些？因为这听起来真的很难。就像任何带过大团队的人都会说：“天哪，这些初级员工老是来找我，反复做低质量的工作。”简直就像：“这日子没法过了。太痛苦了。”是啊，也许最终还要开那么多的一对一会议。

I think something people don't talk enough about when talking about agents and all these AI engineers are going to be doing stuff for you is basically we're all becoming engineering managers with a lot of reports that are just not that smart, and you have to do a lot of reviewing and approving and specifying. I guess thoughts on that and is there anything you could do to make that easier? Because that sounds really hard. Like anyone that has a large team, has had a large team being like, "Oh my god, all these junior people just checking in with me doing not high quality work over and over." It's just like, "What a life. It's going to suck." Yeah. Maybe eventually one-on-ones with so many one-on-ones.

是的。所以我们看到的在 AI 上最成功的客户，我认为，他们使用这些东西的方式仍然相当保守。所以我觉得今天最成功的客户确实很依赖像我们的“下一步编辑预测”这样的功能，就是你正常编码，然后预测你接下来要做的动作。他们也很依赖把要交给机器人的任务范围缩小。在你花在审查代码上的固定比例时间里，你可以从智能体或整体 AI 那里得到两种模式。一种是你花很多时间预先明确需求，AI 去工作，然后你去审查 AI 的工作，然后完成，这就是整个任务。或者你可以把任务切得很碎，你可以明确一点，AI 写一点，审查，再明确一点，AI 再写一点，再审查。这基本上就是自动补全在整个频谱上的体现。而且我们仍然看到，最成功的使用这些工具的人，现在都在把任务切碎，保持相当小的粒度。这听起来没那么糟糕。我很高兴这里有解决方案。

Yeah. So the customers we've seen have most success with AI, I think, are still fairly conservative about some of the ways they use this stuff. So I do think today that the most successful customers really lean on things like our next edit prediction, where you're coding as normal and predicting the next actions you're going to do. And then they also really lean on scoping down the stuff that you're going to hand off to the bot. And for a fixed percent of your time spent reviewing code, you could from an agent or from AI overall, there's kind of two patterns. One is you could spend a bunch of time specifying things up front, the AI goes and works, and then you go and review the AI's work, and then you're done, that's the whole task. Or you could really chop things up, so you can specify a little bit, AI writes something, review, specify a little bit, AI writes something, review. And that's kind of autocomplete all in the way of that spectrum. And still we see often the most successful people using these tools are chopping things up right now and keeping things fairly small. That sounds less terrible. I'm glad there's a solution here.

我想回到你们最初构建 Cursor 的时候。你们是在哪个节点意识到“这已经准备好了”？有没有一个时刻，你觉得“好了，我觉得是时候把它发布出去看看会怎样了”？

I want to go back to you guys building Cursor for the first time. What was the point where you realized this is ready? What was kind of a moment of like okay I think this is time to put it out there and see what happens.

所以当我们开始构建 Cursor 时，我们相当担心在没有向世界发布的情况下空转太久。所以一开始，实际上 Cursor 的第一个版本是手工打造的。

So when we started building Cursor, we were fairly paranoid about spinning for a while without releasing to the world. And so to begin with, we actually the first version of Cursor was hand-rolled.

我们现在以 VS Code 为基础，就像很多浏览器以 Chromium 为基础一样。最初我们不是这样，而是从零开始构建了 Cursor 的原型，这涉及大量工作。我们必须构建自己的现代代码编辑器，包括支持多种语言、在语言间移动的导航支持、错误跟踪、集成命令行，以及连接远程服务器查看和运行代码的能力。所以我们以极快的速度进行构建，从零开始打造自己的编辑器，同时还有 AI 组件。大约五周后，我们就完全依赖这个编辑器了，并抛弃了之前的编辑器。一旦发现它有用，我们就把它交到其他人手中，经历了很短的测试期，然后在代码第一行写出的几个月内就向世界发布了。我想大概用了三个月，这绝对是“快速把产品交到用户手中，公开构建”的做法。

We now use VS Code as a base, like many browsers use Chromium as a base. Initially, we didn't, and built a prototype of Cursor from scratch, which involved a lot of work. We had to build our own modern code editor, including support for many different languages, navigation support for moving amongst the language, error tracking, an integrated command line, and the ability to connect to remote servers to view and run code. So we went on a blitz of building things incredibly quickly, building our own editor from scratch and also the AI components. After about five weeks, we were living on the editor full-time and had thrown away our previous editor. Once it got to a point where we found it useful, we put it in other people's hands, had a very short beta period, and then launched to the world within a couple of months from the first line of code. I think it was probably three months, and it was definitely a 'let's get this out to people and build in public quickly' approach.

让我们惊讶的是，我们原以为会长期为几百人构建产品，但一开始就涌入了大量兴趣和反馈。这非常有帮助。我们从中学习，这也是我们转而基于 VS Code 而不是无头方案的原因。很多改变是由早期用户反馈驱动的，之后我们一直在公开迭代。

The thing that took us by surprise is we thought we would be building for a couple hundred people for a long time, and from the get-go there was an immediate crush of interest and a lot of feedback. That was super helpful. We learned from that, and that's actually why we switched to being based off of VS Code instead of this headless thing. A lot of that was motivated by initial user feedback, and then we've been iterating in public from there.

我喜欢你轻描淡写地描述你们获得的增长。我觉得你们在一年半内从零做到了 1 亿美元的年经常性收入（ARR），这具有历史意义。你认为成功的关键是什么？三个月就构建出来，太疯狂了。你认为成功的秘诀是什么？

I like how you understated the traction you got. I think you guys went from zero dollars to 100 million ARR in like a year and a half, which is historic. What do you think was the key to this success? You built it in three months, that's insane. What do you think was the secret to your success?

第一个版本，也就是三个月版本，并不太好，所以我认为这是一种持续的偏执，关于这个东西可以变得更好的所有方式。最终目标实际上是发明一种全新的编程形式，涉及自动化我们今天所知的很多编码。无论我们在 Cursor 上处于什么位置，都感觉离最终目标还很远。所以总是有很多事情要做，但很多努力并没有过度集中在最初的推动上，而是工具的持续演进，让它不断变得更好。

The first version, the three-month version, wasn't very good, so I think it's been a sustained paranoia about all the ways this thing could get better. The end goal is really to invent a very new form of programming that involves automating a lot of coding as we know today. No matter where we are with Cursor, it feels like we're very far away from that end goal. So there's always a lot to do, but a lot of it hasn't been over-rotated on the initial push; instead, it's the continued evolution of the tool and making it consistently better.

在那三个月之后，是否有一个转折点，事情开始真正起飞？

Was there an inflection point after those three months where things just started to really take off?

说实话，一开始感觉相当慢，也许是我们有些不耐烦。但有一件事是整体的增长速度，这继续让我们惊讶。我认为最令人惊讶的事情之一是增长相当稳定，是指数级的月环比增长，有时被我们的发布和其他事情加速。但一开始指数增长在数字很低时感觉相当慢，所以一开始并没有感觉像比赛开始。

To be honest, it felt fairly slow to begin with, maybe from some impatience on our part. But one thing is the overall speed of the growth, which continues to take us by surprise. I think one of the most surprising things is that the growth has been fairly consistent, an exponential of consistent month-over-month growth, accelerated at times by our launches and other things. But an exponential to begin with feels fairly slow when the numbers are really low, so it didn't really feel off to the races to begin with.

对我来说，这听起来像是“如果你建造了它，他们就会来”真的奏效了。你们只是构建了一个你们自己作为工程师喜欢的产品。你们发布了它。人们就是喜欢它，并告诉了所有人。

To me, this sounds like 'build it and they will come' actually working. You guys just built an awesome product that you loved yourselves as engineers. You put it out. People just loved it, told everyone about it.

基本上就是我们所有人，团队专注于产品，让产品变得更好，而不是把时间花在其他事情上。我们确实花了很多时间在其他事情上，比如组建团队非常重要，做支持轮岗也非常重要。但一些人们在早期创业时可能追求的正常事情，我们让它们烧了很久，尤其是在销售和营销方面。所以只是专注于产品，构建一个你喜欢、团队喜欢的产品，然后为一些用户调整它，听起来简单，但做好很难。有很多不同的方向可以走，很多不同的产品方向。我认为专注和战略性地选择正确的构建内容以及有效排序优先级很棘手。这个领域的另一个棘手之处在于它是一种新的产品构建形式，非常迭代，我们介于普通软件公司和基础模型公司之间。我们想为数百万人开发产品，这一面必须出色。但产品品质的一个重要维度是在有意义的地方在科学和模型方面做更多。所以做好这一点也很棘手。总的来说要注意的是，有些事情听起来简单，但做好很难，而且有很多粗糙的方式可能会搞砸。

It being essentially all of us, the team working on the product and making the product good, in lieu of other things one could spend one's time on. We definitely spent time on tons of other things, for instance building the team was incredibly important, and doing things like support rotations was very important. But some of the normal things that people maybe reach for in building a company early on, we really let those fires burn for a long time, especially when it came to things like sales and marketing. So just working on the product and building a product that you like, your team likes, and then adjusting it for some set of users can sound simple, but it's hard to do well. There are a bunch of different directions one could have run in, a bunch of different product directions. I think focus and strategically picking the right things to build and prioritizing effectively is tricky. Another thing that's tricky about this domain is it's a new form of product building, where it's very iterative, in that we are something in between a normal software company and a foundation model company. We want to develop a product for millions of people, and that side has to be excellent. But then one important dimension of product quality is doing more and more on the science and the model side in places where it makes sense. So doing that well has been tricky. The overall thing to note is that some of these things sound simple to specify, but doing them well is hard, and there are rough ways you can run.

今天很高兴邀请到 Andrew Luo。Andrew 是 One Schema 的 CEO，也是我们播客的长期赞助商之一。欢迎 Andrew。

I'm excited to have Andrew Luo joining us today. Andrew is CEO of One Schema, one of our longtime podcast sponsors. Welcome, Andrew.

谢谢你邀请我，Lenny。很高兴来到这里。

Thanks for having me, Lenny. Great to be here.

那么，One Schema 有什么新动态？我知道你们和 Ramp、Vanza、Watershed 等我最喜欢的公司合作。我听说你们推出了一款新的数据接入产品，可以自动化团队在导入、映射和集成 CSV 和 Excel 文件上花费的几小时手动工作。

So, what is new with One Schema? I know that you work with some of my favorite companies like Ramp and Vanza and Watershed. I heard you guys launched a new data intake product that automates the hours of manual work that teams spend importing and mapping and integrating CSV and Excel files.

是的。我们刚刚发布了 One Schema 文件源的 2.0 版本。我们用 AI 从头重建了它。我们看到很多客户带着数据工程师团队来找我们，他们苦于清理杂乱电子表格所需的手动工作。

Yes. So, we just launched the 2.0 of One Schema file feeds. We've rebuilt it from the ground up with AI. We saw so many customers coming to us with teams of data engineers that struggled with the manual work required to clean messy spreadsheets.

File feeds 2.0 让非技术团队只需一个简单提示，就能自动化处理 CSV 和 Excel 文件的转换过程。我们支持所有最棘手的文件集成，包括 SFTP、S3，甚至电子邮件。我可以告诉你，如果我的团队必须构建这样的集成，把这件事从我们的路线图中移除，改用像 One Schema 这样的工具，那该多好。当然，Lenny。我们听说过太多因交易、员工文件、采购订单等中的一条坏记录而导致的宕机恐怖故事。调试这些问题往往就像大海捞针。One Schema 能阻止任何坏数据进入你的系统，自动验证你的文件，并生成错误报告，指出所有坏文件中的确切问题。我知道导入不正确的数据会给客户带来各种麻烦，并迅速失去他们的信任。Andrew，非常感谢你加入我们。如果你想了解更多，请访问 oneschema.co。那就是 oneschema.co。

File feeds 2.0 allows nontechnical teams to automate the process of transforming CSV and Excel files with just a simple prompt. We support all of the trickiest file integrations, SFTP, S3, and even email. I can tell you that if my team had to build integrations like this, how nice would it be to take this off our road map and instead use something like one schema? Absolutely, Lenny. We've heard so many horror stories of outages from even just a single bad record in transactions, employee files, purchase orders, you name it. Debugging these issues is often like finding a needle in a haystack. One schema stops any bad data from entering your system and automatically validates your files, generating error reports with the exact issues in all bad files. I know that importing incorrect data can cause all kinds of pain for your customers and quickly lose their trust. Andrew, thank you so much for joining me. If you want to learn more, head on over to oneschema.co. That's oneschema.co.

到目前为止，在构建 Cursor、构建 AI 产品的过程中，你学到的最反直觉的事情是什么？

What is the most counterintuitive thing you've learned so far about building Cursor, building AI products?

我认为对我们来说反直觉的一点，之前也稍微提到过，就是我们一开始绝对没预料到会自己做任何模型开发。如我所说，当我们进入这个领域时，有些公司从一开始就直接专注于从头训练模型。我们计算过训练 GPT-4 所需的成本，就知道那不是我们能做到的事。而且这感觉有点像把注意力放错了地方，因为市面上已经有很多出色的模型。为什么要费劲去复制其他玩家已经做过的事情，尤其是在预训练方面，比如把一个什么都不懂的神经网络教成通晓整个互联网。所以我们以为我们根本不会做那件事，而且从一开始就很清楚，现有模型有很多可以为我们做的事情，但它们没有做，因为没有为它们构建合适的工具。但事实上，我们内部做了大量的模型开发，这也是我们在招聘方面的一个重点，并且组建了一支出色的团队，这对我们的产品质量来说也是一大胜利。到目前为止，Cursor 中的每一个神奇时刻都在某种程度上涉及自定义模型。所以这绝对反直觉，也令人惊讶。这是一个渐进的过程，最初有一个训练我们自己模型的用例，使用任何最大的基础模型都没有意义，那个用例非常成功，然后又转向了另一个效果很好的用例，就这样一直发展下去。做这种模型开发时，一个有用的事情是仔细选择你的切入点，不要试图重新发明轮子，不要试图专注于那些最好的基础模型可能已经非常出色的地方，而是专注于它们的弱点，以及你如何能补充它们。

I think one thing that's been counterintuitive for us, hinted at it a little bit before, is that we definitely didn't expect to be doing any of our own model development when we started. As mentioned, when we got into this, there were companies that were immediately from the get-go focusing on training models from scratch. And we had done the calculation for what it took to train GPT-4 and just knew that that was not going to be something we were going to be able to do. And it also felt a little bit like focusing one's attention in the wrong area, because there are lots of amazing models out there. And why do all this work to replicate what other players had done, especially on the pre-training side of things, you know, taking a neural network that knows nothing and then teaching it the whole internet. So we thought we weren't going to be doing that at all, and it seemed clear to us from the start that the existing models had lots of things they could be doing for us that they weren't doing, because there wasn't the right tool built for them. In fact, though, we do a ton of model development internally, and it's a big focus for us on the hiring front, and have assembled a fantastic team there, and it's also been a big win on the product quality side of things for us. And at this point, every magic moment in Cursor involves a custom model in some way. So that was definitely counterintuitive and surprising. And it's been a gradual thing where there was an initial use case for training our own model where it really didn't make sense to use any of the biggest foundation models, that was incredibly successful, kind of moved to another use case that worked really well, and has been going from there. And one of the helpful things in doing this sort of model development is picking your spots carefully, not trying to reinvent the wheel, not trying to focus on places where maybe the best foundation models are excellent, but instead focusing on their weaknesses and how you can complement them.

我想很多人听到你们有自己的模型会感到惊讶。当人们谈论 Cursor 和这个领域的其他公司时，他们往往会称其为 GPT 包装器，只是坐在 ChatGPT 或 Sonnet 之上。而你说的是你们有自己的模型。谈谈幕后的技术栈吧。

I think this is going to be surprising to a lot of people hearing that you have your own models. When people talk about Cursor and all the folks in the space, they would kind of call them GPT wrappers, just sitting on top of ChatGPT or Sonnet. And what you're saying is that you have your own models. Talk about just like the stack behind the scenes.

当然。所以我们肯定以多种方式使用最大的生成模型。它们是将 Cursor 体验带给人们的重要组件。我们使用自己模型的地方：有时是为了服务于基础模型因成本或速度原因根本无法服务的用例。其中一个例子就是自动补全方面。对于不写代码的人来说，这可能有点难以理解。但代码是一种奇怪的工作形式，有时你接下来 5、10、20、30 分钟的工作完全可以从你肩头看过去就能预测。我会把它和写作对比。写作，每个人或很多人都熟悉 Gmail 的自动补全，以及你在写短信或邮件时出现的各种自动补全形式。它们只能提供有限的帮助，因为通常仅凭你之前写的内容，并不清楚你接下来要写什么。但在代码中，有时当你编辑代码库的一部分时，你需要更改代码库其他部分的内容，而且完全清楚你需要如何更改。所以 Cursor 的一个核心部分就是这种增强版的自动补全体验，你可以预测接下来要在多个文件、一个文件中的多个位置做的事情。要让模型擅长这个用例：第一，有速度要求，这些模型需要非常快，它们需要在 300 毫秒内给出补全。还有成本因素，我们运行着大量模型，每次按键都需要更新对你下一步行动的预测。然后这也是一个非常特殊的用例，你需要模型不仅擅长补全通用文本序列的下一个词，而且擅长自动补全一系列差异，查看代码库中发生了什么变化，然后预测接下来会发生什么变化，包括删除和添加等等。我们在专门针对该任务训练模型方面取得了巨大成功。所以这是一个不涉及基础模型的地方，算是我们自己的东西。我们在应用中没有太多关于这个的标签或品牌宣传，但它支撑着 Cursor 非常核心的部分。然后另一组使用我们模型的地方是帮助 Sonnet、Gemini 或 GPT 这样的模型，这些模型既位于那些大模型的输入端，也位于输出端。在输入端，这些模型在代码库中搜索，试图找出要向大模型展示的代码库部分。你可以把这想象成一个迷你谷歌搜索，专门用于查找代码库中与展示给大模型相关的部分。然后在输出端，我们获取这些模型建议你对代码库进行的更改的草图。

Yeah, of course. So we definitely use the biggest generation models in a bunch of different ways. They're really important components of bringing the Cursor experience to people. The places where we use our own models: sometimes it's to serve a use case that a foundation model wouldn't be able to serve at all for cost or speed reasons. And so one example of that is the autocomplete side of things. And so this can be a little bit tricky for people who don't code to understand. But code is this weird form of work where sometimes really the next 5, 10, 20, 30 minutes of your work is entirely predictable from looking over your shoulder. And I would contrast this with writing. So writing, everyone or lots of people are familiar with Gmail's autocomplete and the different forms of autocomplete that show up when you're trying to get those text messages or emails or things like that. They can only be so helpful because often it's just really not clear what you're going to be writing just by looking at what you've written before. But in code, sometimes when you edit a part of a codebase, you're going to need to change things in other parts of a codebase, and it's entirely clear how you're going to need to change things. And so one core part of Cursor is this really souped-up autocomplete experience where you predict the next set of things you're going to be doing across multiple files, across multiple places within a file. And making models good at that use case: one, there's this speed component, those models need to be really fast, they need to give you a completion within 300 milliseconds. There's also this cost component, we're running tons and tons and tons of models, every keystroke we need to be changing our prediction for what you're going to do next. And then it's also this really specialty use case, you need models that are really good not at completing the next token of just a generic text sequence, but are really good at autocompleting a series of diffs, looking at what's changed within a codebase and then predicting the next sort of things that are going to change, both deleted and added and all of that. And we found a ton of success in training models specifically for that task. So that's a place where no foundation models are involved, it's kind of our own thing. We don't have a lot of labeling or branding about this in the app, but that powers a very core part of Cursor. And then another set of places where our models are used is to help things like Sonnet or Gemini or GPT, and those sit both on the input of those big models and on the output. On the input side of things, those models are searching throughout a codebase trying to figure out the parts of a codebase to show to one of these big models. You can kind of think about this as like a mini Google search that's specifically built for finding the relevant parts of a codebase to show one of these big models. And then on the output side of things, we take the sketches of the changes that these models are suggesting you make with that codebase.

然后，我们有一些模型来填充细节。高层思考由这些最聪明的模型完成，它们会花几个 token 来做这件事。然后，这些更小、更专业、速度极快的模型，结合一些推理路径，将这些高层改动转化为完整的代码。因此，在需要专业任务的地方，这对提升质量非常有帮助；同时，对提升速度也极有帮助，而速度对我们来说也是产品质量的一个重要维度。

And then, you know, we have models that then kind of fill in the details. The high-level thinking is done by these smartest models. They spend a few tokens on doing that. And then these smaller specialty incredibly fast models coupled with some inference tracks then take those high-level changes and turn them actually into full code. And so it's been super helpful for pushing on quality in places where you need a specialty task. And it's been super helpful for pushing on speed, which is such an important dimension of product quality for us too.

这太有意思了。我刚刚在播客里采访了 OpenAI 的 CPO Kevin Wheel，他称之为“模型集成”。他们也是这么做的，利用每个模型的最佳特性，而且正如你所说，使用更便宜的模型还有成本优势。这些其他模型是基于像 Llama 这样的开源模型，你们直接接入并在此基础上构建吗？

This is so interesting. I just had Kevin Wheel on the podcast, CPO of OpenAI, and he calls this the ensemble of models. That's the same way they work. To use the best feature of each one and to your point the cost advantages of using cheaper models. These other models, are they based on like Llama and things like that, just open source models that you guys plug into and build on?

是的。我们尽量在做事上非常务实，不想重复造轮子。所以，我们从现有最好的预训练模型开始，通常是开源的，有时也会与那些不公开权重的大型模型提供商合作。因为我们不太关心逐行读取权重矩阵的能力，我们只关心训练这些模型、进行后训练的能力。所以，大体上，是的，我们使用开源模型，有时也会与闭源提供商合作进行调优。

Yeah. So again, we try to be very pragmatic about the places that we're going to do this work, and we don't want to reinvent the wheel. So starting from the very best pre-trained models that exist out there, often open source ones, sometimes in collaboration with these big model providers that don't share their weights out into the world. Because the thing we care about less is the ability to read line by line the matrix of weights that give you a certain output. We just care about the ability to train these things, to post-train them. So by and large, yes, open source models, sometimes working with the closed source providers too to tune things.

这引出了一个很多 AI 创始人和投资者都会思考的讨论，那就是 AI 领域的护城河和防御性。感觉定制模型是这个领域的一个护城河。考虑到正如你所说，其他公司不断推出新产品，试图抢占你的市场份额，你如何看待这个领域的长期防御性？

This leads to a discussion that a lot of AI founders always think about, and investors, which is moats and defensibility in AI. So it feels like one is custom models is a moat in the space. How do you just think about long-term defensibility in the space, knowing there's other folks as you said launching constantly trying to take your lunch?

我认为确实有办法建立惯性和传统的护城河，但总的来说，我们处于一个我们必须不断努力打造最好产品的领域。这个行业的每个人，我真的认为天花板如此之高，以至于无论你建立什么样的防御，都会被超越。我认为这类似于一些与过去普通软件市场、普通企业市场略有不同的市场。我想到的一个是 1999 年底或 90 年代末 2000 年代初的搜索引擎市场。另一个在很多方面类似这个市场的，是 70 年代、80 年代、90 年代个人电脑和迷你电脑的发展。我认为在每一个这样的市场中，天花板都非常高。切换是可能的。你可以从聪明人额外一小时的时间、额外的研发投入中持续获得价值，持续很长时间。你不会用完有用的东西去构建。然后特别是在搜索领域，而不是电脑领域，拥有分发渠道也有助于改进产品，因为你可以根据用户的数据和反馈来调整算法和学习。我认为所有这些动态在我们的市场中也存在。所以，也许对我们这样的人来说是悲哀的事实，但对世界来说是惊人的事实，是存在许多超越的机会，还有更多有用的东西可以构建。我们距离 5 年或 10 年后能达到的水平还有很长的路要走，我们有责任保持这个引擎运转。

I think that there are ways to build in inertia and traditional moats, but I think by and large we're in a space where it is incumbent on us to continue to try to build the best thing. And everyone in this industry, I truly just think that the ceiling is so high that no matter what entrenchment you build, you'll be leapfrogged. And I think that this resembles markets that are maybe a little bit different from normal software markets, normal enterprise markets of the past. I think one that comes to mind is the market for search engines at the end of 1999 or at the end of the '90s and beginning of the 2000s. I think another market that comes to mind that resembles this market in many ways is the development of the personal computer and mini computers in the 70s, '80s, 90s. And I think that in each of those markets, the ceiling was incredibly high. It was possible to switch. You could keep getting value for the incremental hour of a smart person's time, the incremental R&D dollar for a really long time. You wouldn't run out of useful things to build. And then in search in particular, not in the computer case, having distribution was helpful for making the product better too, in that you could tune the algorithms, you could tune the learning based off of the data and the feedback you're getting from users. And I think that all of those dynamics exist in our market too. So I think that maybe the sad truth for people like us, but then the amazing truth for the world, is that there are many leapfrogs that exist, there's many more useful things to build. We're a long way away from where we can be in 5 or 10 years, and it's kind of incumbent on us to keep that engine going.

所以，我听到的是，这听起来更像是一种消费模式，就是持续做到最好，让人们留在你身边，而不是像 Salesforce 那样创造锁定效应，比如与整个公司签订合同，你必须使用这个产品。

So what I'm hearing is it sounds like a lot more like a consumer sort of mode where it's just be the best thing consistently so that people stick with you, versus creating lock-in and things like that where they're just like Salesforce where it's just contracts with the entire company and you have to use this product.

是的。我认为需要注意的重要一点是，如果你处于一个很快就没有有用的事情可做的领域，那不是一个好局面。但如果你处于一个大量投资和越来越多优秀人才在正确道路上工作能持续带来价值的领域，那么你可以获得研发的规模经济，可以深入朝着正确方向研究技术，并达到一个可防御的位置。但是，是的，我认为这有类似消费品的倾向，我真的认为这关乎打造最好的产品。

Yeah. And I think the important thing to note is, if you're in a space where you kind of run out of useful things to do very quickly, then that's not a great situation to be in. But if you're in a place where big investments and having more and more great people working on the right path can keep giving you value, then you can get these economies of scale of R&D, and you can deeply work on the technology in the right direction and get to a place where that is defensible. But yes, I think there's a consumer-like tendency to it, and I really think it's just about building the best thing possible.

你认为未来这个领域会有一个赢家，还是会有许多这样的产品共存？

Do you think in the future there's one winner in this space, or do you think it's going to be a world of a number of products like this?

我认为市场非常大。这也是一个，你之前问过 IDE 的事情，我认为一些考虑这个领域的人被绊倒的一点是，他们看了过去 10 年的 IDE 市场，然后说，谁在编辑器上赚钱？这是一个超级碎片化的领域，每个人都有自己的东西和自己的配置。有一家公司在商业上确实通过制作出色的编辑器赚钱，但这家公司规模有限。然后结论是未来也会是这样。我认为人们错过的是，在 2010 年代，为程序员构建编辑器能做的事情是有限的。而通过编辑器赚钱的公司做的事情包括让代码库导航变得容易，进行一些错误检查和类型检查，以及拥有良好的调试工具，这些都非常有用。但我认为，你可以为程序员构建的东西，为许多不同领域的知识工作者构建的东西，是非常广泛和深入的。我认为我们所有人面临的问题实际上是自动化大量的忙碌工作和知识工作，真正改变我们面前所有知识工作领域，使其更有能力、更高效。

I think the market is just so very big. And this is also one thing that, you know, you asked about the IDE thing early on, and one thing that I think tripped up some people that were thinking about the space is like they looked at the IDE market of the past 10 years and they said, who's making money off of the editors? It's this super fragmented space where everyone kind of has their own thing with their own configuration. And there's one company that commercially actually makes money off of making great editors, but that company is only so big. And then the conclusion was it was going to look like that in the future. And I think that the thing that people missed was that there was only so much you could do building an editor in the 2010s for coders. And the company that made money off of editors was doing things like making it easy to navigate around a codebase, doing some error checking and type checking, and having good debugging tools, which were all very useful. But I think that the set of things you can build for programmers, the set of things you can build for knowledge workers in many different areas, just goes very far and very deep. And I think that really the problem in front of all of us is the automation of a lot of busy work and knowledge work, and really changing all the areas of knowledge work in front of us to be much more able and more productive.

所以，我绕了这么大一圈，其实是想说，我认为我们所在的这个市场真的非常非常大。我觉得它比人们过去意识到的、比以往为开发者构建工具的市场都要大得多。而且我认为会出现很多不同的解决方案。我觉得会有一家公司——至于是不是我们，还有待确定——但我确实认为会有一家公司打造出那个能构建全球几乎所有软件的通用工具，那将是一个非常、非常具有代际规模的巨大业务。但我认为也会有一些细分领域可以占据，比如为某个特定市场细分或软件开发生命周期的某个特定环节做点事情。但通用的编程方式会从仅仅编写正式编程语言，转向某种更高层次的抽象。而这个应用就是你购买并用来实现这一点的工具。我认为那里通常只会有一个赢家，而且那会是一个非常大的业务。

So that was all a long-winded way to say I think the market's really, really big that we're in. I think it's much bigger than people have realized, than building tools for developers in the past. And I think that there will be a bunch of different solutions. I think that there will be one company, and it's to be determined if it's going to be us, but I do think that there will be one company that builds the general tool that builds almost all the world's software, and that will be a very, very generationally big business. But I think that there will be niches you can occupy, doing something for a particular segment of the market or for a very particular part of the software development life cycle. But the general programming shifts from just writing formal programming languages to something way higher level. This is the application you purchase and use to do that. I think that there will be generally one winner there, and it will be a very big business.

有意思。顺着这个思路，有趣的是微软其实一开始就处于这个领域的中心，拥有出色的产品和出色的分发渠道。你之前说过，Copilot 是让你跨过那道坎、让你觉得“哇，这里可能真的有大机会”的东西。但现在感觉他们并没有在赢，反而像是在落后。你怎么看？你觉得那里发生了什么？

Juicy. Along those lines, it's interesting that Microsoft was actually right at the center of this first, with an amazing product, amazing distribution. Copilot, you said, was like the thing that got you over the hump of like, wow, there could be something really big here. And it doesn't feel like they're winning. Feels like they're falling behind. What do you think? What do you think happened there?

我认为有一些具体的历史原因，导致 Copilot 可能没有达到、或者说到目前为止还没有达到某些人对它的期望。然后我认为还有一些结构性原因。结构性原因是——需要说明的是，微软在 Copilot 这个案例上显然是我们工作的巨大灵感来源。总的来说，我认为他们做了很多很棒的事情，我们也是很多微软产品的用户。但我认为这是一个对现有巨头不太友好的市场。一个对现有巨头友好的市场，可能是那种可做的事情有限、很快就被商品化、你可以把它和其他产品捆绑销售，而且不同产品之间的投资回报率很小的市场。在这种情况下，也许购买创新解决方案就不太合理，直接买那个捆绑在其他产品里的东西更合理。另一个可能对现有巨头特别有利的市场，是那种从一开始你就把所有东西放在一个地方，切换起来极其痛苦的市场。但无论好坏，在我们的情况下，你可以试用不同的工具，你可以决定你认为哪个产品更好。所以这对现有巨头不太友好，而对那些你认为会推出最具创新性产品的人更有利。至于具体的历史原因，据我所知，最初开发 Copilot 的那批人大多已经去其他地方做别的事情了。我觉得要协调所有可能参与制作这类产品的不同部门和各方，一直有点困难。

I think that there are specific historical reasons why Copilot might not have lived up, or so far, to the expectations that some people had for it. And then I think that there are structural reasons. I think the structural reason is, and to be clear, Microsoft in the Copilot case is obviously a big inspiration for our work. And in general, I think they do lots of awesome things, and we're users of many Microsoft products. But I think that this is a market that's not super friendly to incumbents. A market that's friendly to incumbents might be one where there's only so much to do, it kind of gets commoditized fairly quickly, and you can bundle that in with other products, and where the ROI between different products is quite small. In that case, perhaps it doesn't make sense to buy the innovative solution; it makes sense to just buy that thing bundled in with other stuff. Another market that might be particularly helpful for incumbents is one where, from the get-go, you have your stuff in one place and it's really, really excruciatingly hard to switch. And for better or worse, in our case, you can try out different tools. You can decide which product you think is better. So that's not super friendly to incumbents, and that's more friendly to whoever you think is going to have the most innovative product. And then the specific historical reasons, as I understand them, are that the group of people that worked on the first version of Copilot have by and large gone on to do other things at other places. I think it's been a little hard to coordinate among all the different departments and parties that might be involved in making something like this.

我想回到 Cursor 的话题。我喜欢问每个构建这类工具的人一个问题：如果你能坐在每个第一次使用 Cursor 的新用户旁边，在他们耳边悄悄说几句建议，让他们用 Cursor 更成功，那会是一两条什么建议？

I want to come back to Cursor. A question I like to ask everyone that's building a tool like this: if you could sit next to every new user that uses Cursor for the first time and just whisper a couple tips in their ear to be more successful, most successful with Cursor, what would be like one or two tips?

我认为目前，我们希望在产品层面解决这个问题，但很多用 Cursor 成功的经验在于对模型能做什么有一种感觉，包括它们能处理的任务复杂度，以及你需要向模型指定多少细节。但要对模型的质量、它的差距在哪里、它能做什么和不能做什么有一种感觉。目前我们在产品中并没有很好地教育用户这些，或者给用户一些“泳道”和指导方针。所以为了培养这种品味，我会给两条建议。一是，如前所述，我会更倾向于不要试图让模型一次性完成一个大任务，告诉它你确切想要什么，然后看输出，要么失望要么全盘接受。相反，我会把事情拆分成小块。你总体上可以花同样多的时间来指定事情，但拆得更碎。所以你是指定一点，得到一点工作成果，再指定一点，再得到一点工作成果，而不是像“让我们写一个巨大的东西，告诉它所有细节”那样。我认为现在这样做有点像是灾难的配方。所以要倾向于拆分事情。同时，在副项目上做这件事可能更合理，而不是在你的专业工作上。我会鼓励人们，尤其是那些习惯了现有软件开发工作流程的开发者，明确地尝试“摔跟头”，通过在一个安全的环境里（比如副项目）大胆尝试，去发现这些模型的极限，并尝试充分利用 AI。因为有时候，或者说很多时候，我们会遇到那些还没有给 AI 一个公平机会的人，他们低估了它的能力。所以总体上倾向于拆分事情、让事情更小，但为了发现你能做什么的极限，明确地在一个安全的环境里“孤注一掷”，去感受一下。你可能会在模型没有崩溃的某些地方感到惊讶。

I think right now, and we'd want to fix this at a product level, a lot of being successful with Cursor is having a taste for what the models can do, both what complexity of a task they can handle and how much you need to specify things to that model. But having a taste for the quality of the model, where its gaps exist, what it can do and what it can't. And right now we don't do a good job in the product of educating people around that, or maybe giving people some swim lanes, giving people some guidelines. So to develop that taste, I would give two tips. One is, as mentioned before, I would bias less toward trying to have the model, in one go, tell it exactly what you want it to do, then seeing the output and either being disappointed or accepting the entire thing for an entire big task. Instead, I would chop things up into bits. You can spend basically the same amount of time specifying things overall, but chopped up more. So you're specifying a little bit, getting a little bit of work, specifying a little bit, getting a little bit of work, and not doing as much of the 'let's write a giant thing telling it exactly what to do.' I think that will be a bit of a recipe for disaster right now. And biasing toward chopping things up. At the same time, it might make sense to do this on a side project and not on your professional work. I would encourage people, especially developers who are used to existing workflows for building software, to explicitly try to fall on their face and try to discover the limits of what these models can do by being ambitious in a safe environment, like perhaps a side project, and trying to use AI to the fullest. Because sometimes, or a lot of the time, we run into people who haven't given the AI a fair shake yet and are underestimating its abilities. So generally biasing towards chopping things up and making things smaller, but to discover the limits of what you can do, explicitly try to go for broke in a safe environment and get a taste for it. You might be surprised in some of the places where the model doesn't break.

我基本上听到的是，你要建立一种对模型能做什么、它能把一个想法带到多远的直觉，而不是仅仅引导它。而且我打赌，每次有新模型发布时，你都需要重新建立这种直觉，比如当它升级到 4.0 时，你得重新来一遍。大体上对吗？

What I'm essentially hearing is kind of build a gut feeling of what the model can do and how far it can take an idea versus just kind of guiding it along. And I bet that you need to rebuild this gut every time there's a new model launch, like when it's on it, I don't know, 4.0, I know comes out, you have to kind of do this again. Is that generally right?

是的。不过在过去几年里，这种变化没有人们第一次接触这些大模型时那么大。但这也是我们希望为用户解决得更好的问题，减轻他们的负担。但确实，这些模型各有各的小怪癖和不同的“性格”。

Yes. It's not, for the past few years it hasn't been as big as the first experience people have had with some of these big models. But yeah, this is also a problem we would hope to solve much better just for users and take the burn off of them. But yeah, each of these things have slightly different quirks and different personalities.

顺着这个思路，人们一直在争论的一个问题是：像 Cursor 这样的工具，对初级工程师更有帮助，还是对高级工程师更有帮助？它们能让高级工程师的效率提升 10 倍吗？它们能让初级工程师变得更像高级工程师吗？你觉得目前谁从 Cursor 中受益最大？

Kind of along these lines, something that people are always debating: tools like Cursor, are they more helpful to junior engineers or are they more helpful to senior engineers? Do they make senior engineers 10x better? Do they make junior engineers more like senior engineers? Where do you think most of who do you think it benefits most today from Cursor?

我认为总体而言，这两类人都能从中受益匪浅。相对排名有点难说。我要说的是，他们各自会陷入不同的反模式。所以，我们看到初级工程师有点过于全面地依赖 AI 处理一切，而我们还没有达到可以在专业工具上端到端这样做的地步，你知道，在长代码库中与几十上百人协作。然后是高级工程师——对很多人来说，并非所有人都这样——而且我们实际上经常看到，这些工具被采用的方式之一是公司内部的开发者体验团队，通常由非常资深的人组成，因为这些人往往是构建工具以提高组织内其他工程师生产力的人。我们见过一些非常突破边界的例子，比如我们看到有些人站在真正尽可能采用这项技术的最前线。但总的来说，平均而言，作为一个群体，高级工程师低估了 AI 能为他们做什么，并坚持他们现有的工作流程。所以相对排名有点难说。我认为他们都会陷入不同的反模式，但总的来说，他们都从这些工具中获得了巨大的好处。

I think across the board, both of these cohorts benefit in big ways. It's a little hard to say on the relative ranking. I will say they fall into different anti-patterns. So I would say the junior engineers we see going a little too wholesale relying on AI for everything, and we're not yet in a place where you can kind of do that end to end on a professional tool, you know, working with tens or hundreds of other people within a long codebase. And then the senior engineers—for many folks, it's not true for all—and we actually often, you know, one of the ways these tools are adopted is there's developer experience teams within companies, often staffed by incredibly senior people, because often those are people who are building tools to make the rest of the engineers within an organization more productive. And we've seen some very, very boundary-pushing, like we've seen people who are on the front lines of really trying to adopt the technology as much as possible there. But by and large, I would say on average as a group, the senior engineers underrate what AI can do for them and stick to their existing workflows. So the relative ranking is a little hard. I think they both fall into different anti-patterns, but they both by and large get big benefits from these tools.

这完全说得通。我喜欢这种光谱的两端：期望过高，期望不足。就像金发姑娘与三只熊。是这个比喻吗？

That makes absolute sense. I love that it's like two ends of the spectrum: expect too much, don't expect enough. And it's like the three bears. Is that the allegory?

是的。是的。好吧。这个——是的。也许是那种高级但还不是主管级别的，你知道，正好在中间。有意思。

Yeah. Yeah. Okay. The—yeah. Maybe the sort of senior but not staff, you know, right right in the middle. Interesting.

好的。还有几个问题。你希望在你进入这个角色之前知道什么？如果你能回到 Cursor 刚起步时的 Michael 那里，也就是不久之前，给他一些建议，你会告诉他什么？

Okay. Just a couple more questions. What's something that you wish you knew before you got into this role? If you could go back to Michael at the beginning of Cursor, which was not that long ago, and you could give him some advice, what's something that you would tell him?

难就难在，感觉很多来之不易的知识都是隐性的，有点难以用语言表达。而生活中一个可悲的事实是，在某些人类努力的领域，你确实需要摔跟头才能学到正确的东西，或者你需要身边有一个在该领域表现出色的榜样。我们在招聘方面就感受到了这一点。我认为我们实际上在招聘方面非常耐心。对我们来说，无论是出于个人原因还是公司战略，拥有一支世界级的工程师和研究人员团队来和我们一起开发 Cursor 都非常重要。还要找到那些兼具求知欲和实验精神的人，因为我们需要构建很多新东西，同时还要有知识上的诚实，也许还有一点微观悲观主义和直率，因为在所有噪音中，尤其是随着公司和业务的增长，保持冷静的头脑我认为也极其重要。但让合适的人进入公司，除了构建产品之外，可能是我们最操心的事情。我们实际上因此等了很长时间才扩大团队。我认为很多人听到的都是招聘太快，我觉得我们一开始其实招得太慢了。我认为这本可以补救，我们本可以做得更好。我们最终采用的招聘方法对我们来说效果很好，这并不新奇——比如去追求我们认为真正世界级的人，并在某些情况下花数年时间招募他们。最终对我们有效，但我认为我们一开始并不擅长。所以我认为在两个方面都有来之不易的教训：一是谁是正确的画像——比如谁真正适合团队，伟大是什么样子——二是如何与某人谈论这个机会，如果他们对什么都不感兴趣，如何让他们兴奋起来。关于如何做好这一点，有很多学习，我们花了一些时间。

The tough thing with this is it feels like so much of the hard-won knowledge is tacit and a bit hard to communicate verbally. And the sad fact of life feels like, for some areas of human endeavor, you kind of do need to fall on your face to learn the correct thing, or you need to be kind of around someone who is a great example of excellence in the thing. And one area where we have felt this is hiring. I think that we actually tried to be incredibly patient on the hiring front. It was really important to us that, both for personal reasons and also for the company strategy, having a world-class group of engineers and researchers to work on Cursor with us was going to be incredibly important. Also getting people who fit a sort of mix of intellectual curiosity and experimentation, because there's gonna be so many new things we need to build, and then also kind of an intellectual honesty and maybe micro-pessimism, bluntness, because with all the noise, especially as the company's grown and the business has grown, keeping a level head, I think, is incredibly important too. But getting the right group of people into the company was the thing that, maybe more than anything else apart from building the product, we really fussed over. And we actually waited a long time to grow the team because of that. And I think that many people you hear hired too fast. I think we actually hired too slow to begin with. I think it could have been remedied. I think we could have been better at it. And the method of recruiting that we ended up eventually falling into worked really well for us, which isn't that novel—like going after people that we think are really world-class and recruiting them over the course of, in some cases, many years. Ended up working for us in the end, but I don't think we were very good at it to begin with. And so I think that there were hard-won lessons around both who was the right profile—like who actually makes sense on the team, like what did greatness look like—and then how to talk with someone about the opportunity and get them excited if they really weren't looking for anything. There were lots of kind of learnings there about how to do that well, and that took us a bit of time.

对于那些正在招聘的人，有哪些经验教训？你错过了什么，或者学到了什么？

What are some of those learnings for folks that are hiring right now? What's something you missed or learned?

我认为，首先，我们可能有点过于偏向寻找符合名校、非常年轻、在那些名校环境中做过高资历事情的原型的人。实际上，我认为我们早期很幸运地找到了很多很棒的人，他们愿意和我们一起做这件事，但他们是职业生涯后期的人。所以，是的，我认为我们一开始可能花了一些时间在有点错误的画像上。部分原因是资历问题，部分原因是兴趣和经验问题。我们雇过一些非常非常优秀且非常年轻的人，但在某些情况下，他们看起来可能和标准模板有点不同。另一个教训是，我们极大地改进了我们的面试流程。所以现在我们有一套手工制作的面试问题，然后我们面试的核心实际上是让候选人现场待两天，和我们一起做一个项目，一个工作测试项目。这效果很好，但我们在不断改进。然后，是的，我认为如何了解人们感兴趣的东西，展现我们最好的一面，让他们知道这个机会，即使他们真的没有在找工作，并进行这些对话。随着时间的推移，我们在这方面肯定变得更好了。

I think, to start with, we maybe biased a little bit too much towards looking for people who fit the archetype of well-known school, very young, had done the things that were high credential in those well-known school environments. And actually, I think we were lucky early on to find a lot of fantastic people who were willing to do this with us, who were later-careered. And so, yeah, I think we kind of spent a bunch of time on maybe a little bit of the wrong profile to begin with. And part of that was a seniority thing. Part of that was kind of an interest and experience thing too. We have hired people who are excellent, excellent, excellent, and very young, but they maybe look, in some cases, slightly different from being straight out of central casting. Another lesson is just that we very much evolved our interview loop. And so now we have like a hand-rolled set of interview questions, and then core to how we interview too is actually we have people on site for two days and do a project with us, a work test project. And that has worked really well, but increasingly refining that. And then, yeah, I think how to learn about what people are interested in and put our best foot forward and letting them know about the opportunity when they're really not looking for anything and have those conversations. There's definitely been, gotten better at that over time.

你有没有喜欢问的面试问题？

Do you have a favorite interview question you like to ask?

我认为这个两天的工作测试，我们原以为只能适用于少数人，却出人意料地有持久力。它的好处在于，它让一个人在一个真实项目上端到端地工作。这不是我们会使用的工作。

I think this two-day work test, which we thought would not scale past a few people, has had surprising staying power. And the great thing about it is it lets someone go end to end on a real project. It's not work that we use.

这有点像候选项目清单。但它能让你在两天内看到真实的工作成果。而且对团队来说，时间投入不必非常大。你可以把原本用于半天或一天现场面试的时间，分散到这两天里，给候选人大量时间去做他们的项目。这样实际上有助于规模化。而且它真的能帮你强化“你想不想和这个人共事”这种测试，因为你确实和这个人相处两天，一起吃很多顿饭。所以这一项我们没想到会保留下来，但它对我们的价值评估流程真的非常重要。而且它对于让人兴奋也很重要，尤其是在公司非常早期的时候，因为那时人们还没在使用产品、不了解产品，产品相对还不太好，你唯一能拿得出手的就是一支团队，有些人觉得这支团队很特别，想加入。这两天能让我们有机会让这个人见见我们，在某些情况下，希望能说服他们愿意和我们一起干。所以是的，这一项是出乎意料的，不完全是面试问题，但算是一种形成性的面试。

It's kind of a candidate list of projects. But it gives you two days of seeing like a real work product. And it doesn't have to be incredibly time intensive on the team's front. You know, you can take the time you would spend in like a half day or one day onsite and spread it out over those two days and give someone a lot of time to work on their project. And so that can actually help it scale. And then it really helps you enforce the 'do you want to be around this person' type test, because you are around this person for two days, you know, bunch of meals with them. And so that one we didn't expect to stick around, but it has been really, really important to our value process. And also important to getting people excited, especially at the very early stages of the company, because before people are using the product and know about it, when the product is comparatively not very good, really the only thing you have going for you is a team of people that some people find special and want to be around. And the two days would give us a chance to have this person meet us and in some cases hopefully get convinced that they want to throw in with us. So yeah, that one was unexpected, not exactly an interview question, but kind of a formative interview.

终极面试问题。所以为了非常明确你描述的内容，就是给他们一个任务，比如在我们的实际代码库中构建这个功能，与团队一起编码并交付。大致是这样吗？

The ultimate interview question. So just to be very clear about what you're describing, it's you give them an assignment like build this feature in our actual codebase, work with the team to code it and ship it. Is that roughly right?

是的。不是说我们不用知识产权，也不是端到端交付，但确实像模拟，通常在我们的代码库里。这是一个真实的两天迷你项目，你要端到端完成，基本靠自己。也有协作。而且我们是一家非常注重现场办公的公司，所以几乎在所有情况下，是的，实际上就是和我们一起坐在办公室里。

Yes. Not like we don't use the IP, not shipped end to end, but yeah, it's like a mock, very often in our codebase. Here's a real mini two-day project, you're going to do it end to end, largely being left alone. There's collaboration too. And then we're a pretty in-person company, so in almost all cases, yeah, it's actually just sitting in office with us too.

你一直说这已经扩展到今天。你们现在有多少人？

And you've been saying that this has scaled to even today's. How big are you guys at this point?

我们快 60 人了，就规模和影响力而言，算是小的。

So we are going on 60 people, so small for the scale and impact.

我原以为会大得多。是的。而且我猜最大比例是工程师。

I was thinking it'd be a lot larger than that. Yeah. And I imagine the largest percentage is engineers.

是的。最重要的是，要说明的是，我们未来工作的一大部分是建立一支更大、更出色的团队，能持续改进产品和客户服务。所以你们不打算长期保持这么小。我们不希望这样。但人数少的部分原因是公司内部工程、研究和设计占比非常高。所以很多软件公司，当有大约 40 名工程师时，总人数会超过 100，因为有很多运营工作，而且通常从一开始就非常销售驱动，那非常劳动密集。而我们是从极其精简、产品驱动起步的。我们现在服务很多市场客户，也扩展了，但还有很多要做。

Yeah. The thing that's more than anything, and to be clear, a big part of the work ahead of us is building a group of people that is bigger and awesome and can continue to make the product better and the service we give to customers better. And so you don't plan to stay that small for longer. We wouldn't hope so. But part of the reason that number is small is the percentage of engineering and research and design is very high within the company. And so many software companies, when they have roughly 40 engineers, would be over 100 people because there's lots of operational work and often they're very sales-led from the get-go, and that's just quite labor intensive. And we started from a place of being incredibly lean and product-led. And we now serve lots of market customers and have built out, but there's much more to do there.

我想问你一个问题。AI 领域发生了太多事情。每天都有新东西发布，有很多通讯，很多通讯的全部功能就是每天告诉你 AI 领域发生了什么。经营一家处于这个领域白热化中心的公司，你如何保持专注，如何帮助团队保持专注、埋头苦干、持续构建，而不被这些光鲜亮丽的东西分心？

A question I wanted to ask you. There's so much happening in AI. There's things launching every day, there's newsletters like many newsletters whose entire function is to tell you what is happening in AI every single day. Running a company that's at the center, kind of the white-hot center of the space. How do you stay focused and how do you help your team stay focused and heads down and just build and not get distracted by all these shiny things?

我觉得招聘是很大一部分。如果你招到态度正确的人，而且所有这些都应该被问到，我觉得我们在这方面做得不错。我想我们可能还能做得更好。而且这是我们公司应该更多讨论的事情。但我认为，招聘有正确性格的人，那些不太关注外部认可、更专注于打造真正伟大的东西、更专注于做高质量工作的人，以及那些通常比较冷静、情绪波动不大的人。我认为招聘能帮你解决很多问题。我觉得这实际上是整个公司的一个学习点，就是对于你引入公司的任何组织工具，你希望从那个工具得到的结果，你可以通过招聘具有你希望从那个组织事物中产生的正确行为的人，走得很远。我想到的具体例子是，我们能够在工程方面避免大量流程。我觉得我们需要多一点流程，但就我们的规模而言，不需要太多流程，因为我们招聘了我觉得非常优秀的人。一是招聘冷静的人。二是多谈论这件事。三是希望能以身作则。就我们个人而言，从 2021 年、2022 年开始，我们一直专业从事这项工作，从事 AI 工作，我们见证了各种技术和思想的来来去去的巨变。如果你把自己带回 2021 年底、2022 年初，那是 GPT-3，instruct 还不存在，没有 DALL-E，没有 stable diffusion。然后我们经历了所有这些图像技术的存在和崛起，还有 GPT-4，所有这些新模型，所有这些不同的模态，所有视频相关的东西。而其中只有很少一部分真正影响业务。所以我觉得我们建立了一点免疫系统，知道什么时候一个事件真的会对我们很重要。而且这种动态，就是有很多很多噪音，但可能只有少数几件事真正重要，我认为在过去十年中，AI 领域也反映了这一点，学术界有太多关于深度学习的论文，太多关于 AI 的论文。

I think hiring is a big part of it. If you get people with the right attitude, and all of this should be asked, and I think we're doing well there. I think we'd probably be doing better there too. And it's something that we should probably talk even more about as a company. But I think hiring people with the right disposition, people who are less focused on external validation, more focused on building something really great, more focused on doing really high quality work, and people who are just generally kind of level-headed, maybe the highs aren't very high and the lows aren't very low. I think hiring can get you through a lot here. I think that's actually a learning throughout the company, that for any organizational tool you're introducing into a company, the result you're looking to get from that tool, you can go pretty far on hiring people with the right behaviors that you want to result from that organizational thing. And the specific example that comes to mind is we've been able to get away with not a ton of process yet on the engineering front. I think we need a little bit more process, but for our size, not a ton of process, by hiring people who I think are really excellent. One is hiring people who are level-headed. I think two is just talking about it a lot. I think three is hopefully leading by example. And for us personally, since 2021, 2022, we've been professionally working on this and working on AI, and we've just seen a sea change of the coming and goings of various technologies and ideas. If you transport yourself back to end of 2021, beginning of 2022, this is GPT-3, instruct doesn't exist, there's no DALL-E, there's no stable diffusion. And then we've gone through all of those image technologies existing, and that rise, and GPT-4, all of these new models, all these different modalities, all the video stuff. And only a very small number of these things really affect the business. So I think we've kind of just built up a little bit of an immune system and kind of know when an event comes around that actually is really going to matter for us. And this dynamic too, of there being lots and lots of chatter but then maybe only a few things that really matter, I think has been mirrored in AI over the last decade, where there have been so many papers on deep learning in academia, so many papers on AI in academia.

最后一个问题。你认为人们对 AI 在构建领域的发展方向以及世界将如何改变，仍然最误解或没有完全理解的是什么？

Last question. What do you think people still most misunderstand or maybe don't fully grasp about where things are heading with AI in building and the way the world will change?

人们仍然有点过于纠结于两个极端：要么认为一切都会很快发生，要么认为这一切都是吹嘘和炒作，完全是骗人的。但我觉得我们正处于一场技术变革之中，这场变革将产生极其深远的影响。我认为它的影响将超过互联网，超过自计算机问世以来我们见过的任何技术变革。而且我认为这需要时间，会是一个持续数十年的过程。我认为会有很多不同的群体在推动这一进程中发挥重要作用。要知道，要走向一个计算机能为我们做越来越多事情的世界，有各种独立的问题需要解决，需要在这些问题上取得进展。其中一些属于科学层面：让这些模型理解不同类型的数据，变得更快、更便宜、更智能，符合我们关心的模态，在现实世界中采取行动。还有一些则关乎我们如何与之协作，以及人类在计算机上应该看到和控制的体验是什么，如何与这些东西协同工作。但我认为这需要几十年时间，而且会有大量令人惊叹的工作要做。

People are still a little bit occupied too much on either end of a spectrum of, you know, it's all going to happen very fast and, you know, this is all bluster and hype and super snake oil. And, you know, I think we're in the middle of a technology shift that's going to be incredibly consequential. I think it's going to be more consequential than the internet. I think it's going to be more consequential than any shift in tech that we've seen since the advent of computers. And I think it's going to take a while. I think it's going to be a multi-decade thing. And I think many different groups will be consequential in pushing it forward. And, you know, to get to a world where computers can increasingly do more and more and more for us, there's all of these independent problems that need to be knocked down and progress needs to be made on them. And some of those are on the science side of things: getting these models to understand different types of data, be faster, cheaper, smarter, conform to the modalities that we care about, take actions in the real world. And then some of it's on like how we're going to work with that and, you know, what's the experience that humans should actually be seeing and controlling on a computer and working with these things. But I think it's going to take decades. I think that there's going to be lots of amazing work to do.

我还认为，有一个群体模式会特别重要，不是自卖自夸，但我觉得就是那种致力于自动化和增强特定知识工作领域的公司：它们既构建底层技术，整合来自供应商的最佳部分，有时也自主研发，同时还构建面向该领域的产品体验。我认为做这类事情的人，我们在软件领域做，其他领域也有人在做，这些人将产生真正深远的影响。不仅对用户看到的最终价值如此，而且随着他们规模化，他们将对推动技术发展非常重要，因为我认为其中最成功的公司将能建立起非常非常大的企业。所以，我很期待看到其他领域出现这样的公司。

I think that also, you know, one of the patterns of a group that I think will be especially important here, not to talk our own book, but I think is like the company that works on automating and augmenting a particular area of knowledge work, builds both the technology under the surface for that, integrating the best parts from providers, sometimes doing it in house, and then also builds the product experience for that. I think people who do that, and we're doing it in software, people do that in other areas, I think those folks will be really, really consequential, not just for the end value that users see, but then I think as they get to scale, they'll be really important for pushing forward the technology, because I think the most successful of them will be able to build very, very big businesses. And, yeah, so excited to see the rise of other companies like that in other areas.

我知道你们正在招聘那些有兴趣的人，比如“嘿，我想来这里工作，做这类事情”。你们现在在找什么样的人才？有没有特别想尽快填补的职位？如果人们感兴趣，他们应该知道什么？

I know you guys are hiring for folks that are interested in, hey, I want to go work here and build this sort of stuff. What kind of roles are you looking for right now? Any roles you're most excited about filling ASAP? What should people know if they're curious?

这个团队需要做的事情太多了，我们目前还没有能力全部覆盖。所以，首先，各个岗位都在招。如果你觉得我们没有适合你的职位，也许你联系我们之后，情况并非如此。也许我们能从你身上学到东西，然后意识到我们需要一些之前没意识到的东西。但总的来说，我认为今年我们要做的两件最重要的事就是拥有最好的产品，然后把它做大。我们现在处于一种抢占市场的模式，世界上几乎每个人要么没用我们这样的工具，要么在用开发速度较慢的工具。所以，扩大 Cursor 的规模是一个大目标。我想说，我们一直在寻找优秀的工程师、设计师、研究员，以及业务方面的各类人才。

There are so many things that this group of people need to do that we are not yet equipped to do. So, kind of generic across the board first of all. And so if you don't think we have a role for something, maybe if you reach out, that won't actually be the case. And maybe we can actually learn from you and decide that we need something that we weren't yet aware of. But, by and large, I think that two of the most important things for us to do this year are have the best product in the case and then grow it. And we're kind of in this land grab mode where almost everyone in the world is either using no tool like ours or they're using one that's maybe developing less quickly. And so growing Cursor is a big goal. And I would say, yeah, especially always on the hunt for folks who are excellent engineers, designers, researchers, but then folks in all across the business side too.

既然你提到了工程师，我忍不住要问这个问题。有个问题就是，代码会写出我们所有的代码，AI 会写出我们所有的代码，但每个人还在疯狂地招工程师。所有基础模型，很多我们都不是在虚张声势。所以，你觉得工程岗位会不会出现一个拐点，开始放缓？我知道这是个很大的问题，但你觉得这些公司对工程师的需求会越来越强，还是说在某个时点会有很多 Cursor 智能体替我们构建？

I can't help but ask this question now that you talk about engineers. There's kind of this question of just like, you know, code's going to write all our code, AI is going to write all our code, but everyone's still hiring engineers like crazy. All the foundational models, so many we're not out there cheating the horn of people looking good. So, yeah. Do you think there's going to be an inflection point of like engineering roles start to kind of slow down? I know this is like a big question, but just, do you see engineers being more and more needed across all these companies or do you think at some point there's all these Cursor agents running building for us?

再说一次，我们的观点是，这中间会有一个漫长而混乱的过渡期，不会一下子跳到那种你只要退后一步，让所有事情都自动完成，然后你就有个工程部门的状态。我们非常希望从现有的编程方式演进。我们希望人类始终处于驾驶位。我们认为即使在最终状态，让人们对一切保持控制也是非常重要的。而且你需要专业人士来做这件事，来决定软件应该是什么样子。所以两者兼有。我认为，是的，工程师绝对是需要的。我认为工程师将能做更多的事情。我认为对软件的需求是非常持久的，这虽然不是最新颖的观点，但想想看，构建那些相当简单、易于指定（或者在外人看来如此）的东西，现在却如此昂贵和劳动密集，这有点疯狂。所以，如果你能把现有的一切（那些因当前成本和需求而合理存在的东西）的成本降低几个数量级，我们就能在计算机上做更多更多的事情，拥有更多更多的工具。我自己就有过这种体会，我早期的一份工作是为一家生物技术公司工作，为他们构建内部工具。现成的工具糟糕透了，完全不符合他们的使用场景。而我当时构建的内部工具，确实有大量的需求。

Again, we kind of have the view that there's this long messy middle of it not jumping to a just like you step back and you ask for all your stuff to be done and you have your engineering department. Very much like you want to evolve from programming as it exists today. We want humans to be in the driver's seat. And we think even in the end state, giving folks control over everything is really important. And you will need professionals to do that and kind of decide what the software looks like. So both. I think that yes, engineers are definitely needed. I think that engineers will be able to do much more. I think the demand for software is very lasting, which is not the most novel thing, but I think it's kind of crazy to think about how expensive and labor intensive it is to build things that are pretty simple and easy to specify, or it would look like that to the outside observer, and just how hard those things are to do right now. And so if you can, all of the stuff that exists right now that's justified by the cost and demand that we have now, if you could bring that down by orders of magnitude, we'd have tons and tons and tons of more stuff that we could do on our computers, tons more tools. And I've felt this where one of my early jobs actually was working for a biotechnology company and building internal tools for them. And the off-the-shelf tools that existed were horrible and did not fit their use case at all. And then the internal tools I was building, there was definitely a ton of demand there for things that could be built.

而且你知道，这远远超出了我在那里期间能构建的东西。但是的，我认为，你知道，在计算机上工作的物理特性是如此之好。你应该能够基本上把所有东西都移动起来，做你想做的一切。但仍然有太多的摩擦。我认为，对软件的需求远远超过我们今天能构建的，你知道，制作像大片电影一样昂贵的简单生产力软件。所以我认为在很远的未来，是的，实际上会有更多的工程师需求。

And you know, that far outstripped just the things that I could build in the time that I was with them. But yes, I think that it's still so, you know, the physics of working on computers are so great. It should be able to basically just move everything around, do everything that you want to do. There's still so much friction. I think that there's much more demand for the software than what we can build today with, you know, things costing like a blockbuster movie to make kind of simple productivity software. And so I think long into the future, yes, there will actually be more demand for engineers.

有没有我们没覆盖到但你想提的？有没有最后一条智慧要留给听众的？你也可以说没有，因为我们已经聊了很多。

Is there anything that we didn't cover that you wanted to mention? Any last nugget of wisdom you wanted to leave listeners with? You could also say no because we've done a lot.

我们思考很多的是如何组建一个团队，既能继续改进现有产品，又能创造新东西。我认为如果我们想成功，ID 必须大幅改变。未来，看起来必须大幅改变。而且，你知道，环顾四周，我们尊敬的公司里，确实有一些公司持续地像青蛙一样跳跃，不断推动前沿，但它们也很罕见。这是一件难事，所以部分在于思考这件事并反思，从第一性原理出发。部分也在于深入研究过去的伟大案例，这也是我们经常思考的。

We think a lot about how you set up a team to be able to make new stuff in addition to like continuing to improve the stuff that you have right now. And I think if we're to be successful, like the ID is going to have to change a ton. What for like looks like it's going to have to change a ton going into the future. And um, you know, if you look around, the companies we respect, there are definitely examples of companies that have continued to really, like, ride the wave of many leap frogs and continue to kind of actually push the frontier, but you know, they're kind of rare too. Like it's a hard thing to do, and so you know, part of that is just kind of thinking about the thing and trying to reflect on it, you know, in our day and you know, the first principles side of things. Part of it is also, you know, trying to get in and study past examples of greatness here, and um, you know, that's something that we think about a lot too.

是的。你刚才说的，我们在开始录音之前，你身后有所有这些书，我当时想那是什么？像是某个老计算机公司的历史，在很多方面有影响力，但我从未听说过。我认为这很能说明你，很多创新来自研究过去、研究历史，以及什么有效什么无效。

Yeah. The what you just told is we were before we started recording you had all these books behind you and I was like what's that over there? It's like the history of some old computer company that was influential in a lot of ways that I've never heard of. And I think that says a lot about you of where a lot of this innovation comes from is studying the past and studying history and what's worked and what hasn't.

好的。如果人们想联系或申请，他们在网上哪里能找到？你说过可能有些他们甚至不知道的职位。他们去哪里找？然后听众如何能帮到你？

Okay. Where can folks find online if they want to reach out and maybe apply? You said that there may be roles they may not even be aware of. Where do they go find that? And then how can listeners be useful to you?

是的。你知道，如果有人对做这些事感兴趣，我们很乐意聊聊，他们可以去 kers.com，既能找到产品，也能找到联系我们的方式。

Yeah. I, you know, if folks are interested in working on this stuff, would love to speak, and they can find, if they go to kers.com, they can kind of both find the product and find out how to reach us.

太简单了。Michael，非常感谢你来做客。这太棒了。太好了。谢谢。大家再见。

So easy. Michael, thank you so much for being here. This was incredible. Wonderful. Thank you. Bye everyone.

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

Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennispodcast.com. See you in the next episode.