团队已有多个任务模板时，版本管理的难点往往不在编号本身，而在于让每次变更都能被后来人读懂、定位和回退。本文给出一套可直接套用的做法：版本号采用“主版本.次版本”两段式，结构性变化升主版本，文案与默认值调整升次版本；每次升版在同一记录中写清影响范围、字段差异、兼容处理与生效时间。下文依次说明编号规则、变更说明字段、旧版本保留判断、角色分工，并用一个从1.0到2.0的完整示例串起整套机制。
要点总览（TL;DR）
- 任务模板版本号采用“主版本.次版本”两段式，从1.0起编；字段结构、必填项、状态流转或模板用途变化升主版本，文案、默认值、示例、排序调整升次版本。
- 变更说明固定八个必填字段：变更日期、变更人、版本号、变更类型、影响范围、具体差异、迁移或兼容处理、生效时间与回滚方式，其中影响范围与迁移处理要写到具体对象和动作。
- 旧版本按引用情况分档保留：仍有项目引用时保留可读副本，完成切换并度过一个完整任务周期后转只读归档；涉及审计或对外交付的长期保留。
- 版本管理按“发起—评审—通知—切换—归档”推进，模板负责人、评审人、使用团队、归档人各有明确交付物。
- 用模板ID、当前版本号、模板名称三个标识固定追溯链条，名称可改，ID与版本号不可复用，版本号只增不减、不跳号。
版本号怎么编：两段式规则与升降级判断
任务模板的版本号建议采用“主版本.次版本”两段式，从1.0开始编号。主版本位表示模板的结构与使用约定发生变化，次版本位表示在不改变结构的前提下做内容优化。两段式的好处是：看到版本号就能大致判断这次变更对在用项目的影响程度，评审人也能据此快速核对版本位是否用对。
判断升哪一位，核心看变更是否改变“使用模板的人需要重新理解或重新填写的内容”。字段结构、必填项、状态流转、模板用途属于这一类，升主版本；描述文案、默认值、示例、排序不改变填写逻辑，升次版本。同一批次变更中只要包含一项结构性调整，整批按主版本发布，避免把结构变化藏在次版本里。
| 变更类型 | 版本位 | 示例编号 |
|---|---|---|
| 新增、删除或合并任务字段 | 主版本 | 1.3 → 2.0 |
| 字段由选填改为必填，或必填改为选填 | 主版本 | 1.3 → 2.0 |
| 状态名称、状态数量或流转路径调整 | 主版本 | 1.3 → 2.0 |
| 模板用途变化，如从缺陷跟踪改为需求评审 | 主版本 | 1.3 → 2.0 |
| 字段描述文案、帮助提示修改 | 次版本 | 1.3 → 1.4 |
| 默认值调整，如默认负责人、默认优先级 | 次版本 | 1.3 → 1.4 |
| 示例内容、字段排序、分组展示调整 | 次版本 | 1.3 → 1.4 |
版本号要与模板名称、模板ID分开管理。模板名称可能因为团队习惯或业务调整而修改，模板ID保持稳定，版本号只随内容变更递增。这样即使模板改了名，通过模板ID加版本号仍能定位到唯一一份历史记录，追溯链条不会断。建议在模板记录中固定三个标识：模板ID、当前版本号、模板名称，名称可改，前两者不可复用。
编号还有两条操作约定：一是版本号只增不减，回退时发布一个新的更高版本并注明“回退至某版本内容”，不直接把版本号改回去；二是不跳号，次版本连续递增，主版本升级时次版本归零，例如1.4之后的结构性变更发布为2.0，而不是2.4。
变更说明写什么：八个必填字段与填写示例
变更说明的作用是让没有参与本次修改的人，在几个月后仍能判断“这次改了什么、影响谁、怎么应对”。建议固定八个必填字段，缺一项就不算完成发布。字段不多，但每一项都对应一个后续会被问到的问题。
| 字段 | 填写要求 | 回答的问题 |
|---|---|---|
| 变更日期 | 实际发布生效的日期，精确到日 | 什么时候变的 |
| 变更人 | 发起并完成修改的模板负责人 | 谁改的、找谁问 |
| 版本号 | 变更后的新版本号，同时注明原版本号 | 从哪一版到哪一版 |
| 变更类型 | 结构性变更或非结构性变更，对应主版本或次版本 | 为什么升这一位 |
| 影响范围 | 涉及哪些模板、哪些团队或项目正在使用 | 谁会受影响 |
| 具体差异 | 逐项列出字段增删改、必填变化、状态与流转调整 | 到底改了什么 |
| 迁移或兼容处理 | 在用任务如何补齐新字段、旧数据如何映射、是否需要人工确认 | 存量怎么办 |
| 生效时间与回滚方式 | 新版本启用时点、旧版本停用安排、发现问题时如何退回 | 什么时候切换、出问题怎么办 |
八个字段中，影响范围和迁移处理最容易被写空。影响范围要落到具体对象，例如“研发一组、研发二组的迭代任务模板，当前约6个项目在用”，而不是“部分团队”。迁移处理要写动作，例如“存量任务的新字段留空，由各项目负责人在切换后一周内补齐”，而不是“注意兼容”。
一条完整的填写示例：变更日期2025年3月10日；变更人张某；版本号1.0→2.0；变更类型为结构性变更；影响范围为研发一组、二组共6个在用项目；具体差异为新增必填字段“验收标准”、删除“预计工时”字段、状态由“待办/进行中/完成”调整为“待办/开发中/待验收/已完成”；迁移处理为存量任务验收标准留空并由项目负责人一周内补齐，预计工时数据导出留档后不再写入；生效时间为2025年3月17日新建任务起适用，旧版本4月30日停用；回滚方式为若切换后两周内出现字段缺失问题，恢复1.0模板并将新任务迁回，回滚操作由模板负责人执行。
旧版本留不留：保留期限与只读归档判断
旧版本原则上要保留，但保留形态和期限可以分档。判断依据有两条：还有没有项目在引用，以及是否涉及审计或对外交付。两条都满足“否”的模板，才考虑彻底下线。
- 仍有项目引用：保留旧版本的可读副本，必要时保留可编辑状态，直到最后一个引用项目完成切换。切换期间新任务用新版本，存量任务继续按旧版本执行。
- 完成切换并度过一个完整任务周期：所有在用项目切到新版本，并且经历一个完整的任务周期（例如一个迭代或一个月度周期）后没有出现结构性问题，旧版本转为只读归档。
- 审计、对外交付或合规场景：涉及交付物验收、外部审计或合同约定的模板，长期保留只读副本，不设自动清理期限。
- 归档内容完整：只读副本要连同版本号、变更说明、生效区间一起保存，单独存一份模板结构而丢掉变更说明，等于失去了追溯价值。
归档时建议在模板索引中登记：模板ID、版本号、生效起止日期、归档日期、归档人。索引是查找入口，比逐个翻模板记录更可靠。对于已经确认无人引用、也不涉及审计的模板，可以在索引中标记“已下线”，记录本身仍保留，避免历史任务找不到对应模板版本。
角色分工与交付物：谁改、谁审、谁归档
版本记录无人维护，通常是因为责任没有落到具体动作上。任务模板的版本管理涉及四类角色，每个角色对应明确的输入和产出，规模小的团队可以由一人兼任多个角色，但动作不能省。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 模板负责人 | 发起变更，判断变更类型，编写变更说明，执行发布 | 新版本模板、完整变更说明 |
| 评审人 | 核对变更类型与版本位是否匹配，检查影响范围是否写全 | 评审确认记录，或退回修改意见 |
| 使用团队 | 确认本团队受影响的项目与任务，确认切换时间与迁移安排 | 切换确认，存量任务补齐结果 |
| 归档人 | 维护旧版本只读副本，更新模板索引与生效区间 | 归档副本、版本索引 |
流程上建议按“发起—评审—通知—切换—归档”五个动作推进：模板负责人提交变更说明草案；评审人确认版本位和影响范围；使用团队确认切换时间；到生效时间后执行切换并跟踪存量任务处理；度过完整任务周期后由归档人完成只读归档。每个动作都有可检查的产出，版本记录就不会停留在口头约定。
当模板数量增多、参与团队变多时，版本记录需要依托统一的工作项与文档载体，避免说明散落在聊天记录里。ONES 的工作项模板可以对任务字段、必填项与状态进行统一配置，模板调整后由负责人在对应工作项中发起变更；变更说明可作为文档与模板记录关联保存，评审意见和切换确认留在同一处，后续按版本号即可回溯每次调整的内容与生效时间。这样，模板负责人写说明、评审人核对、使用团队确认切换，都在同一条记录上完成，归档时也便于整理只读副本与索引。
落地示例：一个模板从v1.0到v2.0的完整记录
以下为演示情景，用于说明规则如何配合，不代表真实团队数据。某研发团队的需求任务模板1.0已使用半年，字段包括标题、描述、优先级、预计工时，状态为“待办/进行中/完成”。团队决定新增必填字段“验收标准”，删除“预计工时”，并把状态调整为“待办/开发中/待验收/已完成”。
版本号判断：本次同时涉及字段增删、必填项变化和状态流转调整，三项都属于结构性变更，因此从1.0升为2.0，次版本归零。如果本次只修改了“描述”字段的帮助文案，则应发布为1.1。
变更说明填写：变更日期为发布日；变更人为模板负责人；版本号1.0→2.0；变更类型为结构性变更；影响范围为使用该模板的3个项目组；具体差异逐项列出新增验收标准（必填）、删除预计工时、状态由三段改为四段；迁移处理为存量任务验收标准留空、由项目负责人在切换后一周内补齐，预计工时数据导出留档；生效时间为新任务即时适用，旧版本保留至切换后一个完整迭代结束；回滚方式为恢复1.0模板并将期间新建任务按旧字段补齐，由模板负责人执行。
旧版本处理：1.0在切换后继续保留可读状态，供存量任务按原结构执行；一个完整迭代结束、确认无项目引用后，转为只读归档，并在索引中登记生效区间为“2024年9月至2025年3月”，归档人同步更新索引。若该模板涉及对外交付验收，则只读副本长期保留。
完成检查：版本记录机制是否可用的核对项
机制建立后，用下面这份清单逐项核对，全部通过即可认为版本记录可用。建议每季度复查一次，模板数量增加时同步检查索引是否完整。
- 每个在用任务模板都有唯一模板ID和当前版本号，名称变更不影响ID。
- 每次变更都有对应变更说明，八个必填字段齐全，没有“部分团队”“注意兼容”这类空泛表述。
- 版本位与变更类型一致：结构性变更升主版本，非结构性调整升次版本，无跳号、无错位。
- 旧版本可查、可读，能定位生效区间，归档副本包含版本号与变更说明。
- 影响范围写到了具体团队或项目，使用团队已确认切换时间。
- 迁移处理写明了存量任务的具体动作和责任人，回滚方式可执行。
- 模板索引与实际模板记录一致，已下线模板有标记但记录未删除。
核对中发现的问题，按“缺什么补什么”处理：缺变更说明的补写并注明补录日期，版本位用错的在下次变更时纠正并在说明中注明，索引缺失的由归档人补齐。版本记录的价值在于长期可追溯，机制跑通后，模板调整就不再依赖个人记忆。
常见问题
模板只改了一个字段的默认值，也要写完整变更说明吗？
要写，但可以按次版本简化处理。默认值调整属于非结构性变更，版本号升次版本位，例如1.3→1.4。变更说明的八个字段仍需齐全，只是“具体差异”写清哪个字段的默认值从什么改为什么，“迁移或兼容处理”可以注明“存量任务不受影响，无需迁移”。字段齐全的意义在于后来人能判断这次变更的影响边界，而不是每项都要写长文。
同一批变更里既有字段调整又有文案修改，版本号怎么定？
按最高影响级别发布。一批变更中只要包含一项结构性调整，整批按主版本发布，次版本归零，例如1.4→2.0，而不是2.4。变更说明的“具体差异”中把结构性调整和文案修改分别列出，让读者看到主版本升级的原因。这样处理可以避免结构变化被藏在次版本里，导致使用团队按小改动对待而漏做迁移。
旧版本已经没人用了，可以直接删除吗？
建议保留记录、标记下线，不做物理删除。历史任务可能仍关联旧版本模板，删除后追溯链条会断。确认无人引用且不涉及审计的模板，可以在模板索引中标记“已下线”，只读副本和变更说明继续保留。涉及交付验收、外部审计或合同约定的模板，长期保留只读副本，不设自动清理期限。
切换后发现新版本有问题，回滚时版本号怎么处理？
回滚不把版本号改回去，而是发布一个更高的新版本，并在变更说明中注明“回退至某版本内容”。例如2.0发现问题后回退到1.0的结构，发布2.1并写清回退原因、影响范围和存量任务处理方式。这样版本序列保持单向递增，历史记录完整，后来人能看到“曾经升到2.0又退回”的完整过程，而不是版本号凭空消失。
团队规模小、模板不多，也需要分四个角色吗？
角色可以由一人兼任，但动作不能省。小团队常见做法是模板负责人同时承担评审与归档，使用团队的确认由各项目负责人完成。关键是把“发起、评审、通知、切换、归档”五个动作留下可检查的产出，例如变更说明、切换确认记录、归档索引。模板数量增加后再逐步拆分角色，比一开始就设岗更实际。
