回顧與練習

核心要點

• 規格是一份簡短、平實語言的工作筆記——你在做什麼、不做什麼——而不是一份要凍結的合同；一頁就夠了。
• 在功能之前先釐清問題和擁有這個問題的人，並寫下非目標（non-goals）：它們是抵擋 AI 新增"貼心"附加功能的最鋒利防線。
• 帶 so that 子句的使用者故事，加上有具體"Done When"那一行的小型 PRD，把意圖變成可測試、可構建的行為。
• 儘早釘死資料模型——欄位名會滲漏到處都是——並把規格切成你能一次驗證一個的 vibe 大小任務。
• 描述問題，而不是解法；結果在規格里改起來便宜，在程式碼裡改起來昂貴。一邊學一邊讓規格保持鮮活。

動手試試

拿一個你一直擱著的想法，在一次 AI 會話裡把它變成一頁規格。先讓 AI 用五個尖銳的問題對你做訪談，然後——用你自己的話——寫下問題、使用者、三個使用者故事（每個都帶 so that）、一份明確的非目標清單、一個六行的資料模型，以及一行你能物理執行的"Done When"。存成 SPEC.md。好規格的檢驗標準：明天你把它粘進一個全新的對話，AI 就能確切知道該構建什麼。

本章提示詞

我有一個粗略的想法：<一行描述>。

扮演我的產品思考夥伴。首先，向我提出 5 個犀利的問題，
一次一個，以釐清問題、目標使用者，以及"完成"
是什麼樣子。先別提議功能。

我回答後，按這些小節起草一頁的規格：
- 問題  - 使用者  - 目標
- 範圍內 (v1)  - 非目標 (v1)
- 使用者故事 (每條"作為 __，我想 __，以便 __")
- 資料模型 (欄位的簡短列表)
- 完成標準 (具體、可實際執行的驗收測試)

保持精煉——一頁以內。若有含糊之處，先問再
假設。我會修改草稿，直到我認同每一行。