Anthropic 9 月 28 日在开发者博客发文，宣布在 Claude Code 可用的 claude-api skill 中加入两个新指令：/claude-api build-eval 用来帮助开发者为自己的 AI 应用建立评测集，/claude-api hillclimb 则根据评测结果逐步调整提示词、模型与参数，并尽量避免应用只在题库上变好、却没有提升真实表现的过拟合问题。
Anthropic 在文中披露了一个内部客服案例。Claude 将原本使用 Opus 4.8、高推理强度的配置，逐步调整为成本更低的 Sonnet 5、低推理强度设置。按照 Anthropic 给出的结果，在调整过程中从未看过的测试工单上，准确率从 78.6% 提升到 90.5%，成本约降到原来的五分之一。
客服评测从 Opus 4.8 调到 Sonnet 5
这组客服评测一共包含 44 张工单，其中 30 张用于调整，14 张保留为测试。起始配置是 Opus 4.8 默认的高推理强度，调整用工单上的决策准确率为 74.4%，每张工单的 token 成本为 4.6 美分。
Claude 首先检查提示词，删除了强制性的工具调用流程、草稿步骤以及彼此矛盾的规则。随后，系统改用低推理强度的 Opus 5.5，准确率升至 87.8%，每张工单成本降到 1.9 美分。
Anthropic 在文章中指出，这部分节省有一部分来自 Opus 5.5 的定价变化：其输入和输出 token 比 Opus 4.8 便宜 20%，缓存读取便宜 60%。
在 Opus 5.5 已达到目标后，Claude 继续尝试成本更低的 Sonnet 5 低推理强度配置。结果显示，准确率约为 88.9%，每张工单成本再减半至约 1 美分。最后，在加入分流规则和退款上限的交叉比对后，Sonnet 5 在调整用工单上的准确率达到 98.9%。
hillclimb 的调优方式：一次只改一处
Anthropic 表示，在 hillclimb 开始前，Claude 会先询问开发者希望优化的目标，例如提升表现，或在表现不变的前提下降低成本。之后，系统会把评测集随机拆分为调整组和测试组。
每一轮调优中，Claude 只读取调整组中的失败记录，并提出一项修改。如果调整组分数上升、测试组却没有变化，Claude 会将其视为可能出现过拟合，并撤回这次修改；只有当两组都出现提升时，修改才会被保留。
文章举例称，如果评测题目刚好需要图片文字识别，调优过程可能会给应用加入 OCR 工具，考试分数会提高，但真实使用场景未必因此受益。基于这一点，Anthropic 要求不要把失败内容直接贴进提示词，也要让答案在结构上无法被模型直接接触，避免模型直接找到评测答案。
分数停滞后会检查失败案例与评测器
当分数连续两到三轮停滞时，Claude 会逐一检查剩余失败案例，并按原因分类，找出是题目本身存在歧义、评分器出错，还是评测环境有问题。
Anthropic 称，公司也用同一套流程调优 claude-api skill 本身，通关率从 66% 提升到约 88%。在这个过程中，团队发现一题的评分器要求与题目本身不一致，另一个评分器的说明则与官方文档相互矛盾。
build-eval 如何建立评测集
在 build-eval 部分，Anthropic 表示，系统会先访谈开发者，再依次从正式环境中的对话记录、错误报告与客服工单、手写的 5 到 10 个案例，以及从代码推导出的案例中取样。随后，它会生成一个页面，让开发者逐条确认每一笔输入。
在评分方式上，文章称应优先采用成本最低、可行的程序比对方法；只有在答案较开放时，才使用另一个模型担任评审，而且评审模型不应与受测模型相同。
Anthropic列出好评测的四个条件
Anthropic 在文中列出好评测的四个条件：
- 题目要能反映正式环境；
- 模型越强、推理强度越高，分数应越高；
- 最强模型在最高强度下，成绩仍应明显低于 100%；
- 每次执行的结果差异要小。
文章还提醒，如果只挑选当天模型答错的题目，测到的可能只是这个模型当前的弱点，而不一定是应用真正需要的能力。