缺陷受理规则要解决的是“这条缺陷是否受理、由谁受理、按什么优先级处理”，把答案写成可判定的字段和动作，而不是停留在原则描述上。本文给出一份规则应包含的要素清单、从字段设计到上线的五步做法、角色与交付物分工，并用一条缺陷示范判定过程，最后给出上线后的检查与维护方法。
要点总览（TL;DR）
- 受理规则要写清四件事：缺陷从哪个入口进来、满足什么条件才受理、受理后归谁、多久必须响应，四者缺一规则就会退回口头协商。
- 制定按五步推进：盘点退回原因、设计受理判定表、确定优先级与时限、建立责任映射表、小范围试运行统计误判，每步都有可检查的完成标志。
- 受理判定写成受理、退回补充、转派三类结果，责任人落到具体模块角色并配备份人，优先级按影响范围与紧急度组合取值并绑定响应时限。
- 规则上线后看数据判断是否生效：退回补充比例是否可解释、责任映射是否覆盖活跃模块、超时缺陷是否被升级、定级是否稳定。
- 出现例外处理频繁、同类缺陷判定不一致、多团队来回转派等信号时，先检查判定项是否覆盖实际情形，再决定补充判定项或调整入口设计。
受理规则先定四件事：入口、判定、责任人、时限
一份能执行的受理规则，至少要把四个问题写清楚：缺陷从哪里进来、满足什么条件才受理、受理后归谁、多久必须响应。四件事缺一件，规则就会退回到口头协商。下面这份要素清单可以直接作为规则文档的目录骨架。
| 要素 | 要写清的内容 | 落地形式 |
|---|---|---|
| 受理入口 | 允许提交缺陷的渠道（缺陷工作项、测试用例失败转缺陷、线上反馈工单等），以及每个入口的提交必填字段 | 提交模板或工作项表单 |
| 受理判定 | 受理、退回补充、转派其他团队三类结果各自的判定条件 | 判定表 |
| 责任人 | 按模块或组件指定唯一责任角色与备份责任人 | 责任映射表 |
| 时限 | 各优先级对应的首次响应时限、修复排期确认时限、超时升级触发条件 | 时限表与升级路径 |
提交必填字段建议固定为：环境（操作系统、浏览器、设备或部署形态）、版本号、复现步骤、实际结果与期望结果、影响范围（受影响用户或功能范围）、附件（日志、截图、录屏）。字段的作用是让判定有据可依，缺少关键字段时受理人可以按规则退回，而不是靠追问补齐。
受理判定写成三类结果，比“收或不收”更贴近实际。信息不完整、无法复现且缺少必要材料的，退回补充并写明缺哪几项；确认属于本产品范围且信息齐全的，受理并进入分诊；确认属于其他团队或其他产品范围的，转派并注明转派依据。三类结果都要留下判定记录，便于后续统计退回原因。
责任人要落到具体角色，例如“支付模块后端负责人”，避免写“开发同学”。每个活跃模块配一名备份责任人，主责人请假或离职时由备份人接手，防止缺陷在无人认领的状态下停留。时限与优先级绑定：优先级越高，首次响应时限越短；超过时限未响应或未确认排期的，自动升级到模块负责人或团队负责人。
制定步骤：从字段设计到规则上线
规则不是一次会议讨论出来的，而是按顺序产出几个可检查的中间物。下面五步给出每步的输入、动作、输出与完成标志，团队可以按周推进。
步骤一：盘点缺陷来源与退回原因
输入是近三个月的缺陷记录，包括各渠道提交量、被退回或反复追问的记录、跨团队转派的记录。动作是逐条归类退回原因，例如信息缺失、无法复现、归属不清、重复提交、非缺陷（需求或咨询）。输出是一份退回原因分类及各类占比。完成标志是：退回原因分类覆盖当期全部退回记录，且每类都能举出至少两条实例。
步骤二：设计受理判定表
把步骤一得到的退回原因逐条转成判定条件，写成可勾选或可自动判断的字段。例如“复现步骤为空或无法按步骤复现”对应退回补充，“模块归属字段为空”对应转派或由分诊人指定。判定表按顺序排列判断项：先判信息完整性，再判是否属于本产品范围，最后判模块归属。输出是一张判定表，每行包含判断项、判断依据字段、对应结果和记录要求。完成标志是：任意一条缺陷都能按判定表走完全部判断项，且不同分诊人对同一条缺陷得出相同结论。
步骤三：确定优先级口径与响应时限
优先级用影响范围与紧急度两个维度组合取值，例如影响范围分为全部用户、部分用户、单一用户，紧急度分为阻断使用、功能受损、体验问题，组合后映射到 P0 至 P3。每一档写明首次响应时限、排期确认时限和升级对象。输出是优先级矩阵与时限表。完成标志是：分诊人能在不咨询他人的情况下为一条缺陷定级，且定级理由可以写进判定记录。
步骤四：建立责任映射表
按当前活跃模块或组件列出主责人与备份责任人，注明负责范围与交接方式。输出是责任映射表，覆盖全部活跃模块。完成标志是：随机抽取十条已受理缺陷，都能在映射表中找到唯一责任人，且不存在无主模块。
步骤五：小范围试运行并统计误判
选择一个产品线或一个迭代周期试运行，记录每次判定的结果与实际处理情况。重点统计三类数据：退回补充比例、转派后被退回的比例、定级被调整的比例。输出是试运行报告与判定表修订建议。完成标志是：试运行覆盖至少一个完整迭代，误判与退回情况有数据支撑，判定表完成一轮修订后再扩大范围。
角色与交付物分工
规则失效最常见的原因是没人维护判定表、没人对判定结果负责。把角色、职责和交付物固定下来，规则才有持续执行的基础。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 缺陷提交人 | 按模板提供环境、版本、复现步骤、影响范围、期望结果等可复现信息 | 符合模板的缺陷记录 |
| 受理人/分诊人 | 执行判定表，给出受理、退回或转派结果，记录判定依据 | 判定记录（含判定项与结论） |
| 模块责任人 | 确认缺陷归属与修复排期，指定修复人 | 归属确认与排期结论 |
| 规则维护人 | 定期复核判定表、优先级口径与责任映射，处理规则变更 | 复核报告与规则变更记录 |
分诊人与模块责任人可以是同一人，但在规则文档中要区分两个动作：分诊是判断“收不收、归谁”，排期是判断“什么时候修”。规模较小的团队可以由一人兼任，规则仍按两个动作分别记录，避免判定与排期混在一起导致责任模糊。
规则维护人通常由质量负责人或测试负责人担任，职责是每月或每迭代复核一次判定结果，检查退回原因是否出现新类型、责任映射是否覆盖新模块。规则变更要留记录：改了什么判断项、为什么改、从哪个版本或日期生效。
当缺陷记录需要在工作项中承载时，ONES Project 可用于缺陷跟踪与质量统计，支持将 Bug 提交至对应项目或迭代并记录修复情况；ONES TestCase 支持将未通过的用例快速创建为缺陷任务，使缺陷在测试与研发团队之间流转。判定表、责任映射和判定记录可以借助工作项字段与权限配置来落实，具体字段配置范围以实际产品版本为准。
示例：一条缺陷如何走完受理判定
以下为演示情景，用于说明判定表如何逐项执行。
提交人记录：环境为移动端 App 5.2.1，Android 13；版本为生产环境；复现步骤为“进入订单详情页，点击‘再次购买’，页面停留 3 秒后返回首页”；实际结果为跳转失败并返回首页；期望结果为进入商品详情页；影响范围为部分安卓用户，涉及下单转化路径；附有录屏与日志。
分诊人按判定表逐项判断：信息完整性——环境、版本、复现步骤、期望结果、影响范围、附件均已提供，通过；产品范围——属于本产品订单模块，通过；模块归属——订单详情页交互，归属订单模块前端。判定结果为受理，指派给订单模块前端主责人，备份责任人为同模块另一名前端工程师。
定级理由：影响部分安卓用户的下单转化路径，功能受损但未阻断全部用户使用，紧急度定为功能受损，影响范围定为部分用户，组合后定为 P1。按时限表，P1 要求 4 小时内首次响应、1 个工作日内确认排期，超时未响应升级至订单模块负责人。
判定记录写四项内容：判定结果（受理）、判定依据（信息完整、属于本产品范围、归属订单模块前端）、指派对象（主责人与备份人）、定级与时限（P1，4 小时响应）。退回或转派时同样记录依据，例如“缺少复现步骤，退回补充”或“属于支付网关团队范围，转派并注明依据”。
上线后的完成检查与规则维护
规则是否生效，看数据而不是看文档是否写完。建议在试运行结束和每个季度末各做一次检查，逐项核对以下内容。
- 退回补充比例是否可解释：每一类退回原因都有对应判定项，且占比变化有业务原因，例如新入口带来信息不全的提交。
- 责任映射是否覆盖全部活跃模块：新增模块、模块拆分或人员调整后，映射表已同步更新，不存在无主缺陷。
- 超时未响应缺陷是否被升级：抽查超过响应时限的缺陷，确认升级动作已发生并有人接手。
- 定级是否稳定：抽查已受理缺陷的定级，与优先级矩阵比对，定级被调整的比例处于可接受范围。
判定规则被绕过通常有几个信号：分诊人频繁在判定表之外做例外处理；同一类缺陷时而受理时而退回；缺陷在多个团队之间来回转派；提交人绕过入口直接私聊开发。出现这些信号时，先检查判定项是否覆盖了实际情形，再决定是补充判定项还是调整入口设计。
维护节奏建议与迭代节奏对齐：每迭代复核一次判定记录中的例外情况，每季度复核一次责任映射与优先级口径。规则变更采用版本化记录，写明变更内容、生效日期和影响范围，旧版本保留备查。组织调整、模块拆分合并、产品线新增或缺陷来源渠道变化时，都应触发判定表与责任映射的同步更新，更新完成后再恢复常规复核。
常见问题
团队规模很小，分诊人和模块责任人由同一人担任，规则还需要分开写吗？
可以由一人兼任，但规则文档里仍建议把“分诊”和“排期”记成两个动作。分诊回答的是收不收、归谁，排期回答的是什么时候修。两个动作分开记录，缺陷被退回或延迟时能看清卡在哪一环；合并记录后，判定依据和排期结论混在一起，后续统计退回原因时容易失真。
判定表设计得再细，提交人仍然绕过入口直接找开发，怎么处理？
先确认绕过的原因。常见情形是提交模板字段太多、入口不好找，或者提交人认为走入口会更慢。可以精简非必要必填项、把入口放到提交人日常使用的页面，并明确绕过入口的缺陷不进入响应时限计算。规则层面保留例外通道，但要求例外缺陷补录判定记录，这样既不堵死紧急情况，也能统计绕过的规模。
优先级定级经常被模块责任人调整，说明规则有问题吗？
少量调整属于正常，比例持续偏高则要复查。先看调整集中在哪一档：如果集中在影响范围的判断上，说明影响范围的取值口径不够具体，需要给出可对照的例子；如果集中在紧急度上，说明紧急度与业务节点的关系没有写清。复查后修订优先级矩阵，并把典型调整案例补进判定记录，让分诊人有参照。
组织调整或模块拆分后，受理规则要改哪些部分？
至少同步三处：责任映射表中的主责人与备份人、判定表中模块归属的判断项、升级路径中的升级对象。模块拆分后原责任人可能只覆盖其中一部分，需要重新指定；新增产品线或提交渠道时，还要补充对应的受理入口与必填字段。变更采用版本化记录，写明改了什么、从哪天生效，旧版本保留备查。
缺陷记录放在工作项里管理时，判定表和责任映射怎么落地？
可以把判定项对应到工作项字段，例如环境、版本、复现步骤、影响范围、模块归属，让分诊人按字段填写并留下判定依据。ONES Project 可用于缺陷跟踪与质量统计，支持将 Bug 提交至对应项目或迭代并记录修复情况；ONES TestCase 支持将未通过的用例快速创建为缺陷任务，使缺陷在测试与研发团队之间流转。字段配置的具体范围以实际产品版本为准。
