这款AI产品每小时都在变聪明，方法却出乎所有工程师意料

不是靠更大的模型，也不是靠更多参数。Lovable 让产品“每小时自我进化”的秘密，居然来自两个极不性感的设计选择：认真定义“卡住”，以及让 AI 学会抱怨。这场分享，把很多 AI Agent 的幻想直接拉回现实。

比模型更重要的，是让产品“活着”

一上来，Benjamin Verbeek 就抛出一个几乎反直觉的事实：Lovable 正在“每个小时都变得更好”，包括他演讲的这一小时。但这并不是靠换模型、堆参数，甚至不是靠什么神秘的 RL 框架。

Lovable 的核心目标只有一个：让用户真的把项目做完。为此，他们选择了一个和主流 AI 产品完全不同的切入点——长期、单一项目。用户会在一个项目里待很久，这意味着产品可以逐渐“认识你”，理解你的习惯、卡点和决策路径。

这听起来不像什么前沿 AI 技术，更像产品经理的基本功。但正是这种“陪用户走完全程”的设计，让 Lovable 有机会做真正的自我改进，而不是一次性演示。Benjamin 的潜台词很明确：如果你的 AI Agent 只活在 demo 里，它永远学不会成长。

Vibe Coding：不是不写代码，而是先不看代码

Lovable 早期提出了一个后来被频繁讨论的概念：Vibe Coding。不是完全不写代码，而是把“代码”从第一视角移走。

理想状态下，用户只需要说出自己想要什么，看结果、测试效果、然后发布。代码存在，但不强迫你直面它。这背后的野心很清楚：他们不是在为程序员优化效率，而是在为“99%不会写代码的人”造工具。

这群人对错误的容忍度更低，对卡住的感知更直接。一旦流程不顺，他们就会放弃。Benjamin 甚至半开玩笑地说：他们在这个过程中“干趴过好几家云服务商”。高频试错、不可预测的使用方式，让系统暴露出大量边角问题。

但正是这些问题，构成了 Lovable 最宝贵的训练数据。不是模型数据，而是产品数据。

第一种“卡住”：你甚至不知道自己卡住了

Lovable 团队花了大量时间做一件听起来很基础的事：定义什么叫“用户卡住了”。

有些卡住是显性的，比如报错、失败；但更多是隐性的——用户反复尝试、频繁回退、长时间停留在某一步。这些信号如果不被系统捕捉，用户就会悄无声息地流失。

他们借鉴了类似 Stack Overflow 的机制，把“解决卡点”这件事系统化，结果是内部评分出现了显著提升。更重要的是，这套机制在规模化之后，带来的变化不是体验更好，而是：更多用户真的把项目完成了。

这对 AI Agent 意味着什么？不是回答更聪明，而是更早意识到“现在该帮忙了”。

第二种“卡住”：AI 自己也会崩溃

更有意思的是第二类卡住：不是用户，而是 AI Agent 本身。

Lovable 给 Agent 增加了一个“vent tool”——直译就是吐槽工具。Agent 可以向创造它的工程师抱怨：这个流程不合理，这个工具不好用，这个复制功能在拖后腿。

听起来很搞笑，但效果极其现实。因为这些抱怨天然带着完整上下文，工程师几乎不用再还原问题场景，就能直接动手改。Benjamin 举的例子很直接：Agent 抱怨 copy 工具，他们就改了。

这形成了一个罕见的闭环：使用者 → Agent → 工程师 → 产品。不是靠指标，而是靠持续的“不爽”。

总结

Lovable 的分享给 AI 从业者一个清醒的提醒：自我进化不是模型能力，而是系统设计。真正拉开差距的，是你有没有认真对待“卡住”这件事——不管是用户，还是 Agent 本身。

如果你在做 AI Agent，不妨问自己三个问题：你的用户会不会长期停留？你是否能第一时间发现他们正在放弃？以及，你的 Agent 有没有资格向你抱怨？

未来真正有生命力的 AI 产品，可能不是最聪明的那个，而是最会发现问题、承认问题、并且持续修正的那个。

关键词： AI Agent， Lovable， Vibe Coding， 产品自进化， 无代码

事实核查备注： 需要核查：1）Benjamin Verbeek 的职位表述（技术成员/Member of Technical Staff）；2）Lovable 是否最早提出“Vibe Coding”这一说法；3）Stack Overflow 机制对内部评分提升的具体指标；4）演讲发生的具体场合与时长。