PRD（Product Requirements Document／產品需求文件）定義要做什麼以及為什麼：問題、範圍、需求，以及背後的決策，讓團隊和關係人有同一張圖。弱點在後面——過了兩三個 sprint，PRD 就和現實脫節，開始漂移。這頁講結構與範本，以及怎麼防止漂移。
這個範本可以直接套用。最有價值、也最快過期的是第 4 項——決策。PRD 只是 路線圖 和底下決策的「看得見的尖端」。
PRD 在核准當天是對的。之後，一場會議改了假設，一個邊界案例推翻了決策——文件卻停在原地。沒人會手動去追一份 12 頁的文件。幾週後，AI agent 開始在一份已經不成立的規格上動工。
每條需求與決策，變成可引用的卡片，而不是第 7 頁的一行字——帶著理由與負責人，用 ID 就找得到。
後面的決策推翻前面的，依賴的卡片——也就是受影響的 PRD 部分——自動標 stale。文件不會再默默騙你三週。
Claude Code、Cursor 經 MCP 讀 PRD——是最新的，或被明確標為 stale，而不是一份沒人知道狀態的靜態文件。
PRD 在核准當天是對的。問題是核准之後那六週，沒人讓它跟上。把需求變成卡片，PRD 自己就會說「我過期了」。這就是 Draftlize。
PRD 定義「做什麼、為什麼」，屬於上層；規格書處理「怎麼做」。PRD 的決策一變，規格也該變，這個連動很關鍵。
多半由 PM 主筆，和工程、設計協作。重點是讓裡面的決策日後追得回來、理由留得住。
把問題、範圍、需求、決策講清楚就夠了。比起長度，「被推翻時能被提醒」更重要。
把需求和決策做成互相連結的卡片，而不是凍住的段落。決策一變，Draftlize 自動把相關處標 stale。延伸讀 決策紀錄。
用連結的卡片寫 PRD，每條需求都能被引用。決策一變就自動把相關處標 stale——PRD 漂移就此結束。
免費開始，送 $5