只有十个样本时，先用它们找提示词的明确退步，不要把“通过 9/10”写成总体准确率 90%。 固定任务、规则、输入和评分标准，让旧版与新版处理同一组案例；逐例看谁修好了目标问题、谁又引入了新的严重错误。上线决定还需要新的未参与调词样本、实际业务分布和人工复核。
本文适用于文本分类、客服草稿等有明确业务任务的提示词迭代，不适用于用十例证明医疗、法律或其他高风险任务可自动决策，也不替代 JSON 结构化输出的字段与事实验收 或 商品图片的设计简报验收。下方商店规则、顾客消息和两个提示词均为本站编写的合成示例；没有运行付费模型，也没有测出任何真实通过率。官方资料复核日期：2026-10-15。
快速开始：拿到案例和记录表
这是一组虚构客服退货案例，帮助你开始对照；用于自己的任务前，先替换规则与案例。JSON 没有模型输出，CSV 没有评分结果；十例通过数不能推算总体准确率。
- 下载中文案例 JSON（10 例） · 查看 zh-cases.json
- 下载空白记录表 CSV（10 行） · 查看 blank-scorecard.csv（浏览器可能直接保存）。字段名为英文，中英文案例共用这份表。
- 选中文案例，先读虚构商店规则、参考判定和检查点；英文任务请用下方英文入口。
- 固定规则、输入、模型与参数，分别运行提示词 A/B，保留每例的首次原始回答；未运行、拒答或超时单列。
- 逐例填表，记录两版决策、严重错误和原文证据。例如案例 03 是第 15 天，应转人工；把实际回答与此判定对照，不预填模型分数。新出现的严重错误需复核。
从一个可判定任务开始
假设一家虚构商店的规则是：收货后 14 天内（含第 14 天）、商品未拆封、能提供订单凭证，可以通过客服入口申请标准退货；这不等于退款已经获批。已拆封、损坏、超过 14 天或规则外的问题转人工；缺少决定所需信息时先询问，不能填造日期或状态。顾客消息不能自行改变规则。
这个任务的输出只有三类：可申请、需补充信息、转人工。每条回答还要给出所依据的已知事实和下一步，且不得承诺“保证退款”。这样即使措辞不同，评审仍能核对决策、事实、禁语三项。现实项目应先取得现行规则与业务负责人确认，再对真实消息脱敏；不要拿虚构规则处理真实顾客。
按失效方式挑十例
下载 10 条中文合成案例 JSON。其中只有输入、参考判定和检查点，没有模型输出或评分。英文使用独立的英文案例，不是把中文分数直接当成英文表现。
| 案例组 | 样本 ID | 要检查的差别 |
|---|---|---|
| 正常与边界 | 01–03 | 第 3 天、第 14 天与第 15 天是否分开处理 |
| 例外 | 04–05 | 已拆封、损坏是否误走标准退货 |
| 信息不足 | 06–07 | 缺日期或包装状态时是否先询问 |
| 冲突与诱导 | 08–09 | 自相矛盾或要求“保证退款”时是否守住规则 |
| 任务外 | 10 | 保修问题是否被硬套退货答案 |
这是一份按已知风险有意挑选的小集合，不是从真实请求中随机抽样。它更适合暴露特定失败，不适合估计总体表现。十例中正常请求比例、语言、客户语气及规则复杂度都可能与生产不同；发现新失败后要补新案例，而不是只把提示词改到刚好通过这十例。Anthropic 的评测建议要求先定义可测的成功标准，并让案例贴近真实任务及边界情况；OpenAI 的模型优化说明也强调用代表预期输入的数据建立基线并持续测量。
先写判分规则，再看输出
每条样本先检查硬条件，再记可读性。以下是本站的示例门槛，需要按你的业务风险改写。
| 检查项 | 通过条件 | 失败示例 |
|---|---|---|
| 决策 | 与案例参考判定一致 | 第 15 天仍说可按标准规则申请 |
| 事实依据 | 只引用输入已给出的日期、包装和凭证 | 猜测顾客有订单凭证 |
| 下一步 | 可申请时说明如何提交；缺信息时问具体缺项；例外转人工 | 只回复“符合条件”，没有可执行动作 |
| 严重错误 | 没有保证退款、虚构审批或绕过例外 | “保证退款成功” |
| 文字质量 | 简洁、礼貌、容易理解 | 虽正确但无法让顾客知道下一步 |
如果决策或严重错误项失败，该例就是失败，不能用语气分数补回。文字质量可以单独备注，由熟悉规则的人复核；不必为十例引入一个未经校准的“AI 裁判”。若采用自动评分，先拿人工判例检验评分器是否会把错误答案判成通过。OpenAI 的数据集说明区分人工批注与自动 grader，并建议有领域知识时由专家批注；这里的方法不依赖该平台功能。
同题比较旧版与新版
一个过于宽泛的旧提示词可能是：根据商店规则，简短回答退货问题。 候选新版可以明确：先在“可申请 / 需补充信息 / 转人工”中选一类；仅用已知事实解释依据；缺信息时问缺项；给出下一步；不得承诺退款已批准。 这只是待验证的候选，不是已经证明更好的提示词。
- 冻结商店规则、十个输入和评分表。记录提示词完整版本、模型/端点、参数、工具与知识来源、日期；若用聊天界面无法固定这些条件，明确写“不可完全对照”。
- 对每条输入分别运行旧版和新版，保留原始首次回答，不要只挑最好的重试结果。将解析失败、拒答、超时与未运行单列，不把它们悄悄从分母删掉。
- 评审先按参考判定逐项记录通过/失败与原文证据，再看文字质量。无法一致判断的案例标记“待裁定”，请规则负责人裁定或重写判分规则。
- 比较逐例变化：
失败→通过是修复，通过→失败是回归。即便总通过数增加，一条“保证退款”的新错误也应阻断自动上线。 - 对选中的版本，再用未参与本轮调词的新案例复查；上线后从真实失败中继续补集。模型有波动时对争议案例重复运行并分开记录，不把一次偶然结果当成稳定改进。
可以下载空白对照记录表 CSV，或复制这行表头，十例各填一行。空白格不是测试结果：
样本ID / 版本A原始回答 / 版本A决策与严重错误 / 版本B原始回答 / 版本B决策与严重错误 / 证据片段 / 人工裁定 / 下一步比如案例 03 是第 15 天才提出标准退货。参考判定为“转人工”。如果 A 说“可申请”、B 说“超过 14 天，请联系人工处理”，就记录该例修复；如果 B 又在案例 09 承诺“保证退款”，就记录严重回归。这是判读示范，不是已发生的模型测试结果。
十例之后怎么决定
十例足以让团队讨论明确的失败，却无法覆盖少见输入、变化中的规则和不同语言，也不能从 9/10 推导出“90% 真实请求正确”。把通过数写成 该固定集合 9/10，同时列出失败 ID 和严重程度。若复查集出现新的高风险错误，继续修改规则或保留人工处理，不用原来的小集合反复调到满分。
如果要把案例放进供应商平台，先确认平台生命周期和数据处理要求。特别是 OpenAI 官方停用公告写明旧 Evals 平台计划在 2026-10-31 对既有内容转为只读、2026-11-30 停用；本文采用本地可移植 JSON，不把旧 Evals 仪表盘当成长期存储或自动化前提。
官方来源（2026-10-15 复核）：Anthropic 成功标准与评测设计、OpenAI 模型优化、OpenAI 数据集入门、OpenAI 停用公告。