不是所有Bug都一样重要。测试你有效分诊、与利益方沟通和对质量做务实决策的能力。
区分严重度（技术影响）和优先级（业务紧急度）。
描述你的分诊框架或矩阵。
解释如何让利益方参与优先级排序。
分享一个困难的优先级决策例子。
我使用严重度-优先级矩阵。严重度衡量技术影响：S1数据丢失或安全漏洞，S2主要功能损坏，S3次要功能问题，S4外观问题。优先级衡量业务紧急度：影响用户数、收入影响、变通方案可用性。高严重低优先可能是罕用功能的崩溃；低严重高优先可能是定价页的错别字。我与产品经理每日分诊，共享看板。在上一个岗位，实施此框架后平均解决时间缩短40%，因为工程师聚焦在真正重要的事上。
展示你考虑业务影响，而非只看技术严重度。
提到利益方协作——分诊不是独立活动。
展示务实：不是每个Bug都需要立即修复。
严重度是技术影响级别，优先级是业务紧急度。未使用功能的关键崩溃是高严重低优先。结账页的小UI问题是低严重高优先。
理想情况下QA、产品和工程协作。QA评估严重度，产品评估业务影响，共同设定优先级。
维护"不修复"或"接受风险"分类。定期审查。如果低优先Bug被用户反复报告，应重新评估其优先级。