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 帮忙注册公司。