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

一场不严谨但有趣的实测

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

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

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

这里有必要补充一下两者的技术背景。DeepSeek V4 Pro是深度求索（DeepSeek）于2025年8月发布的新一代大语言模型，延续了其在开源社区中的强势地位。DeepSeek此前凭借V3和R1系列模型，在代码生成、数学推理等领域展现了与GPT-4o级别模型相当的竞争力。而Codex则是OpenAI于2025年推出的专用编程Agent产品，基于codex-1模型，它不仅是一个语言模型，更是一套包含代码执行沙箱、文件系统访问、终端操作和测试运行在内的完整工程化环境。这一区别至关重要——Codex并非单纯的语言模型，而是一个「模型+工程环境」的耦合体。

这里需要解释一下Agent工具与传统代码生成的本质区别。传统代码生成是「单轮」的——用户给出提示，模型返回代码片段，交互到此结束。而Agent模式是「多轮闭环」的——AI不仅生成代码，还能自主执行代码、观察运行结果、诊断错误、修复问题，甚至规划多步骤任务。这种能力依赖于底层的工具调用（Tool Use）机制：模型通过结构化的函数调用接口，与文件系统、终端、浏览器等外部工具交互。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），负责依次执行输入处理、游戏状态更新和画面渲染三个阶段；一个场景管理系统来处理地图生成和对象管理；以及一套事件监听机制来响应键盘和鼠标操作。

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

这种自我验证策略是当前AI编程领域的一个重要研究方向。传统的AI代码生成是单向的——模型输出代码，人类测试。而Agent模式下，AI需要具备「写代码→运行→观察结果→修复」的闭环能力。DeepSeek的做法颇具巧思：作为纯文本模型，它无法像具备多模态能力的模型那样直接「看懂」截图，因此采用了一种替代方案——通过读取HTML Canvas的像素数据和游戏内部状态变量来间接判断渲染是否正确。这种方法在逻辑上是可行的，但存在明显盲区：它能验证「数据层」的正确性（比如饥饿值是否在下降），却很难验证「交互层」的正确性（比如鼠标点击是否能触发采集动作），而后者恰恰是游戏体验的核心。DeepSeek版本中「点击采集无效」的问题，很可能出在Canvas的鼠标事件监听和碰撞检测逻辑上——这需要正确计算鼠标点击坐标与游戏对象在Canvas坐标系中的位置关系，而纯文本验证手段很难覆盖这类问题。

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

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

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

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

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

而这个「环境问题」恰恰暴露了Zcode作为第三方Agent工具的局限性。与Codex这样由模型开发商深度定制的官方Agent环境相比，第三方工具在多个维度存在天然劣势：首先是工具链适配——官方环境可以针对模型的输出格式、上下文窗口管理和函数调用机制做专门优化；其次是测试反馈闭环——Codex能直接在沙箱中运行代码、捕获错误并自动修复，而Zcode的浏览器交互测试能力明显不足；最后是上下文管理策略，不同工具对长任务的记忆保持和子任务拆分方式也大不相同。这些差异直接影响了最终产出的质量。

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

两个对照实验

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

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

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

游戏功能基本完整

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

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

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

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

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

这一发现深刻印证了提示词工程（Prompt Engineering）领域的一个核心原则——大语言模型的输出质量与输入信息的丰富度高度正相关。「复刻游戏饥荒」这六个字，对于人类开发者而言包含了大量隐含知识（游戏机制、交互方式、美术风格等），但对AI而言，这些都需要被显式地展开。DeepSeek生成的方案文档实际上完成了一次「隐性知识显性化」的过程——将六个字扩展为包含文件结构、玩法细节、技术栈选择的完整规格说明。当这份文档被喂给Codex后，后者的产出质量明显优于自由发挥版本。这说明在AI编程场景中，「需求分析」和「方案设计」的能力同样是核心竞争力，而非仅仅是代码实现能力。在实际工作流中，这也启示我们可以考虑「分工协作」的模式——用一个模型负责需求分析和架构设计，再用另一个模型（或同一模型的Agent环境）负责代码实现，从而充分发挥不同模型或环境各自的优势。

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

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

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

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

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

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

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

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

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

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

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

当前各大AI公司正在激烈竞争编程Agent平台。OpenAI的Codex提供了集成在ChatGPT中的编程Agent能力，支持连接GitHub仓库进行代码审查和修改。Google的Gemini Code Assist Agent基于Gemini模型构建了类似的编程Agent。Anthropic的Claude则通过Computer Use和MCP（Model Context Protocol）协议，赋予模型直接操作计算机桌面和开发工具的能力。在开源生态中，Cursor、Windsurf等AI IDE产品也在快速迭代Agent功能。这场竞争的核心逻辑正如本文总结的公式——模型只是基础设施的一半，工程化能力是另一半。

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

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

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