---

name: cn-prd-review language: zh description: "按中国互联网团队的方式准备和召开需求评审（PRD 评审会）：一份研发、测试和设计都能挑战的预读材料，各角色会问的问题，会议流程，以及书面结论（通过 / 有条件通过 / 不通过）。当被要求帮我准备需求评审、PRD 评审会怎么开、评审前检查一下我的 PRD、研发会问什么问题时使用。产出 PRD 就绪度检查、按角色整理的问题清单和回答要点、60 分钟会议议程，以及含结论和后续事项的评审纪要模板。"

cn-prd-review 的简体中文翻译，英文版本为规范版本。

需求评审

在很多中国互联网公司，一个需求要通过评审才能进入开发：产品经理讲解 PRD，研发、测试、设计和运营提出质疑。评审不通过的原因很固定：范围不清、边界情况缺失、没有埋点方案、排期没有共识。这个技能在会前检查 PRD，演练问题，并把会议开到有书面结论为止。

除非另有要求，用简体中文写。要写 PRD 本身，见 prd-template。

产出内容

• 就绪度检查：对照评审人关注的内容检查 PRD，列出会前要补的缺口
• 按角色整理的问题清单（研发、测试、设计、运营、数据）和回答要点
• 60 分钟评审会议程
• 评审纪要：结论、待解决问题、负责人和日期

所需输入

如未提供，请询问：

• PRD 或其摘要
• 参会人：哪些角色，谁拍板
• 上线目标和固定日期
• 已知分歧或产品经理预计会有的风险

方法

1. 评审前自查。 PRD 应包含：背景与目标（有可衡量的目标）、用户与场景、需求范围（包括明确不做的部分）、功能说明（流程、状态、规则）、异常与边界（错误、空状态、权限、限制）、数据埋点（事件及其服务的指标）、非功能需求（性能、安全、合规）、上线计划（灰度、回滚）和待定问题。逐项标注齐全、部分或缺失。
2. 按角色准备问题。
   • 研发："这个规则的边界是什么？"、"历史数据怎么处理？"、"并发 / 性能要求是多少？"、"依赖哪些团队的接口？"
   • 测试："异常流程有哪些？"、"验收标准是什么？"、"兼容哪些端和版本？"
   • 设计："交互稿覆盖了哪些状态？"、"空状态和错误提示怎么写？"
   • 运营 / 数据："怎么衡量效果？"、"埋点谁来验收？"、"上线后多久复盘？"
3. 会议流程（60 分钟）。 5 分钟背景和目标；20 分钟讲解流程；20 分钟按角色答疑；10 分钟范围和排期；5 分钟当场复述结论。
4. 结论。 通过（进入排期）、有条件通过（指定事项在某日期前补齐后进入排期）或不通过（需要二次评审）三者之一，并写明原因。
5. 当天发纪要。 决定、待解决问题及负责人和日期、范围变化。

输出格式

评审前自查

| 模块 | 状态（齐全 / 部分 / 缺失） | 需要补充 |

预计问题清单

| 角色 | 问题 | 回答要点 | 需要提前准备的材料 |

评审会议程（60 分钟）

| 时间 | 环节 | 负责人 |

评审纪要

• 结论：通过 / 有条件通过 / 不通过（原因）
• 已确认：[决定]
• 待解决：| 问题 | 负责人 | 截止时间 |
• 范围变化：[新增 / 删减]
• 下一步：[排期、技术评审、二次评审]

质量检查

• 每个 PRD 模块都标注了齐全、部分或缺失，以及需要补充什么
• 问题清单覆盖了所有参会角色
• 不做的范围写明了，而不是默认
• 每个埋点事件都对应目标中的一个指标
• 结论是三种结果之一，并写明原因
• 每个待解决问题都有负责人和日期

反模式

• 花 50 分钟朗读 PRD。 提前一天发出去，会上用来答疑。
• "细节后面再定"。 没定义的规则会在开发中变成争论。把它们列为待解决问题并指定负责人。
• 没有埋点方案。 没有埋点，上线后就无法评估效果。
• 没有结论就散会。 没有书面结论的评审还会被重新争论。

示例触发语

• “明天需求评审，帮我看看 PRD 还缺什么。”
• “研发和测试一般会问什么问题？帮我准备一下。”
• “帮我准备一场和中国研发团队的 PRD 评审。”
• “帮我写这次评审会的纪要，结论是有条件通过。”