产品方案与原型评审的依据可以归为四类：目标与范围、需求与约束、方案与原型、验证与决策。方案负责人会前把它们汇总成一份评审包，评审中按“目标—方案—风险—结论”逐项确认，会后留下带负责人和时间的结论记录与待办。本文按准备、流程、分工、示例和完成检查五个部分展开，适用于产品、设计和技术共同参与的方案沟通场景。
要点总览（TL;DR）
- 评审依据分四类：目标与范围、需求与约束、方案与原型、验证与决策，每类材料都要对应到具体评审议题。
- 评审按会前分发评审包、会中按“目标—方案—风险—结论”推进、会后记录结论与待办三段组织，每段有明确完成标志。
- 方案负责人汇总评审包并记录结论，产品负责人确认目标，设计与原型作者讲方案，技术负责人质询可行性，主持人收敛结论。
- 评审完成的判定是议题全部有结论、待办有负责人和时间、遗留项有跟踪方式；依据不足时补材料再评或带条件通过。
- 常见缺口集中在目标不清、原型缺异常场景、无验证证据和结论无记录，会前自检可以提前拦截大部分问题。
评审前要准备哪几类依据
评审包的作用是让参与者在会前用同一套材料理解方案，并在会上围绕具体议题作出判断。判断一份材料该不该放进评审包，可以看它是否对应某个待确认的议题：能支撑“做什么、为什么做”的放进目标与范围类，能支撑“受什么限制”的放进需求与约束类，能支撑“怎么做”的放进方案与原型类，能支撑“凭什么相信可行”的放进验证与决策类。与议题无关的背景资料可以放在附录，不占用评审时间。
四类依据的最低内容
| 依据类别 | 最低内容 | 对应的评审议题 | 常见缺失 |
|---|---|---|---|
| 目标与范围 | 业务目标、要解决的用户问题、成功指标、本期范围与明确不做的边界 | 这个方案值不值得做，本期做到哪里为止 | 只有功能列表，没有目标和不做清单 |
| 需求与约束 | 需求来源、优先级排序、合规与安全约束、技术可行性结论 | 需求是否被完整覆盖，哪些约束不可突破 | 优先级靠口头约定，约束在评审时才提出 |
| 方案与原型 | 方案说明、关键流程、原型或线框图、异常与边界场景、数据与接口假设 | 方案能否支撑目标，异常情况如何处理 | 原型只画主流程，缺空状态、失败状态和权限差异 |
| 验证与决策 | 待验证假设、验证方式与已有证据、评审问题清单、上次评审遗留项 | 哪些判断还缺证据，本次要决定什么 | 假设未列出，结论依赖个人经验 |
四类材料之间需要能相互追溯。目标中的成功指标应当在方案里有对应的流程或功能承载；需求优先级应当能解释原型中哪些场景做得细、哪些先简化；验证清单中的假设应当指向方案中具体的页面或规则。缺少这种对应关系时，评审容易变成逐页看原型，讨论停留在视觉细节上。
依据与议题的对应关系
评审包首页建议放一张议题表，列出本次要确认的问题、每个问题对应的材料和期望的结论类型。例如“本期是否支持多角色审批”对应需求优先级与流程原型，“异常订单如何处理”对应异常场景说明与数据假设。议题数量控制在评审时长能覆盖的范围内，通常一次评审聚焦三到五个关键决策点，其余问题转为会后书面确认。这样安排后，参与者预读时有明确目标，会上也能按议题收敛，避免在次要细节上消耗时间。
按步骤组织一次方案与原型评审
评审流程分为会前、会中、会后三段。每一段都有明确的输入、动作、输出和完成标志，缺少任何一段，评审都难以形成可执行的结论。
会前：确定议题并分发评审包
输入是四类依据的初稿和上次评审的遗留项。动作包括：方案负责人整理评审包，按议题表归口材料；主持人确认参会角色和决策人；提前至少一个工作日分发，并给出预读要求，例如“请重点看异常场景部分并准备意见”。输出是一份版本明确的评审包和参会确认。完成标志是决策人确认已预读，且议题表没有遗漏需要当场决定的问题。
会中：按目标、方案、风险、结论推进
输入是评审包和议题表。会议按四步推进：
- 目标确认。由产品负责人复述业务目标、成功指标和本期边界，参会者对“为什么做、做到哪里”达成一致。输出是确认后的目标表述，若目标本身有分歧，应先解决目标再进入方案。
- 方案讲解。由设计与原型作者按关键流程讲解方案，重点说明主流程、异常与边界场景、数据与接口假设。输出是参会者对方案范围的一致理解。
- 风险与假设质询。技术负责人、业务或客户代表针对可行性、约束和未验证假设提问，方案负责人记录问题与回应。输出是一份风险与待验证假设清单。
- 结论收敛。由主持人逐项对照议题表，明确每项议题的结论类型：通过、带条件通过或退回补充。输出是口头确认的结论和待办分工。
完成标志是议题表上每一项都有明确结论，没有“会后再看”的悬置项；带条件通过的事项写清条件和验证时点。
会后：记录结论并跟踪待办
输入是会议记录和议题表。动作包括：方案负责人在一个工作日内整理结论记录，写明结论类型、决策人、待办负责人和完成时间；遗留项登记跟踪方式，例如纳入下次评审议程或指定书面确认人。输出是一份可查阅的结论记录和待办清单。完成标志是所有待办都有负责人和时间，遗留项有明确的关闭条件。
评审包、结论记录和待办如果分散在聊天记录和个人文档中，后续追溯成本会很高。ONES 的文档与工作项协作可以承载这类过程：评审包作为文档集中存放并保留版本，结论记录关联到对应的工作项，待办以任务形式分派负责人和截止时间，遗留项在后续迭代中持续可见。这样做的价值在于让评审结论与执行动作保持在同一处可查，减少“评审过了但没人跟进”的情况。
角色分工与各自交付物
评审中的角色可以按“提供依据、作出判断、组织过程”三类职责划分。决策人与建议人需要区分：决策人对结论负责，建议人提供专业意见但不替代决策。
| 角色 | 会前提交的材料 | 会中职责 | 会后交付物 |
|---|---|---|---|
| 方案负责人 | 汇总评审包，维护议题表 | 讲解方案整体思路，记录问题与结论 | 结论记录、待办清单、遗留项登记 |
| 产品负责人 | 业务目标、用户问题、成功指标、范围与不做边界 | 确认目标，判断需求优先级 | 目标与范围的最终表述 |
| 设计与原型作者 | 关键流程、原型或线框图、异常与边界场景 | 讲解交互与流程细节，回应场景问题 | 按结论修订原型，标注修改点 |
| 技术负责人 | 技术可行性结论、数据与接口假设、约束说明 | 质询可行性风险，给出实现条件 | 技术风险项与验证计划 |
| 业务或客户代表 | 需求来源、业务规则、合规要求 | 确认业务场景与约束，判断方案是否解决实际问题 | 业务侧确认意见 |
| 评审主持人 | 参会名单、议程与预读要求 | 控制节奏，逐项收敛结论 | 确认结论记录完整并分发 |
决策人通常由产品负责人或业务负责人担任，对“做不做、做到什么程度”拍板；技术负责人对可行性判断有建议权，当技术约束与目标冲突时，应把冲突显式记录并交由决策人权衡。主持人与方案负责人可以由同一人兼任，但在议题较多时分开更有利于控制讨论节奏。角色划分不必与职级挂钩，关键是每类依据都有明确的提交人和确认人。
示例：一次原型评审的依据与结论记录
以下为演示情景，用于说明依据如何支撑结论，不代表真实项目。
背景与议题。某内部审批工具计划在下一版本增加“批量审批”能力。本次评审需要确认三个议题：批量审批是否纳入本期范围；审批失败时如何提示；是否需要支持跨部门批量操作。
提交的依据材料。产品负责人提交了目标说明：将单条审批的平均操作时间从数分钟压缩到更短，成功指标是批量操作使用率和审批积压量下降；范围明确本期只做同一部门内的批量通过，不做批量驳回。设计与原型作者提交了主流程原型、失败状态页面和权限差异说明。技术负责人提交了接口批量处理的可行性结论，指出单次批量上限受后端限制。业务代表提交了审批规则和合规要求，说明跨部门审批涉及额外授权。验证清单中列出一条待验证假设：用户是否愿意一次处理超过二十条审批。
评审中暴露的假设与风险。讨论集中在两点：原型只画了全部成功的状态，部分失败时如何展示未处理条目没有说明；跨部门批量操作被业务代表指出需要额外授权，本期不具备条件。技术负责人补充批量上限的具体数值需要压测确认，属于待验证项。
结论记录与待办写法。结论记录可以写成：“议题一：批量审批纳入本期，范围限同一部门内批量通过，结论为带条件通过，条件为补充部分失败状态的原型并完成批量上限压测，责任人为设计与原型作者、技术负责人，验证时点为下次评审。议题二：部分失败提示方案退回补充，下次评审确认。议题三：跨部门批量操作不纳入本期，记入后续版本候选。”待办逐条对应负责人和时间，遗留项登记为下次评审的首项议程。这份记录让每个结论都能追溯到具体依据和后续动作。
评审完成检查与常见缺口
判断一次评审是否完成，可以逐项核对以下条件：议题表上每项议题都有结论，且结论类型明确为通过、带条件通过或退回补充；带条件通过的事项写清了条件、责任人和验证时点；所有待办都有负责人和完成时间；遗留项有跟踪方式，例如纳入下次议程或指定书面确认人；结论记录已分发给参会者和相关干系人。五项全部满足，评审才算闭环。
依据不足时的处理
评审中发现关键依据缺失时，有两种处理方式。若缺失材料直接影响核心决策，例如目标未定义或技术可行性没有结论，应退回补充材料后重新安排评审，避免在信息不全的情况下作出判断。若缺失材料只影响局部细节，可以选择带条件通过，但必须当场写明条件内容、补齐责任人和验证时点，并在下次评审或书面确认中核验。两种方式都需要记录在结论中，不能以“先做着看”代替明确结论。
常见缺口
- 目标不清。评审包只有功能清单，没有业务目标、成功指标和不做边界，导致讨论无法判断取舍。
- 原型缺异常场景。只覆盖主流程，空状态、失败状态、权限差异和边界数据没有呈现，问题留到开发阶段才暴露。
- 无验证证据。关键假设未列出，或列出了但没有验证方式和已有证据，结论只能依赖个人经验。
- 结论无记录。会上口头达成一致，会后没有书面结论和待办，过一段时间无人记得决定了什么。
这些缺口大多可以在会前检查中拦截。方案负责人在分发评审包前，按四类依据逐项对照最低内容做一次自检，把缺失项补齐或标注为本次评审的待确认问题，能显著减少会上临时补材料的情况。
常见问题
评审包应该在会前多久分发，预读要求怎么写才有效？
建议至少提前一个工作日分发，让参与者有时间读完材料并形成意见。预读要求要落到具体位置，例如“请重点看异常场景和权限差异部分，准备一条以上意见”，比“请提前阅读”更容易执行。分发时同时附上议题表，让参与者知道会上要决定什么，预读才有方向。
评审中目标本身就有分歧，还要继续讨论方案吗？
建议先解决目标分歧，再进入方案讨论。目标未达成一致时，方案层面的取舍缺少判断标准，讨论容易变成各说各话。主持人可以把目标确认单独作为一项议题，由产品负责人说明业务目标和成功指标，决策人当场明确本期边界，确认后再继续方案讲解。
带条件通过和退回补充材料，应该怎么选？
看缺失材料是否影响核心决策。目标未定义、技术可行性没有结论这类情况，直接影响方案是否成立，应退回补充材料后重新安排评审。只影响局部细节的问题，例如某个异常状态的展示方式，可以选择带条件通过，但要在结论中写明条件内容、补齐责任人和验证时点，并在下次评审或书面确认中核验。
评审结论记录由谁写，需要包含哪些内容？
通常由方案负责人在会后一个工作日内整理。记录应包含每项议题的结论类型（通过、带条件通过或退回补充）、决策人、待办负责人和完成时间，以及遗留项的跟踪方式。结论要能追溯到对应依据，例如“补充部分失败状态原型”对应原型缺异常场景的问题，这样后续核验时有据可查。
评审包和结论记录放在哪里，后续才好追溯？
关键是让材料集中存放并保留版本，结论与待办和后续执行保持关联。ONES 的文档与工作项协作可以承载这类过程：评审包作为文档集中存放，结论记录关联到对应工作项，待办以任务形式分派负责人和截止时间，遗留项在后续迭代中持续可见。具体使用方式可结合团队现有的文档与任务管理习惯确定。
