在前面二十一天的旅程中，我們走過了需求分析、使用者故事拆解、介面設計、測試策略，今天終於要進入 AI-DLC Sprint 的第五個環節 - AI Developer。這不是傳統的「寫程式」階段，而是一個全新的開發模式，其中 AI 不再只是程式碼生成器，而是真正的開發夥伴。

從程式碼生成到 AI 開發

還記得剛開始使用 GitHub Copilot 的時候嗎？那種「寫註解就能生成程式碼」的驚喜感。但很快你就會發現，單純的程式碼生成有其極限 - 它缺乏上下文理解、無法把握整體架構、更不懂你的業務邏輯。

AI Developer 的角色遠不止於此。它是一個能夠理解你的領域模型、遵循你的測試規範、符合你的架構設計的開發夥伴。更重要的是，它能夠在開發過程中主動提出建議、發現潛在問題、推薦更好的實作方式。

Code Generation 的層次化策略

筆者在實踐中嘗試了一套層次化的程式碼生成策略，從宏觀到微觀，從架構到細節，讓 AI 在不同層次發揮作用。

不像傳統的 Vibe Coding 的一句話一句話鞭策著 AI，而是讓 AI 像人類一樣讀懂所有文件以及依照嚴格的規範進行架構規劃到實作的完整工作流。

第一層：架構層生成

在這個層次，AI 負責產生整體的專案結構和架構骨架。記得我們在 DDD 階段定義的領域模型嗎？
AI Developer 會基於這些模型生成對應的專案結構。

筆者很喜歡 Claude Code 的 Subagents 的功能，簡直把這個概念發揮得淋漓盡致

比如當我告訴 AI：「基於我們定義的電商領域模型，建立專案結構」，它會生成：

• 符合 Clean Architecture 的目錄結構
• 領域層、應用層、基礎設施層的明確劃分
• 每個聚合根對應的模組結構
• 必要的介面定義和依賴注入設定

這不是簡單的模板套用，而是基於你的具體業務需求的客製化架構。

第二層：模組層生成

在模組層，AI 負責實作具體的業務邏輯。這裡的關鍵是保持領域語言的一致性。當你說「實作訂單聚合根的下單流程」，AI 會：

• 遵循已定義的業務規則
• 實作領域事件的發布
• 處理異常情況和邊界條件
• 維持與其他聚合的正確關係

第三層：方法層生成

這是最細粒度的生成，但也是最容易出錯的地方。筆者的的經驗是，不要讓 AI 一次生成太長的方法，而是採用「步進式生成」，並且粒度越小越好：

• 先生成方法規劃和基本結構
• 逐步填充每個邏輯區塊
• 每次生成後立即驗證
• 根據測試結果調整

這種分層策略的好處是，每一層都有明確的驗證標準，錯誤不會在層與層之間擴散。

前面的流程我們其實已經跟 AI 協作將 User Story & AC 切得非常細，這時候的實作的精準度可以趨近我們想要的樣子

AI Pair Programming 的最佳實踐

Pair Programming 一直是提升程式碼品質的有效方法，但傳統的人與人結對常常因為節奏不同、風格差異而產生摩擦。AI Pair Programming 改變了這個局面。

在與 AI 一起工作時，我發現最有效的模式是動態切換角色：

AI 當 Driver，你當 Navigator
AI 當 Mentee，你當 Mentor

這種模式適合處理大量的樣板程式碼或重複性工作。你提供高層次的指導，AI 負責具體實作。比如：

• 「為所有的 API 端點加上認證中間件」
• 「把這個同步方法改成非同步版本」
• 「為這個類別加上完整的單元測試」
• 「請執行這個 User Story 並且按照規範實作」

在這種模式下，你的注意力可以放在業務邏輯和架構決策上，而不是語法細節。

你當 Coder，AI 當 Reviewer
這種模式適合處理複雜的業務邏輯或創新性的功能。你寫程式碼，AI 在旁邊提供建議：

• 「這個演算法的時間複雜度是 O(n²)，考慮使用哈希表優化」
• 「這裡可能會有並發問題，建議加上互斥鎖」
• 「這個模式在 XX 框架中有更簡潔的寫法」

AI 的建議不是命令，而是參考。你可以選擇接受、修改或忽略。

可以善用 Claude Code 的 Output styles 功能，以及 AI Code Review 的 Pipeline

Spec Drive Development 的概念

如同 SDD 的 Specify - Plan - Tasks 的概念，將規格撰寫清楚，切完的任務十分清楚的情況下，搭配人類在旁邊的監督，可以達到與 AI 協作的完美情況。

重構建議的 AI 時機判斷

重構是保持程式碼健康的關鍵，但什麼時候重構、重構到什麼程度，一直是開發者的難題。AI Developer 在這方面展現了獨特的價值。

AI 的重構嗅覺

AI 能夠識別多種程式碼異味（Code Smell），並在適當的時機提出重構建議：

立即重構的訊號

• 重複程式碼超過三處
• 方法超過 30 行
• 類別責任不單一
• 循環嵌套超過三層

當 AI 發現這些問題時，它會立即提出：「這個方法過長，建議拆分成三個小方法，每個負責單一職責。」

延遲重構的時機

• 功能還在快速迭代中
• 業務邏輯尚未穩定
• 即將進行大規模架構調整

這時 AI 會說：「發現潛在的重構機會，但建議等功能穩定後再進行。已記錄在技術債清單中。」

從 AC 到程式碼的完整流程

還記得昨天討論的 Acceptance Criteria 嗎？今天我們要看看如何把這些 AC 轉化成實際的程式碼。

BDD 到程式碼的自動映射

當你有了清晰的 Given-When-Then，AI Developer 能夠自動產生對應的程式碼結構：

Given（前置條件 -> 初始化程式碼

• 資料庫測試資料的準備
• Mock 物件的設定
• 系統狀態的初始化

When（觸發動作）-> 業務邏輯實作

• API 端點的實作
• 事件處理器的編寫
• 業務方法的開發

Then（預期結果）-> 驗證邏輯

• 斷言的實作
• 回應格式的定義
• 錯誤處理的完善

這種映射不是機械的翻譯，而是智慧的轉化。AI 會考慮效能、可維護性、錯誤處理等多個面向。

TDD 循環的 AI 加速

在 TDD（測試驅動開發）模式下，AI Developer 展現了驚人的效率提升：

紅燈階段（寫失敗的測試）

AI 根據 AC 快速生成測試案例，確保測試真的會失敗（避免假陽性）。

綠燈階段（讓測試通過）

AI 生成最小可行的實作，不過度設計，只求通過測試。

重構階段（優化程式碼）

AI 識別重複、提取共用邏輯、改善命名，同時確保測試持續通過。

傳統的 TDD 循環可能需要 30-60 分鐘，有了 AI 協助，這個時間可以縮短到 5-10 分鐘。

DDD 實作的領域保真度

在實作 DDD 時，最大的挑戰是保持領域語言的純粹性。AI Developer 在這方面的表現讓我驚艷：

領域語言的一致性

AI 會記住你定義的所有領域術語，在程式碼中保持一致的命名。不會出現同一個概念有多個名稱的情況。

業務規則的封裝

複雜的業務規則會被正確地封裝在領域物件中，而不是散落在控制器或服務層。

領域事件的自動識別

當某個動作會影響系統狀態時，AI 會自動建議發布領域事件，維持系統的最終一致性。

結論

AI Developer 不是要取代程式設計師，而是要解放程式設計師的創造力。當 AI 處理了重複性的程式工作，你就有更多時間思考架構、設計系統、理解業務。

記得一位資深工程師說過：「寫程式碼只是軟體開發的一小部分，理解問題、設計解決方案、確保品質才是核心。」AI Developer 正是幫助我們聚焦在這些核心價值上。

程式設計的本質不是打字，而是思考。AI 可以加速打字，但思考依然是人類的特權和責任。擁抱 AI Developer，不是為了少寫程式碼，而是為了寫出更好的程式碼。