阶段评审要回答“继续还是终止”，关键是把决策责任落到具体角色和可核对依据上：谁提出结论、谁提供证据、谁拍板、谁记录并跟踪条件项。下面用一个假设的研发项目阶段评审情景，完整演示决策责任表怎么填、每个字段为什么这样填，以及换到其他阶段时哪些做法可以迁移。
要点总览（TL;DR）
- 阶段评审决策责任表要承载四类信息：角色、证据、结论、条件项，缺一项决策就无法追溯。
- 决策人一栏只填一个最终拍板角色，证据栏写具体材料名称和版本，结论使用继续、有条件继续、终止、暂缓四类固定选项。
- 条件项必须带责任人和关闭时间，记录人把结论同步到工作项或文档，条件关闭状态才可核对。
- 迁移到其他阶段时只需替换阶段名称、证据清单和条件项内容，角色表与结论选项可直接沿用。
- 单次发布许可归发布审批与质量门禁，单需求评审归需求评审与确认，两类场景不套用这份责任表。
示例目标：这份决策责任示例要解决什么问题
本文演示的是一个假设情景，不是真实客户案例，也不代表任何实际项目的评审结果。设定如下：某研发项目准备从设计阶段进入开发阶段，项目组召开一次阶段评审，议题只有一个——是否允许项目进入下一阶段。围绕这个议题，我们要产出一张填好的阶段评审决策责任表。
这张表需要承载四类信息：角色（谁发起、谁提供证据、谁决策、谁记录）、证据（依据哪些材料做判断）、结论（继续、有条件继续、终止、暂缓）、条件项（附带什么约束、由谁在什么时间前关闭）。读者可以照着这个结构，替换成自己项目的角色和材料名称直接使用。
需要先划清边界：本示例只处理阶段性继续或终止的决策。单次发布许可属于发布审批与质量门禁的范畴，单个需求的评审确认属于需求评审流程，这两类场景有各自的决策人和证据要求，不套用本文的责任表。
完整示例：一次阶段评审的决策责任表
示例背景：项目代号“示例项目A”，当前处于设计阶段收尾，评审议题为“是否进入开发阶段”。参会角色与职责如下：
- 评审发起人：项目经理，负责组织评审、汇总材料、提出初步结论建议。
- 技术负责人：提供设计文档与关键技术方案，说明技术可行性。
- 质量负责人：提供验证结果与遗留问题清单，说明质量风险。
- 产品负责人：确认需求范围与优先级，说明进入开发后的范围约束。
- 决策人：研发总监，对继续或终止做最终决定。
- 记录人：项目助理，负责记录结论、条件项并同步到工作项。
证据清单包括：设计说明书（版本V1.2）、风险清单（含3项高优先级风险）、遗留问题列表（共8项，其中2项影响开发启动）、设计验证结果报告。填好的决策责任表如下：
| 字段 | 示例填写内容 |
|---|---|
| 评审议题 | 是否允许示例项目A从设计阶段进入开发阶段 |
| 评审发起人 | 项目经理（提出结论建议：有条件继续） |
| 证据提供方 | 技术负责人：设计说明书V1.2；质量负责人：验证结果报告、遗留问题列表；产品负责人：需求范围确认单 |
| 决策人 | 研发总监（唯一最终拍板人） |
| 决策结论 | 有条件继续 |
| 条件项1 | 关闭2项影响开发启动的遗留问题，责任人：技术负责人，关闭时间：进入开发后第5个工作日 |
| 条件项2 | 对3项高优先级风险制定应对方案，责任人：质量负责人，关闭时间：进入开发后第10个工作日 |
| 记录与跟踪 | 记录人将结论与条件项写入对应工作项，每周评审例会上核对关闭状态 |
结论选项固定为四类：继续、有条件继续、终止、暂缓补充材料后再议。本例选择“有条件继续”，因为设计主体已具备进入开发的条件，但存在必须在开发早期关闭的具体事项。条件项全部带责任人和关闭时间，记录人负责把结论同步到工作项，后续按周跟踪，直到条件项全部关闭。
逐项解释：每个字段为什么这样填
决策人一栏只填一个最终拍板角色。示例中填研发总监，而不是“评审委员会集体决定”。集体负责在记录上容易变成无人负责，出现争议时无法追溯是谁做的判断。如果组织确实采用多人表决，也应指定一人对最终结论签字确认，其余人作为证据提供方或建议方出现。
证据栏写具体材料名称和版本，不写“相关资料”。“设计说明书V1.2”可以核对，“相关资料”无法核对。版本号尤其重要，评审依据的是哪一版设计，直接决定结论的适用范围。材料名称写错或版本缺失，后续追溯时无法判断决策依据是否仍然有效。
结论栏使用固定选项。“基本通过”“原则上同意”这类表述在后续执行中会产生歧义：条件是否生效、谁来判断是否满足，都没有依据。固定为继续、有条件继续、终止、暂缓四类，跨阶段对比时也能直接统计各阶段的决策分布。
条件项必须带责任人和关闭时间。没有责任人的条件项无人推进，没有关闭时间的条件项永远处于“进行中”。示例中两项条件分别指定技术负责人和质量负责人，并给出工作日口径的关闭时间，评审后可以直接核对。
记录人负责同步与可追溯。结论和条件项如果只停留在会议记录里，执行阶段很容易脱节。记录人需要把结论写入对应工作项或评审文档，让条件项的关闭状态可以被查询和核对。在ONES中，这类评审结论和条件项可以承载在项目的工作项与文档里，条件项作为待关闭事项持续跟踪，评审记录与项目进展放在同一处，便于后续复查。具体使用方式按团队现有的工作项和文档组织习惯安排即可。
必填与可裁剪字段。评审议题、决策人、决策结论、条件项（如有）、记录人属于必填，缺一项决策就无法追溯。证据提供方可以按阶段裁剪，例如早期阶段材料较少时可合并为一份阶段输入清单；参会角色名单可以简化，但决策人和记录人建议始终保留。
可迁移规律：换阶段、换项目怎么复用
这套示例的价值在于结构，而不是具体内容。迁移到其他阶段评审时，可以遵循以下规律：
- 决策责任与证据责任分离。提供材料的人负责把事实说清楚，拍板的人负责做取舍。两者合一，评审容易变成材料提供者的自我确认。
- 每次阶段评审只回答一个问题。“是否进入下一阶段”是阶段评审的议题，范围变更、发布许可、单个需求确认都应放到各自的流程里，避免一次会议承担多个决策。
- 结论选项和条件项格式保持统一。四类结论、条件项带责任人和关闭时间，这套格式在各阶段保持一致，跨阶段对比决策质量和条件关闭情况才有可比性。
- 角色可按团队规模合并，决策人和记录人建议保留。小团队里技术负责人可以兼任证据提供和方案建议，但最终拍板角色和记录角色分开，保证结论有出处、有留痕。
- 决策记录挂到对应工作项或文档上。评审结论与项目对象关联，形成可查的评审轨迹，后续复盘时能还原当时依据了哪些材料、做了哪些承诺。
迁移时只需替换三样东西：阶段名称、证据材料清单、条件项内容。角色表和结论选项可以直接沿用，这也是这套示例最省力的复用方式。
适用边界：哪些情况不套用这份示例
这份示例针对阶段性继续或终止决策，以下情形需要另行处理：
- 单次发布许可。发布前的审批与质量门禁关注的是本次发布是否放行，决策依据、角色和结论选项都与阶段评审不同，应走发布审批流程。
- 单需求评审。需求确认关注的是需求本身是否清晰、是否值得做，属于需求评审与确认的范畴，不套用阶段评审责任表。
- 涉及合规、安全的强制评审。这类评审有外部法规或标准规定的参与方、材料和记录要求，需要在本文结构基础上补充相应要求，不能只按项目内部约定执行。
- 团队规模、行业和项目类型差异。角色设置需随组织实际调整，例如大型项目可能增设独立的风险评审角色，小型项目可以合并证据提供方。
最后需要说明：示例中的项目名称、角色、结论和条件项均为演示内容，用于说明填写方法，不代表任何真实项目的评审结果或成效。
常见问题
阶段评审的决策人能不能由评审委员会集体担任？
可以设多人参与的评审机制，但记录上要指定一名最终拍板角色。示例中决策人填研发总监，其余参会者作为证据提供方或建议方出现。如果组织采用表决方式，也应明确一人对最终结论签字确认，否则出现争议时无法追溯是谁做的判断。
条件项在评审后一直没关闭，应该怎么处理？
先核对条件项是否写清了责任人和关闭时间。示例中两项条件分别指定技术负责人和质量负责人，并给出工作日口径的关闭时间，评审后按周核对。若条件项长期未关闭，需要在后续评审例会上重新确认：是责任人未推进，还是条件本身需要调整。调整后的条件项同样要更新责任人和时间，并保留变更记录。
小团队角色少，决策责任表可以简化到什么程度？
评审议题、决策人、决策结论、条件项（如有）、记录人属于必填，建议始终保留。证据提供方可以按阶段裁剪，早期材料较少时可合并为一份阶段输入清单；技术负责人可以兼任证据提供和方案建议。决策人与记录人分开，是保证结论有出处、有留痕的最低要求。
阶段评审结论为“有条件继续”后，条件项关闭前项目能不能先推进？
这取决于条件项的性质和团队约定。示例中“有条件继续”表示设计主体已具备进入开发的条件，但存在必须在开发早期关闭的具体事项，因此项目可以进入下一阶段，同时按关闭时间跟踪条件项。如果条件项涉及安全或合规等强制要求，应按外部规定处理，不能仅凭项目内部约定放行。
评审结论和条件项记录在哪里比较合适？
关键是让结论与项目对象关联，形成可查的评审轨迹。可以把结论和条件项写入对应工作项或评审文档，条件项作为待关闭事项持续跟踪。在ONES中，这类评审结论和条件项可以承载在项目的工作项与文档里，评审记录与项目进展放在同一处，便于后续复查；具体使用方式按团队现有的工作项和文档组织习惯安排即可。
