产品方案评审与需求评审的分工，可以用一句话概括：方案评审判断“这个方案值不值得做、方向对不对、边界在哪里”，需求评审判断“这条需求写得清不清楚、能不能开发、怎么验收”。判断某内容归哪一层，看它是否改变方案的方向与范围；影响方向与范围的留在方案评审，只影响单条需求表述与验收细节的下放到需求评审。本文按这条标尺梳理两类评审各自回答的问题、方案评审的职责边界、应留与应下放的内容清单，以及边界模糊时的判断规则。
要点总览（TL;DR）
- 方案评审回答“值不值得做、方向对不对、边界在哪里”，需求评审回答“这条需求清不清楚、能不能开发、怎么验收”，判断标尺是内容是否改变方案的方向与范围。
- 应留在方案评审的内容包括业务目标与成功判断标准、方案范围与不做什么、关键用户流程与角色分工、方案层面的取舍与替代路径、跨模块依赖与影响面、主要风险与前提假设。
- 应下放到需求评审的内容包括单条需求的字段、文案与交互细节，验收条件与测试要点，需求拆分粒度与优先级排序细节，以及实现方式与技术改造细节。
- 边界模糊时依次判断：是否改变方案方向或范围、结论是否只影响单条需求的可执行性；仍无法判断就记为待定项，写清问题、责任人与影响范围，在需求评审闭环。
- 常见越界有三种：方案评审逐条过需求、方案评审完全不碰细节导致方向无法验证、需求评审重新讨论方案范围，都需要用清单和待定项机制纠正。
方案评审与需求评审各自回答什么问题
两类评审的差别，首先体现在它们要回答的核心提问上。方案评审面对的是一个尚未拆成需求条目的方案整体，它要回答的是：这个方案要解决什么业务问题，目标是否成立，覆盖哪些范围、明确不做什么，关键流程和角色分工是否走得通，在若干可选路径中为什么选这一条。需求评审面对的是已经拆好的单条需求，它要回答的是：这条需求的描述是否完整、字段与规则是否明确、开发能否据此实现、验收时用什么条件判定完成。
判断对象不同，决定了讨论的颗粒度不同。方案评审的判断对象是方案整体，讨论以“块”为单位，比如一条主流程、一个角色边界、一项跨团队依赖；需求评审的判断对象是单条需求，讨论以“条”为单位，比如某个字段的取值、某句提示文案、某个异常分支的处理方式。把单条需求的细节搬到方案评审上逐条过，会让方案层面的取舍被细节淹没；把方案范围拿到需求评审上重新讨论，则会让已经定下的方向反复摇摆。
| 对照维度 | 产品方案评审 | 需求评审 |
|---|---|---|
| 核心提问 | 方向对不对、范围合不合理、取舍是否成立 | 这条需求清不清楚、能不能开发、怎么验收 |
| 判断对象 | 方案整体 | 单条需求 |
| 讨论颗粒度 | 目标、范围、关键流程、角色与主要取舍 | 字段、规则、文案、交互、验收条件 |
| 结论形式 | 方案通过、修改或退回 | 单条需求是否清晰、可开发、可验收 |
| 参与角色重心 | 业务方、产品负责人、主要相关团队 | 产品、开发、测试及需求直接相关方 |
方案评审的边界：评审到哪一层为止
方案评审的起点是业务目标与问题定义，终点是形成一份方向明确、范围清楚、关键路径可验证的方案结论。它覆盖的层级包括：方案要达成的业务目标与成功判断标准；方案的范围边界，即做什么、不做什么；关键用户流程与主要角色分工；方案层面的取舍与替代路径；跨模块或跨团队的依赖与影响面；主要风险与前提假设。这些内容共同决定方案是否值得推进，缺一项都可能让后续需求建立在错误的前提上。
方案评审的结论形式是方案通过、修改或退回，而不是逐条裁决需求条目。评审结束时应当能回答：这个方案是否继续推进，需要修改哪些方案层面的内容，哪些问题作为待定项留给后续环节闭环。它不需要、也不适合在这一层确定每条需求的字段命名、提示文案、异常提示措辞或具体验收用例，这些属于需求评审的职责。方案评审对细节的触碰，以“足以验证方向成立”为限，例如用一条主流程走查来检验角色分工是否可行，而不是把主流程拆成几十条需求逐条讨论。
应留在方案评审的内容清单
以下内容影响方案的方向与范围，应留在方案评审中定下来，不下探到需求评审逐条讨论。
- 业务目标与成功判断标准。方案要解决什么业务问题、上线后用什么指标判断是否达成，这决定后续所有需求的取舍依据。目标不清，需求评审只能讨论表述，无法判断价值。
- 方案范围与不做什么。明确本期覆盖哪些场景、哪些用户、哪些端，同时明确排除项。范围是方案评审最核心的产出之一，需求评审只在该范围内讨论单条需求是否成立。
- 关键用户流程与主要角色分工。从用户进入到完成目标的主流程，以及业务方、产品、开发、运营等角色在流程中各自承担什么。流程走向和角色边界属于方案层，具体页面上的按钮位置和文案属于需求层。
- 方案层面的取舍与替代路径。在多个可行路径中为什么选当前方案，放弃了哪些替代方案及原因。这类取舍影响后续需求的整体设计，必须在方案评审中记录，避免需求评审时重新翻案。
- 跨模块或跨团队的依赖与影响面。方案涉及哪些系统、哪些团队配合、对现有功能有什么影响。依赖关系决定排期与协作方式，属于方案整体判断，不适合拆散到单条需求里各自讨论。
- 主要风险与前提假设。方案成立依赖哪些前提，存在哪些主要风险及应对方向。风险与假设是方案能否推进的判断依据，应在方案评审中显性记录。
应下放到需求评审的内容
与上节互补，以下内容在方案评审中只需点到为止，具体判断交给需求评审完成。
- 单条需求的字段、文案与交互细节。字段名称与取值规则、提示文案措辞、页面交互的具体形式，属于单条需求的可执行细节，在需求评审中结合实现条件确定更合适。
- 验收条件与测试要点。每条需求在什么条件下算完成、需要覆盖哪些测试场景，由需求评审结合开发与测试的实际判断确定。方案评审只需确认成功判断标准的整体口径。
- 需求之间的拆分粒度与优先级排序细节。方案评审确定范围与主流程后，如何把方案拆成若干需求、先做哪条后做哪条、每条多大粒度，属于需求评审与排期环节的工作。
- 实现方式与技术改造细节。用什么技术方案实现、是否需要重构、接口如何设计，由开发在需求评审中评估。方案评审关注的是方案可行性与影响面，不替开发做技术选型。
下放不等于放任。方案评审对这些内容可以提出约束条件，例如“提示文案需与现有风格一致”“验收需覆盖异常分支”，但不在方案评审上逐条定稿。约束条件写清楚，需求评审才有判断依据。
边界模糊时的判断规则
实际评审中总有一些内容介于两层之间，比如某个流程分支是否需要单独设计、某项依赖是否算方案级风险。可以用三条规则依次判断。
- 看该内容是否改变方案方向或范围。如果讨论结果可能导致目标调整、范围扩大或缩小、主流程改道、关键取舍翻转，它就属于方案评审；如果讨论结果只在既定方向和范围内调整做法，就下放需求评审。
- 看结论是否只影响单条需求的可执行性。如果一项结论只改变某条需求的字段、文案、验收条件或实现方式，不影响其他需求与整体流程，它属于需求评审；如果一项结论会连带影响多条需求或跨团队协作方式，应回到方案评审确认。
- 无法判断时，先在方案评审记录待定项，再在需求评审闭环。记录待定项时写清三件事：待定的是什么问题、由谁负责在哪个环节给出结论、结论影响哪些需求。这样既不阻塞方案评审推进，也避免待定项在流转中丢失或被反复重议。
待定项的记录与流转需要载体。方案评审的结论、待定项及其责任人，可以在文档中形成评审记录，并把待定项转为可追踪的工作项，在需求评审时逐项闭环。ONES 的文档与工作项能力可以承载这类记录与流转；ONES Assistant 智能助手可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目、工作项、迭代和 Wiki 页面等工作上下文，并把自然语言指令转化为可追踪的工作、保存为工作项或 Wiki 页面，适合在评审记录整理与待定项登记这类动作中减少重复录入。具体可用范围以实际产品为准。
一个具体例子与常见误解
以一个“新用户引导方案”为例。方案评审阶段应确定：引导要达成的业务目标（例如提升新用户完成首个关键操作的比率）、成功判断标准、覆盖哪些新用户与哪些端、引导的主流程分几步、每一步由哪个角色或系统触发、本期不做哪些引导形式、与账号体系或消息推送等模块的依赖关系、以及主要风险（例如引导过长导致流失）。这些内容决定方案是否成立，评审结论是方案通过、修改或退回。
到了需求评审阶段，再逐条确定：每条引导提示的具体文案、按钮位置与交互形式、跳过与返回的处理规则、每条需求的验收条件与测试要点、需求拆分顺序与实现方式。方案评审对文案只需给出风格约束，不必逐句定稿。
围绕这个例子，有三种常见误解值得纠正。
- 误解一：方案评审逐条过需求。把已经拆好的需求条目搬到方案评审上逐条讨论，会让评审时间被细节占满，方案层面的范围与取舍反而没被认真讨论。纠正方式是方案评审只过方案整体与关键流程，需求条目留到需求评审。
- 误解二：方案评审完全不碰细节，导致方向无法验证。完全不看任何细节，方案可能停留在概念层面，无法判断主流程是否走得通。纠正方式是允许用少量代表性细节做走查验证，例如用一条完整主流程检验角色分工，但不展开到每条需求的文案与验收。
- 误解三：需求评审重新讨论方案范围。需求评审时对已定的范围提出异议并重新讨论方向，会让方案结论失效、排期反复。纠正方式是把范围异议作为待定项回到方案层面确认，需求评审在既定范围内解决表述与可执行性问题。
把这三类误解对照前面的清单检查，团队就能较稳定地判断：哪些内容应在方案评审定方向、定范围、定取舍，哪些内容应留给需求评审定表述、定验收、定实现。
常见问题
方案评审已经通过了，需求评审时发现某条需求做不了，应该回到方案评审吗？
先判断这条需求做不了的原因属于哪一层。如果只是实现方式受限、字段规则不清或验收条件缺失，在需求评审内调整即可，方案方向与范围不变。如果做不了意味着主流程走不通、关键取舍需要翻转，或者范围要扩大缩小，这就触及方案层，应把问题作为待定项回到方案评审确认，而不是在需求评审上直接改方案结论。回到方案评审时，带上具体受阻的需求和原因，便于快速判断是修改方案还是调整范围。
方案评审要不要请开发和测试参加？
建议请。方案评审虽然不裁决需求条目，但需要判断关键流程是否走得通、跨模块依赖是否成立、主要风险是否可控，开发和测试的参与能帮助在方案阶段发现可行性问题，避免方案通过后才发现主流程无法实现。参与方式可以区别于需求评审：开发在方案评审中重点评估技术可行性与影响面，测试关注成功判断标准是否可验证，具体字段、文案与用例留到需求评审再定。
待定项一直没人闭环，怎么避免？
关键在于记录待定项时写清三件事：待定的是什么问题、由谁负责在哪个环节给出结论、结论影响哪些需求。只写“待定”而不写责任人和闭环环节，待定项很容易在流转中丢失。可以把待定项转为可追踪的工作项，指定负责人和截止时间，在需求评审时逐项核对闭环情况。ONES 的文档与工作项能力可以承载这类记录与流转，ONES Assistant 智能助手可连接 ONES Project、ONES Wiki 与 ONES TestCase，把自然语言指令转化为可追踪的工作并保存为工作项或 Wiki 页面，适合评审记录整理与待定项登记这类动作，具体可用范围以实际产品为准。
小团队人手少，能不能把方案评审和需求评审合并成一次会？
可以合并会议，但建议保留两层判断。会议形式上一次开完，讨论顺序仍按先方案后需求推进：先确认目标、范围、主流程与取舍，形成方案结论，再在同一场会议里过需求条目。合并的风险是方案讨论被需求细节带偏，所以需要有人守住顺序，方案结论未定之前不进入逐条需求讨论。如果方案本身较复杂或涉及多个团队，仍建议分开评审，给方案层面的取舍留出充分讨论时间。
方案评审中提到的风险，需要在需求评审里逐条跟踪吗？
方案评审记录的主要风险与前提假设，应在方案层面明确应对方向和责任人。其中会落到具体需求上的部分，例如某个异常分支需要专门设计、某项依赖需要提前联调，可以转为需求或待定项进入需求评审跟踪；属于整体判断的风险，例如方案成立依赖某个业务前提，则在方案层面持续跟踪，不必拆成需求条目。区分标准是这条风险是否对应可执行的具体工作。
