一张跑分表改了三版，我花一个通宵把选型流程重做了一遍

今天早上，老周甩过来一张截图。

GPT-6 Astra 幻觉率那一栏，从 2% 又跳回了 4.2%。老周是我们一个客户的技术负责人，团队做 OPC 外包开发，给几个企业客户跑 AI Agent 服务。上周他刚写了内部评估报告，原话是“Astra 幻觉率降了一半，这条线可以切”。

今天他跟我说：报告先别往上递。

我理解他的火气。GPT-6 Astra 从 9 月 3 号发布那天起，就没消停过。博客先挂出来，然后撤了，页面长时间打不开。官方先说内容管理系统故障，后来说互联网中断，还特意声明撤稿跟跑分无关。结果博客重新上线之后，Astra 幻觉率从 4.2% 改成 2%，过了几天又调回 4.2%。顺带着，GPT-5.6 Sol 的幻觉率、内部网络安全评测成绩也动过。连 Anthropic 那边部分成绩也出现下调后再回升的情况，有些数字调整甚至还早于首次发布博客之前。

官方口径是“确保数据代表模型可用性能的最佳估计”，加上测试条件会影响结果。这话字面上没毛病，但一个开发者看到的是：我拿来做技术选型的那张表，一周内变了三版。这不是跑分误差，这是选型依据在塌。

背景：跑分表一改，选型报告就废了

老周的团队之前一直跑 GPT-5.6 Sol，账单稳定，客户体感也稳。GPT-6 Astra 发布那几天，他确实动过心。官方博客里 Astra 幻觉率降到 2%，比 Sol 低一半，网络安全评测看着也漂亮。团队里有人提议，生产链路从 Sol 迁到 Astra，先切一个低风险客户试跑。

老周原话是：跑分都这样了，不切是不是有点保守。

但他没来得及提交切换方案，跑分就开始变了。先涨后跌，再涨回去，中间还夹着博客页面打不开的混乱。他的团队坐不住了：如果输入条件一周内变三版，那基于这张表的任何评估结论，都像在流沙上盖房子。

这里有个值得关注的细节。跑分变动本身不是最严重的问题，最严重的是没有一份公开声明说清楚，哪次更改对应哪个测试条件。业内人士已经在呼吁，修改成绩时明确说明评测条件变化。但现阶段，这个规范还没成为行业默认动作。

当时怎么做：不追跑分，先搭自己的压测集

老周干了件事。他把原本要递的切换评估报告撕了，没去追跑分为啥变——他说那是 OpenAl 和 Anthropic 的公关问题，不是他一个 OPC 团队能解决的。

他把团队里两个后端和一个测试叫过来，花一个下午搭了一套自己的场景化压测集。

这件事本身不玄乎。老周的客户生产环境里已经跑过几千条真实任务，他从里面抽出 2000 条，分成四类：长文档摘要、SQL 生成、API 参数填充、Agent 流程断点续跑。每类跑一遍 Astra 和 Sol，不打总榜，分别看四个维度：幻觉率、指令遵循、响应时延、单次调用成本。

关键一步是，他把这套压测代码固化成了 CI 流水线的一部分。以后任何模型想进他的生产链路，先过这套 case，数据不达标就直接按掉，不用开会讨论。

我当时也在场，印象最深的是他说的那句话：官方跑分是宣传物料，不是技术验收单。 这话听着糙，但落到 OPC 团队身上特别真实——你要对客户的可用性负责，但没人对那张跑分表负责。

结果如何：选型不再看单点分数，改看场景一致性

压测跑下来的结论跟官方叙事不太一样。

Astra 在代码补全这类任务上确实比 Sol 强，尤其是长上下文里 Agent 断点续跑，稳定性有肉眼可见的提升。但摘要和 SQL 生成两类任务上，差距没那么大，有些 case 里 Sol 的指令遵循反而更稳。而 Astra 单次调用的成本，在跑批场景里贵了不少。

老周最后的决策是：代码补全优先走 Astra，跑批摘要和参数填充继续留在 Sol。另外立了一条硬规矩——每月复测一次，任何模型跑分变化导致核心指标波动超过 5%，必须走变更评估，不允许直接切换。

他把这套做法写成了团队内部的《模型选型与切换规范》，不到两页纸，但每个字都是踩坑踩出来的。

这事让我重新审视了模型选型这件事的关键变量。过去大家习惯盯着跑分榜，看谁刷得高就切谁。但跑分榜的稳定性本身，现在成了新的风险点。模型还在迭代，评测标准还在变，选型逻辑就得跟着变——从“谁分高用谁”变成“谁的表现在我这个场景里可复现、可追踪、可回退”。

换作读者能抄什么作业：别信一张表，建自己的基线

先把结论放这儿：跑分表可以看，但不能当依据。 你要抄的不是老周那套 code，而是“把选型判断下沉到自己的场景化压测”这个思路。具体到不同模型品牌，我的建议是这样——

GPT。这次跑分反复改本身就是最好的教材。OPC 创业者的启发是：Agent 项目的性能基线要自己建，别拿官方博客当验收标准。哪天它跑分又变了，你慌不慌，取决于你有没有自己的案底。

Claude。Anthropic 部分成绩也出现下调后回升，说明头部几家都逃不开这个坑。但 Claude 在长代码生成和调试场景的口碑依然强，值得作为压测组里的代码质量对照基准，别只当备胎。

Gemini。上下文长，价格策略也比较积极，适合做长文档复盘和 API 成本下界参考。建议全量 case 跑一遍，看成本与质量的平衡点在哪，给自己留一个降本后手。

Qwen。值得关注的是阿里千问开源了 Qwen-Drive-1.0-4B，一个自动驾驶场景的视觉语言模型。这个动作本身说明开源模型正在往垂直场景里钻。启发是：OPC 团队遇到最脏最累的定制化需求，可以优先考虑开源模型做私有微调，不把所有问题都甩给闭源大模型。

DeepSeek。国内 coding 场景性价比和私有化部署的公开口碑都不错。如果客户有数据不出域的硬要求，DeepSeek 和 Qwen、GLM 这几个国内开源模型应该进第一梯队候选列表。

Kimi。长文本心智很稳。如果客户 Agent 任务里大量是长文档摘要、长代码审查、会议纪要整理，Kimi 值得拉进压测组比一比，重点看幻觉率和长上下文断点续跑，不是看综合跑分。

GLM。智谱在国内政企客群里根基不浅，可控性和国产化适配是它的牌。做政企、金融、医疗这类客户的 OPC 团队注意了：这类场景合规要求优先于跑分，项目启动阶段就该把模型适配要求写进合同，别等交付时被打回。

豆包。字节系在 C 端分发和移动端落地上有天然优势。如果 OPC 团队做面向 C 端的对话类产品，模型能力本身不是唯一变量，分发渠道和用户数据回路同样值钱。

MiniMax。低时延交互和情感语音那条路线，在实时客服、语音类 Agent 里值得关注。具体场景要实打实压时延和断线重连，别只测文本生成。

最后给 OPC 创业者和 coding 开发者一个可以抄的动作清单：固定 case 集、四维打分、成本红线、回退机制、每月复测。这套东西一次搭好，能反复用。选型这件事，最怕的不是选错，是每次都重新选一遍。