Bug / 缺陷严重程度全流程：PMO入门指南与一文讲清

Bug 严重程度最容易被误解的地方，是团队把它当成“谁的声音更大，谁就能把级别定得更高”。结果可能是一个只影响测试环境的文案问题被标成最高级，而一个低频触发、却会造成数据错乱的缺陷被排在队尾。《Bug / 缺陷严重程度全流程：PMO入门指南与一文讲清》的核心，不是再发明一套等级名称，而是建立一条可复核的判断链：从用户影响出发，经过证据验证、风险评估、优先级决策、修复验证，最终沉淀为组织可复用的质量规则。

一、先讲核心结论：严重程度描述影响，优先级决定先后

1. 把“影响有多大”和“现在做不做”分开

我建议 PMO 在缺陷制度首页放一句定义：严重程度（Severity）描述缺陷造成的影响，优先级（Priority）描述组织何时处理它。两者相关，但不是同一个字段，也不能互相代替。

例如，支付服务在生产环境中偶发超时，影响支付成功率，严重程度可能较高；如果当前已有可靠降级方案，故障窗口短，修复可排入当日热修复，优先级仍然需要结合窗口、风险和资源确认。相反，登录页上的文字错别字影响很小，但若错误出现在当天面向监管机构的演示材料里，业务可能要求立即修正。它的紧急度可以高，严重程度却不必被抬高。

把二者分开并非术语洁癖。严重程度一旦被用来表达“我希望它先做”，团队就会通过抬高等级争取资源，缺陷数据失去比较意义；如果优先级又只按严重程度自动生成，业务窗口、缓解方案和修复成本就会被忽略。

2. 用四个维度给严重程度定锚

成熟的判断不靠“看起来很严重”，而是至少考虑四项：受影响功能、受影响用户或业务范围、影响后果、可用替代方案。必要时再加上发生概率、持续时间、数据可恢复性和合规风险。

• 功能影响：是单个控件异常，还是核心业务流程中断？
• 范围影响：是单个账号、特定版本、一个租户，还是所有用户？
• 后果影响：是体验不佳，还是资金损失、数据丢失、权限越界或合规事故？
• 缓解能力：用户能否绕过？运维能否回滚？数据能否恢复？替代流程是否可靠？

我倾向于先定影响，再讨论发生概率和处理时限。这样可以避免把“发生少”误判为“影响轻”，也能避免把“修起来很难”误判为“缺陷本身很严重”。

3. PMO 应交付的是决策机制，而不是一张等级表

一张 P0 到 P3 的定义表只能解决“叫什么”，不能解决“谁来判断、依据什么、何时升级、谁能改级、改级后通知谁”。PMO 真正要维护的是一套可审计的决策机制：统一字段、证据要求、责任边界、升级时限、例外流程和复盘闭环。

下文的等级示例是可配置的起点，不是行业标准。ISO/IEC 25010 描述软件产品质量模型，ISTQB 的测试知识体系也强调缺陷影响与处理紧急程度应分别理解；但公开标准并未规定所有组织必须采用相同的 P0、P1 或 S1、S2 划分。等级名称可以因团队调整，判断口径必须能被不同团队重复使用。

二、背景和真实场景：为什么缺陷等级会变成组织问题

1. 同一个缺陷，在不同团队眼里可能是不同问题

产品经理看到的是用户能不能完成任务，研发看到的是根因和修改范围，测试看到的是复现概率与回归面，运维看到的是生产风险，客服看到的是用户投诉量，合规团队关心的是数据和审计要求。每种视角都合理，但如果没有统一判断框架，缺陷评审就会变成角色之间争夺定义权。

常见争议不是“缺陷到底存在不存在”，而是缺少能连接这些视角的证据。例如，测试报告写“偶发失败”，产品经理追问影响多少用户，研发判断需要重构，运维担心发布风险，PMO 却只能看到一个严重程度字段。没有环境、版本、账号范围、复现步骤、日志和业务后果，等级只能依赖资历和情绪。

2. 缺陷等级会影响资源、发布和风险接受

严重程度不是静态标签。它会影响是否阻断发布、是否启动应急响应、是否需要管理层知情、是否要通知客户、是否接受带缺陷上线，以及后续是否计入质量指标。等级规则因此会改变团队行为：如果最高级缺陷自动触发处罚，成员可能倾向于降级；如果高等级能获得更多人力，提交方可能倾向于升级。

这也是 PMO 要关注治理设计的原因。组织不能只要求大家“客观一点”，还要让如实报告缺陷比隐藏缺陷更安全，让级别调整有记录，让责任归因与事实判断分开。

3. 不同业务不能照搬同一套影响权重

对内容管理系统来说，页面展示异常可能主要影响体验；对交易系统来说，同一类异常可能导致重复扣款或订单状态不一致。医疗、金融、工业控制、身份与权限系统，还需要显式考虑人身安全、资金损失、隐私泄露、审计责任和监管义务。

因此，PMO 可以统一缺陷流程和字段，但不应强迫所有业务线使用完全相同的严重程度细则。适合的做法是建立组织级通用底线，再由业务负责人和质量负责人补充领域风险规则，并将例外写进制度，而不是靠口头默契。

4. 工具能记录过程，但不能替代判断

在 100 人以上、跨团队协作较多的组织中，缺陷常常经过需求、研发、测试、发布、运维和客服多个环节。类似 PingCode 这类项目管理平台，可以用于关联缺陷、需求、版本、测试结果和处理记录，降低信息散落的风险；但字段填得完整，不代表等级判断一定正确。

我会把工具配置看作制度落地的最后一公里，而不是治理本身。先定义字段、角色和流程，再配置权限、提醒、报表与关联关系。若反过来先建一堆必填项，团队通常会为了通过校验填入“其他”“未知”或复制粘贴，表面完整，实际无法决策。

三、拆解常见误区：等级失真通常不是填错一个字段

1. 把严重程度和优先级合并成一个“紧急”标签

如果缺陷单只有一个“紧急程度”，团队就会把业务窗口、用户影响、修复难度、管理层关注和发布风险全部塞进去。短期看似省事，长期会失去可分析性：同一个等级既可能代表“用户无法继续”，也可能代表“客户在催”。

我的建议是至少保留严重程度与优先级两个字段。前者基于影响事实，由缺陷评审规则约束；后者由产品、研发、运维或业务负责人结合目标、窗口、依赖和资源协商。若组织暂时只能保留一个字段，也应在缺陷描述中明确记录影响与时限，不要让单一标签承担全部决策。

2. 按修复成本给严重程度定级

“要改很多代码”不等于严重，“只改一行”也不等于轻微。修复成本属于估算与排期信息，不是用户影响。高成本缺陷可能源于技术债，也可能只影响少量内部场景；低成本缺陷则可能暴露严重权限漏洞。

应将“影响等级”和“修复工作量”分开记录。评审时可以同时看到两者，用于决定临时措施、修复拆分和发布策略，但不要因难修就降级，也不要因为好修就自动升级。

3. 用复现频率代替影响范围

“我这边只出现过一次”不能推出“影响很小”。一次故障可能造成不可逆的数据损失，也可能发生在所有用户都很少经过的关键分支。反过来，某个展示问题每次刷新都出现，也未必比偶发的数据一致性问题更严重。

复现频率是重要证据，但它与影响范围不是一回事。建议分别记录发生频率、受影响用户比例、持续时间、触发条件和业务后果。对低频高损害事件，采用安全、隐私、资金和数据风险的单独升级规则。

4. 把“没有客户投诉”当作没有影响

投诉是滞后信号，不是完整的影响统计。用户可能没有发现问题、无法联系支持团队，或已经通过其他渠道放弃使用。内部系统、批处理任务和服务间接口更可能在没有客户声音的情况下持续产生错误结果。

因此，评估影响不能只看工单和客服反馈，还应结合日志、监控、业务指标、数据校验和版本覆盖情况。对于用户可见性低但后果严重的问题，主动监测比等待投诉更可靠。

5. 认为等级一旦确认就不应变化

严重程度应当随证据变化而更新。初始报告可能只证明某个账号出现异常；随后日志显示同一版本的多个租户受影响，等级就应上调。也可能经排查发现只是测试数据失配，且没有真实用户影响，等级可以下调。

改级不是承认判断失败，而是根据新信息修正决策。关键是记录修改前后的等级、证据、时间、判断人和通知对象，避免事后无法解释为什么发布决策发生改变。

6. 让提交者独自承担所有判断责任

提交者通常最先看到现象，但未必掌握业务范围、架构依赖和客户合同。要求每位报障者准确给出最终等级，等于把组织决策外包给信息最不完整的人。

更稳妥的做法是让提交者提供事实，系统或规则给出初始建议，由明确角色复核。缺陷发现者不必为“判断不准”受罚；有权限的人则需要对升降级理由负责。

7. 只优化平均修复时间，忽略风险分布

平均修复时间下降，并不一定代表高风险缺陷处理得更好。如果大量低等级问题很快关闭，平均值会被拉低，但最严重缺陷可能仍然长期挂起。平均数也容易掩盖长尾：大多数缺陷几小时解决，少数高风险问题却拖过多个版本。

建议同时观察不同严重程度的修复时间分布、超时比例、重开率、发布逃逸率和重复缺陷率。管理层看板应让风险可见，而不是只展示一个总体平均数。

四、建立专业判断逻辑：从事实到等级，再到处理决策

1. 先把缺陷事实写完整

在讨论等级前，先回答“什么发生了”。一份可评审的缺陷记录，至少应包含：产品与版本、环境、时间、复现步骤、实际结果、预期结果、影响对象、证据链接、是否有绕行方案，以及当前是否仍在发生。

对于生产问题，还应尽可能记录错误率、影响时间段、受影响租户或服务、数据是否一致、是否存在安全或隐私风险、是否已触发监控告警。信息暂缺时，应标记“待确认”并指定负责人，不要用猜测填满缺陷单。

2. 先按后果分类，再比较范围与持续性

我建议评审顺序从后果开始，因为后果决定风险底线。先问是否涉及人身安全、资金损失、隐私泄露、权限越界、数据不可恢复、合同承诺或合规义务；再看核心流程能否完成、受影响范围多大、持续多久、是否可绕行。

这样做能避免“用户数少所以轻微”的误判。即使仅有一个账号受到影响，如果该账号暴露了其他人的敏感数据，影响等级也不应仅按人数计算。

3. 采用等级描述，不采用模糊形容词

组织可从四级开始，必要时再扩展。下面是一套通用示例，等级名称可调整，定义应结合业务风险由质量、产品、研发、运维和安全角色共同确认。

表格中的“S1”不应自动等同于“必须在某个固定小时内修完”。响应时限需要由业务连续性目标、值班安排和服务承诺另行定义。严重程度表达影响，响应时间表达服务要求，两者关联但最好分别治理。

4. 把优先级作为独立决策结果

优先级可由严重程度、业务窗口、风险暴露、修复成本、依赖关系和缓解方案共同决定。不要把一个简单加权公式包装成客观真理：不同因素的权重由组织价值和风险偏好决定，应通过历史案例校准。

例如，可以规定 S1 必须进入快速评审，但是否立即热修复，还要评估修复引入新风险的概率。若现场已有稳定回滚方案，短时间观察可能比仓促发布更安全。若问题涉及数据持续损坏，则优先动作可能是停止写入或隔离服务，而不是先追求代码修复。

5. 通过证据等级控制不确定性

缺陷评审常见的困难不是影响轻重，而是证据不足。可以把结论区分为“已确认”“高度可能”“尚待验证”，并记录证据来源。例如，日志证实某版本发生重复写入，与“用户说可能重复了”不是同一置信度。

不确定性不应自动导致降级。对于高损害、低可逆性的风险，证据不足本身可能要求先采取保护措施，再完成调查。判断逻辑应同时写明“当前等级”和“待确认事项”，避免临时结论伪装成最终事实。

6. 明确谁能评审、谁能改级、谁承担通知

角色设计要符合组织规模。一般可由缺陷负责人收集事实，测试或质量角色检查复现与影响，产品或业务角色判断流程损害，研发评估技术边界，运维判断生产影响，安全与合规角色处理专项风险。PMO 负责规则、时限、升级路径与审计，不应替代业务负责人判定业务损害。

单人团队不必照搬大型委员会。小团队可以由产品与技术负责人共同确认；跨部门组织则应设立快速升级机制，并规定高等级争议由谁在何时拍板。决策速度和决策留痕必须同时存在。

7. 将“发现、响应、止损、修复、验证、复盘”连成闭环

1. 发现：通过测试、监控、用户反馈或数据校验发现异常，保留原始证据。
2. 登记：记录版本、环境、复现步骤、影响对象和业务后果，缺失项标注负责人。
3. 初判：按规则给出暂定严重程度，并标记证据置信度。
4. 响应：确定责任人、处理时限、沟通范围和是否启动事件协作。
5. 止损：必要时回滚、关闭功能、限制流量、暂停写入或提供人工替代流程。
6. 修复：记录根因、代码变更、配置调整及潜在副作用。
7. 验证：验证原问题、相关回归、数据修复和监控恢复，不以“代码已合并”直接视为关闭。
8. 复盘：对高风险、重复发生和逃逸到生产的缺陷分析系统原因，形成可追踪的预防措施。

五、具体案例与数据观察：用一个跨团队场景检验规则

1. 案例背景：偶发订单状态不一致

下面是用于演示判断方法的情景案例，不代表某一家企业的实际事故。某在线服务在一次版本发布后，少量用户反馈订单页面显示“处理中”，但支付渠道已返回成功。问题只在特定网络重试路径出现，测试环境暂未复现；客服工单数量有限，研发初期估计可能只是页面刷新延迟。

如果只看投诉量和复现频率，团队可能把它归为普通展示问题。但进一步查日志后发现，订单写入与支付回调处理存在时间窗口：部分订单状态没有及时对齐。这里需要核实的不只是页面显示，而是是否产生重复扣款、是否漏发权益、数据是否可恢复、受影响版本与用户范围是否扩大。

2. 第一次评审：先定临时等级，不急着宣布根因

初始证据仅能证明状态显示不一致，尚不能确认资金损失。此时可以给出暂定等级，并明确“支付结果与订单状态一致性待核查”。同时指定研发查日志、运维统计版本与错误率、产品梳理用户流程、客服协助确认用户反馈。

这一步的关键是把未知事项变成调查任务，而不是在会议上用“应该没事”或“肯定很严重”替代事实。如果潜在后果较大，团队可以先暂停相关路径或启用对账检查，即使最终定级还未完成。

3. 第二次评审：新证据可能改变影响与处理策略

假设后续发现，影响仅限一个版本的部分请求，支付渠道记录均可核对，没有重复扣款，但存在权益发放延迟。此时严重程度可能低于涉及资金损失的情况，但仍需依据受影响用户范围和延迟时长决定等级。若发现支付成功后订单状态永久丢失，且没有可靠对账机制，风险判断就应明显上调。

注意这里不是“发现更多用户就一定升一级”，而是新证据改变了影响范围、后果或可恢复性。等级变更应附上依据，并通知正在依赖旧等级安排工作的人。

4. 模拟数据：同一问题可能有不同风险形态

下表中的数字是情景模拟，用于展示业务指标如何支持判断，不是行业统计，也不能直接作为等级阈值。实际评审应从日志、交易流水、用户反馈和数据校验中提取证据，并说明统计口径与时间窗口。

比例较低并不能单独证明风险低。第三种形态的影响比例最低，却可能具有更高的数据恢复成本和审计风险。判断需要把比例与后果、持续时间、可逆性并列，而不能只按一个数字排序。

5. 案例的管理含义：别把修复完成等同于风险消失

假设代码修复后，测试环境复现路径通过，并完成受影响订单核对，这还不一定足以关闭风险。团队还要确认生产版本已部署、监控指标恢复、补偿任务无重复执行、客户沟通完成，且关联缺陷没有继续发生。

若同类问题过去已经出现过，复盘重点应从“谁漏测了”转向系统原因：接口是否缺少幂等保护，状态转换是否定义完整，重试机制是否可能重复处理，告警是否覆盖业务结果。只有预防措施进入验证，缺陷关闭才真正降低了未来风险。

6. 建议追踪的数据：衡量流程，而不是追责个体

PMO 可以建立一组有明确口径的观察指标。每个指标都需要说明分母、时间范围、纳入范围和数据来源，否则不同团队之间的数字不可比较。

• 首次定级一致率：抽样复核后，初始等级与评审结论一致的比例。用于观察定义是否清楚，不宜直接用于个人考核。
• 高等级响应达成率：高等级缺陷在约定时间内有人响应并采取下一步动作的比例。响应不等于修复完成。
• 严重缺陷逃逸率：在发布后才被发现、且满足组织定义的高风险条件的缺陷数量或比例。
• 缺陷重开率：关闭后因原问题仍存在或验证不充分而重新打开的比例。
• 等级变更率：缺陷在处置过程中升降级的比例，并按变更原因分类。高变更率可能说明初始信息不足，也可能说明团队及时纠正。
• 高风险超期率：超过约定处理时限仍未修复或未形成有效缓解方案的比例。
• 重复缺陷率：同类根因或同一失效模式再次发生的比例，用于检验复盘措施是否有效。

不要追求所有指标越低越好。例如，等级变更率为零看起来整齐，却可能意味着团队不愿修正判断。对 PMO 来说，更有价值的问题是：为什么变更、是否及时、是否通知相关角色、变更是否带来更好的处置结果。

六、不同阶段的行动建议：按组织成熟度逐步落地

1. 流程刚起步：先统一定义与最小字段

如果团队还在用即时消息和表格登记问题，先不要上复杂评分模型。第一阶段只需统一四级定义、严重程度与优先级的区别，以及一组最小字段：版本、环境、复现步骤、实际与预期结果、影响范围、业务后果、证据、负责人和状态。

挑选最近三个月的代表性缺陷做桌面演练。重点不是证明旧判断谁对谁错，而是找出定义中的歧义：什么算“核心流程”？“部分用户”如何估算？“可绕行”是否要验证？把争议写进规则后，再开始正式使用。

2. 团队已经规模化：建立跨职能快速评审

当缺陷跨越多个团队、发布节奏加快时，建立日常快速分流机制。对高等级缺陷规定首次响应负责人、评审参与角色和升级路径；对普通缺陷采用异步评审，避免所有问题都被拉进会议。

评审会应围绕事实推进，而不是逐条朗读缺陷单。主持人只需确认五件事：影响是否已证实、范围是否可量化、缓解方案是否真实可用、下一步由谁负责、何时重新评估。时间窗和响应承诺由组织按值班能力制定，不应直接照抄他人数字。

3. 多业务线并行：建立通用底线与领域扩展

大型组织可以由 PMO 维护共同的字段、流程状态、报表口径和审计要求，再让业务域补充专属风险项。交易业务可细化资金与账务影响，身份系统可细化权限和账户接管，数据平台可关注数据完整性、延迟和下游影响。

工具层面可通过模板、字段权限、自动提醒、版本关联和仪表盘支撑执行。以 PingCode 这类平台为例，适合把缺陷关联到需求、测试、版本和处理记录，让不同角色在同一条记录上协作。配置时应避免把每个业务细节都变成全员必填字段，通用模板只保留跨团队决策必需的信息。

4. 高风险行业：先定义不可接受后果

如果系统涉及资金、医疗、安全、隐私或监管义务，建议先由风险、安全、合规和业务负责人定义不可接受后果，再将这些后果映射到缺陷升级规则。普通四级表并不足以承载全部风险，某些安全或数据事件需要独立的事件响应流程。

此类组织应考虑证据保存、访问控制、监管报告义务、客户通知条件和恢复演练。严重程度不能只依赖影响用户数，因为少量对象受到的损害也可能不可接受。

5. 发布频繁的团队：把缺陷判断接入发布门禁

发布门禁不宜简单设置为“存在某等级缺陷就禁止发布”。需要同时检查缺陷是否已验证、是否有缓解措施、是否由有权限的负责人接受残余风险、回滚能力是否可用、监控是否覆盖风险点。

可将发布决策分成三类：阻断发布；满足控制条件后有风险接受地发布；不影响发布但必须进入计划修复。每次例外都应记录接受人、理由、有效期限和复审时间，防止临时例外变成永久默许。

6. 工具和数据基础较弱：先清洁数据再做仪表盘

如果缺陷分类混乱、重复记录很多、关闭原因不一致，先治理数据字典和状态流转，不要急着向管理层展示复杂看板。错误输入被可视化之后，只会让错误显得更精确。

可以先抽样检查近 50 至 100 条缺陷，统计缺失字段、重复问题、等级变更原因和重开原因。这个样本量只是实操起点，不是统计学代表性保证；若要推断全组织情况，应扩大样本并按团队、业务和等级分层。

七、不同情形下的取舍：没有一张规则表能消除所有冲突

1. 影响明确、证据完整：快速定级并执行

若复现稳定、影响范围清楚、后果可验证，评审不应反复争论定义。按规则定级、确定责任人和时限，记录依据后推进。此时过多审批会增加处理延迟，却不会显著改善判断质量。

如果是高等级问题，应先采取必要的止损动作，再并行调查根因。不要把“等根因彻底查清”作为开始响应的前提。

2. 低频但后果严重：宁可先控制风险，也不按频率降级

涉及数据不可恢复、权限越界、资金损失或安全后果时，低频不意味着可以忽略。应先看后果是否可逆、影响是否可能扩散、监测是否充分、现有控制是否经过演练。

如果风险无法及时排除，可以临时采取限制功能、暂停发布、回滚或加强监控等动作。之后再依据调查结果调整等级。这个取舍的代价是短期效率下降，收益是降低不可逆损害的概率。

3. 影响较大但修复高风险：权衡热修复与安全止损

高影响缺陷不总是意味着立即改代码。若修复路径未经测试，可能引入更大故障，短期隔离、回滚或人工处理反而更稳妥。决策应比较“现有问题继续存在的风险”与“修复变更带来的新风险”。

需要保留风险接受记录，说明为什么选择某种策略、覆盖哪些用户、监控哪些信号、何时重新评估。不要把“改动很危险”当成无限期搁置高风险缺陷的理由。

4. 用户范围小但涉及敏感数据：不要用人数替代后果

一个用户的数据暴露也可能构成重大隐私事件。评估应关注数据类型、访问者、暴露时长、是否被下载或转发、能否确认删除，以及法规和合同义务。影响范围是重要维度，却不是唯一维度。

这类问题应尽早引入安全和合规责任人，限制无关人员访问证据，并遵循适用的报告和留痕要求。PMO 需要确保流程被触发，而非自行替代专业判断。

5. 低影响问题数量巨大：用组合治理而非全部抢占高优先级

大量低等级问题会挤占团队注意力。对可合并的同类问题建立根因或主题关联，对低影响项设定定期清理窗口，并观察它们是否累积成更大的可用性或维护成本风险。

取舍重点是避免两种极端：一是把每个小问题都升级成紧急任务，打断核心交付；二是把所有小问题永久搁置，直到形成系统性质量债。用积压龄期、重复率和用户任务影响来决定清理节奏，比只看单条严重程度更有效。

6. 业务要求立即修正，但实际影响轻微：提高紧急度，不虚报严重性

监管检查、客户演示、合同验收或市场活动可能创造明确时间窗口。此时可将优先级调高，安排快速修正，但仍保留低影响严重程度。这样既尊重业务需求，也不污染质量数据。

如果组织把严重程度误当成排期按钮，PMO 应推动增加优先级、目标版本或业务截止时间字段，而不是继续扩大等级定义。

7. 组织暂时无法达成一致：先记录分歧与临时控制

争议未必能在一次会议中消除。可记录不同判断、各自证据、对业务的潜在后果、临时控制措施和最终决策人。对于重大风险，先选择风险可控的临时方案，并设定重新评估时间。

比“大家先按最高级处理”更有用的，是明确最高级处理会触发什么、是否可承受、何时复核。过度上调会造成告警疲劳，过度下调会掩盖风险，二者都需要证据和责任机制约束。

八、结尾：等级的价值在于让组织更早看见风险

1. PMO 的目标不是让所有人打出一样的分数

严重程度治理的目标，不是让不同团队机械地给出同一个标签，而是让他们使用相同的事实语言，识别相似风险，并能解释差异来自哪里。只要影响定义、证据要求、升级规则和例外记录清楚，业务线存在合理差异并不意味着治理失败。

反过来，如果所有缺陷都被打成中等级，报表看起来整齐，却无法帮助组织决定发布、投入和风险接受，那才是真正的失效。好制度不是消灭判断，而是让判断可复核、可修正、可追责到决策而非个人。

2. 下一步从一轮小范围校准开始

建议 PMO 在接下来一个迭代内做三件事：抽取近期缺陷样本，找出严重程度与优先级混用的记录；让产品、研发、测试、运维和安全角色共同评审 10 至 20 个典型案例；根据争议修改等级定义、字段和升级路径，再选择一个业务团队试运行。

试运行后不要只问“大家觉得流程顺不顺”，还要检查高等级响应是否及时、等级变更是否有依据、缺陷是否在验证后关闭、发布例外是否留痕、复盘措施是否有效。若某条规则持续制造误报或阻塞，就依据真实案例调整。

3. 最终判断原则

当团队对一个缺陷的严重程度意见不一致时，我会回到五个问题：发生了什么，谁受到影响，后果是否可逆，现有缓解方案是否经过验证，哪些新证据会改变判断。答得越清楚，等级越可靠；答不清楚，就把不确定性、调查责任和临时控制写出来。

缺陷等级不是缺陷本身，也不是对团队表现的评分。它是组织分配注意力与承担风险的一种约定。PMO 把这项约定设计好，才能让有限的研发和运营资源优先投入真正会伤害用户、业务与信任的地方。