从烧光现金、裁掉一半员工，到 ARR 9 个月破亿：Replit 用“全栈平台”反杀 Cursor，赌赢“每层都赚钱”模式

2024 年初，Replit 的年度经常性收入（ARR）还不到 1000 万美元，而到了 2025 年，仅用九个月，它就突破了 1 亿美元大关。这条几乎垂直的增长曲线迅速在开发者社区引发关注。

网友 swyx 感叹说：“我一向对编码代理持乐观态度，但 Replit 这张图……属实让人有点看懵。”他把这条曲线类比为 @waitbutwhy 曾经绘制的“智能爆炸临界点”图：变化突然、陡峭，难以预测后续走向。

Replit 的增长并非仅靠 AI 代码生成，而是基于一套更具系统性的战略设计。有不少开发者认为，它的成功关键在于对平台层的布局与整合能力。在 swyx 的评论下，网友们给出了如下观点：

“Lovable 擅长制造‘看起来像真的’原型，Figma 一出手也许能干掉它。”

“Cursor 是个泡沫 —— Claude Max + 自带 IDE 更好用。他们解决了短期扩展性的问题，但没有护城河。”

“Replit 才是真正有潜力成为小白版 AWS 的选手。说实话，我买账。”

还有人指出，Replit 的关键在于“像 Bolt 一样”，原本就有基础设施能力，在行业转折点完成了及时转向。

与一些专注于智能 IDE 的竞品不同，Replit 的路径更偏向基础设施整合。AI 编程代理只是流量入口，平台真正发力的是托管、数据库、部署、监控、日志等“应用生命周期”的后端部分。这也造就了 Replit 的一个特点：生成即上线，构建即运行。

这使其商业模型不同于仅售卖推理服务的公司：Replit 可以在代码生成环节获客，在托管与使用中变现。有人用一句略带调侃的说法总结它的策略：“每个 token 都在亏钱，但每一层都在赚钱。”

图片来自：https://x.com/mattppal/status/1932798993626771556

Replit 当前的增长与策略，更多反映的是一个趋势：AI 编程工具正逐步从“编辑器”进化为“平台”，从“写代码”迈向“部署应用”。谁能抓住这一链条中更多的节点，或许就更有机会在下一阶段脱颖而出。

最近，David Lieb 和 Tom Blomfield 在播客节目中采访了 Replit 的创始人兼 CEO Amjad Msad。从裁员、融资接连遭拒到成为行业瞩目的新兴独角兽，Replit 是如何“浴火重生”，用短短 9 个月的时间，将 ARR 从 1000 万提升至 1 亿的呢？他详细分享了这段历程，以及对 AI 编程的看法。基于该播客视频，InfoQ 进行了部分增删。

核心观点如下：

• 一旦“创造”的过程变得容易，真正的瓶颈就回到了“你能想到多少好点子”。

• 去探索那些技术刚刚变得可能的边界。因为模型的下一次迭代，可能就让你今天的产品突然变得有价值，你也因此率先进入市场。

• 未来会出现一种“融合模式”——我们依然使用自然语言进行交互，但底层的展现方式不再是代码本身，而是某种基于代码之上的抽象界面或视图。

• 高互动、实时反馈的沟通才是真正推动产品前进的关键。

押上公司命运的产品

David：Replit 最早的目标是让初学者可以在网页上轻松搭建编程环境，但现在你们在 AI 辅助编程方面的发展非常迅速，能和我们分享一下最新的进展吗？

Amjad：我们的使命从一开始就是让编程更容易接触。YC（Y Combinator）之后，我们将目标进一步提升，开始讨论让全球拥有十亿个软件开发者。

大概在 2015 年，AI 曾经历过一波热潮，自然语言处理（NLP）也在当时很火。那时有不少 AI 公司，实际上背后是人工操作，最后都失败了，但也让我们初步看到了用 NLP 处理代码的可能性。我在最早的种子轮融资计划书里就写过，总有一天我们能收集到足够多的数据来训练模型。直到 2020 年 GPT-2 发布，我才真正觉得这变得可行了。

在这之前，我们已经构建了一些基础设施，比如开发环境、托管平台以及周边的服务。我当时想，如果我们能把 AI Agent 加进去，它应该能协调这些系统，效果会非常出色。我们从 2021 年就开始尝试引入 Agent，但那时候效果不理想。一直到 2024 年年初，我们才觉得这个方向越来越接近可行。即使只是 GPT-4.0，也已经能连续保持两分钟左右的逻辑连贯。

其实我们那时相当于下了一个很大的赌注，因为公司当时的情况并不乐观。

Tom：我正想问，你们是否经历了一个“押上公司命运”的时刻？从最初教授人们编程，转变为现在帮助每个人构建应用程序。

Amjad：是的，当时公司已经扩张到一定规模，但我们的资金消耗过大，因此我们决定裁员。我们裁掉了大约 50 人，之后又有 15 到 20 人主动离职，公司规模一下缩减到原来的一半不到。那时我把全部精力都投入到 Replit Agent 上，觉得这就是公司的关键转折点，甚至有种“破釜沉舟”的感觉，这件事必须要做成，因为我相信它是能让公司活下去的唯一机会。

坦白说，如果不是 Claude 3.5 在我们开发 Agent 的中途发布，我们可能已经失败了。因为 Claude 3.5 是第一个能保持五到十分钟连贯性的模型，能真正完成代码生成任务。

Tom：对于那些站在技术最前沿的初创公司来说，这种做法其实是最有效的。一开始设定了一个使命，虽然技术尚未成熟，但先开始着手构建，等技术追上来，就刚好踩在了正确的时间点上。

David：我记得大约六个月前你说：“我们离‘完全自动化的软件开发’还有很远。”你现在还这么认为吗？

Amjad：完全不是了。过去每次我做预测时，都觉得自己很大胆，但事实证明我一直低估了技术的发展，自动化程度比我预想得快得多。就像我说的，Claude 3.5 能保持五到十分钟的连贯性，Claude 3.7 可能能达到四五十分钟甚至一个小时，而在 Opus 的系统卡中，他们提到 Claude 4.0 能连续工作七个小时。

David：Agent 最大的限制一直是：它们能否保持思路连贯，能否利用更长的上下文做出合理判断。如果大语言模型能连续工作七小时，那基本上就是一个人类员工了。

Tom：而且它的工作速度可能远快于人类，相当于在七小时内完成了一周的工作量。

Amjad：目前我认为仍然存在一个关键限制，那就是“计算机操作（Computer Use）能力”——Agent 使用电脑的方式还很糟糕。这就是 Replit Agent 的优势所在，它能在一次 Prompt 下完成整个应用开发，而不是每一步都要你陪着测试、纠错、反复尝试。

Tom：有一家叫 Browser Use 的公司，他们正在做浏览器自动化，效果非常不错。还有另一家叫 Pig 的公司，则专注于 Windows 桌面自动化。我给现在创业者的建议是，可以基于这些底层能力，将浏览器或桌面自动化技术应用到具体的企业垂直场景中。

Amjad：一旦这些技术真正成熟，这两家公司很可能会迎来爆发。

Tom：我觉得现在距离这些技术真正“跑通”可能只剩下几周，所以现在正是开始使用这些技术的最佳时机。

Amjad：完全同意，这正是我们目前关注的方向。Replit Agent 从 v1 到 v2 在自治能力上已经有了巨大提升，而 v3 则是我们迄今为止构建的最具自治能力的系统。我们已经在研发中，真正让我们感兴趣的是背后的基础技术，以及它如何赋能更高程度的自治。

有几个要素特别重要，其中之一就是事务性（Transactionality）——具备回滚能力。你希望 Agent 的行为是安全的，就像 Git 让程序员可以自由试验、创建分支一样。Agent 也应该能够尝试不同路径，在出错时安全回滚。此外，它也应该能够在不同的执行路径之间进行采样（Sampling）。这对自主性也非常关键。举个例子，Anthropic 在发布其 SWE-bench 分数时，会分别展示“未采样”与“有采样”的表现，分数会从 70% 提升到 80%，这说明采样机制对于提升系统的可靠性和能力非常有效。

Tom：这涉及到一个思路：你同时启动多个 Agent，每个尝试一种解法，然后从中挑选出最优路径。

Amjad：我们构建的基础架构是完全事务性的，并且可以“锁步执行”。文件系统是基于快照的，数据库也是快照数据库，甚至虚拟机在运行中也可以进行快照提交。因此我们可以随时分叉、创建分支。

如果“计算机操作”也能成熟，那么我们甚至可以做到这样：多个 Agent 同时尝试不同路径，再通过自动化评估机制进行比较。目前一些做法是用判分器（Judge）来打分排名，但那不是真正的验证器。真正的验证器是测试，是 Agent 实际操作计算机后的测试反馈。通过这样的方式，我们可以采样多个执行路径，找到真正“有效”的那一个，再反复复制执行，最终达到极高的稳定性与可靠性。

Tom：会不会未来，你们可以不只生成一个 Agent，而是同时生成五个、十个，甚至上百万个？

Amjad：这就是未来真正有意思的地方。我们希望用户能够自行设定“计算预算”。现在一些类似 O 结构的模型已经开始提供预算设置，比如你愿意投入多少钱。如果你愿意给我们 1000 美元，我们就能把它全部用在生成和评估上。

Tom：同时生成多个分支并行执行，再挑出最好的那个，人类大脑是做不到这一点的。我们是线性思维，没法像 AI 一样并发决策。

David：这让我想起一个“传说”，我不确定是否属实：据说在 Steve Jobs 管理苹果时，他会故意安排多个团队做相同的项目，然后看哪一个做得最好。我听说 OpenAI 现在也采取类似做法。

Amjad：我也听说过，比如 OpenAI 在做 Codex 项目时就有多个团队同时推进。在学术文献中也有类似结论，小模型如果进行采样，其表现可能超过未经采样的大模型。比如，经过采样的 Sonnet 可能比 Opus 更好。一些公司甚至在尝试一种类似策略：不是雇一个高级工程师，而是雇十个初级工程师，让他们完成相同的任务，最后挑选出效果最好的。

Tom：不过，用人类来做这件事代价太高，而对大语言模型来说却相对便宜。你可以生成上百个版本，然后每次都选出最优的那个。

什么该交给 AI，什么必须平台托底？

David：现在大家是怎么使用 Replit Agent 的？主要的用户群体是谁？

Amjad：这个问题回到我们最初的愿景——只要让编程变得足够简单，就会有越来越多的人愿意尝试。其实我们刚进入 YC 前，Paul Graham 就在 Hacker News 上发现了我们。他告诉我，有一个“超线性关系”：编程越简单，愿意学习编程的人数增长得就越快。

Replit 的优化策略一直都是降低学习门槛，这是我们增长用户和客户的核心逻辑。现在我们看到，各行各业的人都在使用 Replit Agent。特别是产品经理，他们无需依赖工程师就能完成很多有影响力的工作，比如运行 A/B 测试、做产品优化等，极大提高了独立性和执行力。

这也促使我们重新思考产品经理、设计师和工程师这些角色之间的边界。最近我们成立了一个新的产品团队，不再是传统的产品负责人带一组产品经理，而是将设计师、工程师和 PM 组成一个混编小组，大家都在使用 AI，不仅能快速做出原型，有时甚至可以直接推进到上线阶段。这打破了传统的瀑布式协作流程，避免了跨角色之间沟通效率低下的问题，使得整个团队协作速度极快。

Tom：我在创业公司工作时，创意列表和产品待办事项总是无限延长，而最大的瓶颈永远是工程师的时间。但现在我在做自己的项目，我写下待办事项后，它们很快就都完成了。突然间，瓶颈变成了“我还有多少新点子可以想出来”。看着一个空空如也的待办列表，竟然开始发愁下一步该做什么，这种体验真的很奇妙。

Amjad：我听说过一个典型的案例，有家公司在内部广泛部署了 Replit，连创始人都在用。这反而让工程师感到压力山大，因为创始人一个周末就能做出一个功能，反过来质问他们：“我能自己一个人在周末搞定，你们一整个团队干了些什么？”

Tom：这些人原本是技术背景的吗？他们做的是初版原型，还是直接上线？还是交给工程团队让他们重写？你们通常看到的做法是什么？

Amjad：我们一般建议这些用户与工程团队协作，但现实中并不总是如此。很多产品经理和设计师会选择绕过工程师，直接面向用户。我们发现他们大多会先把产品交给内测或测试用户，但也有一些人直接上线投入生产环境。

目前我们正在和这些公司的工程负责人深入沟通，很多人对这种做法非常不满，比如：“谁来负责这套系统的运维？出 bug 谁修？”在我看来，所有这些问题的答案其实很简单：这些应该由 Agent 来负责。

Tom：那现在的主要限制因素是什么？如果我今天用 Agent 写了一段代码，直接上线，通常工程师会反对哪些方面？主要是哪里出问题了？

Amjad：安全（Security）问题是一个非常大的挑战。大语言模型（LLM）和人一样并不完美，它们在某些组件上的表现非常糟糕，尤其是在身份认证方面。目前的模型往往还在使用过时的加盐、哈希方法，这是一个严重的问题。

我们已经看到很多现实中的失败案例，虽然目前还没有特别严重的事故，但我认为迟早会发生。比如，一些独立开发者会意外泄露 API 密钥，或者没有做好登录安全保护，导致系统极易被绕过。而市面上很多工具对此并不负责，甚至直接把锅甩给用户，说这是用户的问题。

但我们不这么看。作为一个面向非开发者的平台，我们认为自己有责任为用户屏蔽掉这些高风险领域。因此，我们主动限制了一些 LLM 当前不适合处理的任务。比如在 Replit 上，如果你添加身份认证组件，我们就会自动拉取一个我们从零开发的认证模块，内置了验证码、标准安全机制，并且与你的数据库打通，用户管理也都集成在页面中，尽可能降低复杂度。

另一个我们认为 LLM 不该负责的模块是支付系统。支付逻辑虽然不复杂，大致就分为一次性付款、订阅和按量计费几种模式，但即便如此，我们也不建议由 LLM 来编写。

Tom：支付逻辑类型就那么几种，不是无限复杂。但也正因为标准化，其实更应该由平台来提供现成模块。

David：今天已经没有人会自己从头写支付系统或身份认证模块了，大家都会用成熟的服务商。现在 AI 时代也在重演同样的趋势，看起来这就是最好的发展路径。

Amjad：除此之外，我们还与一家出色的安全公司 Samrip 建立了合作关系。现在每当用户部署一个 Replit 应用时，系统会自动运行安全扫描，对代码进行检查，并生成包含警告和错误的详细报告，Agent 甚至可以尝试自动修复这些问题。

Tom：我能想象未来还会遇到其他问题，比如可扩展性、数据库的 N+1 查询问题、性能瓶颈等等。你有没有一份明确的“阻碍清单”，列出在实现“真正一键部署”前需要解决的所有问题？

Amjad：我认为，未来最大的限制因素其实是“人”本身，特别是社会层面的不信任感，这恐怕只能随着时间自然演进。把这类问题放在一边不谈，企业要适应新技术，还需要在其他层面上做出改变，比如提升可扩展性的检测能力。目前我们还缺乏类似模糊测试或对抗性 Agent 来主动攻击和测试应用系统的机制，而这将是未来非常重要的一环。

另一个重要方向是企业系统集成。我们正在研发的一个功能，是支持企业将自己的设计系统导入 Replit。很多公司已经有完整的 UI 组件库，我们希望 Replit 在进入这些大公司后，能够无缝对接它们已有的内部系统。

构建护城河：“大量工程投入其实在基础设施上”

David：这让我想到当前不同类型编程工具所构成的“光谱”。一端是所谓的“能力增强型工具”，比如 Cursor 和 WindSurf，它们服务于专业开发者，用于提升效率。另一端是面向消费者的“低门槛工具”，比如那种让任何人都能快速搭建 App 的平台。你们似乎处于这个光谱的中间地带——既帮助企业交付真实产品，又服务于那些非传统意义上的程序员。

你怎么看这个格局的发展？未来会不会逐渐统一，还是会长期存在多个并行工具？

Amjad：如果出现 AGI，那显然就是“统一”了。但先撇开那个世界不谈，目前很难为那种场景做出规划。就现实而言，“如何逐步提升现有工程师的生产效率”是一个非常明确、竞争也非常激烈的市场。无论是像 Cursor 这样的应用公司，还是底层模型公司，都在往这个方向投入。

比如 Claude Code 和 Cursor 之间就已经存在竞争关系，而 Cursor 又依赖 Claude。可以说，这是一场激烈的混战，但市场足够大，我预计最后会出现一些整合，可能不是一家独大，但最终可能收敛到两三家主导者。

我们的服务对象是“知识工作者”——理论上，任何一位知识型员工都应该能够借助软件解决问题。

Replit 的愿景，就是成为“通用问题解决器”：无论是个人生活还是工作场景，我们希望都能帮你解决问题。因此，这个市场会更加多样化，参与者也会根据各自优势定位在不同层次。Replit 的目标，是实现面向非工程师的“自治式编程”。我们希望用户不必担心安全、不必管理系统，只需要带着想法来到 Replit，担任一个“Agent 管理者”的角色。

我们努力将这套机制尽可能“人性化”，并融入用户的自然工作流中。工程师与非工程师之间的一个显著差别是：后者并不会一天八小时坐在电脑前，所以移动端对他们而言非常重要，因此我们也开发了体验非常优秀的移动应用。

我们现在在尝试一种新的使用方式，叫“环境式开发（Ambient Building）”：你可以在电脑上启动一个项目，然后离开，拿着手机收到 Agent 发来的消息：“我做完了这个功能，你还需要别的吗？”你可以直接通过手机继续推进。

Tom：在像 Cursor 或 WindSurf 这样的工具中，主界面元素很明确，就是代码。你看到的是代码改动和差异对比，外加一个小型对话窗口，整个体验以代码为核心的。

但在 Replit 这样的工具中，主要界面是图形化的，是按钮和所见即所得（WYSIWYG）式的构建体验。这种方式在搭建用户界面时非常好用，但当你尝试构建更复杂的逻辑流程时，就会觉得有些困难。因为你看不到代码，也无法清晰了解背后的运行机制，整个系统有点像个“黑盒”。

如果我们把场景拉到更复杂的企业级内部工作流程，那么产品经理或运营经理如何理解整个流程及其逻辑分支？他们该如何可视化这些东西？

Amjad：如果我们回顾计算机历史，就会发现“可视化编程”这个概念其实早就有了，但它从未真正成功。原因在于，过去这些系统通常无法达到图灵完备，无法成为真正的通用计算平台。而现在我们进入了代码生成（Code-gen）时代，它是图灵完备的，理论上可以完成任何计算。但人们与之交互的方式主要是自然语言，而自然语言本身是模糊的，这就导致很难确定系统是否在做正确的事情。

我认为，未来会出现一种“融合模式”——我们依然使用自然语言进行交互，但底层的展现方式不再是代码本身，而是某种基于代码之上的抽象界面或视图。

你可以想象类似 Smalltalk 的系统。Smalltalk 是最早的面向对象编程系统，Alan Kay 甚至认为后来的系统都不能算是真正的 OOP。在 Smalltalk 中，开发者并不通过文件操作代码，而是通过“对象”与代码交互。这个思路或许能为我们提供一些参考。

我相信我们正走向一个“代码抽象视图”的世界，人们将不再阅读或修改代码本身，而是通过某种更具逻辑结构的方式来理解和控制代码行为。

Tom：我感觉这中间其实还有一个“开放空间”，比如是否可以使用伪代码（pseudocode）那样的方式，它看起来像英语但更有结构化？又或者用更先进的可视化拖拽界面？

David：我过去与工程师、设计师等团队合作做产品时，沟通方式大多是口头的，或者通过书面形式表达抽象想法，我们会一起在白板上画图，做系统流程图，也会通过真实的应用去测试，指出哪里慢了、哪里坏了。这种“多模态+高度灵活”的沟通方式其实是非常理想的。我相信我们终将实现一个这样的界面——产品作者依然以这种方式工作，只不过他们交流的对象不再是人类团队，而是 AI Agent。

Amjad：在产品经理这个领域，有没有尝试过让沟通方式更正式、更结构化？

David：确实有尝试让产品沟通更正式一些，但效果并不好。最常见的形式是 PRD（产品需求文档），但我认为它常常沦为一种“表演性产出”——特别是在大公司里，它只是为了给升职评审准备的一个形式上的成果，而非真正推动工作进展的工具。

对我来说，最有效的交流方式还是白板讨论。比如“我们这里想实现什么功能？”、“这里可能会有问题。”、“我们是不是忽略了某个因素？”、“那我们需要重新思考整个方案。”这些高互动、实时反馈的沟通才是真正推动产品前进的关键。

Amjad：AI 其实也可以在这些场景中发挥作用。我最近接触了一个叫 Granola 的初创公司，它可以录音会议并自动生成转录文稿。他们推出了一个团队版产品，所有会议记录都会被集中整理，还提供了移动端应用，用户可以把手机放在桌上录音并实时记录内容。

我在想，也许我们该走向一种“Granola 极致主义”——也就是不去对抗企业沟通日益“口语化”的趋势，而是拥抱它。现在公司内部的沟通很多都发生在 Slack 里，或是在各种会议里，甚至包括和 AI Agent 的对话。与其强行推进文档化的规范，不如发展一套 AI 工具，在后台自动完成信息记录、结构化、归档和搜索，让语音沟通也能变成系统性知识资产。

Tom：什么时候我们会迎来第一个能主动参与会议的 AI 呢？比如你和设计师正在头脑风暴，AI 也插进来说：“我有个想法，要不要试试这个？”

Amjad：很多人对 AI 抱有末日论的看法，觉得它会取代所有人的工作，但我认为不是这样的。未来的工作会更“人性化”，更加互动、多模态，也更有趣。

David：上次我们聊的时候，你刚刚发布 Replit Agent，当时用户增长非常快。现在情况如何？

Amjad：Replit Agent 上线以来，我们的月复合增长率达到了 45%。

David：这是我们通常建议 YC 创业公司在早期用户基数为零的情况下努力追求的指标，而你们是在已经具备规模的基础上实现的，非常惊人。

Amjad：确实如此，但这种增长也给公司带来了不少压力。我们的系统基础还相对较小，一旦增长太快，很容易走偏，开始追求错误的目标。尤其在 AI 领域，如果你只关注收入增长，很容易出现一个问题：用户花了更多的钱，但并没有获得更好的体验。

事实上，在某些情况下，也许并不应该追求极快的增长，因为真正重要的是用更低的成本给用户带来更好的体验。所以我们在 Replit 并没有收入目标，而是更关注产品质量、用户留存等与用户体验直接相关的指标。

Tom：很多 AI 公司会出现一种不良增长模式：虽然收入快速增长，但客户流失率却接近 100%。最终，这种增长方式是不可持续的。

Amjad：是的，而且它们的毛利率通常也很差。也就是说，用户越多、增长越快，公司的财务状况反而越糟。

Tom：那投资人怎么看这个领域？他们能分辨得出这些产品之间的差异吗？

Amjad：说实话，对他们来说很多时候很模糊。当投资人刚开始关注这个领域时，通常只会用每个产品三分钟。而在三分钟之内，这些产品看起来都差不多。

不过我认为，随着时间推移，这些产品之间的差异会越来越明显，尤其是在各自专注的方向上，逐渐会出现“聚合”与“分化”的趋势。未来一年，这个格局可能会清晰许多。但目前我们和投资人交流时，他们还是挺困惑的。他们不太理解这些系统，也不清楚它们将往哪儿发展。

Tom：最近 Cursor 和 WindSurf 都宣布了一些技术更新，比如在 Claude、Gemini 或 OpenAI 的基础上，叠加自研模型和 API，比如“Fast Apply”等。Replit 是怎么做的？

Amjad：很多时候，我们其实是在“修补”底层模型的问题。以“Fast Apply”为例，它之所以重要，是因为目前几乎所有主流模型在处理“差异化修改（Diff）”方面都做得不够好。

Tom：可以解释一下什么是“Diff”吗？

Amjad：假设你要让大语言模型编辑一个文件，最理想的方式是生成一个“差异文件”——也就是告诉系统“删掉这三行，插入另外三行”。但现实是，大多数模型在处理这类任务时表现很差。它们在识别原始代码行数、定位修改点方面经常出错。因此，很多公司一开始的做法是直接重写整个文件——不管它有几百行，模型都全部重新输出。

Tom：听起来又慢又贵。

Amjad：所以我们会尽量引导模型“懒惰一些”——也就是说只修改必要的部分。但这样一来，又很难直接应用这些修改。因此，我们还需要另一个模型来执行这些修改操作，也就是负责“应用 Diff”。

我们可以选择训练一个专门的模型，或者使用像 Gemini Flash 这样的小模型。有时也会在多个模型上做组合优化，补上各自的短板。这其实更像是工程问题，而不是科研问题。我们不是在重新发明模型，而是在用工程手段把已有模型组合起来，构建出一个真正可用的系统。

Tom：我注意到你们并没有像 Cursor 或 WindSurf 那样在产品中让用户选择底层模型。比如其他产品会有一个下拉菜单，让你选择“我想看看 Gemini 怎么看这个问题”。你们为什么不这么做？

Amjad：我们在评估（Eval）上投入了大量精力。我认为这是协作式 AI 编程中被严重低估的一部分。我们花很多时间评估新模型、编写和生成评估数据，分析用户反馈和使用情况。一旦有新的前沿模型发布，我们会立刻进行测试。比如几个月前 Gemini 发布时，我们马上试用了。它在某些场景下的 One-shot 效果比 Claude 还好，但在工具调用和 Agent 编排方面表现一般。不过用户往往只看到宣传热度，然后就说“我想用 Gemini”。

Tom：那你们在这些模型发布之前，会提前收到通知吗？还是说发布当天你们才开始测试？

Amjad：我们和 Google、Anthropic、OpenAI 都有良好合作关系，通常会提前拿到模型的 Checkpoint。我们会第一时间进行尝试。特别是 Anthropic，我们几乎总是在模型发布当天就能上线新功能。我们有时也能预判模型发展方向，比如 Claude 3.5 到 3.7 时我们就开始为 4.0 架构做准备。

但说到底，我们的大量工程投入其实在基础设施上。比如我们构建了一个分布式快照型网络文件系统，这个系统花了我们两年时间，市面上没有现成的解决方案。还有安全性方面也很复杂，比如在 Replit 上，用户只要注册账号就可以获得云端虚拟机。要在这种环境下抵御恶意行为，比如加密矿工的攻击，是非常难的。我们还用了 NixOS，这是一种声明式、可事务回滚的操作系统。我们在全球各地的计算节点上都部署了多 TB 的缓存硬盘，预加载了所有软件包，这些会自动挂载到每个容器上。

所有这些设计都体现了一个核心理念：事务性。你需要一个安全、可回退的系统，这样用户和 Agent 才能大胆地试验、采样、切换路径。这些底层工程虽然不像“发布一个新模型”那样吸睛，但它们才是我们真正建立长期技术优势的关键。

David：没错，风投口中的“护城河（Moat）”，我更倾向于理解为“复利型优势”：你领先的那个方向，会让你越跑越快。你们的这些基础设施，正好就是个很好的例子。

Amjad：真正的“护城河”往往在公司成立几十年之后才显现。比如 Netflix，很多人当初不看好他们，但事实证明，他们建立了一整套强大的内容生产系统，这就是 Disney 后来无法超越的地方。

AI 时代的能力边界与新机会

David：我有几个年幼的孩子，我希望他们未来成为有创造力的生产者。你觉得我应该让他们学编程吗？现在的“学编程”到底意味着什么？

Amjad：如果你想成为专业的软件开发者，那去读计算机科学专业、掌握基础知识当然是有意义的。但如果你希望成为一个创造者，或者在这个世界里作为一个通才发挥作用，我认为就不再需要用传统方式去“学编程”了。你可以通过“渗透式”学习来掌握它——比如直接上 Replit 去做项目，在过程中你自然会遇到一些需要查看代码或日志的问题，靠自己的探索能力和 Google 查资料的能力，你就会慢慢学会。

这其实也是我们那一代人学编程的方式，只不过后来编程逐渐变得“工业化”甚至“形式化”。以前我们用记事本写一个 HTML 文件就能做出网页，现在你得学一大堆工具，比如 Webpack，门槛高了很多。但我认为未来的工作图景是模糊的，我们顶多能预测个大概。所以我对我自己的孩子的教育目标，是让他们拥有尽可能广泛的知识面，成为通才，更重要的是成为“生成型”的人——能源源不断地产生新想法。

因为一旦“创造”的过程变得容易，真正的瓶颈就回到了“你能想到多少好点子”。所以，我不会把“学编程”排在第一位，而是会鼓励他们“学会创造”——用代码创造、用视频创造、用 AI 创造任何东西。

Tom：你怎么看 SaaS 的未来？如果我们很快就能说一句话，比如“帮我做个 Google Calendar”或“克隆一个 DocuSign”，那整个 SaaS 行业会变成什么样？

Amjad：现在就已经有不少用户在用 Replit 取代原本每年数十万美元的 SaaS 工具。有人被某公司报价 15 万美元的软件，自己用 Replit 做出来，花了 400 美元，然后卖给公司 3.2 万。

我认为，那些拥有开发者生态和插件系统的平台型公司还比较安全，比如 Salesforce 这种系统你不太可能用 AI 随便“即兴编写”出来。但很多垂直类 SaaS 恐怕危险了，我猜他们的一些关键指标现在就已经开始下滑了。

Tom：你会给当下正在创业的创始人什么建议？

Amjad：去探索那些技术刚刚变得可能的边界。因为 AI 或模型的下一次迭代，可能就让你今天的产品突然变得有价值，你也因此率先进入市场。

有前瞻性思维的创始人其实挺少的，很多人并不真正花时间去思考未来可能的走向。也许以前这样做并不被鼓励，但现在，具备预测能力，是一个非常重要的竞争优势。你要敢于做判断，然后构建一个“当前看起来很烂但模型一变就能立刻变好的产品”。

参考链接：

https://www.youtube.com/watch?v=kOyIjt6FUrw