Hy4 preview 游戏开发实测：从一句需求到可玩的原型

腾讯混元把 Hy4 preview 定位为“为生产力而生”，但我觉得最容易被低估的生产力场景，恰恰是游戏原型开发：它同时要求模型理解代码、场景、交互、资产和调试反馈。只看一张生成后的截图，很容易高估能力；真正值得测的是模型能否在工具里持续推进。

先说结论

• 一张可玩的截图不能证明项目可以复现。
• 评测要覆盖引擎状态、失败修复、性能、素材授权和干净 checkout 交接。
• MCP 扩大了模型能做的事情，也扩大了权限边界。
• 设计意图、审批和发布决定必须由人工团队掌握。

官方展示了什么

腾讯披露的案例包括两个方向：通过 MCP 接入 Unreal Engine 5，从零搭建射击游戏 Demo；在 Unity（U3D）里制作第三人称企鹅冒险游戏，包含场景、移动、战斗、任务追踪，以及主菜单、加载和关卡三场景流程。

这类案例的关键不在于模型能否写出一段游戏代码，而在于它能否把需求拆成一连串可执行步骤：创建项目结构、配置场景、放置对象、绑定输入、连接脚本、启动编辑器、读取错误，再根据反馈修复。腾讯的发布稿说明了目标和结果，但没有把每一次交互的完整日志都公开，所以这些内容应被视为官方演示，而不是独立复测。

我会如何设计测试

第一轮只给一句相对完整的需求，例如“制作一个可以移动、射击、生成敌人并在击败 Boss 后结算的横版原型”，不额外指定脚本结构。观察模型是否先询问引擎版本、目标平台和资源限制，还是直接开始写代码。一个可靠的 Agent 应该在不确定信息会影响结果时主动缩小范围。

第二轮把任务拆成里程碑：先让它让空场景运行，再加入移动和输入，接着加入敌人和碰撞，最后才做 UI 和音效。每一步都保存工程并运行。这样能看出模型是否会破坏已经可用的部分，也能测出它处理状态和回滚的能力。

第三轮故意制造失败：删掉一个引用、改错一个资源路径，或者让构建使用不兼容的 API。重点不是模型能否一次写对，而是它能否读取报错、定位真正原因，并只修改必要文件。长程任务最怕的是“修复”带来更多隐性回归。

MCP 的价值与边界

如果模型只输出代码，开发者仍要手动打开编辑器、创建对象、挂载组件和运行测试。MCP 的价值是把这些动作放进同一个可审计的工具链里，让模型看到环境反馈，再决定下一步。对于游戏原型，这比单纯增加上下文长度更重要。

但 MCP 也扩大了权限边界。创建文件、执行脚本、访问网络和导出构建都可能产生副作用。我的建议是把编辑器、文件系统和命令执行分开授权；每一个写操作都记录 request ID，并在提交前保留可回滚的工程快照。模型“会操作工具”不等于它应该拥有无限权限。

视觉审美不是自动通过

腾讯强调 Hy4 preview 的前端视觉和交互质量有所提升，游戏 Demo 也会因此更容易获得好看的第一印象。但审美必须用明确标准验收：镜头是否跟随正确，UI 是否遮挡玩法，移动端或低分辨率下是否可用，颜色和字体是否有一致性，素材是否有合法来源。

我会要求模型在每个里程碑生成一张截图，并对照验收清单自检；如果自检失败，必须说明失败原因和下一步，而不是只输出“已完成”。这能把“看起来不错”转化为可复核的工程过程。

适合谁，不适合谁

Hy4 preview 适合需要快速验证玩法、制作内部演示或探索交互方向的开发者。它尤其适合把一个模糊想法快速变成可玩的第一版，再由人类接管架构、资产、性能和发布流程。

它不适合在没有代码审查、权限隔离和回滚机制的情况下直接接管生产项目。腾讯也明确提醒 Hy4 preview 仍是早期版本，复杂长任务可能过度思考和过度自我验证。游戏项目的状态复杂、外部副作用多，这些问题会被进一步放大。

里程碑验收表

每个里程碑都要从干净 checkout 打开项目，确认目标场景没有丢失引用，并用键盘或手柄完成核心循环。保存构建产物和工具轨迹，避免出现“编辑器里看起来正常、换一台机器无法重建”的假成功。

在目标设备上测帧时间和内存，而不只是开发机。除非任务明确要求，否则关闭网络和文件系统工具；生成素材应有授权信息或明确标注为占位符。内部 Demo 可以简化门槛，但正式发行必须由工程和美术团队共同验收。

新鲜感过去后，我会测什么

第一次跑通核心循环并不是终点，因为生成项目的成本往往藏在之后的十分钟里。我会用同一构建做一组小矩阵：全新启动、切换场景后重新加载、素材导入失败、接入第二种输入设备，以及缩小到低分辨率窗口。每个场景都记录模型能否直接从引擎日志定位问题，还是必须由人类把错误重新翻译成提示词。

验收表应该把质量拆成四类。功能质量看移动、战斗、碰撞和流程是否工作；结构质量看场景与脚本的职责是否清楚，新成员能否找到控制状态的地方；运行质量看目标设备上的帧时间、内存、加载卡顿和输入延迟；产品质量看视觉语言、难度、无障碍和音效是否符合需求。一个原型可以通过第一类却没有通过后三类，这并不意味着它没有价值，但必须知道模型真正改善了哪一项。

对于 MCP 驱动的开发，把工具轨迹和工程快照放在一起保存。轨迹至少应包含请求、工具名、经过校验的参数、审批决定、返回结果和重试记录。密钥与用户数据要脱敏，但要保留足够细节来回放失败。如果工具调用试图写入项目目录之外，应暂停并请求明确批准，而不是悄悄扩大沙箱。

我还会要求模型在每个里程碑结束时输出一份“尚未完成”清单，列出缺失素材、未测试平台、已知性能风险和对引擎行为的假设。这样可以抵消漂亮首版带来的完成错觉。这份清单会成为交接文档的一部分，也为下一次会话提供边界清楚的起点。

Hy4 preview 在这里真正有用的角色，不是一个自动化游戏工作室，而是把设计约束快速转成可观察变更序列的协作者。哪些实验值得保留、哪些素材可以发布、项目何时达到候选版本，仍然由人类团队决定。

初步判断

Hy4 preview 的游戏开发故事真正有价值的地方，不是“模型会不会做游戏”，而是它开始尝试在真实引擎和真实反馈里完成一条长链路。评估它时，请记录工具调用、失败修复和最终可运行结果；只有这样，才能知道你得到的是一个漂亮 Demo，还是一个可以继续迭代的工程起点。

一次干净环境交接测试

在宣布原型成功前，把项目导出，让没有参与原始对话的同事从干净 checkout 打开。交接资料至少包括引擎版本、目标平台、安装命令、已知限制，以及进入核心玩法所需的准确操作。如果对方还需要依赖没有记录的编辑器点击或本地素材，这更像演示产物，而不是可复现项目。

我还会为每次工具操作保留简短决策日志：模型准备改什么、触碰了哪个文件或场景、引擎返回了什么，以及是否经过人工批准。这样可以区分模型错误和环境错误，也能在后续实验出问题时只回滚一个里程碑，而不是删除整个工程。

当模型能够执行 shell、文件系统或网络工具时，边界尤其重要。游戏原型不需要访问开发者电脑上的所有资源。建议使用一次性工作区，默认禁止出网，并对导出或项目目录之外的写操作要求明确批准。多一点摩擦，换来的是可观察、可回放的快速迭代。

结论

Hy4 preview 最适合做快速、可观察的游戏实验协作。权限、设计意图、素材授权和发布审批仍应由人工团队掌握；只有在干净环境中可复现构建，生成的原型才应被视为工程交付物。

证据截图

图 1：腾讯说明将游戏开发作为生产力工作流的一部分。

图 2：官方仓库用于核对已经公开的实现产物。

图 3：WorkBuddy 是体验该生产力工作流的托管入口。