原型评审出现严重分歧时，靠延长会议或反复争论通常解决不了问题。更有效的做法是把它转成一套可执行的机制：会中先给分歧定级，判断是否值得升级；需要升级的，按约定层级和时限逐级提交；裁决人依据事先写明的规则给出结论；最后由记录人把结论回写到原型和需求条目。这样，冲突有路径、有裁决人、有留档，团队不必每次重新谈判。
要点总览（TL;DR）
- 先按影响范围与可逆性给分歧定级：局部交互细节、方案路线、目标与范围三类，级别越高越应升级；两轮讨论无收敛、涉及跨团队资源或目标冲突、影响里程碑时触发升级。
- 升级路径设三级：一级由评审主持人与产品负责人当场裁决，二级由跨职能裁决小组在约定时限内复议，三级由业务或技术最终责任人一次性裁定，每级提交分歧陈述、双方证据、影响评估与待决问题。
- 裁决规则写明决定权按议题类型分配，依据优先级为目标与约束、用户证据、成本与风险、可逆性；平票或责任人缺席按代理人或维持现状并限期复议处理，结论仅在新证据或条件变化时走同一链路复议。
- 角色分工明确：主持人定级并控制时限，记录人整理分歧记录单与归档证据，裁决人给出结论与理由，产品负责人把结论回写到原型与需求条目，四者通过同一编号关联。
- 机制上线后更新评审模板，用最近几次评审回放验证定级与时限是否合理，定期复盘升级频率与裁决被推翻的比例，据此修订定级表和时限。
先分清哪些分歧值得升级：定级标准与触发条件
升级机制的第一步是判断分歧的性质。评审主持人需要在会中做出定级，把“意见不同”和“需要升级的严重分歧”区分开。定级的主要依据是影响范围和可逆性：改动越靠近目标与范围、越难回退，越应该升级；只涉及局部交互细节、改起来成本低的，优先在评审桌内解决。
| 级别 | 典型情形 | 判定人 | 处理方式 |
|---|---|---|---|
| 一级：局部交互细节 | 按钮位置、文案措辞、单页信息层级等可快速调整的差异 | 评审主持人 | 当场讨论，指定一人拍板并记录，不升级 |
| 二级：方案路线 | 两套流程方案、不同的信息架构、技术实现路径之争 | 评审主持人初判，产品负责人确认 | 一轮讨论未收敛即进入升级路径 |
| 三级：目标与范围 | 是否纳入某功能、是否改变本期目标、跨团队资源投入冲突 | 评审主持人提出，产品负责人确认 | 直接按升级路径提交裁决 |
升级触发条件建议写成可核对的条目：同一问题经过两轮讨论仍无收敛；分歧涉及跨团队资源调配或目标冲突；结论会影响里程碑或已承诺的交付时间。满足其中一条，主持人就应启动升级，而不是继续在会上消耗时间。
反过来，有些分歧不需要升级。能用数据快速判定的，比如埋点数据、用户访谈记录、可用性测试结果；能用小范围验证低成本试错的，比如做一个可点击原型让少量用户试用。这类分歧由主持人安排验证方式和负责人，设定反馈时间，在评审记录中标注“待验证”，避免占用高层裁决资源。
升级路径怎么排：从评审桌到最终裁决的层级与时限
升级路径建议设三级，每级明确输入、裁决人和输出，并给响应时限。层级过多会让问题在流程里打转，层级过少则容易把细节推到高层。
| 层级 | 裁决人 | 输入材料 | 响应时限 | 输出 |
|---|---|---|---|---|
| 一级 | 评审主持人 + 产品负责人 | 分歧陈述、双方理由、已有证据 | 评审会当场 | 裁决结论或升级决定 |
| 二级 | 跨职能裁决小组（产品、技术、业务/运营代表） | 一级记录、双方证据、影响评估、待决问题清单 | 约定时限内，例如两个工作日内 | 复议结论与理由 |
| 三级 | 业务或技术最终责任人 | 二级结论、未解决争点、影响评估 | 约定时限内，例如三个工作日内 | 一次性裁定，留档生效 |
每级升级都要提交统一材料，避免高层在信息不全时拍板。材料至少包括：分歧陈述（争的是什么、双方主张）、双方证据（数据、用户反馈、技术评估）、影响评估（对进度、成本、范围的影响）、待决问题（希望裁决人回答的具体问题）。材料由记录人整理，提交前经分歧双方确认无遗漏。
时限要事先约定，并写明超时默认处理方式。例如二级小组在时限内未给出结论，视为维持一级结论并进入限期复议；三级责任人在时限内未响应，由产品负责人按现有证据做出临时决定并标注“待最终确认”。默认规则的作用是防止流程卡死，同时保留后续修正空间。
裁决规则怎么写：决定权、依据优先级与结论效力
裁决规则要回答三个问题：谁定、按什么定、定了之后怎么算数。决定权按议题类型分配，比按职级分配更可预期。用户价值与范围类议题由产品负责人裁决，技术可行性类议题由技术负责人裁决，商业目标与资源投入类议题由业务负责人裁决。跨类型的复合分歧，由对应层级中最高一级责任人牵头，其他责任人提供书面意见。
裁决依据要有优先级，建议按以下顺序：目标与约束优先，先看是否违背本期目标和已确认的约束条件；其次看用户证据，包括访谈、测试、行为数据；再次看成本与风险，包括开发成本、维护成本和上线风险；最后看可逆性，同等条件下优先选择容易回退的方案。裁决人应在结论中写明依据了哪几条，便于后续复盘和复议时对照。
平票或责任人缺席要有预案。可以事先指定代理人，代理人拥有同等裁决权；无法指定时，按“维持现状并限期复议”处理，即保留当前原型方案，在约定期限内补充证据后再议。这条规则要写进制度，避免临时找人拍板。
裁决结论的效力需要明确：结论一旦形成，即对当前版本的原型与需求生效，相关方按结论执行，不再在后续会议中重复争论同一问题。复议只在新证据出现或外部条件变化时启动，且需走同一升级链路，由原裁决人或其上级受理。这样既保证结论的稳定性，也保留纠错通道。
角色与交付物：谁记录、谁裁决、谁回写
机制能否跑起来，取决于每个角色是否清楚自己的动作和产出。评审主持人是流程的发动机，负责会中定级、判断是否触发升级、组织材料提交并控制时限。主持人不需要对分歧内容表态，重点是让流程按规则推进。
记录人承担留档职责：把分歧陈述、双方证据、影响评估整理成分歧记录单，归档到团队可访问的位置；裁决形成后，把结论、理由和生效范围写入记录，并跟踪回写状态。裁决人负责给出结论并写明依据，结论要具体到可执行的程度，例如“采用方案A，保留风控确认步骤，支付步骤压缩为两步”。
产品负责人是把结论落到实处的角色：更新原型、修改需求条目、标注变更原因和裁决记录编号，确保开发和测试拿到的是裁决后的版本。交付物清单包括分歧记录单、裁决结论、原型变更记录和需求变更记录，四者通过同一编号关联，形成可追溯的链条。
在记录与回写环节，可以用 ONES 的工作项和文档来承载：把分歧记录单作为工作项附件或文档条目，裁决结论写入对应需求工作项的说明或评论，原型变更与需求变更通过关联关系保留追溯。这样，后续复盘时能直接查到某条需求为什么是现在这个方案。具体字段和操作方式可按团队现有配置调整。
一个完整示例：支付流程原型的两派分歧如何走完三级
以下为演示情景，用于说明机制如何运转，不代表真实项目结论。
某产品在评审支付流程原型时出现两派意见。一派主张简化支付步骤，把确认页与支付页合并，减少用户操作；另一派主张保留风控确认环节，认为合并后风险提示不足。双方各有理由，讨论两轮未收敛，影响本期上线里程碑。
主持人定级为“方案路线”级分歧，触发升级。一级由主持人与产品负责人当场处理：产品负责人听取双方陈述后，认为分歧涉及风控合规，超出自己的裁决范围，决定升级到二级，并指定记录人整理材料。材料包括：两套方案的原型截图、双方理由、风控团队的口头意见、对上线时间的影响评估，待决问题是“在满足风控要求的前提下，支付步骤能否压缩”。
二级跨职能小组由产品、技术、风控代表组成，在两个工作日内复议。小组按统一口径评估：目标与约束上，本期目标是提升支付转化，同时必须满足风控确认要求；用户证据上，可用性测试显示合并方案的操作步骤更少，但风险提示的可见性下降；成本与风险上，保留确认环节的开发成本更低；可逆性上，先保留确认环节、后续用数据验证再决定是否合并，回退成本低。小组结论为：保留风控确认步骤，优化确认页的信息呈现，把支付步骤从四步压缩为三步，并设定上线后两周观察转化数据。
结论回写到原型和需求条目：产品负责人更新原型，记录人把裁决结论、依据和复议条件写入分歧记录单，关联到对应需求工作项。复议条件写明：上线后两周转化数据若低于设定阈值，可凭数据申请复议，走同一升级链路。至此，一次严重分歧走完了定级、升级、裁决、回写的完整过程。
落地与检查：让规则真正跑起来
规则设计完成后，需要配套发布和检查，否则容易停留在文档里。第一步是把升级路径、时限和裁决规则写入评审制度，同步更新评审模板，在模板中增加分歧定级栏、升级材料清单和裁决记录字段，让主持人在会中直接使用。
落地检查可以按以下清单逐项核对：
- 每次评审是否记录了分歧定级结果，定级人与定级依据是否可查；
- 触发升级的分歧是否在规定时限内提交了完整材料，材料是否经双方确认；
- 每级裁决是否写明了结论、理由和依据条目，是否有裁决人署名；
- 裁决结论是否回写到原型和需求条目，变更记录是否与分歧记录单关联；
- 超时或责任人缺席的情况是否按默认规则处理，处理结果是否留档。
机制上线一段时间后，用最近几次评审做回放验证：挑出实际发生的分歧，对照定级标准看级别是否合理，对照时限表看响应是否及时，对照裁决记录看结论是否被后续执行推翻。回放的重点是发现规则与实际节奏不匹配的地方，比如时限过紧导致材料不全，或定级标准过宽导致小事频繁升级。
定期复盘两个指标：升级频率和裁决被推翻的比例。升级频率过高，说明定级标准偏松或会中讨论不充分；被推翻比例过高，说明裁决依据或裁决人配置需要调整。根据复盘结果修订定级表和时限，让机制随团队协作节奏持续校准。
常见问题
评审会上双方各执一词、都不肯让步，主持人应该先做什么？
主持人先做定级，而不是急着表态支持哪一方。按影响范围与可逆性判断：只涉及按钮位置、文案措辞这类可快速调整的差异，当场指定一人拍板并记录即可；涉及两套流程方案、信息架构或技术实现路径的，属于方案路线级，一轮讨论未收敛就进入升级路径；涉及是否纳入某功能、是否改变本期目标或跨团队资源冲突的，直接按升级路径提交裁决。
定级之后，主持人要明确记录双方主张和已有证据，并说明下一步由谁在什么时限内处理。这样会议不会停在争论上，双方也知道后续在哪里继续表达意见。
升级到二级小组后仍然无法达成一致，怎么办？
二级小组的职责是复议并给出结论，不是无限讨论。事先应约定响应时限，例如两个工作日内给出复议结论与理由。若时限内仍无法形成多数意见，按预设规则处理：由对应层级中最高一级责任人牵头裁定，其他责任人提供书面意见并留档；或者按“维持现状并限期复议”处理，保留当前原型方案，在约定期限内补充新证据后再议。
关键是把这条兜底规则写进制度，让参与者在升级前就知道无法达成一致时的走向，减少把问题继续往上推的动机。
裁决人给出的结论，后续还能不能推翻？
可以，但要有条件。裁决结论一旦形成，即对当前版本的原型与需求生效，相关方按结论执行，不在后续会议中重复争论同一问题。复议只在新证据出现或外部条件变化时启动，例如上线后的转化数据低于设定阈值、合规要求调整、资源约束发生变化。
复议需走同一升级链路，由原裁决人或其上级受理，并提交新证据和影响评估。这样既保证结论的稳定性，也保留纠错通道，避免结论被随意推翻或长期搁置。
团队规模不大、评审参与人不多，还需要设三级升级路径吗？
可以简化，但保留定级、裁决人、时限和留档四个要素。小团队里一级和二级可能合并为一次复议，由产品负责人和技术负责人共同处理；三级仍保留一个最终责任人，用于处理目标与范围类分歧。时限可以缩短，例如一个工作日内响应。
需要保留的是规则的可预期性：谁定、按什么定、多久给结论、结论怎么回写。参与人少时流程可以更轻，但不宜完全依赖会上临时协商，否则同一类分歧每次都要重新谈判。
分歧记录单和裁决结论应该记录到什么程度？
记录要能支撑后续复盘和复议，至少包含：分歧陈述（争的是什么、双方主张）、双方证据（数据、用户反馈、技术评估）、影响评估（对进度、成本、范围的影响）、待决问题、裁决结论与理由、裁决人和生效时间、复议条件。
结论要具体到可执行的程度，例如“采用方案A，保留风控确认步骤，支付步骤压缩为三步”，避免只写“同意方案A”。记录人把分歧记录单、裁决结论、原型变更记录和需求变更记录通过同一编号关联，形成可追溯的链条。在承载方式上，可以用 ONES 的工作项和文档存放分歧记录单与裁决结论，并与对应需求工作项建立关联，具体字段和操作方式按团队现有配置调整。
