研发阶段评审要回答的，是当前证据是否支撑继续投入、剩余风险是否可接受、下一阶段承诺什么。本文给出一份虚构项目的完整阶段决策记录示例，逐项解释结论、证据、风险和行动项的写法，并说明如何迁移成团队自己的评审模板。示例中的评审结论与行动项，也可借助ONES这类协作平台承载和跟踪。
要点总览（TL;DR）
- 阶段评审决策记录的核心是五个要素：决策结论、证据、风险、行动项、触发条件，五者构成从判断到闭环的链条。
- 决策结论分为无条件继续、有条件继续与终止三类，判断依据是进入条件核对结果和剩余风险，有条件继续必须写明未达标时的后果条款。
- 证据字段写产出物名称加版本或编号、数据口径与统计截止时间，让未参会的人也能独立复核结论。
- 行动项与风险一一对应，每条都要有唯一责任人、明确期限和可核验的关闭标准，下次评审逐条核验。
- 这份示例只适用于阶段性继续或终止决策；单次发布许可归发布审批与质量门禁，单需求评审归需求评审与确认。
这份示例要解决什么问题
很多团队的阶段评审停留在“大家讨论一下、口头同意继续”，事后既说不清当时依据什么做判断，也无法在下一阶段核验承诺是否兑现。这份示例要展示的，是一份可留存、可追溯、可交接的阶段决策记录应该长什么样。
示例设定如下，全部为虚构内容：某协作类软件产品“星图”，当前处于V2.3版本开发阶段，本次评审的节点是从“开发完成”进入“系统测试”。参与角色包括产品负责人、研发负责人、测试负责人、项目经理，评审日期为某年某月某日。示例不指向任何真实客户、真实项目或实测结果，仅用于演示填写方式。
这份记录要演示五个机制要素：
- 决策结论：本次评审给出继续、有条件继续还是终止，以及理由。
- 证据：支撑结论的可核对产出物与数据，而非主观评价。
- 风险：尚未消除的问题，其影响、概率与处置安排。
- 行动项：谁在什么期限前完成什么，以什么标准关闭。
- 触发条件：什么情况下需要重新评审或升级决策。
这五个要素构成一个闭环：结论由证据支撑，证据不足的部分转化为风险，风险通过行动项处置，行动项的完成情况又成为下一次评审的输入。
完整示例：某版本进入下一阶段的评审决策记录
以下是一份填写完整的记录示例。为便于阅读，分为基本信息、进入条件核对、决策结论、风险与行动项、下一阶段承诺五个部分呈现。
评审基本信息
| 字段 | 填写内容 |
|---|---|
| 评审节点 | 开发完成 → 系统测试 |
| 评审对象 | 星图 V2.3 版本（需求范围见 V2.3 需求基线 v1.2） |
| 参与角色 | 产品负责人、研发负责人、测试负责人、项目经理 |
| 评审日期 | 某年某月某日 |
| 记录人 | 项目经理 |
进入条件逐项核对
| 进入条件 | 核对结果 | 支撑证据 |
|---|---|---|
| 需求范围内功能全部开发完成 | 满足 | V2.3 需求基线 v1.2 共 18 项功能，开发任务关闭 18 项；功能清单核对表已归档 |
| 单元测试通过率达到约定标准 | 满足 | 单元测试报告（构建号 B2317），用例 412 条，通过 409 条，3 条失败已修复并回归 |
| 关键模块代码评审完成 | 部分满足 | 权限模块、同步模块评审记录已归档；报表模块评审记录缺失 |
| 已知缺陷完成分级并给出处置计划 | 满足 | 缺陷清单（截至评审日）共 27 条，其中严重 2 条、一般 11 条、轻微 14 条，均已指定处置方式 |
| 测试环境与测试数据就绪 | 满足 | 测试环境部署记录、测试数据集说明 v1.0 |
决策结论
结论：有条件继续。理由：五项进入条件中四项满足，代码评审一项部分满足，缺失部分集中在报表模块，该模块不属于本阶段测试的主路径；同时存在 2 条严重缺陷尚未修复。综合判断，剩余风险在可控范围内，允许进入系统测试，但须在测试开始后五个工作日内补齐代码评审并关闭严重缺陷，否则暂停测试并重新评审。
遗留风险与处置
| 风险描述 | 影响 | 概率 | 处置动作 | 责任人 | 期限 |
|---|---|---|---|---|---|
| 报表模块代码评审未完成 | 该模块潜在缺陷可能延后暴露，影响测试覆盖判断 | 中 | 补做代码评审并归档记录 | 研发负责人 | 测试开始后 5 个工作日内 |
| 2 条严重缺陷未关闭 | 阻塞相关用例执行 | 高 | 修复并回归，回归通过后关闭 | 研发负责人 | 测试开始后 3 个工作日内 |
| 测试数据覆盖度未验证 | 部分边界场景可能测不到 | 低 | 测试负责人补充边界数据集并记录覆盖情况 | 测试负责人 | 测试第一周内 |
下一阶段承诺与触发条件
- 下一阶段承诺：系统测试按计划启动，测试用例执行率达到 90% 以上，严重缺陷清零后提交发布评审。
- 重新评审触发条件：严重缺陷在约定期限内未关闭；代码评审补齐后发现需返工的设计问题；测试执行率连续两周低于计划值。
- 下一次评审节点：系统测试完成 → 发布评审准备。
逐项解释：每个字段为什么这样填
示例本身只是结果，理解每个字段背后的判断逻辑，才能在自己的项目里填得准确。
决策结论：三类结论的区分标准
无条件继续适用于进入条件全部满足、且没有需要跟踪的遗留风险的情况。有条件继续适用于条件基本满足、但存在明确且可控的遗留项，此时必须同时写明条件和未满足条件的后果，示例中“五个工作日内未补齐则暂停测试”就是后果条款。终止适用于关键条件不满足且短期内无法补救，或剩余风险超出团队可接受范围的情况。三类结论的判断依据都是进入条件核对结果与风险清单，而不是会议现场的感觉。
证据：写产出物，不写评价
证据字段的作用是让没参会的人也能复核结论。“单元测试基本通过”无法核对，“单元测试报告（构建号 B2317），用例 412 条，通过 409 条”可以核对。填写时优先写产出物名称加版本或编号，其次写数据口径，例如缺陷数量按什么范围统计、截至哪一天。主观评价可以出现在讨论记录里，但不应作为进入条件的支撑证据。
风险：影响、概率、处置三件套
风险描述要写清楚“什么没做完或可能出问题”，影响写它对下一阶段的实际阻碍，概率给出高、中、低的判断即可，不必追求精确数值。处置动作必须是可执行的动作，而不是“持续关注”。示例中“补做代码评审并归档记录”是可核验的，“加强质量管理”则无法核验。
行动项：责任人、期限、关闭标准缺一不可
行动项与风险一一对应，每条都要有唯一责任人、明确期限和关闭标准。关闭标准决定下次评审时如何判断这条行动项是否完成，例如“回归通过后关闭”比“尽快修复”更可操作。期限建议用工作日或具体日期，避免“近期”“尽快”这类无法核验的表述。
触发条件：给决策装上回退开关
有条件继续的结论必须配套触发条件，说明在什么情况下需要重新评审或升级决策。触发条件应尽量可观测，例如缺陷数量、期限是否逾期、执行率是否低于阈值。没有触发条件的“有条件继续”，实际上等于无条件继续。
从这份示例提炼可迁移的写法
把示例中的具体内容抽掉，可以提炼出四条适用于多数团队的写法规则。
- 结论先行：记录开头先写决策结论和一句理由，再展开证据与风险。阅读者通常先关心“过没过”，再关心“为什么”。
- 证据支撑：每条进入条件的核对结果都挂上可核对的产出物或数据，让结论可以被独立复核。
- 风险与行动闭环：未满足的条件不隐藏，转为风险条目，再转为带责任人和期限的行动项，下次评审逐条核验关闭情况。
- 字段固定、跨阶段可比：同一类阶段节点使用同一套字段和同一套进入条件口径，不同版本的评审记录才能横向比较，也便于观察进入条件是否长期形同虚设。
在承载方式上，评审记录可以作为文档归档，结论中的行动项转为可跟踪的工作项，关联到对应版本或模块，关闭状态回写到记录中。使用ONES这类平台时，可以把评审记录作为文档、把行动项作为工作项管理，使阶段交接时有据可查；具体配置按团队现有流程调整。
适用边界：哪些评审不套用这份示例
这份示例面向的是阶段性继续或终止决策，即在一个阶段结束时判断是否投入下一阶段资源。以下场景有各自的判断对象和记录要求，不宜直接套用。
- 单次发布许可：判断的是某个版本能否对外发布，关注发布检查项与质量门禁的通过情况，属于发布审批范畴，记录重点在发布检查清单而非阶段投入决策。
- 单需求评审：判断的是某个需求是否成立、范围是否清晰，属于需求评审与确认，产出是需求基线和确认结论，与阶段推进决策不是同一件事。
- 技术方案评审：判断的是方案是否可行，关注设计与取舍，通常作为阶段评审的输入证据之一，本身不承担继续或终止的决策职能。
此外，示例中的进入条件、角色设置和阶段划分都基于虚构项目的设定。团队实际使用时，需要按自己的研发模式调整：阶段如何划分、每个节点核对哪些条件、由谁参与决策，都应与团队的实际流程一致。字段框架可以沿用，具体条目必须替换。
常见问题
进入条件没有全部满足，还能给出“继续”的结论吗？
可以，但要落到“有条件继续”，并且把条件写成可核验的条款。示例中五项进入条件四项满足、一项部分满足，结论是有条件继续，同时写明未补齐代码评审、未关闭严重缺陷时暂停测试并重新评审。判断的关键是剩余风险是否在团队可接受范围内，以及未满足项是否影响下一阶段主路径。如果关键条件不满足且短期内无法补救，或者剩余风险超出可接受范围，就应当给出终止结论，而不是用条件条款掩盖问题。
评审记录里的行动项和项目里的普通任务有什么区别？
行动项来源于本次评审未关闭的风险或未满足的进入条件，它带着评审上下文：对应哪条风险、由谁承诺、什么期限、以什么标准关闭。普通任务可能来自计划拆解或临时需求，不一定有评审背景。实际操作中，行动项可以作为工作项跟踪，但要保留与评审记录的关联，下次评审时能直接调出这批行动项核对关闭情况。如果行动项混入日常任务池且没有标记来源，阶段交接时就很难说清哪些承诺已经兑现。
重新评审的触发条件应该由谁设定、什么时候设定？
触发条件在给出“有条件继续”结论的同一场评审中设定，由参与评审的角色共同确认，记录人写入记录。设定时优先选择可观测的指标，例如严重缺陷是否在约定期限内关闭、测试执行率是否连续两周低于计划值、补齐评审后是否发现需返工的设计问题。触发条件不宜过多，聚焦在会导致决策反转的那几条即可。触发后由项目经理或记录人发起重新评审，并把上次的行动项关闭情况作为输入。
团队阶段划分和示例不一样，字段框架还能用吗？
可以沿用字段框架，替换具体条目。示例假设的是“开发完成进入系统测试”这一节点，团队如果按迭代节奏推进，节点可能是迭代评审或版本封版；如果采用更重的阶段划分，节点数量和进入条件都会不同。需要调整的是：每个节点核对哪些进入条件、由哪些角色参与决策、结论的后果条款怎么写。保持不变的是结论先行、证据可核对、风险转行动项、行动项带责任人和期限这套结构，它决定了记录能否被复核和交接。
评审记录需要和哪些文档或工作项建立关联？
至少建立三类关联：一是进入条件核对所依据的产出物，如需求基线、测试报告、缺陷清单，记录中写明名称和版本；二是结论中产生的行动项，转为可跟踪的工作项并保留与本次评审的关联；三是下一次评审的输入，包括本次行动项的关闭状态和遗留风险的变化。这样阶段交接时，接手的人可以从记录出发找到全部依据和待办。使用ONES这类平台时，评审记录可作为文档归档，行动项作为工作项跟踪，具体配置按团队现有流程调整。
