评级用于排序而非绝对判断
别名: 优先级排序 · 严重度量表 · 问题分级 · 序数量表
概念解释
严重度分数是帮助团队决定先修什么的相对信号，不是问题的客观物理量。同一个"3 分"在不同产品、样本、版本或业务周期中可能对应不同人群规模和风险；评级（severity rating）应与证据、假设和修复成本一起看，脱离这些上下文单独引用一个数字是对这个量表的误用。这一条建立在前一条"频率、影响、持续性三因素合成"之上：三因素给出了分数怎么算，这一条管的是算出来之后能不能拿它做绝对比较——答案是不能，只能拿来排序。
机制
严重度量表本质上是一种序数量表（ordinal scale），它只保证"3 分比 2 分更需要优先处理"这个排序关系成立，不保证"3 分的严重程度恰好是 2 分的 1.5 倍"这种算术关系成立——评级把来自可用性测试、日志、工单、现场观察等多个不同来源、不同性质的观察压缩进几个离散等级，这个压缩过程本身必然丢失原始证据里的细节和量纲，丢失之后无法通过对比分数的大小把它找回来。这也是为什么"把不同评估者打出的分数直接相加求平均"是一种常见误用：平均值假设分数之间的间隔是相等的，但序数量表并不保证这一点，两个都打 3 分的评估者可能依据的是完全不同的证据强度。评级真正发挥作用的地方是资源分配的相对排序——在时间和人力有限的前提下，先处理排在前面的问题，并且保留一份可以事后复审的理由链条，而不是在会议室里为 2.6 分还是 2.8 分争论不休。
边界
有些类别不能被这套排序逻辑覆盖，需要设硬阈值直接跳过排队：任务被完全阻断、造成数据丢失、涉及安全或法律合规、触及无障碍最低要求的问题，不能因为综合评分排在靠后就被无限期推迟——这类问题的处理顺序不是由严重度分数决定的，而是由是否触碰底线决定的，量表在这里让位给规则。反过来，评分不高但修复成本极低的问题（改一个文案、调一个间距）值得顺手处理，不必因为排序靠后就完全搁置——这时候决定优先级的实际上是"分数除以修复成本"这个性价比，而不是分数本身。评级也不能替代真正的定量影响估算：如果产品有能力直接测量某个问题导致的转化率下降或工单增量，这类真实业务数据应该优先于人工评级，评级更适合用在缺少这类数据、必须靠专家判断做初步排序的阶段。
怎么落地
- 在每张问题单里同时记录严重度等级、支撑这个等级的具体证据、评估时的假设、预估受影响用户数、修复成本和预期收益，让排序过程可以被后来者追溯，而不是只留一个孤立的数字。
- 用等级做日常排序，但为最高危类别（阻断、数据丢失、安全、合规、无障碍）单独设一道发布门槛，这道门槛不参与常规的分数排队。
- 给每个等级配一两个真实案例作为参照样例，让不同人打分时有共同的锚点，减少"同样是 3 分，含义却完全不同"的情况。
- 验证办法：定期抽查排序结果，问团队"为什么前五项排在这里"，如果答案说不出具体证据只能说"感觉比较严重"，说明评级正在被当成绝对判断使用而不是排序工具；业务上下文发生变化（新版本上线、用户群体转变）时要重新评估，而不是沿用旧分数。