技能提升网PRD 有背景、目标、用户故事、流程图、数据指标和排期，看起来一项不少。评审会上，开发仍然问边界，设计还在确认用户是谁，测试不知道异常状态如何判断。作者只能不断补充：“这个大家都知道。”
章节齐全不代表文档可用。PRD 的读者要据此估算、设计、开发、测试或批准范围。写作前先列出这些决定，再检查文档是否给了足够信息。
先列读者和决定
同一个项目里，不同读者关注的问题不同。工程负责人需要判断技术路径和依赖，设计师要理解任务与约束，测试人员要识别可验收状态，业务负责人则要确认投入是否值得。PRD 不必为每个人复制一遍背景，但要让关键决定有明确入口。
| 读者 | 要作出的决定 | 文档应提供 |
|---|---|---|
| 设计 | 交互如何覆盖主要任务 | 用户场景、状态、限制和研究证据 |
| 开发 | 如何实现并评估工作量 | 范围、数据、依赖、异常和接口边界 |
| 测试 | 什么结果可以通过 | 成功条件、例外情况和验收口径 |
| 业务 | 是否投入及何时停止 | 目标、成本约束、指标和风险 |
问题陈述不要偷偷带入方案
“用户需要一个智能提醒中心”已经决定了解法。问题陈述应说明用户在什么场景下遇到什么阻碍，造成什么影响，现有替代方式为何不够。这样团队还能比较提醒、流程调整或信息架构等不同方案。
用户研究证据、行为数据和业务约束应能回查。Atlassian 的 PRD 指南建议在需求文档中连接用户访谈、成功指标、假设和设计材料，并通过协作建立共同理解。证据链接可以放在内部系统中，正文只保留结论和定位信息。
范围要写到可以拒绝需求
只列“本期包含什么”很容易在开发中不断扩张。还要明确不在本轮范围的用户、渠道、状态和兼容条件。例如首期只支持单组织管理员，不处理跨组织账号迁移；只读取已确认数据，不自动修改源系统。
范围变化时记录谁决定、依据是什么、影响哪些指标和交付节点。这样后续复盘时能区分执行偏差和决策变化。
把指标写成可以计算的句子
“提升使用率”“改善体验”无法验收。指标至少要说明对象、事件、时间范围、数据来源和比较基线。若数据埋点尚未准备好，PRD 要把测量能力列为依赖，而不是假装上线后自然能看到结果。
成功条件也要有停止判断。某个实验没有达到预期时，是继续观察、修改方案还是回滚，需要在成本可控时提前讨论。否则团队容易只记录上涨的数据，忽略无效结果。
用协作流程处理作者盲区
Doc Co-Authoring Skill 会先收集文档类型、目标读者、希望产生的影响和现有限制，再按章节迭代。这个流程适合 PRD，因为作者脑中常有大量项目背景，读者却没有。
请协助我起草一份 PRD。
先列出设计、开发、测试和业务读者需要作出的决定，再检查我提供的材料是否足够。
优先处理问题定义、范围、成功条件、依赖和待决事项。
不要把功能名称当成用户问题，也不要补写没有证据的指标。
每个关键假设标明验证方式和负责人。
完成后模拟一位没有参加前期讨论的读者，列出他仍无法独立回答的问题。评审不只是收集“同意”
评审前让读者在文档里标出三类内容：无法理解、无法执行和需要决定。会议重点处理这些位置，不逐段朗读。对于未决定事项，记录负责人和截止时间；对于有争议的假设，安排验证而不是用更长的文字掩盖。
PRD 完成的标志不是所有章节都有字，而是目标读者不依赖作者临场解释，也能作出当前阶段需要的决定。
