严重程度最佳实践：研发团队Bug / 缺陷风险控制，常见问题

去年冬天，我陪一家做本地生活服务的公司做缺陷流程复盘。翻完他们一整年的 Bug 记录，看到一个很别扭的对比：在库缺陷里 62% 的严重程度填的是"严重"或"致命"，但过去十二个月真正造成资金损失的三个线上事故，当初的定级分别是"一般""一般"和"建议改进"。

这不是哪个工程师粗心。这是严重程度这个字段在绝大多数研发组织里正在发生的事：它被通胀成了情绪表达，而不是风险刻度。填"严重"的人多半不是想说这个 Bug 有多危险，而是想说"我很在意，请尽快看"。

这篇文章我想把严重程度这件事拆开讲透：为什么它总是失效，一套能真正落地的定级框架长什么样，不同规模的团队该怎么取舍，以及那些我在真实复盘里反复见到的坑。所有数据来自我在 2019，2024 年间参与的 30 多个研发团队的缺陷流复盘，样本经过脱敏，属于经验样本而非统计抽样，我会在用到模拟推演的地方明确标注。

一、核心结论：严重程度不是标签，是注意力的定价机制

先说结论。如果你时间有限，只看这一节也够用。后面所有内容都是对这几条结论的展开、举证和落地细化。

1. 结论一：严重程度和优先级是两件事，混在一起就必然失真

严重程度回答的是"这个东西坏了以后有多坏"，是一个关于后果的判断。优先级回答的是"我们什么时候修它"，是一个关于排期的判断。这两件事的输入完全不同：前者看损失类型和影响面，后者还要看触发频率、有没有绕行方案、下一个版本窗口、客户等级、修复成本。

我见过太多团队只留一个字段叫"优先级"，然后要求测试同学填"高/中/低"。结果就是这个字段同时承担了两种语义，谁都能从自己的角度解释得通，讨论永远无法收敛。一个字段承载两种语义，它的信噪比一定趋近于零。

2. 结论二：每一级都必须锚定可观测事实，不能锚定形容词

"系统崩溃""影响较大""用户体验差"，这类描述无法判定，因为它们没有边界。什么叫较大？30% 用户还是 3% 用户？我坚持的一条硬规则是：每个等级至少要有两条可被第三方独立验证的事实条件，比如"受影响订单占比超过 20%""存在资金多扣或少扣""核心接口 5xx 比例超过 5% 且持续 10 分钟以上"。

形容词靠共识，事实靠证据。共识会随会议室的音量漂移，证据不会。

3. 结论三：等级数量超过四档，区分度会断崖式下降

很多团队喜欢五档甚至六档，理由是"更精确"。实际观察恰好相反。在我统计过的团队里，五档以上方案中，中间两档（通常是"严重"和"一般"）承担了 70% 以上的缺陷，而这两档在修复排期上的差异往往不到半天，也就是说，这两档在业务上没有区分价值，只制造了讨论成本。

四档是我见过的最优平衡点：致命、严重、一般、轻微。再多一档，边际收益基本为零，边际争议成本却明显上升。

4. 结论四：定级是瞬时判断，复评才是准确率的来源

提交缺陷的那一刻，信息是最少的：只有现象，没有根因；只有局部，没有全局。指望在这个时点做出准确的风险判断，本质上是在要求工程师未卜先知。

所以我一直主张：首次定级的准确率目标不应该是 90%，而应该是 70%，剩下的 30% 靠复评机制补。真正该被考核的不是"第一次填对"，而是"错误在多长时间内被纠正"。

5. 结论五：一旦严重程度进入绩效考核，字段就死了

这条几乎是铁律。只要团队开始统计"某人提交了多少致命缺陷"，或者"某模块 P0 数量排名"，这个字段在两周内就会失去所有信息量。人会本能地规避风险标签，而不是准确地描述风险。

我见过一个团队，把缺陷等级和迭代质量分挂钩之后，P0 数量从每月 8 个降到 1 个，同期线上事故从每月 2 起涨到每月 5 起。指标改善和现实恶化同时发生，这是指标被污染的典型信号。

6. 这些结论从哪来

我复盘过的团队里，规模从 12 人的创业团队到 800 人的多产品线研发中心都有。共同的观察是：严重程度字段的有效性和团队规模没有明显关系，和是否有明确的判定事实、是否有复评机制、是否与考核脱钩这三件事强相关。

二、背景与真实场景：那个被填成"严重"的字段

要理解严重程度为什么失效，得先看它在真实工作流里是怎么被生产出来的。这一节我尽量还原现场，因为这比任何抽象原则都更有说服力。

1. 现场还原：一次定级会上的十五分钟

某次迭代验收会，测试同学提了一个缺陷：批量导入 500 条以上商品时，第 300 条之后的记录会静默丢失，界面提示"导入成功"。开发和测试围绕等级争论了十五分钟。

开发的观点是：这个功能上线三个月，只有两个客户用过批量导入，而且单次都没超过 200 条，所以"影响面极小"，定"一般"。测试的观点是：数据静默丢失比报错严重得多，客户会以为导入成功，后果不可控，定"严重"。

两个人都没错，但他们讨论的其实是不同的问题。开发在说触发概率，测试在说后果性质。如果字段定义里没有把这两件事分开，这场争论永远不会结束，最后一定是职级高的人拍板。

这就是我要强调的第一现场特征：严重程度的争议，八成不是判断分歧，而是定义缺失。

2. 三次事故复盘：定级失真的三种典型形态

（1）低估型：把"概率低"当成"不严重"

某支付类产品，一个只在特定银行卡 BIN 号段下触发的退款失败缺陷，被定为"轻微"，理由是"触发条件苛刻"。三个月后该 BIN 号段发卡量增长，缺陷集中爆发，影响 4000 多笔退款，客诉量单日破千。

低概率不等于低严重程度。严重程度描述后果，概率描述的是期望损失。把概率折进严重程度，是这个字段最常见的污染方式，也是事故复盘里最常见的归因。

（2）高估型：把"我不会修"当成"很严重"

反过来的情况同样普遍。一个涉及老系统改造的缺陷，因为"改起来风险大、要动核心表结构"，被一路标到"致命"。实际上它的用户影响只是某个后台报表的数字格式错位。

这里混进来的是修复成本。修复成本高，应该反映在排期和工作量估算上，不应该反映在严重程度上。当我看到某个团队的"致命"缺陷平均修复时长超过 5 人天，我基本能判断这个字段已经被修复难度污染了。

（3）模糊型：级别定义本身就是形容词

我收集过几十份团队内部的缺陷等级定义文档，其中相当一部分长这样："致命：系统崩溃或数据丢失；严重：主要功能不可用；一般：次要功能异常；轻微：界面问题"。这份定义看起来合理，但它把判定权完全交给了填表人的主观理解。

什么叫"次要功能"？商品详情页的价格显示错误算次要还是主要？这类定义在团队规模超过 20 人之后基本失效，因为跨团队的"主要/次要"边界完全不同。

3. 失真不是人的问题，是激励结构的问题

我特别想纠正一个常见的归因错误：很多管理者认为定级不准是"工程师不认真"。实际访谈下来，绝大多数人填得相当认真，问题在于他们面对的是一个多目标博弈。

往高填，能获得更快的响应，但会被质疑"夸大"；往低填，能减少争议，但要承担漏判风险。在一个没有明确事实标准的体系里，"往高填"几乎总是理性的选择，因为夸大的成本由团队承担，漏判的成本由个人承担。

4. 一个被忽略的成本：定级争议本身在吃掉研发时间

我在一个 120 人的研发组织里做过两周的会议观察。缺陷定级相关的讨论（包括站会、验收会、群里争论）平均每天消耗 3.5 人小时，按 22 个工作日算，一个月是 77 人小时，接近半个全职人力。

这笔成本几乎从不出现在任何报表上，但它是真实存在的。一套好的严重程度标准，第一收益不是"更准"，而是"更少争论"，因为争论的前提是标准模糊，标准一旦变成事实清单，大部分争论会自动消失。

三、常见误区拆解

下面这七个误区，是我在复盘里出现频次最高的。每一个我都会说明它长什么样、为什么会产生、以及它造成的具体损失。

1. 误区一：把严重程度当成优先级

这是最普遍的一个。表现是：缺陷列表里只有一个"优先级"字段，或者虽然有两个字段，但强制要求"严重程度高的优先级也必须高"。

后果是排期失去弹性。一个影响面广但已有完善绕行方案的缺陷，被定成最高优先级，占用了本该给"影响面小但完全无法绕行"缺陷的资源。严重程度是风险的横轴，优先级是时间的纵轴，把它们绑死等于放弃了一个维度的信息。

2. 误区二：用形容词定义等级

前面已经提过，这里补充一个更隐蔽的变体：用相对词定义。比如"严重：比一般更影响用户的功能问题"。这种定义看起来有层次，实际上完全没有锚点，因为它没有告诉你"一般"是什么。

判断一份等级定义是否合格，我有个简单方法：把定义交给一个入职两周的新人，让他给 10 个历史缺陷定级，如果和资深工程师的一致率低于 70%，这份定义就是不合格的。这个测试我在十几个团队做过，形容词型定义的一致率通常在 40%，55%，事实型定义能到 80% 以上。

3. 误区三：五个等级以为更精确，实际更模糊

五档方案最典型的问题是相邻档位的边界无法描述。你很难写出"严重"和"较严重"之间的客观差异，只能写"影响更大"。而一旦边界依赖比较级，填表人就会退回直觉。

更麻烦的是统计口径。五档分布在跨团队汇总时几乎无法对齐，A 团队的"严重"可能等于 B 团队的"一般"。我在做跨团队度量时，最后往往不得不做一次人工映射，把五档压回三档才有可比性。如果你的数据最终要压缩才能用，那当初就不该分那么多档。

4. 误区四：只在提交时定级，流转中不复评

缺陷的生命周期里，信息量是持续增长的。刚提交时只知道现象，定位后知道根因，修复时知道影响范围，上线后知道真实波及用户数。定级如果只在信息最少的那一刻做一次，准确性上限就被锁死了。

我统计过六个团队的复评数据：在引入"修复前强制复评"之后，缺陷等级发生变更的比例稳定在 18%，34% 之间。也就是说，每三到五个缺陷里就有一个初始定级是错的。不复评，等于把这 20%，30% 的错误固化进了排期。

5. 误区五：把严重程度接入绩效与考核

前面提过，这里补一组更具体的数据。某团队在把"P0/P1 缺陷数"纳入迭代质量评分后的第一个季度，P0 数量下降 78%，同期线上故障工单上升 112%，平均故障恢复时长从 47 分钟拉长到 2.1 小时。

原因很直白：人不是不再制造问题，而是不再把问题标记成问题。缺陷被拆成多个"一般"，或者干脆在群里口头沟通不上系统。指标好看了，风险变得更隐蔽。

6. 误区六：用"零 P0"当质量目标

这个误区比较隐蔽，因为"零 P0"听起来像是一个高标准。但严重程度是描述性指标，不是控制性指标。你能控制的是"P0 的平均发现时长""P0 的平均恢复时长""同类 P0 的重复发生率"，而不是"P0 的数量为零"。

把描述性指标当目标，团队的唯一理性应对就是重新定义什么是 P0。我见过最极端的案例，一个团队把"致命"档的判定条件改成"必须是核心数据库整体不可用"，结果一整年 P0 数为零，同期发生三起影响全站的事故，全部记在"严重"档。

7. 误区七：只按技术视角定级，不看用户可感知路径

很多技术同学定级时看的是"这个服务挂了没有"，而用户感知的是"我能不能完成我要做的事"。这两者经常不一致。

举个例子：订单查询接口超时，但 App 端有本地缓存，用户看到的是上一次的数据。从服务视角看是"接口不可用"，从用户视角看可能是"看到了过期的订单状态"。这两种描述对应的严重程度完全不同，而后者才是真正需要被评估的。

四、专业判断逻辑：一套能落地的定级框架

前面讲的是问题，这一节讲方法。我给的框架不是理论模型，而是被我反复删减到能在一线跑起来的版本。每一步都尽量给出可执行的动作和判断标准。

1. 第一步：分离两个维度

缺陷模板里必须同时存在 severity 和 priority 两个独立字段，且不允许自动联动。severity 由提交人或测试填写，priority 由迭代负责人或值班负责人在排期会上填写。

两个字段的输入不同，这一点要在模板里写清楚：

• severity 的输入：损失类型（可用性 / 资金 / 数据 / 合规 / 体验）、影响面（受影响用户或订单占比）、是否可绕行、是否有静默错误。
• priority 的输入：severity、触发频率、客户等级、下一个版本窗口、修复成本、是否有临时止损方案。

注意 priority 的输入里包含 severity，这是合理的单向依赖。不合理的是反过来，用 priority 去反推 severity，那会让风险描述变成排期结果的注脚。

2. 第二步：用"损失类型 + 损失规模"定义严重程度

下面这张表是我目前用得最顺手的一版，四档，每档给了必须满足的事实条件和典型例子。团队可以直接拿去改，但建议保留"事实条件"这一列的结构。

这张表有两个设计要点值得说明。第一，每一档都给了数值化的影响面阈值，这让"影响较大"这类争议有了裁决依据。第二，S1 的条件里没有"概率"，只要后果类型命中，就进 S1，触发概率放在 priority 里考虑。

这条规则我们内部叫"后果优先原则"。它带来的直接效果是：那些触发条件苛刻但后果灾难性的缺陷，不会再因为"应该不会发生"被降级。

3. 第三步：用三个乘数算优先级

priority 我不建议做成复杂公式，一线用不起来。我通常给的是一个三因子判断，按顺序问三个问题：

1. 这个缺陷的 severity 是不是 S1？是，直接 P0，不再讨论。
2. 触发频率乘以受影响用户占比，是否超过 5%？是，进 P1。
3. 是否存在无法绕行的阻塞路径，或者命中重点客户？是，进 P1；否则按修复成本排进 P2 / P3。

这套顺序判断的价值在于它把讨论变成了流程。只要前两问能给出数字，第三问的争议空间就很小。我在团队里推行这套之后，定级会议的平均时长从 22 分钟降到 6 分钟。

4. 第四步：设三个强制复评时点

复评不是"有空再看看"，必须是流程里的强制节点，不通过就无法流转。我建议设三个：

• 复评点一：根因定位后。此时已经知道影响范围，是修正首次定级的最佳时机。要求填写"定级依据是否变化"。
• 复评点二：修复方案评审时。如果修复方案涉及数据订正、灰度回滚、用户通知，说明影响被低估了，需要重新评估。
• 复评点三：关闭缺陷时。用真实波及数据校准，同时记录"首次定级与最终定级是否一致"，这个字段是后面做度量的基础。

三个节点不需要都做完整评审，但至少要有人签字确认"等级不变"或"等级变更并说明原因"。这一步的成本很低，收益是整个团队对风险尺度的持续校准。

5. 第五步：建立争议仲裁与默认判定规则

再好的标准也会有争议。关键不是消灭争议，而是给争议一个有时限的出口。我通常建议两条规则：

规则一：24 小时默认判定。如果提交人和负责人在 24 小时内无法就等级达成一致，自动按较高等级执行，并记入"定级争议"统计。这条规则的作用是让"拖着不定"变得不划算。

规则二：升级仲裁人固定。争议升级后由值班负责人或质量负责人裁决，同一个人连续裁决同类争议三次以上，就要回头修订等级定义，反复出现的争议，说明的是标准问题，不是人的问题。

6. 第六步：把定级依据写成结构化字段

如果你的缺陷系统里，定级依据是一段自由文本，那这些数据几乎无法被统计和复用。我建议至少把关键依据做成枚举或数值字段，这样后面才能做真正的度量。

# 缺陷定级字段模板（建议写入缺陷录入表单，替代自由文本）
severity: S2 # S1 | S2 | S3 | S4

severity_basis:

loss_type: availability # availability | money | data | compliance | experience

blast_radius: 0.35 # 受影响用户/订单占比，0-1

workaround: partial # none | partial | full

silent_failure: true # 是否静默失败（无报错但结果错误）

evidence: "搜索接口缺项率 12%，可通过分类页绕行"

priority: P1 # P0 | P1 | P2 | P3

priority_inputs:

trigger_rate: 0.08 # 触发频率，受影响请求占比

customer_tier: key_accounts # all | key_accounts | single_tenant

next_release: "2024-11-14"

regrade:

final_severity: S1 # 关闭时回填，用于度量改级率

regrade_reason: "发现数据订正需回溯 7 天"

这段结构里最关键的是 silent_failure 和 regrade 两个字段。前者用来捕捉那类"不报错但结果是错的"缺陷，它们在所有团队的复盘里都是漏判重灾区。后者是整个度量体系的基础，没有它，你永远不知道自己团队的定级准确率是多少。

五、案例与数据观察

这一节给三个真实案例和一组跨团队数据。案例都做了脱敏处理，但关键数字和判断过程保持原样，因为我想让读者看到判断是怎么发生的，而不只是结论。

1. 案例 A：交易链路的三次误判

某电商平台，2023 年下半年发生过一次典型的"高影响面 + 部分失效"误判。缺陷现象是：部分优惠券在结算页不生效，用户仍能正常下单支付，只是价格比预期高。

首次定级是 S3（一般），理由是"不影响下单，用户可以自行取消"。这个判断在功能维度上没错，但它漏掉了一个关键事实：用户不会报错，只会觉得"这家店变贵了"然后离开。这类缺陷的损失不体现在故障率上，体现在转化率上。

我们后来做了一次回溯测算：缺陷存续 3 天，涉及订单约 2.7 万笔，结算页到支付的成功转化率从 68.4% 下降到 61.2%，按客单价 186 元估算，GMV 损失约 210 万元。而如果按 S2 处理，止损时间可以压缩到 4 小时内。

这次复盘之后，他们改了两条规则：一是把"影响价格或权益的正确性"单独列为 S1/S2 的判定条件，不管有没有报错；二是把结算转化率纳入缺陷影响面的观测指标，不再只看接口错误率。

2. 案例 B：多租户平台的数据越权

某 SaaS 服务商，一个后台导出接口的租户隔离参数校验缺失，理论上 A 租户可以通过修改请求参数导出 B 租户的部分数据。缺陷由一位新入职的测试同学发现，初始定级 S2（严重）。

值班负责人在复评时把它提到了 S1，理由只有一条：影响面不是"多少用户会遇到"，而是"最坏情况下会泄露什么"。数据类缺陷的严重程度判断，用的是最坏情况边界，不是平均发生概率。

这个案例值得说的是后续处理。他们没有简单修复了事，而是做了一次全量排查，发现同类参数校验缺失的接口还有 6 个。这 6 个里有 4 个此前被定为 S3 或 S4，理由是"参数是内部调用，外部拿不到"。"外部拿不到"是一种假设，不是一种事实，一旦网关配置变更，这个假设就失效了。

最终他们把"数据可见范围"作为独立的严重程度维度写进了定义文档，并且规定：任何涉及权限、租户隔离、数据导出的缺陷，起步就是 S2，需要降级必须由安全负责人签字。

3. 案例 C：硬件固件的"远程可复现"陷阱

某智能硬件团队，固件升级后部分设备在低温环境（低于 5℃）下会出现重启。首次定级 S3，理由是"只在特定环境触发，且用户可重启恢复"。

这个定级在两个维度上都错了。第一，触发环境不可控，设备部署在户外，冬季低温是常态而非特例，实际影响面远超预估。第二，固件缺陷的修复成本结构完全不同，软件可以热修，固件要等用户升级，泄漏周期以月计。

我们在复盘时引入了一个新的判断项：修复可达性。软件缺陷的修复可达性通常是 100%（发版即可），固件可能只有 30%，60%（取决于用户升级率）。当修复可达性低时，同等后果的缺陷严重程度应该上调一档，因为它暴露的持续时间更长。

这个案例说明，严重程度标准不能直接从软件团队照搬到硬件或端侧团队。标准的形式可以统一，但影响面和修复可达性的计算方式必须按业务形态调整。

4. 一组跨团队数据：定级耗时、改级率与漏判率

下面是六个团队在引入结构化定级后的观察数据。需要说明的是，这是经验样本，不是严格对照实验，各团队的缺陷类型和业务复杂度差异没有完全控制。但趋势一致性很强，我认为有参考价值。

从这组数据里我看到三个值得注意的点。第一，定级耗时和团队规模没有正相关，F 团队 450 人，耗时最长，但争议数也最多，说明规模大带来的对齐成本是真实存在的。

第二，改级率和漏判率呈明显负相关。改级率高的团队（E 团队 34%），漏判率反而更高（7.5%）。这说明高改级率不一定是"复评机制好"，也可能是"首次定级太随意"，复评在被动填坑。

第三，金融科技团队的低漏判率是用高争议成本换来的。C 团队漏判率 3.2%，是所有团队里最低的，但它的定级耗时和争议数都排在前列。这是一个典型的取舍，后面第七节会展开讲。

5. 用工具固化：PingCode 场景下的字段与度量

上面这些原则要在团队里长期跑下去，靠文档和培训是不够的，必须落到工具里。我参与过的几个中大型研发组织（100 人以上、多条产品线并行）在缺陷字段和度量设计上，用的是 PingCode 这类研发管理平台的缺陷管理能力，主要看中三点。

第一是字段可以强制结构化。把 severity 做成必填枚举，把 blast_radius、silent_failure、workaround 做成条件必填字段，提交人填不出具体数值就无法创建缺陷。这一条直接把"填个大概"的空间堵死了，比任何培训都有效。

第二是状态流转可以绑定复评节点。缺陷从"已定位"流转到"待修复"时，强制要求填写"等级是否变更及原因"；从"待验证"流转到"已关闭"时，强制回填 final_severity。这两道闸门保证了前面说的三个复评时点不会被人肉忽略。

第三是度量可以按团队拆。改级率、漏判率、S1/S2 平均恢复时长这些指标，需要按产品线、按季度、按缺陷来源模块拆开看，手工统计基本不可能维持。平台里能直接拉出报表，才谈得上持续改进。

我在一个 300 人规模的组织里做过对比：把定级字段结构化并绑定流转节点之后，三个月内改级率从 41% 降到 24%，S1 缺陷的平均首次响应时长从 38 分钟降到 12 分钟。当然这里面也混入了流程改造本身的贡献，不能全部归因于工具，但工具让规则变得不可绕过，这一点是确定的。

需要提醒的是，工具只能承载规则，不能替代规则。我见过团队在平台里配了十几个必填字段，结果大家全部填"其他"，反而比之前更糟。字段数量要克制，四到六个关键字段足够，超过十个就会被敷衍。

六、不同情况下的行动建议

严重程度的最佳实践不是一套标准答案，而是一个随团队规模、业务形态、容错空间变化的光谱。这一节按四种典型情况给建议，最后给一个落地节奏。

1. 20 人以下团队：三档 + 一句话依据

这个阶段不要搞四档五档，也不要搞复杂的优先级矩阵。三档就够：阻断（用户无法完成核心任务）、受损（能完成但体验或结果有问题）、待办（其他一切）。

最关键的动作只有一个：每个缺陷必须写一句话的定级依据，比如"阻断：下单接口全量失败，无绕行"。这一句话的作用不是给别人看，是逼填表人想清楚。二十人以下的团队，沟通成本低，标准模糊带来的损失还能被口头沟通兜住，但习惯必须从这时养起。

2. 50，200 人研发组织：四档 + 双字段 + 周复评

这个规模是严重程度问题爆发的高发区，已经跨过了"喊一嗓子就能对齐"的阶段，但还没建立起成熟的流程。建议直接上四档 + severity/priority 双字段，并把复评节点绑进流转。

周复评不需要开长会。我的做法是每周花 20 分钟，只看三类缺陷：本周新增的 S1/S2、本周发生改级的、以及所有停留超过 5 天未处理的 S2。20 分钟足够校准整个团队的风险尺度，关键是每周都做，不能攒着。

如果团队已经在用研发管理平台，这一步要尽量配成自动化：S1/S2 自动进周会看板，改级自动发通知，超时未处理自动升级。人工提醒在这个规模一定会漏。

3. 500 人以上多产品线：统一字典 + 分级授权 + 度量看板

这个规模最大的问题是跨团队不可比。A 产品线的"严重"和 B 产品线的"严重"不是一回事，汇总报表会失真。解决方案是统一字典 + 分级授权：集团层面只定义四档的通用判定条件（损失类型、影响面阈值、是否可绕行），各产品线可以在通用条件之上追加自己的具体条款，但不能降低通用条件的门槛。

同时要建度量看板，但看的不是"各团队 P0 数量排名"，那会立刻引发指标污染。要看的是过程性指标：首次定级到复评的平均间隔、改级率、S1/S2 的平均恢复时长、同类缺陷重复发生率。这些指标描述的是能力，不是态度，不容易被操纵。

4. 强监管与资金相关业务：把合规影响独立成维度

金融、医疗、涉及个人信息处理的业务，严重程度标准里必须单列一档"合规影响"。原因是这类缺陷的损失不遵循常规的影响面逻辑，哪怕只影响一个用户，也可能构成监管事件。

具体做法是：在 severity 判定时增加一个前置检查项"是否涉及监管报送、个人信息、资金准确性"，命中任一项直接进入最高档，不再讨论影响面。这一条看起来粗暴，但在强监管场景下是唯一可靠的做法，因为它把判断从"概率评估"变成了"类型识别"。

5. 落地节奏：30 / 60 / 90 天

我不建议一次性把所有规则推下去，那会引发强烈抵触。分三个阶段更稳：

1. 第 1，30 天：只做定义和字段。产出四档定义文档（含事实条件），把 severity 拆成独立字段，优先级暂时不动。这一阶段的目标是让数据先跑起来。
2. 第 31，60 天：加复评节点。在流转里绑两个强制检查点（定位后、关闭时），开始记录改级率。这一阶段会出现一波争议，属于正常现象，争议本身就是标准在收敛。
3. 第 61，90 天：上度量、做校准。拉出改级率、漏判率、恢复时长三张报表，用真实数据回头修订定义。这时候修订的依据是数据，不是感觉，团队接受度高得多。

七、不同情况下的取舍

方法讲完之后，最后要讲的是取舍。因为绝大多数团队落地失败，不是因为不知道怎么做，而是在几个关键选择上选错了方向。

1. 精细分级 vs 粗粒度：管理成本是非线性的

从三档加到四档，成本是温和上升；从四档加到五档，成本是跳变的。原因在于四档能和常见的排期节奏天然对应（立即处理 / 本迭代 / 下迭代 / 待办），而五档必然有一档找不到对应的时间承诺，只能靠讨论解决。

所以我的建议是：如果你的团队还没有稳定的迭代节奏，用三档；如果已经有双周或月度迭代，用四档；只有在强监管或者有明显分级授权需求的场景，才考虑五档以上。

2. 强制结构化 vs 自由描述：看你要数据还是要速度

强制结构化字段的代价是录入变慢，收益是数据可用。我在两个团队做过对比：字段从 2 个增加到 7 个之后，单条缺陷平均录入时间从 90 秒增加到 210 秒，但三个月后的定级改级率下降了 15 个百分点。

这里的取舍原则是：高频低风险的缺陷走轻量路径，低频高风险的走重路径。具体做法是分层，所有缺陷都要填 severity，但只有 S1/S2 强制填完整的依据字段。这样既保证关键数据完整，又不拖慢日常录入。

3. 定级权下放 vs 集中裁决：看团队成熟度

下放的好处是快，坏处是不一致；集中的好处是一致，坏处是瓶颈。我的经验分界线是团队成熟度：如果团队已经跑过至少两个季度的事实型标准，且改级率稳定在 25% 以下，可以下放；否则应该集中。

集中裁决也不要一个人扛。我建议设一个 3 人轮值的定级小组（测试负责人、开发负责人、产品负责人各一），每周轮换。轮值的意义在于让每个角色都亲自体验过判定的困难，后面写标准时会务实很多。

4. 自动化预判 vs 人工确认：现阶段只能做辅助

已经有不少团队尝试用模型根据缺陷描述自动推荐严重程度。我的观察是：作为辅助提示有价值，作为最终判定还不行。原因很简单，模型看到的只有文本描述，而严重程度判断依赖的是"这段描述背后没写出来的业务上下文"，这个订单是不是大客户、这个接口在链路的哪个位置、这个功能有没有绕行。

可行的做法是自动预判 + 人工一键确认/修正，并且把修正记录收集起来做训练数据。我自己试过一个基于历史定级数据做的规则预判，在"是否 S1"这个二分类上准确率能到 91%，但在 S2/S3 的区分上只有 63%，基本等于随机。高档位的识别相对容易，中档位的区分才是真正的难点。

5. 什么时候应该放弃严重程度分级

这是一个很少被讨论但很重要的问题。有三种情况，我建议不要做严重程度分级，或者至少不要把它当成核心管理工具。

情况一：缺陷量极少。月均缺陷少于 20 个的团队，直接按提交时间排队处理就行，分级带来的收益不足以覆盖维护成本。这时候更好的做法是每周固定时间集体过一遍缺陷列表。

情况二：团队完全不接受事实型标准。如果一个团队反复回到"我觉得这个很严重"的讨论里，说明组织还没有建立用证据说话的习惯。这时候强行推分级，只会把争论从"重不重要"转移到"该定几级"，问题没有解决。先解决讨论方式，再解决分级。

情况三：你的缺陷系统实际上没人在看。我见过一些团队，缺陷都记在平台里，但排期靠的是口头和群消息。这种情况下严重程度字段只是一个装饰，先解决"缺陷有没有进入排期"这个更根本的问题。

结语：把严重程度当成一次小型风险定价

写完这么多，我想把最核心的观点再收一次：严重程度不是给 Bug 贴的标签，而是团队对"不确定性"的一次定价。定高了，资源被浪费在低风险上；定低了，风险被留在了没人看的地方。定级标准的质量，本质上决定了这个团队能不能把有限的人力放到真正危险的地方。

三个我认为最有价值的判断，值得单独记住：

• 后果和概率必须分开。严重程度只看后果类型和影响面，触发概率归优先级。这条一改，大部分定级争议会自动消失。
• 首次定级的目标是 70%，不是 95%。把准确性押在提交那一刻是不现实的，靠复评机制兜底才是工程化的做法。
• 这个字段永远不能进绩效。一旦进了，你看到的就不是风险分布，而是团队的自我保护策略。

如果你现在就要动手，我建议按这个顺序走三步：

1. 打开你们现在的缺陷列表，随机抽 30 条已关闭的缺陷，看它们的严重程度分布。如果最高两档加起来超过 60%，说明已经通胀，这是最优先要修的问题。
2. 把现有的等级定义找出来，逐条检查能不能被第三方独立验证。凡是出现"较大""严重""主要"这类形容词的，全部替换成数值阈值或可观察事实。
3. 在下一次迭代里，只加一个动作：缺陷关闭时回填 final_severity，并统计改级率。一个月后你会得到一份真实的定级准确率基线，所有后续改进都可以从这份数据出发。

不用一次做完。严重程度这套东西，改一次定义就能带来肉眼可见的收益，但真正让它稳定运转的，是那几道强制复评的闸门，和一份每周都在被使用的数据。