當我們談到「如何描述驗收條件」時，很多團隊很快就會發現：同樣一個需求，每個人腦中想的畫面都不太一樣。產品經理以為「寫清楚了」，開發人員以為「理解了」，測試人員卻覺得「哪有這麼單純？」於是，交付出來的結果與當初想像的差距越來越大，程式缺陷層出不窮，驗收又爭執不休。

這背後的根本原因，常常不只是「溝通不良」，而是驗收條件的描述方式不夠精確、沒有共識、也不容易推敲。尤其在導入 Specification by Example時，驗收條件的書寫格式，不只是文件格式的選擇，而是團隊協作、溝通與品質管理的核心。好的驗收條件，可以讓需求清楚、開發目標一致、測試方向明確；反之，模糊或誤用的格式，則會讓需求落實變得困難重重，甚至最後無法驗證所謂的「完成」。

初期共識的本質——重點不是格式，而是語意對齊

在很多 SBE、BDD 或敏捷教科書裡，都會推薦一開始用 GWT（Given-When-Then）來描述驗收條件，強調標準化、結構化的好處。但現實裡初期這樣做，反而會讓一些 PM、QA 或業務成員「卡關」：GWT 的英文格式本身沒有直覺感，格式一多、條列一長，有些人只看到框架，反而忘了「到底要幹嘛」。

真正的初期共識，應該用大家都能理解、好舉例、好討論的方式來打底，而不是急著格式化。例如白話描述、流程圖、便利貼或直接用「如果…那麼…」這種自然語言，才能讓每個角色都安心地表達「自己對這個需求的真實想法與疑慮」。這個階段，討論的重點在於「大家腦中浮現的畫面是不是一樣」，而不是「誰會寫 GWT」。

• 建議初期流程：
A. 先用口語、對話、故事舉例，把情境與預期行為描述清楚，不用管格式。
B. 大家說一次：「你會怎麼做？你覺得會遇到什麼狀況？」比對彼此的認知，發現矛盾或遺漏。
C. 當語意已經很接近時，才將這些共識慢慢「結構化」，轉為 GWT、Decision Table 或 Rule-Based 格式，這時格式才是輔助共識落地與自動化的工具。

因為太早強求格式，容易壓抑需求討論的想像力與參與感，尤其對於不熟悉這些結構化語言的同仁。共識的根本在於「能夠說出同樣的例子、腦中浮現一樣的場景」，而不是「大家都會寫 Given-When-Then」。只有等大家都能說出一樣的故事時，再進入結構化描述，這些格式才能真正幫助落實需求並為後續自動化打好基礎。

驗收條件的三大主流格式

在實務上，描述驗收條件常見三種格式：

• GWT（Given-When-Then）情境式
• 表格式（Decision Table）
• 規則式（Rule-Based）

每一種方式各有其特點與適用場景。善用這些格式，不只能協助團隊理清需求，更能為後續的測試自動化與 GenAI 工具整合打下良好基礎。以下分別介紹這三種格式的表示方法、舉例說明、優缺點分析、適用時機，並深入討論在 Spec by Example 的實踐上常見誤用與補救方式，最後再延伸到 GenAI 時代下的新應用。

一、三種格式的介紹與範例

(1). GWT（Given-When-Then）情境式

這是源自 BDD（Behavior Driven Development）的經典格式，以敘事式的情境呈現使用者操作與系統回應，語法親切、語境清楚，非常適合團隊在需求澄清階段快速取得共識。

格式說明：
Given 某個前置狀態
When 某個動作發生
Then 系統應該有某個可觀察的行為或結果

範例（ATM 提款）：
Given 我的帳戶餘額有 1000 元
When 我從 ATM 提領 500 元
Then 帳戶餘額應顯示為 500 元
And ATM 應吐出 500 元的現金

這種方式適合描述完整流程、強調人機互動，便於開發、測試、產品三方對齊預期。

(2). 表格式（Table）

當需求涉及多個變數或條件，且條件之間交錯複雜時，使用表格可以大幅提升條件覆蓋與邏輯明確度。

格式說明：

範例說明：
例如一個電商折扣規則，僅用文字容易遺漏例外與組合，表格則一覽無遺。QA、測試工程師可以很快將每列轉成一組測試案例，有效驗證各種條件交互的正確性。

(3). 規則式（Rule-Based）
如果業務規則明確、條件簡單，或適合逐條獨立檢查，則 Rule-Based 是最直覺的描述方法。

格式說明：
• 規則1：如果申請人的信用分數低於600分，則拒絕貸款申請。
• 規則2：如果申請人的年收入超過100萬，即可享有優先處理。
• 規則3：如果申請人提供不完整資訊，則回覆通知要求補件。

範例說明：
這類方式易於增補、討論和版本管理。產品經理或業務分析師可先用規則式列出所有要求，再逐步推進細節。

二、三種格式的比較與適用時機

實務建議：
• 團隊剛建立共識時，建議先用白話、故事、舉例或流程圖打底，聚焦語意和案例。
• 條件繁複時，善用表格拆解交錯情境。
• 規則式則適合先盤點需求，再逐步轉為情境或表格補強邏輯。
• 當共識已成熟，再進入 GWT結構化工具，為自動化與 AI 協作鋪路。

三、Spec by Example 實作上的常見誤用與補救

(1). GWT 寫成技術細節，失去情境：
很多團隊將資料庫、API 細節硬塞進 GWT，失去使用者觀點，反而讓開發和 QA 對不到焦。
補救：
要求所有 GWT 以「角色-動作-結果」重寫，專注人與系統互動，減少技術語彙。可透過 Three Amigos 等 workshop 共同練習，讓每個人都能用「故事」說明驗收條件。

(2). 表格式過度繁瑣，遺失關鍵焦點：
有些團隊怕漏掉條件，什麼都往表格塞，造成條件組合爆炸。
補救：
僅針對關鍵業務邏輯、邊界條件建表，其餘可用情境式或註記輔助。定期回顧，確保表格聚焦在「有意義的差異」上，而非所有細枝末節。

(3). 規則式描述太籠統，無法驗證：
規則常常「大方向」對，但缺乏細節，例如「資料需正確」或「錯誤要提示」這種語意，讓開發與測試各自解讀。
補救：
將規則細化，標記條件、範圍與例外。甚至可先以表格或 GWT 展開，然後把共識彙整回規則式，兼顧清楚與可追溯性。

GenAI 時代下的驗收條件新角色：從人對人到人對 AI 的協作橋梁

在過去，驗收條件（Acceptance Criteria）主要是團隊成員之間的溝通工具，確保大家對需求的理解一致。
但在 GenAI（生成式 AI）時代，驗收條件的角色正在升級——它不只是「人懂」，還要讓「AI 也懂」。

(1). 為什麼 AI 需要格式化的 AC？
GenAI 工具（例如 AI 自動產生測試案例、生成程式碼、產出驗證腳本）都依賴「明確、結構化、語意一致」的描述。

如果 AC 沒有標準化格式，AI 就可能：
• 誤解條件（例如「金額超過 500 元需審核」被 AI 當作「大於等於 500」）
• 無法生成可執行的測試步驟
• 產生過多不必要的測試案例

例子：
如果你用自然語言寫「當用戶帳戶有錢時，可以提款」，AI 可能無法判斷「有錢」的確切數字。
但如果改成 GWT（Given-When-Then）：

Given 帳戶餘額為 1000 元
When 用戶提領 500 元
Then 餘額應為 500 元
AI 就能直接解析成測試程式。

(2). 從需求澄清到自動化：格式的演進
在產品開發不同階段，AC 的格式應該隨目標調整：
• 需求初期：先求共識，格式可以彈性
o 使用白板、流程圖、GWT 草稿、口語描述
o 重點是確認大家對需求的理解一致
• 需求落地：格式收斂、結構化
o 使用 GWT、Decision Table、Rule-Based
o 確保 AI 與人類都能精準解析
o 表格欄位統一、規則定義清楚，方便機器讀取

例子：
• Decision Table

AI 可以針對每列自動生成一組測試情境。

(3). 如何讓 AC「AI 也懂」？
要讓 AI 可靠使用 AC，需要三個原則：

A. 語意清楚、格式一致
o 每條 GWT 都要完整描述狀態、動作、結果
B. 可機器讀取
o 加上標籤（如 @boundary, @testcase）或區塊分隔符號，幫助 AI 分辨
C. 具追蹤性
o 格式化的 AC 可以直接成為需求與測試的 Traceability Matrix，方便回溯與驗證

(4). 從 AC 直接生成測試與 Script
當 AC 已結構化，AI 就能直接把它轉成測試步驟、Mock Data、甚至整個自動化流程。

範例 1：GWT → 自動化測試
Given 帳戶餘額有 1000 元 → 建立初始測試資料
When 用戶提領 500 元 → 呼叫提款 API
Then 餘額應為 500 元 → 驗證結果
AI 或工具（如 Cucumber、SpecFlow）可直接執行。

範例 2：Decision Table → 大量驗證
每一列等於一組 Test Case，AI 能批量餵給測試框架，提升覆蓋率。
範例 3：Rule-Based → 條件檢查 Script
規則「若信用分數 < 600 則拒絕」可讓 AI 自動生成信用分數 599 的測試資料並驗證流程。

5. 實務建議
   • 需求初期：格式可彈性，但注意語意準確
   • 需求落地：統一使用 GWT、Decision Table 或 Rule-Based
   • 持續優化：將 AC 當作「可機器解析的需求文件」，直接輸入 AI 工具，減少人工轉換

在 GenAI 時代，驗收條件格式已經不只是討論用的文件，而是人與 AI 之間的關鍵接口。
如果從下一個需求開始，你就用 GWT、表格或規則式來寫 AC，AI 就能幫你自動化測試、產生 Mock Data、甚至執行驗證流程，讓品質與效率同步提升。