误区一：当网盘
把知识库理解成能搜文件的地方，于是比较的是支持多少格式、能存多少文档。为什么危险：业务要的是答案与依据，不是文件列表。替代做法是先统计高频问题与重复率，用问题驱动选型，而不是用存储容量驱动。
误区二：只看演示
演示题目通常由供应商准备，文档干净、问题标准。怎么识别：要求用你提供的一份脏文档与三个刁钻问题现场作答，看它是否承认找不到依据。愿意当场说不知道的产品，通常比全都能答的更可靠。
误区三：忽略权限
权限只做到部门级，离职与调岗不会自动收敛，越权检索往往在试用期之后才出现。为什么难发现：演示账号权限最大。做法是现场演练一次调岗与一次跨部门访问，看检索结果是否随权限即时变化。
误区四：导入即完成
文档导入只是开始，切分方式、标题层级、表格与附件的处理决定检索质量。边界在于扫描件与图纸需要单独管线，直接导入通常只得到一堆无法定位的文本。选型要问清各类文档的处理方式与人工干预手段。
误区五：不管更新
制度换版、人员调整、产品迭代都会让旧内容失效。没有更新责任人与失效标记，知识库半年后就开始给出过期答案。怎么补：在合同里约定内容运营角色、更新频率与失效内容的处理流程，并指定复核人。
适用与不适用
适合谁
- 制度多、更新快、跨部门访问复杂的企业
- 准备在选型会上做真实文档测试的团队
不适合谁
- 只想买一个文档存储与全文搜索工具的单位
典型场景
某物业集团试用三款知识库，前两轮演示都很顺。信息部改为自带文档：一份扫描版巡检标准、一份刚换版的收费制度，再加三个跨项目权限问题；两款产品在扫描件与越权检索上暴露问题，第三款因能拒答并标出出处进入下一轮。
可执行步骤
- 统计近三个月的高频问题、重复率与平均查找时间，确认知识库要解决的问题
- 准备一份扫描件或格式混乱的文档，外加三个没有标准答案的刁钻问题并指定验收人
- 现场演练调岗、跨部门访问与制度换版三个动作，观察检索结果如何变化，形成书面记录
- 把内容运营角色、更新频率与失效内容处理写进合同附件，并指定复核人，逐项确认后归档
常见坑
- 评审只看回答是否流畅、不问出处与依据，容易选中会编造引用的产品，上线后无法复核，也无法追责。
- 权限只做部门粗粒度，试用期又只用管理员账号，越权问题要到上线后才暴露，整改代价很高且影响信任。
- 把文档导入数量当验收指标，切分质量与元数据没人检查，检索效果长期不达标却找不到原因，也无法验收。
- 没有内容运营岗，制度换版后无人更新与下线，回答继续引用旧条款，业务逐渐不再使用，投入难以回收。
自检与验收清单
- 是否用自家真实文档而非供应商样例做现场测试
- 试用账号是否按真实岗位与部门权限逐项配置，并指定负责人
- 是否现场验证调岗、跨部门访问与制度换版三类动作
- 内容运营责任人、更新频率与失效处理是否落纸，注明依据
常见问题
五个误区哪个最难发现？
权限与更新最难发现，因为演示阶段几乎不会暴露。建议把这两项做成试用期的必测动作：调岗后检索结果是否变化、旧版制度是否会被引用，测完再打分，也便于后续复测与调整。
开源知识库能不能避开这些问题？
不能。开源产品同样需要切分管线、权限映射与内容运营，只是把这些工作交回内部。若团队缺少检索调优与运维经验，问题会更晚暴露，建议先做小范围技术验证再扩大范围。
文档很少要不要上知识库？
要看问题重复率。文档少但同类问题反复出现，仍可能值得做；文档多而问题零散，则更适合先做目录与搜索优化。判断依据是查找耗时与回答一致性，不是文档总量，也别把知识库当唯一入口。