Shipping Eval：我把 AI 评测接进 CI，第一次在发布前拦住回归#

这两个月我明显感受到一件事：AI 功能上线的速度越来越快，但“能跑”和“稳定可用”之间的距离也越来越大。我们在 PR 里看代码、跑单测、看接口契约，却经常没有一个固定的机制去验证“这个回答质量有没有退化”。

过去我也用过人工 spot check，但它有两个问题：不稳定、不可回归。最近我把一套最小 AI 评测流程接进 CI，目标很朴素：每次合并前，至少知道这次改动会不会把关键场景打坏。

为什么我现在才认真做评测#

不是因为“评测”这个词变热了，而是基础设施真的成熟了。

从 2025 到 2026，主流模型平台都在强调三件事：

1. 支持更长时长、可异步的任务执行（方便把评测放进流水线批量跑）。
2. 原生工具调用与结构化输出更稳定（便于把结果喂给规则引擎）。
3. 官方开始强调 eval 与 grader 的工程化实践（不再只是 demo）。

这三点叠在一起，意味着评测终于不只是“研究团队的玩具”，而是普通产品团队也能落地的工程能力。

我现在在 CI 里跑什么#

我把评测拆成三层，尽量用最小成本换最大确定性。

第一层：硬规则（必须过）#

这层不谈主观质量，只看底线：

• 是否按要求输出 JSON schema。
• 是否包含禁止字段（比如隐私信息、调试内容）。
• 是否触发已知高风险模式（例如越权提示词）。

这一层失败就直接阻断发布，没讨论空间。

第二层：场景回归（关键路径）#

我维护了一份小而精的样本集，覆盖线上最常见的 20 个请求。每次改动都跑一遍，重点看：

• 任务完成率是否下降。
• 工具调用链是否变长或失效。
• 平均 token 和延迟是否出现异常飙升。

这一层让我第一次真正看到“质量回归”的具体位置，而不是靠体感。

第三层：LLM Grader（软评分）#

有些问题很难用规则表达，比如“解释是否足够清晰”。我会让 grader 按固定 rubric 打分，但只把它当趋势信号，不把它当唯一真相。

我的做法是：

• grader 评分下降会触发告警，但不自动阻断。
• 连续两次下降才升级为必须人工 review。
• grader 的 prompt 版本也纳入仓库管理，避免“评测漂移”。

一次真实的“拦截”#

上周我把工具调用路由做了一个看起来很小的重构，本地体验没问题，单测也全绿。结果 CI 里的场景回归显示：两个高频场景从“一次调用完成”退化成“三次调用后超时”，总耗时涨了接近 70%。

如果没有这套评测，这个改动大概率会在高峰期直接上线，然后由用户帮我做回归测试。现在它在合并前就被挡住了，我只花了一个晚上修掉路由策略和重试阈值。

我给自己的三条落地原则#

1. 先做最小评测集，不要追求一步到位。
   先覆盖最常见、最贵、最容易出事故的场景。

2. 规则和 grader 混用，但职责分离。
   规则负责“能不能发”，grader 负责“值不值得发得更好”。

3. 把评测当发布门禁，而不是周报指标。
   没有门禁，评测数据再漂亮也只是仪表盘。

结尾#

我以前总觉得 AI 迭代太快，评测会拖慢速度。现在反过来：没有评测，团队其实会被返工和线上抖动拖得更慢。

如果你也在做 AI 功能，我建议从一个最小动作开始：挑 10 到 20 个真实用户请求，先把它们固定下来，接进 CI。你很快就会发现，评测不是额外工作，而是你和不确定性之间最便宜的保险。