研发知识问答答案核验记录表模板：上线前验收覆盖度与来源可信度

上线前验收研发知识问答系统，需要留下可复核的记录：哪些问题测过、答案覆盖了哪些要点、引用来源是否可信、未通过的问题由谁整改。下面提供两张可直接复制使用的空白表——测试问题集与答案核验记录表，并说明字段口径、必填项、填写示例和维护规则。核验记录与整改项也可以放入 ONES 项目工作项中跟踪，便于从问题发现走到复核关闭。

要点总览（TL;DR）

• 模板由两张表组成：测试问题集定义测什么、期望答到什么程度；答案核验记录表记录实际回答、引用来源、覆盖度与核验结论，两表以问题编号关联。
• 覆盖度按期望答案要点的命中条数分级为完整覆盖、基本覆盖、部分覆盖、未覆盖；来源可信度按来源是否存在可访问、是否权威、是否支撑结论三步判定。
• 问题编号、期望答案要点、是否必测、引用来源清单、答案覆盖度、事实一致性、核验结论、核验人与日期属于必填，任一为空即视为该条未完成核验。
• 时间紧张时可使用精简版记录集做内部预检，正式上线验收仍建议使用完整字段，并由另一名成员复核必填字段与判定依据。
• 核验记录按验收批次、知识库版本与问答系统版本归档，知识库结构变更、必测问题不通过或整改未关闭时触发复验。

可复制空白模板：测试问题集与答案核验记录表

两张表通过“问题编号”关联：问题集定义测什么、期望答到什么程度；核验表记录系统实际答成什么样、来源是否可信、结论是否通过。复制时保留表头，按行填写即可。

表一：测试问题集

问题编号	业务场景	问题类型	难度	提问原文	期望答案要点	期望引用来源	是否必测
Q-001
Q-002
Q-003

填写提示：期望答案要点建议拆成 2–5 条可逐条核对的短句，便于在核验表中统计命中数量；期望引用来源写到文档名称或知识条目层级，便于判断“来源是否存在、是否匹配”。

表二：答案核验记录表

核验编号	对应问题编号	系统实际回答摘要	引用来源清单	来源可访问性	来源与问题匹配度	答案覆盖度	事实一致性	核验结论	问题描述	整改责任人	复核状态	核验人	核验日期
V-001	Q-001
V-002	Q-002
V-003	Q-003

关联说明：一条问题可以有多条核验记录（例如首轮核验、整改后复验各一条），此时核验编号递增，对应问题编号保持不变；汇总时以问题编号为维度取最新一条复核通过的记录作为该问题的验收结果。

字段说明：每个字段记录什么、怎么判定

字段口径统一，才能让不同核验人填出可比较的结果。下表给出每个字段的含义与填写方式，其中覆盖度和来源可信度是判定重点。

问题集字段口径

字段	记录什么	填写口径
问题编号	问题的唯一标识	建议“Q-序号”，全表不重复，后续核验表引用此编号
业务场景	问题所属的研发或业务环节	用团队已有场景名，如需求评审、接口联调、发布变更、故障排查
问题类型	问题的形态	可取值：事实查询、流程规则、操作步骤、原因分析、对比选择
难度	回答所需的信息跨度	可取值：简单（单一文档可答）、中等（需跨 2–3 份资料）、困难（需跨多份资料并做归纳）
提问原文	测试时实际输入的问题	照抄输入内容，不改写、不补上下文
期望答案要点	合格回答必须包含的信息	拆成编号短句，每条可独立判定命中与否
期望引用来源	回答应引用的资料	写到文档或知识条目名称，可列多个
是否必测	是否纳入上线门槛	填“是/否”；必测问题未通过则验收不通过

核验表字段口径

字段	记录什么	填写口径
核验编号	一次核验的唯一标识	建议“V-序号”，复验另起新编号
对应问题编号	关联的问题	必须与问题集中的编号一致
系统实际回答摘要	系统给出的回答	摘录关键句，保留结论和关键数字，不加入核验人评价
引用来源清单	回答中列出的来源	逐条列出，与系统展示一致
来源可访问性	来源能否打开并定位到相关内容	可取值：可访问且定位准确、可访问但定位偏差、无法访问
来源与问题匹配度	来源是否切题、是否权威	可取值：高度匹配、部分匹配、不匹配；同时注明来源类型（正式发布文档、会议纪要、个人笔记等）
答案覆盖度	期望要点被覆盖的程度	按命中条数分级，见下方口径
事实一致性	回答内容与来源是否一致	可取值：一致、部分一致、存在冲突、来源无对应内容
核验结论	本条是否通过	可取值：通过、有条件通过、不通过
问题描述	未通过或有条件通过的具体原因	写清缺哪个要点、哪个来源有问题、哪处与来源冲突
整改责任人	负责修正的人	填姓名或角色，一条记录对应一个主责人
复核状态	整改后的复验进度	可取值：待整改、待复核、复核通过、复核未通过
核验人、核验日期	留痕信息	填实际核验人和日期，复验时更新为新记录

覆盖度判定口径

覆盖度以“期望答案要点”的命中条数为准，避免凭整体印象打分：全部要点命中记为“完整覆盖”；命中多数要点、缺失的要点不影响主要结论记为“基本覆盖”；命中部分要点、缺失内容会导致误用记为“部分覆盖”；关键要点未命中或回答偏离问题记为“未覆盖”。判定时逐条对照要点打勾，再按上述规则归级，并在问题描述中写明缺失的要点编号。

来源可信度判定口径

来源可信度分三步判定：先看来源是否存在且可访问，再看来源本身是否权威（正式发布的技术文档、经评审的设计文档优先于个人笔记和过期讨论记录），最后看来源内容是否支撑回答中的结论。三步都满足记为“可信”；来源可访问但权威性不足或仅部分支撑记为“部分可信”；来源缺失、无法访问或与回答冲突记为“不可信”。来源可信度判定结果与“来源可访问性”“来源与问题匹配度”两列应保持一致，出现矛盾时以更严格的判定为准并说明原因。

核验结论取值

“通过”表示覆盖度达到基本覆盖及以上、来源可信、事实一致；“有条件通过”表示主要结论正确但存在次要要点缺失或来源权威性不足，需记录限制条件并安排后续补充；“不通过”表示存在关键要点缺失、来源不可信或事实冲突，必须整改后复验。必测问题取值为“不通过”时，整体验收不能关闭。

必填与选填：哪些字段缺失就不能算完成验收

验收记录的价值在于可追溯，因此与“测了什么、答成什么样、谁来判断、结论是什么”直接相关的字段必须填写；辅助排查的字段可以在时间紧张时省略。

必填字段及缺失后果

问题集的必填字段为：问题编号、业务场景、提问原文、期望答案要点、是否必测。缺少问题编号则两表无法关联；缺少期望答案要点则覆盖度无法判定；缺少是否必测则无法确定上线门槛。核验表的必填字段为：核验编号、对应问题编号、系统实际回答摘要、引用来源清单、来源可访问性、答案覆盖度、事实一致性、核验结论、核验人、核验日期。缺少引用来源清单或来源可访问性，来源可信度无法留痕；缺少核验结论，该条记录不能计入验收统计。任一必填字段为空，该条记录视为未完成核验。

选填字段及使用场景

问题类型、难度、期望引用来源属于选填，用于分层抽样和统计覆盖结构；问题描述、整改责任人、复核状态在结论为“通过”时可简化填写，在“有条件通过”和“不通过”时必须补充，否则整改无法跟踪。来源与问题匹配度在来源清单只有一条且明显切题时可暂不细填，多来源回答时建议填写以便区分主次来源。

最小可用记录集

时间紧张时，可保留精简版：问题集保留问题编号、提问原文、期望答案要点、是否必测；核验表保留核验编号、对应问题编号、系统实际回答摘要、引用来源清单、答案覆盖度、核验结论、核验人、核验日期。精简版能支撑覆盖度统计和结论留痕，但来源可信度的判定依据较弱，适合内部预检，正式上线验收仍建议使用完整字段。

必填字段的复核签署要求

核验人填写完成后，由另一名熟悉该业务场景的成员复核必填字段是否完整、覆盖度分级是否与要点命中情况一致、来源可信度判定是否有依据。复核人确认后在复核状态中记录结果；必测问题的复核通过是验收关闭的前提。若团队使用 ONES 承载核验记录，可将每条核验作为工作项，把复核状态作为工作项状态流转，整改责任人作为负责人，形成从发现问题到复核关闭的记录链。

填写示例：一条问题从提问到核验结论

以下示例为演示情景，用于说明两表如何联动填写，不代表任何真实系统表现。

问题集中的填写

问题编号 Q-014，业务场景“发布变更”，问题类型“流程规则”，难度“中等”，提问原文“生产环境发布回滚需要谁审批，回滚窗口有多长”，期望答案要点拆为三条：①回滚需值班负责人和业务负责人双方审批；②回滚窗口为发布后 2 小时内；③超窗回滚需走变更评审。期望引用来源为《生产发布管理规范》和《变更评审流程说明》，是否必测填“是”。

核验表中的完整填写

核验编号 V-021，对应问题编号 Q-014。系统实际回答摘要：“回滚需值班负责人审批，回滚窗口为发布后 2 小时内，超窗需走变更评审。”引用来源清单列出《生产发布管理规范》。来源可访问性填“可访问且定位准确”；来源与问题匹配度填“部分匹配”，因为只引用了发布规范，未引用变更评审流程说明。答案覆盖度填“基本覆盖”，命中要点②③，缺失要点①中的业务负责人审批。事实一致性填“一致”，回答内容与所引来源不冲突。核验结论填“有条件通过”。

判定过程与整改动作

覆盖度判定时逐条对照：要点①只命中一半，要点②③命中，因此归为基本覆盖而非完整覆盖；来源可信度判定时，来源可访问且为正式发布文档，权威性满足，但未覆盖审批角色这一关键信息，且缺少第二份期望来源，因此来源判定为部分可信。由于缺失内容涉及审批权限，属于会影响执行的关键信息，核验结论定为“有条件通过”并要求补充。问题描述写为：“缺失业务负责人审批要点，未引用变更评审流程说明。”整改责任人填发布流程文档负责人，复核状态填“待整改”。整改完成后新增核验记录 V-022，复核状态更新为“复核通过”，该问题方可计入验收通过。

调整与维护：按团队情况改字段、按版本迭代表格

这张表在首次上线验收后仍会持续使用，需要明确字段裁剪原则和版本维护节奏，避免表格越填越重或与知识库现状脱节。

字段裁剪与扩展的取舍原则

裁剪以“是否影响结论判定和整改跟踪”为标准：影响覆盖度或来源可信度判定的字段保留，仅用于统计分析的字段可按需精简。扩展时优先增加与业务场景相关的列，例如按产品线增加“所属模块”，或按来源类型增加“来源版本号”，新增字段需同步更新字段说明和示例，保持模板、说明、示例三处一致。

问题集随知识库变更的更新节奏

知识库发生结构性变更（新增文档体系、流程规则调整、重要文档下线）时，同步检查相关问题：期望答案要点是否仍成立、期望引用来源是否仍存在。建议每次知识库版本发布后做一次问题集巡检，标记失效问题并补充新场景问题，保证问题集始终对应当前知识状态。

核验记录的归档与版本对应

每轮验收的核验记录按“验收批次 + 知识库版本 + 问答系统版本”归档，同一问题编号保留历史核验记录，便于回溯某条结论是在哪个版本下得出的。归档时保留原始填写内容，修订以新增记录的方式进行，不覆盖旧记录。

验收结论汇总与复验触发条件

验收汇总按问题编号统计：必测问题通过率、覆盖度分布、来源不可信条数、未关闭整改项数量。出现以下情况触发复验：必测问题存在“不通过”、整改项未关闭、知识库或问答系统发布新版本、来源文档发生重大修订。复验使用新的核验编号，复核通过后更新该问题的验收状态。若整改项较多，可在 ONES 中按责任人建立整改工作项并关联对应核验记录，用状态流转跟踪“待整改—待复核—复核通过”，让验收结论有据可查。

常见问题

测试问题集应该放多少条问题，怎么分配场景和难度？

模板本身不规定条数，条数取决于知识库覆盖范围和上线风险。可操作的分配方式是：先按业务场景列出团队实际会问到的环节，每个场景至少放一条必测问题；再按问题类型和难度分层，保证事实查询、流程规则、操作步骤、原因分析、对比选择各有代表，简单、中等、困难三档都有样本。必测问题应覆盖高风险场景，例如发布变更、故障处理这类答错代价高的环节。问题集规模确定后，把“是否必测”标清楚，验收统计才有明确门槛。

系统回答引用了来源，但来源本身是过期的会议纪要，该怎么记录？

这种情况在核验表中分开记录：来源可访问性填“可访问且定位准确”或“可访问但定位偏差”，来源与问题匹配度注明来源类型为会议纪要，来源可信度判定为“部分可信”。如果回答结论与当前正式文档冲突，事实一致性填“存在冲突”，核验结论取“不通过”，问题描述写清冲突的正式文档名称。来源可信度判定以更严格的结果为准，不能因为来源能打开就记为可信。

一条问题首轮核验不通过，整改后复验，验收统计时算哪条记录？

复验另起新的核验编号，对应问题编号保持不变，历史记录保留不覆盖。汇总时以问题编号为维度，取最新一条复核通过的记录作为该问题的验收结果；如果最新记录仍为“复核未通过”，该问题继续计入未通过。这样既能反映当前状态，也能回溯每轮整改的过程。

核验人和复核人可以是同一个人吗？

建议分开。核验人负责填写实际回答摘要、覆盖度与来源判定，复核人负责检查必填字段是否完整、覆盖度分级是否与要点命中情况一致、来源可信度判定是否有依据。同一人兼任时，至少隔一轮再复核，或在复核状态中注明自查，降低判定口径漂移的风险。必测问题的复核通过是验收关闭的前提，复核环节不宜省略。

知识库更新后，旧的问题集和核验记录要怎么处理？

知识库发生结构性变更时，对问题集做一次巡检：逐条检查期望答案要点是否仍成立、期望引用来源是否仍存在，失效问题标记停用并补充新场景问题。核验记录按“验收批次 + 知识库版本 + 问答系统版本”归档，旧记录保留原始内容，修订以新增记录方式进行。新版本上线前用更新后的问题集重新核验，避免用旧结论判断新知识状态。