阈值从基线来
指标阈值应当从自身现状推导，而不是照搬外部推荐值。做法是先花两到四周采集现状数据，看分布而不是平均值——常用五十分位与九十分位作为参考，再设定一个略严于现状、能够达成的初始目标，并在后续周期重新校准。拍脑袋定下的阈值通常走向两个极端：要么轻松达标失去引导作用，要么长期红灯最后被整体忽略。
设置步骤
| 一 | 采集两到四周现状数据，覆盖不同模块类型 |
|---|---|
| 二 | 看分布：关注中位数与高分位，而不是平均值 |
| 三 | 设定略严于现状的初始阈值，说明依据 |
| 四 | 每季度评估达标率与修复成本，重新校准 |
典型使用场景
- 新代码覆盖率门禁：先记录现有新代码的覆盖分布，再定起点阈值
- 构建时长约束：按当前中位与高分位设置上限，避免门槛完全不可达
- 重复率治理：按模块类型分别设阈值，基础库与业务模块要求不同
- 告警阈值校准：按历史触发频率与行动转化率调整
- 季度目标设定：在上一季度达标率基础上小幅提升，保持可达性
校准示例
校准示例
# 现状采集（近 4 周，新代码覆盖率）
P50 = 62% P90 = 88%
# 初始门禁：>= 60%（先稳住，避免一上线就大面积报红）
# 季度目标：65% → 70%，每次小步提升
# 校准依据：每季度评估达标率与修复成本，达标率过低则暂停加严阈值设置对照
| 做法 | 结果 | 修正方式 |
|---|---|---|
| 直接采用行业推荐值 | 与自身现状脱节，红灯不断 | 先采集现状再定初始值 |
| 按平均值设定 | 被长尾拉偏，多数模块实际不达标 | 改用中位数与高分位参考 |
| 一次加严到位 | 团队短期无法达成，门禁被绕过 | 改为分季度小步提升 |
| 从不重新校准 | 能力提升后门槛失去引导作用 | 设定季度复核机制 |
| 所有模块同一阈值 | 基础库与业务模块互相不适用 | 按模块类型分档设置 |
基线采集期要覆盖足够多的样本与场景：只取一两周的数据容易受偶发发布节奏影响，得出的分布不能代表常态。
阈值上调要与修复成本一起评估：达标率长期偏高说明可以收紧，但如果每次收紧都伴随大量豁免申请，则说明设定脱离实际，需要重新校准而不是继续加压。
落地检查清单
- 阈值有采集数据与分布依据
- 不同模块类型采用分档阈值
- 有季度复核与校准机制
- 达标率与豁免数量作为调参输入