搭你的第一个评测集
改动前后跑分对比演示；三档任务：攒十条真实用例、写通过标准跑基线、用分数说话
本页解决的问题
先给结论「搭你的第一个评测集」要解决的关键问题是什么？
改动前后跑分对比演示；三档任务：攒十条真实用例、写通过标准跑基线、用分数说话
跟着交接处走，不要只看 Demo。 系统是否可靠，往往取决于模型、工具、状态、权限和人的交接处。把每次交接都当成可以观察、测试和恢复的地方。
为一个自动化步骤写清输入、负责人、审批和恢复动作。
一次运行成功了，却说不清发生了什么，也无法安全重放。
评测集不神秘，就是一堆固定的输入，各配一条「什么算过」的标准。神奇的地方在于跑分那一刻：你以为的全面提升，往往是三条升两条降。没有评测集，那两条降的你永远看不见。
改提示词前后，跑同一套用例
评测的三个坑，这一章都讲过
一是跑分时顺手改用例。用例一改，前后分数就没法比了，加用例可以，改用例要全量重跑基线。
二是只看总分。4/5 比 3/5 好？先看挂的那条是不是原来能过的。
三是标准写成「回答质量高」。这种标准没法判定，要写成「包含下周计划」「数字与原文一致」这种一眼能裁决的句子。判不了的，才轮到 LLM-as-Judge 出场。
这一章的动手清单
0 / 3 已完成
攒 10 条真实用例
15 分钟 所有人从你真实用过的输入里挑 10 条存进一个文件，一行一条。配比有讲究：七条日常、三条刁钻。刁钻的就从 M1 五连跑和 M2 卡死记录里捞，那些让它翻过车的输入最值钱。
什么算做完了
给每条写通过标准，跑出基线分
1 小时 想让改动有据可依每条用例配一句「什么算过」，必须写成一眼能裁决的形式：「输出恰好三段」「结论里包含 XX」「没有编造原文以外的数字」。写完把 10 条全跑一遍，记下第一个基线分。
什么算做完了
改一版提示词，用分数说话
半天 要持续迭代针对挂掉的用例改一版提示词，用例一条不动，全量重跑对比。重点盯两处：总分变了多少、有没有原来过的用例反而挂了。有退化不丢人，把退化那条和原因记下来。你已经在做 Anthropic 说的那套正经工程了。
什么算做完了
「先看清楚 · 同一次改动，五条用例各有各的命」怎样变成可执行的指令
「评测集不神秘，就是 一堆固定的输入，各配一条「什么算过」的标准 。神奇的地方在于跑分那一刻：你以为的全面提升，往往是三条升两条降。没有评测集，那两条降的你永远看不见」强调的不是某句神奇咒语，而是信息是否足够让模型判断“为谁做、要完成什么、什么结果算合格”。
背景决定方向，限制决定边界
从「一是跑分时顺手改用例 。用例一改，前后分数就没法比了，加用例可以，改用例要全量重跑基线」可以看出，一个有效请求至少要把任务、受众、输入材料、输出形式和限制条件分开。少了背景，模型只能猜；少了验收标准，即使文字流畅也无法判断是否完成任务。
继续加字不一定继续变好
把「M3 要记的是：评测集放在哪、基线分多少、第一次对比跑出了什么结论。从这格开始，你说「变好了」的时候手里是有数字的」变成一个小练习：只改背景、要求、限制中的一项，保留其他内容不动，观察哪一层真正改变了结果。
从「先看清楚 · 同一次改动，五条用例各有各的命」走到「动手清单 · 挑一个开始，勾掉它」
「先看清楚 · 同一次改动，五条用例各有各的命」先把问题落在「评测集不神秘，就是 一堆固定的输入，各配一条「什么算过」的标准 。神奇的地方在于跑分那一刻：你以为的全面提升，往往是三条升两条降。没有评测集，那两条降的你永远看不见」上；到了「动手清单 · 挑一个开始，勾掉它」，讨论继续推进到「从你真实用过的输入里挑 10 条存进一个文件，一行一条。配比有讲究： 七条日常、三条刁钻 。刁钻的就从 M1 五连跑和 M2 卡死记录里捞，那些让它翻过车的输入最值钱」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
写请求时也应逐层补齐：先说任务和受众，再给材料和输出要求，最后加上限制与验收方式；一次只改变一层，才能知道哪项信息起了作用。
- 「先看清楚 · 同一次改动，五条用例各有各的命」：评测集不神秘，就是 一堆固定的输入，各配一条「什么算过」的标准 。神奇的地方在于跑分那一刻：你以为的全面提升，往往是三条升两条降。没有评测集，那两条降的你永远看不见
- 「动手清单 · 挑一个开始，勾掉它」：从你真实用过的输入里挑 10 条存进一个文件，一行一条。配比有讲究： 七条日常、三条刁钻 。刁钻的就从 M1 五连跑和 M2 卡死记录里捞，那些让它翻过车的输入最值钱
- 「最后的要点」：M3 要记的是：评测集放在哪、基线分多少、第一次对比跑出了什么结论。从这格开始，你说「变好了」的时候手里是有数字的
最后的「最后的要点」把讨论落到「M3 要记的是：评测集放在哪、基线分多少、第一次对比跑出了什么结论。从这格开始，你说「变好了」的时候手里是有数字的」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。