定义：条目而非文件
知识库的最小单位是可独立引用的条目，例如一条制度、一个故障处置步骤、一段产品参数。文件只是来源，条目才是检索与引用的对象。把整份文档当条目，命中后还要人工读完全文，检索的价值就被抵消。
三层结构
底层是原文与附件，中层是切分后的条目，上层是索引与元数据。三层各有责任人：原文负责准确性，条目负责可读性，索引负责可检索。很多项目只做底层，结果是一个更贵的网盘，问答仍然答不准，用户自然不用。
权限与版本
不同岗位可见范围不同，条目要能在组装阶段按权限过滤。版本决定答案是否有效，旧版必须可追溯但默认不参与检索。缺少版本管理时，新旧内容并存，同一问题会得到两种答案，用户很快不再信任。
更新与责任人
知识会随制度、产品与流程变化而过期，必须有明确的责任人与更新周期。常见做法是每条目标注负责人与复审日期，到期自动提醒；没有责任人的知识库，三个月后就会出现大量过期条目，且无人察觉。
验收看答案
验收不看上传了多少文件，而看一批真实问题能否答对、能否给出出处、答不出时是否明确说不知道。用固定问题集定期抽测，比统计访问量更能反映质量，也更容易向业务证明价值，推动后续投入与扩围。
适用与不适用
适合谁
- 客服、售后、人力、法务等问答集中的部门
- 已有大量文档、但查找与引用困难的企业
- 准备把检索问答接入业务系统的技术团队
不适合谁
- 文档极少、主要靠口头传递经验的团队
- 无人愿意担任条目责任人、也不设复审的项目
典型场景
某物业公司把三百多份制度整理成条目：每条对应一个可回答的问题，标注适用项目、生效日期与责任人。上线后每周抽二十个真实问题测试，答错的补条目或修切分；三个月后转人工比例明显下降，制度更新也能当天生效。
可执行步骤
- 选一个问答需求集中的领域，收集真实问题作为验收样本，并标注出处，同时记录问题来源部门。
- 把文档切成可独立引用的条目，一条只回答一个问题，保留原文链接，便于回溯与核对。
- 为每条标注来源、生效日期、适用范围与责任人，并登记到目录，方便检索与追责。
- 建立索引与权限规则，按岗位过滤可见条目，保存过滤日志，供审计与抽查使用。
- 按固定问题集定期抽测，答错的回补或修正，并记录改进过程，形成可复用的经验。
常见坑
- 把整份文档直接上传就当作知识库，检索命中后仍需人工读完全文，问答价值几乎为零，用户很快放弃。
- 条目没有责任人，制度更新后无人修改，半年后大量答案过期，用户转而私下询问，系统形同虚设，投入也打了水漂。
- 权限一刀切，要么全开放导致敏感信息外泄，要么全封闭导致一线查不到，最后被弃用，还留下审计风险。
- 只统计上传数量与访问量，不看答案是否正确，问题积累到投诉集中出现才被发现，整改已经来不及。
自检与验收清单
- 条目是否可独立引用，并对应明确问题，且能追溯到原文。
- 是否标注来源、生效日期与适用范围，并定期复核。
- 是否指定责任人与复审周期，并留记录，到期有人跟进。
- 是否有按权限过滤的规则与日志，且能逐条复现。
- 是否用固定问题集定期抽测并留结论，按月汇总。
常见问题
知识库和文档管理系统有什么区别？
文档管理解决存与权限，知识库还要解决切分、检索与引用。前者以文件为单位，后者以条目为单位；判断标准很简单：员工提问时，系统能否直接给出可用的那一段，而不是让他自己翻文件。
一定要上向量检索吗？
不一定。条目规范、编号清晰的场景，关键词与结构化过滤往往更准；术语多样、表述不固定的场景才更需要语义检索。常见做法是混合召回，再用重排与规则过滤，单一路径都容易漏。
维护要投入多少人力？
取决于条目数量与更新频率。起步阶段通常由业务骨干兼任，每周固定几小时；条目上千后需要专人负责复审与冲突处理。人力不足时宁可缩小范围，也不要把全公司文档一次入库，否则很快失控。