文档版本与生命周期管理要解决的是“同一份文档在不同阶段由谁负责、以哪个版本为准、过期后怎么处理”。做法是先按文档类型划分阶段，再为每个阶段定义准入条件、版本规则和责任人，用评审与发布节点控制质量，用复审与归档处理过期内容。本文覆盖知识文档从起草到归档的完整流程，研发资产基线与内容审核标准不在展开范围内。
要点总览（TL;DR）
- 先按用途划分文档类型，再为每类指定阶段序列：草稿、评审中、已发布、修订中、已归档；会议记录等轻量文档可跳过评审。
- 版本号采用“主版本.次版本”两段式，主版本对应结构性变更，次版本对应文字修订；每次修订追加变更记录，保留旧版本不覆盖。
- 评审、发布、复审三个控制点各自明确输入、动作、输出和完成标志；复审按文档类型设定周期，结论分为保留、修订、废止。
- 作者、评审人、发布负责人、文档管理员四类角色按阶段分工，小团队可合并角色，但作者与评审人尽量分离。
- 上线前用分类覆盖度、版本可追溯性、评审发布责任、复审机制、归档可用性五项检查验收，先选一类高频文档试点再推广。
先定文档类型与生命周期阶段
生命周期管理的起点是承认不同文档的管理强度不同。把所有文档都塞进同一套重流程，团队会绕过流程；所有文档都随意存放，关键内容又无法追溯。可行的做法是先按用途分类，再为每类指定阶段序列。
常见分类可以按用途划分：制度规范（约束行为的规则）、操作指引（完成某件事的步骤）、方案设计（对某个问题的解决思路）、会议记录（对讨论过程的留痕）、复盘总结（对已完成事项的回顾）。分类不必追求完备，覆盖团队八成以上文档即可，新增类型时补入对照表。
阶段序列建议统一为五个状态：草稿、评审中、已发布、修订中、已归档。五态的好处是状态含义清晰，任何一份文档在任何时刻都能回答“它现在处于什么位置”。
| 文档类型 | 阶段序列 | 简化规则 |
|---|---|---|
| 制度规范 | 草稿→评审中→已发布→修订中→已归档 | 完整流程，必须评审后发布，设定复审周期 |
| 操作指引 | 草稿→评审中→已发布→修订中→已归档 | 完整流程，评审人可为一线使用者代表 |
| 方案设计 | 草稿→评审中→已发布→修订中→已归档 | 完整流程，评审与方案决策会合并 |
| 会议记录 | 草稿→已发布→已归档 | 跳过评审，发布即定稿，按季度归档 |
| 复盘总结 | 草稿→评审中→已发布→已归档 | 评审可简化为负责人确认，不设修订中 |
阶段划分需要与相邻管理动作划清边界。研发资产基线关注的是需求、代码、测试用例等配置项的版本一致性，本文讨论的是知识文档自身的状态流转；内容审核标准解决“什么内容可以发布”，本文只规定“发布前必须经过谁确认”。两者在评审节点上衔接，但规则来源不同，不要混用同一套检查表。
版本号规则与变更记录怎么写
版本号的作用是让任何人看到编号就能判断这次改动的影响程度。建议采用“主版本.次版本”两段式：主版本递增表示结构性变更，例如章节增删、适用范围调整、关键结论改变；次版本递增表示文字修订，例如措辞优化、补充示例、修正笔误。草稿阶段可用 0.x 标识，首次发布定为 1.0。
变更记录是版本可追溯的核心，每完成一次修订就追加一条记录，字段固定、不留空：
- 版本号：本次修订后的编号，如 1.2。
- 变更人：实际执行修改的人，而非审批人。
- 变更时间：精确到日期，跨时区协作时注明时区。
- 变更摘要：一句话说明改了什么，例如“补充第 3 节异常处理步骤”。
- 影响范围：说明受影响的章节、关联流程或需要同步通知的角色。
填写示例：版本号 1.1，变更人张某，变更时间 2025-03-12，变更摘要“修正审批时限表述，由 3 个工作日改为 2 个工作日”，影响范围“第 2 节，需通知各业务线接口人”。
修订时保留旧版本，不做覆盖。保留旧版本的价值在于：出现争议时可以回溯当时的依据，新人可以了解规则演变过程，复审时可以对照历史判断是否需要再次调整。版本与发布状态对应：只有“已发布”状态的版本对外生效，草稿和修订中的版本仅供参考，不能作为执行依据。发布新版本时，旧版本状态改为“已被替代”，仍可查看但标注失效。
评审、发布与复审的操作步骤
三个控制点各自解决一个问题：评审解决内容是否正确，发布解决谁在什么时候开始执行，复审解决内容是否仍然有效。每一步都要有明确的输入、动作、输出和完成标志。
评审
触发条件：文档从草稿提交评审，或修订中的版本完成修改后重新提交。参与角色至少包括作者、评审人和发布负责人，涉及跨部门执行的制度还需相关业务方代表参加。动作是评审人对照检查项逐条确认，意见写入文档评论或评审记录。输出是评审结论：通过、有条件通过、退回修改。完成标志是评审记录中所有评审人给出结论，且无未关闭的阻断性意见。
发布
输入是通过评审的文档版本。动作包括：将状态改为“已发布”，确认版本号，填写生效时间，按影响范围通知相关角色。输出是发布记录和通知留痕。完成标志是目标读者确认收到通知，且文档状态与版本号在文档列表中可见。
复审
周期设定按文档类型区分：制度规范每 12 个月复审一次，操作指引每 6 个月，方案设计在项目结项后 3 个月内复审，会议记录不设复审直接归档。复审结论分三类：保留（内容仍有效，更新复审日期）、修订（进入修订中状态，走变更流程）、废止（状态改为已归档，并在原位置标注替代文档）。完成标志是复审记录中写明结论、日期和复审人。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 评审 | 草稿或修订稿 | 评审人逐条确认，记录意见 | 评审结论与意见清单 | 全部评审人给出结论，阻断意见关闭 |
| 发布 | 通过评审的版本 | 改状态、定版本号、填生效时间、通知 | 发布记录与通知留痕 | 读者确认收到，状态与版本可见 |
| 复审 | 已发布且到期文档 | 评估有效性，给出保留/修订/废止结论 | 复审记录 | 结论、日期、复审人齐全 |
过期文档的处置路径要写死：到期未复审的文档自动标记“待复审”，超过宽限期（如 30 天）仍未处理则转为“已归档”，归档文档保留可查，但在文档列表和搜索结果的显著位置标注“已失效，请以最新版本为准”。
角色分工与各阶段交付物
责任悬空是生命周期管理最常见的失败原因。四类角色覆盖全流程：文档作者负责内容产出与修订，评审人对内容正确性负责，发布负责人对生效时间和通知范围负责，文档管理员对分类、状态和归档负责。
| 阶段 | 文档作者 | 评审人 | 发布负责人 | 文档管理员 |
|---|---|---|---|---|
| 草稿 | R：撰写初稿，标注版本 0.x | I：了解即将评审的内容 | I | A：确认分类与模板 |
| 评审中 | R：回应意见，修订内容 | R：给出评审结论 | C：确认发布条件 | A：跟踪评审进度 |
| 已发布 | I：接收反馈 | I | R：执行发布与通知 | A：登记发布记录 |
| 修订中 | R：执行变更，递增版本 | C：确认变更范围 | I | A：核对变更记录完整性 |
| 已归档 | I | I | I | R：执行归档与失效标注 |
权限设置与角色对应：作者可创建和编辑草稿，评审人可评论和给出结论，发布负责人可将状态改为已发布，文档管理员可归档和调整分类。小团队可以把评审人与发布负责人合并为一人，把文档管理员职责交给项目负责人兼任，但作者与评审人应尽量分离，避免自写自审。合并角色时在职责矩阵中注明兼任关系，防止后续交接时遗漏。
当文档数量增长后，状态流转、版本记录和复审提醒需要载体。ONES Wiki 记录所有页面版本并支持随时查看与回滚，可为不同角色配置读写权限，页面模板库能一键创建制式化文档模板，页面组还可关联项目，使需求与文档互相对应。这些能力适合承载上述阶段流转与责任分工，具体状态字段和提醒规则的配置方式以团队实际使用环境为准。
一个完整示例：从起草到归档走一遍
以下为演示情景，用于说明流程如何串起来，不代表真实案例。
某团队需要制定一份《线上故障响应指引》。作者在文档库中新建页面，选择“操作指引”模板，状态为草稿，版本标记 0.1，内容包含故障分级、上报路径和响应时限。初稿完成后提交评审，版本仍为 0.1，状态改为评审中。
评审人提出两条意见：响应时限与现有值班制度冲突，缺少升级路径。作者逐条回应，修改后版本递增为 0.2，变更记录写明“调整响应时限为 15 分钟，新增三级升级路径”，影响范围为第 2、3 节。第二轮评审通过，发布负责人将状态改为已发布，版本定为 1.0，生效时间为次月 1 日，通知全体研发与运维人员。
三个月后值班制度调整，作者发起修订，状态改为修订中，版本从 1.0 递增为 1.1，变更摘要为“同步新值班制度，更新联系人列表”，旧版本 1.0 保留并标注已被替代。修订稿经评审后重新发布为 1.1。
六个月复审期到时，文档管理员发起复审，复审人确认内容仍适用，结论为保留，更新复审日期。一年后该指引被新的《故障管理与应急响应规范》替代，原文档状态改为已归档，页面顶部标注“已失效，请参阅新规范”，归档记录中写明替代文档名称和归档日期。整条轨迹中，每个版本都能查到变更人、时间和摘要，任何时点的执行依据都可还原。
上线前的完成检查
机制是否跑通，不看制度写得多完整，看能否通过以下检查。每项给出通过标准和阻断项，阻断项未解决不建议全面推广。
| 检查项 | 通过标准 | 阻断项 |
|---|---|---|
| 分类与阶段表覆盖度 | 主要文档类型均有对应阶段序列和简化规则 | 存在大量文档无法归入任何类型 |
| 版本可追溯性 | 随机抽取三份文档，能查到任意历史版本及其变更记录 | 存在覆盖旧版本、无法回溯的情况 |
| 评审与发布责任 | 每个已发布文档都有评审记录和发布负责人 | 关键制度类文档无评审记录 |
| 复审机制 | 复审周期已按类型设定，到期文档能被识别 | 无任何到期识别手段，复审依赖个人记忆 |
| 归档可用性 | 归档文档可查，且标注失效与替代关系 | 归档文档仍被当作有效依据引用 |
建议先选一类高频文档试点，跑通“创建—评审—发布—变更—复审—归档”全流程，用上述检查项验收后再推广到其他类型。试点阶段重点观察两件事：评审是否真的拦住了问题，复审到期是否有人响应。这两点成立，机制才算落地。
常见问题
文档数量不多的小团队，需要完整执行五阶段流程吗？
可以按文档类型简化，不必全部走完整流程。会议记录、周报这类过程留痕文档可只保留草稿、已发布、已归档三个状态，跳过评审和修订中；制度规范、操作指引这类会被反复引用的文档建议保留完整五态。简化时把规则写进文档类型对照表，避免同一类文档在不同人手里走不同流程。
旧版本保留后，怎么避免有人继续按过期版本执行？
关键在状态标注与通知同步。新版本发布时，旧版本状态改为“已被替代”，在页面显著位置标注失效和替代文档名称；发布通知中写明生效时间和替代关系。复审时若结论为废止，同样在原位置标注失效。归档文档保留可查，但在列表和搜索结果中提示“已失效，请以最新版本为准”。
复审到期后没人处理，流程会卡在哪里？
常见卡点是复审依赖个人记忆，没有到期识别手段。建议按文档类型设定复审周期后，由文档管理员定期导出到期清单，或借助协作平台的页面组织与提醒能力跟踪。设置宽限期（如 30 天），到期未复审自动标记“待复审”，超过宽限期转为“已归档”并标注失效，让过期文档自然退出执行依据范围。
评审人和发布负责人由同一人兼任，会有什么风险？
小团队合并这两个角色是可行的，风险主要在发布环节缺少第二道确认。缓解办法是发布前要求评审记录完整、阻断性意见全部关闭，发布负责人按检查项逐条核对后再改状态。作者与评审人仍应尽量分离，自写自审会让评审失去拦截作用。
用协作平台承载这套流程时，需要重点确认哪些能力？
重点看三件事：版本记录能否查看和回滚、权限能否按角色区分读写、文档能否按类型组织并关联项目。ONES Wiki 记录所有页面版本并支持随时查看与回滚，可为不同角色配置读写权限，页面模板库能一键创建制式化文档模板，页面组还可关联项目。状态字段的自定义流转和复审提醒的具体配置方式，以团队实际使用环境为准。
