如何在 CI 中用 LLM eval 门禁拦截 Pull Request

核心亮点

OpenRouter 发布教程，讲解如何用固定的 eval 集在 CI 里给 pull request 设门禁：当通过率低于阈值，脚本以非零退出码阻止合并。做法和单元测试门禁一致，只是判分对象从代码变成了模型输出。

具体能力或事件经过

思路是准备一组锁定的评测用例，每次 PR 都重跑，对照同一套评分标准算通过率。一旦低于设定线，CI 直接红，合并被拦。这样模型或提示词改动如果在真实任务上掉链子，能在合并前就被挡下，而不是等上线后用户投诉。

技术细节

关键是 eval 集要"固定"且"有代表性"。用例应覆盖高频与易错场景，评分标准写成可执行的 rubric，避免人肉主观判分。门禁阈值要留余量，因为模型两次运行会抖，贴线设会误杀正常改动。

与竞品对比

很多团队靠人工 review 或线上盲测发现回归，成本高且滞后。把 LLM eval 接进 CI，是把质量保障前移到提交阶段，和软件工程的测试门禁同构，比事后救火便宜得多。

行业影响或适用场景

凡是把模型接进产品的团队都该有这道门。客服话术、代码生成、抽取规则任何改动，都能在合并前验证不退化。它把"AI 改动可不可靠"变成可自动回答的是非题。

数据口径与可信度

教程给出的是方法论，具体阈值要你按自己的流量标定。eval 集太小结论不稳，建议从 20 到 50 条起步逐步扩到数百条，并随任务演化持续维护，否则门禁会随分布漂移失效。

风险与边界

门禁不是银弹：eval 集代表不了全部真实分布，通过率合格也可能漏掉长尾坏 case。阈值太严会拖慢迭代、太松则形同虚设。它需要专人维护，并与监控、回滚机制配合。

进一步分析

说白了，给 AI 加 CI 门禁，就是别再靠人肉感觉放行模型改动。把一组能代表业务的题锁进仓库，每次改动自动考，不及格不许合并。这套纪律和写单测一样朴素，却是 AI 产品能稳定迭代的地基。

落地步骤

真要做，先建一个 eval 目录，放 20 到 50 条能代表业务的题与标准答案，写成可执行 rubric。在 CI 配置里加一步"跑 eval → 算通过率 → 低于阈值则非零退出"。把这套接进每次 PR，模型或提示词改动自动过考。

常见误区

误区一是 eval 集太小或太简单，门禁形同虚设；误区二是阈值贴线设，正常改动被误杀；误区三是只在合并前跑一次，上线后不再监控。正确做法是样例逐步扩、阈值留余量、生产侧配监控与回滚。

一句话结论

说白了，给 AI 改动加 CI 门禁，就是别靠人感觉放行。锁一组代表业务的题，每次改动自动考，不及格不许合并，AI 产品才能稳稳迭代。

延伸观察

这套门禁会催生一层"评测资产"：随着题库变大变好，它本身就是产品竞争力。将来比的不只是模型多强，而是谁家的回归防护更厚，能在频繁改动中保住体验。把 eval 当代码资产经营，是 AI 团队成熟的标志。