open-lovable开源本地跑，5款大模型随便切，Lovable平替来了

ivye
免费干货
14小时前
17热度
0评论

做前端的朋友大概都见过 Lovable.dev，AI 一句话就能给你整个 React 应用出来，爽是真爽。但订阅费摆在那儿吧，密钥还得交出去，团队拿来用总感觉心里不踏实。

手动去复刻别人网站又太慢了，费时费力，效率低得离谱。这不就两头堵嘛——要么掏钱，要么自己遭罪。

话说 Firecrawl 那帮人（YC W24 出来的）最近搞了个开源的，叫 **open-lovable**。本地跑、支持 5 家大模型随便切、还带双沙箱部署。我实际搭了一遍，三步就起来了，这篇就拆一下它到底解决了啥问题。

open-lovable 究竟是什么

open-lovable 是 Firecrawl 团队官方搞出来的一个 AI web builder 示例应用。干的事特别直白——你把任意网站 URL 丢进去，它帮你抓页面、用 AI 生成一整套现代 React 组件代码，然后秒出可运行的应用。

说白了，它就是 Lovable.dev 那个闭源商业产品的开源平替版。不过 open-lovable 走的是本地优先路线，密钥全留在你自己的机器上，不绑任何云端 SaaS。

**整个流程其实就这几步：你输入 URL → Firecrawl 去抓页面 → LLM 流式生成 Next.js/React 代码 → 沙箱里部署好预览。全程不用离开终端。**

但是……说实话，我得先泼盆冷水。open-lovable 本质上就是个 example app，别指望它能当生产级产品用。Firecrawl 把它是放出来的目的，主要是秀一下自家 API 在 AI web builder 这个场景下能干什么，而不是真的去跟 Lovable.dev 抢商业市场。

README 超短，才 2578 个字符。文档基本全藏在 .env.local 的注释里，releases 也空的——这明显是一份给工程师看的参考实现，不是面向普通用户的产品。

open-lovable 凭什么挑战 Lovable

对手主要有三类，打的点各不一样。

**对 Lovable.dev 自己**，open-lovable 主打"开源 + 本地优先 + 模型无关"。Lovable 闭源、按订阅计费、模型走自家通道；open-lovable 走 MIT 协议，5 家大模型 API Key 想换就换，凭据全部留本地。

说实话，对不想被单一 vendor 锁死、又想自己控制成本的团队，这套组合是有点东西。

**对 v0、Bolt 这类纯云端 AI web builder**，差异在"工程化代码 + 双沙箱部署"。云端工具产出的往往是 HTML 片段或伪代码，丢进 Cursor / VSCode 接着改——你懂的，挺折腾的。open-lovable 直接吐 Next.js + TypeScript 的工程化代码，能丢进任何 React 工程链继续迭代。

而且它支持 Vercel Sandbox（默认）和 E2B Sandbox（可选）两条部署路径，AI 生成的应用一键预览，不用手工配部署环境。对吧，这对懒人来说太友好了。

**对传统手写前端**，差异在"跳过手抄环节"。

复刻一个网站的传统流程是什么？截屏 → 拉框架 → 手写 JSX/CSS → 调样式，几个小时起步。open-lovable 把前两步压到秒级，开发者只需要在生成的代码上做二次精修。

不过话说回来，这套流程能不能真正省工时，还得看具体场景。简单的 marketing page 收益最大，复杂的交互应用嘛……还是得手动调。

5 家大模型 + 双沙箱，怎么搭

技术架构这块说实话设计得挺克制的，没什么花活。

**LLM 层支持 Gemini / Anthropic / OpenAI / Groq / Morphllm 五家**，全部走 .env.local 的 API Key 配置，谁便宜、谁快、谁效果好就切谁——BYOK（Bring Your Own Key，自带模型密钥）嘛，让团队按真实量计费，不被平台抽一层。

比如开发期用 Groq 跑速度验证，正式产出切 Claude 拿质量，成本和效果的平衡点自己掌控。是不是很灵活？

**沙箱层是另一条值得拆的线。** Vercel Sandbox 是默认通道，支持两种认证：OIDC Token（开发推荐，跑 vercel link + vercel env pull 自动获取）和 Personal Access Token（生产场景，从 Vercel dashboard 拿）。

如果你不想绑死 Vercel，E2B Sandbox（e2b.dev）是备选项，配一个 E2B_API_KEY 就能切换。两种沙箱自由切换这个设计我觉得很贴心，平时开发经常遇到单一服务商服务波动，双备份方案能有效避免项目预览流程中断。

有个细节 **Fast Apply**，由 Morphllm 提供。它做的是大文件的快速 diff 编辑，比如生成的 React 文件几千行，AI 只想改其中一小段，传统做法是整文件重写，Fast Apply 做局部 patch 能快一个数量级。

这是可选项，不配也能跑，但开了之后大文件迭代的体感差距很明显。

三步跑通：clone + 配 Key + pnpm dev

上手路径其实就三步。

**第一步 clone + 装依赖：**

git clone https://github.com/firecrawl/open-lovable.git
cd open-lovable
pnpm install  # 或 npm install / yarn install

**第二步配 .env.local**，最小化只需要三项：Firecrawl Key + 1 家 LLM Key + Sandbox provider：

# 必填：Firecrawl API Key（去 firecrawl.dev 注册）
FIRECRAWL_API_KEY=your_firecrawl_api_key

# 至少一家 LLM Key（任选）
GEMINI_API_KEY=your_gemini_api_key
# 或 ANTHROPIC_API_KEY / OPENAI_API_KEY / GROQ_API_KEY

# 沙箱 provider（默认 vercel）
SANDBOX_PROVIDER=vercel

**第三步 pnpm dev，** 浏览器开 http://localhost:3000 进对话界面，就完事了。

老实讲，整个流程对有 Node.js + pnpm 环境的开发者来说基本零摩擦，5 分钟内能从下载到第一个生成的 React 应用。

不过话说回来，如果你选 Vercel 沙箱的话，记得先跑 vercel link 把项目关联上，再跑 vercel env pull，这样 OIDC Token 会自动落到 .env.local 里。你猜怎么着？就是省得手工复制粘贴那堆 key，是不是舒服多了。

适合谁，不适合谁

这套东西的边界得讲清楚。

**适合：**

- 天天在 Cursor / VSCode 里写 React 的前端开发者，想本地搭一套 AI web builder 流程
- 不想交 Lovable.dev 订阅费、又想要同款能力的独立开发者或小团队
- 已经在用 Firecrawl 做网页抓取，想看看官方推荐用法的工程师

对这三类人，open-lovable 是目前最直接的开源选择。

**不适合：**

- 非技术用户。光配 5 家 LLM Key + 沙箱 Token 就够劝退
- 需要生产级 SLA 的团队。它本质是 example app，README 极简、releases 空、无官方支持承诺，拿来跑生产要自己兜底
- 只想用云端 SaaS、本地没装 Node.js 环境的用户。核心 loop 你跑不起来

边界也得心里有数：GitHub 元数据缺失严重（stars/forks/topics/license 字段都是 None，应该是 API 拉取限制），元信息主要靠 README 末尾的 MIT 声明兜底。Fast Apply 和 E2B 都是可选项，默认配置跑的是 Vercel Sandbox + 你选的 LLM。项目最近一次更新是 2025 年 11 月，节奏不算密，跟进得自己注意。

说实话，我觉得 open-lovable 不是要颠覆 Lovable，它是 Firecrawl 给开源社区留的一份参考实现。如果你正好在搭自己的 AI web builder，或者想避开订阅费本地跑一套，它值得花一个下午试一下。

GitHub 开源：https://github.com/firecrawl/open-lovable