严重程度怎么做？项目经理制度设计：Bug / 缺陷从0到1

严重程度怎么做，真正难的不是把缺陷分成“致命、严重、一般、提示”四档，而是让不同团队面对同一个故障时，能得出相近的判断，并据此采取一致的动作。项目经理如果只发布一张等级表，开发会按修复难度判断，测试会按功能影响判断，业务会按客户声音判断，最后等级越争越高，真正需要立即处理的问题反而淹没在“最高级”里。

一、先讲结论：严重程度描述影响，优先级决定顺序

1. 先把两个概念拆开

我设计缺陷制度时，第一条不是定义四个等级，而是明确“严重程度”和“优先级”不是一回事。严重程度回答：这个缺陷对产品、数据、业务或用户造成了多大影响？优先级回答：团队应该什么时候处理它？前者描述事实影响，后者是结合风险、时机和资源作出的行动决策。

把两者混为一谈，通常会出现两种相反的问题。第一种是“客户催得急，所以定为最高严重程度”；第二种是“修复要改架构，所以把缺陷定为最高严重程度”。客户催得急可能影响优先级，修复代价可能影响排期，但都不能替代对实际影响的判断。

一个容易操作的判断句是：先不看谁提的、谁催的、改起来多麻烦，只看当前或可复现条件下，用户和业务实际失去了什么。确认影响后，再判断是否立即处理、是否绕行、是否进入当前迭代。

2. 等级要少，边界要硬

从零搭建时，我通常建议先用四级：S1阻断、S2重大、S3一般、S4轻微。四级足以表达大多数团队需要的影响差异，也便于新人培训和历史数据分析。等级太多看似精细，实际会增加判断成本，尤其是相邻等级没有可验证边界时。

四级不是行业标准答案，而是制度起点。医疗、金融、工业控制等高风险场景可能需要增加安全或合规的专项标签；小团队也可以从三级起步。但无论几级，都要能回答三个问题：什么现象符合该级、哪些现象不符合、发生争议时由谁裁定。

3. 严重程度不应直接等于修复时限

严重程度与响应时限之间应有关联，但不能一一机械绑定。S1通常需要立即响应，S4通常进入常规队列；然而同样是S2，可能因发布窗口、客户影响面、可用绕行方案不同，安排在今天修复或下个版本处理。

如果公司把“S1必须两小时修复”写进制度，团队可能会为了避免违约而降低等级，或者在无法按时修复时隐瞒进度。更稳妥的做法是分别规定确认时限、处置时限、修复目标和升级机制，并说明目标是管理承诺，不是对复杂技术问题的保证。

4. 制度最终要改变行动，而不是只改变标签

一个有效的严重程度制度，至少应让接单人知道要不要立即止损、是否通知负责人、是否阻塞发布、需要多大回归范围、何时复核等级。若等级变了，行动却完全不变，说明等级可能只是报表字段，没有进入管理闭环。

二、背景和真实场景：等级争议通常从“同一现象、不同损失”开始

1. 一个错误提示，可能对应三种完全不同的影响

例如用户点击“提交”后出现错误提示。第一种情况是请求其实成功，只是提示文案错误；第二种情况是请求失败，但用户可以稍后重试；第三种情况是页面显示失败，后台却重复扣款。表面现象相似，实际影响从体验瑕疵到资金风险，严重程度不能因为截图长得一样就定成同一等级。

这也是我不建议只按“页面崩溃、功能不可用、体验问题”做分类的原因。它们是现象，不是影响。制度应要求报告人补充：用户最终能否完成任务、数据是否正确、影响范围有多大、是否可恢复、有没有替代方案。

2. 严重程度争议多发生在跨角色交界处

测试人员关注可复现性和功能覆盖，开发人员关注根因和改动风险，产品人员关注用户任务和业务目标，运营人员关注客户反馈与服务承诺。每个角色都可能掌握一部分事实，却不一定拥有完整判断。

项目经理的职责不是靠职位压出一个等级，而是把争论转成可核对的问题。例如，“客户很生气”要拆成受影响客户数、是否影响核心任务、是否存在临时方案；“改动很危险”要拆成涉及模块、回归面和回滚可能性。事实变清楚后，等级通常不需要争太久。

3. 制度设计前先看工作流，不要先抄别人的等级表

不同团队的产品形态、发布频率和事故处置能力差异很大。一个每天发布的在线服务团队，可以快速回滚并持续监控；一个季度发布一次的本地化交付团队，补丁成本和客户升级成本可能更高。照搬另一家公司的时限和等级名称，可能让制度看起来完整，却无法嵌入真实工作。

正式定级前，我会先抽取最近一到两个发布周期的缺陷，至少覆盖线上故障、阻塞测试、普通功能错误、体验问题和被退回的缺陷。对照当时的影响、处理过程和最终结果，检查现有团队究竟在哪些情形上判断不一致。

三、常见误区：看起来在分级，实际上在奖励错误行为

1. 把“修复难”当成“影响大”

复杂、陈旧、牵涉多个系统，意味着修复成本或技术风险较高，不必然意味着用户影响高。反过来，一个只改一行配置的错误，也可能让大量用户无法登录。若按照修复难度定严重程度，团队会把“难处理”误写成“更严重”，之后既无法分析真实影响，也无法估算缺陷治理效果。

制度上应将修复成本放在估算、风险或技术方案字段中，而不是放进严重程度定义。开发负责人可以提示改动风险，但不应单独决定用户影响等级。

2. 把客户声音大小当成影响范围

一个重点客户提出的问题值得认真处理，但不能仅凭客户级别把缺陷升到S1。否则团队会形成“谁能找到更大客户，谁就能提高等级”的机制。客户重要性可以影响商业优先级，实际影响范围仍要通过受影响账号数、业务量、合同承诺和可替代流程来说明。

这并不意味着小范围问题就不重要。某个问题即使只影响一个组织，如果造成关键数据泄露或合同级业务中断，也可能是高影响。关键不是机械数人数，而是把人数、单用户损失、风险性质和恢复可能性一并考虑。

3. 用“能不能复现”代替“影响有多大”

复现困难会影响调查效率，却不直接决定严重程度。间歇性错误如果只在低风险边缘场景出现，可能仍是一般问题；如果间歇性地重复扣款，即使暂时无法稳定复现，也必须按潜在影响采取保守处置。

建议把“确认状态”与“严重程度”分开记录。确认状态可用待复现、已复现、无法复现、需要日志等；严重程度记录当前证据支持的影响判断。两者并列，避免因为证据不足就把风险悄悄归为轻微。

4. 设一个“最高等级”，却没有定义升级条件

如果任何人都能把缺陷标成最高级，又没有升级门槛，最高级很快会失去区分度。常见后果是值班人员同时收到多个“紧急”提醒，只能靠关系、声量或个人经验排序。

可行的控制方式不是让报告人无法选择高等级，而是允许先标记“疑似S1”，同时要求触发条件、证据和升级责任人。初始判断要快，复核也要快；不能因为需要审批，就让真实故障在流程里等待。

5. 把四级写成形容词，不写成可判断的规则

“严重影响、较大影响、一般影响、轻微影响”只有程度词，没有边界。两个人可以都认为自己遵守了规则，却给出完全不同的结果。定义应尽量落到业务结果，例如核心任务是否无法完成、数据是否错误、是否影响多个客户、是否有可靠绕行方案。

但也不要把定义写成一张无法维护的穷举清单。产品场景会变化，制度需要用“原则加典型示例”的结构：原则负责覆盖新场景，示例负责帮助新人校准。

6. 为了降低指标而频繁降级

如果团队把严重程度与绩效扣分、事故追责直接绑定，成员会有动力把问题定得更轻，或者在复盘时修改历史等级。指标一旦影响个人评价，就容易从描述事实变成维护结果。

等级可用于风险分析和资源安排，但不宜直接作为单人绩效的惩罚依据。管理者应看缺陷产生机制、发现时点、预防措施和响应质量。等级变化必须保留原因、时间和操作者，不能覆盖最初记录。

四、专业判断逻辑：把“影响”拆成能被核实的维度

1. 先判断用户任务有没有被阻断

第一问是：用户是否无法完成关键任务？这里的关键不是某个按钮能不能点，而是用户目标是否还能通过合理路径达成。比如主流程入口失效，但已有可用的备用入口，影响可能低于完全无法操作；如果备用路径只对内部人员开放，对普通用户并不算有效绕行。

要判断绕行方案是否成立，至少确认四件事：用户知道怎么做、权限允许这么做、流程不会引入额外错误、团队能在缺陷修复前持续支持。仅仅“理论上可以让管理员手动改数据库”，不能算面向用户的有效替代方案。

2. 再判断影响了谁、影响到多少

影响范围不应只用“少量用户”“很多用户”这样的描述。尽量记录分母和时间窗口，例如受影响的活跃账号数占比、失败请求占比、涉及的租户数、从何时开始、是否仍在扩大。没有可靠数据时，应明确写“未知”，并安排监控或查询，而不是把未知直接当成零。

用户数量也不是唯一尺度。企业系统中，一个关键管理员操作可能影响少数账号，却让整个组织无法结算；消费产品中，单个用户的非核心偏好设置异常，通常影响较窄。判断要回到业务结果，不能只数人头。

3. 检查数据、安全和合规后果

功能暂时不能用，很多时候可以等待修复；数据被错误覆盖、重复提交、错误授权或无法追溯，风险性质就不同。缺陷制度应单独设定数据与安全风险的升级规则，避免它们被普通的“受影响人数”平均掉。

涉及隐私、权限、资金、合规报告或审计链路时，项目经理不应独自判断风险是否可接受。应按组织规定通知安全、法务、数据保护或业务责任人，并启动相应事件流程。普通缺陷流程不能替代安全事件响应。

4. 判断损失是否可恢复、是否持续扩大

同样是错误写入，若可以从可靠日志无损恢复，与没有备份、无法确认影响范围，风险并不相同。判断恢复能力时，要看恢复所需时间、数据完整性、人工介入成本和重复发生可能性，而不只是“理论上能回滚”。

持续扩大的故障要优先止损。比如每分钟新增的失败交易都在累积，即便最终修复要数天，先关闭错误入口、切换流量或限制高风险操作，可能比立即寻找完美修复更重要。缺陷严重程度和事件处置动作应在此处衔接。

5. 用影响矩阵，不用简单加总分数

把影响维度全部量化成分数，再相加，看起来客观，却可能掩盖关键风险。一次数据泄露不应因为受影响人数暂时少，就被其他低分项抵消。因此我更倾向于“门槛规则加矩阵”：先识别不可被抵消的红线，再结合功能阻断、范围、绕行和恢复能力判定其余等级。

表中的典型情形是校准示例，不是自动判定器。比如重要功能失效，如果只有一个测试账号受影响且存在经验证的替代流程，可能需要下调；如果影响正在扩大且无法确定上限，就应先按更高风险处理，再随着证据完善重新定级。

6. 证据不足时采用临时等级和复核时间

真实项目里，缺陷刚上报时往往不知道影响总量。此时不应在“立即定死等级”和“等待调查后再处理”之间二选一。可以标记“暂定S1”或“暂定S2”，同时指定调查责任人、下一次更新时间和升级条件。

临时等级不是永久标签。证据补齐后，必须记录是上调还是下调、依据是什么、由谁确认。这样既能避免早期信息不足造成延误，也能防止“先升高吸引注意、随后无人复核”的等级堆积。

五、从零到一搭制度：字段、流程、责任人都要一起设计

1. 缺陷记录至少要有可决策的信息

制度不能只要求写标题、复现步骤和截图。项目经理需要一份足以支持判断的最小信息集，让接单人不必在评论区反复追问。字段不宜多到让报告人放弃填写，但必须覆盖影响、证据和处置。

• 用户任务：用户原本想完成什么，当前在哪一步失败。
• 实际结果：系统做了什么，是否产生重复、错误或不可逆结果。
• 影响范围：涉及哪些账号、组织、版本、环境和时间段；未知项明确标出。
• 复现条件：操作步骤、前置数据、频率、浏览器或设备等环境信息。
• 绕行方案：是否经过真实验证，适用于哪些用户，有什么额外成本。
• 风险线索：是否关联数据、权限、资金、安全、合规或对外承诺。
• 建议等级与依据：报告人提出初步判断，并说明符合哪条规则。
• 负责人和更新时间：由谁继续调查，何时提供下一次状态。

“未知”应该是一种合法填写结果。强迫报告人猜测影响范围，会制造虚假的精确性。制度应进一步规定谁负责补证据，以及高风险场景下必须在什么时间内完成初步核查。

2. 为四个等级写边界，而不是只写口号

等级定义建议采用固定结构：影响范围、用户任务、数据风险、绕行能力、默认动作。每个等级各写一段定义，再配两到四个团队自己的真实案例。案例必须说明为什么是这个等级，以及哪些相似情况不适用，避免后来被当成机械模板。

例如，S3的边界可以表述为：主要业务流程仍可完成；影响限于特定条件或局部用户；存在经验证的合理绕行；没有确认的数据损失或安全风险。若其中一项不满足，就需要重新评估，而不是因为“平常都叫一般”而沿用旧判断。

3. 明确谁能建议、谁能确认、谁能升级

报告人可以建议等级，测试或支持人员负责补充证据，产品负责人判断业务任务和用户影响，技术负责人评估止损与修复风险。项目经理负责组织决策、记录理由和推动时限，但不应成为所有技术与合规结论的唯一裁定人。

升级权限要足够简单。任何人发现正在扩大的安全、数据或业务连续性风险，都应能触发紧急响应；但正式等级仍需在规定时间内由责任人复核。制度追求的是快速暴露风险，而不是把每次升级都变成审批考试。

4. 把定级嵌入接单、修复、验证和复盘

建议流程从提交开始：报告人填最小信息集；接单人完成初步筛查；高风险问题先止损并升级；责任人确认暂定等级；技术团队给出方案与影响范围；修复后执行对应回归；关闭前记录实际影响、根因和预防措施。

等级变更不是流程异常，而是正常校准。早期可能高估风险，调查后下调；也可能监控发现影响扩大后上调。每次变化都应保留旧值、新值、原因和时间。若系统只保存当前字段，组织就无法判断制度是否稳定，也无法复盘当时为什么作出某个决策。

5. 用项目管理平台承载规则，但不要把配置当制度

以PingCode为例，团队可以在项目管理平台中按自身版本和配置能力，设置严重程度、优先级、确认状态、责任人、影响范围、到期时间和变更记录等字段，再用工作流提示缺少关键证据的事项。对于一百人以上、多项目并行的组织，这类统一入口有助于减少各团队各写一套字段的情况。

不过，平台字段配置不等于制度完成。某个下拉框写着“S1至S4”，并不会自动让不同团队理解一致。上线前要确认字段是否能被统计、变更是否留痕、权限是否合理、通知是否会产生噪声；还要由项目经理组织校准练习，确保规则真正进入日常决策。

如果工具暂时不支持完整工作流，也可以先用轻量表单、缺陷模板和每周复核会运行制度。先验证判定逻辑，再决定是否自动化。过早把不成熟的规则固化进系统，后续修改会让多个项目同时受影响。

六、案例与数据观察：同一故障如何从争论变成可执行决策

1. 情景案例：提交失败提示背后出现重复记录

下面是情景模拟案例，不对应某家企业的真实事故。某企业内部系统在提交审批时，用户偶尔看到“提交失败”，但后台可能已经保存成功。用户再次点击后，部分记录重复生成。最初缺陷标题只有“审批提交报错”，测试认为偶现、影响面小，建议S3；业务人员则认为审批流程受阻，建议S1。

团队没有先投票定级，而是补了四项证据：用户重试后是否重复创建；重复记录占提交量的比例；是否有自动去重机制；审批人员能否通过记录编号识别并撤回。调查发现，重复记录可以被识别，但需要人工清理；尚未发现无法恢复的数据损失，且影响集中在一个版本和特定网络延迟条件下。

据此，团队暂定S2而非S1：重要任务受到影响，且人工处理有成本，但现阶段没有证据表明主流程全面中断或出现不可逆损失。团队同时关闭自动重试、增加重复记录监控，并要求在两小时内更新影响范围。这里的关键不是“两小时”这个数字，而是定级、止损和补证据并行发生。

随后监控显示受影响提交量低于整体提交量的0.5%，且重复记录均可安全识别清理，最终等级维持S2并进入快速修复。若后续发现重复记录触发了错误付款或审批绕过，等级应立即升级，不能因为最初判断已经写入系统而坚持原结论。

2. 案例中最有价值的不是0.5%，而是分母和条件

单说“有五十条重复记录”，无法判断风险有多大。要知道同期提交总量、影响持续时间、涉及组织数、记录是否可恢复、是否引发下游动作。案例里使用0.5%只是说明团队掌握了分母；这个数值本身不是通用的S2门槛。

组织可以从自己的历史数据里找阈值，但不能只看百分比。例如交易系统的0.1%错误可能已经很严重，内部低频设置项的0.1%异常则未必。阈值必须和业务损失、用户任务及恢复能力一起解释。

3. 用历史样本做一致性校准

新制度上线前，我建议挑选二十到三十条脱敏历史缺陷，让测试、开发、产品和支持人员独立定级。不要先开会讨论，否则最先发言的人会影响后续判断。收集结果后，再看哪些案例分歧最大、分歧来自证据缺失还是定义不清。

一致性不需要追求所有人永远给出相同答案。更重要的是：高风险问题不能被多数票压低；普通问题的分歧能在可接受时间内解决；每次分歧都能指出规则需要补充的地方。试运行时可以追踪定级争议率、复核后的等级变更率、漏报高风险数和平均初筛时间。

4. 监测制度质量，不只监测缺陷数量

缺陷数量受产品规模、测试力度、发布频率和报告文化影响，不能简单解释成质量变差。严重程度制度上线后，如果S1数量突然增加，可能是风险识别改善，也可能是等级膨胀；必须结合影响证据、升级原因和最终损失判断。

我会关注几个组合指标：高等级缺陷中有多少后来被下调；高等级问题从发现到止损花了多久；缺陷关闭后同类问题是否复发；S3、S4积压中有多少超过团队设定的观察期限。单个指标容易被优化，组合起来才更接近制度是否有效。

七、不同情况下的行动建议：同一套规则要有不同处置路径

1. 正在影响线上用户，且故障仍在扩大

先止损，再完善定级材料。指定一名事件负责人，确认影响范围、当前增长速度、可用的开关或回滚路径，并同步值班、业务和相关负责人。此时允许暂定高等级，但要设置下一次更新时间，避免紧急状态持续却没有新的证据。

修复方案不一定是最漂亮的代码改动。若关闭某个入口可以阻止错误继续扩大，且不会造成更大损失，止损通常优先于完整重构。团队应同步判断数据修复、用户沟通和下游核对需求，不能只盯着代码合并。

2. 问题影响少数用户，但涉及数据或权限

不要被受影响人数少迷惑。先确认是否存在越权访问、错误共享、数据不可逆修改、资金或隐私风险，再通知对应的专业责任人。必要时启动独立的安全或合规流程，缺陷等级只是其中一部分管理信息。

如果事实尚不清楚，临时采取保守措施，例如暂停高风险操作、缩小权限或保全日志。保守不等于夸大定级，而是先降低可能损失，再依据调查结果修正影响结论。

3. 问题只在特定客户、设备或配置下出现

先看配置是否属于产品承诺支持范围，客户是否有合理工作绕行，以及定制差异是否改变了风险。如果受影响用户少但业务合同承诺明确，优先级可能很高；严重程度仍按实际影响判断，二者需要分开记录。

不要用“只影响一个客户”直接定为轻微，也不要因为是大客户就自动定为最高。记录客户数之外，还应写清组织内受影响人数、关键任务、时效承诺、替代操作和可能的连带影响。

4. 缺陷难以复现，但投诉或监控信号持续增加

建立短期观察和证据收集计划：记录时间戳、请求标识、版本、账号范围和错误率；在不扩大风险的前提下增加日志或监控；指定下一次判断时间。暂时无法复现不能作为关闭理由，也不能自动证明问题严重。

如果潜在损失很高，团队可以先限制相关功能或增加人工核验。对于低风险问题，则可以继续观察，但要设定停止条件，例如连续多长时间无新样本、监控覆盖了哪些用户、何时重新开启排查。

5. 处于版本冻结或发布窗口临近

发布窗口影响处理优先级和变更策略，不应自动改变严重程度。一个S4文案问题可能因活动上线时间而需要快速修复；一个S2问题如果有验证充分的绕行，也可能选择延后发布并持续监控。

决策时至少比较三种风险：带缺陷发布的用户损失、临时修复引入回归的风险、延迟发布造成的业务损失。项目经理应记录选择依据和回滚条件，而不是只问“能不能赶上”。

6. 小团队与大型组织的做法不同

小团队可以由产品、测试、开发共同在短会上完成定级，重点是定义清楚、记录轻量、事后能复盘。没有必要为每个S3缺陷设置多层审批，否则流程成本可能超过风险本身。

大型组织更需要跨团队的共通定义、明确的事件升级路径、字段治理和定期抽样校准。不同产品可以增加业务特有补充规则，但基础等级含义应保持稳定，否则汇总报表会把无法比较的数据放在一起。

八、制度落地中的取舍：严谨、速度与管理成本如何平衡

1. 等级越精细，决策未必越准确

增加S2.1、S2.2或更多子级，只有在这些区分会改变处置动作时才有价值。如果两个等级既没有不同响应要求，也不进入不同报表，它们只是增加记忆负担。判断边界模糊时，先补案例和触发条件，通常比增加等级更有效。

反过来，如果安全、数据完整性或合规风险需要专门路径，可以新增风险标签或专项事件类别，不一定要把普通严重程度拆得更复杂。标签负责说明问题性质，等级负责说明影响大小，优先级负责安排处理顺序。

2. 数字阈值方便统计，也可能造成错误精确

“影响超过百分之几就是S1”看起来容易执行，却可能鼓励团队围绕阈值讨价还价。受影响比例还依赖分母：活跃用户、注册用户、请求数、组织数，换一个分母结论就可能不同。所有阈值都要写明口径、统计时间窗和数据来源。

有可靠监控时，数字阈值可以作为升级触发器；没有可靠数据时，应以任务影响、风险后果和证据不确定性结合判断。阈值是警报线，不应取代责任人审查。

3. 固定时限有助协作，但必须区分响应与修复

确认收到、开始调查、给出止损措施、提供修复版本、完成验证，是不同的时间节点。把它们压成一个“解决时限”，会让复杂问题看起来必然超期，也会诱发为了关单而采用不充分修复。

团队可以给出目标响应窗口，但必须说明超出时怎么办：谁需要获知、是否更新业务方、是否调整发布计划、是否需要临时缓解。时限管理的核心是透明和升级，而不是所有缺陷都承诺在同一时间内彻底解决。

4. 自动化减少遗漏，也会放大错误规则

自动提醒、字段必填和工作流升级适合处理稳定规则，例如S1必须指定负责人、等级变更必须写原因、关闭前必须有验证结果。它们不适合自动推断复杂业务影响，尤其不应只凭关键词把缺陷直接升级为最高级。

如果自动化规则依赖的字段质量不高，系统会制造更多误报。先用人工流程运行一个周期，确认定义稳定、责任明确、数据字段有用，再逐步自动化，通常比一次性配置复杂审批链更可靠。

5. 完整留痕与轻量协作之间要找到边界

高风险缺陷需要完整决策记录，包括影响范围、止损措施、等级变化、对外沟通和恢复验证。低风险文案问题没有必要写成事故报告。制度可以规定记录深度与严重程度相匹配，让重点留痕而不把每条缺陷都变成行政负担。

6. 评估规则时看行为变化，不只看文档完整度

一份定义精美的制度，如果团队仍然靠群聊临时喊人、等级没有人复核、关闭时没有回归证据，就没有真正落地。试运行期间应观察报告质量、初筛耗时、等级变更原因、止损速度、重复故障和积压结构，再决定哪些规则需要收紧或简化。

九、下一步怎么做：用四周完成可运行的第一版

1. 第一周：收集样本，先找出分歧来源

抽取近期缺陷，覆盖不同等级、不同产品和不同处理结果。统一整理用户任务、影响范围、数据后果、绕行方案和修复结果。暂时不要急着发布新等级表，先识别团队到底是缺字段、缺边界，还是缺决策责任人。

2. 第二周：写定义和例子，做独立判定

形成四级定义、紧急升级规则、证据字段和变更留痕要求。让不同角色独立判定一批历史样本，再集中讨论分歧最大的案例。优先补足S1与S2的边界，以及S2与S3之间“是否有有效绕行”的判断。

3. 第三周：选一个项目试运行

选择业务风险可控、成员愿意配合的项目，按新流程运行。每天或每周抽查高等级缺陷，确认是否有事实依据、是否及时止损、是否按要求更新状态。试运行阶段允许修正规则，但每次改动都要说明原因和生效范围。

4. 第四周：复盘指标，决定是否推广

比较试运行前后的报告完整度、等级争议率、复核变更率、初筛时间和同类问题复发情况。若争议减少但高风险漏判增加，不能宣布成功；若流程更快但团队新增了大量无效提醒，也要调整自动化和通知范围。

1. 先固定概念：严重程度描述影响，优先级描述处理顺序。
2. 再固定边界：用用户任务、影响范围、数据风险、绕行和恢复能力定义等级。
3. 随后固定责任：明确谁补证据、谁确认等级、谁能触发升级。
4. 最后验证结果：用历史样本、试运行数据和复盘结果持续修订。

我认为，严重程度制度最重要的产出不是“四级标签”，而是组织能够在证据不完整时先控制风险，在事实变化时及时调整判断，并在事后解释当时为什么这样决策。等级少一点没有关系，边界模糊、责任不清和没有复核，才会让制度失效。

项目经理下一步可以先做一件具体的事：从最近一个发布周期中挑出十条最有争议的缺陷，按“用户任务、影响范围、数据后果、绕行方案、恢复可能性”重新复盘。若团队无法在这五项上形成事实共识，就先补证据和流程；若事实一致但等级仍不同，再修订定义。这样做，比直接发一张新的等级表更接近从零到一。