終於到了系列的最終章～
30 篇文章不只是為了完賽而寫，而是真實地記錄了我的成長。
從第一個 MenuBar Todo，到最後的 BoltHQ，每個專案都是一次實驗，每次實驗都帶來新的領悟。
今天，讓我回顧這 30 天的旅程，分享四個專案的故事，以及我學到的一切。
初衷：
「我要用 SDD AI Sprint 做一個 MenuBar App！」
現實：
第一個專案就碰上一堆問題：
學到的經驗：
AI 不是魔法，但是捷徑
問題要具體
小步驗證
成果：
如果重做？
現在的我會：
但第一次的「粗糙」很重要，因為它讓我知道：
「我真的可以用 SDD AI Sprint 做出東西！」
初衷：
「有了 MenuBar Todo 的經驗，這次我要做一個大一點的專案！」
現實：
我大膽地做了：
然後...做不完。
學到的教訓：
野心要配得上能力
MVP 的重要性
使用者回饋的價值
成果：
如果重做？
現在的我會：
這次經驗讓我明白：
「完成 比 完美 更重要。」
初衷：
「這次我要做小一點，但要做完！」
現實：
我學聪明了：
學到的教訓：
少即是多
TDD 的價值
使用者體驗的重要性
成果：
初衷：
「我要把前三個專案學到的東西，整合成一個完整的開發流程！」
現實：
這次我做了前所未有的準備：
然後才開始寫 code。
學到的教訓：
準備比執行更重要
AI 傭兵團的威力
流程比工具更重要
成果：
讓我用表格比較一下：
| 項目 | MenuBar Todo | 智能記帳 | 心情日記 | BoltHQ |
|---|---|---|---|---|
| 開發時間 | 3 天 | 14 天（未完成） | 7 天 | 5 天（準備）+ 開發中 |
| 功能數 | 3 | 8 | 3 | 4 |
| 完成度 | 90% | 70% | 100% | 進行中 |
| 有無 PRD | ✗ | ✗ | ✗ | ✓ |
| 有無 TDD | ✗ | ✗ | ✓ | ✓ |
| 有無 UI 設計 | ✗ | ✗ | ✓ | ✓ |
| 使用者 | 只有我 | 沒人用 | 5+ 人 | 還沒上線 |
| 學到什麼 | AI 協作 | MVP 重要性 | 聚焦的價值 | 系統化流程 |
看得出來的趨勢：
準備時間增加，但總時間減少
功能數減少，但完成度提高
文件從無到有，品質提升
測試從無到有，信心增加
最近我在工作上遇到一個「經典」需求：
一週內要完成原本估兩個 Sprint 的功能。
（沒錯，就是那種敵捷開發但 Deadline 和 Scope 都不可撓動的情況）
傳統作法（需要 14 天）：
Day 1-2：看需求，想要做什麼
Day 3-4：設計資料庫，寫 API
Day 5-6：做前端，發現與 API 不合
Day 7-8：改 API，再改前端
Day 9-10：測試，發現一堆 bug
Day 11-12：修 bug，又壞了其他功能
Day 13-14：再修 bug，總算可以上線
SDD AI Sprint 實戰（7 天完成）：
Day 1 上午：與 AI PM 寫 PRD（1 小時）
Day 1 下午：與 AI BA 拆 User Stories（2 小時）
Day 2 上午：與 AI Architect 設計架構（3 小時）
Day 2 下午：與 AI Designer 設計 UI（2 小時）
Day 3-5：TDD 開發核心功能
Day 6：整合測試，修 bug
Day 7：Demo 和上線
差別在哪？
| 項目 | 傳統作法 | SDD AI Sprint |
|---|---|---|
| 需求明確度 | 模糊 | 非常清晰 |
| 設計時間 | 遲到開發才發現問題 | 提前發現並解決 |
| 開發速度 | 慢，一直改 | 快，方向清晰 |
| Bug 數量 | 多，改 A 壞 B | 少，有測試保護 |
| 文件完整度 | 無 | 完整 |
| 信心 | 低，不確定能否完成 | 高，每步都可預測 |
雖然每天都加班，但還是在期限內完成了整個專案。
這次經驗讓我更確信：
SDD AI Sprint 不是理論，是真的能在實戰中發揮作用的方法論。
以前估時：
這個功能大概... 3 天吧
（心裡想著可能要 5 天）
現在估時：
PRD + User Stories: 0.5 天
架構 + UI 設計: 0.5 天
AI 輔助開發: 1 天
測試調整: 0.5 天
Buffer: 0.5 天
= 3 天
準確度反而提高了，因為：
以前：
PM：「這個功能的 API 文件在哪？」
我：「額...我寫在 code 裡面，你看 code 就知道了」
現在：
PM：「這個功能的 API 文件在哪？」
我：「在 docs/API.md，有完整的說明和範例」
AI 讓文件自動產生：
我現在的專案文件完整度是以前的 3 倍。
不是我變勤勞了，是 AI 讓文件「順便」就產生了。
這 30 天最大的收獲不是技術，而是思維方式的轉變。
| 情境 | 以前的我 | 現在的我 |
|---|---|---|
| 遇到複雜功能 | 這個功能好複雜，要研究好久 | 讓我想想怎麼跟 AI 描述清楚 |
| 遇到 Bug | 這個 bug 找不到原因，要慢慢 debug | 把錯誤訊息丟給 AI，一起分析 |
| 學新技術 | 新技術好難學，要看好多文件 | 直接問 AI + 實作驗證 |
| 需求估時 | 這個需求做不完 | 讓 AI 傭兵團一起上 |
當這些事情都變簡單了：
我們就能專注在真正重要的事：
1. 與 AI PM 寫 PRD（10 分鐘）
↓
2. 與 AI BA 拆 User Stories（10 分鐘）
↓
3. 與 AI Architect 設計架構（10 分鐘）
↓
4. 與 AI Designer 設計 UI（10 分鐘）
↓
5. TDD 開發
- 寫測試
- 與 AI 實作
- 重構優化
- 繼續下一個
↓
6. 整合測試（30 分鐘）
↓
7. 上線部署（15 分鐘）
這個流程：
錯誤期待：
「我告訴 AI 要做什麼，AI 就能做出完美的成品」
現實：
「AI 幫我快速產生初稿，我再調整到完美」
AI 是 80分的助手，不是 100分的魔法師。
差的問題：
「幫我寫一個任務管理 App」
好的問題：
「如何在 React 中實作一個可拖曳的任務清單，使用 dnd-kit 庫，支援多欄佈局？」
越具體的問題，越好的答案。
失敗的智能記帳：
成功的心情日記：
做少一點，但做好一點。
沒有測試的痛苦：
有測試的自由：
測試是信心的來源。
以前：
「寫文件好麻煩，有時間再說」
現在：
「AI 幫我寫 PRD，我只需要 review」
讓 AI 產生文件，我們來保證品質。
不準備：
有準備：
磨刀不誤砍柴工。
大步開發：
小步驗證：
快速失敗，快速調整。
單一 AI：
「幫我做一個專案」（什麼都不專精）
AI 傭兵團：
分工合作，各司其職。
只有工具：
有 AI，但不知道什麼時候用
有流程：
知道每個階段該用哪個 AI
好的流程讓好的工具發揮最大效益。
一次完美：
持續改進：
完成比完美更重要，進步比完美更持久。
今年想挑戰自己做些不一樣的事情，所以找了兩位同事一起參加鐵人賽。他們都是我職涯旅程中遇到為數不多的優秀夥伴，兼具硬實力與軟實力。
強烈推薦大家去看看他們的精彩分享：
今年還不小心報名了兩場演講，其中一場是明天的 Hello World Dev Conference 2025。演講內容正是這個系列的精華：SDD AI Sprint 的實戰經驗。希望能將這些經驗帶給更多開發者。
你還在猶豫要不要投入時間學習 AI 開發嗎，三種情況，三個建議～
如果你還在觀望：
不要等了，現在就是最好的時機。如果你剛開始學習：
堅持下去，突破點比你想像的更近。如果你已經在實踐：
歡迎交流，一起探索更多可能。
雖然鐵人賽結束了，但我的 AI 開發之旅才剛開始～
如果你對 SDD AI Sprint 有興趣，歡迎關注我的 AI-Driven Development - 個人開發者的敏捷實踐
我想打造的是個人開發者和團隊都能受益的 AI 開發流程。這 30 天，我用 side project 實踐了 SDD AI Sprint，得出的就是這 30 篇文章的內容。
這些都是我過往經驗和實際試煉的結果。雖然可能不是最完美的做法，但希望能為你帶來一些啟發和實用的方法。
目前 SDD 大家都在使用以及個人體驗上真的改變了傳統開發的模式，但是後面要維護 AI Code 也是一個非常大的挑戰，目前流程上真的很快很順暢，但後面的維護目前還在觀察，以及要把 SDD AI Sprint 導入到小團隊甚至是大團隊也是一個很大的挑戰。
感謝每一位看到這裡的讀者～
特別感謝：
- iThome 鐵人賽平台，提供了這個分享和學習的機會
- AI 工具的開發者們，你們創造了改變世界的工具
- 我的團隊，包容我在這 30 天的各種實驗
- 鐵人賽鳥籠小夥伴，有戰友讓彼此走得更遠
如果這個系列對你有幫助，請：
iThome鐵人賽
看影片追技術