文档归档命名规范模板由两张可直接复制填写的表组成：一张归档目录结构表，一张命名规则字段表。建议的使用顺序是先确定命名字段与取值字典，再套用模板批量改名，最后按检查项验收。下文给出空白表格、逐字段说明、必填与选填划分、一份完整填写示例，以及规范随组织变化时的维护方法。
要点总览（TL;DR）
- 模板由两张表组成：归档目录结构表按“一级分类—二级业务域—三级文档类型—归档批次”分层，命名规则字段表定义文件名由哪些字段拼接。
- 必填字段底线是文档类型、业务对象、版本号、状态、归档日期五项，责任人可作为选填字段，省略时直接去掉该段及分隔符。
- 字段取值来自团队维护的类型清单、系统清单和状态字典，分隔符、大小写和日期格式需在规范开头一次性约定。
- 填写示例：文件“需求-客服系统-V1.2-已归档-20250331-张三”存放在“项目文档/客户服务系统/需求文档/2025Q1”目录下。
- 规范落地后需建立变更审批、历史文件兼容映射和定期检查机制，避免字段调整后新旧文件检索断档。
可复制空白模板：归档目录结构与命名规则表
先复制目录结构表，把团队实际使用的分类填进去；再复制命名规则字段表，确定文件名由哪些字段拼接。两张表填完后，团队就同时有了“文件放在哪”和“文件叫什么”的统一依据。
归档目录结构空白表
目录按“一级分类—二级业务域—三级文档类型—归档批次”四层展开。团队规模较小或文档量不大时，可以合并二级与三级，但同一套目录内层级口径要保持一致。
| 层级 | 目录名 | 存放内容 | 责任人 | 保留期限 |
|---|---|---|---|---|
| 一级分类 | （填写，如：项目文档） | （该分类覆盖的业务范围） | （角色或岗位） | （如：长期） |
| 二级业务域 | （填写，如：客户服务系统） | （该业务域的文档集合） | （角色或岗位） | （如：项目结束后3年） |
| 三级文档类型 | （填写，如：需求文档） | （该类型文档的用途说明） | （角色或岗位） | （如：2年） |
| 归档批次 | （填写，如：2025Q1） | （本批次归档的文件清单） | （归档执行人） | （随上级目录） |
命名规则字段空白表
字段表决定文件名的组成。每个字段需要写明在文件名中的位置、取值规则和示例占位，并标记是否必填。
| 字段名 | 位置 | 取值规则 | 示例占位 | 必填标记 |
|---|---|---|---|---|
| 文档类型 | 第1段 | （取自类型清单，如：需求、设计、测试、验收） | 需求 | 必填 |
| 业务对象 | 第2段 | （取自业务对象清单，使用简称） | 客服系统 | 必填 |
| 版本号 | 第3段 | （V+主版本.次版本） | V1.2 | 必填 |
| 状态 | 第4段 | （草稿、评审中、已发布、已归档） | 已归档 | 必填 |
| 归档日期 | 第5段 | （YYYYMMDD） | 20250331 | 必填 |
| 责任人 | 第6段 | （姓名或工号，按团队约定） | 张三 | 选填 |
文件名拼接格式
字段之间统一使用短横线连接，按字段表顺序拼接：
文档类型-业务对象-版本号-状态-归档日期-责任人
示例占位：需求-客服系统-V1.2-已归档-20250331-张三。选填字段省略时，直接去掉该段及其前面的分隔符，不保留空段。
字段说明：每个命名字段管什么
字段表能否被正确填写，取决于每个字段的取值来源是否明确。下面逐字段说明含义、取值来源和常见写法，与上表一一对应。
| 字段 | 含义 | 取值来源 | 常见写法与注意点 |
|---|---|---|---|
| 文档类型 | 标识文档属于哪一类交付物，决定检索时的第一层筛选 | 部门约定的类型清单，由文档管理负责人维护 | 使用清单内的固定词，如“需求”“设计”“测试”“验收”，不临时造词 |
| 业务对象 | 标识文档服务的项目、系统或客户 | 项目清单或系统清单中的正式名称，可约定统一简称 | 同一对象只用一个写法，避免“客服系统”和“客服平台”混用 |
| 版本号 | 标识文档的修订轮次，便于区分同一文档的不同稿 | 文档自身的版本记录 | 统一用“V主版本.次版本”，如V1.0、V2.1；归档时取最终版本 |
| 状态 | 标识文档在生命周期中的位置 | 团队约定的状态字典，如草稿、评审中、已发布、已归档 | 归档文件通常为“已归档”；状态词不缩写、不混用近义词 |
| 归档日期 | 标识文件进入归档环节的时间 | 实际归档操作日期 | 统一YYYYMMDD，如20250331；不用“3月31日”或“2025-03-31”等混排格式 |
| 责任人 | 标识文档的维护人或归档执行人 | 团队成员名单 | 姓名或工号二选一并在团队内统一，不中英文混写 |
分隔符、大小写和日期格式需要在规范开头一次性约定。常见做法是：字段间统一用半角短横线，字段内部不使用空格和斜杠等特殊字符，英文缩写统一大写或统一小写。约定写进规范后，批量改名时按同一规则执行，避免同一批文件出现多种写法。
必填与选填：哪些字段不能省
必填字段的底线是五项：文档类型、业务对象、版本号、状态、归档日期。这五项分别回答“是什么、属于谁、第几版、处于什么阶段、何时归档”，缺任何一项都会让后续检索或追溯出现断点。责任人字段建议保留为选填，在需要明确到人的场景再补。
| 字段 | 必填/选填 | 理由或适用场景 | 缺失时的处理 |
|---|---|---|---|
| 文档类型 | 必填 | 检索和目录落位的第一依据 | 不允许缺失，缺失则退回补填 |
| 业务对象 | 必填 | 区分不同项目或系统的同名文档 | 不允许缺失；对象尚未确定时用“待定”占位并登记 |
| 版本号 | 必填 | 区分同一文档的不同稿，支撑版本追溯 | 首次归档统一记为V1.0 |
| 状态 | 必填 | 判断文件是否可被引用或继续修改 | 归档环节统一填“已归档” |
| 归档日期 | 必填 | 支撑按时间检索和保留期限计算 | 不允许缺失，按实际归档日填写 |
| 责任人 | 选填 | 需要明确维护人或追责到人时填写 | 省略该段及分隔符，不写“无”或“未知” |
遇到确实无法按规范填写的例外情况，例如历史文件缺少版本信息、外部来件没有内部业务对象，处理方式是保留占位写法并在归档登记表中记录原因和审批人，而不是随意裁剪字段。占位词建议统一为“待定”或“不详”，并在规范中列明哪些字段允许使用占位、由谁批准。
填写示例：一份完整归档命名与目录落位
下面用一个演示情景说明从目录选择到文件名拼接的完整过程。示例中的项目、系统和人员均为虚构，仅用于展示填写方法。
假设客服系统项目在2025年第一季度完成验收，需要归档一份需求文档的最终版。归档执行人先查目录结构表，确定落位路径：
项目文档 / 客户服务系统 / 需求文档 / 2025Q1
再按命名规则字段表逐段拼接文件名：
需求-客服系统-V1.2-已归档-20250331-张三
| 字段 | 示例取值 | 取值依据 |
|---|---|---|
| 文档类型 | 需求 | 取自类型清单中的“需求”项，对应目录第三级的“需求文档” |
| 业务对象 | 客服系统 | 取自系统清单中的统一简称，与目录第二级“客户服务系统”对应 |
| 版本号 | V1.2 | 取自文档版本记录中的最终版本 |
| 状态 | 已归档 | 归档环节按状态字典统一填写 |
| 归档日期 | 20250331 | 实际归档操作日期，按YYYYMMDD格式 |
| 责任人 | 张三 | 该文档的维护人，选填字段，本例填写 |
完整归档结果即：文件“需求-客服系统-V1.2-已归档-20250331-张三”存放在“项目文档/客户服务系统/需求文档/2025Q1”目录下。若该文档不需要指定责任人，文件名则为“需求-客服系统-V1.2-已归档-20250331”，目录路径不变。通过这个示例可以核对：目录层级与字段取值是否对应、日期格式是否统一、选填字段省略后拼接是否仍然完整。
调整与维护方法：规范怎么随组织变化更新
命名规范落地后，组织调整、业务域合并或文档类型增减都会带来字段和字典的变化。维护机制要解决三件事：变更怎么提、旧文件怎么兼容、目录怎么定期清理。
字段与取值字典的变更流程
- 提出变更：由文档管理负责人或业务域责任人提交变更申请，写明新增、修改或停用的字段及原因。
- 评估影响：确认变更影响哪些目录、哪些在用的文件名，以及是否需要同步调整批量改名脚本或模板。
- 审批发布：由文档管理负责人审批，更新规范版本号，并在团队内公告生效日期。
- 执行与记录：按新规则归档新文件，变更内容登记到变更记录表。
| 变更日期 | 变更类型 | 涉及字段或目录 | 变更内容 | 生效日期 | 审批人 |
|---|---|---|---|---|---|
| （填写） | 新增/修改/停用 | （字段名或目录路径） | （具体说明） | （填写） | （填写） |
历史归档文件的兼容处理
规范更新后，已归档文件不必全部立即改名。可行做法是建立一张新旧规则映射表，记录旧写法与新字段的对应关系，检索时通过映射表兼容旧文件；对仍在频繁引用的历史文件，按优先级分批改名，并保留改名记录。这样既避免一次性大规模返工，也保证新旧文件都能被找到。
定期检查与失效目录清理
建议按季度或半年做一次归档检查，核对目录中是否存在空目录、重复目录、超出保留期限的文件，以及文件名不符合当前规范的条目。检查结果形成清单，明确整改责任人和完成时间。超出保留期限的目录按规范清理或移交，清理动作同样登记，避免误删后无法追溯。
当团队在知识库中承载这套归档规范时，目录权限、文档版本和归档状态的管理动作可以借助工具落实。ONES Wiki 支持页面树组织，便于按“分类—业务域—文档类型—批次”的层级呈现文档；文档实时同步并记录所有页面版本，支持随时查看与回滚，便于核对归档版本；支持为不同角色配置读写权限，可把归档目录的维护权限收敛到责任人；误删除的页面可从回收站恢复。规范中的字段表和目录表也可以通过页面模板库固化为制式模板，新成员按模板创建文档，减少命名口径不一致的情况。归档审批的具体配置方式以团队实际使用的产品版本为准。
常见问题
团队文档量不大，目录层级可以简化吗？
可以。目录结构表按四层设计，是为了让分类、业务域、文档类型和归档批次各有明确位置。文档量不大或团队规模较小时，可以把二级业务域与三级文档类型合并为一层，例如直接按“项目文档/需求文档/2025Q1”存放。需要保持的是同一套目录内层级口径一致：要么统一四层，要么统一三层，避免部分目录深、部分目录浅，导致归档时找不到对应位置。
历史文件不符合新命名规范，需要全部改名吗？
不必一次性全部改名。可行做法是先建立新旧规则映射表，记录旧文件名与新字段的对应关系，检索时通过映射表兼容旧文件。对仍在频繁引用的历史文件，按使用频率分批改名并保留改名记录；长期不再引用的文件维持原样即可。这样既避免大规模返工，也保证新旧文件都能被找到。映射表本身也应纳入规范维护范围，随字段变更同步更新。
归档日期和文档自身的版本日期不一致时，以哪个为准？
两个日期承担不同作用，建议都保留但各归其位。文件名中的归档日期填实际进入归档环节的操作日期，用于按时间检索和计算保留期限；文档版本记录中的日期属于文档自身修订历史，留在版本记录里，不进入文件名。如果团队需要按文档定稿时间检索，可以在归档登记表中单独设一列记录定稿日期，避免把两个口径混进同一个字段。
选填的责任人字段，什么情况下应该填？
需要明确维护人或追溯责任到人时填写，例如对外交付文档、跨部门共用的规范文件、需要长期更新的操作手册。内部一次性归档、后续不再维护的文件可以省略。省略时直接去掉该段及其前面的分隔符，不保留空段，也不写“无”或“未知”。团队应在规范中写明哪些文档类型默认填写责任人，减少同一批文件出现有的填、有的不填的情况。
规范更新后，新字段怎么在知识库工具里落地？
落地分两步：先把更新后的字段表和目录表固化为制式模板，再让新归档按模板创建。以 ONES Wiki 为例，页面树可以按“分类—业务域—文档类型—批次”的层级组织文档，页面模板库可把字段表和目录表做成制式模板供新成员直接套用；文档记录所有页面版本并支持回滚，便于核对归档版本；读写权限可按角色配置，把归档目录的维护权限收敛到责任人；误删除的页面可从回收站恢复。归档审批的具体配置方式以团队实际使用的产品版本为准。
