Linguista

「YC访谈-Windsurf CEO」押注 AI Agents，48 小时转型，以及编码的未来

内容介绍

本篇访谈录记录了与 Windsurf 公司联合创始人兼 CEO Varun Mohan 的深度对话。Windsurf 作为一款快速崛起的 AI 开发者工具，其发展历程颇具戏剧性。访谈中，Mohan 详细回顾了公司从最初的 GPU 虚拟化业务 (Exofunction) 出发，如何在意识到行业巨变后，于短短一个周末内毅然决定转型，投身 AI 辅助编程领域，并推出了 Codium（Windsurf 的前身）。

对话深入探讨了 Windsurf/Codium 在技术层面的诸多挑战与突破，包括如何在资源有限的情况下，快速自研模型以追赶甚至超越 GitHub Copilot，以及他们在理解代码上下文、优化检索增强生成（RAG）方面采取的独特策略。同时，访谈也涉及了公司如何从 VS Code 扩展进化为功能更强大的独立 IDE (Windsurf)，其背后的战略考量以及对 AI Agent 未来发展的押注。

此外，Mohan 还分享了关于市场竞争、团队建设、人才招聘以及对 AI 时代软件开发未来的看法，包括对“开发者”角色演变、新兴创业机会的洞察。对于希望了解 AI 工具领域前沿动态、初创公司如何在快速变化的技术浪潮中导航、以及 AI 如何重塑软件工程实践的读者，本次访谈提供了来自一线实践者的宝贵经验与思考。

内容纲要

├── 引言
│   ├── 创业公司需不断证明自己，洞察力会贬值 (Varun Mohan)
│   └── 介绍嘉宾 Varun Mohan (Windsurf CEO/联合创始人)
├── I. 公司背景与关键转型
│   ├── 公司起源：Exofunction (GPU 虚拟化)
│   │   ├── 创始团队背景 (自动驾驶, AR/VR)
│   │   └── 早期业务模式与规模 (管理 1 万 GPU, 数百万收入)
│   ├── 转型催化剂
│   │   ├── Transformer 模型兴起带来的威胁 (商品化风险)
│   │   └── 原有假设被证伪 (定制模型 vs 通用大模型)
│   ├── 关键转型决策 (Pivot)
│   │   ├── 意识到无法规模化，周末决定转型
│   │   ├── 团队受 GitHub Copilot 启发
│   │   └── 快速行动：周一通知，立即开发 Codium
│   └── 转型心态
│       ├── 仅 8 人团队，已获 A 轮融资
│       └── 需要“非理性乐观”与“不妥协的现实主义”
├── II. Codium/Windsurf 的产品开发与技术
│   ├── 早期版本 (Codium V0)
│   │   ├── 2 个月发布 VS Code 扩展
│   │   ├── 基于开源模型，性能劣于 Copilot 但免费
│   │   └── 利用自有推理运行时降低成本
│   ├── 自研模型与技术突破
│   │   ├── 快速攻关，从零训练模型
│   │   ├── 解决“Fill-in-the-middle”问题，实现差异化
│   │   └── 短期内在质量和延迟上取得优势
│   ├── 先进的上下文理解与 RAG
│   │   ├── 超越简单向量数据库 RAG
│   │   ├── 混合方法：关键字搜索、向量、AST 解析、GPU 实时排序
│   │   └── 目标：提高复杂查询的精确率和召回率
│   └── 评估 (Evals) 的核心作用
│       ├── 受自动驾驶背景启发，重视评估体系
│       ├── 评估驱动开发，提供明确改进目标
│       └── 评估方法：利用开源项目、提交历史、单元测试等
├── III. 产品演进与市场拓展
│   ├── 企业客户获取
│   │   ├── Codium 时期吸引 Dell, JP Morgan Chase 等
│   │   └── 关注大型代码库的个性化与性能
│   ├── 拓展 IDE 支持
│   │   ├── 早期决策支持多 IDE (VS Code, JetBrains 等)
│   │   └── 原因：满足企业多样化需求，追求成为标准
│   ├── 从 Codium 到 Windsurf IDE
│   │   ├── 背景：VS Code 限制 Agent 能力发挥
│   │   ├── 目标：提供更好的 Agent 体验
│   │   └── 快速开发：<3 个月发布 Windsurf (基于 VS Code fork)
│   ├── 竞争策略
│   │   ├── 不受竞争对手影响士气 (经历过更大动荡)
│   │   ├── 关注自身长期战略与执行
│   │   └── 对比 Cursor：强调 Agentic Editor, 简化交互而非过度配置
│   └── 非开发者用户
│       ├── 意外发现大量非编程背景用户
│       └── 体现 AI 降低开发门槛的潜力
├── IV. AI 编码的未来与行业思考
│   ├── AI 对软件开发的影响
│   │   ├── "Vibe coding" 将更强大
│   │   ├── AI 将在 SDLC 各环节带来 10x 效率提升
│   │   ├── 未来可能出现“Just-in-Time”软件
│   ├── “开发者”定义的扩展
│   │   ├── 演变为“构建者” (Builder)
│   │   └── 软件开发民主化
│   ├── 人才招聘与团队
│   │   ├── AI 时代需要高能动性、乐于试错的工程师
│   │   ├── 面试方式调整：结合 AI 使用与基础能力考察
│   │   └── 虽效率提升，仍需扩大团队以实现宏大目标
│   ├── 应对基础模型迭代 (GPT Wrapper Meme)
│   │   ├── 承认挑战，持续提升附加值
│   │   └── 机会在于弥合基础模型与 100% 自动化之间的差距
│   └── 给 AI 初创公司的建议
│       ├── 深耕特定领域 (Niche)
│       └── 例子：代码迁移 (COBOL to Java), 自动化 Bug 修复
└── V. 核心经验与总结
    ├── 最重要的经验：快速改变想法，视 Pivot 为荣誉
    └── 持续产出新见解，对抗“洞察力贬值”

Windsurf CEO：押注 AI Agents，48 小时转型，以及编码的未来

引言

Varun Mohan: 我认为对任何初创公司都适用的一点是，你必须不断证明自己。我们拥有的每一个洞察力都是在贬值的。看看像英伟达这样的公司，如果英伟达在未来两年不创新，AMD 就会紧随其后。这就是为什么我完全接受我们很多见解可能是错误的。如果我们不持续拥有我们正在执行的见解，我们只是在慢慢消亡。仅仅是“开发者”这个概念，很可能会扩展到所谓的“构建者”，我认为每个人都将成为构建者。我认为软件将成为一种非常、非常民主化的东西。

主持人: 欢迎回到 Lightcone 的另一期节目。今天我们有特别的嘉宾，Windsurf 的联合创始人兼 CEO，也是将“Vibe Coding”（凭感觉编码）带入现实的人之一，Varun。感谢你的加入。

Varun Mohan: 谢谢你们邀请我。

I. 公司背景与关键转型

主持人: Windsurf 现在发展到什么程度了？我们直观地知道，我们也在用，但它现在有多大规模？是从哪里开始的？

Varun Mohan: 嗯，这个产品已经有超过一百万的开发者使用过。目前有数十万的日活跃用户。它被用于各种场景，从修改大型代码库到极速从零到一构建应用。我们对这项技术未来的发展方向感到非常兴奋。

主持人: 让我们直奔主题吧，你们是怎么开始的？

Varun Mohan: 公司实际上是四年前成立的，我们一开始不叫 Windsurf，而是一家名为 Exofunction 的公司，当时我们是一家 GPU 虚拟化公司。之前我和我的联合创始人在自动驾驶和 AR/VR 领域工作过，我们相信深度学习将改变许多行业，从金融服务到国防再到医疗保健，很多行业。是的，但我们可能时机没选对。最终，我们构建了一个系统，让运行这些深度学习工作负载变得更容易。类似于 VMware 为计算机和 CPU 所做的事情，我们为 GPU 做了同样的事。然而，到了 2022 年中，当时的情况是，我们为少数几家公司管理着多达 10,000 个 GPU，并且已经实现了几百万美元的收入。但是 Transformer 模型因为像 OpenAI 的 text-davinci 这样的模型变得非常流行。我们觉得那将从根本上颠覆我们已有的业务，或者说当时我们那个小小的业务。因为我们觉得每个人都会运行这类 Transformer 模型。在一个每个人都将运行一种模型架构（Transformer）的世界里，我们认为如果我们是一家 GPU 基础设施提供商，我们就会被商品化，对吧？如果每个人都做同样的事情，我们的 Alpha（超额收益）会是什么？所以当时我们基本上就在想，嘿，我们能不能利用我们的技术，将公司彻底转型去做别的事情？

主持人: 这很吓人啊。

Varun Mohan: 那是一个“赌上公司”的时刻。我们在一个周末内就完成了。那个周末，我和我的联合创始人进行了一次对话，大意是“我不认为这行得通，我们不知道如何扩展这家公司”。当时我们是 GitHub Copilot 的早期使用者。周一我们告诉了公司其他人，然后每个人就立即在那个周一开始着手开发 Codium，也就是那个扩展产品。

主持人: 我很好奇想深入了解这个转型故事，因为听到转型的细节，尤其是后期转型的细节，是相当罕见的。在你们决定转向 Codium 的时候，公司发展到什么阶段了？有多少人？

Varun Mohan: 关于公司的一件事是，我想我们试图采纳很多 YC 的理念，比如“拉面盈利”（ramen profitability）之类的关键见解。当时我们只有一个 8 人的团队，尽管我们已经有了几百万美元的收入，我们差不多是自由现金流为正的状态。那时正是零利率政策（ZIRP）的高峰期。所以公司成立了一年半，我们当时神奇地筹集了 2800 万美元的现金。我认为当时我们脑海中的关键点是，如果我们不知道如何扩大规模，即使现在做得还不错也没关系，我们需要非常快地改变现状。

主持人: 我觉得了不起的是，当你创办公司时，你有一个假设，你赌的是很多公司会建立自己的定制深度学习管道来训练 BERT 模型，对吧？那是当时看起来行得通的。但在 2022 年，你看到了“曲棍球棒式”的转变，突然间似乎会有一个模型统治一切。所以你预见了很多未来，而且很多是源于那种信念。我很好奇，那些迹象是什么？因为你肯定已经深入其中了——当时已经有七位数的收入，本可以进行 A 轮融资，但你却说“我们要把这一切都扔掉烧掉”。

Varun Mohan: 是的，实际上更疯狂的是，我们当时已经完成了 A 轮融资。但我们是否本该能融到是另一个问题。不，我觉得你完全正确。我认为当时发生的一件事是，我们主要与自动驾驶公司合作，因为他们当时拥有最大的深度学习工作负载。我们当时看到，那个工作负载在增长并且规模很大，但我们从根本上赌的是其他的自然语言工作负载，比如金融服务、医疗保健等其他行业的工作负载会起飞。但一旦我们看到这些生成式模型能够处理如此多的用例，对吧，举个例子，过去你会训练一个 BERT 模型来进行情感分类，但很快，当我们尝试即使是 GPT-3 的一个较差版本，比如非常老的版本时，我们就觉得“这会扼杀情感分类”。没有人再有理由为这个任务训练一个非常定制化的模型了。我想我们看到了不祥之兆，我们的假设就是错的，对吧？这就是那种情况，你带着某个关于你认为领域将走向何方的论点进入，但如果你的假设是错的，并且地面上的信息发生了变化，你就必须非常快地改变。

主持人: 那你们决定怎么做呢？就是说，你们决定好了，我们要转型。当我们与创始人合作时，这通常是第一阶段。所以你们不是半推半就，你们有那个信念，我们需要尝试一些东西。你们是如何确定下一步该做什么的？

Varun Mohan: 我想我们需要选择一些公司里每个人都会感到兴奋的事情。我认为如果我们选择了我们认为可能有价值但人们不兴奋的事情，我们最终会失败，会立刻失败。我们带着一个有主见的立场：我们是 GitHub Copilot 这个产品的早期使用者。我们认为那只是技术发展方向的冰山一角。显然，公司里的每个人都是开发者。开发工具公司通常来说，过去表现并不那么好。但是，嘿，当你别无选择时，决策就变得非常容易了，对吧？你很大概率会归零，你还不如选择一个你认为可能有价值并且每个人都有动力去做的事情。

主持人: 我想现在大家都忘了，感觉上是因为 GitHub Copilot 已经成了背景板。但在那个特定的时刻，感觉 Copilot 赢定了是必然的，对吧？它拥有一切，比如 GitHub 的连接、微软的分发渠道、OpenAI…

主持人: OpenAI，是的。

主持人: 感觉好像没人能竞争得过。所以你们是怎么有勇气说“啊，是的，我们完全能打败 Copilot”的？

Varun Mohan: 是的，所以这就是“非理性乐观”的部分了。我之前对公司说过，但我认为初创公司需要两种截然不同的信念，它们实际上有点相互矛盾。你需要这种非理性的乐观，因为如果你没有乐观精神，你就什么也做不成，你只是个悲观主义者和怀疑论者，而那些人在生活中通常一事无成。同时，你需要不妥协的现实主义，也就是说当事实改变时，你确实要改变你的想法，对吧？同时做到这两点是非常困难的，因为让你通过非理性乐观取得成功的东西，比如你的信念，恰恰与那些让你成为一个非常现实的公司的东西是相反的。所以，非理性的乐观让我们基本上说：“嘿，我们知道如何自己运行和训练模型。”我们实际上自己训练了第一个自动补全模型，并在我们的产品上运行，免费提供。我不认为我们当时对未来的发展有确切的路线图，但我们只是觉得这里还有很多事情可以做。如果，呃，如果我们做不到，那我想我们就完了。但我们不妨赌一把我们能做到。

II. Codium/Windsurf 的产品开发与技术

主持人: 你们早期的版本比当时的 GitHub Copilot 更好吗？

Varun Mohan: 我们发布的最早版本在质量上远不如 GitHub Copilot。唯一的区别是它是免费的。转型后，我们在大概 2 个月内构建了一个 VS Code 扩展，并发布了产品，还在 Hacker News 上发了帖子。我们构建了那个产品，它缺少很多关键功能，比如我们运行的模型是一个开源模型，远不如 GitHub Copilot 运行的模型好。很快，我们的训练基础设施变得更好了。所以我们实际上出去根据任务训练了我们自己的模型。然后突然间，它实际上获得了 GitHub Copilot 当时都没有的功能。在 2 个月内，具备了基本能力。现在我们会觉得这甚至算不上最先进的技术，这很可笑，但我们的模型实际上可以在代码中间进行填充。当你写代码时，你不仅是在光标末尾添加代码，你还在两部分之间，一行的两部分之间填充代码，对吧？而那部分代码非常不完整，看起来与这些原始模型的训练数据完全不同，对吧？所以我们训练了我们的模型，使其在这种用例下变得非常非常有能力。这实际上让我们的质量和延迟方面得以领先。我们在几个月内就能控制很多细节。

主持人: 到 2023 年初，我会说自动补全能力比 Copilot 当时要好得多。这对你们来说是全新的能力吗？因为你们之前一直在构建 GPU 基础设施。听起来你们基本上是通过采用一个现成的开源模型，将其塞进一个 VS Code 扩展，然后把两者连接起来，从而快速搞定了第一个版本。但紧接着，你们就必须从头开始训练自己的编码模型。你们之前一直在关注 Transformer 的东西，但你们并没有真正构建过它。为了做到这一点，我猜你们必须下载整个 GitHub 的代码库，然后从头开始训练一个完整的模型。你们是怎么在仅仅两个月内搞定这一切的？

Varun Mohan: 是的，嗯，这是个很好的问题。首先，当我们自己运行模型时，我们之所以能够运行它并免费提供，是因为我们当时实际上拥有自己的推理运行时（inference runtime）。这显然源于我们最初是一家 GPU 虚拟化公司的事实。这使我们能够很快地用开源产品发布 V0 版本。紧接着，你完全正确，我们以前从未训练过这样的模型。但我想我们雇佣了聪明、能干、并渴望获胜的人。所以我们需要搞定它。没有其他选择，对吧？否则你就死了。这让决策变得非常非常简单。所以是的，我们必须弄清楚如何获取大量数据，如何大规模地做这件事，如何清理这些数据，如何让它能够处理代码非常不完整的这种情况。然后我们很快就发布了一个模型。

主持人: 哇，你们用大概 8 个人在两个月内完成了所有这些？

Varun Mohan: 是的，没错。

主持人: 你提到你们从第一性原理出发，构建了一个更复杂的系统，做了所有这些解析等等，这很酷。

Varun Mohan: 是的，我想也许其中一个可能有趣的讨论点是，我们公司很多人最初是做自动驾驶的。这之所以重要，是因为那些系统你不能随便应付，也就是说，你不能只是构建了软件然后就让它运行。你需要非常好的评估体系。我认为在公司，我们不追求复杂性，我们追求的是有效性。那么问题来了，为什么现在的系统复杂得多？那是因为我们构建了非常好的评估系统。

主持人: 哦，有意思。评估是怎么进行的？

Varun Mohan: 是的，代码的评估实际上非常酷。基本上想法是，代码可以利用它能够运行的特性，对吧？我们不仅有实时用户数据——我们可以暂时把那个放在一边——但我们可以获取大量开源项目，并在这些开源项目中找到附带测试的提交（commits）。所以你可以想象基于此我们可以做很多很酷的事情。你可以获取一个提交的意图，删除所有不是单元测试的代码，对吧？然后你可以看看，嘿，你是否能够检索到需要进行更改的部分？你是否有一个好的高层意图来进行这些更改？然后在进行更改后，测试是否通过？你可以做这个任务，你可以掩盖（mask）这个任务。通过掩盖任务，它更像是谷歌的任务。我说的谷歌任务是指它试图预测你的意图，也就是说，假设你只输入了三分之一的更改，但没有得到意图，你能否补全剩下的部分让测试通过？所以你可以用很多方式来剖析这个问题，并且每一个都可以分解成更细的粒度。你可以问，我的检索准确率是多少？我的意图准确率是多少？我的，呃，我的通过率是多少？我的测试通过准确率是多少？你可以做到这些，然后现在你就有了可以攀登的山峰。我认为这实际上很重要，在你为任何这些 AI 应用增加很多复杂性之前，我想你需要建立一个你可以实际攀登的严格的山峰，对吧？否则你只是在黑暗中射击，对吧？如果我们添加 AST 解析是不必要的，那为什么还要加呢？实际上，如果它是不必要的，那就太棒了，对吧？我不想在我们的代码中添加很多复杂的东西。事实上，我想要最简单的代码，最终能产生最大的影响。所以评估对我们在公司进行很多这类投资来说真的非常非常关键。

III. 产品演进与市场拓展

主持人: 紧接着，因为你们运行自己的模型，你们开始获得有趣的客户，对吧？

Varun Mohan: 是的，所以基本上发生的情况是，当时产品是免费的，所以我们最终在所有 IDE 上都吸引了大量开发者使用，包括 VS Code、JetBrains、Eclipse、Vim。公司开始联系我们，因为他们不仅希望以安全的方式运行产品，还希望将其个性化，适配公司内部的所有私有数据。所以在接下来的几个月里，像戴尔、摩根大通这样的公司很快就开始成为我们产品的客户。现在这些公司内部有数万名开发者在使用我们的产品。但我们开始将公司的重点放在确保产品在这些非常大的代码库上运行良好。其中一些公司的代码库超过一亿行代码，对吧？确保建议快速是一方面，但确保它真正个性化到他们拥有的代码库和环境，在当时几乎是一个硬性要求。

主持人: 你们完成了那次转型，在两个月内构建了产品，然后发布了它，并在几个月内就拿下了这些大客户？

Varun Mohan: 是的，我的意思是，显然这些公司需要一些时间来敲定合同，但是在之后的几个月或一个季度内，试点项目就开始了。显然，我们公司当时没有销售人员，所以创始团队就只是尽可能多地运行试点项目，看看最终哪些会成功。

主持人: 你们在什么时候从仅仅是 VS Code 扩展扩展到支持所有这些其他 IDE 的？

Varun Mohan: 那其实是在之后很快就发生了。

主持人: 你们是怎么考虑这个问题的？比如，有一种观点是，VS Code 开发者很多，你们团队很小，你们本可以说服自己只专注于为 VS Code 构建一个很棒的体验。你们只占领了所有可能的 VS Code 开发者市场中很小的一部分。但你们没有那么做。你们很快就横向扩展，为所有那些 IDE 构建了扩展。为什么？

Varun Mohan: 我想也许我们认为非常关键的根本原因是，如果我们要与公司合作，公司里的开发者会用很多种语言编写代码。比如，像摩根大通这样的公司，可能有超过一半的开发者用 Java 编写代码，而对于那些开发者，他们会使用 JetBrains 和 IntelliJ。目前全球超过 70% 到 80% 的 Java 开发者使用 IntelliJ，对吧？所以我们就会不得不拒绝很多公司，很多公司就无法将我们作为他们事实上的解决方案，我们会成为公司内部众多解决方案中的一个。因此，我们做出了这个决定。但幸运的是，因为我们足够早地做出了这个决定，它改变了我们构建产品的架构方式，也就是说，我们不是为每个 IDE 构建一个单独的产品版本。我们有很多共享的基础设施，实际上是运行在每个编辑器层面上的。所以实际上只需要编写非常非常少量的代码，就能确保我们支持尽可能多的 IDE。所以这是我们早期做出的一个决定，最终使得这种转换变得容易得多。

主持人: 那么从 Codium 到 Windsurf 的转变呢？

Varun Mohan: 当时，你知道，现在大概是 2023 年年中，我们开始与一些非常大的企业合作。在接下来的一年里，业务收入已经远远超过了八位数，这仅仅是来自这些企业使用我们的产品。我们有这个免费的个人产品，但我认为关于这个行业我们都知道的一点是，这个领域发展得非常非常快。我们基本上总是在对那些不确定的事情下注。实际上，我们在公司下的大多数赌注都行不通。我很兴奋，当我，比如，当我很高兴我们正在做的事情中只有 50% 真正起作用时，因为我认为如果 100% 我们在做的事情都起作用，嗯，我认为这对我们来说是一个非常糟糕的信号。因为它可能意味着以下三件事中的一件。第一件事是，嘿，我们不够努力，对吧？这可能就是它的意思。第二件事是我们不知何故非常自大（hubris），对吧？这种自大就是我们相信我们做的每件事都是对的，即使地面上的事实并非如此。然后，第三个关键点是，我们实际上没有以一种能够告诉我们未来走向的方式来测试我们的假设。我们实际上没有站在能力和技术的最终前沿。我们实际上在去年年初就相信 Agents 会变得极其重要。我们在去年年初就有这方面的原型，但它们就是行不通。但是我们正在构建不同的部分，我们觉得这些部分对于让 Agents 工作起来很重要，那就是理解大型代码库，理解开发者在代码库上快速进行编辑的意图。我们拥有所有这些部分。我们缺少的是一个能够足够有效地调用这些工具的模型。然后显然在去年年中，随着像，呃，GPT-3.5 的出现，情况完全改变了。有了它，我们基本上说：“好吧，我们现在有了这些 Agent 能力，但是我们能在 VS Code 上向开发者展示的东西的上限是有限的。”我们无法提供足够好的体验。我们认为将会发生的是，开发者将花费更多的时间不是在编写软件，而是在审查 AI 将要生成的软件。我认为我们本质上是一家技术公司，你知道，我认为我们是一家产品公司，但我认为产品服务于技术，也就是说，我们希望让产品尽可能好，以便人们能够体验到技术，对吧？我们觉得，你知道，用 VS Code 我们无法做到这一点。所以在去年年中，我们决定：“嘿，我们实际上需要走出去，拥有我们自己的 IDE。”所以这就是促使我们实际创建 Windsurf 的原因。

主持人: 你们这样做的方式是 fork 了 VS Code？fork VS Code 意味着你们必须学习一套全新的能力，基本上是如何在 VS Code 这个我敢肯定超级复杂的代码库上进行开发。

Varun Mohan: 是的，我们需要搞定那个。那又是一次，嗯，我们在启动项目后不到 3 个月内就发布了 Windsurf。那时我们就在所有操作系统上发布了它。

主持人: 哇，结果怎么样？是立刻就火起来了，还是在很长一段时间内都无人问津？

Varun Mohan: 我会说它起飞得相当快。我认为它在早期采用者中起飞的速度相当高。显然存在一些非常粗糙的地方，这就是那种情况，你知道，因为粗糙的地方，人们开始相当快地进入和离开平台。但我们看到的是，随着我们改进 Agent 的能力，随着我们改进被动体验的能力——即使是被动的 Tab 补全体验在过去几个月里也取得了巨大的飞跃——我们开始意识到，不仅人们越来越多地谈论这个产品，而且人们也以更高的留存率留在这个产品上。

主持人: 有多少人参与了 Windsurf 的发布？而且是在一两个月内完成的？

Varun Mohan: 是几个月。是的，不到三个月。这又是一次，我不会说这是赌上公司的时刻，因为它与从 GPU 虚拟化产品转向 AI 代码产品相比，不是一个根本上不同的范式。但是的，任何能参与其中的人都需要放下他们过去正在做的工作，立即投入到这个项目中。

主持人: 那时候你们公司有多大？

Varun Mohan: 工程团队可能仍然不到 25 人。

主持人: 哇，这太疯狂了。

Varun Mohan: 有趣的是，我们公司从员工数量的角度来看，其实人并不少。我们实际上有一个相当大的市场推广（go-to-market, GTM）团队。因为在 AI 领域，我们公司与大多数其他公司相比有点奇怪的一点是，我们有一个相当大的 GTM 团队。比如，我们将产品销售给最大的财富 500 强公司。仅仅让他们刷信用卡来购买是很难做到的。你需要大量的支持，你需要确保技术被正确地采用。这与仅仅把产品给人们然后看着它增长是非常不同的。所以从工程角度来看，我们一直保持相当精简。但由于市场兴趣浓厚，我们实际上一直有很多 GTM 人员。

主持人: 谁是进入那个职能的理想人选呢？是非常优秀的、愿意被前置部署的工程师吗？

Varun Mohan: 是的，我们有两部分组成。我们有客户主管（Account Executives, AE），这些人，总的来说，我们试图找到那些对能力非常好奇和兴奋的人。事实上，是那些会在业余时间使用 Windsurf 的人，因为他们正在向同样热爱软件和技术的领导者提供产品，对吧？所以如果他们完全不了解技术，他们就不会有帮助。然后我们也有这些部署工程师（Deployed Engineer）的角色，类似于你说的，他们会深入接触技术，并确保我们的客户从技术中获得最大价值。

IV. AI 编码的未来与行业思考

主持人: 有趣的是，因为每个人都在使用 Windsurf，听起来甚至这些非技术的 AE 也成为了“Vibe Coding”的高手。

Varun Mohan: 是的，不，我们公司 Windsurf 的最大用户之一是一位非技术人员，他负责公司的合作伙伴关系。他实际上已经取代了公司内部购买一堆销售工具的需求。这是我认为 Windsurf 正在将权力交还给领域专家的情况之一，对吧？过去在一个组织中会发生的是，他需要和产品经理谈，产品经理再和工程师谈，而工程师会有一个很长的积压工作列表，因为这显然不会立即改善产品，对吧？所以这必须是较低优先级。但现在他实际上被赋能去构建这些应用程序了。

主持人: 他有任何编程背景吗？

Varun Mohan: 没有。

主持人: 有趣，因为这绝对是目前 Twitter 上的争议之一，就是如果你不懂一点编码，你真的能“Vibe Code”吗？

Varun Mohan: 是的，我们确实有一点，如果我们确实需要部署这些应用中的一个，我们有一个人专门负责确保这些应用是安全的并被部署。但是那个人所拥有的杠杆作用是惊人的。与其让他出去构建所有这些应用，V0 版本实际上可以由公司内部那些是领域专家但非技术的人员来构建。

主持人: 随着 Codium 的发布，你们正面迎击了像微软和 GitHub 这样的巨头。随着 IDE 的发布，你们又在某种程度上正面迎击了 Cursor，当时最热门的初创公司。还有，嗯，我知道，你们内部是怎么考虑这个的？

Varun Mohan: 这可能是我们公司比较奇怪的一点，但我们公司真的不太受其他公司做什么的影响，士气不会真的受到影响，对吧？这是不可能的，比如，我们公司经历了很多非常动荡的时期。我们在只有 10 名员工的时候就不得不转型，并且彻底扼杀掉我们的想法，这对公司来说是常态。其次，在我们这个领域相关的公司一直是一个不断变化的集合。比如，你知道，我非常尊重我们领域的所有公司，但是的，Copilot，如果你回到 2023 年初，每个人都会认为 GitHub Copilot 是每个人都会使用的产品，没有必要再构建别的了。到了年中，Devin 出来了，每个人都说：“嘿，Devin 会解决所有问题”，对吧？我相信他们现在做得很好。然后在那之后，显然 Cursor 做得非常好。所以我认为对我们来说最重要的是，我们是否真的有一个好的长期战略，并且我们是否以一种能够实现长期战略的方式执行，同时在细节上保持灵活性，对吧？只要我们做到这一点，我想我们就有一战之力，对吧？这就是我们一直以来的方式。

主持人: 不过你们会研究竞争对手的产品吗？

Varun Mohan: 是的，是的，我想我们不想把头埋在沙子里，告诉自己我们的产品很棒。而且，而且只是因为那样做很容易。特别是考虑到在开发 Windsurf 之前，公司从收入角度来看也增长得非常非常快。

主持人: 对于完整的 IDE，你们有什么样的看法或品味，可能与 Cursor 有所不同？我实际上是在问，Cursor 显然是一个非常受欢迎的产品，所以在产品层面上，你们为什么会说“哦，是的，实际上我们想这样构建它”？

Varun Mohan: 是的，不，我认为这是一个很好的问题。所以也许第一点是，实际上在我们开始开发 Windsurf 的时候，所有的产品基本上都是聊天和这种自动补全能力。我认为这基本上就是当时 GitHub Copilot 和 Cursor 的样子。我们采取了一个非常有主见的立场，我们认为 Agents 才是技术真正的发展方向。我们是第一个推出的 Agentic Editor（以 Agent 为核心的编辑器）。而且，我认为最大的收获是，我们不相信那种每个人都需要@提及所有东西的范式，对吧？这几乎让我们想起了像谷歌和那些搜索引擎在谷歌改进产品之前的那种反模式，也就是那种有各种不同类别可供搜索的着陆页。但谷歌推出了一个非常简洁的搜索框。即使是当时的谷歌，如果你写上 AND、OR、site: 等，你会得到更好的答案。而现在它变得好多了，对吧？我想我们相信软件会变得越来越容易构建，对吧？我们会从那个起点开始构建。当我们看到该领域所有其他参与者使他们的产品如此可配置，以一种我们认为对于当时的技术水平来说对用户是好的，但将来会变得不必要的方式时。所以我们投资于像如何深度理解代码库以理解开发者意图这样的能力，如何，如何真正走出去并以一种非常快速的方式对代码库进行更改。我们采取的方法是，嘿，与其拥有这个你标记所有东西的只读系统，如果能非常快速地进行更改会怎么样？这就是为什么当时我们是第一个这样做的。现在，如果你问，这在现在看来是不是一个非常明显的决定？我认为现在看来非常明显。这看起来非常明显。

主持人: 看起来一个“护城河”，我们通常认为它是一个名词，但它实际上是一个动词。

Varun Mohan: 是的，是随时间变化的东西，对吧？我也认为对我们来说，我告诉公司，如果我们不持续产生见解，这就是为什么我完全接受我们很多见解是错误的。如果我们不持续拥有我们正在执行的见解，我们只是在慢慢消亡。那就是实际发生的情况。

主持人: 有趣的是，现在回过头来看，更容易将你旅程中的点点滴滴联系起来，看你采取的许多技术赌注最终是如何复合叠加，形成了 Windsurf 最终的样子，对吧？比如，碰巧的是，你非常擅长 GPU 部署和 VMware 优化，最终成为了让你在自动补全方面做得非常出色的原因，因为它比其他产品更快，对吧？所以这方面有所叠加。还有你为企业构建所有这些插件，并且非常擅长读取大型代码库的方面。你做了一些反主流的事情。有很多产品，我们和 OC 公司合作，很多代码生成工具使用向量数据库，因为我们与很多公司合作，那是很多人的标准构建方法。但你们做了一些非常不同的事情，对吧？

Varun Mohan: 是的，所以其中一件，呃，我认为变得非常流行的事情是，“RAG”（Retrieval-Augmented Generation，检索增强生成）这个术语变得非常流行。

主持人: 你们不是反 RAG 吗？

Varun Mohan: 是的，我不知道我们是不是反 RAG。RAG 显然是有道理的，你确实想要检索一些东西，然后基于检索结果生成一些东西。所以我猜这个想法是正确的，即一切都是检索增强生成。但我认为人们可能有点过于固执己见的是，RAG 的实现方式必须是通过向量数据库去搜索。我认为向量数据库是工具箱中的一个工具，对吧？如果你思考用户最终想要什么，他们想要很棒的答案和很棒的 Agent。这就是他们真正想要的。那你最终如何做到这一点？你需要确保上下文中的内容尽可能相关。所以我们最终做的是拥有一系列系统，使我们能够用最相关的代码片段填充上下文。我们最终实现这一点的方式是，它是关键字搜索、RAG、抽象语法树（AST）解析的组合，然后在此之上，利用我们拥有的所有 GPU 基础设施，获取代码库的大块内容，并在查询进入时实时对其进行排序，对吧？我们发现，这是我们为用户找到最佳上下文的最佳方式。这样做的动机是因为人们会有各种奇怪的问题。他们可能会对一个大型代码库提出问题，比如“将这个 API 的所有版本升级到那个 API”。如果嵌入搜索只找到了 10 个中的 5 个，那在那个时候就不是一个非常有用的功能了。所以我们需要确保精确率（precision）和召回率（recall）尽可能高，这意味着我们使用了一系列技术来真正达到最佳解决方案。

主持人: 很多 AI 初创公司在构建时，对于什么对问题领域有效，采取了太多的智力捷径。但你们是从第一性原理出发的，对吧？所以你们构建了一个更复杂的系统，做了所有这些解析等等，这很酷。

Varun Mohan: 是的，我想也许其中一个可能有趣的讨论点是，我们公司很多人最初是做自动驾驶的。这之所以重要，是因为那些系统你不能随便应付，也就是说，你不能只是构建了软件然后就让它运行。你需要非常好的评估体系。我认为在公司，我们不追求复杂性，我们追求的是有效性。那么问题来了，为什么现在的系统复杂得多？那是因为我们构建了非常好的评估系统。

主持人: 你们开发的有多少是基本上由提高评估分数驱动的，相对于基本上是基于“感觉”的——你们自己都在用 Windsurf，你们一直从用户那里得到反馈，然后你们就感觉这个东西会更好用，而评估只是某种检查，确保你们没有搞砸别的东西？

Varun Mohan: 两者兼而有之，但显然对于某些类型的系统，我认为评估比感觉更重要，或者说比感觉更容易。仅仅因为对于那个基本上获取代码库的大块内容，将其分块，并并行传递给数百个 GPU，在一秒内给你结果的系统，很难凭直觉判断“这是否好得多”，因为那是一个非常复杂的检索问题。但另一方面，从感觉的角度来看，有很多更容易的事情是有价值的。如果我们看看代码库中打开的文件会怎么样？这实际上是一个更难评估的事情，因为在评估时，你不知道用户实时在做什么。这是拥有产品和市场对我们帮助很大的情况之一，对吧？我们能够利用大量关于人们如何使用产品的用户数据来积极地使产品变得更好。所以那可能是从感觉开始，然后之后你可以建立评估，对吧？所以基本上是两者兼而有之。

主持人: 互联网上有很多关于“Vibe Code”只适用于玩具应用的讨论。Windsurf 实际上被用于真实的、生产环境的大型代码库。你能告诉我们高级用户是如何将其用于更硬核的工程开发的吗？

Varun Mohan: 这是个有趣的事情，我们公司很多人，我不是说这很普遍，并没有像世界上其他很多人那样从 ChatGPT 中获得巨大的价值。这并不是因为 ChatGPT 不是一个有用的产品，我认为 ChatGPT 是一个非常有用的产品。这实际上是因为他们中的许多人当时已经在使用像 Stack Overflow 这样的东西了。对于你想问的那类问题，Stack Overflow 是比 ChatGPT 更差的版本，但这只是他们已经知道如何使用的东西，对吧？所以他们能够做到不那么依赖聊天。但基本上发生的是，最近随着 Agents 的出现，Agent 随着时间的推移正在进行越来越大规模的更改。我认为我们公司的开发者现在所做的是，他们感受到了这个产品的起伏，也就是说，如果你提供的意图不够，它实际上会去更改比你实际需要的多得多的代码，对吧？这是目前这个工具的一个真正的问题。但他们理解了这些起伏，现在他们第一次遇到任务时，会将其放入 Windsurf。他们的第一反应不是去编辑器里输入，而是实际输入意图并进行那些更改。而且他们现在正在做一些非常有趣的事情，比如将我们的软件部署到我们的服务器，现在是通过完全在 Windsurf 内部构建的工作流来完成的。所以我们公司内部很多样板和重复性任务已经被完全消除了。但这之所以可能，某种程度上是因为我们能够在一个拥有数百万行代码的代码库上非常非常有效地操作。

主持人: 如果你要给观众一些建议，使用 Windsurf 的用户应该如何正确地提供这种意图，以便更改更加精确？因为你说的 Agent 造成所有这些广泛更改的情况我见过，但你如何获得那些精确的更改？你该怎么做？你如何向系统提供信息？你如何用全大写字母对它喊叫，对吧？

Varun Mohan: 是的，嗯，不，所以我认为这是那种情况，呃，我认为你需要对系统有一点信心，让它稍微出点错，这有点吓人。因为我认为大多数人会很快就否定这些工具。显然，我们公司的任何人都不会否定这个工具，因为他们自己就在构建这些工具。我认为人们的期望非常高，也许这就是我能给出的主要反馈，那就是，你知道，我们的产品对于这些越来越大的更改，它可能会正确地完成 90% 的更改，但如果 10% 是错的，人们就会完全否定整个工具。我认为在那时，可能正确的做法是要么撤销更改——我们有能力实际撤销更改——要么就继续前进，看看它最终能走向何方。也许最重要的方面是尽可能频繁地提交你的代码。我想那也许是最大的建议，那就是，你知道，你不想陷入一种情况，你做了 20 个更改，在此之上又自己做了一些更改，然后你无法撤销它，最后你变得非常沮丧。

主持人: 在这个思路下，我一直在想，我们是否需要改变 Git 在这种 AI 编码范式下的工作方式？你有没有想过，一直做 git commit 是否是正确的做法，或者是否需要进行更深层次的基础设施变革？

Varun Mohan: 是的，我想我们有。所以我们一直思考的一件事是，未来你将有许多许多 Agent 在你的代码库上并行运行。这会带来一些权衡，对吧？如果你有两个 Agent 同时修改同一段代码，就很难知道到底发生了什么。另一件事是，很难同时检出多个分支，让不同的 Agent 独立地在上面工作。

主持人: 所有的合并冲突，哦天哪。

Varun Mohan: 是的，有很多。但是，嘿，你知道，真正的软件开发也是这样运作的。当有很多工程师在一个代码库上操作时，他们都在同时摆弄代码库。所以这并不是一个非常独特的事情。我认为 Git 是一个很棒的工具。我想这可能是一个问题，比如你如何包装 Git，让它以一种适用于这个产品界面的方式工作。一个例子是，Git 有叫做 worktrees 的东西，就是你可以在同一个目录下拥有多个工作树和仓库的版本。也许你可以让许多这样的 Agent 在不同的 worktrees 上工作。或者，与其向你暴露分支概念，你实际上可以自己维护一个分支，然后可以重复地将其应用到用户的主分支上。我们在公司思考为什么我们认为我们的 Agent 非常好的一点是，我们试图对发生的一切有一个统一的时间线。这个统一的时间线不仅仅是开发者做了什么，实际上是开发者所做的加上 Agent 所做的。所以实际上我们的产品，如果你最终在编辑器里做事，如果你最终在终端里做事，对吧，所有这些事情都被捕获了，并且意图实际上是以一种方式被跟踪的，当你使用 AI 时，AI 在那种情况下是知道的。所以在某些方面，我们喜欢这样，Agent 不是在一个完全不同的时间线上操作，而是像某种东西以相当高的频率被合并进来。所以我认为这是一个悬而未决的问题。我不认为我们对此有确切的正确答案。

主持人: 你能设想 Windsurf 未来还有哪些其他的变化？它将如何演变？

Varun Mohan: 可能有很多人认为“Vibe Coding”只是一时的风尚，但我认为随着时间的推移，它会变得越来越强大。我认为，每当我听到有人说“嘿，这对于这个复杂的用例行不通”时，感觉就像是勒德分子（Luddite）在说话，对吧？就像，如果你看看这些 AI 逐年进步的方式，那真是，真是惊人。我会给你举个例子，一个我一直珍视的例子，那就是，有一个叫做 AIME 的数学竞赛，我高中时参加过。我对自己的表现非常兴奋，我的最高分接近 14 分。

主持人: 那是非常高的分数了。

Varun Mohan: 是的，但是，但是疯狂的是，那是我认为“哦哇，AI 系统，它们不可能接近那么好”的事情之一。去年年初，它可能远低于 5 分。而现在，你知道，OpenAI 公布的平均分，对于 O4 mini 来说，已经达到 14.5 到 15 分了。所以几乎就像你必须不断地推演下去，对吧？它会变得疯狂。基本上，软件开发生命周期的每一个部分，无论是编写代码、审查代码、测试代码、调试代码、设计代码，AI 都将很快增加 $10 \times$ 的杠杆作用。这会比人们想象的快得多得多地发生。

主持人: 回到你现在的工程团队，我很好奇，如果他们从处理版本升级和无聊的样板代码中解放出来，节省了所有这些时间，他们会把额外的时间花在什么上？

Varun Mohan: 关于我们公司以及可能每一家在这个领域构建的初创公司的一件事是，技术能够达到的上限非常非常高。所以实际上，如果开发者可以花更少的时间做样板工作，他们就可以花更多的时间测试他们不确定是否有效的假设，对吧？在某些方面，工程变得更像是一种研究型的文化，对吧？在那里你可以非常非常快速地测试假设。但这需要很高的周期时间，对吧？你需要去实现东西，你需要构建评估，你需要和我们的用户一起测试。但这些才是真正让产品变得更好的东西。

主持人: 这是否意味着你未来会招聘不同类型的工程师？比如你在寻找不同的特质？

Varun Mohan: 是的，我认为对于我们招聘的工程师，我们希望寻找具有非常高能动性（agency）、愿意犯错、并且大胆的人。但是，你知道，奇怪的是，我不知道这对初创公司来说是否有所改变，对吧？初创公司永远不应该招聘那些加入公司的原因是为了非常快速地编写样板代码的人，对吧？因为在某种意义上，我不想，你知道，这不是目标，但即使初创公司的代码极其丑陋，它也可以成功，对吧？这通常不是初创公司失败的原因。

主持人: 听起来像我的初创公司。

Varun Mohan: 是啊，是啊，完全正确。那通常不是初创公司失败的原因。初创公司失败的原因是他们没有为用户构建一个具有差异化优势的好产品。那才是他们最终失败的原因。

主持人: 这些都对，但现实中你也总是需要某种“工作母机”来完成某些事情。我觉得在过去，这就像是构建安卓应用。你雇人来做，因为很少有人愿意主动去做。也许在你的工程愿景中，你不再需要那些了，那在组织中不再是一个有用的技能，因为 AI 就像你无限的工作母机。这样说公平吗？

Varun Mohan: 是的，也许软件中那些非常小众、除了少数人之外很多人都不愿意做的方面，这些事情会被更广泛地民主化，除非它具有很大的深度，对吧？至少目前是这样。是的，如果某件事是，“嘿，我们需要更改一个系统以使用新版本”，并且过去总有一个人深入研究版本更改的细节，我不认为公司内部会有人只专注于那个，对吧？

主持人: 你们如何面试人选呢？

Varun Mohan: 是的，我认为我们有一个相当严格和高的技术门槛。这结合了，我们进行的面试实际上允许人们使用 AI 来解决问题，因为我们想验证人们是否讨厌这些工具。仍然有一些开发者确实讨厌，显然如果你讨厌，我们可能不是你适合工作的公司。但与此同时，我们确实有现场面试，在现场我们不给他们 AI，我们想看他们思考，对吧？如果最终有人需要写一个嵌套的 for 循环却需要求助于 ChatGPT，那将是一件坏事，对吧？而且我不是说，这从根本上是因为，因为它只是感觉，那是衡量问题解决能力的一个很好的指标。我认为问题解决能力，在宏观层面上，仍然应该被高度重视。那是人类拥有的宝贵技能。

主持人: 我们交谈过的很多公司，甚至我们自己都遇到的一个挑战是，Windsurf 变得太好了，以至于如果你给人们 Windsurf，甚至很难想出一个 Windsurf 不能一击即中的面试问题。你知道，任何人都可以做到，因为你只需将问题复制粘贴到 Windsurf 中然后按回车键。所以在那时你并没有真正评估任何东西。

Varun Mohan: 我实际上认为那是真的，而且，而且你完全正确。现在像 O4 mini 这样的模型无法解决的问题已经很少了，对吧？我的意思是，如果你看看竞争性编程，它在这方面已经遥遥领先了。疯狂的是，面试本质上将是某种孤立的问题，对吧？它们本质上是孤立的，因为如果问题实际上需要如此多的理解才能完成，你就无法解释清楚问题。所以这对于 LLM 来说是完美的，你给它们一个孤立的问题，在那里你可以非常快速地测试和运行代码。所以是的，你完全正确。就像我认为如果你只进行算法面试，并且让人们使用 AI，我不知道，你那时并没有真正测试任何东西。

主持人: 这是否意味着你们已经不再仅仅是算法问题，而是问一些不同的、更难的、实际上非常适合能够使用 AI 来解决的问题？

Varun Mohan: 是的，我们显然有问题，既有系统设计方面的，也有算法相关的，但这些问题相当开放，对吧？可能没有一个正确的答案。你可以做出权衡。我认为我们想做的是看看人们在不同的权衡和约束条件下是如何思考的，对吧？我们在验证的是求知欲（intellectual curiosity），对吧？如果有人最终说“我不知道为什么”，那完全没关系，只要他们已经达到了我们觉得，嗯，某种程度上显示出兴趣和良好的问题解决能力的深度。如果这说得通的话。就像你能看出来一个人是否好奇，是否想学习东西，这是非常明显的。

主持人: 接下来的想法可能是反直觉的：你处于构建所有这些 AI 编码工具的最前沿，但这完全没有影响你的招聘计划。恰恰相反，你实际上需要更多的工程师来执行。给我们讲讲更多这方面的情况。

Varun Mohan: 所以我认为，我认为这归结为，我认为这个问题有一个非常高的上限，对吧？我们真正想做的事情还有很多很多。公司的使命是将构建技术和应用程序所需的时间减少 $99\%$。要做到这一点需要大量的工作。诚然，我们公司里的每个人都比一年前效率高得多。但我认为我们要去完成这个目标，你知道，这是一项艰巨的任务。我们需要开始更多地关注开发体验的其他方面，对吧？现在我们在代码编写过程以及代码导航过程方面提供了很多帮助。但我们还没有怎么触及设计过程、部署过程。调试过程目前还相当初级，对吧？有太多不同的部分了。如果我来看的话，你知道，如果你说你有 100 个单位的时间，你知道，我们有一把斧头，我们可能在那段时间里砍掉了大概 40 或 50 个单位。但还有很多小块我们需要砍掉，基本上就是这样。

主持人: 确实感觉当我使用 Windsurf 时，我常常是不同技术之间那个极其缓慢的桥梁，在我的……之间来回复制粘贴数据。

Varun Mohan: 那可能实际上仍然占据了你时间的很大一部分。

主持人: 所有的部分都变得如此之快，以至于现在就像是它们之间的粘合剂，但我就是那个粘合剂，而且我慢得多。

主持人: 我能不按常理出牌问个奇怪的问题吗？

Varun Mohan: 问吧。

主持人: 好吧，其中一件事，我的意思是，我认为我们团队的 Pete，他刚刚发表了一篇很棒的文章，关于提示（prompting），以及你应该让用户能够访问系统提示。他提出的另一件事，我们在 YC 内部一直在使用的，是一个新的 Agent 基础设施，可以直接读取我们的记录系统，我们的 PostgreSQL 数据库。在使用这个过程中，我们开始意识到，如果代码生成变得更好——基于这次对话，我想我们可以指望它从现在开始好上 $10 \times$ $100 \times$——那么，如果不是构建打包软件，而是出现“Just-in-Time”（即时）软件，Agent 基本上在你需要时就为你构建好了。这会改变软件和 SaaS 的本质吗？我们所有人和 Windsurf 会怎么样？

Varun Mohan: 我不知道。我认为仅仅是“开发者”这个概念，很可能会扩展到所谓的“构建者”，嗯，我认为每个人都将成为构建者。他们可以决定，你知道，他们想在构建事物方面走多深。也许我们当前版本的开发者可以走得足够深，以至于他们可以在短期内构建更复杂的东西，对吧？但是，是的，我认为软件将成为这种非常非常民主化的东西，对吧？我设想这样一个未来，你知道，当你问 AI 助手“嘿，给我构建一个跟踪我卡路里摄入量的东西”时，实际上会发生什么？为什么你会有一个非常定制的应用去做这个？它可能是一个获取你 AR 眼镜等所有输入的东西，并有一个定制的软件，它会生成出来，就像一个应用程序在那里，它有任务告诉你，你知道，你摄入的所有卡路里是否在计划内。我认为那是一个非常非常定制化的、你自己拥有的、可以不断调整的软件。我可以想象那样一个未来，实际上每个人都在构建，但人们不知道他们构建的是软件，他们只是在构建，只是在构建他们自己拥有的能力和技术。

主持人: 有多少完全不懂写代码的人在使用 Windsurf？

Varun Mohan: 实际上我们有相当大一部分用户是这样的。

主持人: 有意思。

Varun Mohan: 是的。

主持人: 他们是怎么开始用 Windsurf 的？是他们在某个公司工作，某个程序员向他们展示了如何使用吗？我倾向于认为 Windsurf 更多地是针对专业开发者市场，他们将此作为新的超能力，而不是像 Gary 提到的那样针对非技术用户市场。

Varun Mohan: 我们对此也感到震惊，因为我们当时想：“嘿，我们的产品是一个 IDE。”但实际上有相当一部分开发者从未打开过编辑器，他们只是，你知道我们的 Agent 叫 Cascade，对吧？他们就只活在 Cascade 里。我们有浏览器预览，所以他们就打开浏览器预览，他们可以点击东西并进行更改。好处是，因为我们某种程度上理解代码，当他们回到仓库时，代码实际上已经变得相当复杂了，我们实际上能够从开发者离开的地方，或者说那个构建者离开的地方继续下去。我会说我们还没有为那个用例进行大量优化，但实际上那里发生的事情有多么多，真是有点疯狂。

主持人: 你认为从长远来看，这最终会成为一个针对这两个受众的产品，还是你认为实际上会有不同的产品针对不同的受众？比如有一个 Windsurf，专注于那些想要看到代码并深入细节的严肃开发者，然后可能有其他产品，针对那些完全非技术、甚至不想看到代码的人？

Varun Mohan: 我不知道长期会是什么样子。有种感觉告诉我它会变得更加统一。但我要说的一件事是，就像作为一家初创公司，对我们来说，即使我们确实有，你知道，相当数量的人，我们在内部能够专注的事情也是有限的。所以对我们来说，我们不会专注于如何为开发者构建最佳体验，同时又为非开发者构建我们拥有如此多东西的体验。但我不得不想象，这种构建技术的想法，随着你越来越擅长理解代码，你将能够为非开发者提供很棒的体验。但我不知道路径依赖会是怎样。我假设这个领域的一些公司会从非开发者开始，然后支持编辑代码的能力，对吧？我认为我们已经开始看到这种情况，界限正在变得模糊。

主持人: 你可能至少为了你的评估而关心它。

Varun Mohan: 是的，不，你需要为了你的评估而关心它。也许这对我来说是困难的部分，去想象对于纯粹的非开发者产品，如果你不理解代码，你在攀登的山峰是什么？你如何知道你的产品在变得越来越好？这像是一个悬而未决的问题。你是否完全依赖于基础模型变得更好？这没问题，但那你应该想象你的产品只是基础模型之上的一个极其薄的层，那是一个令人恐惧的处境，对吧？这意味着你将在所有不同的轴心上受到竞争。

主持人: 你总体上如何看待这个问题，我猜就像我们在这个播客上经常讨论的，就是 GPT 包装器（GPT wrapper）的迷因…

Varun Mohan: 嗯…

主持人: 我感觉已经完全消失了。尽管每次大模型实验室发布重大更新时都会让它稍微回来一点，每个人都有点害怕，就像，你知道，OpenAI 会吞噬一切。你如何看待这个问题？

Varun Mohan: 我认为我看待这个问题的方式是，是的，公司，正如我之前提到的，它是一个移动的目标。也就是说，今天如果我们生成了所有提交软件的 80%、90%，是的，我想当新模型出来时，我们需要提升我们的水平。我们不能停留在同一个阶段。也许我们需要生成所有提交代码的 95%。我认为我们的机会在于基础模型的能力和 $100\%$ 之间的差距，对吧？只要我们能继续提供一种体验，两者之间存在差距——我认为只要体验中还有任何人在回路中，就存在差距——我们就能够去构建东西。但这对于我们来说是一个不断变化的目标，对吧？所以你可以想象，当一个新模型出来时，也许基础模型本身提供的基线水平翻了一番，我们在基础模型之上提供的 Alpha（超额价值）也需要翻一番。对我来说，这感觉非常，嗯，这不最令人担忧的原因是，假设你采用基础模型，它提供了 $90\%$ 的效率，它将所需时间减少了 $90\%$。这实际上意味着，如果我们能再提供一两个百分点的改进，那就是在新的基线基础上增加了 $20\%$ 的收益，对吧？就像我猜 $90\%$ 如果变成 $92\%$ 或 $93\%$，嗯，那仍然是非常非常有价值的，对吧？在那个时候。因为实际上 $90\%$ 成为了每个人的新基线。所以我认为基本上我们运作的方式是，我们如何尽可能多地提供额外的价值。只要我们关注这一点，我认为我们会做得很好。

主持人: 对于我们那些在 AI 编码领域工作的初创公司，你有什么建议？你有很多这样的公司。你认为哪些机会将对新的初创公司开放？

Varun Mohan: 我看到很多我认为可能特别有趣的事情。我不认为我们真正采用了这些技术中的任何一个，但是在人们如何构建软件方面有太多不同的部分了。而且，我不会说小众（niche），但是有太多不同类型的工作负载了。我还没有真正看到这个领域有很多初创公司只是说：“我们把这一件事做得非常好。”嗯，比如，我给你举个例子，“我们把这类 Java 迁移做得非常好。”疯狂的是，如果你看看这个类别，人们在这上面花费的金额可能是数十亿甚至数百亿美元，每年都在做这些迁移。这是一个巨大的类别。

主持人: 从什么迁移到什么？

Varun Mohan: 比如，这实际上有点疯狂，JVM 7 到 8 或者…

主持人: Rails 版本…

Varun Mohan: 甚至比那更多。实际上是，很多很多公司写 COBOL，拥有 COBOL。疯狂的是，美国国税局（IRS）的大部分软件显然是用 COBOL 编写的。在 21 世纪初，他们试图从 COBOL 迁移到 Java。我认为那是一个超过 50 亿美元的项目。不出所料，它没有成功。

主持人: 你觉得他们现在能一击即中吗？

Varun Mohan: 我不知道他们是否能一击即中，我只是开玩笑。但是，不，但是想象一下，想象一下如果你能把那些任务做得非常好。这是一个经济价值如此之高的任务。我认为我们显然没有能力在公司内部专注于这类事情。如果你能在那里做得非常好，那是一个非常令人兴奋的领域。第二个关键点是，开发者做的很多事情也并不是在改进产品，但很重要，比如自动解决警报和软件中的错误。那也是一个巨大巨大的开销。我很好奇想看看那个类别中一流的产品实际上是什么样子。我敢肯定，如果有人真正深入研究那个领域，他们可以构建一个很棒的产品。但是，但是我想我还没有听说过哪个产品取得了巨大的成功。

主持人: 我认为这实际上都是非常棒的见解。我喜欢它们的一点是，这不仅仅是给两家初创公司的机会，它们中的每一个都像是一个可以容纳一百家大公司的桶。

Varun Mohan: 我们实际上确实有一家来自 S21 的公司叫做 Bloop，他们用 Agents 来做这些 COBOL 到 Java 的迁移。

主持人: 太棒了。

Varun Mohan: 这是个棘手的问题。

主持人: 这是个非常棘手的问题。但如果你去和任何存在超过 30 年的公司谈话，这可能每年花费他们数亿美元。

V. 核心经验与总结

主持人: 回顾这段旅程，我的意思是，我们都非常感谢你创造了 Windsurf。它正在为整个社会提供超能力。你会对那个，基本上是 5 年前的你，在你开始这一切之前，说些什么？

Varun Mohan: 我会说的最重要的事情是，要比你认为合理的快得多地改变你的想法，对吧？很容易一遍又一遍地爱上自己的想法。你也确实需要这样做，否则你真的什么也做不成。但是要尽可能快地转型（pivot），并将转型视为一种荣誉勋章。大多数人没有勇气改变他们对事情的想法，他们宁愿在做他们告诉所有人他们在做的事情上失败，也不愿改变主意，迈出大胆的一步并取得成功。

主持人: Varun，非常感谢你今天加入我们。

Varun Mohan: 谢谢。

主持人: 各位观众，我们下次再见。

要点回顾

I. 公司背景与关键转型

II. Codium/Windsurf 的产品开发与技术

III. 产品演进与市场拓展

IV. AI 编码的未来与行业思考

V. 核心经验与总结