DeepSeek V4：以有限预算优化 AI 游戏生成

经济型模型能否制作出玩家真正想玩的浏览器游戏？过去一周，我们一直在 OpenGame Studio 中测试这个问题。最新加入测试的是 DeepSeek-V4.1-Flash-1017，它是 DeepSeek V4 系列于 10 月 17 日发布的版本。

我们还测试了 Grok 4.6、Xiaomi MiMo V2.6 Flash、MiMo V2.6 Pro、GLM 5.3 Flash 和 Claude Haiku 5.5。目标是改善生成成本、等待时间、可玩表现和画面质量之间的平衡。游戏成功打开，并不代表玩法正确：玩家按左键时角色仍可能向右移动，金币可能提前到账，暂停时角色也可能继续下落。

最新的 DeepSeek 跑酷原型通过了我们执行的核心玩法检查，美术表现则较为朴素。早期实验暴露了其他问题，其中还包括我们自己交付验证流程的缺陷。这些细节比没有解释的模型排名更能帮助创作者。

DeepSeek-V4.1-Flash-1017 生成的原始跑酷游戏。角色、车道和金币可以辨认；环境仍是基础原型水平。

优化经济型游戏生成

对于小型游戏创作者来说，反复试验很重要。首个版本可能需要调整镜头、操作、碰撞规则或美术方向。实际要问的是：这个过程能产出多少有用且可测试的游戏内容？

对于高难度编程工作，Claude Opus 5.5 这样的旗舰模型是显而易见的替代方案。其官方介绍也提到使用子代理。我们希望先探索更经济的候选名单，再决定是否采用更大的工作流程。光看模型名称无法保证游戏质量；使用多个智能体也是一种可能增加工作量和用量的流程选择。

候选模型各有用途：

• Grok 4.6 提供了通用型参照。对我们而言，它的预算针对性较弱，订阅访问是其吸引力之一。官方发布页面介绍了通过 Grok Build 等工具进行编程的方式。
• Xiaomi MiMo V2.6 Flash 和 Pro 让我们能够比较同系列的两种选择。小米将 Flash 定位为高效、适合频繁使用的型号，将 Pro 定位为更适合复杂推理和项目工作的型号。Pro 是其系列中的旗舰；在本次经济性探索中，它仍是候选之一。
• GLM 5.3 Flash 提供了另一种以效率为重点的选项。其官方介绍说明了这一定位。我们想看看它如何处理完整的游戏需求。
• Claude Haiku 5.5 增加了一个海外的成本敏感型选项。Anthropic 将 Haiku定位为快速、高调用量任务的选择。我们把它作为游戏构建模型测试，测试范围有限，详见下文。
• DeepSeek-V4.1-Flash-1017 是最新实验对象。发布公告包含项目演示。我们使用自己的跑酷需求，观察哪些能力可以转移到 OpenGame Studio。

这份候选名单中来自中国的模型系列更多，是因为价格因素让我们将它们列入考察范围。这反映的是我们的筛选过程，并不代表我们对不同国家模型质量作出结论。

一个跑酷游戏，六种模型实验

我们选用的共同游戏是 Colossal Runner，一款原创第三人称三车道无尽跑酷游戏。角色会自动向前移动。玩家要切换车道、跳过障碍、从头顶障碍下方滑行通过、收集金币，并在碰撞后重开。键盘和触屏应当产生相同的可见结果。

原始需求还包括暂停、使用已获得金币复活，以及挡住两条车道、留下一条安全路线的巨型障碍。这些相互影响的规则，比一个只有移动画面和分数计数器的需求更能体现模型表现。

在 2026 年 10 月 11 日至 17 日进行的实验中，我们重复使用了同一份原创需求：

这些是由开发者逐次运行的实验，适合用作实际对比样例，但有明确限制：每个模型都生成了自己的简报和实现，视觉选择也不相同。测试日期不同，网站环境也未冻结。MiMo Flash 构建前还需要额外讨论。用时不包括讨论、需求拟定和游戏测试；GLM 的时间截至遭拒为止。

对 DeepSeek 跑酷游戏，我们保留了现有生成限制，并使用了与 MiMo 实验相同的 3D 构建指引。验收检查前没有手动修复源代码。本系列实验不能证明具有统计可靠性的速度或质量排名。

MiMo、GLM 和 Haiku 带来了哪些发现

MiMo Flash 生成了可检查的游戏，并提供了有用操作，包括有限范围的键盘、触屏和暂停检查。问题在于金币规则：角色到达金币前就可能获得奖励。收集判断读取了错误的位置字段。画面看起来合理、计数器也在增长，却掩盖了互动逻辑的故障。

MiMo Flash 后续定向修复前的原始输出。收集时机缺陷来自玩法和源代码检查；仅凭这帧画面无法证明该问题。

MiMo Pro 也生成了可玩的原型，方向和金币接触检查结果不错。但在半空中暂停暴露了另一处缺陷：距离和金币停止变化，角色却继续下落。要实现完整暂停，必须冻结相关模拟，包括垂直移动。

MiMo Pro 的原始城市场景。它的暂停缺陷需要在跳跃中途测试；好看的静态画面无法显示此问题。

GLM 有两项需要分开说明的结果。 Studio 运行未能交付，因为我们的验证器把游戏内联代码误读成了被禁止的资源标记。这是平台错误。若将它算成 GLM 无法生成游戏的证据，就会产生误导。

我们恢复了未经改动的原始版本，并单独检查。方向、触屏和暂停的有限检查均正常，但重开后可能残留旧金币显示。这次检查告诉我们产物的行为表现；但它并不能把失败的 Studio 流程说成交付成功。

单独检查的 GLM 恢复版原始产物。此图不代表它曾通过 Studio 成功交付。

Haiku 5.5 在这次样本中较快交付了预览。 开始画面显示后，我们做了初步视觉检查便结束测试。我们没有完成键盘、触屏、碰撞、复活或重开验收。初步印象并未改变我们对 MiMo 实验的偏好，但由于缺少玩法证据，我们无法对 Haiku 的质量作出确定判断。

记录测试日志时要区分不同阶段：已交付、已检查画面和已验证行为，不是同一个里程碑。

为什么按左会变成向右？

Grok 跑酷游戏暴露了最明显的操作问题。从中间车道按 ArrowLeft 后，角色移动到了屏幕右侧。向左滑动触屏也会出现相同结果。

操作前：角色位于中央车道。

按下 ArrowLeft 后：角色明显位于右侧。两张截图均来自未经修改的生成版本。

源代码说明了原因：“向左”处理器将角色移向世界坐标 X 的负方向，但镜头朝向导致这个移动在画面上看起来像向右。键盘和触屏共用同一个车道控制器，所以都受到这个错误影响。

玩家应以屏幕上可见的赛道为参照。坐标数值减少，不代表画面上正确地向左移动。对于跟随镜头，也要检查角色相对于车道的位置，因为角色可能一直居中显示，而赛道在移动。

另一项独立赛车实验也暴露了评估方法的弱点。自动控制器能够补偿反向转向并跑完一圈。现在我们会从全新开始状态分别检查两个方向。跑完整条赛道并不能证明控制标签是正确的。

DeepSeek V4 在跑酷游戏测试中的表现

简短确认需求后，最新的跑酷游戏大约用了七分钟构建。我们通过网站预览测试了原始结果：

• 方向： ArrowLeft、ArrowRight、A 和 D 都会朝正确的可见车道移动。重复输入到达最外侧车道后会停止。
• 触屏： 横屏和竖屏模拟中，左右滑动均能使用；向上跳跃，向下会让角色进入滑行姿势。
• 障碍： 键盘游玩可以越过地面障碍、从头顶横杆下滑过，并从巨型阻挡物旁的安全车道通过。
• 金币和复活： 抵达金币后才会开始收集。复活会扣除已获得的金币并安全恢复游玩；金币不足时，复活不会扣金币或消耗次数。
• 暂停和重开： 在跳跃中暂停会保持高度和距离不变，并阻止赛道输入。重新开始会重置为中间车道、归零距离和可见金币。

有一次障碍物挑战继续超过 216 米，收集到 51 枚金币。浏览器自动化发送的是常规游戏操作。我们没有修改坐标、分数或碰撞状态来取得该结果。

在竖屏浏览器模拟中，向左滑动可抵达可见的左侧车道。尚未测试实体手机兼容性。

我们没有穷尽所有随机障碍序列、火车车顶路线、复活次数限制或后期状态。在已测范围内，这是一个规则处理表现令人鼓舞的可用原型。

逻辑、美术与可读性应分别评估

DeepSeek 跑酷原型中的关键对象可以区分：青绿色角色、明亮的车道边缘、金币和对比明显的危险物。深色、稀疏的环境和简单建筑仍有很大的改进空间。单次结果不能证明 DeepSeek 在逻辑方面普遍优于美术。

我们另行测试的 Neon Harbor Sprint 美术风格鲜明，采用强烈霓虹效果，但汽车轮廓和道路较难辨认。一次性能修改降低了渲染分辨率，提升了响应速度，却损失了画面细节。

另一款独立 DeepSeek 赛车原型。它使用了不同的需求，不属于共同跑酷游戏比较。

我们回到跑酷游戏，因为换成另一款游戏会模糊对比。赛车原型仍带来有用提醒：应在实际游玩尺寸下、游戏运动过程中判断角色、危险物和车道边界是否清晰。特效和界面装饰可以很丰富，但可读性仍可能很差。

提示词和技能限制太多了吗？

为了重复使用，我们有意为跑酷测试编写了较详细的需求。普通创作者应该可以从简短得多的点子开始。协助创作者把想法整理成有用简报，也是产品职责之一。

我们没有进行控制变量的“简短提示词与详细提示词”对照测试，因此不能单靠提示词长度解释方向反转。出错的源代码直接显示了镜头和输入方向之间的关系；同一份需求生成的其他游戏也正确处理了方向。

有些限制能够保护游玩体验：操作一致、金币需要实际接触、暂停完整有效、重开状态干净。另一些选择可以开放给模型，例如主题、配色、镜头表现和场景构造方式。僵化的构建流程也可能让人没有足够空间检查和改进第一个实现。更多修改机会值得测试，但在这里它仍只是一个待验证的假设。

早期尝试说明了为什么流程本身也需要关注。一次 MiMo 尝试在交付游戏前耗尽了响应额度。另一次生成了代码，但提供方数据流故障导致最终交付丢失。这些失败成因不同，应该和玩法缺陷分开记录。因此，不能把所有历史尝试都当成只比较模型本身的 A/B 测试。

创作者可以从这样的需求开始：

制作一款简洁的 3D 跑酷游戏，设有三条车道。让我使用键盘或触屏左右躲避、跳过障碍物并滑过横梁。我想要一个清晰易认的角色、令人满足的金币收集反馈，以及碰撞后快速重开的方式。场景主题和美术风格由你决定。

这是建议的起点，不是本次对比测试所用的原始需求。Studio 可以协助补齐缺少的规则、确认简报，同时保留创作选择的空间。然后用简短试玩找出下一项值得修改的内容。

这些测试会怎样改变我们的下一轮实验

对我们来说，优化现在还包括交付可靠性、检查所需时间，以及可玩结果需要多少修复。低成本生成只有在结果经得起日常输入，并能通过可控的修改流程得到改进时才有价值。

我们会保留原始输出、记录每次尝试达到的阶段，并根据可见行为检查键盘和触屏输入。今后的对比可以保持游戏不变，只改变一个流程变量，例如简报长度或修改机会。这些观察本身并不能预测哪种模型会在那次实验中胜出。

想体验可玩的示例，请访问 Colossal Runner。公开的精选版本包含后续修复，与本文展示的原始实验不同。你还可以浏览其他浏览器游戏，寻找想要创作的体验灵感。

有个小型游戏创意？在 OpenGame Studio 中开始编写需求，确认核心循环，再用真实输入测试首个版本。

来源说明

模型名称、发布时间背景和厂商定位由官方来源支持：DeepSeek 10 月 17 日发布、Grok 4.6、MiMo V2.6 Flash、MiMo V2.6 Pro、GLM 5.3 Flash、Claude Haiku 5.5，以及作为未测试旗舰背景示例的 Claude Opus 5.5。

玩法观察和构建用时来自我们在 OpenGame Studio 中的实验及保留的原始版本。八张图片是检查时截取且未经修改的画面，使用原创程序美术，或采用 CC0-1.0 许可的 OpenGame M0 角色素材。没有任何图片是提供方的演示内容或增强重制图。