知识共享授权要解决的是“谁能在什么条件下看到、改动或转发哪份知识”。可执行的做法是先把知识对象按敏感度分层，再为每层写清默认可见范围、授权角色、审批路径和有效期，最后用定期复核与到期回收形成闭环。本文聚焦知识对象本身的权限设计，覆盖分层、规则字段、审批流程、生命周期管理和复核检查，不展开全平台身份认证与整体安全政策。
要点总览（TL;DR）
- 先按对象类型和敏感度把知识分成公开、内部、受控、机密等级，为每级设定默认可见范围，把管理精力放在少数高敏感对象上。
- 授权规则统一写成“对象—角色—动作—条件”四要素，区分只读、评论、编辑、分享、导出等动作，让审批人按规则核对而不是逐案讨论。
- 审批按敏感度分级：低级别按默认范围直接开通，高级别逐级审批，紧急授权允许先开通后补批并设补批时限。
- 授权默认有期，到期提醒与自动收回；人员调岗、离职、项目结项和共享范围扩大都要触发权限核对或重新审批。
- 用固定周期的复核检查分层覆盖、审批留痕、到期回收和越权冗余，连续发现同类问题时回到规则表修订。
先定授权对象与敏感度分层
授权规则混乱，往往源于把“知识”当成一个整体。文档、规范、模板、经验记录在传播范围和修改风险上差别很大，需要先分类再分级。分层的目的不是增加审批，而是让大部分低敏感知识保持默认开放，把管理精力集中在少数高敏感对象上。
第一步按对象类型归类。常见类型包括：制度与规范类文档、产品与项目文档、模板与检查表、经验记录与复盘、会议纪要与过程材料、对外可公开的宣传或帮助资料。分类时以“这份知识被谁使用、误传会造成什么后果”为判断依据，而不是按文件格式划分。
第二步定敏感度级别。建议用三级或四级，级别过多会导致规则难记、执行走样。判定依据可以看三个问题：内容是否包含客户信息、商业条款或未发布计划；是否涉及安全、财务、人事等受控领域；共享范围是否跨部门或跨组织。三个问题中命中越多，级别越高。
第三步为每级设定默认可见范围。默认范围决定了日常共享的基线，例外授权在此基础上叠加。
| 对象类型 | 级别 | 默认可见范围 | 判定依据 |
|---|---|---|---|
| 公开帮助资料、通用模板 | L1 公开 | 全员可见，可自由分享 | 不含客户信息与内部计划，外传无风险 |
| 项目文档、业务线需求文档、常规复盘 | L2 内部 | 本部门或本项目成员可见 | 含内部业务信息，跨部门共享需申请 |
| 制度规范、未发布产品计划、含客户信息的材料 | L3 受控 | 指定角色可见，按名单授权 | 涉及商业信息或客户数据，误传有明确影响 |
| 安全、财务、人事等受控领域材料 | L4 机密 | 最小范围授权，逐次审批 | 命中受控领域，且共享范围跨团队 |
分层表完成后要指定维护人。新知识入库时由创建者选择对象类型和级别，知识库运营者定期抽查分级是否合理。级别判定有争议时，按更高级别处理，再通过复核下调，避免先放开后收紧带来的信息外泄。
授权规则怎么写：对象、角色、动作、条件
“这个文档大家都能看”这类口头约定无法执行，也无法审计。把授权写成规则，需要固定四个字段：对象、角色、动作、条件。每条规则表达为“某类对象，允许某角色执行某动作，前提是满足某条件”，规则之间不重叠、不冲突。
对象填写知识对象的范围，可以是单个页面、页面树下的一个分支、某个空间或某类模板。范围越具体，越容易复核。角色填写授权主体，可用部门、项目组、岗位、指定人员名单或“全员”。角色尽量用组织内已有的稳定单元，避免按个人逐一授权导致人员变动后权限残留。
动作需要区分粒度。只读表示可查看内容；评论表示可留言但不改正文；编辑表示可修改内容；分享表示可把页面转发或授权给他人；导出表示可把内容带出知识库。分享和导出是高风险动作，通常只对高敏感对象单独控制。
条件是规则生效的前提，常见写法包括：限定部门或项目、限定时间段、要求先完成审批、限定访问终端或场景。条件要写成可判断的表述，例如“项目结项后 30 天内有效”，而不是“项目期间酌情开放”。
| 字段 | 取值示例 | 填写要求 |
|---|---|---|
| 对象 | 产品需求文档页面树 / 单个复盘页面 | 写明范围边界，避免“全部文档”这类笼统表述 |
| 角色 | 研发一部 / 项目 A 成员 / 指定 3 人名单 | 使用稳定组织单元，个人名单需注明有效期 |
| 动作 | 只读、评论、编辑、分享、导出 | 按最小必要授予，分享与导出单独审批 |
| 条件 | 本部门内 / 审批通过后 / 项目结项后 30 天内 | 条件可判断、可到期，避免模糊描述 |
规则示例：L2 项目文档对项目成员开放只读和评论，编辑权限仅授予文档负责人；L3 受控文档对指定角色开放只读，跨部门查看需审批，分享与导出默认关闭；L4 机密材料逐次授权，有效期不超过一个项目周期。规则表定稿后作为申请审批的依据，审批人只需核对申请是否符合规则，减少逐案讨论。
授权申请与审批流程设计
规则解决“能不能给”，流程解决“怎么给、谁批、留下什么记录”。流程设计的目标是让常规授权快速通过，让例外授权有明确责任人和留痕。
申请入口统一放在知识库或协作平台内，申请单必填信息包括：知识对象及链接、申请人与使用人、所需动作、使用期限、申请理由、所属项目或部门。缺少对象范围和期限的申请直接退回补充，避免审批人反复追问。
审批角色按敏感度分级。L1 对象无需审批，按默认范围直接使用；L2 对象由文档负责人或所属项目负责人审批；L3 对象由部门负责人审批，涉及跨部门时增加知识库运营者会签；L4 对象由业务负责人与安全或合规责任人共同审批。审批人只对规则内的例外做判断，规则内已覆盖的授权可由系统按默认配置开通。
| 环节 | 输入 | 动作 | 输出与负责人 |
|---|---|---|---|
| 提交申请 | 对象、动作、期限、理由 | 填写申请单并关联知识对象 | 待审申请单，申请人 |
| 规则校验 | 申请单与授权规则表 | 核对是否属于默认范围或需例外审批 | 校验结论，知识库运营者 |
| 分级审批 | 校验结论与敏感度级别 | 按级别选择审批人并给出意见 | 审批结果，对应审批人 |
| 开通与记录 | 审批通过的申请单 | 配置权限，记录对象、角色、动作、期限 | 授权记录，系统管理员或文档负责人 |
| 结果通知 | 授权记录 | 通知申请人并说明到期时间 | 开通确认，申请人 |
紧急授权需要单独通道：允许先开通、后补审批，但必须限定最长补批时限，例如 24 小时内补交审批，逾期自动收回。紧急授权每月汇总一次，由知识库运营者检查使用频率，频繁触发说明规则或流程需要调整。
在协作平台中承载这套流程时，可把授权申请做成工作项，审批意见和开通记录留在同一处，便于后续复核。ONES 的知识库提供从所有页面到单个页面、从编辑到导出等不同颗粒度的权限管控，页面共享与协同编辑支撑日常协作；授权审批与到期回收的具体配置方式，需以实际产品版本为准。
共享过程中的变更、到期与回收
授权开通只是起点。人员调岗、项目结项、共享范围扩大都会让原有权限失效或过度，需要把变更、到期和回收纳入日常管理。
有效期设置遵循“默认有期、按需续期”。L2 以上授权必须填写到期时间，期限与项目周期或使用场景挂钩，不设永久授权。到期前一周提醒申请人和文档负责人，确认是否续期；未确认的到期自动收回，续期需重新走一次简化审批。
人员变动是权限残留的主要来源。员工调岗时，由人事或部门负责人触发权限核对，收回原岗位相关的受控文档权限，按新岗位重新授予；离职时在账号停用前完成权限回收，并检查其作为文档负责人或审批人的角色是否需要移交。个人名单授权要同步清理，避免名单长期累积。
共享范围扩大时，例如从部门内扩展到跨部门、从只读扩展到可分享，视为新的授权申请，重新审批，不能沿用原审批结论。范围缩小或动作降级可直接执行，记录变更原因即可。
| 场景 | 动作 | 责任人 | 记录要求 |
|---|---|---|---|
| 授权到期 | 提前提醒，未续期则收回 | 文档负责人 | 记录到期时间与收回结果 |
| 人员调岗 | 收回原岗位权限，按新岗位重授 | 部门负责人 | 记录变动前后权限对照 |
| 人员离职 | 停用前回收全部授权，移交负责人角色 | 人事与文档负责人 | 记录回收确认 |
| 共享范围扩大 | 重新提交申请并审批 | 申请人 | 记录新审批结论 |
| 项目结项 | 按规则收回项目成员权限，保留归档只读 | 项目负责人 | 记录归档范围 |
回收要有确认方式。系统收回后通知申请人，重要对象的回收由文档负责人二次确认；回收记录保留对象、角色、动作、回收时间和操作人，作为复核依据。
定期复核与完成检查
授权机制是否真正运行，看三件事：规则是否被遵守、权限是否与当前人员匹配、例外授权是否收敛。复核按固定节奏执行，才能发现越权和冗余。
复核周期建议：L4 机密对象每季度复核一次，L3 受控对象每半年一次，L2 对象每年一次并结合项目结项触发。复核人由文档负责人初审、知识库运营者汇总，安全或合规责任人抽查高敏感对象。复核不是重新审批全部权限，而是核对现有授权是否仍有业务必要。
高敏感对象的重点检查项包括：授权名单是否与当前项目成员一致；是否存在超出规则的动作，例如对 L3 文档开放了导出；紧急授权是否已补审批；到期未续期的权限是否已收回；文档负责人变更后审批角色是否同步更新。
越权与冗余授权可通过对照识别：把授权记录与组织成员名单、项目成员名单比对，找出已离开项目或部门却仍有权限的记录；把实际动作与规则表比对，找出规则未允许却被授予的动作。发现后按“先收回、再评估、后重授”的顺序处理。
| 检查项 | 通过标准 | 复核人 |
|---|---|---|
| 分层表覆盖情况 | 新增知识对象均已标注类型与级别 | 知识库运营者 |
| 规则表完整性 | 每条规则含对象、角色、动作、条件四字段 | 知识库运营者 |
| 审批留痕 | L3 以上授权均有申请单与审批记录 | 文档负责人 |
| 到期回收 | 到期授权已收回或完成续期审批 | 文档负责人 |
| 人员变动清理 | 调岗、离职人员权限已核对并处理 | 部门负责人 |
| 越权与冗余 | 抽查样本中无规则外授权，无离项人员残留权限 | 安全或合规责任人 |
完成检查以“可查、可对、可收”为标准：授权有记录可查，权限与人员名单可对照，到期和变动权限可收回。连续两个复核周期发现同类问题的，回到规则表修订默认范围和审批条件，让机制随使用情况调整，而不是靠每次复核临时补救。
常见问题
知识共享授权和全平台账号权限是什么关系？
知识共享授权管的是知识对象本身：哪份文档、哪个页面树、哪个空间，允许谁做查看、评论、编辑、分享或导出。全平台账号权限管的是身份认证、组织架构同步和单点登录，决定一个人能否进入平台。两者需要配合：账号停用是权限回收的前提，但知识对象上的授权记录仍需单独清理，尤其是个人名单授权和文档负责人角色。
敏感度分级用三级还是四级更合适？
取决于知识对象的差异程度。三级适合大多数团队：公开、内部、受控，规则容易记住、执行不易走样。如果存在安全、财务、人事等受控领域材料，且共享范围经常跨团队，可以单独拆出机密级，形成四级。级别越多，维护成本越高，建议先用三级运行一个复核周期，再根据实际争议点决定是否细分。
紧急授权先开通后补批，怎么防止被滥用？
给紧急通道设三个约束：限定最长补批时限，例如 24 小时内补交审批，逾期自动收回；限定可发起紧急授权的对象范围，只对 L3 以上且确有业务中断风险的情况开放；每月汇总紧急授权记录，由知识库运营者检查使用频率。频繁触发说明默认规则或审批路径需要调整，应回到规则表修订，而不是长期依赖紧急通道。
项目结项后，项目成员的文档权限应该怎么处理？
按规则收回项目成员的项目内编辑权限，保留归档只读范围，让后续查阅仍有入口。结项时由项目负责人触发权限核对，确认哪些文档需要转为长期知识资产、哪些随项目关闭。转为长期资产的文档要重新指定负责人和敏感度级别，避免归档材料长期停留在无人维护的授权状态。
复核发现越权授权，应该先收回还是先调查原因？
按“先收回、再评估、后重授”的顺序处理。越权授权意味着当前存在规则外的访问，先收回可以止住风险；随后核对授权来源，是审批遗漏、规则表未覆盖还是人员变动未清理；确认业务确有需要后，再按规则重新提交申请。复核记录中保留收回时间、原因和重授结论，便于下个周期对照。
