---
title: "给提示词写一套能回归的评测"
description: "改提示词最怕凭感觉。把任务、判定和样本固定下来，跑一次基线，之后每次改动都用同一套样本对比通过情况，才不会越改越差。"
updated: 2026-11-13
canonical: https://docai.cc/learn/write-evals/
markdown_mirror: https://docai.cc/learn/write-evals.md
---
## 第一步：定任务与判定

先把任务写成一句话：输入是什么，输出要满足什么。判定标准要具体到能对单条输出回答「通过还是不通过」。

例如不写「回答要准确」，而写「只引用材料里的条款，材料没有的内容要明确说未提及」。标准里同时包含两类条件：

- 硬条件：格式、字段、长度上限、禁用内容，一条不满足就判失败。
- 软条件：要点是否覆盖、语气是否合适，这类需要评分或人工判断。

写不出失败条件的标准，等于没有标准。先把标准写清楚，再谈评分器。

## 第二步：写 20 条金标

从真实请求里挑 20 条输入，人工写好期望输出或通过条件，覆盖三类：

- 常见请求：占多数的正常输入。
- 边界情况：空输入、超长输入、多语言混写、指代不清。
- 已知失败：线上出过错、被投诉过、你担心会出错的。

金标集要固定并纳入版本管理。改提示词导致某条失败时，不要顺手改样本让它通过——那是在改考卷。发现新的失败模式，再补进下一版。

## 第三步：选评分器

按任务类型分配：

- 代码判定：有唯一答案的用它。JSON 是否合法、字段是否齐全、数值是否正确，都适合写成断言。
- 模型裁判：开放题用它。给裁判明确的标准和通过条件，尽量做成对比较，并控制其随机性。裁判的偏差与校准要先有认识。
- 人工评分：最贵，用来抽查前两者的一致性，不用来跑全量。

评分器的选择要和判定标准一起写在文档里。不写清楚，换个人跑出的结果就不可比。

## 第四步：跑基线

改动之前，先用当前版本的提示词跑一遍全套样本，记录每条结果：

- 输入、输出、通过与否；
- 提示词版本、模型名、温度等参数；
- 跑了几次。生成有随机性，[温度](/concepts/temperature/)越高波动越大，单次结果可能误导。

这份基线就是之后所有对比的参照。没有基线，你无法证明新版本更好，只能凭印象。硬条件不稳定的样本单独标出，先修稳定性，再谈质量。

## 第五步：看失败分布并改提示

不要只看通过条数，要看失败集中在哪：

- 同一类格式错误反复出现：输出约束不够硬，或者该用结构化输出。
- 该说「不知道」时编造：缺少材料边界和拒答规则，可参考[减少幻觉](/learn/reduce-hallucination/)。
- 要点漏掉：检查清单不完整，或者示例不足。
- 指令之间互相冲突：提示词太长，后写的规则覆盖了前面的。

每次只改一处，改完跑同一套样本，对比通过项与失败项的变化，重点看之前通过的样本有没有回退。提示词怎么写，见[写系统提示词](/learn/write-a-system-prompt/)；评测如何进日常流程，见[评估每一次改动](/learn/evaluate-changes/)。

## 自测

1. 问：评测集为什么要从真实请求里挑样本？
   答：公开数据集测的是通用能力，你的产品要测自己的任务分布。真实请求覆盖实际用词、边界与已知失败，更能暴露问题。

2. 问：评分器为什么不能只用模型当裁判？
   答：裁判模型评的是「像不像好答案」，事实错误也可能拿高分。有唯一答案的部分用代码判定，模型裁判只用于开放题，并做人工抽样校准。

3. 问：为什么改动提示词要一次只改一处？
   答：一次改多处，通过情况变化时无法归因。一次只改一处，跑同一套样本，才知道哪句话带来改善或回退。