讀完這一章，你會完成本書第一個端到端專案：一個 SaaS landing page，包含清楚定位、產品區塊、pricing teaser、lead capture form、資料持久化、提交成功狀態、基本 SEO metadata（中繼資料），以及可發布的 Lovable live site。
這個專案故意很小。它不做登入、不做金流、不做 AI、不做後台。它的價值在於讓你完整跑過一次 Lovable 的核心循環：
規格
設計
生成
檢查
接資料
測試
SEO
發布
如果你能把這個小專案做好，後面的會員平台、AI 工具網站和企業內部工具就只是同一套流程的放大版。
我們要做的產品叫做 LaunchNote Lite。
它是一個假想 SaaS 的早鳥頁面，定位如下：
LaunchNote Lite 協助小型軟體團隊為更新日誌和產品更新工具
收集早期使用者的興趣。
網站要完成四件事：
這不是一個漂亮 demo 而已。這是一個最小 production（正式上線）slice。它有清楚轉換目標、有資料、有驗證、有上線檢查。
很多人第一次用 Lovable 會直接喊：
請幫我建置完整 SaaS，包含登入、付款、儀表板、AI、管理後台、數據分析和信件自動化。
這通常會讓專案從第一天就變得太大。AI 生成速度很快，但產品複雜度不會因為生成變快就消失。
第一個專案應該教你三件事：
Landing + lead form 是最適合的練習，因為它包含真實產品常見的基本面：
它沒有複雜登入與付款，所以你可以專注學會 Agentic build workflow（工作流）。
LaunchNote Lite 的第一版包含：
leads。name, email, company, role, team_size, message, source。先不要加入：
這些都可以是下一版。第一版只負責一件事：收集早鳥名單。
圖 18-1：把完整 T=0 規格貼入 Lovable 後，對話區保留實際提示詞與完成摘要，右側同步顯示生成的 LaunchNote Lite 首頁。
先建立 project（專案）knowledge 或至少把規格放進第一個提示詞。不要只說「做一個 landing page」。你要讓 Lovable 知道產品、受眾、語氣、內容結構和技術邊界。
提示詞：
請建立新的 Lovable 應用程式，名稱為 LaunchNote Lite。
產品：
LaunchNote Lite 是 SaaS 候補名單產品介紹頁；這項 SaaS 協助小型軟體團隊發布更新日誌和產品更新。
受眾：
- 創業者。
- 產品經理。
- 工程主管。
- 小型軟體團隊。
目標：
把訪客轉換成候補名單潛在客戶。
核心頁面：
- 只有單頁產品介紹頁。
區塊：
- 包含清楚標題和電子郵件收集行動呼籲的主視覺。
- 問題區塊。
- 三項產品優點。
- 三步驟運作方式。
- 價格預告。
- 候補名單表單。
- 常見問題。
- 頁尾。
語氣：
- 清楚、實用、聚焦產品。
- 避免誇大。
- 使用繁體中文介面文案。
設計：
- 現代 SaaS 風格。
- 資訊密度足以滿足產品採購者。
- 乾淨的字體排版。
- 強烈對比。
- 適應行動裝置。
不要加入：
- 登入。
- 付款。
- 管理員儀表板。
- AI 功能。
- 部落格。
第一輪只建置前端版面和表單介面。
暫時不要連接資料庫。
最後一句很重要：先不要接 database。先把 UI（使用者介面）和文案穩住。
第一次生成後，請先檢查畫面，而不是急著加功能。
檢查：
你可以用 Preview（預覽） toolbar 做小字句、間距、顏色調整。對大改動，再用 提示詞。
提示詞：
請檢查 LaunchNote Lite 產品介紹頁的使用者介面。
只改善前端呈現：
- 讓主視覺的價值主張更清楚。
- 讓主要行動呼籲指向候補名單表單。
- 維持單頁設計。
- 改善行動版間距。
- 讓功能區塊更容易掃讀。
- 保持繁體中文文案。
不要加入資料庫、身分驗證、付款或新頁面。
這一步要守住範圍。Lovable 很會順手加東西，你要明確告訴它不要做什麼。
圖 18-2：將表單欄位與驗證 prompt 實際送入 Lovable；生成結果加入姓名、公司、角色、團隊規模與留言欄位。
Landing page 的表單不能只問 email。你要拿到足夠判斷 lead quality 的資訊，但不要讓填寫成本過高。
建議欄位：
| Field | Type | Required | Purpose |
|---|---|---|---|
name |
text | yes | 聯絡人 |
email |
yes | 後續通知 | |
company |
text | no | 判斷組織 |
role |
select | no | 判斷 persona |
team_size |
select | no | 判斷客戶規模 |
message |
textarea | no | 收集需求 |
source |
hidden/text | no | 來源追蹤 |
表單 UX 要有：
提示詞：
請細修 LaunchNote Lite 的候補名單表單。
欄位：
- name：必填文字。
- email：必填電子郵件。
- company：選填文字。
- role：選填下拉選單，選項為創業者、產品經理、工程主管、設計師、其他。
- team_size：選填下拉選單，選項為 1–5、6–20、21–50、51–200、200 人以上。
- message：選填多行文字。
- source：隱藏欄位，預設值為 landing_page。
使用者體驗需求：
- 驗證必填欄位。
- 驗證電子郵件格式。
- 送出期間顯示載入狀態。
- 送出後顯示清楚的成功狀態。
- 顯示容易理解的錯誤狀態。
- 在表單下方加入簡短的隱私提醒。
暫時不要連接資料庫。
現在才接資料。Lovable Cloud 本身就是全端環境，包含 database、auth（驗證）、storage、edge functions 等能力。若你的 workspace（工作區）使用 Lovable Cloud，Lovable 可以直接幫你建立資料表與連接表單。
如果你走 Supabase integration，也是一樣的模型：描述資料需求，讓 Lovable 產生 schema，確認後再讓它接上 UI（使用者介面）。
資料表規格：
資料表：leads
欄位：
- id：UUID 主鍵。
- name：非空文字。
- email：非空且唯一的文字。
- company：可為空的文字。
- role：可為空的文字。
- team_size：可為空的文字。
- message：可為空的文字。
- source：文字，預設值為 landing_page。
- created_at：含時區的時間戳記，預設值為 now()。
提示詞：
請把 LaunchNote Lite 候補名單表單連接到資料庫。
建立名為 leads 的資料表，包含：
- id：UUID 主鍵。
- name：必填文字。
- email：必填且唯一的文字。
- company：選填文字。
- role：選填文字。
- team_size：選填文字。
- message：選填文字。
- source：文字，預設值為 landing_page。
- created_at：含時區的時間戳記，預設值為 now()。
行為：
- 送出時新增一筆潛在客戶資料。
- 電子郵件已存在時，顯示友善訊息：「你已經加入候補名單，我們會通知你。」
- 不要公開潛在客戶清單。
- 暫時不要加入管理員儀表板。
- 實作後，說明如何驗證資料列已建立。
如果 Lovable 產生 SQL 或 migration，請先讀過再執行。第一個專案的 schema 很簡單，你應該能看懂每一欄的用途。
Lead form 看起來不是敏感系統，但它存的是個資。Email、姓名、公司都應該被當成 private data。
最低標準：
提示詞：
請檢查 leads 資料表的資料存取規則。
需求：
- 匿名訪客可以送出候補名單表單。
- 匿名訪客不能讀取潛在客戶資料。
- 匿名訪客不能更新潛在客戶資料。
- 匿名訪客不能刪除潛在客戶資料。
- 應用程式介面不得暴露潛在客戶紀錄。
- 錯誤訊息不得透露資料庫詳細資料。
請檢查目前實作，並建議最小且安全的 Policy 變更。
除非安全上有必要，否則不要修改使用者介面。
這裡不用把它變成完整會員系統。只要確認「可寫不可讀」這個表單收件模式成立。
表單測試不要只測 happy path。
測試案例：
| Case | Expected result |
|---|---|
| 空白提交 | 顯示必填錯誤 |
| email 格式錯誤 | 顯示 email 錯誤 |
| 只填 required fields | 成功提交 |
| 填所有欄位 | 成功提交 |
| 重複 email | 顯示已加入訊息 |
| database 暫時失敗 | 顯示友善錯誤 |
| 手機版提交 | 成功且版面不跳動 |
提示詞：
請為 LaunchNote Lite 候補名單表單建立測試計畫。
請包含：
- 空白送出。
- 無效電子郵件。
- 只填必填欄位的有效送出。
- 填寫所有欄位的有效送出。
- 重複電子郵件。
- 資料庫新增失敗。
- 行動版送出。
針對每個測試，請列出：
- 步驟。
- 預期結果。
- 要在資料庫檢查的項目。
- 失敗是否阻擋發布。
測試後再請 Lovable 修問題：
只修正測試計畫中找到的候補名單表單問題。
不要重新設計頁面。
不要加入新功能。
不要加入登入或管理員頁面。
修正後，請摘要：
- 修改了什麼。
- 應重新執行哪些測試。
很多表單只顯示「送出成功」。這對使用者不夠。
成功狀態應該回答：
建議文案：
你已加入 LaunchNote Lite 候補名單。
我們會在搶先體驗開放時寄信通知你。
如果你不打算立刻寄 email，不要寫「我們已經寄出確認信」。文案要符合實際系統。
提示詞：
請改善候補名單表單的成功和錯誤狀態。
成功狀態：
- 確認使用者已加入候補名單。
- 告知使用者搶先體驗開放時會收到信件。
- 不要聲稱已寄出確認信。
錯誤狀態：
- 請使用友善的繁體中文。
- 不要顯示原始資料庫或 API 錯誤。
- 讓使用者可以重試。
保持行動版版面穩定。
表單收件後，你可能想寄信給自己或團隊。
有三種做法：
第一版建議先不寄信。原因是這章的目標是完成最小端到端產品，不是導入 email infrastructure。
如果你真的要寄通知，請把它當成 extension：
建立新的潛在客戶資料後，寄送內部通知信。
需求：
- 如已設定，使用既有信件功能或 Resend 連線。
- 只寄送到團隊內部電子郵件。
- 包含 name、email、company、role、team_size、message 和 created_at。
- 信件發送失敗時，保留已儲存的潛在客戶資料，並向使用者顯示成功。
- 記錄信件失敗，供管理員審查。
注意最後兩句。使用者提交成功的主流程是「lead saved」。內部通知 email 失敗不應該讓使用者以為加入失敗。
Landing page 是公開頁面，所以至少要有：
提示詞：
請為 LaunchNote Lite 新增基本 SEO 中繼資料。
定位：
LaunchNote Lite 協助小型軟體團隊收集使用者對產品更新工具的興趣。
請設定：
- 頁面標題。
- 不超過 155 個字元的 Meta Description。
- Open Graph 標題。
- Open Graph 說明。
- 建議的分享圖片內容。
- 正式環境自訂網域的 Canonical URL 暫用值。
另外檢查：
- 只有一個 H1。
- H2 區塊結構合理。
- 行動呼籲文字清楚。
- 候補名單表單不需額外說明就能理解。
不要為了 SEO 把頁面寫得像關鍵字垃圾場。這是一頁產品頁，讀者先是人，其次才是 crawler。
圖 18-3：把發布前檢查 prompt 送入 Lovable，對話區列出檢查項目，右側保留實際表單預覽供逐項核對。
發布前請跑一次 production（正式上線）readiness（正式上線準備）提示詞：
請在第一次發布前檢查 LaunchNote Lite。
檢查：
- 建置錯誤。
- 行動版版面。
- 候補名單表單驗證。
- 資料庫新增。
- 重複電子郵件處理。
- 潛在客戶資料的存取規則。
- SEO 中繼資料。
- Open Graph 中繼資料。
- 隱私提醒。
- 發布網站資訊。
請回傳：
- 阻礙。
- 發布前要修正的項目。
- 可安全留到發布後處理的項目。
- 最終發布檢查清單。
你要特別確認：
第一次發布可以先用 Lovable URL。若你有 custom domain，可以接上正式 domain 再 publish。
Live smoke test：
提示詞：
請為 LaunchNote Lite 建立發布後的正式環境冒煙測試檢查清單。
請包含：
- 首頁載入。
- 行動呼籲捲動行為。
- 候補名單表單正常流程。
- 重複電子郵件。
- 無效電子郵件。
- 資料庫資料列驗證。
- 匿名讀取保護。
- 行動版版面。
- SEO 標題和說明。
- 社群預覽。
發布後如果你修改了表單或 metadata（中繼資料），記得 Publish Update。Editor 裡修好不代表 live site 已更新。
當 LaunchNote Lite 能穩定收件後，你才應該規劃下一版。
可能的 V2：
每個都可以做，但不要一次做。
提示詞：
請為 LaunchNote Lite 建議第二版產品路線圖。
目前狀態：
- 單頁 SaaS 產品介紹頁。
- 候補名單表單。
- 潛在客戶資料儲存在資料庫。
- 基本 SEO 中繼資料。
- 已發布正式網站。
請提出：
- 5 項可能的後續功能。
- 預期商業價值。
- 實作風險。
- 建議順序。
- 下一個應建置的功能及原因。
這就是 Agentic workflow（工作流） 的節奏：完成一個可驗證版本，再用資料和目標決定下一步。
這章的順序刻意安排成：
1. 產品規格
2. 前端版面
3. 表單使用者體驗
4. 資料庫持久化
5. 存取規則
6. 表單測試
7. 成功／錯誤狀態
8. 選配通知
9. SEO 中繼資料
10. 發布準備狀態
11. 正式環境冒煙測試
12. 第二版產品路線圖
你也可以把它當成任何 Lovable 小專案的通用模板。
每一步都遵守一個原則：
一次只加入一種風險。
先做 UI（使用者介面），不接資料。UI（使用者介面）穩了，再接資料。資料通了，再補權限。權限過了，再做 SEO。SEO 好了，再 publish。Publish 後，再測 live。
這樣你才知道問題從哪裡來。
一次要求 landing、登入、付款、dashboard（儀表板）、AI、email，很容易讓專案從第一步就失控。第一章專案請保持小。
如果 UI（使用者介面）還在大改，schema 和表單欄位也會跟著震盪。先定義表單，再接資料。
表單真正容易壞的是 invalid input、duplicate email、network error 和 mobile layout。
Lead data 是 private。訪客可以 submit，不代表可以 read。
不要把 raw API error、SQL error 或 stack trace 顯示給使用者。
如果沒有寄確認信，就不要說確認信已寄出。
Preview（預覽） 測過不代表 live URL 沒問題。發布後一定要重測。
leads table 是否存在？讀完本章後，建議用自己的專案情境繼續追問 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鐵人賽
看影片追技術