Bug / 缺陷如何做好严重程度？项目成员入门指南与操作步骤

同一个缺陷，在评审会上被三个人分别标成“致命”“高”和“普通”，往往不是因为谁不懂技术，而是大家把不同问题混在了一起：有人看影响范围，有人看修复紧急度，还有人按开发成本判断。做好 Bug 严重程度，关键不是给每个问题贴一个更响亮的标签，而是用一致、可复核的规则描述用户损害，并把严重程度与优先级分开管理。

一、先讲结论：严重程度描述损害，优先级决定处理顺序

1. 严重程度回答“坏到什么程度”

我建议团队把严重程度定义为：在明确的版本、环境和使用条件下，缺陷对核心功能、数据正确性、系统可用性、安全性及用户任务完成能力造成的影响等级。它描述的是缺陷造成的后果，不是发现者有多着急，也不是开发人员修起来有多麻烦。

例如，按钮颜色偏差通常不会阻断用户完成任务；订单重复扣款会直接造成资金损失。两者即使都只发生在一个用户身上，损害性质也不同。严重程度应该反映后果，而不是仅仅统计受影响人数。

2. 优先级回答“现在先做什么”

优先级还要考虑业务窗口、修复成本、绕行方案、发布计划、合同承诺和依赖关系。因此，高严重程度不一定永远排在第一位；低严重程度也可能因为发布演示、法规期限或高频曝光而需要尽快处理。

我会要求缺陷记录中至少保留两个独立字段：严重程度（Severity）和处理优先级（Priority）。如果团队只有一个“紧急程度”字段，严重程度和时间压力就会互相覆盖，后续很难复盘：问题究竟影响不大，还是当时资源不够？

这三个维度相关，但不能互相替代。一个缺陷可以“严重程度高、优先级中、修复成本高”，也可以“严重程度低、优先级高、修复成本低”。把它们拆开，团队才有可能做清晰的取舍。

2. 等级少而清楚，比等级多更有用

对多数产品团队，我倾向于先用四档严重程度：S1 致命、S2 严重、S3 一般、S4 轻微。等级越多，边界越难解释，成员越容易围绕数字争论。如果原有组织流程已经要求五档，可以保留五档，但需要为每一档写出可观察的判定条件，而不是只改名称。

不要把“P0、P1、P2”直接当成严重程度，除非团队已经明确说明它们不是优先级。字母和数字本身没有统一含义，不同公司甚至会把 P0 用作“最高优先级”，把 S1 用作“最高严重度”。字段名称与定义必须同时出现。

3. 先稳定定义，再追求精确打分

严重程度判断会受到业务类型影响。支付系统、内容社区、内部报表和开发者工具，对“不可接受损害”的理解并不相同。团队需要有一套共同底线，再允许业务线补充本地规则。

因此，我不建议一开始就用复杂加权公式算出小数分数。输入数据如果不一致，公式只会把主观判断包装得像精确测量。更实用的顺序是：先定等级定义，再统一证据字段，最后用复盘数据检查边界是否需要调整。

二、为什么严重程度经常标不一致：从真实工作场景看

1. 同一缺陷可能同时具有多个影响维度

以“导出报表后，部分用户看到旧数据”为例，测试人员可能关注导出功能是否可用，产品经理关注报表是否可交付，数据负责人关注数据准确性，客户成功则担心客户据此做错决策。所有人说的都可能是真的，但他们讨论的是不同影响。

如果缺陷单只写“报表有问题”，团队就会把讨论时间花在猜测范围上。我会把问题拆成四个核查点：哪些用户受影响、哪些数据不正确、错误是否会扩散到下游、用户有没有办法识别和纠正。等级判断应建立在这些事实之上。

2. 入口信息不完整，会把讨论变成印象投票

缺陷标题写“登录失败”，并不足以支持定级。是全部用户无法登录，还是特定浏览器偶发失败？是否只发生在新账号？用户能否通过验证码或重试恢复？发生在生产环境还是测试环境？缺少这些信息时，成员通常会用自己见过的最严重场景补全空白。

这会制造两类相反的偏差：一类是过度升级，先按最坏情况报高等级；另一类是过度降级，认为“我这边没复现”就当作影响很小。合理流程不是要求报告人一开始就给出准确答案，而是让报告人提供事实，让负责人补齐判断所需信息。

3. “技术上难修”不等于“用户影响严重”

有些缺陷只影响一个低频管理页面，但需要改动底层权限模型，开发成本很高；有些缺陷只需修改一行配置，却可能导致所有订单无法提交。修复难度影响排期与方案，不应反过来改变缺陷造成的损害等级。

如果团队把难修问题标成高严重度，严重程度就变成了开发压力的代称。长期看，这会让真正的用户风险被稀释，也会导致管理者无法基于缺陷数据识别产品质量变化。

4. 复现概率和损害程度不是一回事

一个问题发生概率很低，但一旦发生会造成不可逆的数据损失；另一个问题每天都能看到，但只影响一个非关键展示细节。前者的风险不能仅凭低频被判成轻微，后者也不能仅凭频繁出现就自动判成致命。

在初始定级时，我会分别记录“发生频率或复现条件”和“单次发生的损害”。两者合起来帮助判断风险，但最好仍保留严重程度和优先级字段。若团队采用风险矩阵，还要明确它是辅助排序工具，而不是悄悄替代严重程度定义。

5. 争议往往是流程设计问题，不是成员态度问题

当缺陷级别靠会上争辩决定，团队很容易认为是某些成员“太敏感”或“总想抢资源”。我的经验判断是，反复争吵通常说明至少有一项没有被定义：影响范围、核心任务、数据损害、绕行方式，或谁拥有最终定级权。

因此，处理一致性问题时，与其要求大家“提高判断能力”，不如拿出近期分歧案例，把相同事实重新套入判定规则。如果规则仍然得出不同结果，就补充边界；如果事实并不相同，就补充报告模板。

三、常见误区：这些做法会让等级失去含义

1. 把用户声音大小当作严重程度

客户在群里连续催促，说明问题有沟通压力，但不能单独证明损害严重。反过来，没有人投诉也不代表问题不重要：用户可能尚未发现数据错误，或者已经默默放弃任务。

我会把投诉量、客户级别和业务窗口用于优先级讨论，同时把实际损害、受影响范围和恢复方式用于严重程度判断。高价值客户的问题当然值得重视，但不能因为客户身份直接改变缺陷事实。

2. 把“所有人都会遇到”作为唯一的高等级条件

影响人数是重要因素，但不是唯一因素。一名用户发生不可逆资金损失，未必比一百名用户看到轻微排版偏差更轻；同样，一项核心流程对所有用户不可用，往往比同范围的非关键展示问题更严重。

判定时要同时看范围和损害性质。建议记录受影响用户比例、受影响租户数量、关键客户或地区限制，以及受影响任务的重要性。只写“影响面大”而不说明为什么会造成损害，仍然不够。

3. 把“偶现”直接等同于低严重度

偶发描述的是复现概率或触发条件，不是后果。比如并发条件下偶发重复提交，一旦发生可能造成重复扣款。缺陷单应分别写“出现条件有多窄”和“触发后造成什么结果”，再决定当前等级和处理优先级。

对于暂时无法稳定复现的问题，可以先标记为“待评估”或“信息不足”，并设定补证责任人与时间点。强行塞进低等级，会让未知风险被误认为已确认安全。

4. 把“没有解决方案”自动判成最高等级

没有绕行方案会加重影响，但它仍然不是唯一判据。一个低频、边缘、可延后完成的任务即使没有绕行方式，影响未必达到致命；而有临时绕行方案的资金错误，也不能因此被降成轻微。

绕行方案要具体到用户可执行、可发现、可恢复。如果所谓绕行只是“联系支持团队”，就要评估响应时长、处理容量和数据一致性，不能把它当作没有成本的替代路径。

5. 把安全漏洞与普通功能缺陷用同一套标签草率处理

安全问题需要单独评估攻击可利用性、权限边界、暴露数据类型、受影响资产和缓解措施。CVSS 等安全漏洞评分体系服务于漏洞严重性评估，不是所有产品缺陷的通用评分表。把它直接套到按钮错位或报表延迟上，没有实际意义。

如果功能缺陷可能造成越权访问、敏感信息泄露或权限绕过，应启动安全事件或漏洞响应流程，而不是只在普通缺陷列表里选择一个等级。涉及安全问题时，还应限制敏感复现细节的可见范围。

6. 把等级当成责任考核工具

如果团队按“高等级缺陷数量”追责，成员会开始压低等级；如果只奖励发现高等级问题，成员可能倾向于把一般问题往上报。等级应该帮助团队做风险管理，不应直接变成个人表现的简单指标。

更有价值的复盘问题是：严重问题是否被及时发现，用户影响是否被控制，重复缺陷是否减少，定级分歧是否下降。单看某个等级的数量，无法说明质量变好还是只是标签变了。

四、专业判断逻辑：用事实逐层判断，而不是凭直觉选档

1. 先确定判断对象和证据时间点

每次定级都应该说清楚针对哪个版本、哪个环境、什么配置和什么使用场景。生产环境已确认的问题与测试环境中偶发的体验差异，不能因为标题相同就默认同级。

初次定级可以基于当前证据，之后随着影响范围、复现条件和业务后果确认而调整。等级变更不意味着前一次判断一定错误；关键是留下变更原因和依据，避免事后只看到最终结果，不知道当时掌握了什么信息。

2. 按“任务，损害，范围，恢复”四步核对

我常用四个问题把讨论从情绪拉回事实：用户原本要完成什么任务？缺陷造成了什么结果？有多少人或业务对象受影响？用户或系统能否恢复？这四个问题覆盖了大多数产品缺陷的主要判定维度。

1. 任务：明确用户试图完成的业务任务，区分核心任务、辅助任务和纯展示信息。
2. 损害：确认是否造成任务阻断、错误决策、数据丢失、资金损失、安全风险或合规影响。
3. 范围：记录受影响用户、租户、设备、地区、版本、数据类型及持续时间。
4. 恢复：确认能否重试、回滚、补偿、纠正数据，是否需要人工介入，恢复需要多久。

这套顺序的价值在于，它防止团队先选等级，再倒推理由。若某个维度暂时未知，就明确标记未知，并安排验证，而不是用猜测填补事实。

3. 建议采用四档定义作为起点

这张表是团队治理的起点，不是跨行业法定标准。尤其是“重大损害”“大范围”“替代路径有限”需要由业务负责人补充本组织的阈值，例如受影响用户比例、数据恢复时长、服务中断时间或合同约定。

4. 对边界案例使用“先看不可接受后果”的规则

如果问题可能导致不可逆的数据损失、资金损失、越权访问或合规风险，应先确认这些后果是否真实可触发，再决定是否进入高风险响应。不能因为尚未观察到损失，就把潜在风险当作不存在；也不能只凭理论可能性就不加验证地判为最高级。

我会把边界问题拆成“已证实影响”和“待验证风险”两栏。已证实影响决定当前缺陷描述；待验证风险决定是否需要临时止损、专项排查或扩大监控。两者分开，既避免低估，也避免将推测伪装成事实。

5. 把信心程度与严重程度分开记录

严重程度是当前最佳判断，信心程度反映证据是否充分。高等级、低信心的缺陷，需要快速补证或采取预防措施；低等级、高信心的缺陷，则可以按常规排期。若团队没有信心字段，可用“已确认、待验证、信息不足”作为状态。

这能避免一种常见误解：等级看起来高，就以为事实已经确定；等级看起来低，就以为没有必要继续调查。风险管理不仅关心问题有多严重，也关心我们有多确定自己已经理解了问题。

6. 安全、数据和可用性问题应设置升级触发条件

有些事项即使初判不是 S1，也应触发额外响应：敏感数据可能被未授权访问、关键业务数据持续写错、服务错误率快速增长、影响跨多个租户扩散，或无法确认问题是否仍在扩大。触发条件意味着及时拉入适当负责人，不代表自动判定最终等级。

对于符合 Google SRE 错误预算或服务等级目标管理方式的团队，可结合服务可用性指标判断故障影响与响应强度；但 SLO 是服务目标与可靠性管理工具，不是单个缺陷严重程度的替代字段。应根据产品本身的业务承诺设定，而不是照搬其他服务的数字。

五、案例与数据观察：把定级规则放进实际记录里

1. 情景案例：订单确认偶发重复扣款

以下是用于说明判定过程的匿名化情景案例，不代表公开客户数据。某在线服务在网络超时后，用户重复点击“确认订单”，特定并发条件下可能产生两笔扣款，但订单页面只显示一笔。最初缺陷单标题是“支付偶发异常”，仅凭这句话无法判断等级。

我们会补齐的信息包括：问题发生在生产还是测试环境；是否已有真实重复扣款；受影响支付渠道和版本；重复扣款是否自动退款；资金对账延迟多久；用户是否能自行发现；重复触发概率是否随流量上升。

如果核实为生产环境已发生资金重复扣除，且用户无法自行识别，通常至少需要按高风险问题处置，立即止损并确认补偿路径。若进一步确认影响大范围用户、金额持续扩大或没有有效阻断手段，就可能达到 S1。若仅在隔离测试环境出现且没有真实交易，则严重程度判断应基于潜在风险，同时注明证据边界，不能把测试演示直接写成生产损失。

这个案例说明：“偶发”不能替代影响评估，“已造成损害”和“存在潜在风险”也必须分别表达。优先级还需结合支付渠道开放时间、流量峰值、退款能力和止损开关确定。

2. 情景案例：管理后台图表颜色显示错误

假设某管理后台把负增长显示为绿色、正增长显示为红色，但具体数值正确，用户仍可以查看明细表完成分析。若这是内部低频页面，且没有自动触发决策，问题可能属于 S3 或 S4，具体取决于团队对图表可读性和误导风险的定义。

如果同一图表被用于自动审批、绩效判断或对外财务报告，颜色错误就不再只是视觉缺陷。它可能诱导用户做错决定，应进一步核实受影响人数、是否存在历史错误决策、有没有清晰数值标签，以及结果能否纠正。相同代码缺陷在不同业务上下文中，可以具有不同的严重程度。

3. 情景案例：无法登录但存在替代入口

假设新版本在某类浏览器上登录失败，但移动端和其他浏览器可用。若受影响人群占比低、工作可以在其他端完成，且没有安全风险，严重程度未必是最高档；但如果该浏览器是组织统一配置、无法自行切换，或者登录失败导致重要业务窗口错过，优先级可能很高。

这个例子需要团队把“有替代方案”从一句话变成可验证条件：用户是否有权限使用替代设备？替代操作是否会造成数据不同步？预计增加多少操作时间？如果替代路径只能靠管理员逐个处理，那它可能并不具备规模化可用性。

4. 用样本复盘判断规则是否真的能用

团队可以每月抽取一批已关闭缺陷，优先选取高等级问题、被多次调整等级的问题，以及因缺陷造成用户影响的问题。不要只看标签分布，而要检查：记录是否包含任务、损害、范围和恢复信息；首次定级与最终定级为什么不同；是否存在迟报、过度升级或未被发现的后果。

下面的样本推演用于说明复盘指标，不是行业平均值。假设抽查 120 条缺陷，团队可以观察“首次定级一致率”“补充信息后改级比例”和“缺少影响范围记录的比例”。真正重要的不是追求某个漂亮百分比，而是确认分歧是否集中在某些定义模糊的边界。

5. 复盘应看原因链，而不是只看等级数量

若本月 S1 数量增加，可能是产品变差，也可能是监控更完善、历史漏报被发现、等级定义变严格，或业务规模扩大。若 S1 数量下降，也可能只是团队不愿意上报。必须结合版本发布量、活跃用户规模、故障持续时间和用户损害一起解释。

对比数据时，建议使用相对口径，例如每 100 次发布的高严重度缺陷数、每万活跃用户对应的用户影响事件数，或高严重度问题从发现到止损的中位时间。明确统计口径、时间范围和样本来源，避免拿不同版本、不同业务线的数据做简单横向比较。

六、操作步骤：从发现问题到定级、复核、关闭

1. 第一步：报告事实，不要求提交者预先猜等级

报告者的首要任务是说明观察到什么，而不是证明问题足够严重。缺陷模板至少应有标题、环境与版本、复现步骤、预期结果、实际结果、影响对象、发生频率、证据链接和临时绕行方案。

我不建议在表单里把“严重程度”设为必填且不给“不确定”选项。这样会迫使新成员猜一个等级，表面上字段完整，实际却把不成熟的判断固化进统计。

2. 第二步：确认复现条件和影响边界

接手人先验证问题是否可复现，并区分稳定复现、条件复现、偶发、暂未复现。接着确认受影响版本、用户角色、租户、地区、设备或数据类型。如果无法验证，应记录已做的检查和仍然未知的条件。

“未复现”不是“问题不存在”。报告者可能拥有不同权限、数据状态或网络条件。对于高风险后果，团队应补充日志、监控、审计记录或安全分析，而不是仅凭某一名成员本地没有复现就关闭。

3. 第三步：套用等级定义，写出一条可核验的理由

定级记录不要只写“S2”。更好的写法是：“S2：特定版本的企业用户无法完成批量导入，单条导入仍可用；当前确认影响 3 个租户，需人工拆分处理，暂未发现数据丢失。”这句话同时说明了等级、受影响任务、范围和恢复方式。

如果使用某项目管理平台或某项目管理工具，可以配置“严重程度”“优先级”“证据状态”与“受影响版本”等独立字段，并为各等级增加解释文本和必填校验。以 PingCode 为例，适合在中大型企业或 100 人以上组织中，将缺陷记录、评审、责任人和版本节奏放到统一流程里讨论；具体字段、工作流与权限应按组织实际配置，不应把工具的默认设置当作组织标准。

4. 第四步：严重问题先控制影响，再追求原因完整

若缺陷正在扩大，处理顺序通常是先确认止损手段，例如关闭开关、回滚版本、暂停某条交易路径或限制受影响功能，再并行定位根因。不能因为根因还不清楚，就延迟可逆且低风险的止损动作。

止损也要评估副作用。关闭功能可能阻断更多用户，回滚可能造成数据格式不兼容，人工补偿可能引入重复操作。每项措施都要有负责人、影响范围、验证方式和撤销条件。

5. 第五步：用明确规则升级和降级

等级调整必须记录触发依据。升级可能来自受影响范围扩大、真实损失被证实、绕行不可用或同类故障持续出现；降级可能来自影响范围确认很小、有效修复已上线、数据可完整恢复，或最初推测的风险未被证实。

不要因为修复进展顺利就立刻降低缺陷本身的严重程度。严重程度通常描述问题造成或可能造成的影响，修复状态描述团队正在做什么。某些组织会在止损后调整当前风险评估，但应保留原始影响和调整理由，以免历史数据被抹平。

6. 第六步：关闭前验证用户后果已经处理

代码合并不等于缺陷关闭。关闭前至少要确认修复版本、回归范围、用户数据是否需要补偿、监控是否恢复，以及已知受影响用户是否获得必要告知。涉及数据损坏时，还要确认修复的是问题本身还是仅修复了后续写入。

团队可以把“已修复”“已验证”“已完成用户补救”设计为不同状态，避免开发侧已完成却把用户影响遗漏在流程之外。对于较轻微问题，流程可以简化；对于数据、安全和资金问题，关闭门槛应该更严格。

7. 一份适合入门成员使用的缺陷记录模板

8. 评审时采用限时核查，避免无限争论

多数普通缺陷不需要拉长会议。评审人可以按模板快速核对：任务是什么、损害是什么、范围多大、能否恢复、证据是否充分。如果只有一个维度有争议，就聚焦该维度补证，不必从头重辩所有背景。

若成员仍无法一致，指定有业务责任的负责人做临时判断，并写明复核时间和触发条件。对严重风险采用保守处置时，记录“先按高风险控制、待验证后复核”，比把争议隐藏在一个没有说明的等级里更诚实。

七、不同团队与不同风险下的行动建议和取舍

1. 小团队：规则保持轻量，但不要取消证据字段

小团队可以不用复杂的审批链，采用四档定义、一个缺陷负责人和每周一次短复盘。但最少仍应保留影响任务、范围、绕行方案和判断理由，否则所有知识会留在聊天记录里，人员变化后无法复用。

取舍是：轻量流程可以提高响应速度，却更依赖成员经验。可以用每月抽样校准弥补，而不是一开始就建设庞大的等级手册。

2. 中大型团队：统一定义，允许业务线补充阈值

在多产品、多团队组织中，建议统一术语、字段含义和升级机制，同时允许支付、数据、协作、基础设施等业务补充自己的风险阈值。完全统一每个业务的判断细节，可能忽略真实业务差异；完全放任各团队定义，则跨团队统计失去可比性。

以 PingCode 这类项目管理平台为例，中大型组织可把缺陷工作流、责任分派、版本关联和复盘记录放入统一治理框架，同时在不同团队使用适配的字段说明。适用价值在于流程协同与信息可追踪，不能简单推断为工具上线后缺陷率一定下降；效果仍取决于定义质量、执行纪律和复盘机制。

3. 高频发布团队：关注从发现到止损的时间

持续交付团队通常更关心问题发现后多久止损、多久恢复，以及高风险缺陷是否在发布前被拦截。对这类团队，严重程度最好关联告警、回滚能力、灰度范围与发布门禁。

取舍是，过于严格的发布门禁可能让低风险问题拖慢交付；过于宽松则可能让重大影响扩散。可以规定 S1 必须阻断发布，S2 由指定责任人评估是否阻断，S3 与 S4 进入排期，同时明确安全、数据和合规风险具有独立升级权。

4. 面向企业客户的产品：别只按受影响账号数计算

企业软件中的一个租户可能承载大量员工和关键业务。只看受影响租户数量，会把“一个大租户核心任务中断”误判为局部小问题。应同时记录租户规模、受影响角色、业务关键性和客户可用的替代流程。

取舍是，客户敏感度需要纳入服务响应，但不能变成按客户身份任意抬高严重程度。可以让严重程度保持基于影响事实，再由客户承诺、服务等级和业务窗口影响优先级。

5. 数据密集型产品：错误结果有时比系统中断更危险

服务不可用通常很显眼，错误数据却可能长时间不被发现。对报表、推荐、自动审批、风控和数据同步功能，团队要问的不只是“页面是否打开”，还包括结果是否被下游消费、错误是否可追溯、修复后能否重算。

取舍是，扩大数据影响检查会增加排查成本，但遗漏后可能造成错误决策持续累积。建议为关键数据链路建立校验、版本标记、回填机制和影响查询能力，避免每次都靠人工猜测受影响范围。

6. 安全相关问题：优先限制暴露，再补齐完整分级

疑似越权、敏感数据泄露或凭证暴露的问题，应先保护证据并限制知情范围，快速通知安全负责人。公开缺陷标题、截图或评论不应包含可直接利用的敏感信息。

取舍是，严格保密会降低跨团队可见性，过度开放又可能扩大风险。可采用分级权限、脱敏复现材料和受控摘要，同时保留普通工作项与安全事件之间的关联记录。

7. 资源不足时：允许延后修复，但不要模糊风险承诺

团队可能因为发布冻结、依赖团队排期或人员有限，无法马上修复某个高影响缺陷。此时应明确剩余风险、临时控制、负责决策的人、可接受的延后期限和重新评估条件。资源不足是排期现实，不是缺陷变轻的证据。

取舍是，暂缓修复可以保护交付窗口，但也会积累用户和运营风险。决策记录应能回答：如果不修，最坏但合理的后果是什么；团队已经采取什么缓解措施；什么信号出现时必须重新升级。

八、落地检查清单：让规则持续有效，而不是写完就搁置

1. 上线规则前，先用历史案例做校准

从过去三到六个月选取 15 至 30 条有代表性的缺陷，覆盖数据问题、核心流程中断、偶发问题、体验问题和安全疑虑。让产品、研发、测试和运营分别按新规则独立定级，再比较分歧集中在哪些判断条件。

不必追求所有成员第一次就完全一致。更重要的是，大家能否通过证据解释差异。如果分歧来自“核心任务”定义不一致，就补充业务说明；如果来自“影响范围”缺失，就改进模板；如果只是等级边界太模糊，就改等级描述。

2. 每次复盘至少跟踪四类信号

• 首次定级与最终定级一致率：观察初始判断是否稳定，同时结合样本复杂度解释变化。
• 严重问题从发现到止损的时间：关注用户影响是否得到及时控制，而不只是代码合并速度。
• 缺陷记录关键字段完整率：检查任务、损害、范围和恢复信息是否可以支撑判断。
• 重复发生与用户补救情况：确认修复是否降低复发，受影响用户是否得到必要处理。

这些指标应当用于改流程，不宜机械地变成员工排名。某个团队的一致率低，可能意味着它面对的业务更复杂，也可能意味着定义确实不清楚；要结合案例核查，不能只凭一个数字下结论。

3. 为等级规则设置复审触发条件

当产品新增支付、权限、自动决策或大规模数据处理能力时，旧等级定义可能不再覆盖新的损害类型。发生重大事故、出现反复改级、多个业务线对同一术语理解不同，或监控发现未被缺陷流程捕获的影响，也应触发规则复审。

复审不意味着每次都要重写手册。很多时候，补一条边界说明、一个必填字段或一个升级条件，就足以减少争议。规则越容易被团队在工作中调用，越有机会真正改变判断行为。

4. 下一步从三件小事开始

1. 选出最近 10 条发生等级争议的缺陷，标记争议来自影响范围、数据后果、绕行方案还是业务时限。
2. 把团队当前最常用的等级写成四档定义，并为每一档补一条正例和一条反例。
3. 在缺陷模板中增加“已确认影响、待验证风险、受影响范围、恢复方式”四项，再用一个月样本复盘是否减少改级。

我对严重程度管理的最终判断是：等级本身不是质量，能够追溯的证据、可执行的止损动作和一致的复盘方式才是质量。团队不必追求每个成员都凭直觉给出同一个答案，而应确保不同成员面对同一组事实时，能沿着同一套逻辑做出可解释的判断。

下一步不要先购买工具或增加审批层级。先拿真实缺陷验证定义，再把确定有效的规则放进工作流；遇到证据不足时明确未知，遇到真实损害时先控制影响，遇到资源冲突时把风险与取舍写清楚。这样，严重程度才会从一个被随手填写的字段，变成团队保护用户、安排工作和改进产品的共同语言。