错误黑名单单调进化模式（Error Blacklist Monotonic Evolution Pattern）

错误黑名单单调进化模式（Error Blacklist Monotonic Evolution Pattern）#

模式概述#

将每个被人工Review拒绝的错误Case持久化为回归测试用例（"错误黑名单"），设置百分之百回归门槛，确保"犯过的错误绝对不能再犯"。核心洞察是"下界持续抬升比上界突破更能保证可靠性"——即使上界（能处理的最复杂场景）提升缓慢，下界（已验证不会犯的错误）的持续抬升仍能保证系统进化是单调向上的。错误从"消耗型"（出错就修，修完可能再错）转变为"投资型"（每个错误被沉淀为系统能力的永久增量）。

触发场景#

满足以下条件时考虑使用此模式：

✅ 系统输出可被明确判定对错，且错误案例可被持久化
✅ 系统需要持续提升可靠性，且"重犯已知错误"是主要故障来源
✅ 追求"单调向上"的进化保证（即使上界提升缓慢，下界持续抬升）
✅ 高风险场景中"重犯已知错误"的代价远大于"遇到未知场景"
✅ 错误案例可被程序化验证（非主观判断）

不适用场景：

❌ 无法对错误进行持久化标注的场景（如实时流式处理无回溯能力）
❌ 错误案例无法程序化验证的场景（主观判断无法回归测试）
❌ 系统只需一次性使用无需持续优化（黑名单建设成本无法摊薄）

核心做法（5步标准化流程）#

步骤1：建立错误持久化机制#

每个被人工Review拒绝的Case，进入"重要Case评测集"（错误黑名单）
黑名单Case永久保存，包含完整上下文（输入、输出、预期结果、错误原因）
确保黑名单Case可被程序化执行（非人工判断）

步骤2：设置百分之百回归门槛#

未来每次评测回溯时，黑名单中的Case必须百分之百通过
"犯过的错误绝对不能再犯"——这是系统进化单调向上的核心保障
任何黑名单Case失败即视为回归不通过，禁止上线

步骤3：区分上界与下界指标#

上界指标（能处理的最复杂场景）：衡量能力扩展，是"锦上添花"
下界指标（已验证不会犯的错误数量）：衡量可靠性保证，是"雪中送炭"
两者并列评估，不可偏废，但在高风险场景中下界优先

步骤4：优先保证下界抬升#

在资源有限时，优先保证下界持续抬升（已犯错误不再犯）
而非追求上界突破（处理更复杂场景）
高风险场景中故障的根源是"重犯已知错误"而非"遇到未知场景"
下界抬升的工程价值远大于上界突破

步骤5：定期清理过时Case#

避免黑名单过度膨胀导致过度拟合历史
定期评估Case的时效性：业务场景变化后部分Case可能不再适用
清理标准：Case对应的场景已不存在，或系统架构变化使Case不再相关
注意：清理需谨慎，确认Case确实过时而非"看起来过时"

反模式（不要这么做）#

❌ 错误不持久化：每次优化后无法回溯历史Case，同类错误可能反复出现，系统进化非单调向上
❌ 黑名单只增不减：过度拟合历史错误，对新场景泛化能力下降，黑名单膨胀增加评测成本
❌ 回归门槛非百分之百：允许部分黑名单Case不通过，进化非单调向上，"犯过的错误不再犯"成空话
❌ 仅关注上界突破忽视下界抬升：能处理更复杂场景但重犯已知错误，可靠性反而下降

检验标准#

错误黑名单Case数量持续增长（系统持续吸收错误教训）
黑名单Case百分之百通过回归（进化单调向上）
下界指标（已验证不会犯的错误数量）持续提升
系统准确率维持高位并持续逼近100%（靠下界抬升而非上界突破）
错误转化率高（错误被沉淀为评测Case的比例高）

迁移验证#

目标场景	错误持久化方式	回归门槛	下界指标	可行性
CI/CD流水线	失败Case入库为回归测试	100%通过	已验证通过的测试数量	✅
风控规则引擎	误报漏报Case入库	100%通过	已验证不误报漏报的规则数量	✅
搜索质量系统	Bad Case入库为回归用例	100%通过	已验证相关的Query数量	✅
自动驾驶系统	事故场景入库为仿真用例	100%通过	已验证安全通过的场景数量	✅

实践案例#

快手开关治理评测体系（2026年）：人工Review拒绝的Case进入"重要Case评测集"，未来评测回溯时必须百分之百通过——"犯过的错误绝对不能再犯"。这一机制让系统进化是单调向上的：每犯一个错并被标注，系统能力下界就提升一格。98%准确率的维持靠的是下界持续抬升而非模型能力上界突破。

来源：闫文亮《让开关自我消亡：AI赋能的Feature Flag全生命周期治理》(QCon 2026北京站)

关联模式#

评测驱动的自进化闭环模式：本模式是自进化闭环中"错误黑名单"机制的深化模式
不确定性探索+确定性校验双引擎架构模式：双引擎分歧Case沉淀为黑名单的来源