Hamel Husain 实测 Claude Code 新增的自动评测工具

Anthropic 为 Claude Code 推出了全新的评测工具。他们的 claude-api 插件现已加入新的 build_eval 和 hill-climb 命令，能帮你构建评测集、检查打分器，并据此针对性地优化你的应用。

我平时很少评测这类评估工具，因为软件迭代太快，测评文章很容易过时。但 Anthropic 官方出品的工具很可能会影响大家做评测的方式，所以我还是想上手试试，并把体验分享出来。

我和 Isaac Flath 拿一套公寓租赁助手的对话记录做测试，并全程进行了直播。以下是我们的核心发现：

不足之处

1. 还没看数据，就催着你建评测

Claude 一上来就列出了几个潜在的问题点，紧接着让我们立刻选一个做成评测。它给出了如下选项菜单，并推荐选择“转接规则”。当时我们自己都还没看过对话记录，根本吃不准这到底是不是真问题，值不值得优先处理。不过，想着普通用户大概率会顺着推荐走，我们还是选了它建议的这一项。

我认为正确的做法应该是先看数据，摸清情况后再决定优先写哪些评测。智能体固然能帮你排查问题，但在继续推进之前，你依然需要做错误分析，搞清楚哪些问题才真正值得花精力解决。

2. 在上下文不足的情况下让人做判断

接着，Claude 生成了几个 Markdown 文件，用来查看与转接失败相关的数据。在下方的截图中，Claude 让咱们粗略过一遍 inputs.md，“告诉它”哪些标注错了。这就意味着我们得在编辑器里硬啃长篇对话，再切回聊天框一条条反馈修改意见。

我们觉得这非常不可思议：既然用的是编程智能体，它完全应该直接写个标注网页，既方便阅读对话，又能让我们就地打标签。最后我们实在受不了，让 Claude 临时写了个 Web 应用换上。

在随后的流程中，Claude 初步尝试为转接失败构建了一个评估器。它展示了汇总后的标签统计数据，并问我们：“有没有哪个用例你觉得打分不合适？”可它根本没给够上下文，我们压根判断不出这些标签到底对不对。整个流程里反复出现同一个毛病：还没帮用户把数据吃透，就急匆匆地去生成产物或找人确认审批。

3. 评估器的覆盖面铺得太宽

紧接着，该工具生成了一个转接评估器，一口气把四种不同的错误全揉在了一起：

• 重复确认，或者未经确认就直接转接。（基于大模型的裁判评测）
• 在用户同意和实际转接之间插话。（基于代码的评测）
• 在转接过程中或转接完成后说话。（基于代码的评测）
• 把工具底层操作念出来，比如把“正在触发”转接说漏嘴。（基于代码的评测）

这个评估器揉进去的东西实在太多了。我更倾向于把评测范围收窄，一次只盯一类错误；退一步说，至少也该把基于代码的硬规则评测和基于大模型的裁判评测拆开来做。

Claude 对这个评估器的描述也让人摸不着头脑：

核心指标是 protocol_ok。只有四项检查全部通过，用例才算合格。在“不应转接”的通话中，只要没发生转接，protocol_ok 就记为 1。

这堆 AI 生成的废话读起来很费劲。我更想直接看代码或裁判提示词，搞清楚到底生成了什么。我发现，仔细研读提示词永远是值得的，尤其是在评估这样关键的事情上。这部分工作流程如下图所示：

做得好的地方

这款插件开箱即用的问题发现能力让我印象深刻，它找出了其他自动评估方法未能发现的问题！包括人工转接、格式问题、语音智能体等诸多缺陷。虽然借助智能体反复审视数据依然是更好的做法，但在偏“一步到位”的问题发现方案中，这已经是我见过表现最出色的了。

Anthropic 介绍该工具的博文所传达的观点我大体赞同，比如审视数据的重要性、智能抽样、避免评估饱和等。看到越来越多人开始这样思考评估，我感到十分欣慰。

我会用它吗？

目前我会先等等看。我希望整个工作流能在敲定评估器之前帮我探索数据，并且从一开始就提供更好的审查界面。此外，我和 Shreya 整理的这些 Eval 技能主观预设更少、灵活性更高，结合代码智能体使用已经让我相当满意了。

后来我和 Claude eval 插件的作者聊了聊。他很感谢这些反馈，并表示会相应更新插件，所以预计不久后就会有所改动。未来或许值得重新关注一下。

即使这款插件之后会有变化，我也希望这篇全流程解析能帮大家更好地衡量其他评估工具。挑选工具时，务必确保它能帮你在确定评估方案前理解数据，并仔细核查其判定结果。我认为评估工作流的大部分环节都应该在 Web 应用而非对话框中完成，这样才能消除数据探索与标注的阻力。

请记住，如果一款评估工具没有把“审视数据”放在工作流的核心，那它就不值得使用。

感谢 Isaac Flath 审阅本文并与我一起参与直播讨论。