讀完這一章，你會得到一套可以重複使用的 Lovable delivery checklist。無論你做的是 landing page、會員平台、AI 工具、內部營運工具，或下一個自己的產品，都可以用這套流程把 vague idea 變成可驗證、可發布、可維護的 production（正式上線）app。
全書最後要留下的不是一堆功能名稱，而是一個工作方式：
想法 -> 規劃 -> 建置 -> 驗證 -> 安全檢查 -> 發布 -> 迭代
Lovable 的強大不在於你可以用一句話生成很多畫面，而在於它能把自然語言變成 agentic full-stack workflow（工作流）。你要學會的，是如何讓這個 workflow（工作流） 每一步都有品質門檻。
AI 生成工具最大的誘惑是速度。
速度本身不是問題。問題是你可能在沒有釐清需求、沒有驗證資料、沒有檢查權限、沒有測試 live flow 的情況下，把東西 publish 出去。
這本書從第 1 章到第 29 章其實一直在重複同一個觀念：
不要只問 Lovable 能不能做。
要問這個功能是否有規格、資料、權限、測試、安全、發布與迭代計畫。
這章把前面所有內容整理成一套可以印下來、貼在專案旁邊的檢查清單。
最後一次練習，請從前面四個台灣案例任選一個，用本章重新審查：
| 案例 | 最重要的資料風險 | 必做的故障演練 | 上線證據 |
|---|---|---|---|
| 營隊招生 | 兒童與家長資料、名額超賣 | 最後名額競爭、付款回傳重送 | 權限矩陣、對帳紀錄、通知失敗待辦 |
| 診所預約 | 預約個資與醫療資料越界 | 同時搶時段、改期、提醒失敗 | 無病歷資料、櫃檯權限、保存政策 |
| 小型電商 | 價格竄改、庫存與收件資料 | 重複付款、物流與發票失敗 | 訂單快照、庫存事件、交叉狀態看板 |
| 採購簽核 | 跨部門存取與自我核准 | 重複決策、停權、外部 API 中斷 | Revision、決策事件、代理與停權證據 |
審查不能只勾選「已完成」。每個重要項目至少附上一項畫面、資料事件、測試結果或正式設定作為證據。
Lovable 的 agentic delivery loop 有七段：
想法
規劃
建置
驗證
安全檢查
發布
迭代
每一段都有一個核心問題：
| Stage | Core question |
|---|---|
| Idea | 你到底要解決誰的什麼問題？ |
| Plan | AI 是否先理解規格、資料與風險？ |
| Build | 這次要實作的範圍是否夠小且可驗證？ |
| Verify | 你如何證明它真的可用？ |
| Secure | 誰能看、誰能改、哪些資料不能外洩？ |
| Publish | 上線設定是否正確，live site 是否驗證？ |
| Iterate | 下一步是根據證據前進，還是只是加功能？ |
如果你只做 Build，就會得到快速 prototype（原型）。
如果你跑完整 loop，才會得到可以持續前進的產品。
圖 30-1：完整交付循環從清楚的問題、範圍與 non-goals 開始，再逐步進入建置。
第一步不是 提示詞。第一步是釐清想法。
請先回答：
提示詞：
請在建置前協助我釐清產品想法。
想法：
請在這裡描述應用程式構想。
請回傳：
- 目標使用者。
- 主要問題。
- 第一條使用者流程。
- 涉及的核心資料。
- 第一版應包含的內容。
- 第一版明確不包含的內容。
- 最大風險。
- 一段可作為專案背景的產品規格。
好規格通常包含「不做什麼」。這能保護專案不被 AI 生成速度拖進過大範圍。
Checklist:
圖 30-2：Plan Mode 用於先確認架構、步驟與風險，讓後續實作保持可控。
進 Build Mode 前，先讓 Lovable 計畫。
Plan 的品質要看：
提示詞：
請在編輯程式碼前建立實作計畫。
應用情境：
請描述目前的應用程式與目標功能。
請包含：
- 路由變更。
- 使用者介面元件。
- 資料模型變更。
- 身分驗證或權限假設。
- 外部整合。
- 邊界情況。
- 安全疑慮。
- 驗證計畫。
- 建議的實作順序。
先不要寫程式碼。
Plan 不需要完美，但必須暴露風險。沒有風險的 plan 通常只是看起來漂亮。
Checklist:
Build 要小。
好的 Build slice 是：
一個明確功能
一組明確檔案或區域
一個可測結果
一組明確不碰的東西
壞的 Build Mode（建置模式）提示詞：
請建置完整的 SaaS 產品。
好的 Build Mode（建置模式）提示詞：
只實作候補名單表單的資料儲存功能。
背景：
- 產品介紹頁的使用者介面已存在。
- 表單已有 name、email、company、role、team_size 與 message 欄位。
需求：
- 請建立 leads 資料表。
- 送出時新增一筆資料。
- 顯示載入中、成功與錯誤狀態。
- 妥善處理重複的 email。
限制：
- 不要重新設計產品介紹頁。
- 不要加入登入功能。
- 不要加入付款功能。
- 不要加入管理後台。
驗證方式：
- 說明如何確認資料已成功新增。
- 列出需要重新執行的測試。
每次 Build 都要限制 collateral changes。Lovable 能改很多，不代表你應該讓它一次改很多。
Checklist:
只要 app 有資料，就要先想 data model。
問自己：
提示詞：
請在實作前檢查資料模型。
功能：
請描述功能。
請提出：
- 資料表。
- 欄位。
- 必填欄位。
- 關聯關係。
- 擁有者或租戶欄位。
- 狀態欄位。
- RLS 存取模式。
- 哪些資料可以公開。
- 哪些資料必須保密。
- 哪些資料不應儲存。
- 資料遷移風險。
Data model 不清楚時，不要急著做 UI（使用者介面）。UI（使用者介面）可以很快改，資料和權限一旦錯了，後面會更難修。
Checklist:
Auth（驗證） 是「你是誰」。Authorization 是「你能做什麼」。
不要混淆。
常見 pattern：
提示詞：
請檢查這項功能的身分驗證與授權。
使用者類型：
- 未登入使用者。
- 已登入使用者。
- 擁有者。
- 管理員或經理。
- 付費使用者（若適用）。
針對每種使用者，請定義：
- 可以存取的路由。
- 可以讀取的資料。
- 可以建立的資料。
- 可以更新的資料。
- 可以刪除的資料。
- 應該看見的介面操作。
- 強制執行權限的後端規則。
標示目前僅由前端限制的規則。
如果某個權限只存在於 UI（使用者介面），那它不是安全規則，只是顯示規則。
Checklist:
第三方整合要問三件事：
誰擁有憑證？
誰能使用連線？
失敗時產品怎麼處理？
適用整合：
提示詞：
請在實作前檢查整合設計。
整合服務：
請填入服務名稱。
請定義：
- 支援哪一項商業工作流程。
- 需要哪些憑證或連線。
- 哪些人可以建立或管理連線。
- 需要哪些權限範圍。
- 整合失敗時應如何處理。
- 哪些資料會傳送至整合服務。
- 哪些資料會儲存在本機。
- 如何安全地測試。
- 如何中斷連線或輪替憑證。
對台灣讀者，本書金流主線是 Paddle。不要讓 AI 自動把付款流程帶向其他 provider，除非你的產品確實有不同地區與法務需求。
Checklist:
圖 30-3：最終驗證組合使用 browser testing、frontend tests 與 edge tests 覆蓋不同層次。
「看起來可以」不是驗證。
你需要選對測試方式：
提示詞：
請為這項功能建立驗證計畫。
功能：
請描述功能。
請包含：
- 瀏覽器測試案例。
- 前端測試（若有幫助）。
- 後端邏輯存在時的後端驗證案例。
- 資料檢查。
- 身分驗證與權限檢查。
- 安全檢查。
- 發布後的正式環境冒煙測試。
針對每個測試，請列出：
- 操作步驟。
- 預期結果。
- 失敗代表的問題。
- 失敗是否會阻擋發布。
不要要求 Lovable「改完順便測所有東西」。大型變更和測試最好拆成兩個 提示詞。先 build，再 verify。
Checklist:
發布前問：
提示詞：
請在發布前執行安全審查。
請著重檢查：
- 外洩的密鑰。
- 身分驗證與路由保護。
- RLS 政策。
- 擁有者或租戶之間的資料隔離。
- Edge Function 授權。
- 整合服務憑證。
- 付款或權益檢查。
- 錯誤訊息。
- 紀錄與敏感資料。
- 公開路由與私有路由的區分。
請回傳：
- 阻擋發布的重大問題。
- 高優先度修正。
- 中優先度改善。
- 發布前需要執行的測試。
Basic scan 是底線。Deep scan 適合會員、付款、AI、內部工具和處理敏感資料的 app。
Checklist:
Publish 是 release，不是存檔。
發布前確認：
提示詞：
請建立發布準備報告。
應用程式：
請描述應用程式。
請檢查：
- 專案存取權。
- 網站存取權。
- 網域。
- 網站資訊。
- 安全掃描。
- 公開網站的 SEO 審查。
- 身分驗證重新導向。
- 付款流程（若有）。
- 電子郵件流程（若有）。
- AI 使用情況（若有）。
- 外部整合。
- 正式環境冒煙測試計畫。
請回傳：
- 阻擋發布的問題。
- 發布前必須修正的問題。
- 可在發布後安全處理的項目。
- 最終發布檢查清單。
Public SaaS 和 internal tool 的 publish readiness 不同。不要用同一套標準硬套，但都要有明確 release gate。
Checklist:
上線後，不要立刻加一堆功能。
先看：
提示詞：
請在第一次發布後檢查這個應用程式。
請摘要：
- 正常運作的功能。
- 失敗的功能。
- 使用者看得見的問題。
- 後端或整合問題。
- 安全或存取疑慮。
- 下一步最有價值的改善。
- 目前應避免進行的變更。
- 建議的下一個迭代範圍。
Iteration 的目標不是永遠加功能，而是讓產品更可靠、更清楚、更接近使用者需求。
Checklist:
當你不知道怎麼開始，可以用這個提示詞：
我正在使用 Lovable 建置應用程式。
想法：
請描述應用程式。
請幫我把這份想法整理成代理式交付計畫。
請回傳：
- 產品規格。
- V1 範圍。
- 非目標。
- 路由圖。
- 資料模型。
- 身分驗證與權限模型。
- 外部整合。
- 實作順序。
- 驗證計畫。
- 安全檢查清單。
- 發布準備檢查清單。
- 第一段建置提示詞。
先不要寫程式碼。
這個提示詞的目標不是讓 Lovable 一次做完，而是讓它先成為你的 product architect。
用這份 checklist 檢查任何 Lovable 專案：
Lovable 更適合當 agentic delivery environment。你要和它一起 plan、build、verify、secure、publish、iterate。
沒有說不做什麼，AI 很容易幫你加太多。
只要有資料，就要問誰能 read / write / update / delete。
會員與內部工具一定要測 non-owner case。
Publish 只是 release。Live smoke test 和下一輪 iteration 才是產品工作。
越接近公司資料、客戶資料、金流、AI 成本，越需要 workspace（工作區）governance、security scans、GitHub sync 和 audit trail。
Lovable 的價值不是讓你少想，而是讓你把想清楚的事情更快做出來。
最強的 Lovable 使用者，不是 提示詞最短的人，而是能把產品、資料、權限、測試、安全與發布標準講清楚的人。
這本書的主軸可以收斂成一句話：
使用代理式工作流程，把想法變成可以交付的全端網站。
下一個專案開始前，先回到這份 checklist。不要急著生成。先讓 Lovable 成為你的產品規格師、系統設計師、測試夥伴、安全 reviewer 和 release assistant。然後再按下 Build。
讀完本章後，建議用自己的專案情境繼續追問 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鐵人賽
看影片追技術