Eric Simons：我們公司叫做 Stackblitz，Bolt.new 是我們的產品。Bolt.new 上線僅一週，使用者量就達到了 Stackblitz 過去 7 年積累的 2 倍。這個資料連我們自己都大吃一驚。

Bolt 這個專案其實在今年初就有了雛形，雖然之前沒怎麼對外透露，但在年初時我們就嘗試過接入一些頭部大模型。不過當時即便用上了 RAG ，但 code generation 的質量和效能上還是差強人意，所以專案暫時擱置了一段時間，直到我們看到最近幾個月新模型的表現，尤其是新一代模型在 程式碼生成 領域的突破，讓我們看到了產品化的希望，這也是 Bolt 專案重啟的契機。

過去 7 年中，Stackblitz 一直專注於為開發者提供線上 IDE，但隨著技術演進和需求發展，我們之前建立的整個使用者體驗流程在現在看來已經不太合適了。開發 Bolt 時，我們提出了一個全新的思路：如果站在 AI Code Generation 的技術高度，重新定義開發工具，會是什麼樣子？

經過團隊深入討論，我們決定採用一個相對激進的策略——從零開始打造新產品。這樣可以更好地驗證我們的想法。如果市場反響好，就繼續深耕；如果效果不理想，及時調整方向也不會有太大損失。這就是 Bolt 誕生的過程。

Itamar Friedman：我們公司之前叫做 Codium AI，現在改名為 Qodo，我們的模型名字還叫做 Codium。上一期播客是在我們產品釋出兩個月後錄製的，當時我們已經確立了剛才討論的願景。我們認為軟體開發的核心是規格、測試和程式碼。其中我們特別關注測試環節，因為我們認為解決了測試問題，就等於解決了軟體開發的核心痛點。

程式碼測試是一個很寬泛的領域，涉及多個維度。從微觀角度有單元測試（Unit Testing）、元件測試（Component Testing）；從宏觀角度還要考慮測試規模的分級。此外還有迴歸測試（Regression Testing）、冒煙測試（Smoke Testing）等不同型別。

同時，我們開發了新的 Agent Tools ：開源版本稱為 peer agent，商業版本叫 Qodo Merge，還有一個即將推出商業版的開源工具 CoverAgent，有些使用者已經在不知情的情況下，體驗過我們在大型開源專案中提供的自動化程式碼審查功能。隨著這類案例的積累，我們還會推出更多 AI agent 工具。

第一年我們採用了完全的 PLG 策略，實現了 100 萬安裝量。2024 年我們開始探索商業化，推出了 Teams 版本，現已有上千個團隊在使用，幾個月前，我們開始推出企業版，這些內容在 Qodown 最近釋出的文章中都有討論。

我們啟動了企業級業務，已經有多家財富 100 強公司成為我們的客戶。隨後我們完成了 4000 萬美元的 A 輪融資。這筆資金將主要用於開發更多 AI agent 工具，這也是我們未來的發展重點，但短時間內我們不會涉足 IDE 開發。

Swyx： 所以你們不打算開發 fork VS Code ？

Itamar Friedman：如果要做，我們可能會選擇 fork JetBrains 的產品，這樣更有特色。

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 實現了首次線上收入。

1. 重新定義軟體開發的工具，我認為 Bolt 就屬於這類產品， Vercel  和 Replit 也屬於這類；

2. 對現有工具的改進升級，比如 Cursor 其實就是在改進 IDE，Codeium 在做類似事情。

所以不同的 AI coding 產品之間其實是有差異的，不應該被簡單比較。

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、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。

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 伺服器成為可能。這意味著我們可以在瀏覽器環境中啟動一個完整的伺服器。這是一個很重要的技術突破。

Eric Simons：是的，完整的 Node.js 功能。這意味著網路應用可以透過程式設計方式控制自己的 URL。這實現了一個關鍵能力：讓網路構建網路的底層基礎已經具備。

當時我們和 Chrome 團隊的人討論這個想法時，他們都表示不確定。但有些事情必須親自實踐才能驗證。我們花了幾年時間研發，最終在 2021 年釋出了 web container 的第一個 beta 版本。

在和 Chrome 一起探索這件事的過程中，我們發現測試平臺效能和能力主要有兩種方式：

這些都是很好的壓力測試用例。如果平臺有任何缺陷，在這些應用場景中就會被發現。遊戲和 IDE 開發者會發現這些問題——對普通應用來說是作業系統層面的問題，對我們來說則是瀏覽器層面的問題。

我們不斷在 Chromium 的 bug 追蹤系統中提交問題。他們團隊可能都在想“這些人是誰？”但他們的配合真的很棒。比如讓 Chrome DevTools 支援作業系統級別的除錯——這原本不是它設計的用途。他們幫助我們不斷突破技術邊界。

這些改進最終會幫助到了整個生態系統。現在有很多不同型別的瀏覽器應用都能透過 Chrome DevTools 進行更可靠的除錯，這也和我們和網頁遊戲開發者們進行的持續壓力測試有關係。一開始連 Chrome 團隊都對此持懷疑態度，但我們最終還是在 2021 年推出了第一個 WebContainer 測試版。

Itamar Friedman：確實精彩。補充一點，我認為大多數程式設計輔助工具都需要這種測試迴圈，我還要補充的是有些情況下程式碼審查也需要這種過程。

Itamar Friedman：程式碼審查（Code Review）包含多個層面，比如 PR（Pull Request，程式碼合併請求）審查，這發生在程式碼分支合併時。同時還涉及最佳實踐檢查、程式碼可維護性評估等。

Itamar Friedman：是的。而測試主要關注功能驗證。我們把這些統稱為程式碼完整性（Code Integrity），不過這是另一個話題。

說回測試，讓我用自動駕駛領域做個類比。一些創業公司在做高速公路自動駕駛，另一些在做城市自動駕駛。我們看到高速公路自動駕駛的進展更快，比如已經快達到 L4 水平了，遠超自動駕駛。雖然兩種場景都需要測試和驗證，確保在道路上的行為正確，但城市環境的複雜度可能需要完全不同的技術方案。我認為在 AI 程式設計工具領域也存在類似的情況。

其實如果我是 Wix，看到 Bolt 的產品我會有點擔心，因為 Bolt 的確在顛覆這個領域，在這種面向終端使用者的產品中，UX/UI 極其重要。特別是對那些不懂開發的使用者來說，他們需要一個流暢的介面。我覺得這也是為什麼 Cursor 做得很好的原因，我雖然不瞭解他們的具體技術實現，但他們的使用者體驗確實很棒，很大程度上是因為他們開發了自己的 IDE。

但如果你要開發“城市級”的 AI，也就是處理更復雜的企業級場景，就會發現測試和程式碼審查變得極其重要。拿整合測試（Integration Testing）來說，我猜測使用者用 Bolt 構建的主要是獨立應用，也許 bolt 追蹤的願景是提供一個全面的解決方案，也許最終“高速公路級”和“城市級” AI 公司會互相滲透對方的領域，但在初期，這種差異是明顯的。比如整合測試，在企業軟體中極其重要，但對 bolt 目前的場景可能沒那麼關鍵。

總的來說，測試迴圈和程式碼驗證，無論是功能測試還是程式碼審查，在兩種場景中都很重要，但方式和重要程度不同。對於處理複雜企業級場景的“城市級” AI 來說，這些要求會更高，需要更多樣化的解決方案。

Eric Simons：這要從我們的基礎架構說起。前面提到我們從 0 開始構建作業系統，這一點很關鍵。因為像 Cursor 這樣在使用者本地環境執行的工具，需要面對無數種不同的作業系統配置，可能出現各種難以預料的錯誤。

我們在程序層面（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 分支來開發的，聽說你們要合併這些功能，這個整合過程應該會很有意思。

Alessio： Itamar，你們面對的可能是最複雜的場景，有時連在那裡工作的人都搞不清楚如何執行系統。這對你們的效能有多大影響？你們是否大部分工作都在理解環境和依賴庫的問題？我猜他們使用過時的語言版本、過時的庫，甚至是一些從未公開發布的分支。在這些基礎工作和 LLM 層面的工作之間，比例是怎樣的？

Itamar Friedman：這也是我之前詢問你們如何分解任務的原因之一。這確實很關鍵。比如技術棧是什麼？軟體有多複雜？在處理企業真實環境時，這些問題都很難釐清，就像是“城市級”場景。而 Bolt 雖然也支援安裝各種元件，但是在一個相對可控的環境中，這樣做很合理，因為可以縮小範圍，更容易讓東西正常執行。

我們面臨多個維度的挑戰。首先是軟體安裝問題，僅僅是讓系統執行起來就很困難，因為我們服務於世界 500 強企業，很多都需要本地部署方案。

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 編寫最佳實踐指南，系統會將這些指南整合到推薦系統中，確保不會提供與最佳實踐相悖的建議。這只是我們在處理軟體版本迭代過程中需要考慮的眾多因素之一。

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 之類的連線。”每次都會遇到這樣的情況。如果你想服務企業客戶，就必須考慮這些。這很重要，我理解並尊重他們的觀點。

Itamar Friedman：確實如此，這對創業公司來說是個不小的挑戰，因為我們希望能為所有使用者提供各類模型的支援。這給我們的技術帶來了很大壓力。

我想簡單提一下我們的 Alpha Codium。Alpha Codium 是一個開源工具，它能讓使用者在 CodeForce（知名程式設計競賽平臺）上輕鬆達到大師級水平（前 95% 的成績），只需點選一個按鈕即可完成。

但其實即使稱具備"系統 2 思維"能力的 o1 模型，在這類任務中也能從問題分解中受益，儘管它本身就具備推理能力。一個月前我們展示了這一成果。最近 OpenAI 宣佈他們的 o1 在 IOI中達到了 93 百分位。而我們用 Alpha Codium 測試他們的 o1 預覽版時，效能甚至更優。這說明即便是最先進的模型也還未完全實現真正的系統 2 思維。

Itamar Friedman：我把這種情況叫做“系統 1.5"。這是個值得深入探討的話題，我認為目前還沒有看到真正接近系統 2 思維的 AI 。

回到技術層面，我們將 Alpha Codium 的問題分解原則應用到產品中，目標是充分利用各種頂級模型來解決這些子任務。我們希望使用者能同時享受到 O1、Sonnet 和 Gemini 1.5 等模型的優勢。但同時，考慮到一些世界 500 強企業對資料隔離的嚴格要求，我們也需要開發自己的專有模型。

支援如此多樣的模型確實具有挑戰性，這也是為什麼我們認為流程工程（flow engineering）、將問題分解成不同模組很重要。因為當人們處理一個大問題時，每個模型都需要非常不同的 prompt 才能正常工作。但當我們把大問題分解成小任務後，prompt 的重要性就會降低。

作為一家創業公司，在嘗試不同部署方案、最大化模型價值等方面面臨諸多挑戰。我們透過任務分解來緩解這些問題。這也是我很想了解你們經驗的原因。我們的部分工作是開源的，歡迎參考。

Eric Simons：很有意思。對於 Bolt 專案而言，由於我們之前的業務是在防火牆內部署，我們也在思考類似的問題。特別是在推理服務方面，由於缺乏先例，我們有很多問題想請教。

我很欣賞你們的開放態度。在 AI 領域存在太多炒作，很多公司選擇閉源開發，過度營銷但缺乏實質內容。這對整個行業的創新發展其實是不利的。相比之下，你們開源實用程式碼供他們人學習和使用的做法，才是正確的方向。

Swyx： 你們對當前有什麼特別關注的趨勢嗎？

我認為 Bolt 處在規格和程式碼的交界處。從你們的演示可以看出，你們試圖讓描述不僅僅停留在程式碼層面，而是希望創造更好的體驗。而其他新興的 IDE 更關注從測試到程式碼再到規格的轉化。

另一個重要維度是目標使用者群體：是面向“高速公路 AI”、面向開發者、非技術人員還是企業使用者？不同的 ICP 會導致產品在處理規格、測試和程式碼三者關係時採取不同策略。

我注意到越來越多的創業公司開始關注規格和測試，而不是純粹專注於程式碼。隨著 AI agent 的改進和 LLM 能力的提升，這種趨勢會更明顯。某種程度上說，測試就是可執行的規格，這兩者可能會逐漸融合。

我一年多前就在探討系統 1 和系統 2 的問題。現在隨著 o1 的出現，人們又開始討論系統 1。

我認為這個話題還會繼續發酵，因為把 o1 等同於系統 2 思維是一個誤解。這或許只是一輪炒作。真正通向系統 2 的道路在於 AI agent 。只有當它們更深入地理解自身環境，意識到自己的認知盲區時，我們才能真正達到系統 2 的層次。不過這需要更深入的討論。

Eric Simons：我想引用 Geohot 在談論 comma AI 時說過的話。當被問及為什麼選擇開源時，他說：“如果你對自己能做出最好的產品沒有信心，那麼也許應該選擇閉源。”雖然我可能沒有完全準確複述，但這個觀點很有價值。

當然，這並不意味著所有東西都要開源，戰略性考慮仍然重要。但我認為，在可能的範圍內保持開放是有意義的。看到競爭對手使用你的程式碼，也許只是稍作修改，某種程度上也是一種認可。這實際上很健康，因為它能讓團隊保持警覺。當你們在總部看到這種情況時，一定在想："我們必須更加努力，確保保持領先地位。"這對團隊來說是很好的激勵。很多公司在缺乏競爭壓力的舒適期後突然被顛覆。而開源能讓你更早面對現實，逐步感受壓力並及時調整方向。

以 Bolt 為例，開源版本迅速實現了許多使用者需求的功能，如持久化聊天和檢查點等，這些功能在第一週內就已經出現在開源版本中了。當用戶問我們為什麼不釋出這些功能時，我們會很直接承認：“我們正專注於維護伺服器和 GPU 運營。”但這很棒，因為社群成員做得很好，這確實給了我們很大啟發。比如說，如果我們要推出這些功能，我們可以觀察他們的 UX 模式，瞭解什麼是好的，什麼是不好的。

從競爭角度看，我們的核心優勢是 WebContainer 技術，目前市面上還沒有真正的競品。雖然 WebContainer 在瀏覽器中執行，但要實現完整功能，比如從 NPM 安裝包、處理 CORS 跨域請求、連線資料庫等，都需要伺服器端的代理或加速。所以我們實際上是在把 WebContainer 作為一種服務來銷售。

Swyx： 補充一點，Artifacts 其實使用了 web containers。

Eric Simons：我覺得他們現在用的是自己的方案。不過確實有很多這個領域的從業者，包括 AI 實驗室和創業公司，都對 web containers 表現出極大興趣。我預計在未來幾個月會有更多機構宣佈採用這項技術。

Eric Simons：你說得很對。最初我們只是覺得 Bolt.new 這個產品很有趣，可能會有人感興趣。我們預期相當保守，認為如果第一個月能增加幾十萬美元的 ARR 就已經相當驚人了。我們同時也在為其他可能性做準備，因為一些早期使用者希望將 WebContainer 整合到他們的產品中，有點類似 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 的水平還需要大量工作。

Itamar Friedman：看看 Salesforce ，他們正在向 agent force 轉型。這種轉型是可能的。

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 的，主要銷售網路開發課程。現在我能夠重拾那些經驗，重新打磨營銷技能。我們正在開展電子郵件營銷和直播等活動。

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 能做的就越多。

使用者開始反饋說想購買更多 token，於是我們團隊緊急調整策略。我們將基礎價格翻倍，因為 9 美元確實不足以支撐實際使用需求，這個價位也與市場其他產品相當。然後我們增加了 50、100 和 200 美元的高階方案。

有些故事很神奇，比如有個開發者接到當地麵包店的網站製作需求，報價 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 美元，但對於開發產品的客戶，收費自然要高得多。當然，確定合理的價格點仍然具有挑戰性——需要平衡我們能收取的價格和客戶能獲得的價值。

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 討論這個可能性，因為他們提供白標服務方案。因為使用者只想建網站，不想關心底層細節。

Eric Simons：想象一下幾個月後的場景：使用者說“我想做個 RSVP 網站”，系統會問“你想要什麼域名？這裡有 10 個可用的 .com 域名供選擇。”使用者選定後，系統自動完成購買、DNS 配置，然後直接進入建站環節。系統問：“我們開始構建這個網站吧？這個初始設計看起來怎麼樣？” 你確認無誤，然後系統問：“可以推送到正式環境嗎？” 你再次確認。——全程不用離開產品介面。

Eric Simons：根據使用者反饋，我認為他們的需求甚至超出了 Wix 能提供的範圍。市場上存在一個巨大空白：讓非工程師能夠構建更復雜、高質量的軟體和網站。即使是簡單的婚禮網站，我們的方案也能讓構建過程更快更容易。

回到我和聯合創始人 Albert 的初衷，我們一直熱愛在網路上創造。即使在 Stackblitz 還只是一個技術 IDE 的時候，這就是我們希望 13 歲時就能擁有的工具。而現在有了 Bolt，這更是令人興奮，看到人們能夠構建複雜而出色的網路應用，這就是我們的願景。

Eric Simons：我們當然對其他語言感興趣。我們的 WebContainer 已經對 Python 和 C++ 提供了基礎支援。不過從實際情況來看，程式語言其實只是附屬因素，不是核心關鍵。

Eric Simons：說得對。從這個角度看，JavaScript 和 Node.js 生態系統已經非常龐大且成熟，很容易找到開發人才。我認為唯一的侷限可能在於某些專門的功能只存在於 Python 或其他語言的庫中，比如資料科學和機器學習領域。不過目前我們還沒有看到太多這樣的需求。

這更像是 Replit 的通用方法：他們啟用真實的虛擬機器，可以執行任何語言。我記得他們最初也是從 Python 服務開始的。說起來，我還沒有嘗試過他們新推出的基於代理的功能。

Eric Simons：你不是第一個這麼說的人。我也很想看看最終的方向會如何發展，但我認為關鍵的挑戰在於保持專注。

另外，即使是在專注某種語言或生態系統時，也存在很大挑戰。因為在將想法變為上線產品的過程中，有太多可能出錯的環節。而改進這個體驗的核心，就是如何高效地處理這些錯誤。一個有效的解決辦法是構建一個龐大的常見錯誤資料庫，未來甚至可以基於這些錯誤進行系統微調。如果我們專注於單一的生態系統，那開發速度會快很多；但如果嘗試支援多種語言或生態系統，事情就會變得複雜而緩慢。

而且，開發者通常不需要高度精簡、無縫的使用者體驗，而我們的產品目標恰恰是為非開發者提供極簡且高效的解決方案。所以，這正是我們與其他平臺的主要區別：我們堅定地專注於構建 Web 應用的生態系統，而不是分散精力去支援所有語言和工具鏈。

我很好奇這一切會如何發展。特別是微軟的動向值得關注。如果說誰最有能力將虛擬機器、程式碼編輯器和 AI 整合在一起，那就是微軟了。他們擁有云服務（Azure）、VS Code、GitHub Codespaces，還與 OpenAI 和 Anthropic 合作，開發了 Copilot。我敢說他們一定在開發一些重要專案。

延伸閱讀