先看结论
- 团队知识库 90% 的问题不是技术问题：找不到、不确定是不是最新、不知道该信谁。
- 五件事必须先定：命名、目录、权限、版本状态、责任人。工具排在第六。
- 目录按「谁用」分，不按「谁存」分；超过三层基本没人维护。
- 权限默认最小：写权限按角色给，读权限按项目给，别用「全员可见」当默认。
- 上线节奏：第 1 周盘点、第 2 周定规范、第 3 周只试点一个部门，别全公司一起上。
为什么先定规范，而不是先买工具
换工具的迁移成本很低，规范的迁移成本很高。先把规范定下来，工具随时能换；先买工具，规范会被工具的默认设置绑架——比如默认「全员可编辑」，三个月后你会发现没人知道哪份是最新版。
一页纸规范（可直接贴进团队文档）
1. 命名：四段式
[分类]-[主题]-[版本]-[日期] 例：制度-差旅报销-v3-20261101 例：方案-客户A-投标技术方案-v1-20261030
分类用固定枚举（制度/方案/模板/会议/研究），主题用业务词，版本只写主版本，日期写 YYYYMMDD。命名不写作者名字——人走了文件还在。
2. 目录：三层上限，按使用场景分
01-制度流程/ 给全员看的规则 02-项目资料/ 按项目编号分 03-模板工具/ 拿来就用的 04-知识沉淀/ 复盘、案例、方法论 99-归档/ 过期但不删的
不按部门分（部门会变），不按文件类型分（用户找的时候想的是「我要干什么」）。超过三层的目录，第四层开始就没人维护了。
3. 权限：默认最小
| 角色 | 写 | 读 |
|---|---|---|
| 负责人 | 本目录全部 | 全部 |
| 部门成员 | 本部门目录 | 本部门 + 公共 |
| 其他同事 | 只读申请 | 公共 + 授权项目 |
| 外部 | 无 | 无（要分享走导出） |
4. 版本状态：只有两种
每份文档头部标 status：active（现行）/ archived（归档）。不做「v1、v2、v3 并存」——旧版本移入 99-归档 并在头部标 archived，AI 检索时只召回 active。这一条能消掉一半「答了旧制度」的问题。
5. 责任人：一份文档一个人
每份文档写 owner 和 review_date。没有 owner 的文档，三个月后就是孤儿。复核周期：制度季度、方案项目结项、模板半年。
落地节奏：三周，别全公司一起上
| 周次 | 动作 | 产出 |
|---|---|---|
| 第 1 周 | 盘点：现有文档在哪、有多少、谁在用 | 一张清单 + 三个最痛的问题 |
| 第 2 周 | 定规范：上面五项写成团队文档并评审 | 一页纸规范 + 命名模板 |
| 第 3 周 | 试点：选一个部门，迁移 50 份核心文档 | 试点部门的 20 题测试结果 |
| 第 4 周起 | 复盘 + 推广；每周 30 分钟维护会 | 月度更新日志 |
上线检查清单（10 条）
- 命名规范已写进团队文档，且有人抽查
- 目录不超过三层，且没有「其他」目录
- 每份核心文档都有 owner 和 review_date
- 文档头部有 status，过期内容已标 archived
- 权限不是默认全员可编辑
- 有一个「唯一入口」，不是三个群各发一份
- 试点部门能用 20 题测出自测分数
- 有明确的维护会议和时长（建议每周 30 分钟）
- 有反馈入口：发现错误找谁
- 有淘汰机制：多久没人用就归档
一个反常识建议
先做「删」再做「建」。团队知识库里 30%–50% 是过期或重复内容；把它们归档出去，比新增 100 份文档对问答质量的提升更大。
相关
选型分析知识库搭建：ima / 乐享 / Dify / RAGFlow / 本地 Markdown，8 个方案怎么选查看 →自测表20 个问题，测出你的知识库哪一层有病查看 →服务知识库诊断：先测 20 个问题，再决定要不要重做查看 →发现错误或有补充？提交纠错；这个频道会持续更新。
最后更新：2026-11-01