改了一行 Prompt，用例全红了——Prompt 回归测试与 CI 门禁

AI 测试开发面试高频题：“Prompt 变更怎么防回归？”
Prompt 是代码，但它比代码危险：改一个错别字不会有编译错误，却可能让模型行为整体漂移。这篇讲怎么把 Prompt 变更管得像代码变更一样。

一、真实场景：一句"回答尽量简洁"，准确率掉了 25 个点

某在线教育公司有个课程咨询机器人，核心能力是意图分类：把用户消息分成"课程咨询 / 退费投诉 / 价格协商 / 闲聊"四类，再路由给不同团队。分类 Prompt 写在代码里，线上表现一直很稳，周抽检准确率 96%。

某天下午，一个开发同学觉得机器人回复太啰嗦，在 system prompt 里加了一句："回答尽量简洁，不要输出多余内容。"改完随手测了两条，感觉没问题，直接发布了。

三天后，业务方反馈"投诉工单量暴涨，而且很多工单分错了组"。拉数据一查：分类准确率从 96% 掉到了 71%。原因让人哭笑不得——“简洁"这个指令让模型在边界场景下偷懒：遇到"我买的课孩子不想学了，能不能退一部分钱"这种既像退费又像价格协商的消息，模型不再做细致推理，直接甩一个最短的判断，大量"退费投诉"被错分成"价格协商”，工单全路由到了销售组。

复盘时最扎心的一句话是：这次变更没有经过任何测试，因为没有人把 Prompt 当成需要回归的东西。 在大家心里它只是"一段文案"。

二、思路：把 Prompt 当代码管，就得有代码的待遇

代码变更有版本控制、有 review、有 CI 测试。Prompt 凭什么没有？这套体系一共四件事：

1. Prompt 版本化：从代码里抽出来，进 Git，变更走 PR；
2. 黄金用例集：把分类边界场景固化成测试用例；
3. 回归评测：用 promptfoo 这类工具批量跑用例、自动打分；
4. CI 门禁：通过率低于阈值，PR 不许合并。

三、核心代码：promptfoo 用例 + CI 门禁

第 1 步：Prompt 入库，变更走 PR

repo/
├── prompts/
│   └── intent_classifier_v12.txt    # prompt 正文，文件名带版本
├── promptfooconfig.yaml             # 评测配置
└── tests/intent_cases.yaml          # 黄金用例

从 v12 改到 v13，就是一次普通的代码提交：有 diff、有 review、有 CI。"随手改一句"这种操作从物理上被禁止了。

第 2 步：写回归用例

每条用例 = 输入 + 断言。断言分三种：硬断言查结构和枚举（快、准），LLM 裁判查语义（兜住措辞漂移），专门留"边界题"（故障里栽跟头的那种）：

# promptfooconfig.yaml
prompts:
  - file://prompts/intent_classifier_v13.txt
providers:
  - openai:gpt-4o-mini

tests:
  # 硬断言：输出必须是合法 JSON 且枚举值正确
  - description: 明确退费诉求必须分到 refund
    vars:
      user_msg: "孩子学了三节就不想学了，我要退费"
    assert:
      - type: is-json
      - type: javascript
        value: "output.intent === 'refund'"

  # 边界题：退费 + 价格因素混合，正是上次故障翻车的类型
  - description: 退费与议价混合场景不得误分为 price_consult
    vars:
      user_msg: "买的课孩子不想学了，能不能退一部分钱"
    assert:
      - type: javascript
        value: "output.intent === 'refund'"

  # LLM 裁判：语义层面的兜底
  - description: 语气友好的咨询不得被判为投诉
    vars:
      user_msg: "想问下暑期班还有名额吗，顺便看看价格"
    assert:
      - type: llm-rubric
        value: "意图应为课程咨询(course_consult)，不得判为投诉(refund)"

第 3 步：CI 门禁，不达标不许合并

# GitHub Actions 片段
- name: Prompt 回归评测
  run: npx promptfoo eval -c promptfooconfig.yaml -o results.json

- name: 通过率门禁
  run: |
    python tools/gate.py results.json --threshold 0.95

# tools/gate.py：解析评测结果，通过率低于阈值就 exit 1 拦住合并
import json, sys

def main():
    results = json.load(open(sys.argv[1]))
    stats = results["stats"]
    pass_rate = stats["successes"] / stats["total"]
    threshold = float(sys.argv[sys.argv.index("--threshold") + 1])
    print(f"通过率 {pass_rate:.1%}，门禁阈值 {threshold:.0%}")
    if pass_rate < threshold:
        # 打印失败用例，方便直接看是哪类场景崩了
        for r in results["results"]:
            if not r["success"]:
                print(f"  ✗ {r['description']}")
        sys.exit(1)

if __name__ == "__main__":
    main()

故事里那次变更如果走了这套流程：PR 一提交，CI 跑 80 条黄金用例，边界题成片失败，通过率 71% 卡在 95% 的门禁上——那句"回答尽量简洁"根本进不了主干。

四、沉淀成方法：Prompt 变更管理四件套

两条工程纪律：一是**"随手改 prompt"必须被工具链物理禁止**——prompt 不在代码库里就管不住，靠自觉是不行的；二是门禁阈值宁严勿松，阈值从 95% 往下调需要有数据支撑，就像性能预算一样只紧不松。另外别忘了模型这一侧：模型版本升级（比如换新版模型）时，用同一套黄金用例集对新旧模型各跑一遍做对比评测，指标下降超阈值同样拦截——Prompt 和模型是锁在一起的一对变量，任何一个动了都要回归。

五、面试追问，你答得上来吗

1. 用例集要跑几十上百条，每个 PR 都全量跑，又慢又烧 token，怎么办？——答：分层执行。PR 上跑 20~30 条核心冒烟集（可以用便宜的小模型），全量用例集每晚定时跑 + 发布前跑。门禁要的是"快速反馈 + 不放水"，不是每个 PR 都跑全套。
2. Prompt 回归测试和传统接口回归有什么本质区别？——答：断言对象变了。接口回归断的是"输入输出契约"，结果确定；Prompt 回归断的是"行为契约"，要靠枚举硬断言 + 语义裁判 + 统计阈值（通过率、一致性率）组合判断，而且要接受"95% 通过"这种概率性结论。另外它多了个维度：同样的 prompt 换模型版本行为会变，回归必须覆盖"模型升级"这个触发条件。
3. 怎么证明新 prompt 是"优化"而不是"拆东墙补西墙"？——答：看分场景的通过率变化，不只看总分。评测报告按用例标签（分类别、分场景）拆开对比新旧版本：总分涨了但某个核心场景掉了 10 个点，照样不能合——总分掩盖局部退化，是 prompt 优化里最常见的陷阱。

下一篇预告：《模型编造 API 参数，工具调用连环 500——Function Calling 契约测试》