知识库建设验收标准要围绕内容、结构、权限、流程、可用性五类对象拆成可核验的检查项，每项写明通过标准、证据形式、负责人和检查时点，并把影响上线的事项标为阻断项。验收按准备、内容迁移、试运行、正式上线四个阶段推进，每个阶段只判定本阶段能验证的内容。下面给出可直接使用的分阶段检查清单。
要点总览（TL;DR）
- 验收标准按内容、结构、权限、流程、可用性五类对象拆成检查项，每项写明通过标准、证据形式、负责人和检查时点。
- 验收分准备、内容迁移、试运行、正式上线四个阶段，每阶段只判定本阶段能验证的内容，使用成效留到运营阶段评估。
- 通过标准要写成可判断的句子，包含数量阈值、抽样结果、签字确认或系统记录中的至少一种，判定结果分通过、有条件通过、不通过三档。
- 核心知识缺失、越权访问、关键流程未跑通、无责任人内容占比过高属于阻断项，须在上线前清零；一般项可带整改计划上线。
- 上线以书面放行确认单为准，遗留问题转入运营跟踪并回填原验收记录，形成闭环。
谁在什么时点使用这份验收清单
验收清单要落到具体角色，否则容易变成建设方自查、业务方事后追认。建议在项目启动会上就确定四类参与角色，并明确每类角色在验收中的动作。
| 角色 | 主要职责 | 在验收中的动作 |
|---|---|---|
| 知识库负责人 | 统筹建设范围、进度与验收组织 | 召集检查、汇总判定结果、组织复检 |
| 内容责任人 | 按分类维护本领域知识 | 提供内容清单与抽样样本，确认内容准确 |
| IT或平台管理员 | 平台配置、权限设置、入口接入 | 提供权限配置记录、检索测试环境、访问日志 |
| 业务使用方代表 | 代表实际使用者提出可用性要求 | 参与检索测试，确认常用场景可查可用 |
四个检查时点分别对应：建设准备完成时确认口径，内容迁移完成时检查内容与结构，试运行结束时检查权限、流程与检索，正式上线前做整体放行判定。判定权限建议这样分配：单项通过由该项负责人提供证据、知识库负责人确认；阻断项是否清零由知识库负责人会同业务使用方代表共同拍板，涉及权限与安全的阻断项需IT或平台管理员签字。证据由执行方提供，判定与签字分离，避免同一人既做又判。
准备阶段：先把验收口径定下来
准备阶段的检查对象是标准本身，而不是知识库内容。这一阶段没通过，后面的检查会因口径漂移反复返工。检查项如下：
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 验收范围清单 | 书面列明覆盖的部门、知识类型、系统入口，无“待定”项 | 范围清单文档，业务方签字 | 知识库负责人 |
| 知识分类与命名规则 | 分类层级、标签体系、文档命名规则已书面确认并下发 | 分类规范文档及下发记录 | 知识库负责人 |
| 内容责任人名单 | 每个分类均有指定责任人，更新职责写入岗位说明或责任书 | 责任人对照表 | 各部门负责人 |
| 验收清单确认 | 检查项、通过标准、证据形式经业务使用方代表确认 | 确认邮件或会议纪要 | 知识库负责人 |
范围清单要写清边界，例如覆盖哪几个部门的制度文档、操作手册、常见问题，哪些历史资料不在本期迁移范围。分类规则一旦确认，迁移阶段就按此执行，中途调整需走变更记录，避免验收时各说各话。
内容与结构检查项：知识是否可查、可读、可维护
内容与结构是验收的主体。判定要基于抽样，而不是凭印象。建议先确定抽样方法：按分类分层抽样，每个分类抽取不少于一定数量或一定比例的文档，核心分类全量检查，非核心分类按比例抽查。抽样比例在准备阶段写入清单，验收时不得临时调整。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 存量内容迁移完成率 | 范围内文档迁移完成率达到约定阈值，未迁移项有书面说明 | 迁移清单与系统导出记录 | 内容责任人 |
| 抽样准确率 | 抽样文档中内容准确、与现行制度一致的比例达到约定阈值 | 抽样记录表，逐篇标注结果 | 内容责任人 |
| 分类与标签规范 | 抽样文档的分类、标签、目录层级符合既定规则 | 抽样截图或系统字段导出 | 知识库负责人 |
| 文档基本字段 | 单篇文档具备标题、责任人、更新时间、适用范围等字段 | 字段完整性统计 | IT或平台管理员 |
| 重复与过期内容处理 | 重复文档已合并或标注，过期文档已下架或标记失效 | 处理清单及处理前后对照 | 内容责任人 |
| 无主内容处理 | 无责任人文档占比低于约定阈值，其余已指定责任人 | 无主内容清单及补录记录 | 知识库负责人 |
抽样记录要能回溯：记录抽样规则、样本编号、检查人、检查日期和单篇结论。准确率不达标时，按分类退回整改，整改后对同一分类重新抽样，而不是只复检原样本。
权限、流程与可用性检查项
这三类对象容易被漏检，却直接决定上线后能否放心使用。权限检查要覆盖部门、角色、文档密级的对应关系，逐条验证而非只看配置页面。流程检查要求发布、修订、下架各跑通至少一轮真实操作，留下审批记录。可用性检查用真实业务问题做检索测试，记录命中情况和结果排序是否合理。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 权限模型验证 | 按部门、角色、密级抽取账号实测，越权访问为零 | 权限测试记录，含测试账号与结果 | IT或平台管理员 |
| 发布与修订流程 | 发布、修订、下架各跑通至少一轮，审批节点完整 | 流程实例截图或审批记录 | 知识库负责人 |
| 检索命中测试 | 用不少于约定数量的真实业务问题检索，命中率与首条结果相关性达到阈值 | 检索测试记录表 | 业务使用方代表 |
| 多端与入口可用 | 常用入口可正常访问，移动端与桌面端关键页面可用 | 访问测试记录 | IT或平台管理员 |
检索测试的问题应从试运行期间业务方实际提出的问题中选取，覆盖不同分类，避免只用建设方熟悉的词条测试。命中率不达标时，先排查分类标签与文档标题是否规范，再判断是否需要调整检索配置。
每项检查的通过标准与证据形式
通过标准要写成可判断的句子，包含数量阈值、抽样结果、签字确认或系统记录中的至少一种。例如“抽样准确率不低于约定比例”可判断，“内容质量较好”不可判断。证据形式要与标准对应：数量类标准用统计导出，流程类标准用审批记录，配置类标准用截图加测试记录。
判定结果建议分三档：通过、有条件通过、不通过。有条件通过适用于不影响核心使用、可在约定期限内整改的事项，需写明整改内容、责任人和复检日期；到期未整改的转为不通过。证据统一存放在验收目录下，按阶段和检查项编号归档，便于复检和上线后追溯。下面给出四列模板，可直接复制使用：
| 检查项 | 通过标准 | 证据 | 判定结果 |
|---|---|---|---|
| 示例：核心分类文档抽样准确率 | 抽样文档准确率不低于约定比例 | 抽样记录表（编号、样本、结论） | 通过／有条件通过／不通过 |
当验收项、证据附件和整改状态分散在邮件与共享盘时，复检容易丢失上下文。可以把每个检查项建成工作项，挂接证据文档，整改状态随工作项流转，知识库负责人按阶段视图汇总判定结果。ONES的工作项与文档能力可以承载这种检查项流转和证据留痕，具体配置按团队现有流程设定。
阻断项与上线完成条件
阻断项是上线前必须清零的事项，典型包括：核心分类知识缺失或准确率不达标、存在越权访问、发布与下架流程未跑通、无责任人内容占比超过约定阈值。阻断项清单在准备阶段确定，验收中新增阻断项需知识库负责人确认。
一般项可带条件上线，但要写明容忍范围和整改计划，例如非核心分类的部分文档标签不规范，可约定上线后一个月内完成整改，由对应内容责任人跟踪。上线完成条件以书面放行确认单为准，内容包括：阻断项清零情况、有条件通过项的整改期限、遗留问题清单及跟踪归属。放行确认单由知识库负责人、业务使用方代表签字，涉及权限的事项由IT或平台管理员会签。上线后的遗留问题转入运营跟踪，按整改期限复检，复检结果回填原验收记录，形成闭环。
常见问题
验收清单由建设方自己判定可以吗？
建议把证据提供与判定签字分开。单项检查由执行方提供证据，知识库负责人确认；阻断项是否清零由知识库负责人会同业务使用方代表共同拍板，涉及权限与安全的阻断项需IT或平台管理员签字。同一人既做又判，业务方容易在事后追认时提出异议，返工成本更高。
抽样比例定多少合适，验收时能临时调整吗？
抽样比例在准备阶段写入清单，验收时按此执行，不临时调整。常见做法是核心分类全量检查，非核心分类按分层抽样抽取一定数量或比例的文档。比例高低取决于内容规模和风险，没有统一数值；关键是规则先定、记录可回溯，准确率不达标时按分类退回整改，整改后对同一分类重新抽样，而不是只复检原样本。
试运行期间业务方提出的检索问题，验收时怎么用？
检索测试的问题从试运行期间业务方实际提出的问题中选取，覆盖不同分类，避免只用建设方熟悉的词条测试。测试时记录命中情况和首条结果相关性，形成检索测试记录表。命中率不达标时，先排查分类标签与文档标题是否规范，再判断是否需要调整检索配置。
有条件通过的事项到期没整改完怎么办？
有条件通过需写明整改内容、责任人和复检日期，到期未整改的转为不通过。若该事项属于阻断项，上线放行不能通过；若属于一般项，由知识库负责人评估是否扩大容忍范围并更新整改计划，同时把延期情况记入放行确认单的遗留问题清单。
上线后验收记录还需要保留吗？
需要。证据按阶段和检查项编号归档在验收目录下，上线后遗留问题的复检结果回填原验收记录。这样后续运营阶段发现某类内容质量下滑时，可以回溯当时的抽样结论和责任人，判断是建设遗留还是使用中新产生的问题。
