WorkBuddy + Hy4 游戏原型开发：从一句需求到可验证项目

先说结论

WorkBuddy 可以成为 Hy4 游戏原型工作流的控制面，但一张能玩的截图不等于可复现项目。应检查保存的引擎状态、工具 Trace、故障恢复、性能和 clean checkout 构建。

WorkBuddy 的价值不在“AI 一句话做出游戏”，而在协调一个有状态的工具。游戏引擎同时维护场景、资产、脚本、引用、输入映射和平台约束。可靠流程必须在一次只改一个里程碑的同时保存状态。

工作流怎么拆

先写清引擎、平台、核心玩法、素材限制、允许的工具和验收条件，再按阶段推进：

需求 -> 场景计划 -> 引擎初始化 -> 输入 -> 玩法 -> UI/音频 -> 构建

WorkBuddy 负责规划和产物协调，Hy4 负责游戏开发环节里的模型能力，MCP 或同类连接器暴露编辑器动作与反馈。每一层都有自己的失败模式。

WorkBuddy 游戏工作流入口 WorkBuddy 提供工作流入口，但最终要验收的是保存下来的项目。

WorkBuddy 官方入口页面 官方页面用于核对 WorkBuddy 的工作台定位。

Hy4 游戏开发案例入口 案例页面提供 Hy4 游戏原型流程的上下文。

要求 WorkBuddy 在空场景启动、输入生效、碰撞与敌人可用、菜单进入关卡后分别保存快照。每个里程碑都要有截图、变更摘要和测试结果。

然后注入一个可控故障：删除场景引用或修改资产路径。真正有价值的信号，是 Agent 能否阅读引擎错误，找到最小必要改动，并且不破坏已经工作的子系统。只会生成第一张场景图的是内容生成器，能修复断引用的才接近工作流助手。

原文强调了 Hy4 的场景和交互质量，但要把视觉与功能分开检查：镜头构图、目标分辨率下的 UI、目标设备帧时间和内存、输入一致性、手柄支持、素材来源，以及场景切换后的重新加载。

不要让漂亮截图替代 clean build。第二个人应该能在没有原始对话、没有隐藏编辑器操作的情况下，从新 checkout 打开项目。

区分游戏工作流和演示 Demo，最快的方法是主动制造可控故障。核心循环跑通后，依次重命名一个资产、删除一个输入映射、引入已知碰撞或打包错误，每次只改一处。要求 Agent 先说明诊断假设，再做最小修复并重跑相关检查；同时保留原始快照，避免错误修复污染基线。

最终交接至少要包含引擎和插件版本、目标平台、启动命令、项目目录、机器生成与人工编写文件的边界、资产授权、输入映射、测试清单和已知限制。如果是多人或联网原型，还要写清权威状态由谁维护、哪些动作只是本地模拟。这些信息能避免项目只能在作者会话里运行。

视觉和性能必须分开验收。一个场景可能看起来很完整，却在目标设备上出现不稳定帧时间、难以阅读的 UI 或内存峰值。应从干净构建跑一条有代表性的路径，在每次生成修改后重复测量并和基线比较。

它可以帮助制作原型，但正式发布仍需审查代码、素材、性能、平台行为、无障碍和版权。生成结果应视为候选构建。

不会。MCP 只是让编辑器动作可调用、可观察。应使用一次性项目、最小文件权限、默认关闭网络，并审批导出和项目外写入。

引擎版本、目标平台、安装命令、项目快照、已知限制、素材授权、工具 Trace，以及进入核心玩法的准确操作。

固定需求、引擎版本、工具、时间预算和验收条件，测量 clean build 成功率、注入故障后的恢复、人工修改、帧时间和总成本，而不是只看第一张截图。