用途：这是一份操作流程说明，指导如何为该仓库运行 Promptfoo 评估。每次评估涉及两个通过提供商 API 调用的角色：生成器（被测模型）与评判器（对每条 llm-rubric 断言打分的模型）。评估内容的撰写方法见 evals/README.md，本资料只讲运行步骤，需按阶段依次执行。
主要流程：
- 先做预算。确认生成器与评判器密钥已设置（只检查是否存在，命令形如 echo "generator: ${GROQ_API_KEY:+set}"，不读取密钥值），任一缺失即停止报告。生成器固定在 evals/prompts/lib/providers.yaml，评判器固定在 package.json 的 eval:graded 脚本；两者必须是不同模型。所有运行都通过 npm run eval:graded，不要手写 --grader、--delay、-j，也不要传 --providers。启动前查阅提供商限流文档并做一次带响应头的最小请求，估算令牌量（约字节数除以 4），预算不足则减少测试数而非加大延迟。串行运行，一次一个配置，命令之间留足每分钟窗口。
- 先写测试：从 evals/prompts/TEMPLATE.yaml 复制出 <skill>.yaml，在技能尚无内容时写显式、隐式、反模式、负面四类测试。
- 运行基线（--var injectSkill=false）。基线即通过的显式、隐式、反模式测试没有区分力，需重新设计。
- 只为基线失败的部分编写内容。
- 注入技能后再运行；基线失败且注入后通过才构成有效证据。
- 重试前先诊断，可用 pgrep、lsof、查看 ~/.promptfoo/promptfoo.db 等方式判断是在等待提供商还是已卡死；0 通过 0 失败属于无数据而非结果。读取 JSON 输出而非仅看 CSV。
- 明确何时需要重测：新增或修改断言、改写 rubric、固定模型变更时需要；仅改措辞、修链接、改错别字、迁移断言位置、删除模型已掌握的内容则不需要。
- 记录结果：每次运行同时写 CSV 与 JSON，结果表位于 evals/results/<skill>.md，需注明日期、生成器与评判器模型，并给出通过失败统计。
适用场景：为该仓库新增或维护技能评估时复用此流程。
限制：本资料以 Promptfoo 0.122 为准，固定版本变动后需重新核对；限流上限按账号而非进程计算，两个评分评估不可并行；速率限制失败且已正确限速无并发时说明容量耗尽，应停止等待重置时间，不要循环重试。资料未提供具体收费、价格或平台支持信息。