AI 测试开发面试高频题："Prompt 变更怎么防回归？"
Prompt 是代码，但它比代码危险：改一个错别字不会有编译错误，却可能让模型行为整体漂移。这篇讲怎么把 Prompt 变更管得像代码变更一样。
一、真实场景：一句"回答尽量简洁"，准确率掉了 25 个点
某在线教育公司有个课程咨询机器人，核心能力是意图分类：把用户消息分成"课程咨询 / 退费投诉 / 价格协商 / 闲聊"四类，再路由给不同团队。分类 Prompt 写在代码里，线上表现一直很稳，周抽检准确率 96%。
某天下午，一个开发同学觉得机器人回复太啰嗦，在 system prompt 里加了一句："回答尽量简洁，不要输出多余内容。"改完随手测了两条，感觉没问题，直接发布了。
三天后，业务方反馈"投诉工单量暴涨，而且很多工单分错了组"。拉数据一查：分类准确率从 96% 掉到了 71%。原因让人哭笑不得——"简洁"这个指令让模型在边界场景下偷懒：遇到"我买的课孩子不想学了，能不能退一部分钱"这种既像退费又像价格协商的消息，模型不再做细致推理，直接甩一个最短的判断，大量"退费投诉"被错分成"价格协商"，工单全路由到了销售组。
复盘时最扎心的一句话是：这次变更没有经过任何测试，因为没有人把 Prompt 当成需要回归的东西。 在大家心里它只是"一段文案"。
二、思路：把 Prompt 当代码管，就得有代码的待遇
代码变更有版本控制、有 review、有 CI 测试。Prompt 凭什么没有？这套体系一共四件事：
- Prompt 版本化：从代码里抽出来，进 Git，变更走 PR；
- 黄金用例集：把分类边界场景固化成测试用例；
- 回归评测：用 promptfoo 这类工具批量跑用例、自动打分；
- 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 是资产不是文案 | 入 Git、文件名带版本号、变更走 PR + review |
| 用例集 | 把踩过的坑固化成断言 | 每个 bad case 回流成用例，边界题重点标注 |
| 回归评测 | 变更即评测 | promptfoo 批量跑，硬断言 + LLM 裁判结合 |
| 发布门禁 | 不达标不上线 | 通过率阈值卡 PR；上线走灰度 + 线上指标对比 |
两条工程纪律：一是"随手改 prompt"必须被工具链物理禁止——prompt 不在代码库里就管不住，靠自觉是不行的；二是门禁阈值宁严勿松，阈值从 95% 往下调需要有数据支撑，就像性能预算一样只紧不松。另外别忘了模型这一侧：模型版本升级（比如换新版模型）时，用同一套黄金用例集对新旧模型各跑一遍做对比评测，指标下降超阈值同样拦截——Prompt 和模型是锁在一起的一对变量，任何一个动了都要回归。
五、面试追问，你答得上来吗
- 用例集要跑几十上百条，每个 PR 都全量跑，又慢又烧 token，怎么办？——答：分层执行。PR 上跑 20~30 条核心冒烟集（可以用便宜的小模型），全量用例集每晚定时跑 + 发布前跑。门禁要的是"快速反馈 + 不放水"，不是每个 PR 都跑全套。
- Prompt 回归测试和传统接口回归有什么本质区别？——答：断言对象变了。接口回归断的是"输入输出契约"，结果确定；Prompt 回归断的是"行为契约"，要靠枚举硬断言 + 语义裁判 + 统计阈值（通过率、一致性率）组合判断，而且要接受"95% 通过"这种概率性结论。另外它多了个维度：同样的 prompt 换模型版本行为会变，回归必须覆盖"模型升级"这个触发条件。
- 怎么证明新 prompt 是"优化"而不是"拆东墙补西墙"？——答：看分场景的通过率变化，不只看总分。评测报告按用例标签（分类别、分场景）拆开对比新旧版本：总分涨了但某个核心场景掉了 10 个点，照样不能合——总分掩盖局部退化，是 prompt 优化里最常见的陷阱。
下一篇预告：《模型编造 API 参数，工具调用连环 500——Function Calling 契约测试》
