Anthropic把模型评测做成"盲测餐厅"

2024年，一个团队用Claude Code写了3个月代码，最后发现Sonnet生成的模块漏洞率比Opus高40%——但他们直到生产事故后才意识到。这不是模型能力问题，是评测方法出了问题。

LaunchDarkly和Anthropic最近放出一套工具，让开发者给AI代码生成做"私人定制体检"。不是跑那些通用基准，而是测你的安全规则、你的API规范、你团队特有的技术债模式。

核心逻辑像开盲测餐厅：同一道菜让3个厨师做，评委按你的口味标准打分，吃完才知道谁做的。

这套方案需要搭一个代理服务器，把Claude Code的请求转发到LaunchDarkly。后者根据规则路由到不同模型（Sonnet/Opus/Mistral甚至本地Ollama），同时触发你定义的评测规则。几周后，仪表盘会告诉你：哪个模型在你的代码库上真正靠谱。

代理服务器的工作流程

当Claude Code向POST /v1/messages发请求时，代理会做四件事。提取纯文本提示，把Anthropic的消息格式转成LaunchDarkly的LDMessages，工具块和图片直接丢弃——代码生成场景不需要这些。

路由请求通过LaunchDarkly的AI Configs。代理创建一个带selectedModel属性的上下文，模型选择器根据这个属性匹配目标模型变体。调用模型并触发评测器，如果选中的变体绑定了评测器，SDK按采样率自动调度评分，结果流入Monitoring仪表盘。最后返回标准Messages响应， assistant回复作为单文本块，附带token用量。

Claude Code始终对接本地/v1/messages端点，模型选择和在线评测全在后台完成。开发者体验无感知，数据却在默默积累。

三个实战评测器设计

教程建议搭建三类评测器，对应代码生成的真实痛点。安全漏洞扫描器，检查SQL注入、硬编码密钥、不安全反序列化等你实际在意的风险点。API契约验证器，比对生成代码是否符合你们团队的OpenAPI规范、命名约定、错误处理模式。

范围蔓延检测器，标记那些"过度设计"的代码——比如为简单CRUD引入不必要的抽象层，这是某些模型的典型毛病。LaunchDarkly的评测系统支持用LLM-as-judge模式实现这些：你写一段评分prompt，系统让另一个模型当"裁判"给输出打分。

关键设计：评测标准完全自定义。不是用别人的安全榜单，是你自己的.eslintrc、你的架构评审清单、你上次复盘会总结的5个常见陷阱。

数据积累后的选型逻辑

运行几周后，仪表盘会呈现模型-任务匹配度。可能Sonnet在安全评分上稳定领先，但复杂端点的API契约 adherence（遵守度）不如Opus。可能Mistral在你特定的技术栈上性价比最优，但通用基准里根本测不出来。

这种颗粒度的结论，靠HumanEval或SWE-bench是给不了的。那些基准测的是"平均程序员水平"，你要的是"在我的屎山代码里不翻车"。

教程提供了两种搭建方式：LaunchDarkly仪表盘可视化配置，或Claude Code的agent skills（如果已安装后者更快）。项目创建命令是/aiconfig-projects，建一个名为"custom-evals-claude-code"的项目。模型选择器用/aiconfig-create创建，三个变体分别是Sonnet、Opus、Mistral，消息内容为空——这里只负责路由，不预设对话。

这套方案最狠的设计是"无感知数据收集"。开发者继续用Claude Code正常写代码，每次生成背后都在跑A/B测试。没有额外的评测流程，没有打断心流的问卷，数据自然沉淀。

对比传统做法：团队通常先选一个模型用半年，出问题再换，换的时候也没有系统性证据。或者同时开多个订阅，凭感觉轮换。LaunchDarkly把这个过程工程化了，用实际代码库当测试集，用真实业务规则当评分标准。

一个细节：代理目前只处理text-only的代码生成场景。工具调用、多模态输入被显式过滤——这是务实的边界设定，先解决80%的核心场景，而非追求大而全。

如果你的团队正在多模型之间摇摆，或者对现有选型心里没底，这种"持续评测基建"可能比再跑一轮基准测试更有价值。毕竟，代码生成质量的终极裁判，终究是你自己的生产环境。

你现在用的模型，是基于数据选的，还是基于发布会PPT选的？