前端開發 2025 iThome 鐵人賽 · 第 22 / 32 篇

Day 22: 【前端 #3】AI 一鍵生成完整 App 靜態 UI

今天我們將繼續指揮 AI 助手,根據所有設計藍圖,在現有專案基礎上,將 MVP 所需的所有靜態 UI 元素全部建造完成。

快速導覽 查看本文目錄

安安,我是 ChiYu!

昨天,我們扮演了一位冷靜而專業的「結構工程師」,成功地將 AI 生成的華麗原型,重構成為一個結構清晰、職責分明的專業前端專案。我們的 index.html, style.css, script.js 現在各司其職,一切都井井有條。

我們現在有了一個專業的「建築框架」,以及一些基本的「核心傢俱」(習慣列表和 Modal)。但是,我們的房子裡還有很多房間是空的,例如完整的導覽列、心情記錄區等等。

今天,我們的任務就是進行一場 「UI 補完計畫」!我們將繼續指揮我們的 AI 助手,根據我們所有的設計藍圖,在現有的專案基礎上,將 MVP 所需的所有靜態 UI 元素全部建造完成!

Part 1:今日的作戰計畫:完成我們的「樣品屋」

我們的目標非常明確:將我們目前的 UI,擴建成一個外觀上 100% 完整的樣品屋。使用者看到它時,會覺得這就是一個功能齊全的 App,即使它內部還沒有連上數據。

根據我們的《使用者故事》和《佈局元件》文件,我們今天需要補全以下幾個關鍵部分:

  • 一個功能完整的側邊導覽列 (Sidebar)。
  • 一個心情記錄區 (Mood Tracker)。
  • 整體樣式微調,確保所有新舊元件完美融合。

Part 2:Vibe Coding 實戰:指揮 AI 進行「室內精裝修」

現在,讓我們回到 gemini chat 模式,指揮 AI 在我們現有的程式碼基礎上,進行一次**「增量開發 (Incremental Development)」**。這是一個非常重要的專業開發模式,代表我們不是每次都推倒重來,而是在現有基礎上,逐步疊加新功能。

【魔法詠唱:UI 擴建】

# 角色 (Role)

你是一位頂尖的前端工程師,精通語意化 HTML 和現代 CSS,擅長在現有專案基礎上,根據設計文件擴充 UI。

**# 目標 (Objective)**

請根據我提供的所有設計文件,擴充我現有的前端程式碼,補完 MVP 所需的全部靜態 UI 元素。

**# 上下文 (Context)**

- **現有 HTML**: `@frontend/index.html`
- **現有 CSS**: `@frontend/style.css`
- **所有設計藍圖**: `@docs/PROJECT_CHARTER.md`, `@docs/USER_STORIES.md`, `@docs/STYLE_GUIDE.md`, `@docs/LAYOUT_COMPONENTS.md`

---

## 你的任務與產出要求 (Your Task & Output Requirements)

**請直接修改我現有的 `index.html` 和 `style.css` 檔案。**

### 1. 修改 `index.html`:

- **擴充側邊欄 (`<aside class="sidebar">`)**:
    - 移除原本的 `<h2>` 佔位符。
    - 根據《佈局元件》文件,加入包含 Logo placeholder、`<ul>` 導覽連結列表(需包含 SVG 圖示)、以及底部使用者頭像/名稱的完整結構。
- **擴充主內容區 (`<main class="main-content">`)**:
    - 在現有的 `habit-list-container` 下方,新增一個 `mood-tracker-container` 的 `section`。
    - 在其中,加入一個 `<h3>` 標題「今天感覺如何?」以及一組讓使用者可以選擇心情的 UI 元素(例如用 `<div>` 包裹的 emoji 或星星圖示)。

### 2. 修改 `style.css`:

- **追加新樣式**: 在檔案的**末尾**,追加所有新 HTML 元素所需的 CSS 樣式。
- **遵循規範**: 所有顏色、字體、間距, **必須**使用我們已定義好的 CSS 變數。
- **精緻化**: 為導覽列的連結加上 `hover` 和 `active` 的視覺效果,並為心情記錄區設計優雅的排版。

Part 3:心法:Vibe Coding 的真相——對話,而非命令

AI 完成初步擴建後,我們打開 Live Server 預覽。你會看到一個初步的成果,有模有樣,但可能跟我們想像的還有些落差。這正是我們接下來要展示的重點!

很多時候,我們期望 Vibe Coding 就像電影裡的魔法,念一句咒語,城堡就拔地而起。但真實的、高效的 Vibe Coding,更像是指揮一個極度聰明但沒有心電感應的建築師團隊。

一個成功的專案,來自於**「持續的、清晰的、迭代的溝通」**。我們將完整地展示這個過程:

  1. 審核初步成果:我們會發現 AI 的產出可能只完成了 80%,甚至有些地方會錯意。
  2. 進行對話式修正:我們會針對不足之處,用自然語言和 AI 對話,一步步地補充細節、修正樣式,直到畫面完全符合我們的藍圖。

這個過程,才是 Vibe Coding 最真實、也最有價值的樣貌。

Part 4:與 AI 的協同裝修工程

讓我們繼續與 AI 對話,將我們的 UI 打磨至完美。

【對話式修正範例】

你:

「做得很好,但有幾個地方需要調整。首先,請在側邊導覽列的每個連結文字前面,加上對應的 SVG 圖示。」

AI:

「好的,已為您在導覽列連結中加入 SVG 圖示。」

你:

「很棒!接下來,心情記錄區的按鈕,我希望它們是圓形的,並且滑鼠移上去時,要有一個輕微放大的動畫效果。」

AI:

「收到,已將心情記錄按鈕調整為圓形,並加入了 hover 放大效果。」

我們就像在跟一位真人設計師溝通一樣,透過一次次的微調,逐步將畫面打磨成我們心中最完美的樣子。

在我們對 UI 細節感到滿意後,是時候為門面畫龍點睛了——LOGO!

【操作步驟】

  1. 打開魔法實驗室:前往 gemini.google.com。

  2. 詠唱 LOGO 設計咒語:

    請為我設計一個 LOGO,用於名為 “MindTrack” 的習慣追蹤與心情日誌 App。

    設計要求:

    • 風格:極簡、現代、扁平化 (flat design)。
    • 核心元素:請融合「大腦」或「思緒路徑」的抽象線條,與代表「成長」或「目標」的圖形。
    • 色彩:請主要使用我們專案的靜謐藍 (#5A9AAB) 和暖陽珊瑚 (#F5A685)。
    • 尺寸與格式:請生成一個 256x256 像素的透明背景 PNG 圖片。
  3. 挑選與下載:Gemini 會為你生成數個 LOGO 選項。挑選一個你最喜歡的,並將它下載下來。

  4. 放入專案:

    • 在 frontend 資料夾中,建立一個 assets 資料夾。
    • 將下載的 LOGO 圖片(例如 logo.png)放入 frontend/assets 資料夾中。
  5. 更新 HTML:手動或指揮 AI,將 index.html 中 Logo 的 placeholder 替換成 <img src="./assets/logo.png" alt="MindTrack Logo">。

再次刷新頁面,我們的 App 就有了獨一無二的靈魂標誌!

Part 6:提交我們的「完整樣品屋」

當所有 UI 都符合我們的藍圖後,就可以提交了!

  • Commit 訊息: feat(frontend): build out complete static UI with AI-generated logo
  • Commit & Push!

結語:從「創世紀」到「點化萬物」

再次恭喜!今天,我們不只完成了一項極具成就感的任務,更重要的是,我們學習並實踐了 Vibe Coding 最真實、也最核心的工作模式——對話與迭代。

我們手上現在有了一個外觀完整、極其精美,但沒有靈魂的「App 蠟像館」。

它很美,但它是靜默的。

從明天開始,我們將開啟下一個更激動人心的篇章——「點化萬物」。我們將扮演「賦靈者」,學習前端最核心的非同步藝術,為這個靜默的世界,注入第一縷生命氣息,讓它首次與我們後端的靈魂進行對話!

讀完了!你覺得這篇如何?

你的回饋會決定下一篇要寫什麼。

還有疑問

Learning path

2025 iThome 鐵人賽

這篇是系列中的第 22 / 32 篇。可以順著列表補完整脈絡,也可以直接跳到需要的段落。

  1. 01 Day 1: 【啟程】嘿,AI!我們來做個網站,但這次,我們約法三章
  2. 02 Day 2: 【心法篇】開發者的航海圖:什麼是文件驅動開發 (DDD)?
  3. 03 Day 3: 【工具篇 #1】萬丈高樓平地起:建置本地開發環境
  4. 04 Day 4: 【工具篇 #2】程式碼的時光機:Git 與 GitHub 版本控制
  5. 05 Day 5: 【工具篇 #3】終端機裡的魔法:什麼是 Vibe Coding 與 Gemini CLI?
  6. 06 Day 6: 【文件 #1】專案的靈魂:用 Gemini CLI 生成「專案章程」
  7. 07 Day 7: 【文件 #2】使用者的旅程:用 Gemini CLI 描繪「使用者故事」
  8. 08 Day 8: 【文件 #3】系統的心臟:用 Gemini CLI 設計「軟體架構文件」
  9. 09 Day 9: 【文件 #4】數據的家:用 Gemini 規劃「資料庫綱要」
  10. 10 Day 10: 【文件 #5】溝通的契約:用 Gemini 撰寫「Web API 規格書」
  11. 11 Day 11: 【心法 #2】透過AI幫我們生成Prompt
  12. 12 Day 12: 【後端 #1】起手式:AI 代理人 生成模組化的 Flask 專案
  13. 13 Day 13: 【後端 #2】AI 建築師:依藍圖自動建構 CRUD API
  14. 14 Day 14: 【DevOps #1】AI 品管員:設定 GitHub Actions 自動化程式碼檢查
  15. 15 Day 15: 【後端 #3】API 測試:用 Gemini CLI 輔助撰寫 Pytest
  16. 16 Day 16: 【整合篇】後端竣工!回顧與展望
  17. 17 Day 17: 【前端 #0】前端世界的基石: HTML, CSS 與 JavaScript
  18. 18 Day 18: 【文件 #6】網站的風格指南:用 Gemini 定義顏色與字體
  19. 19 Day 19: 【文件 #7】頁面的骨架:用 Gemini 規劃主佈局與元件拆分
  20. 20 Day 20: 【前端 #1】Gemini Canvas 生成UI (還有新的AI建議功能)
  21. 21 Day 21: 【前端 #2】從原型到架構:拆解並整合 AI 生成的 UI 程式碼
  22. 22 Day 22: 【前端 #3】AI 一鍵生成完整 App 靜態 UI 目前閱讀
  23. 23 Day 23: 【前端 #4】非同步的藝術:深入 Fetch API 與 Promise
  24. 24 Day 24: 【前端 #5】狀態管理的哲學:讓 UI 成為數據的鏡子
  25. 25 Day 25: 【前端 #6】核心生命週期:一天搞定習慣的「增刪改查」與「打卡」
  26. 26 Day 26: 【前端 #7】用戶體驗的最後一哩路:優雅地處理載入與錯誤
  27. 27 Day 27: 【文件 #8】數據的畫布:用 Gemini 設計「圖表元件規格書」
  28. 28 Day 28: 【前端 #8】兌現承諾:根據規格書 Vibe Coding 關聯性洞察圖表
  29. 29 Day 29: 【文件 #9】專案的守衛:用 Gemini 規劃「前端認證流程」
  30. 30 Day 30: 【前端 #9】建立大門與鑰匙:根據流程圖實現前端使用者認證
  31. 31 Day 31: 【優化篇】代碼的整形外科:JavaScript 模組化與代碼重構
  32. 32 【完賽感言】左手藍圖,右手魔法:一趟旅程的結束與反思

Further reading

Day 26: 【前端 #7】用戶體驗的最後一哩路:優雅地處理載入與錯誤 封面圖 2025-09-14 Day 26: 【前端 #7】用戶體驗的最後一哩路:優雅地處理載入與錯誤 Day 20: 【前端 #1】Gemini Canvas 生成UI (還有新的AI建議功能) 封面圖 2025-09-08 Day 20: 【前端 #1】Gemini Canvas 生成UI (還有新的AI建議功能) Day 19: 【文件 #7】頁面的骨架:用 Gemini 規劃主佈局與元件拆分 封面圖 2025-09-07 Day 19: 【文件 #7】頁面的骨架:用 Gemini 規劃主佈局與元件拆分

留言討論

用 GitHub 帳號留言,留言會同步到這個 Blog 的 GitHub Discussions。

閱讀導覽

約 5 分鐘

本文目錄

本篇所在系列 · 第 22 / 32 篇

2025 iThome 鐵人賽

  1. Day 1: 【啟程】嘿,AI!我們來做個網站,但這次,我們約法三章
  2. Day 2: 【心法篇】開發者的航海圖:什麼是文件驅動開發 (DDD)?
  3. Day 3: 【工具篇 #1】萬丈高樓平地起:建置本地開發環境
  4. Day 4: 【工具篇 #2】程式碼的時光機:Git 與 GitHub 版本控制
  5. Day 5: 【工具篇 #3】終端機裡的魔法:什麼是 Vibe Coding 與 Gemini CLI?
  6. Day 6: 【文件 #1】專案的靈魂:用 Gemini CLI 生成「專案章程」
  7. Day 7: 【文件 #2】使用者的旅程:用 Gemini CLI 描繪「使用者故事」
  8. Day 8: 【文件 #3】系統的心臟:用 Gemini CLI 設計「軟體架構文件」
  9. Day 9: 【文件 #4】數據的家:用 Gemini 規劃「資料庫綱要」
  10. Day 10: 【文件 #5】溝通的契約:用 Gemini 撰寫「Web API 規格書」
  11. Day 11: 【心法 #2】透過AI幫我們生成Prompt
  12. Day 12: 【後端 #1】起手式:AI 代理人 生成模組化的 Flask 專案
  13. Day 13: 【後端 #2】AI 建築師:依藍圖自動建構 CRUD API
  14. Day 14: 【DevOps #1】AI 品管員:設定 GitHub Actions 自動化程式碼檢查
  15. Day 15: 【後端 #3】API 測試:用 Gemini CLI 輔助撰寫 Pytest
  16. Day 16: 【整合篇】後端竣工!回顧與展望
  17. Day 17: 【前端 #0】前端世界的基石: HTML, CSS 與 JavaScript
  18. Day 18: 【文件 #6】網站的風格指南:用 Gemini 定義顏色與字體
  19. Day 19: 【文件 #7】頁面的骨架:用 Gemini 規劃主佈局與元件拆分
  20. Day 20: 【前端 #1】Gemini Canvas 生成UI (還有新的AI建議功能)
  21. Day 21: 【前端 #2】從原型到架構:拆解並整合 AI 生成的 UI 程式碼
  22. Day 22: 【前端 #3】AI 一鍵生成完整 App 靜態 UI
  23. Day 23: 【前端 #4】非同步的藝術:深入 Fetch API 與 Promise
  24. Day 24: 【前端 #5】狀態管理的哲學:讓 UI 成為數據的鏡子
  25. Day 25: 【前端 #6】核心生命週期:一天搞定習慣的「增刪改查」與「打卡」
  26. Day 26: 【前端 #7】用戶體驗的最後一哩路:優雅地處理載入與錯誤
  27. Day 27: 【文件 #8】數據的畫布:用 Gemini 設計「圖表元件規格書」
  28. Day 28: 【前端 #8】兌現承諾:根據規格書 Vibe Coding 關聯性洞察圖表
  29. Day 29: 【文件 #9】專案的守衛:用 Gemini 規劃「前端認證流程」
  30. Day 30: 【前端 #9】建立大門與鑰匙:根據流程圖實現前端使用者認證
  31. Day 31: 【優化篇】代碼的整形外科:JavaScript 模組化與代碼重構
  32. 【完賽感言】左手藍圖,右手魔法:一趟旅程的結束與反思
看完整系列 32 篇