Claude 4 在 2025 年发布时包含 Opus 4 与 Sonnet 4，官方重点展示了编程、复杂推理、长时间任务和工具使用能力。进入 2026 年后，Claude 家族已经出现更新型号，因此今天搭建 Claude 4 考核体系的意义，不是证明旧模型仍然“最强”，而是建立一套能比较版本、提示和系统变化的方法。
模型会更新，业务任务更会变化。真正耐用的资产不是某次跑分，而是一组来源清楚的测试题、明确评分规则、稳定执行环境和可解释的失败记录。
## 先定义考什么工作
不要从公开榜单反推自己的业务。先列出系统真正承担的任务，例如代码修复、合同字段抽取、客服检索、研究摘要或多工具数据整理。
每个大任务拆成可观察步骤。一个研究代理可能要理解问题、选择来源、调用检索、提取证据、形成结论和正确引用。最终答案错了，仅记“失败”无法知道应改提示、工具还是检索。
建立能力地图时，为每项任务写清输入、输出、可用工具、最长执行时间、失败后是否可重试，以及谁对最终结果负责。只有边界一致，不同模型结果才可比较。
## 把成功标准写成可评分规则
Anthropic 当前评测文档强调，成功标准应具体、可测、可实现且与用途相关。对字段抽取，“看起来不错”不是标准；“必填字段全部存在、数值与原文一致、JSON 可解析”才是。
一个任务通常有多维要求。分别评估事实、格式、完整性、引用、工具选择、延迟和成本，不要急着合成一个总分。总分可能让严重事实错误被语气与格式高分掩盖。
先设置硬门槛，再比较软指标。例如事实错误为零是发布条件，通过后再看表达质量和速度。对代码任务，测试通过与无越权文件修改是硬门槛，代码风格则是次级指标。
## 测试集要来自真实分布
从历史任务中抽样，覆盖常见、长尾和失败案例。按输入长度、语言、领域、工具数量和难度分层，避免一百道相似短题制造虚假信心。
将数据分为开发集、回归集和隐藏测试集。开发集用于调提示，回归集在每次变更时运行，隐藏集只在阶段验收时使用。若团队反复查看隐藏集答案，它很快就会变成另一个开发集。
新增线上失败时，先确认它代表可复现问题，再清理敏感信息并加入回归集。测试集由真实错误持续增长，考核体系才会跟着产品成熟。
## 代码评分优先于主观评分
能用程序验证的项目，尽量不要交给人或另一个模型猜。JSON 模式、字段类型、数值、文件差异、单元测试、链接状态和工具参数都适合代码评分。
代码评分速度快且结果稳定，但只能检查被明确表达的规则。测试全部通过不代表需求完整，因此要同时保留少量人工审查，观察可读性、遗漏和不可预见的副作用。
对开放式总结，可将事实拆成必含点与禁错点，再用字符串、检索证据或结构化判断评分。不要只用 ROUGE 等表面相似度判断语义质量。
## 模型评分要先校准评分者
复杂表达、相关性和叙事质量可以使用模型评分，但评分提示需要明确量表和失败条件。Anthropic 文档建议提供具体 rubric，并让输出保持可解析。
先取一批人类已标注样本，比较模型评分与人工判断的一致性。若某类答案经常误判，调整规则或交回人工。评分模型、版本与参数也要固定，因为评分者升级同样会改变成绩。
避免让被考模型直接评价自己且没有对照。可以使用独立模型、成对盲评或多名评分者，并抽样检查理由。模型评分适合扩量，不等于自动获得客观真理。
## 单独考核工具使用
Claude 4 发布时强调工具并行和在推理过程中调用工具。评测不能只看最后答案，还要记录选择了哪个工具、参数是否正确、调用顺序、失败后如何恢复，以及有没有不必要调用。
为工具准备模拟环境和固定返回值。测试“库存为零”“接口超时”“结果为空”“两个工具冲突”等情况，避免直接连接生产系统造成不可控副作用。
正确拒绝行动也应得分。信息不足时先询问、工具返回异常时停止提交、需要确认时不越过人类，这些都属于任务正确性，而不是模型不够积极。
## 长流程要检查中间状态
智能体任务可能执行几十步。最终偶然成功，不能掩盖中途重复调用、丢失约束或错误恢复。保存每一步观察、工具请求、结果、状态摘要和累计成本。
设置中间检查点，例如计划形成、第一轮检索、修改文件前和提交结果前。检查目标是否漂移、证据是否支持下一步、剩余预算是否合理。
注入可控故障测试恢复能力：让一个工具暂时失败、让文件版本变化、让检索返回冲突资料。好的系统会重新判断或回退，而不是继续沿着失效计划执行。
## 长上下文不是把资料塞满
Claude 4 系列以长任务能力受到关注，但上下文越长，评测越要检查证据利用。准备包含相关、相似但错误、过期资料和无关噪声的文档包，观察模型能否引用真正支持结论的片段。
分别测试关键信息位于开头、中间和末尾，防止位置偏差。要求答案携带可核验引用，并自动检查引用是否存在、是否真的包含对应事实。
对同一问题比较完整资料包与检索后小资料包。若检索方案质量相同、成本更低且引用更准，就没有必要把所有文档直接放进上下文。
## 稳定性要通过重复运行测量
生成模型具有随机性。一个样本成功一次不代表稳定。对关键测试重复运行三到五次，记录完全通过率、最差一次和输出差异。
固定温度和采样参数只能减少变量，不能消除模型服务与工具环境变化。报告平均成绩的同时展示失败分布，尤其关注同一输入时好时坏的脆弱任务。
通过改写措辞、调整顺序、加入无关段落和制造轻微拼写错误做鲁棒性测试。若意思不变的小改动导致结果剧烈变化，应优先改善系统边界而不是继续润色理想提示词。
## 成本与延迟属于考核
Opus 与 Sonnet 类模型的能力和资源定位不同。一个模型正确率略高，却让每个合格任务成本翻倍或尾部延迟无法接受，未必适合全部流量。
记录输入输出词元、缓存命中、工具次数、重试、端到端延迟和人工介入。按最终合格结果计算成本，而不是按单次模型调用计算。
可以采用分层路由：普通任务使用成本较低的模型，复杂或验证失败时升级。路由本身也要评测误判率，避免小模型失败后多次重试反而更贵。
## 建立版本迁移考试
考核 Claude 4 的最大长期价值，是为新型号提供对照。当替换模型时，固定提示、工具、测试集和评分器运行一次；再根据新模型特点调整提示，运行第二次。
第一轮回答模型本身发生了什么，第二轮回答经过合理适配后系统能达到什么。若直接同时换模型和提示，就无法区分升级收益与工程修改。
当前 Claude 平台仍强调在提示工程前先定义成功标准和经验测试。这一原则比具体型号更持久。迁移不是看供应方总榜单，而是看自己的硬门槛、错误类型、成本和长尾是否改善。
## 一个月搭建路线
第一周选两个高频任务，定义输入输出契约与十到二十个硬门槛。第二周从历史记录建立一百条分层测试，完成代码评分和人工标注样本。
第三周加入工具故障、长上下文噪声和重复运行，形成稳定性报告。第四周将当前生产模型与一个候选型号盲测，记录质量、成本、延迟和人工复核。
不要在一个月内追求覆盖所有业务。先让一套考试可重复执行、能指出失败位置，再扩展任务。评测体系越能解释“为什么错”，越能指导下一步工程。
## 考核的是系统，不只是Claude
模型成绩受到提示、检索、工具、评分器和运行环境共同影响。把 Claude 4 单独拉出来问几道题，只能得到演示印象，不能预测生产表现。
成熟的考核体系会保留模型能力对照，同时追踪完整任务。从 Claude 4 到后续型号，题库和标准持续存在，团队就不必每次升级都从感觉出发。
## 参考资料