上线前验收研发知识问答，需要留下可复查的记录：问了哪些问题、期望答案覆盖什么、实际回答引用了哪些来源、哪些通过、哪些需要整改。这份模板把验收拆成“测试问题集表”和“答案核验记录表”两张空白表，用同一套问题编号关联，按覆盖维度和来源可信度两个口径汇总，形成可留痕的验收结论。文末说明如何随知识库版本迭代维护模板，并自然衔接用工作项或文档承载核验记录的方式。
要点总览（TL;DR）
- 模板由两张表组成：测试问题集表确定验收考什么，答案核验记录表记录实际回答、来源可追溯性、覆盖判定、可信度结论和处置意见，两表用问题编号一一关联。
- 覆盖度按问题集表的覆盖维度汇总通过率，来源可信度以“可信”记录占比衡量，并单独统计“无来源”记录数，两个口径分开统计。
- 最小可用版本保留问题编号、问题原文、期望答案要点、覆盖维度、优先级，以及记录编号、实际回答摘要、引用来源、要点覆盖判定、可信度结论和处置意见。
- 验收结束后按版本归档两表，下一轮优先复用高优先级问题并对比历史记录；字段口径变化需在模板版本记录中注明生效轮次。
- 核验记录需要长期追踪时，可承载为可检索的文档或工作项，便于下一轮验收复查整改动作。
可复制空白模板：测试问题集表与答案核验记录表
两张表分工明确：测试问题集表在验收前确定“考什么”，答案核验记录表在验收时记录“答得怎么样”。两表通过“问题编号”一一对应，一个问题编号在核验表中可以有多条记录（例如同一问题在不同知识库版本或不同提问方式下各记录一次），汇总时按问题编号去重统计覆盖情况。
表一：测试问题集表（空白）
| 问题编号 | 问题原文 | 提问场景 | 期望答案要点 | 来源要求 | 覆盖维度 | 优先级 | 录入人 | 录入日期 |
|---|---|---|---|---|---|---|---|---|
| Q-001 | ||||||||
| Q-002 | ||||||||
| Q-003 | ||||||||
| … |
表二：答案核验记录表（空白）
| 记录编号 | 问题编号 | 实际回答摘要 | 引用来源 | 来源可追溯性 | 要点覆盖判定 | 可信度结论 | 处置意见 | 核验人 | 核验日期 |
|---|---|---|---|---|---|---|---|---|---|
| R-001 | |||||||||
| R-002 | |||||||||
| R-003 | |||||||||
| … |
关联规则：核验表的“问题编号”必须取自测试问题集表中已存在的编号；记录编号独立递增，便于同一问题多次核验时区分。验收汇总时，以问题编号为键，统计每个问题的最新一条核验记录，避免重复计数。
字段说明：每个字段记录什么、怎么填
字段口径需要在模板、说明和示例三处保持一致。下表逐字段给出含义与填写方式，其中“覆盖维度”“来源可信度”的判定标准由团队在验收前约定，模板只提供记录位置，不预设阈值。
测试问题集表字段
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 问题编号 | 问题的唯一标识 | 建议用“Q-三位序号”，全表唯一，录入后不再复用 |
| 问题原文 | 验收时实际提出的问题 | 按研发人员真实提问方式书写，保留口语化表达 |
| 提问场景 | 问题出现的业务情境 | 如“需求评审前查历史方案”“新人查构建流程”，用于判断问题是否贴近真实使用 |
| 期望答案要点 | 回答至少应包含的关键信息 | 拆成2–5个要点，逐条可勾选核对，避免写成整段描述 |
| 来源要求 | 回答应引用的知识来源范围 | 写明应来自哪类文档或哪个知识空间，例如“应引用接口规范文档” |
| 覆盖维度 | 该问题考察的知识面 | 从团队约定的维度中选一个主维度，如流程规范、技术方案、历史决策、环境配置 |
| 优先级 | 问题的重要程度 | 高/中/低；高优先级问题必须全部通过才可上线 |
| 录入人、录入日期 | 问题来源与时间 | 便于追溯问题由谁在何时补充 |
答案核验记录表字段
| 字段 | 记录什么 | 填写口径 |
|---|---|---|
| 记录编号 | 单次核验的唯一标识 | “R-三位序号”，每次核验新增一条，不覆盖旧记录 |
| 问题编号 | 关联的测试问题 | 必须与测试问题集表中的编号一致 |
| 实际回答摘要 | 系统回答的核心内容 | 摘录关键句，保留回答中出现的来源标注信息 |
| 引用来源 | 回答给出的出处 | 记录文档名称、页面或段落位置；未给出出处时写“未标注” |
| 来源可追溯性 | 来源能否被复核 | 按“可定位到具体文档段落 / 仅到文档 / 无来源”三档记录 |
| 要点覆盖判定 | 期望要点是否被覆盖 | 逐条对照期望答案要点，记“全覆盖 / 部分覆盖 / 未覆盖”，部分覆盖注明缺哪条 |
| 可信度结论 | 回答是否可信 | 综合来源可追溯性与内容准确性，记“可信 / 存疑 / 不可信”，存疑需写明原因 |
| 处置意见 | 后续动作 | 如“通过”“补充知识文档后复测”“修正文档表述”“暂缓上线该问题” |
| 核验人、核验日期 | 责任人与时间 | 便于复查和追责 |
判定口径建议在验收启动会上固定下来：覆盖维度按问题集表的维度汇总，统计每个维度的通过率；来源可信度以“可信”记录占比衡量，同时单独列出“无来源”记录数。两个口径分开统计，避免用单一分数掩盖来源缺失问题。
必填与选填：验收留痕的最小字段集
如果团队规模小、验收周期短，可以裁剪字段，但裁剪后仍需保证“问题可识别、回答可复查、结论可追溯”。下表给出必填与选填的划分及裁剪时的保留顺序。
| 表 | 必填字段 | 选填字段 | 适用场景 |
|---|---|---|---|
| 测试问题集表 | 问题编号、问题原文、期望答案要点、覆盖维度、优先级 | 提问场景、来源要求、录入人、录入日期 | 小规模验收可先省略场景与来源要求；多人协作时补录入人 |
| 答案核验记录表 | 记录编号、问题编号、实际回答摘要、引用来源、要点覆盖判定、可信度结论、处置意见 | 来源可追溯性、核验人、核验日期 | 单人核验可暂缓核验人字段；需要审计时补齐 |
裁剪时的保留顺序：问题编号与问题原文最先保留，它们是两表关联的基础；其次是期望答案要点与要点覆盖判定，决定覆盖度结论是否成立；再次是引用来源与可信度结论，决定来源可信度结论是否成立；最后才是场景、人员、日期等辅助字段。任何情况下都不建议删掉“处置意见”，否则验收记录无法转化为整改动作。
填写示例：一条问题从录入到核验结论
以下为演示情景，数据为虚构，仅用于说明填写方式。
测试问题集表中的示例记录
| 问题编号 | 问题原文 | 提问场景 | 期望答案要点 | 来源要求 | 覆盖维度 | 优先级 | 录入人 | 录入日期 |
|---|---|---|---|---|---|---|---|---|
| Q-007 | 服务发布前需要走哪些审批环节？ | 新成员准备首次发布 | 1. 提交发布申请；2. 技术负责人审批；3. 测试通过确认；4. 发布窗口时间 | 应引用发布管理规范文档 | 流程规范 | 高 | 示例用户 | 示例日期 |
答案核验记录表中的示例记录
| 记录编号 | 问题编号 | 实际回答摘要 | 引用来源 | 来源可追溯性 | 要点覆盖判定 | 可信度结论 | 处置意见 | 核验人 | 核验日期 |
|---|---|---|---|---|---|---|---|---|---|
| R-012 | Q-007 | 回答列出提交申请、技术负责人审批、测试确认三个环节，并提示在发布窗口内操作，附有规范文档出处 | 发布管理规范文档第3节 | 可定位到具体文档段落 | 全覆盖 | 可信 | 通过 | 示例用户 | 示例日期 |
由示例得出的结论：该问题在“流程规范”维度判定为通过，来源可追溯且要点全覆盖，计入可信记录。若同一问题在另一版本中回答缺少“发布窗口时间”要点，则记为部分覆盖、可信度存疑，处置意见写“补充文档后复测”，并在汇总时以最新记录为准。
调整与维护方法：随版本迭代更新模板
模板本身也需要维护，否则问题集会逐渐偏离知识库现状，核验记录也会失去复用价值。以下规则可按团队节奏执行。
- 问题集扩充规则：知识库新增或重大修订文档时，同步评估是否需要新增测试问题；线上出现回答错误或用户反馈时，将对应问题补入问题集并标注来源。每次扩充保留原编号，新增问题顺延编号，不重排旧编号。
- 核验记录归档与复用：每轮验收结束后，将两表按版本号归档；下一轮验收优先复用上一轮的高优先级问题，并对比同一问题编号的历史记录，观察覆盖与可信度是否改善。
- 模板版本记录：在模板首页记录版本号、变更日期、变更字段和变更原因；字段增删时同步更新字段说明与示例，保证三处一致。字段口径变化（如可信度分档调整）需在变更记录中注明生效轮次。
- 记录承载方式：核验记录需要长期追踪时，可将其承载为可检索的文档或工作项。ONES Assistant 支持基于指定 Wiki 页面组回答问题并附上引用来源，ONES 基于自身权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；团队可将核验结论与整改动作落到工作项或 Wiki 页面中，便于下一轮验收复查。
维护频率建议与知识库发布节奏对齐：每次知识库大版本更新后做一次问题集评审，每轮上线验收前确认模板版本，验收结束后完成归档。这样两张表既能支撑单次上线验收，也能积累为跨版本的知识问答质量记录。
常见问题
问题集应该准备多少条问题才算够用？
模板不规定固定条数，判断依据是覆盖维度是否齐全。先按团队约定的覆盖维度（如流程规范、技术方案、历史决策、环境配置）各安排若干问题，再确保高优先级问题覆盖上线后最常被问到的场景。问题集规模较小时，优先保证每个维度至少有一条高优先级问题，验收汇总时按维度看通过情况，避免只盯总数。
回答没有标注来源，但内容看起来是对的，可信度怎么记？
按模板口径，来源可追溯性记“无来源”，可信度结论不宜直接记“可信”。可以记为“存疑”并在原因中写明“内容与文档一致但回答未标注出处”，处置意见写“补充来源标注后复测”。这样处理能让来源缺失问题在汇总时被单独统计出来，避免被内容正确掩盖。
同一问题在不同知识库版本下核验结果不一致，汇总时怎么算？
核验表每次核验新增一条记录，不覆盖旧记录。汇总时以问题编号为键，取该问题最新一条核验记录计入覆盖与可信度统计，历史记录保留用于对比。如果最新记录为部分覆盖或存疑，该问题在本轮验收中不计为通过，处置意见需写明整改动作和复测安排。
验收通过后，核验记录还需要保留吗？
建议保留并按版本归档。下一轮验收时，同一问题编号的历史记录可用于对比覆盖与可信度是否改善，也能在回答出现回归时快速定位是哪次知识库变更引入的。归档时把两表与对应的知识库版本号放在一起，便于复查时确认记录对应的知识状态。
核验记录放在文档里还是工作项里更合适？
取决于记录的使用方式。以留痕和评审为主时，放在文档中便于整表阅读和归档；需要跟踪整改动作、分配责任人和复测时，把处置意见落成工作项更便于追踪状态。ONES Assistant 支持基于指定 Wiki 页面组回答问题并附上引用来源，ONES 基于自身权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，团队可将核验结论与整改动作落到工作项或 Wiki 页面中，下一轮验收时直接复查。
