让 AI 给 AI 打分，能直接当验收结果吗？先校准裁判

先把打分问题写成可判断的标准

“回答质量好不好”太宽。先把标准拆成能核对的判断，例如是否包含指定依据、是否遗漏必需字段、有没有超出允许范围的承诺。每项标准都要说明什么算通过、什么算失败、哪些材料不足时应返回不确定。标准越含糊，自动评分越容易把文风偏好误当作事实正确。

人工先标一组有争议的样本

选一组覆盖正常、边界、缺资料和可能造成损失的案例，交由熟悉业务的人独立判断并记录理由。再比较裁判模型与人工标注的分歧。只挑容易样本会掩盖评分盲点；只看一个总体准确率，也可能让少量关键误判被平均数盖住。

把分歧按原因整理：标准本身不清、输入缺上下文、裁判没看到依据、表述风格偏差，或业务事实判断需要专业责任人。修改评分说明后用新的保留样本复测，避免只在熟悉的题目上调到看似一致。

别把平台评分流程写成业务真理

OpenAI 当前 Evals 指南描述了定义任务、用测试输入运行、分析结果并迭代的过程；同一页面还公布 Evals 平台将在 2026 年 10 月 31 日转为只读、11 月 30 日计划关闭。因工具生命周期临近变化，团队应把任务标准、样本、人工标签与结果保存为可迁移资产，不把业务验收逻辑锁在某个平台接口中。

评估框架无论用本地脚本、表格还是服务端工具，都要保留版本、运行配置和样本来源。模型评分只能作为一条证据；对外承诺、付款、权限变更等高影响决策，应保留有权人员的最终审批。

特别检查裁判模型容易偏向什么

评分器可能偏好更长、更自信或更像示例的回答，即使这些特征与任务正确性无关。为减少这类误判，可交换答案顺序、隐藏模型身份、加入简短但准确与冗长但错误的对照案例，并让人工审核者说明评分理由。若分数会直接触发拒绝或晋级，必须检验这些边界。

人工裁定不一致时，不要只取多数票。先检查业务标准是否缺少例外、输入是否含关键资料，再决定补充说明、拆分评分项或将该类案例固定交给人工。保留修订记录，避免裁判模型不断学习到一种未经批准的偏好。

把校准结果转成审核规则

先规定自动评分可承担的低风险筛查范围，再写清人工复核触发条件，例如评分低、评分器无法读取证据、模型拒答、版本变化或样本属于特殊业务。保存每次复核和修正，用来发现评分器在何类输入上失效。

部署前验收至少包含标准定义、人工对照集、分层结果、分歧样例、停止条件和负责人。人工与评分器一致，不等于内容一定真实；业务事实仍需回到来源和责任人。