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

项目

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

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

• 第一轮


• …


• 上一轮

模型来源

• Kimi K2.7 Code: 官方 API


• Grok 4.3: Grok Build


• Grok Build 0.1: Grok Build


• Composer 2.5: Grok Build

速度

令牌数

• Kimi K2.7 Code: 26.1M(≈¥40)


• Grok 4.3: 未知


• Grok Build 0.1: 未知


• Composer 2.5: 未知

代码行数

• Kimi K2.7 Code: +1323, -18


• Grok 4.3: +980, -13


• Grok Build 0.1: +1565, -10


• Composer 2.5: +1014, -44

完成度

Kimi K2.7 Code

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

Grok 4.3

审查结论: 无法编译，出现常见问题和多个功能未实现问题。

Grok Build 0.1

审查结论: 无法编译，出现常见问题和少许功能未实现问题。

Composer 2.5

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

最终总结

Kimi K2.6 是首个 T1 国产模型，所以对 K2.7 Code 的期望其实不算高，只是希望它能够保持前代的水平，何况它还是个专精模型。

做题过程：

Kimi K2.7 Code 花了有史以来最长的时间，接近 40 分钟！也花了有史以来最多的令牌数，26M！

期间出现了两次上下文压缩的情况，看来上下文 256K 对于这个复杂度的需求来说还是有点吃紧了。

它首先会在编写代码前阅读代码库，并且在多次编辑文件期间都会回头再次阅读更多的代码，可以说它非常倾向于参考现有代码，

完成得越好的模型在这方面也是少不了消耗时间，虽然总比不阅读代码库且写出错误代码的模型要更好，但是已经有点极端了（导致多次上下文压缩）。

它的工作方式类似 阅读 → 编写 → 阅读更多 → 继续编写 → 全面检查 这个流程，因为在最后它貌似将所有代码都检查了一遍。

这导致它有点像是力大出奇迹的那种，期间思考内容出现大量自言自语地逐个地方去检查和反思：

Now, maybe bubble text could be set to player name. Not required.



Now, maybe we should ensure SkinAttrUI is closed when clicking bg. We did.



Now, maybe need to handle m_btnCloseBg area: In UIWindow, Close() hides window. Good.



Now, potential issue: SkinAttrUI is a popup with no blur? The [Window(UILayer.UI)] default maybe fullScreen false? Not specified. It will be a normal window. Prefab likely has dark bg. Fine.



Now, maybe we should check UILayer enum values and UI attribute. Not needed.



Now, let's do a final read of SkinUI and SkinAttrUI to catch syntax errors.

Now, maybe bubble text could be set to player name. Not required.



Now, maybe we should ensure SkinAttrUI is closed when clicking bg. We did.



Now, maybe need to handle m_btnCloseBg area: In UIWindow, Close() hides window. Good.



Now, potential issue: SkinAttrUI is a popup with no blur? The [Window(UILayer.UI)] default maybe fullScreen false? Not specified. It will be a normal window. Prefab likely has dark bg. Fine.



Now, maybe we should check UILayer enum values and UI attribute. Not needed.



Now, let's do a final read of SkinUI and SkinAttrUI to catch syntax errors.

我在观察时一度以为它已经死循环了，为什么，因为它当时已经跑了将近三十分钟了，而且：

账户里的 36 块钱都烧完了还欠费了。

它倾向于为不同职责的类创建新文件，之前的模型会更倾向于在已有文件中添加类，可能添加的甚至是毫不相关的类。

它在完成需求的同时顺便接入了功能解锁，这算是个加分项，但只有非常少模型做到，这也是体现了它极其全面地阅读代码的优势。

对比上一代 K2.6 出现的 4 个问题，只有 1 个称号预览资源错误的问题还是一样存在，但是多出了一个未清理旧数据的高风险问题。

总得来说，K2.7 Code 它比 K2.6 确实要做得更好，但缺点就是在上代耗时就不低的情况下（33 分钟），这代耗时又慢了 6 分钟，并且消耗令牌数翻了接近三倍！

但作为唯二的 T1 国产模型，也没有其它可以选择的了，如果你财力雄厚，可以尝试一下它的高速版本，如果真的有 5-6 倍的加速且保持同样的性能，

那么如果能在 6-8 分钟就做到这种完成度，那就太夯了。

Composer 2.5 据称依然是基于 Kimi K2.5 训练而来的，而 Cursor Bench 也是我为数不多认为比较接近实际体感的一个基准测试，在这个排行榜中，Composer 2.5 的表现强于 GPT-5.5(high) 和 Opus 4.8(xhigh)。

在 2.0 版本发布时我就很想评测，但是没有渠道可以调用。那么这次多亏了 Grok Build 内置了 Composer 2.5 模型，才有机会对其进行评测。

那么首先一上来 Composer 2.5 的速度就把我吓到眩晕，刚经历过 K2.7 Code 的 40 分钟，结果它只花了 3 分钟！

而用时低于 15 分钟的模型大家都可以在表格中看到基本都是稳居 T3，并且代码行数也只正好写了 1000 行出头，光看这两个数据的话，那当时估计就是坏了坏了。

等 GPT-5.5(xhigh) 审查完，发现它的完成度竟然比 Kimi K2.6 要好一点！稳稳处于 T1 行列。

我有点不太相信这个结果，于是正好我就第一次来尝试使用 Claude Fable 5 再次进行审查，这也是首个被不同模型进行复查的模型。

那最终 Fable 5 的审查结果，发现它依然犯了类似 Kimi K2.6 / K2.7 Code 都有的预览资源错误问题，但是这并不影响它最终的评级。

没想到惊喜在这，如果说 K2.7 Code 高速版只要 6-8 分钟，那么 Composer 2.5 可以说是 K2.6 的高速版了，并且快了 10 倍！

并且 Composer 2.5 的过程给人的感觉是自信、精准，它没有给人一种 Kimi K2.6 以来的力大出奇迹的感觉，仅用非常少的步骤就将相关代码阅读完毕，并且编写的代码行数也非常少。

我认为 Grok 4.3 是个有潜力的模型，它在收到需求后，按照需求的要求对所有易错点（比如配置枚举值转换）、不确定的地方都进行了询问，这个很少模型会做到。

但我让它自行决定最合理的方案，因为其它模型我也没有进行干预，结果它选择的方案是忽略问题，再加上代码语法错误，导致无法编译沦落 T3。

Grok Build 0.1 则和 Grok 4.3 半斤八两，它的情况也比较少见，属于写了枚举值转换函数但是写错的，也出现了幻觉式的错误，导致无法编译，沦落 T3。

总结。

Kimi K2.7 Code 依然是国产表现最好的模型（在这个需求上），过程有点像是不够聪明就勤奋仔细、大力出奇迹，时间和金钱成本都太高，我可能不会考虑用它。

Composer 2.5 则非常夸张，仅用时 3 分钟就达到了超过 Kimi K2.6（一点点）的表现，过程表现得自信、精准，我已经迫不及待地将它作为辅助模型完成一些小需求了。

Grok 系列依旧如测。

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

这次也同步更新了 Grok Build OAuth 的支持，一起在 Copilot 中试试 Kimi K2.7 Code 和 Composer 2.5 吧，期待你的反馈！