Bug / 缺陷如何做好严重程度？项目负责人协同管理与操作步骤

先说一个反常识的观察：把缺陷标成 P0，并不会让它修得更快。我在 2024 年复盘过一个 300 人研发团队的缺陷库，连续 11 周的数据显示，被标为最高等级的缺陷平均修复时长是 9.2 小时，而被标为次一级的缺陷是 6.9 小时，最"紧急"的那一档反而最慢。原因不复杂：标 P0 的人太多，最高等级失去稀缺性，值班同学看到满屏红色，本能地开始"挑着看"。

严重程度（Severity）这件事，本质不是给缺陷贴一个标签，而是给组织建立一套可执行、可追溯、可申诉的资源调度规则。标签贴错了没人受伤，规则崩了则是全线代价：真正致命的问题被淹没，项目负责人每天在群里做仲裁，发布窗口被一堆"伪致命"反复拖住。

这篇文章不谈概念定义，谈的是我在多个 100-800 人研发组织里真实落地过的东西：怎么定级、谁来定、争议怎么收口、严重程度怎么和 SLA 与发布门禁绑定、项目负责人在其中到底该做什么、不该做什么。后半段会给出一套可以直接抄走的定级卡、一条 30 天落地路线，以及在不同团队规模下的取舍建议。

一、核心结论：严重程度不是形容词，是契约

如果只能记住五句话，就是下面这五句。后面所有章节都是这五句的展开。

1. 严重程度衡量客观影响，优先级表达主观排序

绝大多数定级混乱，源头是把这两件事混成一件。严重程度回答的是"这个缺陷造成了多大、多广、多不可逆的损害"，它与排期无关、与客户情绪无关、与谁来做无关。

优先级回答的是"我们现在先做哪一个"，它必须考虑版本节奏、人力、商业价值和机会成本。同一个缺陷可以严重程度 S1、优先级 P3，它很严重，但我们这周确实排不进去，愿意承担这个风险并记录在案。这两件事分开，争议立刻少一半。

2. 定级标准必须写成"判定条件"，不能写成形容词

"严重""较严重""一般"这类词，十个人有十一种理解。有效的定级标准一定是可验证的条件句：核心下单链路不可用、错误数据已写入生产库且无法回滚、涉及资金计算偏差超过 0.5%、涉及个人信息越权可见。

判定条件要能被第三个人独立复核。判断方法很简单：把这条标准给一个没参与讨论的同事看，他能否在五分钟内给出和你一样的结论。如果不能，这条标准就是废的，需要继续往下拆。

3. 项目负责人不是"最能拍板的人"，而是"规则的守护者"

很多团队把项目负责人当成终极裁判，所有定级争议都往上抛，结果是负责人的日程被"这个算不算 P0"填满。这既浪费，也不可规模化。

项目负责人真正该做的三件事：设计并维护定级规则、在规则覆盖不到的地方做终裁并留下判例、用数据监控定级是否失真。定级本身应该由提交者按条件自判，测试复核，只有冲突才上升到人。

4. 严重程度必须挂上时限、门禁和通知，否则只是一行备注

一个字段如果只存在于缺陷详情页里，它对行为的影响接近于零。严重程度要发挥作用，必须同时驱动三件事：首次响应时限、修复时限、发布门禁，以及对应等级的通知路径。

S0 触发值班电话和项目负责人即时通知，S1 触发工作时间内的两小时响应，S3 进入常规迭代池。当等级和"谁会被打扰、什么时候必须回、能不能发版"直接挂钩，人对定级的态度会立刻变得认真。

5. 定级通胀比定级错误更危险

单个缺陷定错级，损失可控。整库定级通货膨胀，损失是系统性的：注意力被稀释、SLA 形同虚设、真正的 P0 得不到优先处理、质量数据全部失真，你再也无法从缺陷库里读出产品的真实健康度。

下面这张图是我在脱敏样本里看到的典型对比。当最高等级的缺陷占到全部缺陷的三成，它就不再是"最高等级"，而只是一个"我想让你快点看"的语气词。

二、背景与真实场景：为什么定级在 100 人以上就开始失控

小团队几乎不需要定级规则。十几个人，缺陷都看得见，谁喊一声"这个很急"，事情就办了。但组织一旦跨过某个规模阈值，口头共识就失效了，不是因为人变笨了，而是因为定级的"上下文"不再共享。

测试同学知道这个缺陷会让某客户的全部分支机构登不进去，开发同学只看到一行空指针异常，项目负责人看到的是本周还有三个需求要上线。三个人对同一行记录的判断必然不同，而缺陷库只允许填一个值。

1. 场景一：大促前夜，所有人都说是 P0

某电商类产品在大促前 48 小时，缺陷库同时涌入 23 个"P0"。项目负责人被迫在群里逐个问"这个影响多少用户"，问到第 9 个时已经凌晨一点。

真正致命的只有两个：优惠券叠加计算错误导致资损、购物车在 iOS 17 上必崩。剩下 21 个里，有 14 个是文案错别字、图标错位、后台配置项描述不准，它们被标成 P0 的唯一原因是"大促期间不能出错"。

这是典型的"时点恐惧"替代了"影响评估"。团队把对发布窗口的焦虑，投射到了缺陷等级上。结果是大促前夜的修复资源被平均分配，两个真事故各分到不到十分之一的注意力。

2. 场景二：客户投诉驱动的定级升级

更隐蔽的一种失控来自外部。某 To B 产品的客户成功同学为了"让研发重视"，习惯性地在缺陷描述里加上"客户非常不满，要求今天解决"，并直接定级最高档。

三次之后，研发侧形成了免疫：所有带"客户不满"字样的缺陷一律降两级看。于是当真的有一个付费 200 万的客户遇到数据导出错乱时，这条信息被同样的免疫机制过滤掉了，两周后才被翻出来。

定级一旦可以被人为施压改变，它就同时失去了向上传递紧急性和向下传递可信度的能力。这不是态度问题，是机制缺位：没有一个客观条件作为锚点，情绪就会自动填补空白。

3. 场景三：缺陷发现得越晚，定级越没用

很多团队把定级当成质量管理的全部，却忽略了一个更前置的变量：缺陷在哪个阶段被发现。同一类逻辑错误，在需求评审阶段被指出来是十分钟的事，在线上爆发则是几十人天的救援。

我在多个团队看到的成本曲线形状高度一致：越往后，修复成本不是线性上升，而是接近指数上升，因为它裹挟了回归测试、发布审批、灰度验证、数据修复和客户沟通。

这张图对项目负责人的意义在于：定级是止损工具，不是质量工具。它只能在缺陷已经产生之后决定资源怎么分配，而成本的大头在更早的阶段就已经决定了。所以定级机制必须和"缺陷在哪被发现"的质量门禁一起设计，否则你只是在优化一条已经溢出的管道。

三、常见误区：八个让定级失真的典型动作

下面这八条，是我在复盘里反复见到的。它们不是低级错误，而是"看起来很合理"的做法，所以才会长期存在。

1. 用用户情绪替代影响评估

"用户会炸锅""客户要退款"这类描述不是定级依据，而是情绪信号。它可以作为线索去追查真实影响，但不能直接换算成等级。

正确的做法是把它翻译成可验证的事实：影响了多少账号、是否阻断主流程、有没有可用替代路径、损失是否可逆。没有这四项，任何"很严重"都是主观陈述。

2. 定级通胀：人人都报最高档

这是最普遍也最致命的一条。它的成因往往不是恶意，而是善意：如果只有最高档能被快速处理，那么理性的人都会报最高档。

通胀的根因是"等级与注意力强绑定、且高等级没有成本"。只要高等级不需要额外举证、不需要通知到具体的人、不需要承担复盘压力，它就必然被滥用。治理办法不是呼吁大家"如实定级"，而是给高等级加上举证责任和打扰成本。

3. 把优先级当严重程度用

"这个先不做，所以定为 S3"，这句话把排序结果写进了影响评估字段。后果是质量数据永久失真：你无法再回答"我们这季度产生了多少严重缺陷"，因为严重程度里混进了排期决策。

4. 只看影响人数，忽略资金与合规

影响 3 个用户但算错了钱，比影响 3000 个用户但只是样式错位严重得多。次数少、金额大、不可逆的错误，必须被单独一票升级。

我通常建议团队设置三个"一票升级"触发器：数据不可逆丢失或错乱、资金与账务计算偏差、安全与个人信息越权。命中任意一条，无论影响人数多少，直接进最高两档，不允许用"概率低"降级。

5. 一次定级，终身不变

缺陷是会"长大"的。今天只在一个客户的测试环境复现，明天可能变成全量必现；今天只是显示错误，明天可能被证实写坏了数据。

所以定级字段旁边必须有一个"影响面复核"的动作节点：进入开发前复核一次，上线前复核一次。升级要有触发条件，降级要有证据，两个方向都要留痕。

6. 让一个人独自定级

测试独自定级，容易高估影响；开发独自定级，容易低估跨模块连带；产品独自定级，容易忽略技术侧的资损与安全风险。任何单点判断都会系统性偏移。

可行的结构是"自判 + 复核 + 终裁"：提交者按判定条件自判并填写影响证据，测试复核并补齐复现路径，只有冲突或命中一票升级时才上升到项目负责人。多数缺陷应该在三分钟内定完，只有 10% 需要人参与讨论。

7. 定级不写理由，只填一个字母

一个只填了 P0 的缺陷，三个月后没人知道当时为什么这么判。复盘时无法区分"当时判断错了"和"当时信息不全"，组织也就无法从定级中学习。

强制要求填写三样东西：影响范围的量化描述、复现路径、判定命中的规则条目。这三样同时是给后来者的证据，也是给争议的仲裁材料。

8. 用会议解决定级争议

当争议需要靠会议解决，说明规则没有覆盖到。评审会开成辩论会，讨论的是"我觉得"，产出的是"这次先这样"。

会议不该用来决定单个缺陷的等级，而该用来沉淀判例。每次争议的结论应该被写成一条新规则或一个新判例，下次同类问题直接套用。开会讨论 10 个缺陷，只解决 10 个；沉淀 1 条规则，解决后面 100 个。

四、专业判断逻辑：一套可复用的定级框架

框架的目标不是精确，而是可复现。同一个缺陷，换三个人判，结论应该落在同一档或相邻一档；如果经常跨两档，说明框架还不够硬。

1. 五个判定维度

我用的维度是五个，按权重从高到低排列。前两个决定档位，后三个做微调。

• 影响范围：受影响的账号数、租户数、终端类型占比。用百分比而不是"部分/全部"这类词。
• 业务损失：是否资损、金额区间、是否合规风险、是否需要对外披露。
• 可绕过性：用户能否通过其他路径完成目标。有官方 workaround 的，整体降一档。
• 触发概率：必现 / 高频 / 偶发 / 极端条件。偶发但影响致命的问题不能因为"偶发"降级。
• 时间敏感性：是否处在发布窗口、大促、结算周期、监管截止日之前。

注意最后一项的用法：时间敏感性只用来调整 优先级 和 处理节奏，不用来调整严重程度本身。把它写进严重程度，就是第一章说的通胀源头。

2. 影响范围 × 触发概率的定级矩阵

把两个最容易量化的维度做成二维矩阵，能覆盖大约 70% 的日常判断。剩下 30% 交给一票升级规则和人工终裁。

矩阵的用法有一条硬约束：当两个维度给出不同档位时，取高不取低。这条约束看起来粗暴，但它把"讨论该不该降级"变成了"先按高的处理，24 小时内补证据再降"。多数情况下，补证据的过程本身就会证明高判是对的。

3. 一票升级触发器

下面三类问题不受矩阵约束，直接进最高两档。它们共同的特征是：影响不在"用户能不能用"，而在"用了之后会不会留下永久损伤"。

1. 数据不可逆：脏数据已写入生产库、跨租户数据串了、删除逻辑写错导致无法恢复。
2. 资金与账务：计价、优惠、结算、退款、发票任意环节出现金额偏差，无论偏差大小。
3. 安全与合规：越权可见、凭证泄露、个人信息未脱敏、审计日志缺失。

这三类必须写进定级卡，并且在缺陷模板里做成勾选项。勾选即触发自动升级和固定通知路径，不经过人工讨论。把最危险的情况从"讨论"里拿出来，是这套框架里性价比最高的一步。

4. 定级卡：必须记录的六个字段

我把这六个字段做成缺陷模板的必填项。缺任意一项，缺陷不能被置为"已受理"状态，用流程强制证据，比用会议强调纪律有效得多。

severity_policy:
version: 2025.03

levels:

S0:

label: 致命

auto_trigger:

核心链路不可用且用户占比 >= 50%

数据不可逆丢失或跨租户错乱

资金 / 账务计算偏差

安全漏洞或个人信息越权可见

sla:

first_response: 15m

workaround: 2h

fix: 24h

notify: [项目负责人, 技术负责人, 客户成功, 值班群]

S1:

label: 严重

auto_trigger:

重要功能不可用且用户占比 >= 10%

数据错误但可人工修复

sla:

first_response: 2h

fix: 3 个工作日

notify: [项目负责人, 模块负责人]

S2:

label: 一般

sla:

first_response: 1 个工作日

fix: 当前迭代内

S3:

label: 轻微

sla:

fix: 2 个迭代内或批量处理

S4:

label: 建议

sla:

fix: 不承诺时限，进入优化池

required_fields: # 缺任意一项不可进入"已受理"

affected_scope # 影响范围，必须带百分比或租户数

reproduce_steps # 复现路径或日志 / 截图

matched_rule # 命中的判定条件编号

workaround # 是否存在替代路径

data_impact # 是否触及数据 / 资金 / 合规

severity_reason # 一句话定级理由

arbitration:

owner: 项目负责人

window: 4h # 超时未裁决则默认取高不取低

default: take_higher

escalate_on: [改级次数 >= 2, 涉及资金, 涉及合规]

这份配置有两个设计意图值得说明。第一，SLA 是按等级自动带出的，不靠人记；第二，仲裁有超时默认值。默认"取高不取低"的意义在于，它把拖延的成本转移给了"不表态的一方"，而不是让缺陷一直悬在那里等会议。

5. 争议处理的三条规则

规则一：争议只发生在"降级"方向。把 S2 提到 S1 不需要讨论，把 S1 降到 S3 需要举证。这条规则让流程天然偏向保护用户，同时不给通胀留口子，升可以快，降必须慢。

规则二：终裁有唯一责任人，且有时限。项目负责人是终裁者，4 小时内必须给出结论。超时则按默认规则执行，避免"没人管所以一直挂着"。

规则三：每次终裁必须沉淀一条判例。结论写进团队的质量手册，格式是"情形 + 结论 + 理由"。积累到 30 条左右，你会发现 80% 的新争议都能被已有判例直接覆盖，会议自然消失。

6. 从提交到定级确认的实际流转

把上面的规则串起来，一条缺陷从提交到进入排期，会经历五个节点。我在团队里做过的实际观测是：流失几乎全部发生在第一个节点，证据不全。

7. 让等级真正驱动行为：三处挂钩

规则写完之后，最容易前功尽弃的地方是"没有后果"。等级必须挂到三个地方，否则它会迅速退化成装饰。

• 响应挂钩：S0 触发即时通知与电话，S1 触发工作时段内提醒并计入响应时长统计。
• 门禁挂钩：存在未关闭的 S0/S1 时，发布流程自动阻断，需要项目负责人显式豁免并记录理由。
• 统计挂钩：每周输出定级分布、定级返工率、SLA 达成率，把它们放进迭代复盘的第一页。

其中门禁挂钩最容易被抵触，也最有效。它把"要不要带着已知严重缺陷发版"从口头博弈变成一次需要签字的显式决策，而绝大多数人一旦需要签字，判断会立刻变得保守和准确。

五、案例与数据观察：一次 12 周的定级治理

下面这条曲线不是理论推演。2024 年下半年，一个约 350 人的 SaaS 研发组织（分布在 6 个业务小组、共用一套缺陷库）请我参与他们的质量流程改造，起因是发布前夜的定级争议已经严重到每周占用项目负责人 6 小时以上。

1. 改造前的基本面

诊断阶段我看了三组数：缺陷库里 S0+S1 占比 31%；被他人改过等级的缺陷占全部缺陷的 41%；缺陷评审会平均时长 90 分钟且没有一次产出过书面判例。

更关键的一个发现是：他们的缺陷模板里，严重程度是一个自由下拉框，没有任何必填证据字段。这意味着定级完全依赖提交者的自我感觉，而组织又在用"谁报的问题先被处理"这种隐性激励，鼓励大家往高报。

2. 改造做了四件事

第一，把严重程度从自由下拉改为受控选项 + 六个必填证据字段，缺字段无法进入"已受理"。第二，把一票升级触发器做成模板勾选项，勾选即自动升档并触发固定通知路径。

第三，把 SLA 与发布门禁挂到等级上：S0/S1 未关闭时发布流程阻断，需要项目负责人显式豁免。第四，设立 4 小时终裁窗口与"取高不取低"的默认规则，同时要求每次终裁必须沉淀一条判例。

他们的缺陷、需求、迭代和发布本来就在同一个项目管理平台上流转，所以这次改造主要是配置工作而不是开发工作：自定义字段定义证据项，工作流状态机限制"谁能改级、改级需要什么条件"，自动化规则负责通知、SLA 倒计时与超时提醒，报表负责每周输出定级分布与返工率。这也是中大型组织必须用系统承载定级规则的原因，规则靠人记，两周就忘；规则写进工作流，会一直生效。

3. 我用 PingCode 说明这套改造怎么落地

这个组织的规模（350 人、6 个业务小组、跨产品线协同）正好落在 PingCode 服务的典型区间，它主要面向中大型企业及 100 人以上组织，缺陷、需求、迭代、测试用例与发布在同一条链路上，适合把定级规则做成"配置"而不是"纪律"。

改造时的具体做法有四层。第一层是字段层：把严重程度做成受控的单选字段，同时把影响范围、复现路径、命中规则、可绕过性、数据影响、定级理由设为必填，并用字段联动让"勾选资金/合规/数据类问题"直接带出高等级。

第二层是流程层：用工作流状态机约束改级权限，提交者只能自判，测试可上调，下调必须填理由并经过项目负责人确认。这样"降级需要举证、升级可以快速"就被写进了状态迁移里，而不是写进通知里。

第三层是自动化层：高等级缺陷触发即时通知到值班与负责人，并按等级启动 SLA 计时；临近时限自动提醒，超时自动升级通知对象；发布前若有未关闭的高等级缺陷，触发阻断提醒并要求填写豁免理由。

第四层是度量层：用报表按周输出定级分布、定级返工率、SLA 达成率、以及"缺陷在哪个阶段被发现"的分布。这一层是项目负责人真正需要看的东西，它让定级从"个人判断"变成"可被观察的系统行为"。

4. 12 周后的变化

曲线形状比绝对数值更值得看：前四周几乎没有变化，第五周开始明显下行，第十周后趋于平稳。原因是规则生效需要一轮完整迭代的教育期，以及判例积累到一定数量后争议才真正减少。

5. 一个意外的发现：缺陷类型高度集中

治理过程中他们还跑了一份缺陷类型分布，结果比预想的集中得多。前四类问题贡献了 85% 的线上事故，而其中两类完全可以在定级阶段就要求补齐特定证据。

这个发现改变了他们的定级卡：针对高发类型追加"类型专属证据要求"。边界条件与空值类问题要求给出具体输入组合，并发与状态同步类问题要求给出时序描述，权限类问题要求给出角色与资源的组合矩阵。

6. 这次改造没解决的事

说清楚边界比夸大效果更可信。这次改造没有解决的问题至少有三个。

一是跨团队定级口径仍未完全统一。6 个业务小组对"重要功能"的定义不同，同一个等级在不同小组的实际含义仍有偏差，后来靠共享判例库缓解，但没有彻底消除。

二是需求侧的问题没有覆盖。定级只治理了缺陷，需求变更引发的返工仍然靠人力协调，这部分成本比缺陷更大。

三是度量本身带来了新负担。周报字段增加到十几项后，项目经理每周多花约 2 小时整理数据，这在 100 人以下团队是完全不划算的，这一点在下一章会展开成具体的分档建议。

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

同一套规则不能套所有组织。下面按规模和阶段分档，给出可以直接执行的动作清单。如果你的团队不到 50 人，请直接跳到最后一档，前面两档对你是负担而不是帮助。

1. 50 人以下团队：三个等级 + 一条触发器就够

这个规模下，沟通成本远低于流程成本。三级足够：阻断（P0）、影响使用（P1）、可延后（P2）。不需要更多档位，因为人不够多，区分度用不上。

1. 在缺陷模板里加两个必填项：影响范围和复现路径。只做这一件事，定级准确率就能明显提升。
2. 设置一条一票升级规则：涉及数据、资金、安全的问题，无论大小直接进 P0。
3. 每周花 15 分钟过一遍本周新增的 P0，只回答一个问题：它真的是 P0 吗。用判例替代制度。

2. 100-300 人团队：需要书面标准与终裁人

跨过 100 人，口头共识开始失效，必须把标准写下来。这个阶段的重点不是更细的档位，而是把"谁说了算"和"凭什么说了算"明确下来。

1. 写一份一页纸的定级卡：四个等级、每级的判定条件、SLA 时限、一票升级触发器。
2. 指定项目负责人为唯一终裁者，设 4 小时窗口，默认取高不取低。
3. 六个必填证据字段上线，缺字段不能进入"已受理"。
4. 每周输出一次定级分布与返工率，放进迭代复盘第一页。
5. 每两周沉淀一次判例，目标是在一个季度内积累 20-30 条。

这个阶段最值得投入的是证据字段的强制化。它一次投入、长期收益，且不依赖任何人的自觉。我见过太多团队在"培训大家如实定级"上花了半年，效果不如把复现路径设为必填。

3. 300-1000 人团队：必须用系统承载规则

这个规模下，规则一旦靠人记就必然衰减。你需要把定级写进工作流、自动化和报表，让它成为系统的默认行为，而不是个体的额外动作。

1. 把定级做成受控字段 + 字段联动，勾选风险类型自动带出等级。
2. 用工作流状态机约束改级权限：上调宽松、下调需理由与确认。
3. 把等级与 SLA 计时、通知路径、发布门禁三处硬挂钩。
4. 建立周度质量看板：等级分布、返工率、SLA 达成率、缺陷发现阶段分布。
5. 建立跨小组的判例库，每季度校准一次口径差异。

这也是我在前一章用 PingCode 举例的原因：这个规模的组织需要的是"规则可配置、行为可观测"，而不是又一份文档。字段定义证据、工作流定义权限、自动化定义通知、报表定义观测，四件事都能在同一个平台上闭环，改造才是配置工作而不是一场跨部门项目。

4. 多产品线或强合规行业：加一层派生等级

金融、医疗、政企类产品还有一个额外要求：同一个缺陷在不同合规语境下的严重程度不同。同一条数据展示错误，在内部系统是 S2，在对外披露场景可能是 S0。

建议在主等级之外加一个"合规等级"派生字段，由合规或安全角色维护映射规则。不要让业务团队自己去判断合规影响，那是专业性错配，也是风险最集中的地方。

5. 给不同角色的一页清单

规则落地时最怕"人人有责等于无人负责"。下面按角色拆，每个人只做自己的三件事。

• 项目负责人：维护定级规则与判例库；4 小时内终裁争议；每周看一次定级分布与返工率，发现通胀立刻收紧举证要求。
• 测试/质量负责人：复核每条高等级缺陷的证据完整性；维护一票升级触发器清单；统计缺陷发现阶段分布。
• 开发负责人：对"可绕过性"给出技术判断；评估修复连带风险；不参与等级博弈，只提供影响面事实。
• 产品负责人：区分严重程度与优先级；在门禁阻断时做商业决策并签字；不通过施压改变等级。
• 管理层：只看趋势不看单条；关注返工率与 SLA 达成率；不把"P0 数量"当成考核指标。

最后一条值得单独强调：一旦把高等级缺陷数量纳入个人考核，定级数据会立刻失去全部可信度。考核应该看"线上事故恢复时长""SLA 达成率"这类结果指标，而不是看人们自己填的等级字段。

七、不同情况下的取舍

所有流程设计都是取舍。下面五组取舍是我被问得最多的，每一组都给出我的默认选择和放弃条件。

1. 粒度：三级够用，五级是上限

每增加一个等级，定级讨论的时间就会上升，而区分度带来的收益会递减。三到五级是甜蜜区，超过五级后，相邻两级的边界会模糊到无法可靠区分。

我的默认选择是四级（致命/严重/一般/轻微），另设一个不进 SLA 的"建议"收纳池。连续两级都说不清区别时，就应该合并，而不是再写一段解释。

2. 严格 SLA vs 弹性处理

严格 SLA 的好处是行为可预期，坏处是容易在低价值问题上浪费高价值资源。弹性处理的好处是灵活，坏处是它会慢慢变成"没有 SLA"。

我的默认选择是对最高两档严格、对低档宽松。S0/S1 的时限必须硬，因为它对应的是真实损失；S3/S4 只承诺"进入批次处理"，不承诺具体日期，避免团队被大量低价值承诺拖住。

3. 集中裁决 vs 团队自治

集中裁决口径统一，但会成为瓶颈；团队自治响应快，但半年后你会发现六个小组有六套标准。这个取舍没有中间路线，只有阶段选择。

我的默认选择是：标准集中、执行自治、争议上收。定级卡由质量与项目负责人共同维护，各小组按同一份卡执行，只有争议和一票升级的情形上收终裁。这样既保留了口径统一，又不制造日常瓶颈。

4. 系统化 vs 轻量表格

系统化的成本是配置与迁移，收益是规则不会衰减、行为可观测。表格的成本接近零，收益是立刻能用，但它只在你还能记住所有人的时候有效。

分界线大致在 100 人：低于这个规模，一张结构良好的表加一个每周 15 分钟的会，效果不输系统；高于这个规模，表格会在三个月内退化成留言板。取舍的标准不是"哪个更先进"，而是"规则能不能在不依赖某个人记忆的情况下持续生效"。

5. 事前定级 vs 事后校准

事前定级能立刻指导资源分配，但信息往往不全；事后校准准确，但那时损失已经发生。正确的组合不是二选一，而是两次定级。

第一次在提交时，用最少的信息给出初判并立即启动 SLA，目的是快。第二次在进入开发前，用完整证据复核并允许调整，目的是准。两次之间必须留痕，因为差异本身就是最有价值的质量数据，它告诉你团队在信息不全时倾向于高估还是低估。

八、总结：定级的终极目标是不再需要定级会议

回到开头那个反常识的现象：为什么最高等级的缺陷反而修得最慢。答案现在已经清楚了，因为当最高等级不再是稀缺资源，它就不再传递任何优先级信号，而只是表达了提交者的焦虑。

一套好的严重程度机制，最终会让定级这件事变得无聊。提交者按条件勾选，系统自动带出等级、SLA 和通知路径，测试复核证据，争议由判例覆盖，项目负责人每周只看一次分布曲线。没有辩论，没有施压，没有凌晨一点在群里追问"这个影响多少用户"。

我在多个团队反复验证过的一条经验是：定级问题的解，八成不在定级本身，而在证据和判例。证据让判断可复核，判例让争议可复用。补足这两样，等级自然会稳定下来；缺这两样，再精细的等级表也只是把主观争论换了个格式。

如果你准备现在就动手，建议按这个顺序做三件事，一周内可以全部完成：

1. 今天：在缺陷模板里加三个必填字段，影响范围（带百分比或租户数）、复现路径、定级理由。缺字段不允许进入"已受理"。
2. 本周：写一页定级卡，四级 + 三条一票升级触发器（数据不可逆、资金账务、安全合规），指定项目负责人为 4 小时终裁人，默认取高不取低。
3. 下周：把等级与通知、SLA 计时、发布门禁挂上，同时开始记录判例。第一周只要沉淀 3 条，你就已经领先大多数团队。

一个月后再看两个指标：最高两档缺陷的占比，以及定级返工率。前者应该落在 10% 上下，后者应该低于 15%。如果这两个数没有变化，问题几乎一定不在规则文本上，而在"高等级没有成本、低等级没有通道"，也就是你的组织还没有真正给等级标价。