发布门禁设计：为什么必须Fail-Closed？

发布门禁最昂贵的结局：假绿

任何发布门禁（release gate）都有四种可能结局，但其中只有三种是诚实的：正确的红（真的回退了）、正确的绿（真的没问题）、错误的红（误报，耽误时间但会有人去查）。而第四种——错误的绿——是唯一无人监控、却代价最高的一种。

错误的红只浪费一次调查；错误的绿则摧毁门禁存在的全部前提。一旦发生，你无法知道有多少个版本是在“绿灯毫无意义”的情况下发布的。问题不再是“为什么回退了”，而是“有多少次发布是在假绿灯下溜走的”。在CAFA-IVR框架的v1.0中，这种结局是可达的：当汇总CSV出现缺失、非数值或非有限指标时（比如上游重命名列、导出文件损坏、除零产生nan），门禁无法评估指标，却让流水线继续前进。

v1.1.0的更新日志直言不讳：“基线/候选比较现在对缺失、非数值、非有限或空的启用指标执行fail-closed。以前会放行畸形输入的流水线现在以状态码2退出。”——这句话本身就值得反复读两遍，它承认了缺陷，也正是本文存在的原因。

Fail-closed的具体含义

在v1.1.0的实现中，每个启用的检查项都要求基线（baseline）和候选（candidate）两份汇总中都存在一个存在、可解析为数字、有限的指标。_metric_value的检查是机械的：

• 指标缺失或为空 → 失败
• 指标无法解析为数字 → 失败
• 指标解析为无穷大或NaN → 失败
• 汇总文件不可读或为空 → 失败

以上任何情况都会打印CAFA-IVR release gate: FAIL，指明具体的违规输入，并以状态码2退出——刻意区别于状态码1，让CI系统和包装脚本能区分“门禁拒绝了此次版本”和“测试工具本身坏了”。一个含糊失败的门禁，迟早会被人们学会忽略；退出码本身就是设计的一部分。

尤其值得玩味的是：该框架自带的试点数据集竟然无法通过自己的CEER门禁。360次试验的复现数据没有关键实体标注，汇总中如实报告ceer: null。直接运行比较：

cafa-ivr compare \
  --baseline empirical/cafa_reproduced_summary_360.csv \
  --candidate empirical/cafa_reproduced_summary_360.csv

输出：

CAFA-IVR release gate: FAIL
 - invalid summary input: empirical/cafa_reproduced_summary_360.csv: required metric 'ceer' is missing

退出码2。门禁看着项目自己的参考数据，拒绝放行。这不是bug，这正是要点所在——一个会放行自身无法评估输入的门禁，同样会放行你的。

Fail-closed 与 fail-open 是可靠性工程中的一对基础设计模式。fail-closed（失效即关闭）指系统在遇到无法处理的异常输入、缺失依赖或内部错误时，默认进入“拒绝/阻断”状态；fail-open（失效即放行）则相反，默认进入“允许/继续”状态。安全领域的典型类比是门锁：断电时电磁锁自动锁死属于 fail-closed，自动解锁则属于 fail-open。发布门禁天然应当 fail-closed，因为它的职责是阻断有风险的版本，而不是在无法判断时替人做“没问题”的假设。与之配套的概念是退出码语义：Unix/CI 约定中 0 表示成功、非零表示失败，但不同非零值可以承载不同含义，例如 1 表示“检查未通过”，2 表示“检查无法执行/配置错误”。把二者区分开，能让 CI 系统和包装脚本自动判断应当重跑、修复配置还是通知负责人，避免把工具故障误读为业务回退。

显式退出优于静默跳过

面对指标缺失，另一种选择是“没有实体标注，那就跳过CEER检查”。这就是fail-open设计，诱人之处在于它从不冒犯任何人。但它正是“假绿”大规模发生的根源：六个月后，有人为了省时间删掉了标注步骤，门禁悄悄停止检查实体，此后每个版本都在一个已经不存在的检查上亮绿灯。无人察觉，因为门禁从未抱怨。

因此v1.1.0要求退出必须是显式的：

cafa-ivr compare \
  --baseline baseline/summary.csv \
  --candidate candidate/summary.csv \
  --no-ceer-gate

--no-ceer-gate在流水线定义中、所有人可见的地方声明：此数据集没有实体标注，我们接受实体检查不运行。 被跳过的检查和被显式退出的检查，区别就在于配置文件中的一行——这恰恰是“我们决定”和“它发生了”的区别。决定是可审计的，发生不是。

这条设计原则可以推广：质量门禁中任何静默跳过，都应要求一个显式、可见、受版本控制的退出选项。 如果跳过是合理的，写下来不花成本；如果跳过是在掩盖流程自身的回退，写下来的动作本身就会抓住它——通常是在代码评审时，有人问“为什么这个流水线禁用了实体门禁？”

显式退出（explicit opt-out） 是配置管理中的一条通用原则：允许关闭某项检查，但关闭动作必须写进受版本控制的配置、出现在代码评审中，并留下可追溯的记录。它与“静默跳过”的区别不在结果，而在可审计性。在 CI/CD 流水线中，配置通常以 YAML 或命令行参数形式随代码一起提交，因此任何 --no-xxx-gate 之类的开关都会进入 diff、被评审者看到、被 blame 追溯到具体提交和作者。相反，fail-open 的跳过发生在运行时，日志里可能只有一行容易被忽略的 warning，久而久之无人知道某项检查已经形同虚设。软件工程中把这类长期未被执行、却仍显示为“通过”的测试或检查称为僵尸检查（zombie check），它们是假绿最常见的载体。

默认关闭的WER门禁

还有一个实现细节把整个系列串了起来。compare命令接受--max-wer-delta——WER回退门禁确实存在，但默认值是None，即禁用。这个框架在第一篇文章中论证WER是错误的度量单位，于是它默认不用WER来门禁发布。实际门禁的量是ASR-IFR和CEER的增量——语音路径是否破坏了更多测试、实体损坏是否增加——WER只作为可选的诊断项，供需要的团队开启。

这不是疏忽，而是把论点编译进了默认值。默认值是工具能做出的最强声明——大多数用户从不修改它们——所以它们应该编码作者的真正信念。作者相信WER是诊断性的，不是决定性的。默认值说明了这一点。

WER（Word Error Rate，词错误率） 是语音识别最常用的评估指标，计算识别文本与参考文本之间的替换、删除、插入错误数占总词数的比例。它直观、易比较，但作为发布门禁存在两个结构性缺陷：其一，WER 对语义不敏感，把“转账”识别成“转帐”与识别成“查询”计入同样的错误；其二，WER 是全局平均量，无法反映错误在关键实体（金额、账号、日期）上的分布，而 IVR 场景中恰恰是实体错误导致真实业务失败。因此本文框架把 WER 降级为诊断项，改用 ASR-IFR（ASR 导致的意图/流程失败率） 与 CEER（关键实体错误率） 作为门禁指标——前者衡量语音识别问题是否让更多测试用例走向错误分支，后者衡量实体损坏是否增加，二者都更贴近端到端业务后果。

诚实的边界

README中写道：“默认的数值门禁是工具演示的示例，不是通用验收标准。生产团队应根据风险等级和历史基线自行治理阈值。”--max-asr-ifr-delta 0.02和--max-ceer-delta 0.01只是起点。支付IVR和音乐IVR不应共享同一个门禁，就像它们不应共享后果尺度一样。框架的职责是机制——存在、数值、有限、fail-closed、显式退出。你的职责是策略：哪些增量、哪个风险等级、对哪个基线、多久评审一次。一个阈值无人负责的门禁，就是穿着漂亮西装的“假绿”。

给所有构建门禁的人

你不需要这个框架也能使用这条原则。无论你拥有什么样的质量门禁——测试覆盖率、延迟预算、错误率告警、模型评估——问那个“第四种结局”的问题：如果这个门禁检查的指标明天变得不可用，门禁会变红还是变绿？ 如果答案是绿，你就没有门禁；你有的是一盏接在空线上的绿灯。像v1.1.0那样修复它：把指标的存在性作为检查的一部分，在缺失时响亮而具体地失败，并让每一次跳过都成为显式、可见、可评审的决定。

你调查的红灯是麻烦。你盲目信任的绿灯，是一份等待日期的故障报告。