Lovable 创始人访谈:当做软件变快,创业卡在哪?

一家小店想做在线预约。以前，老板得先找人做网站、接表单、发确认邮件。现在，跟 AI 聊几轮就能做出一个能点的版本。可把链接发出去以后，老板还是得想清楚顾客从哪来、为什么愿意预约，以及临时改期由谁处理。

11 月 3 日，Lovable 联合创始人兼 CEO Anton Osika 在 CNBC《The Tech Download》接受 Arjun Kharpal 采访。他谈的正是第一版软件做出来以后，那些更难回答的问题。

01　让最懂问题的人先做一版

Osika 回忆，做 Lovable 的起点，是看到许多有想法的人懂顾客，也知道顾客为什么烦，却得先找到会写软件的人，才能试一试自己的解法。Lovable 最初让用户用自然语言生成网站或应用，把这一步交回给提想法的人。

他在访谈里用了一个词，Minimum Lovable Product，可以理解成「小到做得出来，好到有人愿意再用」。比方说，一家小店只做预约确认，功能很少。但如果顾客一眼能看到剩余时段，下次再来时也知道去哪改期，这一版就有了值得保留的东西。

Osika 说，Lovable 上搭建的应用合计每月接近 10 亿次访问，平台每周创建超过 100 万个新项目。这是创始人在访谈里给出的口径。一次访问可以来自同一个人反复打开页面，一个新项目也可能只是一次试做。要判断多少项目变成了生意，还得看上线后有多少人持续使用、付费，以及商家能否持续履约。

02　Lovable 为什么开始做获客？

Osika 说，有些用户已经用 Lovable 跑业务，接下来想把支付、邮件、域名和营销接起来。这个方向已有具体动作。10 月 14 日，Lovable 公布了增长工具，可以根据应用和目标建议 SEO 或广告方案，接入 Google 和 Meta 的广告账户，并在分析页查看结果。广告上线前由用户确认，广告费用由对应平台直接结算。

想象一下，老板告诉 AI「我想让更多附近的人完成预约」。如果系统知道店的位置、营业时间、预约入口，以及用户通常在哪一步退出，它就能把落地页、投放和转化追踪连起来。老板看到点击多、预约少，下一轮就可以先查时段是否充足、价格是否讲清，再决定要不要加预算。

这也是我看 Lovable 和模型厂商竞争的角度。Osika 说，Lovable 会按任务选择不同模型，部分任务也会用开放权重模型。访谈里没有披露具体路由规则。我的判断是，模型能力会影响做出第一版的速度，平台能否让商家从每一轮经营里学到东西，则取决于它能不能把页面、订单和反馈接起来。这个优势是否成立，最终要看商家愿不愿意长期把业务放在上面。

03　把省下来的开发时间，用来更早验证

假设一家小店总在微信里反复确认预约。第一周，只做一条最常见的流程，让顾客选时间、提交预约并收到确认。店员先在后台手工确认。找几位本来就会预约的顾客试一遍，记录多少人能自己完成、多少人还要来问、店员少做了几次来回确认。

如果顾客卡在看不懂服务项目，就先改说明。如果同一时段经常被两个人选中，就先处理冲突。如果用户看完页面仍习惯直接发微信，就看看他们到底是想省时间，还是需要店员先帮忙判断该选什么。每种反馈都指向不同的下一步，做更多页面很难替你回答。

等流程有人反复用，再按实际风险补工程。接支付前，拿重复提交、扣款成功但预约失败的情况做验收。接顾客资料前，用两个不同角色的账号检查各自能看到什么。正式上线前，讲清楚谁处理异常、哪里能查记录、系统出问题时怎么恢复人工接单。

这套分工也适合团队。最懂业务的人先拿一个可用版本去找反馈，工程师把业务规则、权限和异常处理变成可测试的约束。第一版交付的是一个可验证的假设。准备上线时，要交付的是出了问题也有人接得住的流程。

下次遇到一个想做的软件，我会先问自己，这周能找谁用它完成哪件事？提前记下什么结果会让我改主意？有了这两个答案，AI 帮你省下来的时间，才有机会变成下一次更准的产品判断。

本篇补足了什么

这篇补的是 AI 应用从原型走向业务结果的一段。用更短的时间做出一版，就能更早判断这版值不值得继续做。最小的验证，是拿一个真实流程跑一周，把完成率、人工介入次数和失败原因记下来，再决定下一步是改产品、补工程，还是收掉这个需求。

参考来源

CNBC《The Tech Download》，Can AI Turn Your Idea Into a Business?，2026 年 11 月 3 日。

CEOInterviews.AI，同期访谈公开转录。

Lovable，From building your app to growing it: Lovable now helps you find customers，2026 年 10 月 14 日。