Lovable 深度调研报告

商业模式 · 产品 · 应用场景 · 客户类型 · 技术架构 报告日期：2026-09-20 ｜ 数据截至 2026 年 8 月

—摘要

Lovable 本质上不是“代码补全工具”，而是一条把**「想法 → 可付费的线上产品」压缩成一次对话的流水线：它把前端脚手架、云后端、支付、SEO、安全扫描全部预置好，让不懂技术的人也能交付软件。它的商业内核是按用量计费的 credit 订阅**，增长引擎是极低摩擦的 PLG 免费层，而当前最大的未解问题有两个——企业收入占比极低，以及生成应用的安全默认值。

估值

133 亿美元

2026-08 C 轮后

ARR

约 5 亿美元

2026-06，公司自述

累计融资

约 9.5 亿美元

至 C 轮

项目总数

6,000 万+

月访问 9 亿次

员工

146 → 450

2026-03 实际 / 年内目标

人均 ARR

约 280 万美元

软件业历史高位

01公司概况与增长轨迹

Lovable 由 Anton Osika（前 CERN 物理研究者）与 Fabian Hedin 于 2023 年创立，总部斯德哥尔摩。它的前身是开源项目 GPT Engineer——一个基于 GPT-4 的命令行应用生成器，在 GitHub 上两个月冲到 4 万星。2024 年 11 月，团队把它重做成带图形界面的产品并以 Lovable 之名公开发布。这个“开源影响力 + 产品化”的起点决定了它天然拥有开发者社区的口碑势能。

1. 2023

   Anton Osika、Fabian Hedin 在斯德哥尔摩创立公司，开源项目 GPT Engineer 走红

2. 2024-11

   以 Lovable 品牌公开发布，当月 ARR 约 100 万美元

3. 2025-01

   上线两个月 ARR 达 1,000 万美元

4. 2025-07

   ARR 破 1 亿美元，用时 8 个月；完成 A 轮 2 亿美元（Accel 领投），估值 18 亿美元

5. 2025-08

   通过 SOC 2 Type 2 与 ISO 27001:2022 认证；旧版 Legacy 模式下线，全面转向 Agent（后更名 Build）模式

6. 2025-11 ~ 12

   ARR 翻倍至 2 亿美元；完成 B 轮 3.3 亿美元（CapitalG + Menlo 领投），估值 66 亿美元

7. 2026-02

   ARR 达 4 亿美元；注册用户约 800 万。同期发生一起单应用 16 个漏洞、泄露 1.8 万条记录的安全事件

8. 2026-05

   发布 Discoverability 套件：新项目默认 SSR（TanStack Start），旧项目自动预渲染；接入 Semrush 搜索数据。Subagents 功能 GA

9. 2026-06

   ARR 达 5 亿美元；与 Google Cloud 签多年协议，算力用量扩大 5 倍；推出自研模型

10. 2026-08-12

    完成 C 轮 4 亿美元，Menlo Ventures 与 EQT 旗下 Scaleup Europe Fund 领投，估值 133 亿美元。腾讯、Salesforce Ventures、DST Global 等在列

把时间轴上的 ARR 单独拎出来看，涨势的陡峭程度比读一行字清楚：

三轮融资把估值抬了三级台阶：

02商业模式

订阅费是地板，用量费是天花板；免费层负责获客，credit 负责收割。

收入结构与定价

两个反常规设计值得注意：

• 按工作区而非按人头收费——每个档位都包含“无限协作者”，10 人团队和 1 人付一样的钱。这在同类产品里很少见（Bolt 的团队版是按 $30/人/月加价的），直接降低了团队内部扩散的阻力。
• credit 用量计费取代了消息条数计费——简单改动扣 0.5 credit，标准请求 1 个，复杂请求 2 个以上，会话模式每条 1 个。这意味着收入随用户“用得多深”而非“用得多勤”增长。

把第一条换算成钱，同样 10 个座位，两边差 6 倍：

真正的第二增长曲线：Lovable Cloud

订阅之外还有一层用量计费。每个工作区最初可获每月 25 美元的免费云资源额度（用于托管与内置 AI 功能），超出部分按数据库存储、文件存储、函数调用、API 调用计费。做原型的人花不到，但一旦应用真的跑起来有真实用户，云费用就开始跟着流量走——这是把“做出来了”变成“在赚钱”的关键一环，也是毛利结构里最值得盯的部分。

商业模式的三个支点

03产品

不是“生成代码”，而是把产品从想法推到上线运营的整条链路。

交互只有一件事：用自然语言（或截图、文档）描述你想要的，系统产出可运行、可部署的应用，然后你继续用对话改。产品在 2026 年已经从“生成器”扩成一个完整的交付面。

交互与生成层

• Build 模式（原名 Agent 模式，2025 年 9 月起为唯一模式）：执行改动并自行验证结果，可跑十几分钟完成一个复杂功能，过程中用时间线展示步骤，出错时有“自动尝试修复”。
• Plan 模式：只思考、不动代码。用来在动手前对齐范围，是控制“改 A 顺手把 B 也改了”这类失控的主要手段。
• Subagents（2026-05 GA）：主 agent 临时派出的只读助手，用来调研、检查、复审某块代码，把结论报回来。它们不能改文件，所有改动仍由主 agent 执行。
• Skills：工作区级的可复用“作战手册”（名称 + 触发描述 + Markdown 指令），按需加载；区别于“项目知识”那种每次请求都随行的常驻上下文。
• 可视化编辑：直接在预览界面上改文字、调样式，不必用对话描述。

后端与运行层（Lovable Cloud）

开箱提供数据库、身份认证、文件存储、服务端函数与实时订阅，无需用户配置任何基础设施，并内置基于 Google Gemini 的 AI 能力（图像生成、文本分析等）。可按流量升级，行级安全（RLS）负责数据隔离。

也支持自带 Supabase 项目：用户提供项目 URL 和密钥，Lovable 据此生成 Postgres schema、对齐认证流程、把前端接到 REST / GraphQL 上——这条路径给需要自托管或合规要求的团队留了口子。

上线之后的那一半

产品边界（它明确不做什么）

• 技术栈不可选：只有 React 系（Vite / TanStack Start），换 Next.js 或非 Postgres 数据库就等于离开它的生成模型。
• 不做原生移动应用，只产出可在手机上用的 PWA。
• 不面向已有代码库的迁移改造，在平台内从零开始的项目体验最好。
• 老项目无法迁移到新的 SSR 架构，只能靠预渲染补上可抓取性。

04应用场景

真实需求集中在“没人愿意批预算、但又确实要用的软件”。六个场景，每个都有一组能验证它的数字：

05客户类型

从“不会写代码的人”到“不想排队等工程资源的人”，四层结构。

一个值得单独看的动作：客户成功被重写

Lovable 的客户成功负责人公开描述过五点反直觉做法，其中最能说明它客户结构的是两条：

• 每个客户配一个专属 Slack 频道，里面跑一个只服务这家客户实例、项目和合同条款的 AI bot——几百个定制 bot，做起来的成本和做一个差不多。
• 用 Lovable 自己重建了整个客户成功系统，把 Gainsight 换掉，做成每周迭代一次的自研指挥台。

这既是对外的方法论输出，也是最好的产品自证。

06技术架构

架构的每一处取舍，都指向同一个目标：让不懂后端的人也能拿到一个能跑的系统。

生成的应用长什么样

五层从用户看到的前端一路沉到托管，中间那层是整份架构唯一的边界：

生成侧：五步 Agent 循环

1. 任务界定——用户给出意图、需求与约束；
2. 上下文收集——读取完整文件树、环境状态、历史迭代信号；
3. 规划与生成——先出改动计划，再针对前端、接口层、数据层、集成点分别生成补丁（Chat 模式会在应用前展示 diff 预览）；
4. 构建与预览——重新构建，产物部署到预览环境，立刻可见；
5. 反馈闭环——报错与新需求进入下一轮循环；自动修复按钮不消耗 credit。

配套的工程策略包括：代码在隔离沙箱中执行、生成结果先过测试再进预览、官方明确建议“从小处起步、增量搭建”、以及独立的 refactor 轮次来整理结构而不改变行为。

模型与基础设施

• 混合模型策略：既能调用 OpenAI、Anthropic、Google 的前沿模型，也已推出自研并自行训练的模型。轻任务走快模型、复杂推理走强模型，是它控制单位成本的核心手段。
• Google Cloud 是主要技术伙伴：2026 年 6 月签署多年协议，算力用量扩大 5 倍，同时获得 Anthropic Claude 与 Google Gemini 的更深接入。Lovable 的 agent 也通过 Google Cloud Marketplace 和 Gemini Enterprise Agent Gallery 对外分发——这实质上是在借用大厂的采购与结算通道做企业生意。
• 与 Supabase 的结合有更深的层次：不只是“生成 API 调用”，而是通过 MCP（Model Context Protocol）让 AI 直接读取和修改后端状态——访问数据库 schema、密钥、日志与报错，必要时在后台调用 Supabase CLI（含 Docker）部署 edge function。它编排 Supabase，而不只是接进去。

架构代价：三个必须承认的短板

• 安全默认值是最大风险点——见下一节。
• 性能只是“能用”而非“调优过”：打包体积未优化、懒加载不一致、数据库查询可能缺索引，规模上去之前需要工程师介入。
• 复杂业务逻辑会退化：社区反馈集中在组件数量到 15–20 个之后，生成结果的一致性开始出问题；服务端逻辑的生成可靠性明显低于前端。

07竞争格局

同一赛道的产品解决的是不同环节的问题，但界面看起来很像。

把这张表的起步价摊到一条轴上，七家的价位几乎是重叠的 —— 定价不是这个赛道的差异点：

Lovable 的位置

它的买家是非开发者，而 Cursor、Cognition、GitHub Copilot 卖的是企业工程团队——这是两条几乎不重叠的路线。这既是它的护城河（工程团队不会用 Lovable 交付核心系统），也是它的天花板（预算来自个人与部门，而不是 CTO 的年度预算）。整个 AI 编程赛道在 2025–2026 年被大幅重估，资本充裕的玩家在拼自研模型、云算力和用户获取，小团队在这条赛道上的空间正被压缩。

08风险与争议

最有价值的部分往往不是增长数字，而是没被解决的问题。

① 安全：三起事件，同一个根因

证据强度一手披露

第一次扫描里那个 10.3% 值得单独看一眼 —— 它在句子里只是一个数字，画成条才知道是“十个里有一个”：

根因是同一个：前端直连数据库的架构把全部安全责任压在了 RLS 上，而 AI 在生成表结构时经常忘记开启它。 加上“一键上线”的产品文化，有缺陷的代码可能在几分钟内就暴露给真实用户。第三方扫描显示，Lovable 类应用中最常见的问题依次是密钥泄漏、RLS 缺失或策略错误、输入校验不足、缺少安全响应头。

平台侧的应对是有效的但有限的：2025 年 8 月拿到 SOC 2 Type 2 与 ISO 27001:2022，2026 年接入 Wiz 做构建期扫描、为新项目强制开启 RLS、获得面向 AI agent 的 AIUC-1 认证。但内置扫描能检查 RLS 是否开启，检查不了策略是否写对，而策略写错同样等于没有防护。行业层面的数字也印证这不是单家问题：AI 生成代码的漏洞率显著高于人工代码，多数 vibe coding 应用存在凭据暴露。

② 企业收入与使用量严重脱节

证据强度据报道

近三分之二《财富》500 强有员工在用，但企业合同收入只有约 2,000 万美元量级。大量使用是自下而上的影子 IT，没有走采购、没有安全评审、也没有归属记录。 要把这些转化成合同，需要的不只是产品功能，而是治理框架、合规认证和采购通道——Lovable 正在补（发布管控、审计日志、SCIM、信任中心），但这是慢活。

“个位数百分比”这个说法值得画出来 —— 它是这份报告里最该被记住的一处落差：

③ 留存与单位经济学的结构性疑问

证据强度分析推断

按用量计费的模型有个天然问题：用户做出一个应用并上线之后，使用量会掉下来。 一个非技术创始人的典型路径是几周高强度构建、然后进入低强度的维护期，收入随之回落。这意味着净收入留存率（NRR）是这份财报里最重要却没有公开的数字。同时，它的收入高度依赖第三方模型的推理成本，自研模型与 Google Cloud 协议都是在压这部分毛利。

④ 原型与生产的鸿沟

证据强度据报道

已有公开案例：独立开发者用三四小时做出一个考试平台并推销给培训机构，得到的评价是“一般”——没有真正的后端、没有评分流水线、没有加密，并发上一百人就撑不住，最终用 React 19 + 无服务器 AWS 从零重建、没有共享一行代码。这不是 Lovable 独有的问题，但它是整个品类的核心误解：能打动十个用户的演示，和能扛住一百个付费用户的系统，不是同一个系统。

09对做产品的人的启示

• 把“能交付”和“能运行”分开设计。 Lovable 的整条产品线都在填这两者之间的沟：生成之后补支付、补 SEO、补安全扫描、补治理。任何做 AI 生成类产品的团队，都可以把这条补丁清单直接当作自己的路线图参考。
• 按用量计费是双刃剑。 它让客户成功与收入方向一致，但也让收入绑定在“用户在持续建造”这个前提上。设计计费模型时要先想清楚用户完成第一个目标之后靠什么留下来。
• 议价权在“默认值”上。 Lovable 最大的安全事故不是被别人攻破，而是自己生成的代码默认不够安全。凡是替用户做决定的产品，默认配置就是产品责任的一部分。
• 开源起步 → 产品化 → 社区口碑这条路径在开发者工具里依然有效，而且成本远低于买量。
• 企业市场不等于有大客户名单。 “员工在用”和“公司付费”之间隔着一整套治理能力，这一段没有捷径。

—附录：资料来源与数据口径

资料来源：Lovable 官方博客与定价页、TechCrunch、Bloomberg、Forbes、Sacra、Antler 新闻稿、CVE-2025-48757 相关披露与第三方安全扫描报告，以及多家第三方市场分析。

数据口径说明：

• ARR 为年化运行率（最近一个月收入 × 12），且多为公司自述，非审计财报数据。
• 估值与融资轮次以官方公告为准。
• 安全事件细节来自第三方研究与媒体报道。
• 企业客户名单与客户评价多来自公司官方公告或客户主动提供的赞语，未披露使用规模与合同形式，无独立验证。
• 文中标注“据报道”的项目未经一手确认。

报告生成时间：2026-09-20