检查一：接口与权限
选型先确认能否对接现有文档系统、是否支持片段级权限、能否导出索引与评测记录。演示阶段的回答效果容易做得好看，但接口封闭、权限粗放的系统在真实环境无法落地，替换成本极高，往往要推倒重来。
检查二三：盘点与切片
盘点要产出文档清单、负责人、版本与敏感级别；切片要定规则，按条款、按步骤还是按问答对，每片保留来源、章节与生效日期。切片规则不统一会让同一问题召回多段矛盾片段，模型只能挑一段，正确性靠运气。
检查四：评测集先行
配置之前准备真实提问与标准答案，覆盖常见问法、错别字、口语简称与跨文档问题。验收看这批问题的答对率与引用准确率，而不是演示时的精选问题。评测集应版本化保存，供后续调整做回归，避免改一处坏一片。
检查五六：权限与引用
权限检查要看召回阶段是否已过滤无权限片段，而不只是界面隐藏；引用检查要看回答能否定位到源文档的具体章节。二者决定回答能否被审计，缺一项，业务部门都不敢把它放到对外场景，只能停在内网试用。
检查七八：接管与运维
接管机制包括低置信度转人工、敏感问题拦截与用户反馈入口；运维包括更新触发、过期下线、月度抽检与故障响应。上线不是终点，这两项决定半年后的可用性，应在验收时一并检查，而不是留到运维合同再谈。
适用与不适用
适合谁
- 正在推进知识库项目的项目经理与 IT 负责人
- 需要一套可对照验收口径的业务部门
- 已完成选型、正准备组织验收的团队
不适合谁
- 只需要一次演示、不打算长期运维的团队
典型场景
某集团在知识库上线前组织验收会，逐项对照八项检查，发现权限只在界面做了隐藏、召回阶段并未过滤，引用只到文档不到章节。两项被列为整改项，补齐后重跑评测集，答对率与引用准确率才达到业务部门认可的水平。
可执行步骤
- 按检查表逐条确认负责人与证据材料，缺项记为整改项并限期关闭，在周会通报
- 完成文档清单、负责人、敏感级别与生效日期登记，形成可查台账供审计调阅
- 确定切片规则并在样例文档上试切，比对各段是否成义、来源可溯，记录试切结论
- 整理真实提问评测集，记录基线答对率与引用准确率，作为后续回归的对照基线
常见坑
- 把演示效果当验收结论，没有跑真实提问集；上线后答非所问，返工成本远高于前期补测，团队也会失去耐心。
- 切片规则临时决定，同一主题切法不一致；召回多段矛盾内容，回答随机，复核也无法判断对错，改一处坏一片。
- 权限只在界面隐藏，接口仍可召回全文；存在越权泄露风险，内部审计很难通过，上线也可能被叫停。
自检与验收清单
- 选型是否验证过接口开放性、片段级权限与数据导出能力
- 文档清单是否含负责人、敏感级别、生效日期与状态
- 切片规则是否在样例文档上试切并通过复核留档
- 接管规则、抽检节奏与责任人是否已经确定并公示
常见问题
八项检查必须全部通过才能上线吗？
建议前六项必须通过，第七、八项可先以最小版本上线并在灰度期补齐，但要写明补齐时间与责任人。权限与引用两项不建议打折，它们直接决定回答能否被审计，也是内审最先抽查的位置。
评测集要多少条才够？
没有固定条数，关键在覆盖：常见问法、错别字与简称、跨文档组合、无答案问题各占一定比例。建议从真实工单与咨询记录中抽取，先跑基线，再按错误类型逐步补充，而不是一次写满。
上线后还要继续用清单吗？
要。清单应转为月度自检表，重点看新增内容是否按规范切片、过期条目是否下线、接管率是否异常上升。把清单留在项目文档里不再使用，是知识库退化的常见起点，通常半年后才被发现。