译者 | 核子可乐
编辑 | 褚杏娟
策划 | Tina
Chris Anderson 是 CouchDB 和 Couchbase 早期的重要贡献者，也是 Relaxed 公司的创始人之一。在 NoSQL 刚刚兴起的时候，Chris 就处于这一潮流的中心，深刻影响了开发者对数据分发和“离线优先”架构的认知。Chris 痴迷于 Java 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 直言不讳。
1“CouchDB 是精英聚集地”
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 的董事会成员。另外，虽然花了一段时间，他们最终也还是成功上市了，大概是我离开的五年之后……
2开始氛围编程的创业
开发 Fireproof 数据库
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 等等，我们就相当于有了无限多这种“学艺不精”的开发者。
Vibes DIY能开发什么样的应用？
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 组件构成、有着全部你需要的 Type 注解……而且已经做好了规模扩展的全部准备。
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 开发者，用户应该不需要了解这些也能轻松实现。
3赚钱重要吗？
Adam：目前赚钱对你们来说重要吗？还是说暂时只关注把氛围编程做好？
但至少每月 5 美元就能让大家用起来。如果能接受更高的价格，我们也提供性价比很高的按使用量计费机制。从长期来看，这样的商业模式跟 YouTube 基本相当，比如我们以企业案例进行分析。
Jerod：说起来，“把房屋变成电子游戏关卡”的产品出现了吗？我是真感兴趣。
Chris：没有，但总会有人去做。我想这东西迟早会出现的。现在高斯溅射的成本越来越低，在手机上就能跑得动。
Adam：那具体该怎么做呢？就像拍视频那样在家里走来走去，然后把结果上传就行？
Chris：我们一直希望自己能做到最好——说实在的，我们也算这个行业里颇有经验的老手了。但人的能力毕竟是有限的，恐怕我们的极限也就是把电吉他发明出来，至于摇滚乐……留给年轻人们去发明吧。
Jerod：这简直是史上关于“我不知道”最动听的解读了。
Adam：是的，我之前压根没怎么想到过这一点……要是有路线图，真的帮助很大，能让用户知道自己接下来能做什么。不只是各种新奇功能，像推送通知这样的基础实现也很酷。
Chris：这些细节永远无穷无尽。而且从本质上讲，如果在流程中引入 backend.js，那它实际负责的就是把 API 这种复杂元素隐藏起来。这是我们没办法直接通过电子邮件或者浏览器发布的部分，但可以把它放进后端，由后端来转发这些消息。
4“现在应用开发速度比创作短视频还快”
Adam：如果你的设想都成功了，会发生什么？一年、两年之后会是怎么样？
我自己刚接触编程时，觉得世界上最酷的事情莫过于在 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 上，快速宣传自己的应用。”
5“我这个 CEO 写了 75% 的代码”
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：这个可以。
