同一个 AI，今天回答很顺，明天却漏掉关键信息；换了一版提示词，示例看起来更漂亮，实际使用反而不稳定。问题往往在于：我们只挑了一次满意的回答，没有建立一套固定的验收方法。
本文面向使用 AI 整理资料、提取信息和生成工作草稿的普通用户，介绍如何用 10 条小样本建立任务评测集，再比较两版提示词的表现。练习只需要一个能正常使用的对话工具和记录文件，不必部署评测平台。最终交付是一份可复查的测试清单、评分规则和失败记录，本文中的结果数字均为计算示例，没有冒充真实模型测试。
一、评测的对象必须是具体任务
“这个模型聪不聪明”很难直接验收；“能否从一段订单说明中提取日期、数量和待确认项”则可以检查。评测应先固定任务、输入范围和输出用途，才有办法定义成功。
Google 的生成式 AI 评测官方文档强调围绕自己的使用场景建立数据集、定义指标、生成回答并分析结果。通用榜单能提供背景，但不能代替你的业务样例。本文采用的是可手工执行的入门方法，不要求开通 Google 云服务，也不声称复现其平台评测实现。
评测也不同于演示。演示展示工具能完成什么；评测还要主动找它在哪些情况下做不好。失败样例不是应当删掉的“坏截图”，而是下一次改进的依据。
二、准备一个小而完整的任务
本例任务是把一段虚构的物料需求说明整理成四个字段：物料名称、数量、需要日期、待确认事项。输出用四行文本即可，重点是信息准确，不把 JSON 格式问题混进首次练习。
准备一份任务约定：
仅依据提供的需求说明提取信息。
输出四行：物料、数量、需要日期、待确认事项。
未提供的内容写“未说明”。
有冲突的信息列入待确认事项，不自行选一个答案。
计划、估计和已确认状态必须区分。
不要补充采购建议，不执行下单或通知。在测试前保存这份原文，给它标记版本 A。后续修改就另存版本 B，不覆盖 A。还要记下模型名称、可见版本、参数和测试日期；界面没有显示的项目写“未提供”，不要靠猜测填满记录。
所有输入都用虚构数据。首次评测没必要拿真实订单、客户姓名或合同测试，更不应为了比较答案而把同一份敏感资料上传到多个服务。
三、设计十条有差异的测试样例
不要把同一句话改十个物料名称当成十种场景。下面这组教学设计有意覆盖正常、缺失、冲突和表达变化。每一条都应提前写好预期，而不是看完模型答案才临时改标准。
- 完整信息：“需要蓝色标签 20 张，12 月 10 日使用，无其他要求。”预期四字段完整，数量为 20 张。
- 缺少数量：“需要蓝色标签，12 月 10 日使用。”预期数量未说明，不能沿用上条的 20 张。
- 缺少日期：“准备 20 张蓝色标签。”预期日期未说明，不能默认明天。
- 冲突数量：“初稿写 20 张，备注写 30 张，尚未确认。”预期保留冲突并列为待确认，不能擅选 30。
- 单位变化：“准备 2 包标签，每包 10 张。”预期保留 2 包及每包 10 张；若换算 20 张，也必须保留换算依据。
- 计划语气：“暂定需要 20 张，最终数量等确认。”预期标明暂定，而不是写成已确认采购量。
- 多个物料：“蓝色标签 20 张，红色标签 10 张，均在 12 月 10 日使用。”预期分别对应，不能把数量合并成一个物料。
- 无关背景：“上次活动用了 50 张；这次只需要蓝色标签 20 张。”预期不把历史数量当本次需求。
- 表达变化：“十二月十日之前备好二十张蓝色标签。”预期理解中文数字，但不把“之前”改成明确当天送达承诺。
- 完全无有效需求：“这条消息只是讨论活动想法，没有物料安排。”预期说明未提供物料需求，不编出常见用品。
这一小组用于学习，不是通用行业基准。真实使用时，应根据经许可的实际任务增加样例，特别是你已经遇到的失败类型。某一类风险出现频率高，就单独记录该类表现，避免被大量简单题掩盖。
四、把评分规则写成可观察条件
本例对每条回答检查三项，每项通过记 1，不通过记 0：
- 事实对应：物料、数量、日期与输入一致，多物料不串行，换算有依据。
- 缺失与冲突处理：未知不补齐，冲突不擅选，暂定状态不变成确认。
- 任务范围：完成四行信息整理，不额外宣称下单、审批或发送通知。
某些样例没有缺失或冲突，此项检查的是“没有制造额外冲突、没有错误添加待确认”。如果你希望采用不适用标记，应在测试前规定，并在计算时从对应分母排除；不要测试后为了提高成绩选择性剔除。
同时定义一条整例通过规则：三项全部通过，这条样例才记为通过。这样既能看总体，也能知道问题集中在哪一维。字段准确率与整例通过率不是同一个数字，不能混着宣传。
“语气专业”“读起来好看”可以另列为辅助评价，但不应抵消关键事实错误。数量错了，不能因为表达流畅就判定整体成功。
五、怎样执行，才能公平比较
先用版本 A 跑完整组，保留全部输入和回答。独立样例使用新对话，防止前一条的数量、日期或解释泄漏到后一条。如果你的真实产品本来是多轮对话，再额外建立多轮测试，不把两种测试混在一起。
接着只改变提示词中一个明确问题，形成 B。例如针对第 4 条增加“数量冲突时保留双方原值并写明待确认”。不要同时换模型、删字段、加联网，再把差异都归功于提示词优化。
让 B 使用同一组输入、同样的测试顺序与环境约束。为了减少先入为主，可以把回答标成 X、Y 后再评分，评分完成后揭示哪个是 A、哪个是 B。小团队可以由第二个人抽查有争议的样例。
模型输出可能波动。有余力时，每个版本每条样例独立运行 3 次，保存每次回答；不要只留下其中最好的一次。重复运行仍受同一组小样本限制，不能把 30 次记录说成覆盖了 30 种不同场景。
六、读懂分数，别只看一个百分比
假设一轮 10 条样例中有 8 条完全通过，整例通过率是 8÷10＝80%。这是算术示例，不代表本文测试过某个模型。
如果三项维度合计通过了 27 项，总共有 10×3＝30 项，维度通过比例是 90%。它看起来比 80% 高，但并不矛盾：一条回答可以只错一项，却仍不满足整例通过要求。
当每条跑 3 次时，报告应写“10 条独立样例、每条 3 次、共 30 次执行”。可以记录每条是 3 次全过、2 次过还是 0 次过。那些偶尔失败的样例，比单次最优回答更能提醒你上线时的稳定性风险。
不要因为 10 条样例全部通过，就承诺生产环境 100% 正确。 样本可能太少、太容易或与真实输入不同。成本、等待时间、隐私限制也要单独考虑，不能只靠准确性决定是否使用。
七、失败记录如何变成下一步改进
给每条失败记录五项：样例编号、错误原句、违反哪条标准、可能原因、下一次改动。原因只是待验证假设，不要把猜测当成结论。
例如样例 8 把 50 张写成当前需求，可以先怀疑“历史与当前的区分不明确”，再增加针对时间范围的说明。修改后重跑整组，不只重跑样例 8；有时一个补丁会让正常例子变差，这叫回归。
如果多物料始终错配，可以把任务拆成“先识别物料条目，再逐项提取”。这属于改变流程，应另标新版本，不和仅修改语气的版本混为一谈。
还应留出几条没有参与调试的新样例。开发时反复用的题很容易让你过度优化，保留测试能帮助检查规则是否能处理新的表达。样本少时更应如实标明探索性结果，避免假装有统计结论。
八、什么时候才需要自动化评测
当样例多、修改频繁、多个版本要持续比较时，再考虑批量调用和自动评分。能确定核验的字段可写程序检查；开放式表达可使用明确量表与人工复核。让另一个模型评分也需要校准，不能因为它被称为“评委”就默认判断正确。
Google 官方文档区分基于评分规则的方法与确定性计算指标。实际选择取决于任务：提取数量和日期可以更多使用确定性核对；长文可读性难以只靠字符串匹配。本文不提供云平台调用代码，也没有产生付费 API 请求。
常见错误可以按顺序排查：结果忽高忽低时检查会话污染与重复次数；B 突然大幅提升时检查是否更换了输入或评分标准；分数很好但实际不好用时补真实场景与失败分组；评分者意见不一致时给边界案例写更清楚的判例。
先把任务、样例、规则和记录保存下来，评测就已经开始发挥作用。后续每次修改都能回答一个具体问题：这次究竟改善了什么，又有没有引入新的错误。
还没有公开评论，欢迎分享你的想法。