知识库建设验收的对象是建设交付物本身：目录结构、内容迁移、权限配置、检索体验、维护流程和移交材料是否按规划完成。建议在内容迁移与结构搭建完成后、正式开放使用前，由知识库负责人、内容责任人、IT或平台管理员、业务使用方代表共同核对。验收按“内容与结构—权限与安全—检索与可用—流程与责任—交付与移交”五个阶段推进，每项写明通过标准、证据和负责人；阻断项未通过，整体不予放行。持续使用成效归运营评估，平台采购归工具选型，均不在本文范围。
要点总览（TL;DR）
- 验收对象是建设交付物本身，使用时点在内容迁移与结构搭建完成后、正式开放使用前，由知识库负责人、内容责任人、IT或平台管理员、业务使用方代表共同核对。
- 检查按内容与结构、权限与安全、检索与可用、流程与责任、交付与移交五个阶段推进，每项写明可观察的通过标准、证据形式和负责人。
- 通过标准要可观察、可复现并有范围界定，证据以截图、抽检记录、测试记录和签字确认单为主，检查人与最终确认人保持分离。
- 核心文档缺失、权限越权、关键检索不可用、文档无责任人属于阻断项，任一未通过整体结论不能为通过。
- 整体结论分为通过、有条件通过、不通过三种，非阻断项须写明整改责任人与期限，到期复检后关闭。
谁在什么时点使用这份验收清单
这份清单服务于建设阶段的放行决策，使用时点是内容迁移和结构搭建完成之后、面向全员正式开放之前。此时知识库已具备可检查的实体：文档已入库、目录已搭好、权限已配置、流程已试跑，验收人员可以逐项核对并留下证据。若在建设尚未完成时使用，大量检查项会因对象不存在而无法判定；若在开放使用数月后才补做，发现的问题已经影响使用者，整改成本更高。
验收参与角色按职责分工，不按部门层级分配。下表给出各角色在验收中的位置和主要动作，实际执行时可按团队规模合并角色，但检查人与最终确认人应保持分离。
| 角色 | 参与时点 | 主要职责 |
|---|---|---|
| 知识库负责人 | 全过程 | 组织验收、汇总结果、判定整体结论、签署移交确认 |
| 内容责任人 | 内容与结构、流程与责任阶段 | 确认本人负责文档的完整性、字段填写与维护责任 |
| IT或平台管理员 | 权限与安全、检索与可用阶段 | 提供权限配置记录、账号处理规则、检索与入口测试环境 |
| 业务使用方代表 | 检索与可用、交付与移交阶段 | 用真实业务问题执行检索任务，确认培训与反馈渠道可用 |
范围界定需要在验收启动会上讲清楚：本次只核对建设交付物是否按方案完成，不评估上线后的访问量、搜索满意度等运营指标，也不讨论是否更换平台或追加采购。把这三类事项分开，验收结论才能聚焦在“能不能交给使用方”这一个问题上。
第一阶段：内容与结构检查项
内容与结构阶段回答“该有的内容是否都在、放的位置是否正确”。检查以规划方案为基准逐项比对，不以检查人的主观判断为准。目录层级、分类名称、文档归属与规划文档不一致的，记为不符合项并登记差异原因。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 目录层级与分类 | 一级、二级目录数量与名称和规划方案一致，差异项均有书面说明 | 目录截图与规划方案对照表 | 知识库负责人 |
| 计划迁移文档到位 | 迁移清单内文档全部入库，缺失文档逐条登记并注明原因与补交时间 | 迁移清单核对记录 | 内容责任人 |
| 必填字段完整 | 每篇文档具备标题、责任人、更新时间、所属分类；抽检样本字段完整率100% | 抽检记录（建议按分类各抽若干篇） | 内容责任人 |
| 重复、过期、草稿内容 | 重复文档已合并或标注，过期文档已移入归档区，草稿未出现在正式目录 | 隔离或标注清单 | 内容责任人 |
抽检样本要覆盖每个一级分类，避免只查文档最多的分类。必填字段中“更新时间”应反映内容最近一次实质修改，迁移时批量导入产生的日期需要在验收说明中注明，防止使用方误判内容新旧。缺失文档清单是后续复检的依据，登记时写清责任人和计划补交日期，比只写“待补”更便于跟踪。
第二阶段：权限与安全检查项
权限与安全阶段核对访问控制是否按规划落地。检查方式以逐组验证和抽检为主：用不同角色账号实际访问，确认能看到该看的、看不到不该看的。仅查看后台配置页面不足以证明权限生效。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 角色与权限分组 | 规划中的角色全部建立，每个角色抽取账号实际访问，可见范围与规划一致 | 逐组验证记录（角色、账号、预期可见范围、实际结果） | IT或平台管理员 |
| 敏感或受限文档 | 受限文档清单内每篇均设置访问范围，非授权账号访问被拒绝 | 受限文档清单与访问测试截图 | IT或平台管理员、内容责任人 |
| 外部共享与导出 | 外部分享、批量导出按规划开启或关闭，开启项有审批或记录机制 | 共享与导出配置截图、审批记录样例 | IT或平台管理员 |
| 离职、转岗账号处理 | 账号停用、权限回收、内容交接的处理规则已写入制度并有执行记录 | 规则文档与近期处理记录 | IT或平台管理员 |
逐组验证时优先选择权限边界最复杂的角色，例如跨部门可见但排除特定分类的岗位。受限文档的抽检应包含附件和图片，确认访问限制覆盖文档正文之外的载体。账号处理规则要写明触发来源，例如由人事流程触发还是由管理员定期核查，并保留至少一次实际处理记录作为规则可运行的证据。
第三阶段：检索与可用性检查项
检索与可用阶段用可复现的任务验证查找体验。验收前由业务使用方代表准备一组典型检索词，覆盖高频业务问题、专有名词和易混淆概念，每个检索词写明预期命中的目标文档。验收时现场执行并记录实际结果，命中位置、排序和跳转链接一并记录。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 典型检索词命中 | 预设检索词中达到约定命中率的任务，目标文档出现在结果首页或前若干条 | 检索任务测试记录（检索词、预期结果、实际结果） | 业务使用方代表 |
| 分类浏览与标签筛选 | 按分类逐级浏览可到达目标文档，标签筛选结果与文档标注一致 | 浏览路径截图 | 业务使用方代表 |
| 文档内链接、附件、图片 | 抽检文档中的内部链接可跳转，附件可下载打开，图片正常显示 | 抽检记录与异常清单 | 内容责任人 |
| 常用入口访问 | 移动端或企业常用入口可正常打开知识库并完成一次检索 | 入口访问截图 | IT或平台管理员 |
命中率标准在验收前约定，例如“预设检索任务中目标文档进入结果前五条的比例不低于约定值”，避免验收现场临时争论排序是否合理。未命中的任务要区分原因：文档缺失、标题与检索词表述差异、检索配置问题，分别转给对应责任人处理。文档内链接抽检应覆盖迁移过程中格式转换过的文档，这类文档出现断链的概率较高。
第四阶段：流程与责任检查项
流程与责任阶段确认维护机制已经建立并能运行。检查不看流程图是否画得完整，而看流程是否配置到系统中、是否完成至少一次试跑、试跑产生的记录是否可查。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 文档责任人指定 | 正式目录内每篇文档均有责任人，责任人清单与文档字段一致 | 责任人清单与抽检对照 | 知识库负责人 |
| 新建、更新、归档流程 | 三类流程均已配置，各完成至少一次试跑并产生可查记录 | 流程试跑记录 | IT或平台管理员 |
| 评审或审核触发条件 | 需评审的文档类型、触发条件、审核人已写明，试跑中至少触发一次 | 评审规则文档与触发记录 | 知识库负责人 |
| 责任人变更交接 | 交接方式写明（谁发起、谁接收、文档字段如何更新），并有样例 | 交接规则与样例记录 | 知识库负责人 |
试跑要使用真实文档而非测试数据，这样能暴露字段必填、审核人缺失等实际问题。责任人清单建议按分类导出后与文档字段逐一比对，重点检查多人共管的分类是否存在无人负责的文档。交接规则中应明确原责任人在离职或转岗前完成文档移交，接收人确认后才更新文档字段，避免出现责任真空期。
第五阶段：交付与移交检查项
交付与移交阶段面向接手方，核对对方能否在不依赖建设人员的情况下独立使用和维护知识库。检查以接手方实际操作为准：管理员完成一次权限配置，内容责任人完成一次文档更新，业务使用方通过反馈渠道提交一次问题。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 交付文档齐全 | 建设方案、配置说明、操作手册齐备，内容与当前系统状态一致 | 交付物清单 | 知识库负责人 |
| 培训或交接说明 | 管理员与内容责任人完成培训，接手方独立完成一次规定操作 | 培训签到或交接说明、操作记录 | IT或平台管理员 |
| 问题反馈渠道 | 反馈入口、受理人、响应时限已公布，提交测试问题后有人受理 | 渠道截图与受理记录 | 知识库负责人 |
| 遗留问题清单 | 未完成事项逐条登记，含影响说明、责任人和计划完成时间，接手方确认 | 遗留问题清单与确认签字 | 知识库负责人 |
配置说明要写到可复现的程度，例如权限分组如何新增、流程节点如何调整，而不是只描述系统有哪些功能。遗留问题清单需要接手方确认，确认动作本身即表示对方知晓风险并接受后续处理责任。反馈渠道的测试问题应真实提交并跟踪到关闭，仅公布一个邮箱地址不足以证明渠道可用。
通过标准、证据与负责人如何对应
每项检查要能判断“完成”或“未完成”，写法上满足三个条件：可观察，即检查人能看到具体对象或结果；可复现，即换一个人按同样步骤能得到相同结论；有范围界定，即写明抽检比例、覆盖分类或命中数量，避免“基本完整”“大体可用”这类无法判定的表述。例如“必填字段完整”写成“每个一级分类抽检不少于约定篇数，字段完整率100%”，就比“字段填写规范”更容易执行。
证据形式与检查项匹配，常见四类：截图用于配置状态和界面结果；抽检记录用于内容完整性与字段核对；测试记录用于检索任务和访问验证；签字确认单用于移交和遗留问题确认。证据由检查人当场留存，注明日期和检查人，附在对应检查项下，复检时可直接比对。
| 分工 | 由谁担任 | 动作 |
|---|---|---|
| 检查人 | 对应阶段的责任角色 | 执行检查、留存证据、填写结果 |
| 复核人 | 知识库负责人或指定交叉角色 | 抽查证据真实性，确认判定口径一致 |
| 最终确认人 | 知识库负责人 | 汇总各阶段结果，判定整体结论并签署 |
不通过项当场记录，写明检查项、实际情况、责任人和整改期限，整改完成后由原检查人复检并补充证据。复检只针对不通过项及其关联项，不重复全量检查。验收项、证据和整改状态可以落到统一的工作项或文档状态中跟踪，ONES 支持将检查项建为工作项、关联文档并记录责任人与状态流转，便于在复检时按状态筛选未关闭事项；具体配置方式按团队实际使用情况确定。
阻断项与整体完成条件
阻断项是必须通过才能放行的检查项，任一项未通过，整体结论不能为通过。典型阻断项包括：计划迁移的核心文档缺失且无补交计划；存在权限越权，非授权账号可访问受限文档；关键检索任务不可用，业务使用方无法找到高频文档；正式目录内存在无责任人的文档。阻断项的判定在验收启动时确认并写入清单，验收过程中不临时扩大范围。
非阻断项按整改期限处理，例如字段个别缺失、少量断链、培训材料待补充。每项写明整改责任人和完成日期，到期后由检查人复检。整改期间知识库可限定范围开放，或按团队约定延后开放，具体安排由知识库负责人决定。
| 整体结论 | 判定条件 | 后续动作 |
|---|---|---|
| 通过 | 阻断项全部通过，非阻断项全部通过或已完成整改 | 签署移交确认，按计划开放使用 |
| 有条件通过 | 阻断项全部通过，非阻断项存在未完成项但均有明确整改期限和责任人 | 限定范围开放，到期复检并关闭整改项 |
| 不通过 | 任一阻断项未通过 | 不开放使用，整改后重新验收相关阶段 |
验收结论形成后，移交确认单与遗留问题清单一并交给接手方，运营阶段的访问数据、搜索满意度和内容更新频率另行评估，不并入本次验收结论。若后续发现验收范围内的问题，按反馈渠道登记并追溯对应检查项，作为下一轮建设或整改的输入。
常见问题
建设验收和上线后的运营评估应该怎么分开做？
建设验收在正式开放使用前完成，核对的是目录结构、内容迁移、权限配置、检索体验、维护流程和移交材料是否按规划交付，结论是“能不能交给使用方”。运营评估在上线后按周期进行，关注访问量、搜索满意度、内容更新频率等使用成效。两类工作分开的好处是验收结论不受使用数据波动影响，运营问题也不会被误判为建设缺陷。若上线后发现属于验收范围内的问题，按反馈渠道登记并追溯对应检查项，作为下一轮整改的输入。
团队规模较小，验收角色可以合并吗？
可以合并，但检查人与最终确认人应保持分离。小团队中知识库负责人可能同时承担内容责任人和平台管理员的职责，此时检查动作仍要逐项执行并留存证据，最终确认由另一位成员或业务使用方代表签署。角色合并后要特别注意权限与安全阶段的逐组验证，避免配置人和验证人是同一人而漏掉越权问题。合并情况在验收启动会上说明并记录，便于后续追溯。
非阻断项整改期间，知识库可以先开放吗？
可以按团队约定限定范围开放，前提是阻断项已全部通过。开放范围、开放对象和整改期限由知识库负责人决定，并在验收记录中写明。整改期间未完成项保持跟踪状态，到期由原检查人复检并补充证据。若整改涉及权限或核心内容，建议先对相关分类保持关闭，待复检通过后再放开，避免使用方接触到未完成配置的内容。
检索命中率这类量化标准应该在什么时候确定？
在验收启动前由知识库负责人与业务使用方代表共同约定，写入验收清单，验收现场只执行不争论。约定内容包括典型检索词的数量与来源、目标文档应出现的位置范围、未命中任务的分类处理方式。标准要结合知识库的实际内容规模设定，避免照搬其他团队的数字。验收中未命中的任务区分文档缺失、表述差异和检索配置三类原因，分别转给对应责任人，复检时只重测未通过的任务。
验收通过后，遗留问题由谁负责跟进？
遗留问题清单在移交时由接手方确认签字，确认即表示对方知晓风险并接受后续处理责任。清单中每项写明影响说明、责任人和计划完成时间，跟进责任随移交转到运营侧。知识库负责人在移交后仍可保留清单副本，用于下一轮建设或整改的输入。若遗留问题涉及阻断项关联内容，需要重新走对应阶段的验收，不能仅作为普通整改项关闭。
