flaky 用例该不该隔离，靠什么客观数据判据，而不是凭感觉拉黑

【背景】我负责一条支付清算链路的接口自动化（Python 3.11 + pytest 7.4 + httpx，约 1800 条用例，跑在 3 人共享的 staging 上，MySQL 8 同库 + Redis 7）。近 3 个月套件里有 40 多条用例「时红时绿」，每次 CI 红了都要人工翻日志判断「这条到底是真 bug 还是 flaky」，非常耗人，团队对 CI 的信任度也在掉。

【现象】同一条用例，今天绿明天红；红的里面偶尔混着真 bug，一旦误判成 flaky 就漏放。现状是我们用「连续 3 次绿就暂时放行 + 加 TODO」的土办法，但没人说得清「到底失败多少次、在多大样本里，才该判定它是 flaky 而不是回归」。

【已尝试】1）给每条用例加 2 次自动重试——结果是把真 bug 也重试掩盖了；2）拉一张飞书表人工记失败次数——记不全、也没人看。都治标不治本。

【期望答案形态】想要一个可落地的客观判据，最好包含：(1) 用滑动窗口统计失败率时，窗口取多大、置信度/样本量怎么设，才能和「真回归」区分开；(2) 判定为 flaky 后，自动隔离（quarantine）+ 打标签 + 建修复工单的具体做法；(3) 有没有现成工具/插件（pytest 生态或 CI 侧）能直接算这个指标，而不是自己写脚本。请尽量给公式、参数和命令级细节。