把 LLM 测试从"手摸"变成工程化——我试了 Promptfoo

调提示词这件事，我以前基本靠手感。改一版 prompt，手动跑几条用例，看着输出觉得"好像好点了"就上线。但LLM 输出有随机性，几条样本根本说明不了问题，而且上线后经常发现某些 corner case 还是翻车。

最近开始用 Promptfoo。它是一个开源的 LLM 测试与评估框架，也支持红队安全测试。我用它做了一个项目的 prompt 回归测试，效果比手动测好很多。今天聊聊这个工具。

一、Promptfoo 解决什么问题

简单说，它把软件工程里的测试驱动开发思想搬到了 LLM 应用上。

传统调 prompt 的问题：

手动测几条，主观判断 换模型、换提示词版本后没有回归基线 安全漏洞（提示注入、越狱、数据泄露）靠人工想，覆盖不全 不同模型之间没有系统对比

Promptfoo 的做法是：用声明式配置定义测试矩阵，自动运行、自动断言、生成对比报告。

YAML 配置文件├── prompts（待测提示词）├── providers（模型提供商）├── tests（测试用例）└── assertions（断言规则）│▼promptfoo eval 自动运行│▼生成 Web UI 报告 / CI 门禁

二、核心配置长什么样

Promptfoo 用 YAML 配置，结构很清晰。一个最小示例如下：

prompts:- "将以下文本分类为正面或负面：{ {text}}"- "判断这段评论的情感倾向（正面/负面）：{ {text}}"providers:- openai:gpt-4o- anthropic:claude-3-5-sonnettests:- vars:text: "这家餐厅太棒了"assert:- type: icontainsvalue: "正面"- vars:text: "服务态度很差"assert:- type: icontainsvalue: "负面"- vars:text: "一般吧，没什么特别的"assert:- type: answer-relevancethreshold: 0.7

这个配置会：

用两个提示词模板 跑两个模型 对三个测试用例分别断言 自动生成 2 × 3 = 6 组结果对比

三、断言机制是它的核心竞争力

Promptfoo 支持多种断言类型：

断言类型	用途
equals / contains / icontains	精确匹配、包含判断
answer-relevance	答案相关性
context-recall / context-faithfulness	RAG 评估
json-schema	校验输出 JSON 结构
javascript / python	自定义脚本验证
llm-rubric	用更强的模型当评委打分

最实用的是 llm-rubric。复杂业务场景下，规则很难写，可以让 GPT-4o 或 Claude 给输出打分，并说明理由。虽然成本高一点，但覆盖了大量人工难以枚举的情况。

四、多模型对比很实用

我同一个测试配置跑 GPT-4o、Claude 3.5 Sonnet 和本地 Ollama 模型，Promptfoo 会输出一张对比表：

模型	通过率	平均耗时	Token 消耗	成本
GPT-4o	95%	1.2s	12k	$0.18
Claude 3.5	92%	1.5s	14k	$0.21
Ollama llama3	78%	4.5s	18k	$0

这个表对选型很有帮助。有时候本地模型够便宜但质量差一点，有时候云端模型质量高但贵。用数据说话，比拍脑袋选型靠谱。

五、红队测试：不只是功能测试

Promptfoo 还有一个很强的能力：自动化红队测试。

它可以自动生成大量对抗性输入，测试你的应用是否存在：

提示词注入（Prompt Injection） 越狱攻击（Jailbreak） 敏感信息 / PII 泄露 有害内容生成 业务规则绕过 Agent 不安全工具调用

使用方式也很简单：

npx promptfoo@latest redteam setupnpx promptfoo redteam runnpx promptfoo redteam report

连接应用│▼生成上下文感知攻击│▼运行测试并识别漏洞│▼PR 中显示发现   修复建议│▼持续监控

这对要上线的 AI Agent 很重要——你自己想不到的攻击向量，Promptfoo 的社区威胁情报会帮你想到。

六、接进 CI/CD

Promptfoo 是 CLI 工具，接进 CI/CD 很自然。我把它配进 GitHub Actions：

name: LLM Evalon:pull_request:paths:- 'prompts/**'- 'promptfooconfig.yaml'jobs:eval:runs-on: ubuntu-lateststeps:- uses: actions/checkout@v4- run: npm install -g promptfoo- run: promptfoo eval --config promptfooconfig.yamlenv:OPENAI_API_KEY: ${ {secrets.OPENAI_API_KEY }}

这样每次改 prompt 都会自动跑测试，分数低于阈值就阻止合并。把提示词变更纳入代码质量门禁，这是真正的"测试即代码"。

七、Web UI 报告

跑完测试后，Promptfoo 会起一个本地网页：

promptfoo view

报告里能看到每个用例在每个模型上的输出、断言是否通过、token 消耗、耗时。失败用例可以点进去看完整输出和失败原因，排查很方便。

八、我的实际使用感受

适合的场景：

prompt 已经比较稳定，需要防止回归 多模型选型，需要量化对比 对安全性有要求，需要系统做红队测试 团队协作，需要把 prompt 测试纳入 CI 流程

不适合的场景：

还在快速迭代 prompt 的早期阶段，测试配置反而拖慢速度 完全不在乎成本和质量，只求快 没有可定义的期望输出，断言写不出来

最大的改变：

用了 Promptfoo 之后，我调 prompt 不再靠"感觉更好了"，而是看通过率有没有提升、哪个断言失败了、成本变化多少。这种量化反馈让提示词工程更像工程，而不是炼丹。

结语

Promptfoo 代表了一个趋势：LLM 应用正在从"写 prompt"走向"测试 prompt"。

当提示词成为生产系统的一部分，它就需要有单元测试、回归测试、安全测试。Promptfoo 把这套基础设施提供出来了，而且开源、可本地运行、能接 CI/CD。

如果你维护的 LLM 应用已经上线或准备上线，值得把它加进工具链。