Claude Code 新增 /build-eval 和 /hillclimb 命令，评测设计流程开源

Claude Code 怎么做「Eval Design」和「Hillclimbing」？ 来自 A\ 这篇工程方法论，作者 @RLanceMartin 分享了如何把「评测设计」和「爬山优化」这两个 AI 工程中最关键也最容易自我欺骗的环节，产品化为 Claude Code 里的两个命令：/claude-api build-eval 和 /claude-api hillclimb，对应 Skills 也开源在 claude-api skill 中了。 博客地址： claude.dev/blog/automatin… 开源地址： github.com/anthropics/ski… “设计评测、并在其上提升性能而不自我欺骗，是很难的。” 常见的自欺路径有三条： 1. 任务选取偏差：挑容易生成、容易打分的任务，而不是真正关心的任务； 2. 对抗性采样陷阱：专门挑模型失败的案例来构建评测，测到的不是任务的内在难度，是该模型的“失败指纹”。换一个模型，这套评测就失真了。正确做法是“因为人类专家判断它难才选它”； 3. 评分器配置错误：博客强调“评分失误是评测被错误配置的最常见方式之一”，而且往往要在人工抽查打分时才暴露。 好评测的四条标准 本质上是从心理测量学/实验设计借来的信度效度框架： 1. 任务镜像生产：任务分布必须代表你真正关心的东西，而非便于评分的东西 2. 性能随模型能力/努力程度单调变化：如果最强模型最高努力也做不好，多半是任务有歧义或评分器坏了，这是把“可区分性”当作评测健康度的诊断信号 3. 前沿模型留有头部空间：最强配置应明显低于 100%（基线已 ~95%+ 时，评测失去区分度，应转而优化成本） 4. 低运行间方差：四个来源：任务歧义、评分器对相同输出给出不同判定、配置不一致（如 effort 未统一施加）、环境状态泄漏（残留文件、git 历史直接暴露答案） build-eval：评测自动化的关键设计 工作流不应该是黑箱生成，是带人工审批关卡的引导式流程，输入采样按代表性排序：生产对话记录 → bug 报告/工单 → 5–10 个人工手写案例 → 从代码库合成的案例。 评分器选择遵循最便宜够用原则： · 输出受限时用程序化验证（精确匹配、固定标签、schema 校验、测试通过）； · 开放式输出用 LLM-as-judge，但有三条纪律：rubric 写成“可核验的陈述”而非 1–5 分量表；有基线输出时用随机顺序的成对比较；裁判模型不能是被测模型本身（避免自我偏好）。 自动化诊断是亮点：评分器对同一输出跑两次检验稳定性；检查管道问题（超时、API 错误、答案被截断）；基线过高时发出头部空间警告；每个案例输出 JSON 行 + 完整转录，并生成带置信区间的本地结果页。 hillclimb：爬山的核心是防过拟合 适用面判断是前提，可爬山的表面需满足三个条件：迭代便宜（prompt、skill 而非大改 harness 代码）、变化可归因（改什么就影响什么）、目标定义清晰。一个普适的稳健目标：性能持平前提下降成本，即使在饱和评测上也有效。 防过拟合机制构成了一个完整的实验协议： · 随机 train/test 划分，测试集永远不看； · 判定规则：训练集升 + 测试集平 = 疑似过拟合 → 回滚；两者同升才保留； · “绝不把失败案例内容粘贴进 prompt”，这是最直接的过拟合通道，补丁必须针对根因（重写问题段落），而非表面措辞； · 把答案保持在模型结构性接触不到的位置，防 reward hacking； · 开跑前先验证评测噪声小于你想采取行动的最小改进幅度，否则增加重复次数或案例数； · 连续 2–3 轮停滞时，对剩余失败按根因分类，这一步往往会暴露评测自身的 bug（歧义任务、harness 错误、评分器缺陷），剔除后只留真实失败继续迭代； · 最终以测试集上表现最好的版本收尾，若增益在噪声范围内则明确建议不要合并。 两个案例：数字表现 案例一：客服成本优化（44 张工单，30 训练 / 14 留出）。基线 Opus 4.8 高努力档：74.4% 决策准确率，4.6 美分/单。爬山过程展示了典型的“先减负再降配”路径：清理 prompt 中的工具调用仪式、草稿步骤和矛盾规则 → 换 Opus 5.5 低努力档（87.8%，1.9 美分）→ 降级到 Sonnet 5 低努力档（88.9%，约 1 美分）→ 针对性改进路由规则后训练集 98.9%。留出测试集：90.5% vs 原始 78.6%，成本约为原来的五分之一。 案例二：claude-api skill 自身提能（66% → ~88%）。这个过程更像一次诊断式复盘：补齐 8 个缺失功能覆盖 → 74%；修 C#/Java 类型表错误 → 77%；停滞后的根因分析发现模型在凭训练先验写过时的 API 形态（如已被新版 Opus 拒绝的固定预算 thinking），在 skill 顶部加迁移表 → 80%；随后甚至揪出评测自身的缺陷（一个任务只要求捕获一种错误但评分器要求至少三种错误的调用链；另一个评分器与文档矛盾，实测 API 证明文档是对的）→ ~88%。 ClaudeDevs @ClaudeDevs Claude can now help you build evaluations and hillclimb on them. In this article, we share guidance on eval design & skills that Claude Code can use to improve your applications. https://t.co/PgKFC2DWth 🔗 View Quoted Tweet 💬 1 🔄 0 ❤️ 2 👀 437 📊 2 ⚡