8周做到900万美元ARR，Lovable创始人直播建App：17轮迭代和3条提示词的差距

8周，900万美元年经常性收入。这是AI编程工具Lovable上线后交出的成绩单。它2024年11月21日正式发布，这期Cognitive Revolution录制时刚好满两个月。创始人Anton Osika说，按他查到的资料，这是欧洲创业公司有史以来最快的增长速度，没有之一。用户规模是几十万，付费用户隔天就会打开一次产品。

这期的形式也特别。主持人Nathan Labenz请来Anton和AI工程师Isaak Sundeman，一边聊产品理念，一边让Isaak在后台用自家产品现场建一个真App。一个多小时聊完，App建出来了，还建了两遍：第一遍磕磕绊绊改了17轮，第二遍只用了3条提示词。

Anton小时候学编程、做游戏，他把编程叫作理解世界、把想法变成现实的超能力，但全世界拥有这个超能力的人不到1%。他做Lovable的理由就一句话：让剩下99%的人也能用软件解决问题、改进软件，AI写代码比人快得多，这会带来一场高质量软件的寒武纪大爆发。

一道来自生活的考题：洗衣机坏了怎么选

Nathan出的题很接地气。他家洗衣机坏了，太太正在Wirecutter和Consumer Reports上翻测评。他的痛点很具体：买洗衣机之前，他连「该比较什么」都不知道。滚筒还是波轮？能不能上下叠放？这些维度他这辈子没想过，得先花大力气教育自己，才有资格开始比较。

所以他想要的App分两步：先让AI告诉他这类产品该看哪几个关键维度，再在这些维度上做产品对比。输入两个商品链接，AI抓取页面信息，先给出「买这类产品要考虑什么」，再列一张对比表。

Isaak敲下第一条提示词，几十秒后，一个能用的界面就出来了：输入框、分析按钮、产品卡片，React代码，标准网页应用的做法。Nathan提醒说提示词里有几个拼写错误，Anton的回答很干脆：拼错单词完全无所谓，AI都能看懂。真正决定成败的，是提示词的顺序和结构，先说什么、后说什么、一次要几件事。

接下来接后端。Lovable的做法是点一下Supabase按钮，登录账号，数据库和用户鉴权就配好了。然后接FireCrawl抓商品页面，接OpenAI做分析。听起来顺，实际过程翻了好几次车：API返回400错误，FireCrawl那边又蹦出502网关错误，Amazon页面文字太长，只能截断到4000字符。每出一次错，Isaak就得手动打开Supabase的日志面板，把报错复制粘贴回对话，AI再修。一来一回，总共17轮编辑，App才达到「真能给用户提供价值」的状态。

中间有个细节值得单说。Nathan问「怎么从外部URL抓取数据」时，特意用了「scrape」这个词，然后解释了自己的习惯：在不熟的领域，用词要中性，因为你说抓取，模型就顺着写一个Python爬虫，用requests拉HTML，再用BeautifulSoup解析，最后陷进爬虫地狱出不来。而业界明明有现成的好工具FireCrawl。Lovable的解法更釜底抽薪：把信得过的头部工具设为默认选项，用户根本没机会走上弯路。

敢替用户做决定：有主见的架构才是护城河

为什么Lovable要替用户把工具选好？Anton从软件工程的基本规律讲起：需要连接的组件越多，出错概率呈指数级上升。如果让大模型自由发挥，它每次生成的部件之间没有经过打磨适配，跑到某一步必然卡死，而且AI很难从这类错误里恢复。

所以Lovable把选择砍到最少：后端和数据库只用Supabase，支付走Stripe的固定路径，邮件用Resend，图片生成用Runway，各类AI接口用Replicate，抓取用FireCrawl，完整清单挂在lovable.dev/integrations。用户要加支付功能，产品直接生成按钮，跳去Stripe注册、拿API密钥、回来一贴，支付基本保证能跑通。

这套做法还带来一个连带效应。Nathan观察到，代码生成工具圈已经出现谢林点效应，也就是大家不约而同收敛到同一套选择：样式默认Tailwind CSS，支付默认Stripe。Anton确认了这一点，并认为大模型在加速这种收敛。人类学一套新框架要几个月，模型直接输出就能用；训练数据里流行方案的样本最多，模型天然更擅长它们。但他也留了一手：如果有更好的新方案出现，所有AI工具可能一夜之间集体迁移到新的谢林点。

还有个权力转移的故事。Anton说，Lovable贡献了Supabase大部分新注册用户，Supabase因此开始专门为AI agent改造产品，提供程序化的日志访问接口。录制当天，Isaak还得手动复制报错日志，自动把后端日志喂给AI的功能已经在路上。Nathan感慨，自己现在用各种AI工具，大量时间花在几个系统之间当「高级复制粘贴员」：用ChatGPT Pro做规划，再把规划一条条贴进另一个工具执行。这部分摩擦，很快会被产品化抹平。

API密钥的处理也能看出定位。Lovable几乎从不把密钥写死在代码里，哪怕项目还没接后端，它也会生成一个输入框，让用户自己粘贴密钥。FireCrawl初期免费、之后收费，Lovable不代管计费，用户完全掌控自己的账号。对小白来说少了一个概念，对系统来说少了一类错误。

模型层不押注任何一家：新模型出来，隔夜切换

和Cursor那种让用户下拉选模型的做法不同，Lovable的用户根本不知道背后跑的是什么模型。Anton的态度很明确：把模型选择权交给用户是错误的界面设计，用户没有完整上下文，只会选错。正确做法是默认走最快的一链路模型，失败时再在界面上提示，升级到更大更慢的模型做深度排查。具体是哪家模型，对用户来说是多余的信息。

他们内部有管理端的选择器，切换速度极快。Anton说，历史上每次有更强的新模型发布，他们试用确认后，隔夜就全量切换。目前做智能路由，同时用Gemini、OpenAI和Anthropic的模型，很快可能加上DeepSeek。Nathan还补了一句：别忘了Kimi。

录制时点在o3-mini发布之前，Anton现场盘点了各家模型的分工：Claude 3.5 Sonnet综合最强，速度快、代码好、推理靠谱，是干重活的主力；小调用场景用Google的Flash模型，因为Anthropic的Haiku比OpenAI的4o-mini贵；AI卡住的时候切OpenAI的推理模型，把罕见情况从第一性原理想清楚。DeepSeek开源这件事对他们吸引力很大，Anton说可能很快自己训练一个模型，处理大部分快请求。

Nathan追问：照这么说，模型层不会有赢家通吃？Anton留了余地：一切取决于团队执行速度，也不排除某个模型在价格和性能上碾压所有人。但至少从Lovable的架构看，查询本来就被拆分路由到不同模型，新模型最多咬掉别人一块份额，很难一夜通吃。

两个反主流判断：不做全自动Agent，不押生成式UI

这是全期观点密度最高的一段。Anton透露，Lovable最早走的就是agent路线，后来主动放弃了，原因是用户体验。他对agent的定义很清晰：做一个动作，看结果，再做下一个动作，一个高度开放的循环。好处是通用，坏处是耗时完全不可预测。一个不可预测、又做不到100%可靠的系统，用户体验就是灾难。要尽可能远离这种设计，先把速度和可靠性推到极致，再考虑多步化。

Nathan补了一个亲身体验。他同时测试过包括Devin在内的多个编程agent，Devin在后台持续干活，他切走标签页再切回来，发现自己完全不知道它进行到哪一步了，可能已经迭代到第87轮，什么能用、什么不能用、现在在干嘛，全都无从判断。

直播过程也印证了这个取舍。程序遇到报错时，Nathan问：让AI自己接着修，不是更合理吗？Anton承认合理，但他们不放开这个权限。内部其实已经有一个agent模式，只在管理员账号可见，Anton说让agent用起来直观顺畅需要大量迭代，这是未来几周路线图上的头号任务。

「最重要的事情，是让产品可预期地工作，以直觉的方式工作。」

聊到软件界面会不会消失，两人又杠上了。Nathan提出，如果AI足够强，很多场景可能根本不需要专门的应用界面。他举了个例子：今天的马斯克家里洗衣机坏了，大概率根本不会进入他的视野，助理直接买好装好。普通人未来的体验可能也这样，一句「帮我找几台好洗衣机，说说优缺点」，AI全流程代办。他怀疑未来很多交互被UI中介的程度会越来越低。

Anton不同意「生成式UI会取代一切」，理由很朴素：人类偏好可预测、经过大量用户验证过的界面。如果AI每次都现场生成一个新界面，祖母用不了，你自己也记不住按钮在哪。把一个产品的UX打磨到「lovable」这个名字所暗示的程度，需要无数次迭代，公司名字就是这么来的。标准化软件会长期存在，但AI生成的组件会越来越多地嵌进去，按当下任务拉取对的上下文。

不过他让了一步，而且让得很大：长期看，AI会「读心」，极其擅长预测你在当前情境下想要什么。到那时，传达意图和接收结果才是唯一重要的事，中间那些「你根本不在乎滚筒还是波轮」的界面环节会消失。分歧的实质是时间尺度：Nathan说的是终局，Anton说的是过渡期，而过渡期可能比所有人预想的都长。

诚实的成功率：一半人会卡住，然后怎么办

整期最难得的是Anton不吹牛。他直接给出数字：像直播里这种简单应用，技术人员可以非常可靠地建出来；非技术人员有耐心也能成，但至少有50%的概率中途遇到问题，大约10%的概率会卡到怀疑人生，而且带点运气成分。他补了一句：「这已经是它历史上最差的时候了。」

规模天花板也说得很实在：做一个只有单一核心功能的内部工具，大约十几轮编辑能成；功能一多，就要几百轮，而且代码库一大，AI的处理能力明显下降。他们应对的杀手锏是agentic RAG，让AI自主检索相关代码上下文，再加上精细的上下文管理。Anton说，上下文管理是智能RAG的超集，是产品可靠度领先对手的核心原因，细节暂时保密。

用户构成也有意思：新用户注册时会被问编程经验，零基础、略懂、熟练三档大致均匀分布。Anton说他们最爱的用户是创始人和业务操盘手，行动力强，学得快；懂一点调试、知道API调用是怎么回事的技术型用户能走得更远。产品外围也补齐了：应用一键部署到Cloudflare边缘节点直接上线，浏览器里能打开VS Code改代码并实时同步，GitHub和分支已接入，每个项目还能挂自己的知识库塞API文档。团队正在扩张，要求搬去斯德哥尔摩办公室，开市场顶薪。

实操层面最有价值的是Isaak的回滚方法论。他把建App的过程看作一棵搜索树：非技术用户卡住，通常是因为步骤的顺序走错了。这时候别硬修，回滚到上一个正常状态，把之前卡住的报错信息一并放进新提示词，带着「伤疤」重新出发。哪怕不加引导，模型的随机性也可能让它换条路走通。Nathan补充了自己的版本：每个能跑的状态都提交保存，回滚时把上次卡住的报错原文写进新提示词，提醒AI这次绕开，往往真的管用。

直播后半段，Anton干脆重开一局验证这套方法论：不先连Supabase，减少活动部件；URL、FireCrawl抓取、OpenAI分析，三条提示词一气呵成，3轮编辑完成。第一遍17轮里踩过的坑，全变成了第二遍的路线图。他说，如果所有账号都提前登录配置好，这个App从头到尾5分钟就能建完，欢迎网友录速通视频来挑战。

现场还有个好笑的花絮。他们用刚建好的对比工具去比较Bolt和Lovable，对，就是竞品，AI一本正经地说Bolt有内置部署选项而Lovable没有。Anton当场喊冤：我们明明有。Nathan笑着总结，这算是给AI做了一次情景意识测试。

明天就能用的五件事

Anton在结尾说的话够直接：

「如果你现在干活还不用AI，我认为你真的在让你的雇主、你的客户失望。赶紧上车，这是巨大的时间节省。」

作为听众，能直接带走的是这些：

• 提示词的重点是顺序和具体程度，不是文采。拼错字没关系；先说数据流再说界面，一条提示词只压一两个目标。
• 每个能跑的状态都保存，卡住就回滚。在错误里打转超过两三轮，就回到上个正常版本，把报错原文放进新提示词，重走一遍。
• 用词保持中性，或者直接点名工具。不想让AI手写爬虫，就明说「用FireCrawl」；不确定最佳方案时，别用带倾向的动词把它带偏。
• 第一选场景是单一核心功能的内部工具。十几轮编辑能成，成功率远高于一上来做多功能产品。
• 先规划后动手。用chat模式让AI先出方案，确认无误再让它写代码，能省掉大量返工。

两个月900万美元ARR背后的功夫，更多花在把「AI写代码」拆成普通人走得通的路径：替用户选好工具，砍掉分叉，错了就回滚重来。Anton说，现在英语是最热门的编程语言，这话在这期直播里应验了，但AI编程的上限取决于模型，普通人的产出取决于流程。模型每个月都在变强，流程方法论现在就能抄。