我用 20 条真实任务,给 AI 工具做了一次小体检

感谢朋友们点开今天的文章。

很多朋友们用 AI 工具时，出了问题才回头看。今天整理一份资料，明天换个模型，后天把提示词改了，过几天又发现同一个问题重新出现。每次都从头判断，时间久了，谁也说不清到底是哪次改动带来了影响。

今天先做一件很小的事，给自己的 AI 工具留一套固定考题。它不需要复杂平台，也不要求朋友们马上写代码。先从最近真实发生过的任务里挑出 20 到 50 条，记录原始输入、合格结果和容易出错的地方。

这类固定考题通常叫黄金评测集。OpenRouter 最近公开了一套从生产流量构建评测集的方法，我把它改成了可以马上动手的版本。

一、先别编题，去找已经发生过的任务

第一步先去找最近真实用过的记录，别停在桌前猜“AI 可能会遇到什么问题”。可以是客服问答、会议纪要、资料整理、代码修改，也可以是自己每天重复的表格工作。

先挑 20 到 50 条。这个数量足够让朋友们看到常见问题，又不会因为整理工作太重而放弃。挑选时不要只选顺利完成的任务，失败、返工、重新提问和用户投诉都要留下来。

如果手里暂时没有生产记录，可以先从过去一周的聊天记录、文档修改记录和人工返工内容里抽样。合成题可以补缺口，但不能把整份测试集都写成理想化的例子。

真实任务里的失败，比想象中的完美考题更能帮你找到工具的短板。

二、把相似问题合并，别让同一道题重复出现

收集完以后，第二步是去重和聚类。十条“帮我提取待办事项”的请求，可能只是不同会议的换皮题；另一组问题虽然文字相似，却都在考察日期、负责人和任务状态是否被保留。

朋友们可以先按任务目的分组，再按输入特点细分。比如资料问答可以分成信息明确、信息缺失、资料互相冲突三组。每组先留几条最能代表真实情况的样本，避免同一种简单题占满整份评测集。

分组的结果不必追求学术标准。只要能回答两个问题就够了。这几条题目到底在测同一件事吗，这组里有没有一个特别容易失败的样本。

整理时建议给每条记录加上来源、任务类型、难度和是否真实流量几个字段。以后出了问题，朋友们能知道失败来自哪类任务，回头补题也更方便。

评测集的价值不在题目多，而在每一道题都知道自己在测什么。

三、给每道题写出“什么算合格”

只有输入没有标准答案，测试很快会变成凭感觉打分。每道题至少补一份合格结果说明，可以是完整答案，也可以是检查清单。

比如一份会议纪要，合格标准可以写成四条。必须保留负责人，必须保留截止时间，不能把讨论意见写成最终决定，原文没有出现的数字不能补进去。

如果任务没有唯一答案，就写行为标准。资料摘要可以允许不同说法，但必须覆盖三个关键事实。代码解释可以有不同结构，但不能漏掉异常情况。图片分类可以允许少量边界争议，但敏感类别不能混淆。

标准写得越具体，后面越容易让两个人打出接近的分数。朋友们也可以拿五条样本先试评一次，看看自己是否会在同一个标准上反复犹豫，再把描述改清楚。

合格标准写在模型输出之前，评测才不会被漂亮的措辞带着走。

四、先做一轮人工评测，校准自己的尺子

第一轮不需要急着交给另一个模型评分。先自己看完五到十条输出，按照合格标准标记通过、需要修改和不通过，再记下具体原因。

原因要尽量写成事实。漏掉一个负责人，引用了输入中没有的金额，把三条建议写成两条，或者调用了不该调用的工具。这样的记录以后能直接变成回归用例。

如果有两位朋友一起评，先各自独立打分，再对照分歧。分歧最多的地方，通常说明标准还不够清楚。把争议处理完，再扩大到整套评测集。

LLM 裁判可以帮忙提速，但不要让被测试的模型给自己打分。高风险任务仍然要保留人工抽检，尤其是涉及隐私、财务、医疗和外部发送的场景。

评测标准要先经过人的手，自动评分才有可靠的起点。

五、把评测集保存成一个不会随手改掉的版本

整理完第一版后，给它一个日期和版本号，保存原始输入、合格标准、参考答案、评测结果和备注。哪怕朋友们暂时不用 Git，用一个只读文件夹和清楚的命名也比散落在聊天记录里好。

建议把生产数据里的姓名、电话、地址、订单号和内部链接先脱敏。黄金评测集会被反复复制和查看，里面混入真实隐私以后，后续共享和备份都会变麻烦。

每次修改提示词、模型、工具定义或检索设置，都先复制一份新版本，再跑同一套题。不要直接覆盖旧结果，否则出了回退很难找到是哪次改动造成的。

等这套流程稳定后，再把文件提交到 Git，并接入 CI 做自动回归。朋友们现在先完成版本保存，就已经迈过最容易被忽略的一步。

测试集只有留下版本，过去的结果才有机会为今天作证。

六、看四类结果，别只盯着一个总分

一轮评测结束后，至少看四类结果。任务是否完成，输出是否完整，是否遵守禁止项，是否需要人工返工。

如果是 Agent，还要单独记录工具调用。OpenRouter 的教程把工具调用失败拆成两类，一类是选错工具，另一类是参数传错。分开统计后，朋友们才能知道该改提示词、工具说明，还是参数校验。

同一套题可以拿来比较两个模型，也可以比较修改前后的提示词。重点看失败样本有没有减少，关键任务有没有回退，成本和耗时是否增加。平均分变高，却把一条高风险任务做错了，仍然不能算通过。

每次评测结束后，挑三条最有代表性的失败样本写进变更记录。下次再改时，先跑这三条，再跑完整评测集，速度会快很多。

总分只能告诉你变化，失败样本才能告诉你该改哪里。

七、从明天开始，把这套小测试放进 FDE 专项

今天的黄金评测集，解决的是“我怎么知道工具变好了”这个问题。明天开始的 FDE 专项，会继续往前走一步，讨论一个真实业务问题怎样被拆成可交付的 AI 方案。

到时我们会从需求判断开始，继续讲任务边界、数据权限、Agent 接入、原型验收、上线后的评测和使用推广。每一篇都会尽量落到一个朋友们能看懂、能复现、能拿去改造自己流程的动作上。

如果朋友们今天就想开始，可以先打开最近一周的 AI 使用记录，挑出 20 条真实任务，给每条补一句“什么算合格”。明天再回来看 FDE 怎样把这张小表，接到更完整的交付流程里。

好的 FDE 工作，从一张能复查的任务清单开始，而不是从一句宏大的愿景开始。

今日一句话

觉得今天内容还可以的，朋友们可以加个免费关注。

也欢迎朋友们一键三连，转发、点赞、在看。

没有君子不养艺人，王小胖靠一个免费关注继续写。