监控面板的绿灯不一定真实有效，AI护栏评估可能早已失效

当前技术领域讨论AI工程化时，Guardrail（护栏）成为热门话题。无论是Agent必须遵循的Lint规则、上线前强制执行的Evals、每个PR通过的Review Bot，还是将架构规则直接提供给模型，这些措施确实关键。缺乏这些护栏，AI在资深工程师眼中就如同随时可能爆炸的定时炸弹。

监控面板上的绿色表象可能具有欺骗性

在推动公司AI落地过程中，我发现一个令人不安的现象：许多人满足于监控面板上显示的一片"绿色"，却忽略了从未触发的护栏与已悄悄失效的护栏在结果上完全相同——都显示绿灯。

我曾目睹一个典型案例。团队成员配置了GitHub Actions自动部署流程，逻辑设计严谨，要求CI通过才能触发Deploy。然而，每次修改后端代码后，该成员仍习惯通过SSH登录服务器手动执行git pull。后来才发现，CI任务在main分支上实际上从未成功运行过一次。原因是配置文件中存在以下逻辑：

on:
 workflow_run:
 workflows: ['CI']
 branches: ['main']
 types: [completed]

jobs:
 deploy:
 if: ${{ github.event.workflow_run.conclusion == 'success' }}

由于CI持续失败，部署任务始终被跳过（Skipped）。在Actions界面上，这种"被跳过"的状态从远处观察，与正常运行但未触发的任务几乎无法区分。一条被悄然阻塞的管道，看起来仿佛它根本不存在。

这种逻辑在AI Eval（评估集）中造成的后果更为严重。如果评分模型（Grader）从不报错，或已悄无声息地失效，它给出的结果同样显示为"通过"。

最棘手的情况是护栏"失效但显示成功"。例如，有人修改了Prompt模板，导致评分模型的正则匹配失效，所有案例都被判定为Pass；或者数据集字段被重命名，加载器返回空列表，评估集在0.4秒内完成0个用例，然后报告100%通过率。这三种情况在报告中均显示为绿色，但实际上质量控制已完全崩溃。

因此，我在公司内部推行一项原则：每个Grader必须配备一个"已知错误样本"作为对照组。如果该Grader在连续一段时间内未能拒绝任何明确的错误样本，则表明该护栏已失效。

AI评估模型缺乏版本溯源导致结果不可信

另一个容易被忽视的细节是：没有版本溯源的分数不具备证据价值。如果展示85分的评估结果却不告知使用的是哪个版本的数据集快照、哪个版本的Prompt以及哪个版本的评估模型，这本质上只是一个"带小数点的感觉"。

一旦分数发生变化，无法判断是模型真正变强，还是评估集变简单了。这种严谨性源于我处理金融支付系统时养成的习惯——在受监管系统中，没有人会让你"相信"某个控制项正常运行，他们要求你证明：哪个版本、在什么时间、针对什么输入、运行了哪个版本的规则。

当前AI工程化已承受类似压力。许多上线决策基于Eval结果做出，但人们尚未养成保留"审计凭证"的习惯。

自动化工具的可靠性需要主动验证

归根结底，当我们将检查交给自动化工具时，问题从"是否有人审查"转变为"这个工具是否仍在正常工作"。前者可以直接询问负责人，而后者如果不主动验证，就会持续被欺骗。