我们在公司内部下的很多赌注，针对的并不是三四周后就能见效的东西。我们应该每6到12个月就自我颠覆一次现有产品的状态。每过6到12个月，新产品都应该让现有产品显得可笑，甚至让现有产品的形态显得笨拙。你怎么知道什么时候该招人了？我希望公司几乎像一个脱水的实体。每一次招聘就像加了一点点水，只有当我们再次回到脱水状态时，才会去招人。随着AI的兴起，我们正在构建越来越多的产品，你觉得人们还应该在哪些技能上投入更多？工程师现在能够产出更多技术了。构建技术的ROI实际上上升了。这其实意味着你要招更多人。最好的做法就是亲自去折腾所有这些产品。你可以成为组织的 force multiplier，以他们从未预料到的方式。今天，我的嘉宾是 Verun Mohan。Baroon 是 Windservef 的联合创始人兼CEO，这款产品迅速成为人们最喜爱的AI编程工具之一，基本上是 Cursor 的主要竞争对手，上线4个月用户就超过100万。在这次对话中，Veroon 分享了 Windsurf 的独特之处、为什么他们在公司发展早期就决定大力投入企业销售、为什么 agency 将成为工程师和产品构建者最需要培养的最重要技能。还有他们最初如何作为一家GPU基础设施公司起步，意识到上层栈存在更大的机会，以及两次转型如何让他们走到今天的故事。他还进行了现场演示，给出了用好 Windsurf 的建议，以及更多精彩内容。关于工程师和产品构建者整体的发展方向，这次对话中有太多值得学习的地方，我非常兴奋能把它带给你们。感谢 LinkedIn、Twitter 以及我 newsletter 社区上的每一位朋友，你们提出了很好的问题，让我能和 Verun 深入探讨。如果你喜欢这期播客，别忘了在你最喜欢的播客应用或 YouTube 上订阅和关注。此外，如果你成为我 newsletter 的年付订阅者，你将免费获得一年 Perplexity Pro、Notion Plus、Linear、Granola 和 Superhum 的使用权。请访问 lennisnewsletter.com 了解详情。那么，有请 Verun Mohan。本期节目由 Brex 赞助，Brex 是美国每三家获得风险投资支持的创业公司中就有一家使用的金融技术栈。Brex 知道近40%的创业公司失败是因为现金耗尽。因此，他们打造了一套银行体验，专注于帮助创始人从每一美元中获取更多价值。这与传统银行选项形成鲜明对比——后者让创业公司的现金闲置，同时用各种费用蚕食本金。为了帮助创始人保护现金并延长跑道，Brex 将支票账户、treasury 管理和 FDIC 保险的优势整合进一个强大的账户中。你可以以闪电般的速度在全球范围内收发款项；通过 program banks 获得标准 FDIC 保护额度的20倍；从第一美元起就能赚取行业领先的收益，同时随时都能动用资金。想了解更多，请访问 brex.com/banking-solutions。就是 brex.com/bankingsolutions。本期节目由 Product Board 赞助，这是企业级领先的产品管理平台。十多年来，Product Board 帮助 Zoom、Salesforce 和 Autodesk 等以客户为中心的组织更快地构建正确的产品。作为端到端平台，Product Board 无缝支持产品开发生命周期的所有阶段——从收集客户洞察、规划路线图、对齐利益相关者到赢得客户认同，全部基于单一事实来源。现在，产品负责人还可以通过 Product Board Pulse 更深入地洞察客户需求，这是一套全新的 voice of customer 解决方案。内置智能帮助你分析所有反馈中的趋势，然后通过向AI追问来深入挖掘。看看 Product Board 如何帮助你的团队交付影响力更高的产品，解决真正的客户需求并推进业务目标。获取特别优惠和15天免费试用，请访问 productboard.com/lenny。就是 productboard.comleny。
Verun，非常感谢你来到这里，欢迎收听本期播客。兄弟，谢谢邀请我。我是老听众了。哦，我真的很感激。非常高兴你能来。我感觉你们好像一夜成名了，当然这绝不是一夜之间的成功，但我确实越来越频繁地听到 Windsurf 成为人们最喜爱的AI工具。我觉得大家并不了解 Windsurf 背后的故事，也不了解 Kodium，你创立的那家公司。所以我想也许可以从这里开始，请你简要分享一下 Kodium 的历史，以及 Windsurf 是如何从 Kodium 中诞生的。是的，这家公司其实成立快四年了。你也知道，四年前AI编程还不是什么热门概念。ChatGPT 四年前也还没发布。当时我们一开始其实是在做 GPU 虚拟化和编译器软件。在此之前，我在自动驾驶领域工作。我的联合创始人，我从中学就认识他了，当时在 Meta 做 AR/VR。对我们来说，我们相信 deep learning 会触及很多很多行业，不会只触及自动驾驶这类领域，还会触及金融服务、国防、医疗健康。我们相信这些 deep learning 应用很难构建。所以我们让人们在本身没有 GPU 的计算机上也能有效运行这些复杂应用，而我们会处理所有复杂性，帮你在 GPU 上实际运行这些工作负载，对吧？而且我们把这些工作负载优化了很多。然后到了2022年中，我们有了几百万美元的收入。我们管理着大约一万块 GPU。当时团队只有八个人。我们是自由现金流为正的。但我觉得，一旦这些生成式模型开始变得非常好，我们就觉得我们构建的很多东西没那么有价值了，这对我们公司来说是一个非常非常艰难的时刻。当时我们只有八个人，但我们在想，人们还会继续训练这些非常定制化的情感分类模型吗？这些非常定制的模型？还是他们会直接问 GPTN，这是正面还是负面情感？很可能是后者，对吧？在一个每个人都要运行生成式 AI 模型的世界里，一家基础设施公司凭什么成为差异化因素？因为最终每个人都会运行同样的基础设施。所以相反，我们决定，我们相信生成式 AI 几乎会成为下一个互联网。如果那样的话，我们应该去做的就是构建下一个伟大的应用，就像 Google、Amazon 那样。我们进行了 vertical integrated，把我们的基础设施、推理基础设施拿出来，去构建当时的 Kodium。而且那时候我们是 GitHub Copilot 的早期采用者，我们认为编程领域在接下来的几年里会被极大地颠覆。所以我们拿出了自己的基础设施，大规模运行我们自己的模型。我们甚至训练自己的模型。一开始非常非常基础，纯粹是一个 autocomplete 模型，也就是说当用户打字时，我们会补全接下来的一行、两行、三行或四行代码。但我们在所有开发者使用的 IDE 中完全免费提供这个产品。对吧？包括 VS Code、JetBrains、Eclipse、Visual Studio、Vim、Emacs。我们能免费构建这个产品的原因，正是因为我们的基础设施背景。我们把这些工作负载优化到了极致。大概在那之后很快，一些大型企业也开始寻求与我们合作，于是我们建立了面向企业客户的业务体系，与 Dell、JP Morgan、Chase 这类大公司展开合作。对它们而言，核心诉求不只是代码自动补全或者与代码库对话，而是能否提供一个安全可靠的方案，并且能够根据公司内部的私有数据进行个性化定制。因此，我们基于现有基础设施做了调整，投入了大量精力去深入理解这些大公司的代码库。直到六个月前，我们都在做这件事。这并不意味着我们停止了这项工作，但六个月前我们意识到，当时使用的 IDE 已经开始限制我们了。VS Code 是一款非常流行的 IDE，但它对我们向用户展示的 AI 能力存在上限。正因为如此，我们决定 fork VS Code，打造我们自己的 IDE，加入一些新的 agentic 能力。在过去几年里，模型的能力也在逐年指数级增长。这大概就是我们目前的处境。我省略了很多细节，但这就是我们最终走到的地方。这里面有很多值得展开的线索。其一是 AI 的价值究竟会沉淀在哪一层。你们几乎是从最底层的基础设施和 GPU 做起的，后来又转向去做人们口中所谓的 GPT wrapper——当然不是真的 wrapper——所以我想问问，你们从中有哪些心得，以及你认为在 AI 工具栈中，价值最终会落在哪里。或许我可以先谈谈关于创业公司的一点，我认为这一点非常真切：你最初认定要去做的事情，很大概率并不是正确的方向。作为创始人，这其实很难接受，对吧？你需要有一种非理性的乐观，相信你要做的事具有差异化的重要性，否则你为什么要去做？如果这件事显而易见，那大公司早就做了，对吧？但另一方面，你又必须极度现实，因为大多数非传统的想法通常都不是好主意，对吧？所以你就像走在一根奇怪的钢丝上，一边要推动自己相信的未来，一边又在不断获取新信息，需要不断推翻自己原有的信念。如果从基础设施这层说起，我们最初假设模型架构会非常异构。出于自动驾驶的背景，当时外面有很多种模型架构：CNN、GNN、RNN、LSTM，还有一些更轻量的神经网络和 frustr networks。我们当时可能要面对十种左右的架构。那时我们觉得复杂度如此之高，显然如果有人能把这种复杂性 offload 出去，就会很有价值。快进到 2023 年中，一切看起来都要变成 transformer 了。于是我们的假设就错了。到了这个时候，至少在我们看来，大部分价值不太可能纯粹沉淀在基础设施层了，它会沉淀到别的地方。哪一层才是真正能做出差异化的？我们相信应用层是一个非常非常深的、可以去做出差异化的层面。我们可以用多少种方式去打造更好的用户体验、更好的开发者工作流？我们认为改善开发者生活这件事，几乎是没有上限的。基本上，你提到了第二个我觉得非常有趣的线索，就是你们如何在想法已经奏效、已经在赚钱、用户也很喜欢的情况下进行转型。你说过你们有数百万美元的 ARR 收入，然后却说，不，我们要彻底转型。所以问题是，关于如何判断该追随什么，你们学到了什么？我听到的一点非常有意思：一旦你关于创业根基的假设发生了变化，就该重新思考这个想法，或许尝试别的东西了。你知道，我觉得我们的思考方式是，即使到了现在，我们也接受自己会错很多东西。我们就是会错很多。显然那是一个非常重大的时刻，因为那是一次押上公司的赌注。我们基本上告诉投资人：嘿，我们在这件事上已经在赚钱了。我们已经融了 2800 万美元，然后我们说：嘿，我们要彻底转型。而且我们是一夜之间做的决定，对吧？不是说“也许再等一个季度或两个季度”。因为我们知道，对创业公司来说极其重要的一点就是专注。如果你同时在做一个你认为很有前景的事，却又把注意力放在一件你认为没价值的事上，那你肯定会在那件大事上失败，对吧？这是非常显而易见的道理。但我认为，一旦你接受自己的很多假设可能是错的，你就会尽可能集中地去验证这些假设，而且你不会太迷恋自己的想法。我觉得想法本身，当你有个好想法时是很棒的，但你绝不应该太迷恋它。你要有一个极度 truth-seeking 的组织。公司里很多人的想法都反复被检验过。就连做 Windsor 这件事，虽然不算完全的公司转型，但也是公司层面一个重大决定。你总得做一些赌注，有时错有时对。但如果你拥有一个组织，即使做了错误的决定，士气也不会低落，那就再好不过了，这意味着你始终拥有选择权。Lenny，有一件事我经常和公司里的人说：今年我们的工程总产出，会比公司从成立至今的工程产出还要大得多。所以这几乎意味着每一年对我们来说都是一次新生，对吧？这几乎是一种全新的方式，让我们去验证一套全新的假设。也许我们最初的假设本来就是错的。凭什么我们就比别人更聪明，能更频繁地做对呢？这种想法非常给人力量。这让我想到 Ori Lavine 上过 Co-founder Ways 这档播客，他衬衫上印着一句话，他的书名也是这个：Fall in love with the problem, not the solution。这感觉正是你描述的那样。好的，我们来聊聊 Windsurf。人们要怎样用最简单的方式理解什么是 Windsurf？是的，Windsurf 是一个 IDE，对吧？它是一个用来构建软件、开发应用的程序。说起来挺疯狂的，很多使用这个产品的人可能根本不知道什么是 IDE。这挺不可思议的，我们稍后再展开。但我们为什么要去做 Windsurf，它到底是什么？也许我们本可以就在 Visual Studio Code 这类传统 IDE 之上做这件事。那么，稍微展开讲讲：当我们看到 AI 变得越来越强大时，我们认为人们构建技术的方式，以及对应的交互界面，将会发生显著变化。它不再会是一个传统的纯文本编辑器——用户在里面写几行代码，甚至写大部分代码，而 IDE 只提供一些基础反馈，告诉你哪里做对了、哪里做错了。这类基础反馈可能是「你的软件里有 bug」，或者「编译器报错」。它其实可以做得更多，对吧？AI 实际上可以去修改大块的代码。我们认识到的关键一点是，在这种由 AI 驱动的新范式下，AI 很可能会写远超 90% 的软件。在这种情况下，开发者的角色，以及他们在 IDE 里做的事情，可能就变成了审查代码。也许这和过去的情况已经有所不同了。而且我们很快会在 Windsurf 上看到这一点。当我们使用这款产品时，实际上用户的很大一部分时间都在审查 AI 的输出。所以我们需要在 IDE 中构建自定义的审查流程，让这件事变得更容易完成，因为开发者不再把所有时间都花在写代码上。这就是我们打造这款产品的根本前提。我们觉得，如果 UI 非常基础，我们会受到极大限制。举个简单的例子：我们有一款自动补全产品，可以补全几行代码。现在我们推出了一项叫 Windsurf Tab 的功能，它也会向你展示重构建议，而且这些重构几乎是内联式的。在 Windsurf 中，我们可以为此构建自定义 UI；但在 VS Code 里，由于 API 访问权限的限制，我们不得不在用户光标旁边动态生成图像，因为我们没有合适的接口来妥善展示和编辑。而当我们迁移到 Windsurf 后，接受率立刻翻了三倍——ML 模型完全相同，就是翻了三倍。所以我想，这给了我们信心：没错，你可以说技术非常重要，我也认为技术非常重要；但如果用户从我们构建的技术中获得的价值很少，那你就需要认真想清楚，也许我们确实需要构建一个新的平台和界面——而这正是 Windsurf。所以，为了把这一点说得更清楚，你们下的一个重大赌注是：起初你们在所有人熟悉的现有 IDE 中工作，但后来发现这无法带我们到达需要去的地方。你们打算说服人们转向一个完全新的工具，因为它会好得多。这是你们自己的 IDE。我觉得人们可能没意识到这有多冒险。说服工程师去用一个全新的东西，这可是件大事。是啊，当然。对了，Lenny，我想还有一点值得分享：我们的很多开发者确实用 Visual Studio Code，但也有很多人写 Java、C++ 等语言，他们可能使用 JetBrains 系列的 IDE，比如 IntelliJ。对我们来说，我们其实仍然致力于在这些平台上进行构建。我们只是觉得，作为主流 IDE 之一的 Visual Studio Code，限制了我们能提供给实际用户的界面。
Windsurf 目前的增长情况如何？你总能听到这个领域所有竞争对手的各种惊人数字。所以你能和大家分享些什么，让大家了解一下？可以分享几个数字。我们大约四个月前推出了这款产品，在这期间，超过一百万名开发者尝试过这个产品，显然我们现在有数十万的月活跃用户。我喜欢现在的氛围，好像「哦，一百万，没什么大不了」。如今这些数字太荒谬了，我们已经习惯了这边一亿 AR，那边四个月一百万用户。就好像「哦，当然，这有什么难的？」但这其实很荒谬。现在就是一个疯狂的时代。你提到了一个我本打算稍后问的话题，不过我现在就提出来吧。关于工程在未来会如何变化的问题。你抛出一个数据：未来 90% 的代码将由 AI 编写。Anthropic 的 Dario 最近也说了同样的话。你们对未来的样子有着非常有趣的预见。所以我想问，你认为未来几年编程具体会变成什么样？和今天会有多大不同？我想，当我们思考工程师实际上在做什么时，大概可以分成三类：我要解决什么问题（what）、我应该如何解决它（how），以及实际去解决它（solving it）。我猜，这个领域的每个人可能都越来越确信，「实际去解决」——也就是那种「我知道该怎么做，然后去执行」的部分——AI 将处理绝大部分，甚至全部。事实上，考虑到我们在深入理解代码库方面所做的一些工作，「我应该如何解决」也越来越接近被完成了，对吧？如果你深入理解一个组织内部的环境，如果你深入理解代码库，结合最佳实践，「应该如何解决」这个问题也会被解决。所以我认为，工程最终要回归的，其实是你最初希望工程师去做的事情：即哪些是最重要的业务问题需要我们去解决，我们的应用或产品需要具备哪些最重要的能力，然后真正去排定这些事项的优先级，并做出正确的技术决策去执行。我认为这才是工程可能正在走向的方向。那么，这是否意味着没人需要计算机科学学位了？我觉得这可能有点被夸大了。为什么这么说呢？我的论点是：如今很多开发全栈应用的开发者，至少在几年前，他们可能都上过大学，修过操作系统课程，对吧？理论上，他们并不会真的经常去折腾操作系统内核。但这些原理是否帮助他们理解为什么自己的应用很慢？是否帮助他们理解为什么某些设计决策比其他更好？是的，这让他们比其他工程师优秀得多。我认为这种思想，以及对底层运作原理的理解，会让一个优秀的工程师变得更加出色。但与此同时，它也赋能了一大批从未理解过这些原理的人，让他们知道如何实际构建东西。这是整个过程中出现的另一个非凡结果。我不知道你有没有孩子，但假设你有孩子，或者有侄子侄女要上大学了，你会建议他们学软件、学计算机科学吗？还是你会说，如果现在选择这条路，日子不会好过？我想，也许我可以回想一下。我毕业于 MIT，我们公司工程团队里有很多人也都是 MIT 毕业的。我觉得，当我回想我们在工程或计算机科学领域学到最多的是什么时，其实并不完全是怎么写代码，对吧？也许这几乎是一个既定事实：你上完大学后，多多少少会写代码。更重要的是你思考问题的原则，以及如何拆解问题，对吧？还有如何以有趣的方式解决问题。举个例子，我非常喜欢的一门课是分布式系统。在那门课上，你会阅读文献，理解某些设计决策是如何做出的。我觉得这更像是一门解决问题的课程，对吧？一个专业。它是一个教你如何在给定约束下解决问题的专业，比如当今计算机的运行方式，对吧？比如内存的运行速度，再比如一个周期或一秒内能完成多少计算。基于这些，你可以做一些权衡，然后解决问题。所以，我不知道我是否会说你应该去念计算机科学学位。我认为计算机科学几乎等同于解决问题。如果是这样，我觉得它相当有价值。你学的所有东西都有用吗？我想说，我在计算机科学学位中学到的很多东西都没用。举个例子，我上过一门用 Julia 的并行计算课，我觉得 Julia 现在不是一门很流行的编程语言了。我是否为上了这门课感到遗憾？没有。并行计算的原理在今天仍然非常有用，我会这么说。所以，我听到的重点是，无论你是否学计算机科学，或者某种变体，你仍然需要培养的技能是建立计算机和系统运作的心智模型——并行处理、内存、硬盘、互联网等等。然后还有解决问题的能力，能够解决有趣的问题。随着 AI 越来越多地构建我们的产品，你认为人们还应该更多地投资哪些技能？我觉得有一点可能被低估了，就是这种主观能动性（agency）。我经常思考这个问题：很多人上完大学、上完学，基本上每一步都被明确告知该做什么，他们被给予了非常清晰的路径。我觉得或许在社会和学校中，我们并不重视如何确保培养出真正有能动性、想要做出点东西的人，对吧？他们的目标不只是大学毕业，然后去一家大公司，被精确地告知该做什么，或者该把像素放在网站的哪个位置。我觉得这套技能在当下可能被低估了，大概在过去十年左右都是如此。而且我认为这将会非常重要。你知道，对创业公司来说，显然我们一直在寻找这类技能。我们寻找能动性很强的人，因为我们深知，如果我们不创新、不做些疯狂的事，我们就会死。公司就会倒闭。所以我们只看重这个，对吧？但我要说，对于大多数软件工程岗位，情况可能并非如此，对吧？想想看，某家大公司 X 在普通软件工程面试中招的是什么人。可能看起来并不是这样。我喜欢你这句话的表达方式。如果我们不做疯狂的事、不创新，我们就会死。是的，这期播客节目用这个当标题再好不过了。而且我觉得这是百分之百的事实。现在有太多疯狂的事正在发生，太多创新正在发生。如果你跟不上，你就会死。那么，我们来聊聊招聘。你的招聘方式非常有趣。我有几个问题。一个是，我知道你们尽量保持精简，这是现在所有 AI 创业公司的共同特点。你怎么知道什么时候该招人？我喜欢精简公司的理念，但我并不会把它偶像化到觉得，哇，一家只有 10 人或 20 人规模、营收五千万、一亿或两亿美金的公司是梦想。我觉得这不是我们内部所崇尚的。我认为我们崇尚的是：在满足我们野心的前提下，做规模最小的公司。这才是目标。Lenny，或许我可以这样表达：如果我告诉你，我要造一辆自动驾驶汽车，然后我说“我们团队只有 10 个人”。你完全有理由说：“嘿，Verun，你根本不是认真的。”你说得对。在那一刻，我确实不是认真的。所以，我认为答案应该是：去实现你那雄心勃勃的疯狂项目，最少需要多少人？我认为我们正在做的项目——彻底改变软件构建的方式——我们在公司内部提过，目标是把构建应用和技术的时间缩短 99%。这是一个极其雄心勃勃的目标，长期来看，我们不可能靠 10、20、30、40 人的工程团队就实现这个目标。我们认为天花板非常高。所以这是第一个关键点。就是说，实际上，如果我们能成为一家规模相当大的公司，但仍像创业公司一样运作，那才是梦想，对吧，那才是梦想。至于招聘哲学，我们的思路是：只有当某个职能真的让我们不堪重负时，我们才会为这个岗位招人。比如说，我们要去构建推理技术。除非我们在这个领域已经忙不过来了，否则我们不会招人来干这个，对吧？原因是，我认为这是——这其实是未来，对吧？当你为一个已经有足够人手的岗位招人时，你知道，最终会出现很多奇怪的政治问题。这并不是因为人是坏人，我不觉得大多数人都是恶意的，但当有人加入公司，而实际上你并不需要他们时，他们就会去制造出另一件自己该做的事，对吧？他们会去找别的事来做，而实际上那件事并不重要，但他们会试图说服组织的其他人那很重要。我只是觉得，作为创业公司，我们没有带宽去处理这种事。对我来说，我希望看到每个人都几乎是举手喊：“我要累死了，我们需要再招一个人。”那时候我们才会去招人。我喜欢打的一个比方是，我希望公司就像一个脱水的机体，每一次招聘就像一点点水。我们只有再次回到脱水状态时，才会去招人。我太喜欢这个比喻了。而且听起来很痛苦。你得不堪重负、举手喊“我要死了”、处于脱水状态，这听起来很痛苦。但我也知道这是一种非常令人兴奋的工作方式。听起来很难，但如果你身处其中，就……我想请你谈谈这一面，因为有人可能会觉得：这也太可怕了吧，我不想这样工作。你知道吗，Lenny，我其实觉得这在很多层面上都非常好。首先，我们尊重和信任公司的很多人。所以这迫使大家进行无情的优先级排序。你知道，团队去做一件事时，他们绝不会要求去做不重要的事。事实上，如果手上有两件事要做，他们就会直接告诉我：“我现在有两个任务，但没法同时做两件，只能做一件。”然后他们会挑出最重要的那一件。这其实回到了我认为关于初创公司乃至所有公司都成立的一点：赢家不是靠把十件事做得都还不错，而是把一件事做到极致出色，哪怕另外九件都搞砸了。这是我常跟公司说的。这跟学校很不一样，对吧？在学校，你追求的是总GPA；但在公司，我只需要在最重要的那门课上拿A+，其他课全拿F也没关系。其他课全拿F，并不代表你可以去干违法乱纪的事，它的本质含义是，你要把那些不重要的事情降低优先级。这其实会倒逼整个组织去做优先级排序，效果特别好。Douglas——也就是我的联合创始人——和我可以跟全公司说，这两件事是最重要的。但如果我们出去说这两件事是全公司的重中之重，而公司却养了比实际需要多20%的人，那最终会发生什么呢？想要实现无情的优先级排序，几乎必须靠一种倒逼机制：要么人更少，要么让内部每个人都处于满负荷甚至超负荷的状态。在大公司工作的听众肯定都懂你的意思——人一旦太多，大家就会给自己找活干，就会不断提方案。每个人都想体现影响力，想在绩效评估里拿高分。这就是大公司人浮于事的本质。所以我觉得这些道理都很能引起共鸣。要进一步深挖的话，当一个人忙不过来的时候，具体是什么信号告诉你该招人了？Verun，是不是就是有人来找你说“我们团队需要加人，这根本干不完”？实际操作上具体是什么样的？对，基本就是这样。就是说，有件事必须在短期内完成，压力很大。顺便说一句，关于软件，我们确实相信一点：如果你想做出伟大的东西，就不可能说“我一个月就要搞定”。因为你要这么想，如果一个软件项目两三周就能做完，那说明你做出来的东西在真正的复杂度和差异化上能有多高呢？可能并不高，除非你觉得自己比别人聪明得多。但我觉得那是傲慢，对吧？我们的工程团队确实非常出色，但我也并不认为他们出色到能在三周内做完别人需要六个月到九个月才能完成的事。相信这种事挺愚蠢的。所以归根结底，就是那个人站出来说：“嘿，我没足够时间做X。”然后我们来一场对话：“那你能做什么？”如果答案是“我只能做更少”，那我们也许就会做个决定：“哇，那太好了。也许我们真应该把这件事降低优先级。”为什么？因为这一点其实很难，即使是对我和我联合创始人这样的人也是如此。我们也想做很多事，对吧？总有一种冲动想多做几件事。但如果我们被迫不断做抉择——“我们不能做X”——这反而会让人思路非常清晰。这很清晰，因为我们的工程师面试通过率极低，所以要想快速招人、让人迅速入职，对我们来说也并不容易。所以我觉得这对所有人都很清晰。对那个想要更多人手的人来说也很清晰，我们可以直接告诉他：“嘿，听我说，我们认为你不该再做另外那件事了。”这对我们也很清晰，因为我们可以和他们达成共识，对吧？有时候我们也会达成一致：嘿，我们的团队其实很灵活，这件事我们确实得完成。有一点我们想在工程团队里确保做到：一个人对公司的价值跟他团队的规模毫无关系。公司内部有各种项目，每个项目都有直接负责人。如果我们觉得某个项目非常重要，人员可以从一个项目调到另一个项目。对吧？在公司里不存在“谁管多少人”这种概念。那是非常糟糕、非常棘手的想法。事实上，公司里最有价值的人，是那些能用尽可能少的人手搞定最疯狂项目的人。这才是你内部应该奖励的。
Kodium现在有多少人？我们现在将近160人，工程团队目前50多人。太棒了。那其他比较大的职能团队是哪些？我们有go-to-market团队，还有……对，好，我想聊聊你们在销售方面的经验。好。好，那我们把招聘这个话题收尾。我们聊了什么时候该招人的信号。那你在面试和招聘时，看重候选人什么特质？我们最看重的一点是我们技术门槛非常高。假设候选人确实达到了技术门槛，那我们倾向于寻找对我们真正想解决的问题非常有使命感的人，以及愿意非常努力工作的人。有一件事我们不会去做的，就是跟人说“嘿，看，我们公司很佛系，在这儿工作可舒服了”。我觉得不，这个领域非常激动人心，竞争也极其激烈。如果公司的人不够努力，你就该预料到我们会输。我觉得我听到最大的一个警示信号是，当我问“你愿意付出多大努力”时，有些人最终会说：“嘿，我工作非常聪明。”那我基本上就会反问他们：“如果我们公司里已经有很多既聪明又努力的人了，你的差异化优势在哪？你难道是要拖他们后腿吗？”对吧？因为我觉得公司有一点很像那种大型小组作业。一个人不尽本分，最糟的地方还不是他个人的产出，对吧？等公司发展到几百名工程师的时候，我不会去在意某一个不尽本分的人。但跟他一起共事的团队会基本上这么想：这就是公司的内部标准吗？这就是公司的期望吗？Lenny，我猜如果我跟你说，你有一个五人团队，另外四个同事根本不在乎，那你觉得自己会在乎多少？不会太多。没错。所以对我们来说，我们更在乎的是这个，对吧？我们的文化是非常协作的。这不是个人运动，但大家会觉得可以依靠彼此来完成复杂的任务。所以你刚才问的问题，本质上就是“你愿意多努力？你想多努力？”我知道有些人，有这么一群人，一上来就谈工作与生活平衡，“你怎么敢要求我疯狂加班”。首先我想明确一点：如果你来这里工作，你会非常努力，会工作很长时间。这是一个疯狂的领域，我们会通过聪明地工作以及非常努力地工作来取胜。你之前某个时候提到，你们的工程岗位通过率大概是6%左右，是这样吗？对，那可能是做完 take-home 之后的比例。实际上 take-home 本身大概会再筛掉10到15倍的人。我最近越来越常听到的一个问题是，现在有了 Windsurf 这种能帮你解决所有问题的工具，你们是怎么做面试的？我们并不介意候选人使用这些工具，因为我觉得最糟糕的情况之一，就是有人来了这里却不喜欢用这些工具——我们相信它们能带来巨大的生产力提升。我们确实会把人带到公司现场，这样我们就能看到他们如何在白板上思考问题等等。所以我们确实想看到他们即兴思考的能力，希望他们不会只是把我们说的话放进语音转换器，然后丢进 Tatsubishi 里得出答案。所以，还是有办法面试的。我的观点是，这些工具确实非常重要，但我确实认为我们仍然看重一定的解题能力，对吧？如果你解决难题的唯一方式就是把它丢进 ChatGPT，那我觉得这让我们担忧。本期节目由 KOD 赞助。我每天都会用 KOD 来管理我的播客和社区。我会把计划问每位嘉宾的问题都放在上面，也会把社区资源放在上面。我用它来管理工作流程。KOD 可以这样帮到你：想象一下，你在工作中启动一个项目，愿景清晰。你确切知道谁在做什么，以及在哪里能找到完成自己工作所需的数据。事实上，你不必浪费时间搜索任何东西，因为你的团队所需的一切——从项目追踪器、OKR 到文档和电子表格——都存在于同一个标签页中，都在 KOD 里。借助 KOD 协作一体化工作空间，你能获得文档的灵活性、电子表格的结构、应用的强大功能，以及 AI 的智能，全部都在一个易于整理管理的标签页中。就像我之前提到的，我每天都在使用 KOD。超过五万个团队信任 KOD，让他们更对齐、更专注。如果你是初创团队，希望提升对齐度和敏捷性，KOD 能帮你以创纪录的速度从规划进入执行。亲自试试，请访问 kod.io/lenny，即可免费获得面向初创团队的团队版六个月使用权。是 cooda.io/lenny，免费开始使用，并获得六个月团队版使用期。kod.io/lenny。好，我们来聊聊你们的销售和市场推广经历。显然，你们一开始并没有销售团队——大多数人开始创业时都是这样——但据我所知，你们后来意识到这是一个巨大的疏漏，而且这也是很值得聊的机会，因为我觉得你们拥有一支庞大的销售团队和市场推广团队，这真的很独特。对，实际上我们在公司发展早期就做了这个决定。应该说，我们招聘销售副总裁已经是一年多前的事了，现在市场推广团队已经超过80人。所以这是公司内部一个相当庞大的职能。是啊，这里也许可以讲点背景故事。其实刚创办公司时，我们有几位天使投资人本身就是市场运营方面的操盘手。比如 Carlos Delator，他曾是 MongoDB 的 CRO。对我们来说，我们从未把企业销售或销售本身看作什么负面的事。我觉得这是技术型创始人有时不太喜欢的点——他们认为销售是流程中一个非常负面的环节，一切都应该是产品驱动增长。但我不觉得事情非黑即白。企业销售真的很有价值。不过，也许当我们还是一家 GPU 虚拟化公司、一家基础设施公司时，我们之所以从没招过销售人员，是因为我不知道如何规模化这个职能。当时是我自己在卖产品。所以归根结底，如果连我都没法逐步把产品卖出去，我不知道我们怎么把它变成一个可以复制和规模化扩张的流程，对吧？如果我能做一单，却不知道如何把公司收入从几百万做到几千万、几亿，甚至更不敢想，那我怎么出去招一个人，让他去把它规模化呢？另一方面，对于 Kodium，很快就有不少大型企业主动找上门来，仅仅因为这个，在2023年年中左右，我和公司里其他几个人就开始卖产品了。我们同时和大型企业在跑几十个试点项目，并且很快意识到，这个领域需要建立起一套大型企业销售体系。所以到2023年底，我们正式聘请了销售副总裁，之后很快就组建并扩大了销售团队。是啊，你看，如果你想把东西卖给 Fortune 500，光靠刷信用卡是很难做到的。我们来聊聊 Cursor。我不想在竞争对手身上花太多时间，但大家在想到你们的时候总会想到这个。我觉得你们和这个领域的头部玩家。另外也有 Copilot，但那是另一回事。那么，最简单的方式来理解你们和 Cursor 的区别是什么？以及你们认为长期来看如何在这个领域取胜？我觉得也许可以分享几点。从产品角度，我们在确保对超大型代码库的理解质量非常高这方面投入了很多。这正是因为我们的起点，对吧？我们和一些世界上最大的公司合作，比如 Dell、JP Market Jace，像 Dell 这样的公司拥有单一代码库就超过一亿行代码。所以能够快速理解这些代码库并进行大规模改动，是我们花了大量时间做的事。这要求我们真正构建自己的模型，能够在数千个 GPU 上并行消费代码库的大部分内容，并几乎对它们进行排序，从而找出针对代码库提出的任何问题最重要的代码片段。所以基于我们的基础设施背景，我们出去构建了大型分布式系统来做这件事。这大概是第一点。让我顺着这个思路说下去，因为我觉得人们可能低估了这件事的重要性。我们之前在播客上请过 Bolt 和 Lovable 的创始人。那些产品是从零开始构建东西的，它们帮你写代码。但相比之下，把 Windsurf 加载到你比如在 Airbnb 或 Uber 那种百万行代码库上，让它理解你现有的代码、怎么运作、该去哪里改动而不破坏任何东西，这极其困难。所以我理解到的是，这算是一个很大的差异化优势。你们其实是从那里起步的，然后 Windsurf 现在正在这个优势基础上继续构建。没错。对，这是我们花了大量时间的一件大事，就是理解代码库在做什么，还有另一个点是，用户与代码库之间的所有交互是什么，这个我也很乐意稍后展示给你看。第二个关键点在于，我们其实并不只绑定在 Windsurf 上——这话现在说来可能有点奇怪，毕竟我们正在聊的就是 Windsurf——但事实上，我们非常注重支持像 JetBrains 这样的 IDE。要知道，JetBrains，或者说 IntelliJ，拥有超过 70% 到 80% 的 Java 开发者，他们都在基于 JetBrains 的 IDE 里写代码。我们之所以不觉得有必要去打造一款与 JetBrains 竞争的产品，是因为 JetBrains 本身的可扩展性非常强，而这是 VS Code 所不具备的。VS Code 的可扩展性并不强。所以我觉得，我们的目标不仅仅是满足那一部分能够迁移到我们 IDE 上的用户，而是希望把这种 agentic 的体验带给每一位开发者。如果这意味着我们要服务那些使用 JetBrains 的 Java 开发者，那也完全没问题。我们与很多大型企业合作，这些企业拥有一万多名开发者，其中超过 50% 的人都在用 JetBrains。这是一个非常庞大的产品。顺便提一句，JetBrains 本身是一家私营公司，每年营收高达数亿美元。所以这是一家非常大的公司。因此，这是另一个关键点。我们其实希望顺应开发者现有的工作流，如果他们使用不同的平台，我们也会去适配。第三个关键点，对企业客户来说或许也是一大重点，那就是我们能够在很多非常安全的环境中运作。我们通过了 FedRAMP 合规认证，这意味着我们可以向大型政府实体销售产品。我们还提供一种混合使用模式，也就是说，所有被索引的代码实际上都存放在用户自己的租户环境中。代码是公司最重要的知识产权之一，所以如果你从一家大公司的角度来看，这么多年来我们在打造企业级产品的过程中，已经处理了大量大型企业希望看到的复杂需求，而这也是因为我们从一开始就有着这样的发展历程。好了，Varun，别吊胃口了，我们来现场演示一下 Windsurf，让大家看看它是什么样的。过程中我会不断问你一些问题。那你先共享一下屏幕，把 Windsurf 打开。好的。先介绍一下背景。这是一个非常基础的 React 项目，目前里面什么都没有。如果你打开任何一个文件，就是默认的 React app 项目。我这里有一张简单的图片。你可以给 Windsurf 提供一张图，告诉它你希望项目长什么样——比如我希望这个狗狗版 Airbnb 网站长什么样。漂亮，很漂亮的原型图。顺便说一句，我很喜欢这样，这就够了，你只需要这个，这就够了。基本上我们要做的就是：嘿，Windsurf 很酷的一点在于它可以直接在已有项目上工作，对吧？所以我可以直接说：“嘿，把这个 React app 改成基于这张图片的狗狗版 Airbnb 网站，并生成预览。”
现在它会开始执行代码、读取整个仓库。显然，它一开始并不知道当前代码库的具体情况，它会去分析代码库，找出需要做哪些修改。我们先等一下，看看它会怎么做。不过在这同时，我们继续聊。太棒了。好的。首先，你打开 Windsurf，里面有一个现成的 React 样板项目，Windsurf 之前从没见过这些代码。然后你让它在代码库上做改动，也就是“基于这个设计把它改成狗狗版 Airbnb”。没错，完全正确。好的，很酷。那我们先让它跑着，边跑边聊。我想问你一个问题，这也是我问过所有来做客的嘉宾的——你们都在打造帮助工程师、产品经理和设计师做产品的工具。假设你能坐在每一位新用户旁边，在他们第一次打开 Windsurf 时低声传授几个技巧，帮助他们更好地使用这款产品，你会分享哪几点？第一条建议是要有耐心，既要耐心又要明确，对吧？当你让应用去做一些改动时，它其实可能会做出很多不相关的修改。而避免这种情况的最有效方法，就是尽可能地把你的需求描述得特别明确。还有一件事是我常建议大家的：刚开始先用它做小改动。如果有一个很大的目录，别一上来就让它重构整个目录，对吧？因为万一出错了，它基本上会毁掉 20 个文件。从这一点出发，我觉得长期使用的用户会逐渐了解这款产品的“高峰和低谷”。我喜欢拿自动补全来打比方，对吧？当你用自动补全类产品时，你可能会觉得一个建议只被接受 30% 的功能会很烦人。但它之所以没那么烦人，是因为你已经学会了：嘿，70% 的情况下我不需要接受它，而在那些确实需要接受的时刻，我知道如何从中获取价值。而且你在写一段很复杂的指令之前，心里也会预期：嘿，这么复杂的东西，自动补全大概是搞不定的。所以我觉得这就像是去了解产品的强项和弱项。而疯狂的是，每过三个月，这种强弱分布就会被改变和重新评估。情况几乎会变成：它比过去有了实质性的提升。所以我觉得，耐心和明确性可能是我会告诉用户的两个最重要的关键点。我觉得你话里还有一层意思，就是要培养一种直觉，知道模型到底能做什么——该给多具体的指令，又可以抽象到什么程度。这种直觉是随着时间慢慢建立的。没错，是的。嗯，看起来我们已经有预览了。你猜怎么着？我们有了一个可爱的狗狗页面，一个漂亮的狗狗应用。很酷的一点是，除了修改代码之外，我们还能指向不同的元素。我想我可以指向不同的元素然后说：“嘿，把背景……”这个设计不太好看，但我基本上可以说，如果我选中这个元素，就把背景改成红色，对吧？选中某个特定元素，直接改颜色成红色，它应该就能去执行并完成这个操作。这款产品能够在构建过程中实时预览应用，这意味着你现在可以完全活在应用的世界里，对吧？你甚至可能根本不用去看代码。诚然，这看起来很丑，但某种程度上，如果我想的话，我完全可以就这么做，对吧？这就是没有设计师之后会发生的事。是啊，当没有设计师的时候……也许答案就是，当你问我人们应该做什么时，他们应该培养出色的品味，拥有好品味，因为我觉得品味也是非常难的。不过 Lenny，另一个我想在这里展示的关键点是，显然你可以继续深入，我可以选中不同的组件并进行修改。你知道，我们还有很多规划，不仅仅是这种点击就能改组件的功能。不过其中一个很酷的功能是，AI 这边还有一个 AI 审查流程，对吧？这有点像我一直说的，AI 的目标现在已经发生了很大变化，它现在会为你修改大段代码。而开发者现在的工作，其实是去审查 AI 生成的代码。当然，现在在这期播客录制期间，我不会去审查所有正在生成的代码。但假设我想去修改其中一些代码，对吧？这时候，如果你是一位真正想动手修改的开发者，比如我不喜欢我的变量名叫 title，我想把它改成 title string，对吧？像这样。如果我想去做这个改动，去把它改成 title string，对吧？这就是我要做的。我只需要告诉 AI 继续。而 Windsurf 很酷的地方在于，它不仅知道 agent 做了什么，还知道用户做的一切。我们的目标是实现一种近乎流式的状态：用户做的一切，AI 也都知道。它能够预测意图。如你所见，它说：“我注意到 interface 属性 title 被改成了 title string。”然后它就自动去修改了应用里所有从 title 到 title string 的地方。现在就不再提示那个了。所以，即使我在写软件，想做些针对性修改，AI 也能快速代我完成这些改动。想象一下做重构或迁移，你只改了代码的一部分，就可以让 AI 继续完成剩下的，对吧？因为它深度理解代码库，它应该会去找出所有对应的地方去做修改。显然，现在当我重新加载应用时，应用里没有任何 bug，对吧？它仍然正常加载。我显然还可以让它做更酷的事，比如把应用改成复古风格，对吧？嗯，我也不知道具体是什么意思，但我想我可以这么做，它就会相应地为我做出改变。不过是的，这大概就是高层次的要点：AI 不仅能完全在应用空间里操作，还能在用户的代码空间里修改代码，并在两者之间架起桥梁。所以，它不仅为那些纯粹在构建应用的非开发者提供了杠杆，也为那些一直在敲键盘的开发者提供了助力。太棒了。顺便说一句，如果你不在 YouTube 上看，你可能看不到：你可以直接选中页面上的任何元素，然后在你的需求描述里引用它，说明你想改什么。我之前不知道还有这个功能，这太酷了。有趣的是，我刚看过 Lovable、Bolt、Replit 这类应用，它基本上做了所有这些应用能做的事。哦，哇，这就是复古版本啊。不错，我喜欢它在你的红色基础上做得更好了，真的。其实红色现在看起来好多了。对，还有那个小绿按钮。这太棒了。好的，我觉得大家没意识到 Windsurf 这类应用其实可以为你做很多 agentic 的工作，你只需要告诉它“这里，我要你做这个”，而不是它只是在为你自动补全代码。最大的区别在于，你需要先用某个代码库来启动它。你有一个这种 React 样板项目。你们为什么没有做到那一步，直接自动为你生成呢？是因为你们面向的是工程师，他们不需要这个，还是有其他原因？
Lenny，有趣的是，你看到的这个基础应用其实也是 Windsurf 生成的。我们之所以没当场生成，是因为安装所有依赖要花三四分钟，演示时我不想等。但完全可以说，实际上产品的大多数用户都会从零到一搭建这些应用。如果我说件有意思的事：Windsurf 发布时，我们实际上要求公司里的每个人都去用 Windsurf 搭建一个应用，包括我们的 go-to-market 团队和销售团队。有个疯狂的数据，我觉得大家会很惊讶——我们节省了超过 50 万美元原本打算购买的 SaaS 产品费用，因为我们的 go-to-market 团队现在自己搭建应用，而不是去购买。比如我们的合作负责人，他没有去买合作伙伴门户产品，而是自己搭了一个合作伙伴门户，对吧？要知道他以前从没搭建过软件。而且我们在公司内部已经找到了能轻松、安全地部署这些应用的方法。我们现在实际上在为公司的更高效运营搭建非常定制化的软件，这在大概六个月前是我完全没想到的。这太有意思了。你不需要说出具体公司名字，但我想问，你最不看好的领域是什么？你觉得哪个领域会因为公司内部人员自己搭建这类产品而遇到最大的问题？你知道，我认为那些非常垂直化、非常细分的利基产品会受到巨大冲击。我觉得销售类产品就是其中一个例子，对吧？你——也许我不想说得太负面，但在我们这样的公司里，很难指派最顶尖的工程师去搭建一流的销售产品。大家没兴趣去做这个，也没兴趣去搭建一流的法律软件或财务软件。这对我们来说非常难，对吧？实际上，这曾经是那些公司的巨大护城河——它们之所以能搭建这些产品，是因为它们能提出坚定的立场，知道该怎么做，还能雇到足够好的工程师去搭建软件，而我们公司不愿意这么做。所以以前我们会出去买技术，对吧？因为没有替代方案。但现在，疯狂的事情之一是，领域专家现在有机会搭建他们最终想要的工具了，对吧？这其实很疯狂。你想想，为什么这些软件公司，这些垂直软件公司，能够存在？原因是它们有大而全的功能，对很多公司都适用，但每个公司其实只需要其中 10% 的功能。问题在于，每个公司以前都没有能力维护一套软件，或者为了 10% 的功能去搭建一套定制软件。但现在情况完全变了。现在它们可以了。而且一直以来都有这种说法：如果我能直接买，为什么还要花时间自己搭建软件？但现在只需要五分钟，对吧？只要五分钟，而且可能更贴合你的系统，对吧？就像你多少次买了某个软件，然后心里嘀咕：为什么没有和 X 的集成？我明明就在用 X 啊。多烦人啊？这实际上让软件对你的价值降低了。所以，我觉得很酷的是，如果你回过头看，如果有人倒回到你开始演示的那一刻，那基本上就是一个产品经理在跟工程师对话：“嘿，给我搭一个狗狗版 Airbnb。这是我做的愚蠢原型，就是几个框。”那几乎就像一个不太行的产品经理在跟工程师说话，但它居然真的能用。这就是这件事的疯狂之处。所以你分享的这个 go-to-market 人员自己搭建东西的例子，他们其实不需要懂任何产品搭建的知识。你只需要用某种天马行空的方式描述需求，再画几个框示意你想要的效果，它就能做出东西来——这说明 agency（主观能动性）才是关键。如果你有一位产品经理有个想法，那这个想法完全有可能被打磨得更完善，对吧？很多时候你会遇到那种不断冒出想法的产品经理，但给人的感觉是他们对如何执行毫无头绪。他们只是为了说而说；但那些既有想法又有 agency 的人，可以不需要任何外部资源就出去把自己想做的验证出来。我觉得对于正在听这期内容的产品从业者来说，更切身的体会是：销售跑来找你说“嘿，我想要这个功能，能帮我的销售团队”，而你心里想的是“我没空做一大堆东西，我没时间理这个”——于是这个问题就消失了，我觉得这会让很多产品负责人非常高兴。底层用的是 Sonnet 对吧？我来拆解一下它最终是如何工作的：我们有一个负责规划的模型，我得说目前 Sonnet 是一个非常非常好的规划模型，OpenAI 的 GPT-4o 也很不错。但我们的做法是，尽量让基于 Anthropic 的模型或者说 Sonnet 去完成尽可能多的 high-level planning。然后我们在内部运行所有必要的模型，为 agent 提供高质量的 retrieval。正如你看到的，agent 需要理解代码库（codebase）的其余部分到底是做什么的。我们实际上会运行模型来把整个 codebase 切分并理解它。显然，如果我们有一个一亿行代码的 codebase，把整个代码库发给 Anthropic 可不是什么好主意。首先，你根本做不到。那可是超过 15 亿个 token 的代码，对吧？所以这显然比目前最大的 context length 还要大出三四个数量级。而且从成本和 latency 的角度考虑，你也不会想这么做。这是第一点。你看到的第二点是，模型也能非常快速地对软件进行修改。我们构建了自定义模型，这些模型在主流开源模型之上做了 post-train，能够以极快的速度对 codebase 进行修改。之所以要这么做，一是因为速度更快，二是因为那个模型实际上能在 context 中容纳更多的 codebase 内容，因此它在应用修改方面甚至比 Anthropic 的模型还要强。所以我觉得我们的思考方式是：我们唯一的目标是如何做出最好的产品，对吧？如何做出最好的产品，以及如何尽可能把天花板抬高。只要需要，我们就会去构建模型、训练模型。但如果我们在某个任务上做不到最好，而且我们认为开源模型更好，或者 Anthropic 更好，那我们就会直接去用开源模型或 Anthropic。那你们自己构建的模型是基于大家发布的开源模型来做的吗？是的。有意思的是，负责 retrieval 的那个模型实际上完全是我们内部 pre-train 的。不过，对于很多不同的模块，它都是基于开源模型的。有意思的是，负责编辑和 autocomplete 的那个模型也是我们内部做的。就是在你打字的时候，我们实际上会做一些 autocomplete 相关的事情。我很乐意演示一下，不过我觉得很多用户已经熟悉这个功能了。所以我觉得我们的思路是：我们在什么方面能做到最好，我们就会去投入训练。但如果我们做不到最好，不应该为了面子就去训练某个东西。这可能会有点太技术化了，但你们在训练数据方面有什么有意思的吗？有的。我们从用户那里获得的一个有趣之处——这也是我们试图思考的：为什么我们能做到更好？实际上我们每小时能从用户那里获得数千万条反馈。关于他们喜欢什么、不喜欢什么，我们得到了大量反馈。对于 autocomplete 这类功能，我们获得了大量的 preference data。这些 preference data 很特别，它看起来不像你在互联网上找到的数据。它更像是用户正在打字时产生的数据，对吧？想象你正在 codebase 里敲代码，你敲出来的代码肯定是不完整的，对吧？它不会是完整形态，不像 GitHub 上的代码那样。但我们有大量这样的数据。所以我们处在一个非常独特的有利位置，能够构建一个优秀的模型，即使在代码不完整的状态下也能完成补全；而外部的那些 frontier models，它们接触到的这种形态的代码非常少。所以在这种情况下，我们会觉得“嘿，我们有可能做得好得多”，然后我们就会用所有的 preference data 去训练模型。在 retrieval 方面也是一样的，对吧？我们可以判断是否检索到了正确的数据——用户是否接受了那次代码修改？那次 retrieval 到底好不好？这些都是我们能获取的信号。所以基本上，我们的看法是：如果某件事纯粹是 code planning，那我们为什么能在这方面做到最强，这并没有一个很好的理由，对吧？我想不出一个站得住脚的理由。但对于更接近于这样的情况——“这是一个非常棘手的 intermediate codebase，这里有一些需要做的修改，而且我们了解代码的演变过程，或者说我们见过数百万用户代码的演变过程”——我们觉得我们能在这方面做得很好。我觉得有趣的是，这也是最终在这个领域胜出的公司的另一个差异化因素：如果你领先，你就会比其他公司拥有越来越多的这种数据。是的，这大概就是从更高层面来看，为什么我们会喜欢从 0 到 1 构建应用的产品空间。我觉得这确实是一个不错的产品领域，但归根结底，我认为它必须落脚于你对代码的理解，否则你就处于一个太高的抽象层面，不清楚为什么你能在这方面比所有人都做得更好。作为一家公司来说，这一点并不明确。你是说作为一家公司？感觉这个领域可能会变得竞争激烈，而且不清楚随着时间推移，你要如何持续地保持差异化。我明白了。因为如果他们只是基于 Sonnet，做着和其他所有 Sonnet 封装者一样的事情，那就没有什么差异化，或者说……这取决于你怎么做。但如果要我这么说的话，如果你处理的输入只是网页元素，比如非常高层级的网页元素，那么界面可能抽象层级太高，以至于你很难在全方位上比那些 frontier models 做得更好。那你不如干脆什么都直接接入就好了。明白了。太棒了。有一点我想回到，我记了笔记，觉得大家真的需要理解。你提到过，用 Windsurf 的时候，你不一定需要从一个 boilerplate codebase 开始，因为它不是一个高度抽象的从 0 到 1 的应用构建器，而是一个你真正在里面写代码的 IDE。你还提到过它必须安装依赖，这是件有点痛苦的事情，而之所以必须这么做，是因为它在你的本地机器上运行，而不是像 lovable、replet 这些公司那样在云端运行。不过我觉得 Bolt 是以一种很酷的方式在你的浏览器里运行。所以这是一个重要的区别。这就像在你的本地机器上运行，拥有实际运行所需的全部库。不，我认为这很重要。我们相信很多人会在所谓的 code spaces 以及远程机器之类的东西上构建软件。我只是觉得很多开发者喜欢在本地构建。就像你说的，如果你做的不仅仅是全栈应用，你的机器上可能会有一些系统依赖，安装起来非常棘手。假设你正在构建一个基于 GPU 的应用程序，而 Nvidia 驱动是必需的。你就是想给人们灵活性，让他们能在最适合的地方构建。而且你知道，IDE 和本地开发是人们已经做了几十年的事情。所以可能在未来几年内它也不会消失。我很喜欢你们销售人员现在在运行本地主机服务器，而且有了浏览器预览功能，这就更容易了，对吧？你只要把它在旁边打开就行。是的，是的。天哪。好了，我还有几个问题，关于你们如何在 Kodium 思考和运作。你们某种程度上处于产品团队未来运作方式的最前沿，就像每天都在见证未来。所以我很好奇，你们组建团队、配置工程师、产品设计的方式，是否有与其他公司不同的地方，或者尝试过效果非常好或非常糟糕的做法。你知道，我们在核心工程方面有一个有趣的决策，那就是针对公司的核心工程部门，我们没有纯粹的产品经理。顺便说一下，这纯粹是因为我们为开发者构建产品，而且我们的产品也是由开发者构建的。所以我认为，来自我们自己开发者的直觉是有价值的。如果不是这样，那我们可能招错了人。所以我觉得我们的开发者在某种程度上是在灵活地承担更传统的产品经理职责。但另一方面，如果我们构建的东西更像 Uber，或者用户画像非常不同，而且我们自己也不理解它，那我觉得我们的组织架构就不会是现在这个样子。对于公司的企业端来说，因为我们确实与很多大型企业合作，这些需求不是我们工程师能自动理解的，对吧？我不认为我们的工程师每天醒来会想“我们需要 FedRAMP”，对吧？这大概是很多客户来找我们时提出的需求。我们有一些人在产品战略这个角色上灵活变通，他们既理解客户想要什么，又理解我们拥有的技术能力，从而最好地构建出能大规模帮助他们的产品。所以我认为我们在这方面有一个有趣的组织架构，但主要我想说是因为我们是一个面向开发者的产品。嗯，我想说确实如此，然后就像你说的，对于工程团队本身，我们的团队结构相当扁平。我们尽量采用 two pizza teams，保持团队规模相当小，只是因为我觉得问题在于，当一个团队变得太大时，团队负责人就无法再深入钻研技术本身了。而且我认为在这个变化如此迅速的领域，让领导层不深入理解技术、不参与构建是非常危险的，因为会出现太多纸上谈兵的情况。所以我觉得这可能是我们做的另一个决策。另外，团队非常灵活，所以如果我们决定某件事是新的优先事项，我们会很快改变团队的构成，而且在这方面是非常集中规划的。关于 two pizza team 这个概念，我很久以前看到一条推文，有个印度人说大家都在谈论 two pizza teams，但印度的披萨要小得多，所以团队最终更小，他们就说为什么我们不能像美国团队那样构建那么多东西。天哪。好吧，那你们有多少 PM？你说你大概有150名员工。是的，在产品战略职能方面，我们现在有三个人担任这个角色。我明白了，所以就是产品方面，他们的头衔是产品战略，不一定是产品管理。没错。有意思。然后有50名工程师。你说大概80名销售人员。是的，没错。然后显然我们还有一些职能部门，比如招聘，还有 GNA 的一部分，比如财务，对吧？我们公司还有市场营销。所以内部还有一些其他职能。有意思的是，这也是你经常听到的，比如 Anthropic 的 Dario 就说90%的代码将由 AI 编写。但与此同时，你们却在疯狂招聘工程师。这矛盾吗？这矛盾吗？会不会有一个拐点，到了某个时刻，好吧，我们不再需要他们了？你知道，我认为这归根结底取决于，你在内部增加工程师是否能获得边际价值。首先，也许我要澄清一下，如果 AI 写了超过90%的代码，并不意味着工程师的生产力提高了10倍，对吧？工程师花的时间不仅仅是写代码。他们还要审查代码、测试代码、调试代码、设计代码、部署代码，对吧？浏览代码。工程师可能要做很多不同的事情。并行计算中有一个著名的定律，叫 Amdahl's law。我不知道你听没听说过，但它基本上是说，如果你有一个任务图，有一条关键路径，你把其中任何一个任务大量并行化，也就是让它几乎不花时间，对整个流程的提速仍然有限制。简单来说，假设你有100个单位的时间，只有30个单位的时间花在写软件上，我把这30变成了3。我也只是把100变成了73。从全局来看，这仍然只有27%的提升。所以我觉得，你看，我们确实看到了超过30%，可能接近40%的生产力提升，但对于我们要解决的愿景来说，我觉得，即便说公司长期拥有200名工程师，那时候可能仍然太少。所以问题是，每增加一个人，你能获得多少额外的生产力。实际上，也许我还要再说一点，对于一些大公司来说，假设你去找 JP Morgan Chase 的 CIO，她每年在软件上的预算是170亿美元，公司内部有超过5万名工程师，对吧？你告诉她，嘿，现在每个工程师都能产出更多的技术了。这实际上就是你做到的事情，对吧？JP Morgan Chase 或任何这类公司会做出的正确计算是，构建技术的投资回报率实际上上升了。所以不投资更多技术的机会成本上升了，这意味着你应该投入更多，也许在短期内你会有更多的工程师。当然，现在这并非普遍适用。有些公司对它们构建的技术量感到满意，它们对想要构建的技术量有一个上限。但对于那些技术上限实际上非常高的公司来说，这并不意味着你要停下来。这实际上意味着你要招更多的人。这对工程师来说是一个很好的 bull case。我觉得工程行业的"煤矿里的金丝雀"，就是看像我们这样的公司何时会放缓工程师招聘。但目前这并没有发生。我觉得我们也在大量招人。是的，所有人都在招。所以我认为这非常鼓舞人心。我觉得如果你还在上大学，现在进入工程领域仍然是有意义的。是的。好的。让我问你一个问题，大概作为最后一个问题。关于打造 AI 产品、打造 Wind Surf，以及身处这个领域，你学到的最反直觉的事情是什么？我觉得其中一件奇怪的事情是，在网上每个人都很兴奋于我们取得的短期胜利，对吧？比如我们每周发布的东西。我们每隔几周就会推出一波更新，但实际上公司内部下的很多赌注并不在三四周后，也许在三、六、九个月之后。那才是我们内部正在推进的工作，因为我觉得这就像 Lenny，我之前跟你提到过的，我告诉公司里每个人的目标之一是：我们应该每6到12个月就自我颠覆产品的现有形态。每6到12个月，新产品就应该让现有产品显得愚蠢。它甚至应该让现有产品的 form factor 显得笨拙。所以这里存在一种奇怪的紧张关系：你既想把产品推向市场，又想逐步迭代、倾听用户、让它越来越好。但我想说，我们是第一个推出 agentic IDE 产品的，对吧？我们一开始就是这样的定位，而我认为这种价值会迅速贬值，除非我们持续重新证明自己，而且我们需要以用户甚至都没有要求过的方式来重新证明自己。所以这里存在这样一种张力：渐进式改进感觉非常安全，对吧？再加一个按钮。用户说："嘿，我希望这个下拉菜单能做 X。"但这不是我们会赢的原因。那只是一种……你知道，那几乎是 table stakes。是的，我们会决定做其中一些。我们可能不会决定做很多这类事情，但公司内部那些几乎会颠覆现有产品的长期努力，才是我们最终能成功的原因。而且你脑海中需要有这样一种奇怪的平衡：你也不能完全不听用户，因为他们是你存在的原因。这让我想起最近的一位播客嘉宾。我们邀请了 Captions 的 Gar 来节目，他告诉我们他们有两份路线图。他们公司内部有两份路线图：一份是"真正的"路线图，就像那种典型的基于功能请求、用户反馈和数据之类的路线图；然后他们还有一份秘密路线图，这份路线图完全不参考用户或数据，只是他们对世界走向的下注。没错。而且我很喜欢他把它叫做"秘密路线图"，就是为了让它显得很神秘。这很聪明。好的，我还有一个问题，抱歉。在创办 Kodium 之前，你希望自己知道的一件事是什么？说实话，我希望自己……也许"谦逊"这个词不太准确，而是那种能够更快接受自己错了的心态。就像我们做决定的时候，我和联合创始人总会聊起这个。我们几乎总是在说："嘿，真希望我们能早几个月做出这个决定。"我们总是这么说。而奇怪的是，从外部看，所有人都会觉得："哇，实际上这个决定做得正是时候。"但在我脑海里，我总是懊恼地想：要是我们能早几个月做出这个决定会怎样？我觉得部分原因在于，你知道，我曾经很诗意地讲过，你需要非理性的乐观，同时又要毫不妥协地务实，但实践中这很难做到，对吧？因为你也会对自己的那套说法深信不疑。因为如果你自己都不信那一套，你根本就不会起床，对吧？答案早就定了。赢家不会是这些创业公司。答案是 Microsoft 将会成为任何软件品类的赢家，对吧？这不就是答案吗？就因为它的分发渠道、资源和资本，对吧？它会把每个领域都商品化。所以我觉得，在某种程度上，你需要明白——要更频繁地重新评估自己的假设，更频繁地让自己进入不舒服的状态——这是我直到今天都需要提醒自己的，可能也是我在创办公司之初所不了解的。对吧？我们创办公司的时候差不多是在 ZIRP 的顶峰时期，那时候好像所有东西都要一飞冲天，我觉得当时我们有一种不该有的非理性自信。我们聊了这么多，多么精彩的一场对话，我坐在这里听和问都学到了很多。在我让你走之前，你还有什么想分享的吗？或者给听众留下什么最后的小建议或智慧？说实话，我可以对这个领域做一些预测，但大多数可能都会……我觉得最好的做法就是亲自去用所有这些产品，把手弄脏。而且我觉得最明显即将发生的一件事是，未来一年里，任何能够最大限度利用这些工具的人都将获得巨大的 alpha。想象一下，你有多少同事根本不知道这些工具的存在，不知道它们能做什么，他们的效率会低多少。所以我要说的就是，尽快、尽可能亲自去用。你说的"把手弄脏"，基本上就是下载 Wind Surf，开始写代码，让它帮你构建东西。是的。做应用，做应用。开始用它来做原型，甚至修改你现有的代码库。你可能可以以组织从未预料到的方式成为团队的 force multiplier。想象一下，如果你是一个能很快编辑代码库、自己就开始推送变更的产品经理。你可能会从工程同事那里获得极大的尊重。你也可能因此完成更多的事情。我觉得到了那个时候，某种程度上就没有天花板了。我觉得你说的这一点非常被低估。有些应用可以从零开始构建东西，还有些像 Wind Surf 这样的应用可以编辑你现有的代码库。如果你是产品经理，在……你们合作过的最大的公司，从人数上说，是哪家？公开来说，我们现在可以说 JP Morgan Chase。他们有超过5万名开发者。好的。所以你可以是 JP Morgan Chase 的一名产品经理，然后想：我有一个需要解决的问题。我想推动这个指标。我想改变注册流程中的某个步骤。你只需打开 Wind Surf，告诉它你想做什么。然后你能直接推送到 GitHub 并做一个……是的，实际上你可以这么做。好的。PR。是的，它可以帮你做一个 PR。这太疯狂了。好的。未来已经失控了。好的，我们要做这个。最后这一点非常重要，因为我觉得很多人可能没意识到。他们看到其他那些应用，会觉得："哦，就是做一些原型。"但这确实是产品经理可以真正用来干活的东西。是的。当你想到至少是我——我不知道，Lenny——你最尊重的那些人，他们就是这样一群人：不知怎的，尽管有头衔在身，他们的能动性和产出，从最细微的细节到最高层面的战略，都是完美的，对吧？他们知道什么时候该深入细节。而且我觉得，有时候你会看到一些人谈论自己的角色时，会非理性地觉得，哦，因为我是这个职位，所以我不该碰这个。但现在一切都放开了，对吧？我认为这是一个机会，既可以深入最琐碎的细节，也可以上升到最高层面，对吧？然后在每个层面都能发挥作用。太不可思议了。好吧。那么，说到这里，我们就先告一段落了。呃，Arun，非常感谢你能来。太棒了。非常感谢。这场对话太精彩了。谢谢，Run。大家再见。非常感谢大家的收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅。另外，请考虑给我们打个分或留条评论，因为这确实能帮助其他听众找到这个播客。你可以在 lennispodcast.com 找到所有往期节目或了解更多关于这个节目的信息。下期节目再见。