阶段决策记录与决策跟踪台账的边界，可以用一句话概括：记录负责“定”，台账负责“跟”。阶段决策记录是某一次阶段评审的决策凭证，回答“这一次会议定了什么”；决策跟踪台账是跨多次决策的登记与跟踪清单，回答“历次决策定下的事后来办到哪一步”。两者以决策编号关联，评审会议纪要则承担过程记录的角色。本文按这一口径说明三者的字段归属、流转规则，以及分开维护或合并简化的适用条件，并说明在ONES中如何衔接评审记录与行动项跟踪。
要点总览（TL;DR）
- 阶段决策记录是单次阶段评审的决策凭证，回答“这一次定了什么”；决策跟踪台账跨多次决策汇总行动项，回答“历次决策定下的事办到哪一步”。
- 结论类型、决策依据、附加条件唯一归属决策记录；行动项、责任人、期限、状态、关闭证据唯一归属台账；纪要只保留议题、讨论要点与分歧。
- 两者以决策编号关联：台账引用编号而不复制结论，状态只在台账更新，决策记录定稿后保持只读。
- 评审频次高、阶段多（如IPD下DCP与TR并行）时分开维护；小团队低频评审可合并为一张表，但需锁定结论字段，代价是凭证属性被削弱。
- 在ONES中可用阶段评审工作项承载评审输入、评审记录文档定稿决策、附加条件拆成工作项关联决策编号进入跟踪视图，形成记录到跟踪的闭环。
阶段决策记录与决策跟踪台账：各自回答什么问题
阶段决策记录与决策跟踪台账服务于两个不同的管理动作。前者是决策凭证，后者是执行跟踪清单。把两者的回答对象分清，后续的字段设计和维护责任才有依据。
阶段决策记录：回答“这一次定了什么”
阶段决策记录对应一次具体的阶段评审，例如IPD体系中的决策评审点（DCP）或技术评审（TR）。它记录评审对象及其版本、参与角色、评审结论、决策依据与附加条件。结论通常落在继续、有条件继续、终止、暂缓这几类上。记录一旦定稿，就代表该次评审的正式结论，后续不应被随意改写。它的读者是评审参与者和需要追溯决策依据的管理者。
决策跟踪台账：回答“历次决策办到哪一步”
决策跟踪台账跨越多次评审，把各次决策产生的行动项汇总成一张可跟踪的清单。每条记录包含决策编号、行动项内容、责任人、期限、当前状态和关闭证据。台账的读者是项目管理者、行动项责任人和需要了解整体执行情况的干系人。台账的价值在于让“有条件继续”这类决策的附加条件不被遗忘，也让终止决策的收尾动作有据可查。
评审会议纪要：过程记录，不承担决策定稿
评审会议纪要记录的是会议过程：议题、讨论要点、分歧意见和待确认项。它帮助还原讨论脉络，但不适合作为决策的最终凭证，也不适合承担行动项的持续跟踪。常见的问题是纪要里写了结论、又写了行动项，台账再抄一遍，导致同一信息多处维护、口径不一致。合理的分工是：结论进决策记录，行动项进台账，纪要只保留过程。
三者定位对照
| 对象 | 回答的问题 | 时间跨度 | 主要读者 |
|---|---|---|---|
| 阶段决策记录 | 这一次评审定了什么 | 单次评审，定稿后作为凭证留存 | 评审参与者、需追溯决策依据的管理者 |
| 评审会议纪要 | 会上讨论了什么、分歧在哪 | 单次会议 | 评审参与者、后续接手人员 |
| 决策跟踪台账 | 历次决策定下的事办到哪一步 | 跨多次评审，持续到行动项关闭 | 项目管理者、行动项责任人、干系人 |
三者通过决策编号建立关联：决策记录是编号的源头，台账中的每条行动项都挂在该编号下，纪要可以引用编号指向对应决策。这样既保留了过程信息，又避免结论和行动项在多处重复。
同口径差异对照：记录内容、字段与维护责任
把三者放在同一组维度下比较，可以看清哪些内容必须唯一归属、哪些允许重叠。下表按记录对象、时间跨度、关键字段、维护角色、更新频率和关闭条件逐项对照。
| 维度 | 阶段决策记录 | 评审会议纪要 | 决策跟踪台账 |
|---|---|---|---|
| 记录对象 | 一次阶段评审的正式结论 | 一次会议的讨论过程 | 跨多次决策的行动项集合 |
| 时间跨度 | 单次评审，定稿后冻结 | 单次会议 | 从行动项生成到关闭 |
| 关键字段 | 评审类型（DCP/TR）、评审对象与版本、参与角色、结论类型、决策依据、附加条件 | 议题、讨论要点、分歧、待确认项 | 决策编号、行动项、责任人、期限、状态、关闭证据 |
| 维护角色 | 评审组织者或指定记录人 | 会议记录人 | 项目管理者或台账管理员，责任人更新状态 |
| 更新频率 | 评审时写入，定稿后只读 | 会议期间及会后整理 | 随行动项推进持续更新 |
| 关闭条件 | 结论定稿并经确认 | 纪要分发确认 | 全部行动项关闭并留存证据 |
字段归属上，评审类型、评审对象与版本、结论类型、决策依据属于决策记录的唯一归属内容，台账只引用决策编号，不复制结论原文。行动项、责任人、期限、状态、关闭证据属于台账的唯一归属内容。议题、讨论要点、分歧与待确认项属于纪要的唯一归属内容。允许重叠的只有决策编号和评审对象名称这类索引信息，用于跨文档检索和关联。
需要特别说明的是“有条件继续”的结论。结论本身写在决策记录里，附加条件则要拆成一条条可执行、可验收的行动项进入台账。拆分时每条行动项应写清做什么、谁负责、何时完成、以什么作为完成证据。条件描述含糊会导致台账无法判断是否真正关闭，这是实际落地中最常见的失效点。
信息重叠怎么处理：字段归属与流转规则
重复维护的根源通常不是字段设计，而是更新动作发生在多处。解决思路是让每个字段只有一个写入点，其他位置通过引用呈现。以下规则可直接用于团队约定。
- 结论只在决策记录中定稿。台账引用决策编号，需要查看结论时跳转到决策记录，不在台账里另存一份结论文本。
- 行动项从决策记录生成后进入台账。生成动作完成后，决策记录中保留行动项清单的只读快照，便于还原当时定了什么；后续状态变化只在台账中发生。
- 状态变更只在一处发生。行动项的状态、期限调整、关闭证据都在台账中更新，决策记录不跟随变化，避免两处状态不一致。
- 附加条件拆成可跟踪行动项。每条条件对应至少一条行动项，写明验收标准；条件全部满足后，才在台账中关闭并回填证据。
- 终止决策要收尾。决策为终止时，台账中该决策编号下未完成的行动项应逐条处理：确认不再需要的标记关闭并注明原因，仍需收尾的保留并设定新的期限，全过程留痕。
按“谁写、谁读、谁更新”归纳：决策记录由评审组织者写入并定稿，评审参与者和管理者阅读，定稿后不再更新；纪要由记录人写入，参与者阅读，会后确认即冻结；台账由项目管理者建立结构，责任人更新自己行动项的状态，管理者阅读整体进展。三者的写入点互不交叉，是避免重复维护的关键。
适配场景与选择建议：什么情况下分开维护
分开维护还是合并简化，取决于评审频次、阶段数量和合规要求，没有统一阈值，通过标准应由企业流程确定。以下按场景给出条件式建议。
评审频次高、阶段多时分开维护
在IPD体系下，DCP与TR往往并行推进，一个项目要经过概念、计划、开发、验证等多个阶段，每个阶段都可能产生决策和附加条件。此时决策记录数量多、行动项跨阶段延续，合并到一张表会让凭证属性和跟踪属性互相干扰：记录需要冻结，台账需要持续更新，两者更新节奏不同。分开维护能让决策记录保持凭证的稳定性，台账专注于执行跟踪。ONES的IPD解决方案中，概念阶段评估需求覆盖范围、技术可行性与商业价值，决定项目进入计划阶段或终止；计划阶段的PDCP基于评审结果批准基线版本的业务计划书；验证阶段的ADCP综合评估市场准入、生产成熟度与合规性，判定是否具备商业化发布资格。这些决策点各自产生需要跟踪的后续动作，正是分开维护的典型场景。
小团队低频评审时的简化做法
评审频次低、阶段少的小团队，可以用一张表同时承载记录与跟踪：以决策编号为主键，上半部分记录本次结论与依据，下半部分列出行动项与状态。这种做法的代价是凭证属性被削弱——表会持续被修改，历史结论的原始状态不易保留；一旦需要审计追溯，还要额外整理。简化可以接受，但应约定结论字段在定稿后锁定，只允许行动项区域更新。
合规与审计场景的凭证要素
有审计要求的场景，决策记录需要保留可核验的要素：评审类型与阶段、评审对象及版本、参与角色与确认记录、结论类型、决策依据、附加条件、定稿时间。这些要素构成“当时为什么这样定”的证据链。台账则需保留行动项的生成来源、责任人与期限、状态变更记录和关闭证据。两类留痕分开保存，追溯时按决策编号串联。
用ONES承载决策记录与台账的衔接
把上述规则落到工具中，核心是让评审、决策、行动项走同一条流程，并让决策编号成为关联纽带。ONES的IPD解决方案覆盖了从阶段评审到决策输出的过程：计划阶段的技术评审（TR2&TR3）验证整体技术方案与各子系统设计，阶段决策评审（PDCP）基于评审结果批准基线版本业务计划书；开发阶段的技术评审（TR4&TR5）验证产品原型，评审结果决定是否具备转入量产的条件；验证阶段的技术评审（TR6）完成技术定型。这些评审产生的结论和条件，需要有稳定的载体承接。
一条可操作的流程如下：
- 评审输入。以阶段评审工作项承载评审对象、参与角色和评审类型，工作项关联被评审的需求或设计文档及其版本，确保评审针对的是确定的基线。
- 决策输出。评审结束后，将结论类型、决策依据和附加条件写入评审记录文档并定稿。定稿即代表该次决策生效，文档转为只读状态。
- 行动项生成。把附加条件逐条拆成工作项，每个工作项关联决策编号，进入统一的跟踪视图。跟踪视图按决策编号、责任人、期限和状态组织，形成台账的呈现方式。
- 状态与关闭。责任人推进工作项并更新状态，关闭时回填证据；评审记录保持只读，需要查看原始结论时通过编号回到记录。
- 结果。决策记录与跟踪台账通过决策编号关联，结论只维护一次，行动项只更新一处，减少重复录入和口径不一致。
在选型或配置时，可以重点核验三点：决策编号能否作为工作项与文档之间的稳定关联字段；行动项状态变化能否在跟踪视图中集中呈现而不回写决策记录；评审记录定稿后能否限制编辑以保持凭证属性。这三点决定了“记录负责定、台账负责跟”的边界能否在工具中真正落地，而不是停留在制度文本上。
常见问题
决策记录定稿后，如果发现结论写错了，应该改记录还是新开一次评审？
取决于错误的性质。若只是文字表述或引用版本号写错，且不改变结论本身，可由评审组织者按团队约定的更正流程修订，并在记录中保留修订说明与时间，避免凭证被无声改写。若涉及结论类型变化，例如从“有条件继续”改为“终止”，这属于新的决策，应重新组织评审并生成新的决策记录，用新的决策编号关联原记录，原记录保持只读。台账中按新编号登记后续行动项，原编号下未完成的行动项按终止决策的收尾规则处理。
行动项在台账里关闭后，还需要回到决策记录里标注吗？
通常不需要。决策记录保留的是决策时点的原始状态，包括当时列出的附加条件清单，作为只读快照；行动项的完成情况由台账承载。若管理者需要从决策记录直接看到执行结果，可以通过决策编号跳转到台账视图查看，而不是把状态回写到记录中。这样处理的好处是记录始终能还原“当时定了什么”，台账始终反映“现在办到哪一步”，两者职责不混。
评审会上临时提出的改进建议，应该进决策记录还是台账？
先判断它是否属于本次决策的附加条件。与结论直接相关、构成“有条件继续”前提的建议，应写入决策记录的附加条件，再拆成行动项进入台账。与本次结论无直接关系、属于后续优化方向的建议，可留在纪要的待确认项中，由负责人评估后决定是否单独立项。不建议把所有会上提到的建议都塞进台账，否则台账会混入大量与阶段决策无关的条目，跟踪重点被稀释。
多个项目共用一套台账，还是每个项目单独建？
取决于跟踪主体是谁。若行动项责任人跨项目复用、管理层需要看整体执行负载，可建统一台账，用项目字段和决策编号区分来源，便于汇总统计。若各项目阶段节奏差异大、责任体系独立，按项目分建台账更清晰，跨项目汇总通过报表实现。两种方式都要保证决策编号全局可识别，避免不同项目的编号冲突导致关联错乱。合并与分建的取舍标准是跟踪视角，而不是数据量大小。
采用IPD体系时，DCP和TR产生的决策要分别建台账吗？
一般不需要分开建。DCP与TR的结论都属于阶段决策，行动项可以在同一台账中按评审类型字段区分，便于按类型筛选和统计。ONES的IPD解决方案中，计划阶段的技术评审（TR2&TR3）验证整体技术方案与各子系统设计，阶段决策评审（PDCP）基于评审结果批准基线版本业务计划书；开发阶段技术评审（TR4&TR5）的评审结果决定产品是否具备转入量产的条件。这些评审产生的后续动作都指向同一项目的推进，放在同一跟踪视图中更利于管理者掌握全貌。若企业流程对技术评审与决策评审的责任人体系完全分离，也可按类型分建，通过决策编号保持关联。
