讲一下这个https://claude.dev/blog/automating-eval-design-and-hillclimbing/

回复 群友 1459： 这篇是 Lance Martin 9 月 28 日发在 claude.dev 上的，可以看成你上次发的那篇 Anthropic eval 文章的落地版:上一篇讲"eval 该怎么设计"的原则，这篇讲怎么让 Claude Code 自己把这两件事干完——设计 eval，然后照着 eval 往上爬。核心是把 claude-api 这个 skill 里的两个斜杠命令说清楚了。 先说它列的"好 eval 的四个特征"，这部分是骨架：一是题目要反映真实生产场景里你在意的任务分布，而不是挑好生成或者好打分的题；二是模型越强、思考预算给得越多，分数应该越高，如果不涨，通常说明题目有歧义或者打分器没校准；三是前沿必须留有可攀爬的空隙，最强的模型在最高预算下也应该明显低于满分，否则你没法判断改动有没有效果，而且这个差距不能是靠无解或模糊的题目撑出来的——一道题如果无论跑多少次都失败，那基本是题坏了；四是跑批之间的方差要低，方差往往来自题目模糊、打分器对同样输出给出不同结论，或者环境里留了上一轮的状态（比如残留的文件、git 历史）把答案递给了 agent。 里面有个概念我觉得挺关键，叫对抗性采样。模型能力是高低不平的，如果你专门挑"今天这个模型做不出来的题"，你采到的是这个模型能力曲面上的一条低洼带，最后这个 eval 测的是"这个模型的失败指纹"，而不是"这件事本身难不难"。所以判断标准应该是人觉得它难，并且你能说出它为什么难，再收进来。另外也别无条件信用户流量，用户一般只会试自己觉得能成的事，纯从流量里抽题会偏简单。 然后是 build-eval 命令的流程：它会先访谈你，然后在你代码库里面把 eval 搭起来，中间几个节点会停下来等你确认。采样顺序是生产环境的对话记录（会先问留存和敏感数据的事）、bug 报告和工单、你手写的五到十道题、最后才是从代码库里合成。它会生成一个简单页面把每条输入列出来给你过目。 打分器这块，它按输出空间选最便宜的那个：输出有约束就用代码判（精确匹配、固定标签集、JSON 比 schema、测试是否通过），输出开放就用模型当裁判。模型裁判的 rubric 写成一条条可核验的断言而不是 1 到 5 分打星；如果有基线可比，就让裁判在不知道哪个是基线的前提下盲选哪个更好。裁判模型不能是被测的那个模型。它还会挑几道已经打分的题问你要不要改判——不看一批真实打分记录就相信自己的打分器，是最常见的翻车方式。确定以后它会告诉你这套 eval 的规模（题数乘重复次数乘模型，大概要跑多久），跑一次基线，给你分数和置信区间。 基线跑的时候它还会顺手做诊断：同一个输出判两遍看结论会不会变；查超时、API 报错、回答被截断这类管道噪声，别让基础设施的锅算到模型头上；以及如果基线就已经 95% 以上，它会警告你，说这时候该爬的方向是成本或延迟，不是质量。 下半篇是 hillclimbing，就是拿这套 eval 当坡度往上爬。选哪里爬有三条经验：改起来要便宜（所以大家基本都爬提示词和 skill，改得快也回滚得快，直接改 harness 代码代价就大了）；效果要可归因（比如爬 skill 的触发率，指标和被改的那段描述是直接对应的）；目标要收窄（"把性能提上去"这种开放式要求最容易卡死，一个普遍好用的目标是成本——就算 eval 已经饱和了，也可以要求它在不掉质量的前提下省成本）。爬的时候一般一轮只提一个改动，而且要改在根上，比如重写导致失败的那一段、补一条缺失的规则，而不是把某句话换个说法。 它花了不少篇幅讲过拟合，因为 eval 再设计得好也和生产分布有偏差，分数涨了不代表线上变好。典型泄漏方式：题目恰好需要 OCR，但你的线上场景几乎用不到，harness 为了提分就加了个 OCR 工具，benchmark 涨了线上没动；或者针对你抽到的那几道题的边角情况往 harness 里加功能。三个应对办法是：把题目切成训练集和测试集，测试集永远不给爬的人看，训练集涨、测试集不动就是过拟合的信号；失败记录可以看，但绝对不许把失败内容原样贴进提示词；以及别让答案以任何形式落在模型手边，模型是会 reward hack 的。 hillclimb 命令的流程就是把上面这些编成循环：你选它允许改哪些面（系统提示、skill 或指令文件、工具描述、模型和思考预算等参数、harness 代码），再说清目标，然后它随机切分训练和测试集。开始前它会先比一下 eval 的噪声和你能感知的最小提升，噪声更大就直说，让你加重复次数或加题。每轮它读上一轮训练集的记录，提一个补丁，跑一遍，然后按结果裁决：训练涨测试平，判定过拟合，回滚；出现回退，回滚；两边都涨，留下。如果连着两三轮不动，它会停下不做修改，专门把所有还没过的失败按根因分类——这一步经常能揪出题目本身有歧义、harness 有 bug 或者方差问题。最后它把你代码留在测试集上表现最好的那一版，报测试结果和置信区间，如果提升落在噪声范围内，它会建议你别合。 两个例子数据挺有说服力。成本那次是内部客服 benchmark，44 张工单，30 张用来搜、14 张留出。起点是 Opus 4.8 高预算，决策准确率 74.4%，每张工单 4.6 美分。第一轮先审提示词，删掉强制的工具调用仪式、一个草稿本步骤和互相矛盾的规则，然后试 Opus 5.5 低预算，准确率 87.8%，成本降到 1.9 美分。因为 Opus 5.5 过了线，它继续往下换模型试，Sonnet 5 低预算差不多，88.9%，成本约 1 美分。最后再加上路由规则和退款上限的交叉引用，Sonnet 5 到 98.9%，成本基本不变。那 14 张从没被看过的留出工单上，最终配置 90.5%，原始配置 78.6%，成本大约是原来的五分之一。 另一个例子是用它来改进 claude-api 这个 skill 本身：起点 66%，发现缺了八个功能的覆盖，补上到 74%，又发现 C# 和 Java 类型表有错，到 77%。分数卡住两轮之后做了一次根因归类，发现 skill 内容其实都在，是模型按训练时的旧印象写老 API 形状，于是在 skill 顶部加了一张"你记得的写法对应现在的写法"的对照表（比如固定 token 预算的 extended thinking 换成 adaptive thinking、旧版 web search 和 web fetch 工具换成现在的），到 80%。剩下一批怎么改都不动的题，反而暴露了题目和打分器有问题——有一道题只要求捕获一种错误，打分器却要至少三条错误链；还有一道打分器的说明和官方文档冲突，真的调 API 一验，是文档对的。改完这些到大约 88%。 跟上次那篇的关系我这么看：那篇给的是原则，这篇给的是把原则塞进 Claude Code 的成套流程，而且多出了两块上次没细讲的——一个是过拟合的工程化防护（训练测试切分加自动回滚），一个是"爬不动的时候先查 eval 本身有没有 bug"，这是很实用的经验。它对你自己做 Agent 项目的启发大概就是：别把 eval 当成一次性的评分脚本，它应该是个可以持续被优化、也持续被怀疑的对象。