Vibe Coding 的混乱中间地带
在 "Free Range Apps" 中，我认为廉价软件创建可以释放一个由特定社区构建和为之服务的微型应用的漫长尾端。在 "Surfing the Claude Wave" 中，我讲述了我如何用 Claude Code 重建 Wave Floral 的网站。这篇文章不仅关于过去一年我观察到什么被交付了，还关于什么仍然缺失。
如果你是新手：我是 Megha。我为早期创业公司提供软件和产品咨询的自由职业服务，并经营 Wave Floral，旧金山的一家花艺设计工作室。我之前是 Whimsy 的联合创始人，Whimsy 是一个面向活动专业人士的 AI 原生后端。
去年夏天写 "Free Range Apps" 时，我对 vibe coding 作为一种平民力量持乐观态度。现在依然如此。但过去六个月我一直在深入实践：为早期创业公司做自由职业、为从隐形创业公司到财富 100 强的企业提供 AI 采用咨询、举办工作坊帮助非技术人员发布他们的第一个应用、并观察每个主要 vibe coding 平台竞相填补空白。
我预测的一些事情已经实现。我担心的很多事情仍然有问题。而且所有人都在竞相商品化的那部分市场——原型层——在我看来，作为构建一个有防御性业务的地方，基本已经结束了。
现在有趣的问题是：原型之后会发生什么？
如果你是以下人群，这篇文章可能对你有用：
- 构建让用户使用 AI 生成代码的应用程序，无论是 vibe coding 还是其他方式
- 大型公司的产品经理或工程师，想了解什么是可能的以及实际正在发生的事情的全景
1、什么已饱和，什么已交付
构建软件的典型流程，从想法到上线产品，大致如下：
想法 → UI → 后端 → 认证 → 数据库 → 支付 → 部署 → 扩展
一年前，vibe coding 工具在前三个步骤上已经足够好了，但在将剩余步骤链接在一起以托管和维护生产应用方面仍然挣扎。
然而，过去一年有很多进展，许多现有的垂直 SaaS 公司开发和发布了一个 AI 产品。
自去年以来实际交付的内容：
- 支付。 Lovable 现在与 Stripe 和 Paddle 集成。Replit 提供 Stripe 和 RevenueCat（用于移动应用），用户可以直接接受付款。
- 安全。 大多数平台已成为 SOC 2 合规。Lovable 与 Aikido 合作进行渗透测试，并为需要 SOC 2 和 PCI 合规的构建者搭建了流程桥梁。
- 认证。 Google Sign-On 和基本的身份和访问管理 (IAM) 已成为标准。基于 MCP 的认证提供商如 Clerk 和 WorkOS 可以与代理流程干净地对接。
- 邮件。 事务性邮件——那种过去需要设置 Sendgrid 或 Postmark 的服务——越来越多地作为嵌入式功能捆绑在平台中。
- 部署。 Vercel 的 V0 和 Replit 的托管使"你的应用在这个 URL 上线"成为默认状态。我开始称之为部署即提示：让构建者到达分享产品的快乐路径。它需要隐藏 CI/CD、DNS 和大量其他管道工作。
如果你只需要软件看起来漂亮并接受信用卡，我们大致已经做到了。原型层是商品化的。
这个饱和点创造了一场工作流军备竞赛，这意味着大部分防御性现在存在于平台锁定和拥有管道的其余部分。
2、混乱的中间地带：vibe coding 仍然失效的地方
从轶事来看，我认为 vibe coding 的市场渗透率接近达到上限。谁足够好奇开始使用这些工具，现在很可能已经开始了。等到其余人群到达时，AI 嵌入式工具将只是正常的软件。互联网上已经散布着数百个个人待办事项应用，这是典型的第一个 vibe coded 项目。
一种有用的编程思考方式（借用 Shravan Suryanarayana 的框架）分为三个层次：
- 服务层 — 你的应用程序做什么（当用户做 X 时，应用做 Y）
- 基础设施层 — 管道工作（数据如何显示，谁可以看到什么）
- 部署层 — 交付（应用如何从你的机器移动到许多机器）
Vibe coding 平台已经将服务层商品化。但上下文窗口、内存泄漏和 AI 驱动代码的当前状态意味着基础设施和部署层仍需改进。大型平台现在选择解决这个问题的方式，很可能将定义我们在未来十年左右的商品化 AI 原生世界中软件的具体样貌。
考虑到我们在漏斗顶部正在走向饱和，下一个自然步骤是弄清楚为那些想要一个真实的、可运行的、通常是可变现产品的人构建什么。
"这在我的机器上对一个用户有效" 和 "这服务 1000 个付费客户而不会崩溃" 之间的所有内容就是我所称的混乱中间地带。这是没有软件知识的 vibe coding 仍然大部分失败的地方，也是下一波差异化将发生的地方。
具体来说，混乱中间地带包括：
- 多租户架构。 AI 生成的代码压倒性地假设单用户应用。它加载一个人的数据，运行一个人的会话，当两个用户同时命中同一个端点时就崩溃了。没有隐含的理解"用户"意味着"许多彼此隔离的人，具有权限"。
- 并发和延迟。 当十个人同时提交同一个表单时会发生什么？当数据库查询同时从二十个会话调用时？大多数 vibe coded 应用还没有在原始构建者的本地机器之外进行过压力测试。
- 数据库设计和迁移。 通过提示构建的模式往往是脆弱的，容易受到行级安全漏洞的影响，特别是在生产环境和开发环境之间。用通俗的话说，用户可能能够在具有 AI 构建数据库的应用上看到其他用户的数据。仅作为起点，行级安全 (RLS) 问题对非技术用户意味着什么？有没有更好的方式来传达这个？
- 版本控制。 许多平台完全抽象掉了 Git，这在你需要回滚一个错误的更改或与另一个人协作之前感觉很好。这就是 "GitHub 会过时吗？" 这个反复出现的问题出现的地方，我认为答案是否定的——但它的界面可能会。人们可能永远不必再学习如何 rebase 一个更改。
- 安全和密钥管理。 不能期望普通 vibe coder 知道什么是环境变量和 API 密钥；然而大多数平台缺乏关于此的产品内教育。AI 代理读取环境变量的后果，特别是在恶意行为者手中，可能意味着被黑客攻击。
这些都不是性感的问题。但它们也是软件公司作为公司存在的全部原因，这就是为什么谁为非技术构建者解决这些问题，谁就能捕获真正的长尾。
4、Vercel vs. Lovable vs. Replit vs. Base44
关于主要 vibe coding 平台的位置以及我认为各自最有可能获胜的快速阅读：
4.1 Vercel
Vercel 对于非技术构建者来说是一个黑马，考虑到它作为托管和部署平台的悠久历史。这个优势是我认为 Vercel 在所有 vibe coding 应用中在持久力方面最有优势的原因。Vercel 的核心业务是托管、部署、环境管理、密钥和边缘基础设施。
那就是混乱中间地带。V0 是一个相对商品化的无代码应用构建器，但它不需要在原型质量上获胜。它只需要为 Vercel 栈的其余部分提供输入。运行一个真实应用的困难部分是 Vercel 已经悄悄构建了十年的东西。
我过去曾用 Vercel 为我之前的创业公司，目前用它来做副业项目，比如 Hawk Hill PR。这个应用使用风数据来计算在旧金山一个热门骑行路段尝试 PR 是否有利。我想尝试 v0 来快速添加一个我一直拖延的功能增强：按小时显示风和 PR 条件。
v0 检出了一个新分支，进行了一致的设计更改，与我确认，然后部署了该功能。
我特别喜欢的是能够直接在平台上部署，不过我很好奇这在大型工程团队中如何扩展。
考虑到这一点，v0 和 Vercel 可能更适合技术用户，因为托管、部署和服务器功能的长尾是平台的核心产品。
4.2 Lovable
另一方面，Lovable 是最注重设计的，明确为非技术用户构建的。他们最近发布了 Lovable Aesthetics，让用户对设计系统有更多自主权。
他们的模板让我想起了像 Squarespace 或 Framer 这样的网站构建器，着陆页旨在向用户传达，构建你自己的产品*既简单又美观。此外，Lovable 在集成和/或构建支付、认证和邮件方面行动迅速。
值得注意的是，他们让你将项目导出到 GitHub 但不能导入，这个产品决策告诉你一切关于他们认为用户是谁：从零开始的人，而不是有现有代码库的人。
4.3 Replit
Replit 恰恰相反。他们倾向于技术用户，提供代码导入、真正的 IDE 和 Vercel 部署集成。对我来说最有趣的是 Replit 多么激进地将混乱中间地带内部化：他们自己的数据库、应用存储、认证和域名处理。这是一个绝妙的护城河还是一个巨大的维护负担，取决于执行。我怀疑其中许多功能是 Replit 团队为他们的原始 IDE 业务已经构建的，这使得这个策略比乍看之下更具防御性。
4.4 Base44
Base44 处于一个有趣的位置，因为他们的母公司是网站构建器巨头 Wix。不出所料，他们构建了一个强大的模板市场，展示了来自 Base44 团队的免费和付费模板以及高级用户提交的内容。这是将 Squarespace/Wix 的剧本应用于应用。
所有平台的共同模式是：原型构建器本身正在成为一个亏本引流的入口。业务在于之后发生的事情。
5、将定义这个类别的产品问题
如果你正在构建或就职于一个 vibe coding 工具，我会提出几个问题。
每个人真的都是构建者吗？
也许一个更好的框架是：每个人真的需要成为构建者吗？
Vibe coding 的原始承诺是任何人都可以构建自己的软件。然而，我举办的工作坊越多，我看到的双峰分布就越多：一些人真正理解了并开始行动，另一些人想要结果而不想构建，当他们的提示没有生成他们想要的输出时就感到沮丧。两类用户都是有效的构建目标，但需要完全不同的产品功能、用户界面和集成。
目前，vibe coding 平台似乎都在面对同样的问题：弄清楚他们的理想高级用户有多技术、多自主。
诚实的做法可能是开发一个高级用户市场，让他们为他人构建——就像 Framer 和 Squarespace 最终围绕它们发展出整个自由职业经济一样。这似乎与创始人的推销相矛盾，但我认为并非如此。总会有套利机会，熟练的 vibe coder 出租是长尾的延伸。
Bethany Crystal，Build First（一个我在其中担任联合引导者的 AI 学习实验室）的创始人，很好地表达了这个框架：你是这个工具的制作者还是使用者？
那么，这些平台的构建者应该问的问题是：我们是在为用户还是为制作者构建嵌入式 AI？
你的最终用户的产品最终用户是谁？
作为平台回答这个问题有助于你解锁用户留存。换个说法，这实际上是你的平台如何帮助你的用户赚更多钱的问题。
这个领域的典型用户画像：
- 构建可变现产品的独立创业者
- 为本来会被推迟的功能发布内部应用的团队
- 好奇的修补匠，寻找构建个人应用，通常是为了娱乐
- 技术谨慎的用户，将生成式 AI 作为另一种搜索引擎
为试图变现的独立创业者构建和为希望发布否则会被推迟的应用的内部团队构建之间有真正的区别。我听过两种用例的引人注目的版本，产品含义也不同。
描述成本和 token 使用的最简单方法是什么？
用户本质上对他们不断触及的 token 和使用限制不信任。平台需要在专注于降低成本之前，找到一种更好的方式来预测和传达成本。
生成式 AI 平台正在竞相构建新功能和用户界面，同时临时迭代 token 优化。可能在我们在晚宴上弄清楚如何向叔叔解释什么是 token 的时候，token 就已经被商品化了。
在此期间，有一些产品用户界面可以提高透明度，从而提高用户信任和产品留存：
- 像燃油表一样：将 token 使用转化为用户的实际任务，带有一些前述提示的上下文。例如 "大约还有 8 次长对话" 或 "按照你当前的提示使用，大约还有 30 次代码编辑"
- 分项收据：在提示后显示成本，分项列出，像收据经常做的那样。当用户能看到他们付了什么钱时，他们可能更能容忍意外定价。最差的版本是无声计费；最好的版本是任务后总结，说"这次运行使用了 X，因为你附加了一个 40 页的 PDF"。
你应该为用户配置多少，还是让他们自己配置？
教授 AI 采用的工作坊，加上咨询询价的范围界定通话，需要很强的直觉来判断我是在失去听众，还是在引导他们走向他们想构建的愿景或好奇心。我不断担心参与者是否理解我给他们工作流，还是只是在复制粘贴到一个他们无法复现的终点线。
平台有同样的问题。太规定性，你就构建了另一个横向 SaaS。太开放，你就重现了非技术用户面对无限决策的原始问题。
大多数平台陷入的陷阱是把这当作一个单一旋钮——"多少手把手指导？"——而实际上它需要独立移动的两个独立旋钮。有初始状态旋钮（空白画布是什么样的？）和逃生舱旋钮（一旦用户有了自己的意见，多容易覆盖默认值？）。大多数平台一个对了，另一个错了。Notoriously Notion 从一个空白页和一个如此陡峭的学习曲线开始，以至于围绕它成长了一个完整的 YouTube 类型。Squarespace 走了另一个方向——漂亮的默认值，一旦你想打破网格几乎不可能。两者都是有效的；两者都不是 vibe coding 的答案，在 vibe coding 中，用户的目标通常就是最终打破网格。
我不断回到的模式是我称之为脚手架式脱离的东西。从工作模板开始用户——不是空白页，不是向导——让定制的动作感觉像是一系列从默认值的小的、可逆的偏离。第一次编辑应该是标题中的一个词。第十次编辑可能是一个数据库模式。平台的工作是确保第十步不需要理解第一步和第九步之间的所有内容。对我有效的工作坊是参与者带着一个能运行的东西离开的工作坊，他们原则上可以后来拆解——而不是那些他们从零构建并且一周后无法向自己解释的工作坊。
更深的问题是你的平台是在教授一项技能还是在隐藏一项技能。两者都是合法的商业模式。但你应该知道你属于哪一种，因为配置选择由此而来。
你与谁合作，谁被排除在外——自建、购买还是搁置？
Vibe coding 平台不断在做自建还是购买的决策。赢得合作伙伴关系的公司将是那些拥有清晰的 API 文档和 MCP 服务器的公司，投资于现代的、代理友好的工具栈。
有趣的是，"代理友好"正在成为一个真正的产品类别，而不仅仅是营销声明。为人类开发者设计以便在冲刺期间阅读一次并集成的 API，与为 LLM 设计以便在每次调用时从零阅读的 API 看起来非常不同。前者容忍歧义、可选参数和"查看文档了解更多"；后者惩罚所有这些。Stripe 的 API 因其易读性而闻名，因为它是为认知负荷下的人类开发者编写的。下一代易读的 API 将为上下文窗口压力下的代理编写，这是一个更严格的约束。
我在现代开发者文档上喜欢的一个小功能是"复制为 markdown"按钮，提供了一种一键方式将文档直接粘贴到代替你编码的 LLM 中。Stack Auth 和 Stripe 都做得很好。如果你在 2026 年向开发者销售，这应该是基本要求。
在一个每个人都能构建的世界里，定价是什么样的？
旧模式是个人应用免费，专业应用付费。当一个"个人"应用可能服务于一个紧密社区中的五十个人时，这个模式就崩溃了。获胜的定价模型看起来更像基于使用量的计量而不是基于席位的 SaaS，但我还没有看到任何人做到完美。
根本问题是价值单位已经转移。当软件是一个人使用的工具时，席位是有意义的。当软件是一个人部署来做工作的一个小程序时：有时为自己，有时为一个群体，有时为一个从不登录的受众——席位的意义就不大了。一个婚礼策划师构建了一个客户登记表，200 对情侣一年填写，她不是 200 席客户；她是一个席位客户，有 200 个匿名受益人。按席位向她收费是荒谬的。按提交次数向她收费感觉更接近，但以一种订阅不会的方式惩罚了她的成功。
我发现最有趣的定价模式是那些用软上限进行分层使用量实验的模式：为个人使用提供慷慨的基础额度，超过它的按量计费，以及一个独立的（高得多的）层级，在应用开始产生收入或处理受监管数据的那一刻。
6、至今无人填补的最大空白
更好的非技术入门引导是最高杠杆的空白。Vibe coding 应用应该预先询问用户的问题，这些问题会流入基础设施和安全层：
- 你预计有多少用户会访问这个产品？
- 他们是否都需要相同级别的可见性？
- 谁被允许看到什么？
- 你的应用程序是否处理敏感数据？
以及一些目前没有人做好的具体产品机会：
- 非技术终端。 几乎每个 vibe coding 平台在设计上都偏重 UI 和前端。这是一个很好的入门策略，但是一个糟糕的教学策略。部署、分支、环境变量和命令行的概念不会因为你隐藏它们就消失——它们在出了问题时重新出现。我很想看到一个"给我们的终端"，解释你为什么输入你正在输入的内容，而不是完全抽象掉它。Docker 最近的 MCP 目录暗示了这种层，但专门针对 AI 基础设施。
- 多租户即服务。 为小群体提供即插即用的身份、权限和数据隔离。不是企业级 IAM，不是单用户假设。一个为 20 到 200 人服务的应用的实际约束。入门应该询问数据类型、用户类型以及每级用户需要的权限。
- 带安全护栏的自然语言数据库设计。 让非技术构建者用通俗英语指定数据模型，由平台处理迁移、一致性以及不可避免的"我在上线后需要更改这个模式"的时刻。
- 运营交接。 vibe coded 应用开始真正赚钱的那一天，就是其构建者需要考虑监控、错误处理和正常运行时间的那一天。没有人正在构建"面向非技术运营者的 AWS"，而且差距在扩大。我很想看到 vibe coding 公司的一条服务线，构建者可以雇佣经验丰富的工程师来审计应用和/或在出问题时调试。
7、什么会留下，什么不会
无论即将到来的范式转变是什么，我认为有几件事将持续存在：
- GitHub 将成为一个明确的赢家，永远不会被征服。 界面可能会改变，但版本控制作为一个概念太根本了，而且 GitHub 对于与互联网上任何东西集成来说太中心了。如果有的话，GitHub 形状的层将随着更多非技术构建者发布他们不完全理解的代码而变得更加重要。
- 产品感保持不变，并变得比以往任何时候都更重要。 廉价原型时代不会减少对产品思考的需求，它会放大它。当每个人都能在一个下午发布一个 UI 时，差异化在于你选择构建什么以及为什么。我将在下一篇文章中更多地讨论这个。
- 生产力领域的公司需要投资于强大的 API 文档和 MCP 服务器。 任何个人/专业工具公司都将从开发 MCP 功能集中大大受益，为想要自动化其工作流的构建者解锁简单的集成能力。不这样做的公司将悄悄被绕过。
8、我接下来在关注什么
对我来说，这个时刻最有趣的事情是，竞相填补混乱中间地带的平台同时在竞相定义对非技术构建者来说软件是什么。无论他们选择了什么默认值——关于数据、关于定价、关于谁有资格成为构建者而不是购买者——都将塑造未来十年普通人如何与软件相关。
我仍然相信 free range apps 论点。我只是认为未来一年不太关乎 vibe coding 是否有效，而更多关乎谁将构建那些无聊的、必要的、被严重低估的基础设施，把原型变成你朋友的面包店真正能运行的东西。
如果你在这个领域构建，特别是在混乱中间地带问题上，我很想听听你在做什么。
原文链接: The Messy Middle of Vibe Coding
汇智网翻译整理，转载请标明出处