知识空间组织规则要解决的是“内容放在哪、谁能看、以后怎么维护”这三个日常问题。一份可用的规则文档通常把空间、目录、页面、标签、权限五层关系写清楚。下面以虚构团队“示例科技”为背景，给出一份完整填写范例，并逐项说明取值理由与迁移方法。规则最终要落到具体工具里，ONES 文档与知识库可作为承载方向之一。
要点总览（TL;DR）
- 知识空间组织规则的核心是把空间、目录、页面、标签、权限五层关系写清楚，让成员在创建内容前就知道放哪、谁能看、怎么维护。
- 示例科技的空间按业务域与知识类型划分，目录固定为空间加两级共三层，标签承担跨目录的横向关联，权限按角色而非按人配置。
- 命名采用“空间前缀+类型代码+流水号+人工主题”的组合，机器可识别的部分保证唯一性，人工部分保证可读性。
- 迁移时可直接沿用五层结构、角色权限和命名格式，空间数量、目录深度、标签类别与维护节奏需按团队规模和业务调整。
- 示例为虚构情景，规模、合规或保密要求明显超出假设时，权限矩阵与留存规则需另行设计，规则文档也应定期复审。
示例目标：这份规则要解决什么组织问题
“示例科技”是一个虚构情景：约120人的产品研发团队，包含产品、设计、研发、测试、市场与职能六个职能组，知识内容以产品需求、技术方案、项目复盘、制度流程为主，累计页面规模在数千级。团队此前用共享盘和聊天工具传文件，常见问题是同一份方案出现多个版本、新人找不到入口、敏感内容被转发到无关群组。这份规则文档的目标就是让成员在创建内容前就知道放在哪个空间、归到哪个目录、用什么标签、默认谁能看。
规则文档覆盖以下范围：
- 空间的划分依据、归属团队与可见范围；
- 目录的层级结构与命名方式；
- 页面命名、编号与标签使用约定；
- 角色与权限的对应关系；
- 各空间的维护责任人与更新节奏。
规则文档不覆盖两类内容：一是知识检索与发现的具体方法，例如搜索技巧、推荐机制、门户配置；二是内容模板与写作规范，例如需求文档模板、复盘模板的字段设计。这两部分属于相邻主题，需要单独成文。把边界写进规则文档本身，可以避免规则越写越厚、执行时找不到重点。
完整示例：示例科技的知识空间组织规则
以下为“示例科技”规则文档的正文范例，按空间、目录、命名、标签、权限、维护六个部分展开，可直接作为填写参照。
空间划分
| 空间名称 | 归属团队 | 用途 | 可见范围 |
|---|---|---|---|
| 产品与规划 | 产品组 | 产品路线图、需求池、竞品分析 | 全员可读，产品组可写 |
| 研发与技术 | 研发组 | 技术方案、接口文档、架构决策记录 | 研发、测试可读，研发组可写 |
| 设计与体验 | 设计组 | 设计规范、组件说明、交互稿说明 | 全员可读，设计组可写 |
| 项目与复盘 | 项目管理办公室 | 项目计划、里程碑记录、复盘报告 | 全员可读，项目负责人可写 |
| 制度与流程 | 职能组 | 人事、财务、行政制度与操作指引 | 全员可读，职能组可写 |
| 管理专区 | 管理层 | 经营分析、组织调整、薪酬相关材料 | 指定角色可读，管理层可写 |
目录层级
每个空间内目录固定为两级，加上空间本身共三层。以“研发与技术”空间为例：
- 一级主题按知识类型划分：技术方案、接口与集成、架构决策、环境与工具、故障与复盘；
- 二级子主题按系统或模块划分：例如“技术方案”下分订单系统、支付系统、用户中心；
- 页面直接放在二级目录下，不再新建第三级目录；内容确实需要再分层时，用页面内标题组织。
页面命名与编号
页面标题采用“编号 + 主题 + 类型”的格式，例如“RD-ARCH-014 订单系统拆分架构决策记录”。编号规则为：空间前缀（RD 研发、PD 产品、DS 设计、PJ 项目、OP 制度、MG 管理）+ 类型代码（ARCH 架构决策、SPEC 方案、API 接口、REV 复盘、POL 制度）+ 三位流水号。流水号由空间维护人统一分配，避免重号。标题中的主题部分由创建人自行概括，要求能独立看懂，不使用“文档1”“最新版”这类无法识别的名称。
标签体系
| 标签类别 | 命名格式 | 使用场景 |
|---|---|---|
| 业务线 | 业务线:订单 / 业务线:支付 | 标记内容服务的业务对象，支持跨空间汇总 |
| 内容状态 | 状态:草稿 / 状态:评审中 / 状态:已生效 / 状态:已归档 | 标识页面所处阶段，便于筛选待评审和已失效内容 |
| 项目代号 | 项目:启明星 | 关联同一项目跨空间的材料 |
| 适用角色 | 角色:新成员 / 角色:值班 | 标记新人必读或值班常用内容 |
标签由创建人从预置列表中选择，不自行新增类别；需要新增标签类别时，向知识管理员提出，由管理员统一维护标签词表。
权限矩阵
| 角色 | 产品与规划 | 研发与技术 | 制度与流程 | 管理专区 |
|---|---|---|---|---|
| 全员 | 读 | 读（限研发、测试） | 读 | 无权限 |
| 空间成员 | 读写 | 读写 | 读写 | 无权限 |
| 空间维护人 | 读写、归档、分配编号 | 读写、归档、分配编号 | 读写、归档、分配编号 | 无权限 |
| 管理层 | 读 | 读 | 读 | 读写 |
| 知识管理员 | 管理权限 | 管理权限 | 管理权限 | 管理权限 |
维护责任与更新节奏
- 每个空间设一名维护人，由归属团队负责人指定，负责编号分配、目录调整和过期内容归档；
- 空间成员每月检查一次自己创建的页面，把不再有效的内容状态改为“已归档”；
- 维护人每季度做一次目录与标签巡检，合并重复页面、清理失效标签；
- 知识管理员每半年组织一次规则复审，根据组织变化调整空间划分与权限设置。
逐项解释：每条规则为什么这样填
空间按业务域和知识类型划分，而非直接照搬部门架构。原因是知识的使用者往往跨部门：研发要读产品需求，测试要读技术方案，按部门划分会让跨部门内容无处安放。例外情况是职能类内容，例如人事、财务制度，其读者与维护者高度重合，按团队划分更直接。示例中“管理专区”单独成空间，是因为其内容敏感度明显高于其他空间，需要独立的权限边界。
目录层级控制在三层，是容量与可发现性的折中。层级过浅，单个目录下页面过多，浏览时难以定位；层级过深，成员需要记忆路径，创建时也容易放错位置。三层结构下，空间回答“这是哪类知识”，一级目录回答“属于哪个主题”，二级目录回答“涉及哪个系统或模块”，判断路径短且稳定。页面内部再用标题分层，可以承载更细的结构而不增加目录负担。
标签与目录的分工可以概括为：目录管归属，标签管横向关联。一份订单系统的架构决策，归属固定在“研发与技术 / 架构决策”下，同时可以打上“业务线:订单”“项目:启明星”“状态:已生效”三个标签，从而在产品、项目、状态等维度被汇总。如果试图用目录表达所有维度，目录会迅速膨胀；如果只用标签不用目录，内容又缺少稳定的存放位置。两者配合，才能兼顾归属清晰与多维查找。
权限按角色配置而非按人配置，主要考虑可维护性。按人授权在人员入职、转岗、离职时都需要逐条调整，容易遗漏并留下越权访问。角色与空间绑定后，人员变动只需调整角色归属，权限随之生效。代价是角色划分需要提前设计，粒度太粗会导致权限过宽，示例中把“空间成员”和“空间维护人”分开，就是为了让日常写作与归档管理各归其位。
命名规则中，编号前缀、类型代码和流水号是可机器识别的部分，便于排序、检索和批量核对；主题部分需要人工判断，要求写清业务对象和文档类型。把两者分开的好处是：机器部分保证唯一性和可追溯，人工部分保证可读性。若全部交给人工命名，容易出现同义不同名；若全部交给机器生成，标题又会失去信息量。
可迁移规律：换一个团队怎么改这份示例
可以直接沿用的结构有三项：五层关系（空间、目录、页面、标签、权限）本身；权限按角色配置而非按人配置；命名采用“可识别前缀 + 人工主题”的组合格式。这三项与团队规模关系不大，换到多数知识型团队都成立。
需要按规模调整的是空间数量与目录深度。团队在几十人以内时，空间可以压缩到三到四个，例如“业务知识”“技术知识”“制度流程”，避免每个小组都建空间导致入口分散；目录可以保持两层。团队达到数百人、业务线明显分化时，空间可按业务线拆分，目录仍建议不超过三层，超出部分用页面内结构承载。
需要按业务调整的是标签类别与维护节奏。以项目制为主的团队，项目代号标签价值高；以产品线运营为主的团队，业务线标签更常用；强监管行业可能还需要“合规状态”一类标签。维护节奏同样随内容更新速度变化：需求变化快的团队，月度自查比季度巡检更合适；制度类内容变化慢，半年复审即可。
迁移时的最小改动路径建议按以下顺序执行：
- 先确定空间清单和每个空间的归属团队、可见范围；
- 为每个空间定一级目录，控制在五个以内；
- 确定命名前缀与类型代码，指定编号分配人；
- 从现有内容中提炼三到五类高频标签，形成初始词表；
- 按角色配置权限，先覆盖读权限，再细化写与管理权限；
- 指定维护人并约定首次巡检时间。
这套规则落到工具中时，空间对应知识库或文档库，目录对应页面树，标签对应内容标签，权限对应角色授权。ONES 文档与知识库提供了空间、页面树与角色权限的组织方式，可以把上述规则直接映射为配置项；具体配置方式以实际使用版本的说明为准。
适用边界：这份示例在什么情况下不适用
需要明确的是，“示例科技”是虚构情景，文中的空间名称、人员规模、权限矩阵均为演示设定，不代表任何真实客户，也不是实测结果。读者可以参照其结构填写自己的规则，但不应把具体取值当作行业标准。
当团队规模或业务复杂度明显超出示例假设时，规则需要重新设计。例如多业务线并行、跨地域协作、大量外部合作方参与的场景，空间划分可能需要引入“内外部”维度，权限矩阵也要增加外部协作者角色。此时直接套用示例中的六个空间和四级角色，容易出现权限过宽或协作受阻。
强合规、强保密场景下，权限与留存规则需要另行设计。示例只区分了“可读、可写、可管理”三类操作，未涉及内容分级、访问审计、留存期限、导出限制等要求。涉及个人信息、财务数据或合同文本的空间，应结合所在行业的合规要求单独制定访问与留存策略，不能以本文的权限矩阵作为依据。
规则文档本身也需要随组织变化复审。团队重组、业务线调整、工具迁移都会让原有的空间划分和权限设置失效。建议在规则文档中写明复审周期与责任人，把“规则过期”当作需要处理的问题，而不是默认规则一旦发布就长期有效。
常见问题
团队只有二三十人，还需要划分这么多空间吗？
可以压缩。示例中的六个空间对应约120人、六个职能组的设定。团队在几十人以内时，建议先合并为三到四个空间，例如“业务知识”“技术知识”“制度流程”，把原来的细分主题降为空间内的一级目录。空间数量减少后，入口更集中，成员不需要先判断该进哪个空间。等业务线明显分化、单个空间页面过多时，再按业务域拆分。
目录已经有三层，某个主题内容还是放不下怎么办？
优先在页面内部用标题分层，而不是继续新建目录。目录的作用是提供稳定的存放位置和浏览路径，层级越深，创建时的判断成本越高，放错位置的概率也越大。如果某个二级目录下的页面数量长期偏多，可以考虑把它提升为一级主题，同时合并其他内容较少的主题，保持每个空间一级目录在五个以内。目录调整属于维护人的职责，应集中处理并通知空间成员。
标签和目录会不会重复，能不能只用其中一种？
两者承担不同职责。目录回答“这份内容归属哪里”，一份内容只有一个固定位置；标签回答“它还和哪些维度相关”，一份内容可以同时带业务线、项目、状态等多个标签。只用目录，跨业务线、跨项目的汇总很难做；只用标签，内容缺少稳定归属，新人不知道从哪找起。示例中标签从预置词表选择、不自行新增类别，就是为了避免标签越用越散。
人员转岗频繁时，权限怎么配置才不容易出错？
把权限绑定到角色，人员变动时只调整角色归属，不逐条改授权。示例中区分了全员、空间成员、空间维护人、管理层和知识管理员五类角色，读写与管理操作分开。执行时需要注意两点：一是角色划分要覆盖实际岗位，粒度太粗会导致权限过宽；二是人员转岗或离职时，角色调整要和人事流程衔接，避免账号仍保留原空间权限。涉及敏感内容的空间，建议定期核对成员名单。
规则文档发布后，多久需要复审一次？
示例设定为知识管理员每半年组织一次复审，空间维护人每季度做目录与标签巡检。这个节奏适合内容变化中等的团队。需求变化快的团队可以把自查缩短到月度，制度类内容变化慢的团队可以适当延长。复审的触发条件不只是时间，团队重组、业务线调整、工具迁移都会让原有空间划分和权限设置失效，出现这类变化时应立即启动复审，并在规则文档中写明责任人和下次复审时间。
