DeepSeek V4 Pro对决Codex：AI复刻饥荒游戏实测对比

一场不严谨但有趣的实测

8月13日凌晨，DeepSeek^广告悄然放出了V4 Pro模型。一位B站UP主在睡不着的深夜，决定用一个有意思的任务来验证它的实力——让AI从零复刻经典生存游戏《饥荒》。

《饥荒》（Don't Starve）是由加拿大独立游戏工作室Klei Entertainment于2013年发布的开放世界生存游戏。玩家扮演被传送到一个黑暗荒野的科学家Wilson，需要在程序生成的随机地图中采集资源、制造工具、建造营地、狩猎食物，并在夜间保持火光以抵御暗影怪物。游戏的核心机制包括饥饿值、生命值和理智值三大生存属性的管理，以及昼夜交替和季节变化带来的环境挑战。其独特的哥特式手绘美术风格和高度自由的玩法使其成为生存游戏品类的标杆之作。从AI复刻的角度看，《饥荒》是一个极具挑战性的目标——它涉及2D渲染、物理碰撞、状态机、合成配方系统、AI敌人行为等多个技术子系统的协同工作。

具体来说，这些技术子系统各自都有相当的实现难度。以程序化地图生成（Procedural Generation）为例，《饥荒》使用基于噪声函数（如Perlin噪声）的算法来生成地形分布，再叠加一套规则系统来决定不同生物群落（森林、沼泽、草原等）的资源密度和生物种群配置，确保每次游戏都有独特但平衡的体验。敌人AI行为则依赖有限状态机（Finite State Machine, FSM）来实现——每个敌人在「巡逻」「追击」「攻击」「逃跑」等状态之间根据条件转换，看似简单的蜘蛛或猎犬行为背后是多层状态嵌套和优先级判定。合成配方系统则涉及一张庞大的依赖关系图——玩家需要先采集基础材料，再按特定组合在不同制造站（科学机器、炼金引擎等）中合成高级物品。要让AI从零实现这些系统并使其协同工作，远比生成几个独立的代码函数困难得多。

为了让对比更有看头，UP主同时让OpenAI的Codex（模型选用5.6版本，推理强度极高）执行完全相同的任务。需要提前说明的是，由于DeepSeek官方的Agent工具尚未发布，DeepSeek V4 Pro只能借助第三方工具Zcode来运行，而Codex则使用官方自带环境。

这里有必要补充一下两者的技术背景。DeepSeek V4 Pro是深度求索（DeepSeek）于2025年8月发布的新一代大语言模型，延续了其在开源社区中的强势地位。DeepSeek此前凭借V3和R1系列模型，在代码生成、数学推理等领域展现了与GPT-4o级别模型相当的竞争力。其技术架构采用了混合专家模型（Mixture of Experts, MoE），这是一种将模型参数分散到多个「专家子网络」中的架构设计——在推理时，每个输入token只激活部分专家网络参与计算，从而在拥有超大规模总参数的同时，保持相对可控的推理计算成本。这一架构使得DeepSeek能够以较低的推理开销达到与密集模型（Dense Model）相当的性能表现，也是其在开源社区中实现高性价比的技术基础。而Codex则是OpenAI于2025年推出的专用编程Agent产品，基于codex-1模型，它不仅是一个语言模型，更是一套包含代码执行沙箱、文件系统访问、终端操作和测试运行在内的完整工程化环境。值得一提的是，Codex的产品形态经历了显著演变——2021年OpenAI最初发布的Codex是一个基于GPT-3微调的代码补全模型，主要为GitHub Copilot提供代码建议；而2025年的Codex已经进化为一个完整的编程Agent，能够自主理解任务、编写代码、运行测试、修复错误，其底层的codex-1模型专门针对软件工程任务进行了强化学习训练。这一区别至关重要——Codex并非单纯的语言模型，而是一个「模型+工程环境」的耦合体。

这里需要解释一下Agent工具与传统代码生成的本质区别。传统代码生成是「单轮」的——用户给出提示，模型返回代码片段，交互到此结束。而Agent模式是「多轮闭环」的——AI不仅生成代码，还能自主执行代码、观察运行结果、诊断错误、修复问题，甚至规划多步骤任务。这种能力依赖于底层的工具调用（Tool Use）机制：模型通过结构化的函数调用接口，与文件系统、终端、浏览器等外部工具交互。更具体地说，Agent的工作流程通常遵循一个「规划-执行-观察-反思」（Plan-Act-Observe-Reflect）循环：模型首先将大任务拆解为子步骤（规划），然后通过工具调用执行每个子步骤（执行），接收执行结果和错误信息（观察），最后基于结果决定是继续下一步还是回溯修复（反思）。这个循环的效率和可靠性，在很大程度上取决于工具链本身的响应速度、错误信息的详细程度、以及模型与工具之间的接口设计。Codex作为OpenAI的官方产品，其沙箱环境经过专门设计，支持代码执行、包安装、测试运行和错误捕获的完整流程。Zcode作为第三方工具，虽然也提供了类似功能，但在与DeepSeek模型的适配深度上可能存在差距。

这就带来了一个绑不开的变量问题：两者的运行环境并不一致。UP主在视频开头就坦言，这是一次「纯主观、不够严谨』的测评，看个乐呵即可。但即便如此，实测过程中暴露出的一些细节，依然值得深入分析。

DeepSeek V4 Pro的表现：前端惊艳但玩法崩溃

规范的规划流程与自我测试机制

仅凭「复刻游戏饥荒」六个字的提示词，DeepSeek V4 Pro在Zcode上花费了43分钟完成整个项目。值得肯定的是，它的工作流程相当规范：

动手前主动询问了三个关键问题：技术栈选择、玩法范围、画面风格；
明确声明所有素材原创自绘，不复制官方素材；
给出了完整方案，包括文件结构、玩法内容、实现步骤，预估约2000+行代码，并分阶段构建。

从实测结果来看，两个AI都选择了基于Web技术栈（HTML5 + JavaScript + Canvas API）来实现游戏。HTML Canvas是浏览器原生提供的2D绘图接口，允许通过JavaScript在网页上逐像素地绘制图形、处理动画和响应用户输入。对于像《饥荒》这样的2D游戏，Canvas提供了足够的渲染能力，且无需额外安装游戏引擎或开发环境。典型的Canvas游戏架构包括：一个以每秒60帧运行的游戏主循环（Game Loop），负责依次执行输入处理、游戏状态更新和画面渲染三个阶段；一个场景管理系统来处理地图生成和对象管理；以及一套事件监听机制来响应键盘和鼠标操作。

在实现层面，Canvas游戏的主循环通常基于浏览器提供的requestAnimationFrame API——这个API会在浏览器下一次重绘之前调用指定的回调函数，通常以60fps的频率运行（与显示器刷新率同步）。每一帧内，游戏需要依次完成三件事：处理自上一帧以来积累的用户输入事件（键盘按键、鼠标点击和移动）、更新所有游戏实体的状态（位置、生命值、动画帧等），以及将更新后的状态渲染到Canvas画布上。Canvas本身只提供基础的绘图原语（矩形、圆形、路径、图像绘制等），不内置物理引擎或碰撞检测系统，这些都需要开发者（或AI）自行实现。对于更复杂的2D游戏，开发者通常会选择Phaser、PixiJS等成熟的HTML5游戏框架来处理这些底层细节，但AI在本次实测中选择了直接使用原生Canvas API——这虽然降低了外部依赖，却大幅增加了需要手动实现的代码量和出错概率。另外值得注意的是，Canvas与WebGL存在重要区别：Canvas 2D上下文是基于CPU的软件渲染，适合简单2D场景；WebGL则利用GPU加速，适合粒子系统、光影效果等高性能渲染需求。对于《饥荒》的复刻而言，Canvas 2D已经足够。

最让人意外的是它的自我验证能力。DeepSeek调用浏览器打开游戏页面进行测试，甚至截图验证渲染是否正常。但DeepSeek并不具备视觉理解能力，看不懂图片，于是它退而求其次——读取游戏内部状态和画布像素来判断渲染情况。

这种自我验证策略是当前AI编程领域的一个重要研究方向。传统的AI代码生成是单向的——模型输出代码，人类测试。而Agent模式下，AI需要具备「写代码→运行→观察结果→修复」的闭环能力。DeepSeek的做法颇具巧思：作为纯文本模型，它无法像具备多模态能力的模型那样直接「看懂」截图，因此采用了一种替代方案——通过读取HTML Canvas的像素数据和游戏内部状态变量来间接判断渲染是否正确。具体来说，Canvas API提供了getImageData()方法，可以读取指定区域的像素RGBA值——如果某个应该绘制了树木的区域全是透明像素，就说明渲染出了问题。这种方法在逻辑上是可行的，但存在明显盲区：它能验证「数据层」的正确性（比如饥饿值是否在下降），却很难验证「交互层」的正确性（比如鼠标点击是否能触发采集动作），而后者恰恰是游戏体验的核心。

DeepSeek版本中「点击采集无效」的问题，很可能出在Canvas的鼠标事件监听和碰撞检测逻辑上——这需要正确计算鼠标点击坐标与游戏对象在Canvas坐标系中的位置关系。Canvas中的坐标处理是一个常见的陷阱：鼠标事件返回的是相对于视口（viewport）的客户端坐标（clientX/clientY），需要通过getBoundingClientRect()将其转换为Canvas元素内部的坐标，如果Canvas存在CSS缩放或设备像素比（devicePixelRatio）不为1的情况，还需要额外的坐标变换。碰撞检测则需要判断转换后的点击坐标是否落在游戏对象的碰撞区域内——常用的算法包括AABB（轴对齐边界框）检测和圆形碰撞检测，前者将对象简化为矩形区域判断点是否在矩形内，后者计算点到圆心的距离是否小于半径。这些看似简单的计算，在涉及摄像机偏移、地图滚动、对象层级排序等因素时会变得相当复杂，而纯文本验证手段很难覆盖这类问题。

它还自己「玩」了一遍游戏，验证「饥饿值随时间下降」等机制，声称38项测试全部通过。

DeepSeek自己试玩验证游戏机制

实际体验：只剩移动和挨揍

然而理想丰满，现实骨感。当UP主实际试玩时，问题接踵而至：

前端界面确实做得不错，首页观感尚可，采用了简约手绘纸片风；
但核心玩法几乎全线崩溃——采集不到东西、攻击（F键）无效、无法暂停、无法合成物品；
玩家角色基本只剩下「移动」和「挨揍」两个功能；
到了夜晚需要火光，但由于没有火，角色只能眼睁睁地「时序掉血」直至死亡。

DeepSeek在验证报告里对此有所交代：由于测试浏览器环境的问题，它对「画布点击交互」并未进行实测，并将其归为「环境问题，非游戏问题」。这也为后续的分析埋下了伏笔。

而这个「环境问题」恰恰暴露了Zcode作为第三方Agent工具的局限性。与Codex这样由模型开发商深度定制的官方Agent环境相比，第三方工具在多个维度存在天然劣势：首先是工具链适配——官方环境可以针对模型的输出格式、上下文窗口管理和函数调用机制做专门优化；其次是测试反馈闭环——Codex能直接在沙箱中运行代码、捕获错误并自动修复，而Zcode的浏览器交互测试能力明显不足；最后是上下文管理策略，不同工具对长任务的记忆保持和子任务拆分方式也大不相同。在一个2000+行代码的项目中，如果Agent工具无法有效管理上下文窗口——比如在修改后期文件时遗忘了前期文件的接口定义——就很容易产生接口不匹配、函数签名错误等集成问题。Codex通过其沙箱中的文件系统索引和代码搜索工具来缓解这一问题，而第三方工具在这方面的支持程度参差不齐。这些差异直接影响了最终产出的质量。

Codex的表现：界面稍逊但玩法扎实

两个对照实验

UP主给Codex安排了两个项目：

项目一：直接把DeepSeek生成的方案文档喂给Codex，让它照做。耗时19分钟，测试过程中没有发现明显错误。

项目二：与DeepSeek一样，只给六个字的提示词，让它自由发挥。耗时20分钟。

Codex执行任务的过程

游戏功能基本完整

虽然UP主承认Codex做的前端界面没有DeepSeek那么好看，但玩法的完整度形成了鲜明反差：

开局自带甘草、树枝、浆果、碎石等资源；
支持暂停功能，左上角还附有快捷键说明；
E键交互可拾取，空格键攻击有效；
支持用C键合成石斧，武器能提升伤害；
天黑前可以制作火把照明，甚至手上有材料时能「秒搓火把」。

这些正是DeepSeek版本完全缺失的部分。UP主一度调侃：「不对不对，不是DeepSeek的问题，一定是Zcode的问题。」

Codex版本中玩家可以正常制作火把

详细文档显著提升AI产出质量

一个有意思的发现是：给Codex详细文档做出来的项目，明显优于只给六字提示词的版本。而那份详细文档恰恰是DeepSeek写的。这从侧面印证了DeepSeek V4 Pro在规划和方案设计层面的能力并不弱，问题更多出在执行和自我验证环节。

这一发现深刻印证了提示词工程（Prompt Engineering）领域的一个核心原则——大语言模型的输出质量与输入信息的丰富度高度正相关。「复刻游戏饥荒」这六个字，对于人类开发者而言包含了大量隐含知识（游戏机制、交互方式、美术风格等），但对AI而言，这些都需要被显式地展开。DeepSeek生成的方案文档实际上完成了一次「隐性知识显性化」的过程——将六个字扩展为包含文件结构、玩法细节、技术栈选择的完整规格说明。这与软件工程中「需求规格说明书」（Software Requirements Specification, SRS）的作用高度类似——一份好的SRS能大幅降低开发过程中的歧义和返工。当这份文档被喂给Codex后，后者的产出质量明显优于自由发挥版本。这说明在AI编程场景中，「需求分析」和「方案设计」的能力同样是核心竞争力，而非仅仅是代码实现能力。在实际工作流中，这也启示我们可以考虑「分工协作」的模式——用一个模型负责需求分析和架构设计，再用另一个模型（或同一模型的Agent环境）负责代码实现，从而充分发挥不同模型或环境各自的优势。这种「多Agent协作」的思路在研究社区中已经开始被探索，例如微软的AutoGen框架就支持多个AI角色（产品经理、架构师、程序员、测试员）之间的对话式协作，模拟真实软件团队的分工模式。

不过Codex的第二个项目也存在瑕疵，比如白天和黑夜的时间刻度显示不准确——明明该是晚上，界面却显示白天。经过修改后有所改进，比如可以切换手持物品，但时间刻度问题依然没能完全修复。

核心问题：模型能力还是工具环境的差异？

运行环境差异是关键变量

这是本次实测最值得思考的问题。UP主的初步结论是：

DeepSeek V4 Pro + Zcode做这个饥荒游戏「特别垃圾」，但很可能不是模型本身的问题，而是Zcode无法充分发挥DeepSeek V4 Pro的能力。

支撑这一判断的关键证据：

DeepSeek的规划能力是过硬的——它写的方案文档，让Codex都能做出比自由发挥更好的成品；
点击采集功能始终无法复现，即便让DeepSeek修改后仍然失败，且DeepSeek自己也明确指出是测试环境（浏览器点击）的问题；
UP主坦言自己在Zcode上使用较少，此前只用它处理本地任务，从未做过完整项目，对Zcode的运行机制并不熟悉。

换句话说，这次对比在执行环境的公平性上存在硬伤。Codex使用的是官方深度优化的Agent环境，而DeepSeek被迫使用第三方工具，两者的工程化能力、测试反馈闭环并不在同一水平线上。模型能力与工程环境的耦合，让「谁更强」的结论变得模糊。

这也暴露了当前AI编程评测中一个普遍存在的方法论困境：如何将「模型能力」与「工程环境能力」解耦。学术界常用的代码评测基准如HumanEval、MBPP、SWE-bench等，通常在标准化环境下测试模型的代码生成能力，能够较好地控制变量。其中HumanEval由OpenAI于2021年发布，包含164个Python函数级编程题，每题提供函数签名和文档字符串，要求模型补全函数体并通过单元测试；MBPP（Mostly Basic Python Problems）由Google发布，包含约1000个入门级编程题，覆盖更广泛的基础编程能力；SWE-bench则由普林斯顿大学于2023年发布，从真实GitHub项目中提取Issue和Pull Request，要求AI在完整代码库上下文中定位问题并生成修复补丁，代表了更接近真实软件工程的评测难度。然而这些基准主要测试「函数级代码生成」或「代码修改」能力，与本文实测中「从零构建完整项目」的场景存在较大差距——后者涉及架构设计、多文件协调和系统集成等更高层次的工程能力。

近年来，研究社区也开始探索更贴近Agent场景的评测框架。例如AgentBench（由清华大学于2023年发布）在操作系统、数据库、Web浏览等8种真实环境中测试AI Agent的交互能力；WebArena（卡内基梅隆大学，2023年）在模拟的网站环境中评估Agent完成复杂Web任务的能力；而专门针对编程Agent的DevBench（2024年）则要求AI完成从需求分析、架构设计到代码实现、测试编写的全生命周期任务。这些新基准在一定程度上弥补了传统评测的不足，但距离标准化和广泛采纳仍有距离。

在真实的Agent场景中，模型的表现高度依赖于工具链的支撑——包括代码执行环境、错误捕获机制、文件系统操作、网络访问能力等。一个更科学的评测方案应该包括：在相同工程环境下对比不同模型（控制环境变量）、在相同模型下对比不同工具链（控制模型变量），以及对规划能力和执行能力分别打分。

总结：AI编程能力等于模型乘以工程环境

这场深夜的实测，与其说是一次严谨的模型评测，不如说是一次关于**「AI编程能力 = 模型 × 工程环境」**的生动案例。

当前各大AI公司正在激烈竞争编程Agent平台。OpenAI的Codex提供了集成在ChatGPT中的编程Agent能力，支持连接GitHub仓库进行代码审查和修改。Google的Gemini Code Assist Agent基于Gemini模型构建了类似的编程Agent，并深度集成了Google Cloud的开发者工具链。Anthropic的Claude则通过Computer Use和MCP（Model Context Protocol）协议，赋予模型直接操作计算机桌面和开发工具的能力——MCP是Anthropic于2024年底提出的开放协议，旨在标准化AI模型与外部工具和数据源之间的交互方式，类似于AI领域的「USB接口」，使得任何支持MCP的工具都能被AI模型无缝调用。在开源生态中，Cursor、Windsurf等AI IDE产品也在快速迭代Agent功能——Cursor基于VS Code构建，将AI能力深度嵌入代码编辑器的工作流中，支持多文件编辑、代码库理解和终端操作；Windsurf则以「Flow」为核心概念，试图在AI主动性和用户控制权之间找到平衡。这场竞争的核心逻辑正如本文总结的公式——模型只是基础设施的一半，工程化能力是另一半。

对于关注AI编程的用户，几点启示值得记住：

一个强大的基础模型，如果缺乏配套的Agent工具链和测试反馈机制，实际产出可能大打折扣。 这也解释了为什么各大AI公司近期纷纷投入资源建设自己的编程Agent平台——模型只是基础设施的一半，工程化能力是另一半。
详细的需求文档能显著提升AI的产出质量，「六字提示词」这种极简需求往往难以得到理想结果。 在实际使用AI编程工具时，花10分钟写一份清晰的需求文档，可能比反复让AI修Bug节省数倍时间。
评测AI编程能力时，一定要注意控制运行环境这一关键变量。 不同Agent工具对同一模型的发挥有巨大影响，脱离环境谈模型能力容易得出误导性结论。

UP主也表示，后续会考虑在Zcode上重新调试，或等待DeepSeek官方Agent发布后再做一次公平的对决。届时DeepSeek V4 Pro的真实实力，或许才能得到更准确的呈现。在那之前，这场「饥荒复刻大战」的胜负，还远未到盖棺定论的时候。