經過 5 天的開發旅程，今天是 MoodStamp 專案的收尾。雖然沒有完成一個可以上架的完整 App，但這 6 天的價值遠超過一個 Side Project 本身。今天我想好好回顧這段旅程，分享真實的感受、踩過的坑，以及最重要的——AI-DLC Sprint 到底改變了什麼。
很多人會問：「你 6 天就寫了 200 行程式碼？這也太慢了吧？」
但如果你看看我們實際產出的東西：
文件層面：
程式碼層面：
更重要的是無形資產：
如果用傳統方式開發，光是需求釐清和文件撰寫就要花 2-3 天，UI/UX 設計可能要外包或自己硬刻一週。而我們用 AI 協作，把這些時間壓縮到幾個小時，但品質沒有打折。
讓我分享一些具體的對比：
需求釐清階段（Day 1）：
PRD 撰寫（Day 2）：
UI/UX 設計（Day 4）：
測試撰寫（Day 5）：
第一天最讓我驚訝的是，AI 不是等我下指令，而是主動發起對話。
我只是說：「我想做一個心情記錄 App。」
AI 立刻開始問：
這些問題讓我意識到，我原本以為很清楚的需求，其實有很多模糊地帶。傳統開發方式下，這些模糊地帶會變成後期的需求變更和重做，但 AI-DLC 在第一天就幫我釐清了。
更厲害的是，AI 還會提出我沒想到的風險：
「如果使用者輸入敏感內容，你要如何確保 AI 生成的回應是適當的？」
「有些使用者可能不想要 AI 回應，需要提供關閉選項嗎？」
「如果 OpenAI API 掛掉或達到配額限制，有備援方案嗎？」
這種防禦性思考是我以前常常忽略的，但 AI 會系統性地檢查這些潛在問題。
以前寫 User Story，我常常卡在「粒度」的問題：
AI 幫我拆解 User Story 時，我才理解什麼叫「恰到好處」。
舉個例子，我原本想寫：「作為使用者，我想記錄今天的心情。」
AI 說：「這個太大了，我們拆成幾個獨立的價值點。」
然後它給了我：
你看出差別了嗎？
原本的版本只是功能描述，AI 拆出來的每一條都有明確的使用者價值和清晰的範圍界定。而且每一條都是獨立的，可以單獨開發、單獨測試、單獨上線。
更重要的是，AI 自動生成的 Acceptance Criteria 超級詳細：
Given 使用者在輸入框輸入文字
When 文字長度達到 200 字
Then 輸入框應該停止接受新的輸入
And 顯示提示訊息「已達字數上限」
And 字數統計顯示「200/200」並變成紅色
這種細緻度讓我在寫測試時完全不用猜，照著 AC 寫就對了。
我必須承認，設計一直是我的弱項。以前做 Side Project，UI 常常長這樣：
「嗯...這個按鈕好像太小了？那就調成 50px 好了。」
「間距看起來怪怪的？那就加個 margin: 10px 吧。」
「顏色？就用藍色吧，#0000FF...嗯，太亮了，改 #336699。」
結果整個 App 充滿了 Magic Number，沒有一致性，看起來就是「工程師做的設計」。
AI UX Designer 完全改變了這個狀況。它不是隨便選顏色，而是給我一套完整的色彩理論：
「我選擇 #6366F1（藍紫色）作為主色，原因是：
然後它還給了我整套的 Spacing System，基於 8px Grid：
XS: 8px → 相關元素間距（如文字和圖示）
S: 16px → 段落間距
M: 24px → 區塊間距
L: 32px → 主要區塊間距
XL: 48px → 頁面上下留白
有了這套系統，我不用再猜「這裡要留多少空間」，照著規則走就好。而且因為是系統化的，整個 App 看起來會很一致。
最讓我驚喜的是 Accessibility 檢查。AI 自動檢查了：
這些是我以前根本不會想到的，但 AI 把無障礙設計當作基本要求，自動納入考量。
說實話，Day 5 是最掙扎的一天。
TDD 的理念我懂：先寫測試，再寫實作。但實際操作時，內心一直有個聲音：
「寫測試好慢啊...不如先把功能做出來，測試之後再補？」
「這個測試是不是太細了？會不會浪費時間？」
「我已經知道要怎麼寫了，為什麼還要先寫測試？」
這種「急著看到成果」的心態，是 TDD 最大的敵人。
但當我逼自己完成第一個 Red-Green-Refactor 循環後，我開始理解 TDD 的價值。
Red Phase（寫失敗的測試）的價值：
當我寫這個測試時：
test('should not allow empty content', () {
expect(
() => MoodEntry(
id: 'test-id',
content: '',
stamp: '😊',
date: [DateTime.now](http://DateTime.now)(),
),
throwsA(isA<ArgumentError>()),
);
});
我必須先想清楚：「空內容應該怎麼處理？拋出錯誤？還是給預設值？」
這個思考過程逼我在寫 code 之前就把邊界條件想清楚，而不是寫到一半才發現「哎呀，空字串怎麼辦？」
Green Phase（讓測試通過）的價值：
寫實作時，我只需要專注在「讓這個測試通過」，不用想太多：
if (content.isEmpty) {
throw ArgumentError('內容不能為空');
}
這段 code 很簡單，甚至有點「笨」，但它做到了該做的事。這就是 TDD 的精神：先求有，再求好。
Refactor Phase（重構）的價值：
當我想把驗證邏輯抽出來時：
void _validateContent() {
if (content.trim().isEmpty) {
throw ArgumentError('內容不能為空');
}
if (content.length > maxContentLength) {
throw ArgumentError('內容不能超過 $maxContentLength 字');
}
}
我可以放心地重構，因為測試會告訴我有沒有改壞。這種安全感是沒有測試時完全體會不到的。
跑完測試，看到一排綠燈，那種成就感真的很爽。
問題：
Day 5 寫測試時，AI 生成的程式碼有時候會有小錯誤，比如 import 路徑錯誤、參數順序不對。
解決方案：
不要無腦複製貼上！
AI 是助手不是魔法，它能節省 80% 的時間，但剩下 20% 還是要自己檢查。
問題：
剛開始寫測試時，我想把所有可能的情況都測到，結果寫了 20 個測試，但功能還沒開始做。
解決方案：
TDD 不是追求 100% 覆蓋率，而是測試重要的行為。
我學會了問自己：
只測重要的，其他的可以之後再補。
問題：
Day 3 拆 User Story 時，我直接全部交給 AI，結果有幾條 Story 不符合我們的實際需求。
解決方案：
AI 是「協作夥伴」不是「外包廠商」。
最好的協作方式是：AI 做 80%，我把關最後 20%。
1. Day 1 的深度釐清
花時間在一開始把需求想清楚，真的值得。很多專案失敗不是因為技術問題，而是需求一直變。
AI-DLC 的 Inception 階段幫我在第一天就把大部分的問題想清楚，後面開發就很順。
2. Design System 先行
Day 4 建立完整的 Design System 看起來很花時間，但後面實作 UI 時會很快，因為所有的顏色、間距、字體都有規範，不用再猜。
3. TDD 從核心功能開始
Model 層用 TDD 開發絕對是對的，因為它是整個系統的基礎。如果 Model 有 bug，上層全部遭殃。
1. 更早做技術驗證
我們花了 4 天在文件和設計，直到 Day 5 才開始寫 code。如果重來，我會在 Day 2 或 Day 3 就先做一個技術 Spike，確認技術棧真的可行。
比如：
這種快速驗證可以避免「做到一半才發現技術行不通」的悲劇。
2. 更務實的範圍控制
回頭看 Day 2 的 PRD，我們規劃了太多功能：
如果重來，我會更激進地砍功能，只保留最核心的價值：
其他的都是「Nice to have」，可以之後再加。
3. 更早開始「看得見」的開發
文件和測試很重要，但人是視覺動物。如果 Day 3 或 Day 4 就能看到一個簡單的畫面，即使只是 UI 沒有功能，也會更有動力繼續做下去。
所以如果重來，我可能會調整順序：
這樣每天都有「看得見」的進度，心理上比較有成就感。
經過這 6 天，我對 AI-DLC Sprint 有了更深的理解。它不是萬能的，而是有適用範圍。
1. 需求相對明確的 MVP
如果你已經有個大致的想法，只是想快速驗證可行性，AI-DLC Sprint 非常適合。它能幫你在最短時間內做出一個「能動」的原型。
例如：
2. 技術棧成熟的領域
AI 在「已知」的技術上表現最好。如果你用的是 React、Flutter、Node.js 這種主流技術，AI 的建議會很準確。
但如果你要用很新或很冷門的技術，AI 可能會給出過時或錯誤的資訊。
3. 個人或小團隊（2-3 人）
AI-DLC Sprint 的快速迭代節奏很適合個人開發者或小團隊。大團隊可能需要更多的溝通協調，反而會拖慢速度。
1. 需求極度模糊
如果你連「要做什麼」都還不清楚，AI 也幫不了你。AI 能幫你釐清需求，但前提是你至少要有個方向。
比如「我想創業但不知道做什麼」這種問題，AI 給不出答案。
2. 需要大量使用者研究
如果你的專案需要深入了解使用者需求、做市場調查、分析競品，AI-DLC Sprint 可能太快了。
這種專案需要更多的前期研究，不適合「快速衝刺」的模式。
3. 複雜的多團隊協作
如果你的專案涉及前端、後端、設計、產品、測試多個團隊，每個團隊都有自己的流程和節奏，AI-DLC Sprint 的快速迭代可能會造成混亂。
這時候傳統的 Agile 或 Scrum 可能更適合。
iThome鐵人賽
看影片追技術