空间权限要解决的是“谁在什么范围内能看、能改、能分享”的问题。设计时把知识对象按空间、目录、文档三级拆开，逐层确定可见范围、操作动作和共享方式，再用角色分工与审批把授权动作固定下来。本文给出一套可执行的设计步骤、角色权限矩阵模板、配置示例和上线前检查清单，适合负责知识库或空间管理的团队按序落地。
要点总览（TL;DR）
- 空间权限按“空间—目录—文档”三级分层：空间定基调、目录做细分、文档处理例外，下层默认继承上层，放宽超出上层边界时单独审批。
- 先划分空间类型与敏感级别，再定义空间管理员、编辑者、查看者、外部协作者四类角色，用角色权限矩阵固定每个角色能执行的动作。
- 继承规则默认自上而下传递，例外授权需写明范围、对象、动作、期限和回收责任人并走审批，外部分享要限范围、设有效期、留记录。
- 上线前从空间归属、角色覆盖、继承与例外评审、外部分享回收四个维度逐项核对，并用不同角色账号实际验证越权与漏权。
- 权限配置上线后保持季度复核节奏，重点检查例外清单、人员变动后的权限回收和外部分享到期处理。
空间权限要解决什么问题：分层授权的基本框架
空间权限的核心矛盾在于：知识需要被更多人看到和使用，但不同内容的敏感程度、使用场景和责任归属并不相同。如果只按“全开放”或“全封闭”两档管理，要么造成信息过度暴露，要么让协作效率大幅下降。分层授权的作用是把权限决策拆到合适的粒度上，让大部分内容按统一规则自动生效，只对少数例外单独处理。
空间权限的管理对象分为三级。空间是最高层容器，通常对应一个部门、一个项目或一个主题域，承载该范围内的全部知识内容；目录是空间内部的分类结构，用于按业务模块、流程阶段或文档类型组织内容；文档是最小授权单元，指具体的页面或文件。三级对象各自可以设置权限，下层默认继承上层，形成“空间定基调、目录做细分、文档处理例外”的结构。
每一级对象需要明确三个权限要素。可见范围回答“谁能看到”，可以按组织成员、指定人员、外部访客等维度划定；操作动作回答“看到之后能做什么”，常见动作包括查看、评论、编辑、删除、导出、分享；共享方式回答“内容如何流转出去”，包括空间内共享、跨空间引用、对外链接分享等形式。三个要素组合起来，才构成一条完整的权限规则。
分层授权与继承的基本逻辑是：上层设置作为默认值向下传递，下层可以在授权范围内收紧或放宽，但放宽到超出上层边界时需要单独审批。这样设计的好处是，日常新增的目录和文档不需要逐个配置权限，只有真正偏离默认规则的内容才进入审批流程，管理成本集中在少数例外上。
第一步：划分空间类型与敏感级别
授权规则建立在空间划分之上，空间边界不清，后续的角色和继承规则就无从谈起。划分空间时先确定分类维度：按部门划分适合职能知识沉淀，按项目划分适合阶段性交付物管理，按主题划分适合跨部门共享的专业知识。一个组织可以同时使用多种维度，但同一层级内应保持维度一致，避免出现“研发部”和“2024年项目”并列这种口径混乱的情况。
敏感级别标注是划分工作的第二个动作。建议采用三到四档的简单分级，例如公开、内部、受限、机密。公开级内容允许全员查看并可用于对外分享；内部级限组织成员查看；受限级限指定团队或角色；机密级限明确列出的个人。分级标准要写成可判断的描述，例如“包含客户合同条款的内容定为机密级”，而不是留给管理员凭感觉判断。
每个空间还需要明确命名规则和归属责任人。命名建议包含“类型—业务域—敏感级别”三段信息，例如“项目—支付系统—受限”，让成员在空间列表中就能判断能否申请访问。归属责任人通常是该业务域的负责人或知识库管理员，负责审批本空间的权限申请、复核例外授权、在人员变动时发起权限回收。责任人信息应记录在空间说明中，避免出现无人负责的空间。
| 空间类型 | 典型用途 | 建议敏感级别 | 归属责任人 |
|---|---|---|---|
| 部门空间 | 部门制度、流程、培训材料 | 内部 | 部门负责人或指定知识管理员 |
| 项目空间 | 需求、设计、测试、交付文档 | 受限 | 项目经理 |
| 主题空间 | 跨部门专业知识、技术规范 | 内部或公开 | 主题牵头人 |
| 管理层空间 | 经营分析、战略材料 | 机密 | 指定高管或办公室负责人 |
第二步：定义角色与权限矩阵
角色设置的目标是用有限几个角色覆盖绝大多数授权场景，避免为每个人单独配权限。常见角色包括四类：空间管理员负责本空间的权限配置、成员管理和例外审批；编辑者可以创建、修改、整理内容，但不能变更空间级权限；查看者只能阅读和评论，适合大多数普通成员；外部协作者是组织外部的有限访问者，权限范围应单独限定到具体目录或文档。
权限矩阵以角色为行、权限动作为列，逐格填写“允许”“只读”或“禁止”。填写时注意两点：一是动作要覆盖实际使用场景，除查看、编辑外，导出和分享往往是最需要控制的动作，因为内容一旦导出就脱离了平台权限体系；二是同一动作在不同角色间要有明确差异，如果两个角色的矩阵行完全一致，说明角色划分没有实际意义，应合并。
| 角色 | 查看 | 评论 | 编辑 | 删除 | 导出 | 分享 | 权限配置 |
|---|---|---|---|---|---|---|---|
| 空间管理员 | 允许 | 允许 | 允许 | 允许 | 允许 | 允许 | 允许 |
| 编辑者 | 允许 | 允许 | 允许 | 禁止 | 按需 | 禁止 | 禁止 |
| 查看者 | 允许 | 允许 | 禁止 | 禁止 | 禁止 | 禁止 | 禁止 |
| 外部协作者 | 限指定范围 | 按需 | 按需 | 禁止 | 禁止 | 禁止 | 禁止 |
矩阵填写完成后需要评审，评审由空间责任人和安全或合规角色共同参与。评审关注三个问题：敏感级别高的空间是否收紧了导出和分享动作；外部协作者的范围是否限定到具体内容而非整个空间；是否存在某个角色同时拥有编辑和权限配置能力却缺少监督。评审结论记录在案，作为后续变更的基线。
第三步：配置继承、例外与共享规则
继承规则决定权限如何从空间传递到目录再到文档。默认做法是自上而下继承：空间设置的成员和角色自动适用于其下所有目录和文档，目录可以在此基础上增加成员或调整角色，但不能削减空间已授予的权限。文档默认继承所在目录的规则，只有需要单独控制时才设置独立权限。这套默认规则让新增内容自动获得合理权限，减少逐篇配置的工作量。
例外授权是偏离继承规则的操作，必须纳入审批。典型例外包括：某篇文档需要向未加入该空间的团队开放；某个目录需要临时收紧到少数人可见；某份材料需要允许导出。处理方式是提交例外申请，写明内容范围、授权对象、权限动作、有效期限和回收责任人，由空间责任人审批，敏感级别高的空间还需安全角色会签。例外记录集中登记，到期前由责任人确认是否续期或回收。
外部分享需要单独设计规则。分享前确认内容敏感级别允许对外；分享时限定访问范围，优先选择指定人员而非公开链接；设置有效期，到期自动失效或由责任人手动回收；记录分享对象和分享时间，便于后续追溯。对于包含客户信息、合同条款或未公开经营数据的内容，应默认禁止外部分享，确有需要时走例外审批。
- 继承规则：空间→目录→文档逐层传递，下层可增加不可削减。
- 例外审批：写明范围、对象、动作、期限、回收责任人，按敏感级别决定审批层级。
- 外部分享：先核敏感级别，再限范围、设有效期、留记录。
- 定期复核：每季度检查例外清单和外部分享记录，清理过期授权。
角色分工与交付物：谁负责哪一步
空间权限建设涉及四类角色，各自承担不同职责。知识库负责人对整个知识体系的权限框架负责，确定空间划分原则和敏感级别标准，审批跨空间的重大例外。空间管理员负责本空间的日常权限配置，包括成员增减、角色调整、例外申请初审和到期回收。IT或平台管理员负责权限系统的配置承载，包括角色定义的技术实现、继承规则的系统设置和权限变更的操作支持。安全或合规角色负责评审敏感级别标准、抽查例外授权记录、对外部分享进行合规审查。
| 角色 | 主要职责 | 输入 | 输出 |
|---|---|---|---|
| 知识库负责人 | 确定框架与标准，审批重大例外 | 业务知识管理需求、安全要求 | 空间划分原则、敏感级别标准、例外审批结论 |
| 空间管理员 | 日常权限配置与例外管理 | 空间划分表、角色权限矩阵 | 成员权限配置、例外登记记录、回收确认 |
| IT/平台管理员 | 系统配置与操作支持 | 角色定义、继承规则 | 系统权限配置、变更操作记录 |
| 安全/合规角色 | 评审标准与抽查记录 | 敏感级别标准、例外清单 | 评审意见、抽查报告、整改要求 |
交接与评审节点有三个。空间划分和敏感级别标准完成后，由知识库负责人组织一次评审，确认分类口径一致。角色权限矩阵填写完成后，由空间管理员提交、安全角色会签，确认敏感动作已收紧。权限配置上线前，由IT管理员执行配置、空间管理员核对结果，双方在检查清单上签字确认。此后每次例外授权到期和人员变动，都触发一次小范围复核。
在系统承载上，ONES 企业知识库以页面树方式组织内容，页面之间的关系清晰可见，便于按空间和目录结构对应权限层级；其权限管控覆盖从所有页面到单个页面的范围，并延伸到内容编辑和导出等不同维度，页面共享能力支持成员基于页面开展协作。上述角色分工和审批记录可以在同一平台内与内容组织方式对应起来，减少权限配置与内容结构脱节的情况。
示例：一个研发知识空间的权限配置
以下为演示情景，用于说明配置过程，不代表特定组织的实际方案。某研发团队建立“研发知识空间”，敏感级别定为受限，归属责任人为研发总监。空间下划分三个目录：技术规范（长期有效、团队共用）、项目文档（按项目阶段更新）、故障复盘（含系统细节，范围更窄）。
空间级角色配置为：研发总监为空间管理员；各技术方向负责人为编辑者；研发团队全体成员为查看者；测试和运维团队按需申请查看权限。技术规范目录沿用空间继承规则，全员可查看，编辑者负责维护。项目文档目录在继承基础上增加各项目组成员为编辑者，项目结束后由空间管理员将项目组角色调整为查看者。故障复盘目录收紧权限，仅限故障处理相关人员和研发总监查看，导出动作对该目录关闭。
例外处理有两项。其一，一份技术规范需要提供给外部合作方参考，空间管理员提交例外申请，授权对象为合作方两名接口人，权限为指定页面查看，有效期三个月，回收责任人为空间管理员，经研发总监审批后执行。其二，某次故障复盘需要向质量部门负责人开放，采用单篇文档例外授权，期限一个月，到期自动回收。两项例外均登记在例外清单中，季度复核时检查是否续期。
配置完成后，空间管理员用检查清单逐项核对：空间归属和责任人已填写；四个角色均有对应人员；继承规则在三个目录上验证生效；两项例外有审批记录和回收期限；外部分享仅一项且已设有效期。核对通过后空间正式开放使用。
完成检查：空间权限上线前的核对项
上线前的检查目的是发现越权和漏权两类问题。越权指某些角色获得了超出其职责的权限，例如查看者拥有导出能力；漏权指应获得访问的人员无法正常使用内容，例如新加入项目组的成员看不到项目文档。以下清单按四个维度逐项核对，全部通过方可上线。
| 核对维度 | 检查项 | 通过标准 |
|---|---|---|
| 空间归属 | 每个空间是否有明确的责任人和敏感级别 | 空间说明中记录责任人和级别，无空缺 |
| 角色覆盖 | 权限矩阵是否覆盖全部角色和关键动作 | 四类角色均有矩阵行，导出和分享动作已明确 |
| 继承与例外 | 继承规则是否验证生效，例外是否经过评审 | 抽查目录和文档权限与预期一致，例外有审批记录 |
| 外部分享 | 外部分享是否有范围限制和回收机制 | 每项分享有对象、期限和回收责任人 |
除表格核对项外，建议做一次实际验证：用查看者账号登录，确认无法编辑和导出；用外部协作者账号访问，确认只能看到授权范围；检查一个新建文档，确认自动继承所在目录的权限。验证结果记录在检查表中，作为上线依据。上线后保持季度复核节奏，重点检查例外清单、人员变动后的权限回收和外部分享的到期处理，让权限配置随组织变化持续保持准确。
常见问题
空间权限设计中，目录和文档的权限应该由谁来决定？
通常由空间管理员决定本空间内的目录权限和文档例外授权，空间责任人负责审批偏离继承规则的例外。敏感级别高的空间，例外授权还需要安全或合规角色会签。这样分工的依据是：空间管理员最了解本空间的内容和人员，而责任人承担授权结果的最终责任。如果组织规模较小，空间管理员和责任人可以由同一人担任，但审批记录仍应保留，便于后续复核。
外部分享已经设置了有效期，还需要额外做什么？
有效期只解决“到期失效”的问题，还需要同时限定访问范围并留下记录。分享时优先选择指定人员而非公开链接，记录分享对象、分享时间和内容范围，并明确回收责任人。对于包含客户信息、合同条款或未公开经营数据的内容，建议默认不走外部分享，确有需要时按例外授权流程审批。到期前由责任人确认是否续期，到期后核对分享是否已实际关闭。
人员离职或转岗后，空间权限怎么处理才不留隐患？
把人员变动作为权限复核的触发条件，而不是等到季度复核才处理。具体做法是：空间管理员在收到人员变动通知后，检查该成员在各空间中的角色，将其从编辑者、空间管理员等角色中移除或调整；如果该成员是某项例外授权的授权对象，同步回收或变更授权；如果该成员是例外授权的回收责任人，需要先把责任转交给他人。变动处理完成后在例外清单和成员列表中标注处理时间，便于抽查。
空间数量很多时，权限配置怎么避免重复劳动？
关键是把共性规则沉淀到空间模板和角色模板中。按空间类型（部门、项目、主题、管理层）预先定义好默认的敏感级别、角色配置和继承规则，新建空间时套用模板再按需微调，避免每个空间从零配置。同时控制角色数量，如果两个角色的权限矩阵完全一致就合并，角色越少，配置和复核的工作量越小。空间命名中带上类型和敏感级别，也便于批量识别需要收紧的空间。
上线检查时怎么实际验证权限配置是否正确？
用不同角色的账号做实际访问验证，比只看配置表更可靠。常见做法包括：用查看者账号登录，确认无法编辑、删除和导出；用外部协作者账号访问，确认只能看到授权范围内的内容；新建一篇文档，确认它自动继承了所在目录的权限；抽查一项例外授权，确认授权对象和期限与审批记录一致。验证结果记录在检查表中，发现问题回到对应步骤修正后重新验证。
