国产大模型跑分一个比一个高，到底谁能真的干活？

最近这几个月，相信大家都被大模型反复“轰炸”了，从4月的DeepSeek V4开始，然后是GLM 5.2 、Kimi 2.7、MiniMax M3，每一个大模型都会拿出跑分来证明，说自己非常厉害。

但是在实际的工作中，它们到底是“真神”还是“花架子”？ 这个问题可能每个人都有自己的看法。

作为一名混迹后端多年的资深码农，我不太看重这些评分，更相信自己的手感。

所以，我打算掏点儿真金白银，把DeepSeek V4 Pro、Kimi 2.7、MiniMax M3拉到同一个竞技场(GLM 5.2缺席，实在抢不到它的Coding Plan)，在长上下文、多模态理解、办公、Coding领域找一些真实场景，看看它们的表现到底怎么样。

01

真实代码修复

现在的大模型如果不配置1M上下文，感觉都不好意思和人打招呼了。

既然如此，那我就不客气了，找一个大型项目试一试。

Django，我很早之前用过的一个Python Web框架，大概有50万行Python代码，足够大了。

不但考验各个模型的长上下文窗口，更考验它的有效理解和推理能力。

我还特意找了一个真实的issue：

https://code.djangoproject.com/ticket/36940，

打算让这个三个模型修复一下，看看效果如何。

不过这个issue写得太细节了，直接展示了要改的class，不好不好，我重新写了一下，站在用户角度描述：

提示词（可上下滚动）

在Django部署了两个应用：

/myapp/ → 应用 A

/myapplication/ → 应用 B

最近有用户报告以下异常行为：

用户反馈 1: 当用户访问https://example.com/myapp/profile 行为正常，进入自己的 profile 页面。

用户反馈 2：当用户访问：https://example.com/myapplication/profile 返回了404

你帮我看看是怎么回事？

结果，可能是我这个描述写得有过于贴近用户了，导致难度过高，三个模型虽然都猜到了大概的问题，但是都把注意力放到了应用的urls.py文件，而不是修复框架的Bug。

没办法，我只好更加明确一点，提示它们去框架的ASGI模块去看看。

这一下，差别就出来了。

MiniMax M3精准地定位了Bug： removeprefix是纯字符串前缀匹配，不尊重路径段边界。

这正是产生这个Bug的准确原因。

给出的修复建议也非常准确： 按“段边界”做strip.

更让我意外的是，它还对比了WSGI ，说WSGI 服务器把 SCRIPT_NAME 和 PATH_INFO 分开传给 Django，Django 不做 strip，直接读 PATH_INFO，ASGI 这层自己动手strip，反而引入了 bug。

嗯，举一反三，观察全局，感觉像个老程序员的样子。

相比而言，Kimi 2.7 和 DeepSeek V4 Pro 还是没有定位到问题。

Kimi说真正出问题的地方在resolvers.py ：

神奇的是，DeepSeek 也认为 ASGI Handler没问题，认为问题出在resolvers.py，两个家伙像商量好的一样。

不过，我再稍微提示一下，Kimi 和 DeepSeek都能正确地解决问题了。

可以看出，三个大模型都准确地理解了问题，并且推导出是url解析匹配的问题。

但是真正定位的时候，MiniMax M3表现要好一些，找到了准确的地方，Kimi 和 DeepSeek差不太多，还需要进一步辅助。

不过我必须得说一下，对于这种巨型复杂项目中一个细碎的Bug，定位和修复起来是非常有挑战的，关键的问题就是一定得提供足够的上下文信息，否则即使是一个非常有经验的程序员，他也不一定能快速搞定，更不用说初次面对这个源码的大模型了。

M3 的 1M 上下文确实很长，但在使用上也有些注意事项，它主要用于项目级代码理解和重构，长文档全文处理，不适合短问答/单轮对话，以及无上下文依赖的轻量创作。

在Agent中使用的时候默认还是512K 上下文，需要 1M 的还要手动切换，Prompt结构最好是固定内容前置(系统提示、参考文档、代码库)，变化内容后置(当前查询)，这样可以提升cache命中率。

更详细的用法可以参考一下MiniMax官方在小红书上分享的使用指南：

02

城市躲避游戏

测完了大型项目的代码修复，接下来我想试试这几个国产模型的综合编程能力。

我不想用电商网站、博客等CRUD的系统，太简单了，我打算用3D游戏来考验一下它们，毕竟3D游戏涉及到多个技术领域的协同：

3D 图形（Three.js），数学（向量、矩阵、碰撞检测），物理模拟，相机控制，动画系统， 输入系统（键盘、鼠标）， 游戏状态管理， UI 与 HUD....

这种测试更接近真实的软件工程，也更能拉开模型之间的差距。

提示词（可上下滚动）

请生成一个完整的 HTML 文件，实现一个可以直接运行的 3D 城市躲避游戏。

要求所有代码写在一个 HTML 中，仅允许使用 Three.js，不得依赖任何外部模型、贴图、音频或其他资源，所有场景和物体都需要程序生成。

游戏玩法

玩家扮演一名城市中的行人，需要不断向前奔跑，在繁忙的街道中躲避车辆，同时尽可能收集金币获得更高分数。

游戏目标是在保证生存的情况下获得最高分。

玩家控制

WASD 控制移动

Space 跳跃

Shift 加速奔跑

鼠标拖动旋转视角

摄像机采用第三人称跟随模式，能够平滑跟随玩家

城市场景

自动生成一个具有现代城市风格的场景，包括：

道路

十字路口

人行道

建筑物（高度随机，要带窗户纹理）

树木

路灯

红绿灯

草地区域

整个城市不需要无限大，但要有一定规模，避免场景过于单调。

所有建筑均使用程序生成。

车辆系统

自动生成不同颜色和尺寸的车辆。

车辆需要：

沿道路正常行驶

在路口能够转弯或直行

保持合理车速

不要互相穿模

数量会随着游戏时间逐渐增加

车辆应持续刷新，而不是一次生成后保持静止。

收集系统

地图随机生成金币。

玩家接触金币后：

金币消失

播放简单动画

分数增加

随机位置重新生成新的金币

碰撞规则

玩家撞到汽车：

扣除生命值

玩家短暂后退

有短暂无敌时间

生命值归零：游戏结束

显示最终得分

支持重新开始

难度系统

游戏运行过程中：

每隔 30 秒：

汽车数量增加

汽车速度略微提升

金币刷新速度提高

难度应平滑增长。

HUD

屏幕左上角实时显示：

当前分数

剩余生命

游戏时间

当前难度等级

游戏结束时显示：

Game Over

最终得分

存活时间

Restart 按钮

光照

至少包含：

环境光

平行光（太阳）

阴影

画面具有一定层次感。

动画效果

包括但不限于：

玩家跑步动画（可简单摆臂）

金币旋转

汽车持续运动

摄像机平滑跟随

玩家受击动画

性能要求

即使存在：

数十辆汽车

上百栋建筑

多个金币

依然保持流畅运行。

尽量减少重复创建对象。

代码要求

代码结构清晰，建议划分为：

场景初始化

玩家控制

城市生成

车辆系统

金币系统

碰撞检测

UI

游戏循环

所有逻辑放在一个 HTML 文件中，可直接保存后打开运行。

这次测试的结果比较有意思，首先三个模型都是一次开发完成，立刻可以运行，角色移动，Shift加速，Space跳跃，鼠标拖动旋转视角，收集金币，躲避车辆全都一次实现，可见国产的模型现在发展得都相当不错了。

从实现速度上来看， DeepSeek v4 Pro > Kimi 2.7 > MiniMax M3。

但我也注意到，MiniMax M3慢的主要原因是它写完代码后，主动进行了测试，这也让它在逻辑实现上基本没有问题，而另外两家多少有点儿小Bug。

从效果上来看，DeepSeek构建了一个密集街区的“水泥森林”，树和路灯太多了，操作起来略微费劲，道路、长椅、垃圾箱、金币实现得都不错，角色和车辆碰撞时实现了抖动、变色的特效。

（注意：由于我要求不依赖任何外部模型和贴图，所以人物、车辆、树基本上都是几何体的堆叠，这不是测试的重点，不用在意。）

（DeepSeek的效果）

有个唯一的小Bug：开场时，由于玩家操作的人物出现的位置是随机的，有时候会被困某个障碍物中，动弹不得，不过这是个小问题。

MiniMax M3 生成的地图区域很大，显得比较空旷，光影效果也可以，有意思的是它还给角色戴了一个小红帽。

像DeepSeek一样，基本功能也都实现了，我还注意到还实现了双向两车道效果，DeepSeek有时候会出现两车互相穿过，MiniMax这边不存在这种情况。

（MiniMax M3的效果）

Kimi设计的街区也很空旷，也实现了基本功能，就是角色形象丑一点儿，道路也没有体现出那种柏油马路的效果，垃圾桶、长椅、路灯也不太好看，但是建筑设计得错落有致的，在玩儿起来的时候感觉更加丝滑。

（Kimi 2.7效果）

Kimi在开始的时候有个比较严重的Bug，就是“上下键”的效果弄反了，稍一提示就改了过来：

总的来说，我觉得DeepSeek V4 Pro呈现的效果最好，MiniMax M3 在逻辑上实现得最完善。

03

PDF 问答

前面两个都是让大模型看代码，写代码，在办公领域，它们的表现怎么样呢？

我找了一个英伟达的2025年报PDF，这个文件很大，48M，181页。

我想把它发给三个大模型，看看它们能不能像一个人一样“读文件做工作”，能不能在几十页甚至上百页的文档里准确找到需要的数据，看懂表格里的数字关系，把分散在不同页面的信息拼起来，再做一步甚至多步计算，最后给出一个靠谱的答案，而不是凭感觉乱猜。

问题1：Data Center 收入与 Gaming 收入相比，在 FY2025 是多少倍？

这个问题比较简单，就是从表格中提取数据。

MiniMax M3 找到了正确的表格，数据最为精确：

DeepSeek 和 Kimi 又像商量好似的，不约而同地找到了另外一个表格中的粗略的值，真是有意思：

问题2 ： 计算 NVIDIA 从 FY2023 到 FY2025 的营收复合年增长率（CAGR）。

这个问题不但涉及到数据提取，还要进行多步计算，三个模型的回答都非常漂亮，完全一致，这里贴一个MiniMax M3的截图：

问题3：在 FY2025 中，是 Data Center 对营收增长的贡献更大，还是其他所有业务合计贡献更大？请给出计算过程。

这个问题就更难了，有点儿像分析师的工作了，这次三个模型都正确地计算了英伟达总营收的增长，Data Center的增长，其他业务的增长，并且计算得出了结论：DataCenter的贡献更大。

但是很明显，MiniMax M3给出的结果最详细，最清晰，最精确：

总之，给我的感觉是三个大模型在对PDF问答时表现都相当好，MiniMax M3相对更加精准一些。

04

金融场景

我在测试MiniMax的时候，偶然间发现MiniMax Agent 网页端上线了金融场景相关的模块。

https://agent.minimaxi.com/

通过它可以链接金融数据库，目前覆盖A/H/美股、基金、期货、固收和宏观数据的问答场景。

比如，可以问它一个问题：中证红利低波动指数最近半年怎么样？

这对于投资/炒股的同学来说是个相当不错的工具，有空大家可以去试一下。

05

我发现做这种评测还是挺费劲的，先构思场景，然后每种场景都得让几个大模型都跑一遍，仔细观察和分析，看看它们的输出结果，很耗费时间（我甚至有点儿庆幸，没有抢到GLM-5.2，要不然就更费劲了）。

不过，观察各个大模型在同一场景进行竞赛，也是挺有意思的一件事情，从我有限的测试看：

三个大模型PDF问答方面都非常棒，都能理解问题，进行准确推理和计算，可以成为办公的好帮手了。

MiniMax M3 在大型代码库修复Bug，长上下文方面超出我的预料，非常精准。

在复杂的3D游戏领域，DeepSeek V4 Pro干活儿很快，代码也写得很好，很老道，MiniMax M3 在逻辑方面考虑得很完善，Kimi 2.7 则中规中矩。

总之，我觉得完全可以放心地把这些国产开源大模型接入到工作流当中了，但是程序员还得尽可能地去提供更多上下文，指导AI工作。

下一次测试我会争取更多的场景，更多的模型（尤其是海外的模型），也希望国产开源模型有更优异的表现。