2. Linux.do
  3. 记一次对 Claude Fable 5、Opus 4.8、Minimax M3、Xiaomi Mimo V2.5 系列、Hy3、Qwen3.7 系列的真实项目需求的横向评测（榜首更迭！）

记一次对 Claude Fable 5、Opus 4.8、Minimax M3、Xiaomi Mimo V2.5 系列、Hy3、Qwen3.7 系列的真实项目需求的横向评测（榜首更迭！）

SmallMain 2026-06-11 17:22 1

由于测试的模型越积越多了，表格会删除一些同厂商的旧模型，你可以在之前的评测帖子里找到它们的成绩。



项目


这是一个 Unity C# 项目，我进行测试的是一份皮肤系统需求案，我已经做了好预制体，而模型需要编写代码。


本轮与上两轮评测的项目和环境都完全一致：



  • 第一轮

  • …

  • 上一轮


模型来源



  • Claude 系列模型: 官方 API

  • Mimo V2.5 系列模型: 官方 Token Plan

  • Hy3 Preview: 官方 API

  • Qwen3.7 系列模型: 官方 API

  • Minimax M3: 官方 API

  • Nex-N2-Pro: OpenRouter Free API

  • Nemotron 3 Ultra: OpenRouter Free API


速度












































































































































































































































排名 模型 时间（分钟） 备注
1 Grok 4.20 0309 Reasoning 3
2 Step-3.5-Flash 6
3 Mimo V2 Omni 7
4 Doubao-Seed-2.0-Lite 7
5 Doubao-Seed-2.0-Pro 9
6 Doubao-Seed-2.0-Code 9
7 Qwen3-Coder-Next 9
8 Claude Sonnet 4.6(high) 9
9 Qwen3.5-Plus 9
10 GLM-5 Turbo 10
11 Minimax M2.7 10 Highspeed 版本
12 Qwen3.5-Flash 10
13 Gemini 3 Pro 11
14 Hy3 Preview 13
15 GPT-5.5(low) 13
16 GPT-5.5(medium) 15
17 Mimo V2 Pro 15
18 DeepSeek V4 Flash 17
19 Qwen3.7-Plus 17
20 Qwen3.7-Max 18
21 GPT-5.5(high) 19
22 Claude-Opus-4.7(Max) 20
23 GLM-5 20
24 DeepSeek V4 Pro 21
25 Gemini 3 Flash 22
26 Claude-Fable-5(xhigh) 23
27 Mimo V2.5 24
28 KAT-Coder-Pro V2 24
29 Minimax M3 25
30 Claude-Opus-4.6(Max) 26
31 GPT-5.5(xhigh) 28
32 Gemini 3.1 Pro(high) 29 受 429 请求频率限制影响
33 Claude-Opus-4.8(Max) 33
34 Kimi K2.6 33
35 Qwen3.5 9B GGUF Q4_K_XL 35 MBP M4 Pro 48GB 本地部署
36 Qwen3.5 35B A3B GGUF Q4_K_XL 36 MBP M4 Pro 48GB 本地部署
37 Mimo V2.5 Pro 37

令牌数



  • Claude-Fable-5(xhigh): 7.1M

  • Claude-Opus-4.8(Max): 13M

  • Mimo V2.5 Pro: 未知

  • Mimo V2.5: 未知

  • Hy3 Preview: 1.4M

  • Qwen3.7-Max: 4.6M

  • Qwen3.7-Plus: 4.2M

  • Minimax M3: 未知

  • Nex-N2-Pro: 退赛

  • Nemotron 3 Ultra: 退赛


代码行数



  • Claude-Fable-5(xhigh): +1520, -7

  • Claude-Opus-4.8(Max): +1347, -22

  • Mimo V2.5 Pro: +1682, -14

  • Mimo V2.5: +1270, -8

  • Hy3 Preview: +1246, -8

  • Qwen3.7-Max: +1529, -6

  • Qwen3.7-Plus: +1532, -7

  • Minimax M3: +2284, -137

  • Nex-N2-Pro: 退赛

  • Nemotron 3 Ultra: 退赛


完成度


Claude-Fable-5(xhigh)


审查结论: 完成度非常高，仅有一个细节问题。




详细

  • 中：启动 useSkins 只记录使用中 ID，没有登记为已拥有。 Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:82 的

    InitUseSkins 只写 _usingSkins；而 Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:363 请求列表后立刻刷新界面。网络返

    回前，当前使用皮肤会被判定为未拥有，出现“去获取”、置灰、无剩余时间等错误首帧状态。



Claude-Opus-4.8(Max)


审查结论: 完成度很高，虽然存在常见错误，但在最后列出了该处理需要确认；另有一个细微实现不一致。




详细


  • 高：皮肤列表拉取的类型映射不成立，非神针皮肤可能一直被判定未拥有。

    UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:232 打开时只调用 ReqSkinList()，而

    UnityProject/Assets/GameScripts/HotFix/GameLogic/NetMgr/Skin/SkinNetMgr.cs:33 默认发送 SkinType = 0。但协议枚

    举里 UnityProject/Assets/GameScripts/HotFix/GameProto/GameProtocol/P_skin.cs:14 的 0 是 SKIN_NEEDLE，不是“全

    部”。同时 UnityProject/Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:117 每次响应会清空所有

    owned 数据。结果是称号/头像框/气泡框 owned 状态、按钮三态、onlyHas、属性总览都会错。




  • 中：倒计时使用本机 UTC 时间，没走项目服务器时间。

    UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:706 用 DateTimeOffset.UtcNow 计算过期

    时间。项目已有 RealityTimeSys 维护服务器时间偏移，本机时间不准时会把限时皮肤显示成错误剩余时间或已过期。





Mimo V2.5 Pro


审查结论: 存在常见错误，有几处与需求/线上实现不一致的功能缺失。




详细


  1. Assets/GameScripts/HotFix/GameLogic/GameApp_RegisterSystem.cs:31 未注册 SkinSys.Instance。

    这会导致 SkinSys.OnStart() 不执行，S2C_HOME_INFO.UseSkins 不会初始化，SkinNetMgr 的列表/使用响应也不会被转发成 SkinUI 监听的 Event_SkinDataUpdate /

    Event_SkinUseChanged。结果是打开 SkinUI 后请求虽然发出，但响应回来 UI 不会自动刷新，默认选中使用中皮肤也失效。线上基线这里有

    AddLogicSys(SkinSys.Instance)。




  2. Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:352 切换页签时没有保证选中项属于当前页签。

    SwitchTab() 只刷新内容，不检查 _selectedSkinId 是否在当前类型可见；如果从神针切到称号/头像框，可能继续用上一个类型的 skinId 渲染当前页签预览和按钮状

    态，不满足“选中项不可见时自动回退到使用中皮肤”。




  3. Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:640 称号预览资源用错。

    称号页同时显示称号和建筑，但当前代码把“称号皮肤自己的资源”也设置给 m_imgBuilding。线上实现是称号背景用当前称号皮肤，建筑用当前正在使用的神针皮肤。当

    前实现会让建筑预览显示错误资源。




  4. Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:692 称号未拥有置灰不完整。

    GetActivePreview() 在称号类型只返回 m_goTitlePreview，但称号需求是 m_goTitlePreview + m_goBuildingPreview 同时展示；未拥有时建筑预览不会被置灰。




  5. Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinAttrUI.cs:67 属性总览依赖缓存的 TotalAttrs，不是实时聚合“所有正在使用皮肤”。

    Assets/GameScripts/HotFix/GameLogic/NetMgr/Skin/SkinNetMgr.cs:67 只有列表响应且 Count > 0 才更新总属性；使用皮肤成功后不会重算/清空，总览可能显示旧

    属性或空数据。





Mimo V2.5


审查结论: 无法编译，且存在严重的功能错误和与需求/线上实现不一致的功能缺失。




详细


  1. 编译失败：

    Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:12 继承 Singleton，但未 using GameBase;；Assets/

    GameScripts/HotFix/GameLogic/System/Skin/SkinSys.cs:10 继承 BaseLogicSys 也未引入 GameBase。当前会直接 CS0246。




  2. 皮肤类型映射整体错误：

    Assets/GameScripts/HotFix/GameLogic/CfgMgr/Skin/SkinCfgMgr.cs:27 把 2/3/4 定义成 称号/头像框/气泡框，但配置表是 1神针/2头像框/3气泡/4

    称号；协议枚举又是 0~3，见 Assets/GameScripts/HotFix/GameProto/GameProtocol/P_skin.cs:14。Assets/GameScripts/HotFix/GameLogic/NetMgr/

    Skin/SkinNetMgr.cs:26 请求和 Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:36 存储都没有做协议/配置转换，页签、列

    表、使用状态都会错位。




  3. 单类型拉取会清空全量已拥有数据：

    Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:47 每次 S2C_SKIN_LIST 都 _ownedSkins.Clear()，但需求明确接口只返回当前

    类型拥有皮肤。切换页签后其他类型拥有状态会丢失，属性总览也无法稳定聚合所有使用中皮肤。




  4. 属性总览不满足需求：

    Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinAttrUI.cs:81 依赖 _usingSkins 里的 Attrs，但启动 useSkins 初始化没有 attrs；

    Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinAttrUI.cs:136 又直接 $“+{totalValue}”，没有按属性类型格式化百分比/万分比。




  5. UI 行为多处偏离验收：

    onlyHas 是全局布尔 Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:135，不是按类型独立；列表刷新总是重选使用中/第一个

    Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:346，不会保留仍可见的当前选择；世界/城镇切换 interactable 逻辑反了 Assets/

    GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:616。




  6. 事件生命周期泄漏：

    Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:187 直接用 GameEvent.AddEventListener 注册 UI 事件，但 Assets/GameScripts/

    HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:240 没有移除；反复打开界面会留下旧实例回调。





Hy3 Preview


审查结论: 无法编译，且存在严重的功能错误和与需求/线上实现不一致的功能缺失。




详细


  1. 编译失败：SkinUI.cs 有两个同签名 UpdatePreviewTypeSelect()，并且文件末尾多出闭合括号。见 Assets/GameScripts/HotFix/GameLogic/UI/

    PlayerInfo/SkinUI.cs:566、Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:671。




  2. 编译失败：协议字段用错。生成协议里是 SkinId、SkinType、SkinList，但实现大量使用不存在的 Id、Type、Skins，并引用不存在的

    SkinInfoProto。见 Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:34、Assets/GameScripts/HotFix/GameLogic/NetMgr/Skin/

    SkinNetMgr.cs:28、Assets/GameScripts/HotFix/GameLogic/System/Skin/SkinSys.cs:49。




  3. SkinSys 没有注册，系统生命周期不会启动，S2C_HOME_INFO.useSkins、使用状态更新、皮肤列表响应都不会被消费。线上基线原本有

    AddLogicSys(SkinSys.Instance)，当前文件缺失。见 Assets/GameScripts/HotFix/GameLogic/GameApp_RegisterSystem.cs:30。




  4. 玩家信息页入口被回退成“当前版本暂不支持”，没有打开 SkinUI，与需求“点击皮肤按钮打开皮肤管理界面”直接冲突。见 Assets/GameScripts/HotFix/

    GameLogic/UI/PlayerInfoUI/PlayerInfoUI.cs:310。




  5. 属性功能基本未实现。SkinCfgMgr.GetSkinAttributes() 仍是 TODO 且固定返回空列表，导致 SkinUI 属性区域和 SkinAttrUI 总览都不会显示真实加

    成。见 Assets/GameScripts/HotFix/GameLogic/CfgMgr/Skin/SkinCfgMgr.cs:139、Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/

    SkinUI.cs:590。




  6. 资源加载、跳转、预览细节仍是占位。列表图标、名称背景、预览图都没有实际加载；“去获取”只打日志不跳转；头像框/气泡/称号预览也有 TODO。见

    Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:137、Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:402、

    Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:548。





Qwen3.7-Max


审查结论: 较多功能错误和与需求/线上实现不一致的功能缺失。




详细


  1. UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfoUI/

    PlayerInfoUI.cs:310 皮肤入口仍弹“当前版本暂不支持”，没有打开

    SkinUI。需求要求从玩家信息界面进入皮肤管理，这会直接阻断功能。




  2. UnityProject/Assets/GameScripts/HotFix/GameLogic/

    GameApp_RegisterSystem.cs:30 SkinSys 未注册。线上基线这里有

    AddLogicSys(SkinSys.Instance)，当前分支删掉后，

    S2C_HOME_INFO.useSkins 不会被消费，当前使用皮肤状态无法初始化。




  3. UnityProject/Assets/GameScripts/HotFix/GameLogic/CfgMgr/Skin/

    SkinCfgMgr.cs:70 配置类型到协议类型映射错误。配置是 1神针/2头像

    框/3气泡/4称号，协议是 0神针/1称号/2头像框/3气泡，当前用 cfgType -

    1 会把称号请求成气泡、头像框请求成称号、气泡请求成头像框，列表和使

    用状态都会错位。




  4. UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/

    SkinUI.cs:228 皮肤列表/使用事件注册为无参回调，但 UnityProject/

    Assets/GameScripts/HotFix/GameLogic/NetMgr/Skin/SkinNetMgr.cs:67

    发送的是带 response 参数事件。该事件系统按签名匹配，Action 不会收

    到 Action 事件，因此 SkinUI 收到服务器响应后不会刷新列表。




  5. UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/

    SkinUI.cs:133 onlyHas 是单个 _onlyHas 状态，并且切页时在

    UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/

    SkinUI.cs:325 被重置。需求要求“按类型独立”的内存态，当前不满足。




  6. UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/

    SkinAttrUI.cs:98 属性总览合并时只累加数值，丢失属性 Type/NumType，

    最终 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/

    PlayerInfo/SkinAttrUI.cs:203 固定显示 +{value}，百分比类属性会显示

    错误。





Qwen3.7-Plus


审查结论: 无法编译，且存在严重的功能错误和与需求/线上实现不一致的功能缺失。




详细


  1. 阻断编译：SkinUI 使用了 DateTimeOffset，但文件没有 using System; 或 System.DateTimeOffset 限定名。

    Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:815




  2. 线上已有的 SKIN_VIEW / SKIN_EXPIRE、未查看红点、过期处理链路被删掉了。当前 SkinNetMgr 只注册 list/use，而线上仍有 view/expire

    注册与处理；这正中指南的高频雷区。

    当前：Assets/GameScripts/HotFix/GameLogic/NetMgr/Skin/SkinNetMgr.cs:17

    线上：/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/wt-383eb613/UnityProject/Assets/GameScripts/HotFix/

    GameLogic/NetMgr/Skin/SkinNetMgr.cs:17




  3. S2C_HOME_INFO.useSkins 只写入 _usingSkinIds，没有把使用中的皮肤登记为拥有/使用状态；启动后在未拉取对应 tab 列表前，IsSkinOwned/

    IsSkinUsing 都可能返回 false，入口头像框、列表排序、默认选中和 action 状态会错。

    Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:35




  4. SkinDataMgr.UpdateSkinList 只增量覆盖服务器返回项，不清理同类型旧拥有项；过期或失效皮肤不再出现在 S2C_SKIN_LIST 时，本地仍会认

    为已拥有。totalAttrs 也只在非空时更新，变为空时会保留旧属性。

    Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:64




  5. 属性总览没有按需求从“所有正在使用皮肤”聚合，而是依赖最近一次 S2C_SKIN_LIST.TotalAttrs。未打开过列表、刚切换使用皮肤、或服务端返

    回空属性时，弹窗会为空或 stale。

    Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinAttrUI.cs:80




  6. 称号预览把称号资源同时加载到 m_imgTitleBg 和建筑预览 m_imgBuilding，建筑区域会显示错误资源；线上实现是称号背景 + 当前使用神针建

    筑预览。

    Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:664





Minimax M3


审查结论: 存在部分功能错误和与需求/线上实现不一致的功能缺失；但在最后特别说明了协议枚举值调整的破坏性和服务器需要同步更新枚举值这一点，显示了对问题的理解。




详细


  1. 高：协议类型映射被单边改成配置值，和指南/线上基线

    不一致。

    Proto/skin.proto:8 与 UnityProject/Assets/

    GameScripts/HotFix/GameProto/GameProtocol/

    P_skin.cs:14 把 SkinType 改成 1/2/3/4；

    UnityProject/Assets/GameScripts/HotFix/GameLogic/

    NetMgr/Skin/SkinNetMgr.cs:36 直接发送该值，没有

    cfg/server 映射。指南明确要求核对“配置 1~4 vs 协议

    0~3”，线上也有转换逻辑。结果会导致神针/称号请求和

    回包类型错位。




  2. 中：属性总览不是“正在使用皮肤”的配置聚合。

    UnityProject/Assets/GameScripts/HotFix/GameLogic/

    UI/PlayerInfo/SkinAttrUI.cs:73 通过请求所有类型列

    表，再读 UnityProject/Assets/GameScripts/HotFix/

    GameLogic/DataMgr/Skin/SkinDataMgr.cs:216 的

    TotalAttrs。但协议注释是“所有已拥有皮肤的属性总

    和”，需求要求“当前玩家所激活/使用的所有类型皮肤”。

    这会把未使用但已拥有的皮肤属性算进去。




  3. 中：onlyHas 没有按类型独立保存。

    UnityProject/Assets/GameScripts/HotFix/GameLogic/

    UI/PlayerInfo/SkinUI.cs:128 只有一个 _onlyHas，切

    换页签时不按类型恢复状态，UnityProject/Assets/

    GameScripts/HotFix/GameLogic/UI/PlayerInfo/

    SkinUI.cs:1251 也只改全局值。需求要求每个皮肤类型

    独立内存态。




  4. 中：称号预览资源和建筑预览不符合需求。

    UnityProject/Assets/GameScripts/HotFix/GameLogic/

    UI/PlayerInfo/SkinUI.cs:616 给建筑图加载了称号皮肤

    的 homeShowUrl，而不是当前神针/建筑资源；

    UnityProject/Assets/GameScripts/HotFix/GameLogic/

    UI/PlayerInfo/SkinUI.cs:644 又用 item icon 当称号

    背景。称号页要求“称号 + 建筑同时展示”，这里资源语

    义错。




  5. 低：页签克隆没有设置页签文案。

    UnityProject/Assets/GameScripts/HotFix/GameLogic/

    UI/PlayerInfo/SkinUI.cs:273 克隆 4 个页签但没有写

    text 子节点，可能导致四个页签显示模板原文，线上基

    线是显式写入“神针/称号/头像框/气泡框”。





最终总结









































































































































































































































排名 模型/层级 说明
Tier 0 该等级的模型实现与线上基线高度一致。
1 Claude-Fable-5
2 GPT 5.5(xhigh)
Tier 1 该等级的模型的代码正确完整且可编译，仅少量边界问题或轻微不一致。
3 Claude Opus 4.8(Max)
4 GPT 5.5(high)
5 Kimi K2.6
6 GPT 5.5(low)
7 GPT 5.5(medium)
8 Claude Opus 4.6(Max)
9 Claude Sonnet 4.5
Tier 2 该等级的模型的代码至少可编译或仅极少量的语法错误，但是存在明显功能错误、遗漏或与需求/线上不一致。
10 GLM 5.1
11 Minimax M3
12 Mimo V2.5 Pro
13 GLM 5
14 Kimi K2.5
15 Claude Sonnet 4.6(high)
16 Qwen3.7-Max
17 Qwen3.5-Plus
18 KAT-Coder-Pro V2
19 DeepSeek V4 Pro(max)
Tier 3 该等级的模型的问题很多且无法编译，或者存在不少幻觉。
20 DeepSeek V4 Flash(max)
21 Claude Opus 4.7(Max)
22 Qwen3.7-Plus
23 Mimo V2.5
24 Hy3 Preview
25 GLM 5 Turbo
26 Gemini 3.1 Pro(high)
27 Mimo V2 Pro
28 Mimo V2 Omni
29 Minimax M2.7
30 Step-3.5-Flash
31 Qwen3-Coder-Next
32 Gemini 3 Pro
33 Gemini 3 Flash
34 Doubao-Seed-2.0-Code
35 Doubao-Seed-2.0-Pro
36 Doubao-Seed-2.0-Lite
37 Qwen3.5-Flash
38 Qwen3.5 35B A3B GGUF Q4_K_XL
39 Qwen3.5 9B GGUF Q4_K_XL
40 Grok 4.20 0309 Reasoning

Claude-Fable-5(xhigh)：



  • 速度超过 Claude-Opus-4.6(max) 与 GPT-5.5(xhigh)

  • 完成度非常高与 GPT-5.5(xhigh) 相当，仅存在一个体验细节问题


终于 Claude 站起来了，不仅是 Claude 的首个 T0 模型，且接替 GPT-5.5 成为榜首。


当然我要重申，它们都能比较完整地做完这个需求，能力差不多，所以是按照模型发布日期来排名的（虽然它其实比 GPT-5.5 要快）。


我已经有点怀疑是否应该将评审员从 GPT-5.5 换为 Claude-Fable-5 了。


Claude-Fable-5 在做完需求后还有一段 “需向你确认的事项”，对某些奇怪的实现细节（比如皮肤配置枚举

值与服务器枚举值不同、时间戳单位猜测）还有自己不确定的地方进行了汇总，给人的感觉是对于这个需求它游刃有余，

一切尽在掌握；需求未说明自己决定的地方都放在最后列出以进行核对，这是比较难得的。


但是 Claude-Fable-5 的安全方面确实非常敏感，测完之后，正好我在做的 VS Code 扩展有一个大需求，

使用 AI 完成后怕遗漏会再用 AI 审查一遍，但 GPT-5.5 会经典地出现自己审查自己永远有问题的情况，

于是我想使用 Fable-5 审查一下，但是由于存在类似反代的功能，Fable-5 思考一半后直接拒绝了，

甚至我还没有要求它编写代码，而 GPT-5.5 对此是完全没有问题的。


后续我会尝试使用 Claude-Fable-5 替代 GPT-5.5 作为我的主力模型，看看它是否真的比 GPT-5.5 更好。


Claude-Opus-4.8 的速度几乎和我之前测试本地部署的模型一样了，对比 Claude-Fable-5，慢了接近 10 分钟，

需要注意的还有消耗的令牌数，Claude-Opus-4.8 消耗的令牌数是 Claude-Fable-5 的将近两倍，

一来一回 Claude-Fable-5 还真像是 Claude-Opus-5 了，消耗的令牌数低，所以实际价格差距不大。


Claude-Opus-4.8 的完成度有了明显提升，之前一直犯的系统注册和界面入口的常见问题都没有了，

它也和 Claude-Fable-5 一样在最后列出了需要确认的事项，虽然枚举值的处理是错了，但它留下了这样的内容：


皮肤类型枚举：以 skinList 表 Type 字段为准分类（1/2/3/4），未采用 skin.proto 中数值不一致的 SkinType（0/1/2/3）。

说明它知道这里需要判断如何处理，但认为采用配置表的值是合理的，而没有编写相互转换的函数。


首先这样的处理在我看来是完全不合理的，因为虽然留下了说明，但编写了错误的代码，没有对比就没有差距，

反观 Fable-5 既写了转换函数，也留下了这样的说明：


皮肤类型编号不一致：协议枚举 SkinType（0=神针 1=称号 2=头像框 3=气泡）与 skinList 表（1=神针 2=头像框 3=气泡 4=称号）顺序、偏移都不同。我已把转换收口在 SkinNetMgr.ToProtoSkinType/ToCfgSkinType，内部数据一律以配置表类型为准（按 skinId 反查表），仅 C2S_SKIN_LIST.skinType 请求参数按协议枚举发送。请与服务器确认线上实际使用哪套编号，若用表编号只需改这两个函数。

Fable-5 给到了一个完全无可挑剔的答卷。


Mimo V2.5 Pro 的速度非常慢，甚至比我之前测试本地部署的模型还慢，但是完成度相对上个版本有了明显提升，

虽然还存在那两个常见错误，


Mimo V2.5 的速度比上代 V2 Pro 慢，与 Claude-Fable-5 的用时几乎一样，首先它没有犯那两个常见错误，

但是无法编译，未实现、功能错误也非常多，属于 T3 级别。


Hy3 Preview 出现编译错误，位于 T3。


Qwen3.7 系列模型与上一代的差距未拉开很大差距，位于 T2 和 T3，Qwen3.7-Plus 出现编译错误，相对上代 3.5 可能有退步。


Nex-N2-Pro 思考内容发生循环，遂中止了对话，遗憾退赛：


maybe "SkinDataMgr GetSkinPreviewPath(int skinId, int type, bool worldPreview = false)".



Need "SkinDataMgr GetSkinPreviewPathForType".



Need "SkinDataMgr GetSkinPreviewPathForType".



Need "SkinDataMgr GetSkinPreviewPathForType".



Need "SkinDataMgr GetSkinPreviewPathForType".



...

Nemotron 3 Ultra 发生上游错误，无法继续，遗憾退赛。


Minimax M3 下出神之一手，它应该是发现了配置枚举值与服务器枚举值不一致的问题，对此它的判断是，

**一定是后端写错了！**于是它直接修改了 proto 的定义，把服务器枚举改成了一致的值！


惊为天人，史无前例，这是首次有模型直接修改了服务器协议定义的内容。


当然这完全是不符合直觉的操作，但是 Minimax M3 在最后特别说明了这一点，代表着它与 Opus 4.8 一样，

都理解了只是处理不同：


> **注意事项**

> - 协议中 `SkinType` 枚举值的调整属于破坏性变更，服务器需要同步更新枚举值（1/2/3/4）。

> - `C2S_SKIN_LIST.totalAttrs` 字段在协议注释中标注为"所有已拥有皮肤的属性总和"，目前按各类型分别存储并在客户端聚合；如服务器已按"全部类型"聚合，可直接读取 `_totalAttrs`。

除此之外，M3 犯了未设置页签文案的低级错误，总体而言完成度与 Mimo V2.5 Pro 相当，位于 T2。


最后总结



  • Claude Fable 5 表现非常亮眼，我会替换 GPT-5.5 作为主力模型使用一段时间，但是需要注意该模型非常敏感。

  • Claude Opus 4.8 终于变得像 Opus 了，有明显提升，但是 Fable 5 的价格差不多（因为仅有一半令牌消耗量），速度还更快，效果也更好，感觉并非 Fable，而是 Opus 5，有了 Fable 5，Opus 4.8 存在的意义就不太大了。

  • Mimo V2.5 Pro 相对上代进步明显！

  • Minimax M3 相对上代进步明显！

  • 其余模型则如测了。



本次继续使用自己开发的开源 VS Code 插件 Unify Chat Provider 以实现在 Copilot 中使用以上模型。

最新回复 (19)
  • admin 06-11 17:25
    1楼

    大佬回归,一直等你评测呢,你迟迟不上线

  • 小鱼 06-11 17:26
    2楼

    这才是真正的技术帖子，有时间检验，有过程，有数据

  • Mav 06-11 17:27
    3楼

    感觉佬做的很详细也很全面^-^


    最后得到的榜单基本和大家认知相符吧，kimi2.6能力可以啊居然是第一梯队，另外Gemini 3.1 Pro(high)怎么和本地部署级别坐一桌了^-^


    还有就是，佬怎么这么有钱，听到“用Fable-5作为主力模型”的时候感觉壕无人性啊

  • Migration 06-11 17:28
    4楼


    • Fable 5



    终于有 Fable 5 的带真实数据的详细测评了，看完真的很想用！可惜不太能用得起 ^-^

  • 椰肉 06-11 17:28
    5楼

    终于更新了,我对模型实力的理解,有一大部分就是佬的榜单

  • xiaomoyi 06-11 17:32
    6楼

    佬太厉害了，很喜欢看佬的测评，很专业很用心

  • 一般路过不热心群众 06-11 17:34
    7楼

    这个FABLE真的让A风评逆转了吗

  • refrain 06-11 17:34
    8楼

    Claude Opus 4.7(Max)排名这么靠后嘛？直接和deepseek flash一桌了 ^-^

  • numbfish 06-11 17:37
    9楼

    fable5 真的用不起，20x的账号，2个小时干5小时限制了，同时消耗了10%的周限


    更新之后opus4.8也没之前耐用了

  • 奉刀怀邑武登庸 06-11 17:38
    10楼

    终于等到你！接下来就是看nao佬的测评了

  • 张林 06-11 17:40
    11楼

    佬，可以评测一下各自写50章小说的质量吗，在同一个自动化流程下。看下产出效果。


    我测试下来 Gemini 3.1 Pro(high) 写的小说和正常的网文差不多了，但是GPT5.5写出来，全部像是英文翻译过来的，提示词已经优化很多遍了，也是在同一个自动化流下生成的小说。Gemini 3.1 Pro(high) 生成的小说，是完全可以直接看的。GPT5.5 high写出来，一股子英文味道。 ^-^，完全就是不能用。

  • 傲慢与偏见 06-11 17:45
    12楼

    Fable-5 实在是太烧Token了，今早上一个需求，15分钟不到 PRO账号5小时额度直接g

  • fengchris 06-11 17:47
    13楼

    大佬的更新总是值得期待


    混元真是拉完了

  • foreveryu95 06-11 17:52
    14楼

    表示太贵了，根本用不起，完全就是抢钱

  • 咸鱼 06-11 17:54
    15楼

    不是说Qwen3.7代码水平很强么- -，连Mimo都干不过？

  • Tianshangwuyun 06-11 17:54
    16楼

    kimi 2.6还在前面么，这m3体感不行么

  • scrappyfei 06-11 17:55
    17楼

    这样来看，GPT-5.5足够强了，除了前端

  • 咸鱼 06-11 17:56
    18楼

    大D老师默默的当T2的守门员么 ^-^

  • ttuan 06-11 18:01
    19楼

    qwen 怎么还是拉垮啊，天天来公司推销

* 帖子来源Linux.do
附近帖子
返回
飞读
随机推荐