本章目標

讀完這一章，你會知道什麼時候該用 Plan Mode，以及如何讓 Lovable 在不改程式碼的前提下，幫你釐清產品想法、比較技術方案、設計資料模型、調查 bug、評估風險，最後產生可審查、可編輯、可核准的實作計畫。

Plan Mode 是 agentic workflow（工作流） 的煞車與方向盤。Build Mode 負責執行，Plan Mode 負責判斷。你越早學會用 Plan Mode，後面越不容易把 Lovable 推進錯方向。

為什麼這一章重要

AI 開發工具最大的誘惑是「直接做」。你想到一個功能，就想立刻叫 Lovable build。這很爽，但也很危險。

當功能很小，例如改一段文案、調整按鈕、加一張卡片，直接 Build 沒什麼問題。但當功能牽涉登入、資料庫、金流、角色權限、第三方 API、production（正式上線）設定時，直接 Build 等於讓 agent 在不完整資訊下替你做架構決策。

Plan Mode 的價值，是讓你把「想清楚」放回流程裡，而且不犧牲速度。

你可以把 Plan Mode 想成：

• 產品經理：幫你釐清需求與 MVP。
• 架構師：幫你比較做法與資料模型。
• Debug partner：幫你調查問題，不急著亂改。
• Reviewer：幫你評估目前專案是否有風險。
• 實作前的合約：把接下來要做的事寫成 plan。

最重要的是：Plan Mode 不會修改你的 code。這讓它成為高風險任務前最好的安全區。

思考模型：Plan 是決策，Build 是執行

Lovable 有兩個核心模式：

• Plan Mode：思考、探索、比較、調查、產生 plan。
• Build Mode：實作、修改檔案、處理錯誤、驗證結果。

你不該把 Plan Mode 當成普通聊天。它的真正用途是讓你在動手前先決定方向。

一個健康的 workflow（工作流） 會長這樣：

問題 -> 規劃 -> 檢查 -> 核准 -> 建置 -> 驗證

如果你略過 Review，就會變成：

模糊想法 -> 建置 -> 非預期修改 -> 除錯 -> 更多修改

後者是很多 AI 開發專案失控的來源。

Plan Mode 不是拖慢你，而是讓你不要把時間花在修錯方向。

圖 4-1：開始新專案前先確認模式為 Plan；此時可以附上設計、connector 或 database 上下文，但還不會修改程式碼。

什麼時候一定要用 Plan Mode

以下情境，我建議先用 Plan Mode：

• 你還沒確定 MVP 範圍。
• 你要加入登入、權限、資料庫、金流或 AI API。
• 你要改 shared layout、routing、auth（驗證）flow 或資料 schema。
• 你不確定有幾種做法。
• 你想比較 Lovable Cloud 和 Supabase。
• 你遇到 bug，但不知道根因。
• Try to Fix 已經失敗兩三次。
• 你要重構一段已經能運作的功能。
• 你要在發布前做安全、SEO 或架構 review。

反過來，這些情境可以直接 Build：

• 改文案。
• 改一個 isolated component。
• 增加 FAQ。
• 調整 spacing、顏色、CTA。
• 根據已核准 plan 做下一個小步驟。

判斷標準很簡單：如果錯了會牽動很多地方，先 Plan。如果錯了只是一小塊 UI（使用者介面），直接 Build。

Workflow: 從問題到可核准計畫

步驟 1：先說清楚你要探索什麼

Plan Mode 需要明確問題。不要只說「幫我想一下」。你要告訴 Lovable 你要它扮演什麼角色、評估什麼方向、輸出什麼結果。

我想在這個應用程式中新增付費訂閱功能。
實作前，請協助我規劃這項功能。
請聚焦於使用者流程、資料模型、付款服務商、權益判斷邏輯、失敗狀態和安全風險。
不要寫程式碼。

步驟 2：要求它提出假設與問題

很多 plan 失敗不是因為 AI 不會做，而是需求沒有問清楚。

提出計畫前，請列出你目前採用的假設。
如果有任何問題會改變實作方式，請先向我確認。

如果 Lovable 問你「使用者取消訂閱後是否保留到期日前權限」，這不是煩。這正是你應該在 Build 前回答的問題。

步驟 3：要求比較方案

Plan Mode 很適合比較 tradeoffs。

請比較三種做法：
1. 先使用模擬資料建置。
2. 現在連接 Lovable Cloud。
3. 現在連接 Supabase。

針對每種做法，請說明優點、風險、複雜度和適用時機。
最後，請針對適合初學者的 MVP 提出建議。

比較方案能避免你只看到第一個可行解。

步驟 4：要求可審查的 plan

當方向明確後，請 Lovable 產生實作 plan。

請建立一份讓我能在建置前審查的實作計畫。
請包含：
- 範圍
- 假設
- 可能受影響的檔案或區域
- 資料模型
- 使用者流程
- 逐步執行順序
- 驗證計畫
- 風險和復原策略

這個 plan 應該讓你能判斷：要不要做、要怎麼做、哪裡有風險。

圖 4-2：可審查的 plan 會把步驟、依賴、交付物與風險寫清楚；使用者可以在 Build 前修改範圍或順序。

步驟 5：編輯 plan，不要照單全收

Plan Mode 產生的 plan 可以檢查、討論、修改。你可以刪步驟、加限制、改順序。

例如：

請修改計畫：
- 從這個階段移除付款功能。
- 只保留電子郵件潛在客戶資料收集功能。
- 新增行動版版面驗證。
- 新增提醒：目前不要連接資料庫。

你核准的是最終 plan，不是第一版回答。

步驟 6：核准後才 Build

當你滿意 plan，才讓 Lovable 進入 Build Mode。根據 Lovable 文件，核准 plan 後，最新核准版本會保存到 .lovable/plan.md，Build Mode 會依據核准 plan 實作。

這個機制很重要。它把「聊天裡想過什麼」變成「下一步要照什麼做」。

圖 4-3：核准方向並進入 Build 後，Lovable 依計畫執行並回報完成內容；結果仍要對照原計畫逐項驗證。

Plan Mode 的五種典型用法

1. 產品探索

你只有 idea，還不知道怎麼切 MVP。

我想為台灣自由工作者建置一個追蹤專案收入和稅務的網頁應用程式。
請協助我探索這個產品構想。
可能的使用者有哪些？
最小但實用的版本應包含什麼？
第一版應排除哪些項目？
我應該優先驗證哪些使用者流程？
不要寫程式碼。

2. 架構比較

你知道要做什麼，但不知道技術路線。

我需要使用者帳號、已儲存專案和付費存取權限。
請比較這個應用程式使用 Lovable Cloud 和 Supabase 的差異。
請聚焦於設定複雜度、身分驗證、資料庫、Edge Functions、安全性，以及未來交接至 GitHub 的需求。
請為個人創業者的 MVP 建議一條合適的路線。

3. 資料模型設計

你準備接 backend（後端），但還沒決定 tables。

請為會員限定的內容平台設計資料模型。
使用者可以登入、建立私人筆記和收藏文章。
管理員可以發布文章。
請列出必要的資料表、欄位、關聯和存取規則。
先不要產生 SQL。

4. 除錯調查

功能壞了，但你不想讓 Lovable 亂修。

登入表單無法在行動裝置上使用。
預期行為：使用者輸入電子郵件和密碼，送出後進入儀表板。
實際行為：按鈕持續顯示載入中。
請先調查可能原因。
請檢查使用者介面狀態、身分驗證呼叫、網路行為和路由處理。
提出修正方案前，請先說明根本原因。
先不要修改程式碼。

5. 發布前 review

你準備上線前，讓 Lovable 幫你檢查。

請在發布前檢查這個專案。
請聚焦於：
- 無法正常運作的使用者流程
- 缺少的空白狀態
- 安全風險
- SEO 基礎設定
- 行動裝置易用性
- 任何尚未完成的暫用內容

請回傳依優先順序排列的檢查清單。
暫時不要修改任何內容。

如何看懂一份好 plan

一份可用的 plan 不只是步驟清單。它應該包含判斷。

你可以用這張清單檢查：

• 它有沒有重述目標？
• 它有沒有列出假設？
• 它有沒有說明不做什麼？
• 它有沒有指出會影響哪些頁面、components、資料表或 integrations？
• 它有沒有分階段？
• 它有沒有 verification plan？
• 它有沒有列風險？
• 它有沒有說明 rollback 或替代方案？

如果 plan 只有：

1. 新增登入功能。
2. 新增儀表板。
3. 新增資料庫。

這不夠。你要要求它重寫。

這份計畫太粗略。
請重寫並加入假設、受影響區域、資料模型、邊界情境、驗證步驟和風險。

Plan Mode 與 credits

Lovable 文件提到，Plan Mode 每則訊息會扣一個 credit。這代表你不應該無限制地閒聊，但也不該因為省 credit 就跳過規劃。

實務上，你可以把 Plan Mode 用在高槓桿時刻：

• 專案開始。
• 大功能開始。
• 出現不明 bug。
• 接 backend（後端）前。
• 接金流前。
• publish 前。

小修改不用每次都 Plan。大方向一定要 Plan。

提示詞範例

範例 1：MVP 規劃

我想建置 [產品構想]。
目標使用者是 [具體使用者族群]。
商業目標是 [目標]。

請使用 Plan Mode 定義 MVP。
請包含：
- 核心使用者旅程
- 頁面
- 第一版功能
- 延後實作的功能
- 資料需求
- 身分驗證需求
- 整合項目
- 風險和假設

不要寫程式碼。
提出最終計畫前，請先詢問需要釐清的問題。

範例 2：架構比較

我需要實作 [功能]。
請比較至少三種做法。
針對每種做法，請說明：
- 運作方式
- 優點
- 風險
- 複雜度
- 可能影響的既有功能
- 適用時機

最後，請針對這個專案提出建議。
暫時不要修改任何內容。

範例 3：待核准的實作計畫

請為 [功能] 建立建置計畫。

計畫必須包含：
- 範圍
- 不在本次處理的項目
- 假設
- 受影響的頁面和元件
- 資料模型或 API 變更
- 實作順序
- 驗證步驟
- 風險
- 復原計畫

等我核准後再實作。

範例 4：除錯調查

請用 Plan Mode 調查這個錯誤。

預期行為：
[預期行為]

實際行為：
[實際行為]

背景：
[最近的變更]

請：
- 找出可能的根本原因
- 說明應檢查哪些證據
- 建議最小且安全的修正方式
- 告訴我哪些區域不應修改

先不要修改程式碼。

實作練習

回到前面建立的 AI Writer Landing 專案。這次不要建置 新功能，只做 Plan Mode 練習。

任務：

1. 要 Lovable 把 landing page 延伸成一個 AI writing SaaS 的 MVP。
2. 要它比較 frontend（前端）-first、Lovable Cloud、Supabase 三種做法。
3. 要它設計未來可能需要的資料模型，但不要產生 SQL。
4. 要它產生一份第一階段 build plan。
5. 修改 plan，明確刪掉 payment 和 AI API，只保留 lead capture。

完成後，你應該得到：

• 一份清楚的 MVP plan。
• 一份方案比較。
• 一份被你修過的 build plan。
• 一個更小、更安全的第一階段 scope。

常見錯誤

錯誤 1：把 Plan Mode 當搜尋引擎

Plan Mode 不是只拿來問「這是什麼」。它最有價值的地方是結合你的 project（專案）context 做判斷。問它對你的專案有什麼影響。

錯誤 2：Plan 還沒審就 Build

Lovable 產生 plan 不代表你要照單全收。你要像 review PR 一樣 review plan。

錯誤 3：沒有 non-goals

沒有寫不做什麼，plan 很容易膨脹。每份 plan 都應該有 non-goals。

錯誤 4：除錯時太早修

不明 bug 應該先找 root cause。直接修可能只是在症狀上補丁。

錯誤 5：忘記 plan 會變

需求會變，專案狀態也會變。舊 plan 不是永遠有效。大改前重新 Plan。

上線前檢查清單

• [ ] 高風險任務已先用 Plan Mode。
• [ ] Plan 有列目標、scope 和 non-goals。
• [ ] Plan 有列假設與未決問題。
• [ ] Plan 有比較替代方案或說明為何不需要比較。
• [ ] Plan 有資料模型、API 或 integration 影響分析。
• [ ] Plan 有 verification steps。
• [ ] Plan 有風險與 rollback 思路。
• [ ] 你已經人工 review 並修改 plan。
• [ ] 只有在核准 plan 後才進 Build。
• [ ] 最新決策有保存在 project（專案）context 或後續 提示詞中。

延伸閱讀

• Plan Mode（規劃模式）
• 提示詞基礎
• 除錯提示詞
• Lovable 最佳實務

名詞解釋與延伸提問

• Plan Mode：先讓 Lovable 分析與規劃，不直接修改程式碼的工作模式。
• Implementation plan：描述實作順序、影響範圍、風險與驗證方式的計畫。
• Scope：本次要處理的工作範圍。
• Risk review：在動手前先檢查可能失敗或造成副作用的地方。

如何問延伸問題

讀完本章後，建議用自己的專案情境繼續追問 Lovable 或本書作者：

• 「請根據我的專案，重寫本章的檢查清單。」
• 「我的目前版本最可能在哪三個地方失敗？」
• 「請把本章流程改成我下一次可以直接貼上的提示詞。」
• 「如果我要在兩天內完成 V1，哪些範圍應該先刪掉？」

嗨！我是 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。

參加方式：

1. 訂閱本系列文章
2. 分享任一篇系列文章
3. 私訊分享截圖及你的 Lovable 帳號 Email

確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！