AI 提示词回归测试实战：小样本集、评分规则和上线前对比

我们先看一个很常见的 AI 应用改动现场：为了让回答更礼貌，团队把提示词里加了一段“请尽量详细解释”。新问题看起来更完整了，但旧的客服场景突然开始啰嗦，甚至把本来应该拒答的内容也展开解释。

这时很容易陷入两种争论：有人说新提示词更自然，有人说它让旧流程变差。只靠感觉很难定。更稳的做法是准备一组固定问题，每次改提示词都跑同一批样例，再按评分规则对比前后结果。本文就按这个思路一步步做一个轻量提示词回归测试流程。

适合人群

本文适合正在做 AI 客服、知识库问答、代码助手、内容生成或内部智能助理的开发者和产品同学。你不需要复杂平台，先用表格、脚本和人工复核就能把流程跑起来。

目录

• 问题现场：提示词改了，旧问题反而变差
• 初步判断：先别争论，固定样例再看结果
• 动手验证：准备小样本集
• 定位原因：评分规则太模糊，结果就难比较
• 修复方案：前后对比加人工复核
• 验证结果：用通过线决定是否上线
• 常见坑位和总结

问题现场：提示词改了，旧问题反而变差

假设我们有一个知识库问答机器人，旧提示词比较短：

你是企业知识库助手。请基于资料回答问题，不确定时说明不知道。

后来为了改善体验，我们改成了下面这样：

你是企业知识库助手。请基于资料回答问题，尽量详细、友好地解释，并补充相关建议。

新提示词在一些问题上确实更自然。但我们拿旧问题一测，发现三个现象：

• 本来一句话能答完的问题，变成了很长的说明。
• 资料里没有答案的问题，模型开始给“可能的建议”。
• 用户只问步骤时，回答混入了不相关背景。

现在问题就明确了：这不是单个回答好坏，而是提示词改动有没有影响旧场景。

初步判断：先别争论，固定样例再看结果

我们先做一个判断：如果每次测试都临时找问题，就很难知道结果变化来自哪里。今天测 A、明天测 B，最后只能靠印象。

所以第一步是固定一批样例。样例不需要一开始就很多，20 到 50 条就能覆盖大部分高频场景。关键是每条样例要写清楚：

• 输入问题是什么。
• 相关资料是什么。
• 期望回答应该包含什么。
• 哪些内容不能出现。
• 这个样例属于哪类场景。

动手验证：准备小样本集

我们可以先用一个 JSON 文件保存样例。这里用简化结构演示：

[
  {
    "id": "case_001",
    "scene": "资料命中",
    "question": "报销发票抬头怎么填写？",
    "context": "公司报销发票抬头为：杭州某某科技有限公司。",
    "must_have": ["杭州某某科技有限公司"],
    "must_not_have": ["自行填写", "联系供应商确认"]
  },
  {
    "id": "case_002",
    "scene": "资料缺失",
    "question": "年会酒店地址在哪里？",
    "context": "当前资料未收录年会酒店地址。",
    "must_have": ["资料未收录", "无法确认"],
    "must_not_have": ["具体酒店名", "详细地址"]
  }
]

这一步不追求一步到位。先把最容易出错的场景放进去，例如资料缺失、敏感拒答、格式要求、短答案、长答案、边界问题。后面遇到线上问题，再把新案例补进样本集。

定位原因：评分规则太模糊，结果就难比较

有了样例，还需要评分规则。否则大家看同一个回答，可能有人给 90 分，有人给 60 分。

我们先用简单的 0 到 2 分规则：

• 2 分：关键内容正确，格式符合要求，没有多余扩展。
• 1 分：主答案基本正确，但有轻微冗余或表达不清。
• 0 分：核心答案错误、编造信息、漏掉关键内容或违反限制。

再给每条样例增加一个最低通过线。例如资料缺失类必须 2 分，因为这类场景最怕编造；普通解释类允许 1 分以上。

修复方案：前后对比加人工复核

现在我们把流程串起来：旧提示词跑一遍，新提示词跑一遍，得到两组回答，再按同一规则打分。可以先用脚本做结构化记录，再由人复核边界样例。

cases = load_cases("prompt_cases.json")

rows = []
for item in cases:
    old_answer = ask_model(old_prompt, item["question"], item["context"])
    new_answer = ask_model(new_prompt, item["question"], item["context"])

    rows.append({
        "id": item["id"],
        "scene": item["scene"],
        "old_answer": old_answer,
        "new_answer": new_answer,
        "old_score": grade_answer(item, old_answer),
        "new_score": grade_answer(item, new_answer)
    })

save_rows("prompt_compare.json", rows)

这里的 grade_answer 可以先写得很朴素：检查必须包含的词、禁止出现的词、回答长度和格式。不要一开始就追求全自动，人工复核仍然很重要，尤其是资料缺失、合规边界和高价值用户路径。

验证结果：用通过线决定是否上线

最后把结果汇总成一张表：

样例总数：30
新提示词提升：9 条
新提示词持平：18 条
新提示词退化：3 条
关键场景退化：1 条

如果关键场景退化，就不要直接上线。我们可以回到提示词里缩小“尽量详细”的范围，例如只允许在资料明确命中时补充解释；资料缺失时必须简短说明不知道。

这一步的目标不是证明某个提示词完美，而是让上线决策有依据：哪些场景变好了，哪些场景变差了，差的地方能不能接受。

常见坑位和总结

1. 样例只放成功问题

样例集里一定要放失败边界，例如资料没有、问题含糊、用户要求越界、格式要求很严格。只有成功问题，测试结果会过于乐观。

2. 评分规则只写“回答好不好”

规则要尽量可判断，例如是否包含关键字段、是否出现禁止内容、是否控制长度、是否保持指定格式。越具体，争论越少。

3. 改了模型又改提示词

一次只改一个变量更容易定位原因。如果模型版本、提示词、上下文资料同时变化，结果变差时很难知道是谁导致的。

4. 忽略人工复核

自动检查能筛掉明显问题，但边界场景仍然需要人看。尤其是对外客服、合规问答、合同和财务类场景，不要只看平均分。

总结一下，提示词回归测试的核心并不复杂：固定样例、明确规则、前后对比、人工复核、按通过线决定是否上线。它让提示词优化从“感觉更好”变成“证据更清楚”，也能减少一次改动带来的旧场景退化。