项目

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

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

• 第一轮


• …


• 上一轮

模型来源

• Qwen 3.8 Max: 官方 API


• Grok 4.6: Grok Build (Super)


• DeepSeek V4 Pro: 官方 API


• DeepSeek Harness(DeepSeek V4 Pro): 官方 API

速度

令牌数

• Qwen 3.8 Max: 25.1M(¥49.51)


• Grok 4.6: 未知


• DeepSeek V4 Pro: 23M(¥1.73)


• DeepSeek Harness(标准模式): 17M(¥1.40)


• DeepSeek Harness(PTC 模式): 37M(¥2.34)


• DeepSeek Harness(极简模式): 185M(¥7.93)

代码行数

• Qwen 3.8 Max: +1851, -12


• Grok 4.6: +2038, -13


• DeepSeek V4 Pro: +2013, -8


• DeepSeek Harness(标准模式): 未计算


• DeepSeek Harness(PTC 模式): 未计算


• DeepSeek Harness(极简模式): 未计算

完成度

Qwen 3.8 Max

审查结论: 完成度一般，出现多个问题。

详细

• 高——属性区域会自毁： 刷新属性时销毁模板之外的所有子节点，包括固定的 bg 和 m_textTitle；首次展示有属性皮肤后布局即被破坏。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:656。


• 高——激活皮肤未落到实际界面： GameLogic 中资源接口仅被 SkinUI 预览消费；玩家信息头像框只查找组件却从不赋值，换头像界面的头像框逻辑也被移除。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfoUI/PlayerInfoUI.cs:45、UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfoUI/ChangeAvatarUI.cs:24。


• 中——筛选状态未按类型独立： 四个页签共用单一 _onlyHas，不符合每种类型独立保存的要求。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:122。


• 中——空列表与置灰状态错误： 筛选后无项目时只隐藏倒计时，旧名称、预览和操作区仍残留；称号未拥有时只置灰称号节点，建筑预览没有同步置灰。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:602、UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:798。


• 中——启动状态不完整： useSkins 只更新使用映射；若拥有字典尚未加载，不会登记当前使用皮肤，列表响应前会显示成锁定/去获取状态。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:118。

Grok 4.6(xhigh)

审查结论: 完成度较高，但存在常犯的错误。

详细

高：配置类型被直接当作协议类型发送。 配置顺序为 1/4/2/3，协议却定义为 0/1/2/3；当前请求会把神针请求成称号、发送非法称号类型 4，且永远不请求神针类型 0。响应侧又直接用协议值清理配置类型，进一步污染拥有状态。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/CfgMgr/Skin/SkinCfgMgr.cs:16、UnityProject/Assets/GameScripts/HotFix/GameLogic/System/Skin/SkinSys.cs:59、UnityProject/Assets/GameScripts/HotFix/GameLogic/NetMgr/Skin/SkinNetMgr.cs:22、Proto/skin.proto:9、UnityProject/Assets/GameScripts/HotFix/GameLogic/DataMgr/Skin/SkinDataMgr.cs:360。

中：空资源路径不会清理旧图。 预览和头像框加载遇到空路径直接返回，复用 UI 或皮肤失效后可能残留上一张图片；异步回调也未校验当前选择，快速切换时存在旧请求覆盖新预览的风险。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:603、UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfoUI/PlayerInfoUI.cs:335。

DeepSeek V4 Pro(max)

审查结论: 完成度非常高，存在少量细节问题。

详细

• 中：onlyHas 状态关闭窗口即丢失。 状态保存在 SkinUI实例字段中，而 CloseUI会销毁窗口；需求要求其作为按类型独立的内存态，仅应用重启后丢失。应移至 SkinDataMgr等进程级对象。Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:127、Assets/DartouFramework/Runtime/Modules/UIModule/UIModule.cs:568


• 低：倒计时格式不符合“年天时分”。 当前输出 HH:mm:ss并包含秒，需求仅要求年、天、时、分，每秒刷新显示即可。Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:577

DeepSeek Harness(标准模式)

审查结论: 完成度非常高，存在少量细节问题。

详细

• 中｜未拥有预览置灰不完整。 当前只替换 Image 材质，称号和气泡中的 Text 等其他 Graphic 子节点不会置灰。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:674。

DeepSeek Harness(PTC 模式)

审查结论: 完成度非常高，存在少量细节问题。

详细

• [P2] 默认选中使用中皮肤不可靠。 首次重建发生在异步列表响应前，此时 useSkins 只写入使用 ID、没有写入拥有数据，列表会先选最低 ID；响应后该 ID 仍可见，因此不会切回使用中的皮肤。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:444。


• [P2] onlyHas 状态关闭窗口后即丢失。 状态保存在 SkinUI 实例字段中，而 Close() 会销毁窗口；这不符合“仅重启游戏时丢失”的要求，应放到会话级数据管理器。见 UnityProject/Assets/GameScripts/HotFix/GameLogic/UI/PlayerInfo/SkinUI.cs:129。

DeepSeek Harness(极简模式)

审查结论: 出现编译错误与核心功能问题。

详细

• 阻断｜无法编译：SkinAttrUI.cs:91 使用 TbskinList 却未引入 GameConfig.skin；SkinAttrUI.cs:160 又访问不存在的 SkinTotalAttr.AttrId，实际字段是 attrId。至少后者必然触发 C# 编译错误。


• 阻断｜协议类型错位：配置类型为神针/称号=1/4（SkinCfgMgr.cs:23），协议却为 0/1（P_skin.cs:20）。SkinNetMgr.cs:28 直接发送配置值，SkinDataMgr.cs:132 又直接按协议值存储；结果神针请求成称号、称号发送非法值 4，登录状态和列表数据也会落到错误页签。


• 严重｜称号预览资源错误：SkinUI.cs:754 取得称号资源后，同时写入称号背景和建筑图片（SkinUI.cs:781、SkinUI.cs:785）；建筑区域应展示当前神针或默认建筑，而不是把称号图片当建筑加载。

最终总结

Qwen 3.8 Max 耗时高、价格高、完成度一般。

Grok 4.6(xhigh) 出现了 Grok 4.5 评测时未出现的、之前很多模型经常出现的配置枚举转换问题，初次之外完成度与上代相当。

依然是速度很快的模型，但我认为只有几次使用无法感受到更多的差别，需要更长时间的体验。

鉴于 Grok4.6 是新模型、且其它基准测试对 Grok 4.6 的评分比 Grok 4.5 更高，所以将其排在 Grok 4.5 之上。

---

提前防止 DeepSeek 阿 Q 们进行自我安慰：

• 两次评测均在晚上 19:50 之后开始，不存在白天疑似的部署问题。


• 首次使用模型商提供的 “专武”（DeepSeek Harness）进行对比。


• 思考程度使用 Max、参数均为官方评测使用的参数。

非专武版 DeepSeek V4 Pro 0813

DeepSeek V4 Pro 0813 与之前发布的 V4 Flash 0731 的执行流程非常相似，有着一脉相承的感觉，在执行的过程中也会读取 .prefab 文件验证。

其输出速度非常高，基本在 90 tps 以上，部分大量令牌输出的请求甚至最高能达到 130 tps 以上。

最后的报告总结也像 V4 Flash 一样汇报了需求案未澄清、自行决定的决策。

最终，DeepSeek V4 Pro 0813 的完成度非常高，只存在少量细节问题，在这个场景下，效果超过了 Grok 4.6 是毫无疑问的，与 Kimi K3 相当，但比它快多了。

在价格不变的情况下，我认为 DeepSeek V4 Pro 0813 是极其值得使用的，因为它也毫无疑问地要比 V4 Flash 0731 的效果好很多。

但是当超过 10 倍的涨价幅度生效后，DeepSeek V4 Pro 0813 可能无法再成为 Kimi K3 / GPT 5.6 中低端版本的快速平替版。

所谓斩杀线也不复存在。

以下是 DeepSeek Harness 全模式的评测，均使用 DeepSeek V4 Pro max，就不再说明所使用的模型了。

DeepSeek Harness(标准模式)

使用体感上的不同：

• 
  

  中途直接对需求案未澄清、不确定的决策进行了询问，未使用 DSH 时是直接自行做了决定，在最后总结时汇总。

  
  

  这一点上，使用 DSH 的行为更符合需求案中的指令，这可能因为 Copilot 的系统提示词存在不要向用户提问、独立完成的指令而导致的行为差异。

  
  

除此之外，模型完成需求的流程几乎没有区别，都是会读取 .prefab 文件、先浏览代码库、编写代码、再进行编译测试、最后通读检查一遍。

对模型性能的帮助：

• 比不使用 DSH 的任务完成速度快了 4%（1 分钟）。


• 比不使用 DSH 的所用令牌数少了 26%（6M），成本节省 20%（¥0.33）。

对模型效果的帮助：

• 无，结论相同。

DeepSeek Harness(PTC 模式)

使用体感上的不同：

• 
  

  与标准模式一样，模型在中途进行了询问。

  
  


• 
  

  该模式下，模型被要求尽量生成代码来替代直接调用工具，例如：

  
  

  {
  
      code:"const r1 = await tools.bash({ command: \"find Assets/GameScripts -maxdepth 3 -type d | sort | head -100\", description: \"List GameScripts directory tree\", workdir: \"UnityProject\" });\nconsole.log(r1.stdout);\nif (r1.exitCode !== 0) console.log(\"ERR\", r1.stderr);\n",
  
      description:"List GameScripts directory tree in UnityProject"
  
  }
  
  

  
  

  该模式的目的是让模型尽量一次性组合多个工具调用，且尽量将确定性的工作流转化为代码执行（多次、循环、条件判断等）。

  
  

  但实际上，绝大部分时候 DeepSeek V4 Pro 依然是单个单个工具进行调用，并且也不会进行更高级的流程控制。

  
  

  且出现十余次生成的代码有误的情况，例如：

  
  

  Error: code run failed (exception): TypeError: r.stdout.slice is not a function
  
  

  
  

  相比之下，标准模式仅出现两三次工具调用错误。

  
  

对模型性能的帮助：

• 对任务完成速度负提升，慢了 20%（5 分钟）。


• 对令牌消耗数负提升，用量直接翻了倍（20M），成本增加了 27%（¥0.61）。

对模型效果的帮助：

• 无，结论相同。

DeepSeek Harness(极简模式)

使用体感上的不同：

• 
  

  该模式下，仅提供了 bash 和 replace_str 两个工具给模型，这也是官方在评测时使用的模式。

  
  

  这绝对不会是能让模型发挥最佳性能的模式。

  
  


• 
  

  该模式下，无法执行 pwd，模型对当前工作区路径一无所知，所以我必须告知模型当前工作区路径。

  
  

  即使这样，我尝试了多次，在一开始几乎都会大量出现 bash 工具调用错误：

  
  

  

  
  

  在中途也会出现多次猜测路径导致的错误。

  
  


• 
  

  在该模式下，Harness 未开启上下文压缩能力，再加上只有两个工具，模型需要大量的输入和输出令牌，且几乎每几个工具调用就会出现一次错误。
  
  导致任务耗尽了上下文，最终未能完成评测任务。

  
  

  

  
  

对模型性能的帮助：

• 对任务完成速度负提升，运行了 64 分钟，且未完成任务。


• 对令牌消耗数负提升，用量直接翻了 10 倍（185M），成本增加了接近 4 倍（¥7.93）。

对模型效果的帮助：

• 无法完成任务。

总结

• Qwen 3.8 Max 在我这个评测场景中依然高分低能。


• Grok 4.6、DeepSeek V4 Pro 会成为我日常快速执行的首选模型，它们肯定无法比 GPT 5.6 Sol 更让我安心。


• 由于 DeepSeek V4 Pro 的价格上涨超过 10 倍，所以我会更倾向于使用 Grok 4.6。


• 如果一定要选一个除了 GPT、Claude 之外的主力模型，那还是 Kimi K3。

关于专武

对于 DeepSeek Harness，

意料之中的是它无法提升模型的最终效果，但它确实更适合 DeepSeek 模型。

就如同 Codex 之于 GPT 5.6，Claude Code 之于 Opus 5。

本系列评测以来，所有模型均使用 Copilot 进行，我认同模型在不同提示词下的表现会有差异，但也要提醒模型的表现具有概率随机性，并且模型应该具有足够的泛化能力。

偶然出现的所谓：

XXX 模型/工具 一天没解决的问题，换 XXX 模型/工具 五分钟就解决了！

这种情况并不代表什么，也没有任何的意义。

现在 Agent 工具所提供的工具集都是非常相似的，而无论怎样，模型本身能力并不会被工具集显著影响。

工具集主要是有像 Computer Use 这样的工具提升模型能力的边界。

而现在可以得出的结论是 DeepSeek Harness 现在并没有提供任何类似的优势。

并且，我的评测内容并不考验模型的能力有多丰富，而是纯粹考验模型逻辑理解、推理、指令遵循以及代码生成等自身能力。

提示词的不同会有所帮助，但是在纯粹的智力考验中不应该会有显著影响，如果影响显著，是否也说明该模型是刷分做题家，同样的题型换个参数就又不会做了。

所以我依然坚持所有模型都在尽量相同的输入下进行评测，现在的结论也很明显，好的模型它就是纯粹的好，差的模型你给它所谓的千里马专武，也无济于事。