这篇文章讲的是如何把评估（eval）设计与 hillclimbing 自动化。评估能给出应用或 skill 在具体任务上的信号，但设计评估、以及在不自欺的前提下靠评估改进性能，都很难。Anthropic 把这些原则做进了 claude-api skill：在 Claude Code 里可跑 /claude-api build-eval 构建评估，或跑 /claude-api hillclimb 一次只改一个地方，并用留出集识别过拟合。

好评估有几个共性。任务需要镜像生产，采样你真正关心的场景，而不是容易生成或容易打分的内容。更强模型加更高 effort 应当得分更高，如果没有，多半是任务含糊或 grader 校准有问题。最强模型最高 effort 的得分应明显低于 100%，否则无法判断改动影响；留下的 gap 不能来自不可能或模糊任务。run-to-run 方差要低，高方差通常来自含糊任务、grader 不稳定或配置不一致，比如 effort 没被一致应用，或前一次 trial 残留的文件、git 历史把答案递给 agent。采样不要只挑当前模型失败的案例：模型能力是参差（jagged）的，对抗采样会测出某个模型的失败指纹，而不是真正困难或有价值的任务。应该选人类判定为难的案例，并纳入生产流量、bug report、ticket 的具体失败；用户流量本身偏易，因为用户倾向尝试预期能成功的东西。

/claude-api build-eval 把这套原则变成引导式流程。Claude 按优先级采样输入：production transcript（先确认 retention 和敏感数据）、bug report 和 support ticket、五到十个手写案例、从代码库合成并锚定真实例子的案例，每个输入都会生成页面等你确认。grader 方面，输出受限时用程序化验证，如精确匹配、固定标签、JSON schema 或测试；输出开放时默认用 LLM-as-judge，让第二个模型按可核查的 claim 打分而不是 1-5 分，有 baseline 就随机顺序盲比，judge 不能是正在测试的模型。Claude 会先批改少量案例并问你是否给出不同分数；使用 evaluator 前读一批带分数 transcript 很重要。确认后，skill 给出评估集规模（cases × repeats × model）和大致耗时，跑 baseline，返回每个 case 的 JSON 行与完整 transcript。诊断检查包括：grader 对同一输出跑两次看结论是否变化，检查 timeout、API error、截断回答；如果 baseline 已约 95% 以上，会提醒 hillclimb 应转向成本或延迟优化。

hillclimb 适合迭代便宜、得分变化可归因、目标范围明确的修改面。目标不明确或评估接近饱和时容易停滞；成本是普适目标，即使评估饱和，也可要求 Claude 在保持性能的前提下降低成本。过拟合主要来自评估漏进 harness，例如评估任务里 OCR 有用、生产里没用，harness 就会加 OCR 工具。三种对策：分 train/test 集，train 升 test 平是过拟合警报；不要把失败内容贴回 prompt；从结构上让模型拿不到答案。

/claude-api hillclimb 先问优化目标，再随机拆 test/train。成本目标下会审视 prompt caching、prompt 与模型兼容性、模型与 effort 设置。第一轮前先测评估噪声，若噪声大于你愿意行动的改进幅度，就建议增加 repeats 或 cases。每轮读上一轮 train transcript，提出一个 patch，跑评估；train 升但 test 平则怀疑过拟合并回滚，有回归也回滚。停滞两三轮后，Claude 把所有剩余失败按根因分类，找出含糊案例、harness 错误或 run-to-run 方差；若没有单个改动能超过噪声，也会建议增加 repeats。结束时把代码停在 test 集最好的版本，报告带置信区间的 test 结果；收益在噪声以内会建议不要 merge。

两个实测例子。内部客服 benchmark 共 44 条 ticket，30 条参与迭代，14 条留出。初始 Opus 4.8 默认 high effort，决策准确率 74.4%，每条 ticket 成本 4.6 美分。hillclimb 先审计 prompt，删掉强制 tool-call 仪式、scratchpad 步骤和互相矛盾的规则；再换 Opus 5.5 low effort，准确率升至 87.8%，成本降到 1.9 美分。Opus 5.5 的 input/output token 价格比 Opus 4.8 低 20%，cache read 低 60%。继续下探 Sonnet 5 low effort，准确率约 88.9%，成本约 1 美分。最后给 prompt 加路由规则和 refund-cap 交叉引用，Sonnet 5 到 98.9%，成本基本不变；在 14 条留出 ticket 上，最终配置 90.5% 对原配置的 78.6%，成本约为五分之一。

另一个例子是 claude-api skill 自身。初始评估约 66%；给 hillclimber 访问文档和 SDK 后，发现缺八个 feature 覆盖，补上后到 74%；修正 C# 和 Java 类型表错误后到 77%。分数停滞两轮后，Claude 把剩余失败按根因分类，发现内容都在但模型写的是旧 API 形状，于是在 skill 顶部加了一张从旧形式映射到当前形式的表，性能到 80%。再修一个有问题的 task——题目要求捕获一种错误，grader 却要求至少三层链——以及一个与官方文档矛盾的 grader，加上其它编辑，最终到约 88%。使用前先 claude update，因为 claude-api skill 随 Claude Code 分发。