严重程度怎么做？项目成员风险控制：Bug / 缺陷从0到1

严重程度怎么做，最容易出错的地方不是等级太少，而是把“影响有多大”“现在有多急”“谁来处理”混成一个字段。结果常见两种：一个只影响少数用户的视觉问题被标成最高级，真正导致核心交易失败的缺陷却排在后面。我的判断是，严重程度必须描述缺陷造成的损害，优先级描述团队处理顺序；只有把两者分开，再用可验证的影响证据支撑定级，项目成员才有可能用同一套尺度控制风险。

一、先讲核心结论：严重程度不是紧急程度

1. 用严重程度回答“坏到什么程度”

严重程度（Severity）描述缺陷对用户、业务、数据、安全、系统可用性或交付目标造成的影响。它关注结果，不直接承诺修复时间，也不代表提交者、负责人或管理者的职位高低。

例如，某个页面的按钮颜色不符合设计稿，影响可能真实存在，但如果用户仍能完成任务，数据没有风险，影响范围又很小，通常不应与订单无法创建、重要数据丢失放在同一等级。相反，暂时只有少数客户遇到的权限绕过，即使发生概率不高，也可能因为安全后果严重而需要高等级。

2. 用优先级回答“现在先做什么”

优先级（Priority）是团队在当前资源、版本计划、客户承诺和风险窗口下，对处理顺序作出的决定。一个高严重程度缺陷可能因为有可验证的临时绕行方案，被安排在当天处理；一个中等严重程度的问题也可能因为即将发布、影响关键客户或阻断验收，进入更高的处理优先级。

不要用“严重程度高”代替“马上处理”，也不要用“目前不急”反推缺陷不严重。前者会导致所有票据争抢最高级，后者会把真实风险埋进排期讨论中。严重程度用于统一衡量影响，优先级用于结合现实条件分配行动。

3. 等级要少，证据要具体

多数团队用四级就足够起步：S1 灾难性、S2 严重、S3 一般、S4 轻微。等级多到六七级，成员往往分不清相邻级别；只有“高、中、低”三个模糊标签，则难以区分服务中断和局部功能受损。级别名称不是重点，重点是每一级都能被证据解释。

我建议每次定级至少记录四项：受影响的用户或业务范围、受损的核心能力、实际后果、是否存在可行绕行方案。涉及安全、数据完整性、合规或财务损失时，再单独标出，不要让这些风险被平均分稀释。

二、背景和真实场景：为什么一个“高”字会引发争论

1. 同一缺陷，成员看到的是不同层面的损失

测试人员看到的是复现步骤和失败结果；产品人员看到的是用户旅程受阻；开发人员看到的是代码路径和修复复杂度；运营人员看到的是客户投诉；项目负责人看到的是版本承诺。每个观察都可能成立，但如果没有共同的判断语言，大家讨论的其实不是同一件事。

我在缺陷评审中常见这样的对话：“这是 P1，今天必须修。”“为什么是 P1？只有一个客户反馈。”“客户正在做季度结算，而且没有替代流程。”“那问题不是等级高低，而是业务窗口和绕行条件。”把争论拆成影响与行动后，会议通常会短很多。

2. 缺陷风险会随着使用场景变化

“导出失败”不是天然的 S2 或 S3。如果只是非关键报表导出失败，且数据仍可在页面查看，影响可能有限；如果导出是监管申报的唯一数据渠道，截止时间就在当天，影响就可能升高。缺陷本身相同，业务上下文却改变了损失。

同理，“偶发”并不等于轻微，“可复现”也不等于严重。发生频率影响风险暴露机会，但严重程度还要看单次后果、影响范围、持续时间和恢复能力。一个低频但会造成不可逆数据损坏的问题，不能因为复现概率低就自动降级。

3. 中大型团队需要把口径写进工作流

当团队人数超过一百人，缺陷会跨产品、研发、测试、运维、客户成功和多个业务线流转。口头约定很难覆盖新成员、跨时区协作和项目交接；同一个“高”在不同团队可能意味着“当天修复”“本迭代处理”或“发布阻断”，造成报表看起来统一、行动实际上分裂。

在 PingCode 这类项目管理平台中落地时，我会把严重程度、优先级、业务影响、临时绕行、风险复核人设为相互关联但独立的字段，并在工作流中规定哪些角色能修改、哪些变化必须留下理由。工具能帮助记录和提醒，但不能替团队定义什么叫严重。

一个可执行的规则应能回答：谁初判、谁复核、什么情况下可以升级或降级、升级后通知谁、发布前谁确认风险已关闭。若这几项没有约定，系统再完整也只会把争议搬到线上。

三、常见误区：看上去简单，实际最容易造成风险漂移

1. 把客户声音大小当作严重程度

客户催得急，确实可能意味着业务窗口紧、合同承诺明确或影响正在扩大，但催促次数本身不是严重程度证据。一个重要客户遇到的问题值得快速响应，却不能因此把所有其他客户的问题都降为低级，也不能把一个影响极小的体验问题自动标成灾难性。

正确做法是把客户重要性和实际影响分开记录：客户范围、受影响人数、业务流程、合同或合规约束、截止时间。客户价值可以影响优先级，但要避免用客户身份替代缺陷后果。

2. 把修复难度当作严重程度

代码改动复杂、涉及多个服务、需要跨团队协作，说明修复成本较高，不代表用户影响一定更严重。反过来，修复只需一行配置，也不代表问题轻微。把复杂度写进严重程度，容易让团队形成“难改就是高危”的错误激励。

修复成本应进入排期和方案评估；严重程度应描述损害。若高影响问题修复困难，更应透明呈现风险和临时措施，而不是因为“不好修”就降低等级，让风险在报表里消失。

3. 把发生概率与后果混成一个直觉分数

有人会说“这个问题很少出现，所以不严重”；也有人会说“它一旦发生就很糟，所以一定是最高级”。两句话都少了关键条件。风险判断至少要分别看发生可能性和影响后果，再结合暴露人群、持续时间和可恢复性。

对于安全漏洞，可以参考 CVSS 的思路理解：利用条件、攻击影响等维度需要分别评估，不能只凭“听起来危险”定级。CVSS 是漏洞严重性评估框架，并不替代团队的业务优先级；业务环境、资产价值和实际暴露范围仍需单独判断。

4. 把“最高等级”当成情绪表达

如果每周都有大量 S1，最高级就失去区分能力。更危险的是，成员发现只要选择最高等级就能获得关注，低等级问题便可能被策略性升级。此时等级字段不再记录风险，而是在竞争资源。

我会特别检查两类异常：最高级缺陷占比持续偏高，以及被降级的缺陷没有记录新证据。前者可能是标准太宽或业务风险真实恶化；后者可能是定级权限集中、成员担心被追责，不能只用“测试不懂业务”解释。

5. 把缺陷关闭等同于风险解除

代码合并不一定代表用户风险消失。修复尚未发布、发布尚未覆盖全部实例、数据修复尚未完成、回归测试仍有缺口，都可能意味着风险仍在。对高等级缺陷，应区分“修复完成”“验证通过”“部署完成”“影响恢复”几个状态。

如果系统只设“处理中”和“已关闭”，团队就很难知道风险在哪个环节结束。状态过少会压扁过程信息；状态过多又会增加维护成本。应按真实交付链路设置必要节点，不为流程图好看而增加无用状态。

四、专业判断逻辑：把影响拆开，再落到等级

1. 先问六个问题，不要先挑标签

我建议初判者按固定顺序填写事实，而不是先选 S1 再补理由。六个问题分别是：谁受影响、什么能力受损、损失是什么、影响持续多久、能否绕行或恢复、是否触及安全与数据等不可逆风险。

1. 受影响对象：单个用户、一个客户、一类角色、多个租户、全部用户，还是内部操作人员？说明估算来源。
2. 受损能力：是核心交易、登录授权、查询分析、报表展示、通知提醒，还是非关键体验？
3. 实际后果：任务失败、延迟、重复扣款、数据缺失、越权访问、错误决策，还是视觉偏差？
4. 持续时间与窗口：持续数分钟、跨越业务时段，还是会在特定周期反复出现？
5. 绕行与恢复：用户是否有可接受的替代流程？人工补救是否可行，成本和差错风险有多大？
6. 特殊风险：是否涉及敏感数据、资金、合规、安全、不可逆写入或难以追溯的审计记录？

初判材料要区分事实和假设。例如，“约有10%的用户受影响”需要交代是日志统计、支持工单还是粗略估计；“可能造成数据丢失”要注明已确认的丢失、复现风险，还是尚待验证的推测。没有证据时，可以暂定高风险待查，但要设定复核期限，而不是把不确定性伪装成结论。

2. 建议采用四级定义，并为每级设置边界

表格是初始工作定义，不是机械判分器。某个缺陷只要命中一项不可逆重大后果，就可能跨越其他维度的低分；与此同时，不能仅因某一字段“看起来很大”就跳级。边界案例应写明触发条件和反证条件，方便复核。

3. 用“后果优先、范围校准、绕行修正”的顺序

第一步看后果。先确定用户实际失去什么：任务是否失败，数据是否错误，损失是否可逆。不要先按受影响人数排序，因为少数人的严重数据损害可能比大量用户遇到轻微展示问题更重要。

第二步看范围。在后果明确后，再看影响人数、租户、区域、角色和业务链路。范围决定损失扩散程度，但人数统计要避免重复计算，也要说明时间窗口和样本口径。

第三步看绕行和恢复。替代流程必须经过验证。“用户可以手工处理”不是充分证据；还要确认手工步骤是否可执行、耗时、是否引入录入错误、是否满足审计要求，以及是否有足够人员承担。

第四步看风险放大项。安全、隐私、财务、合规、不可逆数据操作和发布范围可能使等级上调。上调理由应写在记录里，不能只留下一个“经评估较高”的结论。

4. 风险评分可以辅助，不能取代红线判断

团队可以用影响范围、后果严重性、发生可能性、可恢复性和绕行成本做评估矩阵，帮助成员发现差异。但我不建议把每项打分相乘后直接自动映射到 S1，S4，因为相乘会产生虚假的精确感：相同总分可能对应“影响广但后果轻”和“影响窄但后果不可逆”两种完全不同的风险。

更稳妥的做法是“门槛规则加人工判断”：先设置明确红线，例如已确认的数据泄露、核心服务全面不可用、不可逆的关键数据破坏；命中红线时必须由指定角色复核。未命中红线的缺陷，再参考范围、发生频率、绕行和业务窗口确定等级。

CVSS 可帮助安全团队形成漏洞严重性评估语言；Google SRE 关于服务可靠性、错误预算和用户影响的实践，则提醒团队把可靠性目标和服务影响联系起来。两者都不能直接替代产品缺陷分级，但能帮助建立“证据先于标签”的判断习惯。引用框架时，团队应明确适用范围，而不是照搬分数。

五、具体案例：从“导出按钮失灵”到可复核的风险判断

1. 情景设定：一句缺陷描述远远不够

以下是一个用于说明方法的情景案例，不代表真实客户数据：某企业内部平台的批量导出功能在月末出现失败。提单内容最初只有“导出报错，影响业务，建议定为最高级”。这句话既没有说明哪些用户受影响，也没有确认数据是否丢失，更没有写清楚是否存在替代方案。

我会要求补充观察窗口、请求总量、失败比例、涉及角色、失败前后的数据状态、是否可分批导出，以及月末处理的截止时间。若团队只能拿到客服描述而没有日志证据，也要标注“用户反馈，影响范围待确认”，不能把估计当成已证实的统计结果。

2. 补证之后，等级可能出现三种不同结论

情形甲：局部展示问题。日志显示文件生成成功，只是下载按钮在部分浏览器上没有响应；用户重新进入历史记录即可下载，数据完整、没有截止时间风险。此时更接近 S3，若仅是轻微交互瑕疵且替代入口清晰，也可能是 S4。优先级仍可因即将发布而上调。

情形乙：重要流程受阻。多数财务角色无法导出月末对账文件，但数据仍可在系统内查询；管理员能够通过受控方式分批生成，人工核对需要额外数小时。此时更接近 S2：关键业务被明显拖慢，绕行存在但成本与差错风险不低。应记录绕行责任人和复核要求，不能只用“能手工做”降级。

情形丙：数据完整性风险。部分导出文件缺少记录，用户可能据此完成结算，且无法确认缺失范围。即便当前受影响用户不多，因错误结果可能传播到外部流程、追溯和补救成本高，评估应重点关注数据完整性，必要时按 S1 或 S2 处理，并先阻断错误文件继续使用。

3. 对比的是损害，不是缺陷名称

三个情形都叫“导出问题”，却分别落在不同等级。可见，“功能名称加缺陷类型”无法决定严重程度；真正决定等级的是是否完成业务任务、结果是否可靠、错误能否被发现、补救是否可行、损害是否扩散。

4. 模拟数据要说明口径，不能包装成行业事实

为了演示如何把模糊描述变成可判断信息，假设日志抽样显示：观察的两小时内共有240次导出请求，其中36次失败；失败集中在一种角色权限配置；已生成文件的记录完整性尚未验证。这里的数字是情景模拟，不是行业基准，也不能直接推出36名用户受影响，因为一次用户操作可能产生多次请求。

下一步应验证失败请求对应多少独立用户、是否有重复重试、是否存在未记录的成功下载，以及失败是否会污染生成文件。只有分母、去重方式、观察窗口和结果状态都清楚，团队才可以把“15%请求失败”转换成有意义的业务影响描述。

5. 复盘时要检查从初判到恢复的全过程

假设最终确认为 S2，团队应记录何时发现、何时确认影响范围、何时启用替代流程、何时修复、何时完成数据核验和用户恢复。复盘不应只统计“修复用了几小时”，还要看识别与止损是否及时，以及临时方案是否引入了新的差错。

若初始被标为 S4，后来因数据不完整升级，重点应问：哪些证据当时缺失、提单字段是否引导成员只报告界面现象、日志能否及时关联业务结果、升级通知是否到达正确的人。目标是改进系统和流程，不是追究最初提交者为什么没有预知未知事实。

六、从0到1建立机制：让成员能提、能判、能改

1. 先统一最小字段，别一上来造复杂流程

第一阶段只需要一套足以说明风险的字段：标题、复现条件、受影响对象、影响范围、实际后果、严重程度、优先级、绕行方案、数据或安全风险、证据链接、初判人、复核人。字段过少会使定级缺少依据；字段过多则会使提交者复制粘贴、随意填完。

表单应让填写者知道“为什么要填”。例如，把“影响用户数”改成“影响范围及估算依据”，允许填写“暂不确定，待日志核查”，比要求一个不可靠的精确数字更诚实。对于安全和数据风险，可设置单独的必填问题或触发复核规则，避免在普通描述中被忽略。

2. 定义谁能初判、谁能复核、谁能改级

提单人通常最接近复现事实，适合提供初始影响描述；测试或质量负责人适合检查复现证据和范围；产品或业务代表适合确认任务损失与替代流程；研发、运维或安全人员适合核实技术后果。并非每张票都要多人会签，关键是高风险和有争议的缺陷要有明确复核责任。

我建议普通缺陷允许提单人初判，负责团队确认；S1、涉及安全数据或跨业务系统的缺陷，则设置指定负责人复核。任何人都可以提出升级，但降级需要保留理由和证据。这样的权限设计减少“为了流程而审批”，同时让风险变化可追踪。

3. 将等级与响应时限关联，但保留业务判断

严重程度可以关联响应期望，例如 S1 立即响应、S2 在约定工作时段内确认负责人、S3 进入常规排期、S4 合并评估。这里的时间应由组织的值班能力、服务承诺、团队规模和发布节奏决定，不应照抄其他企业的小时数。

建议区分“响应时间”和“修复完成时间”。S1 在规定时间内有人接手，不意味着能在同一时间内安全修完；安全回滚、数据修复、回归验证可能需要更多时间。把响应承诺冒充修复承诺，会诱导团队仓促变更。

4. 设定升级、降级和重新打开的触发条件

• 升级条件：影响范围扩大、关键用户无法绕行、确认数据损害、安全暴露持续、恢复方案失败、业务截止时间临近。
• 降级条件：新证据证明影响范围更小、数据无损、绕行已验证且成本可接受、风险窗口已经结束。
• 重新打开条件：修复后复现、验证覆盖不足、发布未生效、关联数据未恢复、原判断的前提被新事实推翻。
• 状态变更记录：保留变更前后等级、变更人、时间、理由和证据，避免只看到最终等级而不知道风险如何演变。

降级不是“问题不重要了”，而是证据或环境改变后重新判断。升级也不是承认初判失败，而是风险信息逐步完整。流程若让成员害怕改级，等级就会僵化成提单时的印象。

5. 在项目平台中配置可审计的工作流

以 PingCode 为例，对于中大型、100 人以上的组织，我会先做一张最小字段映射表，再把严重程度与优先级分开配置。各业务线可以保留特定影响维度，但 S1 至 S4 的共同定义应统一；否则跨团队看板虽然颜色一致，语义却不同。

平台配置建议从一个试点团队开始：先用历史缺陷回填或抽样评审验证口径，再调整字段和权限，最后扩展到其他业务线。不要先把全公司流程一次性锁死；如果定义不贴合真实工作，成员会绕过字段、另建表格，产生双重事实来源。

七、不同情况下的行动建议：把规则落到每天的缺陷流转里

1. 如果团队还没有统一标准

先选最近一个版本中有代表性的十到二十个缺陷，组织测试、研发、产品和业务成员独立定级，不要先互相讨论。比较结果时，记录分歧集中在哪些边界：影响人数、业务重要性、绕行成本，还是安全风险。然后只针对高频分歧补定义。

比起从零写一份几十页的规范，这种校准更接近真实工作。定义不是越完整越好，而是能让相同证据下的不同成员得出相近结论，并让不同结论可以通过新增证据解释。

2. 如果最高等级缺陷太多

先抽样检查最高等级是否真的对应核心中断、重大数据风险或不可接受的安全后果。若大量问题只是“业务负责人很着急”，需要拆开客户重要性、时间窗口与实际后果；若确实出现服务可靠性恶化，则不能通过收紧标签来美化报表。

还要观察高等级缺陷从发现到止损的时间、重复发生率、发布后回滚次数和受影响用户范围。最高级占比下降不是目标；真正目标是风险得到及时识别、受影响范围缩小、恢复更可控。

3. 如果跨团队等级无法横向比较

保留业务线特有的影响说明，但要求共同等级共享核心语义。例如某团队的 S2 代表“关键功能受阻但有高成本绕行”，另一团队也应能够对照相同判据。通过联合评审一批匿名案例校准差异，而不是强制所有团队使用完全相同的响应时限。

涉及安全、支付、医疗、政务等高约束领域时，可增加领域风险标签或专门复核规则，但不必让所有普通缺陷都套用行业最高风险要求。共用底层等级、单独处理特殊风险，通常比不断增加等级数量更容易维护。

4. 如果有用户投诉，但影响范围不清楚

先按已知事实处理，并把未知信息列出来。若可能出现重大且不可逆后果，可以先采取保守止损措施，同时标记“待核实”，而非等待所有统计完整后才响应。风险暂定高、证据待补，这两件事可以同时成立。

设一个具体的核验期限和责任人，例如由运维查日志、由业务确认任务完成情况、由安全人员判断数据暴露范围。若没有期限，“待核实”会变成永久状态；若没有负责人，团队就会把不确定性当作没人负责的空白。

5. 如果临近发布，缺陷等级和发布决策冲突

发布决定应以风险接受为中心，不是让缺陷等级迁就版本目标。对 S1 和未受控的重大安全、数据风险，原则上先阻断发布或缩小发布范围；对 S2，应评估用户范围、临时措施、回滚能力和业务承诺；对 S3、S4，则可结合质量门槛与后续修复计划。

如果组织决定带风险发布，记录必须包括接受风险的人、理由、影响对象、用户告知方式、回滚条件、监控信号和复核时间。风险接受不等于问题解决；管理层签字也不能替代技术止损。

八、不同情况下的取舍：规则要有边界，别追求虚假的精确

1. 统一口径与业务差异之间

口径过于宽泛，会让同级缺陷含义不一致；口径过度细化，会把业务差异硬塞进一张通用表。我的取舍是统一等级的核心后果定义，允许业务线补充领域判据，并要求补充判据不能与共同定义冲突。

例如统一“核心任务不可完成且无可接受绕行”这一判断框架，金融业务可以补充结算窗口和资金差错条件，内部协作系统可以补充关键流程阻塞的定义。这样既保留横向比较能力，也不假装所有业务损失都能用同一把尺子衡量。

2. 量化评分与专家判断之间

量化有助于暴露口径遗漏、比较历史变化，但分数会诱发过度精确。若团队尚未积累稳定数据，先采用等级定义加书面证据，通常优于复杂加权公式。等观察口径稳定后，再分析高频因子与真实损害之间的关系。

即使建立评分表，也应保留“红线升级”和“人工复核”机制。评分是帮助问题被看见，不是让责任从判断者转移给公式。尤其是安全、隐私和不可逆损害，不能因为某几个低分项抵消一个关键风险。

3. 快速响应与信息完整之间

高风险事件往往没有条件等到调查完毕才响应，但响应并不等于立刻断言最终等级。可以先采取可逆的保护动作，同时标记临时判断和待验证事实，随后随着证据更新调整等级。

也要避免“先一律最高级”的做法。它可能在短时间内带来注意力，却会耗尽值班资源，削弱真正重大事件的响应能力。合理策略是对潜在重大后果设快速升级通道，对普通不确定性设定明确调查时限。

4. 指标透明与成员行为之间

缺陷严重程度分布、升降级比例、响应时长和重复缺陷率，能帮助团队发现流程问题，但若直接用于个人排名，成员可能减少提报、降低等级或把问题移出系统。指标设计要服务改进，不要把报告风险的人变成“制造问题的人”。

比较团队数据时，应把业务复杂度、用户规模、发布频率和检测能力纳入背景。某团队高等级缺陷更多，可能意味着产品更不稳定，也可能意味着检测更充分、报告文化更健康。单看数量，无法区分这两种情况。

5. 过程细致与操作负担之间

每个缺陷都召开评审会，会拖慢修复；完全依赖提交者自判，又容易失去一致性。可采用分层流程：S3、S4由负责团队按标准处理；S2由产品、研发或质量指定角色复核；S1进入明确的事件响应机制。复核深度应与潜在损害匹配。

字段也是如此。高风险票据需要完整证据和影响记录；轻微视觉问题不必填写一页风险分析。让表单随风险等级显示必要问题，比要求所有人对所有缺陷填写同样多的信息更可持续。

九、用数据检查机制是否有效：看风险有没有变得可控

1. 不要只看各等级的缺陷数量

数量可以提示趋势，却无法说明风险是否受到控制。缺陷增加可能来自产品质量下降，也可能来自测试覆盖增强、监控改善或提报意愿提升。观察数量时，要同时看每次发布、每千次关键交易、每个业务流程或每段服务时间的缺陷密度，并保持口径稳定。

我会优先看几类过程指标：高等级缺陷从发现到确认负责人的时间、从发现到止损的时间、风险状态未更新的时长、修复后再次出现的比例、发布后确认的影响用户范围。指标太多会分散注意力，团队可先挑三到五项与当前主要风险对应的指标。

2. 区分响应效率、修复效率和用户恢复

“平均修复时长”容易误导：有人可能通过快速关闭工单缩短数字，却没有验证用户恢复；也可能是少数复杂缺陷拉高均值。建议同时记录发现至首次响应、发现至止损、发现至修复验证、发现至业务恢复等时间，并查看中位数和高分位数。

对于用户影响明显的服务，可将缺陷事件与服务可靠性目标结合观察。Google SRE 关于错误预算的基本思路是把可靠性目标与变更节奏联系起来；但一个团队的错误预算不应直接变成所有产品缺陷的严重程度标准。它是服务层面的管理信号，缺陷分级仍需要回到具体影响。

3. 用升降级比例发现规则或证据问题

如果大量缺陷在复核后被降级，可能是提单者缺少信息、初始规则过宽，或审核角色理解不同；如果大量缺陷被升级，可能是发现过程太晚、影响范围未纳入初判，或高风险信号没有进入表单。升降级本身不是坏事，反复出现且理由相同才值得治理。

统计时不要把升级率当成测试人员质量排名。要分类升级原因：新增用户影响证据、确认数据后果、业务窗口变化、绕行失败、初始误判。真正有价值的问题是“哪些信号没被流程捕捉”，而不是“谁最常改等级”。

4. 设置反指标，避免为了好看的数字扭曲行为

如果团队把 S1 数量下降当作唯一目标，可能把高风险问题改标 S2；如果只奖励快速关闭，可能牺牲回归质量；如果只考核首次响应速度，可能出现快速回复但没人真正处理。每个核心指标都应搭配反指标和抽样检查。

例如，响应时间下降的同时观察重复打开率和修复后回归缺陷；高等级占比下降的同时抽查实际影响是否被低估；关闭时间缩短的同时确认用户恢复和数据核验是否完成。指标变化必须能够解释业务结果，而非只解释系统字段发生了什么。

十、结尾：下一步不是多造等级，而是让每个等级有证据

1. 今天就能开始的四个动作

1. 检查当前缺陷系统是否把严重程度和优先级混在一起；若是，先拆分字段和定义。
2. 选十到二十个近期缺陷，让不同角色独立定级，记录分歧来自事实缺失还是标准不清。
3. 发布一页纸的 S1 至 S4 判定卡，明确影响范围、实际后果、绕行方案和特殊风险的填写要求。
4. 选择一个试点团队，观察升降级、响应、止损和用户恢复情况，再决定是否扩展到其他业务线。

若你正准备在 PingCode 这类项目管理平台中配置流程，先确定共同语义，再设置字段、权限、通知和变更记录。平台是执行载体，不是判断权威；最重要的是团队能否从工单中看出缺陷造成了什么、结论依据是什么，以及何时需要重新评估。

2. 最后的判断原则

严重程度不是给缺陷贴上“吓人”或“不重要”的标签，而是把不确定的损害变成可验证、可更新、可行动的风险描述。好的分级既不会让所有问题都冲到最高级，也不会因为证据不足就把风险压低；它允许暂定，要求复核，留下变更理由，并在用户真正恢复后才结束风险。

下一步可以从最近一次引发争论的缺陷开始：补齐影响对象、实际后果和绕行证据，让团队成员独立判断，再把分歧写进判定卡。能让成员根据同一事实做出相近判断，才算真正从0到1建立了严重程度机制。