计划基线建立与变更记录模板由两张表组成：基线建立表记录基线名称、基线范围、版本号、建立日期、审批人与审批结论；变更记录表记录变更编号、关联基线版本、变更原因、变更内容、影响评估、申请人、审批人、生效日期与回退说明。两表通过基线编号和版本号关联，基线范围、版本、审批信息、变更原因、生效日期为必填项。下面先给出可直接复制的空白表格，再逐字段说明填写口径，并附一份完整填写示例。
要点总览（TL;DR）
- 模板由两张表组成：基线建立表记录基线编号、基线范围、版本号、建立日期与审批信息；变更记录表记录变更编号、关联基线版本、变更原因、变更内容、影响评估、审批结论、生效日期与回退说明。
- 两表通过基线编号与版本号关联，同一基线可对应多条变更记录，每条变更只指向一个被修改的版本。
- 基线范围、版本、审批信息、变更原因、生效日期为必填项；必填缺失时基线视为未建立、变更视为未生效，应退回补填。
- 变更原因写触发因素，影响评估写波及范围与代价，两者分列填写，评审时先判断必要性再判断可承受性。
- 模板可按项目规模裁剪选填字段，必填字段不取消；模板自身标注版本与修订日期，历史记录保持原样。
可复制空白模板：基线建立表与变更记录表
先拿到表结构。基线建立表用于冻结某一时点的计划范围与版本，变更记录表用于登记基线生效后的每一次调整。两表共用“基线编号”作为主键，变更记录表再通过“关联基线版本”指向被修改的具体版本，从而形成一条可追溯的链条。
表一：基线建立表
| 字段 | 填写内容 |
|---|---|
| 基线编号 | |
| 基线名称 | |
| 基线范围 | |
| 版本号 | |
| 建立日期 | |
| 编制人 | |
| 审批人 | |
| 审批结论 | |
| 审批日期 | |
| 基线说明 |
表二：变更记录表
| 字段 | 填写内容 |
|---|---|
| 变更编号 | |
| 关联基线编号 | |
| 关联基线版本 | |
| 变更原因 | |
| 变更内容 | |
| 影响评估 | |
| 申请人 | |
| 申请日期 | |
| 审批人 | |
| 审批结论 | |
| 生效日期 | |
| 回退说明 |
使用时先填基线建立表，审批通过后该版本即成为比较基准；此后每次调整在变更记录表中新增一行，关联到对应基线编号与版本。同一基线可以有多条变更记录，但每条变更只对应一个被修改的版本，避免一条记录同时指向多个版本造成追溯混乱。
字段说明：每个字段记录什么、怎么填
字段口径统一，不同角色填出来的记录才能互相对照。下表按字段给出含义与填写要求，其中编号类字段建议在项目内约定统一规则后固定使用。
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 基线编号 | 基线的唯一标识 | 建议采用“项目简称-基线-两位序号”，如 PRJ-BL-01，建立后不再更改 |
| 基线名称 | 基线的业务含义 | 写明冻结的是哪一阶段或哪类计划，如“一期上线范围基线” |
| 基线范围 | 本次冻结覆盖的对象 | 列明纳入基线的计划项、交付物或工作包，并注明不纳入的部分，避免范围理解不一致 |
| 版本号 | 基线自身的版本 | 建议采用 V1.0、V1.1、V2.0 形式，首次建立用 V1.0，范围调整升主版本，局部修订升次版本 |
| 建立日期 | 基线正式生效的日期 | 填写审批通过当日，与审批日期保持一致或晚于审批日期 |
| 编制人 | 起草基线的人 | 填写实际编制者姓名，便于后续追溯 |
| 审批人 | 对基线负责的人 | 填写有权批准该范围的角色或姓名，多人审批时全部列出 |
| 审批结论 | 审批结果 | 填写“通过”“有条件通过”“退回”，有条件通过需在基线说明中写明附加条件 |
| 审批日期 | 结论作出的日期 | 与审批结论同时填写，作为基线生效的时间依据 |
| 基线说明 | 补充信息 | 记录审批附加条件、例外事项或与其他基线的衔接关系 |
| 变更编号 | 变更的唯一标识 | 建议采用“项目简称-CR-三位序号”，如 PRJ-CR-001，按提出顺序连续编号 |
| 关联基线编号 | 被修改的基线 | 填写基线建立表中的基线编号，确保两表可关联 |
| 关联基线版本 | 被修改的具体版本 | 填写变更发生前的版本号，如 V1.0，变更生效后产生新版本 |
| 变更原因 | 为什么要改 | 写触发变更的外部或内部因素，如需求调整、资源变化、风险应对，用事实描述，不写解决方案 |
| 变更内容 | 改了什么 | 具体列出增加、删除或调整的计划项与交付物，与变更原因分开填写 |
| 影响评估 | 改动波及的范围与代价 | 说明对进度、资源、成本、质量及相关基线的影响，给出受影响对象清单和结论 |
| 申请人 | 提出变更的人 | 填写实际提出者，便于沟通与责任归属 |
| 申请日期 | 变更提出的日期 | 用于计算审批周期 |
| 审批人 | 批准变更的人 | 与基线审批人保持同一权限层级，重大变更需更高层级审批 |
| 审批结论 | 变更审批结果 | 填写“通过”“不通过”“暂缓”，不通过时保留记录以备查 |
| 生效日期 | 变更正式执行的日期 | 填写审批通过后实际执行的日期，作为新旧版本切换的时间点 |
| 回退说明 | 变更失败时如何恢复 | 写明回退到哪个版本、需要哪些动作、由谁执行，复杂变更可附回退检查点 |
其中“变更原因”与“影响评估”最容易混填。前者回答“为什么必须改”，记录触发因素；后者回答“改了会怎样”，记录波及范围与代价。两者分列，评审时才能先判断必要性，再判断可承受性。
必填与选填：哪些字段缺一不可
必填字段决定记录是否成立，缺失时该基线或变更不予生效。基线建立表中，基线编号、基线范围、版本号、审批人、审批结论、审批日期为必填；变更记录表中，变更编号、关联基线编号、关联基线版本、变更原因、变更内容、申请人、审批人、审批结论、生效日期为必填。
必填字段清单
- 基线建立表：基线编号、基线范围、版本号、审批人、审批结论、审批日期。
- 变更记录表：变更编号、关联基线编号、关联基线版本、变更原因、变更内容、申请人、审批人、审批结论、生效日期。
选填字段的适用情形
- 基线名称、基线说明：基线数量少、编号已能说明含义时可简化填写；存在审批附加条件时必须补充说明。
- 编制人、申请日期：小团队中编制人与申请人重合时可省略，跨部门协作时建议保留以便追溯。
- 影响评估：局部微调且不涉及进度与资源时可简写，涉及范围、成本或交付节点变化时必须填写。
- 回退说明：一次性、不可逆的小调整可注明“无需回退”，涉及关键路径的变更必须写明回退方案。
必填字段缺失时，处理方式是退回补填而非默认通过。基线缺少审批结论或审批日期，视为尚未建立，不能作为比较基准；变更缺少变更原因或生效日期，视为未生效，执行时仍以原版本为准。这样处理可以避免“先执行、后补记录”造成的版本错位。
填写示例：一次基线建立与一次变更的完整记录
以下为演示情景，用于说明两张表如何配合，数据不代表真实项目。
基线建立表填写示例
| 字段 | 示例内容 |
|---|---|
| 基线编号 | PRJ-BL-01 |
| 基线名称 | 一期上线范围基线 |
| 基线范围 | 一期交付的 12 个工作包及对应验收标准；二期功能不纳入 |
| 版本号 | V1.0 |
| 建立日期 | 2025-03-10 |
| 编制人 | 项目经理 |
| 审批人 | 项目发起人、技术负责人 |
| 审批结论 | 通过 |
| 审批日期 | 2025-03-10 |
| 基线说明 | 后续范围调整须走变更记录，涉及验收标准的变更需技术负责人复核 |
变更记录表填写示例
| 字段 | 示例内容 |
|---|---|
| 变更编号 | PRJ-CR-001 |
| 关联基线编号 | PRJ-BL-01 |
| 关联基线版本 | V1.0 |
| 变更原因 | 客户新增一项数据导出要求，影响一期验收范围 |
| 变更内容 | 新增“数据导出”工作包，调整对应验收标准两条 |
| 影响评估 | 预计增加 5 个工作日，测试范围扩大，交付节点顺延一周；不影响二期计划 |
| 申请人 | 产品负责人 |
| 申请日期 | 2025-04-02 |
| 审批人 | 项目发起人 |
| 审批结论 | 通过 |
| 生效日期 | 2025-04-08 |
| 回退说明 | 若导出功能无法按期交付，回退至 V1.0 范围，导出需求转入二期 |
示例中基线 V1.0 建立后，变更记录以 PRJ-CR-001 关联到该版本，生效后基线演进为 V1.1。后续再有调整，新增 PRJ-CR-002 并关联 V1.1，形成连续版本链。字段名称与空白模板、字段说明表完全一致，复制模板后按此格式填写即可。
调整与维护方法：模板如何随项目演进
模板需要随项目规模裁剪，同时保持自身可追溯。以下规则可作为长期维护的检查清单。
按项目规模裁剪选填字段
- 小型项目可保留必填字段加基线说明，省略编制人、申请日期等辅助字段，减少填写负担。
- 跨部门或合规要求较高的项目，建议保留全部字段，并补充影响评估与回退说明的详细程度。
- 裁剪只针对选填字段，必填字段不因项目小而取消，否则基线无法作为比较基准。
模板自身的版本与变更留痕
- 模板文件本身标注版本号与修订日期，字段增删在修订说明中记录原因。
- 字段调整后，历史记录保持原样，新记录按新模板填写，避免回溯改写造成记录失真。
- 模板修订需经使用方确认，避免不同项目各自维护出互不兼容的字段口径。
基线与变更记录的归档与查阅
- 基线建立表与变更记录表按基线编号集中存放，同一基线的所有变更按编号顺序排列。
- 归档时保留审批结论与生效日期，作为版本切换的时间证据。
- 项目收尾时对基线与变更记录做一次完整性检查，确认每条变更都有对应审批与生效日期。
当项目计划在协作工具中管理时，可以把上述字段落到具体的工作项与版本记录上。ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，提早识别风险和问题；也支持通过对比版本细节追溯变更细节。将基线编号、版本号、审批结论、生效日期作为固定字段维护，变更记录与基线版本一一关联，归档和查阅时就能直接沿版本链回溯，模板的维护规则也随之落到日常操作中。
常见问题
基线已经建立但审批结论还没出来，可以先按新计划执行吗？
不建议。按模板的必填规则，缺少审批结论与审批日期的基线视为尚未建立，不能作为比较基准。此时执行仍以原版本为准，待审批通过并填写审批日期后，新基线才正式生效。若项目时间紧张，可先走有条件通过，并在基线说明中写明附加条件与补齐时限。
一次变更同时涉及多个基线版本，变更记录表怎么填？
按“一条变更只对应一个被修改版本”的规则拆成多条记录，每条记录关联各自的基线编号与关联基线版本，再用相同的变更原因说明它们属于同一次调整。这样版本链保持清晰，回退时也能按版本分别处理。若确实需要跨基线联动，可在影响评估中注明关联的其他变更编号。
小团队字段填不全，哪些可以省、哪些不能省？
可省的是选填字段，例如基线名称、编制人、申请日期，在人员重合、编号已能说明含义时可简化。不能省的是必填字段：基线建立表的基线编号、基线范围、版本号、审批人、审批结论、审批日期；变更记录表的变更编号、关联基线编号、关联基线版本、变更原因、变更内容、申请人、审批人、审批结论、生效日期。必填缺失时记录不成立，后续追溯会出现断点。
变更执行到一半发现不可行，回退说明应该提前写到什么程度？
回退说明在变更审批时就要填写，涉及关键路径的变更需写明回退到哪个版本、需要哪些动作、由谁执行。局部微调可注明“无需回退”，但要在影响评估中说明判断依据。执行中真的触发回退时，建议在变更记录中补充实际回退日期与结果，保持记录与实际一致。
模板字段和协作工具里的基线功能怎么对应？
可以把基线编号、版本号、审批结论、生效日期作为固定字段维护，让工具中的版本记录与模板记录一一对应。ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，提早识别风险和问题；也支持通过对比版本细节追溯变更细节。工具承担版本留痕与对比，模板承担字段口径与审批记录，两者配合使用即可沿版本链回溯。
