怎么量化每条自动化用例的「抓缺陷价值」，让删冗余用例有据可依

背景

我是测试开发，维护一套 B 端 SaaS 接口自动化（Python 3.11 + pytest 7.4 + httpx，约 1800 条用例，跑在 4 人共享的 staging + MySQL 8 + Redis 7）。套件从 700 条涨到 1800 条用了 14 个月，我越来越怀疑里面混了不少"跑着绿、但其实抓不住任何 bug"的用例——它们像体检报告里正常的指标，看着安心，实则没在干活。

现象

• 每次回归失败，真正命中线上/准线上缺陷的比例肉眼可见地在下降，我的粗估从一年前的约 1/4 降到现在的约 1/10；
• 想给用例做"价值分层"（高价值/中/低），目前能拿到的信号只有：断言数量、执行耗时、所属模块、最近 N 次失败记录；
• 缺一个能把"这条用例历史上到底拦下过几个真实缺陷"算出来的指标。

已尝试的排查

1. 想直接看"用例失败 → 是否被开发确认为真 bug"的转化，但失败记录里没和缺陷单（Jira）做关联，历史数据对不上；
2. 考虑过变异测试（mutmut）给每条用例算变异得分，但 1800 条用例 × 全量变异，本地跑一轮要 6+ 小时，且我们是接口级测试，变异对象是后端 Java 代码，工具链不太搭；
3. 想过给断言加"强弱标记"（强断言=状态码+核心字段，弱断言=只断 200），但存量 1800 条要逐条人工标注，成本太高，且标准没人拍板过。

期望得到的答案形态

希望有类似经验的同学能分享：

1. 你们团队怎么定义"用例价值"的指标？是缺陷拦截数、变异得分、断言强度，还是别的？
2. 这个指标怎么采集——是在失败记录里挂缺陷单 ID，还是用变异测试，还是别的机制？数据落在哪（CI 日志/DB/看板）？
3. 有没有最小可落地的起步方案——比如先只标"过去 6 个月命中过真实缺陷"的用例做白名单，其余进观察池，定期复审？
4. 踩过的坑：比如"价值指标"被滥用成 KPI 之后，团队开始只写容易红的用例、不敢写边界用例，这种副作用你们怎么防的？

有具体数字、具体做法的分享最欢迎，纯观点也行，我先谢过各位。