新模型发布，排行榜显示 SWE-bench 92%，社交网络刷屏「史上最强编码模型」。你切过去在你的代码库上跑了一圈，结果跟之前差不多——可能还更差。
排行榜说的是 92%，那到底发生了什么？
这篇文章是微软 Agent Experience（AX）系列第六篇，讲的是你在选模型之前必须面对的那个问题：怎么评估哪个模型在你的技术栈上真的管用——以及为什么公开排行榜给不了你答案。
Goodhart 定律：当度量变成目标
「当一个度量变成目标，它就不再是一个好的度量。」Charles Goodhart 在 1975 年讲这句话的时候说的是货币政策，但用在 AI 基准测试上精准得令人不安。
基准分数驱动采纳，采纳压力驱动优化。模型厂商会针对行业关注的评测优化训练管线。这不是系统的缺陷，这是系统按设计在运转。
结果是每一代模型在基准测试形态的问题上都确实变得更强了。但这跟它们在你的问题上的提升有多大关系，是另一回事。
你能从排行榜上区分「模型的确变强了」和「模型只是被针对性优化过」吗？你分不清，除非在没被优化过的任务上——也就是你自己的任务上——亲自评测一遍。
基准测试到底测了什么
以 SWE-bench 为例：模型拿到一个 GitHub issue 和一个仓库快照，需要产出能通过该仓库测试套件的 patch。仓库是知名的开源项目，有真实 bug 和完整测试。
下面这些不在评测范围内：
- 模型从未见过的你的私有 SDK
- 你团队的编码规范和架构模式
- 同时有 12 个扩展在抢上下文的工作空间
- 引导 Agent 行为的指令文件
- 全量扩展栈产生的组合效应
- 多轮次中 Agent 执行代码、读错误、自我修正的迭代流程
一个 SWE-bench 92% 的模型，确实擅长修开源项目里有完整文档描述的 issue。但这跟它在你的内部认证库和你那套覆盖了半数默认行为的 AGENTS.md 面前能不能写出正确代码——没有任何关系。
分布差距
基准测试从一个分布里采样，你的工作生活在另一个分布里。这两个分布之间的重叠决定了一个基准对你有没有任何预测价值。
一个在 Django 上很强的模型，在你那个「看着像 Django 但几处关键逻辑完全不同」的内部框架上可能平平无奇。高基准分不意味着模型在你的场景里一定不好——它只意味着你还不知道好不好。基准没测你的场景，所以这个分数对你的场景不携带任何信息。
基准作为优化目标
更麻烦的是，这个分布差距会随着时间越来越大。
数据重叠：SWE-bench 的任务来自公开仓库的 GitHub issue 和 patch，全是公开数据。模型在公开代码上训练，任务和训练数据重叠是必然的——而且每一代训练都会让更多基准相关代码进入公开语料库。
训练偏好：行业研究基准任务的难点是什么，训练管线就强调什么。如果 SWE-bench 上很多题需要理解测试夹具，训练数据就有针对性地覆盖测试夹具模式。模型还会在跟基准题目格式相似的任务上做微调——「在一个仓库里修 issue」是一种格式，你的任务可能是「用三个内部库按团队约定搭一项功能」。模型在基准形状的任务上变强的速度，远远快于在你的任务上变强的速度。
结果就是：基准分数涨得比真实效果快。两代之间分数的提升，一部分是真实能力的增长，另一部分只是格式层面的专项优化。
Harness 问题
就算一个基准完美代表了你的任务，还有另一层差距：harness——也就是组装上下文和调度执行的框架。
大多数基准用的是极简 harness：给模型仓库、issue，让它产出一个 patch。没有 MCP Server 返回 API 文档，没有指令文件引导行为，没有 skill 提供引导式工作流，没有来自其他 50 个文件的上下文。模型在一个跟你真实开发环境毫无相似之处的洁净间里操作。
一个在极简 harness 下拿高分的模型，在复杂环境里可能因为处理不了长上下文、或者在工具密集时做不好选择而表现更差。反过来也可能：一个基准分低一点的模型在你的 harness 下反而更强，因为它更擅长复杂上下文和工具密集环境。
哪个模型「更好」？答案取决于环境。基准只测了一种环境，你运行在另一种里。
基准测试的正确用法
尽管上面说了这么多，基准还是有用处的。高分至少告诉你模型有基线编码能力——它能推理代码、跨文件产出可工作的 patch。SWE-bench 30% 的模型大概率不适合生产，90% 的模型大概率有处理复杂任务的原始能力。
分数不能告诉你的是：这种能力在你的任务、你的扩展、你的 harness 里能不能转化为真实效果。把基准分数当作「必要但不充分」的过滤器：帮你缩小候选范围，但不帮你做最终决策。
适合用基准做什么：
- 淘汰明显不够格的模型
- 判断新版本是否出现了回归（当前模型 85%，新版跌到 70%，肯定哪里有问题）
- 粗略判断能力级别（小模型 vs 大模型、代码专项 vs 通用）
不适合用基准做什么：
- 决定哪个模型在你的技术栈上效果最好
- 预测 5 分上涨能不能改善你的产出
- 没做自己的评测就直接拍板换模型
怎么跑自己的评测
和本系列第三篇文章的方法论一样：用你自己的场景做受控对比。不再比较「有扩展 vs 无扩展」，而是比较模型 A vs 模型 B，同样的 prompt、同样的工作区、同样的扩展、同样的评判标准。
注意，这个评测结果可能跟基准恰好相反。模型 A 在 SWE-bench 上 92%，模型 B 只有 88%。但在你的场景里，模型 B 成本更低、输出更好——因为它对你的私有 SDK 处理更准确，更严格遵循你的指令文件。基准没错，它只是没测对你重要的东西。
从 5-10 个场景开始：挑你日常开发里最常见、最有代表性的任务。太简单每个模型都能做对的没有区分度，太复杂每个模型都搞不定的也没有区分度。要的是中间的：模型能力直接决定结果的任务。
比较四个维度：
- 输出质量：哪个模型产出更多符合标准的正确结果
- 成本：哪个模型用了更多 token 和轮次。产出稍微好一点但 token 成本高 3 倍，可能不是正确的选择
- 一致性：同一个场景反复跑，哪个模型结果更稳定。这次 90% 下次 60% 的，比稳定 75% 的更难落地
- 扩展响应性：模型是否听从你的指令文件、有效使用你的工具。一个能力更强但不听引导的模型，可能不如一个能力稍弱但严格循规的模型
变化时重跑：新模型发布、harness 调整、扩展更新——任何一个变化都可能让上次的评测结果失效。把评测做成可重复的流程，而不是一次性调查。新版本一亮排行榜，你几小时内就能拿自己的场景跑出一份跟实际使用相关的结论。
组织层面的坑
这在团队层面也会重演。管理层看到排行榜，选最高分的模型，然后自上而下要求切换。这个决策来自基准数字，不是来自对团队实际工作负载的评测。
结果：切换模型后，一些东西悄悄地坏了——之前管用的指令文件不管用了、工具选择模式变了——但没人把这些问题跟模型切换联系在一起，因为「它基准分数更高」。在切换整个团队到一个对你们特定工作流效果更差的模型之前，花在跑 5 个场景上的时间是一个几乎可以忽略的成本。
小结
基准测的是在特定公开任务上的通用能力。它无法告诉你模型在你的扩展和私有代码下的表现，也无法告诉你它是否尊重你团队的约定。优化压力让这个差距越来越明显——基准分数涨得比真实效果快。
用基准做过滤，用自己的评测做决策。跑的和你测扩展提升时相同的场景，只是把比较对象从「有扩展 vs 无扩展」换成「模型 A vs 模型 B」。结果是你唯一跟实际产出对应的信号。
如果你关注 AI 助手、开发工具和软件工程实践，可以关注 Aide Hub。这里会继续分享能落地的工具教程、技术观察和项目经验。