轉念學 – 敏捷三叔公的學習之旅

越來越多團隊開始用 AI 來產生 User Story。速度確實變快了，文件也比以前整齊，但奇怪的是專案的混亂程度並沒有跟著下降。

會議上依然充滿這些問題：

• 這個情況到底算不算？
• 如果使用者已經付款，但時間快到了呢？
• 這個改票規則，是不是只適用某些班次？

User Story 看起來沒有錯，但需求卻始終無法「清晰明確」。真正的問題往往不在 AI，也不在 User Story 本身，而是 Prompt 一開始就沒有把需求說清楚。

多數 Prompt，其實只是把模糊需求交給 AI 放大

常見的 Prompt 看起來像這樣：「請幫忙產生台灣高鐵訂票系統的 User Story。」

這種問法，對人來說就已經很模糊，對 AI 而言，只會得到一堆「合理但不可驗證」的內容。AI 很擅長補齊空白，但在需求工作中，自動補齊恰恰是最大的風險來源。

真正能用的 Prompt，應該要是把 角色、範圍、品質底線一次說清楚。

一個實務上真的有用的 Prompt 格式

好的 Prompt，結構其實非常樸素，但每一段都在做需求該做的事。

【角色定位】
你是一位熟悉訂票與交易流程的產品分析師。
【輸出格式】
請使用以下格式撰寫：
身為一個【使用者角色】
我希望【可以完成的行為】
以便於【實際帶來的價值或避免的風險】
【品質要求】
內容必須：
- 對使用者有明確價值
- 可被實作與驗證
- 不包含過多行為或假設
【產品背景與範圍】
系統：台灣高鐵線上訂票系統  
功能範圍：線上改票  
使用者：經常搭乘高鐵的上班族與商務旅客
【任務】
請產生一則使用者故事，並延伸出：
1. 驗收條件（Acceptance Criteria）
2. 可驗證的情境（Gherkin）
3. 如有複雜規則，請整理成決策表

這個 Prompt 的價值不在於「寫得多厲害」，而在於它已經先把需求壓進一個可討論的框架裡。後續可以供團隊檢視討論，以及讓 AI 可以比較明確地進行後續的工作 (生成程式或是自動化)。

User Story 本身，其實只是開場白

在這個 Prompt 條件下，AI 產出的 User Story 可能是：

身為一個經常搭乘高鐵的上班族
希望能在列車發車前自行線上改票
以便於行程臨時變動時不必到櫃檯排隊

這樣的故事方向是正確的，但它只回答了一個問題：「想做什麼」。但是真正會讓專案出事的，是後面這些沒被寫下來的問題：

• 發車前多久？
• 有沒有付款差異？
• 票價不同怎麼處理？
• 系統該拒絕到什麼程度？

這些問題，不能留到開發或測試才補。需要事前就討論，這樣才能降低重工，或是比較不會有神奇的 Bug。

驗收條件，才是需求真正開始「落地」的地方

這時候驗收條件就可以派上用場，驗收條件的角色，並非只是在補充說明，它是希望畫清楚底線，讓你知道這個需求範圍包含到哪裡。下面是一個驗收條件的範例：

線上改票的驗收條件範例

• 僅限已完成付款的訂票才能進行線上改票
• 距離列車發車時間須大於 30 分鐘
• 發車前 30 分鐘內，系統必須拒絕改票並顯示說明
• 改票至較高票價班次，需補差額
• 改票至較低票價班次，差額不退還
• 改票完成後，需顯示新的班次與座位資訊

寫到這一步，才能把前面的需求從「看起來合理」，變成是有具體的範圍，並且開始影響到實作與測試策略。

把規則換成情境，誤解會少很多

前面有了驗收條件後，因為還是用文字描述，很容易被各自解讀；如果我們有具體的情境和具體的數值，就會有不一樣的結果，它會逼大家確認我們到底想得是不是同一個例子。

Scenario: 發車前成功改票
  Given 使用者已完成訂票並付款
  And 距離發車時間超過 30 分鐘
  When 使用者送出改票申請
  Then 系統允許改票

Scenario: 發車前 30 分鐘內嘗試改票
  Given 使用者已完成訂票並付款
  And 距離發車時間小於等於 30 分鐘
  When 使用者嘗試改票
  Then 系統拒絕改票
  And 顯示限制說明

規則一多，用決策表才不會靠記憶

當時間、付款狀態、票價同時交織，上面的 Gherkin 很容易漏掉組合。所以我們會用 Decision Table Testing的方式，讓複雜的需求場景呈現的更清楚。

決策表的目的只有一個：讓每個邊界都被看見，而不是被猜測。這樣團隊成員