第一步：场景与问题集
先选一个问答需求集中的领域，收集五十到一百条真实问题作为验收样本，并标注标准答案与出处。问题集决定后续所有判断，选错领域会让项目看起来做了很多却没有业务感受；宁可从最痛的一个场景开始。
第二步：盘点与定责
列出该领域的文档清单，标出有效版本、适用范围与责任人。重复、过期、无出处的文档要先处理，不能直接入库。盘点阶段通常能发现大量冲突条款，这些冲突不解决，条目化只会把矛盾原样搬进系统。
第三步：条目化入库
按条款、步骤或问答对切分，一条只回答一个问题，标注来源、生效日期与权限。切分粒度要试：太粗检索不准，太细缺少上下文。入库后先做小范围检索测试，确认能命中正确条目再继续批量处理，否则返工量很大。
第四步：评测与运营
用第一步的问题集抽测，记录答对率、出处正确率与转人工比例，按错误类型回补条目或修正切分。运营包括月度复审、到期提醒与冲突处理；没有运营的知识库会在半年内退化，重新回到查不到、不敢用的状态。
验收与边界
验收看三项：常见问题能否答对并给出出处、超出范围是否明确说不知道、条目是否能按权限正确过滤。不承诺具体答对率，但抽样方法与判定标准要事先写清；知识内容的准确性由业务方责任人确认，技术方不替代业务判断。
适用与不适用
适合谁
- 客服、售后、人力等问答需求集中的企业，且有专人负责
- 已有文档沉淀、但检索与引用困难的企业
- 愿意指定条目责任人并定期复审的业务部门
不适合谁
- 文档极少、也无稳定问答需求的团队
- 无人愿意承担内容准确性与复审的项目
典型场景
某三甲医院的后勤知识库先从设备报修做起：收集八十条真实问题，盘点两百份文档并标出有效版本，按故障现象切成条目，标注责任科室与生效日期。上线后每周抽测，答错的补条目，三个月后才扩展到采购与安保，并留抽测记录。
可执行步骤
- 选一个问答集中的领域，收集真实问题并标注标准答案与出处，同时记录提问部门。
- 盘点文档清单，标出有效版本、适用范围与责任人，先处理冲突，再进入条目化。
- 按条款或问答对切分入库，标注来源、生效日期与权限，再做小范围试检索
- 用问题集定期抽测，按错误类型回补条目或调整切分，并留记录，形成回归用例。
常见坑
- 跳过问题集直接入库，做完不知道是否好用，只能靠访问量判断，问题被数据掩盖，方向也难调整，团队失去信心。
- 把冲突条款原样搬进系统，问答给出两种口径，用户不知道该信哪条，反而增加沟通成本与投诉，客服疲于解释。
- 切分过细，一条只有一句话，缺少前提条件，模型拼不出完整答案，答复前后矛盾，用户反复追问，信任下降。
- 上线后无人复审，制度更新了条目没改，半年后错误集中爆发，只能整体停用重建，前期投入白费，也很难交接。
自检与验收清单
- 是否有真实问题集与标准答案，标注出处并定期更新。
- 文档是否标出有效版本与责任人，并留复审日期。
- 条目是否带来源、生效日期与权限，并可按权限过滤。
- 是否定期抽测并回补条目，留调整记录，并且有责任人。
常见问题
需要一次把所有文档入库吗？
不建议。全量入库周期长、质量难控，且大量低频文档会稀释检索效果。按场景分批推进，每批都跑问题集验证，效果稳定后再扩；这样即使中途停止，也已交付可用的一部分，风险更可控。
条目切多细合适？
以能独立回答一个问题为准，通常一段到一页。太粗检索命中后还要人工找段落，太细则缺少前提。可以用同一批问题测试不同粒度，看命中率与答案完整度，再定标准并写进规范。
答错了怎么修？
先分因：是没检索到、检索到错误版本，还是条目本身写错。前者调索引与过滤，后者改条目并通知责任人。每次修复都记录到问题集，形成回归用例，避免同类问题反复出现，也便于交接。