缺陷摘要由模型生成后，直接进入开发流转会带来返工和误判风险。人工复核的作用是把摘要当作待审草稿，用固定字段和判定口径逐项比对原始材料，再给出通过、修改或驳回结论。本文给出字段标准、分步操作、角色分工、完整示例和完成检查，适用于测试团队在缺陷提交与流转之间建立复核环节；ONES 可作为缺陷工作项与复核记录的管理载体。
要点总览（TL;DR）
- 复核前先把摘要固定为现象、复现路径、影响范围、日志关键行、当前结论五类字段，并为每类指定来源材料和判定口径，复核才有可比对的标准。
- 复核按四步推进：核对来源材料、逐字段比对并标注差异、给出通过/修改/驳回结论、修改后二次确认再放行，每步都有输入、输出和完成标志。
- 提交人负责提交时自检材料完整性，测试负责人或模块负责人负责流转前终审并放行，复核记录随缺陷工作项留存，判定不一致时按两级升级路径处理。
- 摘要未经复核不得流转到开发，结论为驳回的不得放行；用覆盖率、及时性、修改原因归类和结论一致性抽查验收复核环节是否真正落地。
复核前先定摘要字段与判定口径
复核要能判断对错，前提是摘要包含哪些内容、每项以什么材料为准已经写清楚。字段不固定，复核人只能凭经验判断，结论难以一致，也无法在多人之间交接。建议把摘要固定为五类字段，并为每类指定来源材料和判定口径。
| 字段 | 来源材料 | 判定口径 | 缺失或冲突时的处理 |
|---|---|---|---|
| 现象 | 缺陷标题、实际观察描述 | 描述用户或系统实际看到的结果，与标题指向一致，不含推测性原因 | 标题与描述不一致时以复现结果为准，退回提交人补充观察记录 |
| 复现路径 | 复现步骤、前置条件、测试数据 | 步骤可被他人按序执行并得到相同结果，关键前置条件齐全 | 步骤缺失或跳步时标记为待补充，摘要不得判定通过 |
| 影响范围 | 模块信息、环境、受影响功能或用户 | 说明发生在哪个模块、哪个环境、影响哪些功能或用户群体 | 无法确认时写明“范围待确认”，由终审人决定是否放行 |
| 日志关键行 | 日志、报错截图、堆栈信息 | 摘录与现象直接相关的错误码或异常行，保留原始文本，不改写 | 日志与现象无对应关系时视为冲突，需补充或说明 |
| 当前结论 | 讨论记录、初步分析 | 区分已确认事实与待验证推测，推测须标注 | 讨论中存在分歧时，摘要只记录分歧点，不替团队下结论 |
字段与来源冲突时，处理原则是“以原始材料为准、以可复现为准”。摘要中出现来源材料没有的信息，视为越界补充，需要提交人说明出处或删除。字段缺失属于可修复问题，冲突属于需要澄清的问题，两者在复核结论上应区别对待：缺失通常退回修改，冲突则需要提交人与终审人共同确认后再判定。
人工复核的分步操作流程
复核按固定顺序推进，每一步都有明确输入、动作、输出和完成标志，避免复核人凭印象扫一眼就放行。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 接收摘要并核对来源 | 生成的摘要草稿、缺陷标题、复现步骤、日志、讨论记录 | 确认来源材料齐全，摘要与缺陷工作项对应无误 | 材料清单与对应关系确认 | 五类字段的来源材料均可获取 |
| 2. 逐字段比对与差异标注 | 字段判定口径表、来源材料 | 按现象、复现路径、影响范围、日志关键行、结论逐项比对，标注一致、缺失或冲突 | 带差异标注的复核稿 | 每个字段都有比对结论，无遗漏项 |
| 3. 给出复核结论 | 带差异标注的复核稿 | 根据差异性质判定通过、修改或驳回，并写明理由 | 复核结论与理由 | 结论三选一，理由指向具体字段 |
| 4. 修改后二次确认与放行 | 修改后的摘要、原复核结论 | 核对修改是否覆盖全部差异项，确认无新增偏差 | 放行记录 | 差异项全部关闭，摘要状态更新为已复核 |
第2步是复核的主要工作量所在。比对时建议按字段顺序推进，每完成一项就在复核稿上标注结果，避免反复来回翻材料。差异标注要具体到字段和原文，例如“影响范围写为全站，来源材料仅显示订单模块”，而不是笼统写“描述不准”。
第3步的三种结论对应不同后续动作：通过表示摘要可直接流转；修改表示差异可由提交人自行修正后二次确认；驳回表示来源材料本身不足或存在未澄清冲突，需要补充信息后重新生成或重写摘要。结论一旦给出，应记录在缺陷工作项上，作为流转前的凭据。
第4步的二次确认只核对差异项是否关闭，不重新做全量比对，以控制复核成本。若修改引入了新的表述，复核人需判断是否产生新偏差，必要时回到第2步。放行后摘要才可进入开发流转。
复核角色分工与交付物
复核责任需要落到具体角色，否则容易出现“大家都看过、没人负责”的情况。建议设置两级：提交人自检，测试负责人或模块负责人终审。
| 角色 | 职责 | 交付物 | 时点 |
|---|---|---|---|
| 提交人 | 提交缺陷时对照字段口径自检摘要，补齐缺失字段，标注推测内容 | 自检后的摘要与来源材料 | 缺陷提交时 |
| 测试负责人或模块负责人 | 逐字段比对来源材料，给出通过、修改或驳回结论，确认修改后放行 | 复核结论、差异标注、放行记录 | 缺陷流转到开发前 |
| 复核记录（作为交付物） | 留存字段比对结果、结论、理由与修改记录 | 可追溯的复核记录 | 随缺陷工作项保存 |
提交人自检的重点是材料完整性：复现步骤能否被他人执行、日志是否附上、影响范围是否写明。自检不替代终审，终审人仍需独立比对，避免自检流于形式。
终审人通常由测试负责人担任；当缺陷集中在某一模块时，可由模块负责人终审，以便判断影响范围和结论倾向是否合理。终审人对放行决定负责，因此需要有权要求补充材料或退回重写。
争议时的升级路径建议明确两级：提交人与终审人对字段判定不一致时，先由双方对照来源材料复核一次；仍无法达成一致，升级到测试负责人与开发负责人共同确认，确认结果写入复核记录并作为该缺陷的最终口径。升级过程同样留痕，便于后续复盘。
在工具层面，复核记录需要与缺陷工作项绑定，才能支撑流转放行和事后追溯。ONES 的缺陷工作项可承载状态与记录，ONES Assistant 能理解项目、工作项和 Wiki 页面等工作上下文并执行后续操作，例如按指令创建缺陷、更新状态并通知负责人；基于权限体系的输出过程可追踪、结果可审计。将摘要复核结论记录在缺陷工作项上，配合状态流转控制，可以让“未复核不放行”成为可执行的规则，具体状态与字段配置以团队实际环境为准。
一个缺陷的复核示例
以下为演示情景，用于说明字段比对与结论判定的具体做法。
示例缺陷的原始材料：标题为“订单提交后页面卡在加载中”；复现步骤为“登录测试账号→加入两件商品→点击提交订单→页面持续显示加载中，等待三分钟无变化”，前置条件为测试环境、Chrome 浏览器；日志中有关键行“TimeoutError: payment-service response exceeded 30s”；讨论记录中开发人员提到“疑似支付服务超时，尚未确认是否与本次发布有关”。
生成的摘要草稿为：“订单提交后页面卡住，影响全站用户，日志显示支付服务超时，确认为本次发布引入的问题。”
逐字段比对发现的偏差：现象描述基本一致，但“卡住”应明确为加载中无响应；复现路径在摘要中完全缺失；影响范围写为“全站用户”，来源材料仅涉及订单提交环节，属于扩大；日志关键行未保留原始错误文本；当前结论把讨论中的推测写成“确认”，与讨论记录中“尚未确认”冲突。
复核结论为“修改”：现象表述修正、补入复现路径、影响范围改为订单提交环节、日志保留原始错误行、结论改为“疑似支付服务超时，待确认”。提交人修改后，终审人二次确认五项差异全部关闭，摘要状态更新为已复核并放行流转。修改记录中注明“影响范围扩大、推测写成结论”两类原因，供后续生成与评审参考。
复核质量与流程的完成检查
复核环节是否真正落地，可以用一组可逐项判断的检查项来验收，而不是看流程文档是否写完。
| 检查项 | 判断方法 | 达标参考 |
|---|---|---|
| 复核覆盖率 | 统计进入流转的缺陷中带复核结论的比例 | 应覆盖全部进入开发的缺陷，存在未复核即流转的即为缺口 |
| 复核及时性 | 对比摘要生成时间与复核结论时间 | 在缺陷流转到开发前完成，超出约定时限的需说明原因 |
| 修改原因归类 | 对修改与驳回记录按字段缺失、来源冲突、推测写成结论等类别归集 | 类别可统计，能定位高频问题字段 |
| 原因回流 | 检查高频修改原因是否反馈到摘要生成规则或字段口径 | 有对应的口径调整或提示补充记录 |
| 结论一致性抽查 | 定期抽取已复核缺陷，由另一名负责人独立复核并比对结论 | 结论一致或差异有合理解释，差异集中时校准判定口径 |
阻断条件需要写死并被执行：摘要未经复核不得流转到开发；复核结论为驳回的缺陷不得放行；来源材料缺失导致无法比对的，不得以“先流转后补”方式处理。这些条件应体现在缺陷工作项的状态流转规则中，而不是仅靠口头约定。
检查频率可按迭代设置：每个迭代结束统计覆盖率与及时性，每月对修改原因归类做一次汇总，每季度做一次结论一致性抽查。检查结果用于调整字段口径和复核分工，形成“复核—记录—归类—校准”的闭环。
常见问题
缺陷摘要复核由提交人自检后，终审人还需要逐字段重新比对吗？
需要。提交人自检的重点是材料完整性，例如复现步骤能否被他人执行、日志是否附上、影响范围是否写明，它解决的是“材料够不够”的问题。终审人要判断的是“摘要写得对不对”，仍需独立对照来源材料逐字段比对。如果终审直接采信自检结果，自检容易流于形式，摘要中的推测写成结论、影响范围扩大这类偏差就难以被发现。终审人对放行决定负责，因此也需要有权要求补充材料或退回重写。
摘要字段缺失和字段与来源材料冲突，复核结论应该区别对待吗？
建议区别对待。字段缺失属于可修复问题，通常退回提交人补充后二次确认即可；冲突属于需要澄清的问题，例如摘要写“影响全站用户”而来源材料只涉及订单模块，或把讨论中的推测写成已确认结论，这类情况需要提交人与终审人共同确认后再判定。把两类问题混在一起处理，会导致复核结论无法反映真实风险，修改原因归类时也难以定位高频问题字段。
复核结论为“修改”后，二次确认要不要重新做全量比对？
二次确认只核对差异项是否关闭，不重新做全量比对，以控制复核成本。但修改若引入了新的表述，复核人需要判断是否产生新偏差，必要时回到逐字段比对步骤。差异项全部关闭后，摘要状态更新为已复核，才可放行进入开发流转。二次确认的结果同样记入复核记录，与首次结论一起留存。
团队刚引入摘要复核，检查频率怎么定比较合适？
可以按迭代和固定周期分层设置：每个迭代结束统计复核覆盖率与及时性，看是否存在未复核即流转的缺口；每月对修改与驳回记录做一次原因归类汇总，定位高频问题字段；每季度做一次结论一致性抽查，由另一名负责人独立复核已复核缺陷并比对结论。检查结果用于调整字段口径和复核分工，频率可按团队缺陷量和迭代节奏调整，关键是让“复核—记录—归类—校准”形成闭环。
复核记录放在缺陷工作项上，对流程执行有什么实际作用？
复核记录与缺陷工作项绑定后，才能支撑流转放行和事后追溯：结论、理由、差异标注和修改记录都可回查，抽查结论一致性时也有据可依。在工具层面，ONES 的缺陷工作项可承载状态与记录，ONES Assistant 能理解项目、工作项和 Wiki 页面等工作上下文并执行后续操作，例如按指令创建缺陷、更新状态并通知负责人；基于权限体系的输出过程可追踪、结果可审计。将复核结论记录在工作项上，配合状态流转控制，可以让“未复核不放行”成为可执行的规则，具体状态与字段配置以团队实际环境为准。
