里程碑清单用来记录项目中的关键节点，一张表至少应包含六类信息：节点标识、计划与实际时间及偏差、负责人与验收方、交付物与验收标准、状态与依赖、变更记录。本文提供一张可直接复制到表格工具的空白清单，并说明每个字段的填写口径、必填与选填的取舍、一份版本发布项目的完整填写示例，以及清单建好后的更新与留痕方法。
要点总览（TL;DR）
- 里程碑清单以关键节点为一行记录单位，至少包含六类信息：节点标识、计划与实际时间及偏差、负责人与验收方、交付物与验收标准、状态与依赖、变更记录。
- 最小可用清单保留编号、名称、计划日期、负责人、交付物、状态六列；跨团队交付或对外承诺的项目，把验收标准、依赖和变更记录设为必填。
- 填写时名称要能判断完成与否，验收标准写成可核验条件，实际日期在节点达成当天填写，偏差由实际日期减计划日期得出。
- 清单按周更新状态与偏差，关键字段变更由项目负责人确认并追加变更记录；细粒度任务排期和阶段评审决策放在对应记录中，清单只保留引用。
可复制的里程碑清单空白模板
下面这张表以“关键节点”为一行记录单位，复制到 Excel、在线表格或项目管理工具的自定义表格中即可使用。表头字段与后文说明、示例保持一致，避免同一字段出现两种叫法。
| 节点编号 | 里程碑名称 | 所属阶段 | 计划日期 | 实际日期 | 偏差（天） | 负责人 | 验收方 | 交付物 | 验收标准 | 状态 | 前置依赖 | 关联任务/评审引用 | 变更记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| M-01 | |||||||||||||
| M-02 | |||||||||||||
| M-03 |
使用说明：一行只写一个关键节点；计划日期在节点确立时填写，实际日期在节点完成或验收通过时填写，偏差由两者相减得出；状态从“未开始、进行中、已完成、已延期、已取消”中选取；变更记录只追加、不覆盖，保留修改日期、修改人和原因。
每个字段记录什么：字段说明
字段说明解决“这一格该填什么、填到什么程度算合格”。下表按六类信息分组，给出含义与填写口径，填写时以本表为准。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 节点编号 | 节点的唯一标识 | 采用“M-序号”格式，按时间顺序递增；编号一经使用不复用，取消的节点保留编号并标注状态 |
| 里程碑名称 | 节点的简短名称 | 用“动作+对象+结果”描述，如“完成支付模块联调”，避免只写“阶段一”这类无法判断完成与否的名称 |
| 所属阶段 | 节点在项目阶段中的位置 | 填写阶段名称，与项目计划中的阶段划分一致 |
| 计划日期 | 节点预计达成的日期 | 填写具体日期而非周次；以验收通过为达成口径时，应预留验收时间 |
| 实际日期 | 节点实际达成的日期 | 节点完成或验收通过当天填写；未达成时留空 |
| 偏差（天） | 计划与实际的差距 | 实际日期减计划日期，正数为延期、负数为提前；未完成时可按当前日期估算并注明“预估” |
| 负责人 | 对节点达成负责的人 | 填一个人，不填团队或部门；负责人负责推进节点内的协调与汇报 |
| 验收方 | 确认节点达成的人或角色 | 填写具体角色或姓名，与负责人区分；验收方对验收标准作出通过与否的判断 |
| 交付物 | 节点达成时应产出的成果 | 写清成果名称与形态，如“联调报告”“可演示的测试环境”；多个交付物分行列出 |
| 验收标准 | 判断交付物合格的条件 | 写成可核验的条件，如“核心链路用例全部通过”；避免“基本完成”“效果良好”等无法判定的表述 |
| 状态 | 节点当前进展 | 从固定选项中选择，保证可筛选统计；状态变化时同步更新日期字段 |
| 前置依赖 | 节点达成所依赖的其他节点或外部条件 | 填写依赖的节点编号或外部事项，如“M-02 完成”“第三方接口开通” |
| 关联任务/评审引用 | 指向细粒度任务或阶段评审的入口 | 填写任务清单、评审记录的编号或链接，本表不展开任务明细 |
| 变更记录 | 节点关键信息的修改痕迹 | 记录修改日期、修改人、修改字段、原值与新值、原因；只追加不覆盖 |
必填与选填：最小可用清单怎么定
里程碑清单的必填字段应保证“能认出节点、能判断是否达成、能找到责任人”。在此基础上，依赖、引用和变更记录可按项目复杂度逐步补齐。
| 字段 | 精简版 | 完整版 | 说明 |
|---|---|---|---|
| 节点编号 | 必填 | 必填 | 保证节点可被引用 |
| 里程碑名称 | 必填 | 必填 | 名称需能判断完成与否 |
| 计划日期 | 必填 | 必填 | 节点的时间基准 |
| 负责人 | 必填 | 必填 | 明确推进责任 |
| 交付物 | 必填 | 必填 | 没有交付物的节点难以验收 |
| 状态 | 必填 | 必填 | 支撑进度跟踪 |
| 实际日期与偏差 | 选填 | 必填 | 精简版可在节点完成后补记；需要持续跟踪偏差时设为必填 |
| 验收方与验收标准 | 选填 | 必填 | 涉及跨团队交付、对外承诺时建议设为必填 |
| 所属阶段 | 选填 | 必填 | 节点较多、按阶段汇报时启用 |
| 前置依赖 | 选填 | 必填 | 节点之间存在先后制约时启用 |
| 关联任务/评审引用 | 选填 | 必填 | 需要从节点追溯到任务或评审记录时启用 |
| 变更记录 | 选填 | 必填 | 有外部承诺、合同节点或审计要求时必须保留 |
小团队、周期短、节点少的项目可采用精简版：保留编号、名称、计划日期、负责人、交付物、状态六列，节点完成后补记实际日期。节点跨多个团队、涉及对外交付或需要复盘偏差的项目采用完整版，把验收标准、依赖和变更记录纳入必填。
字段缺失时的处理原则是：缺失字段不猜测填写，用“待定”标注并在下次更新时补齐；影响验收判断的字段（如验收标准）缺失时，该节点不进入“已完成”状态。精简版升级为完整版时，先补齐存量节点的验收方与验收标准，再启用依赖和变更记录字段。
填写示例：一个版本发布项目的里程碑清单
以下示例为演示情景：某团队计划发布 V2.3 版本，设定四个关键节点。示例中的日期与人员为示意数据，用于说明字段如何取值。
| 节点编号 | 里程碑名称 | 所属阶段 | 计划日期 | 实际日期 | 偏差（天） | 负责人 | 验收方 | 交付物 | 验收标准 | 状态 | 前置依赖 | 关联任务/评审引用 | 变更记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| M-01 | 完成需求范围冻结 | 规划 | 2025-03-07 | 2025-03-07 | 0 | 产品负责人 | 项目负责人 | V2.3 需求清单 | 需求条目全部标注优先级并通过评审 | 已完成 | 无 | 评审记录 R-012 | — |
| M-02 | 完成核心功能开发与联调 | 开发 | 2025-04-11 | 2025-04-15 | +4 | 开发负责人 | 测试负责人 | 联调通过的测试环境、联调报告 | 核心链路用例全部通过 | 已完成 | M-01 | 任务清单 T-100 至 T-140 | 2025-04-08 开发负责人将计划日期由 04-11 调整为 04-15，原因：第三方接口延期，验收方已知悉 |
| M-03 | 完成回归测试并达到发布标准 | 测试 | 2025-04-25 | 预估 +2 | 测试负责人 | 项目负责人 | 回归测试报告、缺陷清单 | 阻塞级缺陷清零，遗留缺陷均有处理结论 | 进行中 | M-02 | 评审记录 R-018 | — | |
| M-04 | 完成 V2.3 版本发布 | 发布 | 2025-04-30 | 发布负责人 | 项目负责人 | 发布记录、上线公告 | 生产环境验证通过，回滚方案就绪 | 未开始 | M-03 | 发布单 D-007 | — |
关键字段的取值理由：M-02 的名称写成“完成核心功能开发与联调”，验收方据此可以判断节点是否达成；计划日期填具体日期，实际日期在联调通过当天填写，偏差由 04-15 减 04-11 得出 +4。M-03 尚未完成，实际日期留空，偏差按当前进度估算并标注“预估”，状态为“进行中”，避免把估算值当成事实。
偏差与状态需要联动记录：节点延期时，先更新计划日期或实际日期，再在变更记录中写明修改人、原值、新值和原因；状态从“进行中”变为“已完成”时，必须同时具备实际日期和验收结论。示例中 M-02 的变更记录保留了原计划日期，后续复盘可以直接看到延期发生在哪个环节。
示例与字段说明保持一致：每一列都对应前文说明表中的字段，没有新增列；验收标准写成可核验条件，依赖列只填节点编号，任务与评审通过引用列指向外部记录，不在本表展开明细。
调整与维护：让清单随项目更新
清单的价值取决于更新是否及时、变更是否留痕。建议把维护动作绑定到固定的项目节奏上，而不是等到汇报前集中补填。
- 更新时点：每周例会后更新状态与偏差；节点完成或验收通过当天填写实际日期；计划日期调整时同步写入变更记录。
- 责任人：节点负责人维护本人节点的进度与交付物信息，项目负责人或项目管理角色负责整体复核、字段口径统一和归档。
- 变更审批：计划日期、验收标准、负责人等关键字段的修改，由项目负责人确认后生效；涉及对外承诺的节点变更，需同步通知验收方并记录确认结果。
- 分工边界：本表只记录关键节点，细粒度任务排期与任务依赖放在任务清单中，通过引用列关联；阶段评审的决策结论放在评审记录中，节点表只保留评审引用和结论状态。
- 定期复核：每个阶段结束时核对节点编号是否连续、状态与实际是否一致、延期节点是否都有变更记录；项目结束后将清单归档，作为后续项目估算与复盘的输入。
更新检查项可以固化为一张短清单：本周是否有节点状态变化未记录；延期节点是否写明了原因与调整后的日期；已完成节点是否都有实际日期和验收结论；引用列指向的任务或评审记录是否仍然有效；变更记录是否只追加未覆盖。
当清单需要在多人之间共享并持续跟踪时，可以借助项目管理工具承载节点状态、负责人和变更痕迹。ONES 支持用里程碑标记项目中的重要时间点、事件或决策点，并可设置项目计划和里程碑基线，实时对比计划与执行的偏差，通过版本细节对比追溯变更；其瀑布项目方案中，客户也以关键里程碑和交付物进行规范化管理。将本文的字段映射为工具中的里程碑属性与状态后，更新节奏和变更规则仍按上述清单执行，工具承担的是记录、对比与追溯的载体作用。
常见问题
里程碑清单和任务清单可以合并成一张表吗？
可以放在同一个工具里，但建议分成两张表。里程碑清单一行对应一个关键节点，字段围绕验收和偏差；任务清单一行对应一项可执行工作，字段围绕排期、依赖和工时。合并后节点行会被大量任务行淹没，进度汇报时难以快速定位关键节点。两张表通过“关联任务/评审引用”列互相指向即可。
节点延期后，计划日期应该改还是保留原值？
两种做法对应不同用途。需要保留原始承诺时，计划日期不改，另设一列记录调整后的预计日期，偏差按预计日期计算并标注“预估”；需要以最新计划为基准时，直接修改计划日期，同时在变更记录中写明原值、新值、修改人和原因。无论选哪种，同一项目内口径要统一，避免复盘时无法还原延期发生的时点。
验收标准写到什么程度才算合格？
标准是验收方不看其他材料也能作出通过与否的判断。例如“核心链路用例全部通过”“阻塞级缺陷清零且遗留缺陷均有处理结论”，都能直接核对；而“基本完成”“质量达标”这类表述无法判定。涉及跨团队交付时，建议在节点确立阶段就由负责人和验收方共同确认标准，减少验收时的分歧。
项目进行到一半才建里程碑清单，存量节点怎么补？
先补必填字段：编号、名称、计划日期、负责人、交付物、状态。已完成节点补记实际日期和验收结论，缺验收标准的节点先标注“待定”，由负责人和验收方确认后再改为“已完成”。依赖和变更记录可以随后补齐，但已发生的计划调整应在变更记录中说明，避免历史信息丢失。
用项目管理工具承载里程碑清单，需要注意什么？
重点是把字段口径先定下来，再映射到工具属性，否则不同人建出的里程碑结构不一致。ONES 支持用里程碑标记项目中的重要时间点、事件或决策点，并可设置项目计划和里程碑基线，实时对比计划与执行的偏差，通过版本细节对比追溯变更。工具承担记录与追溯，更新节奏和变更规则仍需团队约定并执行。
