Eval 不是上线前才做的事

我们这一年做过的 AI 项目里，最贵的 bug 都不在代码里，而在 prompt 和数据里。 代码 bug 可以 hotfix，数据漂移和 prompt 退化是没法在监控里看见的——直到客户发邮件骂人。

所以从今年起，我们把一条规则写进了所有项目的 SOP：

PoC 第一周必须有 Eval 集，第二周必须有自动评分跑分。

为什么 Eval 这么重要

一个常见的失败链路：

1. PoC 跑通几个 case，演示一切顺利
2. 接入生产数据，开始有反馈说"有时不准"
3. 调 prompt，反馈"现在又不准了别的 case"
4. 团队开始上"用户感觉"驱动开发
5. 三个月后没人知道哪个版本最好

Eval 集解决的事情，不是"做到多准"，而是 让你有一把秤。 没有秤之前，所有改 prompt 的动作都是赌博。

我们怎么落地

• Day 1：从客户的真实数据里抽 30-50 个有代表性的 case（含边界、含失败）
• Day 3：定义评分维度，比如准确性 / 引用正确 / 风格一致 / 拒答合理
• Day 5：跑分管线接入 CI，每次改 prompt 都跑
• Day 7：Dashboard 暴露给客户，让客户也能看分

后面优化的时候，任何改动都可以回答"会变好吗"——这是工程，不是玄学。

一句话

别等上线再上 Eval。建 Eval 不是工程师的额外负担，是工程师的护身符。

下一篇：我们如何用 LLM-as-Judge 同时省 80% 标注成本。