一、Vibe coding是什么
Vibe Coding，直译过来其实就是“氛围编程”或者叫“沉浸式编程”。它只看效果，说出需求，其他全部扔给 AI。发现哪里不满足？只需再次告诉 AI，“马上调、马上反馈”，沉浸感拉满，效率高得离谱。
Vibe coding 编程流程：
a、我用自己的话（可能是自然语言，也可以是画个图、举个例子）告诉 AI：“我要啥样的功能/效果/结果”。
b、AI（不论是 ChatGPT、Copilot 还是专业 Vibe Coding 平台里的 Agent）自动给你造出代码+界面，你根本不用管它用啥方法。
c、你用实际运行出来的结果来“检验”：对了就收下，不对就吐槽、提要求，让 AI 再调。
d、如此循环，直到你看到的结果完全符合你心中所想，这代码你就交差了。
二、Vibe coding起源
Vibe Coding这个概念由OpenAI联合创始人Andrej Karpathy在2025年2月首次提出，短短几个月内就在全球开发者社区引起巨大反响。
从硅谷的初创公司到世界500强企业，从个人开发者到大型技术团队，都在探索这种全新的编程范式。它的核心思想是开发者使用自然语言向大型语言模型（LLM）描述需求，由 AI 自动生成可运行的代码，从而减少人工编写代码的工作。
三、vibe coding 代表性工具有哪些
Bolt.new和Lovable是这场革命的代表性工具。
Bolt.new，ARR在2025年1月完成融资时已达到2000万美元，通过1.055亿美元融资后，估值超过10亿美元。依托自然语言生成全栈网页应用的能力，降低开发门槛，吸引非技术用户。仅用2个月即从零增长至2000万美元ARR，增速打破AI编程工具的历史纪录。
Lovable 2025年9月ARR飙升至1亿美元，并保持每月新增约800万美元的增速，预计年底达到2.5亿美元。估值攀升至20亿美元（2025年7月完成1.5亿美元融资）通过全栈应用生成平台，用户用自然语言描述需求即可自动生成完整代码（准确率92%）。付费用户月留存率高达85%，远超ChatGPT等竞品。
两者均聚焦AI驱动的低代码开发，但Lovable在商业规模和技术成熟度上更胜一筹，而Bolt.new凭借极简操作吸引更广泛用户群体
四、技术上是否成熟，适合场景是什么？
从最新的实践来看，适合下面的场景。
- 快速原型开发与MVP验证
核心价值：通过自然语言描述需求，几分钟内生成可运行的最小可行产品（MVP），例如电商网站、社交应用原型等。AI工具（如Cursor、Claude Code）可生成80%的基础代码，开发者仅需优化剩余20%的关键逻辑。典型案例：初创团队用Vibe Coding一周内完成智能家居App的交互逻辑和UI开发，节省了传统编码60%的时间。 - 中大型遗留系统迁移
规模化改造：适合需迁移数千个老旧模块（如Java转Go）的企业，通过“AI迁移工具”批量生成转换方案，端到端效能提升10倍。
案例参考：某银行使用Vibe Coding将COBOL核心系统转换为Python，代码转换准确率达85%，错误率较人工处理降低90%。 - UI迭代与页面生成
效率优势：前端开发者可快速调整组件样式（如“将侧边栏内边距减半”），AI实时生成React/Vue代码，避免手动查找CSS属性。
限制补充：生成代码可能导致重复渲染等性能问题（如React中未优化的状态更新），需人工介入调试。 - 教育与零基础入门
学习辅助：学生通过自然语言指令理解数据结构实现（如“生成一个红黑树类”），AI生成的代码注释量是人工编写的3倍，降低了学习曲线。
五、vibe coding 的限制
1. 可靠性与正确性的“黑箱”问题
- 限制描述： AI 生成的代码往往是“貌似正确”的。它可能在90%的常见情况下都能正常工作，但在一些关键的边界条件或异常处理上，存在着微妙的、难以察觉的逻辑缺陷。因为代码不是开发者从第一性原理出发构建的，所以开发者很难对它的绝对正确性有十足的把握。
- 具体例子： 你让 AI 写一个处理并发任务的函数。它可能会生成一段看起来很完美的多线程代码，但其中可能隐藏着一个在极高负载下才会出现的“竞态条件”（Race Condition）的 Bug。
- 影响： 这极大地增加了测试和验证的负担。开发者从“代码编写者”的角色，更多地转变为“AI 代码的审查者和测试工程师”。如果没有极其严格的测试驱动开发（TDD）习惯，很容易将有缺陷的代码引入生产环境。
2. 架构与系统设计的“天花板”
- 限制描述： AI 助手非常擅长“局部优化”和“功能实现”，但它们在“全局架构设计”上能力很弱。一个健壮的软件系统，需要深思熟虑的架构设计，包括模块划分、接口定义、数据流、扩展性、容错机制等。这些都不是一个简单的“Vibe”能够描述清楚的。
- 具体例子： 你可以对 AI 说：“写一个用户登录的API”，它能做得很好。但你无法对它说：“为我们的电商平台设计一套可扩展的、支持全球部署的微服务架构”。这需要对业务目标、团队能力、成本预算、技术选型进行复杂的权衡，AI 目前还无法胜任。
- 影响： Vibe Coding 适用于构建系统中的“砖块”（具体功能），但不适用于绘制整座大厦的“蓝图”（系统架构）。依赖它来构建大型复杂系统，会导致架构混乱，最终难以扩展和维护。
3. 可维护性与技术债务的“陷阱”
- 限制描述： AI 生成的代码可能缺乏一致的风格、清晰的注释和设计思想的传承。代码的逻辑可能是生成该代码的那个特定模型的“怪癖”，而不是业界公认的最佳实践。
- 具体例子： 一个团队里，三位开发者用 Vibe Coding 模式分别开发了三个模块。这三个模块虽然功能上能跑通，但代码风格、错误处理方式、命名规范可能完全不同，组合在一起像一个“缝合怪”。半年后，当一个新成员需要维护这段代码时，他会发现完全无法理解当初生成这段代码的“Vibe”是什么。
- 影响： 这种模式会快速累积技术债务。初期获得的速度优势，会在未来的维护阶段被成倍地偿还。代码变得越来越难以理解和修改。
4. 安全与合规的“盲点”
- 限制描述： AI 模型的训练数据来自公开的互联网代码（如 GitHub），其中包含了大量存在安全漏洞的“坏代码”。AI 在生成代码时，有可能会无意中复现这些漏洞。
- 具体例子： 你让 AI 写一个处理用户上传文件的功能，它可能会生成一段没有对文件名或文件类型进行严格校验的代码，从而导致路径遍历或文件上传漏洞。开发者如果对此没有警惕，就会直接将安全风险引入系统。
- 影响： 在对安全和合规要求极高的领域（如金融、医疗），过度依赖 Vibe Coding 而缺乏严格的安全审查，是极其危险的。
5. 调试与问题排查的“噩梦”
- 限制描述：调试自己写的 Bug 已经很难，调试一个你不理解其内在逻辑的黑箱生成的 Bug，则是一场噩梦。 当 AI 生成的代码出现问题时，你缺乏对其构建的完整心智模型（Mental Model），不知道它的预期行为是什么，排查问题会变得非常低效。
- 具体例子： AI 生成了一个复杂的数据转换算法，在大部分情况下都很好，但对于某个特定的输入，结果就是错误的。你可能需要花费数小时，才能逆向工程出 AI 的那套复杂逻辑，并找到问题所在。
- 影响： 调试成本可能会完全抵消掉 AI 生成代码时节省的时间。
6. 领域知识与业务逻辑的“鸿沟”
- 限制描述： AI 具备通用的编程知识，但它不理解你公司独特的、复杂的、甚至有些奇怪的业务规则。这些规则往往是非公开的，并且充满了历史原因和特殊情况。
- 具体例子： AI 可以生成一个通用的订单折扣计算逻辑，但它不知道你公司“只在周二下午、针对VIP客户、购买了A产品组合、且收货地址在特定区域时，才能应用一个特殊的9折优惠”这种极其具体的业务规则。这部分逻辑，仍然需要人类专家进行精确的编码。
- 影响： Vibe Coding 在处理通用技术问题时很有效，但在深入到企业核心的、定制化的业务逻辑时，其能力会大幅下降。
六、Vibe coding 为什么带动了 Supabase 的估值上升
Supabase将PostgreSQL与一系列企业级开源工具深度整合：内置身份验证系统基于GoTrue，自动生成的RESTful API和GraphQL接口基于PostgREST，文件存储功能使用S3兼容的对象存储，向量工具包（pgvector）则为AI应用的语义搜索和推荐系统提供原生支持。这种"全家桶"式的架构设计，让开发者无需在十几个第三方服务之间来回切换，只需一个Supabase项目即可覆盖后端的全部需求。
这家2020年从Y Combinator孵化的初创公司，最初定位为"Firebase的开源替代品"。2024年9月的C轮融资估值为9亿美元，彼时市场对其评价还停留在"有潜力的开源项目"层面。但随后的发展出乎所有人意料：2025年4月，Accel领投的D轮融资将估值推至20亿美元，涨幅122%；仅仅5个月后，E轮融资再次刷新纪录，估值直达50亿美元。
这种罕见的估值加速度，源于Supabase在关键时刻抓住了两大趋势的交汇点。第一是AI编程工具的爆发。2024年末到2025年初，Cursor的用户数突破百万，Bolt.new和Lovable相继推出，Claude Code和GitHub Copilot的能力大幅提升——这些工具让非专业开发者也能构建复杂应用，但它们都需要后端支持。Supabase团队敏锐地发现，AI工具生成的代码往往包含数据库操作、用户认证等标准功能，而Supabase的API设计恰好与这些需求高度契合。
第二是开发者对开源和灵活性的需求升级。在经历了多家云服务商涨价和政策调整后，开发者社区对"避免供应商锁定"的意识空前强烈。Supabase不仅开源，还提供了清晰的自托管文档和社区支持，这在企业客户中建立了信任。
领投方Accel和Peak XV的押注背后，是一个令人瞩目的数字：Supabase的开发者用户数在过去一年从100万激增至400万，增长率达到300%。
七、Supabase ARR 多少，相比云厂商如何？
Supabase 主要面向的还是开发者生态。
第一波是作为 Google firebase 的竞品，将开发的门槛降低到前台开发人员，减少对后台的依赖。
Vibe coding 火了之后，架构恰好契合 Vibe coding 的诉求。根据最新的数据，Supabase的年度经常性收入（ARR）已达到7000万美元。这一数字较一年前的2000万美元ARR增长了3.5倍，其估值已突破50亿美元，反映出AI编程浪潮下开源数据库的强劲增长势头。
但是相比 AWS数据库业务，一年超过了 200 亿美金，这笔钱是零头。
八、Supabase 成功背后核心的能力是什么？
应该说 supabase 作为创业公司还是比较成功的，vibe coding 没有火爆之前，supabase 就通过对开发者的深度 knowhow 和运营能力，吸引了一大批的开发者。这也是 vibe coding 火了之后，各个工具软件把 supabase 作为默认后端的原因。
九、Supabase 是否未来会成为一个独立的赛道，为什么云厂商没有做好此类产品？
相比企业级大市场，supabase 7000 万美金，是一个小市场。
云厂商动不动几百亿美金的数据库收入，看不上这几千万，按云厂商的考核逻辑，这都不算一个大的机会，自然很难投入资源做好。
vibe coding 面向主要还是开发者 MVP 的开发，负载是非常轻量，未来如果能突破企业级市场，才能有更大的增长动力。如果只是服务于开发者，假设有 1000 万开发者付费，每个月 25 美金，市场空间的顶点也就是 30 亿美金。
类似 Lovable 之类的工具，当前主要精力在完善自身的能力，规模一旦做大，后端对用户是不可见的，替换就会成为必然。这个必然会减少收入来源。
十、Vibe coding 如何走向 Vibe working
只是基于 Supabase，Vibe coding 受限还是比较大的，只是能解决简单的业务和原型验证类的场景。
真正要走向 vibe working，做企业级能力，必须有更综合的基础实施进行支持，这个基础实施，需要提供语义上下文，各种负载支持包括 TP，AP，存储等等。
