知识库目录的更新与维护，核心是建立一套能持续执行的机制：先定分类规则和层级上限，再区分新增、调整、归档三类变更的触发条件，明确目录管理员与分类负责人的分工，按月度增量检查、季度全量复核的节奏运行，并用变更记录和失效链接清单留痕。本文按规则、变更、角色、节奏、示例、验收六个环节展开，说明每一步的输入、动作与产出。
要点总览（TL;DR）
- 目录维护先定一份规则说明：选定单一主分类维度、层级控制在三层以内、统一目录名与文档标题格式，后续变更都以它为依据。
- 变更分新增、调整、归档三类：新增先审批再创建，调整先评估影响再迁移，归档保留原路径说明与替代位置。
- 职责落到目录管理员、分类负责人、文档作者三个角色，各自有交付物和响应时限，人员变动时按清单交接。
- 检查按月度增量、季度全量运行，统一记录表单字段并保留至少四个周期，复核结论作为下季度输入。
- 用结构、内容、使用、机制四类共八项标准验收，两项以上不达标时回到规则或角色分工排查。
目录维护先定规则：分类维度、层级与命名
目录一旦开始增长，临时决定“这篇放哪里”会迅速产生重复目录和交叉归类。维护工作的第一步是把规则写下来，形成一份团队可查阅的目录规则说明，后续所有变更都以它为依据。
选定单一主分类维度
常见的分类维度有三种：按业务域（如产品、市场、人力）、按文档类型（如制度、方案、会议纪要）、按生命周期（如规划、执行、复盘）。一个知识库只选一种作为主分类维度，其余维度用标签、索引页或搜索条件承载。混用两种主维度，例如一级目录既按部门又按文档类型，往往导致同一份文档有两个合理位置，最终出现内容重复或归属争议。
选择依据可以看主要使用场景：读者习惯按“我在哪个业务里找”定位，就选业务域；文档类型高度标准化、需要统一模板管理，就选文档类型。规则说明中应写明选择理由，便于后续新成员理解。
层级深度控制在三层以内
建议目录层级不超过三层，即“一级分类—二级分类—具体条目”。超过三层的需求，优先用标签补充检索维度，或在一级分类下建一个索引页，用链接列表组织相关文档。层级过深的直接代价是导航成本上升，读者需要逐层展开才能判断内容是否存在。
规则说明中应明确层级上限，并给出超出时的替代做法，避免每次遇到新内容都重新讨论。
目录命名与文档标题的命名约定
目录名使用名词短语，表达内容范围，不加序号以外的修饰词。文档标题建议包含三段信息：主题、状态、版本或日期。例如“报销制度（现行版，2024-06）”“客户 onboarding 方案（草稿）”。状态标识放在标题末尾的括号内，位置统一，便于扫描和批量识别过期内容。
规则说明的产出物是一页文档，包含：主分类维度及理由、层级上限、目录命名规则、文档标题格式、标签使用范围。这份文档由目录管理员维护，变更时记录版本。
三类变更的触发条件与处理流程
目录变更分为新增、调整、归档三类。每类变更的触发条件不同，处理动作和影响范围也不同，混在一起处理容易造成结构失控或误删内容。下表给出判定口径。
| 变更类型 | 触发条件 | 处理动作 | 产出 |
|---|---|---|---|
| 新增目录 | 出现新业务线或新项目类型；同类文档数量超过约定阈值（如10篇）；现有目录下内容明显混杂两类主题 | 提交新增申请，说明归属位置与命名；目录管理员审批后创建 | 新目录项、审批记录 |
| 调整目录 | 两个目录内容高度重叠需合并；单一目录条目过多需拆分；业务名称变更需改名；文档归位错误需移动 | 评估影响范围（涉及文档数量、外部引用链接），制定迁移清单，执行后核对 | 变更前后对照表、迁移清单 |
| 归档目录 | 业务线终止；目录下内容全部过期；连续两个复核周期无新增且访问量趋零 | 确认无在用文档，整体移入归档区，保留原路径说明 | 归档记录、替代位置说明 |
新增：先审批再创建
新增目录的申请应包含：拟建目录名、上级目录、预计容纳的文档清单、与现有目录的区别说明。目录管理员重点核对两点：是否与现有目录职责重叠，命名是否符合约定。审批通过后再创建，避免个人随手建目录造成结构碎片化。
调整：先评估影响再动手
合并、拆分、改名、移动都会改变已有链接和读者习惯。执行前导出受影响文档清单，标注哪些文档被外部引用、哪些是高频访问条目。调整完成后逐一核对迁移结果，确认没有文档遗留在旧路径或变成孤立条目。
归档：保留可追溯的痕迹
归档不等于删除。目录整体归档时，在归档区保留原目录名和一句说明，写明归档时间与替代位置。确实需要删除的条目，先确认无引用、无访问需求，删除后保留删除记录，便于必要时恢复。
角色分工：目录管理员、分类负责人与文档作者
目录维护失效的常见原因是“大家都觉得有人管”。把职责落到三个角色上，每个角色有明确的交付物和响应时限，机制才能运转。
| 角色 | 职责 | 交付物 | 响应时限 |
|---|---|---|---|
| 目录管理员 | 维护目录规则说明；审批新增与调整申请；保证整体结构一致性；组织季度复核 | 规则说明、审批记录、复核报告 | 新增申请3个工作日内答复 |
| 分类负责人 | 负责本分类下条目增删与内容有效性；参与月度检查与季度复核；提出合并或归档建议 | 分类检查记录、处置意见 | 月度检查5个工作日内完成 |
| 文档作者 | 提交文档时按规则选择目录；标注状态与版本；内容过期时主动更新或申请归档 | 合规命名的文档、状态标注 | 文档发布时同步完成 |
交接动作要具体
分类负责人变更时，交接内容包括：本分类目录清单、待处理事项、近期变更记录。目录管理员在人员变动后一周内更新角色名单，并通知相关方。文档作者离职或转岗前，其名下文档需由分类负责人确认归属和状态，避免出现无人维护的条目。
在工具层面，ONES Wiki 支持为不同角色配置读写权限，目录管理员与分类负责人的操作范围可以按角色区分；页面树方式组织页面，使目录与文档的从属关系直接可见，便于交接时逐项核对。
维护节奏：月度增量检查与季度全量复核
检查频率过低，问题积累到难以收拾；频率过高，占用过多维护精力。月度做增量、季度做全量，是兼顾及时性与成本的常见安排。
月度增量检查
每月由分类负责人完成本分类的检查，动作包括：核对本月新增文档是否归入正确目录；检查是否出现空目录或只有一篇文档的孤立目录；导出失效链接清单并逐条处理（更新链接、替换文档或申请归档）。检查结果填入统一表单，目录管理员汇总后处理跨分类问题。
季度全量复核
每季度由目录管理员发起，覆盖全部目录。重点看三件事：目录结构与当前业务是否匹配，是否有业务已调整而目录未跟进；长期无访问条目的处置意见；规则说明本身是否需要修订。全量复核的结论形成书面报告，作为下一季度检查的输入。
检查记录的表单字段
建议统一使用以下字段，便于跨周期对比：检查周期、检查人、分类路径、条目总数、新增数、归档数、失效链接数及处理状态、待决事项、完成日期。记录集中存放，保留至少四个周期。
ONES Wiki 记录所有页面版本并支持随时查看与回滚，复核中发现的误改可以追溯和恢复；误删除的页面可从回收站恢复，降低清理动作的风险。
示例：一次季度目录复核怎么走完
以下为演示情景，用于说明一次完整复核的步骤与产出，不代表特定组织的实际数据。
第一步，发起。目录管理员在季度首周发布复核通知，附上复核表单模板和截止日期，明确各分类负责人的范围。
第二步，导出数据。从知识库导出三类数据：各目录的文档数量与最近更新时间、近90天访问量、无上级归属或未被任何索引页引用的孤立条目清单。数据作为复核底稿分发。
第三步，逐项确认。分类负责人对照底稿，对每个目录标记“保留、合并、归档”三种意见之一。标记合并的，写明目标目录；标记归档的，确认无在用文档并注明替代位置。
第四步，汇总与发布。目录管理员汇总各方意见，处理冲突（如两个分类都主张同一目录归属），形成变更清单，执行结构调整，发布新结构说明并通知全体使用者。
第五步，记录与结转。复核报告归档，未决事项列入下季度检查清单。本次复核的产出物包括：复核底稿、变更清单、新结构说明、复核报告。
完成检查：目录维护是否到位的判断标准
机制是否有效，用可核对的条目判断，而不是凭感觉。以下检查表可按季度逐项打分。
| 类别 | 检查项 | 判定标准 |
|---|---|---|
| 结构类 | 层级深度 | 所有目录不超过约定层级上限 |
| 结构类 | 重复目录 | 不存在职责重叠的两个目录 |
| 结构类 | 空目录与孤立条目 | 空目录为零，孤立条目已归位或归档 |
| 内容类 | 过期条目 | 标题标注过期的文档已完成更新或归档 |
| 内容类 | 失效链接 | 失效链接清单清零或有明确处理计划 |
| 使用类 | 查找路径 | 抽查目标文档，可在约定点击次数内到达 |
| 机制类 | 变更记录 | 本周期新增、调整、归档均有记录可查 |
| 机制类 | 复核执行 | 月度检查与季度复核按周期完成并有报告 |
抽查“查找路径”时，随机选取若干业务场景，让不熟悉该分类的成员按目录导航找目标文档，记录实际点击次数。超过约定次数，说明目录结构或命名需要调整，而不是归因于个人不熟悉。
八项全部达标，说明维护机制在运行；出现两项以上不达标，应回到规则或角色分工环节排查原因，而不是只在下个周期补做检查。
常见问题
团队规模很小，还需要分三个角色吗？
角色可以合并，职责不能消失。两三个人的团队常见做法是目录管理员与分类负责人由同一人兼任，文档作者仍按规则选目录、标状态。需要保留的是三件事：有人对整体结构负责、有人对本分类内容有效性负责、提交文档时按规则归位。团队扩大后再把角色拆开，规则说明和检查表单可以直接沿用。
目录调整后，外部引用的旧链接怎么处理？
调整前先导出受影响文档清单，标出被外部引用的条目。能保留原路径的，在旧位置留一条指向新位置的说明；必须改路径的，通知引用方更新，并在变更记录中写明调整时间与新旧对照。调整完成后逐一核对，确认没有文档遗留在旧路径或变成孤立条目。
月度检查发现某分类长期没有新增，可以直接归档吗？
先看两个条件：目录下是否还有在用文档，以及是否连续两个复核周期无新增且访问量趋零。两个条件都满足，再确认无外部引用，整体移入归档区并保留原目录名和替代位置说明。只满足一个条件时，先列入季度复核的待决事项，由目录管理员和分类负责人共同判断。
检查记录要保留多久，用什么形式存？
建议至少保留四个周期，便于跨季度对比趋势。字段统一为：检查周期、检查人、分类路径、条目总数、新增数、归档数、失效链接数及处理状态、待决事项、完成日期。记录集中存放，与目录规则说明放在同一处，新接手的人能一次看全历史。
用 ONES Wiki 承载目录时，哪些维护动作可以直接在工具里完成？
ONES Wiki 以页面树方式组织页面，目录与文档的从属关系直接可见，交接时可逐项核对；支持为不同角色配置读写权限，目录管理员与分类负责人的操作范围可以区分；记录所有页面版本并支持查看与回滚，误删除的页面可从回收站恢复。层级上限、变更审批、失效链接检测等环节，需按实际使用的产品能力确认后再决定人工还是工具处理。
