Bug / 缺陷如何做好严重程度？项目成员最佳实践与操作步骤

同一个 Bug，被测试标成“严重”，开发认为“只是边界问题”，产品却要求“今天必须修”，往往不是谁不专业，而是团队把三个不同问题混成了一个：缺陷影响有多大、修复要排多急、现在是否具备修复条件。要把缺陷严重程度做好，关键不是给成员一张更长的等级表，而是先统一判断口径，再用影响范围、用户损失、数据风险和可绕行程度给出可复核的结论。

Bug / 缺陷如何做好严重程度？项目成员最佳实践与操作步骤

一、先讲核心结论：严重程度不是“谁声音大谁定”

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

我建议团队先把“严重程度”和“优先级”分开。严重程度描述缺陷造成的客观影响，例如核心功能不可用、数据丢失、权限越界或局部显示异常；优先级则描述团队什么时候处理它，受到版本窗口、客户承诺、修复成本、依赖关系和资源情况影响。

两者相关，但不能互相替代。一个安全漏洞可能影响范围尚不明确，却需要立刻升级处理；一个只影响少数内部用户的低风险问题，也可能因为演示或交付节点临近而被安排在本周修复。前者是严重程度高、优先级高；后者可能严重程度低、优先级暂时提高。

2. 先看后果，再看情绪和修复难度

判定严重程度时，我会先问：用户会遭遇什么后果？影响多少用户、哪些关键流程？是否涉及资金、隐私、安全、数据完整性或合规义务？有没有可靠的临时绕行方案？这些问题比“客户很着急”“开发改起来要两天”“页面看起来很糟”更能帮助团队稳定判断。

一个常用的判断顺序是：业务后果 → 影响范围 → 出现概率与触发条件 → 可恢复性和绕行能力 → 外部约束。修复成本通常影响排期，而不应直接决定严重程度。修起来困难，不代表用户损失更大；改起来简单，也不代表问题可以忽略。

3. 等级越少越容易执行，但每级必须有边界

对多数产品团队来说，四级严重程度已经够用：致命、高、中、低。若团队只有“高、中、低”三个等级，安全事件、数据损坏和普通功能阻断容易挤在同一级；若设置七八级，成员则会花更多时间争论“二级和三级的区别”，而不是补齐复现证据。

等级名称不是重点，关键是每一级都能回答三个问题：什么样的影响属于这一档？哪些情况不属于？遇到信息不足时由谁复核？如果团队无法举出最近真实发生过的例子，通常说明等级定义还停留在口号层面。

这张表只适合作为起点，不是脱离产品场景的通用真理。同样是“无法提交”，在内部试用环境和支付主链路上的后果截然不同；团队应根据自己的业务关键流程、用户类型和服务承诺校准等级定义。

二、背景和真实场景：为什么同一个缺陷会被打出不同等级

1. 缺陷报告记录的是观察，不一定已经说明影响

测试人员往往最先看到的是可复现现象：点击保存后页面报错、搜索结果为空、导出文件缺列。但现象并不等于业务后果。要判断严重程度，还需要知道用户正在完成什么任务、失败会不会导致数据丢失、失败发生在什么条件下、是否只影响某个浏览器或某类账号。

例如，“导出失败”可以是低、中、高等不同等级。若导出的是可重新生成的普通报表，且页面数据可直接查看，影响可能有限；若导出文件是财务结算的唯一交付物，且错过结算窗口会带来实际损失，影响就明显更高。描述同样简短，背景却改变了判断。

2. 用户数量不是唯一尺度，关键任务权重也很重要

“只有一个客户遇到”不等于低严重度。如果这个客户是使用核心流程的关键组织，或者问题影响到管理员、财务、安全运营等关键角色，一例也可能造成高损失。反过来，所有用户都能看到的轻微视觉错位，不一定比少数用户的数据错误更严重。

我会让团队把“覆盖人数”和“影响权重”分开记录。覆盖人数回答“多少人受影响”；影响权重回答“这些用户正在做什么、失败成本多高”。只记录用户数量，容易低估低频高损失事件；只记录业务重要性，则可能把每个客户意见都当成最高等级。

3. 版本、环境和时间窗口会改变处理紧迫性

缺陷严重程度通常应尽量保持稳定，但优先级可能随交付环境变化。上线前一天发现主流程存在严重错误，团队可能需要立即修复或阻断发布；同一问题在隔离测试环境中刚被发现，处理动作仍然重要，但可以先扩大验证、确认影响范围，再决定是否触发发布阻断。

这并不是说测试环境的问题可以降低等级，而是要分别写清“影响判断”和“处理安排”。例如，严重程度为高、优先级为本周处理；或者严重程度为中、优先级因客户演示调整为当日处理。让两个字段各自表达含义，后续复盘才看得懂。

4. 评审争议经常来自缺少共同的事实底座

当测试只写“功能不能用”，产品只记得客户催促，开发只看到日志中的偶发超时，三方讨论就会变成观点对撞。有效评审首先要补事实：复现步骤、环境版本、账号权限、发生频率、受影响范围、错误日志、数据前后状态和替代操作。

如果证据不全，不应靠投票把不确定性伪装成结论。可以先给出暂定等级，并注明“影响范围待确认”或“是否造成数据错误待验证”，再设定负责人和复核时间。暂定结论比含糊地写“待定”更利于行动。

三、常见误区：看似省事，实际会让等级失去价值

1. 把严重程度和优先级写成同一个概念

最常见的做法是把“紧急”当成严重程度。客户催得急，问题就被设为最高等级；没人催，问题就被设为低等级。短期看，这能快速回应声音最大的需求，长期却会让等级失去预测能力，团队也无法从缺陷数据中识别真正的产品风险。

更好的写法是分别记录：严重程度说明影响，优先级说明处理顺序，截止时间说明承诺。比如“严重程度：中；优先级：高；原因：影响下周客户验收；计划：周三前提供修复版本”。这比把所有紧迫信息塞进“致命”两个字清楚得多。

2. 按“修起来有多难”打分

开发评估发现改动涉及底层模块，需要多人协作，于是认为这是高严重度；另一个只改一行代码的问题，就被认为不严重。这把工程成本误当成用户影响，会造成两个后果：复杂但影响有限的问题被过度升级，容易修但损失重大的问题被低估。

修复成本当然重要，但它应该影响方案选择、排期、回滚策略和资源协调。严重程度评审可以记录技术复杂度，却不应把“难改”直接转成“严重”。如果风险来自修复本身，例如修复可能破坏兼容性，应另行记录变更风险。

3. 把“偶发”自动判为低等级

低频不等于低风险。偶发的数据覆盖、权限校验绕过或支付重复扣款，可能比稳定复现的样式问题危险得多。频率是判断影响概率的重要输入，但应和单次后果、可检测性、恢复成本一起看。

团队可以记录“发生频率”和“严重程度”两个不同字段。频率低但单次损失高的缺陷，应加强监控和影响排查；频率高但每次影响轻微的问题，则可通过批量修复和流程改进降低累计成本。

4. 用复现难度替代影响判断

某些环境相关问题难以稳定复现，测试同学可能担心报告不被接受，进而把等级调低。实际上，复现难度是诊断难度，不是用户损失大小。反过来，问题容易复现，也不代表它一定严重。

对难复现问题，应更重视时间戳、请求标识、日志、网络条件、设备信息和数据样本。等级可以先根据已知后果确定，再把“根因未明”作为调查状态。不要为了让问题看起来“更确定”，把风险描述写得过轻。

5. 只看受影响人数，不看受影响对象和流程

人数容易统计，业务损失却更需要上下文。一个权限错误即使目前只在一个账号上发现，也可能意味着同类账号均存在风险；一个界面问题即使全员可见，若不影响任务完成，等级未必最高。用单一人数阈值做判断，既会误判，也会鼓励团队争论“到底有多少人”。

我建议把范围拆成三层：已确认受影响人数、潜在受影响群体、关键角色或关键流程。对于潜在范围未知的高风险问题，先控制风险、查清边界，不要因为“目前只收到一例”就认定只有一人受影响。

6. 缺少复核机制，等级一旦填入就不再更新

严重程度不是录入后永远不变的标签。新日志可能证明问题只发生在旧版本；客户反馈可能发现数据已经被错误覆盖；监控数据也可能显示影响范围远超最初估计。等级应允许依据新证据调整，同时保留调整原因和时间。

为避免反复改级造成混乱，建议在缺陷中保留当前等级、原等级、调整人、调整时间和依据。复核不是追究谁最初判断错了，而是让风险随证据变化而更新。

四、专业判断逻辑：把影响拆成可讨论的维度

1. 先用四个核心问题做初判

如果团队暂时没有成熟的风险矩阵，可以先用四个问题做结构化判断。回答不要求精确打分，但必须有依据，避免凭印象直接选等级。

1. 任务影响：用户是否无法完成核心任务？是否只是体验变差，还是流程中断？
2. 影响范围：是单一账号、某类角色、某个租户，还是多个地区或全体用户？已知范围和潜在范围分别是多少？
3. 后果性质：是否涉及数据丢失、数据错误、隐私泄露、权限越界、资金损失、安全、合规或不可逆操作？
4. 缓解能力：有没有安全、可执行且用户能理解的绕行方案？数据能否恢复？恢复需要多长时间、由谁操作？

如果前三个问题有任意一项指向重大损失，应先按较高风险组织调查；如果用户仍能通过可靠替代方式完成任务，且没有数据、安全或合规风险，才考虑降级。判断过程中要把“已经确认”与“尚待验证”分开写。

2. 用影响与概率矩阵辅助，不让分数替代判断

团队人数较多、业务线较复杂时，可以增加风险矩阵。通常将“后果影响”与“发生可能性”分开评估，再通过矩阵得到建议等级。它的作用是让成员把依据摆出来，而不是制造一个看似精确的分数。

矩阵只是一种讨论工具。安全问题即使尚未确认发生概率，也不能简单用“可能性低”抵消严重后果；同样，发生概率高但影响极轻，也未必需要中断发布。团队应把法规、服务承诺和数据敏感度设为升级条件，而不是全部塞进乘法公式。

3. 判断绕行方案时，检查四个条件

“有绕行方案”经常被过度乐观地使用。能绕开不等于风险已解除。比如要求用户手动改数据库、重复提交订单，或联系管理员逐个处理，都可能引入新风险和高昂操作成本。

• 可用性：普通用户是否能在不依赖开发人员的情况下完成绕行？
• 安全性：绕行是否会扩大权限、暴露数据或增加误操作概率？
• 完整性：绕行后结果是否与正常流程一致，是否需要补数据或人工核验？
• 可持续性：方案能维持多久，处理量增加时是否仍可执行？

只有在安全、可理解、结果可靠且成本可接受时，绕行才足以支持等级判断。若绕行需要专业人员逐笔修正，即使技术上“能做”，也不应轻易当作用户无影响。

4. 用标准辅助安全问题，但不要把标准名词当成产品结论

对于漏洞类缺陷，可以参考 FIRST 发布的 CVSS 评分体系。CVSS 用一组攻击向量、攻击复杂度、所需权限、用户交互、影响范围及机密性、完整性、可用性等因素描述漏洞技术严重性。它有助于安全团队保持评估结构一致，但不直接等于产品团队的发布优先级。

同一个技术评分，在不同部署方式、用户暴露范围、数据敏感度和缓解条件下，实际业务风险可能不同。团队应同时记录评分版本、向量和上下文；若采用 CVSS 4.0，应明确标注版本，避免和旧版本分数混用。CVSS 是漏洞评估工具，不是所有功能缺陷的通用打分器。

五、案例与数据观察：把等级争论转成可验证的决策

1. 案例：订单重复提交，先判影响再决定止损

下面是用于说明判断方法的情景案例，不对应某个真实客户或真实产品。一名用户在网络延迟时连续点击提交，系统偶尔生成两笔订单。最初报告只有“按钮卡住，可能重复下单”，研发认为复现概率低，产品则担心客户投诉，双方对等级意见不同。

评审时，我会先把问题拆成四件事：重复订单的发生频率、是否产生重复扣款、用户能否自行取消、系统是否具备自动去重和审计记录。若只是后台生成重复草稿，且没有产生资金交易，影响与已经重复扣款的情况不同；若已扣款但能够自动退款，也仍需确认资金冻结时间、用户通知和对账影响。

团队可以先采取风险控制动作：临时增加重复请求拦截、监控短时间重复订单、限制高风险入口，随后根据日志回查受影响范围。等级是否致命取决于实际后果和服务边界，而不是“只复现过一次”或“修复只需一行代码”。

这个案例说明，等级结论应该随着证据更新。初期可以设为“高风险待确认”，但必须同步负责人、核查范围和复核时间；不能只留下一个等级，再等下一次例会讨论。

2. 案例：报表数值不一致，先追数据链路而非看页面范围

另一类常见分歧是报表金额不一致。界面上只有一个汇总数字偏差，看起来像局部显示问题；但如果该数字用于结算、预算审批或合规申报，它背后可能连接多个下游决策。判断时要确认偏差来源：展示格式、缓存延迟、计算逻辑，还是源数据已被错误写入。

若仅展示层四舍五入不一致、底层数据正确、用户不会据此执行关键操作，严重程度可能有限；若错误已经写入导出文件并被外部系统消费，就要追踪受影响时间段、用户、导出记录和下游任务。页面上“只差一个数字”，并不能证明风险也只在一个页面。

3. 用分层样本看团队的等级是否失真

不要只看高严重度缺陷数量。对过去一至两个版本的缺陷，可以抽样检查：高等级中有多少确实阻断关键流程；低等级中有多少后来升级；缺陷关闭后是否复发；是否存在“等级很高但长期无人处理”的积压。抽样能揭示团队口径，而不是只展示漂亮的总数。

例如，若“高”级缺陷大多是视觉或文案问题，说明团队可能把客户催促直接映射成严重程度；若低等级中频繁出现数据回滚和权限问题，说明当前判定漏掉了低频高损失场景。观察重点应是分类是否准确、是否能预测处置需求，而不是追求某个固定的严重缺陷占比。

下图为情景模拟数据，只用来演示如何检查分类质量。团队应使用自己的历史缺陷、复核记录和事故复盘替换示例数值，不应把模拟比例写成行业基准。

4. 对 100 人以上组织，重点从“会不会填”转向“跨团队能否一致”

当团队规模扩大、多个产品线共用缺陷流程时，单个测试小组形成的口径很容易分化：某业务线把所有客户问题标高，另一条线则倾向压低等级。此时，问题不是成员是否学会填表，而是不同业务的核心流程、风险容忍度和升级机制有没有被明确表达。

以 PingCode 为例，100 人以上的组织可以把缺陷字段、工作流和复核规则放进统一的项目管理平台中：例如为严重程度提供统一定义，为安全与数据问题设置专项字段，为等级变更保留记录，并用仪表盘观察跨项目的复核情况。工具可以帮助统一记录和追踪，但不会自动替团队决定什么是“严重”；业务负责人仍需定义关键流程和风险边界。

实际配置时，不建议一开始就做复杂的自动打分。先统一字段定义和必填证据，再观察一个迭代周期的争议点，最后把重复出现的判断规则固化到流程中。否则，系统只是把不一致的标准自动化，表面上数据整齐，实际决策仍然混乱。

六、项目成员最佳实践：从报告到定级的可执行步骤

1. 测试人员：报告事实，不替整个团队猜后果

测试人员的价值不是把每个问题都打成高等级，而是让团队能够复现、理解并评估问题。缺陷描述要包含明确的环境和操作步骤，记录实际结果与预期结果，并尽可能说明受影响的账号、数据和版本。

1. 记录产品版本、环境、设备或浏览器、账号角色和必要配置。
2. 用最短步骤描述复现过程，注明发生次数与总尝试次数；无法稳定复现时保留时间点和日志线索。
3. 记录实际结果、预期结果，以及是否造成数据变化、任务中断或重复操作。
4. 区分已确认的影响与推测内容，例如“确认一个账号失败，其他账号待验证”。
5. 根据团队定义提出初始等级，同时注明支持该判断的证据。

报告不要写“严重影响客户”“肯定会丢数据”却没有依据。可以写“保存后页面返回失败；刷新后记录消失，后台日志显示请求超时；数据是否写入待开发核查”。这样的描述既不弱化风险，也不把推测冒充事实。

2. 开发人员：补充技术风险，不要把根因不明当成降级理由

开发人员通常最了解问题发生在前端、服务端、数据库还是依赖服务，也能判断是否存在回滚和修复风险。需要补充的是技术事实，而不是用代码复杂度替代业务影响。

• 说明已确认的故障边界：哪些接口、模块、版本或数据路径受影响。
• 确认是否存在数据写入、部分成功、重试重复执行或历史数据污染。
• 提供临时控制方案及风险，例如关闭开关、回滚、限流或执行数据修复。
• 评估修复变更的回归范围，并把变更风险与缺陷严重程度分开记录。
• 如果根因未明，说明接下来要验证的假设与预计更新时间。

当开发人员说“难复现”时，下一步不应是结束讨论，而是明确需要哪类证据：请求链路、日志采样、用户操作时间、数据差异，还是版本差异。把不确定性拆成可执行调查任务，才能避免问题在待办列表里长期失焦。

3. 产品与业务负责人：提供用户任务和损失背景

产品和业务负责人应解释用户为何使用该功能，以及失败会影响什么决策、交易或工作流程。不要只说“客户很重要”或“这个功能很核心”，还要说明用户是否有替代路径、替代路径的成本，以及影响是否受到合同或监管要求约束。

可用的信息包括：功能在用户旅程中的位置、受影响的角色、业务窗口、可接受中断时间、人工处理成本、客户沟通义务和相关服务承诺。并非所有背景都能精确量化，但明确陈述假设，通常比给出伪精确分数更可靠。

4. 缺陷负责人：确保每个等级都能推动一个动作

定级的目的不是填完字段，而是触发合适的处理方式。负责人需要确认等级、优先级、责任人、下一次更新时间、受影响范围核查和关闭条件。高等级问题如果没有明确负责人和时间点，等级再准确也不会减少用户损失。

建议使用下面的处理步骤，适用于从缺陷提交到关闭的常规流程。严重事件可以并行启动应急响应，而不是按顺序等待所有字段全部补齐。

1. 接收：确认报告可定位，标记环境、版本和提交人；信息不足时退回补充具体字段，而不是简单写“描述不清”。
2. 初筛：识别数据、安全、资金、核心服务等升级条件，必要时先采取临时控制措施。
3. 评估：依次讨论任务影响、受影响范围、后果性质、发生条件和绕行能力。
4. 分开定字段：分别填写严重程度、优先级、处理计划和目标时间，说明各自依据。
5. 指定核查：对未知的影响范围、数据状态或复现条件指定责任人与完成时间。
6. 跟踪调整：有新证据时更新等级，并保留调整原因；高风险缺陷同步通知相关角色。
7. 验证关闭：确认修复已覆盖触发条件、历史数据已处理或确认无需修复，并完成回归验证。
8. 复盘规则：对误判、复发和影响扩大的问题，记录口径改进，不只复盘个人操作。

5. 给缺陷单设计一组真正有用的字段

字段不宜越多越好。每个字段都应该对应一个决策或后续动作。对于多数团队，下面的字段足以支撑初判与复核；安全、合规或数据密集型产品再增加专项字段。

如果系统支持自定义工作流，可以在“致命”或涉及数据、安全的缺陷上要求补充影响范围和止损动作；不必让所有低风险缺陷填写同一套长表单。表单长度应与风险匹配，否则成员会为了快速提交而填写模板化空话。

七、不同情况下怎么行动：把等级映射到响应，不只映射到标签

1. 核心服务不可用或存在重大数据风险

如果用户无法使用核心服务，或出现疑似数据丢失、越权访问、资金损失等情况，先控制风险，再完善根因。必要时暂停相关入口、回滚版本、禁用功能或限制操作范围。不要为了追求“信息完全”而延迟止损，但要记录采取措施的时间、影响和责任人。

此时的重点不是立即争论四级还是五级，而是确认应急负责人、受影响范围、用户沟通责任、恢复条件和下一次状态更新时间。等级可以暂定为致命或高，待更多证据出现后复核；但“暂定”必须附带行动，不能变成无人认领的标签。

2. 关键功能受阻，但有安全的临时绕行

若主要流程被阻断，但用户可以通过已验证的替代路径完成任务，可以按高或中处理，具体取决于绕行成本、用户范围和业务时间窗口。绕行方案应明确适用对象、操作步骤、风险限制和失效条件，不能只在内部聊天里口头通知。

如果绕行依赖运营或技术人员手工处理，应统计预计处理量和耗时。手工方案在 5 个用户时可行，不代表在 500 个用户时仍安全；规模扩大后，临时方案可能从“缓解措施”变成新的故障源。

3. 局部功能异常，任务仍可完成

这类问题通常进入常规修复计划，但不代表可以无限期搁置。要看它是否持续增加人工操作、造成重复工单、让用户绕行出错，或与即将发布的功能发生依赖。若问题累积成明显的客服成本或数据不一致，应重新评估影响。

适合合并处理的情况包括：多个相似显示缺陷集中在同一模块、修复需要同一组件改造、单独修复会重复做回归。合并处理要保留每条缺陷的影响记录，避免把不同风险简单打包成一个“大杂烩”。

4. 偶发问题、影响范围未知或缺少稳定复现

对偶发问题，可建立短期调查窗口：收集日志、请求标识、发生时间、账号类型、版本和上下游依赖；同时观察是否有重复模式。若怀疑存在高后果风险，在未查清之前采用保守控制，而不是因为“概率不高”直接压低等级。

如果经过约定时间仍无法复现，负责人应决定下一步是增加观测、保持待查、用监控替代复现，还是在明确风险接受后关闭。关闭理由需说明当前证据和残余风险，避免“无法复现”被误读为“问题不存在”。

5. 体验问题或低影响问题持续积压

低等级问题也要管理。可以按用户触达频率、修复是否与其他改动共享、可访问性影响和累计人工成本安排批量处理。对同类问题做聚类，往往比逐条争论严重程度更有效，因为它可能暴露设计规范、组件缺陷或内容流程问题。

如果积压低等级缺陷数量很大，团队不必通过把它们改成高等级来争取资源。更健康的做法是单独设定体验质量容量、明确每个版本可处理的改进比例，并公开积压年龄和复发情况。

八、不同情况下的取舍：没有一套等级能消除所有争议

1. 统一标准与业务差异之间的取舍

标准完全统一，跨团队统计更容易，但如果不区分支付、内容编辑、内部运营等业务，具体判断可能失真；完全由业务线自行定义，又会让“高”和“致命”在不同团队间不可比较。我的建议是“统一原则、局部补充”：全公司共享等级定义，同时允许业务线列出核心流程、合规条件和特殊升级规则。

补充规则不能重新发明一套等级。它应解释本业务如何识别“核心流程”“重大损失”或“可接受绕行”，并说明与全局标准冲突时谁有最终复核权。这样既保留横向可比性，也允许业务场景有边界。

2. 快速响应与充分证据之间的取舍

紧急事件不可能等到所有事实都查清才响应；但过早下结论也会造成误报、停服和资源错配。处理方式不是二选一，而是将“先控制风险”和“后确认定级”拆开。可以先采取可逆、低副作用的措施，再随着证据增加决定是否扩大处置。

例如，短时关闭一个高风险入口可能比全站回滚损失更小；先限流并监控，也可能为确认影响范围争取时间。所有临时措施都应设定复核点，避免临时状态因无人负责而长期存在。

3. 低误报与低漏报之间的取舍

高风险缺陷被误判为致命，会消耗值班和发布资源；真正的高风险问题被判为低，又可能造成更严重后果。两种错误成本并不总是相等。对于数据、安全、资金和合规问题，团队通常应更关注漏报成本，必要时采用“先升级评估、后降级”的方式。

对于展示问题和轻微体验问题，则可通过样本复核控制过度升级。重点不是要求所有缺陷都从严，而是明确不同问题类型的风险容忍度，并通过复盘观察实际误判代价。

4. 数字评分与专业判断之间的取舍

打分表能降低新人上手难度，也便于规模化记录；但把“影响范围 3 分、概率 2 分、绕行 1 分”相加后自动得到等级，容易营造精确错觉。评分依据如果没有场景定义，不同人仍会对“3 分”理解不同。

较稳妥的方式是先用判断问题得出建议等级，再把评分作为解释材料。对于触发重大风险的条件设置覆盖规则，例如确认敏感数据泄露时，不允许通过其他低分把结果平均到低等级。自动化适合提醒和路由，不宜代替最终风险判断。

5. 追求零缺陷与控制发布风险之间的取舍

并非所有缺陷都必须在发布前修完。关键是团队是否知道剩余风险，是否有监控、回滚和用户沟通准备，以及接受风险的人是否具备决策权限。以低风险问题阻断全部交付，可能造成不必要延迟；带着未解释的数据风险上线，则可能付出更高代价。

发布评审应写清未修复缺陷、受影响对象、暂缓修复原因、缓解措施、风险接受人和复核时间。风险接受不是把责任推给用户，而是组织在已知条件下作出的可追溯决策。

九、团队如何持续校准：用复核质量而非等级数量衡量流程

1. 每个迭代抽样复核，不必全量开会

团队可以每个迭代抽取少量致命、高、低等级缺陷，加上所有等级被调整过的缺陷，检查原始证据和最终判断是否一致。若问题集中在某一档，就修订该档的示例、必填信息或升级条件，不必把全流程推倒重来。

复核时应关注等级调整原因。如果调整来自新证据，说明流程有效地吸收了信息；如果调整只是因为不同负责人偏好不同，说明口径还需要统一。复核的目标是发现系统性偏差，而不是给提交者打分。

2. 观察能反映流程健康度的指标

指标要能引出行动。单纯统计高等级缺陷数，无法判断高风险是否变多；统计缺陷关闭速度，也可能诱导团队快速关闭但不验证。可以组合观察以下数据，并按产品线、版本和问题类型切片。

• 等级调整率：判断初始分类是否稳定；进一步区分因新证据调整和因口径争议调整。
• 高等级响应时间：从确认高风险到有人接手、采取控制措施分别用了多久。
• 影响范围确认耗时：从发现到查清受影响用户、数据或版本的时间。
• 复发率：已关闭问题是否因同一根因再次出现，反映修复与验证质量。
• 低等级升级比例：识别重大后果是否在早期被漏判。
• 积压年龄：观察不同严重程度问题等待处理的时间，识别低等级问题长期堆积。

指标必须附上定义和统计口径。例如“响应时间”从报告提交、首次确认还是等级确认开始计时，会得到不同结果。没有统一口径的仪表盘只会制造新的争论。

3. 用复盘更新定义，而不是不断增加等级

当团队发现某种缺陷总被争论，不要立刻增加“中高”“高减”等新等级。先检查它是否缺少关键维度，例如数据可恢复性、租户影响范围、用户角色权重或绕行成本。补充定义和典型例子，通常比增加等级更能解决问题。

更新规则后，应选用旧案例进行回放：把之前容易争议的缺陷交给不同角色重新判定，看看新定义是否减少分歧。如果仍然出现大量不同答案，说明字段定义还不够具体，或业务风险边界尚未由适当负责人决定。

十、下一步怎么做：用一个迭代建立可复用的缺陷分级机制

1. 第一周：统一词义和升级条件

召集测试、开发、产品、运维或安全代表，先确定严重程度与优先级的区别，再为致命、高、中、低分别选取真实历史案例。每一级写出典型情况、排除情况和必须复核的触发条件，不要先花时间设计复杂评分公式。

2. 第二周：修改缺陷模板和评审动作

将影响范围、业务后果、绕行方案、证据与不确定性加入缺陷模板。对高风险缺陷设置负责人和更新时间，对低风险问题保持轻量填写。明确等级由谁初判、谁复核、谁能接受残余风险，避免所有人都能改级但无人承担判断责任。

3. 一个迭代后：抽样检查并调整

统计等级调整原因、高等级响应时间、低等级升级案例和未确认影响范围的缺陷。挑出争议最大的几条，确认是缺少证据、定义不清，还是业务优先级与严重程度混淆。调整后让团队用历史案例再次演练，避免规则只停留在文档中。

如果团队使用 PingCode 等项目管理平台，可以用字段、流程节点、权限、通知和报表承载这套机制：例如在提交时要求填写影响证据，在高风险状态变更时通知责任人，在关闭前要求关联验证结果。工具的作用是让判断可追踪、动作不遗漏；等级定义、风险接受和业务取舍仍应由团队共同负责。

4. 最后记住一个判断原则

缺陷严重程度不是给问题“贴标签”，而是把用户后果翻译成组织能够执行的响应。真正有效的分级，既不会因为客户催得急就把一切都标成致命，也不会因为问题偶发、难复现或修复昂贵就低估风险。

下一步可以先从最近一个版本的 20 条缺陷开始：抽取高等级和低等级样本，检查每条是否有影响范围、业务后果、绕行能力和复核依据；再把争议集中在等级定义还是信息缺失上。用真实案例校准一轮，往往比继续讨论抽象的“严重程度应该怎么定义”更快建立共识。