讀完這一章，你會知道如何讓 Lovable 在 Build Mode 裡真正接手實作，同時不失去控制。你會學到怎麼下達可執行任務、怎麼設定 guardrails、怎麼看 visible tasks、怎麼使用 prompt queue（提示詞佇列）、怎麼 review diffs，以及什麼時候要求 browser testing、frontend tests（前端測試） 或 backend（後端）verification。
Build Mode 是 Lovable 的執行層。它會改檔案、跑工具、處理錯誤、產生摘要，也可能跨前端、後端和設定一起修改。這很強，但也代表你要用工程交付的方式管理它。
Plan Mode 讓你想清楚，Build Mode 讓事情真的發生。
如果說 Plan Mode 是「決策」，Build Mode 就是「執行」。Lovable 在 Build Mode 會探索 codebase、理解上下文、修改檔案、處理 build error，必要時檢查 logs、network activity 或 testing output。它不是只回覆建議，而是直接對你的 project（專案）動手。
這也是風險所在。
當你說「幫我修一下」，Lovable 可能會做出一組合理修改，但你不一定知道它改了哪些檔案、影響哪些 flow、是否順手重構了你沒要求的地方。如果你想用 Lovable 做 full-stack app，必須學會把 Build Mode 當成一位速度很快的工程夥伴：給清楚任務、設定邊界、看它執行、檢查結果、要求驗證。
本章要建立的習慣是：
清楚任務 -> 護欄 -> 建置 -> 檢查 diff -> 驗證 -> 摘要風險
Build Mode 會「接手 execution」，但不代表你可以完全不管。
比較好的心智模型是：你是 product owner 和 reviewer，Lovable 是 implementation agent。它負責動手，你負責範圍、判斷、驗收。
Build Mode 適合：
Build Mode 不適合：
一句話：Plan Mode 處理「要不要、怎麼做」，Build Mode 處理「照這個方向做出來」。
Build Mode（建置模式）提示詞應該包含五個部分：
例如：
請在產品介紹頁新增潛在客戶表單。
背景：
- 這是採用前端優先策略的 MVP。
- 目前還不連接資料庫。
行為：
- 欄位：姓名、電子郵件、公司。
- 驗證必填欄位和電子郵件格式。
- 送出後顯示成功訊息，並清空表單。
- 請先把送出資料保存在本機狀態。
護欄：
- 不要加入身分驗證。
- 不要連接 Supabase 或 Lovable Cloud。
- 不要修改主視覺區塊文案。
實作後：
- 摘要這次修改了什麼。
- 告訴我如何手動驗證表單。
這不是囉嗦。這是在降低誤會。
在按下 Build 前，問自己：
如果答案不清楚，回 Plan Mode。
Build Mode 最適合接收「已經可以動手」的任務。當你只是想探索可能性，不要急著 Build。
不要只寫「add cart」。要寫使用者做了什麼、系統如何反應、資料如何變化。
不好的提示詞：
請新增購物車。
比較好的提示詞：
請為商品列表新增購物車。
當使用者點擊「加入購物車」時：
- 顯示成功通知。
- 更新頁首的購物車數量。
- 把購物車商品儲存在本機儲存空間。
- 如果同一件商品被加入兩次，增加數量，不要新增重複資料列。
暫時不要加入付款或結帳功能。
行為越具體，Build Mode 越像在實作規格，而不是猜測產品。
Build Mode 可以跨檔案修改，所以 guardrails 不是可有可無。
常用 guardrails：
不要修改身分驗證邏輯。
除非必要，不要編輯共用版面元件。
不要連接資料庫。
不要修改既有的設計系統變數。
這次變更僅限於儀表板頁面。
如果需要更大範圍的修改，執行前請先說明原因。
Guardrails 不只是防止 Lovable 亂改，也能幫你在 review 時判斷是否越界。
如果你明確寫了不要改 auth（驗證），但 diff 裡出現 auth（驗證）相關檔案，就要停下來問原因。
Lovable 在 Build Mode 工作時，會透過 visible tasks 顯示目前步驟、修改檔案、使用工具和進度。這是你理解 agent 行為的重要窗口。
你應該留意：
如果你看到方向明顯錯了，可以停下 request，補更多上下文，再重新來。根據 Lovable 文件，停止 request 會保留目前已完成的變更；如果要移除變更，再用 undo 回到先前狀態。
圖 5-1：Details 的 Timeline 讓 Build Mode 的探索、讀檔與執行步驟可見；發現方向錯誤時，不必等到最終結果才介入。
Build 完成後，不要只看 preview（預覽）。你至少要看：
Lovable 會透過 file diffs 和 summaries 呈現變更。你要把它當成 code review，不是結果通知。
圖 5-2：Changes 分頁把每個新增或修改的檔案展開成 diff；Review 時要確認變更是否符合 guardrails，並檢查是否混入不必要內容。
你可以追問：
請用簡單易懂的方式說明這次變更差異。
修改了哪些檔案？原因是什麼？
你是否修改了任何共用元件或身分驗證邏輯？
進入下一步前，我應該手動驗證哪些項目？
Build Mode 不只確保 code compile。它可以搭配不同驗證工具確認行為。
你要根據問題選工具：
例如，表單 UI（使用者介面）可以用 browser testing：
請用 Browser Testing 驗證潛在客戶表單。
請檢查空白送出、電子郵件格式錯誤、有效資料送出、成功訊息和行動版版面。
登入元件可以加 frontend tests（前端測試）：
請為登入表單撰寫並執行前端測試。
測試範圍應包含空白欄位、電子郵件格式錯誤、載入狀態和成功送出後的回呼。
Backend（後端） function 可以先 direct call：
請使用一段簡短輸入，直接呼叫 summarize Edge Function。
驗證回應結構和錯誤處理。
暫時不要修改使用者介面。
重要原則：大改和測試最好拆成兩個 提示詞。Lovable 的 browser testing 文件也建議，避免在同一個 提示詞裡要求「做大改並測完」。比較安全的流程是先 build，再 follow-up test。
圖 5-3：Build 完成後同時檢查變更摘要與 Preview。摘要說明做了什麼，Preview 則提供使用者可見結果的第一層驗證。
Build Mode 一次處理一個 task。當 Lovable 正在工作時，你可以繼續送 提示詞，它們會進入 visible queue。你可以 pause、resume、reorder、edit、copy、remove，甚至重複某個 queued 提示詞。
這對批次工作有幫助，但也容易讓人失控。
適合 queue 的任務：
不適合 queue 的任務：
如果是高風險任務，不要排一串。Build 一步，看結果，再決定。
Lovable 文件提到，Build Mode 是 usage-based。成本會受到修改檔案數量、邏輯複雜度、探索 codebase 的量、驗證工具、browser checks、web search、image generation 等影響。
這不代表你要怕用 Build Mode，而是要避免浪費。
省成本的方法不是寫短 提示詞，而是寫清楚 提示詞：
模糊提示詞造成的重工，通常比一開始多寫幾行規格更貴。
請在價格預告下方新增常見問題區塊。
內容：
- 問題 1：「這個工具適合誰？」
- 回答 1：「適合需要快速把想法整理成文章的台灣創作者、顧問和行銷團隊。」
- 問題 2：「現在可以直接付款嗎？」
- 回答 2：「目前先開放早鳥名單，正式方案上線後會通知。」
- 問題 3：「會支援繁體中文嗎？」
- 回答 3：「會，第一版會以繁體中文工作流程為主。」
設計：
- 配合目前產品介紹頁的風格。
- 確保行動版容易閱讀。
護欄：
- 不要修改主視覺、潛在客戶表單或導覽列。
只實作已核准計畫中的第一階段。
範圍：
- 新增潛在客戶表單介面。
- 新增本機驗證。
- 新增成功和錯誤狀態。
本次不處理：
- 不連接資料庫。
- 不加入身分驗證。
- 不整合電子郵件服務。
實作後：
- 摘要說明修改的檔案。
- 告訴我如何手動驗證。
請修正潛在客戶表單持續載入的問題。
預期行為：
送出有效資料後，表單會顯示成功訊息並停止載入。
實際行為：
送出按鈕持續顯示載入中。
護欄：
- 不要重新設計表單。
- 不要加入後端整合。
修正後：
請用 Browser Testing 驗證有效資料送出和電子郵件格式錯誤時的行為。
Browser testing（瀏覽器測試） 會讓 Lovable 用真實瀏覽器操作 preview（預覽）：點按鈕、填表單、切頁、看 screenshots、讀 console logs 和 network requests。它很適合驗證完整 user flow。
適合 browser testing：
不適合 browser testing：
Browser testing（瀏覽器測試） 比一般檢查慢，所以不要濫用。你要在關鍵 user flow 上使用它。
每次 Build 結束，最好要求 Lovable 做一次交付摘要：
請摘要這次建置：
- 修改了什麼
- 哪些項目沒有修改
- 如何驗證
- 已知限制
- 建議的下一步
這個摘要可以幫你決定要不要進下一步。如果它提到「payment not implemented」或「data is still mock」，那不是問題，而是範圍控制成功。你只要知道目前狀態即可。
請為 [頁面或流程] 建置 [功能]。
預期行為：
- [行為一]
- [行為二]
- [行為三]
護欄：
- 不要修改 [敏感區域]。
- 不要加入 [範圍外功能]。
- 保留 [角色或流程] 的既有行為。
實作後：
- 摘要說明修改的檔案。
- 說明如何手動驗證。
- 列出所有尚未排除的風險。
只實作已核准計畫中的第 [階段編號] 階段。
範圍：
- [項目一]
- [項目二]
本次不處理：
- [排除項目一]
- [排除項目二]
驗證方式：
- [手動或自動化檢查]
等我核准後再進入後續階段。
第一則提示詞：
請實作個人資料設定表單的使用者介面。
欄位：顯示名稱、個人簡介、網站和頭像 URL。
目前請先使用模擬儲存行為。
不要連接後端。
第二則提示詞：
請用 Browser Testing 驗證個人資料設定表單。
請檢查顯示名稱空白、有效資料儲存、成功訊息和行動版版面。
請說明剛才完成的變更。
依下列類別整理：
- 使用者介面
- 狀態或邏輯
- 資料或後端
- 樣式
- 測試或驗證
請特別指出任何在預期範圍外遭到修改的檔案。
回到 AI Writer Landing 專案。這次用 Build Mode 做一個小而完整的功能：lead capture form。
要求：
預期結果：
Build Mode 很強，但它需要清楚任務。模糊需求會導致模糊實作。
Preview（預覽） 正常不代表所有改動都合理。Diff 是你理解專案變化的關鍵。
大改和 testing 拆開更安全。先實作，再驗證。
Auth（驗證）、payment、database、shared layout 都要寫清楚不要碰哪裡。
Queue 很方便，但高風險任務需要一步一步看結果。
讀完本章後，建議用自己的專案情境繼續追問 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鐵人賽
看影片追技術