寫 AC(驗收條件)是 user story 最常被跳過的一步:寫得好花時間,寫得爛只是把模糊丟給下游。AI 出現後,業界玩出五種路線,取捨很不一樣。
方法一:通用 AI + Prompt 模板
把背景、需求、澄清結果塞進結構化 prompt,要求輸出固定格式的 story 與 4–7 條 Given/When/Then。Mike Cohn 建議把「加 AC」當獨立步驟,先用簡單條列方便跟使用者 review,確認後再轉 Gherkin。
Prompt 範例:
你是資深 BA。根據以下資訊為這個 story 產生 AC:【產品背景】B2B 訂單系統,客戶分月結與現金兩種【Story】As a 業務,I want 修改已成立的訂單,so that 客戶追加需求時不用重下單【已知規則】月結客戶鎖帳期間不能改訂單【澄清問答】Q: 出貨後可以改嗎? A: 不行要求:1. 先用簡單條列列出 AC(3–7 條),涵蓋正常、異常、邊界情境2. 每條都要可測試,避免「操作要順暢」這種寫法3. 先不要用 Gherkin,等我確認後再轉
優點:零成本、彈性最高。 缺點:品質取決於你餵的脈絡——你要先想清楚,才問得出好問題。
方法二:專案管理工具內建 AI
Jira、Miro、StoriesOnBoard 直接在卡片上加 AI 按鈕,一鍵產出十幾條 AC,還能持續追加。
怎麼做:這類工具通常不用寫 prompt,選卡片、按 AI 按鈕即可。要提升品質,關鍵是去改工具的「AC 模板設定」,例如:
產生 AC 時遵守:格式用 Given/When/Then;最多 5 條;必須包含至少 1 條異常情境;禁止出現「使用者體驗良好」等不可測試的描述。
優點:嵌在流程裡,摩擦最低。 缺點:AI 只看得到卡片那幾行字,產出多是通用條款;「一鍵追加」鼓勵堆量而非收斂。
方法三:專用 AC 產生器
強制場景結構:happy path、異常情境、邊界條件三類產出,有些還附 Gherkin 與 Definition of Done。
Prompt 範例(沒有專用工具,用一般 AI 也能模仿這個結構):
為以下 story 產生 AC,分三組輸出:A. Happy path(主要成功流程)B. Negative(輸入錯誤、權限不足、系統失敗)C. Edge cases(邊界值、極端數量、時間邊界)每組 2–3 條,Given/When/Then 格式。【Story】(貼上你的 story)
優點:這就是測試設計基本功,能系統性補上人最常漏的 edge cases。 缺點:AI 補的是「這類功能通常要注意什麼」,不是你的業務規則。它知道登入要防密碼錯誤,不知道「月結客戶鎖帳期間不能改訂單」。
方法四:Context-aware 工具
產生 AC 時去撈會議逐字稿、Slack、既有 tickets,反映團隊實際討論過的內容——直攻前三種方法的死穴:關鍵脈絡往往在 prompt 之外。
Prompt 範例(買不起工具的土炮版:自己把脈絡餵進去):
以下是這個 story 的相關脈絡,請「只根據這些內容」產生 AC,不要自行補充通用規則;脈絡中有提到但互相矛盾之處,請列出來問我。【Refinement 會議記錄】(貼上)【Slack 討論串】(貼上)【相關舊 ticket】(貼上)【Story】(貼上)
優點:解決 garbage-in-garbage-out 的根本問題。 缺點:導入成本高、隱私敏感;團隊可能覺得「反正 AI 會撈」,反而弱化當場講清楚的對話品質。
方法五:AC 作為 AI Agent 的可執行規格
AI coding agent 工作時,第一步就是讀 AC 理解「done」的定義,並且「字面上地」執行;也有工具從 AC 直接長出可執行的 Gherkin 測試。
Prompt 範例(以 Claude Code 這類 coding agent 為例):
請閱讀 stories/order-edit.md 中的 story 與 AC。1. 先把每條 AC 轉成可執行的 Gherkin 測試(先不寫實作)2. 列出 AC 中模糊、無法直接轉成測試的地方,停下來問我,不要自行假設3. 我確認後,再依測試實作功能,以全部測試通過為 done 的標準
注意第 2 點:強迫 agent「先問再做」,就是在防它字面執行時自行腦補。
優點:「AC 要可測試」從 best practice 變成硬需求,回饋立即。 缺點:模糊之處 agent 不會問你,而是自行腦補;錯誤被自動化放大,不是被攔截。
成效如何?數據怎麼說
2025–2026 的實證研究給了幾個參考點。芬蘭學者用 107 條需求測試 LLM 產生 Gherkin AC:格式正確率近乎 100%,語意上的需求涵蓋率約 93–94%;若先按 epic 組織脈絡再生成,專家評分明顯更高——正確性 4.61 vs 4.14、完整性 4.31 vs 3.50(滿分 5)。另一份研究比較 LLM 與人:LLM 產出對標準答案的涵蓋率約 96%,學生只有 53%。企業場域的研究則發現,加上 RAG(撈內部文件)與獎勵模型迭代修正後,AC 的正確性與對齊度顯著提升——呼應方法四的方向。
但這些數字要小心解讀。所謂「涵蓋率 93%」,意思是:需求文件裡寫了 100 條,AI 產的 AC 能對應到其中 93 條。換句話說,它量的是「寫下來的需求,AI 漏掉幾條」。可是實務上最痛的,往往是根本沒被寫下來的規則——只存在老鳥腦中的業務眉角、會議上講過但沒記錄的例外情況。這些東西不在考卷上,AI 答不到,涵蓋率也量不到。所以涵蓋率高,不等於 AC 完整。另外,多份研究的共同結論是人工驗證仍不可省,需求越複雜,AI 的判斷越不可靠。
至於業界偏好,先講有數據的部分:2025–2026 的調查顯示,產品團隊用 AI 已是常態——一份調查中受訪團隊 100% 都在用 AI、96% 穩定使用;另一份 1,200 位 PM 的調查則顯示 73% 每週使用,最大宗用途就是撰寫 PRD 與需求文件(68%),而被建議優先學習的技能正是 prompt engineering。不過要老實說:「哪種方法產 AC」目前沒有嚴謹的採用率調查。從工具市場與教學內容的分佈推論,通用 AI 加 prompt(方法一)仍是主要入口,工具內建 AI(方法二)隨 Jira 等平台快速普及;方法四、五則還在爬坡初期——Gartner 預估企業應用內建 AI agent 的比例,會從 2025 年的不到 5% 成長到 2026 年底的 40%。
三個共同的坑
一、AC 從對話的產物變成文件的產物。 一鍵生成讓 PO 跳過三劍客會議,直接把十條 AC 丟進 sprint——形式完備,共識為零。
二、流暢掩蓋盲區。 AI 的 AC 讀起來專業,但只有通用知識沒有你的領域規則;看起來越完整,review 越鬆懈。
三、量的膨脹。 一個 story 的 AC 建議 3–7 條,再多就該拆 story;但 AI 習慣多多益善,跟拆小 story 的紀律對著幹。
結語:打字機,還是對話夥伴?
這五種方法的演進,其實正一步步逼近敏捷社群講了十幾年的東西:關鍵範例、共同理解、活文件——這不就是 Specification by Example 嗎?
如果你的團隊還停在方法一、二,把 AI 當「更快寫文件的打字機」,那就可惜了。AI 真正的潛力,是當「澄清需求的對話夥伴」:問出你沒想到的問題、舉出你沒考慮的例子。
AC 的價值不在那份文件,而在產出它的那場對話。 AI 可以加速對話,也可以取代對話——選哪條路,是你的決定,不是工具的。
發表迴響