别被那堆绿色的打勾给骗了，很多 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 模板，导致评分模型的正则匹配失效了，结果所有 Case 全部判定为 Pass；或者数据集字段被重命名了，加载器返回了个空列表，结果评估集在 0.4 秒内跑完 0 个用例，然后向你报告 100% 通过率。这三种情况在报告里看起来全是绿色的，但实际上你的质量控制已经彻底崩了。
所以我在公司内部推行一个原则：任何一个 Grader 必须配一个“已知错误样本”作为对照组。如果这个 Grader 连续一段时间没有拒绝过任何一个明确的错误样本，那这个护栏就是失效的。
还有一个细节，很多人在做 AI 评估时容易忽略：没有版本溯源的分数根本不算证据。如果你给我看一个 85 分的评估结果，但没告诉我用的是哪个版本的数据集快照、哪个版本的 Prompt、哪个版本的评估模型，这其实就是个“带小数点的感觉”。
一旦分数变动，我没法判断是模型真的变强了，还是评估集变简单了。这种严谨性是我在处理金融支付系统时养成的习惯——在受监管的系统中，没人会让你“相信”某个控制项运行了，他们要求你证明：哪个版本、在什么时间、针对什么输入、运行了哪个版本的规则。
现在的 AI 工程化其实已经继承了这种压力。很多上线决策是基于 Eval 结果做的，但大家还没养成留“审计凭证”的习惯。
说白了，当我们把检查交给自动化工具时，其实是把问题从“有没有人看过”变成了“这个工具还在正常工作吗”。前者你可以直接问那个负责人，而后者如果你不刻意去验证，你永远在被欺骗。
