研发知识库按项目产品还是技术领域分类，取决于知识主要被谁、在什么场景下使用。以交付复用、版本追溯和客户问题回溯为主的团队，适合以项目产品为分类主干；以技术方案跨项目复用、专家经验沉淀为主的团队，适合以技术领域为分类主干。多数研发团队可以采用“技术领域为主干、项目产品为标签或关联维度”的双维结构。下面按判断依据、搭建步骤、角色分工、示例和验收检查依次说明。
要点总览（TL;DR）
- 分类主轴取决于知识的使用方式：交付复用、版本追溯、客户问题回溯为主时按项目产品组织；技术方案跨项目复用、专家经验沉淀为主时按技术领域组织。
- 多数研发团队适合双维结构：技术领域为主干决定知识放在哪里，项目产品作为标签或关联维度决定知识被谁在什么场景下找到。
- 落地按四步推进：盘点知识并归类、确定主轴与辅助维度、制定命名规则与目录结构、设定归属与维护责任人，每步都有明确完成标志。
- 分类体系上线后，用典型检索场景、新知识归属、交叉与过期知识规则、命名执行情况四项检查验证，未通过时优先调整影响面最大的问题。
先判断：你的知识主要按哪种方式被使用
分类主轴的选择，本质上是回答“知识放在哪里，才能让需要它的人以最短路径找到”。判断时先盘点三类信息：知识类型（技术方案、接口文档、项目复盘、客户问题记录等）、使用角色（开发、测试、架构师、项目经理、新人）、检索场景（按项目回溯、按技术问题查找、按领域学习）。三类信息对齐后，主轴方向通常就清晰了。
按项目产品分类的适用条件比较明确：交付物需要在后续项目中复用；版本变更和客户问题需要按项目追溯；项目结项时需要完整归档。这类团队的知识天然围绕项目生命周期产生，按项目产品组织能保持上下文完整。
按技术领域分类的适用条件同样具体：技术方案需要在多个项目间复用；专家经验需要脱离单个项目沉淀下来；新人需要按领域路径系统学习。这类团队如果按项目组织，同一技术主题会被拆散在多个项目目录下，复用和传承都会受阻。
双维结构的适用条件是两类需求同时存在。主次关系上，领域决定知识“放在哪里”，项目产品决定知识“被谁在什么场景下找到”。领域作为主干保证技术内容的连续性，项目产品作为标签或关联维度保证交付场景的可追溯性。如果团队规模较小、知识类型单一，单一维度足够时不必强行引入第二维度。
| 知识类型 | 主要使用角色 | 典型检索场景 | 建议主轴 |
|---|---|---|---|
| 技术方案、架构设计 | 架构师、开发 | 解决同类技术问题时查找参考方案 | 技术领域 |
| 接口文档、版本说明 | 开发、测试、对接方 | 按产品版本确认接口变更 | 项目产品 |
| 项目复盘、结项材料 | 项目经理、产品负责人 | 回溯项目过程与决策 | 项目产品 |
| 客户问题记录、缺陷分析 | 支持、开发 | 按客户或版本回溯问题处理 | 项目产品 |
| 领域知识、专家经验 | 新人、技术专家 | 按领域系统学习或查阅 | 技术领域 |
| 跨项目通用规范 | 全体研发 | 按主题查找统一约定 | 技术领域 |
完成这张表的填写后，统计各行的知识数量和使用频率。占比最高、检索最频繁的那一类，其对应主轴就是主分类轴。两类都占比较高时，采用领域为主干、项目产品为辅助维度的双维结构。
核心答案与操作步骤：搭建分类主干
方向确定后，按以下四步搭建分类主干。每步都说明输入、动作、输出和完成标志，便于逐项推进。
步骤一：盘点现有知识并归类
输入为存量文档清单，包括文档标题、所属项目、创建人、最近更新时间。动作是逐条标注知识类型，并按上一步的判断表归入候选类别。输出为知识类型分布统计，例如技术方案类占比、项目复盘类占比、接口文档类占比。完成标志是清单中每条知识都有明确类型标注，且类型分布能支撑主轴判断。
步骤二：确定主分类轴与辅助维度
输入为步骤一的知识类型分布和检索场景统计。动作是确定主分类轴，并明确辅助维度的承载方式（标签、关联链接或独立索引页）。同时设定层级深度上限，建议控制在三到四层；超过这个深度，查找成本明显上升，可用标签或搜索补足。输出为主轴与辅助维度的书面说明。完成标志是团队对“知识放在哪里”有一致答案，且层级深度有明确约定。
步骤三：制定命名规则与目录结构
输入为主轴说明和现有知识清单。动作是设计目录树，并为每类知识制定命名规则，例如“领域-子领域-主题”或“产品-版本-文档类型”。跨项目、跨领域的交叉知识需要单独约定处理方式：通常在主所属位置存放正文，在其他相关位置建立关联引用，避免同一内容多处维护。输出为目录结构图和命名规则文档。完成标志是任取一条现有知识，都能按规则确定其唯一归属位置。
步骤四：设定归属与维护责任人
输入为目录结构和团队角色名单。动作是为每个一级目录指定负责人，明确新增、更新、归档的操作要求。输出为责任人清单和维护约定。完成标志是每个目录都有具名负责人，且负责人确认接受职责。
在工具承载上，分类结构需要落到具体的文档空间中。ONES Wiki 以页面树方式组织页面，页面之间的关系可以直观呈现，适合承载领域主干的层级结构；页面组可关联项目，需求与文档互相对应，便于把项目产品维度挂接到领域目录上。权限方面，ONES Wiki 支持为多种角色配置不同的读写权限，可按目录划分编辑与查看范围，让领域负责人维护各自目录、普通成员按规则提交内容。
角色与交付物：谁定规则、谁维护内容
分类体系的持续可用，依赖四类角色各司其职。规则制定与内容维护分开，避免规则频繁变动或内容无人更新。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 知识库负责人 | 制定分类规则、设计目录结构、组织规则评审 | 分类规范文档、目录结构图、命名规则 |
| 领域负责人或技术专家 | 审核领域归属、把关技术内容质量 | 领域目录、内容审核记录 |
| 项目或产品负责人 | 提供项目产品标签、明确归档要求 | 项目知识归档清单、标签维护记录 |
| 普通研发成员 | 按规则提交和更新知识 | 符合命名规则的知识条目 |
规则变更需要评审与发布机制。建议由知识库负责人发起变更提案，领域负责人参与评审，变更内容在团队内发布后生效，并保留变更记录。规则变更频率不宜过高，通常按季度或半年集中评审一次，紧急问题可走临时评审。ONES Wiki 的细粒度权限管控可以配合这一分工：从页面组到单个页面分别设置编辑与查看权限，让领域负责人管理本领域目录，普通成员在指定范围内提交内容。
示例：一个研发团队的分类结构落地
以下为演示情景，用于说明双维结构的组织方式，不代表真实客户案例。某多产品线研发团队，知识包括技术方案、项目复盘和接口文档三类，同时服务多个产品项目。
领域主干按技术方向分层：后端、前端、数据、测试四个一级领域，每个领域下再分二级主题，例如后端下分服务架构、性能优化、数据访问。技术方案类知识存放在对应领域目录下，按主题组织。
项目产品作为辅助维度挂接：每个项目在产品目录下建立项目空间，项目复盘、接口文档、版本说明存放在项目空间内，并通过标签或关联链接指向相关领域目录。这样，按项目回溯时进入项目空间即可看到完整交付上下文；按技术问题查找时进入领域目录即可看到跨项目沉淀的方案。
交叉知识的处理示例：一份服务架构方案同时服务三个项目。正文存放在后端领域的服务架构主题下，三个项目空间分别建立关联引用，并在引用处注明适用版本和差异说明。这样正文只有一份，项目侧仍能按需找到。该示例适用于知识类型较全、项目数量较多的团队；知识量小或项目单一的团队可简化为主轴单层结构。
完成检查：分类体系是否可用的验证项
分类体系上线后，用以下清单逐项核对，判断是否达到可用状态。
| 检查项 | 通过标准 | 未通过时的调整方向 |
|---|---|---|
| 典型检索场景能否快速找到目标知识 | 选取三到五个真实检索场景，均能在限定步数内定位到目标文档 | 检查目录层级是否过深，补充索引页或关联入口 |
| 新知识提交时是否有明确归属位置 | 任取一条新知识，提交者能按规则确定唯一归属 | 补充命名规则说明，或调整目录划分粒度 |
| 交叉知识与过期知识的处理规则是否明确 | 交叉知识有唯一正文位置和关联引用规则；过期知识有归档或标注机制 | 补充交叉知识处理约定，设立定期清理机制 |
| 命名规则是否被实际执行 | 抽查近期新增条目，命名符合规则的比例达到团队约定水平 | 在提交环节增加检查，或由领域负责人定期巡检 |
检查未通过时，优先调整影响面最大的问题：检索失败集中出现在某一层级，说明该层级划分需要重构；归属不清集中出现在某类知识，说明该类知识需要单独约定规则。检查建议在试点范围先做一轮，确认有效后再推广到全库。
常见问题
团队规模较小、知识类型单一，还需要做双维分类吗？
不必强行引入第二维度。双维结构的价值在于同时满足“按技术主题沉淀”和“按项目回溯”两类需求，当团队知识量小、项目数量少、检索场景集中时，单一主轴通常足够。可以先按主要使用方式选一个主轴，把另一维度留作标签或备注，等知识量和项目数增长、查找开始出现困难时再扩展。
同一份技术方案服务多个项目，正文应该放在哪里？
建议正文只保留一份，放在其主所属的技术领域目录下，在各项目空间中建立关联引用，并在引用处注明适用版本和差异说明。这样避免同一内容多处维护导致版本不一致，项目侧仍能按需找到。如果方案在不同项目中有实质性差异，应拆分为独立文档或增加版本分支，而不是在同一篇文档里混写。
分类规则定好后，怎么避免目录越建越深、越建越乱？
在规则中明确层级深度上限，建议控制在三到四层，超过后查找成本明显上升，可用标签、关联入口或搜索补足。同时约定新增目录的审批方式：由知识库负责人统一审核目录变更，领域负责人在本领域内调整二级主题。定期抽查近期新增条目，命名和归属不符合规则的及时纠正，比事后大规模重构成本低得多。
分类体系上线后，多久检查一次比较合适？
建议先在试点范围做一轮检查，确认规则有效后再推广到全库。全库上线后按季度或半年做一次集中检查，重点看典型检索场景是否仍能快速定位、交叉知识与过期知识的处理规则是否被执行。项目结项、产品版本发布等节点可增加临时检查。规则变更同样按季度或半年集中评审，紧急问题走临时评审并保留记录。
用 ONES Wiki 承载分类结构时，权限怎么配合角色分工？
ONES Wiki 支持为多种角色配置不同的读写权限，可从页面组到单个页面、从内容编辑到内容导出做不同颗粒度的管控（F4、F6）。配合角色分工时，可让领域负责人拥有本领域目录的编辑权限，普通成员在指定范围内提交内容，项目空间按项目成员范围开放。具体权限颗粒度与配置方式建议按实际使用的版本核验。
