AI 寫 User Story 同 Acceptance Criteria：BA 嘅 5 步工作流
2026-08-10 · BA × AI 實戰 · Eric Cheung
點解 User Story 係 BA 嘅「每日功課」？
無論係 Agile 團隊定傳統瀑布式開發，BA 嘅核心工作都係同一件事：將持分者嘅模糊需求，變成開發團隊睇得明、測得到嘅規格。User Story 就係呢個轉換過程嘅基本單位——但寫好一條 User Story，絕對唔係「As a... I want...」三行字咁簡單。
現實係：BA 好多時要喺一日之內，由訪談筆記、會議錄音、ticket 評論同 email 鏈入面抽絲剝繭，整理出十幾條故事，仲要諗埋 acceptance criteria。呢啲時間本應花喺「問啱問題」同「同用戶確認假設」——偏偏大部分花咗喺「抄寫同組織」。以下呢套 5 步工作流，正正將後者交俾 AI。
快速結論（TL;DR）
- 用 AI 寫 User Story 嘅關鍵係「AI 做初稿、你做編輯」——唔係叫佢代筆，而係你負責判斷同對齊。
- 5 步工作流：收集原始材料 → 定義角色同目標 → 生成故事草稿 → 寫 Given/When/Then Acceptance Criteria → INVEST 驗證。
- 輸入質素決定輸出質素：訪談筆記同會議錄音餵得愈足，AI 寫出嚟嘅故事先愈貼地。
- Acceptance Criteria 要覆蓋正常路徑、邊緣情況、權限同錯誤處理四類情況，先可以直接變成測試用例。
- AI 生成嘅故事只係草案——INVEST 入面嘅「Negotiable」同「Valuable」永遠要靠你嘅業務判斷。
5 步工作流：由原始材料到 INVEST 驗證
Step 1 — 收集原始材料：將對話變成結構化輸入
AI 輸出嘅質素，直接取決於輸入。第一步唔係叫 AI「寫啲 user story 出嚟」，而係將你手頭嘅 raw 材料一次過餵晒俾佢：訪談筆記、會議錄音嘅轉錄文字、Jira/Linear ticket 評論、用戶 email、甚至舊系統嘅使用說明。叫 AI 先做「整理」而唔係「創作」——將材料入面所有角色、目標、痛點同業務規則抽晒出嚟。
以下係我哋對 XX 系統嘅訪談筆記、會議錄音轉錄同 ticket 評論。
請先做整理，唔好創作：
1. 列出所有出現嘅用戶角色（連同一句職責描述）
2. 列出每個角色嘅核心目標同痛點
3. 抽出所有業務規則、限制同例外情況
4. 標明任何資料來源唔一致嘅地方
--- raw 材料貼喺度 ---Step 2 — 定義角色同目標（Persona + Goal）
User Story 嘅「As a」唔可以求其。同一個功能，Front Desk 職員同 System Admin 睇嘅角度完全唔同——寫錯角色，成條故事嘅價值主張就會歪。喺生成故事之前，先叫 AI 由 Step 1 嘅材料歸納出角色清單，每個角色配一句目標陳述。呢一步做得好，之後每條故事嘅「So that」先會有意義。
根據以下角色清單同目標，幫每個角色寫一句清晰嘅 goal statement：
格式：作為〈角色〉，佢想〈目標〉，因為〈原因〉。
淨係輸出角色 + goal statement，唔好寫故事住。
--- 角色清單 ---
...Step 3 — 生成 User Story 草稿
依家有咗結構化材料同角色定義，就可以生成故事。秘訣係要佢輸出「故事 + 理由 + 假設」三件套：除咗 As a / I want / So that，仲要列出每條故事背後嘅假設——呢份假設清單就係你之後要同用戶逐條確認嘅問題清單，亦係防止 AI 亂作嘅最佳防線。
根據以下材料同角色定義，生成 user story 草稿。
每條故事輸出三部分：
1. As a / I want / So that（用返我哋團隊嘅格式）
2. 背後假設（至少 2 條）
3. 相關嘅業務規則
故事要細粒度——一條故事只做一件事。
--- 材料 ---
...（Step 1 整理結果）
--- 角色 ---
...（Step 2 結果）Step 4 — 用 Given/When/Then 生成 Acceptance Criteria
Acceptance criteria 係開發同測試之間嘅契約。叫 AI 為每條故事生成 Given/When/Then 格式嘅條件，重點係覆蓋四類情況：正常路徑、邊緣情況（空值、上限、重複提交）、權限限制、錯誤處理。一份寫得好嘅 criteria 應該可以直接變成測試用例——上星期篇測試自動化文章講嘅 AI 生成 test case 工作流，正正可以接落呢度。
為以下每條 user story 生成 Given/When/Then acceptance criteria。
要求：
- 覆蓋正常路徑、邊緣情況（空值/上限/重複提交）、權限、錯誤處理
- 每條 criteria 具體到可以直接變成測試步驟
- 唔好寫 UI 實現細節（例如按鈕顏色、元件名稱）
- 每條故事 5-8 條 criteria
--- User stories ---
...Step 5 — INVEST 驗證 + 團隊 Review
生成完唔好即刻貼上 Jira。用 INVEST 原則逐條檢查：Independent（可否獨立交付）、Negotiable（有冇留協商空間）、Valuable（對用戶有冇價值）、Estimable（團隊可否估算）、Small（夠唔夠細）、Testable（測唔測得到）。叫 AI 自己先做一輪 INVEST 自查，你再用人腦覆檢——AI 擅長捉「Testable」呢類結構問題，但「Negotiable」同「Valuable」永遠需要你嘅業務判斷。
用 INVEST 原則檢查以下 user stories，逐條評分：
Independent / Negotiable / Valuable / Estimable / Small / Testable
對每一條，指出邊個字母唔達標 + 具體點樣改。
最後 output 一個修正版。
--- User stories ---
...3 個常見陷阱
- 陷阱一：材料唔夠就開工。得一句「幫我寫 user story」得嚟嘅故事一定空泛。最少要餵角色背景加一個真實場景；如果真係冇 raw 材料，叫 AI 用問題反問你嚟補齊資料，唔好叫佢亂作。
- 陷阱二：Acceptance Criteria 過度規格化。AI 傾向將每條故事寫到「廚房洗碗盤」咁齊全，連 UI 字眼都寫埋入去。Criteria 應該描述行為同結果，唔係描述實現方法——留返空間俾團隊做 design。
- 陷阱三：跳過團隊 review。AI 生成嘅故事只係草案，佢唔知你團隊嘅技術債，亦唔知辦公室政治。User story workshop 嘅價值唔係「讀故事」，而係「傾故事」——AI 慳到你寫嘅時間，慳唔到對齊嘅時間。
總結
User Story 寫作係 BA 最高頻、最重複嘅工作之一，亦係最容易用 AI 提升效率嘅位置。呢套 5 步工作流嘅核心唔係「叫 AI 代筆」，而係「叫 AI 做初稿、你做編輯」：材料整理、角色歸納、故事起草、criteria 生成全部交俾 AI，你專注喺假設確認、INVEST 判斷同團隊對齊。試吓下個 sprint 用呢套流程——你會發現寫需求嘅時間縮短一半，而問問題嘅時間多咗一倍。後者，先係 BA 真正嘅價值。