讀完這一章，你會先放下「Lovable 是不是另一個 AI 網頁產生器」這個問題，改用更準確的角度理解它：Lovable 是一個用自然語言驅動的全端產品開發平台。它真正強的地方，不是把一句 提示詞變成漂亮首頁，而是把產品開發裡原本分散在需求、設計、前端、後端、資料庫、整合、測試、安全、部署之間的工作，收斂成一個可以被 AI agent 推進的循環。
這個循環會貫穿全書：
想法 -> 規劃 -> 建置 -> 驗證 -> 安全檢查 -> 發布 -> 迭代
如果你只把 Lovable 當成「幫我生一個網站」的工具，你會很快碰到天花板。如果你把它當成 agentic full-stack workflow（工作流），你才會看懂它為什麼值得用一本 IT 書來講。
過去要做一個全端網站，你通常要跨過很多門檻。你需要把需求寫清楚，找設計方向，建立前端專案，處理路由和狀態，設計資料表，接登入，寫 API，保存 API key（API 金鑰），部署前後端，處理網域，檢查 SEO，還要避免資料外洩。
這些工作沒有一項是神秘的，但每一項都會卡住人。對非工程背景的人來說，它們像一堵牆。對工程師來說，它們則是大量熟悉但瑣碎的交付成本。
Lovable 的主張是：你用自然語言描述想做的產品，它幫你產生可編輯的真實程式碼，並且支援前端、後端、資料庫、驗證、整合、GitHub、部署、安全與治理。這代表你不是只得到一張靜態 mockup，而是得到一個可以繼續迭代、測試、發布、移交的專案。
這一章要先建立正確心智模型。因為接下來的每一章，都不是在教你背按鈕位置，而是在教你如何把 Lovable 當成一個產品交付系統來使用。
第一次打開 Lovable，你最容易注意到的是 提示詞。你輸入一句話，它開始幫你做東西。這很直覺，也很容易讓人誤會。
提示詞只是入口，不是全貌。
圖 1-1：Lovable Dashboard 是產品開發的起點。左側整理 workspace 與既有專案，中央提示詞輸入框可在建立專案前選擇 Plan 模式。
在 Lovable 裡，一個專案不是一段聊天紀錄而已。它是一個 application：有頁面、有 preview（預覽）、有程式碼、有專案設定、有歷史紀錄、有 access control、有 backend（後端）選項、有 GitHub sync，也有 publish 的生命週期。你可以從 提示詞開始，也可以從 template、remix、Figma 截圖、手繪草圖，或既有網站截圖開始。進入專案後，你可以用 chat 修改，也可以用 preview（預覽） toolbar 選畫面元素調整，用 Knowledge 保存專案背景，用 GitHub 讓工程師接手，用 Publish 把目前版本部署出去。
圖 1-2：專案編輯器把 Chat、Preview、檔案與程式碼入口放在同一個工作區，讓需求討論與畫面驗證可以連續進行。
這就讓 Lovable 和一般「產生網站」工具拉開距離。一般生成工具常常停在輸出結果，Lovable 更像是一個工作台：你不是一次拿到答案，而是在裡面持續把產品往前推。
圖 1-3：Publish 不是離開編輯器後的另一套工具；發布網址、可見範圍、安全檢查與版本狀態都留在同一個產品生命週期裡。
很多工具都會說自己能做 full-stack，但實際上可能只是前端頁面加上一點假資料。這本書裡講 Lovable 的 full-stack，會採用更嚴格的定義。
一個全端產品至少需要處理這些層次：
Lovable 文件把這些能力拆在不同地方：Lovable Cloud、Supabase integration、GitHub integration、Payments、Testing、Security、Publish、SEO/AEO。單看每一頁，像是功能說明；合起來看，就是一條完整的產品交付鏈。
這也是本書的寫法。我們不會用「功能 A、功能 B、功能 C」的方式照抄文件，而會用「做出一個能上線的產品，需要經過哪些關卡」來安排章節。
「AI 生成」和「Agentic」有一個很大的差別。
AI 生成偏向一次性輸出。你給它 提示詞，它產生一段文字、一張圖、一個頁面或一段程式碼。結果好不好，主要看那次輸出的品質。
Agentic workflow（工作流） 則偏向持續執行。你給它目標，它會拆步驟、探索上下文、修改檔案、檢查結果、遇到錯誤再修正，必要時回頭問問題或重新規劃。這不是只靠單次生成，而是靠一個可以反覆推進工作的流程。
Lovable 裡的幾個核心概念正好對應這件事：
所以這本書不是教你「怎麼寫神奇 提示詞」。提示詞很重要，但 提示詞只是指令。真正的能力來自你能不能把 Lovable 放進一個清楚的工作流：什麼時候該規劃，什麼時候該實作，什麼時候該驗證，什麼時候該停下來重想。
假設你想做一個「AI 文章摘要工具」，讓使用者貼上長文，系統幫他產生摘要。最簡單的 提示詞可能是：
請建置一個 AI 文章摘要網站。
這樣 Lovable 可能會產生一個看起來合理的網站。但如果你真的要把它做成產品，問題會立刻出現：
這些問題不是 Lovable 的弱點，反而是它能發揮價值的地方。你可以先用 Plan Mode 要它拆出產品規格和技術風險，再用 Build Mode 實作第一版，接著用 browser testing 檢查使用者流程，再補上 Paddle、Email、AI backend（後端）function，最後檢查安全與發布。
比較好的第一個提示詞會長這樣：
我想建置一個小型 SaaS 產品：AI 文章摘要工具。
目標使用者是台灣創作者與行銷人員。
第一版應該包含產品介紹頁、文章輸入、摘要輸出與帳號登入。
暫時不要實作付款功能。
寫程式前，請先幫我規劃產品流程、資料模型、AI API 流程與風險。
請列出建置前我應該回答的假設與問題。
注意最後兩句。你不是急著叫 Lovable 產生頁面，而是先叫它幫你規劃。這就是 agentic 開發的入口。
Lovable 的使用者不只一種。
如果你是創業者或 indie maker，你可以用它快速把想法變成可點、可測、可展示的 MVP。你不用先組一個完整工程團隊，也能做出有登入、有資料、有付款、有發布流程的第一版產品。
如果你是產品經理或設計師，你可以用 Lovable 把需求和流程變成接近真實產品的 prototype（原型）。這比靜態 wireframe 更容易暴露問題，因為使用者可以真的點、真的填表、真的走流程。
如果你是工程師，Lovable 不是要取代你的判斷。它比較像一個能快速搭骨架、改 UI（使用者介面）、產生 CRUD、接服務、做初步測試的 AI pair builder。真正重要的地方，你仍然需要審查程式碼、資料模型、權限、安全和部署策略。
如果你在企業或團隊裡，Lovable 的 workspace（工作區）、roles、GitHub sync、security scan、audit logs、SSO、SCIM 這些能力，會比單純生成網頁更重要。因為正式組織在意的不只是「做得出來」，還包含誰能看、誰能改、資料能不能被保護、程式碼能不能帶走、上線流程能不能被治理。
這本書雖然標題很強，但不會把 Lovable 寫成萬能工具。
不適合的用法包括：
Lovable 能加速很多事，但它不能替你決定產品是否值得做、商業模式是否合理、法規是否符合、資料是否應該收集。你仍然是產品的負責人。
本書不會按照文件選單逐頁解釋。那樣會變成功能清單，不會變成工作能力。
我們會分成五個部分：
你可以把這本書想成一套訓練：不是訓練你「問 AI 一句話」，而是訓練你成為會指揮 AI agent 交付產品的人。
我有一個應用程式構想：[描述構想]。
建置前，請協助我把它整理成產品規格。
請包含目標使用者、核心使用者流程、頁面、資料模型、外部整合、風險與第一版範圍。
先不要寫程式碼。
如果構想太模糊，請提出釐清問題。
這個提示詞適合在你只有概念時使用。它把 Lovable 放在產品規劃角色，而不是馬上要求它產生畫面。
我想在這個專案新增[功能]。
實作前，請說明處理方式。
請告訴我可能受影響的頁面、元件、資料表、後端函式與外部整合。
請列出假設與風險。
等我核准計畫後再修改檔案。
這個提示詞適合風險比較高的功能，例如登入、金流、資料寫入、權限或第三方 API。
下一項任務請使用這套工作流程：
1. 理解目前的專案。
2. 提出一份小範圍的實作計畫。
3. 建置變更。
4. 驗證使用者流程。
5. 列出發布前仍存在的風險。
任務是：[描述任務]。
這個提示詞的重點是明確指定工作節奏。你不是只描述終點，而是告訴 Lovable 你希望它如何推進。
選一個你真的想做的小產品，不要超過三個核心功能。用下面的格式寫第一個 Lovable 提示詞：
我想建置[產品]。
目標使用者是[使用者]。
第一版應該協助他們達成[主要成果]。
核心流程：
1. [流程一]
2. [流程二]
3. [流程三]
建置前，請協助我規劃：
- 頁面
- 資料模型
- 身分驗證需求
- 後端或外部整合需求
- 測試策略
- 發布前的風險
先不要寫程式碼。
完成後，不要急著按 Build。先看 Lovable 回答裡有沒有漏掉這三件事：
如果這三件事不清楚，先繼續問，不要急著做。
「幫我做一個像 Notion 的工具」這種 提示詞很常見，但它太大了。Lovable 可能會產生一個看似完整的介面，卻沒有清楚的資料模型、權限、協作規則或上線策略。
比較好的方式是先界定第一版：
請建置輕量筆記應用程式的第一版。
只需要登入、筆記清單、新增／編輯／刪除筆記與搜尋功能。
暫時不要加入協作、分享、範本或計費功能。
畫面能看不代表產品能用。你還要確認資料是否保存、登入是否正確、錯誤狀態是否處理、手機版是否可用、發布後是否和 preview（預覽） 一致。
複雜任務如果直接 Build，容易一邊做一邊改方向。登入、付款、資料遷移、權限、安全、第三方整合，都應該先規劃再實作。
Lovable 可以幫你產生程式、整合服務、跑測試、發布網站。但產品責任仍然在你身上。尤其是金流、個資、AI 內容、安全和法規，不能只因為 AI 做得出來就直接上線。
讀完本章後，建議用自己的專案情境繼續追問 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鐵人賽
看影片追技術