經過 25 天的 AI-Driven Development 探索，從最初的敏捷困境反思，到 AI-DLC Sprint 框架的建立，再到各種工具實戰和團隊協作模式的探討，我們已經走過了一段精彩的旅程。

今天，讓我們停下來做個小結，並且誠實地談談那些「沒那麼美好」的部分。

25 天的旅程回顧

回頭看這 25 天，我們建立了一個完整的 AI 開發體系：

第一週：思維轉變

從「為什麼敏捷沒有解決根本問題」開始，我們認識到傳統開發模式的局限，進而提出了 AI-DLC Sprint 這個融合 AI 能力的新框架。我們把複雜的 Scrum 流程簡化成適合不同規模團隊的 Solo/Team/Scale Sprint。

第二週：工具賦能

從 Claudable 到 Claude Code，從 AI PM 到 AI Architect，我們探索了各種工具如何加速開發。那個 30 分鐘完成的習慣追蹤器，現在回想起來還是很神奇。

第三週：實戰落地

深入流程從規格書、User Story、設計開發到測試策略、Code Review、TDD/BDD 的 AI 實踐。這週最大的收穫是理解了 AI 不是取代人類，而是與人類一起工作，讓整個流程變得更全面、更智能。

第四週：團隊協作

從 AI Scrum Team 到 Cross-Functional 協作，我們看到了 AI 如何像經驗豐富的團隊成員一樣工作。特別是 Day 25 的 AI Team 協作，那種一個人指揮六個 AI 角色的感覺，真的像是擁有了一整個團隊。

AI-DLC Sprint 的真實價值

經過這段時間的實踐，我更確信 AI-DLC Sprint 的核心價值：

1. 速度的本質提升

不是快 2 倍，是快 10 倍。以前需要一個月的專案，現在一週就能交付 MVP。但這不是魔法，而是因為 AI 消除了大量的「無效工作」：

• 不用寫 Boilerplate Code
• 不用不懂規格文件還拆解任務半天
• 不用查文件找 API
• 不用手動寫測試案例
• 不用反覆調整 CSS

2. 認知負擔的釋放

最大的改變是心智模型的轉變。以前我們要記住語法、記住 API、記住最佳實踐。現在只需要專注在「要做什麼」而不是「怎麼做」。

就像筆者在 Day 15 提到的 TDD，有了 AI 後，紅綠重構的循環變得如此流暢，因為 AI 處理了繁瑣的部分，我們只需要定義行為。

3. 品質的意外提升

原本擔心 AI 會降低程式碼品質，但實際上相反。只要文件足夠精確，Prompt 足夠清晰，AI 生成的程式碼往往包含了：

• 完整的錯誤處理
• 適當的型別定義
• 一致的程式碼風格
• 基本的安全考量

AI-DLC Sprint 可以優化的地方

但是，AI-DLC Sprint 並不完美。這 25 天的實踐也暴露了一些需要改進的地方：

1. Context 爆炸問題

隨著專案規模增長，要讓 AI 理解整個系統變得越來越困難。我們需要更好的 Context 管理策略，可能是分層的、模組化的 Context 系統。

2. 創新性的瓶頸

AI 擅長組合已知的模式，但真正的創新仍然需要人類。如何在 AI-DLC Sprint 中保留創新空間，是個值得思考的問題。

3. 團隊採用的阻力

不是每個人都準備好與 AI 協作。需要更多的培訓、更友善的入門路徑，以及更多的成功案例分享。

好了，鋪墊夠了，現在讓我們進入今天的主題——那些筆者踩過的坑，希望你不要再踩。

AI 開發的七宗罪（反模式）

反模式一：Context 肥胖症

這是我最常犯的錯誤。想要 AI 了解所有背景，結果把整個專案的程式碼都貼給它。

錯誤示範：

我有一個電商系統，這是所有的程式碼：
[貼上 10,000 行程式碼]
現在幫我加一個購物車功能...

為什麼這樣不好：

• AI 會迷失在細節中
• Token 成本爆炸
• 回應品質反而下降

正確做法：

專案背景：電商系統，使用 Next.js + PostgreSQL
現有模組：用戶系統、商品管理、訂單處理
相關 Schema：[只貼相關的 2-3 個表]
任務：新增購物車功能，需要支援...

可以使用 User Story + Agent Memory(CLAUDE.md) 來達成，要給 AI 最少必要資訊，而不是所有資訊

反模式二：Prompt 工程過度症

初期我總想寫出「完美的 Prompt」，結果 Prompt 比程式碼還長。

錯誤示範：

你是一個資深的全端工程師，精通 React、Node.js、PostgreSQL...
請注意以下幾點：
1. 使用 TypeScript
2. 遵循 SOLID 原則
3. 實作要包含錯誤處理
4. 要有適當的註解
5. 變數命名要有意義
6. 要考慮效能
7. 要有單元測試
... (還有 20 條)

為什麼這樣不好：

• AI 可能忽略真正重要的需求
• 過度限制了 AI 的彈性
• 維護這種 Prompt 本身就是負擔

正確做法：

用 TypeScript 寫一個用戶登入 API，包含：
- JWT token 生成
- 密碼加密驗證
- 基本錯誤處理
其他依照標準實踐即可。

反模式三：盲目信任症候群

AI 說什麼都對，直接複製貼上不思考。這個在 Day 14 的測試策略中特別危險。

真實案例：
有一次 AI 建議我用遞迴處理一個樹狀結構，我直接用了。結果因為資料量大，Stack Overflow 了。

教訓：

• AI 的建議要經過思考
• 特別是效能相關的程式碼
• 關鍵邏輯一定要 Review
• 目前 AI 對於部署相關的資訊非常不穩
• 要記得使用 context7 MCP 更新最新資訊

反模式四：對話失憶症

每次都開新對話，不累積 Context，導致每次都要重新解釋。

錯誤做法：

對話 1：幫我寫個登入功能
對話 2：幫我寫個註冊功能（重新解釋整個系統）
對話 3：幫我寫個忘記密碼（又重新解釋）

正確做法：
保持同一個對話串，或是不斷更新 Agent Memory (CLAUDE.md)

反模式五：過度依賴症

完全依賴 AI，自己不思考，結果基本功退化。

症狀：

• 簡單的 array map 都要問 AI
• 不看文件，直接問 AI
• Debug 完全依賴 AI

解方：

• AI 是輔助，不是替代
• 簡單問題自己解決
• 用 AI 來處理繁瑣但不是核心的工作

反模式六：完美主義陷阱

想要 AI 一次生成完美的程式碼，不斷調整 Prompt，浪費大量時間。

錯誤心態：
「這個 Button 元件還不夠完美，讓我再調整一下 Prompt...」
（花了 2 小時調整，其實手動改只要 5 分鐘）

正確心態：

• AI 生成 70% → 手動調整 30%
• 不要追求一次到位
• 迭代比完美更重要

反模式七：Context 切換混亂

在同一個對話中跳來跳去，一下前端一下後端一下資料庫。

混亂對話：

1. 幫我設計資料庫 Schema
2. 寫個 React Component
3. 回到資料庫，加個欄位
4. 對了，CSS 要怎麼寫
5. 資料庫索引要怎麼建

清晰對話：
分層處理，每層一個對話：

• 對話 1：完整處理資料庫設計
• 對話 2：API 層開發
• 對話 3：前端實作

使用 AI Agent 善用 / 自建指令 or Subagents(Claude)
建立專用的 AI subagents 讓每一個 agent or 指令只專注做一件事情。

結論：從錯誤中成長

這 25 天最大的收穫，不是學會了多少 AI 技巧，而是理解了 AI 的邊界。AI 是一個強大的工具，但它不是萬能的。正如筆者在 Day 2 提到的：

這不是要優化馬車，而是要發明汽車。但即使有了汽車，你還是需要會開車。

AI-Driven Development 的核心不是「AI 幫你寫程式」，而是「你和 AI 一起寫出更好的程式」。每個踩過的坑，都讓我們更懂得如何與 AI 協作。