昨天我們完成了 PRD 文件產出和技術初步規劃，今天要進入 AI-DLC Sprint 最關鍵的階段：User Story & AC。這一步決定了開發的節奏和品質，因為它把「要做什麼」和「怎麼驗證」都定義清楚了。

為什麼 User Story 這麼重要？

很多人（包括以前的我）覺得 User Story 就是「把 PRD 切小塊」而已，但實際上它的價值遠不止此：

傳統的 Story 拆解：靠經驗和直覺，容易拆得太大或太小
AI-DLC Sprint 的 Story：精準拆解 + 自動生成 AC + 智能估點

而且，好的 User Story 會遵循 INVEST 原則：

• Independent：獨立的，不依賴其他 Story
• Negotiable：可協商的，不是固定的實作方式
• Valuable：有價值的，給使用者帶來好處
• Estimable：可估算的，團隊能估工時
• Small：小而美，一個 Sprint 內可完成
• Testable：可測試的，有明確的驗收條件

讓 AI 扮演 Scrum Master

這次我們要再創造一個新的 AI 同事：Scrum Master。他的任務是把 PRD 拆解成一個個可執行的 User Story。

建立 Scrum Master Agent

在 Claude Code 中創建一個新的 Subagent：

Subagent 配置

name: "Agile Scrum Master"
role: "User Story 拆解專家"

responsibilities:
  - 將 PRD 拆解成符合 INVEST 原則的 User Story
  - 為每個 Story 生成 Acceptance Criteria
  - 估算 Story Points
  - 識別 Story 之間的相依性

principles:
  - 遵循 INVEST 原則
  - 使用 "As a [role], I want [feature], So that [benefit]" 格式
  - AC 使用 Given-When-Then 格式
  - Story Point 使用費氏數列 (1, 2, 3, 5, 8)

讓 AI Scrum Master 拆解 Story

@"agent-tpm-product-manager" 讀取 @docs/PRD.md 

請幫我將 PRD 中的 MVP 功能拆解成 User Stories，
並為每個 Story 撰寫 Acceptance Criteria。

要求：
1. 每個 Story 必須遵循 INVEST 原則
2. 使用標準的 User Story 格式
3. AC 使用 Given-When-Then 格式 (TDD)
4. 每個 Story 給一個 Story Point
5. 輸出為 Markdown 格式，儲存到 docs/user-stories.md

AI 同事生成的 User Stories

讓我分享 AI 生成的幾個精彩 Story：

Story 1：快速記錄心情

## US-001: 快速記錄心情

**As a** 想要記錄情緒的使用者
**I want** 用一句話快速記錄今天的心情
**So that** 我不需要花太多時間就能完成記錄

### Acceptance Criteria

**AC1: 成功輸入心情**
- **Given** 我打開 MoodStamp App
- **When** 我在輸入框輸入「今天完成報告，很有成就感」
- **Then** 輸入框應顯示我輸入的文字
- **And** 字數計數器應顯示當前字數

**AC2: 字數限制**
- **Given** 我在輸入框中
- **When** 我輸入超過 200 字
- **Then** 系統應阻止繼續輸入
- **And** 顯示提示「已達字數上限」

**AC3: 空內容驗證**
- **Given** 我打開記錄頁面
- **When** 我不輸入任何文字就按下送出
- **Then** 系統應顯示錯誤訊息「請輸入心情內容」
- **And** 不應儲存任何資料

### Story Points: 3

### 相依性
- 無（這是基礎功能）

### 技術考量
- 需要建立 MoodEntry Model
- 需要設計輸入驗證邏輯
- 需要測試各種邊界情況

Story 2：選擇心情印章

## US-002: 選擇心情印章

**As a** 記錄心情的使用者
**I want** 選擇一個 emoji 代表今天的心情
**So that** 我可以快速視覺化我的情緒狀態

### Acceptance Criteria

**AC1: 顯示印章選擇器**
- **Given** 我完成心情輸入
- **When** 頁面顯示印章選擇器
- **Then** 應顯示 10 個預設 emoji（😊😢😡😐🥰😥😎🤔😴🤩）
- **And** 每個 emoji 應清晰可點

**AC2: 選擇印章**
- **Given** 印章選擇器已顯示
- **When** 我點擊任何一個 emoji
- **Then** 該 emoji 應有視覺回饋（例如放大動畫）
- **And** 其他 emoji 應回復成未選中狀態

**AC3: 必須選擇印章**
- **Given** 我已輸入心情內容
- **When** 我沒有選擇印章就按下送出
- **Then** 系統應顯示提示「請選擇一個印章」
- **And** 不應儲存資料

### Story Points: 3

### 相依性
- 依賴 US-001（需要先有心情輸入）

### 技術考量
- 需要設計 Stamp Selector 組件
- 需要處理狀態管理（哪個印章被選中）
- 需要添加選中動畫效果

Story 3：儲存心情記錄

## US-003: 儲存心情記錄

**As a** 使用者
**I want** 儲存我的心情記錄到本地
**So that** 我下次打開 App 時還能看到我之前的記錄

### Acceptance Criteria

**AC1: 成功儲存**
- **Given** 我已輸入心情並選擇印章
- **When** 我按下「完成」按鈕
- **Then** 系統應將資料儲存到 Hive 資料庫
- **And** 顯示「儲存成功」的提示
- **And** 自動跳轉到日曆視圖頁面

**AC2: 資料格式正確**
- **Given** 使用者完成記錄
- **When** 系統儲存資料
- **Then** 資料應包含：id、content、stamp、date、aiResponse
- **And** id 應為 UUID 格式
- **And** date 應為當前時間

**AC3: 儲存失敗處理**
- **Given** 使用者按下完成
- **When** 儲存失敗（例如儲存空間不足）
- **Then** 系統應顯示友善的錯誤訊息
- **And** 保留使用者輸入的內容，不清空
- **And** 允許使用者重試

### Story Points: 5

### 相依性
- 依賴 US-001 和 US-002

### 技術考量
- 需要建立 Hive 資料庫
- 需要寫 MoodEntry Model 的 TypeAdapter
- 需要實作 Repository Pattern
- 需要測試儲存和讀取功能

AI 生成的亮點

1. AC 寫得超細致

AI 不只是列出「功能要可以用」，而是考慮到：

• 正常流程：Happy Path
• 錯誤處理：空內容、超過限制、儲存失敗
• 邊界情況：200 字限制、未選擇印章
• 使用者體驗：視覺回饋、友善的錯誤訊息

2. Story Points 很合理

AI 的估點考慮到：

• 技術複雜度：需要建立多少組件？
• 相依性：是否依賴其他 Story？
• 不確定性：有多少未知的部分？

例如：

• US-001（輸入框）= 3 點：簡單但需要驗證
• US-003（儲存）= 5 點：需要建立 Hive + Repository
• US-005（AI 語錄）= 8 點：需要整合外部 API

3. 相依性識別

AI 自動識別出 Story 之間的相依性：

• US-002 依賴 US-001（先有輸入，才能選印章）
• US-003 依賴 US-001 + US-002（需要先有內容和印章）
• US-004 依賴 US-003（需要先有資料才能顯示）

這讓我們知道開發的順序～

讓 AI 扮演 QA Engineer

現在我們要再創造第三個 AI 同事：QA Engineer。他的任務是檢查 Story 和 AC，確保測試覆蓋率。

建立 QA Engineer Agent

Subagent 配置

name: "Quality Assurance Engineer"
role: "測試策略專家"

responsibilities:
  - 檢查 User Story 的可測試性
  - 補充遺漏的測試場景
  - 識別 Edge Cases
  - 生成測試計畫

principles:
  - 每個 AC 都要可測試
  - 考慮正常流程、異常流程、邊界情況
  - 使用 Given-When-Then 格式
  - 測試應覆蓋所有重要路徑

讓 QA Engineer 審查 Story

我的 Prompt

@"agent-Quality Assurance Engineer" 讀取 @docs/[user-stories.md](http://user-stories.md)

請審查這些 User Stories，並：
1. 檢查每個 AC 是否可測試
2. 識別遺漏的測試場景
3. 補充 Edge Cases
4. 生成測試計畫

輸出格式：
- 審查意見
- 補充建議
- 測試計畫

儲存到 docs/[test-plan.md](http://test-plan.md)

QA Engineer 的審查結果

審查意見範例

## US-001 審查意見

### ✅ 已覆蓋的場景
- 正常輸入流程
- 空內容驗證
- 字數限制

### ⚠️ 遺漏的測試場景

**1. 特殊字元處理**
- 輸入 emoji 是否正常顯示？
- 輸入換行符是否正常處理？
- 輸入 HTML/JavaScript 是否會被轉義？

**2. 性能測試**
- 快速連續輸入 200 字是否會lag？
- 輸入框是否有 debounce 機制？

**3. 邊界情況**
- 輸入恰好 200 字時的處理
- 輸入空白字元（space/tab）的處理
- 複製貼上超過 200 字的處理

### ⭐ 建議補充的 AC

**AC4: 特殊字元處理**
- **Given** 我在輸入框中
- **When** 我輸入 emoji 或換行符
- **Then** 系統應正常顯示這些字元
- **And** 字數計數器應正確計算

**AC5: 複製貼上處理**
- **Given** 我複製了超過 200 字的內容
- **When** 我貼上到輸入框
- **Then** 系統應只保留前 200 字
- **And** 顯示提示「內容已被截斷至 200 字」

測試計畫範例

## MoodStamp 測試策略

### 測試分層

**Unit Tests (70%)**
- MoodEntry Model 測試
- Repository 測試
- Validator 測試
- OpenAI Service Mock 測試

**Widget Tests (20%)**
- 輸入框 Widget
- 印章選擇器 Widget
- 日曆視圖 Widget

**Integration Tests (10%)**
- 完整的記錄流程
- 儲存 → 讀取 → 顯示
- AI 語錄生成流程

### 測試優先級

**P0 - 高風險区域**
- 資料儲存功能（不能遺失數據）
- 輸入驗證（防止無效數據）

**P1 - 中風險区域**
- UI 互動流程
- AI API 整合

**P2 - 低風險区域**
- 動畫效果
- 美化細節

### TDD 開發順序

1. **Day 3**: 寫 MoodEntry Model 的測試
2. **Day 4**: 寫 Repository 的測試
3. **Day 4**: 寫輸入驗證的測試
4. **Day 5**: 寫 Widget 的測試
5. **Day 6**: 寫 Integration Tests

結論

User Story 不是任務清單，是導航地圖

今天最大的心得是：
User Story 不是把 PRD 切小塊，而是把「要做什麼」和「怎麼驗證」都定義清楚。

AI 在 Story 拆解的價值：

1. INVEST 原則檢查：自動確保 Story 品質
2. AC 自動生成：考慮到所有測試場景
3. Edge Case 識別：想到你想不到的情況
4. 測試計畫生成：明確的 TDD 順序

AI 說的一句話我很認同：

「好的 AC 不是寫得多詳細，而是寫得多明確。明確的 AC 讓測試人員、開發人員、PM 都知道什麼叫「完成」。」