2025 iThome 鐵人賽 · 第 1 / 32 篇

Day 1: 【啟程】嘿,AI!我們來做個網站,但這次,我們約法三章

2025 iThome 鐵人賽 Day 1:開啟文件驅動開發 (DDD) 與 Vibe Coding 的旅程。介紹本系列文章的核心目標,以及如何透過 AI 輔助來構建「習慣養成與心情日誌」專案。


Day 0: 【啟程】嘿,AI!我們來做個網站,但這次,我們約法三章

嘿,大家好啊!我是 ChiYu,也可以叫我 Eric。

寫了五年的 Code,平常都在跟 .Net 還有 Azure 打交道。簡單說,就是個靠鍵盤吃飯的工程師啦。去年有參賽,但中途忘記發文中斷!!! 希望今年能培養好習慣每天準時一篇不斷更!!!

這趟旅程,是為誰準備的?

在開始之前,我想先說說,這系列文章是為誰而寫的。

你可能完全沒有程式背景,但對現在最紅的 Vibe Coding 充滿好奇嗎?你是不是也想跟上這波 AI 浪潮,試著自己動手做點東西,甚至想成為一名開發者呢?

如果答案是「YES」,那這系列文章就是為你量身打造的!

我們不只玩 Vibe Coding,我更希望在過程中,帶你認識一些重要的「開發觀念」。像是什麼是「前端」、「後端」?什麼是「API」?版本要怎麼控制?這些在專業開發中一定會用到的術語和工作流程,我會用最白話的方式,融入到我們的實作裡。

所以,別擔心自己是「程式小白」。跟著我,我們一步一步來,不只做出一個酷專案,更要幫你打下成為開發者的堅實基礎。

那個…我只是想要一台腳踏車,你給我一艘航空母艦幹嘛?

身為工程師,有新玩具當然會想要跟著玩看看,但純粹的 Vibe Coding 下去,到底會得到什麼?

我的故事是這樣的:我想說來做個最經典最常見的「待辦事項清單 (Todo List)」練練手感。就對 AI 下了一個超簡單的指令:「幫我做個 Todo List 網站,要有CRUD的功能,並且想要一個簡約的UI,我希望專案要越完整越好。」

那時候我心裡想的超單純:啊不就一個 HTML,裡面塞一點點 JavaScript 就搞定了嗎?簡單、好懂、我自己要改也方便。

結果呢?AI 老兄一頓操作猛如虎,給我生出了一整個專案包。我點開資料夾,下巴直接掉下來。哇靠,這是怎樣?React、Node.js、Express、MongoDB……全家餐都來了!

老實說,這 App 能跑,但感覺完全歪掉了。我只是想要一台腳踏車,結果 AI 給了我一艘航空母艦。這要我怎麼騎……啊不是,這已經超出我所了解與熟悉的範圍,且專案規模整個失控!會導致這樣的原因有各種可能,可能是我的Prompt太過鬆散,但又出現了這個「專案要越完整越好」這個關鍵字,也可能是AI自己異想天開等等。出現這種「技術奇觀」讓我意識到,完全放任的 Vibe Coding 真的很容易失控,變成一個你根本不想碰的燙手山芋。

而且老實說,有時候在社群上看到一些分享,真的會替他們頭痛,曾看到有人在分享,他的朋友VibeCoding出了一個購物網站,但登入系統不論怎麼打密碼都可以登入,或是開發出的網站把所有應加密資訊顯露出去。

我完全懂拿到新玩具那種興奮感,AI 工具也確實是開發上的一大福音,而且也讓許多程式小白能體會成為一名工程師的感覺!! 但問題出在「盲目相信」。當專案一搞大,你很快會發現:東西越來越難改、AI 給的專案根本跑不起來、就算跑起來了,噴出來的 BUG 你也看不懂。更慘的是,你叫 AI 修,它修完又生出新的 BUG,最後就卡在一個無限迴圈裡動彈不得。這對沒有太多開發經驗的人來說,真的是個超級大坑。

為魔法裝上韁繩:左手藍圖,右手魔法

所以咧?難道就要這樣放棄 AI 這個神隊友嗎?當然不行!

這就像拿到一把絕世神兵,你不能因為它太利就把它丟掉,而是要學會怎麼駕馭它。所以我就開始找方法,到底要怎麼做才能讓 AI 乖乖聽話,然後我找到了這個說新不新說舊不舊的開發法則:

文件驅動開發 (Document-Driven Development, DDD)。

這東西的精髓,就是把 Vibe Coding 這匹野馬套上「韁繩」。這也是我想分享的這整個系列的核心玩法:【左手藍圖,右手魔法:DDD 與 Vibe Coding 的開發協奏曲】

我們的玩法:40% 藍圖 / 40% 魔法 / 20% 心法

接下來的 30 天,我們的內容佔比大概會是這樣:

  • 40% 是畫藍圖 (AI 文件生成):白話文就是,在叫 AI 寫 Code 之前,我們先逼它跟我們一起把「規格」想清楚、寫下來。我們要當個聰明的甲方,把需求、架構、API 都定義好。
  • 40% 是玩魔法 (AI 氛圍編程):等規格文件都搞定了,嘿嘿,重頭戲來了。我們就把這些文件丟給 AI,跟它說:「照著這個寫!」 這時候的 Vibe Coding 就不會亂跑,而是超精準的火力輸出。
  • 20% 是聊心法 (觀念與整合):最後這 20% 嘛,就是聊聊開發的觀念。當 AI 幫我們做了這麼多事之後,我們開發者的價值到底在哪?(先劇透:我們從蓋磚頭的工人,升級成拿藍圖的總工程師了啦!)。

我們這次的 AI 神隊友:Google Gemini

市面上的 AI 模型百百種,那在這 30 天的系列文中,我主要會使用的 AI 神隊友就是 Google Gemini。

為什麼選它?首先,它的能力很全面,反應也很快,不論是跟它聊規格、產文件,還是寫程式碼,它都能夠勝任,就像一個什麼都會的全能型選手。

再來,也是最關鍵的一點,就是它有官方的命令列工具 Gemini CLI。有了它,我們就可以待在舒服的 VS Code 終端機裡,完成從文件生成到程式碼編寫的所有事情!這對於我們要實踐「右手魔法」的 Vibe Coding 來說,簡直是絕配!而且免費的版本就足夠應用在這次的主題了,每天提供的用量基本上都用不完!!!

我們會在接下來幾天,一步步為魔法的降臨做好準備:Day 1 學習文件驅動的心法,Day 2 把開發環境準備就緒,Day 3 掌握版本控制。然後在 Day 4,我們將正式召喚這位終端機裡的盟友,手把手帶大家安裝與操作 Gemini CLI,敬請期待!

實戰專案:來做個【習慣養成與心情日誌】吧!

光說不練假把戲,對吧?所以接下來這 30 天,我們要來點真格的!我們來一起做一個**「習慣養成與心情日誌」**的網站。我們會用 Python + Flask 當後端,前端就返璞歸真,用 HTML/CSS/JS,從零把它做出來。

如果你也跟我一樣,覺得 AI 超猛,但又怕它變成脫韁野馬,那這趟旅程你絕對不能錯過。

明天我會來介紹什麼是 DDD 文件驅動開發,先讓大家了解這主題的核心之一【文件】的重要性。

特別提一下,在這篇系列文之後提到DDD都會是指文件驅動開發而不是另外一個更常見的DDD 領域驅動開發(Domain-Driven Development)。

標籤:

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

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

還有疑問

Learning path

2025 iThome 鐵人賽

這篇是系列中的第 1 / 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 3: 【工具篇 #1】萬丈高樓平地起:建置本地開發環境 封面圖 2025-08-22 Day 3: 【工具篇 #1】萬丈高樓平地起:建置本地開發環境 Day 2: 【心法篇】開發者的航海圖:什麼是文件驅動開發 (DDD)? 封面圖 2025-08-21 Day 2: 【心法篇】開發者的航海圖:什麼是文件驅動開發 (DDD)? 【開發雜談】Vibe Coding 2.0:從文件驅動 (DDD) 進化到規格驅動 (SDD),讓 AI 真正為你所用 封面圖 2025-12-29 【開發雜談】Vibe Coding 2.0:從文件驅動 (DDD) 進化到規格驅動 (SDD),讓 AI 真正為你所用

留言討論

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

閱讀導覽

約 5 分鐘

本篇所在系列 · 第 1 / 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 篇