清单比系统更重要
验收时最常缺的是知识清单：哪些文档入库、责任人是谁、生效日期与适用范围。没有这份清单，系统里有多少内容、哪些已过期都说不清。怎么补？要求交付方提供可筛选清单，并与入库记录逐条对得上。
元数据要支撑过滤
部门、业务线、文档类型、密级、生效日期这五类字段，决定检索能怎么收窄范围。字段缺失时，用户只能用关键词碰运气；字段齐了才谈得上按权限与时效过滤，后续运营也有可分析的维度，问题定位也更快。
评测集必须可复跑
验收不看一次演示，而看同一批问题在新旧版本上的对比。评测集应包含问题、期望要点、来源文档与判定结论，任何人拿到都能复跑。边界是评测集由客户业务方确认，交付方不能既出题又判卷，否则结论不可信。
越权测试单独做
验收环节要专门测越权：用低权限账号提一个只有高权限文档才能回答的问题，看系统是拒答、返回公开内容，还是泄漏原文。怎么算通过？答案中不得出现受限文档的原文、标题与可推断的细节，也不能给出可反推的线索。
适用与不适用
适合谁
- 准备把知识库写进采购或交付合同的企业
- 需要向管理层说明投入与验收边界的项目负责人
- 多部门参与、责任容易模糊的建设项目
不适合谁
- 只做个人笔记整理、不涉及多部门协作的场景
典型场景
某集团在确认单里把交付物拆成七项，验收时由信息中心与业务部门分工：信息中心测权限与日志，业务部门抽两百条提问核对答案与来源。越权测试用门店账号查询总部合同条款，系统返回公开制度并提示无权限，该项通过。
可执行步骤
- 在确认单列出七类交付物，并逐项写明责任人与验收方法
- 约定抽检比例与评测集的确认方，并明确由业务方判定对错
- 设计越权测试用例，覆盖三个权限层级与两类敏感文档类型
- 把更新责任与响应时限写入运维条款，并约定季度核对方式
常见坑
- 验收只看演示问答、不做抽检，上线后发现大量文档未入库或版本过期，责任难以界定，返工也没有基线。
- 评测集由交付方单方编写，题目偏简单，真实提问下命中骤降，返工又没有可依据的基线。
- 不测越权，低权限账号能问出合同条款，事故发生后才发现权限只在界面层做了限制，整改要重建索引。
自检与验收清单
- 交付物是否逐项对应责任人与验收方法
- 知识清单能否与入库记录逐条对上
- 评测集是否由业务方确认并可复跑
- 越权测试是否覆盖多个权限层级与角色
常见问题
验收要不要约定准确率数字？
不建议在合同里写死比例，因为口径不同结果差异很大。更稳的做法是约定抽检方法与判定规则，由双方共同抽样评估，并作为版本对比的基线，而不是一次性的合格线，也便于后续比对。
交付物里为什么要运营手册？
知识库的失效主要来自无人维护。手册要写清更新流程、责任人、评审方式与常见问题处理，让接手方在交付方离场后仍能独立运行，这也是能力转移的凭证，验收时应一并归档。
可以只验收系统功能吗？
不建议。功能验收通过而知识质量不达标，系统仍会被业务弃用。至少同时验收知识清单完整性、评测集结果与更新机制三项，三者缺一都可能在上线三个月内暴露问题，返工也更贵。