无效缺陷识别需要四类依据：需求与设计基线、可复现的现场证据、缺陷准入规则，以及判定责任与复核记录。四类依据共同回答“所报现象是否属于约定范围内的预期行为、证据是否足以支撑结论、该走哪条流程、由谁负责并如何留痕”。本文聚焦缺陷受理与分诊判定环节，给出可直接执行的判定标准、分诊步骤、角色分工、示例与检查清单。
要点总览（TL;DR）
- 无效缺陷判定需要四类依据：需求与设计基线、可复现的现场证据、缺陷准入规则、判定责任与复核记录，分别回答“是不是问题”“问题是否成立”“走哪条路”“结论是否可信”。
- 分诊按受理登记、基线核对、复现验证、准入判定、回写与通知五步推进，结论必须同时引用基线条目和证据，只写“无效”无法通过复核。
- 提交人提供现场信息，分诊人执行判定，产品与开发代表解释基线和技术判断，复核人由未参与初判者担任，争议按升级路径处理。
- 判定理由建议写全结论类型、基线条目、证据清单与后续入口四要素；依据不足时暂缓判定并列出待补信息，不把资料缺失等同于缺陷不成立。
- 定期抽样复核无效判定，用争议案例对齐准入规则与基线解释口径，减少同类问题反复争论。
判定无效缺陷的四类依据
无效缺陷判定容易滑向主观印象：有人凭经验说“这是设计如此”，有人因为复现不了直接关闭。要让结论稳定、可追溯，需要把判定建立在四类可核对的依据上。每类依据回答一个具体问题，缺一类就会在某个环节出现争议。
| 依据类别 | 回答的问题 | 具体包含的信息 | 缺失后果 |
|---|---|---|---|
| 需求与设计基线 | 所报现象是否属于约定范围内的预期行为或已知限制 | 需求文档条目、设计说明、接口约定、产品规则、已知限制清单、历史决策记录 | 无法区分缺陷与预期行为，容易把设计约定误判为缺陷，或把真实缺陷当成“设计如此”关闭 |
| 可复现的现场证据 | 现象是否真实发生、在什么条件下发生 | 环境信息（设备、系统、浏览器、网络）、版本号、复现步骤、实际结果与预期结果、日志、截图或录屏、相关数据 | 无法验证现象，判定只能依赖描述，复现失败时难以区分“不存在”与“信息不足” |
| 缺陷准入规则 | 该问题应走缺陷流程，还是转需求、咨询或重复合并 | 缺陷定义与准入条件、需求变更入口、咨询类问题分流规则、重复缺陷判定标准 | 缺陷库混入需求与咨询，重复缺陷堆积，统计口径失真 |
| 判定责任与记录 | 谁有权判定、依据什么判定、结论如何留痕 | 分诊角色与权限、判定理由字段、复核人、结论类型、通知与回写记录 | 判定无人负责或无法追溯，提交人异议时缺少复核依据 |
四类依据中，需求与设计基线决定“是不是问题”，现场证据决定“问题是否成立”，准入规则决定“走哪条路”，判定责任与记录决定“结论是否可信”。分诊时按此顺序核对，可以把大部分争议在受理阶段化解。
分诊判定步骤：从受理到结论
把四类依据落到动作上，分诊可以按五个步骤推进。每一步都有明确输入、动作、输出和完成标志，避免判定停在“看一下再说”。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 受理登记 | 提交人填写的缺陷单 | 核对最小信息集：环境、版本、复现步骤、实际结果、预期结果、日志或截图；缺项时向提交人补充 | 信息完整的缺陷单 | 最小信息集齐备，或已明确列出待补项 |
| 2. 基线核对 | 缺陷单、需求与设计文档、已知限制清单 | 对照基线条目判断所报现象是否属于预期行为或已约定限制；找到对应条目并记录编号 | 基线核对结论 | 能指出具体基线条目，或确认基线中无相关约定 |
| 3. 复现验证 | 缺陷单、测试环境 | 按提交步骤复现；复现成功则补充证据，复现失败则记录尝试条件并判断是否为信息不足 | 复现结果与证据清单 | 复现结论明确，证据可支撑后续判定 |
| 4. 准入判定 | 基线核对结论、复现结果、准入规则 | 按规则给出结论：有效缺陷、无效、转需求、咨询答复、重复合并 | 结论类型与判定理由 | 结论类型明确，理由写明所依据的基线条目与证据 |
| 5. 回写与通知 | 判定结论 | 将结论、理由、证据回写到缺陷记录，通知提交人；转需求或咨询类同步到对应入口 | 已回写的缺陷记录与通知 | 提交人收到结论与理由，记录可被后续查询 |
第2步与第3步的顺序可以按情况调整：当现象明显指向已知限制时，先核对基线可以节省复现成本；当基线中找不到对应约定时，复现验证成为主要依据。无论顺序如何，结论都必须同时引用基线条目和证据，只写“无效”两个字的判定在复核时无法成立。
角色分工与判定交付物
无效判定涉及四类角色，各自提供不同依据。分工清晰，判定才不会变成分诊人独自承担全部举证责任。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 提交人（测试、客服、用户支持等） | 按模板提交现象，提供环境、版本、复现步骤、日志与截图；配合补充信息 | 信息完整的缺陷单与现场证据 |
| 分诊人/缺陷管理员 | 执行受理登记、基线核对、复现验证与准入判定；回写结论并通知提交人 | 判定结论、判定理由、证据清单 |
| 产品代表 | 解释需求与设计基线，确认某现象是否属于约定行为或已知限制 | 基线解释意见与对应文档条目 |
| 开发代表 | 提供技术判断，协助复现与日志分析，确认是否为环境或配置问题 | 技术分析结论与复现协助记录 |
| 复核人 | 对争议判定或抽样判定进行复核，给出维持或改判意见 | 复核意见与改判记录 |
复核与争议升级路径需要事先约定：提交人对无效结论有异议时，由未参与初判的复核人处理；复核仍无法达成一致时，升级到产品与开发共同确认。复核人不应由初判人兼任，否则复核失去纠偏作用。
在工具承载上，缺陷工作项可以记录判定结论、理由与证据附件，分诊与复核通过状态和指派流转。ONES Project 支持缺陷跟踪管理，并统计缺陷状态分布，适合把判定记录沉淀在同一工作项中供后续查询；与 TestCase 数据互通后可一键提交 Bug 至对应项目或迭代，减少受理登记时的信息搬运。若缺陷来自客服或外部工单，ONES Desk 可将工单一键关联到 ONES Project 的缺陷工作项，持续跟踪至处理完成，判定结论也能沿关联关系回传给提交方。
示例：一条被判定为无效的缺陷如何走完流程
以下为演示情景，用于说明四类依据如何共同支撑无效结论，不对应真实项目。
背景与提交信息。某后台系统提交一条缺陷：在列表页连续翻页超过十页后，筛选条件被重置。提交信息包含浏览器版本、系统版本、操作步骤、实际结果与预期结果，并附有操作录屏。
基线核对。分诊人查阅需求文档，发现列表页规则中写明“翻页超过十页时重置筛选条件以控制查询性能”，该条目在需求评审时已确认，并列入已知限制清单。基线核对结论为：所报现象属于已约定限制，对应需求条目编号可查。
证据核验与复现。分诊人按提交步骤复现，现象与描述一致，录屏与日志均能对应。复现结果确认现象真实存在，但结合基线核对，该现象属于设计约定范围。
结论表述与反馈。判定结论写为：无效，理由为“该行为符合需求文档第X条关于翻页超过十页重置筛选条件的约定，属已知限制”，附基线条目链接、复现记录与录屏。通知提交人时说明判定依据，并提示如认为该限制需要调整，可走需求变更入口提交。
可迁移的判定规律。这条缺陷的关键在于“现象真实但属于预期行为”。判定理由必须同时写明现象已复现和基线有约定，两者缺一不可：只写“设计如此”无法证明已核实，只写“已复现”则没有回答为什么无效。同类判定都可以沿用这一写法：结论类型、基线条目、证据清单、后续入口四要素齐全。
判定质量检查与常见争议处理
判定质量靠事后检查与争议处理机制维持。以下检查项可在每条无效判定完成后逐条核对。
- 判定理由是否写明了具体基线条目或准入规则条款，而非仅写“无效”“设计如此”。
- 证据清单是否包含环境、版本、复现结果，复现失败时是否记录了尝试条件。
- 结论类型是否与准入规则一致，转需求、咨询、重复合并是否进入了对应入口。
- 提交人是否收到结论与理由，记录是否可被后续查询。
- 判定人与复核人是否为不同角色，复核意见是否留痕。
依据不足时应暂缓判定，列出待补信息并退回提交人或转产品确认，不能把资料缺失直接等同于缺陷不成立。提交人提出异议时，由未参与初判的复核人重新核对四类依据，给出维持或改判意见并记录理由。团队还应定期抽样复核无效判定，用争议案例对齐准入规则与基线解释口径，减少同类问题反复争论。
常见问题
提交人只提供了文字描述、没有日志和截图，分诊时应该直接判无效吗？
不建议直接判无效。缺少日志和截图属于证据不足，与“现象不成立”是两回事。处理方式是先按最小信息集列出待补项，退回提交人补充环境、版本、复现步骤和日志；如果提交人无法补充，分诊人可以按描述尝试复现，并把尝试条件和结果记录下来。只有基线核对确认属于预期行为，或复现与证据核验后确认现象不成立，才构成无效判定的依据。
复现失败时，如何区分“缺陷不存在”和“信息不足”？
关键看复现尝试是否覆盖了提交人描述的条件。分诊人应记录尝试的环境、版本、步骤和结果；如果条件与提交描述一致仍无法复现，且日志中没有对应异常，可以倾向现象不成立；如果环境、版本或数据条件与提交描述存在差异，应归为信息不足，继续向提交人确认或请开发代表协助分析。两种情况的结论表述不同，后续处理入口也不同，记录中要写清楚属于哪一种。
提交人对无效结论有异议，团队应如何复核？
由未参与初判的复核人重新核对四类依据：基线条目是否准确、证据是否充分、准入规则适用是否正确、判定理由是否完整。复核给出维持或改判意见并记录理由。复核仍无法达成一致时，升级到产品与开发代表共同确认。复核人由初判人兼任会让复核失去纠偏作用，这一点需要在流程中事先约定。
判定为无效的缺陷，后续还需要跟踪吗？
需要区分情况。属于预期行为或已知限制的无效判定，记录保留即可，提交人如认为限制需要调整，引导其走需求变更入口；属于重复合并的，跟踪原缺陷；属于信息不足暂缓判定的，保留待补状态并跟进。判定结论、理由和证据都应回写到缺陷记录中，便于后续查询和抽样复核。若缺陷来自客服或外部工单，可借助 ONES Desk 将工单关联到 ONES Project 的缺陷工作项，让判定结论沿关联关系回传给提交方。
团队刚建立分诊规则，如何减少无效判定的反复争论？
先把准入规则和基线解释口径写成可查的条目，明确缺陷、需求、咨询、重复的边界，并指定各类问题的判定责任人与复核人。运行一段时间后抽样复核无效判定，把争议案例整理成对照说明，定期校准规则。规则条目和判定记录沉淀在统一位置，新成员按同一口径执行，争论会明显减少。
