功能開發工作流程

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

核心理念

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

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

七個階段

階段一：發現與理解

目標：釐清需要建構什麼

關鍵問題：

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

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

---

階段二：程式碼庫探索

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

行動：

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

工具：使用 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

階段五：實作最佳化

階段六：審查和效能測試

階段七：總結改進成果

---

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