讀完這一章，你會知道如何在 Lovable 裡把前端頁面接上真正的後端。你會理解 Lovable、Supabase 與 Lovable Cloud 的分工，學會描述資料模型、產生資料表、連接表單與列表、使用 Storage、Realtime、Edge Functions 和 Secrets，並知道為什麼 RLS（Row Level Security，列層級安全） 是 production（正式上線）app 的安全底線。
這章不會把所有後端主題一次講完。登入與權限會留到第 10 章，金流、Email、AI 與第三方 API 會留到第 11 章。第 9 章要先處理一件事：讓你的產品資料真的可以被保存、讀取、更新、驗證和保護。
第 8 章做完首頁後，你已經有一個像產品的介面。但只要資料還停在畫面上，它就仍然只是 prototype（原型）。
真正的全端網站至少要回答這些問題：
Lovable + Supabase 的價值，是你可以用產品語言描述需求，讓 Lovable 協助你產生 UI（使用者介面）、資料表、查詢邏輯與後端 function。你仍然要審查資料模型與安全規則，但你不用從空白專案開始手刻所有 boilerplate。
這是 Lovable 從「AI 網頁產生器」變成「AI 全端網站 agent」的關鍵分界。
很多人聽到後端，第一反應是 database。這只對一半。
在產品裡，後端代表的是「產品狀態」：
資料表 = 產品記憶
身分驗證 = 誰正在使用
Storage = 使用者上傳的檔案
Realtime = 狀態變更如何同步
Edge Functions = 不能放在前端的邏輯
Secrets = 不能曝光的憑證
RLS = 誰可以碰哪些資料
所以你不要只問 Lovable：
請新增資料庫。
你要描述：
這個產品需要保存更新日誌項目。
每個項目都屬於一個專案。
團隊成員可以撰寫項目草稿。
已發布的項目會顯示在公開更新日誌頁面。
未發布的草稿只供通過身分驗證的團隊成員查看。
這樣 Lovable 才能從產品規則推導資料模型，而不是只幫你生一張模糊的 table。
Lovable 文件裡有兩條後端路線：
兩者都以 Supabase 的 open-source foundation 為基礎，都能提供 database、auth（驗證）、storage、edge functions 等能力。差別在於管理方式。
這條路線適合：
Lovable 會透過 Supabase integration 連到你的 project（專案），協助你產生 schema、UI（使用者介面）與後端邏輯。當需要建立 table 或修改 schema 時，Lovable 可能會給你 SQL snippet，請你到 Supabase SQL Editor 執行，再回到 Lovable 確認完成。
Lovable Cloud 是 Lovable 內建的 full-stack cloud platform。它把 backend（後端）hosting、database、auth（驗證）、storage、edge functions、AI 和 logs 放進 Lovable 工作流裡，讓你不必另外建立 Supabase project（專案）。
這條路線適合：
但使用 Lovable Cloud 前要先知道幾個限制：
如果你是個人或小團隊，想學清楚資料庫與後端概念，我建議先用自己的 Supabase project（專案）練習。你會更明確看到資料表、SQL、Auth（驗證）、Storage、Policies 和 Logs。
如果你想快速做 app，且接受 Lovable Cloud 的管理方式，可以用 Lovable Cloud。實務上，你要看的不是哪個比較「高級」，而是哪個比較符合你的 ownership、部署、成本與資料治理需求。
圖 9-1：連接自己的 Supabase project 後，Lovable 可以從 chat 設計 schema、執行 migration、部署 Edge Functions，並把 UI 接上資料。
圖 9-2：Lovable Cloud 提供同一套全端能力但不需另設 Supabase account；選擇重點在後端所有權、帳務與管理介面。
開始第 9 章前，請先準備：
本章延續第 8 章的 LaunchNote 案例。
LaunchNote 是給台灣獨立開發者和小型 SaaS 團隊使用的更新日誌工具。
它需要保存：
- 專案
- 更新日誌項目
- 標籤
- 附件
最小可行後端：
- 建立更新日誌項目。
- 編輯草稿。
- 發布項目。
- 顯示公開更新日誌。
- 上傳項目封面圖片。
這是一個適合練習 Supabase 的案例，因為它有資料表、關聯、狀態、公開頁面、內部管理頁面和檔案上傳。
做後端時，最容易犯的錯是先請 Lovable 加一個 form。表單很快會出來，但資料模型可能很亂。
正確順序是：
產品物件
-> 欄位
-> 關聯
-> 狀態
-> 權限
-> UI
你可以先用 Plan Mode 要 Lovable 幫你設計資料模型：
實作前，請先規劃 LaunchNote 的後端資料模型。
產品背景：
LaunchNote 讓小型 SaaS 團隊把產品更新發布到公開更新日誌。
核心物件：
- 專案
- 更新日誌項目
- 標籤
- 附件
規則：
- 一個專案可以有多筆更新日誌項目。
- 一筆更新日誌項目屬於一個專案。
- 一筆更新日誌項目可以有多個標籤。
- 更新日誌項目的狀態可以是草稿或已發布。
- 已發布項目會顯示在公開更新日誌頁面。
- 草稿只會顯示在內部儀表板。
- 附件可以包含項目內使用的圖片。
請提出：
- 資料表和欄位。
- 關聯。
- 重要索引。
- 應設為必填的欄位。
- 基本 RLS Policy 假設。
- 現在應實作和留待日後實作的項目。
暫時不要修改應用程式。
這個提示詞的目標不是讓 Lovable 立刻改程式，而是先產生一份可以審查的 database plan。
Lovable 可以幫你產生資料表，但你不能把 schema 審查外包掉。資料模型一旦錯了，後面 UI（使用者介面）、auth（驗證）、RLS（Row Level Security，列層級安全）、API 都會跟著歪。
審查時請特別看：
id、created_at、updated_at。owner_id、team_id、project_id。以 LaunchNote 來說，最小 schema 可能會像這樣：
projects
- id
- name
- slug
- description
- created_at
- updated_at
changelog_entries
- id
- project_id
- title
- slug
- summary
- content
- status
- published_at
- cover_image_url
- created_at
- updated_at
tags
- id
- project_id
- name
- slug
- created_at
changelog_entry_tags
- entry_id
- tag_id
你不一定要在第一版就把 ownership、team membership、audit log 全做完。但你必須知道這些東西會在哪裡接上。
這就是第 9 章和第 10 章的分界：第 9 章先建立資料模型，第 10 章再把 user、role、permission 補完整。
當 schema plan 確認後，再進入 Build Mode：
請實作 LaunchNote 的第一個後端版本。
請使用 Supabase 作為資料持久化方案。
為以下物件建立必要的資料庫 Schema：
- projects
- changelog_entries
- tags
- changelog_entry_tags
建置以下使用者介面流程：
- 列出更新日誌項目的內部儀表板頁面。
- 建立項目表單。
- 編輯項目表單。
- 只顯示已發布項目的公開更新日誌頁面。
項目欄位：
- title
- summary
- content
- status：draft 或 published
- published_at
- cover_image_url
行為：
- 儲存為草稿時，該項目不會出現在公開更新日誌。
- 發布時將 status 設為 published，且 published_at 為必填。
- 公開更新日誌只顯示已發布項目，並依 published_at 由新到舊排序。
完成整合前，請先顯示我需要執行的所有 SQL。
如果你使用自己的 Supabase project（專案），Lovable 可能會產生 SQL snippet。請到 Supabase SQL Editor 執行，再回 Lovable 說明你已完成。
執行 SQL 前，請先看懂它大概做了什麼。你不需要變成 DBA，但至少要確認：
後端接上後，不要只看畫面。你要測試資料真的有進 database。
最小測試流程：
updated_at 或畫面內容有更新。你可以請 Lovable 幫你建立 seed data：
請新增用來測試 LaunchNote 的種子資料。
請建立：
- 一個名為「LaunchNote Demo」的專案。
- 三筆更新日誌項目。
- 一筆草稿。
- 兩筆 published_at 日期不同的已發布項目。
- 三個標籤：產品、修正、改善。
加入種子資料後，請驗證：
- 儀表板顯示所有項目。
- 公開更新日誌只顯示已發布項目。
- 已發布項目依時間由新到舊排序。
目前不要加入身分驗證。
如果 Lovable 需要你執行 SQL，請先確認資料是測試資料，不是真實 production（正式上線）data。
產品很快會需要圖片或檔案。以 LaunchNote 來說，每篇 changelog entry 可能需要 cover image 或附件。
Supabase Storage 或 Lovable Cloud Storage 可以處理這件事。資料表通常只保存檔案 URL、path 或 metadata（中繼資料），不直接把檔案塞進資料表。
你可以這樣 提示詞：
請為更新日誌項目新增封面圖片上傳功能。
需求：
- 使用者建立或編輯項目時，可以上傳一張封面圖片。
- 把檔案儲存在後端 Storage。
- 把圖片 URL 或 Storage 路徑儲存在 changelog_entries 資料列。
- 在公開更新日誌頁面顯示已發布項目的封面圖片。
- 驗證檔案類型為圖片。
- 上傳期間，使用者介面仍應可以正常操作。
- 上傳失敗時顯示清楚的錯誤訊息。
這項功能不要允許上傳影片。
審查重點：
Lovable Cloud 文件提到 storage buckets 預設是 private，且所有 plans 預設阻擋建立 public storage buckets。這是好事，因為公開檔案應該是明確決策，不是無意間發生。
Supabase 支援 realtime updates。這很強，但不代表每個功能都要即時。
適合 Realtime 的情境：
不一定需要 Realtime 的情境：
LaunchNote 的 public changelog 通常不需要 realtime。但 internal dashboard（儀表板） 如果團隊多人一起編輯，就可以考慮讓列表即時更新。
範例：
只在內部更新日誌儀表板新增 Realtime 更新。
當其他團隊成員建立、更新、發布或刪除項目時，不必重新整理頁面就更新儀表板清單。
不要在公開更新日誌頁面加入 Realtime 行為。
實作範圍僅限於 changelog_entries。
Realtime 會增加複雜度與資源使用。請把它留給真的需要即時同步的產品場景。
Edge Functions 是後端邏輯的位置。只要某件事不能安全地放在 browser 裡，就應該考慮放到 Edge Function。
常見情境：
在第 9 章，我們先用一個不碰外部金流的例子：發布 changelog 時，自動產生一段短摘要。
請為更新日誌發布流程新增 Edge Function。
當項目發布時：
- 根據項目內容產生一段簡短易懂的摘要。
- 把摘要儲存到 summary 欄位。
- 保持原始內容不變。
- 如果摘要產生失敗，請回傳清楚的錯誤。
這個工作流程請使用後端邏輯。
不要在前端程式碼暴露任何 Secret Key。
這裡的重點不是 AI，而是「這段邏輯應該跑在後端」。第 11 章會再深入 AI、Email、Paddle 和第三方 API。
.env 要分清楚
圖 9-3：Cloud 工具可依風險設定自動允許、逐次核准或禁止；涉及 schema、auth、storage 與 secret 的操作，建議保留明確的核准界線。
Lovable Cloud 文件把 Secrets 和 VITE_ environment variables 分得很清楚：
VITE_ 開頭的是 build-time browser-exposed values，放在 .env。簡單判斷：
不能被使用者看到 -> Secrets
本來就會進瀏覽器程式包 -> VITE_ .env
適合放 Secrets 的例子：
RESEND_API_KEY
OPENAI_API_KEY
適合放 .env 的例子：
VITE_SUPABASE_URL
VITE_SUPABASE_PUBLISHABLE_KEY
不要把 secret 塞進前端。也不要以為變數名稱很隱密就安全。只要進 browser bundle，使用者就有機會看到。
你可以請 Lovable 做一次檢查：
請檢查這個專案使用環境變數和 Secrets 的方式。
檢查：
- 沒有後端 Secret 暴露在前端程式碼中。
- 所有 VITE_ 變數都可以安全公開。
- Edge Functions 從 Secrets 讀取私人憑證。
- 原始碼檔案中沒有寫死的 API Key。
修改前，請先回報調查結果。
RLS（Row Level Security，列層級安全）, Row Level Security, 是 Supabase app 上線前最重要的安全概念之一。它控制誰可以讀或寫哪些 rows。
Lovable 文件也明確提醒：Supabase 的 development default 可能比較寬鬆，上線前必須設定 RLS（Row Level Security，列層級安全） policies，並在 Supabase dashboard（儀表板） 裡審查與測試。
第 9 章先建立一個基本觀念：
沒有經過 RLS 審查，就不要把含有真實資料的應用程式視為可正式上線。
即使你還沒做登入，也要先知道未來的 policy 會怎麼長。以 LaunchNote 來說：
你可以請 Lovable 先產生 RLS（Row Level Security，列層級安全） plan：
請為 LaunchNote 建立 RLS Policy 計畫。
目前的資料表：
- projects
- changelog_entries
- tags
- changelog_entry_tags
存取規則：
- 公開訪客可以讀取已發布的更新日誌項目。
- 公開訪客不能讀取草稿。
- 通過身分驗證的團隊成員，可以讀取和編輯自己所屬專案的項目。
- 使用者不能存取自己不屬於的專案。
請提供：
- 必要的所有權或成員關係資料表。
- 讀取、新增、更新和刪除所需的 Policy。
- 驗證 Policy 的測試案例。
暫時不要套用 Policy，我要先審查計畫。
這個 plan 會自然銜接第 10 章，因為完整權限需要 auth（驗證）、user roles、membership table 和 test users。
Lovable 的 Environments 文件描述 Test and Live environments：Lovable 在 Test 建置，Live 是 production（正式上線），publish 才把 application code 和 database schema 同步到 Live。資料和 Cloud configuration 不會互相覆蓋。
但同一份文件也明確標示：截至 2026-03-24，這個功能不再提供給新的 Cloud projects。既有已啟用的 Cloud projects 才繼續有 access。
所以書裡要用保守講法：
這不是小細節。後端 schema 改動可能影響真實資料。你要把「在哪裡測試」當成後端設計的一部分。
實作前，請先規劃後端資料模型。
產品：
LaunchNote 協助小型 SaaS 團隊發布公開更新日誌。
物件：
- 專案
- 更新日誌項目
- 標籤
- 附件
規則：
- 一個專案有多筆項目。
- 項目可以是草稿或已發布。
- 只有已發布項目會出現在公開更新日誌頁面。
- 草稿只供內部使用。
- 項目可以有標籤。
- 項目可以有一張封面圖片。
請提出：
- 資料表與欄位。
- 關聯。
- 索引。
- 必填欄位。
- RLS 假設。
- 這次要實作什麼，哪些留到之後。
暫時不要修改應用程式。
為什麼有效：
請實作 LaunchNote 第一個使用 Supabase 的版本。
請建立：
- 更新日誌項目的儀表板清單。
- 新增項目表單。
- 編輯項目表單。
- 公開更新日誌頁面。
資料行為：
- 把項目儲存到 Supabase。
- 草稿只出現在儀表板。
- 已發布項目出現在公開更新日誌頁面。
- 公開項目依 published_at 由新到舊排序。
- 顯示載入、空白和錯誤狀態。
完成整合前，請先顯示我需要執行的 SQL。
為什麼有效：
請為更新日誌項目新增封面圖片上傳功能。
需求：
- 每筆項目可上傳一張圖片。
- 把檔案儲存在後端 Storage。
- 在項目資料列儲存圖片路徑或 URL。
- 顯示上傳進度。
- 上傳失敗時顯示清楚的錯誤訊息。
- 已發布項目要顯示圖片。
- 保持行動版版面穩定。
安全：
- 除非必要，不要讓整個 Storage Bucket 公開。
- 請說明哪些檔案需要公開讀取權限，以及原因。
為什麼有效：
請建立用來發布更新日誌項目的後端函式。
當草稿發布時：
- 驗證 title 和 content 不可為空。
- 把 status 設為 published。
- 如果缺少 published_at，請補上。
- 根據 content 產生簡短摘要。
- 把 summary 儲存到資料庫。
- 任何步驟失敗時，請回傳結構化錯誤。
這段流程請放在後端邏輯。
不要在前端程式碼暴露私人憑證。
為什麼有效：
請檢查目前的資料庫 Schema，並提出 RLS Policy。
存取需求：
- 公開訪客可以讀取已發布項目。
- 公開訪客不能讀取草稿。
- 通過身分驗證的使用者只能管理自己所屬專案的項目。
- 使用者不能讀取或修改其他團隊的專案。
請提供：
- 缺少的所有權或成員關係欄位。
- select、insert、update、delete Policy。
- 每個 Policy 的測試案例。
- 目前 Schema 的風險。
等我核准計畫後，再套用變更。
為什麼有效：
用 Lovable + Supabase 或 Lovable Cloud 替 LaunchNote 建立第一版後端。
用 Pattern 1 請 Lovable 規劃資料模型。
預期結果：
用 Pattern 2 實作 dashboard（儀表板）、create form、edit form 和 public changelog。
預期結果：
用 Pattern 3 加入 cover image upload。
預期結果：
用 Pattern 5 產生 RLS（Row Level Security，列層級安全） plan。
預期結果：
UI（使用者介面）可以幫你發現欄位，但不能取代資料模型。先畫資料物件，再做表單。
很多內容型產品都需要狀態。沒有狀態欄位，你很難安全地分開 internal 和 public。
任何進 browser bundle 的值都不能當 secret。需要 private key 的邏輯請放到 backend（後端）function。
Realtime 很吸引人，但會增加複雜度。除非產品真的需要即時同步，先用一般讀寫就好。
RLS（Row Level Security，列層級安全） 不是「有打開」就安全。你要用不同角色、不同資料狀態、不同 project（專案）測試。
schema change 可能破壞 production（正式上線）。做正式產品時，要先備份、測試、審查 SQL，再 publish 或 migration。
不是每個 project（專案）都要一開始接 Supabase。
先不要加 backend（後端）的情境：
Lovable 很容易讓你快速加上 backend（後端），但產品決策還不穩時，太早加資料庫會讓你背負遷移成本。
VITE_ variables 是否只包含可以公開的 build-time values？讀完本章後，建議用自己的專案情境繼續追問 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鐵人賽
看影片追技術