先決定你現在是要學，還是要在專案裡做
網站負責解釋與分發工作包；真正的 Repository 掃描、缺口判斷與文件產出交給 Coding Agent。
PRD 實作課 · Demo
先別急著叫 AI 寫文件
PRD 不是功能願望清單。它先把「為什麼做、替誰做、這次做到哪裡」講清楚，讓設計、工程與 QA 不必各自猜一次。
- 01讀大綱
- 02看案例
- 03填素材
- 04貼提示詞
- 05對照驗收
Anatomy · 文件解剖
一份 PRD，先回答七個問題
先看每段要留下什麼決策，再看格式。格式可以調整，這七類問題不能被漂亮文字掩蓋。
- 01
問題
誰在什麼情況下，遇到什麼麻煩？
團隊知道為什麼值得做，而不是先討論功能。
- 02
目標
做完後，使用者或產品要改善什麼？
留下可觀察的成功標準，避免只寫『體驗更好』。
- 03
使用者與情境
這次優先服務誰？他什麼時候會使用？
AI 不需要猜測所有人都可能想要什麼。
- 04
範圍與非目標
這一版做什麼，又明確不做什麼？
控制 MVP 邊界，讓新需求有地方安放。
- 05
需求
產品必須提供哪些使用者可感受到的行為？
將想法拆成可排序、可追蹤的需求。
- 06
驗收提示
看到什麼結果，才知道這條需求完成？
提供 QA 與下一份 Acceptance Criteria 的入口。
- 07
尚未確認
哪些資訊仍不足，現在不能假裝已經決定？
讓未知保持可見，不讓 AI 用合理文字偷偷補完。
Study · 對照學習
同一份骨架：先看挖空，再看成品
範本與案例維持相同七段結構。先讀 SmartTrip 為什麼這樣填，再把同一個問題換成自己的答案。
保留問題，換成你自己的答案。
# Product Requirements: <產品名稱>
**狀態：** Draft · **負責人：** <姓名> · **更新日期：** YYYY-MM-DD
## 1. 問題
<誰，在什麼情況下，遇到什麼具體問題？>
## 2. 目標
- G1：<希望改善的結果>；以 <量測方式與門檻> 判定。
## 3. 使用者與情境
- 主要使用者：<這一版優先服務誰>
- 使用情境：<何時、為什麼會使用>
## 4. 範圍
### 這一版要做
- <MVP 必須包含的能力>
### 這一版不做
- <明確排除的能力>：<原因>
## 5. 需求
### REQ-001：<需求名稱>
- 使用者行為：<使用者要完成什麼>
- 預期結果：<產品要呈現什麼結果>
- 來源：<痛點、訪談或已確認決策>
## 6. 驗收提示
- REQ-001 完成時，可以觀察到：<可驗證結果>
## 7. 尚未確認
- OPEN-001：<仍缺什麼資訊>；需要 <誰或哪份證據> 回答。Practice · 換你試做
先用人話寫素材，不用先學工程術語
這不是 PRD 本身，只是你要交給 Coding Agent 的原始材料。能確定的就寫，不確定的留白，讓下一步的提問把它找出來。
可以先留白；複製提示詞後再到 Coding Agent 裡補充。
AI Practice · 手動三步
不要一次叫 AI 包辦：先問、再寫、最後審
三段提示詞刻意分開。每一步都把結果留在 Claude Code、Codex 或你使用的 Coding Agent 裡，再由你決定是否進到下一步。
先問，不要急著代寫
把會改變產品範圍、使用行為或驗收方式的未知找出來。
我正在練習把產品想法整理成 PRD。以下是我的產品素材。
先不要產出 PRD，也不要討論技術架構。
請先找出會影響「服務誰、解決什麼、這一版做什麼、怎樣算完成」的未知事項。一次只問最多 5 題，並簡短說明每題會影響哪個決策。
已經有明確答案的事情不要重問；可以延後決定的技術細節先放入「尚未確認」。複製後，請在標示位置貼上自己的產品素材。
Review · 自己驗收
文件寫完，不代表問題已經說清楚
逐條檢查 AI 產出的 PRD。你必須能指出每個答案從哪裡來，也必須看得出還有哪些事情沒有答案。
把「怎樣算完成」寫得可測試
PRD 留下高層次驗收提示；下一張卡再把它拆成 Given / When / Then。