需求变更审批记录是变更单流转过程中形成的批准证据，记录审批人、审批时间、审批意见与审批结论；需求变更单承载变更内容与流转状态，评审记录留痕评审过程的分析与意见，版本基线则是变更被批准并纳入后形成的需求版本快照。四者的关系可以概括为：变更单是主线，评审记录与审批记录是挂在主线上的两类过程证据，版本基线是变更生效后的结果状态。本文讨论的范围限于需求对象的版本与变更，跨资产配置和对外发布版本只作边界提示。
要点总览（TL;DR）
- 需求变更审批记录是对某张变更单某次审批动作的结果留痕，最小字段包括审批人、审批时间、审批意见、审批结论。
- 需求变更单承载变更内容与流转状态，是主线对象；评审记录留痕评审过程的分析与风险意见；版本基线是变更获批并纳入后形成的需求版本快照。
- 四者形成单向推进、可反向回溯的链路：变更单发起评审，评审通过进入审批，审批通过并入需求生成新基线，基线可回溯到变更单及其评审、审批记录。
- 常见混淆有三处：把评审意见当审批结论、把变更单状态当审批记录、把需求基线当对外发布版本。
- 落地时在变更单发起时明确影响范围，评审节点保留分析与风险意见，审批环节留下结论与条件，基线生成时登记纳入的变更清单。
需求变更审批记录是什么
需求变更审批记录是对某一张需求变更单的某一次审批动作所作的结果留痕。它回答的问题是：这次变更由谁在什么时间审批、给出了什么意见、最终是批准还是驳回。审批记录依附于变更单存在，脱离具体变更单的审批记录无法说明它批准了什么。
从最小字段看，一条完整的审批记录应能支撑事后追溯和责任确认。字段不必多，但缺一项就会削弱证据效力：
| 字段 | 作用 | 缺失后的影响 |
|---|---|---|
| 审批人 | 标识作出审批结论的责任主体 | 无法确认谁对批准结果负责 |
| 审批时间 | 确定审批动作发生的时点 | 难以判断变更是否在基线冻结前获批 |
| 审批意见 | 说明批准或驳回的理由与附加条件 | 后续执行缺少条件约束的依据 |
| 审批结论 | 明确批准、驳回或要求补充 | 变更单状态变化失去证据支撑 |
审批记录与变更单正文、评审意见的分工在于：变更单正文描述“改什么”，评审意见记录“大家怎么分析这个改法”，审批记录只承载“是否同意改”的结论性证据。审批记录不重复变更内容，也不替代评审中的风险讨论，它是一条结论证据，而不是分析材料。
四个对象的边界：变更单、评审记录、审批记录、版本基线
四个对象容易混用，原因之一是它们都围绕同一次变更出现。把各自承载什么、不承载什么划清，后续的关联关系才有讨论基础。
| 对象 | 承载内容 | 不承载的内容 |
|---|---|---|
| 需求变更单 | 变更内容、变更原因、影响范围、优先级、流转状态 | 评审中的具体讨论过程、审批结论的签署证据 |
| 评审记录 | 评审参与人、分析意见、风险识别、备选方案讨论、评审结论建议 | 正式的批准或驳回决定 |
| 审批记录 | 审批人、审批时间、审批意见、审批结论 | 变更内容描述、评审分析过程 |
| 版本基线 | 被批准变更纳入后形成的需求版本快照，包含该时点需求条目的集合状态 | 单条变更的讨论与审批细节 |
边界上有两点需要说明。跨资产的配置项管理与基线管理属于配置管理范畴，涉及多个资产类型之间的基线协调，不在本文讨论的需求对象版本范围内。对外发布的研发版本与发布管理属于版本与发布管理范畴，它关心的是交付物如何打包发布，与需求版本基线是不同层面的对象。
审批记录如何与变更单、评审记录、版本基线关联
四者在流程中形成一条单向推进、可反向回溯的链路。变更单发起后进入评审，评审记录挂在变更单下；评审通过后进入审批，审批记录指向同一张变更单；审批通过后变更内容并入需求，形成新的版本基线；版本基线可以回溯到对应的变更单及其评审、审批记录。
这条链路的关键在于引用关系而非复制关系。评审记录和审批记录都通过变更单编号与变更单关联，而不是各自独立存在；版本基线在生成时记录本次纳入的变更单清单，从而保留从基线回到变更源头的路径。这样做的价值是：当有人质疑某个需求版本为什么是现在这个样子，可以沿基线找到变更单，再沿变更单找到评审意见和审批结论，形成完整的证据链。
在工具承载上，这条链路需要变更单、评审节点与审批留痕在同一管理对象体系内打通。ONES 的方案围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯；当某个需求发生变化时，可以沿关联关系分析受影响的任务、测试和交付内容，同时保留过程追踪和审计依据。这一能力的前提是需求与任务、测试、交付内容之间已经建立关联关系，具体字段与审批配置方式以实际部署为准。
容易混淆的相邻概念
实际工作中，混淆往往发生在三组对象之间。区分它们不需要复杂判断，关键是看这个对象回答的是哪个问题。
- 审批记录与评审记录。评审记录回答“这个变更方案是否合理、有哪些风险”，是过程分析；审批记录回答“是否同意执行”，是结论证据。评审结论建议可以写“建议批准”，但它本身不是批准，只有审批记录中的审批结论才具备批准效力。
- 审批记录与变更单状态字段。变更单上的“已批准”是一个状态值，表示当前流转到哪一步；审批记录是支撑这个状态变化的证据，包含谁批的、何时批的、批的条件是什么。状态可以被后续操作改变，审批记录作为历史证据应当保留。把状态字段当作审批记录，会在追溯时丢失责任人和审批理由。
- 版本基线与发布版本。版本基线是需求对象在某一时点的快照，用于控制需求范围的稳定与可比；发布版本是对外交付的研发版本，涉及构建、测试通过和发布计划。一个需求基线可能对应多个发布版本，一个发布版本也可能包含多个基线中的需求。两者归属不同管理域，不能互相替代。
一个具体例子与常见误解
假设某产品团队在需求基线 V1.2 冻结后，收到一条变更：将登录页的短信验证码有效期从 60 秒调整为 120 秒。变更单记录了变更内容、影响范围（涉及登录模块与安全策略文档）和提出人。随后进入评审，评审记录中安全负责人提出有效期延长会增加暴力破解风险，建议同时增加失败次数限制，产品经理同意该建议，评审结论为“有条件通过”。
评审通过后进入审批，审批人查看变更单与评审记录，在审批意见中写明“同意调整有效期，但失败次数限制须在同一版本内实现”，审批结论为批准。变更内容并入需求后，团队生成新的需求基线 V1.3，基线记录中列出本次纳入的变更单编号。数月后审计人员询问 V1.3 中验证码策略的由来，团队从基线找到变更单，从变更单找到评审记录中的风险讨论和审批记录中的附加条件，确认失败次数限制已随同一版本交付。
这个例子中常见的误解有三类。第一类是把评审意见当审批结论：评审中“有条件通过”只是建议，若没有后续审批记录，这次变更并未获得正式批准。第二类是把变更单状态当审批记录：变更单显示“已批准”只能说明流程走到了这一步，审计需要的是审批人、时间和附加条件，这些只在审批记录中。第三类是把基线当发布版本：V1.3 是需求基线，它说明需求范围在此时点被固定，并不等于该基线已经对外发布，发布状态要看研发版本与发布管理的记录。
把四者的关系落到日常管理动作上，团队需要在变更单发起时明确影响范围，在评审节点保留分析与风险意见，在审批环节留下结论与条件，在基线生成时登记纳入的变更清单。ONES 的方案可将标准流程、评审节点、交付物模板和过程数据沉淀为可复用资产，适合需要把变更流转与审批留痕固定为组织惯例的团队；具体流程设计仍需结合项目实际，基线冻结与审批时点的先后顺序也应按团队交付节奏确定。
常见问题
评审结论写“有条件通过”，是否等同于变更已被批准？
不等同。评审结论中的“有条件通过”属于评审记录里的建议性判断，说明评审参与人对方案的态度和附加要求。正式批准需要审批记录中的审批结论，并写明审批人、审批时间和审批意见。如果评审之后没有进入审批环节，这次变更在流程上并未获得批准，附加条件也缺少正式约束力。实际操作中，可以把评审建议的条件写入审批意见，让审批结论同时确认条件内容，避免条件在执行中丢失。
变更单状态显示“已批准”，还需要单独保留审批记录吗？
需要。变更单上的状态字段表示当前流转到哪一步，是结果值；审批记录是支撑这一状态变化的证据，包含谁批的、何时批的、批的条件是什么。状态可能因后续操作被改写或回退，审批记录作为历史证据应当独立保留。审计或复盘时，仅凭状态字段无法回答责任主体和批准理由，追溯链条会在这里断开。
需求版本基线与对外发布版本可以互相替代吗？
不能互相替代。需求版本基线是需求对象在某一时点的快照，用于固定需求范围、支持范围比较和变更追溯；对外发布版本属于研发版本与发布管理范畴，关心交付物如何构建、测试和发布。一个需求基线可能对应多个发布版本，一个发布版本也可能包含多个基线中的需求。判断某个需求是否已对外交付，需要查看发布管理记录，基线本身只说明需求范围在此时点被固定。
审批记录需要保留哪些内容才算完整？
最小字段是审批人、审批时间、审批意见、审批结论四项。审批人标识责任主体，审批时间用于判断审批是否发生在基线冻结等关键时点之前，审批意见承载批准或驳回的理由与附加条件，审批结论明确批准、驳回或要求补充。字段不必多，但缺任一项都会削弱证据效力。若审批涉及多人或多级，应保留每一级的记录，而不是只留最终结论。
变更被驳回后，评审记录和审批记录还要保留吗？
建议保留。驳回同样是一次审批动作的结果，审批记录中的驳回理由对后续重新提出变更、评估方案调整都有参考价值。评审记录中的风险分析和反对意见，也可能在下一轮变更中被再次引用。保留被驳回变更的完整记录，可以避免同一问题反复讨论，也便于说明某个需求范围为何在当前基线中未被纳入。
