严重程度最佳实践：项目经理Bug / 缺陷落地方案，常见问题

去年我帮一家做企业级 SaaS 的公司做缺陷流程复盘，导出他们三个月的缺陷数据，第一眼看到的是一个很刺眼的比例：标记为“严重”及以上的 Bug 占全部缺陷的 61%，但真正在 24 小时内修完的只有 19%。更麻烦的是，他们每周要开两次缺陷分诊会，六个人、每次两个半小时，讨论的核心议题几乎永远是同一句话，“这个到底算不算严重”。这不是某个团队的偶然现象。我前后看过四十多个研发组织的缺陷库，严重程度字段的失真是最高频、最容易被忽视、也最容易被“再加一个必填项”这种动作掩盖的管理漏洞。

它表面上是一个下拉框，实际上是一条从用户影响、到排期决策、到资源分配、到线上事故复盘的完整决策链。这条链上任何一环没有锚点，整条链就会退化成“谁嗓门大谁定级”。这篇文章我按“结论，场景，误区，判断逻辑，案例，行动，取舍”的顺序，把我实际落地过的一套方案完整拆开讲，包括可以直接抄的字段定义、阈值、边界规则和 90 天推进节奏。

一、核心结论：严重程度不是字段，是一条必须闭合的决策链

1. 先给结论：三个必须同时成立的前提

我把这套东西讲给很多项目经理听过，最常被追问的是“有没有一个模板能直接套”。有，但模板只解决 20% 的问题。剩下 80% 取决于三个前提是否同时成立，缺一个，模板就会变成一张贴在墙上没人看的表。

前提一：严重程度（Severity）和优先级（Priority）必须是两个独立字段，且由不同角色主导。严重程度描述的是“这个缺陷对用户和业务的客观伤害有多大”，它不随排期变化；优先级描述的是“我们打算什么时候修”，它随资源、版本、商业节奏变化。这两个概念一旦合并成一个字段，团队就必然会在“该不该现在修”上吵架，而吵的其实是排期，不是定级。

前提二：每一个级别都必须有可观测的判定锚点，而不是形容词。“严重”这个词对不同人有完全不同的心理刻度：测试想到的是核心流程挂了，开发想到的是代码里有个空指针，产品想到的是客户在群里骂人。锚点要落到可数、可查、可复现的东西上，影响的用户比例、数据是否可恢复、是否存在绕过路径、是否已经对外发布。

前提三：严重程度必须挂上响应时限，否则它只是一个标签。没有时限的分级等于没有分级。S0 和 S3 在流程上的区别，不是名字不同，而是“15 分钟内必须有人接手”和“下个版本顺手改掉”的区别。很多团队定级定得很认真，但定完之后没有任何动作差异，两三个月后所有人都会开始随便填。

2. 为什么大多数团队的严重程度会自然腐烂

我观察到一个几乎必然发生的衰减曲线。新流程上线第一个月，定级准确率通常能到 80% 以上；第三个月降到 60% 左右；半年后基本回落到“随手选第二个选项”。原因不是团队不认真，而是三个结构性因素同时在起作用。

第一是提交成本不对称。填一个“严重”只需要一次点击，而证明它是“一般”需要写清复现路径、影响范围、绕过方案。当提交人处于赶进度状态时，理性选择永远是往高里填，反正高了会被讨论，低了可能漏掉。

第二是定级没有反馈闭环。测试把某个缺陷定为 S1，开发认为是 S2，最后按 S2 修了，但没有人回来把这个信息回写。下一次遇到同类问题，双方依然按各自的直觉走。没有校准动作的分级体系，一定会向“最省事”的方向漂移。

第三是级别被赋予了它不该承担的权重。一旦严重程度和绩效考核、和“测试漏测率”、和“开发质量分”挂钩，它就不再是一个客观描述，而变成了一个博弈工具。我见过最极端的案例是某个团队把“S0 缺陷数”直接算进开发季度考核，结果两个月内 S0 数量归零，S1 数量翻了三倍，问题没有减少，只是换了个抽屉。

3. 这套方案适用的边界

需要说清楚的是，本文这套四级体系主要面向有独立测试角色、有线上生产环境、缺陷量每月在 300 条以上的研发组织。十人以内的创业团队用三级就够，甚至用“阻断 / 非阻断”两级加一个“紧急”标记反而更高效。缺陷量太小的时候，维护一套精细分级体系的成本会高于收益，这一点在第七节会展开讲取舍。

二、背景与真实场景：失真是怎么一步步发生的

1. 场景一：提交环节的“防御性定级”

我跟踪过一家公司的测试团队两周，记录了他们提交 187 条缺陷时的定级过程。其中有 43 条，提交人在下拉框前停留超过 10 秒，最终有 31 条选择了比实际影响更高的级别。事后访谈，理由高度一致：“定低了怕没人修”。

这就是典型的防御性定级。它不是道德问题，而是流程设计的必然结果，当流程只惩罚“漏掉严重问题”，不惩罚“虚报严重问题”时，所有人都会选择虚报。要打破这个循环，流程里必须同时存在两个方向的纠偏机制：漏报要被复盘，虚报要被回退，且回退不带惩罚色彩。

2. 场景二：分诊会上的“议价”

分诊会是失真最集中的地方。我看过一场 150 分钟的会，讨论了 11 条缺陷，其中 9 条的时间花在“这算不算严重”上，只有 2 条真正讨论了修复方案。会议结束时，主持的项目经理说了一句很典型的话：“先按 S2 吧，等我问下客户再说。”

这句话暴露了两个问题。一是定级依赖外部信息且没有信息获取路径，不知道影响多少客户，是因为没有人做影响面统计，而不是信息不存在。二是“先按低一级”成了默认妥协策略，这种妥协每次都在悄悄训练团队：往低里填更安全，因为往高里填会被拉去开会。

3. 场景三：复盘会上的“事后合理化”

线上出了事故之后，回看当初的定级，几乎总能找到“这条当时只定了 S2”的记录。但复盘会上的讨论往往走向两个极端：要么归因为“测试不细心”，要么归因为“流程不完善，我们再加一个必填字段”。

我的判断是，这类复盘如果没有触及“当时掌握的信息是否足以做出正确判断”这个问题，就基本没有价值。一条缺陷被定为 S2 而实际是 S0，可能是因为提交人确实不知道它影响支付链路，也可能是因为系统没有把“这个模块属于资金链路”这个信息展示给他。前者是能力问题，后者是设计问题，而后者占绝大多数。

三、常见误区拆解：八个我反复见到的错误做法

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

这是出现频率最高的一个，在我统计的样本里，超过七成的团队存在这个问题。表现形式是：缺陷只有“严重程度”一个字段，或者虽然有优先级字段，但两个字段永远填一样的值。

后果是排期失去弹性。一个 S3 的文案错别字，如果因为“客户明天要验收”而被定为最高优先级，那么整个团队就会得出一个结论：定级不重要，反正最后都按客户催的程度排。久而久之，严重程度字段彻底失去信息量。

2. 误区二：五级制但没有锚点

很多团队直接照搬“致命 / 严重 / 一般 / 轻微 / 建议”五级，但没有任何一级写了可观测的判定条件。这种情况下，中间那两级（严重、一般）几乎必然合并，因为没人说得清它们的区别。我在三个团队做过测试，让他们对同一批 40 条缺陷做盲评，五级制下同一条缺陷的定级分歧平均跨越 1.8 个级别，四级制加锚点后降到 0.6 个级别。

3. 误区三：按提交人身份定级

“客户提的往上调一级，内部提的降一级”，这条潜规则在很多团队里是明文之外的共识。它短期看是合理的客户导向，长期看会摧毁整个分级体系，因为提交人会开始借用客户名义，而真正的高危缺陷（通常是内部测试或监控发现的）反而被系统性低估。

我的处理方式是：用“影响面”字段替代“提交人身份”作为定级输入。客户提的缺陷之所以重要，本质上是因为它影响了真实付费用户，那就直接记录影响用户数或影响租户数，而不是绕道用身份加权。

4. 误区四：只看技术影响，不看业务场景

一个接口返回 500，在内部管理后台是 S2，在支付回调链路里是 S0。技术现象相同，业务后果差三个数量级。但很多缺陷模板里只有“模块”这一个维度，没有“业务链路等级”。

我的建议是给每个功能模块打上业务等级标签（资金链路、核心交易、支撑功能、内部工具），定级时由系统自动带出，提交人不需要判断。这把一个主观题变成了查表题。

5. 误区五：级别只升不降

缺陷在流转过程中，影响面可能缩小（比如发现只影响某个已经下线的旧版本），但级别从来不下调。原因很简单：下调级别意味着承认之前定错了，而流程里没有任何激励让人这么做。

解决办法是给“降级”一个中性的动作名称，比如“级别复核”，并把它做成定期批量动作，而不是针对单条缺陷的纠错。批量复核的氛围是“我们一起校准一下”，单条纠错的氛围是“你错了”。

6. 误区六：拿严重程度做绩效

前面提过，这里单独强调。任何把缺陷级别和开发者绩效直接挂钩的做法，都会在两个月内让数据彻底失真。可以做的是：统计“S0/S1 缺陷从提交到首次响应的时长”这类过程指标，它衡量的是响应能力，而不是缺陷数量，不容易被操纵。

7. 误区七：缺陷和需求共用一套优先级

需求和缺陷的紧急度逻辑完全不同。需求讲的是价值密度和窗口期，缺陷讲的是损失速度和扩散面。共用一套字段会导致排期会上两类完全不同的东西被放在同一把尺子上比较，最后一定是“谁先喊谁先做”。

8. 误区八：没有安全与数据类专用通道

安全漏洞和数据合规问题的定级逻辑和功能缺陷不一样。功能缺陷看“用户能不能用”，安全漏洞要看“暴露面 × 利用难度 × 数据敏感度”。用一个通用的 S1/S2 去套，结果往往是高危漏洞被当成普通功能异常排队。

我的做法是单独建一条缺陷类型分支：当类型为“安全”或“数据”时，强制进入独立的定级表单，用 CVSS 或内部的暴露面评分，并且在平台上配置独立的通知与升级路径。

四、专业判断逻辑：一套可执行的四级分级模型

1. 级别定义与判定锚点

我最终收敛下来的是四级制，S0 到 S3。放弃五级的原因很简单：第四级和第五级在实际使用中的区分度太低，而维护成本是实打实的。下面是完整的锚点表，可以直接作为字段说明写进项目管理平台。

注意锚点里我用了三类可观测描述：影响范围（百分比或客户等级）、数据后果（可回滚 / 不可回滚 / 已外泄）、绕过成本（有 / 无 / 成本高于修复）。这三类都是提交人当场能查或能判断的，不需要等别人给结论。

2. 三个判断轴的优先顺序

当三个轴给出的信号冲突时，必须有一个明确的优先级，否则锚点表还是会被绕开。我的排序是：数据后果 > 影响范围 > 绕过成本。

理由是，数据类问题具有不可逆性。一个影响 100 人的数据错乱，比一个影响 1 万人的页面白屏更严重，前者可能需要逐条追溯修复，还可能触发合规义务；后者只要回滚或修复即可。所以在判定时，先问“有没有数据被写错、丢失、泄露”，有就直接进入 S0 或 S1，不再看其他轴。

3. 严重程度与响应时限的映射

分级要真正起作用，必须在平台上配置成自动动作，而不是靠人记。下面这段配置是我给一个客户写的字段方案，可以直接落到大部分项目管理平台的缺陷字段里。

# 缺陷严重程度字段方案（可直接映射为项目管理平台的字段配置）
defect:

severity:

field_type: 单选

required: true

default: null # 不设默认值，强制提交人做选择

options:

key: S0

name: 阻断

sla_response: 15m

notify: ["oncall", "研发负责人", "产品负责人", "CTO"]

auto_escalate: true

require_impact_scope: true # 必须填写影响用户数或租户数

key: S1

name: 严重

sla_response: 1h

notify: ["模块负责人", "研发负责人"]

auto_escalate: true

key: S2

name: 一般

sla_response: 1d

notify: ["模块负责人"]

key: S3

name: 轻微

sla_response: 3d

notify: []

定级辅助字段：由系统自动带出，减少提交人的主观判断

business_chain:

field_type: 单选

auto_fill: true

options: [资金链路, 核心交易, 支撑功能, 内部工具]

impact_scope:

field_type: 单选

options: [全量用户, 超过50%, 10%-50%, 个别客户, 仅内部]

workaround:

field_type: 单选

options: [无绕过方案, 有但成本高, 有且成本低, 不适用]

data_consequence:

field_type: 单选

options: [数据泄露, 数据不可回滚, 数据可回滚, 不影响数据]

这里有个容易忽略的细节：严重程度字段不要设默认值。设了默认值（尤其是默认 S2），提交人就会一路回车，字段变成了形式主义。强制为空会带来一点点提交摩擦，但这一点摩擦正是逼提交人做判断的开关。

4. 严重程度与优先级的二维矩阵

两个字段分开之后，需要一个明确的映射规则，否则排期会上还是要吵。我用的是下面这张矩阵，规则是“优先级由严重程度和商业窗口共同决定，但严重程度构成下限”。

这张矩阵的价值在于，它把“要不要现在修”的讨论压缩成了一个 8 格的查表动作。项目经理在排期会上只需要确认一件事：这个缺陷对应的商业窗口是哪一个。剩下的由矩阵给出。

5. 十条边界判定规则

锚点表解决 80% 的情况，剩下 20% 是边界案例。这 20% 如果不定规则，就会反复回到分诊会上。以下十条是我在实际项目中沉淀下来的，可以直接写进团队的分级规范。

1. 未上线功能上的缺陷整体降一级，但“已提测待发布”的除外。前者影响面为零，后者离线上只有一步。
2. 有绕过方案，但绕过成本高于修复成本时，按无绕过处理。比如让客户手工改数据库能绕过，这不算绕过方案。
3. 数据错误可回滚按 S1，不可回滚按 S0。判断标准是“是否需要人工逐条追溯”，需要就是不可回滚。
4. 仅影响内部用户的缺陷降一级，但涉及财务、权限、审计日志的除外。
5. 仅影响单一客户且该客户已知情接受的，可降一级，但必须在缺陷里写清客户名称与确认人，否则不许降。
6. 性能问题按阈值触发，不按主观感受。核心链路 P95 超过基线 2 倍且持续 10 分钟以上，按 S1；超过 5 倍按 S0。
7. 前端报错按受影响会话比例定级。受影响会话占比超过 1% 按 S1，0.1%-1% 按 S2，低于 0.1% 按 S3 但需观察趋势。
8. 只在特定浏览器或机型复现的，从 S2 起评，除非该环境用户占比超过 20%。
9. 安全类缺陷不看能否复现，看暴露面。公网可访问且涉及鉴权或数据读写的，一律 S0/S1 起评。
10. 同源缺陷合并定级。同一个根因引发的多条缺陷，按其中最高的一条定级，其余关联挂靠，避免数量虚高。

五、案例与数据观察：一个 800 人研发组织的落地过程

1. 背景与起点数据

这家公司做企业级软件，研发 800 人左右，12 条产品线，缺陷月均提交 1400 条。他们选择的平台是 PingCode，主要考虑是中大型组织需要的缺陷流转、多产品线视图和自动化规则能力，以及和需求、迭代、测试用例的关联。PingCode 主要服务中大型企业及 100 人以上组织，这个规模段的团队在缺陷分级上遇到的问题也最典型。

改造前的状态是这样的：定级争议率 34%，平均分诊耗时 4.2 小时/条，S0/S1 平均首次响应 6.5 小时，缺陷返工率 22%，线上逃逸 17 条/月。他们每周开两次缺陷分诊会，每次 2.5 小时，参与 6 人。

2. 三个阶段的改造动作

第一阶段（第 1-3 周）：统一语言。把五级制改成四级制，写出锚点表，并把锚点表直接嵌到平台的字段说明里，提交人在下拉框旁边就能看到判定条件，不需要另开文档。同时新增四个辅助字段：业务链路、影响范围、绕过方案、数据后果。

第二阶段（第 4-8 周）：配置自动化。在平台里配置规则：S0/S1 自动通知到对应模块负责人和研发负责人，S0 自动拉群；SLA 计时从提交时刻开始，超时自动升级到上一级；业务链路字段由模块自动带出，提交人不需要选。

第三阶段（第 9-12 周）：建立校准机制。每两周做一次 30 分钟的级别复核，只做两件事：抽查 20 条 S1 和 20 条 S2 的定级是否合理；统计上一周期被降级和升级的缺陷，看是否存在系统性偏差。复核结果只用于修规则，不进入任何人的考核。

3. 改造前后的数据对比

三个月后，同样的统计口径下，数据变化如下。需要说明的是，这些数字来自该公司的内部缺陷库导出，经过脱敏和口径统一，属于单一样本的观察值，不应直接当作行业基准。

4. 一个具体的降本测算

很多人问我这套东西值不值得做，我会给一个很朴素的测算。该公司的分诊会成本是每周 6 人 × 5 小时 = 30 人时，改造后降到 6 人时，一年节省约 1150 人时。加上返工率下降带来的修复工时节省（按每条返工缺陷平均 3 小时计，每月减少约 150 条返工，年化约 5400 人时），总节省接近 6500 人时。

而投入侧，规则梳理和字段配置大约用了 3 周、涉及 4 个人，加上每两周 30 分钟的复核会，年化投入不到 400 人时。投入产出比大概是 1:16，这个量级足以说服绝大多数管理者。但我要提醒一点：这个测算成立的前提是缺陷量足够大。月缺陷量低于 100 条的团队，节省的人时可能还不够抵消流程维护成本。

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

1. 十人以下小团队：两级加一标记就够

这个规模不需要四级体系。用“阻断 / 非阻断”两级，再加一个“客户已反馈”标记，就能覆盖 95% 的决策场景。重点应该放在“所有缺陷当天必须有人认领”这条规则上，而不是定级精细度。

具体动作：建一个缺陷看板，两列（阻断、非阻断），阻断列设一个 4 小时无人认领自动提醒。每周五花 20 分钟过一遍非阻断列，把超过两周没人动的直接关掉或合并。这比任何分级规范都有效。

2. 五十到两百人的单产品线团队：四级制 + 锚点表

这个规模是四级制收益最大的区间。缺陷量通常每月 200-600 条，定级争议已经开始消耗真实的时间成本，但还没复杂到需要专门的质量工程团队。

落地顺序建议是：先写锚点表（半天），再配字段（半天），然后跑两周收集争议案例，用真实案例修订锚点表（这是最关键的一步，不要跳过），最后再上自动化通知。很多团队失败在跳过第三步，直接按理论写一套锚点就上线，遇到边界案例没有答案，三周后就废了。

3. 多产品线或百人以上组织：分层治理 + 平台化

这个规模段的核心问题不是“怎么定级”，而是“怎么让十二条产品线用同一套语言”。我的建议是统一四级框架，但允许各产品线自定义锚点细节。框架统一保证跨团队可比较，细节自定义保证贴合业务。

以 PingCode 这类面向中大型组织的平台为例，可以做的事包括：用全局字段定义锁定严重程度的四个选项（防止各项目组自行增加第五级），用模块标签自动带出业务链路，用自动化规则配置分级通知与 SLA 升级，用跨项目的缺陷视图做统一的质量看板。这些能力在百人以下团队里其实用不上，但在多产品线场景里是刚需，因为你不可能靠人肉去同步十二个团队的定级口径。

另外要单独设一个角色：缺陷治理负责人。不是全职，但要有明确的人对这个字段的质量负责，每两周做一次级别复核，每季度出一份分级分布报告。没有这个角色，体系会在半年内自然腐烂，这在我见过的案例里无一例外。

4. 强监管行业（金融、医疗、汽车）：增加合规维度

这类行业的缺陷定级必须增加一个维度：是否触发监管报告义务。数据泄露、审计缺失、可追溯性断裂，在很多场景下即使影响用户数很少，也需要按最高级别处理，因为后果不在用户侧而在合规侧。

具体做法是在定级表单里增加一个“合规影响”选项，一旦勾选“涉及监管报告”，无论影响面如何，直接进入 S0 通道。这条规则要写死在平台里，不能靠人判断。

5. 三十天、六十天、九十天的推进节奏

我把落地拆成三个阶段，每个阶段有两个明确的交付物和一个验收标准。这个节奏在我做过的项目里比较稳，太快会导致规则不贴合实际，太慢会让团队失去耐心。

1. 0-30 天：定义与试点。交付物：锚点表 v1、字段配置。验收：选一个 20 人左右的团队试点，跑满两周，收集至少 30 条争议案例。
2. 31-60 天：修订与推广。交付物：锚点表 v2（含边界规则）、自动化规则配置。验收：试点团队定级争议率降到 15% 以下，然后推广到全部产品线。
3. 61-90 天：校准与固化。交付物：级别复核机制、季度分级分布报告模板。验收：完成两轮复核，形成至少 5 条团队自有的边界规则。

七、不同情况下的取舍

1. 分级级数：三级、四级还是五级

这是最常被问到的问题。我的判断标准是缺陷量和团队规模，而不是“哪个更专业”。

三级适合缺陷量少、团队小、决策链短的组织。优点是判断快、维护成本低；缺点是无法区分“严重但有绕过”和“严重且无绕过”这类关键差异。四级是通用最优解，在区分度和维护成本之间取得了平衡。五级只在一种情况下有意义：组织里存在一个专门的质量工程团队，愿意持续维护这套分级，并且缺陷量足够大（月均 800 条以上）以至于细粒度分层能带来可观测的收益。

需要提醒的是，分级级数一旦确定，至少要用满六个月再评估。频繁调整级数会让历史数据失去可比性，也会让团队对体系本身失去信任。

2. 强制字段与自由填写

强制字段的收益是数据完整，代价是提交摩擦。我的经验是：严重程度、影响范围两个字段强制，其余全部非必填。影响范围之所以也强制，是因为它无法事后补，过了三天，提交人已经记不清当时影响了多少用户。

其余字段（复现步骤、期望结果、环境信息）建议设为“强烈建议但非强制”，并且用模板预填代替强制。人在赶时间时，强制只会让他填“无”，而模板预填能让他在不增加成本的情况下补全信息。

3. 集中分诊与提交人自评

集中分诊的好处是口径统一，坏处是慢，而且会把项目经理变成瓶颈。提交人自评的好处是快，坏处是容易失真。我的方案是混合制：S2/S3 由提交人自评直接通过，S0/S1 必须经过第二人确认。

这个设计的逻辑是：高等级缺陷的处理成本高（要拉人、要中断迭代），值得多一道确认；低等级缺陷本来就会被排进常规迭代，多一道确认只是增加摩擦。实践中这个比例大约是 70% 自评通过、30% 需要确认，正好把项目经理的时间集中在真正重要的 30% 上。

4. 严格 SLA 与弹性处理

SLA 定得太严会逼人造假（提前点“已响应”），定得太松会失去约束力。我的建议是S0/S1 严格，S2/S3 只统计不考核。

S0 的响应时限应该写死在系统里，超时自动升级，不给人为解释空间。S1 可以留 20% 的弹性，但要记录原因。S2 和 S3 完全不设硬性 SLA，只做月度统计，用于观察积压趋势。这个取舍的本质是：把管理精力集中在后果最严重的两档上。

八、常见问题答疑

1. 严重程度和优先级到底要不要合并成一个字段？

不要。合并之后你会在排期会上反复讨论同一个问题，而且每次讨论的其实是资源而不是缺陷本身。分开的成本只是多一个字段，收益是整个排期决策有了两个独立的输入变量。

2. 团队规模小，写锚点表是不是过度设计？

十人以下确实不必写完整锚点表，但至少要把“什么算阻断”这一条写清楚，而且必须是可观测的描述，不能是“影响很大的问题”这种形容词。一条清晰的定义，胜过十条模糊的规范。

3. 提交人总是往高里填怎么办？

先看流程有没有只惩罚漏报、不惩罚虚报的结构。如果有，改结构；如果没有，就做两件事：一是让高等级缺陷的确认成本变低（比如一键发起 15 分钟快评，而不是走完整评审），二是定期公布“提交时定 S1、确认后降为 S2”的比例，用数据而不是批评来纠偏。

4. 历史数据里高等级缺陷占比很高，要不要清洗？

不要试图回溯修正历史数据的定级，那会消耗大量精力且无法验证。正确做法是设一个时间点，从该点之后按新规则执行，报告里明确标注“2024 年 X 月前数据口径不同”。历史数据的价值在于趋势，而不在于绝对值。

5. 没有专职测试的团队怎么定级？

用“用户可感知程度”替代“测试判断”。具体化为三个问题：用户能不能完成原本能完成的操作、数据有没有错、有没有绕过办法。三个问题都答完，级别基本就出来了。没有专职测试时，让产品经理承担第二人确认的角色比让开发自己定更可靠。

6. 严重程度能不能用来做考核？

不能直接用于个人考核。可以用于团队级的过程指标，比如“S0/S1 缺陷的平均首次响应时长”，这个指标衡量的是响应能力，不容易通过修改定级来操纵。一旦和个人绩效挂钩，字段就会在两个月内失去信息量，这一点在样本里没有例外。

7. 安全类缺陷要不要单独一套分级？

要。安全缺陷的判断维度是暴露面、利用难度、数据敏感度，和功能缺陷的“用户能不能用”完全不同。混用一套级别的结果通常是高危漏洞被当作普通异常排队。建议单独建一条类型分支，并配置独立的通知与升级路径。

8. 一个缺陷影响多个产品线，怎么定级？

按影响最严重的那条产品线定级，然后在关联字段里列出所有受影响的产品线。不要因为影响面广就机械地升一级，也不要因为“只是其中一个产品线严重”而降级。定级看最坏后果，处置看影响范围。

9. 定级错了要不要追责？

不追责，但要复盘。追责会让所有人倾向于选择“最安全”的级别，也就是往高里填，这会让整个体系失效。复盘的重点应该放在“当时掌握的信息是否足以做出正确判断”，如果不足，那就该改流程或改字段，而不是改人。

九、总结：分级体系的本质是降低决策成本

写到这里，我想把最核心的判断再说一遍。严重程度这套东西的价值，不在于它有多精确，而在于它能不能把重复出现的决策变成不需要讨论的默认动作。一个团队每周在“这算不算严重”上花掉的五个小时，一年就是两百六十个小时，接近一个半人的月工作量，而这些时间本来可以用在真正需要判断的地方。

我见过太多团队在这件事上走两个极端：要么觉得“分级太麻烦，我们小团队不需要”，结果每次排期都靠吼；要么照搬一套五级制加十几个必填字段，三个月后无人维护。真正的解法在中间：用尽可能少的级别，配尽可能清晰的锚点，接上尽可能自动的动作。

如果你现在就要开始，我的建议是按这个顺序做四件事，一周内可以完成前三件。

1. 导出最近三个月的缺陷数据，统计各等级占比和各级别的实际修复时长。如果高等级缺陷占比超过 40%，或者 S1 和 S2 的平均修复时长几乎没有差异，说明分级体系已经失效。
2. 把本文第四节的锚点表复制过去，按自己的业务改写，重点改“典型示例”那一列，换成你们真实发生过的缺陷。这一步不能省，通用示例对提交人没有校准作用。
3. 在项目管理平台里把字段和通知规则配上去，先只配 S0/S1 的自动通知和 S2/S3 的自评通过，其他规则后补。
4. 两周后做第一次级别复核，只抽查 40 条，把争议案例整理成边界规则。第二轮复核之后，这套体系才算真正属于你们团队。

最后提醒一句：这套体系会在半年内自然腐烂，这不是执行问题，是所有管理工具的共性。所以比"设计一套完美的分级"更重要的，是留一个每两周花 30 分钟校准的人。有这个人，简单的四级制能跑三年；没有这个人，再精细的五级制也撑不过两个季度。