一个代码审查流水线有 5 个类别：bug（92%）、安全（90%）、性能（85%）、风格（70%）、注释准确性（40%）。开发者在忽略所有发现——包括准确率 92% 的 bug 检测。40% 准确率的类别制造了太多噪音，开发者已经放弃阅读整个审查输出。
用户评判一个系统，看的是最差的可见输出，不是数学平均值。
信任污染的数据
一条运行了 6 个月的流水线新增了文档质量检查，误报率 55%。加入前，开发者处理了 80% 的发现。加入后：25%——所有类别都是，包括准确率 95% 的 bug 和 93% 的安全。
校准差的类别不只伤害自己的采纳率，它摧毁了对所有其他类别的信任。一个系统的可信度由最不可靠的可见组件决定。
早期侵蚀是可以检测的。 添加一个 55% 驳回率的 API 规范检查后，bug 发现的驳回率从 5% 爬到了 8%，安全从 8% 到 12%。这是先行指标——等开发者直接静音整个 bot 的时候，损害已经造成了。
ROI 算账
一个 6 类别系统，各类别准确率在 45%-94% 之间，价值从 $100 到 $15,000/月不等。准确率最低的两个类别每月只贡献 $300 的价值。但它们的误报导致整体处理率从 75% 掉到 40%，每月损失约 $6,650 的高价值发现。
禁用每月 $300 的不可靠类别来保住每月 $6,650 的可靠类别，这不是取舍，是算术。
正确做法：隔离、修复、重新上线
第一步：立即禁用问题类别。 从可见输出中移除。这能恢复对其余准确类别的信任。不要因为”有些发现是对的”就留着——2:1 的噪信比摧毁信任的速度，比完全没有发现还快。
第二步：隔离修复。 用具体标准改进 prompt（参见 K4.1.1），添加示例，在标注数据集上测试。一个 60% 误报率的类别通过更好的 prompt 工程提升到了 88% 准确率。
第三步：逐步重新引入。 不要一下切回 100%——内部测试 88% 在真实数据上未必能保持。
- 先用影子模式——生成发现但不显示。和人工审查对比。
- 在 10-20% 的 PR 上启用。测量真实准确率。
- 确认指标稳定后扩展到 50%，再到 100%。
- 把前后对比数据告知开发者，重建信心。
新类别用影子模式
新类别绝不应该直接上线到生产环境。质量门控框架：
- 新类别以影子模式启动——生成发现但不展示
- 两周测量期，以人工审查为基线对比
- 准确率必须超过 80% 才能提升为可见
- 持续监控，低于 75% 自动降级
- 追踪开发者驳回率，作为信任侵蚀的先行指标
这能防止一个真实准确率未经验证的新类别损害已建立系统的可信度。
这些方法修不了信任污染
加置信度分数。 LLM 自报的置信度校准很差——模型会给误报打高置信度。把过滤负担推给开发者（“忽略 0.7 以下的发现”）解决不了信任问题。开发者不应该为了让审查工具能用而手动配阈值。
汇总准确率报告。 “总体准确率 97%“掩盖了两个字段只有 55% 的事实。用户体验的是单条发现，不是平均值。一个开发者连续看到三条错误发现，不会去算系统的总体准确率——他会直接不看了。
“保守一点”的 prompt。 这条模糊指令可能减少所有发现——包括真阳性——而不是针对特定高误报类别。这是把 K4.1.1 的反模式用在了 K4.1.2 的问题上。
“实验性”标签或免责声明。 建一个双层系统，某些发现标为”实验性”，开发者照样看到误报。他们可能驳回整个标记类别，更糟的是养成略读所有发现的习惯。
限制每个 PR 的发现数量。 每次审查上限 3 条不会提高准确率。三条误报还是三条误报。
开发者投票决定类别。 慢、主观，而且在投票期间挡不住损害。等积累到足够票数来禁用一个类别时，信任早就没了。
按团队路径划定范围
在一个有 5 个团队使用不同命名规范的 monorepo 中，通用的命名检查对大多数团队来说必然产生误报。解决办法：路径特定的规则，只在每个团队的目录下激活命名检查，规范校准到每个团队的实际标准。
这是与 K3.3.1 的跨域关联——路径范围的规则通过为正确的代码加载正确的标准来防止误报。
一句话总结： 一个低准确率类别会毒化所有类别的信任——立即禁用，在影子模式下修复，然后用实测准确率逐步重新引入，因为用户只看最差的那条输出。