软件超新星：Lovable 的“超人级全栈工程师”，数秒将想法变成应用

摘要

• Lovable 于11月21日上线后的前2个月内，实现了900万美元年化经常性收入，Anton Osika 称这是他能找到的欧洲所有产品发布中最快的。 数十万用户已经试用，付费用户大约每隔1天就会回来，用户经验从完全不会写代码到深度开发者均匀分布。真正具备投资意义的信号，是软件创作本身存在异常广泛的需求，而不只是专业程序员写代码的速度更快：Lovable 明确瞄准“那99%不会写代码的人”。

• 产品判断是，AI将引发一场“高质量软件的大爆发”，但持久化的界面会在这场爆发中留下来。 Anton 预计，AI会让几乎所有人都能创建和定制软件，但用户仍然看重经过测试、行为可预测的UX，以及长期积累的肌肉记忆。生成式组件会大量涌现，但只要一致性仍然重要，完全生成式界面就不太可能取代标准化产品。

• Lovable 认为，让全栈开发变得可靠的关键不是原始代码生成，而是基础设施的强约束。 每增加一个连接，系统就会“呈指数级地更容易出错”，因此 Lovable 将用户引向 Supabase 数据库和后端函数、Stripe 支付、Firecrawl 网页数据以及基于 Cloudflare 的发布等顺畅路径。价值由此转向能够把部署、调试、密钥和集成统一打包的平台。

• Lovable 通过智能路由把模型选择隐藏在产品内部，并称一旦出现更好的模型，就会“连夜”完成切换。 录制时，Claude 3.5 Sonnet 是其最强的通用编程模型；Google 的快速模型负责最小规模的调用，而 OpenAI 推理模型更适合系统陷入困境时。DeepSeek 的开源属性可能让 Lovable 很快训练并控制自己的默认模型，但 Anton 也承认，最终仍可能由一家供应商在价格和性能上占据主导。

• 现场演示证明了产品的真实效用，也暴露出面向非技术用户的可靠性缺口仍然很大。 团队做出了一个AI产品比价应用：抓取URL、推断购买标准并比较耳机，但过程经历了API报错、手动转移日志和反复提示；第一条路径用了17次编辑，较干净的重建版本被描述为3次编辑，而导语概括为4次提示。Anton 估计，非技术用户遇到问题的概率至少为50%，彻底卡死的概率可能约为10%：“这已经是它最糟糕的时候了。”

• Lovable 正在有意限制代理能力，直到自主执行变得可预测、可解释。 Anton 将LLM代理定义为一个不断行动、观察、再行动的开放循环，但可变的执行时长叠加并不完美的可靠性，会造成“非常糟糕的体验”。近期目标是实现有边界的自调试，并推出代理模式，让系统能够尝试合理恢复，而不是让用户盯着“第87次迭代”却不知道发生了什么。

• 管理层预计，随着基础模型进步，今天的上下文管理技巧会越来越难形成差异化，持久竞争将转向基础设施、UX抽象和执行速度。 Lovable 已经使用“agentic RAG”在不断扩大的代码库中定位内容，但 Anton 预计更聪明的底层模型会削弱这一优势。因此，公司正在构建团队协作、同步IDE编辑、分支和一键生产发布，同时把招聘集中在斯德哥尔摩，围绕异常高的人才密度组建团队。

精读

1. AI将软件创作从稀缺技能变成大众能力

• Nathan Labenz 将 Lovable 归类为AI编程代理和全栈工程师；Lovable 则把自己描述为“超人级全栈工程师”：用户用自然语言描述应用，系统便创建界面、代码、后端连接和部署路径。本期节目检验的，是它能否做出真正的全栈应用，而不只是静态落地页。

• Anton 的前提从稀缺性出发：全球能写代码的人远不到1%，但学会编程让他获得了“一种理解世界、谈论技术并把想法变成现实的超能力”。AI可能把这种能力延伸给剩下的99%，让他们也能创建、编辑和个性化软件。

• 速度构成这套判断的另一半。AI写代码的速度远超人类，Anton 因此预计会出现“高质量软件的大爆发”，人类创造力将以更快的速度释放。现有软件岗位受到的影响更复杂，但大众化创作是他认为“最明显的最大变化”。

2. 即使AI能够预判意图，可预测的界面仍会留下来

• Nathan 用“坏掉的洗衣机”举例，挑战以应用为中心的想象。在一个足够强大的未来，他或许只需告诉通用AI寻找合适的替代品、解释取舍、完成购买并安排安装——就像 Elon Musk 可能直接把整个问题交给AI——而无需打开专门的比价界面。

• Anton 的反驳是，人类偏好行为可预测、且经过大量用户验证的产品。刚生成的界面可能因用户、甚至因每次交互而不同，从而摧毁 Slack 或电子邮件背后共享的解释体系和肌肉记忆：“精确的UX非常难做到。”

• 两者的折中不是让界面彻底流动，而是局部生成。AI可能会“极其擅长预测我们的需求”，并删掉那些仅用于表达偏好的控件，但标准化组件仍会一致地呈现信息。更多软件会主动提取上下文并生成相关组件，但熟悉的产品“多数时候”仍会存在。

3. 强约束基础设施是 Lovable 对全栈脆弱性的答案

• Nathan 在 Replit、Cursor 及类似工具上的经验是，做出漂亮界面并不难，真正让体验崩溃的是部署。缺少依赖、构建失败、端口转发以及将服务暴露到互联网等问题，往往会让AI在惊艳的初始结果之后无法恢复。

• Anton 从机制上解释了这种不对称：当独立生成的组件必须彼此连接时，软件才真正变难，而每增加一个连接，失败概率就会“呈指数级上升”。Lovable 的应对方式是限制选择，而不是让通用编程模型凭空设计一套任意技术栈，任由其中各部分从未经过协同调优。

• 数据库和函数统一走 Supabase；支付则遵循定义好的 Stripe 流程，包括自动生成账户设置路径或API密钥输入框。这些约束旨在让结果“几乎保证能够运行”；相比之下，Cursor 这类约束更少的工具可能生成互不兼容的组件，之后再陷入恢复困境。

• Nathan 认为，这些默认选项可能引发一轮整合。Anton 同意 Tailwind CSS 已经近似开发者之间的谢林点，而语言模型会进一步强化流行技术，因为它们拥有更多训练数据，也能即时复现主流实践。但更好的创新仍然可能获得采用，并“连夜”成为新的默认选项。

4. 智能路由把模型选择变成内部优化问题

• Nathan 将 Cursor 明显可见的模型下拉菜单与 Lovable 隐藏式选择进行对比。让每个开发者自行选择可以快速迁移，但也会造成决策碎片化；集中路由则能让所有用户同步切换，同时把价格、速度和质量的责任放到产品上，而不是交给缺少相关上下文的用户。

• Anton 表示，Lovable 历来会在新模型发布后“连夜切换”。它不依赖单一供应商：智能路由会从 Gemini、OpenAI 和 Anthropic 中选择，DeepSeek 以及可能的 Kimi 也在考虑范围内。内部选择器让团队可以快速调整模型链，并评估整体用户体验是否改善。

• 产品默认希望使用适合任务的最快模型链。如果失败，Lovable 可以开放更深层的分析路径和部分用户控制，使用更大、更慢的模型，而不必让所有人面对供应商名称。Anton 认为，展示完整链路对用户来说“信息量太大”，还会增加选错的概率。

• 录制时，Claude 3.5 Sonnet 仍然是“最好的那个”——速度快、编程和推理能力强，可靠性也最高。Google 的快速模型负责最小规模调用；OpenAI 推理模型在需要从第一性原理恢复的罕见场景中仍然最强。DeepSeek 的开放性，则让更底层的控制以及由 Lovable 训练默认模型在“很快”实现成为可能。

5. 演示从简单界面开始，很快触及后端现实

• Isaak Sundeman 先从一个刻意受限的MVP开始：用户粘贴几个产品URL，点击 Analyze 按钮，获得有关哪些特征值得关注的AI建议。第一条提示只要求先做出精致界面，尚未指定抓取或模型调用，最终生成了一个 React 应用，包含输入框和诚实标注的“功能即将推出”通知。

• Nathan 表示，拼写错误并不会真正让模型困惑，因为模型能够理解；格式和顺序才更重要。应用一旦成形，精确的修改要求会重要得多。Lovable 会先生成计划，并遵循自己偏好的网页开发实践，让用户先看到可运行的视觉状态，再接入外部系统。

• 按钮最初什么也不会做，因为应用没有后端。Isaak 通过一键流程连接 Supabase 项目，为应用提供数据库和后端函数，无需用户自行拼装基础设施。这一连接还会自动把最新上下文发送给 Lovable 的编程模型。

• 纯聊天模式允许团队询问如何获取外部URL数据，而不会立即修改代码。Lovable 推荐 Firecrawl，引导 Isaak 获取API密钥，并打开带有上下文的输入框。用户仍然掌握 Firecrawl 的账户和最终成本，Lovable 没有把第三方服务藏在捆绑计费之后。

6. 外部API暴露出生成与自主执行之间的剩余差距

• Firecrawl 集成制造了本期最明显的摩擦。浏览器与 Supabase 通信，Supabase 调用 Firecrawl，Firecrawl 再抓取产品页面；任何边界都可能失败。因此 Anton 要求的不是只能写出局部合理代码的系统，而是一个“擅长在不同交互组件之间自我调试”的系统。

• 演示中，Isaak 必须打开 Supabase 边缘函数日志，复制错误，再粘贴回 Lovable。Isaak 指出，把这些日志直接喂给AI系统目前还没有上线，但应该尽快实现；Nathan 认为，这本应彻底消除这次人工中断。

• Anton 表示，他认为过去 Lovable 可能贡献了 Supabase 的大部分新增注册，至少曾经如此，也补充说现在可能仍然是这样。他说，Supabase 及类似供应商已经意识到，需要为程序化、代理优先的访问方式构建产品，而不能假设所有事情都由人类开发者手动检查。

• Anton 认为，上下文管理是可靠LLM应用的基础：系统必须判断任务需要API响应、项目历史、知识库还是其他来源。Lovable 在选择并呈现这些上下文上投入很深；据他认识的、对比过不同工具的人反馈，这也是 Lovable 比竞争产品更可靠的原因之一。

7. Lovable 正从积极编码者转向苏格拉底式产品负责人

• Nathan 问，系统如何让用户回答更多问题，而不是在需求不完整时直接锁定一条路径。Isaak 说，聊天模式是早期答案；下一步产品方向是主动插入澄清环节，展示计划，并询问是否准备开始构建。超级用户无需这段对话也能获得价值，但新手需要借此达到相同熟练度。

• Anton 更长期的比喻，不只是AI工程师，而是“首席产品与技术官”，甚至可以与首席设计官或设计负责人合并。这个助手应该质疑需求、建议产品和技术选择，帮助用户更快学习，而不是被动等待结构完美的规格说明。

• Nathan 的提示纪律提供了一个反例：使用“scrape”这个词，可能让缺乏前置推理能力的模型直接写出自制的 requests 加 Beautiful-Soup 代码，即使商业工具更合适。他偏好描述目标结果的中性提示，也看重 Lovable 对生产级默认选项的筛选，而不是每次都重新发明基础设施。

• Lovable 偏好的集成包括 Resend 邮件、Stripe 支付、OpenAI 或 Anthropic AI，以及 Replicate 的各类模型，其他供应商也在争取成为默认选项。Anton 仍承认，系统应该更积极地挑战错误假设；目前它依赖的仍是熟悉相关领域的用户，或“学习速度很快的人”。

8. 比价应用能够运行，但错误定义了当前边界

• Nathan 设计了两阶段分析：先告诉买家，在陌生品类中哪些维度决定满意度，再沿这些维度比较产品。滚筒洗衣机与波轮洗衣机的差异不只是一个功能点，因为波轮机无法叠放，最终会把陌生的技术区别转化为家庭空间决策。

• 产品愿景扩展为3层：识别重要问题的顾问；从不一致规格中整理出的客观“参数对照表”；以及从厂商页面缺失的信息中提炼问题的用户评价摘要。团队希望使用结构化模型响应和函数调用，让这些内容最终呈现为表格，而不是一段没有层次的聊天文本。

• 错误包括400响应、无法识别的请求键、短暂出现的500级“bad gateway”、过时的API假设，以及文本过长导致 OpenAI 无法处理的页面。团队将 Firecrawl 文档加入项目上下文。最终的耳机比较识别出音质、降噪和续航，并以更清晰的视觉方式呈现并排结果。

• Lovable 与 Bolt 的测试也展示了幻觉风险：应用错误地说 Lovable 没有内置部署，并将 Anton 认为本质相同的界面描述成不同产品。Anton 的校准判断是，技术用户可以可靠地构建这类应用；非技术用户遇到摩擦的概率至少为50%，陷入长时间停滞的概率可能约为10%。

9. 用户无法理解当前状态时，开放式代理能力会失效

• Nathan 将代理能力定义为被委托的决策权限，并将其与类似 Zapier 的固定工作流区分开来，后者的步骤和提示都是预先规定的。Anton 强调的则是LLM模式：代理行动、观察结果、再次行动，并在开放式、目标导向的循环中持续推进。大量推理其实可以通过设计好的链路完成，无需这个循环。

• Anton 的反对意见是体验层面的，而非哲学层面的。通用代理的执行时长可能不可预测；再叠加低于100%的可靠性，结果就是“一种非常糟糕的体验”。Lovable 会先优化快速、可靠的调用，只有在额外步骤的行为足够直观、能够维持用户信任后，才会谨慎增加这些步骤。

• Nathan 对 Devin 的实验让成本变得具体：在多个产品之间来回切换后，他回来发现 Devin 已经到了“第87次迭代”，仍在持续工作，却无法快速判断进展。Lovable 内部已经有代理模式，并计划在接下来几周扩大自调试范围，但 Anton 表示，要让代理能力变得可靠且令人愉悦，还需要“大量迭代”。

10. 回滚能把失败生成转化为有用的搜索信息

• 经过17次编辑后，Nathan 提出了他最重视的AI编程实践：每个可运行状态都提交保存，并愿意回到上一个良好状态。模型往往能在干净分支上更有效地实现功能，而不是在多次混乱修补后继续工作。回滚时，他会把失败的错误信息带入修改后的提示，让下一次尝试避开同一条路径。

• Anton 将实现过程想象成一棵搜索树。功能可能要求按照特定顺序完成若干子步骤；如果顺序错了，非技术用户可能不断陷入循环。回滚可以把项目恢复到已知良好状态，同时尝试另一条分支；即使没有额外指导，模型的随机性本身也可能选中成功路径。

• 在较干净的重建版本中，团队更顺畅地结合了URL输入、Firecrawl 抓取和 OpenAI 分析。导语称第二次构建用了4次提示，而现场统计称用了3次编辑；第一次尝试则进行了十几次以上交互，并遭遇了一连串异常糟糕的错误。

• 规模重新带来难题。Nathan 的个人应用已经占据大约100,000个token，迫使他编写脚本，在让 o1 Pro 制定计划前先剥离CSS及其他低价值上下文。Anton 不愿透露具体细节，但表示 Lovable 的“agentic RAG”会随着项目增长检索相关代码；即便如此，数百次编辑和大型代码库仍然明显更难处理。

11. 爆发式增长将 Lovable 的重心推向团队与基础设施

• Lovable 于11月21日上线，此前公司开发刚超过1年，期间经历了多轮产品迭代，包括因UX糟糕而放弃的早期“agent route”。上线后的前2个月内，其年化经常性收入达到900万美元，高于100万美元的年化水平，用户数则达到数十万。

• 编程经验调查大致均匀分布在25%区间，从完全没有经验到深度经验。技术用户因为理解API和架构，能够构建更复杂的系统，但 Anton 更看重的群体由“高行动力”定义：创始人、运营者和代理机构负责人，他们能迅速看清新技术带来的可能性。

• 发布只需点击一次，应用通过 Cloudflare 在边缘部署，并为扩展而设计。用户可以将 GitHub 仓库与 VS Code 或其他IDE同步，在 Lovable 之外编辑代码，把API文档加入项目知识，并通过分支进行实验性修改。团队协作将是 Lovable 从个人开发者向外扩张的下一步。

• Anton 预计，更好的基础模型会让 Lovable 当前的“智能算法”变得不那么重要。长期价值将转向强约束基础设施、合适的UI和代码抽象，以及一支高度协同的斯德哥尔摩团队，后者以市场顶薪招募人才。他最后的建议很强烈，但仍留有余地：“如果你现在还不用AI，我认为，如果你是在为雇主、客户或代理机构运营，那真的很让他们失望。”他的要求是，让自己彻底投入其中。