Chris Anderson 是 CouchDB 和 Couchbase 早期的重要貢獻者，也是 Relaxed 公司的創始人之一。在 NoSQL 剛剛興起的時候，Chris 就處於這一潮流的中心，深刻影響了開發者對資料分發和“離線優先”架構的認知。Chris 痴迷於 JavaScript CouchApps 以及致力於把網路的控制權交還給使用者，還合著了《CouchDB：權威指南》（O'Reilly 出版社）一書。
不過，以前的資料庫大佬如今已經轉向了先的領域：Vibe 程式設計，並開發了 Vibes.diy 和 Fireproof。其中 Vibes.diy 是一款 AI 驅動的應用構建器，使用者無需豐富的程式設計知識就可以根據自己的喜好建立應用程式。 Fireproof 則是一個氛圍程式設計資料庫，在瀏覽器中執行，無需任何配置即可為任何應用新增協作功能。
兩個專案目前均已開源：
https://github.com/VibesDIY/vibes.diy
https://github.com/fireproof-storage
近期，Chris 做客 Ghangelog 訪談節目，與兩位總編 Jerod Santo、Adam Stacoviak 聊到了 CouchDB、創業，以及這段漫長旅程如何最終引領他走向一個全新的正規化：Vibe 程式設計。
“15 年來，我們在很多方面都專注於同一件事，而如今做的氛圍程式設計方向，也是這種專注的延伸。”Chris 進一步解釋道，“程式設計這事太難了，而它本不該這麼困難，比如說我程式設計就比較溜，所以我希望每個人都能掌握這門技能。”
他提到，15 年前負責 CouchApp 專案，目標就是把 CouchDB 打造成一款無伺服器應用程式執行時，只需要往裡面投放 JS 程式碼就能執行。
“那你搞成了嗎？”面對這樣的犀利提問，Chris Anderson 說道，“這個專案曾經，或者說直到現在，也仍在幫助很多缺少基礎設施支援的人們完成開發，比如為農村醫療保健或者私人俱樂部編寫應用程式。同樣地，我發現很多人也在用 Vibes 做類似的嘗試。”
“跟其他的 NoSQL 資料庫相比，你們的技術簡直漏洞百出。這能叫 Web 規模？玩具規模還差不多。你們的記憶體對映檔案就是垃圾，使用者只會選擇自己信任的資料庫。認真點的用例，他們都只會使用 Couchbase。”Chris 直言不諱。
Jerod：CouchDB 的最初締造者應該是 Damien Katz 吧，或者說它是一群人的共同成果？維基百科頁面上列出了不少人，但我們不太瞭解具體細節。
Chris：CouchDB 基本就是 Damian 獨力完成的。他當時在搞 Lotus Notes 專案，但不滿於必須暫停全域性才能進行同步……因此他發明了一種資料結構，能夠平等實現流式同步。
Jerod：那你是怎麼參與進來的？
Chris： 我剛開始用 CouchDB 來爬網。那是很早的事情了，為此我強迫自己學習 Erlang，就是為了能寫個除錯日誌功能。接下來我慢慢掌握了整個技術棧，就一發不可收拾了。
Jerod：那你具體是怎麼做的？主動聯絡 Damian 說“嘿，我想來幫忙”或者是“咱們一起創業吧”？
Chris ： 這一切都始於 IRC（因特網中繼聊天）。我當時在 IRC 上閒逛……我記得 Damian 應該是來波特蘭參加 OSCON 大會的，而且之前我們就已經在網上聊過不少。後來 Damian 又邀請朋友們到他在北卡羅來納州阿什維爾的家中作客，就是這次我說“咱們一起創業吧”。而我的主要工作除了編碼，就是擔當法務。
期間發生了很多事情，但最讓我印象深刻的是，我們無意間孵化了 Node.js。比如 Isaac Schlueter 和 Ryan Dahl 就經常在我們的辦公室裡晃盪，還有 Mikeal Rogers 那幫人，他們總愛鼓搗各種 npm……但就是在與這群大牛共事的過程中，我們孵化出了 PouchDB 這樣的專案，將 JS 提升到了新的水平。那段經歷真的很有趣。
Jerod：我第一次接觸 CouchDB 是透過 Geoffrey Grosenbach 編寫的 CouchDB PeepCode。他為專案初步奠定了不錯的基礎。當時我只是個初出茅廬的 Ruby on Rails 開發者，剛剛開始接觸 JS 生態，也稍微探索了一下資料庫領域，充滿了好奇心……因為 Rails 能大大降低資料庫介面卡的切換門檻，但當時還沒人這麼做……總之我對各種資料庫都很感興趣，而 CouchDB 跟我之前用過的資料庫截然不同。而且，Geoffrey 留下的餘韻至今令人難忘。
Chris： 傳奇人物。
Jerod：沒錯，絕對的傳奇人物。CouchDB 專案成了精英們的聚集地……事實證明這是真的。縱觀整個發展歷程，這個專案確實吸引到了很多才華橫溢的參與者。
Chris： 可別忘了，2008 年到 2009 年那會是 API 革命的開端。當時行業發現，完全可以把資料庫放在 REST API 背後，而當時 JSON 幾乎還沒有成型。總之我們都對 XML 感到失望，開始嘗試編寫類似單體式伺服器的東西……而等到這個專案逐漸成熟，雖然只是 2011 年，一部分早期採用者就已經在做微服務了。那真的是股翻天覆地的變化。
Jerod ：那這門生意做得順利嗎？畢竟你為它專門開了家公司，生意怎麼樣？有沒有遇到什麼困難？
Chris： 生意不錯，但困難也不少。某種程度上講，我們塑造了一種文化認同，就像我曾說過的，這讓我們有機會跟 Membase 合併，那邊有一大批非常聰明的成員。他們瞭解市場，知道怎樣推動一家初創公司走向成功。Steve 和我就在那邊學到了管理收入的技巧，現在我們都是 Vibes DIY 的董事會成員。另外，雖然花了一段時間，他們最終也還是成功上市了，大概是我離開的五年之後……
Jerod：那從離開 CouchDB 到創立 Vibes.DIY，你經歷了哪些轉變？
Chris： 我也研究過各種資料庫技術，參與過 FaunaDB 的開發，直到現在仍然在做維護——必須誇一句，FaunaDB 的完整性是真的強。後來我又去了麥肯錫，那段經歷也挺有意思的，我全家甚至都不敢相信。期間我遇到了另一位傳奇人物 Jason Smith，他也負責一個人託管 Couch npm。總之我很開心能透過麥肯錫接觸到現實世界，因為我由此意識到自己根本不懂什麼叫基礎設施。對於矽谷這幫搞軟體的，基礎設施獲取起來很容易——啟動個虛擬機器，或者呼叫一個 S3 儲存桶就行，但這在傳統行業裡完全是無法想象的奢侈選項。在工作過程中，我意識到應當打造一種能夠隨時隨地執行的資料庫技術，在擺脫許可束縛的情況下開展創新。而 Vibes DIY 也繼承了這一理念。
我和 Protocol Labs 的 Mikeal Rogers 團隊一起開發了一個深度技術專案，他們在不可變資料結構及內容定址方面做過大量研究。我加入那個團隊一段時間，也感受到了它的潛力，還構建了一套能在瀏覽器中執行的嵌入式資料庫，並使用端到端加密來實現多使用者同步。這也是 Vibes DIY 的源頭所在。那款資料庫名叫 Fireproof。
我今天講的幾乎所有內容都是開源的，包括 Fireproof。它的獨特之處在於能夠為每項操作提供加密資料來源。它就像是執行在瀏覽器當中的迷你區塊鏈，超輕量級、不依賴網路就能直接執行……也就是說在複製過程中，只知道自己獲取到了什麼、而不用擔心資料本體那頭有什麼問題。
Jerod：你說的加密資料來源，應該怎麼理解？
Chris： 這可以追溯到 Rich Hickey 的 Clojure 和他們跟我們開發 Couch 時共同開創的不可變資料結構。這種資料結構的特點在於，在不變數這個前提下，也就是不可變的後備儲存，那麼整個體系的各個環節都需要創新。Fireproof 及其使用的 IPLD 資料結構會強制執行這項約束，其唯一允許使用的指標就只有內容的雜湊值。也就是說，所有內容均由其自身的雜湊值進行定址。
也就是說能操作的就只有已經寫入的內容。這意味著每次進行類似 B 樹的更新時，要麼得頻繁攪動資料、產生大量不必要的寫入操作，要麼需要解決一些非常棘手的問題，具體可以參考 Alan Shaw 等人的研究。總之，這方面涉及大量工作，包括構建一個搜尋樹，比如 B 樹，但無論是按固定順序還是隨機順序放入記錄，最終總能得到相同的根雜湊值，由此讓快照擁有穩定的識別符號。如此一來，副本不必在所有地方都機械保持一致，而能夠進行最佳化、以高效方式進行復制，並確保最終仍能達成相同的效果。
Jerod：Fireproof 實現了你剛剛提到的這些概念嘍？
Chris： 更重要的是，Fireproof 讓這些概念變得更易用了。說起技術，特別是資料庫技術，人們常會提到“footgun”，就是說只要稍不留心就會釀成大禍的情形。我對這項技術的要求就是別那麼脆弱，最好能讓接觸過程式設計、但學得不精的使用者也能搞定。
Jerod：所以你的重心放在怎麼降低風險上。
Chris： 差不多，事實也證明這確實是個好方向，因為……
Jerod： 因為很多人都想試試氛圍程式設計。
Chris： 更進一步說，有了大語言模型和 GPT 等等，我們就相當於有了無限多這種“學藝不精”的開發者。
Jerod：確實如此。只要買得起 token，那就可以無限提供這類開發者。你開發的 Fireproof 是為了降低人們的創新門檻，那 Vibes DIY 在其中扮演什麼角色？
Chris： 我們本打算等 Fireproof 技術成熟之後再推向市場，再發布類似自動駕駛汽車的黑匣子記錄器這類用例。這些都是非常嚴肅的場景，而基於內容定址的不可變資料結構正好派上用場。但真正需要它的人並不多，所以也不會在乎 Fireproof 有多便利，反正跟自己沒多大關係。
有人在 Discord 上跑來跟我們說，“我已經 15 年沒程式設計了，但我用 ChatGPT 和你們的 API 成功開發出了開箱即用的鼓機程式。”這讓我們意識到，氛圍程式設計確實能幫助到很多人。
於是我找來了自己的老朋友 Marcus Estes。我們相識差不多 20 年了，他是那種“老油條”，總有辦法把事情做成。他知道哪裡有機會，也知道如何把握。我也一直在關注氛圍程式設計，覺得這事“有趣也挺可愛的。”但他突然意識到“不只是有趣，是必須得做”，於是我們就義無反顧開始了。總之，這段經歷真的很有意思。
最大的不同其實是我孩子們的反應。我之前總跟他們聊 Merkle CRDT 之類的東西，他們都聽煩了，但現在他們總愛搶我手機，看我在幹什麼。
Jerod：那氛圍程式設計到底能開發什麼樣的應用呢？
Chris： 我還挺受啟發的——我也在嘗試找到氛圍程式設計能夠實現的“最小公分母”……答案是，我用到了 ChatGPT Canvas 和 Claude 元件，思考如何讓普通人，就是那些還不熟悉 JS 技術棧、或者不太瞭解 React 及其完整工具鏈的人們，如何用這種方式構建最佳介面和邏輯。如果認真觀察，就會發現整個流程甚至沒有提到“部署”，而是“釋出”。我們在 Vibes DIY 中也是這麼做的：在設計一項功能時，每當發現需要引入一個新概念，就儘可能不去引入。總之越簡單越好。
市場反響也讓我們更有信心。我剛從 Redner ATL 回來，那是在亞特蘭大舉辦的科技大會。我們的展位前排起了長隊，擠滿了人。他們可能根本沒聽說過氛圍程式設計，或者是聽說過還沒試過、要麼就是覺得現有工具還是太複雜了……但我們鼓勵大家上手試試，而且會把成果做成“貼紙”，人們發現往往 90 秒鐘就能做出一款應用。
Redner ATL現場，圖源x
Adam：那這“貼紙”是幹嘛用的？上面會列印二維碼，掃了之後就能下載安裝之類？
Chris：我們採用的是近場通訊晶片。我其實是在類似“火人節”上了解到這種方式的，當時有人會在美甲裡嵌入 NFC 晶片。
Jerod：那如果我把“貼紙”帶回家，要怎麼使用呢？比如說已經把某些資訊嵌入進去了，接下來要咋辦？
Chris： 只要把它貼近手機，就能得到一條可開啟的 URL 地址。對我們來說，這其實代表著一種歸屬權。程式碼已經在那裡了，重要的是怎麼用起來……以往非程式設計師往往沒有思路，但如果能在觀眾離開展位後也能隨身攜帶自己的程式碼，那後面會有更多朋友關注並來到我們的展臺。
Adam：他們還可以訪問自己剛剛氛圍程式設計方式開發的程式碼嗎？ 我是說，他們還能不能繼續開發、再做完善？
Chris ： 沒錯，大多數觀眾都是帶著手機來到我們展位的，所以我們會優先考慮移動端體驗。但如果沒帶，也可以用我們提供的手機，或者展位上的筆記型電腦。大家仍然可以獲得“貼紙”，仍然可以把它掃描到自己的手機裡……只要來到現場，大家都可以點選“Remix”按鈕、輸入程式碼、或者以聊天的方式要求把表單中預載入的 Remix“變成粉紅色”。總之，想調整哪個部分都可以，非常簡單。
那次經歷真的很棒，我們都玩得很開心。我在亞特蘭大吃完午飯，在回來的路上對手機說：“我想拍幾張照片，幫我把照片裡所有人的臉變成桃子。”結果一次就成功了。大家都覺得這很搞笑，所以我就把成果展示出來。當時我們跟 Netlify 共用一個展位，大家也是現實中的好友……Netlify 一位負責人 Sean 還把孩子帶來了，她看了我們的成果，還說“我想變成一隻貓”。
Adam： 純氛圍生成，這就是網際網路的力量。
Jerod： 好像真的把世界變成了 GeoCities。
Chris： 而且是個可編寫、可調整的 GeoCities，隨時可以檢視它的原始碼。
Jerod：那完全是基於 Web 平臺的嘍？還是說你們的程式碼還有其它執行方式？
Chris： 我還是想主要關注 Web 平臺。我小時候曾經在黑白屏的 Mac 機上用 HyperCard，我希望有更多人能體會到這種樂趣……但我又意識到，氛圍程式設計的很多受眾其實會有種“要麼完全按我想要的形式做，要麼乾脆不用”的感覺。對我們來說，面向各種平臺的方案已經很多了，所以我們決定單純構建 React 應用——本質上就是在使用 Web 執行時（也就是瀏覽器的功能），幫助使用者能像發 TikTok 短影片一樣輕鬆表達自己的靈感。也就是說，如果開發應用比製作 TikTok 短影片還簡單，那會怎麼樣？這就是 Vibes DIY 希望找到的答案。
Jerod：這個想法我很喜歡。我想 Adam 和我剛剛討論的就是這樣的可能性，而且蘋果已經允許在手機上執行本地模型還有 Xcode。也許未來我們可以輕鬆在手機上構建並部署自己的 iPhone 應用。更重要的是，這些成果是一次性的、可以只為自己服務，甚至不需要面向其他人釋出。當然，釋出、側載之類仍然受到平臺限制，還有很多問題需要處理。但有了 Web，只要一條 URL 就能實現基本功能了，這真的很棒。
Chris： 就是這意思。
Jerod：我想再問問“貼紙”的問題，貼紙裡嵌入的資訊就是指向實際執行位置的 URL 嗎？還是說裡面也包含程式碼？
Chris： 就是一條 URL。只要有了 URL，我們的服務層就能發揮作用——整個服務層也很簡單。現在市面上有很多氛圍程式設計工具，但它們還是為專業人士打造的，會使用完整的 Next.js 應用模擬出專業的輸出效果。我們用的仍然是現成的商品模型，唯一的區別就是提供切換機制——對 AI 感興趣的開發者得可以嘗試各種不同模型，瞭解它們之間有什麼區別。而如果想輸出成果，只需要向 Vibes 下令、讓它編寫 app.jsx 檔案就行，僅此而已。總之，我們的目標是讓 AI 變得更有趣、更實用也更充滿活力。
大家開發的應用程式將擁有官方在瀏覽器中編寫程式碼時使用的相同 API 金鑰。只要點選“Demo data”演示資料按鈕，它就會填充剩餘的部分，比如生成一份待辦事項清單，或者開發一款應用。之所以做這個專案，是因為我希望把應用開發的週期縮短到 90 秒，可能搞清楚這應用是幹嘛的都比這時間長。
Jerod：那假設我用 90 秒做了一款演示程式，效果不錯，玩得也很開心……那我能進一步擴充套件、延伸、構建這款應用嗎？還是說就到此為止了？
Chris： 這也是我們最關注的問題之一，這東西必須得有用。我們提供一個標準庫，確保所有應用都能在瀏覽器端順利執行，還可以透過雲端遠端同步給其他使用者以方便協作。就是說只需要按下“複製”按鈕，你的程式碼都會出現在剪貼簿中，供你隨意拖放到任何地方。成果甚至可以在其他氛圍程式設計工具裡使用，比如說配合別的工具做進一步擴充套件。也許大家可以把 10 個 Vibe 放進同一款應用中……總之一切皆有可能。這是一款可塑性很強的軟體，初學者可以輕鬆上手，專業人士也不會覺得太過簡陋。
Adam：我剛試了試，可能是 Safari 的問題，我這邊顯示黑屏。
Chris： 那應該不是 Safari 的問題，而是 Claude 的問題，這裡多少有點運氣成分。Claude 確實是這樣，有時候會理解偏差，然後搞出一些莫名其妙的問題。必須承認，我們還有不少工作要完善。
那最好的辦法就是把提示詞再粘一遍，重新生成。這就是氛圍程式設計中的常態。這東西就是時靈時不靈的。
Jerod： 我也經常這麼做。還記得谷歌搜尋剛出來那會嗎，大家會先輸入搜尋詞，大致看看搜尋結果，如果不滿意就會翻第二頁、第三頁、第四頁。但我不一樣，我會瀏覽一下，發現結果不好就調整一下搜尋關鍵詞。在測大模型時也差不多，我會把同一個問題粘到四個模型裡，看看誰的答案最好、誰輸出答案的速度最快之類。我也可以把四個模型的輸出在腦袋裡彙總一下，拼湊出更完整的答案。所以我能理解，關閉選項卡、開個新選項卡、貼上提示詞再試一回。
Chris： 沒錯，我們也在認真考慮你的這種方法。我們想到也許可以同時測試三個版本，然後讓使用者從中挑出效果最好的那個……當然，我們也會盡量控制，畢竟複雜度每增加一點，都會把一部分不太熟練的使用者拒之門外。
Jerod：那成本呢？OpenAI 出的影片工具 Sora 就是這麼做的，根據使用者指定的迭代次數，經會生成兩個、四個甚至六個版本，但消耗的 token 也依次遞增。不過這對創意工具很重要，大家肯定是想同時看到四個不同的版本，從中選出最好的，而不是一遍遍嘗試，那樣就不直觀了。
Chris： 模型切換很重要，因為我自己也會比較 Claude 4 到底比 3.7 好了多少，或者如果換成 Codex Mini，是不是足以生成一個能良好執行、又不花裡胡哨的應用。比如說，GPT 模型就能生成精簡的應用程式，沒有任何工作的部分……而 Claude 4 會包含更多關於專案背景、透明度調節之類的個性化選項，還挺好玩的。
Jerod： 我是覺得 Claude 4 已經相當好了，至少足夠讓我滿意。其實不久之前我還挺懷疑的，但現在我真的服了。
不知道你們看沒看過 Simon Willison 那篇《從鵜鶘騎腳踏車看大模型 12 個月發展歷程》那篇文章？他一直在關注每個新出的模型，所以會用同樣的要求測試各種模型的效果。他要求模型編寫程式碼，生成一副鵜鶘騎腳踏車的 SVG 圖，並且把期間的所有細節都記錄下來。他會定期更新自己的測試結果，標明哪副圖是哪個模型生成的，還會給不同的影像打分。這篇文章真的讓我們看到了令人驚歎的進展。說回 Claude 4，我覺得它已經跨過了“我覺得不行”那道標準線，到了“可以用起來”的水平。我也不確定 3.7 到 4.0 之間究竟發生了什麼，但感覺 Claude 就像突然開竅了一樣。
Jerod：那你們提供系統提示詞工具嗎？
Chris： 整個專案都是開源的，大家可以去 GitHub 上的 Vibes DIY org，開啟 repo prompts.ts 檔案，看看我們到底做了什麼。之前我就提到，如果能像和人交流那樣跟大模型對話，少些技術元素、多些自己的需求，那生成的效果反而更好。
你想做的高爾夫開球預約工具就很典型。YouTube 上有一段很棒的搞笑影片，裡面提到有兩類 Vibe 程式設計師，一類對著 4000 行大模型文字和複雜的功能規範直犯愁，另一類則直接要求“給我做個 GTA，做 GTA 6。”
總體來說，我們不需要部署，只要按下那個大大的紫色按鈕，就可以完成釋出了。剛才我還在思考這個問題，所謂釋出，就是把幾百行 JSX 放進跟子域名關聯的 Cloudflare KV 當中。這樣在訪問這個子域名時，就會有相應的靜態 HTML，它本質上屬於執行時，其中包含所有包……之後它會透過 esm.sh 載入其他所需的包。這樣你就擁有了自己的應用程式……整個過程幾乎不需要花費任何託管費用，也幾乎不涉及任何服務費用，唯一的開銷就是應用程式呼叫的 AI 資源，所以得當心別讓它超出你的 token 配額。總之，它讓人們可以非常輕鬆地編寫出基於 AI 的應用程式。
Simon Willison 搞出來的就是騎腳踏車的鵜鶘，而我們則可以用自然語言快速生成一份結構化的待辦事項清單，列出接下來需要完成的事務。總之，每當升級或者更換新模型時，我都會執行這份清單……比如今早我說“帶孩子去參加夏令營”，它就把需要帶的東西：防曬霜、午餐之類都列了出來。
Jerod Santo: 那這些資訊儲存在哪裡呢？我輸入的資料都跑哪去了？
Chris： 所有內容都會儲存在 Fireproof 當中，那裡用的是 Merkle CRDT。也就是說它只儲存在瀏覽器的本地儲存內。Fireproof 的工作原理，就是把所有資料庫操作都當作 diff，跟在 Git 當中一樣。它是端到端加密的，之後是寫入——我們在瀏覽器中用的是 IndexedDB，因為它用 Uint8Arrays 時速度非常快……之後還可以透過 S3 儲存桶和 WebSocket 實現非同步複製。總之這部分單靠 Fireproof 就可以實現。
這項功能目前也被引入了 Vibes，就是說所有 Vibe 都是獨立的，因此特別適合那種病毒式傳播的 AI 體驗。但未來，所有 Vibe 都將採用類似 Google Docs 的安全模型。我們肯定不希望終端使用者先得掌握 Postgres 的逐行安全保障機制，或者被迫使用類似 where 子句這樣的語句來避免 bug……相反，應用內的就歸應用內。大家可以設定寫入許可權或者讀取許可權，但共享起來還是跟 Google Docs 一樣簡單。就是說在啟用這項功能之後，Adam 和 Jerod 就可以透過電子郵件邀請彼此加入自己的應用，比如商量打球那天帶什麼午餐。
Adam： 一切都在 Web 平臺上實現？
Chris： 沒錯，哪怕是從來沒接觸過程式碼、也沒部署過應用的使用者，同樣能不依賴任何設定完成應用的開發和部署。這一點很重要，畢竟如果使用者壓根沒聽說過 API，你肯定不要求對方提供 API 金鑰。
Jerod：每隔段時間都會出現某種爆款，你覺得 Vibes 能行嗎？
Chris： 這個嘛，我覺得你們的播客節目就是幫助我們破圈的鑰匙。實際上，我們的目標還是希望有更多人以更嚴肅的方式和工具進行氛圍程式設計。目前我們還沒有面向高階開發者的控制權、選項和細節，但後續肯定會去做。畢竟他們也會帶動那些不太熟悉技術的朋友嘗試編寫程式碼，並指導他們如何正確使用這些選項。
那如果你某個朋友就是想自己開發點什麼，或者一直纏著你幫他開發個什麼，你就可以推薦這款工具，告訴他“只要有靈感，我就能幫你輕鬆實現”。
Jerod：從這個角度來看，它很像是 GeoCities 或者 Glitch。當然，Glitch 最近調整了定位方針，但最初的感覺確實很像。Glitch 就是要引導人們先上手，然後慢慢學習。
Adam：那在非獨立的多人協作模式中，版本控制是怎麼實現的？
Chris：如果認真觀察之前的聊天內容，就能找到可改進的空間。比如說“我指的不是常規的高爾夫，而是想引入一些獨特的有趣規則”。Claude 會去重寫這些規則程式碼，這樣就有了一個略微不同的差異版本。整個過程還是可以在單一的聊天會話中完成，而且這還不算是 remix，只能算是普通的迭代。這時候如果回到相應的聊天中，就可以點選舊版本程式碼，系統顯示的舊版本內容。而螢幕上顯示的則是點選“釋出”之後的最新版本。如果新版本不好，那就可以隨時切換到舊版本……
在釋出之後，掃描貼紙並訪問的網址，在螢幕角落裡就會有一個“Remix”按鈕。點選這個按鈕，就相當於完成了分叉。我絕對沒有冒犯的意思，但我覺得自己是那種想法不夠周全的人，為了確保 Vibes DIY 始終朝著我的既定目標發展，我就會不停地分叉——這是種好用的笨辦法。
Jerod Santo: 哈哈，這傢伙不管說什麼都有自己的一套邏輯。那你到底是喜歡分叉，還是不喜歡？這要取決於你所謂的“笨辦法”到底是褒義還是貶義。
Chris： 呃，我覺得笨辦法有時候非常重要，因為我們總有想嘗試某些東西並進行 remix，但又不想被概念上的元素分散了心神的時候。這種情況下，笨辦法肯定是褒義的。
Jerod： 這就像釋出按鈕跟部署按鈕之間的區別。要 remix，不要 fork 分叉。畢竟這款產品更多面向的是普通人。
Chris： 沒錯，就是這個意思。
Jerod ：但這又會給另一些受眾帶來困擾……懂技術的人會找來找去，但就是找不到他們需要的“fork”按鈕。
Chris： 確實。但其實在底層，它也已經為高階應用做好了準備，這裡有 Merkle CRDT、由標準的 React 元件構成、有著全部你需要的 TypeScript 註解……而且已經做好了規模擴充套件的全部準備。
Jerod： 我不禁想象如果把成果部署在 Cloudflare 上，帶有 HTML 檔案和一大堆鍵值對後端；它的功能、業務和生產規模都很大，比如像 TikTok 那樣。Vibes 也能輕鬆擴充套件到那個程度嗎？
Chris： 只能說跟傳統需要虛擬機器或者各種複雜狀態的 CPU 方案相比，Vibes 的成本只是九牛一毛。比如說 Kubernetes 容器，我只會在記憶體實在不夠的時候才去租一個。但現在連這都不需要了，所有活動記憶體都處於邊緣使用者的智慧體當中。
Jerod： 那你能不能再深入解釋一下，之所以目前的這些酷炫目標能夠實現，靠的就是 Cloudflare 的幫助。這麼說來，Cloudflare 是個很有趣的平臺呀。
Chris： 其實我們的技術棧也正源自這種思維方式……不只是進入 KV 釋出流，還有 Fireproof 同步，都由 Cloudflare Workers 提供支援。如果只需要當前連線的客戶端列表，那這是種廉價租用記憶體的好辦法。所以在本質上，資料流代表的就是那些微波的加密資料差異，我們把它寫入到本地，透過 API 進行推送，而且使用者是完全無感的。它最終會成為 R2 儲存桶中的又一條記錄，並相應更新指向資料庫的指標。所以全部監聽該指標的人都會拉取最新資料。而且因為它屬於 CRDT，所以合併操作都具有彈性。
我還會考慮恢復機制。假設指標丟失了，只剩下檔案……那行之有效的辦法，就是直接載入所有檔案然後合併，這樣得到的結果就相當於從最新檔案開始往前讀取一樣。
Adam：為什麼要強調記憶體呢？為什麼必須放在記憶體當中？
Chris： 其實不一定，我們只用 S3 儲存桶也可以實現。只是放在記憶體裡，執行速度會更快一些。
Adam：但是一定要這麼做嗎？還是說放記憶體裡單純更快？
Chris：其實就單純因為記憶體更快。我們本質上需要的是一個目錄、一個指向。從技術角度來分析，我們需要這些的真正原因，是因為它支援多寫入安全。假設你有一個 SQLite 資料庫，並打算實現這種架構——很多使用者真的有這種需求，即將 SQLite 資料段放進 S3 儲存桶，而後在瀏覽器中載入並查詢……這當然很好，但只要一涉及寫入，麻煩就出現了。這會要求我們進行某種定製，包括獲取預寫日誌、放入其中並管理由此帶來的各種衝突等等……這可是大有難度。但相反，有了 Merkle CRDT，我們可以替代大家處理這些合併操作。
因此，為了能夠支援多寫入安全，我們唯一需要引入的就是指向最新檔案的指標，也就是重建差異所必需的指標——它可以指向多個檔案。就是說在併發負載下，如果 50 個人都在同一起始狀態上寫入資料，且彼此之間未經協調……那現在我們也只需要一個 50 位元組寬的指標。在下次讀取時，會把這些資料拉進來合併，而後再寫回這個指標。也正因為如此，我們才能實現效能提升。
Jerod：那根據你的構思，到底是 Fireproof 作為核心，Vibes DIY 圍繞它而來；還是說 Vibes DIY 才是目標，Fireproof 是為它而生？
Chris ： 我感覺自己就像在駕駛千年隼號，其實也沒想那麼多，一路狂奔就完事了。
這兩種說法都成立，而且相互間並不矛盾。Fireproof 適合喜歡分叉的使用者，而 Vibes 適合那些至少是不想搞那麼複雜的使用者，越簡單越好。
Jerod：所以最終可能取決於你到底是專注實現某個點，還是要用無限的頻寬來支撐起像千年隼號那樣的超光速引擎？
Chris： 那這麼說的話，我們是 100% 專注於 Vibes 的。
從各個方面來講，這是因為 Fireproof 已經基本完成了。資料庫其實需要的從來都不是新功能，而是更強的功能，且應當持續釋出。所以在這樣的環境下，Vibes 獲得了一些很酷的新功能。我們添加了一項有趣的新功能——那種輕量化的機制。就像我之前說的，我不希望強迫人們搞清楚 API 是什麼、更不要說 API 金鑰了……比如說把 YouTube API 金鑰嵌入進來。
我們真正想要實現的，是把自己的播放列表轉換成 YouTube 畫面，或者是 Spotify 乃至其他類似的大眾媒體 API。而作為 Vibe 開發者，使用者應該不需要了解這些也能輕鬆實現。
Adam：目前賺錢對你們來說重要嗎？還是說暫時只關注把氛圍程式設計做好？
Chris： 最重要的是我們得先把事情做對……而且越是延伸思路，我們就越是興奮莫名。如果你是好奇用氛圍程式設計工具和資料庫後端構建應用需要花多少錢，那最入門級的訂閱是每月 25 美元加 25 美元——也就是每月 50 美元。我們還提供每月 5 美元的一體式套餐，適合那些只需要 R2 儲存桶的使用者。如果大家的需求足夠簡單，那肯定不需要整個 Kubernetes 容器來支撐自己的 Postgres 例項執行。這個價格只能給我們賺取微薄的收入，真正的成本仍然來自那些 token——無論是生成酷炫的漫畫圖片，還是解析待辦事項清單，抑或生成應用程式碼，都需要消耗大量 token。
但至少每月 5 美元就能讓大家用起來。如果能接受更高的價格，我們也提供價效比很高的按使用量計費機制。從長期來看，這樣的商業模式跟 YouTube 基本相當，比如我們以企業案例進行分析。
設想那些大型營銷機構，他們的宣傳內容基本就是“拍下您家中的我司產品，再用畫面中的產品替換掉自由女神像”之類。這樣的郵件列表瀏覽量大概在 10 萬級別……按消耗的相應 token 來核算，那你可能需要向我們支付 2 萬美元左右。但如果你只是個小孩子，想出了個很酷的方法，可以掃描自己的房屋結構再把它轉換成電子遊戲的關卡，那肯定就不需要花那麼多錢。不過二者的應用執行成本是一樣的，傳播速度也一樣快。在那樣的情況下，免費的增值模式就建立起來了。別人也可以隨意使用你的應用——比如生成一個簡單的關卡或者幾張圖片。但他們很快會用完自己的免費體驗 token……如果他們喜歡這種方式，那同樣每月支付 5 美元就能開始訂閱。總之，我們不僅要把它賣給開發者，還希望把它賣給那些想根據自己的想象力和腦洞做出探索、或者類似終端使用者那樣生成酷炫漫畫形象的群體。總之，哪怕你是個沒什麼錢的孩子，只要能製作出酷炫的遊戲關卡生成器、為我們帶來幾萬名註冊使用者，那我也希望能向你支付報酬，就跟 YouTube 一樣。
Jerod：說起來，“把房屋變成電子遊戲關卡”的產品出現了嗎？我是真感興趣。
Chris： 沒有，但總會有人去做。我想這東西遲早會出現的。現在高斯濺射的成本越來越低，在手機上就能跑得動。
Adam： 那具體該怎麼做呢？就像拍影片那樣在家裡走來走去，然後把結果上傳就行？
Chris： 我們一直希望自己能做到最好——說實在的，我們也算這個行業裡頗有經驗的老手了。但人的能力畢竟是有限的，恐怕我們的極限也就是把電吉他發明出來，至於搖滾樂……留給年輕人們去發明吧。
Jerod：這簡直是史上關於“我不知道”最動聽的解讀了。
Chris： 我的意思是，我們有可擴充套件的路線圖功能。所以我剛剛談到的還都只是瀏覽器執行時，它能做到很多事、也還沒有得到充分利用，特別是對那些還沒有真正發揮它極限的人們來說。路線圖機制是我們從 CouchDB 生態那邊學來的。本質上，Fireproof 就相當於執行在瀏覽器當中的 CouchDB 模型。大家應該經常看到 npm 的驅動方式，把所有包都儲存在 CouchDB 當中。每當有人上傳新包或者更改元資料和其他內容時，只需要配合訂閱資料庫 feed 的事件響應器就能執行不少繁重的工作，比如傳送電子郵件或者更新某個分析包。
同樣的，現在如果大家願意，也可以建立一個 Cloudflare Worker 來訂閱高爾夫資料庫。每當有人提交新的開球時間，使用者就能收到推送通知。我們的路線圖是透過 backend.js 檔案來實現這一點，而且此檔案同樣由模型來編寫。
Adam：是的，我之前壓根沒怎麼想到過這一點……要是有路線圖，真的幫助很大，能讓使用者知道自己接下來能做什麼。不只是各種新奇功能，像推送通知這樣的基礎實現也很酷。
Chris： 這些細節永遠無窮無盡。而且從本質上講，如果在流程中引入 backend.js，那它實際負責的就是把 API 這種複雜元素隱藏起來。這是我們沒辦法直接透過電子郵件或者瀏覽器釋出的部分，但可以把它放進後端，由後端來轉發這些訊息。
Adam：如果你的設想都成功了，會發生什麼？一年、兩年之後會是怎麼樣？
Chris： 目前開發應用程式的速度已經比創作 TikTok 短影片更快了。我想未來人們可能會在看到優秀的應用時右滑並長按啟動，於是會有越來越多優秀的應用實現病毒式傳播，在無數人的手機上跑起來。這種體驗跟目前的 Insta、TikTok 或者 YouTube 是類似的。它們體現的是使用者從程式設計中獲得的樂趣，這一點已經在亞特蘭大的科技大會現場得到了證實。
我自己剛接觸程式設計時，覺得世界上最酷的事情莫過於在 HTML 中修改一行程式碼、點選“重新整理”，然後新內容就出現了。我希望讓更多人體會到這種感覺，把成果分享給朋友……到那個時候，會有越來越多人意識到程式設計是件很酷的事情。
Adam：那你要如何應對潛在的欺詐，或者說在那個不受約束的世界裡，如果大家都習慣了分享和接受他人發來的 Vibe 應用，那該怎麼防範騙局？
Chris： 好在現在的安全保障技術還挺多的。我們這幫開發工具的構建者對於這類問題經驗還不太多，但如果大家以前做過社交媒體，就知道有哪些策略。總之，我們已經做出了一些基本的嘗試，比如限制內容的釋出範圍。我們會稽核釋出到主頁上的內容，所有分享都會受到一定限制。總之這就是社交媒體那套監管的相同邏輯，唯一的區別在於這次我們不是圍繞影片或者圖片，而是專注於 HTML。
我想強調的是，我們不會提供直接進入編輯器輸入內容的功能——這對我們來說當然不難，但我們認為使用者最好把程式碼複製到其他地方。我們不會讓 Claude 生成那些存在隱患的開箱即用程式碼，我們也只使用 OpenAI 的影像生成器。這樣我們的工作會更輕鬆。最終，我們希望對所有這些內容進行價值衡量，但要等產品成了規模之後才知道。
Adam：用更多 AI 解決這些問題，很有意思嗎？有了 AI，很多難題都有了更輕鬆的解法。
Chris ：AI 確實能夠更快地解決新問題，降低很多問題的處理門檻。但我還是希望透過目前這套單檔案應用 JSX 機制把問題隔離出去。另外，千萬不要低估單源策略的力量，網路瀏覽器確實讓很多問題都有了簡單解法。
Jerod ： 所以說，如果這件事做成了——我的意思是，現在大家最好就加入進來，學習如何成為 DIY 大牛了，對吧？就像那群早期入駐 YouTUbe 的人、早期入駐 TikTok 的人，他們是賺到過一波紅利的。但應用真的具備病毒式傳播的能力嗎？真能建立起廣大的受眾群體嗎？會有強大的分發渠道嗎？我知道你們才剛剛起步，所以網路效應可能還沒有顯現，但你們的產品裡有沒有幫應用吸引受眾的工具？
Chris： 之前我提到，從提示詞到應用釋出，整個過程只需要 90 秒。那在實際場景下，大家可能還需要額外的 90 秒來思考“這個應用好用嗎”，然後再點擊發布。點選之後，它就被繫結在 URL 上，發給誰誰就能訪問。至於內建功能，比如新聞推送、“為你推薦”頁面等等……我們後續也很期待逐個實現。
我們目前正在擴充團隊。想做這件事的朋友可以跟我聯絡，這絕對是片有趣的藍海，因為很多設計語言都已經成型了。我們甚至不需要去定義什麼是演算法推送。我們只需要讓它先起效，為世界帶來一種新的媒體物件。
就像製作影片一樣，製作應用也差不多。我們甚至別的計劃——前面我提到 Jason Smith，他是專門負責 npm 的。我昨天跟他聊過，他說“我最近一直在做影片生成相關的探索，我覺得可以……比如提供演示資料按鈕，幫使用者填充應用資料；還可以提供一個影片導覽按鈕，點選一下就能捕捉到人臉、進行口型同步再發到 TikTok 上，快速宣傳自己的應用。”
Jerod：很酷。那你們有沒有在物色新的工程師或者其他型別人才？
Chris： 肯定有啊，現在用 Vibes 肯定會有種很簡陋的感覺。畢竟我只是個 React 開發者，同時也擔任公司 CEO……你能想象一款產品的程式碼，有四分之三都是 CEO 寫的嗎？
Jerod：哈哈，這應該叫高管程式碼了吧？
Chris： 總之，對於那些技術狂人而且對於把所有細節都做好抱有很深的熱情，那肯定會從 Vibes 中發現我的各種錯誤、感覺失望。但我希望大家的技能水平在同一範圍之內，這樣可以共同認真思考如何修復這些問題，並逐漸形成最佳實踐。
Jerod：就是說 CEO 程式碼中的各個層級，都有相應最適合的經手人員要求？
Chris： 沒錯。
Adam：我感覺應該是受到了 WordPress 的影響，而且是積極的影響。我在開發這個高爾夫好友專案時，感覺就像個……電影導演。每款應用都有適合自己的特定風格，真的很不錯。
Jerod：那你們兩個之間有沒有共同點，比如說共同的設計美學追求？
Chris： 只能說，我們選擇讓自己與眾不同。我們沒有使用 Shadcn，並不是因為它不好，而只是想與眾不同。我們想擁有更多變化，讓 Claude 或者其他開發工具能更好地表達自己。其實我跟聯合創始人 Marcus 做過大量研究，比如藝術史方面的探索，類似“我們不想要合成波，那種風格已經過時了”之類。這些也決定了我們提示詞設計語言的諸多特質。
我們發現，80 年代義大利一所設計學院提出了所謂孟菲斯風格。我們嘗試著稍微描述了一下孟菲斯風格，並發現大模型的輸出相當不錯。這一切都可由使用者自由編輯。現在進入設定頁面，大家可以直接輸入自己的風格提示詞，比如說合成波風格。也可以切換到其他大模型，比如 DeepSeek——但在 DS 上，可能需要生成 10 次才能獲得一個可以執行的應用版本。
如果大家真的想深入研究，也可以直接訪問我們的 GitHub、分叉整個專案，然後修復我編寫的 React 程式碼。
Jerod：也就是說，只要大家願意，完全可以在自己的 Cloudfalre 賬戶上把整個 Vibes 專案執行起來？
Chris： 差不多吧。我們在設定上真的是敞開大門——透過 GitHub 登入之後，大家就能部署到我們的終端、使用我們的登入系統，甚至直接把它當成自己的專案。基本上，我們希望大家能夠成為 Vibes DIY 使用者，去執行一個分叉作為自己內部工作流程的一部分，且不必承擔完整技術棧帶來的繁重壓力。這個分叉只會在我們的後端上執行。當然，如果你確實有能力、也有意願承擔這份壓力，那直接編寫後端程式碼也沒問題……但那就是高階工程師的範疇了。
Jerod ：從內容生成和提示詞設計的角度講，你們要怎麼跟上底層技術的變化？
Chris： 這方面肯定還有大量工作要做。有些模型也還在醞釀，沒有正式出爐。之前我就一直在密切關注 Windsurf，想要努力跟上時代。換句話說，我們可能需要一位大語言模型領域的大使來保證我們不要掉隊。
Jerod：那 Next.js 呢？這個專案變化速度快不快？還是說因為隨時在生成新應用，所以 Next.js 影響不大？
Chris： 是的，我們只需要處理一個檔案。之所以選擇使用 app.jsx 而不是 app.tsx，是因為這能降低模型出錯的可能性。現在如果大家想用 tsx，我確定 Windsurf 也能一次性幫忙解決這個問題。
Jerod ：確實，但有必要嗎？這個階段肯定都已經到了釋出後的階段，那還不是想怎麼改就怎麼改？
Chris ： 是啊，jsx 的核心優勢在於簡潔，允許任何人訪問和編輯這些應用，並把它們遷移到任意後端。在彈出應用時，它會執行相同的 API，也可以隨意遷移。只是個人想法哦，我覺得在某些情況下，特別是在為應用中引入了影像生成等 AI 功能等使用者付費模式時，大家甚至可以直接把我們的 npm 模組拖到其他環境中使用。這樣就可以直接釋出應用，而不必擔心大模型成本。
我們歀庫中內建的這些 npm 模組，負責在免費 token 用盡時彈出登入視窗。只要完成登入，就能獲得另外一批免費 token。如果再次用盡，系統會要求使用者輸入信用卡資訊。大家當然希望自己的應用能夠儘量推廣，可一旦人們在生產環境中使用這些提示詞，那整個傳播推廣可能會產生高昂的 ChatGPT 呼叫成本。為了避免這種情況，大家可以在 Vibes 上進行推廣，或者使用 Vibes 的 npm 模組，把這些麻煩事交給我們。只要你的應用使用量夠大，可以藉此直接賺取作者收入。
Jerod：明白了，這樣的可擴充套件性會更好。我想這就是你前提提到的 YouTube 商業模式。作為應用開發者，我透過使用者對應用的使用來消耗 token，而你作為 Vibes DIY 則從每位繼續使用應用並付費的使用者身上賺錢。正因為如此，誰能給你帶來更多客戶，你就給誰報酬。這是個很有趣的商業模式。
Chris： 但說起來容易、做起來難。現在 CouchDB 表現是挺好的，但我也經歷過被 MongoDB 折騰得焦頭爛額的窘境。
當時我還專門寫了首說唱吐槽呢。但 MongoDB 也有它的價值，我從他們身上學習到，佔領市場的秘訣在於如果企業使用者未經許可就嘗試開發應用，一定要把底層功能做穩做牢。比如獸醫診所希望自己的客戶管理系統能新增寵物最喜歡的零食功能，那 Vibes 就可以快速生成一款零食追蹤器。在這種情況下，Fireproof 採取的強制加密一致性甚至足以用於監管供應鏈。總之，Vibes 擁有可靠的底層安全基礎設施，所以不只是程式碼本身足夠酷炫，我們還有足夠的通道來擴充套件整個系統、應對更嚴肅的應用需求。
Jerod：你覺得 Vibes 這個品牌真能往嚴肅方向擴充套件嗎？
Chris： 要靠時間來檢驗了，但我個人比較有信心。我們可做的還有很多很多……
如果大家想分叉核心部分，讓它跟 React 以外的東西也能相容，比如說 Vue 和 Solid.js 吧。但之所以選擇 React，是因為它能提供最具深度的訓練集。但是，使用者也可以使用打包器將 Vue 應用或 React 應用部署到我們的 Cloudflare 端點，不會對使用流程產生任何影響。至少從基礎設施的角度來看，Vibes 已經準備就緒了。
讓更多朋友參與到程式設計中來。比如做個能讓他們大吃一驚的圖片生成器，沒準在 Facebook 上就一夜爆火了。
Adam： 老哥有句話不知當講不當講。
Chris： 洗耳恭聽。
Adam： 宣傳語就寫“與好友共享氛圍”。
Chris： 妙啊。
Jerod： 這個可以。
Chris： 我們的專案就像是個非常簡單的開關……在交流中，我們發現很多人對這樣的聊天式介面非常期待——只要跟大模型聊一聊，它就能幫忙生成程式碼，而且支援多使用者模式。後續我們會開啟這種模式，比如允許 Adam 邀請 Jerod 加入高爾夫應用的共享開發，也可以邀請 Jerod 擔任高爾夫應用的程式設計師，加入同一聊天頻道。
Jerod： 那就真的是跟好友們共享氛圍了。
Adam： 確實是這樣。
原文連結：
https://github.com/thechangelog/transcripts/blob/master/podcast/the-changelog-647.md
宣告：本文為 InfoQ 翻譯整理，不代表平臺觀點，未經許可禁止轉載。
首屆 AICon 全球人工智慧開發與應用大會（深圳站）將於 8 月 22-23 日正式舉行！本次大會以 “探索 AI 應用邊界” 為主題，聚焦 Agent、多模態、AI 產品設計等熱門方向，圍繞企業如何透過大模型降低成本、提升經營效率的實際應用案例，邀請來自頭部企業、大廠以及明星創業公司的專家，帶來一線的大模型實踐經驗和前沿洞察。一起探索 AI 應用的更多可能，發掘 AI 驅動業務增長的新路徑！