先記住：AI 產出的 PRD 是草案，決策仍要有來源與人確認。
需要深入時：再建立追溯關係。

十分鐘生出 PRD，為什麼還是沒人敢開工？

進入AI 的時代之後擅長把一個點子整理成目標、功能、時程和 KPI已經是日常工作了。
麻煩的是，文件可能把沒有討論過的折扣規則、上線日期和轉換率目標全部補滿。
文件完整，不代表決策完整。
我會把 AI 產出的 PRD 當成可審查草案，重點是暴露未知與形成共識。

先給它一份來源包

優惠券專案的來源包可以很小：
一段已確認的產品目標
一份現行 API 契約
一張設計稿以及本次不做的事項。

每份來源都標版本或日期。
若目標說允許訪客，API 卻只有會員權限，那麼AI 應指出衝突，不能自己選一份。
文件缺少資訊時，保留問題比填入看似合理答案更有價值。
PRD 的主要內容是問題、使用者、範圍、流程、規則、限制、驗收與風險；不是越多章節越正式。

把 Story 切成可交付的行為

第一則可以是「會員取得優惠報價」，包含成功與明確失敗。
第二則是「商品變更後重新確認報價」。
第三則是「提交結果不明時恢復流程」。

這邊不必把「畫輸入框」「寫 service」各自當成有使用者價值的 Story；
它們可以是 Story 底下的工程任務。
這樣驗收才會從使用者行為出發，而不是只看檔案是否存在。

每則 Story 再加一個正常與一個反例。
例如該券已過期，當會員送出，則保留輸入、顯示失效原因且不更新成有效報價。
這足夠讓不同角色討論理解是否一致。

用追溯關係保護文件品質

我會幫核心規則編簡單代號：
R1 金額由伺服器裁定，R2 舊版本報價不可提交。
接著讓 Story、設計與測試指回這些規則。

如果一段實作沒有對應需求，問它為什麼存在；如果一條需求沒有任何驗收，問怎麼證明做到。
說起來也不是為了建立龐大管理系統，只是避免文件和程式都各說各話～

且文件也要有狀態：草案、待確認、已確認。
AI 沒有參加會議，就不能列成已同意。

可以交給 AI 的 Prompt

請依來源包產生優惠券 PRD 草案，包含問題、使用者、範圍、流程、規則、限制、驗收和未知。每條核心規則附來源；衝突另外列出。將功能拆成可端到端驗收的 User Story，再列工程任務。不要捏造商業指標、負責人、上線日期或已簽核狀態。

這段整合前一週的脈絡管理、流程分析與契約思維。
AI 的工作是整理與發現缺口，人的工作是確認取捨與對結果負責。

今日練習與筆記

拿一份 AI 文件，挑三個裡面肯定的句子，逐一問「證據在哪」。
找不到就改成假設或待確認，並寫出需要誰提供什麼資訊。

煩死人的第二週結束，但至少到目前思維思考上已經有比較可靠的輸入了吧（？
第三週要處理輸出：當程式能跑卻很難改，來看看讓 SD 原則把責任重新整理清楚。