先说结论：拿 Promptfoo 和 Midjourney prompt 放一起比，本身是个层级错题。前者是给提示词写单元测试的工程框架，后者是描述一张画面的文案技巧，它俩不在同一个赛道上，谁也替代不了谁。
但我在把 Promptfoo 的官方文档逐条翻完之后，发现这个对比里有真东西——而且是真能用的那种。
关键在这里：Promptfoo 的模型评分断言 llm-rubric，官方文档明确写着它可以「Grade text, images, or audio against a rubric with a compatible model」，也就是能拿图片去评分；而它的 provider 列表里，fal.ai 下面挂着 ideogram/v3、recraft/v3/text-to-image、flux/dev 这些正经图像模型，ModelsLab、Novita、HuggingFace 也都在。也就是说，Midjourney 那种写提示词的路子，完全可以被搬进 Promptfoo 跑成一条可回归的测试流水线。
唯一的门槛在 Midjourney 自己身上：它至今没有官方 API。生成只有 Discord 机器人和中途上线的网页版两条人工路径，官方条款（2026 年 5 月 27 日生效那版）写得很直白，不允许用自动化工具访问服务。所以你没法把 Midjourney 直接塞进 Promptfoo 的 provider 里当被测对象。
这就是这篇要讲的事：提示词到底该按哪种方式管理。我用五个维度把这两种做法拆开对比，每一维都给出能落地的替代方案，而不是停在"你俩不是一个东西"这种废话上。
顺带一提，我做这个站的时候写过一篇 AI 提示词工程完全指南，那篇讲的是"怎么把提示词写好"。这篇讲的是完全另一件事——怎么保证你写好的提示词，明天还是好的。这两件事之间，隔着一个 Git 仓库。
维度一：能不能复现，决定你能不能发现退化
这是我认为最要命的一条差异，也是绝大多数人踩坑的地方。
你在 Midjourney 里写了一条提示词，出了张满意的图。三个月后你想复现它——大概率复现不出来。原因很朴素：Midjourney 每次重抽都是新的随机过程，同一条提示词会给你完全不同的构图、不同的光线、不同的手部细节。
而且这事儿在 2026 年尤其折磨人，因为 Midjourney 的版本自己就在动。我查了官方版本文档，当前默认模型是 V8.2（2026 年 7 月 24 日上线），在它之前是 V8.1（2026 年 4 月 14 日上线，6 月 10 日到 7 月 23 日当默认），再往前是 V7（2025 年 4 月 3 日）和 V6.1（2024 年 7 月 30 日）。V8.1 把 --seed 参数还回来了，而且确实可复现——同一条 prompt 加同一个 seed，出图接近一致。这是好事，但它只对 V8.1 有效，而且它解决的是"同一版本内的复现"，解决不了"三个月后模型升级了还能不能出这张图"。
Promptfoo 这边，seed 是 provider 配置里的一等公民。fal.ai 的 provider 我查了官方页面，配置项里 seed、guidance_scale、num_inference_steps、image_size.width/height 全是明写的字段。同时 Promptfoo 还有一层缓存兜底：默认把成功的响应存在 ~/.promptfoo/cache，TTL 默认 14 天，可以设 PROMPTFOO_CACHE_TYPE 和 PROMPTFOO_CACHE_PATH，也可以用 --no-cache 关掉。
这意味着你可以这么干：先把当前版本的提示词跑出一份基线存进 Git，然后换模型、改提示词、调参数，再跑一次，两次结果直接并排比。哪天发现"上周还 92% 通过的用例这周掉到 71%"，你能精确定位到是哪次改动干的。
这一点在 Midjourney 侧基本是无解的。不是工具不好，是它的产品形态决定的：官方刻意不提供程序化接口，你连"批量跑 50 条提示词"这个动作都做不到。
维度二：谁来判定"好"，决定你能不能规模化
Midjourney prompt 的判定方式只有一种：人眼看。这其实完全说得通——画面的美感本来就没有标准答案。你在 Discord 里盯着四张图选一张，这个动作本身是有价值的，因为审美判断需要人。
Promptfoo 的判定方式分两层，这是它的全部意义所在。
第一层是确定性断言，纯本地计算，零额外成本，同一份输出永远同一个结果。官方文档列了三十多种，我挑几个你做图像任务真的会用到的：
contains/contains-any/contains-all—— 输出里必须出现某些词。用来锁提示词里的风格关键词有没有被模型吃掉is-json/contains-json—— 输出必须是合法 JSON，还能挂 JSON Schema。用来校验结构化抽取is-html/is-xml—— 格式合法性javascript/python/ruby—— 你自己写任意校验逻辑，这是最灵活的一档cost/latency—— 单次调用的花费和耗时阈值is-refusal—— 模型是不是拒绝了这次请求
第二层是模型辅助断言，要多烧一次模型调用，但能处理"没有唯一正确答案"的情况：similar（嵌入向量余弦相似度）、llm-rubric（按自然语言评分标准打分）、g-eval（带思维链的评分，稳定性比直接打分好）、factuality、answer-relevance，RAG 场景还有 context-faithfulness、context-recall、context-relevance。
回到图像。官方 llm-rubric 那行字写的是「Grade text, images, or audio against a rubric with a compatible model」。也就是说，你可以让一个多模态模型拿着评分标准，直接看生成的图片打通过或不通过。比如这一条：
assert:
- type: llm-rubric
value: |
判断这张图是否满足：主体是穿半透明雨衣的女性；
场景是夜晚雨后的赛博朋克街道；
地面有霓虹倒影。三条缺任意一条即不通过。
metric: "画面还原度"我实测下来的体感是：llm-rubric 在图像上好用，但有个前提常被忽略——judge 模型必须自己支持视觉输入。你拿一个纯文本模型去判图，它会开始编。官方文档在 provider 字段上给了口子，你可以给断言单独指定 judge provider，别用被测模型自己判自己。
还有个工程细节我觉得比断言类型本身更值钱：加权。每条断言都能带 weight，用例还能带 threshold，最终分是加权平均。比如格式校验权重 2、画面还原权重 3、风格一致权重 1——格式错一次比风格偏一点严重得多，这个业务判断直接编码进配置，不用每次开会吵。
另外还有个 assert-set，可以把一组断言打包并设阈值，比如"4 条里过 3 条算过"。这个在画风类任务上特别好用，因为画风本来就是连续谱，卡太死会误杀。
维度三：能不能进 CI，决定你能不能拦住事故
这一维是 Promptfoo 跟 Midjourney prompt 差距最大、也最没法绕过去的一条。
Promptfoo 的 CI 集成是官方一等公民。命令行参考里写明：promptfoo eval 在有测试失败或通过率低于 PROMPTFOO_PASS_RATE_THRESHOLD 时返回退出码 100，其他错误返回 1，失败退出码还能用 PROMPTFOO_FAILED_TEST_EXIT_CODE 改。阈值默认是 100，也就是一个都不许挂。
输出格式支持 JSON、JSONL、CSV、YAML、HTML、完整 XML 和精简 JUnit XML——精简 JUnit 那份是故意不塞原始 prompt 和完整输出的，就是为了不让 CI 面板变成第二个全量导出面。
还有 GitHub Action（promptfoo/promptfoo-action），改动 prompt 相关目录时自动跑，并在 PR 上贴结果评论和矩阵视图链接，低于阈值直接卡住合并。
反过来看 Midjourney 这边，不是"接入麻烦"，是根本进不去。官方没有 API、官方条款禁止自动化访问，任何第三方"Midjourney API"都是拿一堆消费级账号去驱动 Discord 或网页自动化。我查了 2026 年这批服务的变化：ApiFrame 还在跑，GoAPI 和 PiAPI 都已经退出 Midjourney 这个品类转去做别的了。剩下能自建的方案，风险是自己扛：账号封禁、浏览器集群维护、条款风险全在你头上。
所以真正能落地的做法是：把 Midjourney 当"人工创意车道"，把有官方 API 的图像模型当"自动化回归车道"。你用 Promptfoo 跑的是后者，用 Midjourney 出的是前者。两条道用同一套断言标准，审美标准就统一了。
维度四：成本结构，两边算的都不是一种账
Midjourney 是订阅制，按 fast GPU 时间计费。基础档 $10/月含 3.3 小时（200 分钟）fast GPU，标准档 $30/月 15 小时，Pro $60/月 30 小时，Mega $120/月 60 小时。官方版本文档给的换算是：V8.1 一张标准图 0.8 GPU 分钟，2K HD 图 1.3 分钟——照这个算，$10 的基础档一个月大概能出 250 张标准图。年付是 20% 折扣，另外加购 fast GPU 时间一律 $4/小时。
几个容易忽略的门槛：Stealth 模式（不公开生成）只有 Pro 和 Mega 有；年营收超过 100 万美元的公司，必须上 Pro 或 Mega 才能拥有自己生成的图的版权。这两条不是促销细节，是合规问题。
Promptfoo 这边，软件本身一分钱不花——MIT 协议，核心跑在你本机，数据不出你的网络（本地跑的时候）。但模型调用要钱，而且这里有个真实的坑：矩阵是笛卡尔积。3 个 prompt × 4 个 provider × 50 个 test case = 600 次调用。你要是再给每条断言配 llm-rubric，judge 调用再翻一倍。
我给的解法是三条：先用 1 prompt × 1 provider 把断言调对，再扩维度；用 --max-concurrency 限并发，别把 provider 的速率限制撞穿；CI 里 PR 只跑 smoke 集，全量放 nightly。
还有个便宜的省钱点：缓存。改一条 prompt 只重跑受影响的分支，这个在迭代调参阶段省的钱最多。
维度五：资产能不能留痕，决定你三个月后还在不在
最后这维最不起眼，但对长期最要命。
你的 Midjourney prompt 现在存在哪儿？在 Discord 的聊天记录里，在某个文档的表格里，在某个人的浏览器书签里。很多人的做法是拿 Notion 之类的 AI 笔记存着，图省事——但笔记是给人看的，测试是给机器跑的，这中间隔着一道鸿沟。笔记没有版本、没有评审记录、没有 diff、没有 owner，同事改了一条你不知道改了什么；模型升级了出图变了，没人说得清是哪一步导致的。
Promptfoo 的配置是 promptfooconfig.yaml，进 Git，走 code review，改动有 diff。官方文档里那套目录结构建议（按 feature 分目录、prompt 和测试数据分文件、providers.yaml 提到上层共享）不是审美偏好，是为了让「和业务逻辑一起改的东西放在一起」，让 diff 读起来有意义。
官方还提供 assertionTemplates 和 $ref 引用，让公共断言写一次就能到处复用，不用复制粘贴五十遍。
还有个我觉得被低估的功能：named metrics 和 derived metrics。给每条断言打上 metric: "画面还原度" 这样的标签，UI 里就能按指标聚合看；然后用 derivedMetrics 写公式，比如 '还原度 * 0.6 + 一致性 * 0.4'，直接算出综合分。这比"看 47 条用例有多少条过了"要有用得多，因为后者会让你在 200 条低风险改写里把 1 条授权失败淹掉。
我实测给你的一套能跑的配置
上面五维讲完，给个真能复制走的。我选 ideogram v3 当 provider，因为它的强项是图内文字和 logo 生成——这是最接近"你为什么要写精细提示词"的场景；recraft/v3/text-to-image 做矢量风格，flux/dev 做通用画质对照。
# promptfooconfig.yaml
description: "图像提示词回归测试"
prompts:
- id: file://prompts/cyberpunk-portrait.txt
label: "赛博朋克人像 v1"
- id: file://prompts/cyberpunk-portrait-v2.txt
label: "赛博朋克人像 v2（加了雨衣质感）"
providers:
- id: fal:image:fal-ai/ideogram/v3
label: "ideogram v3"
config:
image_size:
width: 1024
height: 1024
seed: 42
- id: fal:image:fal-ai/flux/dev
label: "flux dev"
config:
num_inference_steps: 28
guidance_scale: 7.5
seed: 42
defaultTest:
assert:
- type: llm-rubric
value: |
画面必须是夜晚雨后的赛博朋克街道，
主体为女性半身像，有霓虹反射光。
metric: "场景还原度"
weight: 2
- type: cost
threshold: 0.05
tests:
- description: "标准版"
vars:
subject: "a woman in a translucent raincoat"
mood: "cyberpunk street at night, wet asphalt, neon reflections"
assert:
- type: llm-rubric
value: "必须能看清雨衣的半透明质感，不能是普通外套"
metric: "材质还原度"
- description: "极端场景"
vars:
subject: "a man in a hooded jacket"
mood: "cyberpunk street at night, wet asphalt, neon reflections"
assert:
- type: llm-rubric
value: "画面必须包含男性主体，若生成成女性则不通过"
metric: "主体一致性"跑起来：
export FAL_KEY=your_key
npx promptfoo@latest eval
npx promptfoo@latest viewview 起本地 web 界面，行是 test case，列是 prompt × provider 的组合，每格显示完整输出、断言结果、token 数、延迟和花费，并且能对比历史多次运行。你要找的"哪一次改动搞坏了哪条用例"，就在这个矩阵里。
进 CI 就三行：
export PROMPTFOO_PASS_RATE_THRESHOLD=90
npx promptfoo@latest eval --output results.json --output results.junit.xml
# 退出码非 0 就挡住合并还有一条我特别想推荐的用法：promptfoo eval --assertions asserts.yaml --model-outputs outputs.json。它能直接对已有的输出跑断言，不重新调模型。你手里已经有一批跑好的图和提示词对，想先看看有多少条能过质量线，不用重新烧一遍生图的钱。
我踩过的四个坑
坑一：矩阵爆炸等于账单爆炸。 上面那个例子，2 个 prompt × 2 个 provider × 2 个 test case = 8 次生图调用，judge 再翻一倍。我第一次跑的时候没算，直接把 provider 铺到 4 个、用例给了 50 条，一晚上烧掉的钱够买好几年 Midjourney 基础档。永远从最小矩阵开始——1 prompt × 1 provider × 3 用例，先把断言调对。
坑二：judge 模型抖动伪装成回归。 llm-rubric 的评分来自另一个模型，它自己也会漂。你今天用 A 模型判、明天用 B 模型判，那"分数变化"里混着 judge 变化，根本分不清是提示词退化了还是评判标准变了。把 judge 固定死，换 judge 就重新打基线。另外对非确定性场景，用 --repeat 让同一用例跑 N 次看通过率，而不是看单次结果下结论。
坑三：缓存让你以为线上没问题。 缓存 14 天 TTL 是个好东西，但如果你要检测漂移、复现线上事故，就得用 --no-cache 走真实调用。可复现的历史输出，不等于当前还能复现。
坑四：provider 会退役。 这个坑我是在官方 providers 文档里亲眼看到的——GitHub Models provider 已于 2026 年 7 月 30 日退役，推理 API 不可用，官方把这条单列在 "Retired providers" 章节。你配好的 YAML 哪天某个 provider 下线了，报错会很突然。关键配置别把命脉交给一个 provider，多备一条 fallback。
所以，什么时候该用哪个
我把这五维拉通之后，自己的判断是这样的：
如果你只是要出一张好看的图，Midjourney 仍然是最好的选择之一，它的画面质感、编辑工具链（inpainting、pan/zoom、Omni Reference）和订阅性价比都很难被替代。别为了"工程化"把创作流程搞复杂，那是本末倒置。我站内这篇 Midjourney V8 prompt 模板指南可以当提示词写法参考。
如果你要跑批量、要在 CI 里拦住退化、要让提示词成为团队资产，那就必须走 Promptfoo 这条路，而且被测对象得换成有官方 API 的图像模型。这条路上可选的 provider 其实相当多：fal.ai 下面的 ideogram、recraft、flux、sana（4K）、bagel（7B 多模态），加上 ModelsLab、Novita、HuggingFace，还有 Replicate、OpenAI 图像这些。想要中文文案渲染，ideogram 和 recraft 是首选；想要本地跑、prompt 和数据完全不出机器，HuggingFace 系加 Ollama 那条路我在这篇 SDXL 30 天实测里详细写过。
如果你已经用 AI 笔记存了一堆 Midjourney 提示词，其实不用推倒重来。第一步只做一件事：把笔记里最常用的那 5 条掏出来，改写成 YAML 里的 5 个 test case，配上最便宜的确定性断言（contains 锁关键词、cost 锁预算），先跑通一次。这个动作花不了半小时，但它会立刻让你发现哪几条提示词其实结构是重复的、可以合并——这一步的收益往往比上 CI 还大。
如果你是团队里有几十条提示词在跑，那 Promptfoo 的 CI 门禁基本是必需品了。这块我建议直接看 100 个实战 prompt 示例和 提示词工程完全指南打底，再把断言接上去。工具是最后一步，判定标准要先有。
一句总结
Midjourney prompt 是手艺——你靠审美和迭代把画面调出来，效果好不好当场就知道，但过程留不下痕迹。Promptfoo 是工程——你把提示词当成代码，写断言、写用例、跑矩阵、卡 CI，效果好不好由事先定义的标准说了算，过程全在 Git 里。
所以最后那句反直觉的话是：如果你还在凭感觉判断提示词好不好，你就已经在用 Promptfoo 的方式思考了，只是还没有把它写下来。
顺便交代一个 2026 年的行业动向：OpenAI 正在关停自己的 Evals 平台（2026 年 6 月 3 日官宣，10 月 31 日转只读，11 月 30 日彻底下线），官方迁移指南推荐的去处正是 Promptfoo。同时 OpenAI 在 3 月 9 日宣布收购了 Promptfoo ——它会并进 OpenAI Frontier 平台，MIT 协议和开源路线继续保留，团队整体加入。所以如果你正在选一个评测框架，这不是个小众工具了，它是 OpenAI 官方指定的那个。
上面这些是我 2026 年 11 月初查官方文档核出来的现状。Promptfoo 的版本号我核到的是 npm 上的 0.125.1，GitHub 星数 2.6 万+。版本迭代很快，你真正上手前，请以 promptfoo.dev/docs 当天显示的为准。