记一次对 DeepSeek V4 全系列 vs GPT 5.5 全系列真实项目需求的横向评测
- 内容介绍
- 文章标签
- 相关推荐
项目
这是一个 Unity C# 项目，我进行测试的是一份皮肤系统需求案，我已经做了好预制体，而模型需要编写代码。
本轮与上两轮评测的项目和环境都完全一致：
- 第一轮
- …
- 第十一轮
模型来源
- DeepSeek V4 系列: 官方 API
- GPT 5.5 系列: GPT Plus Codex
速度
| 排名 | 模型 | 时间（分钟） | 备注 |
|---|---|---|---|
| 1 | Grok 4.20 0309 Reasoning | 3 | |
| 2 | Minimax M2.1 | 5 | |
| 3 | Minimax M2.5 | 6 | |
| 4 | Step-3.5-Flash | 6 | |
| 5 | Mimo V2 Omni | 7 | |
| 6 | Doubao-Seed-2.0-Lite | 7 | |
| 7 | GPT-5.4(low) | 8 | |
| 8 | Doubao-Seed-2.0-Pro | 9 | |
| 9 | Doubao-Seed-2.0-Code | 9 | |
| 10 | Qwen3-Coder-Next | 9 | |
| 11 | Claude Sonnet 4.6(high) | 9 | |
| 12 | Qwen3.5-Plus | 9 | |
| 13 | GLM-5 Turbo | 10 | |
| 14 | Minimax M2.7 | 10 | Highspeed 版本 |
| 15 | Qwen3.5-Flash | 10 | |
| 16 | GPT-5.3-Codex(medium) | 10 | |
| 17 | Gemini 3 Pro | 11 | |
| 18 | Kimi K2.5 | 11 | |
| 19 | GLM 4.7 | 12 | |
| 20 | GPT-5.5(low) | 13 | |
| 21 | GPT-5.4(high) | 14 | |
| 22 | GPT-5.5(medium) | 15 | |
| 23 | Mimo V2 Pro | 15 | |
| 24 | Claude Opus 4.5 | 15 | |
| 25 | Claude Sonnet 4.5 | 16 | |
| 26 | GPT-5.3-Codex(high) | 16 | 触发了一次上下文压缩 |
| 27 | GPT-5.3-Codex(xhigh) | 16 | |
| 28 | GPT-5.4(medium) | 17 | |
| 29 | DeepSeek V4 Flash | 17 | |
| 30 | GPT-5.4(xhigh) | 18 | |
| 31 | GPT-5.5(high) | 19 | |
| 32 | Claude-Opus-4.7(Max) | 20 | |
| 33 | GLM-5 | 20 | |
| 34 | DeepSeek V4 Pro | 21 | |
| 35 | DeppSeek V3.2 | 22 | |
| 36 | Gemini 3 Flash | 22 | |
| 37 | KAT-Coder-Pro V2 | 24 | |
| 38 | GPT 5.2(xhigh) | 25 | |
| 39 | Claude-Opus-4.6(Max) | 26 | |
| 40 | GPT-5.5(xhigh) | 28 | |
| 41 | Gemini 3.1 Pro(high) | 29 | 受 429 请求频率限制影响 |
| 42 | Kimi K2.6 | 33 | |
| 43 | Qwen3.5 9B GGUF Q4_K_XL | 35 | MBP M4 Pro 48GB 本地部署 |
| 44 | Qwen3.5 35B A3B GGUF Q4_K_XL | 36 | MBP M4 Pro 48GB 本地部署 |
令牌数
- DeepSeek V4 Pro(max): 无法准确得知
- DeepSeek V4 Flash(max): 无法准确得知
- GPT 5.5 系列: 无法得知
代码行数
- DeepSeek V4 Pro(max): +1340, -10
- DeepSeek V4 Flash(max): +1167, -7
- GPT 5.5(xhigh): +1599, -15
- GPT 5.5(high): +1234, -6
- GPT 5.5(medium): +1142, -15
- GPT 5.5(low): +728, -135（貌似动用了命令行编辑文件而不是工具）
完成度
DeepSeek V4 Pro(max)
审查结论: 存在常犯错误，未完成部分功能。
详细
-
皮肤入口不可用
UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfoUI/PlayerInfoUI.cs:310-314OnClickSkinBtn()仍然打开“当前版本暂不支持”弹窗，没有打开SkinUI。功能入口直接失败。
-
SkinSys未注册，核心链路不生效UnityProject/Assets/GameScripts/HotFix/GameLogic/GameApp_RegisterSystem.cs:30-57- 当前没有
AddLogicSys(SkinSys.Instance)。 - 结果：
S2C_HOME_INFO.UseSkins不会被消费，SkinNetMgr响应后也不会转发SkinSys.Event_SkinDataUpdate，SkinUI请求列表后不会刷新数据。
-
协议类型与配置类型映射错误
- 协议：
P_skin.cs:14-35是0神针 / 1称号 / 2头像框 / 3气泡框 - 配置：
TbskinList.cs:39-41是1神针 / 2头像框 / 3气泡 / 4称号 - 当前
SkinDataMgr/SkinNetMgr直接使用skinType，没有转换：SkinNetMgr.cs:27-31SkinDataMgr.cs:104-112SkinDataMgr.cs:119-140
- 会导致请求类型、使用中状态、页签展示全部错位。
- 协议：
-
onlyHas不是按类型独立状态SkinUI.cs:132-137SkinUI.cs:341-355- 当前只读
m_toggleOnlyHas.isOn，没有按皮肤类型保存独立状态；切页会串状态。
-
预览区域实现不完整
SkinUI.cs:596-643- 称号预览没有设置玩家名/等级，也没有加载当前神针建筑图。
- 头像框预览没有加载头像。
- 气泡框预览没有加载头像和当前头像框。
- 与需求中的“称号+建筑、头像框、气泡完整预览”不一致。
-
属性来源错误 / 不稳定
SkinUI.cs:687-700- 当前皮肤属性只读服务器返回的
SkinInfo.Attrs，未拥有皮肤或未请求到列表时直接隐藏；但需求是按skinList.AttributionAdd展示当前选中皮肤属性。 SkinAttrUI.cs:91-105依赖SkinDataMgr.TotalAttrs，激活皮肤后S2C_SKIN_USE不会刷新该总属性，属性总览会 stale。
DeepSeek V4 Flash(max)
审查结论: 存在编译错误，存在幻觉，功能实现不完整。
详细
-
明确编译失败
UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:568-569- 使用了
PlayerInfoData.Level、PlayerInfoData.Name，但当前PlayerInfoData只有playerName，未定义Level/Name。
-
协议类型映射错误，导致页签请求错数据
P_skin.cs协议枚举是：0=神针, 1=称号, 2=头像框, 3=气泡框。- 当前代码用简单
skinType - 1/SkinType + 1：SkinNetMgr.cs:30SkinDataMgr.cs:52SkinDataMgr.cs:76
- 结果：称号、头像框、气泡框请求/使用状态都会错位。
-
SkinAttrUI 不满足“正在使用皮肤属性总和”要求
SkinAttrUI.cs:75直接读SkinDataMgr.GetTotalAttrs()。SkinDataMgr.cs:61-67的_totalAttrs只来自最近一次S2C_SKIN_LIST。- 激活皮肤后
S2C_SKIN_USE不刷新_totalAttrs，属性总览会 stale；也没有按当前使用皮肤从配置重新聚合。
-
预览逻辑多处不符合需求
- 称号页签：
SkinUI.cs:570-572用当前称号配置的WorldShowUrl当建筑预览，应展示当前使用的神针建筑。 - 气泡页签：
SkinUI.cs:588-589把气泡资源设置到头像框m_imgBorder2，且没有设置m_imgBubble2。 - 名称描边：
SkinUI.cs:503-505传入"2B73B6"，ColorUtility.TryParseHtmlString通常需要#2B73B6，颜色可能不生效。 - 倒计时：
SkinSys.cs:64-86未按“年天时分”格式，且用客户端 UTC 时间，不是项目内服务器时间。
- 称号页签：
GPT-5.5(xhigh)
审查结论: 完整实现所有功能。
详细
主要问题：
无。
GPT-5.5(high)
审查结论: 一点小错误，功能实现完整。
详细
-
过期皮肤仍可能被当作拥有/可使用
SkinOwnData.IsExpired()有实现，但HasSkin()/ action 区逻辑未使用。SkinUI.cs:469-477只按HasSkin / IsUsingSkin切按钮。- 缺少
S2C_SKIN_EXPIRE处理后，已过期皮肤可能仍显示“激活/已使用”。
-
属性总览格式存在错误风险
SkinDataMgr.cs:299-331聚合属性时只保留AttrId / AttrValue，丢失skinList.AttributionAdd.Type。SkinAttrUI.cs:101-102再用attrCfg.NumType格式化，可能把皮肤配置里的百分比类型显示成普通数值。- 线上基线保留了
type后再格式化。
GPT-5.5(medium)
审查结论: 有一个常见错误和一个功能未实现。
详细
主要问题：
-
皮肤类型映射错误，网络请求/回包会串类型
P_skin.cs协议枚举是0=神针, 1=称号, 2=头像框, 3=气泡框。- 但
SkinCfgMgr.NormalizeSkinType()对1~4直接原样返回，只把0转成1：SkinCfgMgr.cs:110-123。 SkinNetMgr.ReqSkinList()直接发送这个值：SkinNetMgr.cs:21-27。- 结果：神针请求会发
1，服务端语义是称号；称号请求会发4，协议中不存在。S2C_HOME_INFO.useSkins/S2C_SKIN_USE回来的称号也会被当成神针。
-
神针皮肤模型未接入场景建筑
- 线上
SceneObjSys会在主城建筑加载/刷新时优先取SkinSys.GetCurrentNeedleSkinModelPath()。 - 当前分支回退为永远取建筑等级默认模型，且没有监听皮肤使用变化。
- 结果：神针皮肤即使激活，实际主城建筑模型不会切换。
- 线上
GPT-5.5(low)
审查结论: 三个功能点未实现。
详细
主要问题
-
神针皮肤没有接回主城模型实际应用链路
- 当前
SkinSys.cs只有GetCurrentSkinResPath，缺少线上Event_SkinUsingUpdate/GetCurrentNeedleSkinModelPath。 - 当前
SceneObjSys.cs没有监听皮肤切换，也没有用神针皮肤模型替换主城建筑；线上有该链路。
- 当前
-
SkinUI 预览实现不符合需求
SkinUI.cs:210-211称号页签把建筑图和称号背景都设成当前称号资源，未展示当前神针建筑。SkinUI.cs:214玩家名/等级硬编码为"玩家名称"、"LV.1"。- 头像框/气泡预览没有加载玩家头像、当前头像框：
m_imgHead、m_imgHead2、m_imgBorder2基本未使用。 - 气泡文案是固定占位文本。
-
“去获取”按钮没有按
skinList.jumpTo跳转SkinUI.cs:273-278检查了cfg.JumpTo，但实际打开GetMoreUI，没有调用线上已有的JumpSys.Instance.JumpToBuildingOrUI(jumpId, Close)。
最终总结
| 排名 | 模型/层级 | 说明 |
|---|---|---|
| Tier 0 | 该等级的模型实现与线上基线高度一致。 | |
| 1 | GPT 5.5(xhigh) | |
| 1 | GPT 5.4(xhigh) | |
| 2 | GPT 5.2(xhigh) | |
| 3 | GPT-5.3-Codex(xhigh) | |
| Tier 1 | 该等级的模型的代码正确完整且可编译，仅少量边界问题或轻微不一致。 | |
| 4 | GPT 5.5(high) | |
| 4 | GPT 5.4(high) | |
| 5 | GPT 5.4(medium) | |
| 6 | Kimi K2.6 | |
| 7 | GPT 5.5(low) | |
| 8 | GPT 5.5(medium) | |
| 9 | GPT-5.3-Codex(high) | |
| 10 | GPT-5.3-Codex(medium) | |
| 11 | Claude Opus 4.6(Max) | |
| 12 | GPT 5.2(medium) | |
| 13 | GPT 5.4(low) | |
| 14 | GPT 5.2 Codex(xhigh) | |
| 15 | Claude Opus 4.5 | |
| 16 | Claude Sonnet 4.5 | |
| Tier 2 | 该等级的模型的代码至少可编译或仅极少量的语法错误，但是存在明显功能错误、遗漏或与需求/线上不一致。 | |
| 17 | GLM 5.1 | |
| 18 | GLM 5 | |
| 19 | Kimi K2.5 | |
| 20 | Claude Sonnet 4.6(high) | |
| 21 | Qwen3.5-Plus | |
| 22 | KAT-Coder-Pro V2 | |
| 23 | DeepSeek V4 Pro(max) | |
| Tier 3 | 该等级的模型的问题很多且无法编译，或者存在不少幻觉。 | |
| 24 | DeepSeek V4 Flash(max) | |
| 25 | Claude Opus 4.7(Max) | |
| 26 | GLM 5 Turbo | |
| 27 | GLM 4.7 | |
| 28 | Gemini 3.1 Pro(high) | |
| 29 | Mimo V2 Pro | |
| 30 | Mimo V2 Omni | |
| 31 | Minimax M2.7 | |
| 32 | Minimax M2.5 | |
| 33 | Step-3.5-Flash | |
| 34 | Qwen3-Coder-Next | |
| 35 | Gemini 3 Pro | |
| 36 | Gemini 3 Flash | |
| 37 | Doubao-Seed-2.0-Code | |
| 38 | Doubao-Seed-2.0-Pro | |
| 39 | Doubao-Seed-2.0-Lite | |
| 40 | Qwen3.5-Flash | |
| 41 | Qwen3.5 35B A3B GGUF Q4_K_XL | |
| 42 | Qwen3.5 9B GGUF Q4_K_XL | |
| 43 | Grok 4.20 0309 Reasoning | |
| 44 | DeepSeek V3.2 | |
| 45 | Minimax M2.1 | |
| 46 | GPT 5.1 Codex mini(medium) |
等待已久，DeepSeek V4 终于在昨天发布，其实昨天早上已经跑出了成绩，但是忙到今天才有时间编辑帖子。
在这期间，我看了很多对它的评测或者排行榜，其中就有 toyama nao 的逻辑和代码评测，对其的评价都超过了 Kimi K2.6 和 GLM 5.1，但很遗憾，在这个需求上，DeepSeek 的表现远不如预期。
- 起初，V4 表现出来的工作流程确实和 V3.2 有明显不同，与排行靠前的模型一样，它会先全盘阅读代码并进行思考，然后再进行编码。
- 但是，V4 Pro 对于两个常错点都没有做对，那么基本意味着它只能屈居于 T2，除了完成度极高（就像 Claude 模型）的话，才可能能够被放在 T1 级别。
- 最终，V4 Pro 的完成度不高，包括协议类型转换在内的多个功能点都没有完成，最终只能被放在 T2 级别。
- 惊讶的是，V4 Flash 完成了入口与系统注册两个功能点，协议类型转换也意识到了需要去做，但是实现是错的，零散的未实现的细节比较多，最终由于幻觉导致使用了不存在的属性，编译失败，最终只能被放在 T3 级别。
- 我对比了一下 V4 Flash 和 Opus 4.7(Max)，V4 Flash 甚至做的要更好一点，所以它代替了 Opus 4.7 成为了新的 T3 领衔者，万万没想到 Opus 4.7 在 T3 级别待的时间这么短。
DeepSeek V4、Kimi K2.6 和 Opus 4.7 这几个都是评价褒贬不一，表现众说纷纭，大家实测为真。
接下来是几乎同一时间发布的 GPT-5.5，一般代码审查都是用 GPT 当时最好的模型去做的，所以为了避免自己人帮自己人，都是会用 Claude 模型再做一次审查，这次则是 GPT-5.5(xhigh) 和 Claude Opus 4.7(max)。
- 作为主力使用也有差不多一天了，GPT 5.5 的口癖貌似确实得到了改善，现在的总结简单、直接，用词也更加平常，之前简单的问题被长篇大论描述地一头雾水的情况貌似也没有了。
- GPT 5.5(xhigh) 经过两次审查，依然无懈可击，找不到任何可被验证的错误点，毋庸置疑的 T0 级别。
- GPT 5.5(high) 的表现与 GPT 5.4(high) 差距不大，功能实现完整，只有一些小细节问题，最终被放在 T1 级别。
- GPT 5.5 的 medium 和 low 思考程度下完成度相差不多， medium 未完成协议类型转换但小错误少，low 完成了协议类型转换但小错误多，这可能是偶然做对的，但由于协议类型转换在这个评测里份量比较重，所以 medium 被放在了 low 后面。
- 我使用的 Plus 账号在不使用 Fast 层级的情况下，速度好像有所下降（之前也是标准层级进行评测），XHigh 比 5.4 甚至慢了 10 分钟。
总结，GPT 依然领先，且差距不小，那这篇帖子所谓的 “VS”，也是有一点标题党了，毕竟对手是实力相当，这两个…
但官方应该知道现在的 DeepSeek V4 有些许问题，所以还是预览版，希望能加快迭代脚步。并且价格方面在下半年大幅下降后，这个推理能力、上下文和注意力应该会有非常大的优势！
未来可期吧。
网友解答：--【壹】--：
kimi-k2.6 和 glm5.1 都给人思维链太长太发散的感觉，ds 体验了下反而还好，思维链比前两个有条理。
（均在 opencode go 计划下使用）
--【贰】--：
这么多测试看下来，deepseek的pro确实存在训练不到位的问题，反而是flash的能力有点意思。期待ds能早日把pro优化到位吧。
--【叁】--：
其实前三基本上都是碰到这个需求的上限了，都基本完整地实现了，需要更复杂的需求考验他们。只是谁更新放谁在上面。
--【肆】--： SmallMain:
我对比了一下 V4 Flash 和 Opus 4.7(Max)，V4 Flash 甚至做的要更好一点
这成绩挺好啊，这下可以光明正大地宣传Deepseek V4 Flash > Claude Opus了
--【伍】--：
毕竟是超越了claude opus成为全球最贵的模型
--【陆】--：
我嘞个豆啊
完整实现所有功能， 简单粗暴
不过看起来high仍然还是不错的甜点区
--【柒】--：
GPT还是厉害。
这几天看外网测评论坛，对k2.6的好评还是有的，不失为一个备用选项。
--【捌】--：
kimi k2.6这么厉害了吗，居然和那几位坐一桌了
--【玖】--：
我好像出现幻觉了，我在 Tier 3 看到了Claude Opus 4.7(Max)
--【拾】--：
opus4.7这么靠后啊，建议再测一下JAVA go python
--【拾壹】--：
flash确实让人惊讶的好。很适合作为小任务的执行subagent。
--【拾贰】--：
和我猜的一样，编程真下苦功夫的目前只看到glm和kimi的公司，其他几家感觉不屑于vibe编程，压根没投入资源
很正常，像gemini也不行，但是百科问答、代码问答还挺好的
--【拾叁】--：
看来还是路漫漫，这几天这么多测试看下来就是不稳定，这一次上下文是一个亮点，期待之后的模型吧
--【拾肆】--：
我自己实际使用过程中，感觉DeepSeek-v4-pro（max）确实是不如 glm 的
--【拾伍】--：
可能还是在编程方向、语言、框架上有区别，我在java后端的测试上v4是不输glm kimi的
--【拾陆】--：
感谢佬友的评测，非常有帮助，还帮我缓解了模型焦虑
--【拾柒】--：
这样看来5.5还是厉害啊，直接问鼎榜首，
--【拾捌】--：
每次看见这个榜单的opus4.7都绷不住
--【拾玖】--：
pro 看来编码不是很厉害。世界知识丰富的话可能当 gemini 用比较合适
项目
这是一个 Unity C# 项目，我进行测试的是一份皮肤系统需求案，我已经做了好预制体，而模型需要编写代码。
本轮与上两轮评测的项目和环境都完全一致：
- 第一轮
- …
- 第十一轮
模型来源
- DeepSeek V4 系列: 官方 API
- GPT 5.5 系列: GPT Plus Codex
速度
| 排名 | 模型 | 时间（分钟） | 备注 |
|---|---|---|---|
| 1 | Grok 4.20 0309 Reasoning | 3 | |
| 2 | Minimax M2.1 | 5 | |
| 3 | Minimax M2.5 | 6 | |
| 4 | Step-3.5-Flash | 6 | |
| 5 | Mimo V2 Omni | 7 | |
| 6 | Doubao-Seed-2.0-Lite | 7 | |
| 7 | GPT-5.4(low) | 8 | |
| 8 | Doubao-Seed-2.0-Pro | 9 | |
| 9 | Doubao-Seed-2.0-Code | 9 | |
| 10 | Qwen3-Coder-Next | 9 | |
| 11 | Claude Sonnet 4.6(high) | 9 | |
| 12 | Qwen3.5-Plus | 9 | |
| 13 | GLM-5 Turbo | 10 | |
| 14 | Minimax M2.7 | 10 | Highspeed 版本 |
| 15 | Qwen3.5-Flash | 10 | |
| 16 | GPT-5.3-Codex(medium) | 10 | |
| 17 | Gemini 3 Pro | 11 | |
| 18 | Kimi K2.5 | 11 | |
| 19 | GLM 4.7 | 12 | |
| 20 | GPT-5.5(low) | 13 | |
| 21 | GPT-5.4(high) | 14 | |
| 22 | GPT-5.5(medium) | 15 | |
| 23 | Mimo V2 Pro | 15 | |
| 24 | Claude Opus 4.5 | 15 | |
| 25 | Claude Sonnet 4.5 | 16 | |
| 26 | GPT-5.3-Codex(high) | 16 | 触发了一次上下文压缩 |
| 27 | GPT-5.3-Codex(xhigh) | 16 | |
| 28 | GPT-5.4(medium) | 17 | |
| 29 | DeepSeek V4 Flash | 17 | |
| 30 | GPT-5.4(xhigh) | 18 | |
| 31 | GPT-5.5(high) | 19 | |
| 32 | Claude-Opus-4.7(Max) | 20 | |
| 33 | GLM-5 | 20 | |
| 34 | DeepSeek V4 Pro | 21 | |
| 35 | DeppSeek V3.2 | 22 | |
| 36 | Gemini 3 Flash | 22 | |
| 37 | KAT-Coder-Pro V2 | 24 | |
| 38 | GPT 5.2(xhigh) | 25 | |
| 39 | Claude-Opus-4.6(Max) | 26 | |
| 40 | GPT-5.5(xhigh) | 28 | |
| 41 | Gemini 3.1 Pro(high) | 29 | 受 429 请求频率限制影响 |
| 42 | Kimi K2.6 | 33 | |
| 43 | Qwen3.5 9B GGUF Q4_K_XL | 35 | MBP M4 Pro 48GB 本地部署 |
| 44 | Qwen3.5 35B A3B GGUF Q4_K_XL | 36 | MBP M4 Pro 48GB 本地部署 |
令牌数
- DeepSeek V4 Pro(max): 无法准确得知
- DeepSeek V4 Flash(max): 无法准确得知
- GPT 5.5 系列: 无法得知
代码行数
- DeepSeek V4 Pro(max): +1340, -10
- DeepSeek V4 Flash(max): +1167, -7
- GPT 5.5(xhigh): +1599, -15
- GPT 5.5(high): +1234, -6
- GPT 5.5(medium): +1142, -15
- GPT 5.5(low): +728, -135（貌似动用了命令行编辑文件而不是工具）
完成度
DeepSeek V4 Pro(max)
审查结论: 存在常犯错误，未完成部分功能。
详细
-
皮肤入口不可用
UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfoUI/PlayerInfoUI.cs:310-314OnClickSkinBtn()仍然打开“当前版本暂不支持”弹窗，没有打开SkinUI。功能入口直接失败。
-
SkinSys未注册，核心链路不生效UnityProject/Assets/GameScripts/HotFix/GameLogic/GameApp_RegisterSystem.cs:30-57- 当前没有
AddLogicSys(SkinSys.Instance)。 - 结果：
S2C_HOME_INFO.UseSkins不会被消费，SkinNetMgr响应后也不会转发SkinSys.Event_SkinDataUpdate，SkinUI请求列表后不会刷新数据。
-
协议类型与配置类型映射错误
- 协议：
P_skin.cs:14-35是0神针 / 1称号 / 2头像框 / 3气泡框 - 配置：
TbskinList.cs:39-41是1神针 / 2头像框 / 3气泡 / 4称号 - 当前
SkinDataMgr/SkinNetMgr直接使用skinType，没有转换：SkinNetMgr.cs:27-31SkinDataMgr.cs:104-112SkinDataMgr.cs:119-140
- 会导致请求类型、使用中状态、页签展示全部错位。
- 协议：
-
onlyHas不是按类型独立状态SkinUI.cs:132-137SkinUI.cs:341-355- 当前只读
m_toggleOnlyHas.isOn，没有按皮肤类型保存独立状态；切页会串状态。
-
预览区域实现不完整
SkinUI.cs:596-643- 称号预览没有设置玩家名/等级，也没有加载当前神针建筑图。
- 头像框预览没有加载头像。
- 气泡框预览没有加载头像和当前头像框。
- 与需求中的“称号+建筑、头像框、气泡完整预览”不一致。
-
属性来源错误 / 不稳定
SkinUI.cs:687-700- 当前皮肤属性只读服务器返回的
SkinInfo.Attrs，未拥有皮肤或未请求到列表时直接隐藏；但需求是按skinList.AttributionAdd展示当前选中皮肤属性。 SkinAttrUI.cs:91-105依赖SkinDataMgr.TotalAttrs，激活皮肤后S2C_SKIN_USE不会刷新该总属性，属性总览会 stale。
DeepSeek V4 Flash(max)
审查结论: 存在编译错误，存在幻觉，功能实现不完整。
详细
-
明确编译失败
UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:568-569- 使用了
PlayerInfoData.Level、PlayerInfoData.Name，但当前PlayerInfoData只有playerName，未定义Level/Name。
-
协议类型映射错误，导致页签请求错数据
P_skin.cs协议枚举是：0=神针, 1=称号, 2=头像框, 3=气泡框。- 当前代码用简单
skinType - 1/SkinType + 1：SkinNetMgr.cs:30SkinDataMgr.cs:52SkinDataMgr.cs:76
- 结果：称号、头像框、气泡框请求/使用状态都会错位。
-
SkinAttrUI 不满足“正在使用皮肤属性总和”要求
SkinAttrUI.cs:75直接读SkinDataMgr.GetTotalAttrs()。SkinDataMgr.cs:61-67的_totalAttrs只来自最近一次S2C_SKIN_LIST。- 激活皮肤后
S2C_SKIN_USE不刷新_totalAttrs，属性总览会 stale；也没有按当前使用皮肤从配置重新聚合。
-
预览逻辑多处不符合需求
- 称号页签：
SkinUI.cs:570-572用当前称号配置的WorldShowUrl当建筑预览，应展示当前使用的神针建筑。 - 气泡页签：
SkinUI.cs:588-589把气泡资源设置到头像框m_imgBorder2，且没有设置m_imgBubble2。 - 名称描边：
SkinUI.cs:503-505传入"2B73B6"，ColorUtility.TryParseHtmlString通常需要#2B73B6，颜色可能不生效。 - 倒计时：
SkinSys.cs:64-86未按“年天时分”格式，且用客户端 UTC 时间，不是项目内服务器时间。
- 称号页签：
GPT-5.5(xhigh)
审查结论: 完整实现所有功能。
详细
主要问题：
无。
GPT-5.5(high)
审查结论: 一点小错误，功能实现完整。
详细
-
过期皮肤仍可能被当作拥有/可使用
SkinOwnData.IsExpired()有实现，但HasSkin()/ action 区逻辑未使用。SkinUI.cs:469-477只按HasSkin / IsUsingSkin切按钮。- 缺少
S2C_SKIN_EXPIRE处理后，已过期皮肤可能仍显示“激活/已使用”。
-
属性总览格式存在错误风险
SkinDataMgr.cs:299-331聚合属性时只保留AttrId / AttrValue，丢失skinList.AttributionAdd.Type。SkinAttrUI.cs:101-102再用attrCfg.NumType格式化，可能把皮肤配置里的百分比类型显示成普通数值。- 线上基线保留了
type后再格式化。
GPT-5.5(medium)
审查结论: 有一个常见错误和一个功能未实现。
详细
主要问题：
-
皮肤类型映射错误，网络请求/回包会串类型
P_skin.cs协议枚举是0=神针, 1=称号, 2=头像框, 3=气泡框。- 但
SkinCfgMgr.NormalizeSkinType()对1~4直接原样返回，只把0转成1：SkinCfgMgr.cs:110-123。 SkinNetMgr.ReqSkinList()直接发送这个值：SkinNetMgr.cs:21-27。- 结果：神针请求会发
1，服务端语义是称号；称号请求会发4，协议中不存在。S2C_HOME_INFO.useSkins/S2C_SKIN_USE回来的称号也会被当成神针。
-
神针皮肤模型未接入场景建筑
- 线上
SceneObjSys会在主城建筑加载/刷新时优先取SkinSys.GetCurrentNeedleSkinModelPath()。 - 当前分支回退为永远取建筑等级默认模型，且没有监听皮肤使用变化。
- 结果：神针皮肤即使激活，实际主城建筑模型不会切换。
- 线上
GPT-5.5(low)
审查结论: 三个功能点未实现。
详细
主要问题
-
神针皮肤没有接回主城模型实际应用链路
- 当前
SkinSys.cs只有GetCurrentSkinResPath，缺少线上Event_SkinUsingUpdate/GetCurrentNeedleSkinModelPath。 - 当前
SceneObjSys.cs没有监听皮肤切换，也没有用神针皮肤模型替换主城建筑；线上有该链路。
- 当前
-
SkinUI 预览实现不符合需求
SkinUI.cs:210-211称号页签把建筑图和称号背景都设成当前称号资源，未展示当前神针建筑。SkinUI.cs:214玩家名/等级硬编码为"玩家名称"、"LV.1"。- 头像框/气泡预览没有加载玩家头像、当前头像框：
m_imgHead、m_imgHead2、m_imgBorder2基本未使用。 - 气泡文案是固定占位文本。
-
“去获取”按钮没有按
skinList.jumpTo跳转SkinUI.cs:273-278检查了cfg.JumpTo，但实际打开GetMoreUI，没有调用线上已有的JumpSys.Instance.JumpToBuildingOrUI(jumpId, Close)。
最终总结
| 排名 | 模型/层级 | 说明 |
|---|---|---|
| Tier 0 | 该等级的模型实现与线上基线高度一致。 | |
| 1 | GPT 5.5(xhigh) | |
| 1 | GPT 5.4(xhigh) | |
| 2 | GPT 5.2(xhigh) | |
| 3 | GPT-5.3-Codex(xhigh) | |
| Tier 1 | 该等级的模型的代码正确完整且可编译，仅少量边界问题或轻微不一致。 | |
| 4 | GPT 5.5(high) | |
| 4 | GPT 5.4(high) | |
| 5 | GPT 5.4(medium) | |
| 6 | Kimi K2.6 | |
| 7 | GPT 5.5(low) | |
| 8 | GPT 5.5(medium) | |
| 9 | GPT-5.3-Codex(high) | |
| 10 | GPT-5.3-Codex(medium) | |
| 11 | Claude Opus 4.6(Max) | |
| 12 | GPT 5.2(medium) | |
| 13 | GPT 5.4(low) | |
| 14 | GPT 5.2 Codex(xhigh) | |
| 15 | Claude Opus 4.5 | |
| 16 | Claude Sonnet 4.5 | |
| Tier 2 | 该等级的模型的代码至少可编译或仅极少量的语法错误，但是存在明显功能错误、遗漏或与需求/线上不一致。 | |
| 17 | GLM 5.1 | |
| 18 | GLM 5 | |
| 19 | Kimi K2.5 | |
| 20 | Claude Sonnet 4.6(high) | |
| 21 | Qwen3.5-Plus | |
| 22 | KAT-Coder-Pro V2 | |
| 23 | DeepSeek V4 Pro(max) | |
| Tier 3 | 该等级的模型的问题很多且无法编译，或者存在不少幻觉。 | |
| 24 | DeepSeek V4 Flash(max) | |
| 25 | Claude Opus 4.7(Max) | |
| 26 | GLM 5 Turbo | |
| 27 | GLM 4.7 | |
| 28 | Gemini 3.1 Pro(high) | |
| 29 | Mimo V2 Pro | |
| 30 | Mimo V2 Omni | |
| 31 | Minimax M2.7 | |
| 32 | Minimax M2.5 | |
| 33 | Step-3.5-Flash | |
| 34 | Qwen3-Coder-Next | |
| 35 | Gemini 3 Pro | |
| 36 | Gemini 3 Flash | |
| 37 | Doubao-Seed-2.0-Code | |
| 38 | Doubao-Seed-2.0-Pro | |
| 39 | Doubao-Seed-2.0-Lite | |
| 40 | Qwen3.5-Flash | |
| 41 | Qwen3.5 35B A3B GGUF Q4_K_XL | |
| 42 | Qwen3.5 9B GGUF Q4_K_XL | |
| 43 | Grok 4.20 0309 Reasoning | |
| 44 | DeepSeek V3.2 | |
| 45 | Minimax M2.1 | |
| 46 | GPT 5.1 Codex mini(medium) |
等待已久，DeepSeek V4 终于在昨天发布，其实昨天早上已经跑出了成绩，但是忙到今天才有时间编辑帖子。
在这期间，我看了很多对它的评测或者排行榜，其中就有 toyama nao 的逻辑和代码评测，对其的评价都超过了 Kimi K2.6 和 GLM 5.1，但很遗憾，在这个需求上，DeepSeek 的表现远不如预期。
- 起初，V4 表现出来的工作流程确实和 V3.2 有明显不同，与排行靠前的模型一样，它会先全盘阅读代码并进行思考，然后再进行编码。
- 但是，V4 Pro 对于两个常错点都没有做对，那么基本意味着它只能屈居于 T2，除了完成度极高（就像 Claude 模型）的话，才可能能够被放在 T1 级别。
- 最终，V4 Pro 的完成度不高，包括协议类型转换在内的多个功能点都没有完成，最终只能被放在 T2 级别。
- 惊讶的是，V4 Flash 完成了入口与系统注册两个功能点，协议类型转换也意识到了需要去做，但是实现是错的，零散的未实现的细节比较多，最终由于幻觉导致使用了不存在的属性，编译失败，最终只能被放在 T3 级别。
- 我对比了一下 V4 Flash 和 Opus 4.7(Max)，V4 Flash 甚至做的要更好一点，所以它代替了 Opus 4.7 成为了新的 T3 领衔者，万万没想到 Opus 4.7 在 T3 级别待的时间这么短。
DeepSeek V4、Kimi K2.6 和 Opus 4.7 这几个都是评价褒贬不一，表现众说纷纭，大家实测为真。
接下来是几乎同一时间发布的 GPT-5.5，一般代码审查都是用 GPT 当时最好的模型去做的，所以为了避免自己人帮自己人，都是会用 Claude 模型再做一次审查，这次则是 GPT-5.5(xhigh) 和 Claude Opus 4.7(max)。
- 作为主力使用也有差不多一天了，GPT 5.5 的口癖貌似确实得到了改善，现在的总结简单、直接，用词也更加平常，之前简单的问题被长篇大论描述地一头雾水的情况貌似也没有了。
- GPT 5.5(xhigh) 经过两次审查，依然无懈可击，找不到任何可被验证的错误点，毋庸置疑的 T0 级别。
- GPT 5.5(high) 的表现与 GPT 5.4(high) 差距不大，功能实现完整，只有一些小细节问题，最终被放在 T1 级别。
- GPT 5.5 的 medium 和 low 思考程度下完成度相差不多， medium 未完成协议类型转换但小错误少，low 完成了协议类型转换但小错误多，这可能是偶然做对的，但由于协议类型转换在这个评测里份量比较重，所以 medium 被放在了 low 后面。
- 我使用的 Plus 账号在不使用 Fast 层级的情况下，速度好像有所下降（之前也是标准层级进行评测），XHigh 比 5.4 甚至慢了 10 分钟。
总结，GPT 依然领先，且差距不小，那这篇帖子所谓的 “VS”，也是有一点标题党了，毕竟对手是实力相当，这两个…
但官方应该知道现在的 DeepSeek V4 有些许问题，所以还是预览版，希望能加快迭代脚步。并且价格方面在下半年大幅下降后，这个推理能力、上下文和注意力应该会有非常大的优势！
未来可期吧。
网友解答：--【壹】--：
kimi-k2.6 和 glm5.1 都给人思维链太长太发散的感觉，ds 体验了下反而还好，思维链比前两个有条理。
（均在 opencode go 计划下使用）
--【贰】--：
这么多测试看下来，deepseek的pro确实存在训练不到位的问题，反而是flash的能力有点意思。期待ds能早日把pro优化到位吧。
--【叁】--：
其实前三基本上都是碰到这个需求的上限了，都基本完整地实现了，需要更复杂的需求考验他们。只是谁更新放谁在上面。
--【肆】--： SmallMain:
我对比了一下 V4 Flash 和 Opus 4.7(Max)，V4 Flash 甚至做的要更好一点
这成绩挺好啊，这下可以光明正大地宣传Deepseek V4 Flash > Claude Opus了
--【伍】--：
毕竟是超越了claude opus成为全球最贵的模型
--【陆】--：
我嘞个豆啊
完整实现所有功能， 简单粗暴
不过看起来high仍然还是不错的甜点区
--【柒】--：
GPT还是厉害。
这几天看外网测评论坛，对k2.6的好评还是有的，不失为一个备用选项。
--【捌】--：
kimi k2.6这么厉害了吗，居然和那几位坐一桌了
--【玖】--：
我好像出现幻觉了，我在 Tier 3 看到了Claude Opus 4.7(Max)
--【拾】--：
opus4.7这么靠后啊，建议再测一下JAVA go python
--【拾壹】--：
flash确实让人惊讶的好。很适合作为小任务的执行subagent。
--【拾贰】--：
和我猜的一样，编程真下苦功夫的目前只看到glm和kimi的公司，其他几家感觉不屑于vibe编程，压根没投入资源
很正常，像gemini也不行，但是百科问答、代码问答还挺好的
--【拾叁】--：
看来还是路漫漫，这几天这么多测试看下来就是不稳定，这一次上下文是一个亮点，期待之后的模型吧
--【拾肆】--：
我自己实际使用过程中，感觉DeepSeek-v4-pro（max）确实是不如 glm 的
--【拾伍】--：
可能还是在编程方向、语言、框架上有区别，我在java后端的测试上v4是不输glm kimi的
--【拾陆】--：
感谢佬友的评测，非常有帮助，还帮我缓解了模型焦虑
--【拾柒】--：
这样看来5.5还是厉害啊，直接问鼎榜首，
--【拾捌】--：
每次看见这个榜单的opus4.7都绷不住
--【拾玖】--：
pro 看来编码不是很厉害。世界知识丰富的话可能当 gemini 用比较合适