第 9 课：需求评审与迭代

第二章：需求定义与文档 | 第 9 课

课前思考

PRD 写好了，接下来做什么？是直接丢给开发（或 AI）开始写代码吗？大部分团队在这个环节会跳过一个关键步骤——需求评审。结果往往是：需求理解不一致，返工成本巨大。

一、为什么要做需求评审

需求评审不是走流程。真正的需求评审要实现三个目标：

对齐理解：确保所有人对「我们要做什么」的理解一致
发现盲点：让不同角色从各自视角挑出 PRD 中的遗漏
评估可行性：开发评估技术方案，设计评估交互合理性

AI 时代的需求评审

在 AI 辅助开发中，需求评审变得更重要——因为 AI 会严格按照文档执行，不会「猜测你的意图」。PRD 中的模糊之处会被 AI 放大。

二、需求评审的流程

评审前准备

提前发 PRD 给参会者，要求提前阅读
准备评审议程：背景 → 核心需求 → 逐个功能 → 边缘情况 → 技术可行性
邀请必要角色：PM、开发、设计、测试

评审中要点

从用户视角出发，不是从功能视角出发
先讨论「要不要做」，再讨论「怎么做」
记录所有待办项（Action Items），明确负责人和截止时间

评审后迭代

根据评审意见修改 PRD
核心变更需要二次对齐
定稿后将 PRD 作为「单一事实来源」

课后练习

拿一份你之前写的 PRD，模拟一次需求评审——列出至少 3 个可能的遗漏点
用 AI 帮你把评审意见整合进 PRD

课程讨论

有问题或想法？欢迎在下方留言讨论。