從 Lovable 原型到生產：5 個差距

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 費用都變成每月固定的 $55（$25 用於 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 的構建者的平行指南。