第四步：起草一份輕量 PRD

PRD（產品需求文件）不過是把你的決定彙總到一處。它有一副可預測的骨架——每次都是那幾個小節：

PRD
├─ 問題          為何存在
├─ 使用者          為誰而做
├─ 目標          做什麼，一句話
├─ 範圍內        v1 包含什麼
├─ 非目標        v1 略去什麼
├─ 使用者故事      作為 __，我想 __，以便 __
├─ 資料模型      你儲存的欄位
└─ 完成標準      驗收測試

保持它精簡。下面是一份完整的入門級 PRD，你可以直接交給 AI：

# Book Tracker — Mini PRD

## Problem
I read a lot but lose track of what I've finished and what I thought of it.

## User
Me (a single user). No accounts needed for v1.

## Goal
A simple web app to add books, track reading status, and rate finished ones.

## In Scope (v1)
- Add a book (title, author)
- Set status: To Read / Reading / Finished
- List all books, filterable by status
- Rate finished books 1–5 stars

## Non-Goals (v1)
- User accounts / login
- Social features, sharing, recommendations
- Importing from other services
- Mobile / native apps

## Tech (keep it simple)
- Single-page web app
- Local browser storage (no backend for v1)

## Done When
I can add a book, change its status, rate it, and see my list
persist after a page refresh.

注意那行 "Done When"（完成的標誌）。那是你的驗收測試——一個判斷你是否已交付 v1 的具體方式。永遠要寫上一條。一個好的"Done When"，是你能親手做到的事：點這裡、輸入這個、重新整理、看到那個。如果你的完成條件讀起來像一種感覺（"等它打磨好了""等它感覺對了"），那它永遠完不成，因為沒有什麼可供你對照檢查。把它寫成一份你能交給陌生人去照做的指令碼。

你不必手寫這份 PRD。一個有用的做法是，把你前面幾步的回答喂回給 AI，讓它來拼出草稿，然後你來編輯。之所以是編輯而不是照單全收，是因為你必須理解並認同每一行——這份文件是你會反覆貼上回去的事實來源，所以這裡的一個錯誤會被複制進之後的每一次會話。