用 AI 寫敏捷使用者故事與驗收條件：從 Epic 切分到 Given-When-Then 的實戰教學

Sprint 規劃會議上最尷尬的一幕，往往是這樣：PO 唸完 backlog 裡的一條故事，工程師抬頭問「所以這到底要做什麼？」，設計師說「這跟我上週畫的流程不一樣吧」，然後整間會議室陷入十分鐘的即興討論。故事寫了，卻沒有把該講清楚的事講清楚——這是敏捷團隊最常見、也最耗成本的內傷。

一分鐘重點：使用者故事不是把需求換句話說，而是用「誰、想要什麼、為了什麼價值」逼出對話；驗收條件不是實作步驟，而是用「什麼前提、什麼事件、什麼反應」定義何時算做完。AI 在這件事上的價值，是把你腦中一段模糊的需求，在幾秒內轉成一批格式正確、符合 INVEST 的故事草稿，還順手附上 Given-When-Then 驗收條件——省下的是打字與格式的苦工，換來的是團隊能把時間花在真正該吵的地方：可行性、體驗與優先序。這篇會帶你走完整套流程，並附上一段可以直接複製的 Prompt。

適合誰讀：產品經理（PM）、產品負責人（PO）、Scrum Master，以及任何要把需求變成可開發任務的工程與設計團隊成員。就算你不是敏捷科班出身，也能照著做。

提醒：本文的 Prompt 與範例是教學示範，AI 產出的故事與驗收條件務必經過團隊 refinement 覆核。涉及商業優先序、上線承諾等決策，請由 PO 與工程負責人拍板，別直接照 AI 的排序開工。

先搞懂：使用者故事到底在解決什麼問題

很多團隊把使用者故事當成「比較短的需求規格」，這是根本的誤解。傳統需求規格書想做的事，是把系統該有的行為一次寫到滿、寫到死，讓團隊照著實作。但軟體開發的殘酷真相是：需求會變、你一開始也想不全、寫得再細工程師還是有疑問。

使用者故事的哲學剛好相反。它刻意寫得很短，短到你不可能靠它就開工——這是設計，不是偷懶。故事的真正目的，是當一張「我們得好好談這件事」的提醒卡。經典的定義是 3C：卡片（Card，簡短的故事本身）、對話（Conversation，開發前團隊一起釐清細節）、確認（Confirmation，也就是驗收條件）。三者缺一不可，缺了對話，故事就只是一張沒人看得懂的便利貼。

理解這點，你才會明白 AI 在這裡的角色：它能幫你把卡片和確認寫得又快又規範，但那場對話——工程師講出系統限制、設計師確認流程、PO 說明為什麼這件事現在最重要——是 AI 取代不了的。

As a… I want… so that… 為什麼是這個格式

使用者故事有個經典句型，別小看它，每一格都有作用：

As a 〔角色〕,
I want 〔想完成的事〕,
so that 〔想得到的價值/理由〕.

中文可以寫成「身為一個〔角色〕，我想要〔做某件事〕，以便〔獲得某個價值〕」。三段各自逼你回答一個常被跳過的問題：

As a（角色） 逼你講清楚「這是為誰做的」。是新註冊的訪客、還是已消費過的老會員？兩者要的東西天差地遠。角色寫得越具體，故事越不會做歪。

I want（想要什麼） 是使用者的意圖，注意是「意圖」不是「畫面」。寫「我想要一個下拉選單」是實作，寫「我想要篩選出我買得起的商品」才是意圖——把意圖留給故事，把選單留給設計去決定。

so that（為了什麼） 是最常被省略、卻最重要的一段。它逼你講出這件事的價值。當你發現某條故事的 so that 寫不出來，或寫出來很牽強，那通常是個訊號：這件事可能根本不該做，或優先序沒那麼高。so that 是你砍需求的最好武器。

INVEST：一條好故事的六個體檢項目

寫完故事不代表它是條好故事。敏捷圈用 INVEST 六個字母當品質檢查表，這也是最適合交給 AI 逐條驗的工作：

• I — Independent（獨立）：故事之間盡量不要互相卡死，能各自排程、各自上線。
• N — Negotiable（可協商）：故事描述的是「要什麼」，不是「一定要怎麼做」，實作細節留給團隊談。
• V — Valuable（有價值）：每條故事都要能交付一小片使用者或商業價值，而不是純技術任務。
• E — Estimable（可估算）：團隊有足夠資訊能對它的規模達成共識；估不出來通常代表太模糊或太大。
• S — Small（夠小）：小到一個 Sprint 內能舒服做完，最好一到三天。
• T — Testable（可測試）：有明確的驗收條件，能判斷何時算完成。

實務上最常爆掉的是 S 和 I：團隊習慣把一整個功能塞成一條故事，結果做不完也切不出價值。解法通常是「縱向切分」——這是下一段的重點。

切分 Epic：把大石頭敲成能搬的小石頭

史詩（Epic）是大到一個 Sprint 塞不下的大需求，例如「做一套會員點數系統」。它不是拿來開發的，是拿來切的。切分最常見的錯誤是「橫向切」——按技術層切成「做資料庫」「做後端 API」「做前端畫面」三條故事。這樣切的致命傷是：三條都做完你才生得出一丁點使用者價值，前兩條各自都不可交付、不可驗收，完全違反 INVEST 的 V。

正確的做法是縱向切分：沿著使用者流程或資料操作切，讓每條故事都是一小片「從頭到尾能動」的完整價值。以會員點數系統為例，可以切成：

• 會員消費後自動累點並看到點數餘額
• 會員在結帳時用點數折抵金額
• 會員查看自己的點數異動紀錄
• 點數在到期前寄出提醒通知
• 後台人員手動調整特定會員的點數

每一條都能單獨開發、單獨上線、單獨對使用者產生價值。這種切法還有個附帶好處：它天然幫你排出了優先序，你可以先上「累點與看餘額」驗證核心，再決定要不要做「到期提醒」。

Given-When-Then：把驗收條件寫成可測的行為

驗收條件（Acceptance Criteria）回答一個問題：這條故事怎樣才算「做完」？寫得好，QA 照著測、工程師心裡有底、上線爭議大減；寫得爛，就會變成上線後才在吵「這不是我要的」。

Given-When-Then 是最好用的格式，它來自行為驅動開發（BDD），三段對應得清清楚楚：

Given 〔某個前提/初始狀態〕
When 〔使用者做了某個動作/發生某個事件〕
Then 〔系統應該有的可觀察結果〕

以「用點數折抵金額」這條故事為例，一組完整的驗收條件會涵蓋正常、邊界與錯誤三種情境：

情境一（正常）
Given 會員帳戶有 500 點、購物車金額為 1000 元
When 會員在結帳頁選擇用 300 點折抵
Then 應付金額應顯示為 700 元，且點數餘額預扣為 200 點

情境二（邊界：點數不足）
Given 會員帳戶只有 100 點
When 會員嘗試折抵 300 點
Then 系統應阻止並提示「可用點數不足，最多可折抵 100 點」

情境三（錯誤：訂單取消）
Given 會員已用 300 點完成下單但尚未出貨
When 會員取消該筆訂單
Then 已折抵的 300 點應於 24 小時內全額退回會員帳戶

關鍵原則：Then 描述的是「系統可觀察的行為與結果」，不是「怎麼實作」。寫「應付金額顯示 700 元」是行為，寫「呼叫 discount_service 更新 order.total 欄位」是實作——後者不該出現在驗收條件裡，那是工程師的自由，你越界寫死了，反而綁住團隊、也讓非工程角色看不懂。

台灣情境案例：怡君怎麼把「會員點數系統」變成能開發的 backlog

怡君是一家台灣美妝電商新創的 PM，團隊只有四個工程師加一位設計。某天週會，創辦人丟下一句：「我們也來做個會員點數系統吧，留住回購的客人。」——這句話就是一個典型的、大到沒法開發的 Epic。

過去怡君會自己關在會議室兩小時，硬把需求寫成一份 Word 規格，結果 Sprint 規劃時工程師照樣問東問西。這次她改用 AI 輔助。她先花十分鐘寫清楚三件事：商業目標（提升 90 天回購率）、目標使用者（過去半年消費過一次以上的會員）、成功指標（點數功能上線後回購率提升 5%）。然後她把這段脈絡連同創辦人那句話，一起丟給 AI，套用下一段的 Prompt。

AI 幾秒內產出七條縱向切分的故事，每條都有 As a I want so that 格式與 Given-When-Then 驗收條件。怡君沒有照單全收——她做的是刪與改：砍掉一條「會員可將點數轉贈好友」（so that 講不出這一季的價值，優先序太低），把「查看點數異動紀錄」標為第二批。接著她把剩下五條帶進 refinement 會議。

會議上真正的價值才浮現：資深工程師阿哲指出「消費後自動累點」牽涉到既有金流回呼的時序問題，這條的複雜度比 AI 估的高，撲克估點時大家從 3 點討論到 8 點；設計師則發現 AI 寫的折抵情境沒考慮到「部分商品不適用點數」的規則，補了一條驗收條件。一小時後，怡君手上是一批工程認可、設計對齊、PO 排好序、可以直接進 Sprint 的故事。她省下的不是思考，而是打字和格式；換來的是把團隊的腦力集中在只有人能判斷的地方。

可直接複製的 Prompt：一次把模糊需求拆成 INVEST 故事＋驗收條件

把下面這段複製到你慣用的 AI 工具，替換〔 〕裡的變數即可。它會一次完成收斂 Epic、縱向切分、INVEST 檢查與 Given-When-Then 驗收條件：

# 角色
你是一位資深敏捷產品教練，同時具備 PO 與資深工程師的視角。
你擅長把模糊的商業需求拆成符合 INVEST 原則的使用者故事，並寫出可測試的驗收條件。

# 背景資訊
- 產品／功能：〔產品/功能，例如：美妝電商的會員點數系統〕
- 目標使用者：〔目標使用者，例如：過去半年消費過一次以上的會員〕
- 商業目標：〔商業目標，例如：90 天內回購率提升 5%〕
- 團隊已知限制：〔技術債、法規、既有系統等限制，若無可填「暫無」〕
- 一個 Sprint 長度：〔例如：兩週〕

# 原始需求（可能很模糊，請幫我釐清）
〔在此貼上老闆或客戶那句話，例如：做一個會員點數系統留住回購客人〕

# 任務，請依序完成
1. 先把上面的原始需求收斂成 1～2 個史詩（Epic），並用一句話界定各 Epic 的範圍與「這次不做什麼」。
2. 針對每個 Epic，用「縱向切分」（沿使用者流程／資料操作，而非技術層）拆成多條使用者故事。
3. 每條故事都用這個格式：
   身為一個〔角色〕，我想要〔做某件事〕，以便〔獲得某個價值〕。
4. 逐條用 INVEST 六原則自我檢查，若某條不合格（尤其是太大或無價值），請直接改寫或再切分，並簡短說明理由。
5. 為每條故事寫 2～4 組 Given-When-Then 驗收條件，務必涵蓋正常路徑、邊界情境與錯誤情境。
   Then 只描述「系統可觀察的行為與結果」，不要寫任何實作細節或技術欄位。
6. 為每條故事標一個粗略的相對規模參考（S／M／L）當估點討論的起點，並註明「最終點數需由團隊估算」。

# 輸出格式
用 Markdown。每個 Epic 一個標題，底下條列故事；每條故事附驗收條件與規模參考。
用繁體中文與台灣軟體業慣用語。

小技巧：如果第一輪產出的故事偏大，直接回一句「請把第 X 條再縱向切分成 2～3 條更小的故事」，AI 會沿著同樣的原則往下切。

常見錯誤：這幾種寫法會讓故事白寫

• 把驗收條件寫成實作步驟。「呼叫 API、更新資料表、刷新畫面」不是驗收條件，那是工作日誌。驗收條件只回答「系統對外表現出什麼行為」，把怎麼做的自由留給工程師。
• so that 用萬用句敷衍。一堆故事的結尾都寫「以便提升使用者體驗」，等於沒寫。講不出具體價值的故事，多半是優先序有問題，該被質疑而不是被美化。
• 橫向切分 Epic。按「後端一條、前端一條」切故事，每條都不可獨立交付，Sprint 結束時生不出可展示的價值，這是新手最痛的坑。
• 故事塞太大還硬進 Sprint。一條故事佔掉整個 Sprint，通常代表它是偽裝的 Epic。做不完會拖垮團隊士氣與速度可預測性。
• 跳過對話，把故事當規格照做。故事寫得再漂亮，少了開發前那場 refinement 對話，工程師還是會做出你沒想到的版本。故事是對話的起點，不是終點。
• 讓 AI 決定優先序就開工。AI 不知道你這一季的策略重心、也不知道哪個客戶在催，它排的順序只能參考。

AI 幫不上的地方：清楚劃出這條界線

用 AI 寫故事很爽，但你得知道它的天花板在哪，否則會把「初稿」當「定稿」誤事。

商業優先序，AI 決定不了。哪條故事先做、哪條這季不做，取決於公司策略、市場時機、關鍵客戶的壓力——這些脈絡多半不在 AI 手上，也不該交給它拍板。AI 能幫你把選項列清楚，但按下排序鍵的必須是 PO。

技術可行性與隱藏成本，要靠工程師。AI 估的規模是紙上談兵，它不知道你們某個十年老系統改一個欄位要動半天、也不知道那個第三方金流回呼有多不穩。像怡君案例裡「自動累點」的時序問題，只有動手的人才看得出來。

體驗與流程細節，要靠設計對齊。AI 生的驗收條件常常漏掉真實使用情境的分支（例如部分商品不適用點數）。設計師與實際跑過流程的人，才補得齊這些人味。

那場「對話」本身，AI 無法代勞。使用者故事方法論的核心是團隊一起釐清共識。AI 給你的是更好的討論素材，不是替你省掉討論。把省下來的打字時間，拿去把對話談得更深，才是正確用法。

一句話總結界線：AI 負責把需求寫得規範又快，人負責判斷這件事該不該做、能不能做、怎麼做才對。

下一步：把整套產品流程都系統化

寫好使用者故事只是產品開發的其中一環。當你的 backlog 變得清晰，接下來要面對的是進度怎麼管、產品怎麼上市、團隊目標怎麼對齊。這些在 AgentAI 智庫都有成套的實戰教學可以接著看：把故事排進時程、控管風險，讀 用 AI 做專案管理；功能做完準備推向市場，讀 用 AI 規劃產品上市；想讓團隊的每條故事都對準大目標，讀 用 AI 設定 OKR 與 KPI；需要把 API 與系統行為寫成文件，讀 用 AI 寫技術文件。

想找更多能直接套用的 AI 做法，AgentAI 智庫還備有大量可複製的 AI 工作流 與 實戰食譜，把你每天的重複工作一個一個變成系統。從今天這條故事開始，讓需求不再卡在「這到底要做什麼」。

常見問題 FAQ

延伸閱讀

• 用 AI 做專案管理
• 用 AI 規劃產品上市
• 用 AI 設定 OKR 與 KPI
• 用 AI 寫技術文件