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

项目

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

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

• 第一轮


• …


• 上一轮

模型来源

• Grok 4.5: Grok Build


• Kimi K3: 火山 Agent Plan


• Claude Opus 5: Claude Code 自行中转


• GPT 5.6 Sol/Luna: Codex 自行中转


• DeepSeek V4 Flash 0731: 官方 API

速度

令牌数

• Grok 4.5: 未知


• Kimi K3: 15M(¥40)


• Claude Opus 5: 24M


• GPT 5.6 Sol: 未知


• GPT 5.6 Luna: 47M


• DeepSeek V4 Flash 0731: 21M(¥0.94)

代码行数

• Grok 4.5: +1924, -18


• Kimi K3: +1903, -6


• Claude Opus 5: +1943, -8


• GPT 5.6 Sol: +1201, -8


• GPT 5.6 Luna: +1223, -13


• DeepSeek V4 Flash 0731: +2184, -133

完成度

Grok 4.5

审查结论: 完成度非常高，出现两个功能错误问题。

详细

• 中：称号未拥有时只置灰称号节点，建筑预览强制不置灰（Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:712），不符合“当前展示节点及子节点置灰”的要求。

Kimi K3

审查结论: 完成度非常高，出现两个功能错误问题。

详细

• 未拥有称号只置灰称号节点，没有置灰同时展示的建筑；没有神针资源时建筑还会直接隐藏。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:595、UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:607。

Claude Opus 5

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

详细

• 限时皮肤过期后状态残留：网络层只注册 LIST/USE，删除了线上 VIEW/EXPIRE 链路；列表刷新也不会清除已失效的 _usingSkins，计时器只更新“已过期”文本，因此皮肤仍可能显示使用中并继续计入属性。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/NetMgr/Skin/SkinNetMgr.cs:15、UnityProject/Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:143、UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:640。

GPT 5.6 Sol

审查结论: 完成度极高，无明显问题。

详细

无问题。

GPT 5.6 Luna

审查结论: 完成度尚可，存在功能未实现及多个细节问题。

详细

• 阻断：皮肤列表和名称为空。 列表背景、图标被直接清空，详情名称也被清空并隐藏品质背景；同时配置层完全未读取 ItemInfo，无法取得名称和品质。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:373、UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:469、UnityProject/Assets/GameScripts/HotFix/GameLogic/CfgMgr/Skin/SkinCfgMgr.cs:13。


• 高：onlyHas 状态不是按皮肤类型独立保存。 当前只有一个 _onlyOwned，切换页签会沿用上一页签状态。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:75、UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:142。


• 中：属性总览忽略百分比/万分比格式。 所有值均直接显示原始整数；类型 1/3 配置会显示错误。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinAttrUI.cs:119。


• 中：入口解锁控制被注释，称号等级被固定清空。 见 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfoUI/PlayerInfoUI.cs:106、UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:606。

DeepSeek V4 Flash 0731

审查结论: 完成度较高，但有多个细节问题。

详细

• P1｜皮肤类型映射错误：配置使用神针/头像框/气泡/称号 1/2/3/4，协议使用神针/称号/头像框/气泡 0/1/2/3，请求和响应却直接传值。神针会请求成称号，称号发送非法类型 4，启动及使用状态同样错位。UnityProject/Assets/GameScripts/HotFix/GameLogic/NetMgr/Skin/SkinNetMgr.cs:33


• P2｜启动数据初始化不完整：useSkins 只写入使用字典，没有登记为已拥有。列表响应前，正在使用的皮肤会显示锁定、置灰和“去获取”，属性总览也为空。UnityProject/Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:125


• P2｜称号和气泡组合预览错误：称号资源同时被加载到称号背景和建筑图片，建筑应展示当前神针；气泡仅设置第一条气泡，m_imgBubble2 与当前头像框 m_imgBorder2 从未赋值。UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:741


• P2｜“已过期”状态不可达：IsOwned 在到期后直接返回 false，时间区域随即隐藏，因此后面的“已过期”文本永远不会显示；同时使用设备 UTC 而非服务器同步时间。UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:975


• P2｜仅显示已拥有不是按类型独立：所有页签直接共用当前 Toggle 值，切换页签会继承上一页签状态，不符合每种皮肤类型独立存储要求。UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:573


• P2｜使用中皮肤无法持续固定第一位：列表项创建后按 ID 缓存复用，后续激活新皮肤时没有调整 siblingIndex；数据虽然重新排序，视觉层级仍保持旧顺序。UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:590

最终总结

Kimi K3 & Grok 4.5

Kimi K3 与 Grok 4.5 犯的是同一个问题，果然是同根生。

Grok 4.5 是我日常偶尔在用的模型，因为它速度快，效果也不错，非常期待它后续的 Grok 4.6、Grok 4.7 版本。

Kimi K3 的速度实在是太慢了，再加上消耗的令牌数也不低，所以直接打破了评测最长耗时记录，并且遥遥领先，整整花了一个多小时才完成了测试。

最近我在尝试使用 Kimi K3 重构一个项目的 UI，这是一个由 GPT 5.6 生成的管理工具，即使我给出了多个设计要求，但界面依然是非常浓郁的 AI 味。

Kimi K3 在这方面确实非常不错，它给出来的设计草案和 Demo 看起来很棒，两者对比之后才发现觉得 GPT 5.6 编写的界面有 AI 味的原因。

GPT 5.6 的设计主要差在排版、整体元素的大小和间距上，Kimi K3 的设计则更加精致。

由于 Kimi K3 的重构工作还未完成，就暂时不放图片出来对比了。

总结来看，我会愿意让 Kimi K3 进行 UI 设计，但在其它任务上，无论考虑速度还是性价比都不如使用 GPT 5.6。

而 Grok 4.5 的速度非常快，在日常任务中我愿意使用它来替代 Composer 2.5。

Claude Opus 5

Claude Opus 5 花费了 55 分钟完成了评测，我认为一部分原因是它读取了非常多的 .prefab 文件，并且非常深入，因为它找出了很多预制体上的问题（虽然并不在需求要求的范围内）：

- m_goListContent 未绑定 ContentSizeFitter 组件，滚动范围可能不对。

- Viewport 的 Mask 没有 Graphic，实际不会裁剪。

- m_goTemplateListItem 上没有 Button， 可能无法点击。

这些问题是第一次有模型提出，而且我确实有印象，在之后的线上版本中我陆续修复了这些问题。

但预制体并不在评测范围内，因为我也不想它直接去读取预制体文件（数据量很大，费 Token 也费时间，所以我有在需求案里直接描述了所有相关预制体的结构），只能说耗时过多情有可原，但也不予加分了。

代码的完成度上，Claude Opus 5 只犯了和 Claude Fable 5 一样的一个细节错误，比 Claude Opus 以往的版本的表现都要好。

GPT 5.6 Sol

GPT 5.6 Sol 在浏览了一遍代码库之后，遵从指令向我询问了它不确定的问题。

这是 GPT 5.5 及其它模型都没有做到的，或者说它们并没有发现这些问题，因为询问的问题都是之前模型易错的问题。

GPT 5.6 Sol 花费的时间也是 GPT 系列模型有史以来最长的，它不仅阅读了代码，还阅读了配置表。

值得一提的是，GPT 5.6 Sol 我是测了两次，因为第一次评测时，我发现它在遇到问题时，并没有直接向我提问，而是先去查找提交历史、其它分支的代码，它通过这种方式发现了线上分支的代码，于是我直接中止了对话。

这种情况可能之后会越来越常见，评测的环境需要更加严格了。

最终，GPT 5.6 Sol 相对 GPT 5.5 来说，它花费的时间更长，但是它也做得更多。

即使需求案里没有要求的，它也会认为这是应该做的，比如说这个评测需求里，红点系统、自动切换系统都只写了一半，涉及到的地方都使用了 TODO 进行注释。

虽然皮肤涉及到了这些系统，但是需求案并未要求要补全红点或者自动切换系统的功能，GPT 5.6 Sol 还是默认认为这些系统应该是完整的，尽力去做了。

DeepSeek V4 Flash 0731

这篇文章中前四个模型其实在上个星期就测好并且写好了总结，但一直不太想发布，因为一直在等一个良（梁）日。

突然今天 DeepSeek V4 Flash 正式版发布，并且 GPT 5.6 Luna 的价格令人震惊瘫坐，看来吉时已到，正好测了立马发布。

本次 DeepSeek V4 Flash 正式版与预览版本的表现确实天差地别，以下分点说明：

• 正式版本用时与预览版本差不多，但是正式版本在完成编码后花了几分钟尝试用各种方法想要通过编译去验证代码正确性，要说明的是由于是 Unity 项目，一般模型是不去编译验证的，因为 dotnet build 会失败。
  
  这次确实第一次尝试也失败了，但不像其它模型一样直接放弃，而是又再次自己审查了一遍自己写的代码，在发现了一个问题并修复后，又突然想到用 Unity batch mode 去验证，
  
  然后又失败了，这是因为 Unity 的 license 导致的问题；然后它又尝试了 Roslyn 静态编译，这是正确的方法，验证出几个问题后再次修复了，最终通过了 Roslyn 静态编译验证，结束了编码，给出了总结报告。


• 前 10 分钟，它都在阅读已有代码库，大概有 5 分钟都在尝试编译验证代码，实际编码的时间我估算只有 2 分钟左右，而预览版本是没有尝试编译验证的，不考虑这部分时间的话，正式版本的速度要比预览版本快 5 分钟左右，也就是快了 30%。


• 他会通过 python 去解析必要的 Prefab YAML 文件验证代码正确性，很少有模型会做到，但最后的总结报告并没有像 Opus 5 一样找出预制体中的问题，当然也没有像 Opus 5 一样花了太长时间去阅读预制体。


• DeepSeek V4 Flash 也像 GPT 5.6 Sol 一样，即使需求案里没有要求的也去做了，比如红点系统，并且令人惊喜的是，它给出了有效的总结报告，即指出了自己疑惑、猜测出的决策：

  # 需要你确认的设计决策（需求未明之处）
  
  
  
  1. "新皮肤"红点判定：服务器未下发新皮肤标记，我按客户端推断实现 —— 首次出现的已拥有皮肤（启动 useSkins + 打开界面返回的皮肤列表）标红，点击任意红点皮肤后全部清除。功能上线时老玩家的已有皮肤会先亮一次红点。
  
  2. S2C_SKIN_LIST.TotalAttrs 未使用：由于 C2S_SKIN_LIST 按类型请求，TotalAttrs 是单类型还是全局总和无法确认，属性总览改为按文档描述客户端合并（使用中皮肤属性求和）。若服务器期望用 TotalAttrs，请告知。
  
  3. 称号预览等级：项目无玩家等级字段，m_textTitleUserLevel 显示的是神针等级（主城建筑等级）。
  
  4. 已过期皮肤视为未拥有（显示锁定 + 去获取按钮）。
  
  5. 气泡预览中的 m_textBuble 文字：需求未定义内容，保留预制体默认，未做修改。
  
  

  
  


• 犯了经典的皮肤类型映射错误，还有预览展示错误、初始化数据问题，而且出现了少见的独立页签状态和使用中缓存问题。


• 最终，根据审查结论，DeepSeek V4 Flash 正式版的完成度逊于 Composer 2.5、GLM 5.2 等模型。
  
  好消息：
  
  - 仅靠着 284B 的模型参数量就达到了 T1 行列的水平，这是目前已知参数量的模型中唯一一个！
  
  - 速度非常快，别看两个竞品模型 Grok 4.5 和 GPT 5.6 Luna 宣传得有多快，实际上在 OpenRouter 上的统计其实都只有 40 - 50 tps，而 DeepSeek V4 Flash 正式版基本能稳定在 120 tps 以上；这个统计也符合我自己的使用体感。
  
  坏消息：
  
  - 犯的细节错误比较多，作为一个小模型，如果速度能再翻倍就更好了，目前实用性我认为中规中矩，胜在渠道稳定（不担心降智）且易于获取。

将 V4 Flash 正式版排在 GLM 5.2，甚至是 Composer 2.5 的后面可能招来很多争议，我也有心理准备。

特别是有像 DeepSWE 这样也非常符合我的使用体验的基准测试，测试结果是 V4 Flash 正式版的得分超过 GLM 5.2 不少。

但通过我自己这次进行的 Unity C# 需求开发中的表现来看，284B 能有这个表现已经非常惊艳了，但用 284B 的模型全面战胜 1T+ 的模型，在评测过后，我持怀疑态度。

GPT 5.6 Luna

GPT 5.6 Luna 这次测的是 Max 思考程度，由于它现在的价格在购买订阅后几乎等于不要钱，并且宣传的速度也非常地快，那么我对它的实际能力就很感兴趣了。

实际测试有一点大跌眼镜，在 Max 思考程度下，它竟然打破了 Kimi K3 的耗时记录，花费了 95 分钟才完成了整个测试！

这并不是它的令牌输出速度太慢，实际上是执行步骤非常多，花费了整整 47M 的令牌数，是一般模型的 4 - 5 倍。

GPT 5.6 Luna 主要犯了一个功能未实现的严重错误，但其实它可以完成的更好，它在中途其实已经停下来询问过自己不清楚的地方，

但由于这些问题都可以从代码库中找到答案，所以之前模型的询问我也是没有直接给出答案，而是让模型自行仔细阅读代码。

但最终依然没完成此功能的开发，总结中也有列出自己未实现此功能，是因为无法找到对应的数据。

这样看来，GPT 5.6 Luna 给我的感觉就更像是 GPT 5.6 Sol 的阉割版，能够思考但是又思考得不足。

导致了它在面对这种对它来说复杂的需求时耗时太长，且最终完成的效果也不够好。

作为一个定位是经济快速的模型，在这种需求上实际体验不如 Grok 4.5、DeepSeek V4 Flash 这些模型。

总结

• 前沿模型完成任务的速度越来越慢了，无论你是说因为模型大了还是高峰期限速之类的，最终对于用户来说就是慢了，除了 Grok 4.5、DeepSeek V4 Flash 以外，其它几个模型花费时间都超过了 30 分钟。


• 模型猜测用户意图的能力越来越好了，Opus 5、DeepSeek V4 Flash 会查看预制体中的错误，5.6 Sol 会查看配置表中的错误；在这个评测场景来说是好的，但是否会过拟合还得再测试更多场景。


• DeepSeek V4 Flash 正式版与 Grok 4.5 会替代 Composer 4.5 成为我日常快速任务使用的模型，首先它们足够快，给人的感觉都很可靠，其次效果也足够好，而 DeepSeek 主要胜在不用担心降智，价格极其便宜且易于获取。


• Kimi K3 与 Opus 5 成为我前端、架构、3D 设计所使用的模型，之前我不会为了这些任务专门使用一个模型（只用 GPT）。


• GPT 5.6 Sol 成为我的主力模型，之前是 GPT 5.5。


• GPT 5.6 Luna 在订阅中价格便宜，但对于复杂需求来说不太好用，但不排除它有非常好的执行简单任务的能力。


• T1 行列现在已经成为基线了，DeepSeek V4 Flash 正式版的发布甚至让其已经成为斩杀线了，非 T1 模型几乎不用再考虑使用，并且期待第一个进入 T0 行列的国产模型出现。