文章封包
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