讀完這一章，你會知道如何在 Lovable 專案出錯時，系統化地找出原因，而不是反覆要求 AI「再修一次」。你會學會區分 build error、runtime error、preview（預覽） issue、unexpected behavior、edge function error、auth（驗證）problem、payment problem 和 integration failure，並用 Plan Mode、Code Mode、browser testing、logs、direct function calls、revert 和小步重建來恢復穩定。
這章的重點不是背錯誤訊息。真正重要的是 debug workflow（工作流）：先重現，再隔離，再理解，再修正，再驗證，再防回歸。
Lovable 讓你做功能很快，所以錯誤也可能被很快累積。
常見情境：
如果你每次都只說：
請修正這個問題。
Lovable 可能會做出 quick fix，但不一定解決 root cause。更糟的是，它可能為了消除錯誤而改壞別的功能。
Debug 的目標不是讓錯誤消失。Debug 的目標是理解錯誤為什麼發生，並用最小修改修掉真正原因。
Debug 時，不要把整個 app 當成黑盒子。
你要把問題分層：
建置層：程式能不能編譯？
執行層：應用程式開啟後會不會當機？
使用者介面層：使用者能不能看到和操作？
狀態層：身分驗證、載入、篩選、角色是否正確？
網路層：請求是否送出，回應是否正常？
後端層：Edge Function 是否正確執行？
資料層：資料庫是否有正確資料？
安全層：RLS 和權限是否允許正確角色？
整合層：Paddle、Resend、AI、Slack 等外部服務是否成功？
每次 debug，你的任務是把問題從「不知道哪裡壞」縮小成「這一層、這個行為、這個 input、這個錯誤」。
1. 重現：重現問題
2. 觀察：收集錯誤、紀錄、截圖、網路請求和測試輸出
3. 隔離：判斷問題在哪一層
4. 解釋：讓 Lovable 說明根本原因
5. 修正：用最小修改修正
6. 驗證：用正確測試確認
7. 預防：加入回歸測試或記錄注意事項
這個流程比「一直重試」慢一點，但穩定很多。
Debug 提示詞要先講清楚你期待什麼、實際發生什麼。
弱提示詞：
儀表板壞了，請修好。
好提示詞：
LaunchNote 儀表板不再顯示更新日誌項目。
預期行為：
- 登入後，儀表板應列出目前使用者所屬專案的項目。
- 專案 A 在資料庫中有兩筆項目。
實際行為：
- 儀表板已載入，但項目表格是空的。
- 畫面沒有顯示錯誤訊息。
請先用 Plan Mode 調查。
請判斷這是使用者介面狀態、查詢、身分驗證、RLS 或缺少資料的問題。
先不要修改程式碼。
這樣 Lovable 可以先分析，而不是直接亂修。
圖 14-1：Try to Fix 適合處理明確錯誤的第一輪；若沒有解決，就應停止重試，改用 logs、重現步驟與 root-cause 分析縮小範圍。
Lovable 的 troubleshooting 文件建議，build error 出現時可以先用 Try to Fix。這通常是最快第一步，因為 Lovable 能掃 logs、找語法錯誤、缺 dependency 或明顯型別問題。
但 Try to Fix 不是萬能。
適合 Try to Fix：
不適合一直 Try to Fix：
如果 Try to Fix 失敗兩次，切換策略：
停止嘗試自動修正。
請分析目前已經嘗試過哪些方法。
說明最可能的根本原因，並提出更安全的除錯計畫。
先不要修改程式碼。
圖 14-2：複雜問題先在 Plan Mode 拆假設、依賴與證據，再決定修正範圍；這能避免把 symptom 當 root cause。
Plan Mode 很適合 debug，因為它可以先調查、不改 code。
提示詞：
請使用 Plan Mode 調查這個問題。
問題：
Paddle 在測試模式下結帳成功，但回到儀表板後 Pro 功能仍維持鎖定。
預期行為：
- 測試結帳成功後，使用者的訂閱狀態應變成 active。
- Pro 專屬功能應解鎖。
實際行為：
- 付款看起來成功。
- 儀表板仍顯示免費方案。
請調查：
- 是否收到付款事件。
- 是否儲存訂閱狀態。
- 權益邏輯是否讀取正確欄位。
- 使用者介面是否使用過期狀態。
- 紀錄或網路請求中是否有錯誤。
請回傳：
- 根本原因假設。
- 所需證據。
- 最小且安全的修正方式。
- 驗證計畫。
先不要修改程式碼。
這個提示詞把問題拆成 payment event、database、entitlement（權益）logic、UI（使用者介面）state 和 logs。Lovable 會更容易找到真正位置。
如果你知道錯誤在某個檔案附近，Code Mode 可以讓你引用檔案和行號給 Lovable。
範例：
我在 Code Mode 的以下位置找到權益邏輯：
@src/lib/entitlements.ts
請檢查訂閱狀態相關邏輯。
問題：
- canceled 使用者應保留存取權限直到 current_period_end。
- 目前他們會立即失去存取權限。
請先說明目前邏輯。
接著提出最小的變更方式。
不要編輯無關檔案。
這種 提示詞比「修訂閱取消」精準很多。它讓 Lovable 聚焦一個檔案、一段邏輯、一個 expected behavior。
圖 14-3：空白頁或互動失敗要同時看畫面、console 與 network；三者能區分 render error、API failure 與 route／auth 問題。
白畫面通常有幾種原因：
提示詞：
上次變更後，預覽畫面變成空白白色畫面。
請先調查，再決定是否修改。
檢查：
- 建置錯誤。
- 瀏覽器主控台錯誤。
- 最近修改的檔案。
- 路由和身分驗證守衛的行為。
- 元件是否在渲染時拋出錯誤。
- vite.config.ts 或安全性標頭是否遭到修改。
請回傳：
- 最可能的根本原因。
- 證據。
- 最小修正方式。
不要做大範圍重構。
如果你有 console error，直接貼上。Lovable debugging 文件也建議把 DevTools console 內容提供給 AI。
以下是主控台錯誤：
[貼上錯誤]
請用簡單易懂的方式說明其含義。
找出最可能造成問題的檔案或元件。
提出最小修正方式。
Edge Function 錯誤常見原因：
Troubleshooting 文件建議 Edge Functions 出錯時看 Cloud tab -> Logs，並確認 secrets 和 environment variables。
提示詞：
請對 AI 摘要 Edge Function 進行除錯。
症狀：
- 點擊「產生摘要」後顯示錯誤。
- 使用者介面顯示「無法產生摘要」。
請：
- 檢查 Edge Function 的後端紀錄。
- 驗證必要的 Secrets 和環境變數。
- 使用範例酬載直接呼叫 Edge Function。
- 判斷問題出在輸入驗證、AI Connector、額度、速率限制、資料庫寫入或前端處理。
找出失敗層級前，不要修改程式碼。
如果 direct call 成功但 UI（使用者介面）失敗，問題在 frontend（前端）wiring。如果 direct call 失敗，問題在 backend（後端）或 external service。
Email failure 不一定是 Resend 壞掉。事件鏈可能在任何一段斷掉：
使用者操作
-> 後端觸發
-> 信件酬載
-> 呼叫 Resend API
-> Resend 接受請求
-> 投遞／退信／拒絕
提示詞：
請對團隊邀請的 Resend 信件工作流程進行除錯。
預期行為：
- 管理員邀請團隊成員時，應用程式應建立邀請紀錄並寄送信件。
實際行為：
- 儀表板出現邀請紀錄。
- 收件者沒有收到信件。
請調查：
- 是否呼叫信件函式。
- 傳送給 Resend 的酬載。
- Resend 回傳成功或錯誤。
- 寄件網域或寄件者地址是否可能遭到拒絕。
- 是否記錄失敗。
信件發送失敗時，不要阻擋邀請紀錄建立。
這裡要看出一個產品判斷：email 失敗不一定要讓核心操作失敗。Invitation record 可以先建立，再提示 email failure，讓 admin 重寄。
Auth（驗證） 和 RLS（Row Level Security，列層級安全） 常被混在一起。
Auth（驗證） 問題是：
RLS（Row Level Security，列層級安全） 問題是：
提示詞：
請把身分驗證和 RLS 分開，對這個存取問題進行除錯。
問題：
使用者 A 成功登入，但看不到專案 A 的項目。
請確認：
- 使用者 A 是否通過身分驗證？
- Session 是否包含預期的 User ID？
- 使用者 A 是否有專案 A 的 project_memberships 資料列？
- 查詢是否使用正確的 project_id 篩選？
- RLS 是否允許使用者 A 選取專案 A 的項目？
- 是否有資料庫或網路錯誤？
請回傳表格：
- 層級。
- 證據。
- 通過或失敗。
- 下一步操作。
找出失敗層級前，不要修改 Policy。
這種表格化排查能避免 Lovable 直接改 RLS（Row Level Security，列層級安全），結果把資料放太寬。
如果錯誤一直回來，先停下來。
提示詞：
這個問題經過多次修正後仍然存在。
請摘要：
- 目前已嘗試哪些解決方案。
- 修改了哪些檔案。
- 哪些錯誤已改變，哪些維持不變。
- 哪些假設可能有誤。
- 可避開脆弱路徑的不同做法。
先不要編輯程式碼。
這可以幫你避免在同一條錯誤路徑上繼續加補丁。
也可以要求 Lovable 用簡單語言解釋：
請用簡單易懂的方式說明這個錯誤為何發生。
接著說明之前的修正為何沒有解決根本原因。
如果 AI 也說不清楚，通常代表需要更小的 reproduction 或 rollback。
Lovable 支援回到較早版本。當一串修正把系統越修越亂時，revert 往往比繼續 patch 更便宜。
適合 revert 的情境：
Revert 後要告訴 Lovable：
我已把專案還原到付款權益變更前的穩定版本。
請用更小的步驟重新實作功能：
1. 只新增訂閱狀態儲存。
2. 驗證測試結帳後狀態會更新。
3. 新增權益共用函式。
4. 使用 Edge Tests 驗證共用函式。
5. 更新使用者介面的功能門檻。
不要一次實作所有步驟。
Revert 的價值在於重新取得穩定基線。
Auth（驗證）、payments、RLS（Row Level Security，列層級安全）、migration、Edge Functions 都屬於 fragile updates。這些地方不要用寬鬆 提示詞。
提示詞：
這次變更會影響關鍵的付款和權益路徑。
請謹慎執行。
編輯前：
- 檢查相關檔案。
- 找出相依項目。
- 說明目前流程。
- 列出風險。
- 提出最小變更。
編輯期間：
- 不要修改無關元件。
- 除非必要，不要修改資料庫 Schema。
- 不要放寬 RLS Policy。
- 保留既有測試模式行為。
編輯後：
- 使用既有付款測試情境驗證。
- 建議回歸測試。
任務：
請修正 canceled 訂閱的處理方式，讓使用者在 current_period_end 前仍保有存取權。
這種 guardrail 提示詞不只是禮貌提醒。它會改變 Lovable 的工作節奏，讓它先理解再動手。
修完大 bug 後，請 Lovable 總結：
請摘要這次除錯過程。
請包含：
- 原始症狀。
- 根本原因。
- 修改的檔案。
- 套用的修正。
- 執行的驗證。
- 新增或建議的回歸測試。
- 所有後續風險。
請寫成簡短的工程說明，讓我可以儲存到 Project Knowledge 或更新日誌。
這份紀錄很有用。下次類似問題發生時，你可以把它放進 Knowledge 或 troubleshooting notes，讓 Lovable 不要重走錯路。
請用 Plan Mode 調查這個問題。
預期行為：
[應該發生的行為]
實際行為：
[實際發生的行為]
背景：
[最近的變更、受影響功能、測試帳號、環境]
請找出：
- 可能失敗的層級。
- 所需證據。
- 最可能的根本原因。
- 最小且安全的修正方式。
- 驗證計畫。
先不要修改程式碼。
為什麼有效：
預覽畫面是空白白色畫面。
請調查：
- 建置錯誤。
- 瀏覽器主控台錯誤。
- 最近修改的檔案。
- 路由和身分驗證守衛。
- 元件渲染當機。
- vite.config.ts 或安全性標頭變更。
請回傳：
- 證據。
- 可能的根本原因。
- 最小修正方式。
不要做大範圍重構。
為什麼有效：
請對這個 Edge Function 進行除錯：
[函式名稱]
症狀：
[使用者看到的內容]
請：
- 檢查函式紀錄。
- 驗證必要的 Secrets 和環境變數。
- 使用範例酬載直接呼叫函式。
- 判斷問題出在輸入、身分驗證、資料庫、外部 API 或前端處理。
- 建議最小修正方式。
找出失敗層級前，不要修改程式碼。
為什麼有效：
這個問題經過多次修正後仍然存在。
請摘要：
- 已嘗試的方法。
- 修改的檔案。
- 仍然存在的錯誤。
- 可能有誤的假設。
- 不同的實作方式。
- 還原到穩定版本是否更安全。
先不要編輯程式碼。
為什麼有效：
請摘要這次已解決的除錯過程。
請包含：
- 症狀。
- 根本原因。
- 修正方式。
- 修改的檔案。
- 驗證證據。
- 新增或建議的回歸測試。
- 後續風險。
請寫成精簡的工程說明。
為什麼有效：
替 LaunchNote 演練三種 debug 情境。
假設 dashboard（儀表板） 不顯示 entries。使用 Pattern 1 調查。
預期結果：
假設 AI summary 失敗。使用 Pattern 3。
預期結果：
假設 Paddle test checkout（結帳） 成功但 Pro features 沒解鎖，且已修兩次。使用 Pattern 4。
預期結果：
當問題簡單時可以。當問題複雜時，這會讓 Lovable 猜測並產生補丁。
AI 不一定知道你的產品規則。你要說清楚 expected 和 actual。
Edge Functions、Email、AI、payment webhook（事件回呼）都需要 logs。沒有 logs 只是在猜。
登入成功不代表有資料權限。資料被擋不代表登入失敗。
加 null check 可能讓錯誤消失，但資料為什麼是 null 才是重點。
Revert 是控制風險，不是退步。當 code state 失控，回到穩定點通常更快。
Debug 沒有結束於「改了」。Debug 結束於「證據顯示問題已修正，且沒有破壞關鍵流程」。
遇到以下情況，請停止直接修：
這時候應該切到 Plan Mode、整理 attempted fixes、考慮 revert，或把問題拆成更小 reproduction。
讀完本章後，建議用自己的專案情境繼續追問 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鐵人賽
看影片追技術