/feature-dev

description: 啟動系統化的功能開發工作流程

功能開發工作流程

歡迎使用功能開發工作流程！此流程將指導您完成從需求分析到實作的完整開發過程。

核心理念

在開始實作前請遵循以下原則：

• **提出澄清問題** - 在實作前充分理解需求
• **先理解現有模式** - 分析程式碼庫的既有架構
• **簡潔優雅** - 優先選擇簡單優雅的解決方案，而非快速但複雜的實作

七個階段

階段一：發現與理解

**目標**：釐清需要建構什麼

**關鍵問題**：

• 這個功能要解決什麼問題？
• 功能的範圍是什麼？有哪些邊界？
• 有哪些限制條件（效能、相容性等）？
• 是否有類似的現有功能可以參考？

**輸出**：清晰的功能需求描述

---

階段二：程式碼庫探索

**目標**：深入理解現有程式碼庫的架構和模式

**行動**：

• 啟動並行的探索代理來分析程式碼庫
• 尋找類似的功能實作
• 追蹤相關的執行路徑
• 識別架構層次和模式

**工具**：使用 `code-explorer` 代理

**輸出**：

• 架構圖和元件關係
• 現有模式和抽象化
• 相關檔案和相依性清單

---

階段三：提出澄清問題

**目標**：在設計前解決所有模糊之處

**關注點**：

• 未明確定義的邊緣案例
• 錯誤處理策略
• 範圍邊界
• 與現有功能的整合點

**重要**：等待使用者回答後再繼續實作

**輸出**：已解答的問題清單

---

階段四：架構設計

**目標**：設計符合程式碼庫的實作方案

**行動**：

• 提出多種實作方法
• 分析每種方法的優缺點
• 推薦最適合當前情境的方案
• 說明為何這是最佳選擇

**考量因素**：

• 與現有架構的契合度
• 可維護性和可擴展性
• 效能影響
• 測試策略

**輸出**：

• 推薦的架構設計
• 替代方案及其取捨
• 實作計畫

---

階段五：實作

**目標**：依照選定的架構建構功能

**前提**：必須獲得使用者明確批准後才能開始

**原則**：

• 遵循選定的架構
• 符合程式碼庫慣例
• 撰寫清晰、可維護的程式碼
• 包含適當的錯誤處理
• 新增必要的測試

**輸出**：完整的功能實作

---

階段六：品質審查

**目標**：確保程式碼品質和正確性

**行動**：

• 啟動審查代理專注於：
• 程式碼簡潔性
• 功能正確性
• 專案慣例遵循
• 處理審查發現的問題
• 進行必要的重構

**工具**：使用 `code-reviewer` 代理

**輸出**：

• 審查報告
• 已修正的問題清單
• 改進建議

---

階段七：總結

**目標**：記錄完成的工作和後續步驟

**內容**：

• 完成的功能摘要
• 關鍵決策說明
• 修改的檔案清單
• 建議的後續步驟
• 測試建議

**輸出**：完整的專案總結文件

---

使用指南

啟動工作流程

只需告訴 Claude 您想要開發什麼功能：

我想新增一個使用者登入功能

或

幫我實作資料匯出功能

在各階段之間互動

• 在每個階段結束時，會詢問您是否繼續
• 您可以隨時提供額外資訊或調整方向
• 不要急於跳過澄清問題階段

最佳實踐

1. **詳細描述需求** - 提供越多背景資訊越好 2. **回答澄清問題** - 這些問題很重要，能避免後續返工 3. **審查設計方案** - 在實作前確認架構設計 4. **測試實作** - 在標記完成前測試功能 5. **記錄決策** - 保留重要設計決策的記錄

專門代理說明

code-explorer（程式碼探索者）

• **用途**：深入分析現有程式碼庫
• **能力**：追蹤執行路徑、映射架構、理解模式
• **時機**：階段二 - 程式碼庫探索

code-architect（程式碼架構師）

• **用途**：設計功能架構和實作藍圖
• **能力**：評估多種方案、分析權衡、推薦最佳設計
• **時機**：階段四 - 架構設計

code-reviewer（程式碼審查者）

• **用途**：審查程式碼品質和正確性
• **能力**：發現錯誤、檢查慣例、提供改進建議
• **時機**：階段六 - 品質審查

注意事項

這個工作流程適合：

• 中大型功能開發
• 需要深入理解程式碼庫的任務
• 重要且影響廣泛的變更
• 學習和理解新專案

這個工作流程不適合：

• 簡單的錯誤修復
• 微小的文字或樣式調整
• 緊急熱修復
• 已經完全理解的簡單任務

對於簡單任務，直接進行實作會更有效率。

範例場景

場景一：新增使用者驗證

使用者：我需要新增電子郵件驗證功能

階段一：澄清需求
- 驗證流程為何？（發送連結 vs 輸入代碼）
- Token 有效期限？
- 未驗證使用者的存取限制？

階段二：探索程式碼庫
- 分析現有的使用者模型
- 檢視郵件發送系統
- 理解驗證流程

階段三：澄清問題
- 重複請求驗證郵件的處理？
- 變更電子郵件地址的流程？
- 驗證失敗的錯誤訊息？

階段四：設計
- 方案 A：使用 JWT token
- 方案 B：資料庫 token
- 推薦：方案 B（更安全，可撤銷）

階段五：實作
- 建立驗證模型和遷移
- 實作郵件發送邏輯
- 新增驗證端點
- 更新使用者模型

階段六：審查
- 檢查安全性
- 確認錯誤處理
- 驗證測試覆蓋率

階段七：總結
- 記錄新增的端點
- 說明設計決策
- 建議後續測試

場景二：效能最佳化

使用者：使用者列表頁面載入太慢

階段一：理解問題
- 目前載入時間？
- 資料量多大？
- 效能目標？

階段二：分析程式碼
- 追蹤查詢執行
- 檢視資料獲取邏輯
- 識別瓶頸

階段三：澄清
- 是否可以使用快取？
- 是否需要即時資料？
- 分頁策略？

階段四：設計方案
- 方案 A：新增分頁
- 方案 B：實作虛擬滾動
- 方案 C：快取 + 分頁
- 推薦：方案 C

階段五：實作最佳化

階段六：審查和效能測試

階段七：總結改進成果

---

**記住**：這是一個指導性框架，不是嚴格的規則。根據專案需求和時間限制靈活調整各階段。重要的是在實作前充分理解需求和現有程式碼，以確保建構出正確且可維護的解決方案。