从 Lovable 原型到生产：5 个差距

Lovable 让你在几个小时内从一个想法走到一个能跑的应用。你把想要的东西描述一遍，看着它生成一整个 React 应用外加 Supabase 后端，到当天收工的时候，你手上已经有了一个看起来像三人团队做出来的演示。

你拿给别人看。他们注册了。甚至有人付了钱。

接着就是每个 Lovable 构建者都会撞上的那一刻："演示日能跑"和"生产环境能跑"之间的落差。原型是真做出来了，而生产环境完全是另一场比赛。

这里没有贬低 Lovable 的意思。Lovable 做到了它承诺的事：以极快的速度做出能用的原型。只是原型优化的目标是"它跑得起来吗"，生产环境优化的目标是"它能不能可靠、便宜、安全地跑，并且撑得住规模"。

这是两个不同的问题，答案自然也不一样。

Lovable 原型和生产应用之间的 5 个差距

我们跟几十位把 Lovable 原型推上生产的构建者聊过，每次冒出来的都是同样这五个差距。有些一眼就能看到，有些要等到你有了付费用户才会现身。

1. AI 成本随规模上涨：用量涨上去，AI 功能就开始烧钱
2. 负载下的可靠性：API 速率限制、服务中断和超时会直接毁掉用户体验
3. 数据与隐私：用户数据流经第三方 API，带来合规风险
4. 规模化后的性能：API 往返带来的延迟，用户是感觉得到的
5. 供应商锁定：应用的核心功能，押在一家你左右不了其定价和可用性的公司身上

下面一个个来看，也说说各自该怎么办。

差距 1：AI 成本随规模上涨

这是最常见的一个，通常也是第一个让人肉疼的。

你的 Lovable 应用带着 AI 功能：一个聊天机器人、一个摘要器、一个推荐引擎、一层分类逻辑。做原型的时候，这些功能调 OpenAI API，成本基本看不见，一个月最多几美元。

但每一次触发 AI 功能的用户交互都在烧 token，而 token 成本是随用户数线性增长的。

100 个用户时的那 12 美元，你根本不会放在心上。5,000 个用户时的 620 美元，开始吃你的利润。25,000 个用户时的 3,000 美元，可能已经超过你的全部收入。

AI 功能大概率正是用户喜欢你应用的原因，留着。真正要动的是按 token 付费这件事本身。

生产环境的做法： 针对你自己的具体任务微调一个小模型（7B 参数），部署到本地。无论用户数是多少，AI 成本都固定在每月 55 美元（Ertas 25 美元 + VPS 30 美元）。下面的架构一节会展开讲。

差距 2：负载下的可靠性

做原型的时候，调 OpenAI 的 API 基本上一调就通。到了生产环境，你得为它调不通的那些时刻做好准备。

速率限制。 OpenAI 按账号等级设速率限制。你的应用一旦触发请求突增，比如同一分钟里 50 个用户同时点了 AI 功能，就会收到 429 错误，用户看到的是一句"出了点问题"。

API 服务中断。 过去一年里 OpenAI 出过好几次大规模中断。OpenAI 一挂，你应用里的每一个 AI 功能跟着一起挂。你没有兜底链路，没有冗余，也决定不了它什么时候恢复。

超时处理。 GPT-4 的响应要 3 到 10 秒，负载高的时候能拖到 15 到 30 秒。Lovable 生成的前端，多半没有为这些场景准备细致的超时处理、重试逻辑或者加载态。

生产环境的做法： 跑在你自己基础设施上的模型没有速率限制（吞吐由你自己控制），OpenAI 出事故的时候它照常工作，微调过的 7B 模型响应一般在 0.5 到 2 秒。你还可以加一层兜底：先走本地模型，本地模型不可用时再回退到 OpenAI。

这个可靠性差异落到实处，大概是这样：

差距 3：数据与隐私

这个差距是悄悄摸上来的。

你的应用每往 OpenAI API 发一次用户输入，这份数据就走一遍 OpenAI 的基础设施。原型演示阶段没人在意；到了有付费用户的生产应用，问题就实打实了：

GDPR 合规。 如果你有欧洲用户，你就是在把他们的个人数据发给一家美国的第三方。这会牵出数据处理协议的要求、隐私声明的义务，还可能涉及跨境传输限制。法律上的暴露面不小。

用户信任。 你的隐私政策里多半没写用户输入会交给 OpenAI 处理。等用户发现了（早晚会发现），一部分人就走了。在医疗、法律、金融、人力资源这类敏感行业尤其明显。

数据留存。 OpenAI 的数据留存政策改过好几轮。用户数据被处理完之后会怎么样？这个答案不完全握在你手里。

行业合规。 如果你做的是医疗（HIPAA）、金融（SOC 2）或者政府（FedRAMP）方向，把数据发给外部 API 这条路可能一开始就走不通。有些企业只要 AI 处理发生在自己场地之外，连评估你的产品都不会评估。

生产环境的做法： AI 模型跑在本地，用户数据就不会离开你的基础设施，也没有第三方数据处理方需要操心。你的隐私说法可以很简单："你的数据留在我们自己的服务器上，就这样。"在任何一个受监管的行业里这都是竞争优势，对每一个用户来说也都是信任信号。

差距 4：规模化后的性能

API 的往返会带来延迟，应用越大，这份延迟叠得越明显。

Lovable 应用里一个典型的 AI 功能，链路是这样的：

1. 用户触发一个操作（请求到达你的服务器，500ms）
2. 你的服务器把请求发给 OpenAI（网络延迟 100-200ms）
3. OpenAI 处理请求（GPT-4 要 2,000-8,000ms）
4. 响应传回你的服务器（100-200ms）
5. 你的服务器把响应发给用户（500ms）

一次 AI 交互合计 3 到 9 秒。超过 2 秒用户就有感觉，到了 5 秒以上，他们会开始怀疑应用是不是坏了。

负载一高还会更糟。OpenAI 的服务器繁忙时，那 2 到 8 秒的处理时间能拉长到 15 到 30 秒。队列开始堆积，用户开始暴躁地连点，错误率飙升。

生产环境的做法： 本地运行的微调模型，把去 OpenAI 的那一趟网络往返整个去掉，推理就发生在跟应用同一台服务器上（或者旁边的 VPS 上）。7B 模型跑在一台配置尚可的 VPS 上，典型响应时间是：

用户感受到的 AI 功能是即时的。这是实打实的体验提升，直接影响留存。

差距 5：供应商锁定

你的 Lovable 原型里，AI 功能完全依赖 OpenAI。这意味着：

• 价格一变，你立刻受影响。 OpenAI 涨价（或者改计费模式）的时候，你的利润率一夜之间就变了。你没得谈，想换掉它也躲不开大量返工。

• 模型下线会弄坏你的应用。 OpenAI 已经下线过好几个模型版本。你用的版本走到生命周期终点时，你必须迁移，而新版本的行为可能不一样，你的提示词和用户的预期会一起被打乱。

• 功能可用性没有保证。 OpenAI 随时可以改速率限制、使用政策或者功能权限。已经有创业公司在几乎没有提前通知的情况下被限制甚至取消了 API 权限。

• 你做不出差异化。 所有用 GPT-4 加同一段提示词的应用，产出的东西大同小异。你的 AI 功能是一件大路货，任何竞争对手抄一段提示词就能复刻出来。

生产环境的做法： 一个属于你自己的微调模型，把供应商依赖整个拿掉。模型、训练数据、部署方式和成本都由你掌控。想更新模型，按你自己的节奏重训一次。想换底座模型（比如从 Qwen 换到 Llama），换就是了，训练数据还是那一份。

更要紧的是，微调模型是你的知识产权。 它把你的领域经验、你的用户的使用模式、你的产品的具体行为都编码在了里面。这才是护城河，竞争对手调同一个 API 是复刻不出来的。

生产就绪的 AI 架构

一个 Lovable 应用的生产就绪 AI 技术栈，大概长这样：

┌────────────────────────────────────┐
│  Your Lovable App (Vercel/Netlify) │
│  React + Supabase                  │
└──────────────┬─────────────────────┘
               │
               ▼
┌────────────────────────────────────┐
│  Your VPS ($30/month)              │
│  ┌──────────┐  ┌────────────────┐  │
│  │  Ollama   │  │  Fine-Tuned    │  │
│  │  Server   │──│  Model (GGUF)  │  │
│  └──────────┘  └────────────────┘  │
└────────────────────────────────────┘

相对于原型，改动是外科手术式的：

1. 应用前端原封不动（它是 Lovable 生成的，别去动它）
2. 原来调 OpenAI 的那个 API 路由，改成调你的 Ollama 端点
3. 其余的一切，认证、数据库、业务逻辑，全都不变

API 调用的改动通常就是一行：

// Before (prototype)
const endpoint = "https://api.openai.com/v1/chat/completions"

// After (production)
const endpoint = "http://your-vps-ip:11434/v1/chat/completions"

Ollama 支持 OpenAI 兼容的 API 格式，所以请求体、请求头和响应解析全都不用改，变的只有那个 URL。

Ertas 如何补上这道差距

从"我知道我该微调一个模型"到"我有一个微调模型跑在生产环境里"，中间这段路是大多数构建者卡住的地方。传统上，微调需要：

• ML 工程知识
• GPU 资源
• Python 脚本
• 超参数调优
• 模型评估流水线
• 格式转换工具

Ertas 把这些全都拿掉了。只要你能导出 API 日志、上传一个文件，你就能微调出一个模型。

一个 Lovable 构建者从原型走到生产，流程是这样的：

1. 导出你的 OpenAI API 日志，取最近几周的。你需要的是成对的输入提示词和 AI 响应，至少 200 到 500 条样本。

2. 上传到 Ertas Studio。 把 JSONL 或 CSV 文件拖进去。Ertas 会校验你的数据，并给出一份预览。

3. 选一个底座模型。 对大多数 Lovable 应用来说，Qwen 2.5 7B 是对的选择：速度快，在窄任务上准确，便宜的硬件就跑得动。

4. 训练。 点一下按钮。LoRA 配置、学习率选择、训练轮数和验证集划分都由 Ertas 处理。训练要 15 到 45 分钟。

5. 评估。 Ertas 会给你并排的对比：在你的测试用例上，微调模型的输出对上原来 GPT-4 的输出。质量够不够，一眼就看得出来。

6. 导出 GGUF。 一次点击，下载一个文件，那就是你的生产模型。

7. 用 Ollama 部署。 把 GGUF 文件放到 VPS 上，启动 Ollama，改一下 API 端点，收工。

整个过程，从导出 API 日志到拿到一个生产可用的本地模型，占用你的时间是几个小时，摊在一两天里完成（其中大部分是在等训练跑完）。

上线前的检查清单

在把本地运行的 AI 正式推上线之前，把这份清单过一遍：

基础设施

• VPS 已开通，至少 4 vCPU、16GB 内存
• Ollama 已安装，并配置为开机自启
• 模型已加载，能响应测试请求
• Ollama 端点已做防护（防火墙规则，或者只走内网）
• VPS 监控已就位（CPU、内存、磁盘）

质量验证

• 用 50 条以上真实输入同时跑过 OpenAI 和本地模型做对比
• 在你的使用场景下，输出质量达到或超过 OpenAI
• 边界情况已处理（空输入、超长输入、格式异常）
• 响应格式符合应用的预期（JSON 结构等）

应用改动

• API 端点已指向 Ollama
• 超时处理已配置（本地模型更快，但仍要设一个合理上限）
• 模型不可用时的错误处理（重启 Ollama，或者回退到 OpenAI）
• 必要时更新响应解析（Ollama 格式对上 OpenAI 格式）

监控与迭代

• 记录 AI 的输入和输出，供后续重训使用
• AI 端点的错误率监控
• 收集用户对 AI 质量的反馈
• 随着数据积累，规划每月一次的模型重训

成本跟踪

• OpenAI API key 已移除，或者降级为仅作兜底
• VPS 成本已纳入运营预算
• Ertas 套餐保持有效，可持续做微调
• 上个月的 API 成本已记录下来，方便对比

真正重要的几个数字

一个典型的 Lovable 应用从原型走到生产，前后对比是这样：

生产版本成本低 93%，响应快 3 到 5 倍，数据留在自己手里，每月开销可预测。这已经是另一种商业模式了。

什么时候该切换

不用等到成本疼了才动。切换的最佳时机是你手上的数据够微调了，通常是 AI 功能积累了 200 到 500 次真实用户交互之后。

有的构建者在 100 个用户时就切了，有的等到 1,000 个。切得越早省得越多，同时你也确实需要足够的数据，才能微调出一个好模型。

一个还算靠谱的经验法则：OpenAI 账单超过每月 50 美元并且还在往上走，就是时候了。 搭起来的成本是几个小时的工作量，回本周期通常不到一个月。

你的 Lovable 原型已经证明这个想法成立。接下来，让它在规模上也成立。

延伸阅读

• 你的Vibe编码应用达到了10K用户。现在你的AI账单是$3K/月。：按 token 计价的 AI 应用，规模化时的完整成本拆解。
• 独立应用的自托管 AI：用自己的模型替代 GPT-4：为什么自托管模型对独立开发者和小团队是对的选择。
• 从 Cursor 到生产：部署无供应商锁定的 AI 功能：写给用 Cursor 而不是 Lovable 的构建者的平行指南。