调提示词这件事，我以前基本靠手感。改一版 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-sonnet
tests:
- vars:
text: "这家餐厅太棒了"
assert:
- type: icontains
value: "正面"
- vars:
text: "服务态度很差"
assert:
- type: icontains
value: "负面"
- vars:
text: "一般吧，没什么特别的"
assert:
- type: answer-relevance
threshold: 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 setup
npx promptfoo redteam run
npx promptfoo redteam report
连接应用
│
▼
生成上下文感知攻击
│
▼
运行测试并识别漏洞
│
▼
PR 中显示发现 + 修复建议
│
▼
持续监控
这对要上线的 AI Agent 很重要——你自己想不到的攻击向量，Promptfoo 的社区威胁情报会帮你想到。
六、接进 CI/CD
Promptfoo 是 CLI 工具，接进 CI/CD 很自然。我把它配进 GitHub Actions：
name: LLM Eval
on:
pull_request:
paths:
- 'prompts/**'
- 'promptfooconfig.yaml'
jobs:
eval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install -g promptfoo
- run: promptfoo eval --config promptfooconfig.yaml
env:
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 应用已经上线或准备上线，值得把它加进工具链。
