基于自有资料回答的工具，权限设置直接决定两件事：答案质量和资料安全。谁能问哪个库、谁能改哪份文档，都要按部门边界划清。常见的问题是所有资料倒进同一个库——研发的问题引出了财务制度的回答，答非所问，还顺带把不该看的内容带了出来。
按部门建库，不按文件建库
起点是按使用场景建库：每个部门或每类业务一个库，库内放该业务的文档。判断标准是「回答时允许引用哪些资料」——同一库内的资料允许互相引用，不同库之间默认互不可见。
跨部门都要用的内容（公司制度总纲、员工手册）单独建公共库，避免复制多份造成版本漂移。库的粒度别太细，太细维护成本翻倍；也别太粗，一粗隔离就失效。
一个常被忽略的点：库级权限挡不住文档级敏感内容。含薪酬结构、客户名单、未公开报价的表格，即便放在部门库里，也可能被引用进答案。这类文档直接不进库，另走线下流程，比事后追权限可靠。
权限分层，先想「谁不该看到」
角色通常分三层：管理员（建库、上传与删除文档、配置权限）、成员（可以提问并获得基于库内资料的答案）、只读或受限成员（视版本支持，仅查看或不能提问）。
配置顺序有个讲究：先盘点「谁不该看到」，再配「谁可以看到」。前者逼你把库里的敏感内容找出来单独安置，后者只是日常授权操作。顺序反了的典型症状是先建一个大库人人可问，等出了问题再翻记录，追不回来。
还有一条容易跳过的原则：知识库权限要和源文档权限保持同一水位。源文档只给三个人看的，问答库里也别开放给整个部门——两边水位差迟早出事。这条和浏览器插件的权限逻辑是相通的，见插件的权限怎么看。
验证隔离有没有真的生效
配置完不要想当然，用三个测试验证：
| 测法 | 怎么做 | 看什么 |
|---|---|---|
| 越权提问 | 拿只属于 A 部门的问题，问 B 部门的成员 | 是否拒绝，或明确说明资料不足 |
| 引用来源 | 问一个跨库都涉及的词 | 引用是否只来自该成员有权访问的库 |
| 管理员对照 | 用管理员账号问同一句话 | 两者答案的差异是否合理 |
三个测法都过，隔离才算落地。用例存档，每次调整权限后重跑一遍，别凭印象认为「应该没问题」。
日常维护的三件事
文档更新。部门制度改版后旧版必须下架，否则问答会混引新旧版本——员工照旧版办事的麻烦，比权限问题更难收场。
人事变动。人员转岗或离职当天处理权限，别等季度清理。这一条和账号管理是一回事，见多个 AI 工具怎么管理。
看问答记录。定期抽查回答有没有引用不该出现的资料，发现即回查权限配置。知识库是活的，维护节奏决定它的可信度。
另外留一份快照：把当前的库结构、成员与权限导出或截图存档。半年后对比这份快照，多余授权与遗忘的临时权限一眼可见——尤其是给外部合作方开过的临时权限，项目结束后极其容易被忘掉。
知识库权限速查
- 按部门建库，公共内容单独建公共库
- 含薪酬、客户名单的文档不进库
- 先想「谁不该看到」，再配「谁可以看到」
- 库权限与源文档权限保持同一水位
- 三个测法：越权提问、引用来源、管理员对照
- 制度改版下架旧版，人事变动当天调权限
常见问题
- 误把敏感文件传进大库了，怎么补救？立刻删除该文档，再查问答记录里是否已被引用，必要时通知相关成员，然后把「上传前审核」加进流程。删除只是第一步，引用过就等于已经泄露过一次。
- 公共库和部门库内容重复怎么办？制度类内容留在公共库做单一来源，部门库只放该部门的执行细则。两处都放，必然出现版本打架。
- 外部合作方要用，权限怎么给？单独立库，只放可对外内容，按项目授权并设有效期，合作结束当天回收，不要往内部库里加人。
更多工具规范在AI 工具教程栏目。
信息来源
- 本文为知识库权限设计与验证方法整理，三层角色划分与隔离测法依据通行的权限管理实践，核对时间 2026 年 11 月；
- 具体产品的角色名称、成员上限与日志能力以其当前版本为准，本文不作承诺。
