上线前验收研发知识问答，需要把“问得全不全”和“答得有据可查”变成可统计的记录。这套模板提供两张表：测试问题集表按知识域、问题类型、难度和期望来源铺开题目，答案核验记录表逐条记录正确性、来源可追溯性和拒答情况，两表用问题编号关联，最后按知识域与问题类型汇总通过率，作为上线判定依据。
要点总览（TL;DR）
- 模板由两张表组成：测试问题集表记录问题编号、知识域、问题类型、难度、问题正文、期望答案要点、期望来源、是否必测；答案核验记录表逐条记录正确性、来源可追溯性、拒答或不确定标注，两表用问题编号关联。
- 必填字段决定统计口径：问题集表缺知识域、问题类型、问题正文、期望来源或是否必测的题目视为无效题；核验表缺正确性判定或来源可追溯判定的记录不计入通过率，必测题无记录按不通过处理。
- 上线判定看三项：必测题全部通过作为前置条件，整体正确率与来源可追溯率达到验收前约定的合格线，各知识域题量不为零且通过率不低于约定幅度。
- 问题集随知识库演进维护：文档新增补题、修订更新期望答案要点与期望来源、下线删除或改写对应题目，问题集独立升版并记录对应的知识库版本，按季度全量回归、变更时定向回归。
可复制空白模板：测试问题集与答案核验记录
先复制下面两张表到文档或表格工具中，按行录入。问题集表负责“问什么、期望怎么答”，核验表负责“实际答成什么样”。两表只通过“问题编号”关联，编号在问题集表中生成后不再修改，核验表直接引用同一编号，避免同一问题出现两套标识。
表一：研发知识问答测试问题集
| 问题编号 | 知识域 | 问题类型 | 难度 | 问题正文 | 期望答案要点 | 期望来源 | 是否必测 | 备注 |
|---|---|---|---|---|---|---|---|---|
| Q-001 | ||||||||
| Q-002 | ||||||||
| Q-003 | ||||||||
| … |
表二：答案核验记录
| 问题编号 | 实际回答摘要 | 正确性判定 | 来源可追溯判定 | 拒答/不确定标注 | 问题记录 | 核验人 | 核验日期 |
|---|---|---|---|---|---|---|---|
| Q-001 | |||||||
| Q-002 | |||||||
| Q-003 | |||||||
| … |
录入顺序建议先完成问题集表，再统一发起问答并填写核验表。核验表每行对应问题集表的一行，问题集表中标记为必测的题目，核验表中必须有记录，缺记录按未通过处理。
字段说明：每个字段填什么、为什么要有
字段口径统一，不同人核验同一道题才能得到一致结论。下面按两张表分别说明，重点解释影响判定的字段。
问题集表字段定义
| 字段 | 填写口径 | 作用 |
|---|---|---|
| 问题编号 | 建议“Q-三位序号”，全表唯一，生成后不改 | 两表关联的唯一键 |
| 知识域 | 按知识库的实际分类填写，如需求管理、测试流程、发布规范、架构说明、运维手册 | 统计覆盖度，识别空白知识域 |
| 问题类型 | 建议分为事实查询、流程步骤、条件判断、跨文档综合、边界与例外 | 区分问答能力的不同考察面 |
| 难度 | 建议分为基础、进阶、困难，按答案需要跨几份文档、是否需要推理判断来定 | 观察不同难度下的通过率差异 |
| 问题正文 | 写成研发人员真实会问的一句话，保留业务术语 | 保证测试贴近实际使用 |
| 期望答案要点 | 列出答案必须包含的关键结论，2–5条，不写完整答案 | 作为正确性判定基准 |
| 期望来源 | 写明应引用的文档名称，尽量到章节或段落 | 作为来源可追溯判定基准 |
| 是否必测 | 填“是”或“否”，必测题通常覆盖核心流程与高风险知识 | 决定上线前置条件 |
| 备注 | 补充出题背景、关联需求或已知争议点 | 便于后续维护时理解出题意图 |
核验表字段定义
| 字段 | 填写口径 | 作用 |
|---|---|---|
| 问题编号 | 与问题集表完全一致 | 关联两表 |
| 实际回答摘要 | 摘录回答的关键结论，不必全文照抄 | 留痕，便于复盘争议 |
| 正确性判定 | 建议三级：通过（要点齐全且无错误）、部分通过（主要结论正确但有遗漏或表述偏差）、不通过（结论错误或缺失关键要点） | 计算正确率 |
| 来源可追溯判定 | 建议三级：可定位（引用能落到具体文档与段落）、部分可定位（只给文档名或范围过宽）、不可追溯（无引用或引用与答案无关） | 计算来源可追溯率 |
| 拒答/不确定标注 | 回答明确表示无法回答填“拒答”；回答带有“可能”“建议确认”等限定填“不确定”；正常回答留空 | 单独统计，避免与答错混为一谈 |
| 问题记录 | 记录答错原因，如知识库缺文档、文档过期、检索未命中、答案拼接错误 | 定位整改方向 |
| 核验人 | 填写实际核验人姓名 | 责任可追溯 |
| 核验日期 | 填写核验当天日期 | 区分不同轮次 |
期望答案要点与期望来源必须在发起问答前填写完成。核验时对照这两列逐项打勾，能减少凭印象判断带来的口径漂移；同一道题由两人核验时，也应以这两列为共同基准讨论分歧。
必填与选填：哪些字段决定验收结论
必填字段缺失的条目不计入通过率统计，这是保证统计口径一致的前提。选填字段用于补充说明，缺失不影响统计，但会影响复盘时的信息完整度。
| 表 | 必填字段 | 选填字段 |
|---|---|---|
| 问题集表 | 问题编号、知识域、问题类型、问题正文、期望来源、是否必测 | 难度、期望答案要点细化、备注 |
| 核验表 | 问题编号、正确性判定、来源可追溯判定、核验人 | 实际回答摘要、问题记录、核验日期 |
处理规则如下：
- 问题集表中缺少必填字段的题目，视为无效题，不进入测试范围，也不计入覆盖率分母。
- 核验表中缺少正确性判定或来源可追溯判定的记录，该条不计入通过率统计，并在验收报告中单列为“记录不完整”。
- 必测题在核验表中完全没有记录的，按不通过处理，不能以“未测”跳过。
- 难度虽为选填，若计划按难度分层统计，应在录入阶段补齐，事后补填容易失真。
填写示例：一条问题从录入到核验完成
下面用一条需求管理类问题演示两表如何配合。示例中的文档名称与回答内容为演示情景，实际使用时替换为团队自己的知识库内容。
问题集表中的填写
| 字段 | 填写内容 |
|---|---|
| 问题编号 | Q-014 |
| 知识域 | 需求管理 |
| 问题类型 | 流程步骤 |
| 难度 | 进阶 |
| 问题正文 | 需求评审通过后，需求状态要经过哪些环节才能进入开发？ |
| 期望答案要点 | 1. 评审通过后进入待排期；2. 排期确认后转为已计划；3. 开发领取任务后转为进行中；4. 每个环节的责任角色 |
| 期望来源 | 《需求管理流程规范》第3章“需求状态流转” |
| 是否必测 | 是 |
| 备注 | 核心流程，新成员高频提问 |
核验表中的填写
| 字段 | 填写内容 |
|---|---|
| 问题编号 | Q-014 |
| 实际回答摘要 | 回答列出待排期、已计划、进行中三个状态，并说明由产品经理排期、开发负责人领取任务，引用《需求管理流程规范》第3章 |
| 正确性判定 | 通过 |
| 来源可追溯判定 | 可定位 |
| 拒答/不确定标注 | 留空 |
| 问题记录 | 无 |
| 核验人 | 示例核验人 |
| 核验日期 | 示例日期 |
这条示例体现两个判定口径。来源可追溯判定为“可定位”，依据是回答的引用能落到《需求管理流程规范》第3章这一具体章节，核验人可以直接翻到原文核对；若回答只写“根据需求管理规范”而不指明章节，应判为“部分可定位”。
拒答与不确定的合理情形也需要示范。假设另一道题问的是尚未写入知识库的灰度发布审批人，回答明确说明知识库中没有该信息并建议咨询发布负责人，核验时在拒答/不确定标注中填“拒答”，正确性判定填“通过”——对于知识库确实没有覆盖的问题，明确拒答优于编造答案。若回答给出审批人姓名但语气含糊、未引用任何文档，则标注“不确定”，正确性判定按实际内容判断，来源可追溯判定填“不可追溯”。
覆盖度与来源可信度的统计口径
两张表填完后，按知识域、问题类型、难度三个维度分别统计题量与通过率，再单独计算来源可追溯率，最后结合必测题结果给出上线结论。
统计维度与计算方式
| 统计项 | 计算方式 | 用途 |
|---|---|---|
| 知识域覆盖题量 | 按知识域分组计数有效题 | 识别题量过少或为空的知识域 |
| 知识域通过率 | 该知识域判定为“通过”的题数 ÷ 该知识域参与统计题数 | 定位薄弱知识域 |
| 问题类型通过率 | 按事实查询、流程步骤、条件判断等分组计算通过率 | 观察哪类问题答得差 |
| 难度通过率 | 按基础、进阶、困难分组计算通过率 | 判断困难题是否拖累整体 |
| 来源可追溯率 | 判定为“可定位”的题数 ÷ 参与统计题数 | 衡量来源可信度 |
| 拒答与不确定占比 | 标注为拒答或不确定的题数 ÷ 参与统计题数 | 单独观察，不与答错合并 |
合格线由团队在验收前约定并写入验收说明，常见做法是：整体正确率达到约定比例，来源可追溯率达到约定比例，且任一知识域的通过率不低于整体合格线一定幅度。合格线一旦确定，本轮验收不再调整，避免事后放宽标准。
上线判定规则
- 必测题全部判定为“通过”，是上线的前置条件；存在必测题不通过时，先整改对应知识文档或问答配置，再重新核验。
- 来源可追溯率未达合格线时，即使正确率达标，也应视为来源可信度不足，优先补齐文档引用与段落定位。
- 某知识域题量为零或明显偏少，说明覆盖度存在空白，需要补题后重新统计，不能以其他知识域的高通过率替代。
- 拒答占比偏高时，先排查知识库是否缺少对应文档，再判断是否属于合理的边界拒答。
补题方法上，优先从研发团队真实提问记录、新成员常见问题、近期变更的流程文档中提取题目，每补一批题同步更新问题集版本号，并在核验表中新增对应记录，保持两表行数一致。
调整与维护：问题集随知识库演进的更新方法
问题集的价值在于持续可用。知识库变动后，对应题目要同步调整，否则通过率反映的是旧知识的状态。维护工作可以按下面的规则执行。
增删改规则
| 知识库变化 | 问题集动作 | 核验记录动作 |
|---|---|---|
| 新增文档或章节 | 在对应知识域补充新题，标注期望来源为新文档 | 新增核验记录，首轮全量核验 |
| 文档修订 | 更新受影响题目的期望答案要点与期望来源 | 重新核验并保留历史记录，注明修订轮次 |
| 文档下线 | 删除或改写依赖该文档的题目，避免期望来源失效 | 对应记录标记为“已失效”，不参与后续统计 |
| 流程或组织调整 | 复核条件判断类与边界类题目，补充新例外情形 | 按调整范围做定向回归 |
版本与回归
- 问题集使用独立版本号，如V1.0、V1.1，每次增删改题目后升版，并在问题集表头记录对应的知识库版本或更新时间。
- 定期回归建议按季度执行全量核验，知识库发生较大变更时增加一次定向回归；日常可按必测题加随机抽样的方式做小范围抽查，抽样比例由团队根据题目总量约定。
- 核验记录按轮次留档，复盘时对比相邻两轮的通过率变化和问题记录，定位是文档质量问题还是问答配置问题。
问题集与核验记录需要在多人之间协作维护时，可以放到 ONES Wiki 中按知识域分页面管理，把每轮核验作为工作项流转状态并指派核验人，使题目修订、核验结论和整改任务在同一处可追踪。ONES Assistant 支持基于指定的 Wiki 页面组回答问题并附上引用来源，在验收阶段可以用它对照问题集做初步核验，再人工复核来源定位是否落到具体段落。
常见问题
问题集里的“期望来源”只写文档名可以吗？
建议写到章节或段落。来源可追溯判定分为“可定位”“部分可定位”“不可追溯”三级，只写文档名通常只能判为“部分可定位”，核验人需要自行在文档中查找对应内容，判定结果会受查找效率影响。写到章节或段落，核验时可以直接翻到原文比对，不同人核验同一道题也更容易得出一致结论。
如果知识库文档本身没有清晰的章节结构，可以先在文档中补齐标题层级，再回填期望来源。
知识库确实没有覆盖的问题，回答拒答算通过还是不通过？
按模板口径，知识库确实没有该信息、回答明确说明无法回答并给出获取途径的，拒答/不确定标注填“拒答”，正确性判定可以填“通过”。这类题目考察的是回答是否克制，编造答案才是更严重的问题。
如果回答给出了具体内容但语气含糊、未引用任何文档，标注“不确定”，正确性判定按实际内容判断，来源可追溯判定填“不可追溯”。拒答与不确定单独统计占比，不与答错合并计算。
必测题在核验时漏测了，能按“未测”排除在统计之外吗？
不能。必测题在核验表中完全没有记录的，按不通过处理，不能以“未测”跳过。必测题全部通过是上线的前置条件，漏测意味着这条前置条件没有满足，应先补测再出结论。
如果确实因为环境或权限原因无法测试，应在问题记录中写明原因，并在验收报告中单列，由验收负责人决定是否延期上线，而不是从统计中剔除。
合格线应该在什么时候定，定完还能调整吗？
合格线应在发起核验之前约定并写入验收说明，内容包括整体正确率、来源可追溯率，以及各知识域通过率相对整体合格线的允许下浮幅度。核验开始后再调整合格线，容易变成按结果倒推标准。
如果本轮验收发现合格线设置明显不合理，例如题目难度结构与预期偏差较大，建议记录原因后作废本轮数据，调整合格线并重新核验，保留两轮记录以便对比。
问题集和核验记录在团队里怎么协作维护？
多人维护时，问题集按知识域分页面管理，每轮核验作为独立记录留档并指派核验人，题目修订与整改任务在同一处可追踪。ONES Wiki 可用于承载问题集页面，核验记录可按轮次建立工作项并流转状态；ONES Assistant 支持基于指定的 Wiki 页面组回答问题并附上引用来源，可在验收阶段对照问题集做初步核验，再由人工复核来源定位是否落到具体段落。
具体页面组织与状态流转方式需结合团队现有协作习惯配置。
