严重程度怎么做？研发团队入门指南：Bug / 缺陷从0到1

“严重程度”不是给 Bug 排队时随手填的一个数字，而是团队对用户损失、业务中断和风险边界的共同判断。同一个登录故障，如果只是测试环境偶发、刷新即可恢复，和全量用户无法登录、且没有替代入口，绝不能因为标题都叫“登录失败”就打同一个等级。要从零建立缺陷分级机制，先统一一件事：严重程度描述问题造成的影响，优先级描述团队何时处理；两者相关，但不能混为一谈。

一、先讲核心结论：严重程度衡量影响，不衡量修复难度

1. 先把严重程度与优先级拆开

我建议团队在缺陷单中至少保留两个字段：严重程度（Severity）和处理优先级（Priority）。严重程度回答“问题造成了多大损失”，优先级回答“在当前资源和计划下，应该多快处理”。如果只留一个“紧急程度”字段，团队往往会把用户影响、修复工作量、上线时间和管理者关注度全塞进去，最后每个人都觉得自己的问题该是最高级。

例如，某个低频后台报表的计算结果偏差，可能影响范围较小，但涉及财务决策，严重程度不一定低；相反，首页一个次要图标错位可能被所有用户看到，视觉覆盖范围很大，却未必妨碍完成任务。又如，安全漏洞可能尚未观察到实际利用，但一旦被利用后果严重，不能因为当前投诉数量为零就降级。

严重程度要尽量稳定地描述影响；优先级可以随业务节奏变化。发布冻结、客户承诺、监管节点、修复成本和团队容量可以改变优先级，但不应该改写问题实际造成的影响。把这两者分开，是减少争吵、保留决策记录的第一步。

2. 入门团队先用四级，不要先造复杂体系

刚开始建立分级规则时，我通常建议用四级：S1 致命、S2 严重、S3 一般、S4 轻微。四级足以区分“必须立即止损”“要尽快修复”“进入正常计划”和“可择机处理”，也比七八级体系更容易记住、落到工单和复盘中。

如果团队原有习惯是 P0、P1、P2、P3，也可以沿用编号，但要在制度里明确它代表的是严重程度，而非迭代优先级。字母和数字本身没有统一的行业含义，真正重要的是每一级都有可观察的判定条件、处理动作和升级规则。

上表是团队可落地的起点，不是跨行业标准。医疗、金融、工业控制等场景必须增加安全、合规、生命健康或资产损失相关的专门规则；普通互联网产品也可能因账号、支付、隐私或数据删除等关键链路而需要提高判定敏感度。

3. 任何等级都要能解释“为什么”

只有等级，没有依据，无法支撑排期、升级或复盘。提交缺陷时，应同时记录受影响的用户或角色、受影响的功能路径、发生频率、影响范围、是否有替代方案、数据或安全后果，以及判定人和判定时间。信息不全时可以先标为“待确认”，但不能把信息缺失默认为低严重程度。

这套规则的目标不是让所有人一次判断都准确，而是让判断过程透明、可修订、能追溯。团队最终要比较的不是“谁的感觉更强”，而是“现有证据支持哪一种影响判断”。

二、背景和真实场景：为什么同一个 Bug 会得到三个等级

1. 缺陷描述相同，业务上下文可能完全不同

在缺陷评审里，我最常看到的争议不是“这段代码有没有错”，而是缺少判断所需的场景。同一条“导出失败”，如果用户可以改用可靠的异步导出，任务仍能按时完成，影响可能有限；如果导出是监管报送的唯一入口，且截止时间临近，影响就会显著放大。标题没有变，业务后果变了。

登录、支付、权限、数据导入导出、审批、消息通知等功能尤其容易出现这种情况。一个页面报错可能只是单个入口的问题，也可能把整条关键链路堵死。只看模块名称、代码改动量或缺陷标题，无法判断严重程度；必须把问题放回真实任务路径里。

2. 用户数不是唯一的影响尺度

影响范围要看“有多少人受影响”，也要看“受影响的人正在完成什么任务”。影响少数管理员的数据权限错误，可能比大量用户看到的非关键图标错位更严重；影响一个关键客户的生产环境，也可能因为合同、时限和业务连续性而需要迅速处理。

因此，我不建议设置“影响用户不足某个固定人数就不得高于 S3”这类简单门槛。人数可以是证据，但不是结论。对于多租户系统，还要区分一个用户、一个租户、一类租户和全站；对于内部系统，则要区分普通使用者、运维、财务、审批人等关键角色。

3. 严重程度是风险判断，不是投诉计数

投诉量低可能只是问题还没暴露、用户没有渠道反馈，或受影响用户很少但任务价值很高。数据丢失、权限越权、账务错误等问题，通常不能等待用户集中投诉后才上调等级。团队应把“已发生的影响”和“合理可信的潜在影响”分别记录，避免用推测冒充已证实事实，也避免因尚未观察到损失就忽视风险。

安全问题可参考 FIRST 发布的 CVSS 规范评估漏洞技术严重性，但 CVSS 分数不等同于产品缺陷的业务严重程度。漏洞利用条件、权限要求和技术影响是一类输入；真实环境中的资产价值、暴露范围、补偿控制和业务后果，则需要团队结合上下文判断。技术评分能提供结构，不能代替业务决策。

4. 建议在缺陷单中记录可复核的上下文

一条可用于定级的缺陷记录，不应只有“点击后异常”。最少应说明谁在什么版本、什么环境、通过什么步骤遇到什么结果；期望结果是什么；实际影响到哪个任务；是否能绕行；是否涉及数据、安全或合规；影响是已确认还是待核实。

• 受影响对象：用户角色、租户范围、客户端或部署环境。
• 任务链路：从入口到目标结果的关键步骤，指出阻塞发生在哪一步。
• 发生条件：稳定复现、特定配置触发、低概率偶发，或目前尚不能复现。
• 后果证据：错误日志、监控、业务记录、用户反馈或测试结果。
• 缓解方式：是否有可靠替代路径，绕行需要多少时间、权限或人工成本。

信息质量本身不应决定严重程度，但会决定团队是否需要立即补充调查。若可能涉及数据损坏或安全风险，先限制影响并保全证据，再继续确认，不要为了把工单字段填完整而拖延止损。

三、常见误区：看起来简单，最容易把分级带偏

1. 把严重程度等同于优先级

“今天必须修”是处理安排，不是影响描述。发布前发现的文案错误，可能因为发版窗口而需要立即修；某个罕见但可能造成严重数据损坏的问题，团队也可能先执行隔离、监控或回滚，而不是立刻完成根因修复。把“紧急”直接当作“严重”，会让等级随日历和会议变化，历史数据失去比较价值。

较好的做法是分别记录“影响等级”和“计划处理时间”。例如，S3 缺陷由于客户演示被安排在本周修复，仍然可以保持 S3；S1 风险若已通过关闭入口得到有效控制，也可以在风险状态变化后重新评估后续修复节奏，但要留下变更理由。

2. 把修复工作量当成严重程度

“改起来很麻烦”不是用户影响。“只改一行代码”也不代表问题轻微。开发成本影响解决方案和排期，严重程度描述问题后果，两者属于不同维度。将两者混为一谈，会让难修的问题被人为降级，也会让容易修的问题被人为升级。

修复成本可以作为优先级讨论的输入：如果两个缺陷影响相近，先修哪个可以综合考虑成本、风险和计划。但成本不应该反向改写等级，否则团队会形成“越难修越不严重”的错误激励。

3. 把可见度等同于业务损失

界面问题容易被截图，数据一致性问题往往不显眼。一个按钮错位可能让用户不舒服，但仍能完成任务；一个后台计算错误可能不被立即发现，却持续污染后续报表。只按“是否看得见”“是否容易演示”来定级，会系统性低估后台、异步和数据链路问题。

反过来，视觉问题也不能一概判为低等级。如果遮挡使关键操作无法完成，或无障碍问题让一类用户无法使用核心功能，它就不再只是审美问题。判断点是任务是否受阻、哪些用户受影响，以及是否存在可接受的替代方式。

4. 把复现概率当成唯一依据

偶发问题未必影响小。低概率但后果严重的故障，可能需要比高频、可忽略的展示瑕疵更高的风险关注。反之，高频出现的轻微提示异常，如果不影响任务、不产生错误结果，也不必自动升到最高等级。

我会把“发生频率”和“后果严重性”分开记录。前者帮助估计暴露概率，后者判断一旦发生会造成什么；再补充是否可检测、可恢复和可绕行。尤其是数据写入、并发、定时任务、权限和外部依赖故障，单看人工复现频率容易低估系统性风险。

5. 把客户级别或声音大小当作等级

客户身份可以影响业务优先级和沟通方式，但不应直接决定技术严重程度。一个重要客户遇到局部问题，确实可能需要快速响应；但如果影响范围有限且有可靠绕行，不能只因为客户级别高就把所有类似缺陷定成 S1。反过来，没有客户投诉也不代表问题无害。

团队应把“用户影响事实”和“商业承诺背景”分开写。前者支撑严重程度，后者支撑处理优先级。这样既能尊重客户承诺，也能避免等级被谈判和情绪左右。

6. 让缺陷等级长期不复核

严重程度不是工单创建时一次写定、此后永不变化的标签。调查可能发现影响范围比最初预期大，也可能通过临时措施把风险有效隔离。等级变化应当允许，但要记录变更前后值、证据和判断人。

如果大量缺陷在关闭时仍保留未经复核的初始等级，团队会把“猜测”误当成事实。对高等级问题，至少在确认影响、实施止损和验证修复三个节点复核；对一般问题，也应在证据推翻原判断时及时调整。

四、专业判断逻辑：用一套可复核的问题完成定级

1. 先判断是否触发不可妥协的高风险条件

常规打分之前，先筛查是否存在需要直接升级复核的情形：核心业务全面中断；重要数据丢失、错误覆盖或不可逆损坏；未授权访问敏感信息；权限校验失效；支付或账务出现错误；可能违反法律、合同或行业要求；问题仍在扩散且无法及时遏制。

触发这些条件不等于每个问题都必须永久定为最高级，而是表示不能仅凭“用户少、概率低、现在没投诉”结束判断。应立即确认范围、采取临时控制、通知相关责任人，并根据证据判断最终等级。对安全或隐私事件，还要遵循组织既有的事件响应与报告流程。

2. 按五个维度检查影响

如果没有明显的高风险触发项，我建议使用五个维度做结构化判断：任务影响、受影响范围、发生与暴露条件、替代和恢复能力、数据与安全后果。它们不是必须相加的数学公式，而是防止团队只盯着单一因素的检查框架。

做判断时，不要机械地把五项打分相加。数据泄露或不可逆损坏可能单独构成高风险；而几个低影响线索也不一定能抵消核心任务完全中断。量表的作用是提示证据缺口，不是制造“总分看似精确”的错觉。

3. 用等级定义和反例共同校准边界

每个等级都要有“符合条件”和“不足以升级”的反例。比如，S1 的正例可以是全量用户无法完成核心任务且无绕行；反例可以是某一非关键页面加载较慢，但页面之外的主要流程正常。反例能帮助评审者理解边界，比只写“重大、严重、一般、轻微”更有用。

如果团队只能给等级下定义，却无法解释一个相邻等级的反例，通常说明等级边界仍然模糊。建议在启动时拿过去的真实缺陷做匿名校准：每个人独立定级、写理由，再比较分歧来自范围、任务价值、绕行能力还是风险认知。不要先追求所有人意见一致，先把分歧来源找出来。

4. 信息不完整时先控制风险，再补齐判断

“待确认”不是拖延，也不是低级别的代名词。它适用于影响边界尚不清楚、复现条件不稳定、日志不足或业务后果待核实的情况。对可能涉及高风险的缺陷，应同时指定调查负责人、补证据的时间点和临时控制措施。

一个实用原则是：不确定性可以改变置信度，不能自动降低潜在后果。若潜在损害重大而证据不足，应暂按较高风险管理，快速收集证据后再降级；若潜在损害有限，可以先进入正常排查，但仍需明确复核条件。

5. 用简单决策规则补足团队的判断一致性

新团队可以先约定以下顺序：发现核心任务中断、数据安全风险或不可逆损失，立即进入高风险复核；没有上述情况时，判断主要任务能否完成；再评估受影响角色和范围；最后判断绕行是否可靠、恢复成本是否可控。这个顺序把不可忽略的后果放在前面，避免先被“目前只有一位用户反馈”带偏。

若使用某项目管理平台或缺陷管理系统，可将等级定义、必填证据、升级规则和变更记录放在同一工作流中。工具的价值在于减少漏填、留下审计轨迹并提供统计，不在于自动替团队做业务判断。即使系统支持规则引擎，也应让规则服务于人工复核，而不是把未知情形硬塞进一个自动分数。

五、具体案例与数据观察：用业务后果而不是标题定级

1. 案例一：导出失败，先问导出承载什么任务

假设某业务系统的导出按钮报错。初始工单只有“点击导出后提示失败”，没有说明用户是谁、导出什么、是否还有替代方式。按这条描述直接定为 S2 或 S3 都缺少依据。我会先补问：失败影响全部用户还是某种筛选条件？用户能否在页面查看结果？是否可用异步任务、接口或人工支持完成？数据是否已经生成但未下载？

若只有低频筛选组合失败，其他查询与导出正常，用户仍可通过另一种筛选方式获得同一结果，影响更接近局部功能异常。若导出是月末对账的唯一正式凭证入口，且截止前没有可靠替代方案，业务影响可能明显提高。若导出内容出现其他租户数据，则问题已从功能失败升级为数据访问风险，应启动安全调查，不应仅按“导出按钮故障”处理。

这个案例的关键不是把“导出”固定映射到某个等级，而是识别实际任务、替代方式和数据边界。标题是索引，证据才是定级依据。

2. 案例二：页面展示错误，可能藏着持久数据错误

假设订单列表把金额显示成了错误格式。若只是千位分隔符显示异常，后端金额、账单和下载文件都正确，主要损失可能是理解成本与信任感；若页面显示错误且用户据此执行退款或审批，影响会扩大；若数据库中的金额也被错误覆盖，则需要评估数据恢复范围、下游账务和审计记录，不能继续当作展示缺陷。

排查时，我会把“前端显示、接口响应、持久化数据、下游消费”分层核对，避免只修复截图里的现象。页面看起来相同，数据层是否受损会改变严重程度，也会改变修复验证范围。

3. 案例三：偶发登录失败，频率低不等于可以忽略

假设某些用户在特定网络切换后偶尔无法登录。团队需要区分是短暂重试即可恢复、会话未丢失，还是用户被锁定、身份验证信息被错误处理，甚至可能出现跨账号访问。前三者的业务影响和风险完全不同。复现概率只是一个条件，身份、权限和数据边界才决定潜在后果。

如果失败率低且可通过重新认证可靠恢复，可纳入正常迭代并持续观察；如果问题发生在关键岗位、影响生产操作，或伴随权限异常，就应提高复核级别。对疑似安全问题，先保全相关日志，限制风险路径，再确定根因和最终等级。

4. 情景模拟：不同指标如何改变判断

下面的数字是一个虚构的团队校准练习，用来演示“问题频率、任务损失、绕行成本、风险等级”如何组合，不代表行业平均水平，也不应直接作为所有团队的阈值。假设团队每月处理约 100 条缺陷，三类案例分别是一般界面异常、关键导出受阻和疑似跨租户数据暴露。

这组模拟说明，缺陷数量和反馈次数无法单独决定等级。导出问题即使影响对象少，若绕行成本高且关键期限迫近，也可能需要较快处理；疑似数据暴露即便尚未确认实际访问，也需要立即调查。实际团队应把模拟参数替换成自己的业务链路、客户分布和恢复成本。

5. 观察团队自己的分布，比照抄外部阈值更有价值

我建议连续观察至少一个完整迭代周期，统计各等级的数量、重开率、等级变更率、平均确认时间和实际处置方式。若团队 90% 的缺陷都被标成 S1 或 S2，未必说明产品特别糟，更可能是定义太宽、缺少反例，或优先级被混进严重程度。

如果 S1 缺陷长期没有触发任何止损、升级或管理响应，也值得检查等级是否虚高；如果 S4 缺陷频繁造成返工、用户绕行或数据修正，则可能存在低估。数字是校准信号，不是绩效排名。不要把“高等级缺陷少”当作团队质量高的直接证据，否则会诱导压低等级。

六、从提交到关闭：让分级进入工作流，而不是停留在文档

1. 提交时先采集证据，不要求报告者独自做最终裁决

缺陷报告者往往最了解复现步骤，但不一定掌握用户范围、数据影响和业务承诺。不要把“由提交人给出准确严重程度”当作流程前提。可以让报告者填写初步影响和证据，再由产品、开发、测试或值班负责人按责任边界确认等级。

好的提交流程会引导用户写事实：发生在哪个版本、影响什么任务、是否可复现、有没有截图或日志、已知多少用户受影响。避免只给下拉框让人选 S1 到 S4，却没有说明依据。字段越多不一定越好；只保留能够影响判断和处置的关键信息。

2. 评审时先对齐事实，再讨论等级

当产品认为 S2、开发认为 S3、测试认为 S1 时，先不要投票。逐项对齐：核心任务是什么？影响边界是否已确认？数据是否持久化？有没有可靠绕行？风险是否可逆？很多争论会在事实补充后自然消失。

如果证据仍不足，指定一个负责人去查，而不是用资历或职级压出结论。对于高风险事项，允许先临时按更高风险采取保护措施，再在证据充分后调整等级。记录“当前判断”和“待确认项”，比假装已经确定更安全。

3. 处理过程中分开追踪风险控制和根因修复

缺陷处置常有两个目标：尽快降低用户风险，以及彻底修复根因。关闭入口、回滚版本、限制权限、暂停任务或提供人工替代，可能先完成止损；代码修复和回归验证随后完成。工单应记录这两条进展，避免“已经有绕行”被误写成“问题已修好”。

如果临时措施改变了影响范围，可以重新评估当前紧急程度，但不要抹掉最初发生的后果。复盘时仍需分析缺陷如何进入生产、为什么监控未发现、替代措施是否及时，以及修复是否覆盖相邻路径。

4. 关闭时确认用户结果，不只确认代码合并

关闭缺陷前，应确认修复在受影响条件下通过验证，受影响数据是否恢复，临时控制是否可以撤销，用户是否需要通知，以及是否有相似入口或版本需要检查。代码已合并不等于业务影响已解除，部署完成也不代表数据已修复。

高风险问题尤其要记录验证证据和责任人。涉及安全、隐私或合规的缺陷，要按组织要求保留调查与处置记录；普通问题也应留下版本、测试范围和关闭原因，方便后续判断等级是否准确。

5. 定期复盘等级变化和漏判案例

每月或每个迭代抽样回看一组缺陷，重点不是追责，而是找规则盲区：初始等级是否被频繁上调？是否有高影响问题被定成轻微？同类问题是否在不同团队被判成不同等级？高等级问题是否真正触发与风险相称的动作？

我会特别关注“重开”和“等级变更”。重开可能说明验收标准不清或修复只覆盖了表象；等级反复变化可能说明信息采集太迟、边界定义不明确，或决策权责混乱。数据用于改进流程，不用于简单比较个人表现。

七、不同情况下的行动建议与取舍

1. 新团队：先求定义可用，再逐步细化

如果团队没有历史分级规则，先发布四级定义、五个判断维度和一个高风险升级条件。不要一开始就设计复杂分值、十种例外和多层审批。规则越难记，越容易变成填表负担；但定义过于宽泛，又会让所有问题都挤在同一级。

落地时选取最近一段时间的真实缺陷做盲评。让不同角色先独立定级和写理由，再对比分歧，最后修订边界。保留几个典型正例和反例，下一批缺陷评审时直接引用。初版规则不必完美，但必须能解释团队为什么做出当前判断。

2. 产品已有稳定用户：增加业务角色和关键链路映射

产品成熟后，团队需要明确哪些角色、流程和数据对象属于关键资产。对于多租户产品，补充租户边界和版本分布；对于企业内部系统，补充财务、审批、运营、运维等角色对流程的依赖；对于面向公众的服务，补充核心转化或服务可用性路径。

取舍在于维护成本：映射过粗，无法支持判断；映射过细，会让每次改版都需要维护大量文档。只为会显著改变严重程度或响应动作的差异建模，其他背景信息用工单描述补充。

3. 涉及安全、隐私或合规：设置独立升级通道

若缺陷可能涉及未授权访问、个人信息泄露、数据损坏、审计缺口或监管义务，不要让普通 Bug 队列成为唯一入口。应明确安全、法务、隐私或合规责任人的参与条件，并按组织既有事件响应流程处理。

优点是可以快速保护证据、限制扩散并协调通知责任；代价是流程更严谨，可能增加沟通和记录工作。不要为追求流程简化而把安全事件与普通功能问题混在一起，也不要让“所有疑似问题都走最高级事件流程”造成告警疲劳。关键是设清触发条件和快速退出条件。

4. 处于发布窗口：紧急程度可以变，影响等级不要随意变

临近发布时，即便 S3 缺陷也可能值得暂缓发布或优先修复；发布后某些低影响问题则可以等待常规迭代。应把发布风险、回滚成本、修复变更风险和业务期限放进优先级决策，而不是把严重程度直接改成 S1。

这是“速度与稳定性”的取舍：热修可以缩短暴露时间，也可能带来新回归；等待下一窗口可以降低变更风险，但会延长现有影响。团队应记录选择依据、接受的剩余风险和回滚方案，而不是仅留下一个“已提优先级”的标签。

5. 资源有限：对低等级问题设置透明的接受条件

不是每个缺陷都必须立即修复。S3 或 S4 问题可以排入后续计划、合并处理，甚至在明确理由后接受现状。但接受并不等于删除：记录已知影响、适用版本、用户绕行方式、接受人和复核触发条件。若用户范围扩大、业务用途改变或风险信号出现，应重新打开评估。

对于不可逆数据风险、安全边界和合规要求，不能只以“修复太贵”作为长期接受理由。若短期不能彻底修复，应考虑关闭功能、限制暴露、增加监控或提供补偿控制，并设定复核期限。资源不足是现实约束，但不应变成隐瞒风险的理由。

八、团队如何从零启动：一周内建立可运行的最小机制

1. 第一天：确定术语、等级和责任人

先明确团队使用“严重程度”描述影响、“优先级”安排处理顺序，并确定四级定义。再指定谁可以初步定级、谁负责高风险复核、等级争议由谁裁决。角色可以根据团队规模合并，但职责必须有人承担。

责任设计要避免两个极端：所有工单都必须等管理者审批，会拖慢日常处理；任何提交者都能随意改最高等级，会削弱规则可信度。可以让报告者给出初步判断，值班或缺陷负责人确认；涉及数据、安全或合规时，自动邀请对应专业角色。

2. 第二天：选取历史缺陷做校准

挑选一批不同类型的历史缺陷，匿名后让产品、开发、测试和支持人员独立定级，并要求每个人写一句核心理由。重点讨论相邻等级的分歧、数据风险漏判和用户范围不清的问题。讨论结果沉淀为正例、反例和待补充证据清单。

不要把历史处理方式直接当成正确答案。过去被紧急修复的缺陷可能只是因为发布窗口临近；过去被放低等级的问题也可能后来造成返工。校准时重新依据影响事实判断，再决定是否需要修订规则。

3. 第三至第四天：将规则放进缺陷模板和工作流

缺陷模板增加受影响角色、任务路径、发生条件、替代方式、数据安全影响和证据链接。对高风险条件配置提醒或升级路径；对等级变更保留变更原因。表单要短而有效，能在提交时采集关键事实，不要让报告者填写无法获知的信息。

如果团队使用某项目管理平台，可以配置必填字段、自动通知、状态流转和统计视图，但不要把自动化规则写成“关键词命中就定最高级”。系统适合提醒“缺少影响范围”“疑似安全风险待复核”，业务判断仍应由了解上下文的责任人作出。

4. 第五至第七天：试运行并观察误差

试运行时，不必急着考核所有人是否完全遵守。记录哪些字段经常空缺、哪些等级定义最容易误解、评审等待时间是否增长、高风险问题是否及时触发止损。发现规则造成无效等待或重复填报，应立即简化；发现关键风险被漏掉，则补充触发条件和升级责任。

一周只能验证流程是否可用，不能证明等级分布已经稳定。至少经过几个完整迭代，再结合重开率、变更率、用户影响和处置动作调整定义。规则更新要有版本记录，并告诉团队哪些判定边界变了。

5. 最小可运行检查清单

• 是否区分严重程度与优先级？
• 每个等级是否有可观察定义和至少一个反例？
• 是否能识别数据、安全、隐私和合规风险？
• 信息不足时，是否有“待确认”、负责人和复核时间？
• 是否记录绕行、止损、修复验证和等级变更原因？
• 是否定期查看等级分布、重开率和漏判案例？

如果上述问题大多有明确答案，团队就已经具备了从零运行的基本机制。后续优化应围绕真实争议和真实后果展开，而不是为了看起来成熟，不断增加字段、审批层级和复杂评分公式。

九、结语：好的分级机制不是“分得准”，而是风险能被看见

1. 最终判断不应停留在一个字母或数字

严重程度的价值，不在于给缺陷贴上看似精确的标签，而在于团队能否用同一套语言解释影响、发现风险、选择处置方式，并在证据变化时修正判断。等级如果不能触发合适的调查、止损、沟通或验证动作，就只是数据库里的一个字段。

我更看重两种能力：一是能把“影响小”和“目前证据不足”区分开；二是能把“问题严重”和“必须立刻采用某种修复方案”区分开。前者避免低估未知风险，后者避免用等级替代工程判断。

2. 下一步先做三件事

今天就可以从一个小范围开始：写出四级定义，补上受影响任务、范围、绕行和数据安全四类关键信息；再拿最近十几条真实缺陷做一次盲评，记录分歧而不是急着消灭分歧；最后选定复核责任人，让高风险问题有明确的升级和止损路径。

这套机制不需要一次设计到位。先让每个等级都能解释“影响是什么、证据在哪里、下一步做什么”，再根据真实缺陷不断校准。严重程度不是用来证明谁更着急，而是帮助团队把有限注意力优先放到不可忽视的损失上。