提示词也能回归测试：用 promptfoo 把提示词改动纳入 CI
提示词工程有个隐性痛点：它一直被当作文档，而不是代码。改一句系统提示、换一个 few-shot 示例，往往是「我觉得更顺了」就上线，没人知道这次改动是不是把某个边缘问题改坏了。promptfoo 要补的就是这个洞——它把提示词连同一组测试用例，变成一个能在命令行重复跑、能接进 CI 的评测脚本。 它怎么工作 写一个配置文件，列三件事：要测哪些提示词变体、一组输入样例、以及判定标准（正则包含、JSON 字段校验、或让另一个模型打分）。然后跑一行命令：npx promptfoo eval，它把每个提示词在每个样例上都跑一遍，输出一张对照表。 再用 npx promptfoo view 打开本地界面，就能并排看：旧提示词和新提示词，在这 50 个用例上分别答成什么样。 接进 CI 的价值 把这一步挂进 GitHub Actions：每次有人改提示词文件，自动跑评测，失败率上升超过阈值就拦住合并。提示词从此有了「测试套」——改坏了能立刻发现，而不是靠用户反馈。 判定标准别贪多。一开始只测硬指标：输出能不能被你的下游 JSON schema 解析、关键事实有没有出现。软的「答得好不好」交给人工抽检，否则你会陷入给模型打分的模型打分。 判断 2026 年做 AI 应用，提示词已经是生产代码的一部分。既然是代码，就该享受代码的待遇：版本控制、评审、回归测试。promptfoo 这类工具把「凭感觉改提示词」变成「带着测试改提示词」，这是从玩具走向产品的必经一步。 补充一个实践点：测试用例要从真实失败里积累。每次用户反馈答得不好，就把那个问题和期望答案补进 promptfoo 的用例库。半年下来，你的测试套就是一份「我们踩过的坑清单」，提示词改动再也不会重蹈覆辙，新成员接手也能一眼看懂这条提示词经历过什么。 提示词是生产代码，就该享受版本控制和回归测试的待遇。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：提示词测试