重复缺陷识别最容易漏掉的，是同一根因在不同入口、不同措辞、不同环境下的多次上报。只靠提交人按标题搜一遍，很难覆盖这些情况。更稳妥的做法是把查重从“提交时人工搜索”扩展到“受理环节结构化比对”，并配合定期回扫，用可观察指标检验遗漏是否下降。ONES 可作为缺陷受理、关联与历史回查的承载工具，下文围绕流程改进展开。
要点总览（TL;DR）
- 重复缺陷识别最容易遗漏的是同一根因在不同入口、不同措辞、不同环境下的多次上报，仅靠提交人按标题搜索覆盖不到。
- 常见遗漏集中在五类：措辞差异、入口分散、根因相同但表现不同、已关闭缺陷复发、跨团队共用组件被分别登记。
- 改进按顺序推进：先统一重复判定口径与比对字段，再把查重前移到分诊受理环节，然后做跨来源合并，最后建立已关闭缺陷的复发回查。
- 这套做法需要字段相对统一、分诊角色明确、历史缺陷可检索；代价是分诊耗时增加、术语培训与跨团队协调成本上升。
- 用重复缺陷占比、误合并后重新拆分数量、复发及时关联比例、分诊平均耗时做同口径前后对照，连续观察多个周期再下结论。
当前查重做法与要达成的目标
多数团队的查重发生在提交环节：提交人输入标题后，在缺陷列表里按关键词搜一遍，看到相似记录就手工备注，看不到就继续提交。分诊人接手时，通常凭经验判断“这条是不是见过”，缺少统一的比对字段和判定规则。这种做法在缺陷量小、提交人固定时还能运转，一旦入口增多、参与角色变杂，覆盖范围就明显不够。
要优化，先要把现状记录清楚。建议基线至少包含四类信息：重复判定口径（什么算重复、什么算关联）、查重发生的时点与执行人、参与查重的角色范围、近几个周期的重复缺陷占比。基线的作用是给后续改进提供对照，避免改完之后只凭感觉判断“好像好了一些”。
目标设定上，查重追求的是把漏合并和误合并都控制在可接受范围，而非零重复。团队需要明确两件事：可接受的重复缺陷占比是多少，误合并一条缺陷的代价有多大。误合并会掩盖独立问题，漏合并会浪费排查人力，两者需要分别设阈值。目标写进书面规则，后续验证才有依据。
重复缺陷识别最容易遗漏的几类问题
遗漏往往发生在“看起来不一样”的地方。下面几类问题在受理环节最容易被放过，可以对照自身流程逐项检查。
| 遗漏类别 | 发生位置 | 遗漏机制 |
|---|---|---|
| 措辞差异 | 提交与分诊 | 同一问题被不同角色用不同术语描述，关键词搜索匹配不上 |
| 入口分散 | 客服、测试、线上监控、用户反馈 | 各来源分别登记，未做跨来源比对 |
| 根因相同、表现不同 | 不同模块、环境、版本 | 表层现象不同，底层缺陷相同，按现象搜索无法命中 |
| 复发遗漏 | 已关闭缺陷 | 问题再次出现时未回查历史记录，被当作新缺陷登记 |
| 跨团队共用组件 | 多个团队各自登记 | 底层依赖缺陷被分别上报，缺少统一归口 |
措辞差异最常见。测试人员写“登录页点击无响应”，客服写“用户无法进入系统”，监控告警写“接口超时率上升”，三条记录指向同一问题，但关键词几乎没有交集。入口分散则让问题更复杂：客服工单系统、测试用例失败、监控平台、用户反馈渠道各自成体系，没有跨来源比对动作时，同一问题会在多个系统里各登记一次。
根因相同但表现不同的情况，对查重字段的要求更高。同一底层缺陷可能在一个模块表现为数据错乱，在另一个模块表现为页面报错，在不同版本上表现程度也不同。仅比对标题和现象描述很难识别，需要把影响模块、报错信息、复现路径纳入比对范围。
复发遗漏和跨团队共用组件这两类，问题出在历史记录没有被有效利用。缺陷关闭后，关键特征没有留存，问题再次出现时无人回查；底层组件被多个团队依赖，各团队按自己的视角登记，缺少合并动作。这两类遗漏在缺陷量增长后尤其明显。
优先改进动作：从提交时查重到受理环节比对
改进建议按优先级推进，先解决判定口径和比对字段，再做跨来源合并，最后建立定期回扫。顺序颠倒容易导致动作做了但无法判断效果。
第一步，统一重复判定口径。把“什么算重复、什么算关联、什么算独立问题”写成书面规则，附上正反例。口径统一后，不同分诊人做出的判断才具有可比性，后续统计重复缺陷占比才有意义。这一步的产物是一份可执行的判定规则，完成标志是分诊人能在不讨论的情况下对样例给出一致结论。
第二步，把查重前移到分诊受理环节。由分诊人做结构化比对，提交人自查作为辅助。分诊人掌握更多上下文，能在受理时同时看到来源、影响范围和历史记录，比提交人单点搜索更可靠。比对字段建议固定为：报错信息、复现路径、影响模块、环境与版本、发生时间。字段固定后，比对动作可以从“凭印象”变成“逐项核对”。
第三步，跨来源登记时增加来源标记与合并动作。客服、测试、监控、用户反馈各自登记时保留来源标记，受理时识别同一问题的多条记录并执行合并，同时保留原始上报记录，便于追溯和统计。合并动作需要明确谁有权执行、合并后如何通知原提交人。
第四步，对已关闭缺陷建立复发回查习惯。关闭缺陷时记录关键特征，例如典型报错、触发条件、影响版本，问题再次出现时先回查历史记录再决定是否新建。这一步改变的是历史数据的可用性，让“以前修过”能被快速找到。
在工具层面，ONES 的工作项检索与关联能力可以承载上述比对动作：分诊人在受理时按报错信息、模块、版本等字段检索历史工作项，将新上报记录与已有记录建立关联或合并，并保留来源信息。复发回查时，已关闭工作项的关键特征可被检索到，减少重复登记。这些能力服务于受理环节的比对动作，具体配置需结合团队现有字段设计。
改进的适用前提与代价
这套改进在缺陷登记字段相对统一、分诊角色明确、有可检索历史缺陷库的条件下效果较好。字段不统一时，结构化比对无从谈起；分诊角色不明确时，查重责任会落空；历史库不可检索时，复发回查和跨来源合并都缺少依据。
代价需要提前说明。分诊环节耗时会增加，逐项比对字段比凭经验判断更慢；统一术语需要培训，不同角色对同一现象的表述习惯需要时间磨合；跨来源合并涉及多个团队，协调成本不低。这些投入应纳入改进计划，避免推行一段时间后因人力压力回退。
缺陷量极小或登记极不规范时，不建议直接上查重优化。此时先补登记质量，把报错信息、复现路径、影响模块等字段填完整，再谈比对和合并。另外要警惕误合并风险：过度合并会把独立问题压成一条，掩盖真实缺陷。流程中应保留拆分与复核路径，允许分诊人或提交人对合并结果提出异议并重新拆分。
如何验证遗漏是否真的减少
验证的核心是用同口径数据做前后对照，避免把缺陷量波动或统计方式变化当成改进效果。建议跟踪以下指标：
| 指标 | 观察内容 | 数据来源 |
|---|---|---|
| 重复缺陷占比 | 周期内被判定为重复的缺陷数占全部缺陷数的比例 | 缺陷登记与合并记录 |
| 误合并后重新拆分数量 | 合并后被拆分回独立缺陷的次数 | 合并与拆分操作记录 |
| 复发缺陷及时关联比例 | 复发问题在受理时被关联到历史缺陷的比例 | 关联记录与历史缺陷库 |
| 分诊平均耗时 | 单条缺陷从进入到完成分诊的平均时间 | 分诊环节时间戳 |
对照方法有两种：改进前后同口径统计，或选择部分团队分组试点对比。同口径统计要求判定规则、统计周期、缺陷范围保持一致，否则数字变化可能来自口径调整而非流程改进。分组试点适合多团队场景，试点组与对照组在缺陷量和人员配置上应尽量接近。
解读结果时注意限制条件。样本期短、缺陷量本身波动大时，单周期数据不足以支撑结论，建议连续观察多个周期再看趋势。重复缺陷占比下降的同时，如果误合并后重新拆分数量上升，说明合并动作偏激进，需要回调判定口径。分诊平均耗时增加属于预期代价，应结合重复缺陷占比的变化综合判断投入是否值得。
常见问题
缺陷量很小的团队，也需要做结构化查重吗？
缺陷量小、提交人相对固定时，提交时按关键词搜索加人工判断通常够用，可以先不做结构化比对。此时更值得投入的是把报错信息、复现路径、影响模块等字段填完整，让后续检索有依据。等入口增多、参与角色变杂、重复登记开始消耗排查人力时，再按口径、字段、跨来源合并的顺序推进。
分诊人做结构化比对后耗时明显增加，怎么控制成本？
先固定比对字段，只核对报错信息、复现路径、影响模块、环境与版本、发生时间这几项，避免无限扩大搜索范围。其次把提交人自查保留为辅助动作，让明显重复的记录在提交环节就被拦下。分诊耗时的增加属于预期代价，应结合重复缺陷占比和复发关联比例的变化综合判断，而不是单看耗时一项。
合并后发现是独立问题，流程上应该怎么处理？
流程中要保留拆分与复核路径：分诊人或原提交人都可以对合并结果提出异议，经复核后拆回独立缺陷，并记录这次拆分。拆分数量本身是有用的指标，持续上升说明判定口径偏激进，需要回调“什么算重复”的规则。把拆分当作正常纠错动作，而不是流程失败，才能避免分诊人为了少出错而不敢合并。
跨团队共用组件的缺陷，归口应该怎么定？
建议为共用底层组件指定一个归口团队或归口工作项，各团队上报时标注来源与受影响模块，由归口方判断是否与已有记录合并。合并时保留各团队的原始上报记录，便于追溯影响范围。归口规则需要提前书面约定，明确谁有权执行合并、合并后如何通知各来源方，否则跨团队协调容易停在口头。
改进推行一段时间后，怎么判断效果不是统计口径变化造成的？
关键是保持判定规则、统计周期、缺陷范围在前后两个阶段一致，口径一旦调整就要在数据上标注断点。有条件时采用分组试点，让试点组与对照组在缺陷量和人员配置上尽量接近。样本期短或缺陷量波动大时，单周期数字不足以支撑结论，建议连续观察多个周期看趋势，并同时关注误合并后重新拆分的数量是否同步上升。
