Lovable 到生產：原型之後發生什麼

Lovable 讓你在幾小時內從想法到可工作的應用。你描述你想要的，看著它產生一個帶有 Supabase 後端的完整 React 應用，到一天結束時你有了一個看起來像三人團隊建立的演示。

你展示給人們看。他們註冊了。甚至有人付費了。

然後每個 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 費用都變成每月固定的 $44.50（$14.50 用於 Ertas + $30 用於 VPS）。我們將在下面的架構部分詳細介紹這一點。

差距 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）

總計：3-9 秒用於單次 AI 互動。使用者注意到超過 2 秒的任何情況。超過 5 秒，他們開始懷疑應用是否壞了。

這在負載下變得更糟。當 OpenAI 的伺服器繁忙時，那 2-8 秒的處理時間可能延伸到 15-30 秒。你的佇列積壓。使用者開始憤怒點擊。錯誤率上升。

生產解決方案： 本地端執行的微調模型完全消除了到 OpenAI 的網路往返。處理發生在你的應用的同一伺服器（或附近的 VPS）上。在良好的 VPS 上 7B 模型的典型回應時間：

你的使用者體驗到感覺即時而非遲緩的 AI 功能。這是直接影響留存的有意義的 UX 改善。

差距 5：廠商鎖定

你的 Lovable 原型的 AI 功能完全依賴 OpenAI。這意味著：

• 定價變化立即影響你。 當 OpenAI 提高價格（或更改其定價模式）時，你的利潤率一夜之間改變。你無法談判。你無法在不進行大量重寫的情況下切換。

• 模型棄用破壞你的應用。 OpenAI 已棄用多個模型版本。當你的模型版本到達生命週期結束時，你必須遷移——而新版本可能表現不同，破壞你的提示和使用者的期望。

• 功能可用性無法保證。 OpenAI 可以隨時更改速率限制、使用政策或功能存取。新創公司已在極少通知的情況下 API 存取受到限制或撤銷。

• 你無法差異化。 每個使用相同提示的 GPT-4 應用都會得到大致相同的輸出。你的 AI 功能不是護城河——它們是商品。任何競爭對手都可以通過複製你的提示來複製它們。

生產解決方案： 你擁有的微調模型完全消除了廠商依賴。你控制模型、訓練資料、部署和定價。如果你想更新模型，就按你的時間表重新訓練。如果你想切換基礎模型（例如從 Qwen 到 Llama），你可以——你的訓練資料保持不變。

更重要的是，微調模型是你的智慧財產。 它編碼了你的領域專業知識、你的使用者模式和你的產品特定行為。那是護城河。沒有競爭對手可以通過呼叫相同的 API 來複製它。

生產就緒的 AI 架構

以下是 Lovable 應用的生產就緒 AI 堆疊樣子：

┌────────────────────────────────────┐
│  你的 Lovable 應用（Vercel/Netlify） │
│  React + Supabase                  │
└──────────────┬─────────────────────┘
               │
               ▼
┌────────────────────────────────────┐
│  你的 VPS（每月 $30）              │
│  ┌──────────┐  ┌────────────────┐  │
│  │  Ollama   │  │  微調後的      │  │
│  │  伺服器   │──│  模型（GGUF）  │  │
│  └──────────┘  └────────────────┘  │
└────────────────────────────────────┘

與你的原型相比，更改是手術性的：

1. 你應用的前端保持完全相同（它是 Lovable 構建的——不要碰它）
2. 呼叫 OpenAI 的 API 路由現在呼叫你的 Ollama 端點
3. 其他一切——身份驗證、資料庫、業務邏輯——都未更改

API 呼叫更改通常是一行修改：

// 之前（原型）
const endpoint = "https://api.openai.com/v1/chat/completions"

// 之後（生產）
const endpoint = "http://your-vps-ip:11434/v1/chat/completions"

Ollama 支援 OpenAI 相容的 API 格式，所以你的請求體、標頭和回應解析都保持不變。唯一改變的是 URL。

Ertas 如何彌合差距

「我知道我應該微調模型」和「我有一個在生產中執行的微調模型」之間的差距，是大多數構建者卡住的地方。微調傳統上需要：

• 機器學習工程知識
• GPU 存取
• Python 腳本
• 超參數調整
• 模型評估管道
• 格式轉換工具

Ertas 消除了所有這些。如果你能匯出你的 API 日誌並上傳檔案，你就能微調模型。

以下是 Lovable 構建者從原型到生產的工作流程：

1. 匯出你的 OpenAI API 日誌，來自過去幾週。你需要輸入提示和 AI 回應作為對。最少 200-500 個範例。

2. 上傳到 Ertas Studio。 拖放你的 JSONL 或 CSV 檔案。Ertas 驗證你的資料並向你顯示預覽。

3. 選擇基礎模型。 對於大多數 Lovable 應用，Qwen 2.5 7B 是正確的選擇——它在狹窄任務上速度快、準確，並在可負擔的硬體上執行。

4. 訓練。 點擊按鈕。Ertas 處理 LoRA 配置、學習率選擇、週期數和驗證分割。訓練需要 15-45 分鐘。

5. 評估。 Ertas 向你顯示並排比較：你的微調模型輸出 vs. 你的測試案例的原始 GPT-4 輸出。你可以立即看到品質是否在需要的水平。

6. 匯出 GGUF。 一鍵。下載單個檔案。那就是你的生產模型。

7. 使用 Ollama 部署。 在你的 VPS 上載入 GGUF 檔案，啟動 Ollama，更新你的 API 端點。完成。

整個過程——從匯出 API 日誌到擁有生產就緒的本地端模型——需要你一兩天內幾小時的時間（大部分時間是等待訓練完成）。

生產清單

在你的本地端 AI 上線之前，請查看這個清單：

基礎設施

• 配置了最少 4 vCPU、16 GB RAM 的 VPS
• Ollama 安裝並配置為開機啟動
• 模型載入並對測試請求回應
• Ollama 端點已保護（防火牆規則，或僅內部網路）
• 設置了 VPS 監控（CPU、記憶體、磁碟）

品質驗證

• 針對 OpenAI 和本地端模型測試了 50 個以上的真實輸入
• 對於你的用例，輸出品質匹配或超過 OpenAI
• 處理了邊緣案例（空輸入、非常長的輸入、意外格式）
• 回應格式與你的應用預期相符（JSON 結構等）

應用更改

• API 端點更新為指向 Ollama
• 配置了超時處理（本地端模型更快，但設置合理的限制）
• 模型不可用的錯誤處理（重啟 Ollama，或退回到 OpenAI）
• 如需要更新了回應解析（Ollama 格式 vs. OpenAI 格式）

監控和迭代

• 記錄 AI 輸入和輸出用於未來重新訓練
• AI 端點的錯誤率監控
• AI 品質的使用者反饋收集
• 計劃隨著你收集更多資料進行每月模型重新訓練

費用追蹤

• OpenAI API 金鑰已移除或降級為僅後備
• VPS 費用在你的運營預算中追蹤
• Ertas 訂閱已啟動用於持續微調
• 已記錄上個月的 API 費用作為比較

重要的數字

以下是典型 Lovable 應用從原型到生產的前後對比：

生產版本費用低 93%，回應速度快 3-5 倍，保持資料私有，並且每月費用可預測。這不是優化——而是不同的商業模式。

何時進行切換

你不需要等到費用變得痛苦。最好的切換時機是當你有足夠的資料進行微調時——通常在你的 AI 功能有 200-500 次真實使用者互動之後。

一些構建者在 100 個使用者時就切換了。有些等到 1,000 個。你越早切換，你省的錢越多——但你也需要足夠的資料來獲得好的微調模型。

一個合理的經驗法則：如果你的 OpenAI 帳單超過 $50/月且還在上漲，是時候了。 設置費用是幾小時的工作，回收期通常不到一個月。

你的 Lovable 原型證明了這個想法是可行的。現在讓它大規模可行。

---

延伸閱讀

• 你的 Vibe-Coded 應用達到 10K 使用者。現在你的 AI 帳單是每月 $3K。 — 帶有每 token AI 定價的應用擴展的完整費用分析。
• 獨立應用的自託管 AI — 為何自託管模型是獨立開發者和小型團隊的正確選擇。
• Cursor 到生產：沒有廠商鎖定的 AI — 使用 Cursor 而非 Lovable 的構建者的平行指南。