How-to71°

Lovable 创始人复盘:从 GPT Engineer 到 7000 万个项目,架构推倒重来了好几次

Why we picked it

Lovable 创始人亲述踩坑史:删掉 Agent 代码改回工具调用,用知识文件代替微调,还能给整台运行中的机器做分支。做编程产品的都该看看。

Lovable 创始人 Anton Osika 复盘了产品从 2023 年开源 GPT Engineer 到如今 7000 万个项目、超 10 万个 PR 的演进过程。团队几次推翻重来:删掉了自由度过高的异步 Agent,改回一条用户请求对应一串可预测的工具调用;放弃微调,改用「知识文件」加检索来减少错误,Lovable Stack Overflow 早期版本让用户卡住的比例降低了 5%。后来给每个项目配常驻沙箱,跑增量 TypeScript 检查,缩短检查和修正的循环。最新的 Camille 框架可以对整台运行中的机器做快照、分支和合并,让 Agent 几秒内回到同一工作环境。

Original · shao__meng

Lovable 创始人复盘:从 GPT Engineer 到 7000 万个项目,架构推倒重来了好几次 来自 @antonosika 的分享,Lovable 在 2023 年定下的产品目标几乎没变:让不会写代码的人通过聊天来做软件、部署软件,并且马上看到结果。变的是实现方式,先后几次重做:收窄问题范围,削减 Agent 的自由度,用知识文件代替微调,缩短检查和修正的循环,最后做到对整台运行中的机器做分支和合并。Lovable 至今已在代码库里合并超过 10 万个 PR,用户在平台上创建了超过 7000 万个项目。 起点:先把问题收窄 2023 年春天,Osika 在 GitHub 上开源了 GPT Engineer:你描述想要的软件,它先问几个澄清问题,再写出整个代码库。Lovable 一开始只做新项目,也就是用户带着想法来,Lovable 生成代码并一键托管。这样不用应付各种已有代码库和运行环境。团队还去掉了早期让用户选前端技术栈的选项,统一使用一套固定的技术栈。原则是三件事:限制问题范围、控制代码在什么环境里运行、从运行结果中学习。对这一套固定环境的每次改进,都能惠及大量项目。 Agent 的自由度要和模型能力相当 Osika 原本预期模型会进步很快,所以一直推动团队做自主 Agent。工程师 Mårten Wiman 做过一套复杂的异步设计,Agent 可以自己创建任务、派给子 Agent。结果自由度更高的 Agent 容易钻进技术细节里出不来,频繁出错,完成时间也没法预测,产品反而变得不可靠。 于是团队删掉了几乎所有 Agent 代码,改回一条用户请求对应一串可预测的工具调用,输出就是聊天回复加实时预览。到 2024 年底,主要的编辑流程是一次回复里包含所有需要修改的文件。当时原生工具调用还不够稳定,他们让模型把代码包在 <lov-write> 这类标签里,等模型输出完再解析出改动。系统有重试和错误处理,但没有那种由模型自己调用工具、查看结果、再决定下一步的开放循环,由用户看预览来决定下一步怎么改。上下文方面,他们用几个微调过的小模型挑出每次改动涉及的代码,包括不用修改、但改动依赖它的文件。 原计划训练模型,实际是知识文件加检索更管用 2023 年的计划是用产品数据微调模型。2024 年他们先找到一个更简单的办法:工程师翻看出错应用的聊天记录,把反复出现的错误和避免方法写成简短说明,叫作「知识文件」。例如「只使用 lucide-react 里存在的图标,不要编造图标名」。系统在检索时选出相关的说明,加进模型的上下文,不需要做微调。Osika 认为这对 Lovable 在 2024 年底起飞至关重要,当时甚至称之为一种「扩展定律」:每多写一份知识文件,Agent 就更可靠一些。文中也提到,这和现在的 agent skills 是同一个思路。后来推出的 Lovable Stack Overflow 让 Agent 检索类似问题和解决办法,早期版本让用户卡住的比例降低了 5%。 缩短检查和修正的循环 如果每次修改都要完整构建一遍,再小的改动也会很慢。他们给每个项目准备了常驻的沙箱,保留项目文件,开发服务器一直运行,改动可以直接更新到实时预览。另外跑增量的 TypeScript 检查,复用之前的检查结果,发现错误后交给 Agent 在项目运行时修复。Osika 的判断是,编程 Agent 的速度取决于它多快能检查和改正自己的工作。 对整台运行中的机器做分支和合并 后来他们更进一步:只保存源代码不够,还要保存正在运行的进程。有状态的沙箱可以给机器的内存、CPU 状态和磁盘打快照,需要时恢复,Agent 过几天回来也能在几秒内回到同一个工作环境。这套框架叫 Camille。它现在可以对整个应用连同运行环境和数据库做分支,让 Agent 从同一个起点尝试不同方案,也成为 Lovable 许多功能的基础。 接下来的三个难题 · 把繁琐的运维交给系统:在真实用户和真金白银都依赖应用之后,负责测试、部署、扩容、可用性、安全和提前修复 bug。Osika 认为最难的是信任:用户一句话被误解,就可能删掉数据或造成无法挽回的破坏。 · 覆盖所有类型的软件:桌面、移动端、复杂工作流、实时数据处理和全球化业务系统,每一类都有不同的环境、限制和出错方式。 · 做出更好的软件基础设施:包括可观测性、机器快照的分支与合并、新的同步引擎、持久化执行,以及可验证的安全和隐私保障。 他的目标不是做一个「AI 软件工程师」,是做一个人们可以在上面经营整个生意的平台:用户已经在里面接入 Slack、导入数据、处理支付、做增长和分析,甚至让 Lovable 帮忙注册公司。 Anton Osika @antonosika In 2023, I wrote down an idea for a world where anyone could build software just by describing it. Today, more than 70 million projects have been built with @Lovable . 100,000 PRs later, we're at a point where we fork entire computers, including their memory, running processes, environment and data to give the best customer experience. I love reading about the history of how technology is built, so I wrote down what I got right & what I got wrong back in 2023 and the journey so far. The team will continue sharing what we're learning as we build the software of the future. Here's our inaugural post: 🔗 View Quoted Tweet 💬 4 🔄 0 ❤️ 3 👀 279 📊 4 ⚡