要用 AI 編寫用戶故事和驗收準則，應從已驗證的用戶證據開始，寫明角色和目標，把工作拆成可覆核的結果，再寫出獲授權人員能夠觀察和判斷的準則。AI 應揭示欠缺的假設和邊界情況，而不可虛構用戶需要、選擇實現細節或批准需求。

關鍵要點

每個故事都應追溯至已驗證的需要、問題、政策或營運限制。

圍繞用戶目標寫故事，而非圍繞指定功能或介面。

涵蓋正常、邊界、失敗、權限、無障礙、私隱和安全結果。

區分驗收準則、實現任務、測試個案和完成定義。

通用 AI 工作流程提供來源、覆核和審批控制。更廣泛的次序和責任分配可參閱用 AI 制訂項目計劃；用戶故事不是縮小版項目計劃。

用戶故事之前需要哪些證據？

收集能夠解釋用戶、問題、預期結果、限制和待解問題的證據。來源可以是已批准研究發現、支援服務模式、分析數據、政策要求、無障礙發現、事故報告或責任明確的業務規則。

建立證據包：

證據 ID	來源	已觀察需要或限制	人群/情境	信心	負責人
E-014	主持式研究發現	用戶不知道提交是否成功	首次申請人	中	研究負責人

把證據和方案分開。「用戶需要確認提交已收到」描述結果；「顯示五秒綠色提示」只是一項實現構想，不應預設為用戶需要。

不要向 AI 服務提供機密錄音、個人資料、安全細節或不受限制的內部文件。只使用已批准的最少片段和穩定證據 ID。

如何編寫以目標為本的用戶故事？

GOV.UK 指出，用戶故事應說明角色、用戶需要甚麼及目標，常用「作為……我需要/想要/期望……從而……」格式，並強調目標是最重要部分。［1］

生成文字前先填寫故事畫布：

欄位	問題
角色	誰真正經歷這項需要，而非虛構人物？
情境	需要在何時何地出現？
需要	用戶必須達成甚麼結果？
目標	該結果為何重要？
證據	哪些 ID 支持故事？
限制	有哪些政策、無障礙、私隱、安全或營運界線？
假設	甚麼尚未驗證？
批准人	誰擁有產品決定權？

然後讓 AI 提供備選方案：

從這份證據包起草三個用戶故事候選。每項都必須說明角色、需要和目標，引用支持證據 ID，避免介面和實現選擇，列出沒有證據的假設，並說明何時應拆分或拒絕故事。不要虛構用戶研究，也不要把持份者偏好當作用戶證據。

覆核角色是否真實相關、目標是否以結果為本，以及團隊能否在不預先指定方案的情況下討論故事。

如何拆分 epic 或過大的故事？

GOV.UK 把需時數星期以上的大型故事稱為 epic，並建議盡可能拆成可在一次迭代內完成的小故事。［1］不要只按數據庫、API 和介面等技術層拆分，否則每項故事可能都沒有獨立用戶價值。

有用的拆分維度包括：

不同的用戶目標或旅程階段；
正常路徑與可恢復的異常路徑；
讀取、建立與更改三類結果；
權限或角色類型；
先處理簡單情況，再處理複雜變化；
支援的渠道或政策司法管轄區；
先人工覆核，再安全地自動化。

每項受影響故事都要保留橫切限制。工作拆分後，私隱、無障礙或授權要求不可隨之消失。

怎樣的驗收準則可觀察？

驗收準則描述獲授權用戶、客戶或其他主體接受工作前必須符合的條件或結果。NASA 軟件工程指引強調定義和記錄驗收準則及條件；適用時可包括範圍、效能、可靠性、兼容性、數據等約定指標。［2］

從外向內編寫準則。優先描述可觀察結果、訊息、狀態轉換、匯出紀錄或可量化容差，不要寫內部類別、數據庫列或選用程式庫。

先使用普通清單：

準則 ID	情況	可觀察結果	證據來源	負責人
AC-01	有效提交	用戶取得唯一編號和明確下一步	E-014	產品負責人
AC-02	重複提交	用戶收到警告且已填資料不會遺失	E-021	產品負責人
AC-03	處理服務不可用	用戶取得可恢復的失敗路徑	營運政策 P-03	服務負責人

「建立端點」、「使用模態視窗」或「編寫單元測試」都不是合適的驗收準則；它們是實現或交付任務，不是用戶可觀察的驗收結果。

驗收準則應涵蓋哪些邊界情況？

讓 AI 按明確類別挑戰正常路徑：

邊界： 空白、最小、最大、過期、重複或罕見但有效的輸入。
失敗： 依賴不可用、逾時、請求被拒、部分完成或重試。
權限： 未登入、角色錯誤、擁有權改變或存取已撤銷。
無障礙： 鍵盤操作、焦點、狀態讀出、錯誤恢復和非視覺理解。
私隱： 數據最小化、可見範圍、保留、匯出和刪除界線。
安全： 未授權操作、不安全輸入、重播、速率限制及必要審核。
營運： 監察、支援交接、回滾和服務降級時的行為。

並非每項故事都需每個類別，但每類都應明確判定「已涵蓋」或「不適用」。團隊無權決定的領域應由相關負責人覆核。

NIST 的生成式 AI 風險框架提醒模型可能自信地生成錯誤內容，並強調評估、來源核實、人工監督和安全處理錯誤。［5］在責任團隊驗證證據和可行性前，AI 生成的準則只是候選。

何時使用 Given、When、Then？

具體例子有助建立共同理解時，可使用 Given/When/Then。Cucumber 把 Given 定義為初始情境，When 為事件或操作，Then 為預期可觀察結果，並建議結果應對用戶或外部系統可見，而非埋在系統內部的實現細節。［3］

例子：

Given 已登入申請人完成所有必填欄位 When 申請人提交一次 Then 服務顯示唯一編號和預期下一步

重複提交、斷線、授權改變和無效數據應各用獨立例子，不要把多個分支塞進一個長場景。場景是準則的例子，不會自動代表整套驗收準則。

驗收準則與任務、測試和完成定義有何分別？

產物	主要問題	範圍	負責人
用戶故事	用戶要達成甚麼、為甚麼？	一項連貫需要	產品團隊
驗收準則	哪些可觀察條件使故事可接受？	故事特定	產品及相關方
實現任務	團隊如何建立？	技術工作	交付團隊
測試個案	如何執行並比較具體行為？	驗證覆蓋	QA 和工程
完成定義	哪種共享質素狀態適用於增量？	產品或團隊層級	Scrum 團隊/機構

Scrum 指南把完成定義定義為增量達到產品質素措施時的正式狀態。［4］它比故事特定的驗收準則更廣泛並更可重用。故事即使符合功能準則，也可能因文件、安全覆核、整合或另一項共享質素要求未完成而不符合完成定義。

驗收測試亦不同於驗收準則：準則說明甚麼必須為真，測試和覆核活動則生成證明它為真的證據。NASA 將驗收測試描述為用於判斷系統是否符合驗收準則的正式測試。［2］

準則獲批後，可用AI 測試生成流程設計具體測試；需要可重複營運指引時，使用用 AI 建立 SOP 清單。

如何用 AI 編寫用戶故事和驗收準則並保留追溯？

建立需求追溯表：

故事/準則	證據 ID	限制 ID	測試或覆核證據	決定負責人	狀態
US-07 / AC-01	E-014	P-03	AT-114	產品負責人	已批准

每項準則都應有來源或明確負責人決定，每項高影響限制都應映射至一項或多項準則。準則日後應映射至測試或覆核證據，但起草時不可虛構尚不存在的證據。

視乎情況，與產品、設計、工程、QA、研究、無障礙、安全、私隱、法律或營運負責人共同覆核。提出以下問題：

用戶和目標是否有證據支持？
是否有準則其實是實現指示？
正常、邊界和失敗結果是否可觀察？
權限、無障礙、私隱和安全決定是否明確？
容差和例外是否可量化？
每一項是否都有負責批准的人？

最終決定使用保留人工審批的 AI 工作流程。AI 可以準備覆核包，不可批准自己生成的需求。

總結

從已驗證證據、限制、假設和負責人開始。
圍繞角色的需要和目標寫故事，而非指定介面。
盡可能沿獨立而有價值的結果拆分 epic。
定義可觀察的正常、邊界、失敗、權限、無障礙、私隱和安全結果。
Given/When/Then 是可選例子，不能取代思考。
把準則追溯至證據，並把人工審批與生成分開。

常見問題

AI 能從會議紀錄編寫用戶故事嗎？

它可以起草候選，但會議發言不會自動成為已驗證用戶需要。起草前要區分證據、持份者要求、假設和決定。

一項故事應有多少條驗收準則？

應足以定義有意義的正常、邊界和失敗結果，又不把故事變成規格堆疊。清單過長或混合多個目標時應拆分故事。

用戶故事必須使用「作為、我想、從而」格式嗎？

不必。格式很有用，但核心是角色、需要和目標。選擇團隊能一致覆核的格式。

必須用 Given/When/Then 寫準則嗎？

不必。很多故事用清晰清單更合適。具體場景能澄清情境、事件和預期結果時才使用。

驗收準則和測試個案相同嗎？

不同。準則定義接受前必須為真的條件；測試個案說明用於取得證據的輸入、操作、環境和比較。

完成定義是每項故事的一部分嗎？

共享完成定義適用於增量或產品質素狀態，驗收準則則針對具體故事。工作完成前可能兩者都須符合。

所有準則都可量化時，AI 能批准需求嗎？

不能。可量化不等於具有用戶價值、政策權限、可行性、安全性或機構批准，仍須由負責人員決定。

免責聲明：AI 生成的故事和準則只是草稿，不能取代獲授權的產品、工程、無障礙、安全、私隱、法律或營運審批。

來源：

GOV.UK Service Manual — Writing user stories — https://www.gov.uk/service-manual/agile-delivery/writing-user-stories
NASA Software Engineering Handbook — SWE-034 Acceptance Criteria — https://swehb.nasa.gov/spaces/7150/pages/16450634/SWE-034%2B-%2BAcceptance%2BCriteria
Cucumber — Gherkin Reference — https://cucumber.io/docs/gherkin/reference/
Scrum Guides — The Scrum Guide — https://scrumguides.org/scrum-guide.html
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

Sources checked 2026 年 8 月 30 日。

延伸閱讀：

如何用 AI 編寫用戶故事和驗收準則：涵蓋邊界情況並保留追溯