改一版提示词,手测三五条,感觉"好像好了"就上线——这是提示工程里最常见的翻车路径。感觉会骗人,样本会骗人,尤其是你自己挑的样本。这篇文章讲怎么把提示词开发从玄学变成工程:一切改动,评估说话。

第一步:黄金集(Golden Set)

上线前先攒 30–100 条真实输入,覆盖:

  • 典型场景(大头,约 70%)
  • 边界情况:超长输入、空输入、中英混杂、对抗性表述
  • 历史翻车现场:每次线上 bad case,修复后回填进黄金集——这是集合最重要的增长来源

给每条标注期望输出(精确答案或验收要点)。没有这步,后面一切都是空谈。

第二步:自动评估的三个层次

规则断言:能用程序判定的就别用模型——JSON 合法性、正则匹配、数值容差、必须包含/不得包含的串。快、免费、零偏差。

模型打分(LLM-as-Judge):适用于开放性输出。但裁判有已知偏差,要主动校正:

  • 位置偏差:对比两个候选时偏向先出现的——评审时随机交换顺序,跑两次
  • 长度偏差:偏爱长回答——评分维度里显式加入"简洁性"
  • 自恋偏差:偏爱同族模型的输出——裁判模型尽量与被评模型异源

人工抽检:自动分全对但语义全错的情况存在,每周抽 5–10 条人审,校准裁判。

第三步:回归测试

提示词进了版本库,评估就该像 CI 一样跑:

# .github/workflows/prompt-eval.yml 核心逻辑
on: [pull_request]          # 提示词/模板改动即触发
jobs:
  eval:
    steps:
      - run: promptfoo eval --dataset golden_set.yaml
      - run: promptfoo assert --threshold 0.85   # 通过率门槛,不达标即失败

promptfoo、OpenAI Evals、自研脚本都可以,重要的是门槛化:低于阈值阻止合并,而不是出个报告没人看。

把成本和延迟拉进指标

正确率 95% 但成本翻了三倍,通常不值得。评估报告至少四列:通过率、p50/p95 延迟、token 成本。优化是多维的,单维最优常常是陷阱。

一个实用工作流

  1. 新需求 → 先写 10 条期望样例(测试驱动)
  2. 迭代提示词直到黄金集通过率达标
  3. 上线后 bad case → 回填黄金集 → 变成永久的回归用例
  4. 每次改提示词,跑全量:通过率不降、成本不升,才允许发布

提示词是你系统里变更最频繁的"代码"之一。变更频繁却没有测试的东西,迟早出事——这不是 LLM 时代的新道理,只是老道理终于轮到提示词了。