Hamel Husain实测Anthropic评估插件：先看数据再建评估

Hamel Husain是AI评估领域的实践者，他与Isaac Flath在直播中用Anthropic新发布的Claude Code评估插件处理了一组公寓租赁助手的真实对话记录。这个插件包含build_eval和hill-climb两个命令，号称能帮助用户构建评估、检查评分器并改进应用。Hamel平时不写评估工具评测，因为软件变化太快、评测保质期很短；但Anthropic作为模型厂商发布的第一方工具，很可能影响人们做评估的方式，所以他决定试一下。

结果并不理想。第一个问题出现在最开始的环节：Claude浏览对话后直接列出几个潜在失败点，让用户立刻选一个来建评估，推荐的是呼叫转接规则。两人此时还没自己看过那些对话，无法判断这是否是一个真正值得优先处理的失败。Hamel认为正确做法是先看数据、做错误分析，再决定哪些失败值得写评估——工具应该辅助发现问题，而不是跳过理解直接要求承诺。

第二个问题是标注体验。Claude生成了一个Markdown文件列出与呼叫转接失败相关的数据，让用户浏览inputs.md并告诉它哪些标签是错的。这意味着在编辑器里读长对话，再切回聊天窗口报告修正。Hamel觉得这很荒谬——既然用的是编程代理，它本可以直接构建一个标注应用，让对话易于阅读、反馈就地提交。他们最终要求Claude建了一个网页应用来替代。

第三个问题是评估器范围过宽。工具生成的呼叫转接评估器同时检查四种失败：是否重复询问确认或未确认就转接（LLM评判）、是否在用户同意和转接之间说了什么（代码评估）、是否在转接期间或之后说了什么（代码评估）、是否把工具机制念出来比如正在触发转接（代码评估）。Hamel认为应该一次聚焦一个错误，或者至少把需要LLM评判和代码评估的分开。更糟的是，工具用protocol_ok是标题、一个案例只有四项检查全部通过才算通过这样的描述来解释评估逻辑，Hamel称之为AI垃圾——他宁愿直接看代码或评判提示词。

不过也有值得肯定的地方。Hamel承认这个插件在开箱即用的问题发现能力上超出了他见过的其他自动评估方案，它发现了人工交接、格式和语音代理等方面的问题。他仍然认为用代理迭代地看数据更好，但这是他在一次性问题发现方式上见过的最强表现。

Hamel的结论是暂时不用这个插件。他已经有自己和Shreya整理的Eval skills工作流，更灵活也更少预设。他后来与插件作者交谈，对方感谢反馈并表示会更新，所以他认为将来值得再看。但他提炼的原则适用于任何评估工具：确保工具帮你在选择评估之前理解数据，仔细检查它的判断。他相信评估工作流的大部分应该在网页应用中完成而非聊天窗口，以减少数据探索和标注的摩擦。如果评估工具不把看数据放在工作流中心，就不值得使用。