以下我在 Unity 项目里整理的一套工作方式。

大家一开始给 Codex 的游戏开发需求需求或许写得很细：大厅底部放背包、冒险、商店，右上角放设置，页面之间能切换，按钮也要有反馈。结果它确实都做出来了，但第一眼还是很像 Demo——场景里是几个基础模型，UI 是标准按钮，灯光和材质也只是“能看见”。

后来我发现，问题不是需求不够长，而是我只验收了功能，没有验收画面。Codex 更像一个执行力很强的程序员：你让它把流程跑通，它就会选择最快的办法。要让结果接近正式游戏，需要给它补上编辑器操作、UI 设计、资产生产和截图返工这几块能力。

一、为什么需求写得很细，结果还是像 Demo

“制作一个大厅”在开发者和 Codex 眼里，可能是两件不同的事。

我想的是：玩家进入后有明确焦点，场景有前后层次，主按钮足够醒目，UI 和环境属于同一种美术风格。

Codex 默认理解的往往是：创建场景、放几个物体、把按钮接上事件、确认没有报错。只要没有额外限制，Cube、Plane、默认材质和基础 Button 都是最快的实现方式。

图 1：功能跑通和正式页面之间，差的主要不是代码量，而是视觉标准

所以一句“画面做得精美”基本没用。真正有用的是把验收条件写清楚：

• 场景不能只从 Scene View 检查，必须进入 Play Mode 截图；
• 大厅要有主要视觉焦点、前景、中景和背景；
• 默认按钮和默认材质只能用于原型，提交前必须替换；
• UI 要有统一的字号、颜色、间距和选中状态；
• 第一版做完后，必须根据截图再返工一次。

这几条比继续追加几千字需求更有效。

二、先改 Codex 的工作方式，再考虑接更多 AI

项目根目录可以放一份 `AGENTS.md`，记录长期不变的项目规则，比如 Unity 版本、URP/HDRP、资源目录、目标分辨率、命名规范和禁止事项。具体工作则拆成几个小 Skill，不要做成一个包办所有事情的万能 Skill。

Skill	负责什么	最后要交什么
场景制作	构图、模型摆放、灯光、材质、后处理	运行截图、资源清单、未解决问题
UI 制作	页面结构、组件、动效、分辨率适配	UI Prefab、状态截图、适配结果
视觉检查	对 Game View 截图挑问题并返工	P0/P1 问题清单、修改前后对比

我现在更倾向于把“完成”写成一个固定闭环：

资源检查 → 视觉计划 → 实际制作 → 运行截图 → 找问题 → 修复 → 再截图

下面这几条，可以直接放进 `AGENTS.md`：

- 可运行不代表完成。 - 默认材质、默认按钮和基础几何体不能作为最终内容。 - 所有玩家可见页面都必须提供 Game View 截图。 - 场景至少要有视觉焦点、前中后景和玩家路线引导。 - UI 必须有 Normal、Pressed、Selected、Disabled 等状态。 - 没通过截图验收的资产，不得标记为可发布。

这里最关键的不是规则写得多，而是 Codex 做完以后必须拿出证据。没有截图和返工，所谓“高品质”很容易只停留在文字里。

三、我认为最先值得接的两个工具

图 2：Codex 负责总控，其他工具补它看不见、做不好的环节

1. Unity MCP：让 Codex 真正进入编辑器

Codex 单独工作时，最擅长的是 C#、配置文件和项目结构。它可以修改 Scene 文件，但不一定知道最终画面到底长什么样。

Unity MCP 的价值，是让 Codex 能够读取层级、创建对象、调整组件、运行场景、执行测试和保存结果。这样工作流就不再是“改完代码以后靠猜”，而是：

修改脚本或场景 → 进入 Play Mode → 保存日志和截图 → 根据结果继续修

它不会自动带来好审美，但至少能让 Codex 看到自己做出来的东西。

Unity MCP 权限比较高，建议单独开 Git 分支，并限制它随意删除资源或修改 `ProjectSettings`。每轮大改以后看一眼 Git Diff，能避免很多麻烦。

2. Figma：不让 Codex 凭感觉排 UI

我的大厅 UI 最初很像 Demo，是因为整个页面没有设计系统。主按钮和普通按钮差不多大，文字、图标和间距也没有固定规则。

更稳的做法，是先在 Figma 里确定颜色、字体、间距、按钮和卡片，再让 Codex 按这些结构在 Unity 里实现。哪怕只做一个很小的组件库，也比每个页面临时发挥强。

• 主按钮、次按钮、图标按钮；
• 顶部栏、底部导航；
• 弹窗、物品卡片、标签页；
• 空状态、锁定状态和红点提示。

UI 设计稿不必做到像大厂交付稿那么细，但至少要让 Codex 有明确的尺寸、层级和状态可以照着做。

四、模型、动画、音频分别怎么选

3D 模型：Meshy、Tripo 和 Rodin

如果要把 AI 模型直接放进 Unity，我会按用途来分，而不是只看谁生成得最精致。

工具	做哪些东西比较好	需要注意
Meshy	普通 NPC、武器、家具和环境小道具	流程省事，但手、头发和衣服要重点检查
Tripo	多视图角色、怪物、批量资产	更适合做自动化，但拓扑和绑骨仍要验收
Rodin	主角、Boss、展示级模型初稿	细节更重要，通常还要进 Blender 清理

三视图最好是正面、严格侧面和背面，人物使用 A-Pose。三张图里的身高、发型、衣服长度和配饰必须一致。只要参考图互相矛盾，模型大概率会在背部、腋下或头发处出问题。

AI 生成的 FBX 不等于可直接上线。导入 Unity 前仍要检查面数、UV、贴图通道、骨骼、权重、穿模和商业许可。

动画：通用动作买现成，特殊动作再用 AI 动捕

走路、跑步、跳跃、受击这类通用动作，成熟动画包往往比 AI 重新生成更稳定。DeepMotion 或 Move.ai 更适合做项目里特有的表演，比如剧情动作、特殊攻击和 NPC 交互。

最容易暴露廉价感的其实不是模型面数，而是动作停顿、脚底打滑和手部穿模。动画导入以后要在角色真实比例上测试，不要只看平台里的预览角色。

音频：先补齐反馈，再考虑大规模配音

一个按钮没有点击声、场景没有环境底噪、攻击只有动画没有声音，都会让页面显得很“空”。ElevenLabs 这类工具适合快速补临时配音、环境声和音效，但我会优先做下面几类：

1. UI 点击、弹窗、任务完成；
2. 脚步、武器、受击；
3. 室内外环境循环；
4. 剧情对白和引导语音。

音频生成后还要检查循环接缝、响度和重复感。临时能用，不代表最终混音也能用。

五、可以按这个顺序接入

图 3：工具接入顺序，先让一条链路跑通，再扩大规模

不建议一开始把 Figma、模型、动画、配音、NPC 对话和自动测试全部接上。接口越多，失败点越多，最后很容易把时间花在维护工具上。

第一阶段只解决最明显的 Demo 感：

• Codex + Unity MCP；
• Figma 和一套基础 UI 组件；
• 场景 Skill、UI Skill、视觉检查 Skill；
• 选择 Meshy 或 Tripo 中的一个跑通导入流程。

目标也不要定成“做完整游戏”，而是做完一个大厅垂直切片：场景、UI、按钮反馈、简单角色和音效全部达到可展示状态。

第二阶段再补动作、配音和更多 3D 资产。第三阶段内容量上来以后，再接自动化测试、本地化、CI 构建和许可证台账。

这套顺序的好处是，每接一个工具都能看到它是否真的解决问题。否则工具列表看起来很强，项目里却还是十个完成一半的页面。

结语

Codex 很适合当项目里的“技术总控”：写代码、拆任务、改配置、跑测试都很强。但场景好不好看、UI 有没有层级、动作是否自然，它不会仅凭一句“做成商业品质”就自动解决。

更认可的做法，是让 Codex 负责执行和自动化，把视觉标准写进 Skill，用 Unity MCP 让它操作和检查编辑器，再用 Figma、3D 生成、动作和音频工具补齐它缺少的环节。

工具不用接得最多，能稳定做完一个高完成度页面，才算真的有用。

说明：文中工具的功能、价格和商业许可会调整，正式接入或上线前应以各平台当时的官方说明为准。