产品方案评审的问题要关闭，先要回答一个判断：修改是否真的消除了原问题，并且没有带出新的不一致。可执行的做法是要求每条问题在关闭前备齐四类证据——修改后的方案或原型版本、问题提出人的确认、关联影响面复查结论、验证与关闭记录；验证人优先由问题提出人担任，责任人只负责修改，不自行判定关闭。
要点总览（TL;DR）
- 关闭前验证要备齐四类证据：修改后的方案或原型版本、问题提出人的确认、关联影响面复查结论、验证与关闭记录归档。
- 按“问题登记—分配责任人与期限—提交修改—提出人复核—影响面复查—关闭归档”六步推进，每步都有明确的完成标志。
- 责任人与验证人分离：责任人负责修改并标注版本，验证人优先由问题提出人担任，缺席时由评审主持角色代行并留痕。
- 出现无提出人确认、无版本记录、影响面未复查三种情况之一，问题不得关闭；期限未到且未说明延期原因的也暂不关闭。
关闭前验证要核对哪四类证据
评审问题从“已修改”到“可关闭”，中间隔着一组能被他人复核的证据。缺少任何一类，关闭动作都只是状态变更，无法证明问题已消除。以下四类证据构成关闭前的核对基准。
| 证据类型 | 核对内容 | 判断口径 |
|---|---|---|
| 修改后的方案或原型版本 | 问题所指向的页面、流程或字段在哪个版本、哪个位置完成了修改 | 能定位到具体版本号或文档位置，且修改内容与问题描述对应；仅有口头说明不算 |
| 问题提出人的确认 | 提出人是否认可原始诉求已被满足 | 提出人给出明确的“通过”结论；提出人缺席时按代行规则留痕，不能由责任人代填 |
| 关联影响面复查 | 关联页面、流程、字段及上下游方案是否因本次修改出现新的不一致 | 列出复查范围与结论，范围至少覆盖问题所在模块的直接关联项 |
| 验证记录与关闭结论归档 | 复核意见、复查结论、关闭时间与关闭人是否记录在案 | 记录可被后续评审或追溯查阅，关闭结论与证据一致 |
这四类证据的顺序有讲究：版本证据是前提，提出人确认是核心，影响面复查防止局部修复引发新问题，归档则让关闭结论可追溯。实际操作中，最常见的缺口是只有版本记录、没有提出人确认，或者修改完成后直接改状态、跳过影响面复查。
从问题登记到关闭的六步操作流程
把上述证据嵌入流程，每条评审问题按六步推进。每一步都应有明确的输入、动作、输出和完成标志，避免流程停在“已修改”状态无人推进。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 问题登记 | 评审现场记录、方案文档 | 写清问题描述、所在方案位置（页面/流程/字段）、提出人、严重程度 | 一条可独立追踪的问题条目 | 问题描述具体到可定位，提出人明确 |
| 2. 分配责任人与期限 | 问题条目、方案迭代计划 | 指定修改责任人，结合严重程度与迭代节奏设定修改期限 | 责任人与期限字段 | 责任人和期限均已填写，无空白项 |
| 3. 提交修改 | 问题条目、方案或原型 | 责任人完成修改，在问题条目中标注修改版本与位置 | 修改后的方案版本及版本标注 | 版本可定位，修改内容与问题对应 |
| 4. 提出人复核 | 修改版本、原始问题描述 | 提出人对照原始诉求判断是否消除，给出通过或退回结论 | 复核意见 | 结论明确为通过或退回，退回时写明原因 |
| 5. 影响面复查 | 修改版本、关联方案清单 | 复查关联页面、流程、字段与上下游方案的一致性 | 影响面复查结论 | 复查范围与结论均已记录 |
| 6. 关闭归档 | 前五步的全部记录 | 更新问题状态为已关闭，归档验证记录与关闭结论 | 关闭记录 | 状态更新，关闭人与关闭时间可查 |
流程中有两个容易断点的地方。一是第3步到第4步之间：责任人提交修改后若无人提醒复核，问题会长期停留在待验证状态，建议在提交修改时即通知提出人。二是第5步：影响面复查常被简化为“看过了”，应要求写出复查范围，哪怕只有一行，也能让后续追溯有据可依。
当团队使用工作项或文档系统承载评审问题时，可以把问题描述、所在方案位置、责任人、期限、修改版本和关闭状态作为条目字段管理，让状态流转与证据记录留在同一处。ONES 的工作项与文档能力可用于承载这类登记与状态跟踪，具体字段配置与操作方式以实际产品资料为准。
责任人、期限与验证人如何分工
关闭验证失效的常见原因是责任人与验证人合一：修改的人自己判断问题已解决，然后关闭。分工的基本原则是修改与验证分离，验证人对“问题是否消除”作出判断，责任人对“修改是否完成”负责。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 问题提出人（默认验证人） | 提出问题时写清诉求；修改后判断问题是否消除，给出通过或退回结论 | 问题描述、复核意见 |
| 修改责任人 | 按期限完成修改，标注修改版本与位置，提交复核 | 修改后的方案或原型版本、版本标注 |
| 评审主持角色 | 把关期限设定与延期说明，确认关闭结论证据齐全，处理验证人缺席时的代行安排 | 期限确认、代行记录、关闭结论确认 |
| 影响面复查人 | 复查关联页面、流程、字段与上下游方案的一致性 | 影响面复查结论 |
验证人优先由问题提出人担任，因为提出人最清楚原始诉求的边界。提出人因调岗、休假等原因无法确认时，由评审主持角色代行验证，并在关闭记录中注明代行原因和判断依据；代行不等于降低标准，仍须对照原始问题描述逐项核对。
期限设定应结合问题严重程度与方案迭代节奏：影响主流程的问题应在下一版方案定稿前完成修改，表述类问题可随迭代批量处理。期限到期未完成时，责任人说明延期原因并重新约定时间，问题保持打开状态；直接关闭或无限挂起都会让评审结论失真。
一个方案评审问题的完整关闭示例
以下示例为演示情景，用于说明关闭记录如何填写，不指向具体项目。
问题描述：订单提交页在收货地址为空时仍可点击提交，缺少必填校验提示。所在位置：订单提交页原型 v1.2，地址选择模块。
提出人与责任人：提出人为交互评审参与人，责任人为该模块的产品设计人员，期限设定为下一版原型评审前。
修改内容与版本：在订单提交页原型 v1.3 中，地址为空时提交按钮置灰，并在地址模块下方增加“请选择收货地址”提示。版本标注：v1.3，地址选择模块。
提出人复核意见：已核对 v1.3，地址为空时无法提交且有提示，原始诉求已满足，结论为通过。
影响面复查结论：复查了订单确认页与地址管理页，两处均引用同一地址状态，未发现新的不一致；优惠券选择流程不依赖地址字段，不在本次复查范围。
关闭记录：关闭时间与关闭人随记录归档，问题状态更新为已关闭，验证人为问题提出人，无代行情况。
这条记录的价值在于每一栏都能被第三人复核：版本可查、结论有依据、复查范围有边界。若提出人复核意见只写“已改”，或影响面复查一栏空白，这条问题就不应关闭。
关闭前的完成检查清单
评审主持角色在确认关闭前，可逐项勾选以下检查项。任一阻断项未满足，问题保持打开状态。
- 修改后的方案或原型版本已记录，且能定位到具体位置。
- 问题提出人已给出明确的通过结论；如为代行验证，代行原因与依据已记录。
- 验证人不是本次修改的责任人。
- 影响面复查已覆盖关联页面、流程、字段及必要的上下游方案，结论已记录。
- 期限已到并完成修改，或期限未到但有明确的延期原因与新约定时间。
- 验证记录、复核意见与关闭结论已归档，问题状态已更新。
阻断条件：无提出人确认、无版本记录、影响面未复查，三者任一出现即不得关闭。期限未到且未说明延期原因的，同样暂不关闭，先补齐说明再判断。把这些条件写进评审规则，关闭动作才有统一口径，评审结论也才能在后续迭代中被追溯和复用。
常见问题
问题提出人已经离职或长期不在项目里，验证人怎么安排？
由评审主持角色代行验证，并在关闭记录中写明代行原因和判断依据。代行时仍要对照原始问题描述逐项核对，不能因为提出人不在就放宽标准。如果原始问题描述本身写得模糊，先补齐问题描述再验证，避免代行判断失去参照。
修改期限到了但责任人还没改完，问题应该怎么处理？
保持问题打开状态，由责任人说明延期原因并重新约定完成时间，评审主持角色确认新的期限。直接关闭会让评审结论失真，无限挂起则会让问题在后续迭代中被遗忘。延期原因和新期限都应记录在问题条目中，便于下次评审时追溯。
影响面复查要查到什么范围才算够？
至少覆盖问题所在模块的直接关联项，包括关联页面、流程、字段以及引用同一数据的上下游方案。复查结论要写出范围和判断，哪怕只有一行。范围写清楚，后续追溯才有依据；只写“已看过”无法支撑关闭结论。
小问题也要走完整的六步流程吗？
流程可以按问题严重程度裁剪，但验证人与责任人分离、版本记录、提出人确认这三项建议保留。表述类问题可以随迭代批量处理，影响主流程的问题应在下一版方案定稿前完成修改。裁剪的是节奏和复查深度，关闭前的基本证据不宜省略。
评审问题记录放在文档里还是工作项里更合适？
取决于团队已有的协作习惯。问题需要分配责任人、跟踪期限和状态流转时，放在工作项中管理更便于推进；问题讨论和方案上下文较多时，放在文档中记录更完整。也可以两者结合：文档承载方案与评审记录，工作项承载问题条目与关闭状态。使用 ONES 时，工作项与文档能力可用于承载这类登记与状态跟踪，具体字段配置与操作方式以实际产品资料为准。
