缺陷严重程度和修复优先级经常被当成同一个字段使用，结果要么把影响不大的问题排到最前，要么让真正影响业务的问题长期留在待办里。两者回答的是不同问题：严重程度衡量缺陷造成的后果有多大，修复优先级决定团队接下来先处理哪一个。本文按定义、关系、混淆边界、相邻概念和落地做法逐层说明，帮助你在缺陷单上把两个字段分开判断。
要点总览（TL;DR）
- 严重程度衡量缺陷造成的业务、用户与系统后果，修复优先级决定团队先处理哪一个，两者判断对象不同。
- 严重程度是优先级的主要输入，优先级还要结合暴露范围、临时规避手段、发布窗口和修复成本综合排定。
- 高严重度缺陷可能因尚未上线或已有规避方案而排在后面，低严重度缺陷也可能因阻塞关键流程而提前处理。
- 常见混淆包括把严重程度直接当排序结果、用“紧急”描述影响大小、跨环境评级不一致，区分关键是先对齐影响事实再定排序。
- 落地时在缺陷单上分设两个必填字段，评审中先定严重程度、再定优先级，并保留变更记录供复盘。
严重程度与修复优先级各自指什么
严重程度回答“这个缺陷造成的影响有多大”。它的判断对象是缺陷已经或可能带来的业务、用户与系统后果，例如核心流程是否中断、数据是否出错、用户能否继续完成操作、影响范围是单个用户还是一批用户。判断依据是缺陷的客观后果，与团队当前有多少人力、这个版本什么时候发布没有直接关系。
修复优先级回答“先修哪一个”。它的判断对象是团队排期与资源投入顺序，也就是在有限的人力和时间内，哪个缺陷应该先进入开发、先被验证、先随版本发布。优先级是一项决策结果，判断时要把严重程度、紧迫性、暴露范围、是否存在临时规避手段、发布窗口和修复成本放在一起权衡。
两个字段的判断时点也不同。严重程度通常在缺陷提交和评审阶段确定，由提交人描述现象、测试或业务方确认后果，之后随影响变化而调整；优先级在排期和分诊环节确定，由负责缺陷处理的团队结合当前迭代目标、版本节奏和资源情况给出。判断人不同、判断时点不同，是两者需要分字段记录的根本原因。
| 对比项 | 严重程度 | 修复优先级 |
|---|---|---|
| 回答的问题 | 影响有多大 | 先修哪一个 |
| 判断对象 | 缺陷造成的业务、用户与系统后果 | 团队排期与资源投入顺序 |
| 主要判断依据 | 功能中断程度、数据影响、影响范围、可恢复性 | 严重程度、紧迫性、暴露范围、临时规避、发布窗口、修复成本 |
| 常见判断角色 | 缺陷提交人、测试、业务或产品负责人 | 缺陷处理负责人、研发负责人、版本排期角色 |
| 典型判断时点 | 提交与评审阶段，随影响变化调整 | 排期与分诊阶段，随版本节奏调整 |
| 常见误用 | 用“紧急”描述影响大小 | 直接照搬严重程度作为排序结果 |
两者的关系：输入与决策的关系
严重程度是修复优先级的主要输入之一，但只是输入，不是结论。合理的判断链条是：先确认缺陷的客观后果，得到严重程度；再把严重程度放进当前版本节奏、用户暴露范围、是否有临时规避手段、修复所需工作量等条件中，得到修复优先级。前者相对稳定，后者随团队处境变化。
高严重度不等于最高优先级，常见情形包括：缺陷影响很大，但只出现在尚未发布的功能分支上，当前没有真实用户暴露；或者已有明确的临时规避方案，用户可以继续完成关键操作，团队可以按正常节奏修复；又或者修复需要改动底层结构，仓促上线会带来更大风险，需要安排专门窗口处理。这些情况下，严重程度仍然要如实记录，优先级则可以排在更靠后的位置。
低严重度也不等于可以长期搁置。一个界面文案错误如果出现在开户、支付确认或合规告知等关键流程上，可能阻塞用户完成操作或引发误解，优先级就会被提前；一个偶发的提示异常如果每次发布都会反复出现、消耗测试和客服大量沟通成本，也可能被排进当前迭代。判断时看的是“现在不修会带来什么后果”，而不只是“影响看起来大不大”。
把这条链条写清楚，团队在评审时就有了共同语言：先对齐影响，再对齐排序。两者出现分歧时，讨论的重点是优先级判断所依据的条件，例如暴露范围、规避手段和发布窗口，而不是反复争论严重程度定高了还是定低了。
常见混淆边界怎么区分
实际工作中，混淆往往出现在几个固定位置。下面按情形给出区分口径。
把严重程度直接当优先级使用
表现是按严重程度从高到低排序，严重程度高的先修，其余顺延，优先级字段形同虚设。区分口径是：严重程度确定后，必须再经过一次排期判断才能得到优先级。如果某个高严重度缺陷因为环境未上线而排在后面，应在缺陷单上写明原因，例如“仅测试环境出现，待发布前统一修复”，让排序结果可被复核。
用“紧急”替代严重程度描述
“紧急”“尽快”“很重要”描述的是时间压力，属于优先级语言，无法说明缺陷本身造成了什么后果。区分口径是：严重程度字段只写影响，例如“订单提交后金额显示错误，影响全部新订单”；紧迫性写进优先级判断依据，例如“大促前必须修复”。两者分开写，后续复盘才能区分是影响判断有误，还是排期判断有误。
同一缺陷在不同环境或版本下严重程度变化
同一缺陷在测试环境、预发布环境和生产环境的影响可能不同，在旧版本和新版本上的表现也可能不同。区分口径是：严重程度按缺陷实际造成后果的环境和版本记录，并在描述中注明适用范围；当缺陷扩散到影响更大的环境时，更新严重程度并留下变更记录。优先级随之重新评估，但不要把环境变化直接写成严重程度升级而不说明依据。
跨团队对同一缺陷评级不一致
业务方、测试和研发对同一缺陷的严重程度判断不一致时，容易各自按自己的理解排期。区分口径是：以可观察的后果为共同基准，先对齐“影响了谁、影响多少用户、能否继续操作、数据是否出错”这几个事实，再确定严重程度；优先级由负责排期的团队在事实对齐后给出。分歧无法当场解决时，记录双方依据并提交到缺陷评审例会上统一口径，避免同一类缺陷在不同团队得到不同评级。
和相邻概念的边界：分诊、责任分配与工单SLA
缺陷分级容易和几个相邻管理动作混在一起，划清边界有助于把讨论聚焦在影响与排序上。
缺陷分诊与责任分配关注的是“由谁处理、流转到哪个环节”。分诊决定缺陷进入哪个模块、交给哪个负责人、是否需要补充信息，责任分配决定后续跟进人。分级为分诊提供输入，但分诊本身不重新定义严重程度，也不替代优先级排序。
工单优先级与SLA管理关注服务响应时限与承诺，例如多长时间内首次响应、多长时间内解决。它面向服务请求和事件处理，约束的是响应节奏；缺陷严重程度描述的是产品缺陷造成的影响，两者对象不同。工单关联到缺陷工作项后，工单侧的响应承诺和缺陷侧的修复排序应分别记录，避免用SLA时限倒推缺陷严重程度。
本文讨论的范围限于缺陷分级本身，即严重程度与修复优先级的定义、关系和区分口径。分诊的具体归属流程、责任分配规则以及SLA时限设计属于其他管理主题，需要时另行展开。
一个具体例子：同一缺陷的两次判断
以下为演示情景，用于说明判断顺序，不代表真实客户案例。
某团队在版本回归中发现一个缺陷：用户在结算页修改收货地址后，订单金额没有按新地址的运费规则刷新，仍显示旧金额。该缺陷出现在即将发布的版本中，当前仅测试环境可复现，生产环境尚未上线该改动。
第一次判断严重程度：缺陷会导致用户看到的应付金额与实际运费不一致，可能引发下单错误和后续退款沟通，影响所有使用该结算流程的用户，且没有临时规避手段。据此定为高严重程度，描述中注明“结算页地址变更后金额未刷新，影响全部走该流程的订单”。
第二次判断修复优先级：缺陷尚未在生产环境暴露，距离发布还有两个迭代；修复涉及运费计算与页面状态的联动，工作量中等；如果延后，需要确认发布前必须完成。综合这些条件，团队将其排在当前迭代的高优先级位置，理由是“发布前必须修复，否则新版本上线即影响全部订单”，同时记录“若发布延期，优先级随发布窗口重新评估”。
如果判断顺序颠倒，先按“发布前必须修”定成最高优先级，再回头补一个严重程度，容易出现两种误判：一是把紧迫性误写成影响范围，导致严重程度虚高，后续同类缺陷的评级失去参照；二是当发布窗口变化时，优先级下调，但严重程度没有同步复核，缺陷单上留下互相矛盾的两个字段。先定影响、再定排序，并分别写明依据，才能让两个字段在后续复盘中各自可查。
落地时怎么让两个字段各司其职
让两个字段真正分开，需要字段设置和评审做法同时到位。
字段设置上，缺陷单分别设置严重程度与优先级两个字段，各自给出有限、含义明确的取值。严重程度可按“致命、严重、一般、轻微”分级，每一级用一句可观察的后果描述作为判定标准，例如“致命”对应核心流程中断或数据错误，“轻微”对应不影响操作的展示问题。优先级可按“立即处理、本迭代处理、排期处理、暂不处理”设置，并在字段说明中写明它表示排期顺序。两个字段都设为必填，避免提交时只填一个。
评审做法上，采用先定严重程度、再定优先级的分步流程。缺陷提交后先由提交人和测试确认影响事实，完成严重程度判定；进入排期环节后，由负责缺陷处理的团队结合版本节奏、暴露范围和修复成本给出优先级，并在缺陷单上写明排序理由。两步分开进行，评审记录中能看出每个结论依据的是哪些事实。
记录与复盘上，保留缺陷的状态流转和字段变更历史。当严重程度或优先级被调整时，记录调整原因，例如“生产环境复现，严重程度上调”“已有临时规避方案，优先级下调”。迭代结束后按严重程度分布和优先级分布分别统计，观察是否存在高严重度长期未处理、低严重度频繁插队的情况，据此修正判定标准。
在工具承载上，ONES Project 适配缺陷管理等研发场景，支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况，可统计缺陷状态分布。团队可以在缺陷工作项上配置分级字段，用状态流转记录支撑上述评审与复盘；缺陷工作项的字段自定义范围以实际配置为准。当缺陷由服务工单转入时，ONES Desk 的工单可一键关联到 ONES Project 的缺陷工作项并持续跟踪，工单侧的优先级与缺陷侧的严重程度分别记录，对应前面划出的边界。
常见问题
严重程度定得高，优先级就一定要排在最前吗？
不一定。严重程度记录的是缺陷造成的客观后果，优先级是团队在当前资源与节奏下的排期决策。一个高严重度缺陷如果只出现在尚未发布的分支上，或者已有临时规避手段让用户能继续完成关键操作，优先级可以排在更靠后的位置。此时应在缺陷单上写明排序理由，例如“仅测试环境出现，发布前统一修复”，让排序结果可被复核，同时保留真实的严重程度记录。
同一缺陷在测试环境和生产环境表现不同，严重程度要不要改？
要按缺陷实际造成后果的环境和版本记录严重程度，并在描述中注明适用范围。当缺陷扩散到影响更大的环境时，更新严重程度并留下变更记录，优先级随之重新评估。需要注意的是，环境变化本身不自动等于严重程度升级，调整时要写清依据，例如“生产环境复现，影响全部新订单”，避免字段变更缺少可追溯的理由。
业务方和研发对同一缺陷的严重程度判断不一致，怎么处理？
先回到可观察的后果事实，对齐“影响了谁、影响多少用户、能否继续操作、数据是否出错”这几个问题，再确定严重程度；优先级由负责排期的团队在事实对齐后给出。如果当场无法达成一致，记录双方依据并提交到缺陷评审例会统一口径，避免同一类缺陷在不同团队得到不同评级。分歧处理的关键是把讨论从“定高了还是定低了”转到影响事实和排序条件上。
缺陷由服务工单转入时，工单的响应时限能不能直接决定缺陷优先级？
建议分别记录。工单优先级与SLA管理约束的是服务响应时限与承诺，缺陷严重程度描述的是产品缺陷造成的影响，两者对象不同。用SLA时限倒推缺陷严重程度，容易让分级失去参照。工单关联到缺陷工作项后，工单侧的响应承诺和缺陷侧的修复排序各自保留，需要时再在排期环节综合权衡。ONES Desk 的工单可一键关联到 ONES Project 的缺陷工作项并持续跟踪，两侧字段分别记录，便于对应这条边界。
两个字段都设成必填，评审时还需要额外记录什么？
除了字段取值，建议记录判断依据和变更原因。严重程度写清影响事实，优先级写清排序理由，例如“发布前必须修复，否则新版本上线即影响全部订单”。当任一字段被调整时，记录调整原因，例如“已有临时规避方案，优先级下调”。迭代结束后按严重程度分布和优先级分布分别统计，观察是否存在高严重度长期未处理、低严重度频繁插队的情况，据此修正判定标准。
