文章封包
Workflows
準備 PRD 或路線圖審查的產品經理、UX 研究員與產品營運團隊
8 分鐘閱讀
01
從一個產品決策和核准的證據邊界開始。
02
讓每個需求都能回到有日期的研究、客服、業務或決策來源。
03
分開保存觀察、解讀、假設、矛盾與待解問題。
看看審查者實際檢查的有來源工作區
下方是 Wenlan App 從確定性測試資料擷取的真實桌面畫面。畫面列出有來源數量的近期 Pages，也讓來源衝突與新來源等待審查。這不是客戶資料；同一個審查介面也支援產品研究證據。
- 01
核准來源邊界
只加入團隊可以檢查、允許用於這次產品決策的研究與決策來源。
- 02
整理一個產品決策
把觀察、解讀、假設、矛盾與待解問題分開，並讓重要主張連回來源。
- 03
寫 PRD 前先審查
打開引用與原始記錄，確認需求有依據，過期或無法證明的內容保持可見。
PRD 證據封包範例
這是可檢查輸出的結構範例，不代表任何特定使用者研究或真實產品決策。
- 證據輸入
- 有日期的訪談段落、客服訊號與已核准的過往決策。
- 候選需求
- 把一項需求連回來源，並分開記錄團隊解讀、假設與衝突證據。
- 審查結果
- 保留、縮小或維持未解；決定時留下理由、目前修訂與待補證據。
01
先從一個產品決策開始，不是公司檔案庫
開始寫 PRD 前，先為正在審查的決策建立一個產品範圍內的證據庫。只收集團隊可以檢查的核准訪談筆記、客服或業務筆記、研究資料與過往決策；目標是讓每個需求都可追溯，不是把所有對話做成一個泛用資料夾。
Wenlan 可以把支援的 Markdown、文字、可擷取文字的 PDF、資料夾與唯讀 Obsidian 來源，連到有來源的 Pages、引用、修訂、過期狀態與審查。它不會替你決定產品路線，也不會把來源自動變成已核准的產品需求。
02
綜合前先固定來源邊界
在請 Agent 綜合前，先寫下產品範圍、審查問題、日期區間、納入的來源類型與排除的資料。一個窄邊界能幫你分辨需求是來自使用者觀察、團隊解讀、假設，還是需要重新檢視的決策。
在小型來源登錄表中保存來源日期、文件版本與確切標題或段落。如果筆記不完整，或來源沒有獲准用於這個產品決策，應記錄為無法取得，不要默默補上缺口。
- 核准的訪談或研究筆記：保留觀察與來源位置。
- 客服或業務筆記：把重複出現的問題訊號和未驗證的要求分開。
- 過往決策：記錄決策日期、理由、範圍，以及當時可用的證據。
- 假設與待解問題：保持可見，不要把它們寫成使用者事實。
03
把筆記連成需求的證據鏈
每個重要需求使用一列或一個 Page 段落。把需求連到有日期的來源段落，分開記錄原始觀察和你的解讀，並在判斷需求應保留、縮小或維持未解前，先留下互相矛盾的證據。
同一條證據鏈應能通過 PRD 審查：審查者可以打開來源，看見目前修訂，理解仍存在的假設，並追蹤過往決策如何改變。來源變動時，只刷新受影響的 Page，並保留舊修訂供審查。
- 記錄產品問題、source ID、日期、確切位置與適用範圍。
- 把每句話分類為觀察、解讀、假設、決策或待解問題。
- 把接受或拒絕的理由連到證據，不只連到會議結論。
- 比較衝突訊號；證據無法解決時就保留矛盾。
- 需求進入 PRD 草稿前，先標記無依據或已過期的內容。
有界的產品研究知識工作流
wenlan status
wenlan sources add ~/Research/product-notes
/distill <產品決策>
/pages <產品決策>
/lint
/curate04
證據可檢查後才開始寫 PRD
PRD 可以整理證據庫，但不應用流暢文字遮住證據。審查前確認每個需求都有來源路徑或明確的未解標記，每個重要假設都有負責人或下一個檢查，每個過往決策仍符合目前的來源集合。
即使不使用 Wenlan，這仍是一套實用的產品研究方法：小型證據登錄表、需求到來源的對照、矛盾記錄、假設清單與決策歷史，都能讓審查者重做判斷。
05
知道這個工作流不會自動化什麼
Wenlan 不會轉錄會議、遮蔽個人識別資訊、招募研究參與者、匯入分析資料、連接 Jira、Linear、Slack 或 CRM，也不會自動排序機會、產生完整 PRD、選擇路線圖或聲稱產品結果。這些決策與控制仍需要維護中的來源和人工審查。
它也不能讓沒有依據的要求變成事實。保持來源、主張、日期、限制與審查狀態可見，讓 Agent 協助整理證據，但不要取代產品團隊的判斷。
讓一個產品決策可追溯
從核准的來源集合開始，把需求連到有日期的證據，並在 PRD 審查前保留矛盾與待解問題。
FAQ