低保真和高保真原型在需求评审中承担不同的验证任务，选择依据是本次评审要回答的问题：确认信息结构、页面范围和主流程走向时用低保真；验证交互细节、状态切换和关键操作路径时用高保真。多数需求评审先用低保真确认方案骨架，再对高风险或高争议环节补高保真局部，避免整场评审被拖进视觉细节。
要点总览（TL;DR）
- 选择依据是本次评审要验证的问题：确认信息结构、页面范围和主流程走向时用低保真；验证交互细节、状态切换和关键操作路径时用高保真。
- 高保真原型的制作与返工成本更高，适合放在方案骨架已确认的阶段，用于收敛细节而非推翻方向。
- 两种原型可以组合：低保真定骨架，高保真验证关键路径，把高保真资源集中在风险最高、争议最大的环节。
- 评审前准备问题清单、原型标注、方案状态标记和需求说明，评审中按原型精度控制讨论边界，结论分为通过、修改、待验证三类。
- 评审结论转为需求工作项与待办，原型版本与需求条目关联，待验证项在后续评审中逐条闭环。
两种原型在需求评审中各自回答什么问题
原型精度应当由评审目标决定。评审要确认“方案对不对、范围够不够”，低保真原型就足够；评审要确认“操作顺不顺、状态全不全”，才需要高保真原型。把原型做得更精细本身不构成评审质量的提升，只有与本次要验证的问题匹配，精细度才有意义。
低保真原型通常以线框、灰模或手绘形式呈现，弱化视觉样式，突出页面由哪些区块组成、信息如何排布、主流程从哪里进入又在哪里结束。它在评审中回答的是结构性问题：页面范围是否覆盖了业务场景、主流程走向是否符合业务预期、模块之间的跳转关系是否成立、哪些内容属于本期范围。参与者看到的是骨架，讨论自然集中在方案本身。
高保真原型接近最终界面，包含真实文案、控件样式和可点击的交互。它在评审中回答的是行为性问题：关键操作路径是否顺畅、状态切换是否完整、异常与边界情况如何呈现、表单校验和反馈是否符合预期。参与者可以直接操作原型，发现流程中的断点和歧义。
两种原型可以组合使用。常见做法是低保真定骨架、高保真验证关键路径：先用低保真把范围与流程评审通过，再针对争议集中或交互复杂的模块制作高保真局部，在后续评审中深入验证。组合的关键是明确每一轮评审各自要回答的问题，避免在同一场评审中混用两种精度而导致讨论失焦。
同口径差异对照：评审目标、成本与反馈类型
把两种原型放在同一组维度下对照，可以更快判断自己的评审场景落在哪一侧。下表按评审要验证的问题、制作与修改成本、参与者关注点、反馈类型和适用阶段五个维度展开。
| 对照维度 | 低保真原型 | 高保真原型 |
|---|---|---|
| 评审要验证的问题 | 信息结构、页面范围、主流程走向、模块关系 | 交互细节、状态切换、关键操作路径、异常与边界 |
| 制作与修改成本 | 较低，调整页面结构或流程分支的返工量小 | 较高，交互与状态改动往往牵动多个页面，返工量更大 |
| 评审参与者关注点 | 业务方关注范围与流程是否完整，开发关注模块划分 | 业务方关注操作是否顺手，开发关注状态与异常处理 |
| 反馈类型 | 集中在范围增减、流程分支、优先级排序 | 集中在交互路径、状态覆盖、提示与校验 |
| 适用阶段 | 需求早期、方案骨架尚未定型时 | 方案骨架已确认、需要敲定交互与状态时 |
成本差异直接影响评审节奏。高保真原型的制作周期更长，评审中一旦发现流程层面的问题，修改会波及多个页面和交互状态，返工成本明显高于低保真。因此高保真更适合放在方案方向已经稳定的阶段，用于收敛细节而非推翻方向。
使用对照表时要注意一个前提：表中描述的是两种原型在典型评审中的分工，具体项目仍以本次评审的问题清单为准。评审中尚未确认的交互或状态，应标注为待验证项，留到下一轮高保真评审或补充说明中处理，而不是在低保真评审上强行给出结论。
按评审场景选择：四类常见情形的取舍
对照结论落到具体评审情形，可以归纳为四类常见取舍。判断时先问本次评审最想解决的一个问题，再对照下表选择原型精度与组合方式。
- 新需求首次评审、范围未定：优先低保真。此时方案骨架还在讨论中，页面可能增删、流程可能改道，低保真能让参与者聚焦“做不做、做多少”，避免在视觉细节上消耗评审时间。
- 交互复杂或争议集中的模块：用高保真局部。例如多步骤表单、状态频繁切换的列表、涉及权限差异的操作页，仅靠线框难以说清行为，制作该模块的高保真原型可以让争议点在可操作的界面上被验证。
- 跨角色流程评审：低保真串联全流程，关键节点补高保真。跨部门流程涉及多个角色的交接，先用低保真把端到端流程串起来确认角色分工与交接点，再对交接密集或易出错的节点补高保真，验证具体操作。
- 时间紧或参与方多：控制高保真范围。参与方越多，评审中提出的细节问题越分散。此时只对最高风险的一到两个路径做高保真，其余部分保持低保真并明确标注待验证，保证评审按时收敛。
四类情形共享同一种组合逻辑：低保真定骨架，高保真验证关键路径。骨架未定时不急于做高保真；骨架确认后，把高保真资源集中在风险最高、争议最大的环节，其余部分以标注和说明补充。
评审前如何准备原型与评审材料
选定原型精度后，评审前的准备决定了讨论能否聚焦。准备工作围绕四类材料展开，建议在评审通知中一并发出。
- 问题清单：列出本次评审要回答的问题，按优先级排序，控制在参与者能逐条讨论的数量内。问题清单是控制讨论边界的依据，评审中偏离清单的话题记入待办而非当场展开。
- 原型标注：低保真原型标注页面范围、流程分支和跳转关系，说明哪些页面属于本期、哪些是后续规划；高保真原型标注状态切换、异常路径和校验规则，说明每个关键操作的预期反馈。
- 方案状态标记：在原型或说明文档中区分已定方案与待确认项。已定方案作为评审基线，待确认项逐条编号，便于评审中逐项给出结论。
- 需求说明与验收关注点：附上对应的需求说明，写明业务背景、目标用户和验收关注点，让参与者在看原型前理解方案要解决的问题，减少因背景信息缺失产生的误解。
材料准备完成后，建议自查一遍：问题清单中的每个问题，是否都能在本次原型上得到回答；原型上标注的待确认项，是否都有对应的讨论安排。若某个问题在当前精度下无法回答，应调整原型精度或将其移入下一轮评审。
评审中的引导与结论记录
评审过程中的引导要围绕原型精度设定讨论边界。低保真评审中，主持人应把“按钮颜色”“间距大小”一类话题引回范围与流程，记录为视觉待办即可；高保真评审中，讨论聚焦交互路径与状态覆盖，对原型未覆盖的异常路径明确记录为待补充，而非当场推断结论。
结论记录建议分为三类，每类对应不同的后续动作：
- 通过：方案在该问题上已确认，可作为后续设计与开发的基线。
- 修改：方案需要调整，记录修改点和责任人，明确下一版原型或需求文档的更新时间。
- 待验证：当前信息不足以结论，记录待验证的问题、验证方式和计划评审时间。
每条结论都应关联到具体的需求条目和原型页面，注明对应的原型版本。这样后续迭代时，团队能追溯某个交互或范围决策是在哪一轮评审、基于哪版原型确定的，减少重复讨论。评审结束后，主持人应在当天发出结论纪要，把三类结论分列清楚，并附上下一轮评审的时间安排。
从评审结论到方案落地：用工作项承接原型迭代
评审纪要发出后，结论需要进入可追踪的承接流程，否则“修改”和“待验证”两类结论容易在后续迭代中丢失。一种可行的做法是把每条结论转为需求工作项或待办：通过的结论更新需求状态，修改类结论生成带责任人和截止时间的任务，待验证项单独建项并标注计划验证的评审轮次。
原型版本与需求条目的关联同样重要。每轮评审使用的原型应保留版本记录，并在需求条目中注明对应版本，使后续修改有据可查。待验证项在下一轮评审中逐条闭环，关闭时记录结论依据，未关闭的顺延并说明原因。
在ONES中，需求可以作为工作项管理，评审结论、修改任务和待验证项以工作项或子项的形式挂在对应需求下，状态从待评审流转到已确认，原型版本与相关文档关联到需求条目，评审纪要和结论记录在需求详情中。这样，评审结论、原型迭代与需求状态在同一条链路上衔接，团队在后续迭代中可以直接查看某项需求的评审历史与当前状态。
常见问题
低保真原型评审时，参与者坚持讨论视觉细节怎么办？
主持人把这类话题记录为视觉待办，并说明当前原型精度不承载视觉结论，然后引导回问题清单。评审通知中提前写明本次要回答的问题，能减少这类偏离。若视觉细节确实影响方案判断，可将其列为待验证项，安排到高保真评审或单独的设计沟通中处理。
方案骨架还没定，但业务方要求先看高保真效果，如何协调？
可以先说明高保真在骨架未定时返工成本高，建议用低保真完成范围与流程确认，再对业务方最关心的模块做高保真局部。这样既回应了对方对效果呈现的诉求，也避免整版高保真随方案调整反复重做。协调的关键是把两轮评审各自要回答的问题写清楚。
一场评审里同时放低保真和高保真页面，会不会让讨论失焦？
混用本身可行，前提是明确每个部分要回答的问题。建议在评审材料中标注哪些页面用于确认范围与流程、哪些用于验证交互与状态，并按顺序推进：先过低保真部分，再进入高保真部分。若参与方较多、时间有限，可拆成两轮评审，分别对应两种精度。
评审结论中的待验证项，怎样避免在后续迭代中被遗忘？
把待验证项单独建为工作项，写明待验证的问题、验证方式和计划评审轮次，并挂在对应需求下。下一轮评审前逐条检查，关闭时记录结论依据，未关闭的顺延并说明原因。这样待验证项有明确的责任人和时间点，不依赖个人记忆。
原型版本需要保留到什么程度？
至少保留每轮评审实际使用的那一版，并在需求条目中注明对应版本。修改类结论产生新版本时，旧版本不必删除，保留记录便于追溯某项决策基于哪版原型确定。版本命名和存放位置在团队内统一即可，重点是需求条目能指向具体版本。
