使用 ChatGPT 或 Claude 从零制作 Godot / Unity 游戏：全流程深度研究报告

本报告面向具备基本编程概念、但没有系统游戏开发经验的初学者到中级开发者。核心结论是：ChatGPT、Codex、Claude、Claude Code 目前已经可以显著缩短游戏开发中的“信息检索—写代码—改代码—运行测试—批处理资产—构建发布”循环，但它们仍然不适合被当作“一句话自动生成完整游戏”的黑盒。更可靠的模式是把游戏项目拆成可以验证的垂直切片，每次让 AI 完成一个具有明确输入、约束和验收条件的任务，再由引擎、测试和人工试玩形成反馈闭环。Codex 官方定位已经覆盖规划、功能实现、重构、评审和发布；Claude Code 则可直接读取代码库、修改多文件、执行命令，并通过 Hooks、Subagents 与 MCP 连接外部工具。

对于引擎选择，本报告建议：

截至本报告日期，Godot 官方仍建议新项目使用 Godot 4.x，并建议通过版本控制/备份管理升级风险；Unity 侧则应选择一个正式支持的 Unity 6 编辑器版本并固定版本，而不是所有成员随意更新。

一个特别重要的判断是：MCP 不是制作游戏的必需条件。 MCP 是让 AI 应用连接工具、数据和工作流的标准；它的价值在于把“让 AI 告诉你点击哪些按钮”升级为“让 AI 在经过批准后直接调用编辑器工具”。 目前 Blender、Unity、Godot 均已有社区 MCP 项目，但并非引擎官方核心组件，因此应把它们视作“效率层”，不能让项目架构依赖某个 MCP 插件才能正常打开或构建。Blender MCP 明确声明自己是第三方项目；Unity MCP 和主流 Godot MCP 同样来自社区项目。

推荐的总体开发回路是：

四周 MVP 最重要的范围约束应是：一个角色、一套核心移动/战斗机制、一种敌人或障碍、一个完整关卡、一个开始/暂停/死亡/胜利 UI、有限的音效和背景音乐、可重复完成的 5–15 分钟游戏循环，以及至少一个可分发构建。不要在四周 MVP 中同时加入多人联网、程序化开放世界、复杂角色定制、完整剧情系统和十几种敌人。

本报告给出的时间均为规划估算而非行业标准。假设单人开发者已有基本编程基础、每天投入约 2–4 小时；AI 可以减少样板代码和资料检索时间，但不会消除游戏设计、调参、审美判断与测试成本。

引擎、AI 助手与工具体系

Godot 与 Unity 的本质差异不在于“哪个绝对更强”，而在于项目规模、团队技能和工具链成本。Godot 具有原生 2D 工作流、场景/节点组合、GDScript 与轻量工程结构；TileMapLayer 本身即可承载网格绘制、碰撞、遮挡、导航和 terrain 工作流。Godot 也支持完整 3D 导入流程，并将 glTF 作为重要的 3D 交换格式。 Unity 则更自然地衔接 C#、Package Manager、商业资产、成熟 3D 工具链、Profiler/Test Framework 与多平台商业发布。

ChatGPT / Codex 与 Claude / Claude Code

不建议根据“哪个模型在某个榜单高几分”来长期绑定工具链，因为模型、价格和功能都会变化。更稳定的比较方式是比较工作流能力。

一个实用的分工并不是“ChatGPT 做 Unity、Claude 做 Godot”，而是：

聊天模型负责规格和判断，代码代理负责仓库级变更，MCP 负责编辑器内部操作。

例如让 ChatGPT/Claude 先把“玩家移动”转换成验收规范：

你是资深 Godot 4 游戏程序员。

项目：
- Godot 4.x
- 2D 横版平台游戏
- GDScript
- CharacterBody2D
- 输入动作：move_left、move_right、jump

目标：
实现可调参数的玩家控制器。

约束：
- 不使用第三方插件
- 不把输入逻辑放进 _process()
- 需要重力、左右移动、跳跃
- 后续必须容易增加 coyote time 和 jump buffer

验收条件：
1. 空中受到重力。
2. 落地后可以跳。
3. 松开方向后立即停止水平移动。
4. 所有重要参数用 @export。
5. 解释每个函数为何存在。
6. 最后给出 5 条人工测试用例。

先输出节点结构，再输出完整 GDScript。

这比：

帮我写一个平台游戏角色

可靠得多。有效提示词可以统一成：

角色（Role）
+ 引擎和确切版本
+ 当前工程状态
+ 单一目标
+ 不允许做什么
+ 可修改文件范围
+ 验收条件
+ 输出格式
+ 测试/验证步骤

对于仓库 Agent，再加一条尤其重要：

在修改任何文件前：
1. 先阅读相关场景、脚本和项目配置。
2. 列出计划修改的文件。
3. 不创建重复系统。
4. 修改后实际运行测试/构建。
5. 如验证失败，先分析日志再修复。
6. 最后给出 diff 摘要，而不是只说“已完成”。

Codex 的官方产品方向本身即覆盖功能实现、bug 修复、重构、评审与发布；Claude Code 则正式支持代码库读取、文件编辑、命令执行以及 MCP、Hooks、Subagents 等 agent 能力。

MCP 与核心工具分级

严格意义上的“必需 MCP”：没有。 必需的是引擎、源代码、版本控制和能够完成资产/构建工作的工具；MCP 是推荐的自动化接口层。

GitHub 元数据可以作为“社区活跃度”的辅助信号而不能当作质量保证：截至 2026-10-01，mcp-for-blender 最近仍在 2026-09-30 更新，CoplayDev/unity-mcp 同样在 2026-09-30 有推送，而 Coding-Solo/godot-mcp 最近一次记录的推送是 2026-04-16；因此目前 Unity/Blender MCP 的迭代活跃度明显更值得持续观察。

OpenAI 侧，Codex 可以直接连接 MCP；ChatGPT Web 可使用远程 MCP-backed 工具。 Anthropic 侧，Claude Code 可以连接 MCP，而 Messages API 的 MCP Connector 可以直接接远程 MCP 服务器；当前该 API Connector 属于 Beta，并主要面向远程 HTTP MCP，不能把“本机 stdio Blender MCP”简单等价为一个远程 API MCP。

因此本地游戏开发最实际的组合是：

Godot / Unity / Blender
          ↑
      本地 MCP
          ↑
Codex CLI / Claude Code
          ↑
    开发者审批

而不是让公开网络上的任意模型获得无限制 Editor/文件系统权限。MCP 官方安全文档明确讨论了 confused-deputy、SSRF、会话劫持、本地 MCP compromise 与最小权限等风险。

从概念到发布的完整制作流程

下面时间按“单人、已有基础编程、制作小型 MVP”估算。2D 项目通常取区间下部，3D 项目通常取上部；原创高品质美术不包含在这些估算里。

Godot 官方支持使用 --headless 在没有图形环境的 CI 中工作，并可通过 --export-release / --export-debug 从命令行导出项目，这使其很适合轻量 CI。 Unity 则可以在 -batchmode 中运行 Test Framework，输出机器可读测试结果，并通过构建脚本或 Build Profiles 实现自动化。

最小 Godot 角色代码

# player.gd — Godot 4.x
extends CharacterBody2D

@export var move_speed: float = 220.0
@export var jump_velocity: float = -420.0

var gravity: float = ProjectSettings.get_setting(
    "physics/2d/default_gravity"
)

func _physics_process(delta: float) -> void:
    if not is_on_floor():
        velocity.y += gravity * delta

    var direction := Input.get_axis("move_left", "move_right")
    velocity.x = direction * move_speed

    if Input.is_action_just_pressed("jump") and is_on_floor():
        velocity.y = jump_velocity

    move_and_slide()

真正让 AI 帮你升级代码时，不应直接说“让手感更好”，而应给可测参数：

基于这份 Godot CharacterBody2D 控制器加入：

- coyote time: 0.10 s
- jump buffer: 0.12 s
- 起跳后提前松开按键时降低上升速度
- 地面加速度与空中加速度分离
- 不改变现有 Input Map 名称

同时输出：
1. 完整脚本；
2. 参数解释；
3. 8 个边界测试；
4. 你认为最可能导致 double-jump bug 的代码位置。

最小 Unity FPS 控制器骨架

using UnityEngine;

[RequireComponent(typeof(CharacterController))]
public sealed class SimpleFpsController : MonoBehaviour
{
    [SerializeField] private float moveSpeed = 5f;
    [SerializeField] private float mouseSensitivity = 2f;
    [SerializeField] private float gravity = -20f;
    [SerializeField] private Transform cameraPivot;

    private CharacterController controller;
    private float pitch;
    private float verticalVelocity;

    private void Awake()
    {
        controller = GetComponent<CharacterController>();
    }

    private void Update()
    {
        float x = Input.GetAxisRaw("Horizontal");
        float z = Input.GetAxisRaw("Vertical");

        Vector3 move =
            (transform.right * x + transform.forward * z).normalized;

        if (controller.isGrounded && verticalVelocity < 0f)
            verticalVelocity = -2f;

        verticalVelocity += gravity * Time.deltaTime;

        Vector3 velocity =
            move * moveSpeed +
            Vector3.up * verticalVelocity;

        controller.Move(velocity * Time.deltaTime);

        float yaw = Input.GetAxis("Mouse X") * mouseSensitivity;
        float mouseY = Input.GetAxis("Mouse Y") * mouseSensitivity;

        transform.Rotate(Vector3.up * yaw);

        pitch = Mathf.Clamp(pitch - mouseY, -89f, 89f);
        cameraPivot.localRotation = Quaternion.Euler(pitch, 0f, 0f);
    }
}

生产项目应进一步迁移到项目选择的输入系统、实现跳跃/斜坡/冲刺、可配置 sensitivity 和独立 look/move 模块；这里的目的只是得到第一天即可玩的垂直切片。

UI 与 9-slice

AI 生成 UI 最容易犯的错误，是直接生成“一张完整按钮图片”。更好的资产设计是让 AI 生成视觉概念，再人为拆成可重用组件：

Generate a fantasy bronze UI panel kit:
- neutral front-facing orthographic design
- no text
- square corners visually distinct from edges
- uniform edge thickness
- empty flat center area
- no perspective
- no drop shadow outside canvas
- suitable for conversion to a 9-slice panel

后处理：

源图
→ 修正对称与边框
→ 裁出左上/上/右上/左/中心/右/左下/下/右下
→ 定义 Border
→ 在多个宽高比下拉伸测试
→ 生成 hover/pressed/disabled 状态

Godot 中用 NinePatchRect 类思路，Unity 中使用 Sprite 的 border/9-slice 工作流。文字不要烘焙进 AI 图片：文字应由引擎字体系统渲染，以便本地化、无障碍和不同 DPI 适配。

物理和关卡阶段同样应坚持“测试场景优先”。例如为每种物理机制建立一个独立场景：

tests/manual/
    jump_test.tscn
    slope_test.tscn
    moving_platform_test.tscn
    damage_test.tscn

然后让 AI 针对可复现测试场景修 bug，而不是面对完整关卡猜原因。

AI 资产、动画与音频生产流水线

二维精灵、切片与图集

生成游戏 2D 资产时，首要目标不是单张图的美感，而是跨帧一致性、尺寸一致性、pivot 一致性和透明边界稳定性。

推荐流程：

Style Bible角色参考立绘确定轮廓/配色生成动作关键帧人工修形统一画布/Pivot切片Sprite Atlas导入引擎动画状态机测试显示代码

先制作一个 style_bible.md：

视觉风格：16-bit inspired，不模拟具体在世艺术家
角色高度：64 px
轮廓：2 px dark outline
光源：左上 45°
色板：最多 24 色
阴影：单级硬边阴影
背景透明
角色脚底 pivot：画布 x=50%, y=92%
所有动作必须保持相同身体比例

然后使用这种提示：

2D game character sprite,
side view,
small robot courier,
consistent body proportions,
neutral orthographic camera,
transparent background,
hard-edged pixel-art inspired shading,
no text, no UI, no scenery.

Pose: running, right leg forward.
Keep head size, backpack size and limb lengths identical
to the supplied reference character.

不要直接请求：

帮我生成一整张完美的 8 帧像素 sprite sheet

更可控的方式是独立生成参考姿态/关键动作，再在像素编辑器中修正并排成 sheet。AI 的任务是减少草图成本，而不是替代最终像素级约束。

Godot 的 SpriteFrames 资源可以承载 AnimatedSprite2D / AnimatedSprite3D 的帧动画。

推荐目录：

art/
  source/
    character_hero/
      concepts/
      working/
  export/
    sprites/
      hero/
        idle/
        run/
        jump/
        hit/
  atlases/

像素项目还要固定：

Pixels Per Unit / pixels-per-meter
滤镜方式
mipmap 策略
compression
pivot
透明边距

不要让不同角色以随机缩放系数进入项目，否则物理碰撞、摄像机和关卡比例都会慢慢漂移。

自动清理透明精灵

# tools/trim_sprites.py
from pathlib import Path
from PIL import Image

SRC = Path("art/raw")
DST = Path("art/processed")
PADDING = 4

DST.mkdir(parents=True, exist_ok=True)

for path in SRC.glob("*.png"):
    image = Image.open(path).convert("RGBA")
    alpha = image.getchannel("A")
    bbox = alpha.getbbox()

    if bbox is None:
        print(f"Skip empty image: {path}")
        continue

    cropped = image.crop(bbox)

    out = Image.new(
        "RGBA",
        (cropped.width + PADDING * 2,
         cropped.height + PADDING * 2),
        (0, 0, 0, 0),
    )
    out.paste(cropped, (PADDING, PADDING))

    output_path = DST / path.name
    out.save(output_path)
    print(f"{path.name}: {image.size} -> {out.size}")

注意：角色逐帧动画不要盲目自动 trim，否则 pivot 会随帧移动而产生抖动。上面脚本更适合独立 icon、道具和粒子图；角色 animation sheet 应保持统一画布。

图集与切片建议

对 2D 性能较敏感的项目：

AI/手绘源图
→ 单图清理
→ 固定 PPU 和 pivot
→ 自动命名
→ atlas pack
→ 引擎 Sprite import
→ animation clip

文件名应可机器解析：

hero_idle_00.png
hero_idle_01.png
hero_run_00.png
hero_run_01.png
enemy_slime_hit_00.png

这样 AI、Python、构建工具和资产管理系统都容易自动处理。

Spine / DragonBones 骨骼动画

适合：

角色由多个可变形部件组成
+ 需要大量循环动画
+ 需要换装
+ 需要同一骨架复用 animation

Spine 目前对 Unity 与 Godot 均有官方 runtimes，因此商业项目如果预算允许，它比“自己维护一个骨骼导入插件”更稳妥。 DragonBones 仍有官方组织维护的 runtime 仓库，但正式采用前应对目标引擎版本、导出格式、移动端和构建流水线做一次完整 POC。

AI 可以帮助做：

请把这个角色动画需求转换为 Spine 动画表：

状态：
idle
walk
run
jump_start
jump_loop
land
attack_light
hurt
death

对每个状态给：
- 推荐时长
- 是否 loop
- root 是否移动
- 哪些 bones 应独立控制
- 动画事件时间点
- 可以复用的关键姿势

不要让 AI 随机决定骨骼命名。提前制定：

root
  pelvis
    torso
      head
      arm_upper_L
      arm_upper_R
    leg_upper_L
    leg_upper_R

然后整个项目冻结命名约定。

三维资产：AI 模型不能直接进游戏

DreamFusion 的原始方法利用 2D diffusion prior 和 Score Distillation Sampling 优化 3D NeRF，随后可用 marching cubes 导出 mesh。它证明了 Text-to-3D 的可行性，但这类生成结果并不意味着直接获得了“游戏就绪”的低模拓扑、UV、rig 和 LOD。

正确的生产链是：

文本/图片生成 3D 草稿
        ↓
检查比例与 silhouette
        ↓
清理浮空/重叠/非流形几何
        ↓
Retopology
        ↓
Apply Transform
        ↓
UV unwrap
        ↓
High → Low Bake
        ↓
BaseColor / Normal / AO / Roughness
        ↓
LOD0 / LOD1 / LOD2
        ↓
Rig / Weight Paint
        ↓
动画
        ↓
glTF / FBX
        ↓
引擎 Import Preset

Blender 的 Decimate Modifier 能减少顶点/面数，同时尽可能保留整体形状；Cycles Bake 可用于把高模信息烘焙到贴图。 但 Decimate 不应被误认为“自动专业 retopology”：角色肩部、肘部、膝部等高形变区域仍需要合理 edge flow。

示例 3D 生成 prompt：

Stylized low-poly sci-fi storage crate,
game asset,
single isolated object,
front/side/back design consistency,
hard-surface construction,
large readable shapes,
no tiny floating details,
no text or logos,
designed for eventual 5k–8k triangle retopology,
PBR material separation:
painted metal / bare metal / rubber.

这个提示不是让模型真的遵守“8k triangles”，而是告诉生成阶段不要创造无法低模化的细碎结构。

拓扑清理 checklist：

对于 Godot，3D 导入流程支持场景资源导入和进一步配置；Godot 官方文档长期将 glTF 2.0 作为重点推荐的交换路径。 Blender 的 FBX 仍广泛用于复杂动画数据交换，特别是在许多 Unity 工作流里。

Blender 批处理导出

# tools/export_glb.py
# 调用：
# blender -b character.blend -P tools/export_glb.py

import bpy
from pathlib import Path

output = Path.cwd() / "build_assets" / "character.glb"
output.parent.mkdir(parents=True, exist_ok=True)

# 确保 Object 模式，避免导出时状态不一致。
if bpy.context.object and bpy.context.object.mode != "OBJECT":
    bpy.ops.object.mode_set(mode="OBJECT")

bpy.ops.export_scene.gltf(
    filepath=str(output),
    export_format="GLB",
    use_selection=False,
    export_apply=True,
)

print(f"Exported: {output}")

这类脚本非常适合交给 ChatGPT/Claude 生成第一版，但真正的价值在于把脚本放进仓库，由 CI 重复执行。

Blender MCP 应该怎样用

Blender MCP 当前可让模型操纵对象、材质、检查场景并执行 Blender Python，还整合了若干外部资产/生成渠道。 因为它具有执行代码的能力，建议把任务分成：

低风险：
- 查询场景对象
- 检查命名
- 检查 poly count
- 列出材质
- 测量 bounding box

中风险：
- 创建对象
- 修改 modifier
- 批量重命名
- 设置材料

高风险：
- 删除大量对象
- 覆盖文件
- 执行任意 Python
- 下载/导入第三方资产

高风险动作必须要求确认。

音效与音乐

游戏音频至少分为：

AudioLDM 的原始研究支持 text-to-audio、audio-to-audio、文本引导 style transfer，并展示了 SFX、语音和音乐生成。 一个更好的音效 prompt 应包含：

event
+ material
+ distance
+ acoustic environment
+ duration
+ intensity
+ what must NOT appear

例如：

Single sci-fi energy door opening,
heavy mechanical metal,
close microphone,
dry studio-like acoustic,
0.8 seconds,
strong transient at start,
short hydraulic tail,
no music,
no voice,
no background ambience.

再比如脚步：

One boot footstep on wet concrete,
medium-weight adult,
close perspective,
short transient,
slight water splash,
0.35 seconds,
no reverb tail,
no second footstep,
no music.

AI 生成后仍应执行：

去除多余前后静音
→ 去 DC / click
→ EQ
→ 必要时压缩
→ 峰值管理
→ 做 4–12 个变体
→ 引擎内随机 pitch / volume
→ 实机听感测试

循环音乐则可以：

生成 60–90 秒音乐草稿
→ 确定 BPM
→ 编辑到整小节
→ 找零交叉点
→ 做 loop start / loop end
→ 在 DAW 连续重复 10 次试听
→ 导出 master
→ 游戏中再压缩

示例音乐 prompt：

Loopable exploration music for a deserted orbital station,
92 BPM,
minor tonality,
restrained synth pulse,
cold metallic ambience,
no vocals,
no dramatic ending,
steady intensity,
leave space for gameplay sound effects,
approximately 60 seconds.

音量规范要区分“广播标准”和“游戏内部混音目标”。 EBU R128 的正式广播目标是 −23 LUFS，生产 True Peak 一般不超过 −1 dBTP；它非常适合作为理解 LUFS、True Peak 和测量方法的参考，但不能把“−23 LUFS”机械地当成所有游戏音乐的发布标准。

游戏项目可以先建立自己的 house target，例如：

Master：
保持足够 headroom，避免长时间 limiter 顶死

Dialogue：
优先保证可懂度

SFX：
关键反馈 > Foley > Ambience

Music：
不得持续掩盖 UI、对白、关键战斗提示

Ambience：
低于关键 gameplay cues

最终：
在耳机、笔记本、电视/音箱至少三类设备测试

作为内部初始校准而非外部强制规范，小团队可以让音乐 master 处于约 −18 到 −14 LUFS 的量级，并保留约 −1 至 −3 dBTP 的峰值余量，再围绕对白/SFX 做听感调节；真正发布前应按目标平台的规范和实际设备重新测量。

格式方面可采用：

源文件：
48 kHz / 24-bit WAV

短 SFX：
保持 WAV 或由引擎转为平台友好压缩格式

长音乐 / ambience：
通常压缩为 Ogg Vorbis / 平台适配格式

循环源：
保留无损 master，再由构建流程生成运行时文件

不要只保留最终压缩后的 OGG/MP3，因为后续重新处理会重复有损编码。

AudioLDM 自身仓库明确说明数据来自 AudioSet、Freesound 和 BBC Sound Effects，并以学术研究版权例外描述其 demo；因此“代码开源”不能简单推导为“所有生成结果在你的所有商业法域中都零风险”。

工程化、插件与自动化

成熟项目中，AI 最大的长期价值往往不是“每天生成几十段代码”，而是把开发规范编码为自动验证。

推荐项目结构：

project/
├─ art/
│  ├─ source/
│  └─ export/
├─ audio/
│  ├─ source/
│  └─ runtime/
├─ game/
├─ tests/
├─ tools/
├─ prompts/
│  ├─ coding/
│  ├─ art/
│  └─ audio/
├─ docs/
│  ├─ GDD.md
│  ├─ ARCHITECTURE.md
│  └─ STYLE_GUIDE.md
├─ provenance/
└─ .github/workflows/

成熟插件与扩展组合

Unity：优先用 Unity 官方 released packages，而不是一开始购买大量 Asset Store 框架。 Unity 将 Released Package 定义为针对目标 Editor 版本经过测试并提供正式支持的 package。

Unity CPU Profiler 与 Memory Profiler 都是官方诊断路径；优化应依据 profiler 数据而不是让 LLM 猜。

**Godot：**优先使用引擎本身，再从官方 Asset Library 按实际问题添加插件。Asset Library 当前包含大量面向 Godot 4.x 的社区工具，而且各插件版本与许可证不同，因此不能因为“在 Asset Library”就假设它等同于官方维护。

可关注：

每加一个第三方插件，都应该问 AI：

请评估这个 Godot 插件是否值得引入。

给定：
- 引擎版本：Godot 4.x
- 项目预计维护 2 年
- 目标：Windows + Web
- 当前已有系统：...
- 插件仓库：...

请检查：
1. 它解决的需求能否用 100 行以内自研代码解决？
2. 插件是否侵入场景/资源格式？
3. 删除插件后是否还能正常打开项目？
4. 许可证风险是什么？
5. 是否锁死具体 Godot minor version？
6. 建议：采用 / 封装后采用 / 不采用。

IDE 层面，Claude Code 官方有 JetBrains 集成，支持 IDE diff 和 selection context；Codex 也提供本地 CLI/IDE 工作流。

Godot CI 最小方案

Godot 官方明确支持命令行导出。 假定 CI runner 已安装正确 Editor 与 export templates：

# .github/workflows/godot-build.yml
name: Godot Build

on:
  push:
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      # 实际项目应在此固定 Godot 版本并安装 export templates。
      - name: Verify project loads
        run: |
          godot --headless --path . --editor --quit

      - name: Export Linux release
        run: |
          mkdir -p build
          godot 
            --headless 
            --path . 
            --export-release "Linux" 
            build/game.x86_64

      - uses: actions/upload-artifact@v4
        with:
          name: linux-build
          path: build/

不要在 CI 中写：

下载“latest Godot”

而应固定：

Godot exact version
export template exact version
plugin commit/tag

否则一次自动升级就可能让全团队的构建不可重现。Godot 官方也建议对版本升级保持谨慎并配合版本控制。

Unity 自动测试与构建

Unity Test Framework 官方支持 batch mode：

Unity 
  -batchmode 
  -projectPath "$(pwd)" 
  -runTests 
  -testPlatform EditMode 
  -testResults test-results.xml 
  -logFile -

这种测试 CLI 是 Unity 官方支持路径。

生产构建可通过 -executeMethod 调用 Editor C#：

Unity 
  -batchmode 
  -quit 
  -projectPath "$(pwd)" 
  -executeMethod BuildScript.BuildWindows 
  -logFile -

// Assets/Editor/BuildScript.cs
using System;
using UnityEditor;
using UnityEditor.Build.Reporting;

public static class BuildScript
{
    public static void BuildWindows()
    {
        string[] scenes =
        {
            "Assets/Scenes/Main.unity"
        };

        var options = new BuildPlayerOptions
        {
            scenes = scenes,
            locationPathName = "Build/Game.exe",
            target = BuildTarget.StandaloneWindows64,
            options = BuildOptions.None
        };

        BuildReport report = BuildPipeline.BuildPlayer(options);

        if (report.summary.result != BuildResult.Succeeded)
        {
            throw new Exception(
                $"Build failed: {report.summary.result}"
            );
        }
    }
}

Unity 正式构建体系支持按平台维护构建配置。 CI 还必须正确处理 Unity 许可证、Android SDK、Xcode/签名证书等平台依赖。

Unity 自动导入规则

大量 AI 资产进入项目后，最容易出现“每个 Texture Import Setting 都不同”。应使用 AssetPostprocessor 固化规则：

// Assets/Editor/TextureImportRules.cs
using UnityEditor;

public sealed class TextureImportRules : AssetPostprocessor
{
    private void OnPreprocessTexture()
    {
        if (!assetPath.Contains("/Sprites/"))
            return;

        var importer = (TextureImporter)assetImporter;

        importer.textureType = TextureImporterType.Sprite;
        importer.spritePixelsPerUnit = 64f;
        importer.mipmapEnabled = false;
        importer.alphaIsTransparency = true;
    }
}

然后由 AI 帮你维护规则代码，而不是手动处理 500 张图。

提示模板也要版本控制

不要把最有效的 prompt 留在聊天记录里。

prompts/
  code/
    add_feature.md
    fix_bug.md
    review_pr.md
  art/
    character_concept.md
    prop_texture.md
  audio/
    ui_sfx.md
    ambience.md

示例：

---
id: code.fix_bug
version: 1.4
engine: godot
---

# Context
{{context}}

# Reproduction
{{steps}}

# Expected
{{expected}}

# Actual
{{actual}}

# Logs
{{logs}}

# Constraints
- Do not modify public APIs unless necessary.
- Do not add a new dependency.
- Prefer the smallest verified fix.

# Required response
1. Root-cause hypotheses ranked by probability.
2. Exact files to inspect.
3. Patch.
4. Regression tests.

建议同时建立生成资产 provenance：

{
  "asset": "ui_panel_iron_01.png",
  "generator": "image-model",
  "model_version": "record-exact-version-here",
  "prompt_file": "prompts/art/ui_panel.md",
  "seed": 1847291,
  "input_assets": [],
  "generated_at": "2026-10-01",
  "human_edits": [
    "symmetry correction",
    "9-slice border cleanup"
  ],
  "license_snapshot": "provenance/licenses/provider-2026-10-01.pdf"
}

这是解决可解释性、可复现性和法律审计成本最低的办法之一。

两套完整工作流与四周 MVP

Godot 二维平台游戏

假设目标：

单人
PC 首发
Godot 4.x
10 分钟完整关卡
1 名玩家角色
2 种敌人
1 种核心特殊机制
简单音乐/SFX

推荐技术栈：

Godot 4.x
GDScript
Git + Git LFS
ChatGPT/Codex 或 Claude Code
Krita/Aseprite 类像素工具
Stable Diffusion 类生成工具（可选）
Spine（可选）
Audacity/DAW + AudioLDM（可选）
GitHub Actions

Godot 的 TileMapLayer 能处理网格绘制并与碰撞、导航等功能结合，很适合这类 2D 工作流。

Godot 2D 平台游戏：四周垂直切片

任务分解表：

验收定义：

从启动游戏开始：
→ New Game
→ 玩家理解移动和特殊机制
→ 能完成整个关卡
→ 遇到至少一种可失败状态
→ 死亡可重新开始
→ 暂停/音量可操作
→ 到达结尾
→ 出现完成状态
→ 重新进入游戏无致命错误

Unity 三维第一人称工作流

假设目标：

单人
PC
Unity 6 固定正式版本
一个 10–15 分钟 FPS 小关卡
移动 + 观察 + 射击
2 种敌人
3 种武器/交互中的最多 1–2 种先进入 MVP

工具：

Unity
C#
Blender
Git + LFS
Codex / Claude Code
Unity MCP（可选）
Blender MCP（推荐于资产自动化）
ProBuilder
Input System
Cinemachine（按项目需要）
Unity Test Framework
Profiler / Memory Profiler
Audio editor
CI

Unity 3D FPS：六周工作流

Unity Profiler 与 Memory Profiler 应进入工作流，而不是等 FPS 降到无法接受时才打开。

可复制的四周 MVP 计划

若从零开始，最稳的项目应优先选择 Godot 2D 平台游戏；若已经熟悉 C#，可以把相同计划映射到 Unity 3D，但缩小资产规模。

第一周：必须“能玩”

里程碑：

一个人第一次拿到构建后，不看源码也能移动角色并理解目标。

第二周：形成完整核心循环

玩家动作
→ 遭遇障碍/敌人
→ 做决策
→ 成功/失败反馈
→ 得到奖励/推进
→ 下一次挑战

必须有：

Health / damage
死亡 / restart
一个敌人或障碍
一个特殊机制
基础 HUD
声音反馈

里程碑：

已经是一款“很丑但完整的小游戏”，而不是技术 demo。

第三周：替换正式资产

灰盒 → 正式 sprites/meshes
临时 beep → 正式 SFX
默认 UI → style-consistent UI
测试场 → 正式单关卡

此周不要新增大型玩法系统。

里程碑：

可以录制 30 秒游戏视频，观众无需解释就能看懂在做什么。

第四周：只做修复、优化和发布

建立冻结规则：

禁止：
- 新玩法
- 新武器体系
- 新剧情系统
- 大规模重构
- 随意升级引擎

允许：
- bug
- UX
- performance
- balancing
- polish
- release engineering

里程碑：

Release Candidate
+ README
+ credits
+ third-party licenses
+ AI asset provenance
+ clean-machine build test
+ 可下载包

建议总体投入约 60–90 小时。对真正第一次碰 Godot/Unity 的开发者，四周的目标不是“做出商业成品”，而是完整经历一次 concept → prototype → content → build → release 的循环。

风险、法律、隐私与参考来源

AI 游戏开发最大的隐患并不是“AI 写错一行代码”；代码错误通常能测试出来。更麻烦的是资产授权不清、数据泄漏、不可复现、工具被过度授权，以及发布前才发现第三方服务条款不允许你的使用方式。

生成内容与版权

OpenAI 当前条款明确表示，在法律允许范围内，用户保留 Input 权利并拥有 Output，但同时指出模型输出可能不唯一，其他用户可能得到类似内容；因此“服务商把合同层面的 output 权利给你”并不等于某个国家/地区一定会认定该内容具备完整著作权保护。

Midjourney 2026-05-27 生效的条款也表示，用户在适用法律允许的最大范围内拥有其生成 Asset，但附带第三方权利和计划条件；企业年收入超过其条款所列门槛时还有特定订阅要求。条款同时明确要求用户对输入与生成内容承担责任。

因此商业项目不应使用：

“画成某在世画师完全相同的风格”
“生成 Disney / Pokémon / Marvel 风格角色并直接销售”
“复制某游戏的 HUD”
“给我做一个几乎相同的某品牌 logo”

更合理的是描述可观察的视觉属性：

limited color palette
hard-edged cel shading
chunky geometric silhouettes
retro-futurist industrial design
two-value lighting
high contrast readable gameplay shapes

模型许可证不是统一的

“Stable Diffusion”已经不是一个单一许可条件的固定产品。Stability AI 当前许可页面指出，其部分 Core Models 在特定收入门槛下可按 Community License 使用，而更高商业收入需要不同许可安排；因此必须记录确切模型、确切版本、确切许可证日期。 老的 CompVis Stable Diffusion 权重本身也带有具体使用限制，而不是简单的“无条件公有领域”。

最小合规记录应该是：

asset
generator
model
model version/hash
date
prompt
seed
input/reference assets
provider terms URL
model license
human modifications
approver

Midjourney 自动化尤其要谨慎

Midjourney 2026 条款明确禁止使用自动化工具访问、互动或通过服务生成 Assets。 因此不要因为“AI 工作流需要自动化”就自行写 bot 把 Midjourney 接进 CI 或 MCP。除非其未来官方产品和条款明确提供相应 API/自动化权限，否则将其定位为人工概念设计工具更安全。

隐私与源代码

对未发布游戏尤其敏感的数据包括：

商业机密
API keys
Steam/Apple/Google signing credentials
未公布剧情
玩家数据
内部服务器地址
第三方 NDA 资产
付费源代码
未发布市场计划

OpenAI 当前企业/API 隐私政策表示，ChatGPT Business/Enterprise 等商业产品以及 API Platform 的业务数据默认不用于训练；企业/API 数据控制和 retention 还可按具体产品配置，API 在部分场景可申请 Zero Data Retention。 普通消费者账户与商业/API 数据政策不能混为一谈。

Anthropic 侧同样应以当前 Commercial Terms 和组织的数据配置为准，而不是假设“Claude Code 能看到仓库，所以任何公司代码都可以直接上传”。

MCP 是执行权限，不只是上下文

当 MCP 可以：

写文件
执行 shell
删除对象
运行 Blender Python
修改 Unity Scene
调用外部 API

它已经相当于给 AI 一个软件机器人账户。

因此应使用：

最小权限
→ 默认 read-only
→ 写操作明确审批
→ delete/publish/upload 单独审批
→ 不把生产密钥给本地游戏 MCP
→ 限制允许访问的目录
→ 为工具调用保留日志

MCP 官方安全指南明确列出了本地服务器 compromise、SSRF、会话劫持、权限范围等攻击面。

可解释与可复现

每次重要 AI 修改至少记录：

需求 ticket
→ prompt/template version
→ AI 修改的 commit
→ 自动测试结果
→ 人工验收者

不要记录“AI 的内部推理过程”；真正需要可复现的是输入、工具、代码 diff、版本、seed 和测试结果。

推荐 Git 提交：

feat(player): add coyote time and jump buffering

Acceptance:
- coyote window: 100 ms
- input buffer: 120 ms
- no double jump
- existing movement tests pass

Generated with AI assistance; manually reviewed and play-tested.

三种预算情景的最终建议

核心原始与官方资料

最终最值得固化成团队原则的一句话是：

让 AI 生成“可验证的小步变更”，而不是生成“无法解释的大块游戏”。

在 Godot 或 Unity 中，真正成熟的 AI 游戏开发流程不是“Prompt → Game”，而是：

Specification
→ AI-assisted implementation
→ Engine validation
→ Automated tests
→ Human playtest
→ Profiling
→ Version control
→ Reproducible build
→ License/provenance audit
→ Release

当这条链路建立后，ChatGPT/Claude 才真正从“会写代码的聊天机器人”变成游戏制作流水线中的工程工具；而 Blender/Unity/Godot MCP 的价值，也是在这条受版本控制、权限控制和验收条件约束的流水线里才会最大化。