你团队中的某人构建了一个大语言模型功能。也许它是一个内联代码建议功能。也许它是一个“修复此拉取请求评论”按钮。也许它是一个能够自主发起拉取请求的完整智能体。演示很成功。截图效果也不错。于是你们发布了它。
现在，一位真实用户将其应用于真实的代码库，而你完全不知道它的表现是逐周改善还是恶化。
这种介于“它在演示中运行良好”与“我们能证明它正在改进”之间的差距，正是评估（evals）所要解决的问题。然而到了 2026 年，我们在这方面仍然令人惊讶地糟糕。我们指着 SWE-bench Verified 分数，仿佛它们等同于“它是否在我们的仓库中有效”，我们过于信任以大语言模型作为评判者的评分方式，超出了文献建议的程度，并且我们将低延迟的令牌流误认为是实用性。本文是一份实用指南，介绍了如何衡量对开发者工具至关重要的三个方面：它是否有用，是否正确，以及是否安全。
开发者工具评估的独特之处
许多通用的大语言模型评估建议都是为聊天机器人编写的，其输出是供人类阅读的段落。而开发者工具则处于光谱的另一端。其输出通常是一个差异文件、一个文件、搜索结果、一段结构化的 JSON 数据，或者是一种副作用：例如关闭一个问题单、构建成功通过、发布制品。这几乎改变了你进行评估的所有方式。
聊天机器人的回复只需要“足够好”即可。而差异文件要么能干净地应用，要么不能。单元测试要么通过，要么不通过。拉取请求要么被合并，要么永远搁置在那里。与聊天机器人团队相比，你可以更频繁地使用地面真值（ground truth），即针对实际测试进行实际执行。这是好消息。
坏消息是，故障模式更加尖锐。如果一个聊天机器人产生幻觉，提供了一个略微错误的事实，用户只会点个踩并收到道歉。但如果一个编程助手对一个类的方法产生幻觉，在动态语言中它可能会编译通过，而在非动态语言中则会破坏构建。如果一个智能体虚构了一个命令行界面标志，它将运行错误的命令。其爆炸半径更大，静默失败更隐蔽，而你的用户并不喜欢这些情况。
因此，对于开发者工具而言，评估问题从来不仅仅是“模型是否说了正确的话”。它是某种形式的：给定这个真实输入，生成的产物能否经受住构建、测试、代码检查器、审查者以及用户意图的考验？
三个维度：有用性、正确性、安全性
我发现将评估沿三个独立的维度进行划分很有用，因为针对每个维度所使用的技术截然不同，且它们涉及不同的利益相关者。
正确性是最容易定义也最容易衡量的。它是二元的或接近二元的。补丁能够编译。测试通过。SQL 查询返回了正确的行。重构保留了原有行为。应用程序接口调用返回了 2xx 状态码。正确性是诸如 SWE-bench、HumanEval 以及你自己的单元测试等基准所衡量的内容。当你拥有地面真值时，你应该使用它。
有用性则更加模糊。对错误的问题给出正确的答案并无用处。完美重写了开发者正准备丢弃的代码并无用处。当用户想要一行修复方案时，提供一个 14 步的计划并无用处。有用性指的是“这个产物是否真正让用户更接近他们试图完成的目标”。这就是“评估看起来很棒”与“用户讨厌它”之间产生大多数分歧的地方。
安全性是人们直到吃亏后才重视的维度。智能体是否从环境中泄露了密钥？它是否在没有询问的情况下执行了破坏性命令？它是否接受了从抓取的自述文件中注入的提示词？它是否开启了一个窃取数据的拉取请求？对于聊天机器人而言，安全性主要意味着“它是否说了一些 e
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
