需求评审不是走过场，而是团队对齐的关键时刻。一场好的评审能让开发、测试、设计对目标有统一理解，减少后续返工。
评审前的准备
评审前至少提前一天发出文档，让参与者有时间预读。文档应该包含：
- 背景和目标：为什么要做这个需求，解决什么问题
- 用户场景：谁在什么情况下使用，期望达成什么
- 核心流程：主要交互路径，异常情况如何处理
- 验收标准：怎样算做完，怎样算做好
评审中的节奏
我通常按照这个节奏推进：
- 先讲背景和目标（3 分钟），确保每个人理解"为什么做"
- 过核心流程（15 分钟），聚焦主路径，不纠缠边缘 case
- 开放讨论（10 分钟），收集技术可行性和设计建议
- 明确行动项（2 分钟），谁在什么时间前完成什么
评审的目标是达成共识，不是证明自己是对的。保持开放心态，技术方案往往是团队一起碰撞出来的。
评审后的跟进
评审结束后当天发出会议纪要，包含决策结果和待办事项。文档按讨论结果更新后再次发出确认。这样能避免"会上说了但没人记得"的情况。
以上是我在多次评审中踩坑总结的经验。每个团队节奏不同，找到适合自己的方式最重要。