知识分类要落地，先明确它服务的查找与复用场景，再选一到两个主维度建立层级，配套命名规则、归属判定和责任人，用小范围试点验证可检索性与维护成本后逐步推广。层级建议控制在三到四层，每条知识指定唯一主归属，跨类内容用标签补充。本文给出从目标界定到上线检查的完整做法。
要点总览（TL;DR）
- 先写一份分类目标说明，明确服务对象、三到五个典型查找场景，以及分类与检索、模板的分工边界。
- 选一到两个主维度（业务对象、流程阶段、文档类型、组织角色）决定唯一归属，其余需求用标签横向补充。
- 层级控制在三到四层，同层命名保持统一粒度，同义词只保留一个，避免近义目录并列。
- 每条知识只设一个主归属，跨类内容用标签或引用关联；分类管理员、内容作者、评审者职责分开，分类变更走审批并定期巡检。
- 存量内容先做旧新分类映射表，选一个业务单元试点，用查找耗时、归属争议数量、空分类比例验证后再分批推广。
先定分类要解决的问题与边界
分类体系的设计起点是一份目标说明，写清服务对象、核心场景和不纳入范围。没有这份说明，后续的维度选择和层级设计容易变成凭感觉堆目录，上线后既难判断好坏，也难说服作者按规则归类。
典型场景可以按查找动作来列。新人上手，需要按业务对象或流程阶段找到入门材料；跨项目复用，需要判断某份方案能否直接搬到另一个产品线；评审依据查找，需要在特定阶段快速定位规范、模板和既往结论。把这三类场景各写一条具体例子，分类目标就有了可检验的落点。
分类与检索、内容模板承担不同职责。分类负责组织归属，决定一条知识放在哪个目录、挂在哪个节点下；检索负责查找过程，处理关键词匹配、排序和过滤；模板负责内容格式，规定一份文档该有哪些章节。三者混在一起谈，常出现“分类没做好就靠搜索补”或“用模板目录代替分类”的偏差。本文只讨论组织归属，检索实现和模板细则不在范围内。
出现以下信号时，说明现有分类需要重建而非局部修补：同一份材料在多个目录重复出现；作者在提交时反复询问该放哪里；评审者找不到应依据的规范；目录名称与实际内容长期不符。把这些信号记录成清单，作为立项依据。
本节交付物是一份分类目标说明，包含四项内容：服务对象（哪些角色依赖这套分类）、核心场景（三到五个具体查找任务）、边界（分类管什么、不管什么）、不纳入范围（检索排序、模板格式等）。完成标志是团队能据此判断一个新需求是否属于本次分类工作。
选择分类维度并设计层级结构
维度选择决定分类树的骨架。常见主维度有四类：业务对象或产品线、流程阶段、文档类型、组织角色。一个知识库通常选一到两个主维度作为归属依据，其余作为辅助标签。主维度过多会让同一条知识有多个合理位置，归属争议随之增加。
| 维度 | 适合的场景 | 使用注意 |
|---|---|---|
| 业务对象/产品线 | 多产品并行、复用需求强 | 产品线频繁调整时层级易失稳 |
| 流程阶段 | 研发、交付等阶段划分清晰 | 阶段定义需先统一，否则边界模糊 |
| 文档类型 | 规范、方案、记录等格式差异大 | 类型过多时单层条目膨胀 |
| 组织角色 | 按岗位组织学习材料 | 组织调整会牵动整棵树 |
主维度与标签的分工要写进规则：主维度决定唯一归属，标签做横向补充。例如以产品线为主维度，用“评审依据”“新人必读”“已归档”等标签标记用途和状态。标签可以多选，归属只能有一个。
层级深度建议三到四层。两层往往不足以区分业务对象与内容类型，五层以上则让作者在提交时难以判断，也让浏览路径变长。单层条目数量保持可控，同一层级下超过十余个并列条目时，考虑合并或增加一个中间层。宽度和深度需要一起看：层级浅而宽，查找靠扫视；层级深而窄，查找靠路径记忆。
命名规则要统一粒度。同一层级的名称应属于同一抽象级别，避免“需求管理”和“某产品V2接口文档”并列。同义词只保留一个，近义概念合并或明确区分标准，例如“规范”与“标准”择一使用，并在规则中注明另一词不再作为目录名。名称尽量短，把限定条件放进标签或元信息。
本节交付物是分类树草案，包含层级结构、每层命名、主维度与标签的分工说明。完成标志是任取一条知识，作者能依据草案说出它应落在哪个节点。
制定归属判定与维护机制
归属判定解决“一条知识放哪”的执行问题。基本规则是唯一主归属：每条知识只在一个节点下作为主条目存在，跨类内容通过标签关联或在其他节点建立引用，不复制条目。复制条目短期方便，长期造成版本分叉和清理困难。
| 角色 | 职责 | 关键动作 |
|---|---|---|
| 分类管理员 | 维护分类树与规则 | 审批新增、合并、废弃分类；处理归属争议 |
| 内容作者 | 按规则提交知识 | 选择主归属、填写标签与元信息 |
| 评审者 | 校验归属正确性 | 在内容评审时检查分类是否符合规则 |
分类变更需要流程。新增分类由作者或管理员提出，说明使用场景和预计内容量，管理员审批后上线；合并分类需先迁移内容再下线旧节点；废弃分类要保留映射记录，避免历史链接失效。变更记录集中保存，便于回溯。
定期巡检按固定节奏执行，例如每季度一次。巡检内容包括：空分类和长期无更新的节点、名称与实际内容不符的节点、重复或近义并列的节点、归属争议集中的节点。巡检结果形成清理清单，由管理员跟进。
分类规则最终要落到知识库的目录与文档归属上。ONES 文档管理支持按目录组织文档，并可为文档设置属性与标签，配合评审流程在提交环节校验归属。团队可以把主维度映射为目录层级，把用途和状态映射为标签，让作者在提交时完成归属选择，评审者在同一流程中确认。
本节交付物是归属判定规则表和维护责任清单。完成标志是每个分类节点都有明确责任人，每条新增知识都有可查的归属依据。
迁移存量内容并试点验证
存量迁移先做盘点。按现有目录导出知识清单，标注每条的旧归属、内容类型和使用频率，再建立旧分类到新分类的对照表。对照表要覆盖全部旧节点，包括将被合并和废弃的节点，并注明迁移方式：直接映射、拆分、合并或归档。
试点范围选一个内容量适中、作者配合度高的业务单元，覆盖两到三类典型知识。验证指标建议包括：典型查找任务的完成耗时、归属争议数量、空分类比例、作者提交时的平均归类时间。指标在试点前后各测一次，形成对比记录。这些指标的具体阈值需结合团队基线设定，本文不给出通用数值。
试点中发现的问题按类型处理：结构问题调整层级或合并节点；规则问题补充判定说明；命名问题统一用词；工具问题调整目录或标签配置。每次调整记录原因，避免反复改动同一节点。
推广按批次进行，每批上线后留出观察期再启动下一批。批次划分可按业务单元或内容类型，优先迁移使用频率高的知识。上线公告中附对照表和归属规则，减少作者的重复询问。
本节交付物是存量映射表、试点验证记录和分批推广计划。完成标志是试点批次的查找任务能在预期步数内命中，归属争议数量较迁移前下降。
完整示例：一条研发知识如何归类
以一份“订单服务接口设计说明”为例，演示从判定到落位的全过程。假设分类树以产品线为主维度，第一层为产品线，第二层为研发阶段，第三层为文档类型，标签用于标记用途和状态。
判定路径如下：先看业务对象，该文档属于订单服务所在的产品线，确定第一层；再看它服务于设计阶段，确定第二层；文档类型为设计说明，确定第三层。最终归属为“产品线／设计阶段／设计说明”。标签填写“接口设计”“评审依据”，状态标记为“现行有效”。
归属争议常出现在跨产品线的公共接口文档。裁决依据是主维度优先：文档主要服务于哪个产品线的业务，就归入该产品线；被多个产品线共用的部分，在主归属下保留完整内容，其他产品线节点建立引用并打上共用标签。裁决由分类管理员做出，记录在变更日志中。
落位后填写元信息：负责人、最后更新日期、适用版本、关联需求编号。命名遵循统一格式，例如“订单服务接口设计说明（V2）”，版本信息放在名称末尾而非目录名中。完成标志是该文档在对应节点可被检索到，且标签能支持按用途筛选。
完成检查：分类体系是否可用
上线前按结构、使用、维护三类逐项核对。检查结果记录成清单，未通过项明确整改责任人和期限。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 结构 | 层级深度 | 不超过四层，路径可完整说出 |
| 结构 | 单层条目数量 | 无明显膨胀节点，近义节点已合并 |
| 结构 | 命名一致性 | 同层粒度统一，无同义词并列 |
| 使用 | 典型查找任务 | 抽样任务能在预期步数内命中 |
| 使用 | 归属明确性 | 抽样知识均有唯一主归属 |
| 维护 | 责任人 | 每个节点有明确管理员 |
| 维护 | 变更流程 | 新增、合并、废弃均有审批记录 |
存在以下情况时不予上线：大量重复分类未清理、归属规则缺失或无法执行、关键节点无责任人。这些属于阻断项，需先整改再进入推广。检查通过后，分类体系进入常态维护，按巡检节奏持续修正。
常见问题
分类层级到底做几层合适，条目多了怎么办？
建议三到四层。两层通常区分不开业务对象和内容类型，五层以上会让作者提交时难以判断，浏览路径也变长。单层并列条目超过十余个时，优先考虑合并近义节点或增加一个中间层，而不是继续加宽。层级浅而宽靠扫视查找，层级深而窄靠路径记忆，两种方式对作者的要求不同，选之前先看团队更习惯哪种。
一条知识同时属于两个产品线，怎么处理才不产生重复条目？
按主维度优先裁决：文档主要服务于哪个产品线的业务，就归入该产品线作为唯一主条目。被多个产品线共用的部分，在主归属下保留完整内容，其他产品线节点建立引用并打上共用标签。裁决由分类管理员做出并记录在变更日志中，避免同一份材料在多个目录各存一份、后续版本分叉。
存量知识很多，能不能一次性全部迁到新分类？
不建议一次性全量迁移。先按现有目录导出清单，建立旧分类到新分类的对照表，覆盖将被合并和废弃的节点；再选一个内容量适中、作者配合度高的业务单元试点，覆盖两到三类典型知识。试点验证查找耗时、归属争议数量、空分类比例等指标后，再按业务单元或内容类型分批上线，每批留出观察期。
分类上线后由谁维护，多久检查一次？
每个分类节点应有明确的管理员，负责审批新增、合并、废弃分类并处理归属争议；内容作者按规则选择主归属并填写标签；评审者在内容评审时校验归属是否正确。巡检可按季度执行，重点看空分类和长期无更新的节点、名称与内容不符的节点、重复或近义并列的节点，结果形成清理清单由管理员跟进。
分类和搜索是什么关系，分类做好了还需要搜索吗？
两者分工不同。分类负责组织归属，决定一条知识放在哪个目录、挂在哪个节点下；搜索负责查找过程，处理关键词匹配、排序和过滤。分类清晰能让浏览路径可预期，搜索则处理记不住目录位置的情况。把两者混为一谈，容易出现“分类没做好就靠搜索补”的偏差，实际使用时仍然找不到。
