AI 评测最佳实践:别等写完再验收

你让 AI 帮忙改了一版表单页，本地跑起来「看着还行」，就 merge 了。

两周后设计同学来问：为什么间距全乱了、空态没了、按钮 hover 和主题色对不上？

功能没挂，测试也可能还是绿的——但页面的气质已经悄悄漂了。 这就是 OpenAI 在 [Evaluation best practices](https://platform.openai.com/docs/guides/evaluation-best-practices) 里想帮你避开的典型坑：把「感觉差不多」当成验收标准。

文档里有一句很硬的话：

Evaluate early and often.（尽早评估、持续评估。）

AI 协作不是「先写完再肉眼验收」，而是从一开始就把评估接进交付链路——和写 prompt、改组件、调 Agent 工具链同步进行，而不是上线前补一张 checklist。

一、先搞清楚：你要评的到底是哪一种 Eval

OpenAI 把「evals」分成三类：行业 benchmark（MMLU 这类横向比模型）、通用数值指标（ROUGE、BLEU）、以及针对你自己 LLM 应用设计的测试。

这篇指南讲的是第三类——和你业务绑定的 eval，不是拿 perplexity 自嗨。

对前端来说，这意味着：

别问「这次生成质量高不高」这种空问题，要问在你真实任务分布里，输出是否满足可交付标准——组件 API 有没有泄漏、主题约束有没有被破坏、页面状态是否完整、视觉层级有没有漂移。

分数只是辅助；你要评的是任务，不是抽象「代码质量」。

二、六条正路，四条反路

文档给了一组很实用的 tips，和对应的 anti-patterns，可以直接当团队纪律：

其中 vibe-based evals 四个字，值得贴墙上：

等上线、等 demo、等「老板觉得 OK」再评估，等于把 nondeterminism（AI 输出的随机性）留到最贵的地方爆。

评估越早介入，返工越便宜；越晚靠感觉，气质漂移越难抓。

三、Task-specific evals：前端该评什么

官方强调：测试要反映模型在真实世界分布下的能力。 不是造几个「完美 prompt」自测通过就完事。

把这句话翻译成前端 AI 协作场景，eval 对象通常长这样：

注意：这些不是「审美偏好」，而是可写成 rubric 的交付标准。

功能可能还在，但留白变挤、层级变平、反馈各说各话——用户说不清哪里不对，只会觉得「变 cheap 了」。成熟的前端工程，会把这类「气质回归」和质量回归一起纳入 eval，而不是留给设计同学事后肉眼看。

文档还提醒：LLM 更擅长判别而非开放式生成。

所以 eval 设计优先 pairwise 对比（A/B 哪个更符合 design spec）、分类（是否违反 token）、按 rubric 打分——而不是让模型自由发挥再凭感觉挑。

四、Continuous evaluation：每次改动都过一遍

指南把 eval 流程拆成五步：定义目标 → 收集数据集 → 定义指标 → 运行对比 → 持续评估（CE）。

CE 的含义是：每次变更都跑 eval——换 prompt、加 tool、改 Agent 路由、甚至 bump 了一版组件库，都要触发同一套测试集。同时监控线上，把新出现的 nondeterminism 沉淀进 eval set，让集合越滚越大。

对前端 AI Harness，可以落成很具体的钩子：

prompt / 系统指令变更     → 跑 UI 生成 eval 集
design token 变更         → 跑视觉层级 + 硬编码色检测
组件库 minor 升级         → 跑 API 契约 + 快照/视觉 diff
Agent 新增工具（读 Figma）→ 跑 tool selection + 参数提取 eval

Eval 不是发布前的门禁，而是开发环上的常态回路。

这和传统 CI 的关系也清楚：单元测试保逻辑，E2E 保路径，task-specific eval 保「AI 产出是否仍像你的产品」——三者叠加，才覆盖 AI 系统的随机面。

五、架构越复杂，eval 点越多

OpenAI 按架构复杂度列了四类模式，并指出 nondeterminism 从哪进来，就在哪加 eval：

文档对 multi-agent 有一句狠话：要不要上多 Agent，应该由 eval 驱动决策，而不是先堆复杂度。

如果 single-agent + 好 eval 已经能稳住，就别为了「架构好看」提前拆团队——eval 会告诉你边界在哪。

每一层都有对应 eval 题型：instruction following、functional correctness、tool selection、data precision、agent handoff accuracy。

前端不必照搬客服工单例子，但「工具选错」「参数传错」「交接丢状态」这三类失败，在 AI 写代码场景里一样高发。

六、Human calibration：自动打分前先和人「对齐」

指南把评估器分成三类：数值指标（快、可回归）、人工评判（准、贵）、LLM-as-a-judge（折中、可扩展）。

关键不在选哪一种，而在 Maintain agreement——自动指标必须和人工标注对齐，否则你会得到「分数很好看、产品很难用」的幻觉。

OpenAI 对 LLM judge 的建议也很实操：

• 优先 pairwise 或 pass/fail，比开放式打分稳

• 用最强模型做 judge 起步，再验证能否换更小模型

• 控制长度偏见（模型爱给长答案高分）

• Rubric 要细，最好给 1 分 / 5 分 / 8 分的示例答案（show rather than tell）

• 多人标注用共识投票聚合

落到前端：可以先让设计 / 资深前端对 30–50 条 AI 输出做 blind review，定出「合格 / 不合格」和边界样例，再把这些样例喂给 LLM judge 或脚本 grader。Judge 对齐之前，别急着把 eval 接进 CI 当硬门禁——否则你会自动化地批量放行错误。

心理学里有个熟悉的坑：指标一旦变成 KPI，大家就开始 optimize 指标本身。

所以 eval 设计要同时看「抓到了多少真问题」和「误杀了多少好输出」——只追求通过率，和 vibe-based evals 只是换了个数字皮肤。

七、边缘场景：happy path 不够

文档专门有一节 Handle edge cases。真实用户输入和线上上下文，从不是 demo 里那种干净句子。

Eval 集至少要覆盖：

• 输入多样性：多语言、Markdown/JSON、带图需求

• 上下文复杂度：一句话多个意图、错别字、极简指令（用户只发「退货」）、长对话、工具返回字段歧义

• 对抗与格式：jailbreak、强制 JSON 输出、用户 prompt 与 system prompt 冲突

前端场景里，「帮我把这个按钮改好看点」就是典型低上下文输入——你的 eval 不能只有「请根据 design token 生成 PrimaryButton 组件」这种教科书 prompt。

Production 日志 是 eval 数据集的金矿；开发期全量 log，就是为了日后能 mined 出这些 case。

如果你只想带走一句话，我建议记这个：

Evaluate early and often——评估不是上线前的补考，而是 AI 协作的默认节奏；前端尤其要用 task-specific evals 盯住 API、状态、token 和视觉气质，别等功能还在、页面已经「变味」才后悔。

参考原文：[OpenAI — Evaluation best practices](https://platform.openai.com/docs/guides/evaluation-best-practices)