AREX Feed Article
Anthropic 为 Claude Code 新增 build-eval 与 hillclimb 子命令：构建评测并围绕评测迭代
北京时间 9 月 29 日凌晨，Anthropic 开发者账号 ClaudeDevs 在 X 上，Claude 现在可以帮助构建评测（evaluations），并基于评测做 hillclimb（沿评测分数逐轮迭代改进应用）。帖文链接了 9 月 28 日发布在 claude.dev 的《Automating eval design and hillclimbing with Claude》。
这两个能力由 （技能包）新增的两个子命令提供：在 Claude Code 中运行 /claude-api build-eval 可以在代码库里搭出一套评测；运行 /claude-api hillclimb 则让 Claude 针对这套评测逐轮改进应用，并用留出集（held-out set）盯住过拟合。文章用两个实例演示了这套流程：一个跑在内部客服基准上，另一个针对 claude-api skill 自身。
claude-api skill 里的两个新子命令
发帖账号 ClaudeDevs 的写着「面向使用 Claude 构建应用的开发者的官方更新」。帖文称，文章分享的是 eval 设计指导，以及 Claude Code 可以用来改进应用的 skills。文章开头则说，评测能给出应用在特定任务上表现的信号，但设计评测、以及基于评测改进而不骗过自己，都很难；这次新增的指导就加在 claude-api skill 里，这个 skill 提供 API 使用指导，以及与 Claude 协作的通用技巧，托管在 GitHub 的 anthropics/skills 仓库里。
列出了这两个子命令和各自要读取的步骤文件。build-eval 会先做一轮访谈（评的是什么、用例从哪来、怎么评分、可运行的脚本与实测成本），并在生成评测之前，要求用户对输入样本、评分方法和成本逐项明确同意。hillclimb 启动的前提则是：先确认存在一套可运行的评测（没有就先走 build-eval），和用户划清可改与不可改的范围，按实测的单次运行成本定出预算与停止条件；方案获批后，才进入「读取 → 提议 → 应用 → 运行 → 记录」的循环。
好评测的四条标准，和一个采样陷阱
文章先给评测本身立规矩，列出四个特征：
- 任务要镜像生产：采样你真正在意的场景，不要因为某类任务好生成、好打分就选它。
- 更强的模型和更高的 effort 水平（模型思考投入的档位）应当带来更好的成绩；如果不是，常见原因是任务有歧义，或者评分器已经失准。
- 前沿要留有余量：最强模型在最高 effort 下应明显低于 100%，否则无法可靠判断改动是否奏效；这个差距也不该来自不可能或有歧义的任务，一个常见迹象是某个任务无论重复多少次都失败。好任务的标准是：两位领域专家会得出相同判定，且评分器检查的每一项都写在任务里。
- 运行间方差要低。高方差常来自有歧义的任务，或对同一输出给出不同结论的评分器；方差也可能藏在配置里，比如 effort 没有一致地应用；环境同样会干扰结果，上一次试验留下的文件或 git 历史，可能直接把答案递给模型。
文章还点出了一个采样陷阱：模型的能力是「参差的」（jagged），专挑今天的模型会失败的用例，只是在采样某个模型能力曲面的谷底，测出来的是「这个模型的失败指纹」，而不是任务本身有多难、对你的应用有多重要。更稳妥的做法是挑人类判定为难的用例，收录之前能说出它为什么难；纳入生产流量、bug 报告和工单里的具体失败；但也不要盲信用户流量——用户有时只尝试他们预期能成功的东西，完全按用户流量采样可能偏简单。
build-eval：先选样本、再选评分器，然后跑出带置信区间的基线
样本来源有优先级：生产 transcript（生产环境的交互记录，先问清数据保留与敏感信息的问题）→ bug 报告与支持工单 → 你亲手写的 5～10 个用例 → 从代码库合成的用例。skill 优先使用生产流量，也能以少量真实样本为锚生成合成数据；它会生成一个简单页面，把每条输入都展示给你，等你确认后才继续。
评分器（grader）按「够用且最便宜」来选：输出可能性受限时用程序化校验，比如精确匹配、固定标签集合、符合 schema（结构定义）的 JSON、测试通过；输出开放、有效答案多但质量标准清楚时，用 LLM-as-judge（让另一个模型充当评委）来评分：第二个模型读取输入、输出和一份写成「可核查断言」的评分标准（不是 1～5 分的量表），给出分数与理由；如果存在基线，判分模型会在不知道哪边是基线的情况下、以随机顺序比较两份输出，选出更好的那个。判分模型由用户选定，并且不应是被测的模型。文章提醒，在相信评分器之前要读一批已打分的 transcript：评分失败是评测被配错的常见原因之一。
评分器验证通过后，skill 会报出评测规模（用例数 × 重复次数 × 模型）和大致耗时，跑出基线并打印带置信区间的分数。产出包括：用例、评分器、运行器、每个用例一行 JSON 与完整 transcript，以及一个列出各用例分数、能跳到 transcript 的页面；想要图表，可以让 Claude 在旁边再生成一个静态页面，这类附加页面默认在本地打开，不加载任何网络资源。
基线运行时还带三类诊断。评分器方面，把同一个输出跑两遍，看结论是否会变；管道方面，检查超时、API 错误和被截断的回答，避免基础设施噪声被当成模型波动；余量方面，如果基线已达约 95% 或更高，就提醒用户把 hillclimb 的目标转向成本或延迟。
hillclimb：每轮一个补丁，用留出集裁决
hillclimb 开始前，Claude 会问你想优化什么：性能，或者是「保持性能、把成本压下去」。允许它改动的范围由你指定：系统提示词、skills 或指令文件、工具描述、模型选择与 effort 水平等 API 参数，以及 harness 代码；harness 是包在模型外面的那层代码，包括提示词、工具和调用 Claude 的循环。以成本为目标时，它会检查常见的成本驱动，包括 prompt caching（提示词缓存）、提示词与所选模型的适配性审计、模型与 effort 档位的选择。
文章对怎么选优化对象给了三条经验：改动要便宜，提示词与 skills 这类文本最容易改也最容易回滚，开放式地改 agent harness 则往往牵动大量代码；效果要可归因，评测指标要直接跟着被改对象走，文章举的例子是调 skill 的触发率；目标要收窄，评测接近饱和时，把目标换成成本通常成立，也就是在表现不降的前提下找省钱的办法。
即便评测设计得不错，它也很少精确匹配生产环境里真正的任务分布，「过拟合」因此很常见：系统在评测上更好，在生产流量上却没有。文章说，评测有很多途径「漏」进 harness，比如某些评测用例受益于 OCR（文字识别）、生产任务却基本用不上，而 harness 为了提分加上了 OCR 工具。对应的三条做法是：把用例拆成优化器可读的 train 与从不示人的 test（train 涨、test 平是常见的过拟合信号）；绝不把失败内容粘进提示词；以及把答案在结构上挡在模型够不到的地方，因为模型有时会直接找出评测答案，也就是所谓的 reward hacking。
真正跑起来时，还有一个前置门槛：评测的噪声（即分数仅因随机性就可能起落的幅度）必须小于你愿意据以行动的最小改进；不满足，它会直接说明，并建议增加重复次数或用例。每轮只提交一个补丁：读上一轮 train 的失败记录，提出一处修改，瞄准效果能盖过噪声；它要修的是根因，比如重写引发问题的那段内容、补上缺失的规则，而不是替换措辞。跑完评测再裁决：train 涨而 test 不动，视为过拟合嫌疑，回滚；出现回退，回滚；两边都涨，保留。
文章配图：hillclimber 的迭代流程——每轮提出一处改动，train 集供它读取失败记录，test 集从不示人。
当分数连续两三轮停住，Claude 会把剩余的 train 失败逐条读完、按原因归类；如果不存在任何单个修改能带来超过噪声的收益，这一步会更早发生。它会建议增加重复次数或用例，避免在测不出来的改动上耗轮次；文章说，这一步能抓出有歧义的用例、harness 错误和运行间方差，只有真正的失败才会进入后续轮次。整个流程结束时，Claude 把代码留在 test 集上对你目标最好的版本，报告相对基线的、带置信区间的成绩；如果增益落在噪声之内，它会说明，并建议不要合并。
客服基准实例：审计提示词、下调模型档位
第一个实例是一套内部客服基准，目标定为降低成本、同时提升表现：共 44 张工单，30 张用于搜索，14 张留出、从不参与优化。
起点是 Opus 4.8、默认（高）effort：搜索集上的决策准确率为 74.4%，每张工单的 token 成本为 4.6 美分。第一步是审计提示词，删掉强制性的工具调用仪式、一个 scratchpad（草稿）步骤和互相矛盾的规则，然后换用 Opus 5.5、低 effort：准确率 87.8%，成本降到 1.9 美分/单，不到原先的一半；文章把其中一部分节省归因于 Opus 5.5 更低的定价。因为 Opus 5.5 过了基线的准确率门槛，hillclimb 又往下探了一档更便宜的模型：Sonnet 5 在低 effort 下成绩相当，为 88.9%，成本约再减半，为 1 美分/单。
最后，提示词又加上了路由规则和一条退款上限的交叉引用，把 Sonnet 5 推到搜索集 98.9%，成本大致不变。在 14 张从未参与搜索的留出工单上，最终配置的准确率为 90.5%，原始配置为 78.6%，成本约为原来的五分之一。
文章配图：成本导向的 hillclimb 路径。横轴为每单成本（对数刻度），纵轴为训练拆分上的决策准确率。
自测 claude-api skill：补齐缺失覆盖、修正评测自身的错误
第二个实例的被测对象是 claude-api skill 自己：Anthropic 依据自家文档搭了一套评测，检验这个 skill 能否写出正确调用其 API 的代码。skill 一开始只有 66%；把文档与 SDK 交给 hillclimber 后，它先发现 skill 漏掉了八个功能的覆盖，补齐后到 74%；随后它找出 C# 和 Java 类型表里的错误，成绩到 77%。
两轮停滞后，它进入反思步骤：不做修改，只把剩余失败按根因归类。这次归类发现，skill 里的内容其实都在，问题出在 Claude 会照训练时记住的旧写法作答；于是它加上一张表，把「记得的形态」映射到现行写法，比如把固定 token 预算的 extended thinking 改成 adaptive thinking（这种固定预算的写法在近期 Opus 模型上会被 API 拒绝），把旧版 web search、web fetch 工具换成当前版本；它还把 C#、Java 的警告挪到 adaptive thinking 示例之前。成绩到 80%。
归类过程还暴露了另一类问题：有些任务补了内容也不涨分，这通常说明用例或评分器本身有问题。一个任务要求代码捕获一种错误类型，它的评分器却期待至少三层的链条，Claude 改写了任务描述；另一个评分器的说明与文档矛盾，实际调用 API 后证明文档是对的。修掉这些之后，又做了更多 skill 修改；到第 24 轮，成绩为 87.9%。
文章配图：claude-api skill 评测的通过率随 hillclimb 轮次上升。
两组数字都来自 Anthropic 自己的运行，文章给出了运行条件、中间步骤与修改内容。流程本身可以独立核对：公开仓库里的 claude-api skill 写明了两个子命令、各自要读取的步骤文件，以及运行中要求用户逐项确认的环节。