Day 13 - 用 Claude Code 產生使用者故事與驗收標準

成功標準

你走進蛋糕店買草莓蛋糕，菜單寫著「鋪滿 5 顆大草莓與香草奶油」。蛋糕一拿出來，你瞄一眼就清楚店家有沒有做對。

軟體開發也是同一件事。使用者故事（User Story）是說明使用者拿到什麼好處的最小工作單位；驗收標準（Acceptance Criteria, AC）則是大家用肉眼在畫面上確認功能做好的依據。

核心概念拆解

三個核心概念

① 使用者故事（User Story）：像尋寶圖上的藏寶標記。精確定義：由角色、行動與價值三要素組成的工作單元，專注傳遞端到端的使用者價值。

② 驗收標準（Acceptance Criteria）：像終點線的計時感應器。精確定義：用 Given、When、Then 語法描述的驗收條件，定義系統在特定操作下的外部可觀察狀態。

③ 完整邊界情境（Boundary Scenarios）：像馬路邊緣的反光導引柱。精確定義：系統在正常操作、空資料以及連線異常等情境下的全部可對應狀態。

寫法方案與權衡

先建立團隊共識，再串接自動化規格。

① 清單式條列：簡單有效。快速記錄核心條件，速度極快，適合前期探索。

② Gherkin 語法撰寫：高效實用。用 Given、When、Then 規範嚴謹語意，能直接銜接自動化測試與跨職能驗收。

四個執行要點

① 鎖定單一價值：套用「身為某角色，我想執行某動作，以便獲得某成效」，專注解一個問題。

② 只寫看得到的現象：Then 專門描述螢幕畫面與系統回傳的變化，保留底層程式與資料庫的實作彈性。

③ 補齊完整情境：照順序補上成功流程、零資料狀態、載入失敗與重新嘗試。

④ 標註商業決策：碰上排序優先順序或複雜規則，直接標註【待確認】，交給產品負責人定奪。

結構化示範：FlowBoard 主故事與驗收情境

延續 FlowBoard 專案的核心探索，我們定義 US-01 故事卡：

US-01
身為首次進入工作區且正準備執行任務的新成員，
我想清楚看見第一個可執行的任務，
以便立即融入團隊展開工作。

依據規格展開三張情境驗收卡片：

① 正常情境卡片：具備指派任務的新成員

• 初始情境（Given）：新成員首次成功登入工作區，帳號具備至少一項進行中的指派任務。
• 觸發事件（When）：首頁載入完畢。
• 可觀察結果（Then）：畫面呈現引導提示，提供「查看第一項任務」的醒目按鈕；點選後立即開啟任務詳細內容。

② 空資料情境卡片：待分派任務的新成員

• 初始情境（Given）：新成員首次成功登入工作區，目前指派任務清單數量為零。
• 觸發事件（When）：首頁載入完畢。
• 可觀察結果（Then）：畫面呈現引導說明文字，同時提供聯繫工作區管理者的建議入口。

③ 異常情境卡片：任務讀取狀態異常

• 初始情境（Given）：符合引導資格的新成員登入工作區。
• 觸發事件（When）：系統回傳連線載入異常。
• 可觀察結果（Then）：畫面顯示連線重試提示訊息，並提供重新載入的點擊按鈕。

讓 AI 執行故事與驗收標準產出

角色：你是一位專業的需求工程助手，專注產出清晰明確的使用者故事與驗收標準。

輸入資料：
【貼上產品需求、使用者角色、目標、功能需求 ID、限制條件與待確認問題】

執行步驟：
① 提煉核心價值：每則故事只聚焦一項獨立的使用者價值，完整保留原始需求 ID。
② 展開完整情境：為每則故事依序建立正常成功、空資料、異常處理、權限限制與重試操作的驗收標準。
③ 採用 Given/When/Then 語法：Then 區塊必須精確描寫介面呈現或系統回傳的可觀察現象，保留系統底層實作空間。
④ 標註待決定規則：遇到需要商業判斷的邏輯時，標示【待確認】，並提出具體決策問題。

輸出格式：
故事 ID／對應需求 ID／使用者故事／驗收情境清單／待確認規則清單

範例輸出與核心價值

Feature: 新成員起始引導

Scenario: 具備指派任務的新成員
  Given 成員首次成功進入工作區
  And 成員帳號具備至少一項可檢視的指派任務
  When 工作區首頁載入完成
  Then 成員看見起始引導提示
  And 提示畫面具備「查看第一項任務」的主要行動按鈕
  When 成員點選主要行動按鈕
  Then 成員看見該任務的詳細內容頁面

Scenario: 零任務指派的新成員
  Given 成員首次成功進入工作區
  And 成員目前的指派任務數量為零
  When 工作區首頁載入完成
  Then 成員看見等待任務分派的說明內容
  And 成員看見聯繫管理者的指引

Scenario: 任務讀取異常與重試
  Given 符合資格的新成員進入工作區
  When 系統回傳載入異常狀態
  Then 成員看見載入提示文字
  And 畫面提供重新嘗試的操作選項

這項做法的核心價值在於提供一致客觀的驗證依據。工程夥伴能據此撰寫整合測試，測試團隊也能直接依據步驟驗證畫面，大幅降低溝通歧異。

人類需要檢查什麼

① 驗收條件描述的現象是否具備肉眼或介面直接觀察的特性？
② 正常操作、空資料狀態與異常重試動線是否皆具備合理的前進方向？
③ 核心商業邏輯（例如多任務時的排序優先權）是否由產品經理親自拍板確認？
④ 全團隊共同規範（例如系統資安標準）是否妥善收納於團隊完成準則（Definition of Done）？

把規則封裝成 Claude Code Skill

建立檔案路徑：

.claude/skills/acceptance-criteria/SKILL.md

設定 YAML 內容：

---
name: acceptance-criteria
description: 將產品需求轉換為使用者故事與具備 Given When Then 的可觀察驗收標準，完整收納各項邊界情境。
---

請依據需求內容，產出專注於單一使用者價值的故事。
驗收標準必須描寫使用者或外部系統可直接觀察的現象，保留底層資料庫實作空間。
依序涵蓋成功流程、零資料狀態、異常狀態、重新嘗試與權限確認等情境。
遇到需要團隊確認的規則時，維持標記並提出待確認問題。

在 Claude Code 中執行指令：

/acceptance-criteria 請讀取 PRD 的 US-01，產生故事、正常流程與例外驗收情境。

實際執行截圖說明：

執行完成後，同一個 US-01 會完整展開為包含成功、空資料與異常狀態的驗收情境，需要產品經理確認的規則也會清晰標註。

今天的產出物

今天完成 US-01 使用者故事與三組可觀察驗收情境卡片，並將「第一項任務排序」列入待確認項目。只要驗收標準能夠直接觀察，整個團隊就能在同一條準繩上踏實前進。

參考資料

• Agile Alliance：What are User Stories?
• Cucumber：Gherkin Reference