“我试的时候看起来不错”，这正是大多数提示词回归问题进入生产环境的方式。提示词测试与评估用证据取而代之：一组固定的输入、对正确输出的定义，以及每次提示词变更时都会运行的检查。
这两个术语有所重叠。评估是衡量一个提示词或其输出有多好。测试是自动运行这些度量，并在未达到阈值时失败。
你可以评估的两样东西
提示词本身。 就其写法而言，它是否清晰、完整、一致、安全？这是静态分析。它不需要调用模型，所以是即时的、免费的，而且每次结果都相同。
模型的输出。 给定这个提示词和这个输入，答案对吗？这需要调用模型，也需要一种判断结果的方法。
它们能发现不同的问题，好的流程两者并用。静态检查在每次按键和每次提交时运行。输出评估在某个变更可能影响行为时运行。
第 1 层：对提示词的静态检查
静态检查读取提示词文本，查找已知缺陷：
- 没有说明目标，或没有输出格式。
- 含糊的词语和没有数字的大小描述。
- 相互矛盾或重复的指令。
- 没有加分隔符的模板变量。
- 注入措辞、凭据或个人数据。
- token 数超出预算。
这就是 PromptFlowEngine 提示词评估所做的事。分数是 100 减去每个发现对应的固定扣分（严重 30、警告 10、提示 3），只要有严重问题，分数上限就是 50，八个维度中的每一个都采用相同的算法。由于公式是公开的，分数的任何变化都能追溯到某个具体发现。
静态分数并不告诉你模型的答案是否正确。它告诉你的是，提示词是否给了模型一个公平的机会。
第 2 层：测试集
测试集是带有预期的输入列表。从小处着手。
| 用例类型 | 原因 |
|---|---|
| 典型输入 | 确认主路径可用 |
| 边界情况 | 空输入、超长、语言错误、格式错误 |
| 对抗性输入 | 试图覆盖指令的尝试 |
| 过去的失败 | 发现的每个缺陷都变成永久性测试 |
精心挑选的二十个用例胜过两百个近似重复的用例。尽可能从真实流量中提取，并去除个人数据。
第 3 层：判断输出是否通过
使用能判断该属性的最便宜的方法。
代码断言。 确定性的，而且免费。尽可能使用。
- 能解析为 JSON 并符合 schema。
- 包含或不包含某个字符串。
- 长度在范围内。
- 标签等于预期标签。
- 数值答案在容差范围内。
与参考答案比较。 用精确匹配或相似度度量与已知的好答案比较。适合提取和分类，对开放式写作较弱。
模型评分。 由第二个模型按评分标准对输出做出判断。用于代码无法检查的特质：对来源的忠实度、语气、完整性。
You are grading an answer against a source document.
Does the answer contain any claim not supported by the source?
Reply with a JSON object: {"unsupported_claims": [string], "pass": boolean}.
<source>{{source}}</source>
<answer>{{answer}}</answer>
模型评分器本身也是提示词，有自己的失效模式。让每个评分标准只含一个问题，先要求给出证据再给出结论，并在信任评分器之前，用一批人工判断的样本检验它。
人工审阅。 参考标准，也是最昂贵的。用它来校准自动方法，并审阅生产输出的样本。
值得跟踪的指标
| 指标 | 它告诉你什么 |
|---|---|
| 通过率 | 满足预期的测试用例所占比例 |
| 格式有效率 | 能被解析的输出所占比例 |
| 忠实度 | 有所提供上下文支持的答案所占比例 |
| 拒答准确率 | 该拒绝的拒绝，该回答的回答 |
| 一致性 | 同一输入多次运行结果的一致程度 |
| token 与延迟 | 你所获得质量的成本 |
报告通过率时要同时给出用例数量。10 个用例上的“90%”就是一次失败。
处理非确定性
同样的提示词和输入可能产生不同的输出。要把这一点考虑进去：
- 对需要一致性的任务，把温度设低。
- 每个用例运行多次，报告通过率，而不是单次结果。
- 对属性做断言（“提到了退款期限”），而不是对确切文本做断言。
- 固定模型版本，并在其变化时重新运行测试套件。
CI 中的回归测试
只有自动运行，测试才能保护你。
每次提交时： 静态检查。它们很快，而且不需要 API 密钥。当某个提示词文件的分数低于最低要求、超过 token 上限，或包含诸如泄露密钥之类的严重发现时，提示词测试门禁会使拉取请求失败。
- run: promptflow check "prompts/**/*.md" --min-score 70 --max-tokens 1500
提示词或模型变更时： 带通过率阈值的输出测试集。
按计划定期： 针对线上模型运行完整测试集，以发现提供商一侧的变化。
PromptFlowEngine 涵盖其中的第一项。它不会针对模型运行提示词；输出评估需要你自己的测试运行器和模型访问权限。
比较两个版本
在几个草稿之间做选择时，用相同的输入进行比较，并查看发生了什么变化，而不只是总数：哪些用例从通过变成了失败，token 如何变化，是否引入了新问题。工作区中的比较视图会报告两个提示词之间在质量、token 和成本上的差异，并列出每个版本解决或引入的发现。
一个可以起步的最小流程
- 运行静态检查并修复警告。
- 编写 20 个带预期的测试用例。
- 为格式和必需内容添加代码断言。
- 记录基线通过率。
- 用静态检查来把关拉取请求。
- 每当提示词或模型变化时，重新运行测试集。