讀完這一章，你會知道如何用 Lovable 把一個「看起來像網站」的首頁，推進成「真的能承載產品體驗」的介面。你會學會使用 Design guidance 建立視覺方向，用 Preview（預覽） toolbar 精準修改畫面，用圖片、影片、字體和 design system 管理前端品質。
這章的核心不是追求漂亮。漂亮只是第一層。真正重要的是：你的使用者一進來，能不能快速理解產品、完成下一步、相信這個網站值得繼續使用。
很多人第一次用 Lovable，會先請它做一個 landing page。這很合理，因為 landing page 是最容易看見成果的地方。但如果你只把 Lovable 當成產生首頁的工具，很快會遇到三個問題：
真正的產品體驗不是一張 hero section。它包含資訊架構、使用者路徑、視覺階層、內容語氣、操作入口、錯誤狀態、響應式畫面和品牌一致性。
Lovable 強的地方，是你可以用自然語言描述產品意圖，再透過 preview（預覽） 直接指向畫面細節。這讓你不只是在「生成 UI（使用者介面）」，而是在跟 agent 一起雕塑產品體驗。
你可以用這個順序設計首頁：
使用者是誰
-> 他現在有什麼問題
-> 這個產品怎麼幫他
-> 他為什麼相信你
-> 他下一步要做什麼
如果首頁不能回答這五件事，再漂亮都只是裝飾。
所以第 8 章要建立的 mental model 是：
產品介紹頁 = 第一個產品流程
設計方向 = 視覺假設
預覽編輯 = 聚焦迭代
設計系統 = 可重複使用的產品語言
首頁不是書封。它是使用者第一次操作產品之前的第一個流程。
開始前，請先準備好這幾件事：
這章可以用一個 fictitious SaaS 練習：
產品名稱: LaunchNote
目標使用者: 台灣獨立開發者與小型 SaaS 團隊
核心功能: 把產品更新、產品路線圖、版本資訊轉成公開的更新日誌頁面
主要行動呼籲: 免費開始使用
次要行動呼籲: 查看示範
接下來的 提示詞都會以這個產品為例。
不要一開始就說：
請為我的 SaaS 建置漂亮的產品介紹頁。
這種 提示詞太空。Lovable 可能會給你三個漂亮方向，但每個方向都缺少產品判斷。
比較好的做法，是先寫一份產品體驗 brief。這份 brief 不需要很長，但要包含：
範例：
我正在建置 LaunchNote，這是一個為台灣獨立開發者和小型 SaaS 團隊設計的產品。
它協助團隊把產品更新、產品路線圖項目和版本資訊轉成公開的更新日誌頁面。
請建置首頁的第一版。
目標使用者：
- 經常發布小型產品更新的個人創業者。
- 需要簡單公開更新日誌的小型產品團隊。
首頁應傳達：
- 在 5 秒內說明 LaunchNote 的用途。
- 說明它為何比手動撰寫更新更省時。
- 呈現終端使用者看到的更新日誌頁面。
- 傳達產品簡單、可靠，而且是為持續交付的團隊設計。
主要行動呼籲：免費開始使用
次要行動呼籲：查看示範
設計方向：
- 乾淨、實用、以產品為主的 SaaS 風格。
- 避免空泛的未來感 AI 視覺。
- 請使用繁體中文使用者介面文案。
- 第一螢幕應保持聚焦且容易閱讀。
目前不要加入身分驗證、付款或資料庫整合。
這個提示詞的價值，是把 UI（使用者介面）設計拉回產品問題。Lovable 會比較容易生成有重點的首頁，而不是用假文案填滿版面。
Lovable 的 Design guidance 可以在正式 build 前，先產生三個輕量的設計方向。這些方向通常會呈現不同的 layout、字體、色彩、間距和視覺語氣。
你可以把它當成「視覺假設比較」：
你不是在挑最炫的圖，而是在挑最能服務產品定位的方向。
適合觸發 Design guidance 的 提示詞：
建置前，請為 LaunchNote 首頁建立三個設計方向。
我想比較：
- 實用的 SaaS 方向。
- 精緻且以產品為主的方向。
- 更適合獨立開發者、帶有編輯感的方向。
所有方案都應容易閱讀、值得信任，並適合繁體中文文案。
不要使用深色的未來感 AI 風格。
選方向時，請用產品問題評估，而不是只看第一眼：
如果三個方向都不對，不要勉強選。你可以要求 Lovable 再生成一組，或針對最接近的一個方向 refine。
圖 8-1：Design guidance 在 Build 前先比較 layout、字體、色彩與整體視覺語氣，降低選錯大方向後反覆返工的成本。
當你選到接近的方向後，不要只按 Submit 然後祈禱。你可以在送出前，用 refinement（細修）提示詞把方向拉準。
範例：
建置前，請細修這個方向。
讓首頁更像是為小型 SaaS 團隊設計的專業產品工具。
減少裝飾元素。
增加主視覺文案周圍的留白。
請在第一螢幕使用更明確的產品截圖區。
讓行動呼籲的階層更清楚：「免費開始使用」是主要動作，「查看示範」是次要動作。
繁體中文文案應保持精簡、實用。
Design guidance 的重點，是在 build 前降低大方向錯誤。你越早修正視覺方向，後面越不需要大量返工。
Build 完第一版之後，不要每次都用一大段 提示詞描述「左邊第二個 section 的第三個卡片」。Lovable 的 Preview（預覽） toolbar 就是為了解決這種問題。
Preview（預覽） toolbar 有四種主要模式：
當你能指向畫面時，就不要用模糊描述。指向元素會讓 Lovable 拿到更準確的上下文。
圖 8-2：Preview toolbar 讓你直接在產品畫面上選取、改字、標註或留言；指出目標元素通常比描述位置更準確。
假設 hero 的 CTA 太弱，你可以：
S 進入 Select elements。把這個項目改成主要動作。
請從目前色彩組合中選用對比更強的顏色。
按鈕文字維持「免費開始使用」。
不要修改次要行動呼籲。
這比「讓首頁 CTA 更明顯」更準，因為 Lovable 知道你指的是哪一個元素。
如果只是改文案，直接用 inline edit。
適合 inline edit 的情境：
不適合 inline edit 的情境：
小文字直接改，大結構用 提示詞。
當你想調整空間關係時，畫圖比文字快。
例如你想刪掉 hero 下方太多裝飾卡片，可以圈起區域後輸入：
移除這個區域內的所有內容。
改成一個精簡的產品預覽，顯示更新日誌項目清單。
縮短區塊高度，讓桌面版第一螢幕可以看到下一個區塊。
這種修改很適合 annotation，因為你要表達的是「哪一塊區域」和「空間比例」。
Comment 適合團隊協作，不一定每個 comment 都要立刻送給 Lovable。
你可以把 comment 當成產品審查紀錄：
這個區塊說明了功能，卻沒有解釋工作流程。
建議把三張空泛的卡片改成三步驟流程：
1. 撰寫更新
2. 發布更新日誌
3. 與使用者分享
等你或團隊確認後，再把 comment thread 送給 Lovable 實作。
圖片會大幅影響首頁可信度。對 SaaS 產品來說，最有價值的圖片通常不是抽象插圖，而是產品畫面、流程截圖、範例輸出或使用情境。
Lovable 支援幾種常見做法：
public 目錄裡的圖片。對產品首頁，建議優先使用這幾種圖片：
不建議過度依賴：
替換 hero 圖片時，可以這樣 提示詞：
請使用這張上傳截圖作為主視覺的產品預覽。
桌面版放在主視覺右側，行動版放在文案下方。
請新增細緻的外框，讓它看起來像應用程式截圖，而不是一般圖片。
截圖內容應保持清楚可讀。
不要裁掉更新日誌項目。
如果圖片放在 GitHub public 目錄，提示詞要直接引用路徑：
使用以下本機公開資產作為功能預覽：
public/launch-note-demo.png
請把它放在「看看使用者會看到什麼」區塊。
請新增描述更新日誌預覽、符合無障礙需求的替代文字。
調整版面，避免圖片在行動版佔據整個區塊。
注意檔案大小。Lovable 文件提醒，大圖片會讓 repo 變大，也可能拖慢 preview（預覽） 或 sandbox 啟動。產品截圖要先壓縮，尺寸也要符合實際顯示需求。
圖 8-3：完成第一版後，在同一個編輯器中對照 Chat 與真實 Preview；產品圖片、CTA、中文排版與工具列修改都能在畫面上立即檢查。
影片不是必需品。它只有在能讓使用者更快理解產品時才值得放。
適合放影片的情境：
不適合放影片的情境：
Lovable 文件建議，最簡單且推薦的方式是嵌入外部影片，例如 YouTube。大型影片不要直接丟進 repo，除非你知道自己在做什麼。
範例提示詞：
在產品操作說明區塊嵌入以下 YouTube 示範影片：
https://www.youtube.com/watch?v=example
請放在三步驟工作流程區塊之後。
新增精簡的繁體中文標題。
不要自動播放影片。
如果影片無法載入，頁面仍應可以正常使用。
如果你真的要使用 public 目錄裡的影片，也要控制檔案大小：
在示範區塊插入以下本機影片：
public/launch-note-demo.mp4
請把它放在尺寸受限、具有明確預覽畫面的容器裡。
行動版不要使用滿版寬度。
請在影片下方新增替代文字，說明示範內容。
Lovable 支援 web-safe fonts 和 Google Fonts，但目前文件標示不支援直接上傳 custom fonts。
這代表你在 提示詞裡可以指定：
但字體選擇要回到產品定位。
對 SaaS 工具，建議：
範例：
請更新字體排版。
正文請使用乾淨的無襯線字體風格。
標題請使用稍微帶有編輯感的風格，但保持繁體中文可讀性。
為中文文字設定清楚的備用字體順序。
不要使用超過兩種字體家族。
增加長篇文字區塊的行高。
如果你指定 Google Font，可以這樣：
英文介面標籤請使用 Inter，繁體中文文案請保留容易閱讀的系統備用字體。
按鈕、導覽列和正文應一致套用字體。
不要修改版面或色彩組合。
字體是系統，不是單點裝飾。你應該請 Lovable 一次整理 typography rules，而不是只把某個標題換成花俏字體。
當你只有一個 landing page，提示詞裡寫清楚顏色、字體和 component style 通常就夠了。
但當你有多個頁面、多個產品、多個團隊成員時，你會需要 design system。
Lovable 的 Design systems 可以把 React components、tokens、使用規則與安裝設定集中成一個 dedicated project（專案），再連到其他 project（專案）使用。連接後，Lovable 會把 component library 複製到 connected project（專案），也會把 .lovable knowledge files 複製進去，讓 agent 在後續 generation 中讀取規則。
這個功能適合：
不一定適合：
如果你的團隊還沒有 design system，可以先用 project（專案）knowledge 保存簡化版規則：
這個專案的設計規則：
- 使用克制的 SaaS 介面。
- 主要顏色：#2563EB。
- 成功顏色：#16A34A。
- 警告顏色：#F59E0B。
- 錯誤顏色：#DC2626。
- 卡片和輸入欄位的圓角請控制在 6px 到 8px。
- 按鈕應有清楚的階層：主要、次要、透明背景。
- 避免純裝飾性的漸層。
- 請使用繁體中文使用者介面文案。
- 儀表板頁面應保持資訊密集，但仍容易閱讀。
等產品穩定後，再把常用 component、tokens、usage rules 整理成正式 design system。
我正在為 LaunchNote 建置 SaaS 首頁。
產品：
LaunchNote 協助台灣獨立開發者和小型 SaaS 團隊，把產品更新發布成乾淨的公開更新日誌。
首頁目標：
讓訪客在 5 秒內理解產品，並點擊「免費開始使用」。
必要區塊：
- 包含清楚價值主張、主要行動呼籲、次要行動呼籲和產品預覽的主視覺。
- 說明手動撰寫更新為何耗時的問題區塊。
- 三步驟工作流程：撰寫更新、發布更新日誌、與使用者分享。
- 展示產品路線圖、版本資訊和公開更新日誌的功能區塊。
- 社會認同暫用區塊。
- 最後的行動呼籲。
設計：
- 實用、乾淨、以產品為主的 SaaS 風格。
- 請使用繁體中文文案。
- 避免空泛的 AI 視覺和模糊的行銷文案。
目前不要加入身分驗證、付款、資料庫或後端邏輯。
為什麼有效：
讓選取的區塊更容易掃讀。
保留相同內容，但改善資訊階層：
- 更有力的標題。
- 更短的段落。
- 三個更清楚的項目符號。
- 增加標題和卡片之間的間距。
不要修改其他區塊。
不要修改色彩組合。
為什麼有效：
用上傳的產品截圖替換選取的圖片。
需求：
- 截圖內容應保持清楚可讀。
- 新增細緻的瀏覽器外框。
- 不要裁掉重要的使用者介面。
- 行動版放在主視覺文案下方。
- 新增有意義的繁體中文替代文字。
為什麼有效：
檢查並改善整個頁面的字體排版。
目標：
- 讓繁體中文正文更容易閱讀。
- 標題與正文應有明顯區別。
- 不要使用超過兩種字體家族。
- 增加長段落的行高。
- 按鈕文字應保持精簡。
不要修改區塊順序或產品文案。
為什麼有效：
請根據目前首頁，為這個專案建立精簡的設計指南。
請包含：
- 色彩變數
- 字體排版規則
- 按鈕樣式
- 卡片樣式
- 間距規則
- 圖片使用規則
- 應避免的事項
請把它寫成 Lovable 未來產生內容時可以遵循的 Project Knowledge。
暫時不要修改應用程式。
為什麼有效：
用 Lovable 建立一個 LaunchNote 首頁，然後完成三輪迭代。
使用 Pattern 1 建立首頁。
預期結果：
使用 Preview（預覽） toolbar 選取 hero CTA、產品 preview（預覽） 和其中一個 feature section，各做一次修改。
預期結果：
請 Lovable 根據目前首頁產生 project（專案）design guideline。
預期結果：
「漂亮」不是需求。你要說明漂亮是為了什麼。
比較弱：
讓它更漂亮。
比較好：
讓主視覺更值得信任，也更以產品為主。
改善可讀性、減少裝飾，並讓產品預覽更醒目。
如果你只是要修一個 button，請用 Preview（預覽） toolbar 選取 button。不要丟一段可能讓 Lovable 重整整頁的 提示詞。
早期 prototype（原型）可以有 placeholder，但正式產品要盡快換成產品證據。尤其是 SaaS 首頁，使用者通常想看產品長什麼樣。
首頁在 desktop 很漂亮，不代表 mobile 好用。每次完成主要設計調整後，都要要求 Lovable 檢查 mobile：
請檢查行動版首頁。
請修正間距、文字換行、行動呼籲順序和圖片尺寸。
除非必要，不要修改桌面版版面。
如果產品方向還不穩，太早把 UI（使用者介面）做成 design system 會增加維護成本。先用 project（專案）knowledge 管規則，等 pattern 穩定後再升級。
這章的 workflow（工作流） 很適合產品首頁、marketing pages、portfolio、內容型網站和需要強視覺方向的頁面。
但有些情境不需要先跑 Design guidance：
在這些情境下，直接用 Plan Mode 或 Build Mode 處理更快。
讀完本章後，建議用自己的專案情境繼續追問 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鐵人賽
看影片追技術