产品方案评审与需求评审的边界，落在“评什么”和“要回答哪个决策问题”上：方案评审判断方向与做法是否成立，需求评审判断具体需求是否清楚、可做、可验收。会议先后、参会人员、文档篇幅都不能单独作为划分依据。本文给出两类评审的对象清单、结论形式和一个可迁移的例子，帮助团队把方向讨论与条目质量讨论分开处理。
要点总览（TL;DR）
- 方案评审判断方向与做法是否成立，对象是目标、范围、关键路径与取舍；需求评审判断条目是否清楚、可做、可验收。
- 划分依据是本次评审要形成的结论类型，会议先后、参会人员和文档篇幅都不能单独作为标准。
- 方案评审可以确认需求清单的范围与优先级，字段定义、异常分支细节、验收用例粒度应留到需求评审。
- 需求评审以方案结论为输入前提，发现与方案冲突时记录并回到方案层面确认，不在现场推翻方向。
- 方案评审与设计评审的区别在关注点：前者看做法是否成立，后者看呈现与交互是否合理。
一句话说清两类评审的分工
方案评审回答三个问题：为什么做、做成什么样、大致怎么做。它面向方案层面的目标、范围、关键路径与取舍，确认的是“这件事值不值得做、这个做法是否成立”。需求评审回答另一个问题：这一条需求写清楚了吗、能否开发与验收。它面向具体需求条目的描述质量与可验证性，确认的是“这条需求是否具备进入开发和测试的条件”。
把两者分开的判断口径可以归纳为一句话：看这次评审要形成的结论是什么。如果结论是“方向确认、范围确认、主要做法确认”，属于方案评审；如果结论是“这条需求可以开发、验收口径明确”，属于需求评审。同一场会议里两类议题都出现时，也应按结论类型分段处理，先确认方向，再逐条确认需求质量。
| 对比项 | 产品方案评审 | 需求评审 |
|---|---|---|
| 评审对象 | 方案层面的目标、范围、关键路径、取舍与风险 | 具体需求条目的描述完整性、验收标准、依赖与优先级 |
| 决策问题 | 为什么做、做成什么样、大致怎么做 | 这一条需求是否清楚、可做、可验收 |
| 典型产出 | 通过、带条件通过、退回补充 | 需求条目确认、修改意见、验收口径 |
| 越界的典型表现 | 逐条抠字段定义与异常分支 | 重新讨论方案方向与范围取舍 |
需要说明的是，方案评审可以确认需求清单的范围与优先级，例如确认本期做哪些需求、先做哪一类。这属于范围层面的决策，仍归方案评审。具体需求怎么写、验收用例细到什么程度，则留到需求评审处理。
方案评审管什么、不管什么
方案评审的对象是“做法是否成立”。它需要把方案的目标与价值假设摆出来，说明范围边界，包括本期做什么、明确不做什么，描述关键流程与涉及的角色，并交代主要取舍与风险。这些内容共同支撑一个判断：在当前资源和约束下，这个方向与做法是否值得推进。
方案评审应产出明确的结论形式，常见三类：
- 通过：方向、范围与主要做法获得确认，可以进入需求细化。
- 带条件通过：方向成立，但需补充某项论证、调整某段范围或补充风险应对，条件满足后进入下一阶段。
- 退回补充：目标不清、范围失控或关键取舍未交代，需要重新准备方案。
方案评审需要明确停止下探的界线。字段如何定义、异常分支如何处理、验收用例细到什么粒度，这些属于需求质量范畴，应留到需求评审。方案评审阶段可以指出“这里存在异常场景需要覆盖”，但不逐条敲定处理规则。界线划在这里的好处是：方向问题有足够时间讨论，细节问题在信息更完整的需求阶段处理。
一个实用的自检方法是看议题是否影响“做不做、做多大、大致怎么做”。影响这三类判断的，放在方案评审；只影响“这一条怎么描述、怎么验”的，留到需求评审。
需求评审管什么、不管什么
需求评审承接方案评审的结论，把已经确认的方向和范围转化为可开发、可验收的需求条目。它的典型对象包括：需求描述是否完整，前置条件、主流程与结果是否交代清楚；验收标准是否明确，能否据此判断完成；依赖关系是否识别，与其他需求或系统的衔接是否清楚；优先级是否与方案阶段确认的范围一致。
需求评审不以重新讨论方案方向为目标。如果评审中发现某条需求与方案结论冲突，处理方式是把冲突记录下来，回到方案层面确认，而不是在需求评审现场直接推翻方向与范围取舍。这样既保护方案结论的稳定性，也避免需求评审被方向争论拖长。
方案评审的结论是需求评审的输入前提。开会前应把方案结论、确认的范围与优先级作为背景材料提供给参会者，让需求评审从“方向已定”的起点开始，集中处理条目质量。缺少这一前提时，需求评审容易反复回到“要不要做”的问题上，两类评审的边界也就随之模糊。
两个相邻概念容易混在哪里
方案评审与需求评审的差异在对象层级与决策问题。方案评审处理的是方案整体，需求评审处理的是方案之下的具体条目。两者是上下游关系：方案评审的输出构成需求评审的输入，需求评审的结论又反过来检验方案范围是否可落地。
方案评审与设计评审的差异在关注点。方案评审关注做法是否成立，即目标、范围、路径与取舍是否合理；设计评审关注呈现与交互，即界面布局、操作流程、信息层级是否符合使用习惯与业务规则。设计评审通常在方案方向确认之后进行，它不重新论证要不要做这个功能，而是检查这个功能以什么形式呈现给用户。
| 评审类型 | 核心关注 | 典型决策 |
|---|---|---|
| 方案评审 | 做法是否成立 | 方向、范围、关键路径与取舍是否确认 |
| 需求评审 | 条目是否清楚可验收 | 这条需求能否进入开发与测试 |
| 设计评审 | 呈现与交互是否合理 | 界面与操作流程是否符合使用场景 |
视觉设计制作教程不在本文讨论范围。这里只做概念层面的区分，帮助读者判断一场评审会应当归入哪一类、应当形成什么结论。
一个具体例子：会员积分功能怎么分两次评审
假设团队计划为会员体系增加积分功能。按边界划分，这项工作可以拆成两次评审，各自处理不同层级的问题。
方案评审阶段讨论的是：做积分的目的是提升复购，积分范围包含获取与消耗两条主线，本期暂不做跨店结算，主要风险在于积分规则设计不当导致成本失控或用户套利。这一阶段形成的结论是方向确认、范围确认，可能附带条件，例如要求补充成本测算后再进入需求细化。
需求评审阶段讨论的是：积分获取规则的具体条件，如下单金额与积分比例的对应关系、不同会员等级的差异；积分过期如何处理，过期提醒的时点与方式；每条需求的验收标准，例如“下单满100元获得10积分，退款后积分同步扣回”如何验证。这一阶段不再讨论“要不要做跨店结算”，因为方案评审已经确认本期不做。
常见的误解是在方案评审上逐条抠字段与异常分支。例如在方向尚未确认时，就花大量时间讨论积分过期是按自然月还是按天计算。结果是方向问题被细节淹没，会议超时，关键取舍反而没有结论。另一种误解是在需求评审中重新推翻范围，例如临时提出“本期还是把跨店结算加上”，导致需求条目反复修改、开发排期失去依据。
两次评审的结论、需求条目与方案文档需要在同一处留痕并完成交接，避免结论散落在会议纪要和个人记录中。ONES 的文档与工作项管理可以承载这一过程：方案评审结论记录在方案文档中，需求评审确认的条目以工作项形式关联到对应方案，状态与修改意见随条目流转，后续开发与测试可以追溯到评审时的验收口径。这样，方向决策与条目质量各有归属，评审边界在协作工具中也有对应的落点。
把边界落到对象与决策问题上，团队就能在会前判断这场评审该讨论什么、该形成什么结论。方案评审守住方向与做法，需求评审守住条目质量与验收口径，两类评审各司其职，方向讨论不被细节打断，需求确认也不反复回到起点。
常见问题
方案评审已经确认了范围，需求评审时还能调整优先级吗？
可以调整，但要区分调整的性质。如果只是同一范围内条目顺序的微调，属于需求评审可以处理的内容，记录调整理由即可。如果调整涉及增删范围本身，例如把本期不做的内容重新纳入，就超出了需求评审的决策权限，应回到方案层面确认。
实际操作中，可以在需求评审前把方案确认的范围与优先级作为背景材料发给参会者，会上遇到范围类异议时先记录、不展开争论，会后由方案负责人判断是否需要补充一次方案确认。
小团队人手少，能不能把方案评审和需求评审合并成一次会？
可以合并召开，但建议按结论类型分段处理：先集中确认方向、范围与主要取舍，形成方案层面的结论，再逐条确认需求描述与验收口径。分段的意义在于让两类决策各有明确的结论，避免方向问题与细节问题互相打断。
合并时容易出现的风险是细节讨论挤占方向讨论的时间。一个可行的做法是给方案部分设定固定的时间盒，时间到先形成方向结论，细节议题转入需求部分继续。
方案评审时有人提出具体的字段和异常处理问题，应该怎么处理？
先判断这个问题是否影响“做不做、做多大、大致怎么做”。如果影响范围或关键路径，例如某个异常场景会显著改变方案复杂度，应当在方案评审中讨论并记录为风险或约束条件。如果只影响这一条需求怎么描述、怎么验证，就记录下来，留到需求评审处理。
会上可以用一句话回应：“这个点记下来，需求评审时逐条确认。”这样既不让提问者觉得被忽略，也守住了方案评审的讨论边界。
需求评审中发现需求与方案结论冲突，正确的处理顺序是什么？
先把冲突记录下来，说明冲突涉及哪条需求、与方案哪项结论不一致，然后暂停对该条需求的细节讨论，回到方案层面确认。方案层面确认后，再按新结论更新需求条目并重新评审。
不建议在需求评审现场直接表决推翻方案方向。需求评审的参会者构成和准备材料通常围绕条目质量，现场推翻方向容易缺少必要的论证信息，也会让已确认的方案结论失去稳定性。
方案评审的结论需要写到什么程度，才能作为需求评审的输入？
至少应包含四项内容：目标与价值假设、本期范围（做什么与明确不做什么）、关键流程与涉及角色、主要取舍与风险。结论形式应明确为通过、带条件通过或退回补充；带条件通过时，条件内容与满足时点也要写清楚。
这些内容的作用是让需求评审从“方向已定”的起点开始。如果方案结论只写了目标、没有写范围边界，需求评审就容易反复回到“要不要做”的讨论上。
