先記住：一句「很簡單」先拆成角色、目標、成功與不做範圍。
需要深入時：再整理完整 Use Case。

「這應該很快吧？」

假設 PM 希望在購物車加一個「套用優惠券」按鈕。
你看了設計稿，只有輸入框和一顆按鈕，直覺估半天。
開發到一半才發現：會員限定、不能疊加、部分商品不適用，而且使用者改數量後要重新算。

PM 往往在描述希望達成的效果，工程師需要把效果轉成系統可以執行的規則。
但 PM 說的是「加一顆按鈕」，真正要做的，往往是按下去之後那一連串規則。

先問「做完以後有什麼不同」

如果目標是讓會員知道折扣後要付多少錢，那麼成功不只是出現「套用成功」Toast。
畫面還得顯示優惠名稱、折扣金額與最新總額，並確保它們是同一份報價。
接著問誰能用。
訪客看到同一顆按鈕，是先登入，還是可以試算但不能結帳？
這兩種設計會影響導頁、草稿保留與 API 權限，不能等串接時才臨時選一個。

最後問哪些事情不在這一版，例如暫時不支援多券疊加。
把不做的範圍寫下來，讓估時有可依據的邊界。

把一句話拆成可討論的流程

教學假設：會員一次可用一張券，伺服器回傳完整報價。

1. 使用者輸入代碼，前端檢查是否空白。
2. 使用者送出，畫面進入驗證中，避免同一操作連點。
3. 伺服器回覆新報價，畫面一起更新優惠與金額。
4. 若券不適用，保留輸入並顯示可理解的原因。
5. 若商品內容改變，舊報價失效，需要重新確認。

第五步最容易被忽略。
它讓我們發現「套券」與「購物車版本」有關，不能把結果當成永遠有效的布林值。

用反例檢查理解

原本的驗收可能只有「點下去可以折價」。我會把它改成：

• 商品符合條件且券有效：顯示伺服器確認後的折扣與總計。
• 券已過期：不更新為成功，輸入保留，告知可更換代碼。
• 送出後使用者改了數量：舊回應不能直接覆蓋新購物車。
• 網路逾時：顯示尚未取得結果，不把折扣當成零或成功。

這些例子能讓 PM、後端與 QA 指出理解差異。
「套用失敗後是否可以原價結帳？」這是產品問題，要留給決策者。

可以交給 AI 的 Prompt

請把「購物車新增套用優惠券按鈕」拆成角色、目的、前置條件、正常流程、例外流程、成功條件與本次不做的範圍。假設一次一張券，價格由伺服器計算。請特別檢查操作後商品變更、逾時與重複點擊。所有未提供的產品規則放在待確認區，不要替團隊做決定。

這段的重點是讓 AI 找缺口，不是一次填滿所有缺口。
當它提到「逾時自動重試」，我們還要追問：這是查詢報價，還是會消耗優惠券？操作的副作用會改變處理方式。

今日練習與筆記

把一個短需求改寫成五行：誰、想完成什麼、何時可以開始、成功後狀態、失敗後狀態。
再加上一條「這次不做」。
如果這五行還無法寫清楚，現在最有效率的工作可能是提問。
明天把目光放到正常流程之外，看看隱性需求到底藏在哪裡。