讀完這一章，你會完成第三個端到端專案：一個 AI 工具型網站。它包含輸入表單、AI 生成結果、後端 Edge Function、安全 secret handling、用量與錯誤狀態、結果儲存、基本歷史紀錄，以及 Paddle-first 的付費解鎖設計。
這章的重點不是「把 AI 接進前端」。真正的重點是：
AI 呼叫必須走後端，成本和錯誤必須被產品化，付費邏輯必須在伺服端驗證。
AI 工具網站最容易做出 demo，也最容易做出危險的 production（正式上線）app。只要你把 API key（API 金鑰） 放到前端、沒有用量限制、沒有錯誤處理、沒有輸入長度限制、沒有付費驗證，就會從「可展示」變成「可被濫用」。
這章會把 AI 功能當成產品工作流，而不是神奇按鈕。
我們要做的產品叫做 BriefForge AI。
它是一個簡單的產品文案摘要工具。使用者貼上一段產品描述，選擇輸出格式，系統產生：
第一版支援：
暫時不做：
這一章的核心是「一個可營運的 AI 工具骨架」。
傳統表單失敗，通常只是資料沒存或使用者看到錯誤。
AI 工具失敗，可能會有更多問題：
因此 AI 工具的產品規格一定要包含：
Lovable 可以幫你很快接上 AI，但你仍然要定義產品邊界。
Lovable 有幾種 AI 路徑：
這是本章主線。Lovable built-in AI 會幫你的 app 建立 AI backend（後端），並管理 LOVABLE_API_KEY。AI 呼叫會透過後端 Edge Function，而不是直接從瀏覽器呼叫。這是最適合第一版 AI 工具的路徑。
適合：
如果你的 app 需要特定 provider 或特定能力，可以用 connector，例如：
這些 connector 通常需要 workspace（工作區）admin 或 owner 設定連線，並且第三方用量由該第三方帳號收費。
如果你要接自己的 AI provider key，請把 key 放在 backend（後端）Secrets，不要放前端。任何 VITE_ 變數都會進 browser bundle，不適合放秘密。
這章先用 Lovable built-in AI。等第一版穩定，再討論外部 connector。
BriefForge AI 第一版包含：
公開區：
- 產品介紹頁。
- 提供有限免費產生次數的工具示範表單。
- 價格預告。
登入後區域：
- 產生摘要。
- 查看近期產生紀錄。
- 複製結果。
- 查看使用次數。
後端：
- 用於產生 AI 內容的 Edge Function。
- 輸入驗證。
- 使用量限制檢查。
- 付費權益檢查。
- 結果持久化。
- 友善錯誤對應。
資料表：
generations
- id
- user_id
- input_text
- output_type
- result_json
- status
- error_code
- tokens_estimate
- created_at
usage_counters
- id
- user_id
- period_start
- period_end
- generation_count
- created_at
- updated_at
subscriptions
- id
- user_id
- provider
- provider_customer_id
- status
- plan
- current_period_end
- created_at
- updated_at
subscriptions.provider 第一版使用 paddle。不要把付款 provider 寫死在 UI（使用者介面）文字裡，但資料模型可以保留 provider 欄位，方便未來處理不同付款來源。
圖 20-1：把 BriefForge AI 的產品規格送入 Lovable 並選定設計方向後，右側生成工具首頁，對話區保留 prompt 與完成摘要。
AI 工具第一步不要接 AI。先做 landing、表單、結果區塊和狀態。
提示詞：
請建立名為 BriefForge AI 的 Lovable 應用程式。
產品：
BriefForge AI 協助創業者和產品團隊把零散的產品筆記整理成清楚的上線文案。
受眾：
- 新創創業者。
- 產品經理。
- 獨立開發者。
- 行銷團隊。
核心流程：
1. 使用者輸入產品筆記。
2. 使用者選擇輸出類型。
3. 使用者點擊「產生」。
4. 應用程式顯示載入狀態。
5. 應用程式顯示結構化 AI 結果。
6. 使用者可以複製結果。
輸出類型：
- 價值主張。
- 功能重點。
- 產品介紹頁主視覺文案。
- 社群貼文。
- SEO 標題和說明。
第一階段先建置：
- 公開產品介紹頁。
- 工具輸入介面。
- 輸出類型選擇器。
- 空白結果狀態。
- 模擬載入狀態。
- 模擬結果顯示。
- 複製按鈕。
- 價格預告。
暫時不要連接 AI。
暫時不要加入付款。
暫時不要加入登入。
這一步讓你先驗證產品是否說得清楚。AI 工具不是只靠模型，UI（使用者介面）和輸入設計會直接影響輸出品質。
AI 功能要先定義 contract。不要只讓前端傳一大坨自由文字。
Input contract：
input_text: string, required, 80 to 3000 characters
output_type: enum
tone: enum optional
audience: string optional
language: enum default zh-TW
Output contract：
{
"summary": "...",
"sections": [
{ "title": "...", "content": "..." }
],
"metadata": {
"output_type": "...",
"language": "zh-TW"
}
}
提示詞：
請定義 BriefForge AI 的輸入和輸出契約。
輸入：
- input_text：必填，80 到 3000 個字元。
- output_type：必填列舉值：value_proposition、feature_bullets、hero_copy、social_post、seo_metadata。
- tone：選填列舉值：practical、confident、friendly、concise。
- audience：選填文字。
- language：預設為 zh-TW。
輸出：
- 類似 JSON 的結構化結果，包含 summary、sections 和 metadata。
- 使用者介面應清楚呈現結構化結果。
驗證：
- 輸入太短時顯示友善錯誤。
- 輸入太長時顯示友善錯誤。
- 送出期間停用「產生」按鈕。
暫時不要連接真實 AI 呼叫。
這個 contract 會讓後端、前端和測試都更穩。
AI 工具不一定一開始就要登入，但只要有用量限制、歷史紀錄或付費方案，就需要識別 user。
第一版規則：
匿名訪客：可以看到產品介紹頁和工具介面，但必須註冊才能產生內容。
免費會員：每月 5 次產生額度。
付費會員：每月 200 次產生額度。
提示詞：
請為 BriefForge AI 新增身分驗證和用量感知存取。
規則：
- 匿名訪客可以查看產品介紹頁和輸入介面。
- 匿名訪客必須註冊或登入才能產生內容。
- 通過身分驗證的免費使用者每月有 5 次產生額度。
- 付費使用者每月有 200 次產生額度。
- 在儀表板或工具區顯示目前使用次數。
- 使用者達到免費額度時，顯示友善的升級提示。
暫時不要實作 Paddle。
請先使用暫用的付費權益檢查，之後可替換成 Paddle 訂閱狀態。
先用 placeholder entitlement（權益）是合理的，因為你要先把 AI flow 做好，再接金流。
AI 工具應該儲存結果，至少方便使用者回看，也方便你 debug。
提示詞：
請為 BriefForge AI 建立資料庫 Schema。
資料表：
1. generations
- id：UUID 主鍵。
- user_id：必填 UUID。
- input_text：必填文字。
- output_type：必填文字。
- result_json：可為空的 JSONB。
- status：文字，預設值為 pending，只允許 pending、succeeded、failed。
- error_code：可為空的文字。
- tokens_estimate：可為空的整數。
- created_at：含時區的時間戳記，預設值為 now()。
2. usage_counters
- id：UUID 主鍵。
- user_id：必填 UUID。
- period_start：必填且含時區的時間戳記。
- period_end：必填且含時區的時間戳記。
- generation_count：整數，預設值為 0。
- created_at：含時區的時間戳記，預設值為 now()。
- updated_at：含時區的時間戳記，預設值為 now()。
存取規則：
- 使用者可以讀取自己的產生紀錄。
- 使用者不能讀取其他使用者的產生紀錄。
- 使用者不能從前端手動增加自己的使用次數。
- AI 內容產生和使用次數增加應透過後端邏輯執行。
這裡有一個關鍵：usage counter 不應該讓前端自己加。用量是商業規則，必須由 backend（後端）function 控制。
圖 20-2：實際送出 Edge Function prompt 並啟用 Lovable Cloud；完成後工具介面出現結構化輸出區，後端負責驗證、額度與 Lovable AI 呼叫。
AI 呼叫一定要走 Edge Function。
Edge Function 負責：
提示詞：
請為 BriefForge AI 內容產生功能建立 Edge Function。
函式責任：
- 要求使用者通過身分驗證。
- 驗證 input_text 長度為 80 到 3000 個字元。
- 驗證 output_type 列舉值。
- 檢查目前每月使用量。
- 檢查使用者是免費或付費方案。
- 達到使用量限制時阻擋內容產生。
- 從後端呼叫 Lovable 內建 AI。
- 要求模型回傳與 JSON 相容的結構化輸出。
- 在 generations 儲存 input、output_type、result_json、status 和 error_code。
- 只有內容產生成功時才增加使用次數。
- 向前端回傳友善的結構化回應。
安全：
- 不要從前端程式碼呼叫 AI。
- 不要在前端暴露 Secrets。
- 不要信任用戶端的使用次數。
- 不要向使用者回傳原始服務商錯誤。
這是本章最重要的 提示詞。你不是叫 Lovable「加 AI」，你是在定義 backend（後端）boundary。
AI 不是只吃使用者輸入。你要給它角色、輸出格式、限制和語言。
提示詞template 可以這樣：
你是一位產品行銷助理。
任務：
把使用者的產品筆記轉換成要求的輸出類型。
規則：
- 除非 language 另有指定，否則使用繁體中文。
- 內容具體明確。
- 避免誇大。
- 不要杜撰輸入中沒有暗示的功能。
- 回傳與 JSON 相容的結構化內容。
- 每個區塊保持精簡。
輸入：
{{input_text}}
輸出類型：
{{output_type}}
語氣：
{{tone}}
受眾：
{{audience}}
請 Lovable 把這個 template 放在後端，不要讓前端隨便改 system 提示詞。
提示詞：
請更新 BriefForge AI Edge Function 的提示詞範本。
需求：
- 系統指示放在後端程式碼中。
- 前端只能傳入 input_text、output_type、tone、audience 和 language。
- 模型不得杜撰產品功能。
- 模型預設使用繁體中文。
- 模型應回傳與 JSON 相容的結構化輸出。
- 模型輸出格式不正確時，回傳友善錯誤，不要讓使用者介面當機。
AI 工具的結果畫面要能操作，不只是顯示一段文字。
Result UI（使用者介面）：
History：
提示詞：
請為 BriefForge AI 建置結果和歷史紀錄使用者介面。
結果介面：
- 顯示摘要。
- 顯示每個產生的區塊。
- 新增「全部複製」。
- 新增「複製區塊」。
- 新增「產生新內容」。
- 新增「使用相同輸入重新產生」。
歷史紀錄介面：
- 顯示目前使用者近期的產生紀錄。
- 顯示輸出類型、狀態和建立時間。
- 讓使用者開啟先前的結果。
- 不要顯示其他使用者的產生紀錄。
狀態：
- 空白歷史紀錄。
- 載入歷史紀錄。
- 內容產生失敗。
- 達到使用量限制。
Regenerate 要注意用量。它也是一次 AI call，不是免費 retry。只有 provider timeout 或內部錯誤時，你才可能設計不計費 retry。
圖 20-3：把錯誤代碼、繁中訊息、重試與用量規則送入 Lovable，生成集中式錯誤映射、逾時處理與穩定的結果區域。
AI 工具常見錯誤：
| Error | User message |
|---|---|
input_too_short |
請提供更多產品資訊，至少 80 個字。 |
input_too_long |
內容太長，請先縮短到 3000 字以內。 |
usage_limit_reached |
你本月免費額度已用完，可以升級後繼續使用。 |
ai_timeout |
AI 回應時間過長，請稍後再試。 |
ai_malformed_output |
這次回傳格式不完整，請重新產生一次。 |
unauthorized |
請先登入再產生內容。 |
unknown_error |
產生時發生問題，請稍後再試。 |
提示詞：
請改善 BriefForge AI 的錯誤處理。
把後端錯誤代碼對應到友善的繁體中文訊息：
- input_too_short.
- input_too_long.
- usage_limit_reached.
- ai_timeout.
- ai_malformed_output.
- unauthorized.
- unknown_error.
規則：
- 不要向使用者顯示原始服務商錯誤。
- 在後端紀錄足夠除錯所需的詳細資料。
- 出現錯誤時，保持結果區域穩定。
- 合理時允許使用者重試。
- 驗證錯誤不要增加使用次數。
錯誤文案是產品體驗，不是工程細節。
使用者已經說過，台灣人的金流主線用 Paddle。這章延續 Chapter 11：BriefForge AI 的付費解鎖走 Paddle-first。
付費規則：
免費版：每月 5 次產生額度
Pro：每月 200 次產生額度
Paddle integration 要做：
提示詞：
請為 BriefForge AI 新增以 Paddle 為主的付費解鎖。
方案：
- 免費版：每月 5 次產生額度。
- Pro：每月 200 次產生額度。
需求：
- 新增價格方案區塊，包含免費版和 Pro。
- 為 Pro 新增「升級」按鈕。
- 從後端函式啟動 Paddle 結帳。
- 把訂閱狀態儲存在 subscriptions 資料表。
- 處理 Paddle Webhook 事件，更新訂閱狀態。
- 如果可用，為付費使用者新增客戶入口網站連結。
- AI 內容產生 Edge Function 必須在伺服器端檢查訂閱狀態。
- 不要依賴前端使用者介面判斷使用者是否已付費。
不要加入任何其他金流服務商。
最後一句是本書針對台灣讀者的主線決策。不要讓 Lovable 自動帶到其他金流 provider。
AI 功能不能只靠手動點 UI（使用者介面）。
測試項目：
提示詞：
請為 BriefForge AI 建立後端驗證計畫。
請涵蓋：
- 必須登入。
- 輸入驗證。
- 輸出類型驗證。
- 免費用量限制。
- 付費用量限制。
- 成功產生後的資料保存。
- 使用次數增加。
- 驗證失敗不應增加使用次數。
- AI 逾時處理。
- 格式錯誤的 AI 輸出處理。
- Paddle 訂閱權益檢查。
針對每個案例：
- 輸入。
- 預期回應。
- 預期資料庫變化。
- 是否會阻擋發布。
Lovable 的 testing 文件建議：backend（後端）issue 先 direct call Edge Function，再加 edge tests（Edge 自動化測試）。這對 AI 工具非常適合。
使用者看的流程也要測：
提示詞：
請為 BriefForge AI 建立 Browser Testing 計畫。
測試：
- 匿名訪客可以看到產品介紹頁。
- 匿名訪客在產生內容前會被提示註冊。
- 通過身分驗證的免費使用者在額度內可以產生內容。
- 內容產生期間會出現載入狀態。
- 結果正確呈現。
- 「全部複製」可正常運作。
- 近期產生紀錄會出現在歷史紀錄中。
- 使用次數會更新。
- 免費使用者達到額度後會看到升級提示。
- 「升級」按鈕會啟動 Paddle 結帳。
- 從結帳回來後，Webhook 更新完成時會顯示付費狀態。
- 行動版版面仍可使用。
針對每個測試：
- 步驟。
- 預期結果。
- 失敗代表的問題。
- 是否會阻擋上線。
Browser testing（瀏覽器測試） 可以看到真實 flow，但 webhook（事件回呼）和 subscription status 仍要用 backend（後端）verification 交叉確認。
Lovable Cloud 的 AI activity dashboard（儀表板） 可以看到 AI request 的狀態、模型、token、成本、duration 等資訊。這對 AI 工具很重要，因為成本是產品的一部分。
你應該定期看：
提示詞：
請檢查 BriefForge AI 的用量與失敗狀態。
請檢查：
- 近期 AI 請求。
- 失敗的 AI 請求。
- 平均執行時間。
- Token 使用模式。
- 高成本請求。
- 常見錯誤代碼。
請回傳：
- 產品問題。
- 提示詞問題。
- 後端問題。
- 成本控制建議。
- 擴大規模前應完成的變更。
如果 Business 或 Enterprise 關閉了完整 request/response visibility，你仍然可以看 summary metrics。這是隱私和 debugging 的取捨。
AI 工具發布前要跑 security review。
重點：
提示詞：
請為 BriefForge AI 執行安全檢查。
檢查重點：
- 暴露的 Secrets。
- 前端 AI 呼叫。
- Edge Function 身分驗證。
- 用量限制執行。
- Paddle 權益驗證。
- generations 和 usage_counters 的 RLS Policy。
- 錯誤訊息。
- 紀錄和敏感使用者輸入。
- 提示詞注入風險。
請回傳：
- 重大阻礙。
- 高優先修正。
- 中優先改善。
- 發布前所需測試。
這類 app 一定要把「成本濫用」當成安全問題。用量限制不是 billing decoration，它是防濫用機制。
發布流程沿用 Chapter 17。
Live smoke test：
提示詞：
請為 BriefForge AI 建立正式環境冒煙測試檢查清單。
請包含：
- 公開頁面。
- 身分驗證。
- 內容產生流程。
- 結果呈現。
- 歷史紀錄。
- 使用次數。
- 免費額度。
- Paddle 結帳。
- Paddle Webhook。
- 付費權益。
- 錯誤處理。
- 行動版版面。
- 安全掃描狀態。
AI 工具上線後要看第一批真實 usage。不要只看功能通不通，也要看 latency、cost 和錯誤率。
請照這個順序做：
1. 產品規格。
2. 前端工具使用者介面。
3. 輸入和輸出契約。
4. 身分驗證。
5. 資料庫 Schema。
6. Edge Function。
7. AI 提示詞範本。
8. 結果和歷史紀錄使用者介面。
9. 錯誤處理。
10. 用量限制。
11. Paddle 付費解鎖。
12. 後端驗證。
13. Browser Testing。
14. AI 活動審查。
15. 安全掃描。
16. 發布和正式環境冒煙測試。
這個順序的核心是：
先建立產品契約，再接 AI。
先建立後端邊界，再談付費。
先驗證用量和權限，再發布。
前端程式碼可被使用者檢查。秘密只能放 backend（後端）Secrets 或 connector 管理機制。
AI 呼叫要走 Edge Function。這樣才能驗證 user、檢查用量、控制成本、保護 secret。
如果只是把 Generate button disable，使用者仍可能繞過前端。用量限制必須在 backend（後端）enforce。
AI request 可能慢或失敗。UI（使用者介面）必須有 loading、timeout、retry 和 friendly error。
沒有紀錄就難以 debug，也無法做歷史、用量和客服支援。
Validation failure 不該扣。Provider timeout 是否扣，要清楚定義。第一版建議只有成功才扣。
Pro badge 不能當權限來源。Edge Function 必須查 subscription status。
AI 工具的 production（正式上線）指標包含成本、latency、failure rate 和 token usage。只看 UI（使用者介面）是不夠的。
讀完本章後，建議用自己的專案情境繼續追問 Lovable 或本書作者：
嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。
如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：
📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。
📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。
🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。
如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！
🎁 免費送 Lovable 額度給讀者！
我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。
參加方式：
確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！
iThome鐵人賽
看影片追技術