在 GenAI 工具逐漸進入產品與開發流程的時代，團隊們越來越希望能用 AI 協助撰寫「驗收條件」，來提升需求溝通效率與落地速度。

不過，若只是丟一段需求給 AI，常常會出現「看起來像驗收條件、實際卻無法驗收」的情況，導致開發不清楚標準、測試不知道怎麼驗證、產品又覺得不夠完整。

這時候，設計好的 Prompt 就變得至關重要——你提供 AI 的格式、語氣與重點，就決定它產出的條件是否有用。

本文整理了四種在實務中效果良好、容易導入的 Prompt 格式，每一種都搭配了：

• 清楚的語法格式
• 一般範例與說明
• 對應「台灣高鐵訂票系統」的實戰範例

格式 1：使用者故事轉換格式（User Story → Gherkin）

(1) Prompt Format：
根據以下使用者故事，請產出 3~5 個驗收條件，使用 Given-When-Then 格式。

(2) 範例：
根據以下使用者故事，請產出 3~5 個驗收條件，使用 Given-When-Then 格式。
這是要針對台灣高體訂票系統: https://irs.thsrc.com.tw/IMINT/?locale=tw 的用戶故事
使用者故事：
作為一般旅客
我想要可以查詢今天從台北到台中的車次
這樣我可以安排出發時間

GenAI：
a. 可查詢今日的台北→台中車次
Given 使用者開啟高鐵訂票首頁，
When 選擇「起站」為台北、「訖站」為台中，並選擇今天的日期，
Then 系統應顯示從台北到台中的所有可搭乘車次與出發時間。

b. 查詢條件為必填欄位
Given 使用者未填寫起站、訖站或乘車日期，
When 嘗試點擊「查詢」按鈕，
Then 系統應阻止查詢並顯示必要欄位的錯誤提示（例如「請選擇乘車日期」）。

c. 查詢結果排序正確
Given 使用者查詢今日從台北到台中的車次，
When 查詢結果顯示於畫面上，
Then 所有車次應依照「出發時間」由早到晚排序。

d. 查無班次時顯示提示
Given 使用者選擇查詢條件為「台北→台中」但當天班次已全部結束，
When 點擊查詢，
Then 系統應顯示「查無可搭乘車次」的提示訊息。

e. 車次顯示必要資訊
Given 使用者成功查詢出車次列表，
When 車次結果顯示時，
Then 每筆車次應顯示出發與抵達時間、車種、票價、是否可訂票等資訊。

(3) 好處：

• 格式結構明確，利於後續自動化
• 符合 BDD/SBE 工具習慣

(4) 適用時機：

• 需求明確採 User Story 描述
• 需要與開發／測試進行對齊、實作自動化前置準備時

格式2：任務流程分解格式（Task Flow Breakdown）

(1) Prompt Format：
根據下列任務流程，請逐步產出每個步驟的驗收條件，每步驟至少 1–2 點。

(2) 範例：
根據下列任務流程，請逐步產出每個步驟的驗收條件，每步驟至少 1–2 點。
這是台灣高鐵訂票系統的任務流程，任務流程：訂票→ 付款完成→ 取票→ 產生收據

GenAI：
a. 訂票
Given 使用者已查詢車次並選擇搭乘時間與座位，
When 點選「下一步」進入訂單確認頁，
Then 系統應顯示完整的車次資訊、票價、座位與乘客資料確認欄位。

Given 使用者欲完成訂票但未填寫必填資料（如聯絡電話），
When 點擊「確認訂票」，
Then 系統應提示「請填寫完整資料」並阻止提交。

b. 付款完成
Given 使用者選擇付款方式（如信用卡、LINE Pay），
When 輸入正確付款資料並提交，
Then 系統應處理交易，並顯示「付款成功」頁面與訂單編號。

Given 使用者付款失敗（如卡號錯誤或網路中斷），
When 提交付款後系統無回應，
Then 系統應提示「付款失敗」並提供重新付款選項。

c. 取票
Given 使用者付款成功並獲得訂票編號，
When 前往自動售票機或使用「手機取票條碼」，
Then 系統應正確讀取資料並列印紙本車票或出示電子票證 QR Code。

Given 使用者已過取票期限或訂單已取消，
When 嘗試取票，
Then 系統應提示「此訂票已失效，無法取票」。

d. 產生收據
Given 使用者已完成付款並成功取票，
When 點選「列印收據」或請求電子發票，
Then 系統應產出包含金額、乘車資訊與發票號碼的收據畫面或 PDF 檔。

Given 使用者付款過程中取消交易或未成功，
When 嘗試列印收據，
Then 系統應顯示「尚未完成付款，無法產出收據」。

(3) 好處：

• 結構化思考，易於對應流程圖或 UI 流程
• 減少漏寫步驟

(4) 適用時機：

• 使用者流程清楚（如訂票、報名、購物）
• 想從任務切割角度檢查完整性

格式3：角色視角區分格式（Role-Based Perspective）

(1) Prompt Format：
根據以下功能，請從不同角色（一般使用者 / 系統 / 管理員）列出各自的驗收條件。

(2) 範例：
根據以下功能，請從不同角色（一般使用者 / 系統 / 管理員）列出各自的驗收條件。 這是要針對台灣高體訂票系統: https://irs.thsrc.com.tw/IMINT/?locale=tw 的 "訂票付款" 功能來開立

a. 一般使用者（旅客）
Given 使用者已選擇車次與座位，
When 進入付款頁面並選擇付款方式（如信用卡、LINE Pay），
Then 系統應顯示清楚金額與應付明細（票價、票種、數量）。

Given 使用者輸入正確付款資訊，
When 點選「確認付款」後交易成功，
Then 系統應顯示「付款成功」頁面，並提供訂單編號與 QR Code。

Given 使用者輸入錯誤的付款資訊或中途中斷付款，
When 付款失敗，
Then 系統應顯示錯誤訊息並提供重新付款的選項。

b. 系統（後端邏輯 / API）
Given 接收到使用者提交的訂票資料，
When 付款流程開始，
Then 系統應先鎖定座位、保留訂單時間（例如 10 分鐘內完成付款）。

Given 第三方付款平台回傳成功訊息，
When 交易完成，
Then 系統應更新訂單狀態為「已付款」並產生電子票證資料。

Given 系統偵測到付款失敗或逾時，
When 超過保留時限未付款，
Then 系統應自動釋放座位並將訂單標記為「失敗」。

c. 管理員（客服 / 後台操作）
Given 管理員登入後台管理系統，
When 查詢訂單編號，
Then 應可看到付款狀態（成功 / 失敗）、付款方式、時間戳記。

Given 有使用者來電申訴付款問題，
When 管理員開啟訂單細節，
Then 應可看到付款錯誤原因碼或第三方支付紀錄。

Given 管理員欲手動取消或退款特定訂單（如超收或重複付款），
When 點選「取消 / 退款」操作，
Then 系統應記錄操作紀錄並通知使用者退款處理進度。

(3) 好處：

• 幫助檢查利害關係人角度是否被涵蓋
• 建立一致性期待，降低需求誤解

(4) 適用時機：

• 系統涉及前台、後台或 API 三方角度
• 權限分工明顯的系統

格式 4：正反情境補強格式（Positive vs Negative）

(1) Prompt Format：
根據此需求，列出 2~3 個正常流程（Happy Path）驗收條件，及 1~2 個錯誤處理（Exception Path）條件。

(2) 範例：
根據以下需求，列出 2~3 個正常流程（Happy Path）驗收條件，及 1~2 個錯誤處理（Exception Path）條件。 針對台灣高體訂票系統: https://irs.thsrc.com.tw/IMINT/?locale=tw 的 "查詢車次" 功能來開立

a. 正常流程（Happy Path）驗收條件
Given 使用者選擇「起站：台北」、「訖站：台中」和「乘車日期：今天」，
When 點擊「查詢車次」按鈕，
Then 系統應顯示從台北到台中今日所有可搭乘的班次清單。

Given 使用者完成查詢操作後，
When 結果顯示，
Then 每筆班次應包含「出發時間」、「抵達時間」、「票價」、「剩餘座位狀態」。

Given 查詢結果顯示頁面，
When 使用者點選某班次的「訂票」按鈕，
Then 系統應正確導向選擇座位與票種的下一步流程。

b. 錯誤處理流程（Exception Path）驗收條件
Given 使用者未選擇起站或訖站，
When 嘗試點擊「查詢車次」按鈕，
Then 系統應提示「請選擇起站與訖站」並禁止送出查詢。

Given 使用者選擇的日期為過去時間（如昨天），
When 點擊「查詢車次」，
Then 系統應顯示「無法查詢過去日期車次」的錯誤提示，並清空日期欄位。

(3) 好處：

• 避免只寫 Happy Path，強化錯誤與風險場景
• 幫助風險思維進入早期驗收條件

(4) 適用時機：

• 有驗證規則、邊界處理或風險控管需求
• 提升穩定性與使用者體驗保障

這 4 種就像是「核心 prompt 工具箱」，足以應付 80% 的需求驗收設計情境。

雖然這四種格式夠好用，但不一定足夠用；它們是通用起手式，但在不同場景，還可以延伸或補強。

所以無論你是 PM、開發、QA 或教學設計者，都可以從這些格式出發，快速建立與 AI 合作的驗收條件產出流程。