知识库目录表用一张表就能承载：每条记录写清目录编号、上级目录、目录名称、层级、目录类型、内容范围说明、责任人与维护人、访问权限、关联标签、状态和更新时间。本文提供可直接复制的空白目录表、逐字段填写口径、必填与选填划分、一份多层级填写示例，以及目录上线后的新增、合并、归档和复核方法，重点解决字段怎么填、层级怎么控制两个问题。
要点总览（TL;DR）
- 知识库目录表用一张表承载12个字段：目录编号、上级目录、目录名称、层级、目录类型、内容范围说明、责任人、维护人、访问权限、关联标签、状态、更新时间，按行录入一个目录节点。
- 必填字段是决定目录能否被唯一定位、挂到正确上级、找到负责人的字段；关联标签作为选填，用于跨目录横向关联。
- 先建一级目录再逐层向下，末级目录控制在能一屏看完的条目数量内，层级以三到四级为宜，超过时优先拆分或合并。
- 目录上线后按新增、合并、归档、复核四类动作维护：合并保留一个编号并注明去向，停用与归档目录保留至少一个复核周期再清理。
- 复核分日常检查、结构复核、全量盘点三层，节奏可按目录规模与变更频率调整，每次复核后更新更新时间字段。
可复制的知识库目录空白模板
下面这张表按行录入，一行代表一个目录节点。复制表头到表格工具或文档中即可开始填写；行数按实际目录数量增减，空白行用于演示录入位置。一级目录的“上级目录”填“无”，其余目录填写其直接上级目录的编号或名称，保持全表口径一致。
| 目录编号 | 上级目录 | 目录名称 | 层级 | 目录类型 | 内容范围说明 | 责任人 | 维护人 | 访问权限 | 关联标签 | 状态 | 更新时间 |
|---|---|---|---|---|---|---|---|---|---|---|---|
录入时先填一级目录，再逐层向下补末级目录，每填完一层检查上级目录是否已存在。末级目录是实际存放文档的节点，建议控制在一屏能看完的条目数量内，层级深度以三到四级为宜，超过时优先考虑拆分或合并。
目录字段说明：每个字段填什么
字段口径统一，不同人填出来的目录才能直接比对和汇总。下表逐字段说明含义与填写方式，模板、示例均按此口径执行。
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 目录编号 | 目录节点的唯一标识 | 采用“层级前缀＋序号”形式，如 A、A-01、A-01-02，全表不重复；调整时编号保持不变，便于引用 |
| 上级目录 | 当前目录的直接父节点 | 填写上级目录的编号；一级目录填“无”。只填直接上级，不写完整路径 |
| 目录名称 | 目录在知识库中显示的名称 | 用业务对象或职能名称，控制在十余字以内；同一上级下名称不重复，避免“其他”“杂项”这类无法判断内容的名称 |
| 层级 | 目录在树中的深度 | 一级填 1，逐级递增；与上级目录字段保持逻辑一致，便于排序和检查 |
| 目录类型 | 目录承担的组织角色 | 按组织习惯取值，常用“分类目录”“文档目录”“索引目录”；分类目录只用于向下分组，文档目录为末级存放文档 |
| 内容范围说明 | 该目录收录什么、不收录什么 | 用一两句话写清收录对象和边界，例如“收录产品需求评审纪要与结论，不含需求原始记录”；边界写清可减少错放 |
| 责任人 | 对该目录内容质量负责的人 | 填写岗位或姓名，一个目录只对应一个责任人，避免多人并列导致无人负责 |
| 维护人 | 执行日常整理与更新的人 | 填写具体人员；责任人可兼任维护人，规模较大时分开设置 |
| 访问权限 | 目录的可见与编辑范围 | 按角色或范围描述，如“全员可读”“项目组可读写”“仅管理层可读”；与承载工具的权限设置保持一致 |
| 关联标签 | 辅助分类与跨目录关联的词 | 填写已有标签体系中的词，多个用顿号分隔；标签用于横向关联，不替代目录层级 |
| 状态 | 目录当前是否可用 | 取值“启用”“停用”“归档”；停用表示暂停新增内容，归档表示只读保留 |
| 更新时间 | 该行记录最近一次修改日期 | 填写年月日；目录名称、范围、责任人、权限任一变化都要更新此字段 |
必填与选填怎么区分
判定依据是字段对目录定位和归属的作用：决定目录能否被唯一定位、能否挂到正确上级、能否找到负责人的字段设为必填；用于辅助分类、检索和运营观察的字段设为选填。这样划分可以降低首次录入负担，同时保证目录结构完整。
| 字段 | 必填/选填 | 判定理由 |
|---|---|---|
| 目录编号 | 必填 | 唯一标识，被上级目录字段引用 |
| 上级目录 | 必填 | 决定目录在树中的位置，缺失则无法形成层级 |
| 目录名称 | 必填 | 使用者在知识库中识别目录的直接依据 |
| 层级 | 必填 | 用于排序与层级检查，可由上级目录推导但需落表 |
| 目录类型 | 必填 | 区分分类节点与文档节点，影响能否直接存放文档 |
| 内容范围说明 | 必填 | 减少错放，是后续合并与归档的判断依据 |
| 责任人 | 必填 | 目录质量与复核的归属人 |
| 维护人 | 必填 | 日常更新动作的执行人，缺失会导致目录长期不维护 |
| 访问权限 | 必填 | 涉及信息可见范围，需在目录层面明确 |
| 关联标签 | 选填 | 辅助横向关联，目录层级已能表达主要归属 |
| 状态 | 必填 | 决定目录是否接收新内容，新建时统一填“启用” |
| 更新时间 | 必填 | 复核与审计的时间依据，可由系统记录或人工填写 |
选填字段只在有明确用途时填写，例如需要跨部门按主题查找时再补关联标签。必填字段在首次录入时一次填全，后续变更同步更新，避免出现有目录无责任人、有层级无上级的情况。
填写示例：一份填好的目录表
以下为演示情景，用于说明字段如何配合，不代表任何真实组织的目录结构。示例按“产品研发”一级目录向下展开到末级文档目录，覆盖多层级、权限差异与责任人分工。
| 目录编号 | 上级目录 | 目录名称 | 层级 | 目录类型 | 内容范围说明 | 责任人 | 维护人 | 访问权限 | 关联标签 | 状态 | 更新时间 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| A | 无 | 产品研发 | 1 | 分类目录 | 收录产品研发相关的过程文档与规范，不含市场与销售资料 | 研发负责人 | 研发助理 | 全员可读 | 研发 | 启用 | 2025-03-10 |
| A-01 | A | 需求管理 | 2 | 分类目录 | 收录需求从提出到评审确认的材料 | 产品负责人 | 产品助理 | 产品组可读写，全员可读 | 需求 | 启用 | 2025-03-10 |
| A-01-01 | A-01 | 需求评审纪要 | 3 | 文档目录 | 收录需求评审会议纪要与结论，不含需求原始记录 | 产品负责人 | 产品助理 | 产品组可读写，全员可读 | 评审、需求 | 启用 | 2025-03-12 |
| A-01-02 | A-01 | 需求原始记录 | 3 | 文档目录 | 收录需求提出方的原始描述与附件 | 产品负责人 | 产品助理 | 产品组可读写 | 需求 | 启用 | 2025-03-12 |
| A-02 | A | 技术规范 | 2 | 分类目录 | 收录研发执行所需的技术标准与约定 | 技术负责人 | 架构组成员 | 研发组可读写，全员可读 | 技术 | 启用 | 2025-03-11 |
| A-02-01 | A-02 | 接口约定 | 3 | 文档目录 | 收录对外与内部接口的字段、版本与变更说明 | 技术负责人 | 架构组成员 | 研发组可读写，全员可读 | 接口、技术 | 启用 | 2025-03-11 |
| A-02-02 | A-02 | 历史技术方案 | 3 | 文档目录 | 收录已下线或已被替代的技术方案，仅供查阅 | 技术负责人 | 架构组成员 | 研发组可读 | 技术 | 归档 | 2025-02-20 |
| B | 无 | 人事行政 | 1 | 分类目录 | 收录人事制度与行政流程文档 | 行政负责人 | 行政专员 | 全员可读 | 人事、行政 | 启用 | 2025-03-08 |
示例中可以看到几个配合关系：编号前缀体现层级，A-01-01 能直接看出属于 A-01；权限随内容敏感度变化，需求原始记录与历史技术方案收窄了可见范围；归档目录保留编号与责任人，状态改为“归档”并停止新增内容。实际使用时按组织业务对象替换名称与范围说明即可。
目录的调整与维护方法
目录上线后需要持续维护，否则会出现同类内容分散、失效目录长期占用位置、责任人变动无人接手等问题。维护动作围绕新增、合并、归档和复核四类展开，每类都明确触发条件与执行人。
新增与合并目录的规则
- 新增目录前先检索现有目录，确认没有可复用的上级或同类节点；确需新增时，由维护人提出，责任人确认内容范围说明后再录入。
- 新增末级目录时同步填写责任人与访问权限，避免先建目录后补归属。
- 同一上级下出现两个范围高度重叠的目录时执行合并：保留编号较小或使用频率较高的目录，将另一目录内容迁入，原目录状态改为“停用”并注明合并去向。
- 合并后更新受影响目录的上级目录、层级与更新时间，检查是否有下级目录需要一并调整。
归档与停用处理
- 目录内容不再新增但仍有查阅价值时，状态改为“归档”，权限调整为只读，保留编号与责任人。
- 目录内容已全部迁出或业务已取消时，状态改为“停用”，在内容范围说明中写明停用原因与替代目录。
- 停用与归档目录不立即删除，保留至少一个复核周期，确认无引用后再清理。
定期复核节奏与责任人
| 复核类型 | 建议节奏 | 执行人 | 复核内容 |
|---|---|---|---|
| 日常检查 | 每月 | 各目录维护人 | 新增内容是否放入正确目录，末级目录条目是否过多 |
| 结构复核 | 每季度 | 各一级目录责任人 | 层级是否过深、是否存在重叠目录、权限是否仍合适 |
| 全量盘点 | 每半年或每年 | 知识库管理负责人 | 责任人是否在职、停用与归档目录是否可清理、字段是否填写完整 |
复核节奏可按目录规模与变更频率调整，变更频繁的业务目录可缩短到每月结构复核。每次复核后更新对应行的更新时间，形成可追溯的维护记录。
目录表落地到具体工具时，层级与权限需要由承载文档的系统实现。ONES Wiki 支持以页面树组织内容，页面之间的从属关系可以直接呈现，与目录表中的上级目录、层级字段对应；同时支持为多种角色配置不同的读写权限，并记录页面版本、支持查看与回滚，便于在合并、归档和复核时保留变更痕迹。将目录表作为设计底稿，再在工具中按树形结构建立页面并设置权限，可以让字段规范与实际知识库保持一致。
常见问题
目录编号在目录调整后需要重新编排吗？
不需要。目录编号的作用是唯一标识和被上级目录字段引用，调整目录名称、范围或位置时保持编号不变，引用关系才不会断。新增目录时按“层级前缀＋序号”续编，例如 A-01 下新增第三个末级目录编为 A-01-03。合并目录时保留被保留目录的编号，被合并目录的编号随停用状态一起保留，并在内容范围说明中注明合并去向，便于追溯原有引用。
目录层级超过建议深度时怎么处理？
先判断多出来的层级是否在表达真实的内容差异。如果某一层只有一个子目录，或两层目录的内容范围说明高度重叠，可以直接合并；如果某一层承载的是不同的业务对象，可以把它提升为一级目录，与其他一级目录并列。另一种做法是把细分维度从目录层级转到关联标签，用标签表达主题、项目或阶段，目录只保留稳定的归属结构。层级调整后要同步更新受影响目录的上级目录、层级和更新时间字段。
责任人离职或岗位调整，目录表怎么衔接？
把责任人变更纳入全量盘点的检查项，盘点时逐条核对责任人是否在职、是否仍负责该目录内容。日常发现变更时，由维护人提出调整，一级目录责任人确认新的人选后更新责任人字段和更新时间。交接时建议同时核对内容范围说明是否仍然准确，因为岗位调整常伴随职责范围变化，范围说明不更新会让后续录入的人按旧口径放错内容。
目录表落地到文档工具后，还需要单独维护这张表吗？
建议保留。目录表记录的是设计意图，包括内容范围说明、责任人和维护节奏，这些信息在多数文档工具里不会随页面树自动呈现。落地时以目录表为底稿建立树形结构并设置权限，之后目录表作为核对依据：结构复核时对照表检查实际页面树是否与设计一致，盘点时检查字段是否填写完整。ONES Wiki 支持以页面树组织内容，页面之间的从属关系可以直接呈现，与目录表中的上级目录、层级字段对应；同时支持为多种角色配置不同的读写权限，并记录页面版本、支持查看与回滚，便于在合并、归档和复核时保留变更痕迹。
访问权限字段写到什么颗粒度合适？
按角色或范围描述即可，例如“全员可读”“项目组可读写”“仅管理层可读”，不必写到具体人名。颗粒度以能指导工具中的权限设置为准：如果同一目录下不同子目录的可见范围差异很大，说明权限应该在子目录层面分别填写，而不是在上级目录写一个笼统的范围。填写后要与承载工具中的实际权限设置核对一致，避免表上写全员可读、工具里却收窄了范围。
