規劃工具

輸入方式

用自然語言描述想做的產品即可，例如：幫健身教練管理學員課表與收款。

推薦邏輯

工具會用產品型態、資料複雜度、登入需求、付款需求與維運能力做初步判斷。

必要欄位

至少要包含需求摘要、功能清單、排除項目、交付物、驗收標準、維護期與付款方式。

適合時機

當想法已經有明確使用者，但還沒有拆成功能、限制與驗收方式時，就該先寫 PRD。

最少要檢查

確認正式環境的環境變數、資料庫權限、監控通知、付款測試、網域 SSL 與備份方式，並保留預覽部署給測試與驗收。

交接重點

列出 GitHub 程式碼倉庫、部署平台、資料庫、身份驗證、權限控管、付款、Email、監控的負責人與付款方式。

必要內容

列出路徑、方法、驗證方式、請求資料、回傳資料、錯誤碼與範例，避免只寫端點名稱。

常用格式

身為某種使用者，我想要完成某件事，以便得到某個價值。

訪談前先釐清

先寫清楚受訪者類型、目前假設、想驗證的風險與不能引導回答的問題，避免訪談變成推銷。

排序標準

要求 AI 同時看使用者價值、實作成本、風險降低、收入影響、法規限制與是否阻擋其他功能。

版本切法

Alpha 用來驗證流程，Beta 用來讓真實使用者試用，正式版才處理穩定性、文件與交付細節。

好標準的樣子

把成功情境、錯誤情境、權限限制、資料變化、通知結果與不可做事項都寫成可以檢查的句子。

研究方法選擇

想知道原因先訪談，想估比例再問卷，想確認流程卡點就做可用性測試。

比較維度

至少比較目標客群、核心流程、定價方式、整合能力、信任證據、客服方式與新手阻力。

先定義核心行為

找出註冊、啟用、完成主要任務、付費、留存與流失這些行為在你的產品裡各代表什麼。

風險類型

把需求變更、第三方服務、資料品質、權限、付款、法規、效能與人力可用性分開評估。

會後整理

要求 AI 區分已決定事項、尚未決定事項、不同角色關心的風險與下一次會議前要補的資料。

先定義成功

寫清楚使用者第一次進來後，最希望他完成哪個動作，以及完成前需要知道哪些資訊。