Bolt.new：AI Coding 领域的 Figma，2 个月实现近千万美元 ARR

01.

Bolt  和 Qodo 的

最新进展

Swyx： 可以先介绍下 bolt.new 吗？

Eric Simons：我们公司叫做 Stackblitz，Bolt.new 是我们的产品。Bolt.new 上线仅一周，用户量就达到了 Stackblitz 过去 7 年积累的 2 倍。这个数据连我们自己都大吃一惊。

Bolt 这个项目其实在今年初就有了雏形，虽然之前没怎么对外透露，但在年初时我们就尝试过接入一些头部大模型。不过当时即便用上了 RAG ，但 code generation 的质量和性能上还是差强人意，所以项目暂时搁置了一段时间，直到我们看到最近几个月新模型的表现，尤其是新一代模型在 代码生成 领域的突破，让我们看到了产品化的希望，这也是 Bolt 项目重启的契机。

过去 7 年中，Stackblitz 一直专注于为开发者提供在线 IDE，但随着技术演进和需求发展，我们之前建立的整个用户体验流程在现在看来已经不太合适了。开发 Bolt 时，我们提出了一个全新的思路：如果站在 AI Code Generation 的技术高度，重新定义开发工具，会是什么样子？

经过团队深入讨论，我们决定采用一个相对激进的策略——从零开始打造新产品。这样可以更好地验证我们的想法。如果市场反响好，就继续深耕；如果效果不理想，及时调整方向也不会有太大损失。这就是 Bolt 诞生的过程。

Swyx： Codium最近的发展怎么样？距离上次播客讨论之后有什么新进展？

Itamar Friedman：我们公司之前叫做 Codium AI，现在改名为 Qodo，我们的模型名字还叫做 Codium。上一期播客是在我们产品发布两个月后录制的，当时我们已经确立了刚才讨论的愿景。我们认为软件开发的核心是规格、测试和代码。其中我们特别关注测试环节，因为我们认为解决了测试问题，就等于解决了软件开发的核心痛点。

代码测试是一个很宽泛的领域，涉及多个维度。从微观角度有单元测试（Unit Testing）、组件测试（Component Testing）；从宏观角度还要考虑测试规模的分级。此外还有回归测试（Regression Testing）、冒烟测试（Smoke Testing）等不同类型。

最开始我们只推出了一个专注于单元测试的 IDE 插件。经过一年半的发展，这个插件已经进化成支持多种上下文感知测试的工具套件。我们不仅为本地代码库提供索引服务，还为财富 500 强企业处理了价值 1 万美元的代码库。

同时，我们开发了新的 Agent Tools ：开源版本称为 peer agent，商业版本叫 Qodo Merge，还有一个即将推出商业版的开源工具 CoverAgent，有些用户已经在不知情的情况下，体验过我们在大型开源项目中提供的自动化代码审查功能。随着这类案例的积累，我们还会推出更多 AI agent 工具。

这一年半以来，我们在产品矩阵方面实现了显著增长，重点聚焦于代码运行时的实际场景：包括测试、代码审查等环节。我们相信这些都是打造企业级 AI 编程助手的关键基石。

第一年我们采用了完全的 PLG 策略，实现了 100 万安装量。2024 年我们开始探索商业化，推出了 Teams 版本，现已有上千个团队在使用，几个月前，我们开始推出企业版，这些内容在 Qodown 最近发布的文章中都有讨论。

我们启动了企业级业务，已经有多家财富 100 强公司成为我们的客户。随后我们完成了 4000 万美元的 A 轮融资。这笔资金将主要用于开发更多 AI agent 工具，这也是我们未来的发展重点，但短时间内我们不会涉足 IDE 开发。

Swyx： 所以你们不打算开发 fork VS Code ？

Itamar Friedman：如果要做，我们可能会选择 fork JetBrains 的产品，这样更有特色。

Swyx:  我观察到通用的  AI Agent 的热度似乎在减退。现在市场上更多是像你们这样的专业化产品，比如 QodoGen、QodoMerge ？

Itamar Friedman：还有 QodoCover，这是 CoverAgent 的商业版本，即将推出。

Swyx:  我注意到 Factory AI 也在做类似的 Specialized Bot 。它们都有明确的应用场景，这说明市场对通用型 agent 的需求并不强烈，而去年我们还在讨论 AutoGPT ，这个话题在 2023 年很热门，但现在已经不那么受关注了。我觉得主要是因为当用户拿到一个 general agent 的时候并不知道怎么用。

Itamar Friedman：我同意这个观点。即便现在有了 computer use 这个问题依然存在。理论上我们可以通过 prompt 让 AI 扮演 QA 工程师或开发者的角色，但在企业级复杂软件开发中，专业化的 agent 仍有其必要性。比如考虑权限管理（Permission Management）和数据源（Data Source）的问题，就像管理用户权限一样。对开发团队来说，需要为 agent 设置专门的安全机制和审批流程。这可能是个被忽视的视角，但光是这一点就足以证明我们需要不同类型的 specialized agent。

Alessio： Qodo 专注于复杂应用的开发管理工具，而 Bolt 则更注重简单易用。有用户提出过 “Bolt.new 适合入门，但后期需要更专业的版本来做深度开发”这样的需求吗？

Eric Simons：确实如此。我们内部将 Bolt 定位为“从 0 到 1”的启动工具，这是它最独特的价值。当然，处理企业级应用也很重要。世界 500 强企业的代码库往往有 20 年、30 年的历史，所以从 101.3 升级到 101.4 这样的迭代同样关键。

我们观察到两个明显不同的用户群体：

1. 专业开发者：他们用 Bolt 快速启动项目，然后导出到 GitHub 或下载后用 Cursor 继续开发。有时会回到 Bolt 添加新功能。

2. 编程新手：他们倾向于始终在 Bolt 环境中工作。

产品上线第一天就出现了一个热门的 YouTube 视频，说“Bolt 是 Cursor 终结者”。这让我们很惊讶，因为这完全不是我们的产品定位，因为 Cursor 是本地 IDE 。但深入分析后，我们发现有大量用户在用 Cursor 尝试开发应用。他们不是传统意义上的开发者，但严重依赖 AI 辅助。这种方式在 Cursor 中操作比较复杂。当 Bolt 推出时，这些用户发现它极大简化了开发流程。它不是传统的 IDE，而是基于聊天的界面。

我们已经看到一些完全基于 Bolt 构建的创业项目。比如明天我要和一个叫 Paul 的人做直播，他用 Bolt 完整地构建了一个 CRM 系统，包括后端等等，甚至有人通过集成 Stripe 实现了首次线上收入。

Itamar Friedman：我也认为把 bolt 和 cursor 的类比并不合适，从本质上看，现在有两类开发工具：

1. 重新定义软件开发的工具，我认为 Bolt 就属于这类产品， Vercel  和 Replit 也属于这类；

2. 对现有工具的改进升级，比如 Cursor 其实就是在改进 IDE，Codeium 在做类似事情。

所以不同的 AI coding 产品之间其实是有差异的，不应该被简单比较。

02.

WebContainer 

是 Bolt 的核心

Alessio： Bolt 在四周内就创造了 400 万美元收入，是怎么做到的？Twitter 上有很多 Code Generation Agent 的演示，但实际应用效果并不理想，但 bolt 直接推出了可用的产品并实现了商业化？

Eric Simons：这个结果连我们自己都没想到，而且现在增长势头越来越猛。市场确实出现了两个方向，重新思考软件开发流程，以及增强现有开发者能力。这都得益于 AI Code Generation 技术的突破性进展。它不仅让现有开发者效率倍增，还大大降低了编程入门门槛。

对所有学习编程的人来说，最大的障碍是配置本地开发环境。在开发 StackBlitz 时，我们发现浏览器有了很多新的 API，比如 WebAssembly 和 ServiceWorkers，这让我们可以在浏览器中构建一个毫秒级启动的操作系统，这弥补了 Web 平台的一个缺失功能 ：在 Web 上开发 Web 应用。就像 Windows 有 Visual Studio，Mac 有 Xcode，Web 平台也应该有原生的开发工具。

当我们将这个称为 WebContainer 的技术与先进的 AI 模型结合时，就创造了 Bolt。它特别适合那些在配置本地环境时遇到困难的新手。这可能是爆发式增长的主要原因，因为几乎没有其他产品在尝试在浏览器标签页中运行完整的开发环境。就像 Figma 取代了需要下载的 Photoshop，Google Docs 取代了桌面版 Word，新一代用户期待无需下载就能完成开发工作。AI Code Generation 的加入让这种体验更加完美。

我们还整合了 Netlify 的部署功能，这归功于 Netlify 的 API，这个集成做得非常巧妙，用户甚至不需要登录 Netlify，我们就能直接帮他们部署文件，立刻获得一个在线网站。如果他们想长期使用这个网站，只需点击一个链接就可以关联到自己的 Netlify 账户。这创造了极其流畅的用户体验 ，我 71 岁的母亲两周前都用它制作了她的第一个关于护士生涯的网站。

产品的成功完全源于它的实用价值。Bolt 上线第一周就有很多人用它制作个性化项目，比如一位东海岸的销售人员用 Bolt 为患有特殊医疗状况的女儿制作了一个网站，用于在旅行时提前联系当地的医疗资源。

这让我很受触动，同时也在想：为什么他不用 Wix 或 Squarespace 呢？我自己 2021 年也用 Squarespace 做过婚礼网站。虽然我会编程，但选择了它是因为觉得更快。不过现在回想，传统建站平台需要学习大量界面操作，实际并不简单，因为要涉及到成百上千的配置选项。

而 Bolt 只有一个文本框，用户只需描述需求：“我需要一个婚礼网站，这是日期、地点和照片”，就能完成建站。就像我妈妈说的："我是 Pat Simons，70 年代是一名护士，这些是我的经历"，网站就生成了。如果她觉得不错，只需点一下部署按钮网站就能上线，还可以直接购买域名并绑定，非常简单直接。

这可能是有史以来最简单的网站构建和部署方式，这也解释了为什么我们能看到如此快速的增长。我们正在开发的新功能会让这个过程变得更简单。

Swyx： 说到 Netlify，虽然我是 CLI（命令行界面） 的维护者，但匿名上传这个功能可不是我的功劳。这其实是 Netlify 的创始理念：让用户可以直接把 zip 文件或文件夹从桌面拖放到网站上，不需要登录就能获得一个在线 URL。这个特性一直保留到今天。

有意思的是，Bolt、Cognition Devin 以及其他一批 agent 类型的创业产品，都因为这个特性选择了 Netlify 来部署。他们并不在意 Netlify 的其他功能，只是因为这个接口对计算机来说特别友好和易用。这告诉我们：如果你专门为计算机设计一个易于操作的接口，它就会被 AI agent 采用。这是很多开发工具公司正在意识到的事情。

再说说 web containers 技术。你们在技术模式和产品设计上都做得很出色。相比其他尝试构建类似工具的团队，包括我在内，你们的实现更为完善。特别是在基础设施方面，你们的 Browser Sandbox 正是用户所需要的。Alessio 投资了 E2B，我们之后会请他们来讨论服务器端的方案。你们选择的方案是在浏览器内部实现的 serverless architecture，这意味着服务一个用户和一百万用户的成本基本相同。

理论上，因为你们可以运行完整的后端环境，我们应该能够进行测试。你们可以运行 Git，可以运行 Node，将来可能还能支持 Python。我们之前讨论过这个可能性。理想情况下，你们应该能够实现一个完整的 agent 循环：运行代码、检测错误、修正代码，实现自我修复。这不正是我们的终极目标吗？

Eric Simons: 完全同意。在 Bolt 中我们已经实现了相当一部分功能，虽然还有很多需要改进。在 WebContainer 方面，我们采取了不同的策略。目前市面上有很多将 Docker 容器转换为 WebAssembly 的方案，但它们通常庞大（60-100MB）且运行缓慢，影响用户体验。因此，我们决定从零开始构建一个专门为浏览器设计的精简 OS ，大小仅约 1MB。

Swyx :  本质上是将 Linux 系统调用（System Call）映射到 WebAssembly 来实现？

Eric Simons: 可以这么理解，开发环境不需要传统操作系统的许多组件，比如音频驱动等，可以大幅精简。

说到这里，我想谈谈浏览器的发展历史。在 90 年代末，人们对 Web 的发展有两种截然不同的愿景。Tim Berners-Lee 提出了 document-based 的理念，而 Alan Kay 的观点相反。最终，document-based 网页浏览方式成为了主流。Alan Kay 有个很出名的观点是：浏览器应该成为迷你操作系统，能够下载并执行小型二进制文件，在其中运行一个小型虚拟化操作系统。

历史证明这两种观点最终都是正确的。document-based 确实让 Web 成为了世界上最普及的平台。但现在，我们需要在浏览器中处理更多底层操作，这就是为什么会出现 WebAssembly，还有 WebGPU 等技术，一系列用于构建操作系统的 API 逐渐被引入浏览器。

2017 年，我们意识到了一个重要变化：虽然 Service Workers 最初是为了支持应用离线运行而开发的，但它实际上使得在浏览器中运行 Web 服务器成为可能。这意味着我们可以在浏览器环境中启动一个完整的服务器。这是一个很重要的技术突破。

Swyx : 就像完整的 Node.js？

Eric Simons：是的，完整的 Node.js 功能。这意味着网络应用可以通过编程方式控制自己的 URL。这实现了一个关键能力：让网络构建网络的底层基础已经具备。

当时我们和 Chrome 团队的人讨论这个想法时，他们都表示不确定。但有些事情必须亲自实践才能验证。我们花了几年时间研发，最终在 2021 年发布了 web container 的第一个 beta 版本。

在和 Chrome 一起探索这件事的过程中，我们发现测试平台性能和能力主要有两种方式：

1. 第一种是视频游戏，因为它们需要密集计算；

2. 第二种是 IDE，因为它需要虚拟化运行环境并在其上构建应用，这需要复杂的功能和大量计算资源，本质上是在应用中构建应用。

这些都是很好的压力测试用例。如果平台有任何缺陷，在这些应用场景中就会被发现。游戏和 IDE 开发者会发现这些问题——对普通应用来说是操作系统层面的问题，对我们来说则是浏览器层面的问题。

我们不断在 Chromium 的 bug 追踪系统中提交问题。他们团队可能都在想“这些人是谁？”但他们的配合真的很棒。比如让 Chrome DevTools 支持操作系统级别的调试——这原本不是它设计的用途。他们帮助我们不断突破技术边界。

这些改进最终会帮助到了整个生态系统。现在有很多不同类型的浏览器应用都能通过 Chrome DevTools 进行更可靠的调试，这也和我们和网页游戏开发者们进行的持续压力测试有关系。一开始连 Chrome 团队都对此持怀疑态度，但我们最终还是在 2021 年推出了第一个 WebContainer 测试版。

Itamar Friedman：确实精彩。补充一点，我认为大多数编程辅助工具都需要这种测试循环，我还要补充的是有些情况下代码审查也需要这种过程。

Swyx :  测试（Test）和代码审查有哪些区别？

Itamar Friedman：代码审查（Code Review）包含多个层面，比如 PR（Pull Request，代码合并请求）审查，这发生在代码分支合并时。同时还涉及最佳实践检查、代码可维护性评估等。

Swyx :  所以它超越了 CI（持续集成）的范畴？

Itamar Friedman：是的。而测试主要关注功能验证。我们把这些统称为代码完整性（Code Integrity），不过这是另一个话题。

说回测试，让我用自动驾驶领域做个类比。一些创业公司在做高速公路自动驾驶，另一些在做城市自动驾驶。我们看到高速公路自动驾驶的进展更快，比如已经快达到 L4 水平了，远超自动驾驶。虽然两种场景都需要测试和验证，确保在道路上的行为正确，但城市环境的复杂度可能需要完全不同的技术方案。我认为在 AI 编程工具领域也存在类似的情况。

其实如果我是 Wix，看到 Bolt 的产品我会有点担心，因为 Bolt 的确在颠覆这个领域，在这种面向最终用户的产品中，UX/UI 极其重要。特别是对那些不懂开发的用户来说，他们需要一个流畅的界面。我觉得这也是为什么 Cursor 做得很好的原因，我虽然不了解他们的具体技术实现，但他们的用户体验确实很棒，很大程度上是因为他们开发了自己的 IDE。

但如果你要开发“城市级”的 AI，也就是处理更复杂的企业级场景，就会发现测试和代码审查变得极其重要。拿集成测试（Integration Testing）来说，我猜测用户用 Bolt 构建的主要是独立应用，也许 bolt 追踪的愿景是提供一个全面的解决方案，也许最终“高速公路级”和“城市级” AI 公司会互相渗透对方的领域，但在初期，这种差异是明显的。比如集成测试，在企业软件中极其重要，但对 bolt 目前的场景可能没那么关键。

总的来说，测试循环和代码验证，无论是功能测试还是代码审查，在两种场景中都很重要，但方式和重要程度不同。对于处理复杂企业级场景的“城市级” AI 来说，这些要求会更高，需要更多样化的解决方案。

03.

Bolt 的
Task Decomposition

Itamar Friedman：我在使用 Bolt 时注意到你们在错误处理方面做了很多工作，包括错误捕获和自动修复。同时我也发现你们采用了任务分解（Task Decomposition）的方法，这是业内一年前就开始流行的概念，但你们的实现非常出色，你们具体是怎么做的？

Eric Simons：这要从我们的基础架构说起。前面提到我们从 0 开始构建操作系统，这一点很关键。因为像 Cursor 这样在用户本地环境运行的工具，需要面对无数种不同的操作系统配置，可能出现各种难以预料的错误。

而 WebContainer 的优势在于提供了统一的系统镜像（System Image）。因为是我们从头构建的系统，所以可以在任何需要的层面实现监控，这是是我们开发 Bolt 时的重点工作。

我们在进程层面（Process Level）、运行时层面（Runtime Level）等多个层面都实现了完整的监控机制。这种全方位的监控在本地环境中理论上也可以实现，但要确保它在各种操作系统上都能可靠运行，难度会大得多。这就是为什么在使用 Bolt 时，无论是构建过程（Build Process）中的问题，还是 Web 应用运行时的故障，甚至是中间环节的任何错误，系统都能准确捕获。

目前我们的实现还比较基础，主要是因为产品才上线 90 天。我们还需要完善很多功能，也需要扩充团队。

但基本流程是这样的：当发现错误时，系统会显示出错位置，并提供"修复"和"忽略"两个选项。用户只需点击修复按钮，系统就会启动自动修复流程。

具体来说，我们的 agent 会收集所有遥测数据（Telemetry Data），包括应用程序状态、来自 Node.js 或浏览器的错误信息等，然后尝试解决问题。这个机制的效果相当不错。相比本地开发环境，有一个可靠的基础设施并能实现错误处理闭环，这是一个重大升级，我认为这也是产品成功的关键因素之一。

另外，你提到的任务分解确实是我们 AI agent 的核心功能之一。Claude 在处理 artifacts 方面做得很好，我们和其他人都借鉴了这种将任务按特定顺序分解的方法。

我们已经开源了 Bolt.new 的核心部分，用户可以查看系统提示（system prompts）等内容，也可以在本地运行。这个领域开源项目不多，我们觉得这么做会很有趣。看起来大家也很喜欢，有很多人在 fork 代码，添加不同的模型。

Swyx： 确实，我就为开源版本添加了实时语音功能，用于演示。我是基于一个已经添加了多 LLM 功能的 bolt.new 分支来开发的，听说你们要合并这些功能，这个整合过程应该会很有意思。

04.

如何做好
企业级的代码生成？

Alessio： Itamar，你们面对的可能是最复杂的场景，有时连在那里工作的人都搞不清楚如何运行系统。这对你们的性能有多大影响？你们是否大部分工作都在理解环境和依赖库的问题？我猜他们使用过时的语言版本、过时的库，甚至是一些从未公开发布的分支。在这些基础工作和 LLM 层面的工作之间，比例是怎样的？

Itamar Friedman：这也是我之前询问你们如何分解任务的原因之一。这确实很关键。比如技术栈是什么？软件有多复杂？在处理企业真实环境时，这些问题都很难厘清，就像是“城市级”场景。而 Bolt 虽然也支持安装各种组件，但是在一个相对可控的环境中，这样做很合理，因为可以缩小范围，更容易让东西正常运行。

我们面临多个维度的挑战。首先是软件安装问题，仅仅是让系统运行起来就很困难，因为我们服务于世界 500 强企业，很多都需要本地部署方案。

Swyx： 你们现在会提供多少种部署选项？

Itamar Friedman：我们统计了 96 种部署选项，因为涉及多个维度。例如，代码管理系统的连接方式就是一个维度，可能是 GitHub 或 GitLab，可能是云端或本地部署。还要考虑使用哪个模型，是调用 API 还是使用我们自己的模型。

我们目前四个专业模型：自动补全模型、对话模型、代码审查模型和代码嵌入模型。

说回部署方案，我们的 96 种部署选项中，主要部署维度包括：

1. 代码管理系统集成方式

1）系统类型：GitHub、GitLab

2）部署方式：云端、本地部署

2. AI 模型选择：API 调用或自研模型

3. 网络环境：完全气隔或 VPC（虚拟私有云）

4. 基础设施：是否使用 Kubernetes（容器编排平台）

在服务企业级客户时，这些都是必须考虑的因素。这仅仅是部署层面的挑战。在软件架构方面，我们遇到更多挑战。比如，一些公司采用了大量微服务架构，每个服务都有独立的代码库，导致存在数万个代码库。

我记得第一次面对企业级环境时的困惑：不知道从何处着手，不知道在哪里找东西。仅仅是建立有效的代码索引就是一个巨大的挑战。传统的索引方式已经不够用了，我们在博客中讨论过这个问题，我们现在有三个相关的开源项目并在持续发展。普通索引是不够的，关键是要让企业的技术主管参与索引过程。比如用不同的颜色标记代码库的质量等级：高质量库、低质量库、待废弃库、重点发展库等。只有将这些维度整合到索引中，企业才能真正用好工具，避免从最初的“太棒了”到后来的“好烦人”。

GitHub Copilot 是个很棒的工具，但根据数据显示，它在企业环境中的用户留存率只有 38% 到 50%。这个数字虽然不算太差，但确实有提升空间。主要原因是在处理远程代码库的上下文时存在困难。要解决这个问题，需要让组织的技术主管或开发者平台团队能够更好地控制和影响工具的使用方式。

举个例子，对于包含历史遗留代码的项目，如果仅基于这些可能已经过时的代码进行模型微调，就会产生重复过往错误的倾向。在 Qodo 中，我们允许技术主管通过 markdown 编写最佳实践指南，系统会将这些指南整合到推荐系统中，确保不会提供与最佳实践相悖的建议。这只是我们在处理软件版本迭代过程中需要考虑的众多因素之一。

Eric Simons：你们合作的世界 500 强企业是如何做 inference service 的？是使用 Azure OpenAI、AWS Bedrock、Claude 的服务，还是在自己的 GPU 上运行？这些顶级企业是如何应对这个问题的？

Itamar Friedman：这确实涉及多个层面的挑战。每家企业都有自己的选择，我认为没有标准答案。有些企业会明确要求："我们只用 AWS 和 AWS 的 VPC ，别无选择。"其中一部分可能会进一步强调："我们只接受来自 Bedrock 的模型。"

这对我们来说是个挑战，因为 Bedrock 上还没有优质的代码嵌入模型。这也是我们正在与 AWS 合作解决的问题之一。不过，如果客户愿意在 AWS VPC 上运行，并在 GPU 或 Inferentia（AWS 的 AI 推理加速器）上部署模型，我们的方案是可行的。

我们确实看到了多样化的部署需求：有的企业选择本地部署搭配自有 GPU，Azure 用户倾向于使用 Azure OpenAI，还有在 GCP（谷歌云平台）上运行但希望使用 OpenAI 的案例。虽然现在 GCP 上有 Gemini，甚至 Sonnet 也可用，但需求仍然多样。这些都构成了我们面临的挑战。坦白说，情况比我们最初预想的更复杂，我们花了几个月时间才开始理清这个 96 种部署选项的矩阵中的每一种情况。

还会有更多意外情况，比如“我们只用 AWS，但我们的 GitHub Enterprise 是本地部署的。哦对了，所以我们需要 Private Link 之类的连接。”每次都会遇到这样的情况。如果你想服务企业客户，就必须考虑这些。这很重要，我理解并尊重他们的观点。

Swyx： 这主要影响你们的架构和技术选择？

Itamar Friedman：确实如此，这对创业公司来说是个不小的挑战，因为我们希望能为所有用户提供各类模型的支持。这给我们的技术带来了很大压力。

我想简单提一下我们的 Alpha Codium。Alpha Codium 是一个开源工具，它能让用户在 CodeForce（知名编程竞赛平台）上轻松达到大师级水平（前 95% 的成绩），只需点击一个按钮即可完成。

我们的核心理念是将复杂问题分解为多个小模块。这种方法能显著提升模型性能，这也印证了当前的普遍认知：模型在处理小规模、明确的任务时表现更出色。

但其实即使称具备"系统 2 思维"能力的 o1 模型，在这类任务中也能从问题分解中受益，尽管它本身就具备推理能力。一个月前我们展示了这一成果。最近 OpenAI 宣布他们的 o1 在 IOI中达到了 93 百分位。而我们用 Alpha Codium 测试他们的 o1 预览版时，性能甚至更优。这说明即便是最先进的模型也还未完全实现真正的系统 2 思维。

Swyx： 也许它们确实还不是完整的系统 2 思维，仍需要一定的引导？

Itamar Friedman：我把这种情况叫做“系统 1.5"。这是个值得深入探讨的话题，我认为目前还没有看到真正接近系统 2 思维的 AI 。

回到技术层面，我们将 Alpha Codium 的问题分解原则应用到产品中，目标是充分利用各种顶级模型来解决这些子任务。我们希望用户能同时享受到 O1、Sonnet 和 Gemini 1.5 等模型的优势。但同时，考虑到一些世界 500 强企业对数据隔离的严格要求，我们也需要开发自己的专有模型。

支持如此多样的模型确实具有挑战性，这也是为什么我们认为流程工程（flow engineering）、将问题分解成不同模块很重要。因为当人们处理一个大问题时，每个模型都需要非常不同的 prompt 才能正常工作。但当我们把大问题分解成小任务后，prompt 的重要性就会降低。

作为一家创业公司，在尝试不同部署方案、最大化模型价值等方面面临诸多挑战。我们通过任务分解来缓解这些问题。这也是我很想了解你们经验的原因。我们的部分工作是开源的，欢迎参考。

Eric Simons：很有意思。对于 Bolt 项目而言，由于我们之前的业务是在防火墙内部署，我们也在思考类似的问题。特别是在推理服务方面，由于缺乏先例，我们有很多问题想请教。

我很欣赏你们的开放态度。在 AI 领域存在太多炒作，很多公司选择闭源开发，过度营销但缺乏实质内容。这对整个行业的创新发展其实是不利的。相比之下，你们开源实用代码供他们人学习和使用的做法，才是正确的方向。

Swyx： 你们对当前有什么特别关注的趋势吗？

Itamar Friedman：回到我们最初讨论的话题：软件世界是由规格（specs）、测试（test）和代码（code）构成的。我看到两个主要趋势：一是像 Bolt 这样重新思考整个开发环境的创业公司；二是不同公司在规格、测试和代码三个维度上的侧重点。

我认为 Bolt 处在规格和代码的交界处。从你们的演示可以看出，你们试图让描述不仅仅停留在代码层面，而是希望创造更好的体验。而其他新兴的 IDE 更关注从测试到代码再到规格的转化。

另一个重要维度是目标用户群体：是面向“高速公路 AI”、面向开发者、非技术人员还是企业用户？不同的 ICP 会导致产品在处理规格、测试和代码三者关系时采取不同策略。

我注意到越来越多的创业公司开始关注规格和测试，而不是纯粹专注于代码。随着 AI agent 的改进和 LLM 能力的提升，这种趋势会更明显。某种程度上说，测试就是可执行的规格，这两者可能会逐渐融合。

我一年多前就在探讨系统 1 和系统 2 的问题。现在随着 o1 的出现，人们又开始讨论系统 1。

我认为这个话题还会继续发酵，因为把 o1 等同于系统 2 思维是一个误解。这或许只是一轮炒作。真正通向系统 2 的道路在于 AI agent 。只有当它们更深入地理解自身环境，意识到自己的认知盲区时，我们才能真正达到系统 2 的层次。不过这需要更深入的讨论。

05.

开源战略

Itamar Friedman： 关于开源策略，我想分享一些想法。我们大多数工具都采用双线开发模式：开源版本和专业版本。这件事很难，所以我也很想了解 bolt 的策略。我的理解是，你们采用了一个相对中间态的方案：大部分代码开源，但部署和运行环境不开源。这有点类似 Hugging Face 的模式，但为什么要做这样的设置，直接使用部署好服务不是更好吗？

Eric Simons：我想引用 Geohot 在谈论 comma AI 时说过的话。当被问及为什么选择开源时，他说：“如果你对自己能做出最好的产品没有信心，那么也许应该选择闭源。”虽然我可能没有完全准确复述，但这个观点很有价值。

当然，这并不意味着所有东西都要开源，战略性考虑仍然重要。但我认为，在可能的范围内保持开放是有意义的。看到竞争对手使用你的代码，也许只是稍作修改，某种程度上也是一种认可。这实际上很健康，因为它能让团队保持警觉。当你们在总部看到这种情况时，一定在想："我们必须更加努力，确保保持领先地位。"这对团队来说是很好的激励。很多公司在缺乏竞争压力的舒适期后突然被颠覆。而开源能让你更早面对现实，逐步感受压力并及时调整方向。

以 Bolt 为例，开源版本迅速实现了许多用户需求的功能，如持久化聊天和检查点等，这些功能在第一周内就已经出现在开源版本中了。当用户问我们为什么不发布这些功能时，我们会很直接承认：“我们正专注于维护服务器和 GPU 运营。”但这很棒，因为社区成员做得很好，这确实给了我们很大启发。比如说，如果我们要推出这些功能，我们可以观察他们的 UX 模式，了解什么是好的，什么是不好的。

从竞争角度看，我们的核心优势是 WebContainer 技术，目前市面上还没有真正的竞品。虽然 WebContainer 在浏览器中运行，但要实现完整功能，比如从 NPM 安装包、处理 CORS 跨域请求、连接数据库等，都需要服务器端的代理或加速。所以我们实际上是在把 WebContainer 作为一种服务来销售。

我们选择开源 Bolt 核心组件的一个主要原因是，我们认为会有更多这样的，基于浏览器的 AI Code Generation 体验，就像 Anthropic 在 Claude 中做的 Artifacts 那样。

Swyx： 补充一点，Artifacts 其实使用了 web containers。

Eric Simons：我觉得他们现在用的是自己的方案。不过确实有很多这个领域的从业者，包括 AI 实验室和创业公司，都对 web containers 表现出极大兴趣。我预计在未来几个月会有更多机构宣布采用这项技术。

Itamar Friedman： OpenAI 发现用户没有按预期方式使用他们的模型，于是开发了 ChatGPT，现在 ChatGPT 几乎已经成为 OpenAI 的代名词。对于 bolt 来说，今天 Bolt.AI 是不是已经成为整个公司的核心业务了？而不再有 Stackblitz 和 bolt 的区分了？

Eric Simons：你说得很对。最初我们只是觉得 Bolt.new 这个产品很有趣，可能会有人感兴趣。我们预期相当保守，认为如果第一个月能增加几十万美元的 ARR 就已经相当惊人了。我们同时也在为其他可能性做准备，因为一些早期用户希望将 WebContainer 整合到他们的产品中，有点类似 Bolt 的应用场景。但实际情况是，我们在这两个方向都看到了需求。

Bolt 的发展轨迹确实很像 OpenAI 或 Anthropic 的战略路线。就像 OpenAI 同时提供 ChatGPT 和 API 一样，我们也采用了这种方式，也看到了相似的结果，只是目前收入结构确实明显偏向 Bolt 这边。

Itamar Friedman：如果要给建议的话，我认为你们有三个选择：一是专注发展 Bolt，二是聚焦 web container，三是筹集约 10 亿美元融资同时推进两条线。这不是玩笑话。我认为如果不选择第三条路，就必须在前两者之间做出取舍。因为在竞争压力下同时推进两个方向，需要强大的资金支持。这很具有挑战性，虽然也许你们能做到。现在的市场环境下，确实有公司即便没有成熟产品也能筹集到超过 1 亿美元融资。

Eric Simons：很中肯。现在的挑战在于预测发展方向。在最初几周，当我们和投资者分享数据时，大家都觉得很振奋：首先突破 50 万，然后达到 100 万。通常创业公司在 TechCrunch 发布报道后会经历一段低迷期，但我们还没有看到增长曲线下滑。现在已经过去六周，我们对发展趋势有了更清晰的判断。

Itamar Friedman：现在市场上有几十家类似的公司，他们的数字都很漂亮，就像我在 Bolt 身上看到的潜力。但要保持这种优势，我觉得需要保持专注。比如 Wix 正在颠覆这个市场，而你们选择开源了部分技术。我相信他们也在开发 container 相关的技术，你们需要应对这种竞争。

说到开源，当我们发布 Alpha Codium 时，有位创业者朋友私下问我：“你们为什么要开源这个项目？”

开源让其他人更容易复制。不过我的看法是，对我们而言，Alpha Codium 就像是 GPT-1 。我同意开源有助于产品改进和社区建设，但 OpenAI 在 GPT-3.5 阶段选择了闭源。这也是我们的考虑之一。Alpha Codium 目前处于类似 GPT-1 的阶段，要达到 GPT-3.5 的水平还需要大量工作。

Eric Simons：这让我想起 GeoHot 的话：想要胜出，唯一的选择就是比其他人更努力。这意味着打造最好的产品，创造最佳体验。开源某种程度上像是破釜沉舟，但它也能赢得很多信任和支持。

Itamar Friedman：看看 Salesforce ，他们正在向 agent force 转型。这种转型是可能的。

06.

商业化与增长

Swyx： Bolt 的增长速度还在加快，似乎现在每天有 10-20 万的 ARR 增长？

Eric Simons：是的，每周的数据都令人震惊。我们正在分析流量来源：是 TikTok 的效应吗？我们看到大量口碑传播，这不仅仅体现在推荐数据上。直接流量很大，TikTok 和 YouTube 带来了可观的用户。

这在创业者、SaaS 建设者、独立开发者，乃至整个开发者社区都引起了轰动。我们的团队也很出色，员工们甚至在周末加班解决问题。产品反馈非常积极，就像今天有人在推特上说，他们第一周没能成功使用，6 周后再次尝试就感觉太棒了。

产品本身、AI agent ，还有底层模型比如 Sonnet 都有了显著提升。仅仅是更新了新的 agent 和 Sonnet，转化率就有了巨大提升。

3 周前我们聊天时，日均 ARR 增长约 10 万美元。而这周每天达到了约 50 万美元，这个数字令人难以置信。今天我们创造了新的流量记录，这种增长态势让我感到震惊。

Alessio： 我前两天第一次使用了 Bolt，让我惊讶的是，它在寻找最简实现方案方面表现得很好。比如我要求创建一个活动 RSVP 页面，它就做出了一个婚礼 RSVP 系统。作为开发者，我本能的做法是创建一个独立的管理界面，先搭建前端框架。但 Bolt 采用了更简便优雅的方案：在顶部添加管理视图切换按钮，每个页面配备内联编辑功能。这种方式同样实用，，因为减少了文件数量，对模型来说可能更简单。我很好奇，这种精简优雅的设计有多少是模型自主决策的，又有多少是通过你们的 prompt 引导实现的？

Eric Simons：很大程度上要归功于模型本身。有趣的是，如果要量化这个效果：基础模型能带来约 10 倍的性能提升，底层模型的优劣差异极大。在此基础上，通过提示工程和多代理方法等技术还能额外获得 3-4 倍的提升。

所以我觉得，我们的成功和我们的核心技术负责人紧密相关，他叫 Dominic Elm ，来自德国，是公司的创始工程师之一。在加入 Stackblitz 之前，他专注于机器学习领域，曾开发过类似 Google Colab 的在线机器学习 IDE。虽然 2016 年这个市场还不成熟，但他积累了丰富的模型训练经验。过去一年我们深入 AI 领域的工作都由他主导。

我认为很多功劳都归功于 Dom 独特的视角：他既深入理解我们的技术，尤其是作为 WebContainer 开发负责人，又精通这些模型的工作原理。无论是提示工程还是多代理系统的开发，都需要这种深厚的复合背景。我们团队中其他成员也具备类似的跨领域经验，这让我们能挖掘出更多潜力。在 Web 应用开发领域，我很少看到其他团队能达到这种水平。这可能是因为我们的团队虽小但经验丰富，能够更快地把各个要素串联起来。

Swyx： 这可能正是“筹集十亿美元？建议的潜在问题所在。你们的精简运营反而成了优势。

Eric Simons：完全正确。当然，从 0 增长到 6 周内拥有 2-3 万客户，我们确实需要扩充客户支持和成功团队等非工程岗位。但我们在 2021 年就看到过：盲目扩张反而可能伤害公司，因为人员管理会变得异常困难。对规模足够大的公司来说，扩张确实必要。但对我们而言，循序渐进的团队发展策略效果更好。这次我们会采取类似的方法，只是节奏稍快一些。这也是我给创业公司的建议：尽可能按需缓慢地扩张。

Swyx： 我觉得你处在一个独特的位置谈论“获得 PMF 之后怎么办”这个问题。第一步通常是招募数据科学家，因为需要从大量不同客户的数据中发现规律。你要开始理解客户流失情况、客户细分和数据扩充。在那次会议中，你提到了一个很有趣的观点：因为你们长期面向企业销售，所以你们实际上已经为企业销售建立了完整的体系，但这套系统并不适用于以开发者为中心的自下而上方法。

Eric Simons：是的，这是公司历史上首次主要面向非开发者群体销售。我们过去的经验和操作手册基本都不适用了。最近有人给我们提出了一个很好的观点：我们现在是一家 B2C 公司，运营方式需要相应调整。

首先这意味着要全方位跟踪数据。正如你所说，需要专人全天候分析数据，了解用户画像，识别重点保留的目标用户群体。对于那些不属于目标客户群的流失用户，我们也能坦然接受。

企业软件开发的门槛要低得多，这也是我们在 Stackblitz 中发现的。你提到，作为一家创业公司，很难实现本地部署，这确实没错。但一旦做到了，这就像是进入了应许之地，因为世界 500 强公司能开出很大的支票。

在面向企业销售时，网站上的一些细节并不那么重要。当然，你会关注企业联系表单的转化率，但真正重要的是人际接触点，比如季度回访电话会议。这需要一整套运营体系，包括：

• 招募销售工程师提供一线安装支持

• 设计客户成功保障方案

• 处理数据访问限制带来的挑战（我们无法直接查看企业客户实例的使用情况）

• 建立关系以获取客户分享的遥测数据

• 评估客户满意度和使用成效

服务好企业客户是一门艺术，我们已经在这方面取得了成功。但这与 B2C 业务完全不同。现在作为一家公司，我们正在调整重点，更关注数据分析等方面。

幸运的是，对我和联合创始人来说我们之前的公司是做 B2C 的，主要销售网络开发课程。现在我能够重拾那些经验，重新打磨营销技能。我们正在开展电子邮件营销和直播等活动。

Alessio： Bolt 是如何制定定价策略的？我注意到你们有五个不同的价格层级，都是基于 token 和容量。对普通消费者来说，他们可能根本不需要理解 token 的概念，你们最初是如何设计这个定价结构的？后续又有什么改进计划？

Eric Simons：当我们在 2017 年刚推出 Stackblitz 时，是面向企业市场的。我们在 2018、2019 年左右尝试过给产品定价，但很长一段时间都是免费的。后来我们推出了 9 美元的基础方案，有点像 Costco 的 1.5 美元热狗，一个象征性的低价，作为引流，并不是主要的收入来源，主要是为了吸引那些需要更多存储空间和私人项目的用户。

当我们推出 Bolt 时，虽然预期会有大量用户注册，但没想到会迎来如此巨大的增长。第二周我们就意识到，9 美元的定价可能是除了 Copilot 外最便宜的 AI 编码工具，但我们已经被支持 support tickets 淹没了。这是典型的供需失衡：用户迅速消耗完 token，却无法购买更多，并且 9 美元能提供的推理能力实在有限。

这里有个关于 Copilot 和 Bolt 的有趣对比：当用户使用 Copilot 时，它输出的上下文很有限，因为它们试图最小化 context。这有点像 Netflix 一样，付一次费用之后就可以无限观看，早期的 AI 产品都倾向于采用这种“ all you can eat” 的模式，因为会考虑到是不是设定某些限制之后就会带来负面的用户体验。但这个模式的问题在于，他们没有特别强的动力让产品变得更好，低价策略不鼓励厂商提供更丰富的上下文信息，而实际上上下文越多，AI 能做的就越多。

这正是 Bolt 的独特之处：我们提供尽可能完整的上下文。这就是为什么你可以直接要求它"做一个 RSVP 网站"，它就能完成，因为它能获取整个应用程序状态的上下文。相比之下，如果你在 Copilot 上提出同样的要求，可能最多只能得到一个创建按钮的 React 组件。

用户开始反馈说想购买更多 token，于是我们团队紧急调整策略。我们将基础价格翻倍，因为 9 美元确实不足以支撑实际使用需求，这个价位也与市场其他产品相当。然后我们增加了 50、100 和 200 美元的高级方案。

除了固定订阅费用外，用户还可以额外购买 token，这种按使用量计费的模式现在占公司收入的 20-30%。用户真的在用这个工具工作，特别是网络开发机构。以前他们需要支付设计师费用，将设计转换成代码，现在使用我们的工具，效率提升显著。

有些故事很神奇，比如有个开发者接到当地面包店的网站制作需求，报价 1000 美元。30 分钟后就交付了成品，客户非常满意，因为这种项目通常要花几个月时间。

Alessio： 这确实改变了人们的预期。以前如果有人在 30 分钟内完成网站，我会怀疑是否只是复制了旧项目。但现在使用这些工具，速度快已经成为常态。更重要的是价值交付。这也解释了你们的定价策略：用户要么选择每月 20 美元的基础版，要么选择每月 1000 美元的专业版。中间的 50 美元档位似乎很尴尬，因为它既不适合轻度用户，也不够重度用户使用。所以在固定价格之上提供按需服务是很合理的。

Eric Simons：关于 50 美元的方案，实际上有相当多的用户。我认为这个价位对开发者来说很合适，足够他们在一个月内生成所需的组件和设计。

Bolt 的定价策略比较新颖，但我认为随着 AI 技术的进步，类似 Bolt 这样的产品将会越来越普遍。回到 Copilot 的对比，早期的问题在于，即使提供更多上下文，模型本身的能力也不足以充分利用。但现在情况完全不同了，LLM 已经可以理解和利用大量的上下文信息，生成出完整的应用程序，这是一个技术拐点，所以我们才会采用这种定价策略——给模型输入大量上下文信息，发挥其全部潜力，尽管这会提高成本，需要更高的定价，但因为用户可以用 Bolt 实现前所未有的效率提升，他们也会愿意付更高的价格。

举个例子：我们最早的重度用户之一是一位在泰国银行软件公司担任产品经理的女士。她开发了一个叫 viralhooks.ai 的工具，用于帮助用户制作病毒式传播的 TikTok 视频，通过分析现有热门视频的卖点来辅助创作。在 Bolt 推出前一周，她在 Upwork 上发布这个项目，一位乌克兰开发者报价 5000 美元，工期三个月。这个报价对这类应用来说很合理。但在 Bolt 推出后，她只花了 50 美元、一两周时间就建好了一个精美的应用。从 5000 美元、三个月到 50 美元、一周时间，这种转变令人震惊。

有人说我们的定价太夸张，但事实是我们现在甚至还没有真正盈利。任何了解优质软件开发成本的人都能看出这里的价值：成本降低 99%，交付速度提升 5 倍。我认为我们是第一批通过实际收入证明这一点的产品之一。

这个成绩也引起了 VC 的关注。其中一家顶级 VC 公司在看到我们的数据后评论说，他们从未见过如此惊人的现象：用户愿意为这种服务支付 200 美元档位的费用。这在 AI 领域是前所未有的，主要得益于新一代模型的强大能力。

Swyx： 这正是我之前讨论的 AI 能力与定价匹配的观点。我之前发布的图表中提到，OpenAI 将通用人工智能（AGI）划分为五个级别：Chatbots、Reasoners、Agents、Innovators、Organizations。每个级别对应不同的价格区间：20 美元对应 ChatGPT 级别，200 美元是你们现在的位置，然后是 2000、20000、200000 美元。每个层级都有其合理性。比如我认为 BrightWave 的定价就高于 ChatGPT，因为它提供了更多价值。

Eric Simons：我认为这是 AI Code Generation 等领域的一个重要突破点。在过去三到六个月里，AI 系统的能力和效率提升显著，产品价值比三六个月前高出许多，我们可能会看到更多类似的创新产品出现。像 Bolt 这样的产品已率先证明了这一点，未来将有越来越多的企业利用 AI 系统，通过这些应用场景提升效率和创造更高价值，这种趋势是不可避免的。

Alessio：Bolt 的定价模式可以说是基于每次查询的价值来定的。比如给普通用户讲故事不会收取 2000 美元，但对于开发产品的客户，收费自然要高得多。当然，确定合理的价格点仍然具有挑战性——需要平衡我们能收取的价格和客户能获得的价值。

Swyx： 我觉得你在设计系统方面做得非常到位。开源版本和现有版本的 Bolt 一个主要区别在于你在设计系统上投入了大量精力，大多数功能一推出就有很好的视觉效果。但用户还需要完整的后端支持，这方面有什么特别的挑战或发现吗？

Eric Simons：确实。在将 Bolt 推向市场时，我们最初的思维还停留在面向开发者的阶段，认为这只是一个原型工具，用户会下载代码自行部署。但早期用户测试让我们认识到部署的重要性。正如你特别提到的，后端功能，比如登录和认证系统，必须是产品的有机组成部分。

用户来到 Bolt 最核心的需求，就是能够构建一个具备后端和收费功能的完整应用。我们的核心用户之一 Mauricio 提出了一个非常关键的观点，他说：“每一个应用，我和其他社区用户想要在 Bolt 中构建的，都必须满足三大要素：数据库、身份验证（auth）和支付功能。” 这三大功能缺一不可。除此之外，还有管理后台（Admin Dashboard）。现在我们在这些方面都做得不错。

Swyx： 就像每个数据库都需要一个类似 WP-Admin 的管理后台。

Eric Simons：没错。比如我们在前面提到的 Viralhooks 的例子，她现在使用 Firebase 处理身份认证和数据库功能。目前，Firebase 和 Supabase 是两大表现非常出色的工具。而我们现在面临的问题是，用户仍然需要手动操作：他们必须去 Supabase 手动创建一个实例，然后再返回到 Bolt 中继续使用。而与 Firebase 配合时的流程也是类似的。这些产品各自有其特点和复杂的操作步骤，对吧？

Swyx： 也许可以考虑一种方式，Boltbase？

Eric Simons：是的，我们最初设想让 Bolt 能够自动完成这些配置步骤，因为这些平台都提供了相应的 API。

Swyx： 我会更进一步，建议准备预热好的实例直接分配。虽然实际上不是无服务器架构，但可以给用户一种无服务器的体验。在用户启动应用时直接分配预热好的实例。

Itamar Friedman：这是个很好的想法。

Eric Simons：对，就是在后台维护一个 Firebase 实例池。

Swyx： 可以是一个、十个或一百个实例，具体数量待定。更广泛地说，这也是我们在通话中想探讨的：当你实现了 PMF 后，除了投入时间理解客户、做数据分析、优化运营、调整定价和控制成本外，还需要思考下一个增长阶段是什么。虽然我在那次通话中主要扮演协调者角色，可能没能充分推动这个讨论，但我认为必须继续突破边界。我很想听听你对此的想法。

Eric Simons：我认为我们已经解决了很多紧急的 P0 问题，看到一些关键突破点。但这仅仅是开始，只是修复了一些明显的问题。

从根本上讲，很多人来到这里的目的就是加速从想法到上线的过程。但现在流程中有很多繁琐的步骤，比如需要去 Firebase 或 Supabase，手动启动实例、运行迁移、添加数据表等。这些事情其实完全可以通过 agent 自动完成，应该直接集成到系统里。部署也是同样的问题：现在需要用户创建 Netlify 账户并手动操作。我们计划将托管功能内置到产品中。我一直在和 Netlify 的 Matt 讨论这个可能性，因为他们提供白标服务方案。因为用户只想建网站，不想关心底层细节。

Swyx： 这意味着你们也要涉足域名注册业务了？

Eric Simons：想象一下几个月后的场景：用户说“我想做个 RSVP 网站”，系统会问“你想要什么域名？这里有 10 个可用的 .com 域名供选择。”用户选定后，系统自动完成购买、DNS 配置，然后直接进入建站环节。系统问：“我们开始构建这个网站吧？这个初始设计看起来怎么样？” 你确认无误，然后系统问：“可以推送到正式环境吗？” 你再次确认。——全程不用离开产品界面。

07.

市场空白与机遇

Swyx： Itamar 是第一个将你们比作“新一代 Wix”的人。我之前从未这样想过。Wix 是一家市值 100 亿美元的公司。你们的发展方向是什么？现在还有选择的余地。

Eric Simons：根据用户反馈，我认为他们的需求甚至超出了 Wix 能提供的范围。市场上存在一个巨大空白：让非工程师能够构建更复杂、高质量的软件和网站。即使是简单的婚礼网站，我们的方案也能让构建过程更快更容易。

回到我和联合创始人 Albert 的初衷，我们一直热爱在网络上创造。即使在 Stackblitz 还只是一个技术 IDE 的时候，这就是我们希望 13 岁时就能拥有的工具。而现在有了 Bolt，这更是令人兴奋，看到人们能够构建复杂而出色的网络应用，这就是我们的愿景。

Swyx： 还有一个我想探讨的角度是编程语言的问题。你们目前非常偏向 JavaScript。我们之前聊过很久关于 Python，甚至 Ruby。这些语言重要吗？上一代的网站构建工具大多是基于 Ruby，还有一些是 PHP。我们是否要捕捉这些市场？还是说坚定地押注 JavaScript？

Eric Simons：我们当然对其他语言感兴趣。我们的 WebContainer 已经对 Python 和 C++ 提供了基础支持。不过从实际情况来看，编程语言其实只是附属因素，不是核心关键。

Swyx： 还涉及到生态系统的问题。比如，最终我希望得到一个代码库，让我可以聘请开发者来完成那些 Bolt 无法完成的工作？

Eric Simons：说得对。从这个角度看，JavaScript 和 Node.js 生态系统已经非常庞大且成熟，很容易找到开发人才。我认为唯一的局限可能在于某些专门的功能只存在于 Python 或其他语言的库中，比如数据科学和机器学习领域。不过目前我们还没有看到太多这样的需求。

这更像是 Replit 的通用方法：他们启用真实的虚拟机，可以运行任何语言。我记得他们最初也是从 Python 服务开始的。说起来，我还没有尝试过他们新推出的基于代理的功能。

Swyx： Replit 集成了数据库、在线托管等所有构建所需的功能。我觉得你们和他们处于正面竞争。

Eric Simons：你不是第一个这么说的人。我也很想看看最终的方向会如何发展，但我认为关键的挑战在于保持专注。

如果你的目标用户是开发者，你需要明确地为他们提供解决方案；但我们的定位却是非开发者，这两个方向的需求是有区别的。

另外，即使是在专注某种语言或生态系统时，也存在很大挑战。因为在将想法变为上线产品的过程中，有太多可能出错的环节。而改进这个体验的核心，就是如何高效地处理这些错误。一个有效的解决办法是构建一个庞大的常见错误数据库，未来甚至可以基于这些错误进行系统微调。如果我们专注于单一的生态系统，那开发速度会快很多；但如果尝试支持多种语言或生态系统，事情就会变得复杂而缓慢。

而且，开发者通常不需要高度精简、无缝的用户体验，而我们的产品目标恰恰是为非开发者提供极简且高效的解决方案。所以，这正是我们与其他平台的主要区别：我们坚定地专注于构建 Web 应用的生态系统，而不是分散精力去支持所有语言和工具链。

我很好奇这一切会如何发展。特别是微软的动向值得关注。如果说谁最有能力将虚拟机、代码编辑器和 AI 整合在一起，那就是微软了。他们拥有云服务（Azure）、VS Code、GitHub Codespaces，还与 OpenAI 和 Anthropic 合作，开发了 Copilot。我敢说他们一定在开发一些重要项目。

排版：杨乐乐

延伸阅读