阶段决策记录用于留存研发阶段评审的结论，核心回答“这个阶段继续、有条件继续、暂停还是终止”。本文提供一张可直接复制到文档或表格工具中的空白模板，并逐项说明字段含义、必填项与填写示例，帮助团队把评审结论、依据和后续动作记录清楚。模板适用于阶段级评审，不覆盖单次发布许可或单个需求的确认流程。
要点总览（TL;DR）
- 阶段决策记录的核心是回答阶段继续、有条件继续、暂停还是终止，模板按基本信息、评审输入、决策结论、遗留条件、决策人与后续动作五区组织。
- 决策结论、决策依据、决策人、决策日期四项为必填，缺任何一项记录都无法说明谁在何时基于什么做出了什么决定。
- 结论为“有条件继续”时，继续条件、责任人和关闭期限必须同时填写，条件要可验证，避免“有条件”变成没有约束的“继续”。
- 填写时把决策依据与反对意见分开记录，材料清单写清名称和版本，便于半年后复盘时确认当时的判断依据。
- 模板可按轻量与完整两档裁剪，并保留版本号、变更说明和按项目—阶段—日期的归档规则，定期抽查记录质量再调整字段。
可复制的阶段决策记录空白模板
下面这张表按“基本信息—评审输入—决策结论—遗留条件—决策人与后续动作”的顺序排列，复制到文档或表格工具后即可填写。表格采用两列结构，左列为字段名，右列为填写内容；材料清单和遗留问题可能有多条，填写时可在一个单元格内分行，或拆成多行子表。
| 区域 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 记录编号 | |
| 决策对象 | ||
| 阶段名称 | ||
| 评审日期 | ||
| 评审输入 | 评审材料清单 | |
| 关键指标与完成情况 | ||
| 未决事项与风险 | ||
| 决策结论 | 决策结论 | 继续 / 有条件继续 / 暂停 / 终止 |
| 决策依据 | ||
| 反对意见与保留意见 | ||
| 遗留问题与条件 | 遗留问题 | |
| 继续条件 | ||
| 责任人 / 关闭条件 / 期限 | ||
| 决策人与后续动作 | 决策人 | |
| 决策日期 | ||
| 后续动作 |
如果团队使用在线表格，可以把“遗留问题”和“后续动作”拆成独立子表，每行一条，便于分配责任人和跟踪关闭状态。空白模板只规定字段，不规定评审会议怎么开；会议组织方式由团队既有流程决定。
每个字段记录什么：字段说明
字段说明的作用是让不同评审人按同一口径填写，避免同一张表里出现“结论写继续、依据写待定”这类前后不一致。下表逐字段解释含义与填写口径。
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 记录编号 | 该记录的唯一标识 | 建议采用“项目简称-阶段-日期-序号”，便于归档检索 |
| 决策对象 | 本次决策针对的产品、项目或版本 | 写到可识别的层级，如“某产品 2.0 版本”，避免只写项目代号 |
| 阶段名称 | 被评审的研发阶段 | 使用团队流程中的标准阶段名，如“需求评审后”“开发完成”“上线前” |
| 评审日期 | 评审实际发生的日期 | 填写实际日期，与决策日期可能相同，也可能因复议而不同 |
| 评审材料清单 | 评审所依据的材料 | 列出材料名称与版本，如“测试报告 v1.2”“架构方案 v0.9”，只写“相关文档”无法追溯 |
| 关键指标与完成情况 | 支撑判断的量化或事实信息 | 写指标值、目标值和差距，如“缺陷关闭率 92%，目标 95%” |
| 未决事项与风险 | 评审时尚未解决的事项 | 逐条列出，注明影响范围；已关闭的事项不写入 |
| 决策结论 | 阶段是否继续 | 只能取四个值之一：继续、有条件继续、暂停、终止 |
| 决策依据 | 支撑结论的事实与判断 | 与评审输入对应，写“因为哪项指标、哪份材料得出该结论” |
| 反对意见与保留意见 | 评审中未被采纳的不同意见 | 记录意见内容与提出人，便于后续复盘；无反对意见时写“无” |
| 遗留问题 | 不阻塞本次结论但需跟踪的问题 | 每条写清问题描述，避免与“继续条件”混写 |
| 继续条件 | “有条件继续”时需满足的条件 | 条件应可验证，如“完成安全扫描并关闭高危项” |
| 责任人 / 关闭条件 / 期限 | 遗留问题与条件的落实安排 | 每条问题对应一名责任人和一个可判断的关闭标准及期限 |
| 决策人 | 对结论负责的人 | 写姓名与角色，集体决策时写明牵头人 |
| 决策日期 | 结论正式生效的日期 | 复议场景下填写最终确认日期 |
| 后续动作 | 结论确定后要执行的动作 | 写动作、承接人和时间点，如“进入系统测试，测试负责人两周内提交报告” |
决策结论的四个取值需要区分清楚：“继续”表示阶段目标已达成，按计划进入下一阶段；“有条件继续”表示可以推进，但必须完成列明的条件；“暂停”表示暂不推进，等待补充信息或问题解决后重新评审；“终止”表示该阶段或该方向不再继续。四个取值互斥，填写时只选一个，不用“基本通过”“原则同意”等模糊表述替代。
决策依据与反对意见要分开记录。依据写支持结论的事实，反对意见写评审中提出但未被采纳的观点。两者混在一起，后续复盘时容易误读当时的判断逻辑。反对意见即使未被采纳，也应保留提出人和理由，这对后续阶段的风险识别有参考价值。
必填与选填：哪些字段不能空
阶段决策记录的最小可用集合是“决策结论、决策依据、决策人、决策日期”四项。缺少其中任何一项，记录都无法回答“谁在什么时候基于什么做出了什么决定”，也就失去了作为决策凭证的作用。其余字段按团队流程裁剪。
| 字段 | 必填 / 选填 | 理由与适用场景 |
|---|---|---|
| 决策结论 | 必填 | 记录的核心内容，缺失则整张表没有意义 |
| 决策依据 | 必填 | 支撑结论，便于后续追溯判断是否成立 |
| 决策人 | 必填 | 明确责任归属，复议和复盘时需要找到对应人 |
| 决策日期 | 必填 | 确定结论生效时间，与后续动作的时间线对应 |
| 决策对象、阶段名称 | 建议必填 | 缺少则记录无法定位到具体项目和阶段；单项目团队可简化对象写法 |
| 评审材料清单 | 建议必填 | 结论需要可追溯的材料支撑；轻量评审可只列关键材料 |
| 记录编号 | 选填 | 记录量大、需要检索时启用；小团队可按日期归档 |
| 关键指标与完成情况 | 选填 | 有量化门禁的阶段建议填写；探索型阶段可省略 |
| 未决事项与风险 | 选填 | 存在未决事项时填写，无则写“无” |
| 反对意见与保留意见 | 选填 | 有不同意见时填写，便于复盘；无则写“无” |
| 遗留问题、继续条件、责任人 | 条件必填 | 结论为“有条件继续”时必须填写，否则条件无法跟踪 |
| 后续动作 | 建议必填 | 结论需要落到下一步动作；简单阶段可并入会议纪要 |
裁剪字段时有两条边界需要守住。第一，必填四项不能省，即使评审很轻量，也要留下结论、依据、人和日期。第二，结论为“有条件继续”时，继续条件和责任人不能省，否则“有条件”就变成了没有约束的“继续”。裁剪带来的主要风险是追溯困难：材料清单缺失时，半年后无法确认当时依据的是哪个版本；反对意见缺失时，复盘会误以为评审没有分歧。
填写示例：一次阶段评审的完整记录
以下示例为演示情景，用于说明各字段的写法，不对应真实项目。背景设定为某产品 2.0 版本在开发完成阶段进行评审，测试报告显示缺陷关闭率未达目标，评审结论为有条件继续。
| 字段 | 示例填写内容 |
|---|---|
| 记录编号 | PROD2-开发完成-20250612-01 |
| 决策对象 | 某产品 2.0 版本 |
| 阶段名称 | 开发完成阶段 |
| 评审日期 | 2025-06-12 |
| 评审材料清单 | 测试报告 v1.2；架构方案 v0.9；性能测试记录 v1.0 |
| 关键指标与完成情况 | 缺陷关闭率 92%，目标 95%；核心接口平均响应时间 180ms，目标 200ms 以内 |
| 未决事项与风险 | 剩余 3 个中等级缺陷未关闭；第三方支付接口联调尚未完成 |
| 决策结论 | 有条件继续 |
| 决策依据 | 核心功能与性能指标达标，剩余缺陷集中在非主流程；支付联调属于外部依赖，已有替代方案验证 |
| 反对意见与保留意见 | 测试负责人提出：3 个中等级缺陷中 1 个影响订单导出，建议关闭后再进入系统测试 |
| 遗留问题 | 订单导出缺陷待修复；支付接口联调待完成 |
| 继续条件 | 进入系统测试前关闭订单导出缺陷；支付联调在系统测试第一周内完成 |
| 责任人 / 关闭条件 / 期限 | 订单导出缺陷：开发负责人，缺陷状态为已关闭，6 月 16 日前；支付联调：后端负责人，联调记录通过，6 月 20 日前 |
| 决策人 | 项目负责人 张某 |
| 决策日期 | 2025-06-12 |
| 后续动作 | 6 月 17 日进入系统测试，测试负责人提交系统测试计划；6 月 20 日复核继续条件完成情况 |
这个示例中，“决策结论”与“继续条件”相互对应：结论写“有条件继续”，条件就必须可验证、有责任人和期限。反对意见单独记录，没有并入决策依据，保留了测试负责人的判断。后续动作写明了承接人和时间点，便于下次评审时核对条件是否关闭。
当记录需要在团队内长期留存并和阶段工作项对应时，可以把记录作为文档关联到对应的阶段任务上。ONES 提供文档与工作项管理能力，可用于存放评审记录、关联阶段任务并保留版本，具体配置按团队实际使用方式确定。
模板的调整与维护方法
模板需要随流程变化调整，但调整应有记录，避免不同阶段使用不同版本导致记录无法横向比较。以下方法可按团队规模选用。
按评审类型裁剪字段。阶段评审可以分轻量和完整两档。轻量评审用于探索型或内部阶段，保留必填四项加决策对象、阶段名称即可；完整评审用于对外交付或高风险阶段，启用全部字段。裁剪时在模板说明中标注哪些字段被省略、省略后由什么材料补充，例如“关键指标并入测试报告，记录中只引用报告版本”。
维护模板版本与变更记录。模板文件应包含版本号和变更说明，记录每次调整的字段、原因和生效日期。字段增删时同步更新字段说明表，保证模板、说明和示例三者一致。示例可以保留一份最新完整版，历史示例归档，不随模板反复改写。
归档与检索要求。记录按“项目—阶段—日期”归档，记录编号与文件名保持一致。归档时确认必填项完整、遗留问题有责任人和期限。检索场景主要是复盘和审计，因此材料清单中的版本号、决策人姓名要写全，避免只写角色简称。
定期复核。团队可以在每个季度或每个大版本结束后抽查若干条记录，检查结论与依据是否对应、继续条件是否按期关闭。发现字段长期空置或反复补填，说明模板与流程不匹配，应调整字段而不是要求填写人凑内容。复核结果作为下一版模板的输入，形成“使用—复核—调整”的循环。
常见问题
阶段评审结论写成“基本通过”可以吗？
不建议。模板把决策结论限定为继续、有条件继续、暂停、终止四个互斥取值，目的是让记录能直接对应后续动作。“基本通过”无法判断阶段是否已经放行，也无法确定遗留事项是否构成推进前提。如果评审中确实存在分歧，可以把不同意见写进“反对意见与保留意见”，结论仍从四个取值中选一个。
评审当天没有形成结论，记录该怎么填？
可以先把记录状态留在评审输入部分，写清已提交的材料、关键指标和未决事项，决策结论暂不填写，并注明下次评审的时间。等结论形成后再补填决策结论、决策依据、决策人和决策日期。需要避免的是先写一个模糊结论再回头修改，这样会让决策日期和实际生效时间对不上。
小团队字段裁剪到什么程度仍然可用？
最小可用集合是决策结论、决策依据、决策人、决策日期四项，再加决策对象和阶段名称以便定位。记录编号、关键指标、反对意见等字段可以按需省略。裁剪时要确认省略的信息是否有其他材料承接，例如关键指标并入测试报告并在记录中引用报告版本，否则后续复盘会缺少判断依据。
“有条件继续”的条件关闭后，需要更新原记录吗？
建议在原记录上补充关闭情况，或另建一条跟踪记录并关联原记录编号，写清条件关闭的日期和验证人。原记录的决策结论和决策日期保持不变，这样既保留了当时的决策事实，也能看到条件是否按期落实。下次阶段评审时可以直接引用这条跟踪记录，不必重新翻找会议纪要。
阶段决策记录和发布审批记录需要合并成一张表吗？
两者回答的问题不同。阶段决策记录判断阶段是否继续推进，发布审批记录判断某次发布是否放行，涉及的质量门禁和审批范围也不一样。合并会让一张表同时承担两类判断，字段互相牵制。更清晰的做法是分开记录，在阶段决策记录的后续动作中引用对应的发布审批记录编号，保持两条线索可追溯。
