My Obsidian Blog

记一次对 GPT 5.4 Mini/Nano、Minimax M2.7、Xiaomi Mimo V2 Pro/Omni、GLM5 Turbo、Grok 4.20 的真实项目需求的横向评测

18分钟阅读

记一次对 GPT 5.4 Mini/Nano、Minimax M2.7、Xiaomi Mimo V2 Pro/Omni、GLM5 Turbo、Grok 4.20 的真实项目需求的横向评测

原文：https://linux.do/t/topic/1791625

TL;DR

项目 这是一个 Unity C# 项目，我进行测试的是一份皮肤系统需求案，我已经做了好预制体，而模型需要编写代码。 本轮与上两轮评测的项目和环境都完全一致：

项目

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

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

模型来源

  • GPT-5.4 Mini(xhigh): Codex(Team)

  • GPT-5.4 Nano(xhigh): OpenRouter

  • Mimo 系列: 官方 API

  • Minimax M2.7: 官方 API

  • GLM 5 Turbo: 官方 API

  • Grok 4.20 0309 Reasoning: 官方 API

速度

排名模型时间（分钟）备注
1Grok 4.20 0309 Reasoning3
2Minimax M2.15
3Minimax M2.56
4Step-3.5-Flash6
5Mimo V2 Omni7
6Doubao-Seed-2.0-Lite7
7GPT-5.4(low)8
8Doubao-Seed-2.0-Pro9
9Doubao-Seed-2.0-Code9
10Qwen3-Coder-Next9
11Claude Sonnet 4.6(high)9
12Qwen3.5-Plus9
13GLM-5 Turbo10
14Minimax M2.710Highspeed 版本
15Qwen3.5-Flash10
16GPT-5.3-Codex(medium)10
17Gemini 3 Pro11
18Kimi K2.511
19GLM 4.712
20GPT-5.4(high)14
21Mimo V2 Pro15
22Claude Opus 4.515
23Claude Sonnet 4.516
24GPT-5.3-Codex(high)16触发了一次上下文压缩
25GPT-5.3-Codex(xhigh)16
26GPT-5.4(medium)17
27GPT-5.4(xhigh)18
28GLM-520
29DeppSeek V3.222
30Gemini 3 Flash22
31GPT 5.2(xhigh)25
32Claude-Opus-4.6(Max)26
33Gemini 3.1 Pro(high)29受 429 请求频率限制影响
34Qwen3.5 9B GGUF Q4_K_XL35MBP M4 Pro 48GB 本地部署
35Qwen3.5 35B A3B GGUF Q4_K_XL36MBP M4 Pro 48GB 本地部署

令牌数

  • GPT-5.4-Mini(xhigh): 无法得知

  • GPT-5.4-Nano(xhigh): 无法得知

  • Mimo V2 Pro: 3.6M(¥6.13)

  • Mimo V2 Omni: 3.2M(¥2.71)

  • Minimax M2.7: 花费 ¥11.68，账单记录默认会在每天凌晨进行更新，暂无法得知花费令牌数

  • GLM 5 Turbo: 4.2M(¥8.20)

  • Grok 4.20 0309 Reasoning: 1.4M(¥3.86)

代码行数

  • GPT-5.4-Mini(xhigh): 未完成

  • GPT-5.4-Nano(xhigh): 未完成

  • Mimo V2 Pro: +1783, -5

  • Mimo V2 Omni: +1636, -33

  • Minimax M2.7: +1577, -7

  • GLM 5 Turbo: +1486， -14

  • Grok 4.20 0309 Reasoning: +584, -4

完成度

Mimo V2 Pro

审查结论: 存在幻觉，功能不完整，无法编译。

详细

SkinSys.cs#L64 把协议层的 response.SkinList/TotalAttrs 直接传给了 SkinDataMgr.cs#L126，但这里要求的是当前文件里自定义的 GameLogic.SkinInfo/GameLogic.AttrInfo，定义见 SkinDataMgr.cs#L13 和 SkinDataMgr.cs#L49。协议类型实际来自 P_skin.cs#L42 和 P_skin.cs#L62。List 不能隐式转换，这里是确定的编译错误。

SkinUI.cs#L160 调用了 JumpSys.Instance.JumpTo(jumpTo)，但 JumpSys 只提供了 JumpSys.cs#L19 的 JumpToBuildingOrUI。仓内搜索也只找到这一处 JumpTo( 调用。这又是一个确定的编译错误，而且命中“去获取”主链路。

需求明确要求玩家信息界面的皮肤按钮直接打开皮肤管理界面，见 皮肤功能开发.md#L55。但当前 PlayerInfoUI.cs#L310 仍然弹“当前版本暂不支持”。核心入口仍被挡死，功能不可达。

皮肤类型映射被写错了。需求/配置使用 1=神针、2=头像框、3=气泡框、4=称号，见 皮肤功能开发.md#L38；协议使用 0=神针、1=称号、2=头像框、3=气泡框，见 P_skin.cs#L14。当前代码却直接发送/存储原值：SkinNetMgr.cs#L35、SkinDataMgr.cs#L106、SkinSys.cs#L83。即使先修掉编译，神针/称号等数据也会写进错误 key，列表、默认选中和使用状态都会串位。

SkinUI 丢了两个需求里的关键交互。其一，世界/城镇预览虽然有 SkinUI.cs#L205 和 SkinUI.cs#L725 的状态逻辑，但在 SkinUI.cs#L50 根本没有给 m_tabWorldPreview/m_tabCityPreview 绑按钮事件，需求见 皮肤功能开发.md#L160。其二，onlyHas 被做成了单个 _onlyShowOwned 布尔值，SkinUI.cs#L116、SkinUI.cs#L150，切页签时不会按类型独立记忆，违反 皮肤功能开发.md#L167。

Mimo V2 Omni

审查结论: 存在幻觉，功能不完整，无法编译。

详细

T3 当前 GameApp_RegisterSystem.cs:55 在 AddLogicSys(SkinSys.Instance); 处直接结束，缺失 RegisterAllSystem 收尾、AddLogicSys 方法和类结束括号。这个文件静态上已无法编译，且后续系统注册也被截断。

T2 皮肤类型映射被整体写错。协议枚举 P_skin.cs:20 定义的是 0~3，而配置 TbskinList.cs:39 是 1~4；当前 UI 页签直接使用 _skinTypes = 0,1,2,3 SkinUI.cs:143 去过滤配置 SkinCfgMgr.cs:47，网络请求也原样发送 SkinNetMgr.cs:24。结果默认“神针”页签拿不到配置，“称号”页签会读到神针配置，后续列表、预览、使用链路都会错位。

T2 功能入口被回退成不可用。当前 PlayerInfoUI.cs:310 点击皮肤按钮只弹 "当前版本暂不支持"，而且皮肤按钮解锁控制还被注释掉了 PlayerInfoUI.cs:104。按需求这里应直接打开皮肤管理界面。

T2 SkinUI 仍有大量核心验收点停留在 TODO/占位状态：列表背景和图标未加载 SkinUI.cs:467，红点被硬编码关闭 SkinUI.cs:505，名称背景和描边未实现 SkinUI.cs:621，四类预览资源都没加载 SkinUI.cs:645。另外 onlyHas 只剩单个 _onlyShowOwned SkinUI.cs:116，不再是“按类型独立”的内存态 SkinUI.cs:165。

T2 属性来源和格式化都不对。当前选中皮肤属性只从已拥有列表里的 SkinInfo.Attrs 取 SkinDataMgr.cs:185，所以未拥有皮肤不会显示配置属性；UI 还把右侧属性值一律拼成百分比 SkinUI.cs:707，总览弹窗一律拼成 +数值 SkinAttrUI.cs:79。这和需求要求的“读配置并按属性类型正确格式化”不符。

Minimax M2.7

审查结论: 存在幻觉，功能不完整，无法编译。

详细 问题

GLM 5 Turbo

审查结论: 存在幻觉，功能不完整，无法编译。

详细

严重: 当前分支有确定的编译阻断，已经足够判 T3。SkinCfgMgr.cs:155 把返回类型声明成了 GameConfig.atuoSkillAttribution.num，但 TbskinList.cs:45 的 AttributionAdd 实际是 GameConfig.attribution.num；同时 SkinUI.cs:590 和 SkinUI.cs:591 访问了 PlayerInfoData.Level/Name，但当前数据结构只有 PlayerInfoData.cs:11 的 playerName 和 PlayerInfoData.cs:428 的 divineLevel。

高: 预览区实现和需求不一致，称号/气泡两个关键预览都错了。SkinUI.cs:587-SkinUI.cs:588 在“称号”页把建筑预览写成 GetSkinShowUrl(0, true)，这里会直接拿空配置，导致“称号 + 建筑同时展示”做不出来；SkinUI.cs:613-SkinUI.cs:615 在“气泡框”预览里把头像再次加载到了 m_imgBorder2，当前使用中的头像框不会被展示。

高: 属性总览弹窗的数据源和格式都不可靠。SkinNetMgr.cs:45-SkinNetMgr.cs:46 只在 S2C_SKIN_LIST 时更新 _totalAttrs，但 SkinNetMgr.cs:75-SkinNetMgr.cs:76 在换肤成功后并不会重算总属性，所以 SkinAttrUI.cs:71 读到的很可能还是旧值。并且 SkinAttrUI.cs:98 无条件按 +数字 输出，SkinUI.cs:742-SkinUI.cs:746 又把 numType == 3 当成原始百分比直接拼 %，百分比属性会显示错。

高: 系统注册文件也回退了。当前 GameApp_RegisterSystem.cs:33-GameApp_RegisterSystem.cs:56 里已经没有 SkinSys，同时对比线上同文件还少了 BroadcastSys、PowerChangeSys、AudioSys、SoldierStarSys。即使当前某些调用直接走单例，这也意味着 SkinSys.OnStart() 根本不会执行，而且该文件里混入了和皮肤无关的全局回退。

Grok 4.20 0309 Reasoning

审查结论: 存在幻觉，功能不完整，无法编译。

详细

严重 皮肤功能当前是不可达的。系统注册里已经删掉了 SkinSys 启动入口 [GameApp_RegisterSystem.cs:39](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/GameApp_RegisterSystem.cs#L39)，而玩家信息页的皮肤按钮被回退成“当前版本暂不支持”弹窗 [PlayerInfoUI.cs:310](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfoUI/PlayerInfoUI.cs#L310)；同时解锁显隐也被注释掉了 [PlayerInfoUI.cs:106](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfoUI/PlayerInfoUI.cs#L106)。这和基线里直接注册系统、打开 SkinUI 的实现相反 [base GameApp_RegisterSystem.cs:39](/Users/smallmain/Documents/Work/dartouUnityFramework/UnityProject/Assets/GameScripts/HotFix/GameLogic/GameApp_RegisterSystem.cs#L39)、[base PlayerInfoUI.cs:388](/Users/smallmain/Documents/Work/dartouUnityFramework/UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfoUI/PlayerInfoUI.cs#L388)。

严重 SkinCfgMgr 现在和真实配置表结构对不上，属于明确编译阻塞。它在 [SkinCfgMgr.cs:42](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/CfgMgr/Skin/SkinCfgMgr.cs#L42) 开始读取 data.SkinId / ItemId / Quality / Name / Attrs / Duration，但实际 TbskinList 只有 Id / Type / AttributionAdd / HomeShowUrl / WorldShowUrl / HomeModelUrl / WorldModelUrl / JumpTo [TbskinList.cs:37](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameProto/GameConfig/skin/TbskinList.cs#L37)、[TbskinList.cs:45](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameProto/GameConfig/skin/TbskinList.cs#L45)、[TbskinList.cs:65](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameProto/GameConfig/skin/TbskinList.cs#L65)。另外 JumpTo 被定义成了 string [SkinCfgMgr.cs:108](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/CfgMgr/Skin/SkinCfgMgr.cs#L108)，但表里是 int。

严重 SkinNetMgr 和 SkinSys 仍是占位状态，运行契约已经断掉。SkinSys.GetCurrentSkinIdByType() 直接 return 0 且保留 TODO [SkinSys.cs:50](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/System/Skin/SkinSys.cs#L50)；SkinNetMgr.ReqSkinList() 不再传 SkinType [SkinNetMgr.cs:36](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/NetMgr/Skin/SkinNetMgr.cs#L36)，但协议里该字段仍然存在 [P_skin.cs:100](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameProto/GameProtocol/P_skin.cs#L100)；RespSkinUse() 还调用了不存在的 SkinDataMgr.Instance.UpdateUsedSkin() [SkinNetMgr.cs:53](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/NetMgr/Skin/SkinNetMgr.cs#L53)。另外基线里仍有 SKIN_VIEW / SKIN_EXPIRE 链路 [base SkinNetMgr.cs:12](/Users/smallmain/Documents/Work/dartouUnityFramework/UnityProject/Assets/GameScripts/HotFix/GameLogic/NetMgr/Skin/SkinNetMgr.cs#L12)，当前被直接删掉，没有替代方案。

严重 SkinUI 既有编译错误，也没有实现核心验收项。文件里用了 List [SkinUI.cs:99](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs#L99) 却没有 using System.Collections.Generic；还引用了仓库里找不到的 JumpTool、UIMgr、SkinAttrUIData 和未定义的 Event_SkinDataUpdate [SkinUI.cs:123](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs#L123)、[SkinUI.cs:132](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs#L132)、[SkinUI.cs:139](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs#L139)。即便忽略编译，HasSkin() 也被硬编码成 true [SkinUI.cs:229](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs#L229)，InitMenuTabs() 没有真正绑定页签行为 [SkinUI.cs:160](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs#L160)，倒计时始终写死为“永久” [SkinUI.cs:196](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs#L196)，所以 onlyHas、三态按钮、置灰、倒计时、默认选中都没有成立。

高 皮肤类型映射被写错了。当前 UI 把页签序号直接当皮肤类型使用 [SkinUI.cs:96](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs#L96)、[SkinUI.cs:298](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs#L298)，但配置表 TbskinList.Type 实际是 1神针 / 2头像框 / 3气泡框 / 4称号 [TbskinList.cs:39](/Users/smallmain/Documents/Work/dartouUnityFramework.worktrees/test-1/UnityProject/Assets/GameScripts/HotFix/GameProto/GameConfig/skin/TbskinList.cs#L39)。由于需求里的页签顺序是“神针、称号、头像框、气泡框”，当前实现会把称号/头像框/气泡框全部映射错位。

代码质量

Grok 4.20、GLM 5 Turo、Minimax M2.7、Mimo V2 Pro 和 Mimo V2 Omni 的代码风格依旧经典，注释非常详细，行间注释多。

最终总结

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

Minimax M2.7 非常倾向于使用子代理，搜索、两个长代码文件都是使用子代理并行完成的。

这很好，提高了速度，避免上下文污染，不过也很坏，每个子代理的上下文都是全新的，

也就意味着没有输入缓存，花费直接接近 Mimo V2 Pro 的两倍（但 V2 Pro 的单价比 M2.7 高一倍）。

但最终效果依然没有能够进入到第二梯队。

我已经尽力叫 Grok 4.20 干活了，它第一轮收到需求案之后，罗列了非常多的待确定项，

包括配置表在哪、协议在哪、如何读取、如何加载图片等等一系列问题，这我都是没提供给

任何模型的，毕竟这些都可以在项目中找到，可以说它有点懒了，于是我再次用强指令让它

自行解决，尽力搜索，尽量完成，但写了三百来行之后它又向我询问字段、配置等问题。

我再次给他自行搜索，不要偷懒的强指令，最终它宣布它完成了整个需求案，但只写了五百来行代码，几乎不可用。

GLM 5 Turbo 的速度很快，但实际结果表明代码能力弱化了，可能是对 Agent 能力进行了专门的加强，本次甚至掉下了第三梯队。

Mimo V2 系列则表现不佳，没什么想说的，唯一就是 Omni 的价格低廉，速度很快，

作为一个多模态模型，可能能代替 Step-3.5-Flash 作为一个快速模型使用，

有此类需求的佬友可以和 Qwen3.5 系列对比一下，现在百炼平台可以调用所有端侧模型了。

不然的话本地部署还是太慢了。

GPT 5.4 Mini 与 Nano 均未能完成这个需求，Mini 是在写入 SkinUI.cs 这个长代码文件时触发超过最大输出令牌数的错误，

我重试了四五次依然是一样的错误，根据 Mimo 两个模型的输出令牌数统计，均为 2.5w 左右，而且它们代码写的也是最多的，

行间注释非常多，GPT 一般情况下是不写什么注释的。

整个需求需要输出 1600 行左右的代码，SkinUI.cs 大概需要 500 行左右，所以应该完全不会超出模型的输出能力，

所以这个问题有两种可能，一个是在 Codex 中，5.4 Mini 的输出长度被限制在了几千以内，另一个就是输出时发生了无限循环，

一直输出直到超过最大输出令牌数。

Nano 的情况则非常经典，似曾相似，与 GPT 之前测试的小尺寸模型一样，它在疯狂地读取 prefab 文件，跑了十几二十来分钟，

依然还在探索代码库，完全没有进入到编写代码的阶段，一般出现这种情况可能模型已经处于无限循环了，鉴于这种情况，我直接终止了

评测。

总结这次的评测，没有惊喜，而且花费还挺大，现在这些模型都需要真金白银的花费，但实际效果却不太如人意。

现在依然只能选择 GPT、Claude、GLM、Kimi 这几个模型。

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

如果对佬友们有帮助，请给我一个 Star，感谢！

✍️ 续写感悟 (APPEND)📍 中间插入 (INSERT)🛠️ 快速修订 (PATCH)

关系图谱