知识检索范围设置要解决的是“谁能搜到什么”：同一组关键词，不同角色看到的文档集合应当有明确边界。落地时把范围拆成空间/库级可见范围、文档级密级与标签、检索入口过滤条件三层，再按盘点、定义、配置、验证的顺序推进，并指定各环节的责任人。范围规则最终要由知识库空间、文档权限和检索入口承载，ONES 知识管理可作为落地工具之一。本文给出三层框架、操作步骤、角色分工、配置示例与完成检查清单。
要点总览（TL;DR）
- 知识检索范围设置拆成三层：空间/知识库级可见范围决定候选池，文档密级与标签在池内收窄，检索过滤条件只作用于单次查询；冲突时以更严格的一层为准。
- 实施按五步推进：盘点资产与角色、定义密级与标签、配置空间成员与继承、设置检索过滤默认值、用典型角色账号验证，每步都要有输入、动作、输出和完成标志。
- 规则定义、日常配置、合规审批和使用反馈分给知识管理员、空间负责人、安全/合规角色与普通使用者，例外申请走固定审批路径并记录有效期。
- 验收重点查越权可见、应见未见、过滤默认值、继承规则和例外记录；常见失效原因是继承覆盖、标签缺失和用户关闭过滤项。
- 过滤条件只影响检索结果、不改变访问权限，规则文档中要把两者分开说明，避免使用者把搜不到误当成没有权限。
先定范围分层：空间、文档与检索过滤三层
范围设置容易失败，通常是因为把“可见性”当成一个开关处理。一个用户搜不到某篇文档，可能来自三种原因：他不在该空间、文档密级高于他的权限、检索时过滤条件把结果排除了。三层分开配置，出问题时才能定位到具体一层。
| 层级 | 控制对象 | 典型配置位置 | 优先级 |
|---|---|---|---|
| 空间/知识库级可见范围 | 整个空间或知识库对哪些部门、团队、角色开放 | 空间成员管理、访问权限设置 | 基础层，决定检索的候选池 |
| 文档级密级与标签 | 单篇文档或文档集合的可见级别、业务标签 | 文档属性、密级字段、标签体系 | 收敛层，在空间范围内进一步收窄 |
| 检索入口过滤条件 | 时间、文档类型、状态、标签等检索时的筛选维度 | 搜索框过滤项、默认筛选值 | 查询层，作用于单次检索 |
三层的输入与输出各不相同。空间层需要资产清单和角色清单，输出是“空间—成员”对照表；文档层需要密级定义和标签规范，输出是文档密级标注规则；检索层需要各角色的常用查询场景，输出是过滤项清单与默认值表。三份产物合起来，就是一套可执行的范围规则表。
冲突处理遵循“更严格者优先”的原则。空间允许访问、文档密级不允许时，以文档密级为准；文档密级允许、检索过滤条件排除时，本次检索不返回该文档，但用户直接访问文档链接仍可打开。这意味着过滤条件只影响检索结果，不改变访问权限，两者要在规则文档中分开说明，避免使用者误以为搜不到就是没有权限。
本文讨论的是信息查找范围，即哪些人在哪些入口能检索到哪些文档。AI 问答如何组织答案、底层搜索算法与索引如何实现，属于另外的问题，不在本文范围内。
按步骤完成一次范围设置
以下五步按依赖关系排列，前一步的产出是后一步的输入。每步给出输入、动作、输出和完成标志，完成标志用于判断这一步是否真的做完，而不只是配置界面填过。
步骤一：盘点知识资产与使用角色
输入是现有知识库目录、文档清单和团队角色名单。动作是把文档按业务主题归类，把角色按“需要查什么”归类，然后交叉形成资产—角色矩阵，标出每类文档对每类角色是“必须可见”“按需申请”还是“不可见”。输出是一张矩阵表。完成标志是矩阵中每个格子都有明确取值，没有空白格。
步骤二：定义密级与标签体系
输入是步骤一的矩阵和组织的保密要求。动作是确定密级档位，例如公开、内部、受限、机密四档，为每档写明可见角色范围；同时定义标签维度，例如业务线、文档类型、项目阶段。还要确定默认可见级别：新文档未标注时按哪一档处理，通常取较保守的一档，由作者在发布时主动调整。输出是密级定义表和标签规范。完成标志是任意一篇新文档都能依据规范在五分钟内完成标注。
步骤三：配置空间/库的成员与继承规则
输入是资产—角色矩阵和密级定义表。动作是为每个空间设置成员范围，明确哪些角色通过部门或团队继承获得访问权，哪些需要单独添加；同时检查子空间或子目录是否继承上级权限，继承方向是单向还是可覆盖。输出是空间成员配置表和继承规则说明。完成标志是每个空间的成员名单都能对应到矩阵中的角色，且继承关系画得出来。
步骤四：设置检索入口的过滤项与默认值
输入是各角色的常用查询场景记录。动作是确定检索入口提供哪些过滤维度，例如时间范围、文档类型、状态、标签；为每个入口设定默认过滤值，例如默认只搜已发布文档、默认时间范围为近两年；并决定用户是否可以自行调整这些默认值。输出是过滤项配置表和默认值清单。完成标志是每个检索入口的默认值与矩阵中的角色预期一致。
步骤五：用典型角色账号做检索验证
输入是前面四步的全部产物和若干测试账号。动作是为每个典型角色准备一组关键词，分别检索，记录返回结果与预期是否一致，重点看两类偏差：搜到了不该看的文档，该看的文档没搜到。输出是验证记录表，逐条写明角色、关键词、预期结果、实际结果、偏差原因。完成标志是所有偏差都已定位到具体层级并完成修正，或已登记为例外并走审批。
角色分工与交付物
范围设置涉及规则定义、日常配置、合规把关和使用反馈四类工作，集中在一个角色身上容易形成瓶颈，也容易在人员变动后失效。下表按角色列出职责与交付物。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 知识管理员 | 定义三层范围规则，维护密级与标签体系，组织验证 | 范围规则表、密级定义表、验证记录 |
| 空间负责人 | 维护本空间成员名单，审核本空间文档密级标注 | 空间成员配置表、密级标注抽查记录 |
| 安全/合规角色 | 审定密级标准，审批例外申请，抽查越权风险 | 密级标准批复、例外审批记录、抽查报告 |
| 普通使用者 | 按规则检索，反馈漏检与越权情况 | 问题反馈单 |
例外申请走固定路径：使用者或空间负责人提出，说明需要访问的文档范围和业务理由，由安全/合规角色审批，知识管理员在系统中落实临时或长期授权，并记录到期时间。例外记录要能按文档和按人两个方向查询，便于后续复查。
范围变更由以下情况触发：组织架构调整导致角色变化、新增知识库或文档类型、发生越权事件、密级标准修订。变更责任人是知识管理员，空间负责人配合更新本空间配置，安全/合规角色对涉及密级调整的变更重新审定。每次变更后在规则表中记录变更日期和影响范围。
在工具层面，这套分工需要系统提供对应的承载点：空间成员与权限设置在空间管理入口完成，文档密级与标签作为文档属性维护，检索过滤项在搜索入口配置。ONES 知识管理提供知识库空间、文档属性与检索入口，可分别对应上述三层；具体配置路径以产品实际界面为准。
示例：一个研发知识库的范围设置
以下为演示情景，用于说明三层规则如何落地，数值与角色设置为示例设定，不代表任何组织的实际配置。
场景设定：某研发团队的知识库包含需求文档、设计文档、测试用例、运维手册四类内容，使用角色包括产品经理、开发工程师、测试工程师、运维工程师和外部合作方。
| 文档类型 | 密级 | 可见角色 | 所在空间 |
|---|---|---|---|
| 需求文档 | 内部 | 产品、开发、测试 | 产品空间 |
| 设计文档 | 受限 | 开发、架构评审组 | 研发空间 |
| 测试用例 | 内部 | 测试、开发 | 测试空间 |
| 运维手册 | 受限 | 运维、开发负责人 | 运维空间 |
检索过滤项的默认值设置为：默认只返回状态为“已发布”的文档，默认时间范围为近一年，文档类型不预设。用户可以在检索时调整时间范围和类型，状态过滤默认开启但允许关闭，关闭操作在结果页有提示。
不同角色检索同一关键词“登录接口”时，结果差异如下：产品经理在产品空间内看到需求文档中的登录接口描述；开发工程师在研发空间看到设计文档中的接口定义，同时在测试空间看到相关测试用例；测试工程师看到测试用例和需求文档，看不到设计文档；运维工程师看到运维手册中的登录服务部署说明，看不到需求与设计文档；外部合作方仅能看到标记为公开的对接说明文档。这一差异来自空间成员范围与文档密级的叠加，而非检索算法本身。
该示例的输入是四类文档清单和五类角色名单，动作是逐类标注密级、配置空间成员、设定过滤默认值，输出是上表与检索结果差异说明。团队可参照这一结构替换为自己的文档类型和角色。
完成检查：范围设置是否生效
配置完成不等于设置生效。以下检查项应逐项执行，每项给出通过标准和验证方法，检查结果记入验证记录表。
| 检查项 | 通过标准 | 验证方法 |
|---|---|---|
| 越权可见 | 低权限角色检索不到高于其密级的文档 | 用低权限账号检索高密级文档的关键词，结果为空或仅显示无权限提示 |
| 应见未见 | 矩阵中标记为“必须可见”的文档能被对应角色检索到 | 按矩阵逐角色抽取文档标题关键词检索，核对命中 |
| 过滤默认值 | 检索入口默认过滤值与配置表一致 | 新开检索页面，不调整任何过滤项，检查默认条件 |
| 继承规则 | 子空间权限与预期继承方向一致 | 在子空间新增一名成员，检查其是否获得上级空间预期范围内的访问权 |
| 例外审批记录 | 每条例外都有申请理由、审批人和有效期 | 抽查例外清单，核对审批记录完整性 |
常见失效原因有三类。继承覆盖：子空间单独设置了权限，覆盖了上级空间的成员范围，导致部分人失去访问权或获得额外访问权，检查时应从子空间向上逐层核对。标签缺失：文档发布时未标注密级，系统按默认级别处理，若默认级别设置过宽，会出现越权可见；应抽查近期发布文档的标注率。过滤项被用户关闭：状态或时间过滤被使用者手动关闭后，检索结果范围扩大，若其中包含其本无权限的文档，说明权限层本身有缺口，需回到文档密级检查。
发现问题后的修正动作按层级对应：越权可见先查文档密级标注，再查空间成员；应见未见先查空间成员和继承关系，再查过滤默认值是否过严；过滤默认值不符直接修改检索入口配置并重新验证。每次修正后在验证记录中写明问题、原因、修正动作和复验结果。涉及密级调整的修正需经安全/合规角色确认后生效。
常见问题
空间权限允许访问、但文档密级更高时，以哪个为准？
以更严格的一层为准，即文档密级优先。空间成员范围决定的是检索候选池，文档密级在池内进一步收窄，所以空间允许访问、密级不允许时，该文档不应出现在检索结果中，直接访问也应被拦截。
这条规则要写进范围规则表，并在验证阶段用低权限账号专门测一遍，确认密级确实压过了空间权限。
用户关闭检索过滤项后搜到了更多文档，是权限出了问题吗？
需要分两种情况看。如果多出来的文档本来就在该用户的可见范围内，只是被时间或状态过滤挡住了，这属于过滤条件的作用，不是权限缺口；如果多出来的文档密级高于该用户权限，说明文档密级标注或空间成员配置有缺口，要回到权限层修正。
建议在检索入口对关闭默认过滤的操作给出提示，并在验证记录中单独记录这类情况，便于区分是过滤问题还是权限问题。
子空间单独设置权限后，上级空间的成员访问不到了，怎么排查？
这是典型的继承覆盖问题。子空间一旦单独配置成员或权限，就可能不再沿用上级空间的成员范围，导致原本通过上级继承获得访问权的人失去入口。
排查时从子空间向上逐层核对成员名单，确认每一层的继承方向是单向继承还是允许覆盖，并把继承关系画进空间成员配置表。修正后重新用受影响角色的账号检索验证一次。
例外授权应该设多长时间，到期后怎么处理？
例外授权按业务需要设定有效期，涉及敏感文档时取较短周期，并在审批记录中写明到期时间。到期后由知识管理员回收权限，需要延续的重新走审批，避免临时授权变成长期默认权限。
例外记录要能按文档和按人两个方向查询，安全/合规角色定期抽查，核对审批理由、审批人和有效期是否完整。
团队规模较小、角色不多时，还需要做完整的三层设置吗？
三层结构仍然适用，但可以简化。角色少时，资产—角色矩阵的格子数量有限，密级档位可以合并，检索过滤项也可以只保留时间与状态两个维度。
需要保留的是分层思路和验证动作：即使只配一层空间权限，也要用不同角色账号检索一次，确认没有越权可见和应见未见，否则后续人员增加时问题会更难定位。
