20VC

Z Highlights

敢于自我颠覆的公司能最早抓住新范式。初创公司成功不是因为做对很多事，而是因为把一件事做得非常好。每次转型之后做到“断舍离”，让整个组织完全投入到新方向中能大大提高成功概率，最终的成功足以覆盖其他所有失败成本。

留给初创公司最大的机会在于，构建需要非常高密度工程直觉的东西。开发者工具真正的壁垒在连续一整天、整个工作流中的体验，只有做过一线开发、对用户有高度同理心的团队才能做出来。大公司往往受到组织结构限制难以做到极致。

未来最成功的AI工具，一定是那些能动态调整人机边界的系统。用户并不是一直希望“全自动”或者“全手动”，而是希望在不同场景中，有不同层级的控制。Agent的判断力比模型本身的输出质量更难构建，但也更有价值。

Varun Mohan，初创公司Windsurf的联合创始人兼CEO。Windsurf专注于构建面向工程师的 code Agent系统，因被收购成为迄今AI领域规模最大的收购案之一而广受关注。本次访谈发布于2025年6月，由「20VC」节目的创始人Harry Stebbings主持，围绕AI产品构建、初创公司战略转型、Agent与IDE的融合趋势等核心议题展开。

初创公司战略：选择大于努力

Harry：Varun，我真的非常期待这次对话。我从Lee Marie、Neil Mehta和很多其他人那里都听到过关于你的好评。特别感谢你今天能来。

Varun：谢谢你邀请我，Harry。

Harry：你曾经说过，真正正确的想法几乎从不会在最初就出现。我想从这个话题开始问你：你后来是怎么重新理解“一个真正优秀的创意”到底是什么的？

Varun：Peter Thiel的那套理论还是有不少道理的，比如说创业一开始要选择一个不那么显而易见的方向。但问题在于，大多数“不显而易见”的想法其实本身就是坏主意。你走了一条非传统路线，并不等于你选的就是一个好主意，这一点很多人经常会忽略。

从更高的层面来说，如果你选择的是所有人都觉得理所当然的方向，那几乎可以肯定，这里面就没有什么“alpha”优势了。大公司会比你先一步入场，因为它们有更多的渠道资源和资金。

所以，初创公司通常要靠选择那些在大众看来“不太寻常”的方向来胜出。但同时，你也必须有足够的自知之明，明白你的那个“特别”的想法很可能其实并不是好想法。

从失败到突破：战略转型与快速成长

Harry：你们当时转向Windsurf时，你自己认为最“非典型”的认知或者见解是什么？

Varun：其实在这之前我们就已经做过一次转型。的第一版产品，连公司名字都已经换过两次了。最开始叫 Exafunction，当时在做GPU虚拟化技术，背后的逻辑是：未来的计算负载会越来越依赖GPU。这就是最初的使命。团队里很多人此前都在自动驾驶、AR/VR这些领域干过，当时团队还挺小的。

事实证明，我们在一个方向上是对的——GPU确实会变得越来越重要，我们判断NVIDIA会卖出大量GPU，这点没错。但错的是：低估了GPU工作负载的集中程度。我们以为市场上会涌现出很多不同结构的模型架构。但最后出现的情况是——几乎所有架构最终都趋同成了Transformer。在这样的技术格局下，作为基础设施提供方，几乎没有什么差异化优势可言。所以当时必须转型。但这就是市场的现实——有些东西在入局前你是很难知道的。最初的假设错了，因此只能放弃。有时候你会有一个“很特别”的视角，但市场走向可能完全不是你设想的那样。

Harry：完全认同。但问题是，很多人太执着于自己的“论断”。这也是我不太喜欢所谓“投资论断驱动型”投资人的原因之一。很多创业者都深深迷恋自己的想法，而他们从小到大听到的也是：真正能坚持到底、有韧性的创业者，才是最终胜出的人。但你在之前提到，“不要对自己的想法太上头”这点我很赞同。你怎么看这两者之间的张力？一边是坚定执念，另一边是理性抽离。

Varun：这其实是创业最难的部分之一。你必须同时在脑中持有两种看似矛盾的信念：一是非理性的乐观主义，如果你一点乐观都没有，那你可能连床都不愿意起，更别说创业了；二是毫不妥协的现实主义。你每天都得问自己一个问题：“我们存在的理由是什么？”如果答案是“不太清楚”，那你必须立刻改变方向，尽快带着整个公司转向。在创业领域有件很荒谬的事是：你不会因为坚持做错事而得到任何认可。或许你可以告诉同事、投资人或朋友说：“我还在做这件事。”但当你失败时，没有人会在意你坚持了多久。

Harry：那在今天这个阶段，你觉得自己现在还对哪一个想法“爱得太深”了？我可以举个例子：作为投资人，我自己非常痴迷于“投资组合构建的纪律性”。我喜欢那种通过精心组合来控制风险和机会的投资方式。但现实是，在当下这个时代，你必须打破很多规则。虽然我并不是在鼓吹盲目冒险，但的确需要比传统模式更具弹性。这就是我放不下的东西。那么你呢？

Varun：如果从经验主义角度讲，我们过去确实每一次都对自己的想法太过执着了。站在外面看，可能有人会觉得：“你们公司能多次转型，这是个积极信号。”但我自己其实一直在反思，为什么不能更早地做出转型？

比如说，从GPU虚拟化转型到做code AI产品，我现在都还会自责：明明早就看到了信号，却还是拖了三个月才下决心。当时合作的公司，大多数都是做自动驾驶的，正值“ZERP 时代”（零利率时代）最热。但到了2022年中，很多这类公司都无法继续融资，我们才开始意识到，市场在变，技术也在变，而我们的潜在客户似乎也撑不了太久了。我现在回头看，真希望早三个月动手。

Windsurf其实也是类似的情况。我们早就知道Agent会非常强大，其实完全可以更早开始做Windsurf。

Harry：我最近采访了Fiverr的CEO，他说这几年发生的一个巨大变化是——“time to clone”（被复制的时间）大幅缩短了。也就是说，一家新公司推出一项创新后，别人能在非常短的时间内复制出一模一样的东西。那么我想请教你，在这种情况下，“第一个做到”这件事到底还有多重要？

Varun：抢先一步主要带来两个作用。第一，它反映了你这家公司本身的运作方式；第二，它让你可以更快地从市场中学习。

让我先讲第一个。通常那些能率先进入新范式的公司，都是愿意自我颠覆的公司。他们的组织结构对变革非常开放，能快速在转弯处掉头。他们不断投资于非渐进式的技术，愿意打破原有的自我结构。这种特质对软件或code AI这样的快速变化行业来说尤为关键。

第二个方面是：抢先一步意味着你更早进入市场，可以更快地学习，这也使你更有可能成为下一个迭代的领导者。你会最早看到这个领域“尸体堆在哪里”——也就是说，你能率先看清哪些方向死得最快、哪些坑你踩过了、哪些方向值得坚持。

我自己特别喜欢想一个问题：如果我们能把产品更早地推向市场，在第一个月里，就能从用户那里学到什么？这些知识能不能帮助我们更快构建下一个版本？我相信，这种“学习优势”可以随着时间持续产生复利效应。

Harry：但换个角度看，看到别人先试错，不也挺好吗？你能观察他们哪里做错了，然后吸取教训，自己出手时就能避开那些坑，节省大量试错成本。

Varun：在软件领域问题在于：很多错误其实都发生在公司内部的研发环节，而外人是看不到的。公司内部现在有一种积累下来的“品类直觉”：有些想法连碰都不会碰，因为我们曾亲自尝试过，发现根本行不通。这种“失败的记忆”已经写入了公司基因。我们现在的创新，其实很多就是建立在这些历史试错的基础之上的。而这些东西，是你从外部观察一家公司的时候很难看出来的。

Harry：你们以前做过什么尝试，后来发现行不通，但外界并不知道的？

Varun：我们确实发布过这个产品的测试版，而且内部自用（dogfooding）了很长一段时间。我可以举几个例子。第一个例子是，去年推出过一个code review的测试版产品。当时试过很多种方式来交付这个code review产品。做过一个Chrome浏览器扩展、还在公司内部做过一个并行的网页版工具......在内部试了各种方案，但都感觉不够理想。而在几周前，最终发布了现在这个code review产品，它体验好得多，也真正提供了很高的价值。之所以以现在的方式发布，是因为吸取了去年所有失败尝试的教训。

我再举一个例子，是关于随Windsurf一起发布的code Agent产品。我们在去年年初就做过第一版，但那个版本的效果并不好。效果不佳的原因有很多。也正是因为那次失败，我们才得以回到最初的设计阶段，逐个修复那些关键要素，为最终发布Windsurf做好准备。其中包括：需要在code-based understanding上做到足够好，同时底层模型本身也必须变得更强。当模型的性能提升上来了，内部在code-based understanding上的研发也成熟了，这时候才真正准备好发布这个产品。所以这就是那种情况——如果只是等着别人把这个产品做出来，我们最终就得在多个维度上去追赶他们，才能把产品推出来。

Harry：你会建议创业者在早期尽可能多地融资吗？毕竟这本质上就是你能拥有的“试错次数”，实验的次数。如果你融得多，就能多试几次。基于你的经验，你会建议这么做吗？

Varun：我们确实是这么做的，稍微透露一下吧：我们在还在做GPU虚拟化项目的时候就完成了A轮融资，当时是Green Oaks主导的。

Harry：他们也是你的种子轮投资方？

Varun：是的，他们也投了我们的种子轮。至于他们是否应该在A轮继续投，我就留给观众自己判断了。但这确实给了我们一个重要的信心——哪怕转型了，我们依然有足够的资金去探索新的方向。

当时我们发布了Codium这个扩展产品，完全是免费开放的。之所以敢这么做，一方面是因为我们在基础设施方面有强大的技术积累，另一方面是公司账上还有足够的现金支持我们推出产品，不必在意短期收益上的细节。所以我认同你的观点，资金确实意味着你能尝试的次数更多。但前提是这家公司必须具备快速转向的能力。很多公司到了十人、十五人、二十人的阶段之后，就不再愿意完全推翻原有方向。但我们不一样。我和我的联合创始人是在一个周末决定要做Codium的，到了周一就把这个决定告诉了整个团队。那一天起，所有人都转去做Codium，尽管当时原来的业务已经有几百万美元的收入了。

Harry：那有没有什么结构性的做法，能帮助一个公司在转型后迅速反应、快速落地？

Varun：我一直坚信，在初创公司里，成功并不是因为你把很多事情都做得很好，而是因为你把某一件事做得非常好。就像我之前说的，要拥有一个真正好的点子，本身就是一种幸运。设想一下，有两家公司，每家都在做不同的产品，而每个产品的增长都是按指数曲线变化的，会有一个所谓的“R 值”。那作为初创公司，最正确的选择就是全力聚焦那个R值更高的产品。同时投入到两个产品中是完全不合理的，尤其当它们的增长曲线不在同一个数量级时。

所以每次转型之后，正确的做法就是果断放弃旧的方向。因为你之前做的那件事，很可能对接下来的新业务根本没有任何战略相关性——它的营收倍数、增长潜力都和新业务没法比。如果你能做到“断舍离”，让整个组织完全投入到新方向中，你的成功概率会大大提高。但这当然是一个令人恐惧的决定。你需要去告诉团队、投资人、客户：我们不会再继续做原来的那一套了。但一旦你下定决心了，其实执行起来会轻松很多。

Harry：当你已经在做几百万美元营收的时候，放弃原有业务等于自己吃掉自己的收入，这真的很难。所以我完全同意你的看法。你刚才说，成功其实是把一件事做到极致，而要做到这一点本身就已经够难了。那你们现在有没有什么其实很想去做的事，只是因为你们坚持专注，所以暂时没法做？

Varun：在我们所在的领域，注意到一个趋势：Windsurf的很多用户并不是专业程序员，而是那种“感受型编码”的用户，他们用Windsurf的工具在构建真正有用的应用。比如公司内部就有一位不是工程师的同事，他是负责合作伙伴关系的，他用Windsurf的产品自己搭建了一些应用，替代了过去内部采购的一些销售工具，总共节省了大约50万美元的开支。

Harry：所以他写代码帮你们节省了50万美元？

Varun：对，他自己搭建了公司内部用的系统，比如合作伙伴门户、报价工具等等。这些原本都是每年要花几十万美元购买的销售类SaaS工具。这其实也说明了一个现象——这些工具本身都很定制化，以前公司不会自己去开发这些内部工具。但现在，软件的开发成本大幅下降，尤其是那些“临时性”或者“轻量级”的软件变得极易构建，于是非技术人员也可以自己搭建出功能完备的应用。所以在Windsurf接下来的一个重要方向是：怎么让这类用户的生产效率变得更高？

但这中间始终存在一个张力——如果把重心更多地放在提升这类“非工程师用户”的体验上，那可能就会牺牲掉对真正开发者、尤其是处理大型代码库的工程师所能提供的深度支持。这终归还是一个聚焦与取舍的问题。

Harry：Windsurf的使命到底是要让工程师效率提升10倍，还是让普通人也能像工程师一样工作？

Varun：目前的重心是前者，也就是让专业工程师变得更高效。而后一种结果，是专注做好前者之后的自然衍生。因为底层的技术能力是具备的，它确实能够赋能非技术用户。但产品重点明确是放在如何提升开发者的生产力上。

Harry：那将来你们和Cursor会不会趋同？你们会逐步扩展到“可爱型工具”（lovables）和“低阶组件”（bolts）那一类用户？而那些工具也会反过来尝试走向你们所在的专业开发者方向？

Varun：这确实是我们常常被问到的问题。那些专注于“非开发者”用户的工具，比如lovables、bolts类产品，随着时间推移，确实会不断往更深的方向发展，加入越来越多的调节项、配置能力，提升可定制性。而对我们来说，如果能够真正深入理解代码，尤其是大型代码库，那么自然就能让非技术人员也构建出应用，且无需太多额外工作。

不过我想说的是，如果现在就去针对非技术用户构建产品，那就等于放弃了在帮助专业开发者方面所能做到的深度。所以我相信，最终这两个方向确实会趋同：一个真正理解你代码库的公司，最终可以只通过极少量的自然语言指令，就构建出一个和你现有代码逻辑一致的完整应用。

Harry：如果你现在有无限资源，有什么是你会用不同方式来做的吗？

Varun：我想我们会在公司内部尝试更多的项目，会做更多“下注”。就像我刚才提到的，现在公司内部尝试的产品方向中，大概有50%或更多其实是失败的。我们有大量的产品和技术研发是在为未来做准备，其中的大部分，最终都会失败。

但这也正是初创公司的一大特征：那个最终成功的方向，足以覆盖掉其他所有失败带来的成本。如果资源无限，我会让我们失败得更多——因为真正起作用的那个点，足以带来颠覆性的收益。

Harry：我之前和Neil Mehta聊过一些关于你的事，他说我一定要问你一个问题——你是怎么做产品的？你们的产品开发节奏是什么样的？你刚才提到内部项目失败率很高，那在你看来，有哪些不那么常规的产品构建方式，是你特别重视的？

Varun：外界有一种“常识”，认为一家工程师数量越多的公司，产品就做得越好。但这种看法有点把软件研发简化成了流水线工厂的逻辑。我真正认同的方式是：当一个想法还没验证、方向还不明确时，反而应该让非常少的人来负责它。

如果你把十个人投入到一个尚未被证明是否成立的项目里，每个人都会有自己的意见和想法，而在没有结果之前，这些意见都不能算错。这时候就很难达成一致，也很难让所有人朝着同一个方向推进，还可能会造成沟通混乱。更有效的方式是，找一小撮非常有主见的人，让他们去快速验证一个想法是否成立。

接下来问题就是：一旦你有了一个雏形，怎么判断是否应该继续投入？这个判断其实很难。不过公司有个经验教训，很多人之前在“硬科技”公司干过，比如做自动驾驶的。我们总结出一个经验是：当你真正有了一个好想法时，就算是初始版本、粗糙版本，也已经能体现出惊人的价值。

比如最早构建Windsurf里的Agent时，就算那个版本还很粗糙，它已经能做到很多过去八九个月以来我们从未实现过的事情。那一刻我们就知道：这个方向有潜力。当你确定了这个粗糙版本已经“有生命力”，那就是时候追加资源，把它推到更深的层面。

Harry：难怪Neil那么喜欢你。他常跟我聊“用户震撼体验”——就是那种第一次接触Agent的时候，被它的能力惊到的瞬间。我想深入问几个细节。你刚才说一开始只是“少数几个人”在做这些新项目，那具体是多少人？你在公司内部怎么组织这种“新方向”的项目团队？

Varun：大概就是三四个人左右。

Harry：那是几个工程师加一个设计师吗？

Varun：对，其实如果项目本身是纯粹的系统技术，可能就只是几位工程师在做。我们做的是开发者工具型产品，这有个优势：我们自己的工程师本身就是目标用户，他们在用 V0版本的过程中就会形成直觉，判断一个“粗糙但可用”的版本是否有潜力。

Harry：那预算和开发时间呢？是你设定的吗？还是由团队成员自己决定？

Varun：我们其实没太考虑过这件事。这部分可能是因为现在身处的是一个“非受限市场”——也就是说，如果你能开发出一项能加速软件开发的优秀技术，对客户的价值是巨大的。所以基本不会从“这个项目的预算是多少”的角度去评估事情。

但内部确实会关注一点：这个项目的进展如何？我们有没有在不断解锁新的进展？要不要决定把它搁置，去做别的？这不是一个民主决策过程，更多是公司内部的自上而下的判断。

Harry：有没有那种你们曾经搁置过、但事后回想其实应该坚持做下去的项目？

Varun：我们最早开发的autocomplete（代码自动补全）体验，就是Windsurf里的第一个产品。当时在打磨产品体验方面的进度其实拖慢了。而之所以体验不够好，其中一个主要原因是我们当时被绑定在VS Code里，它的UI扩展能力比较有限，导致没法实现更好的交互逻辑。

但后来开发了Windsurf，拥有了自己的编辑器后，就能在用户体验上投入得更多，最终也实现了真正想要的效果。

Harry：你刚刚提到VS Code，那让我想到一个话题——护城河（moat, 即企业在市场中的结构性竞争优势）和产品防御力。你觉得在AI的世界里，护城河是不是已经“死了”？大家经常说Cursor和Windsurf可以随时切换，我今天用你，明天换对方也没问题。那你怎么看？护城河真的不存在了吗？

Varun：对于初创公司来说，护城河这件事从一开始就有点“虚”。如果你读过《七种力量》（Seven Powers）这本书，里面有很多关于护城河的精彩理论。

Harry：我很喜欢那本书。

Varun：我也觉得它很好，但对于初创公司来说，那套理论很多时候还是太早了。比如说，就算你公司里有50个顶级工程师，全是最优秀的人才。团队已经非常强，大多数工程师来自MIT，甚至是MIT最顶尖的那一批。可即使如此，加起来你也只是拥有“数百工程人年”的产品积累。而在我们的领域里，其他人也完全可以从头搭建出类似的东西。

所以在这个赛道上，唯一真正的护城河就是——速度。就像我之前说的那样：你需要比别人更早知道“哪里有坑”，需要通过快速的学习，积累出持续性的优势。我常举的例子是NVIDIA。外界总觉得他们的护城河是CUDA，但我并不这么看。大型公司，比如 OpenAI、Anthropic、Google，他们自己都在造TPU、花几十亿美元投入芯片。你觉得如果CUDA不存在，他们就不用NVIDIA的GPU吗？当然会，他们可以直接写assembly，写底层汇编也会照样跑在NVIDIA的硬件上。因为这东西太值钱了，没得选。

人们选择NVIDIA，不是因为它的锁定机制，而是因为它真的做得好。它的低精度浮点运算能力非常强，芯片之间的interconnect也很强，整体运算速度快。而且它每年都有“倒计时炸弹”压在头上——如果下一代硬件在速度、内存带宽上跟不上，那它就会被AMD追上。你看，这种机制跟Google这种平台型公司的商业模式是完全不一样的。但NVIDIA依然成为了全球最有价值的科技公司之一。

Harry：我完全同意，尤其是在初创公司阶段，护城河确实比较虚。但如果你想象一下，有两家公司今天同时出发，其中一家公司被整合进一个巨头，比如OpenAI 或Anthropic，它们立刻就拥有了分发能力、品牌认知，还有能以超大规模购买芯片的资源。这种情况下，《七种力量》那一套理论是不是就又变得重要了？护城河又存在了？

Varun：，那种观点之所以没那么成立，是因为即便在那种情况下，“速度”仍然非常关键。你可以问问自己：为什么一家初创公司会在一个重要赛道里击败巨头？为什么2000年代初是Google赢了，而当时Microsoft明明已经是巨无霸了？归根到底，是因为这家公司有更深刻的洞察，而且能在战略执行上压倒对手。

Harry：但你不觉得在现在这个时代，分发比速度还重要吗？你可能做出一个特别好的产品，速度也很快，但如果 Anthropic 明天把Cursor捆绑进Claude，然后直接推送给所有企业客户，那你就完了。他们有渠道、有品牌、有覆盖率。

Varun：你说得没错，这是非常现实的压力。但这也是我们创业这么长时间学到的东西——你必须做出“无法忽视”的产品。如果你的产品只是“比别人好一点”，那确实会被碾压。但如果它好到让用户愿意绕过默认选项、专门来找你，那你就有生存空间。

我们现在的用户就是这样。我们并不是通过市场投放吸引他们的，甚至很多用户一开始连Windsurf是谁都不知道。他们只是试了一下我们的产品，然后发现它真的有巨大不同。这种“巨大不同”，才是真正有意义的竞争力。你问我要怎么描述Windsurf的目标，我会说，我们要做的是一个“比默认好两个数量级”的开发体验。

Harry：那你怎么评估产品到底有没有达到那个“两个数量级的差距”？你怎么看一个产品有没有到那个“跳跃点”（escape velocity）？

Varun：有一个最直观的信号是——用户自己会带来新用户。我们内部有一个“单用户指标”（single user metric），就是看一个人用完产品之后，有没有回头、有没有带来别人、有没有开始把产品集成进他自己的工作流程里。

这和传统的“团队销售型”指标不一样。很多AI产品的商业模式，其实还处在SaaS旧逻辑里，就是靠团队决策、预算分配、上层推动。而Windsurf不是。我们看到的是，用户用完之后自己来找我们说：“我能不能自己买？”、“我能不能给我整个团队部署一下？”这种从个体主动扩散出来的增长信号，是我目前最看重的。

AI未来与竞争壁垒：长远规划

Harry：你觉得在code AI这个领域里，有什么是大公司短期内做不到的？有哪些是留给像Windsurf这样的团队的机会？

Varun：最大的机会，在于我们能去构建那些需要非常高密度工程直觉的东西。

大公司可能会说：“我们有400个产品经理，可以把每个功能都评审一遍。”但开发者工具不一样，真正的壁垒往往不在某个具体功能，而是在连续一整天、整个工作流中的体验。你是不是懂得什么时候该弹出窗口、什么时候应该保持沉默、什么时候自动补全要aggressive、什么时候又要保守一点，这些东西没有明确规则。这种“流动中的精度感”，其实只有做过一线开发、并且对用户有高度同理心的团队，才有可能做得出来。而大公司，由于组织结构的限制，往往很难在这方面做到极致。

Harry：你觉得所有做code AI的公司，最后都会变成一个IDE吗？也就是说，不管你现在是做Agent、自动补全，还是语言服务器协议，大家最终都会变成一个完整的IDE？

Varun：是的，这是非常显而易见的。这就像是你在说：“我有个方法可以预测接下来每句话会怎么写”，然后你却告诉我你不想去做编辑器——这就说不通。如果你有能力建模所有的上下文，知道用户接下来可能要写什么，甚至还知道用户修改代码的意图，你却不去控制 UI，那你就无法真正释放这些能力的价值。用户要的是整个“写代码”的过程能够高效、流畅、有反馈感。你如果只控制其中一环，体验一定是割裂的。

Harry：那对于用户来说，是不是也意味着——他们今后会在一个新的平台上写代码，这个平台是以AI为中心构建的？

Varun：是的。长期来看，我们一定会进入一个全新的开发环境。团队里很多人以前做过自动驾驶，而自动驾驶的技术曲线给了我很大的启发——我们一直以为自动驾驶是一个“感知”问题，但其实它更像是一个“接口”问题。

同样的道理，代码世界里正在发生的转变，也是“接口”的改变。现在的开发接口还是以手写文本为核心的，而AI开发的理想形态，应该是更高层的表达方式，比如自然语言、流程图，甚至是功能目标。而Agent、token、context 这些能力的发展，意味着IDE这个边界正在被打破。你并不需要再靠传统IDE的形式去组织代码。开发者所期望的，是和代码之间更高效、更智能的交互接口。

Harry：你们最后是变成一个IDE本身，还是说你们只是变成IDE的“AI 层”？毕竟现在也有很多公司在做类似的事情，提供一种“嵌入式AI层”，比如通过扩展接口接入现有编辑器。

Varun：这是个好问题，我也不觉得答案是非黑即白。更准确的说法是：我们希望成为开发环境中的AI核心。不管最终的UI是什么样的，不管用户是喜欢我们自己的编辑器，还是希望把它嵌入VS Code、JetBrains或其他地方，我们真正要构建的是智能层本身——也就是具备Agent能力的系统，它能理解代码库、上下文和用户意图。

我们其实已经开放了Windsurf的API，很多用户就是把Windsurf嵌入到他们自己写的定制开发工具里使用的。换句话说，IDE只是UI层，而我们真正要做的是理解层和行动层。这两个才是决定AI工具价值的核心。

Harry：从另一个角度看，用户为什么愿意用你们的工具？毕竟每个人都可以调一个开源模型，加点prompt，写个AgentLoop，搭个前端。你怎么说服他们用Windsurf，而不是自己造轮子？

Varun：这个问题我想分三个层次来回答。

第一，数据层。我们对代码的理解是深度结构化的，不只是把代码作为token去处理。我们建立了自己的语法解析器、上下文建模系统，这些都是开箱即用的东西，不是靠prompt可以解决的。

第二，反馈循环。我们做了很多智能微调的机制，Agent不会简单重复“用户问—模型答—用户问”的回合式结构，而是能主动评估自己的行为，调整策略。这背后用到了复杂的状态追踪与控制逻辑。

第三，工程能力与体验设计。一个真正好用的开发工具，不是堆积功能，而是把所有能力组织得刚刚好。我们花了大量精力去打磨这个体验边界，比如什么时候让Agent安静，什么时候该“打断”用户；什么时候自动弹出对话框，什么时候保持无声运行。

这些东西不是靠堆API能实现的，它需要你既懂技术，又真的在乎开发者的工作流。

Harry：你怎么看AI产品的“人机边界”？就是说，到底哪些事该让Agent全自动完成，哪些又是该保留给人的决策权？

Varun：这个问题特别重要。我们现在设计Agent时，就非常关注这一点。比如，让Agent在用户写代码的时候自动分析上下文，但不会立刻执行操作，除非它有非常高的信心，并且能明确解释它的行为理由。而当用户进入更高层次的任务，比如调试逻辑、重构架构，我们的Agent就会退到辅助位置，提出建议、提示上下文，但不主动干预。

你可以理解为，Agent是在不断地问自己：“我现在该不该出手？”这种判断力，其实比模型本身的输出质量更难构建，但也更有价值。

Harry：这是我最近录过的最喜欢的一期节目之一了。太棒了。真的非常感谢你今天来聊这些。

Varun：非常感谢你邀请我。这次聊得真的特别开心。

Harry：我还记得我们第一次聊天的时候，你跟我说，“老实说，我也不知道我们到底在做什么。”但现在你们已经构建出了Windsurf，一个非常酷、影响深远的产品。能够见证这个过程真的太棒了。

Varun：是的，那时候真的还不知道我们到底要做什么（笑）。而且这一点也没什么可丢人的。说实话，很多人创业时都太想“证明自己是对的”，但其实更重要的是找到真正对的方向，而不是坚持最初的想法。你得不断观察市场，不断问自己：“我们是否还在解决一个真正重要的问题？”如果不是，那就要立刻转向。整个公司的文化就是围绕这个问题展开的。

Harry：这是一个非常有力量的信念。我非常喜欢你刚才说的那句话：初创公司成功不是因为把很多事做对了，而是因为把那一件事做得非常好。希望听众们也能记住这一点。

Varun：谢谢你。我也一直在提醒自己这一点，尤其是在产品开始扩展之后更是如此。你越早抓住那个关键方向，就越能集中火力做出突破。

Harry：那下次再聊的时候，就来看看Windsurf能不能把这一件事继续做成10倍，甚至100倍的效果吧。

Varun：我们会努力的！

编译：Mia Pan