OpenAI报价30亿，三个月实现收入翻倍，Windsurf做对了什么？

核心是让开发者更好「审」代码，

而不是写代码

主持人：Windsurf 究竟是什么？如何让大家更简单易懂地理解它？

Varun Mohan: 简而言之，Windsurf 是一个集成开发环境（IDE），旨在帮助开发者构建软件和应用。有意思的一点是，许多使用我们产品的用户可能并不清楚什么是 IDE，我们稍后再深入探讨。

那么，我们为什么要着手开发 Windsurf 呢？实际上，最开始我们计划构建这个产品时，很多人可能会问，为什么不直接在现有的 IDE（例如 Visual Studio Code）上进行开发呢？

简单来说，随着 AI 能力的持续增强，我们认为技术构建的方式将会发生根本性的改变。传统的纯文本编辑器已经不足以满足未来的需求了。过去，开发者在 IDE 中编写代码，IDE 提供一些基础反馈，比如「你的代码有 bug」或者「编译错误」，仅此而已。然而，如今的 IDE 能够做的事情远不止这些。它可以自动化地修改大量的代码，甚至直接生成代码片段。

我们意识到，伴随 AI 技术的发展，AI 很可能会承担 90%甚至更多的代码编写工作。届时，开发者的角色将发生转变，更多地侧重于审查和调整 AI 生成的代码，而非从零开始编写。我们认为，基于这个新的 AI 时代背景，开发者的工作流程势必会发生变化。因此，我们在 Windsurf 中进行了一系列优化调整，旨在让开发者能够更高效地进行这些「审查」工作，这是我们开发这款产品的核心原因。

举个简单的例子，我们之前有一个代码自动补全功能，可以补全一小段代码。但是现在，我们在 Windsurf Tab 中引入了代码重构的功能，几乎可以实现内联式的重构。为了实现这一功能，我们在 Windsurf 中定制了一套用户界面。但在 VSCode 中，由于 API 限制，我们只能通过动态生成图片并将其放置在光标附近来展示代码修改。当我们将这一功能迁移到 Windsurf 平台，我们的采纳率就提升了三倍。

这极大地增强了我们的信心。我们深知，技术本身的先进性固然重要，但如果我们的用户无法充分利用我们的技术获取价值，那么我们就必须重新审视一个问题：「我们是否确实需要一套全新的界面和交互方式？」这就是 Windsurf 项目诞生的初衷。

主持人：所以，你们做出的重大战略决策，是基于这样的判断：虽然可以从一开始就在大家熟悉的现有 IDE 上开展工作，但最终发现这条路径存在局限性，「我们需要做一些突破性的事情，让用户愿意切换到一个全新的、能够带来更大效益的 IDE。」 我觉得这可能是很多人没有充分认识到的，说服开发者去尝试和采纳一个全新的工具，其风险是非常巨大的，毕竟对于工程师而言，这是一个非常重要的职业决定。

Varun Mohan: 确实如此。需要澄清的一点是，我们很多开发者用户目前仍然在使用 VS Code。同时，也有不少使用 Java、C++ 等语言的开发者，他们可能更倾向于 JetBrains 系列的 IDE，比如 IntelliJ。对于我们来说，我们未来仍会继续在这些主流平台上进行开发和维护。

但是，我们确实认为，像 VS Code 这样的一些主流 IDE，在用户界面方面限制了我们能够为客户提供的能力。尤其是 VS Code，它的 API 相对有限，无法很好地支持我们希望实现和展示的高级功能。

主持人：Windsurf 目前的增长情况如何？大家经常听到竞争对手公布各种令人惊叹的数据，请你分享一些 Windsurf 的相关数据。

Varun Mohan: 我们的产品发布至今大约四个月，在这段时间内，已经有超过一百万名开发者尝试了我们的产品。目前，我们的月活跃用户数达到了数十万。

03 

未来工程师的核心能力是去找到重要的问题

主持人：你认为未来几年内，软件编码的方式将发生怎样的变化？与现在相比，会有哪些不同？

Varun Mohan: 我认为我们可以将工程师的工作大致划分为三个层面：首先是确定「我应该解决什么问题？」，其次是思考「我应该如何解决它？」，最后才是实际的「解决它」这个执行过程。

在这个领域，大家应该越来越清晰地认识到，在解决问题的过程中，特别是那些「我知道怎么做」并直接付诸实践的任务，绝大部分甚至可能全部都将由 AI 来处理。事实上，随着 AI 对代码库的深入理解，它甚至能够协助解决「如何解决它」这个问题。

如果你能够深入理解一个组织的环境，并对代码库有透彻地了解，那么找到最佳解决方案的路径也会变得越来越明确。所以，我认为，未来工程师的角色将更加侧重于识别我们需要解决的最重要的商业问题是什么？我们的产品或应用需要具备哪些核心功能？然后基于这些判断，进行优先级排序，做出正确的技术决策，并最终将这些决策付诸实践。我认为工程师的工作正在朝这个方向发展。

那么，这是否意味着计算机科学变得不再必要了呢？我认为这个观点可能有些被夸大了。因为即使是如今开发全栈应用的工程师，在几年前，他们可能也学习过操作系统课程。理论上讲，他们并不会在日常工作中频繁地操作操作系统内核调度程序。但这些底层原理有助于他们理解为什么自己的应用运行缓慢以及帮助他们判断某些设计决策为何比其他的更具优势，这些知识让他们比其他工程师更具优势。

我认为，理解底层原理能够让一位优秀的工程师变得更加卓越。但同样重要的是，AI 的发展也使得那些之前没有系统学习过这些底层知识的人，依然有机会构建出色的产品。这是当前发展带来的另一个显著变化。

此外，我们有很多更深远的计划，远不止于在 Windsurf 中进行简单的点击修改组件。其中一部分令人兴奋的功能就体现在 AI 的应用上。

我们有一套 AI 代码审查流程，就像我之前提到的那样。AI 当前的作用已经发生了显著变化，它现在不再仅仅是协助用户进行一些简单的修改，而是能够修改大量的代码。在这种新的工作模式下，开发者的核心职责就变成了审查 AI 生成的大部分代码。

如果我想修改其中的一部分，比如我不喜欢变量名叫做 title，我想把它改成 Title String，那么我可以直接进行修改。如果我希望进行这样的修改，只需指示 AI 继续执行即可。

有意思的地方在于，Windsurf 不仅了解 AI 完成了哪些操作，它也清楚用户进行了哪些修改。我们的目标是让整个过程像一个无缝的流式操作一样，用户执行的每一个步骤，AI 都能够感知并预测用户的意图。比如，AI 现在提示说：「我注意到接口属性 title 已经被更改为 Title String。」 然后它会自动去修改代码库中所有使用了 title 的地方，将其更新为 Title String。

因此，即使我作为一名开发者，想要进行一些细微的修改，AI 也能够在我的操作路径上快速地完成这些更改。试想一下，如果你需要进行一次代码重构或迁移，而只需修改代码的某一部分，你只需要告诉 AI 继续执行，其余的工作它都会自动完成。而且由于 AI 对整个代码库有深入的理解，它能够精准地找到所有需要修改的位置并完成相应的操作。

当然，现在当我重新加载应用时，应用程序没有任何错误，依然能够正常运行和加载。我甚至可以指示它执行一些更有趣的任务，比如让这个应用变得「复古」。虽然我也不太确定「复古」具体意味着什么，但我可以尝试一下。它就会根据我的要求做出相应的修改。

总之，AI 不仅能够在应用程序的层面进行操作，还能深入到用户的代码空间中进行修改，从而弥合了应用层面和代码层面之间的差距。这使得 Windsurf 不仅能够帮助那些完全不了解编程的用户构建应用程序，也能为开发者，特别是那些仍然习惯于亲手编写代码的开发者提供极大的帮助。

04

差异化优势：

能处理百万行的代码库

主持人：Windsurf 与 Cursor 的主要区别在哪里？你如何看待 Windsurf 在这个领域的长期竞争策略？

Varun Mohan: 我可以从几个方面来回答这个问题。在产品层面，我们投入了大量的精力来确保我们能够高质量地理解极其庞大的代码库，这是因为我们从公司成立初期就与像戴尔（Dell）、摩根大通（JPMorgan Chase）这样的大型企业展开了合作。以戴尔为例，其代码库的单个代码仓库可能就超过一亿行。因此，如何快速理解这些庞大代码库的内容并进行大规模的代码修改，是我们花费了大量时间攻克的难题。

为了实现这一目标，我们实际上构建了自己专属的模型，它能够并行处理大量的代码库，通过成千上万颗 GPU 对其进行分析，并对代码片段进行智能排序，从而精准识别出最关键的部分，以便能够对用户提出的任何关于代码库的问题作出响应。因此，我们凭借在基础设施领域的深厚积累，构建了大型分布式系统来支撑这项能力。这是 Windsurf 的一个核心差异化优势。

主持人：我觉得大家可能低估了这项技术的重要性。举个例子，我们之前曾邀请过 Bolt 和 Lovable 的创始人来访谈，他们的产品是从零开始构建的，这类工具可以为你编写全新的代码。

但是，如果是在像 Airbnb 或 Uber 这样的大型公司，你面对的是一个拥有数百万行代码的庞大代码库，要真正理解代码的结构、它的运行机制，以及在哪些地方进行修改而不会破坏现有系统，这无疑是一项极其艰巨的任务。所以，我理解你的意思是，Windsurf 的一个重要优势在于你们从一开始就解决了理解大型代码库这个核心问题，而 Cursor 等其他竞争对手则在逐步追赶这一能力。

Varun Mohan: 完全正确。这确实是我们投入了大量时间精力的一个关键领域，即深入理解代码库的实际运作方式。此外，我们特别关注的另一个重点是代码库中所有与用户交互相关的部分。

Varun Mohan: 第二个关键区别在于，我们并不仅仅局限于提供像 Windsurf 这样的单一工具，实际上我们非常重视并大力支持像 JetBrains 系列这样的集成开发环境（IDE）。JetBrains 和 IntelliJ 的用户群体覆盖了大约 70% 到 80% 的 Java 开发者，我们认为没有必要去构建一个与 JetBrains 直接竞争的产品，因为 JetBrains 本身具有非常好的可扩展性。相比之下，VSCode 在这方面的表现则相对不足。

对我们而言，我们的目标不仅仅是满足那些愿意切换到我们 Windsurf IDE 的用户，而是希望能够为每一位开发者提供一种灵活多样的使用体验。这意味着，即使 Java 开发者仍然习惯使用 JetBrains，我们也愿意提供全面的支持。

我们与许多大型企业建立了合作关系，在这些企业中，拥有超过 10,000 名开发者，其中超过 50% 的开发者使用 JetBrains。这是一个非常庞大的市场群体。而且，JetBrains 本身是一家年收入过亿的私营公司，这说明其市场份额和影响力是巨大的。这是另一个关键点，我们希望开发者能够在他们最熟悉、最习惯的平台上进行工作，并且能够无缝地融入他们的现有工作流程。

主持人：我理解你的意思，你们并非强制要求开发者适应新的平台，而是提供一种更灵活的解决方案，让他们可以在自己偏好的工具中也能充分利用 Windsurf 的能力。

Varun Mohan: 是的。第三个关键点，尤其是对于企业客户而言，我们支持许多对安全性要求极高的环境。我们已经获得了 FedRAMP 认证，这意味着我们可以为大型政府机构提供服务。此外，我们还提供混合模式的产品部署，这意味着所有的代码索引和存储实际上都可以部署在客户的本地租户环境中。对于许多公司来说，代码是其最重要的知识产权之一，因此数据安全和隐私保护至关重要。

从大型企业的角度来看，我们多年来积累的经验和处理过的复杂问题，使我们能够提供符合他们严苛要求的企业级产品和服务。这部分能力也是我们在早期进入市场时积累的历史经验所带来的独特优势。

05 

Claude 负责规划，

多模型配合执行

主持人：Windsurf 使用的模型是 Sonnet 吗？

Varun Mohan: 是的。我们的系统使用一个「规划模型」。目前来看，Anthropic 的 Claude-Sonnet 是一个非常优秀的规划模型，同时 OpenAI 的 GPT-4 模型的能力也不错。「规划模型」负责高层次规划，同时我们在内部运行其他必要的模型来执行高质量的检索和具体操作。处理上亿行代码的代码库并发送给通用大模型是不现实的，因为技术上（token 限制）、成本和延迟都不允许。因此，我们在内部构建并训练了定制模型，在开源基础上优化，它们能快速高效地修改代码库，在更多代码上下文中做决策，相比通用模型有明显优势。我们的策略是：在必要的地方构建和训练自己的模型，在通用模型表现更好的地方则直接集成使用。

主持人：你们自己训练的那些模型，是基于其他机构发布的开源模型吗？

Varun Mohan: 是的，部分基于开源模型。但负责检索、代码自动补全和代码编辑等核心功能的部分模型完全是我们内部独立训练的，我们专注于最擅长的领域并做到极致。

主持人：这个问题可能有点偏技术，你们在训练模型时，是否有任何特别之处或独特的方法？

Varun Mohan:一个特别之处在于我们从用户那里获取了极其丰富的数据，包括用户偏好和实时操作反馈（例如接受或拒绝自动补全、保存修改等）。特别是用户在编写代码时的「进行中」代码数据，这与互联网上的已完成代码不同，这使我们能训练出在代码不完整状态下依然能准确补全和修改的模型，这是通用模型不常处理的情况。我们擅长处理复杂中间状态的代码库，并且通过用户行为数据理解代码演变模式。

主持人：这也成为了在这个领域最终能够胜出的公司的一个重要竞争优势。如果你们处于领先地位，就能够比其他竞争对手收集到更多、更独特的数据。

Varun Mohan: 是的，能够深入理解代码库是关键，否则能力停留在表层，很难建立差异化竞争优势。

主持人：你这里指的是作为一家公司而言吗？

Varun Mohan: 对，作为一家公司。

主持人：那作为一个用户而言呢？

Varun Mohan: 我感觉这个领域的竞争会非常激烈，最终不同产品的区分度可能体现在能否持续地保持领先优势。

主持人：因为如果他们只是简单地在 Sonnet 的基础上进行一些包装或二次开发，其能力与其他的 Sonnet 封装器相差无几，那就没有明显的差异化，也缺乏坚实的竞争壁垒。

Varun Mohan: 这取决于具体应用，如果是处理非常基础的网页元素，可能直接使用前沿通用模型就足够了。

主持人：另外，我认为对于大家理解 Windsurf 非常重要。你此前提到过在 Windsurf 中，你需要从一个已有的基础代码库开始，而不是将其视为一个完全抽象的「从零到一」的应用构建工具。它实际上是一个集成开发环境，你在其中进行代码编写，需要安装依赖库。

Varun Mohan: 对，这一点很重要。许多开发者偏好本地开发环境，尤其处理需要本地系统依赖（如 GPU 驱动）的复杂应用时。对此，我们提供这种灵活性，允许开发者在习惯的环境中工作。本地开发和基于 IDE 的模式已存在几十年，未来几年也不会消失。

06

关键的决策，

要为 6 个月后做准备

主持人：在打造 Windsurf 的过程中，或者在 AI 行业摸爬滚打的过程中，你学到的最反直觉的一件事是什么？

Varun Mohan: 我觉得有一件很有意思的事情是，大家在网络上对我们短期内取得的进展表现出极大的热情，比如我们每周发布的新功能，或者每隔几周进行的产品更新。

但实际上，我们公司内部的许多关键决策，都是在为未来三个月、六个月、甚至九个月后的发展做准备。我们公司的目标是，每隔 6 到 12 个月就对现有产品进行一次彻底的「自我革新」。每过 6 到 12 个月，我们现有的产品形态应该看起来有点落伍。

所以，这里就存在一个看似矛盾的现象：一方面，你希望在市场上有成熟的产品，能够逐步迭代，听取用户的反馈，持续改进。但另一方面，我们作为首批推出完整 IDE 产品的公司，是从颠覆性的产品革新方向出发的。

然而，如果我们不持续地进行自我颠覆和演进，那么现有产品的价值很快就会贬值，我们必须不断地重新证明自己的价值，可能需要我们在用户尚未明确提出需求的领域进行创新。因此，在公司内部，始终存在着一种矛盾：进行增量式改进感觉更安全，例如添加一个新按钮，或者用户反馈说「我希望这个下拉菜单能实现 X 功能」。但这些改进并非我们最终取胜的关键原因，它们只是一些基础功能，我们可以做也可以不做。

但最终决定我们能否取得成功的，是那些具有长远影响、甚至会颠覆现有产品形态的方向，这种矛盾很微妙。增量改进是重要的，同时也不能完全忽视用户的声音，因为用户是我们的基础。

主持人：这让我想起了最近一位播客嘉宾 Captions.AI 联合创始人 Gaurav Misra 的分享，说他们公司有两个路线图：一个是「真实路线图」，完全基于功能需求、用户反馈和数据来制定；另一个是「秘密路线图」，完全不考虑用户的直接反馈或数据，而是基于他们团队自身对技术趋势的判断和预测，大胆押注未来的发展方向。

Varun Mohan: 是的，没错。

主持人：Anthropic 的 Dario 曾预测，未来 90% 的代码将由 AI 编写。然而，你们公司现在却在大规模地招聘工程师。你认为是否会有一个临界点，届时你们对工程师的需求会显著减少？

Varun Mohan: 我认为核心的问题在于，通过增加更多的工程师，我们能否获得更大的边际价值提升？

首先，我需要澄清一点：即使 AI 能够编写 90%的代码，这并不意味着工程师的生产力将提高十倍。因为工程师的工作不仅仅局限于编写代码。他们还需要进行代码审查、测试、调试、系统设计、部署，甚至在代码库中进行导航和理解。工程师所做的工作内容非常广泛，不仅仅是简单的代码编写。

在并行计算领域有一个著名的法则，叫做 Amdahl 定律（Amdahl’s Law）。它的基本含义是，如果你的任务可以分解成不同的部分，其中一部分是串行的「关键路径」，那么即使你将可并行化的部分无限加速，整个任务的完成时间也存在一个上限，由那个串行的关键路径决定。简单来说，比如你完成一项任务总共需要 100 个时间单位，其中 30 个单位是用来写代码的。即使我能将这 30 个单位的时间缩短到 3 个单位，你最多也只能将总时间从 100 个单位减少到 73 个单位，整体效率提升最多是 27%。

所以，我们确实看到了生产力提高了 30%，甚至接近 40%。但从我们希望解决的目标来看，即便公司拥有 200 名工程师，可能仍然不足以实现。因此，问题的关键在于，每个工程师通过 AI 工具能够带来多少额外的生产力提升？

再举一个例子，如果你去看像摩根大通这样的大型金融机构，他们的首席信息官（CIO）每年在软件方面的预算高达 170 亿美元，拥有超过 5 万名工程师。如果你告诉她：「这些工程师现在能够构建更多技术了。」这才是 Windsurf 真正带来的价值。摩根大通或其他公司会进行这样的计算，即构建技术的投资回报率提高了。AI 技术提高了技术投资的回报率，意味着他们应该投入更多的资源，并且在短期内可能需要更多的工程师。这种情况并非适用于所有公司，确实有一些公司对技术的需求有限，或停留在某个发展瓶颈。但哪些对技术需求极为庞大的公司而言，「AI 赋能的工程师」意味着他们会继续招聘更多的工程师。

07 

「如果创始人都没法把产品卖出去，

又怎么指望销售去卖」

主持人：目前，你们的工程团队有多少人？

Varun Mohan: 目前我们公司大约有 160 名员工，工程团队有 50 多人。

主持人：除了工程团队，公司还有哪些规模较大的部门或职能？

Varun Mohan: 我们有市场团队。

主持人：你们起初像大多数初创公司一样，没有专门的销售团队。但后来你们意识到这是一个巨大的市场机会，并为此做出了显著的调整。现在，你们拥有一个规模相当大的销售和市场团队，这在你们公司的发展历程中是一个非常突出的特点。

Varun Mohan: 对，实际上这个决定我们在公司早期就做出了。大约在一年前我们就聘请了销售副总裁，而现在我们的市场团队已经超过 80 人了，这在公司内部是一个规模相当可观的职能部门。

在公司刚成立时，我们有一些天使投资人是具有丰富运营经验的市场销售专家。比如 Carlos Delatorre，他曾是 MongoDB 的首席营收官（CRO）。对我们而言，我们从未对企业销售或销售本身持负面看法。我认为这可能是技术型创始人常常存在的误解，他们可能觉得销售是流程中一个不必要的「坏」环节，一切都应该通过产品驱动实现增长。

我认为事情并非非黑即白，企业销售是非常重要的组成部分。但可能是因为当时我们是一家专注于 GPU 虚拟化的基础设施公司，所以我们早期从未招聘过销售人员，因为我自己就是负责销售产品的那个人。

回想起来，如果我自己都难以通过销售来获取增量收入，我不知道如何将这个流程规模化，如何将公司的收入从数百万推向数亿，甚至数十亿。所以，如果我自己都不清楚如何完成这项任务，又怎能招聘一名销售人员，期望他来做到呢？另一方面，到了 Codeium 这个发展阶段，许多大型企业很快就主动联系到我们。

在 2023 年年中，我们开始正式对外销售产品，并与多家企业同时开展了并行试点项目。很快我们就意识到，在这个领域需要建立一套针对大型企业客户的销售机制。因此，在 2023 年年底，我们就聘请了销售副总裁。随后，我们迅速扩大了销售团队的规模。对我们来说，如果你希望将产品销售给财富 500 强企业，仅仅依靠用户在线刷卡购买几乎是不可能实现的。

主持人：在团队结构、工程管理、产品设计等方面，你们是否有别于其他公司之处，或者尝试过哪些特别成功的方法，亦或是经历过哪些完全失败的尝试？

Varun Mohan: 我们公司内部有一个非常有意思的决策，那就是核心工程团队中没有设置纯粹的「产品经理」职位。这主要是因为我们的产品是专门为开发者群体打造的，而我们团队成员自己就是开发者。我们深信，我们作为开发者的直觉和经验对于产品的决策具有重要价值。如果我们的直觉不起作用，那么可能我们招聘的员工就不够匹配。所以从某种意义上讲，我们的开发者也在承担着一部分传统产品经理的角色。

但另一方面，对于企业级业务来说，我们确实与许多大型企业有合作，很多时候客户提出的需求是我们工程师自身难以直接体会的。「类似于需要 FedRAMP 认证」这类需求绝大多数都是由客户主动提出的。

因此，我们也有一部分员工正在向产品战略类角色进行转型，他们负责深入理解客户的需求，同时结合我们的技术能力，帮助我们构建出能够规模化应用的产品。所以，整体而言，我认为我们在组织结构方面是比较独特的，这主要归因于我们的产品面向开发者群体，并且许多产品决策是基于开发者的直觉进行的。此外，正如你所说，我们的工程团队结构也比较扁平化。我们奉行「两块披萨团队（Two-Pizza Team）」的原则，将团队规模控制在较小的范围内。因为我觉得如果团队规模过大，团队负责人就无法深入地了解技术细节。

而且，在这样一个技术发展日新月异的行业中，领导者如果不能深刻理解技术，并且不亲自参与实际的开发工作，这实际上是非常危险的。这也是我们做出的另一个重要决策，团队的灵活性非常高，如果我们决定某个项目的优先级发生了变化，我们会非常迅速地调整团队结构。这一点在我们公司是高度集中规划和执行的。

主持人：你刚才提到公司大约有 150 名员工，请问目前有多少位产品经理呢？

Varun Mohan: 在产品战略这个领域，我们目前有三个人担任这个角色。

主持人：我明白了。所以他们的正式头衔是「产品战略经理」，而非传统的「产品经理」？

Varun Mohan: 没错。

主持人：有意思。那么大概是 50 名工程师，80 多名销售人员，再加上其他部门？

Varun Mohan: 对的。我们还有一些其他职能部门，例如招聘、财务以及市场营销等。

08 

亲自去用，

了解模型的能力边界很重要

主持人：有没有一些试用 Windsurf 的小贴士，帮助用户更高效地利用这款工具？

Varun Mohan: 第一个建议是，用户需要保持一定的耐心，同时在发出指令时要尽量明确。当你让应用程序进行修改时，它可能会生成很多你不需要的或不相关的更改。防止这种情况发生的最好方法就是尽可能地具体和明确地描述你的需求。我建议用户在刚开始使用时，先从小的代码修改任务入手。如果你的项目包含一个非常大的目录，不要一开始就尝试让 Windsurf 重构整个目录，因为一旦出现偏差，可能会影响到二十多个文件。

从这个角度来看，用户会随着使用逐渐掌握产品的「能力边界」和「表现模式」。我喜欢用代码自动补全功能来做类比，当你使用代码自动补全功能时，有时它建议的内容可能只有 30%是你真正想要的，这听起来或许会让人觉得有些沮丧或不便。但实际上，并不会觉得特别烦人，因为你已经学会了如何筛选，知道在 70%的情况下你可以忽略它的建议。而当你采纳它的建议时，你清楚它能带来价值。而且，你还会提前预判，如果你输入的指令非常复杂，你会预期到「这次自动补全可能不会完全符合我的要求」。

所以，我认为这就像是需要理解和掌握产品的「高峰」和「低谷」一样。每隔三个月，产品的各项功能都会持续得到改进和重新评估，与之前相比会变得更加智能和好用。因此，我认为保持耐心和明确指令是用户在使用 Windsurf 初期需要掌握的两个关键技巧。

主持人：我觉得你刚才强调的一点非常重要，那就是用户需要花时间去了解模型的能力范围，例如需要提供多具体的指令，或者它能处理多抽象的任务。随着使用经验的积累，用户会逐渐建立起对模型能力的直觉判断。

结束之前，有没有什么最后想和听众分享的，或者有什么智慧之言？

Varun Mohan：说实话，我可以给出一些关于这个行业的预测，可能大部分都会错。我觉得最好的办法就是亲自去尝试这些工具，动手用这些产品。我觉得未来一年，会有大量的「alpha」机会，任何能最大限度利用这些工具的人都会领先一步。

想象一下，你的同事中有多少人甚至都不知道这些工具的存在，也不知道它们能做什么，这会让他们的工作效率大打折扣。尽可能快地动手去试，去用它们。

主持人：你说的「动手去试」，意思是下载 Windsurf，开始编程，要求它帮你构建东西吗？

Varun Mohan：对，构建应用。你甚至可以用它来制作原型、修改现有的代码库。你可能会成为团队里的倍增器，做出别人从没想到的贡献。想象一下，如果你是一个产品经理，能够快速地修改代码库并自己推动变更，那你可能会获得工程师们的极大尊重，也能做更多的事情。我觉得到那时，可以说，你几乎就没有上限了。