严重程度管理方法大全：项目负责人Bug / 缺陷制度设计落地清单

去年我帮一家做企业服务的公司做研发效能诊断，翻他们三个月的缺陷库，一共 2,847 条记录，其中被标成"致命"和"严重"的有 1,806 条，占 63.4%。但同一时期，他们的紧急发版只有 4 次，线上真实事故 11 起。超过六成的缺陷挂着最高级别的标签，却没有对应的处理动作发生，这已经不是某个测试同学手松的问题，而是制度失效：当所有人都能随手标最高级，最高级就不再传递任何信息。

这件事之后我把手上十几个团队的缺陷数据横向拉了一遍，发现一个很稳定的规律：缺陷等级分布的失真程度，和团队的交付节奏呈强相关，而不是和质量水平呈强相关。越是发布频繁、跨团队协作多的组织，等级通胀越严重。这篇文章我想把这套东西讲透，严重程度管理到底在管什么，制度怎么设计才不会被绕过，以及在不同规模、不同业务形态下该怎么取舍。

一、核心结论：严重程度不是标签，是资源调度契约

先把结论摆出来。我在做缺陷体系咨询时，最常纠正的一个认知偏差是：很多人把严重程度理解成"这个 bug 有多坏"，于是它变成了一个描述性字段，谁都可以凭感觉填。但它真正的身份是一份关于资源优先调度权的契约，你把它标成最高级，等于向整个组织申请"其他事情先停一停，先处理我这个"。

既然是契约，就必须有对价、有举证、有违约后果。少了任何一环，这个字段就会退化成情绪表达。

1. 分级的目的不是分类，是决定谁先动、谁出钱

我见过太多团队把严重程度当成一个"归档标签"，填完之后没有任何下游动作跟着变，排期不变、值班不变、发布门禁不变。这种情况下，分级纯粹是给报表看的，一线很快就会意识到"认真填也没用"，然后统一填中间值或者最高值。

真正有效的分级，至少在四个地方产生硬约束：谁被叫醒、谁的排期被打断、走不走加急发布通道、事后谁来复盘。如果这四个动作里没有一个随等级变化，那这套制度从设计上就是空的。

2. 严重程度必须由可观测维度决定，不能由感受决定

"严重"这个词本身没有信息量。有效的定级必须拆成几个可以被第三方独立验证的维度。我惯用的是三个：影响面（多少用户/多少数据受影响）、可绕过性（用户有没有替代路径）、时间敏感性（拖一周会怎样）。这三个维度都可以用事实陈述，而不是用形容词。

举个具体对比：一个"结算页偶现白屏"和一个"后台报表导出乱码"。前者看起来更严重，但如果白屏只在高版本 Safari 上出现、有明确的兜底跳转，而报表乱码导致财务每月对账多花两天人工，那后者的实际优先级可能更高。不带维度描述的"严重"两个字，无法支撑这种判断。

3. 制度能不能落地，取决于举证责任在谁身上

这是我认为最被低估的一条。多数团队的定级流程是：提交人填等级 → 开发看一眼 → 有异议就争论。举证责任实际上落在"反对者"身上，而反对者往往是最忙的那个人。结果就是默认通过，等级只升不降。

把举证责任倒过来：提交人必须在提交时填写影响范围、复现路径、用户可绕过方案、业务时间窗口这四项。填不全，系统自动落到默认等级（通常是中间档），并且不进入加急队列。这一条改完，我合作过的一个团队 P0 数量在两周内从每周 19 个降到每周 3 个，没有一个 bug 消失，只是没人再愿意为了一个中等问题去填那四个字段。

4. 没有降级通道的分级制度，一定会通胀

任何只允许升、不允许降的体系，长期必然收敛到最高档。原因是信息不对称：提交人比处理人更了解现场，而处理人验证成本高，理性的选择是先接受再处理。所以制度里必须有一条明确的、低摩擦的降级通道，注意是低摩擦，不是"要走审批"。

我的做法是：处理人在接单时有一次单方面降级权，不需要说服提交人，只需要在缺陷里写一句理由并 @ 提交人。如果提交人不认同，24 小时内可以申请仲裁，超过 24 小时自动生效。这个设计把"争论"从必经路径变成了例外路径，绝大多数情况下没人会为了一个等级去发起仲裁。

5. 等级必须与动作绑定，否则只是装饰

我通常要求客户在制度文档里写一张"等级，动作对照表"，明确到可以执行：P0 触发值班电话、冻结当日非紧急发布、2 小时内必须有首次响应；P1 当日响应、进入当周迭代；P2 进常规排期；P3 进需求池、按季度批量处理。没有对应动作的等级，等于没有等级。

二、背景与真实场景：为什么等级制度两周后就开始失效

制度设计得再漂亮，落地时都会遇到同一批阻力。我把这些年见过的失效场景归了五类，几乎每个团队都能对上号。

1. 场景一：全员 P0 的"狼来了"现场

前面提到的那家 2,847 条缺陷的公司，我抽样看了 50 条标为"致命"的记录。其中 31 条的影响描述只有一句话，12 条甚至连复现步骤都没有，真正符合"核心功能不可用且无替代方案"的只有 6 条。失真率 88%。

更麻烦的是后续效应：他们的值班同学告诉我，凌晨被叫起来处理"P0"，打开一看是个文案错别字，已经发生过三四次。之后再有 P0 告警，他的第一反应是先睡十分钟再看，这就是通胀的直接代价，真正的事故被淹没在噪声里。

2. 场景二：上线前夜的集体抬价

我观察到一个非常稳定的曲线：发布前 72 小时，高等级缺陷占比会陡增 2 到 3 倍。原因不复杂，发布窗口临近日，把等级抬高是阻止发布的最有效手段。这不是恶意，是理性博弈。

如果制度里没有"发布冻结期定级需双人确认"这类约束，这个曲线会一直存在。我一般建议把发布前 48 小时设为定级冷静期：期间新增的 P0/P1 必须由测试负责人和研发负责人共同确认，单人提交只能到 P2。

3. 场景三：等级一旦挂钩绩效，数据就彻底不可信

有段时间很流行把"线上 P0 数量"作为研发团队的考核指标。我见过一个团队这么做之后发生的事：三个月内 P0 数量从月均 6 个降到 1 个，看起来成果显著。但同期他们的紧急回滚次数从 2 次涨到 7 次，因为大家学会了把 P0 拆成几个 P1 分次提交，或者干脆把问题描述写得模糊一点。

结论很清楚：严重程度是调度工具，不是度量工具。拿它做考核，等于让被考核者定义自己的分数。

4. 场景四：跨团队协作时，等级被武器化

当缺陷需要跨团队处理时，等级会变成一种谈判筹码。A 团队希望 B 团队优先处理自己的问题，最直接的办法就是把等级拉满。我见过一个中台团队，他们收到的外部缺陷里 P0 占比常年 40% 以上，而团队自己内部产生的 P0 不到 5%。

这种失衡靠"沟通"是解决不了的，只能靠制度：跨团队缺陷的定级由接收方复核，或者由统一的质量委员会仲裁，而不是由提交方单方面决定。

5. 场景五：新人不敢降级，老人懒得解释

还有一个隐性成本很少被讨论。新加入的同学对业务影响面没有判断力，面对一个标着"致命"的缺陷，他没有信心说"这个其实只有 P2"，于是照单全收。而资深同学因为反复解释太累，慢慢也就不解释了。

这个问题的解法不在流程，在案例库。我要求每个团队维护一份"定级样例集"：20 到 30 条真实缺陷，附上最终等级和判断理由，新人入职第一周必须过一遍。这比任何制度文档都有效，因为人学判断靠的是类比，不是靠读定义。

三、常见误区拆解：六个让制度失效的设计错误

下面这六条，是我在评审客户缺陷制度文档时出现频率最高的错误。有的看起来只是术语问题，实际会直接导致执行走样。

1. 误区一：把严重程度和优先级混为一谈

这是最经典也最致命的混淆。严重程度描述的是问题本身的客观影响，优先级描述的是我们决定什么时候修。前者是事实判断，后者是资源决策。

两者分离才有意义。一个严重程度很高但已经有稳定绕过方案的问题，优先级可以很低；一个严重程度中等但正好卡在明天大促路径上的问题，优先级可以很高。如果把两者合并成一个字段，你就同时失去了客观性和决策弹性。

2. 误区二：盲目照搬五级分类

致命 / 严重 / 一般 / 轻微 / 建议，这套五级分类在教科书里很常见，但在实际执行中，"严重"和"一般"的边界几乎没有团队能稳定区分。我做过一个小实验：让 8 位测试同学对同一批 30 个缺陷独立定级，五级制下的一致率只有 52%，改成三级制后升到 79%。

我的建议是：团队规模在 200 人以下、业务相对单一的情况下，三级足够（阻断 / 影响 / 轻微）。超过这个规模、或者有强合规要求，再考虑四级。级别越多，边界越模糊，争议越多。

3. 误区三：以为把定义写清楚就够了

我见过写得很漂亮的制度文档，七八页，每个等级都有详细定义、举例、边界说明。执行三个月后回访，等级分布依然是倒金字塔。原因很简单：文档定义的是"应该怎么填"，系统约束的是"实际能怎么填"。

如果缺陷提交表单里等级是个自由下拉框，那制度的实际执行率就取决于每个人的自觉程度。而自觉是不可依赖的。真正有效的做法是把规则写进系统：必填字段、条件校验、状态流转限制、自动降级规则。

4. 误区四：把严重程度当成质量考核指标

前面场景三里已经说过，这里再强调一次，因为它太常见了。一旦严重程度影响个人评价，它就立刻从事实记录变成策略工具。你会看到两种行为同时出现：一种是压低自己相关的等级，一种是抬高他人相关的等级。

如果确实需要度量质量，应该用不依赖人工判断的指标：线上错误率、回滚次数、故障恢复时长、缺陷重开率。这些指标造假成本高得多。

5. 误区五：忽略"环境"这条隐藏轴

很多团队定级只看"影响多大"，不看"在什么环境下影响"。同样一个崩溃，发生在内部测试环境、预发环境、还是全量生产环境，处理优先级完全不同。更细一点：只在特定浏览器版本、特定租户配置、特定数据量下出现，这些条件都应该进入定级依据。

我在制度模板里会强制加一个"影响环境"字段，取值包括：全量生产 / 部分生产（按租户、地域、版本）/ 预发 / 测试。这个字段单独看没什么，但它和影响面组合起来，能过滤掉大量虚高的等级。

6. 误区六：只定级，不复盘

制度是要迭代的。如果没有定期回看"上个月标为最高级的那些缺陷，最终处理结果如何"，制度就会一直停在初始版本，而团队的实际行为早已漂移。

我的建议是每月做一次 30 分钟的定级校准会：随机抽 10 条缺陷，团队一起重新定级，看和原始等级差多少。偏差超过 30% 就说明定义需要修订，偏差低于 10% 说明制度已经稳定，可以减少会议频率。

四、专业判断逻辑：三轴定级法与我实际在用的规则

这一节是我自己沉淀下来的一套方法，不追求理论完备，追求的是"一个新人在看完之后能做出和老人接近的判断"。

1. 三个轴：影响面、可绕过性、时间敏感性

我把定级拆成三个独立打分的轴，每个轴三档，组合成一个三维坐标，然后用坐标映射到等级。这样做的好处是每一步判断都有事实依据，不需要"整体感觉"。

影响面：这个缺陷波及多少用户或多少数据。高 = 核心链路不可用或数据错误扩散；中 = 部分用户受影响或有条件触发；低 = 边缘场景、内部使用、极少触发。

可绕过性：用户有没有可用的替代路径。无替代 = 高；有替代但需要用户额外操作或降低体验 = 中；有明确兜底且用户无感知 = 低。

时间敏感性：这个缺陷拖一周会造成什么。会造成业务损失、合规风险或对外承诺违约 = 高；会影响后续迭代节奏 = 中；可以长期挂着 = 低。

2. 定级矩阵：把三维压缩成可执行的四档

三个轴各三档，理论上有 27 种组合，直接给 27 条规则没人记得住。我实际用的是下面这张压缩表，按"高轴数量"和"是否含无替代路径"两个条件来归类。

这张表的最后一行很重要。任何矩阵都有例外，制度的成熟标志是知道例外该走哪个口子，而不是没有例外。"低影响面 + 高时间敏感性"的典型场景是：只影响一个大客户，但那个客户明天要签约。这种情形必须走人工仲裁，不能靠表格机械判定。

3. 举证清单：定级时必须提交的四项事实

我把这套要求固化成了缺陷模板的必填字段。缺任意一项，系统不允许提交 P0/P1。

1. 影响范围陈述：涉及多少用户、多少数据、哪些租户或地域；如果是按比例，写清估算依据。
2. 复现步骤：从初始状态到问题出现的完整路径，包含环境信息（版本、浏览器、配置）。
3. 绕过方案：用户当前可以怎么做；如果无替代，明确写"无替代方案"并说明为什么。
4. 时间窗口：这个问题拖到什么时候会造成不可逆损失；如果无所谓，写"无明确时间窗口"。

这四项的作用不只是提高定级质量，还有一个隐性收益：它会自然筛掉那些"顺手标个 P0"的提交。填四项的成本大概是 5 到 8 分钟，只有真正着急的人才会愿意付出这个成本。

4. 仲裁与降级：把争论变成例外

制度设计里最容易被忽略的是"争议处理成本"。如果每次定级分歧都要开会，制度会在一个月内被绕过。所以我的原则是：默认路径零成本，争议路径有明确时限和明确责任人。

（1）单方面降级权

处理人在接单时可以直接降一级，只需在缺陷中记录理由。提交人 24 小时内可申请仲裁，超时自动生效。这条规则让 90% 的分歧在不需要任何人参与的情况下解决。

（2）仲裁责任人的确定

仲裁人不应该是管理者，应该是最了解业务影响面的那个人。通常是对应模块的产品负责人或技术负责人。管理者参与仲裁会把技术判断变成权力判断。

（3）升级的对称约束

降级有通道，升级也要有。处理人认为等级被低估时，同样可以单方面升一级，规则对称。不对称的制度一定会被单边利用。

5. SLA 绑定：让等级产生时间承诺

等级如果不带时间承诺，它就不会影响任何人的行为。我通常用的 SLA 结构如下，各团队可以按自身节奏调整数值，但结构建议保持一致。

特别说一下 P3 的自动关闭机制。我服务过的团队里，P3 缺陷平均存活时间是 217 天，其中约 60% 在关闭时已经不再有意义。设置自动过期不是为了清理数据，是为了让"记录一个问题"这件事重新变得有成本。

6. 自动化辅助：让系统承担机械判断

三轴打分不需要人算。我把规则写成一段可执行的配置，接入缺陷系统时自动给出建议等级，人只需要确认或覆盖。这样既保留了人的判断权，又把 80% 的机械工作交给了系统。

// 三轴定级的自动建议逻辑（示例，接入缺陷系统 webhook 时使用）
const AXIS = { HIGH: 3, MID: 2, LOW: 1 };

function suggestSeverity(defect) {

const impact = defect.affectedUsers >= 0.2        // 影响 20% 以上用户

? AXIS.HIGH

: defect.affectedUsers > 0 ? AXIS.MID : AXIS.LOW;

const workaround = defect.hasWorkaround

? (defect.workaroundCostly ? AXIS.MID : AXIS.LOW)

: AXIS.HIGH;

const urgency = defect.deadlineDays === null

? AXIS.LOW

: defect.deadlineDays <= 3 ? AXIS.HIGH

: defect.deadlineDays <= 14 ? AXIS.MID : AXIS.LOW;

const highCount = [impact, workaround, urgency].filter(v => v === AXIS.HIGH).length;

// 核心规则：三轴全高 = P0；两轴高且包含"无替代方案" = P1

if (highCount === 3) return 'P0';

if (highCount === 2 && workaround === AXIS.HIGH) return 'P1';

if (highCount >= 1) return 'P1';

if (impact === AXIS.MID || workaround === AXIS.MID) return 'P2';

return 'P3';

}

// 调用示例

suggestSeverity({ affectedUsers: 0.35, hasWorkaround: false, workaroundCostly: false, deadlineDays: 2 });

// => 'P0'

这段代码的价值不在于它多聪明，而在于它把定级依据显性化了。当有人对建议等级有异议时，争论的焦点会从"我觉得很严重"变成"这个 affectedUsers 参数估得不对"，后者是可以被验证和修正的。

五、案例与数据观察：一次 300 人研发组织的等级体系改造

下面这个案例来自一家做企业协同产品的公司，研发规模 300 人左右，分 6 个产品线，共用一套缺陷平台。他们在改造前的问题是：跨产品线的缺陷流转混乱，P0 泛滥，发布节奏被频繁打断。

1. 改造前的基线数据

我先让他们拉了 90 天的数据作为基线：缺陷总量 4,120 条，P0 占 18.7%，P1 占 31.2%，两者合计接近一半。同期紧急发布 23 次，跨团队定级争议工单 87 张，平均定级耗时 3.2 分钟。

更关键的一个数据是：标为 P0 的缺陷里，最终被降级的比例是 41%。这说明提交方和处理方对"什么算 P0"的认知差异极大，制度实际上处于半失灵状态。

2. 改造动作：把规则写进平台配置

他们用的是 PingCode 做研发管理，缺陷和需求、迭代在同一个系统里。这次改造的关键不是写文档，而是把制度固化进平台配置，这也是我一直推荐中大型团队用一体化平台而不是多个工具拼接的原因：制度要能被执行，前提是它长在流程里，而不是长在 Wiki 里。

具体做了四件事。

（1）必填字段与条件校验

在缺陷类型上增加了"影响范围""可绕过性""时间窗口""影响环境"四个自定义字段，并设置条件规则：等级选择 P0 或 P1 时，这四个字段变为必填，且"影响范围"必须填写具体的用户量或租户数。

（2）状态流转的等级约束

配置了流转规则：P0 缺陷不允许直接关闭，必须经过"已验证"状态；P1 缺陷超过 3 个工作日未处理，自动触发状态回退并通知模块负责人。这类规则在人工流程里几乎不可能长期坚持，但在系统里是一次性配置。

（3）跨团队缺陷的接收方复核

跨产品线的缺陷，提交后进入"待接收方确认"状态，接收方确认时才最终确定等级。这一步把定级权从提交方转移到了处理方，跨团队争议工单在两个月内从月均 29 张降到 6 张。

（4）等级变更全程留痕

每次等级变更都记录变更人、时间、理由。这些数据后来成了最有价值的资产，他们据此发现，等级上调最集中的时段是每周四下午，正好是周迭代规划会之前。

3. 数据观察：等级分布应该长什么样

我手上有 11 个团队的缺陷等级分布数据，健康的团队基本符合同一个形状：P0 在 2% 到 6%，P1 在 15% 到 25%，P2 在 40% 到 50%，P3 在 25% 到 35%。这是一个金字塔，越往下越宽。

反过来，如果 P0 加 P1 超过 40%，几乎可以断定定级失真；如果 P3 低于 10%，通常意味着团队不敢记录小问题，或者根本没有记录习惯，后者更危险，因为那说明缺陷库不能反映真实质量。

4. 一个反面案例：制度过度设计导致全面绕过

同一时期我还接触了另一家公司，规模 120 人，做的是内部管理系统。他们参照某个大厂模板，设计了五级分类、九项必填字段、三级审批的缺陷流程。结果上线一个月，缺陷提交量下降了 68%，不是质量问题变好了，是大家改在群里口头说了。

这个案例的教训很直接：制度复杂度必须和团队规模、缺陷吞吐量匹配。这个团队月均缺陷不到 80 条，根本支撑不起一套需要专职质量岗维护的流程。后来他们把字段砍到三个、等级砍到三级、审批全部取消，提交量才回到正常水平。

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

下面按团队特征给出具体做法。这些不是理论推演，是我在不同项目里实际用过、并且验证过有效或无效的组合。

1. 20 人以下小团队：不要制度，要约定

这个规模下引入任何正式的分级流程都是负收益。我的建议是只用两档：现在修 / 排期修。判断标准一句话说清：影响线上用户且没有绕过方案的，现在修；其他排期。

不需要必填字段，不需要 SLA，不需要仲裁。这个阶段真正重要的是养成"记录缺陷"的习惯，而不是记录得多精确。

2. 50 到 200 人：三级制 + 必填四项

这是制度开始有价值的区间，因为已经出现跨模块、跨角色的协作，靠口头同步会漏。核心动作有三个：三级分类（阻断/影响/轻微）、四项必填举证、明确降级通道。

这个规模不建议上多级审批。我见过的失败案例基本都是在这个阶段引入了过重的流程。定级争议直接由模块负责人裁决就够了，参与人越少收敛越快。

3. 200 人以上或多产品线：平台化 + 接收方复核 + 定期校准

到了这个规模，制度必须长在系统里。建议使用一体化研发管理平台承载缺陷流转，把必填校验、状态流转约束、跨团队复核、等级留痕都配置成系统规则。像 PingCode 这类面向中大型企业的平台，优势在于缺陷、需求、迭代、发布在同一个数据模型里，等级变更能直接联动排期和发布门禁，不需要跨系统对账。

同时必须建立月度定级校准机制。规模越大，定义漂移越快，靠一次性文档是压不住的。

4. 强合规行业（金融、医疗）：留痕优先于效率

这类业务的约束不在内部效率，在外部审计。所以制度设计的第一目标是可追溯，第二才是调度效率。具体表现是：等级变更必须双人确认并留痕、P0/P1 必须关联变更单和回滚方案、缺陷关闭需要有验证记录。

这类组织里我通常建议保留四级甚至五级，不是因为分级更准，而是因为审计要求等级和责任人的对应关系足够细。

5. To C 高频线上业务：时间敏感性权重最高

面对海量用户的 C 端产品，缺陷的绝对影响面普遍很大，"影响面"这个轴的区分度反而不高。这时候真正能拉开差距的是时间敏感性，大促前的一个小问题，可能比平时的严重问题更值得优先处理。

建议在这种业务里把时间窗口做成显式字段，并且和业务日历联动。技术上可以做到：缺陷提交时自动读取当前是否处于活动期，如果是，等级自动上调一档并标注原因。

6. 硬件与嵌入式：可绕过性权重最高

硬件产品的修复成本极高，一旦出货就没法改。所以定级时最该关注的是可绕过性，用户能不能通过软件升级、配置调整、操作规范来规避。如果完全不可绕过且已经量产，那不管影响面多小，都是最高级。

这类团队还需要一个额外字段：发现阶段（样机 / 试产 / 量产）。同一个缺陷在样机阶段发现是 P2，在量产阶段发现就是 P0，因为处置成本差一个数量级。

七、不同情况下的取舍

制度设计本质上是一系列取舍，没有全都要的选项。下面五组是我最常被问到、也最需要负责人自己拍板的取舍。

1. 精度 vs 速度：单条成本与整体效率的反向关系

提高定级精度必然增加单条处理成本。前面那个 300 人案例里，平均定级耗时从 3.2 分钟涨到 8.9 分钟，涨了将近两倍。这笔成本是真实存在的，必须提前向团队说明。

我的判断标准是：如果缺陷月吞吐量低于 100 条，不要追求精度，因为节省下来的调度收益覆盖不了录入成本。如果月吞吐量超过 500 条，精度带来的排期优化收益会远超成本，这时候不投入反而是浪费。

2. 严格 vs 弹性：制度刚性和团队信任的平衡

规则越严格，绕过动机越强。我见过配置了十几条校验规则的缺陷系统，结果大家发明了一堆变通做法：等级填 P2 但标题里加"【紧急】"作为暗号。

比较务实的做法是只在最高档设硬约束：P0 必须填全字段、必须双人确认、必须走加急流程。P1 及以下保持宽松，靠事后校准来纠偏。这样既守住了最关键的那道门，又不会让日常操作变得难受。

3. 集中仲裁 vs 分散自治：规模决定选择

小规模团队适合分散自治，因为参与者彼此熟悉，沟通成本低。规模上去之后必须有一部分集中，否则跨团队的问题永远排不上。

但我不建议设专职的"质量委员会"来做日常仲裁，那会变成瓶颈。更有效的结构是：日常争议由接收方单方面决定，只有跨产品线的争议才上升到集中的仲裁角色，而且仲裁只对等级不对排期。

4. 与绩效挂钩 vs 完全脱钩：一个不该犹豫的取舍

这个我一直给明确的建议：严重程度必须与个人绩效完全脱钩。一旦挂钩，数据立刻失真，而且失真的方向一定是系统性的、难以纠正的。

如果管理层确实需要质量度量，用前面提到的那组客观指标：线上错误率、回滚率、故障恢复时长、缺陷重开率。这些指标的共同特点是不依赖人工标注。

5. 自动化 vs 人工判断：边界在哪里

我倾向于把自动化用在两个地方：机械规则校验（字段是否填全、数值是否越界、状态流转是否合规）和建议生成（根据三轴自动给出建议等级）。这两块的共同点是规则明确、错误代价低。

而"这个缺陷到底影响多少用户"这类判断，必须留给人。自动化的正确位置是减少机械劳动，不是替代业务判断。试图用算法决定严重程度的团队，最后往往得到一个没人相信的分数。

回到开头那家 63% 缺陷标为"致命"的公司。他们的制度文档其实写得不错，问题出在三个地方：等级是自由下拉框、没有降级通道、跨团队定级由提交方单方面决定。这三条改完之后，两个月内 P0 占比降到 5.7%，而线上真实事故数量基本没变，也就是说，他们从来没有那么多严重问题，只是从来没有一个机制去发现这件事。

如果你正在负责这件事，我建议下一步只做三件事，不要再展开：第一，把过去 90 天的缺陷等级分布拉出来，看它是不是金字塔形；第二，在你的缺陷表单里加上影响范围、可绕过性、时间窗口三个必填字段，只对最高两级生效；第三，给出处理方一次单方面降级的权限，24 小时内自动生效。

这三件事加起来不到一天的工作量，但足以让等级重新开始传递信息。剩下的精细化，等你能稳定看到一条健康的分布曲线之后再说，严重程度管理的终点不是一套完美的定义，而是一个所有人都相信的数字。