阶段决策记录用于在研发阶段评审结束时，把“继续、有条件继续、暂停或终止”的判断固定下来，让后续工作有明确依据。一份完整的记录通常包含阶段与评审对象、评审输入与证据、关键问题与风险、决策结论与条件、待办与责任人、决策人与日期六个部分。本文给出一份填写完整的示例，并逐项解释写法；示例中的项目、角色和数据均为演示情景，不代表真实客户案例。
要点总览（TL;DR）
- 阶段决策记录在阶段评审收尾时固定“继续、有条件继续、暂停或终止”的判断，一份完整记录包含阶段与评审对象、评审输入与证据、关键问题与风险、决策结论与条件、待办与责任人、决策人与日期六个部分。
- 决策结论要写明确，避免“基本通过”“原则同意”这类模糊表述；附加条件应指向具体对象、给出可检查的完成标志并绑定时间或触发节点。
- 证据与风险要一一对应，责任人写到具体角色或具体人，时限写成明确时间点或触发节点，并安排复核动作让记录可跟踪。
- 六段式结构可复用到需求、开发、上线前等不同阶段，字段不变、内容随阶段替换；决策结论与待办分开记录，便于独立更新。
- 示例为演示情景，不覆盖发布许可与单需求评审，数据不能作为行业基准；记录需要随阶段推进更新，避免只写结论不写依据、只写问题不写条件。
这份示例要解决什么问题
阶段决策记录的核心任务是在阶段评审收尾时给出一个可执行的判断：这个阶段的工作是否足以支撑进入下一阶段。它把评审过程中形成的证据、争议和风险收敛成一条结论，并明确结论生效的条件和后续动作。记录写完之后，团队不需要再靠会议记忆或口头传达来理解“到底过没过、还差什么”。
这份记录的使用时机通常在阶段评审会议结束、结论达成之后，由评审组织者或项目负责人整理成文，经决策人确认后发布。它承接的是评审过程中的材料与讨论，输出的是下一阶段能否启动、以什么前提启动的正式依据。
需要区分三类容易混淆的文档。阶段决策记录回答“这个阶段能否收口、下一阶段是否放行”，关注阶段性判断；发布审批回答“这个版本能否对外交付”，关注交付许可与质量门禁；单需求评审回答“这个需求是否成立、方案是否可行”，关注单个需求的范围与实现。三者可能在同一时期发生，但对象和结论不同，不能互相替代。本文聚焦阶段决策记录，发布审批与单需求评审的具体流程不在展开范围内。
本文示例为演示情景，项目名称、人员角色、数据指标均为说明写法而设定，不对应任何真实组织，也不能作为行业基准或成效参考。读者可以对照示例的结构和措辞，替换为自己项目的实际内容。
完整示例：某版本进入集成测试前的阶段决策记录
以下示例设定一个演示项目“星港客户端 V3.2”，当前处于开发完成、准备进入集成测试的阶段节点。评审对象是本阶段的开发交付物与测试准备情况，决策问题是“是否允许进入集成测试”。示例中的数字和角色均为演示设定。
| 记录字段 | 填写内容（演示情景） |
|---|---|
| 阶段与评审对象 | 星港客户端 V3.2，开发阶段收口评审；评审对象为本阶段完成的 14 个开发工作项、接口联调结果与集成测试准备情况 |
| 评审输入与证据 | 开发完成清单（14 项中 13 项完成，1 项部分完成）；接口联调记录（8 个接口中 7 个通过，1 个存在字段映射偏差）；单元测试报告（覆盖率 72%，核心模块 81%）；集成测试用例准备清单（计划 120 条，已就绪 96 条）；遗留缺陷清单（严重 0、主要 3、一般 11） |
| 关键问题与风险 | 问题 1：接口 A 的字段映射偏差可能导致集成阶段返工，影响范围待确认；问题 2：集成测试用例尚有 24 条未就绪，集中在支付与消息推送模块；风险 1：部分完成的工作项涉及权限校验，若延后处理可能阻塞集成测试的登录场景 |
| 决策结论 | 有条件继续：允许进入集成测试，附加三项条件，条件未满足前不启动对应模块的集成验证 |
| 附加条件 | 条件 1：接口 A 字段映射偏差在进入集成测试后 2 个工作日内给出修复方案并完成验证；条件 2：支付与消息推送模块的 24 条用例在对应模块集成验证开始前补齐；条件 3：权限校验工作项在登录场景集成验证前完成，并由开发负责人提供自测记录 |
| 待办与责任人 | 待办 1：接口 A 修复方案与验证，责任人：后端开发负责人，时限：2 个工作日；待办 2：补齐支付与消息推送用例，责任人：测试负责人，时限：对应模块验证前；待办 3：权限校验完成并提交自测记录，责任人：开发负责人，时限：登录场景验证前；待办 4：条件满足情况在下次阶段例会上复核，责任人：项目经理，时限：5 个工作日后 |
| 决策人与参与角色 | 决策人：研发总监；参与角色：项目经理、开发负责人、测试负责人、产品负责人；记录人：项目经理 |
| 记录日期 | 演示日期，评审当日记录，条件复核后更新状态 |
这份示例的结论是“有条件继续”，而不是简单的“通过”。这样写的原因是评审中确实存在未闭环的问题，直接写“通过”会掩盖条件，写“暂停”又与整体进度判断不符。把条件单独列出并绑定责任人和时限，使结论具备可验证性：条件满足则继续推进，条件逾期则触发再次评审。
逐项解释：每个字段为什么这样填
决策结论的四种表述
继续、有条件继续、暂停、终止四种结论对应不同的证据状态，写法上要能直接指导下一步动作。“继续”表示阶段目标已达成、无阻塞项，下一阶段按计划启动；“有条件继续”表示整体可推进，但存在必须在特定节点前闭环的事项，需要写明条件和验证方式；“暂停”表示关键证据缺失或存在重大未决问题，下一阶段暂不启动，需补充材料后重新评审；“终止”表示阶段目标无法达成或方向不再成立，相关工作停止并进入收尾。
常见写法问题是用“基本通过”“原则同意”这类模糊表述代替明确结论。这类措辞在会后容易产生不同理解，也无法判断条件是否触发。示例中直接写“有条件继续”，并紧跟条件清单，读者不需要猜测结论的强度。
附加条件写成可验证条目
附加条件的写法要满足三个要求：指向具体对象、给出可检查的完成标志、绑定时间或触发节点。示例中的条件 1 写“接口 A 字段映射偏差在 2 个工作日内给出修复方案并完成验证”，对象是接口 A，完成标志是修复方案加验证，时间是 2 个工作日。对照的模糊写法是“尽快解决接口问题”，既没有对象范围，也没有验证方式。
条件之间应尽量独立，避免一条条件依赖另一条条件的完成才能判断。如果确实存在依赖，需要在条件描述中写明先后关系，例如“在登录场景验证前完成”，让执行者知道判断顺序。
证据与风险的对应关系
评审输入要能支撑结论，风险条目要能追溯到具体证据。示例中“接口联调 8 个中 7 个通过”是证据，“接口 A 字段映射偏差可能导致返工”是对应的风险；用例就绪 96/120 是证据，“支付与消息推送模块用例未齐”是对应的风险。这样写的好处是，后续复核时可以直接回到原始材料核对，而不是依赖记忆。
证据清单不必罗列全部原始文档，列出评审实际依据的关键材料及其结论即可。每项证据最好带一个可比较的数值或状态，便于判断变化。
责任人与时限避免空泛
责任人写到具体角色或具体人，避免“开发团队”“相关同事”这类集体表述。时限写成明确的时间点或触发节点，例如“2 个工作日内”“对应模块验证前”，而不是“尽快”“近期”。示例中待办 4 设置了一个复核动作，由项目经理在 5 个工作日后检查条件满足情况，这一步让记录从一次性结论变成可跟踪的过程。
从这份示例可以迁移的写法
六段式结构可以复用到不同阶段。需求阶段收口时，评审对象换成需求清单与方案文档，证据换成需求确认记录与可行性分析，结论关注是否进入开发；开发阶段收口时，证据换成完成清单与测试报告；上线前阶段收口时，证据换成回归结果与上线准备清单。字段不变，内容随阶段替换，团队不需要为每个阶段重新设计记录格式。
把决策结论与待办分开记录，好处是两者可以独立更新。结论在评审时确定，待办在后续执行中逐条关闭；复核时先看条件是否满足，再判断结论是否需要调整。如果混在一起写，条件关闭后结论的表述容易变得含混。
阶段决策记录与会议纪要分工不同。会议纪要记录讨论过程、不同意见和发言要点，服务于回溯；决策记录只保留支撑结论的证据、风险和条件，服务于执行。两者可以互相引用，但不必合并成一份文档。评审中的分歧可以留在纪要里，决策记录呈现的是收敛后的判断。
在协作工具中承载这类记录，一般做法是把记录作为文档或工作项描述保存，把附加条件和待办拆成可分配、可设置截止时间的工作项，并与对应的阶段节点关联。这样条件是否满足可以直接从工作项状态看出，复核时不需要逐条翻查文档。ONES 的文档与工作项能力可以承担这一分工：记录正文放在文档中，待办以工作项形式分配责任人和时限，阶段评审的结论与后续流转在同一处衔接。具体配置方式依团队现有流程而定。
示例的适用边界与常见误用
这份示例覆盖的是阶段性继续或终止判断，不覆盖发布许可与单需求评审。发布审批涉及对外交付的许可判断和质量门禁的具体规则，单需求评审涉及单个需求的范围确认与方案取舍，两者的评审对象、参与角色和结论形式都不同，不能直接套用本示例的字段和措辞。示例中的数据为演示设定，不能作为覆盖率、缺陷数量或工期的行业基准，读者应替换为自己项目的实际口径。
常见误用之一是只写结论不写依据。记录中只有“同意进入下一阶段”，没有证据清单和风险条目，后续出现问题时无法判断当时的判断基础，也无法追溯条件是否被忽略。另一种误用是只写问题不写条件，把风险罗列一遍却没有说明这些问题如何影响结论、由谁在什么时间闭环，记录就退化成问题清单。
还有一种误用是把记录当成一次性归档。阶段决策记录的条件和待办需要在后续推进中更新状态，条件满足后标注关闭，条件逾期则触发复核或再次评审。如果记录写完即归档、不再维护，它就失去了约束下一阶段动作的作用。建议在阶段例会上固定留出复核环节，让记录随阶段推进保持有效。
常见问题
阶段决策记录和阶段评审会议纪要需要分开写吗？
建议分开。会议纪要记录讨论过程、不同意见和发言要点，服务于回溯；阶段决策记录只保留支撑结论的证据、风险和条件，服务于执行。两者可以互相引用，但不必合并。评审中的分歧留在纪要里，决策记录呈现收敛后的判断，这样后续执行时不必从讨论记录中重新提炼结论。
决策结论写成“有条件继续”后，条件一直没满足怎么办？
需要在记录中预先约定复核节点和触发规则。常见做法是由项目经理在设定时间点检查条件状态：条件满足则标注关闭、结论维持；条件逾期则触发复核或再次评审，由决策人重新判断是继续、暂停还是调整条件。示例中安排了 5 个工作日后的复核待办，就是为了让“有条件继续”具备可执行性，避免条件长期悬空。
小团队阶段节点不多，也需要写完整的六段式记录吗？
可以按评审复杂度裁剪。六段式结构的核心是证据、结论、条件与责任人四类信息，小团队可以合并部分字段，例如把评审输入与关键问题放在同一段，把参与角色简化为决策人与记录人。需要保留的是结论的明确性和条件的可验证性，这两点决定记录能否指导下一阶段动作。裁剪后仍建议保留复核环节。
阶段决策记录里的证据需要附原始文档吗？
不必全部附上。记录中列出评审实际依据的关键材料及其结论即可，每项证据带一个可比较的数值或状态，便于后续复核时判断变化。原始文档保留在原有位置，记录中注明来源，需要核对时再回到原始材料。这样既控制记录篇幅，也保证结论可追溯。
在协作工具中承载阶段决策记录，重点看哪些能力？
重点看两件事：记录正文能否作为文档或工作项描述稳定保存并关联到阶段节点；附加条件和待办能否拆成可分配责任人、可设置截止时间的工作项，并随执行更新状态。ONES 的文档与工作项能力可以承担这一分工，记录正文放在文档中，待办以工作项形式分配责任人和时限。具体配置方式依团队现有流程而定，选型时可结合团队已有的评审节奏和工具使用习惯判断。
