在恐怖游戏项目中，过场动画的制作往往比核心玩法更耗时。一段 30 秒的过场，可能同时涉及镜头路径、灯光闪烁、雾气流动、血迹扩散、角色动作、字幕节奏和镜头抖动等多个层。更麻烦的是，很多氛围素材是高度重复的：雾气、灰尘、血迹、疤痕、异空间扭曲光效……如果全部靠人工制作，再一个一个放进 Godot 场景，整条流程会非常长。MCP（Model Context Protocol）让 Claude 这类 AI 模型不再只停留在聊天框里，而是能直接读取 Godot 场景树、执行 GDScript、创建节点、设置动画关键帧；配合 Higgsfield 这类 AI 视频工具生成动态素材，就能把恐怖游戏过场动画的素材生产、场景装配、镜头调试串成一条可复现的半自动流水线。
这篇文章会带你走通这样一条完整链路：先理解 MCP、Godot MCP、Higgsfield 和 Claude 在流水线里各自负责什么；再配置 Godot 项目与 MCP 服务；然后让 Claude 自动创建恐怖过场镜头路径；接着把 Higgsfield 生成的视频素材导入 Godot；最后给出运行验证、常见报错排查和生产化建议。适合已经能上手 Godot 基础操作、但对 MCP 还停留在“听说过”阶段的开发者。文章里所有命令、配置和脚本都以“最小可运行”为目标，你可以先跑通，再往自己的项目迁移。
1. 先理解这条过场动画流水线由哪些角色构成
1.1 MCP 解决的是“模型与工具之间的会话”问题
MCP 的全称是 Model Context Protocol，翻译过来是“模型上下文协议”。它解决的是一个很朴素的问题：Claude 这类大模型默认只能根据聊天上下文生成文字，没有办法读你硬盘里的场景文件，也没办法按下 Godot 编辑器的运行按钮。过去要让 AI 操作工具，只能靠各种插件的外挂脚本，每个工具一套私有接口，维护成本很高。
MCP 的作用是给“模型”和“外部工具”之间定义一套统一的交互方式。模型按照协议文本构造工具调用请求，本地运行的 MCP Server 接收到请求后真正去执行操作，再把执行结果返回给模型。对开发者来说，这套协议的直观效果是：你可以主动告诉 AI “去读取项目目录下的 main.tscn”，AI 会像人类打开文件一样看到层级内容，再根据结果决定下一步做什么。
要在 Godot 里使用 MCP，最核心的组件是一个称为 Godot MCP Server 的本地服务。它本质上是一个小服务进程，负责把 Godot 编辑器能力封装成工具。常见能力包括读取场景树、获取节点属性、执行 GDScript、创建节点、修改节点属性、控制编辑器播放状态等。不同社区实现暴露的工具名称和参数会有差异，但底层思路都一样：
- Claude 收到用户任务后，决定调用哪个工具。
- MCP Server 收到调用请求，操作 Godot 编辑器或项目文件。
- 操作结果返回给 Claude，Claude 基于结果继续规划下一步。
1.2 Godot MCP 把编辑器暴露成一组可调用工具
如果你没用过 MCP，可以把它理解成“给 AI 装了一双可以操作系统的手”。在 Godot 场景里，这双手能做的工作大致可以分成四类：
| 类别 | 典型能力 | 实际项目用途 |
|---|---|---|
| 场景读取 | 读取场景树、节点列表、节点属性 | 让 AI 先了解当前场景有什么，再决定在哪个父节点下创建内容 |
| 脚本执行 | 在项目里执行 GDScript | 动态创建节点、修改材质、设置动画关键帧 |
| 文件操作 | 读取、创建、修改项目文件 | 自动生成脚本文件、资源导入后的元数据文件 |
| 编辑器控制 | 打开场景、播放场景、停止运行 | 让 AI 直接帮你运行验证，然后把 Log 带回来分析 |
需要注意，MCP 并不是直接把全部编辑器能力暴露给 AI。工具集由开发者主动声明和允许，相当于给 AI 一个“最小权限工具包”。这里建议的做法是：在 MCP 配置里只暴露当前任务需要的工具，比如读取场景树和执行 GDScript，不要把所有文件系统权限全部放开。尤其是多人协作的项目，AI 误改文件的问题一旦发生，回滚成本会很高。
1.3 Higgsfield、Claude 和 Godot 的分工可以按“导演-美术-合成”来理解
把三个工具放在一起看，最适合的分工模型是：
- Claude 负责统筹和调度，相当于导演。它分析你给的恐怖过场描述，拆分任务，调用 Godot MCP 操作编辑器，也调用文件工具检查素材。
- Higgsfield 负责生成动态素材，相当于美术环节。它能根据文字提示生成视频或图像素材，用来做雾气、血液流动、异空间扭曲、灰尘、光线变化等难以逐帧手绘的内容。
- Godot 负责最终合成，相当于剪辑台。所有素材最终都会落到 Godot 的节点、材质、动画轨道里，形成可运行的过场动画。
这条链路有一个很关键的特点：AI 生成视频素材并不直接等于“会动的过场动画”。Higgsfield 生成出来的是一段视频或一组序列帧，它要变成一个在 Godot 里可控制、可循环、可跟上镜头走位的资源，还需要经历导入、设置纹理、挂在场景里、控制播放等步骤。Claude 在这里的价值就是自动完成这些重复步骤。
1.4 为什么恐怖游戏特别适合这种自动化流程
不是所有游戏类型都适合把过场动画制作半自动化，但恐怖游戏很适合。原因有三个：
第一，氛围素材高度模板化。雾气、灰尘、血迹、闪烁灯光、黑暗中的噪点、屏幕划痕，这些素材在不同关卡里只是位置、浓度、颜色不同，本质是同一种生成任务。第二，恐怖过场的时间通常很短，但镜头语言丰富。AI 可以快速生成多版本镜头路径，你只需要在 Godot 里跑一遍验证。第三，测试消耗大。恐怖游戏的镜头、节奏、画面抖动参数需要反复试验，人工调一次要几分钟，让 Claude 配合 MCP 批量调整参数，再统一运行验证，效率会明显提高。
这也是整个流水线的核心目标：不是完全替代人，而是把“重复劳动”交给 AI，把人留在“方向决策”环节。
2. 环境准备：Godot 项目、MCP 服务与 AI 客户端配置
2.1 先对齐版本基线，避免“代码没错但环境不对”
MCP 配置最容易出的问题就是版本和协议不匹配。在开始写任何自动化脚本之前，建议先确认以下几项：
| 项目 | 建议值 | 说明 |
|---|---|---|
| Godot | 4.x 稳定版 | 4.x 的场景文件是文本格式，方便 MCP 读取和修改；3.x 也能用，但部分社区 MCP 工具优先适配新版本 |
| GDScript | 与 Godot 4.x 匹配 | 自动化脚本按 4.x 语法写，避免使用 3.x 的旧 API |
| AI 客户端 | 支持 MCP 的 Claude 桌面端或兼容客户端 | 配置入口一般在客户端的 MCP Server 配置文件里 |
| MCP Server | 选择社区中维护较新的 Godot MCP 实现 | 不同实现的命令、参数、工具名不同，落地前先读对应 README |
| Higgsfield | 浏览器可用账号 | 本文把它作为 AI 视频素材生成环节，生成结果先导出到本地素材目录 |
这里的版本线是“最低要求”，不是唯一要求。如果你的项目已经用了 Godot 4.2 或 4.3，直接继续用，不需要为了这篇文章降级。如果原始项目还在 Godot 3.x，建议先在测试分支里把场景迁移到 4.x，再接入 MCP。否则后面导入的资源、脚本 API、场景格式都会反复报错，排查成本会很高。
2.2 在 Godot 侧准备一个最小项目结构
为了验证 MCP 打通，先创建一个非常小的 Godot 项目。项目名可以用horror_cutscene_demo，目录结构建议这样安排：
horror_cutscene_demo/ ├── project.godot ├── assets/ │ ├── models/ │ ├── textures/ │ └── media/ ├── scenes/ │ ├── main.tscn │ └── cutscene/ │ ├── corridor.tscn │ └── camera_rig.tscn ├── scripts/ │ ├── camera_rig.gd │ └── cutscene_controller.gd └── ai_output/ ├── prompt_logs/ └── generated_scripts/ai_output目录不参与最终打包，专门用来存放 AI 生成的脚本草稿、素材清单和提示词日志。这样做有两个好处：第一，AI 生成的脚本不会直接污染scripts核心目录，只有人工审阅通过后才复制过去；第二，如果 AI 生成结果有误，可以快速定位是哪个版本的提示词产出的。
在 Godot 编辑器里新建一个main.tscn，根节点用Node，名称可以叫Main，下面预留一个空的Cutscene子节点。后面 Claude 会在这个子节点下自动创建镜头、动画和素材节点。
2.3 在 MCP 客户端里注册 Godot MCP Server
多数支持 MCP 的客户端会提供一个 JSON 配置文件。你需要在配置里添加mcpServers，告诉客户端“godot”这个 MCP Server 如何启动。下面是一个示意配置：
{ "mcpServers": { "godot": { "command": "godot-mcp-server", "args": [ "--project", "D:/Projects/horror_cutscene_demo", "--port", "8765" ] } } }这段配置的含义是：当 AI 客户端启动时，它会调用godot-mcp-server命令，把D:/Projects/horror_cutscene_demo这个项目路径和端口号8765作为参数传给 MCP Server。MCP Server 启动后会通过这个端口与 Godot 编辑器通信。
这里必须强调：命令名godot-mcp-server和参数--port是示意写法。不同社区 MCP 实现可能用npx启动，也可能用uvx启动，端口可能叫--port，也可能叫--http-port。实际配置时以你选择的 MCP Server 仓库 README 为准。最稳妥的办法是先看仓库示例，复制它的命令，只改项目路径。
配置完成后，重启 AI 客户端，在客户端设置里应该能看到godotMCP Server 已经连接或待连接。如果显示连接失败，先检查本地命令是否存在、命令行路径是否正确，再检查端口是否被占用。
2.4 用一条测试命令确认 MCP 链路已打通
不要一上来就写复杂过场。先给 AI 一条最简单的任务，例如：
请调用 MCP 工具读取 scenes/main.tscn 的场景树，并列出 Cutscene 节点下有哪些子节点。如果链路正常，AI 会先调用读取场景树的工具，返回类似下面这段结构化内容：
scenes/main.tscn ├── Main (Node) │ ├── Cutscene (Node) │ └── CameraRig (Node3D)如果这一步失败，后续所有自动化都无从谈起。失败通常有三种表现：
- AI 回复“我没有这个工具”：说明 MCP Server 没有注册成功，或客户端配置未加载。
- AI 返回超时或连接失败：说明 MCP Server 进程没有正常启动，或端口通信有问题。
- AI 读到了空场景：说明项目路径配置错误，MCP Server 连到了别的项目。
建议：在跑任何自动化流程之前，先确认“读取场景树”这一项能稳定返回结果。这是后续所有任务的基础，排查价值很高。
3. 跑通第一条自动化过场：让 Claude 操作 Godot 创建镜头路径
3.1 先用文字写一份恐怖过场分镜
自动化不是为了省掉设计环节，而是为了把“已经想好的分镜”快速变成可运行场景。所以第一步仍然是人来写分镜。这里用一个非常短的片段示例：
- 地点：狭窄走廊。
- 环境：走廊尽头有暗红色光源，雾气缓慢流动，灯光每隔三秒闪烁一次。
- 动作：镜头从走廊入口缓慢前推，推到中段时画面轻微抖动，走廊尽头出现一个黑色人形轮廓。
- 时长：12 秒。
如果直接把这些描述给 Claude，它很容易理解，但很难一步到位操作 Godot。正确做法是把描述转成“镜头路径 + 场景元素 + 动画参数”三个部分。
请帮我在 horror_cutscene_demo 项目里搭建一个 12 秒恐怖过场镜头。 要求： 1. 在 Cutscene 节点下创建 CameraRig，类型为 Node3D。 2. 在 CameraRig 下创建 Path3D，路径从起点 (0, 1.5, 0) 到终点 (0, 1.5, -8)。 3. 创建 PathFollow3D 子节点，并挂载 Camera3D。 4. 使用 AnimationPlayer 创建 12 秒镜头推进动画。 5. 动画曲线先慢后快，前 6 秒匀速，后 6 秒逐步加速，模拟突然注意到目标的紧张感。这样要求足够具体，Claude 能调用 MCP 工具完成大部分操作，而不是只提供一段大概的脚本代码。
3.2 让 Claude 理解当前场景并给出工具调用序列
拿到任务后，Claude 内部会按“读取 → 规划 → 执行 → 验证”的方式工作。它可能先调用读取场景树工具，确认Cutscene节点存在；再调用执行 GDScript 工具创建CameraRig；接着创建Path3D并设置曲线点；然后创建AnimationPlayer和动画轨道。
下列工具名是几种常见的 MCP 能力映射，具体名称以你的 MCP Server 为准：
| 功能 | 常见工具名 | 输入 | 输出 |
|---|---|---|---|
| 读取场景树 | read_scene_tree | 场景路径 | 节点层级 |
| 执行 GDScript | run_gdscript | 脚本内容 | 执行结果或错误 |
| 获取节点属性 | get_node_property | 节点路径、属性名 | 属性值 |
| 创建节点 | add_node | 父节点路径、节点类型、节点名 | 新节点路径 |
| 设置属性 | set_property | 节点路径、属性名、值 | 成功/失败 |
| 打开运行 | play_scene | 场景路径 | 运行状态 |
这个表可以帮助你判断 MCP Server 是否够用。如果你的服务实现没有add_node，不要慌，很多操作可以合并成一段 GDScript，直接由run_gdscript完成。
3.3 GDScript 自动生成：镜头推进的核心实现
如果 MCP Server 的工具粒度比较粗，更可靠的做法是让 Claude 生成一段可直接执行的 GDScript，再由 MCP 执行。下面这段脚本用于创建镜头推进路径：
extends Node3D @onready var animation_player: AnimationPlayer = $AnimationPlayer func _ready() -> void: _build_path() _build_animation() animation_player.play("camera_push") func _build_path() -> void: var path := Path3D.new() path.name = "CameraPath" add_child(path) path.owner = get_tree().edited_scene_root var curve := Curve3D.new() curve.add_point(Vector3(0, 1.5, 0)) curve.add_point(Vector3(0.2, 1.5, -4)) curve.add_point(Vector3(0, 1.5, -8)) path.curve = curve var follow := PathFollow3D.new() follow.name = "CameraFollow" path.add_child(follow) follow.owner = get_tree().edited_scene_root var camera := Camera3D.new() camera.name = "MainCamera" camera.current = true follow.add_child(camera) camera.owner = get_tree().edited_scene_root func _build_animation() -> void: var anim := Animation.new() var track_index := anim.add_track(Animation.TYPE_VALUE) anim.track_set_path(track_index, "CameraPath/CameraFollow:progress") anim.track_insert_key(track_index, 0.0, 0.0) # 前 6 秒匀速推进，后 6 秒加速 anim.track_insert_key(track_index, 6.0, 0.4) anim.track_insert_key(track_index, 12.0, 1.0) # 设置插值方式为线性，避免默认贝塞尔曲线带来的异常回摆 anim.track_set_interpolation_type(track_index, Animation.INTERPOLATION_LINEAR) animation_player.add_animation("camera_push", anim)这段脚本的核心逻辑是：创建一条三次贝塞尔曲线路径，用PathFollow3D沿路径移动，然后用AnimationPlayer控制progress属性，从而在 12 秒内把镜头从起点推到终点。第 6 秒时progress设成 0.4，第 12 秒设成 1.0，所以前 6 秒只走 40% 路径，后 6 秒走完剩余 60%，形成先慢后快的节奏。
需要注意，直接通过脚本创建的场景节点，必须设置owner为当前场景根节点，否则保存场景后这些节点会消失。这是 AI 生成 GDScript 时最容易踩的坑之一。
3.4 执行后的检查点
脚本执行完成后，不要急着播放。先在 Godot 编辑器里确认几件事：
Cutscene下是否出现了CameraRig节点。CameraRig下是否出现了CameraPath、CameraFollow、MainCamera。AnimationPlayer是否包含名为camera_push的动画。- 打开动画编辑器，拖动时间轴，
progress值是否从 0 到 1 平滑变化。
如果其中任何一项不对，直接在对话里告诉 Claude，让它修复。这个过程本身就是“半自动”的价值：AI 负责执行和修改，你负责验收。不要跳过这个人工检查步骤，因为 AI 生成结果可能在编辑器可见性、场景所有权、节点顺序上出现细微问题。
4. Higgsfield 素材接入：将 AI 视频变成 Godot 可用的过场资产
4.1 Higgsfield 在流水线中的定位
Claude 可以在 Godot 中创建节点、设置曲线、播放动画，但它无法凭空生成一张会流动的雾气视频。这个时候就需要 Higgsfield 这类 AI 视频生成工具补上“动态素材生产”环节。
在本项目的流水线里，Higgsfield 生成的内容有两类用途：
- 背景视频：比如走廊尽头的摇曳光线、异空间扭曲、雾气缓慢流动。这类素材通常铺在全屏或场景背景层，对分辨率要求较高。
- 粒子替代素材：比如飘浮的灰尘、血迹蔓延、半透明黑影。这类素材最好输出为带透明通道的序列帧或视频，直接贴在面片或粒子发射器上。
需要澄清一点：Higgsfield 生成的视频是“素材”，不是最终特效。它进入 Godot 后还要配合透明材质、动画循环、颜色调整和镜头移动，才能融入三维场景。
4.2 生成参数建议
不同 AI 视频工具的输出规格不同，但在游戏资产导入流程里，可以按下面这套规格去生成，兼容性最好：
| 素材类型 | 建议分辨率 | 时长 | 帧率 | 推荐格式 | Godot 导入方式 |
|---|---|---|---|---|---|
| 全屏背景雾效 | 1920x1080 | 8-12 秒 | 24/30 fps | WebM 或 MP4 | VideoStreamPlayer |
| 透明通道灰尘 | 1024x1024 | 4-6 秒 | 24 fps | PNG 序列帧 | SpriteFrames |
| 半透明黑影 | 1024x1024 | 4-6 秒 | 24 fps | PNG 序列帧 | SpriteFrames |
| 光柱或闪烁光效 | 512x512 | 2-4 秒 | 30 fps | WebM | 材质纹理自动播放 |
生成提示词不要只写“雾气”，要写清楚材质、运动方向、背景色、透明要求。比如：
生成一段走廊尽头的暗红色雾气视频，雾气缓慢向镜头方向流动，背景为纯黑，雾气半透明，边缘柔和，8秒循环，镜头固定。适合作为游戏过场背景素材使用。生成完成后，把素材保存到assets/media/目录，文件名按“用途_场景_版本”的规范命名，例如：
fog_corridor_v01.webm dust_float_v01.png shadow_figure_v01.png4.3 在 Godot 中播放视频素材
Godot 4.x 播放视频通常用VideoStreamPlayer节点。下面是一个通过脚本动态创建视频背景的示例：
extends Node3D func add_video_background(video_path: String) -> void: var video_player := VideoStreamPlayer3D.new() video_player.name = "FogVideo" add_child(video_player) var stream := VideoStreamWebM.new() stream.set_file("res://assets/media/fog_corridor_v01.webm") video_player.stream = stream video_player.loop = true video_player.autoplay = true这里有几个容易出错的地方。第一，Godot 对视频格式支持有限，最稳妥的是 WebM 和 OGV，MP4 能否播放取决于编辑器构建时是否支持对应解码器。第二，视频素材默认可能带有黑色背景，如果黑底未去除，过场里会出现明显黑色矩形，需要处理透明或使用材质透明通道。第三，循环动画建议让素材本身做成首尾可循环，否则播放结束后的跳变非常明显。
4.4 用 Claude 自动生成导入逻辑
不要把素材导入和节点装配当成两件事。让 Claude 一次性完成“检查素材目录 → 在场景里创建视频节点 → 设置循环 → 调整位置和透明度”的流程。
示例任务可以这样写：
请读取 assets/media 目录下的文件，在 CutsceneNode 下创建一个 VideoStreamPlayer3D 节点，播放 assets/media/fog_corridor_v01.webm，设置 loop 为 true，autoplay 为 true，位置放在走廊远端 z=-9，透明度设为 0.7。生成完成后打印场景树供我检查。Claude 会先调用文件读取工具了解有哪些素材，再调用创建节点工具，设置属性，最后调用读取场景树工具返回结果。这样整个流程不再是“素材归素材、场景归场景”，而是真正形成了自动化流水线。
4.5 注意透明素材与颜色空间问题
透明视频素材是恐怖游戏里最常见的坑。AI 视频工具生成的素材，透明通道往往并不干净，边缘会带有白边或黑边。导入到 Godot 后，在材质设置里需要：
- 把
transparency设置为alpha。 - 把
shading_mode设置为unshaded，避免场景灯光影响平面素材。 - 对序列帧使用
billboard_mode让其始终面向镜头。
如果边缘有白边，可以在导入设置里启用透明压缩，或让 Claude 生成一组“膨胀-收缩”处理脚本，去除边缘色。对于只有简单透明需求的素材，也可以在生成提示词里要求“纯黑背景”，然后在材质里把黑色区域按透明度剔除。但这些方法都有副作用，最稳妥的还是生成时就要求透明通道，或者直接生成带透明背景的 PNG 序列帧。
5. 运行验证与典型报错排查
5.1 验证链路：从播放到检查三件事
完成上述步骤后，运行 Godot 项目，过场动画是否正常，不能只看“画面在动”，至少检查三个维度：
- 镜头是否正确沿
Path3D推进。如果镜头没有动，优先检查AnimationPlayer的轨道路径是否写对了节点路径，尤其是PathFollow3D的progress属性。 - 视频素材是否在正确位置循环播放。注意观察黑底、跳变、卡顿、播放速度异常。
- 场景保存后节点是否还在。如果关闭场景再打开节点丢失，说明创建节点时没有正确设置
owner。
验证建议在 Godot 编辑器里直接按 F6 运行当前场景。运行输出会显示在编辑器底部输出面板。如果脚本报错，会直接在输出面板出现红色错误信息，包含脚本文件路径和行号。
5.2 常见问题速查表
| 问题现象 | 常见原因 | 检查方式 | 处理建议 |
|---|---|---|---|
| AI 客户端显示 MCP 连接失败 | 命令不存在、路径错误或端口被占用 | 在命令行手动执行 MCP Server 命令 | 手动执行看具体报错；更新配置文件里的路径和端口 |
| AI 能读取场景树，但执行 GDScript 失败 | Godot 项目未在编辑器中打开，或脚本语法与版本不匹配 | 查看 Godot 输出面板中的红色报错 | 确认编辑器已打开目标项目；检查 API 是 3.x 还是 4.x |
| 自动化创建的节点保存后消失 | 创建节点时没有设置owner或没有正确添加为子节点 | 关闭场景重新打开，看节点是否存在 | 在创建逻辑里设置node.owner = get_tree().edited_scene_root |
| 视频素材播放时带黑色底色 | WebM 视频本身带黑底，或材质未设置透明 | 独立打开素材文件检查 | 使用带透明通道的 PNG 序列帧，或调整材质透明设置 |
| 镜头动画播放速度不对 | 关键帧插值方式和时间点设置不符合预期 | 打开动画编辑器查看关键帧位置 | 调整为线性插值，并确认第 6 秒关键帧的进度值正确 |
| MCP 工具调用超时 | 场景树过大或脚本执行时间过长 | 查看 MCP Server 日志 | 拆分成小任务，让 AI 分批执行 |
5.3 日志与排查顺序
出现问题时不要直接重新生成内容。推荐按以下顺序排查：
- 先确认输入：分镜描述、素材路径、节点路径有没有写错。
- 再确认连接：MCP Server 是否连接成功，Godot 项目是否已打开。
- 接着看 MCP Server 日志和 AI 客户端日志，确认工具调用是否真的执行。
- 然后看 Godot 输出面板，定位 GDScript 报错。
- 最后检查场景保存和资源导入情况。
日志位置因所用 MCP 实现和客户端不同而不同，一般会在客户端设置里看到“查看日志”入口，或在启动 MCP Server 的终端窗口看到工具调用记录。把日志保存下来再让 Claude 分析，比直接凭感觉改脚本要有效得多。
5.4 一个经常被忽视的坑：Claude 并不知道它看不到的东西
Claude 通过 MCP 读取信息时，能看到的只是 MCP Server 暴露的数据。比如它读取了场景树，但场景树的输出可能没包含节点可见性、锁定状态、颜色等属性；它执行了 GDScript，但错误信息可能只返回了简短文本。这时候 AI 会因为信息不足而产生误判。
建议在你的任务描述里，明确要求 Claude 在执行前后输出完整的场景树快照，或者在脚本里添加必要日志。例如：
执行完脚本后，调用读取场景树工具，打印 Cutscene 下所有节点和它们的类型、位置、属性。如果出现错误，原样输出错误信息。不要猜测，不要跳过步骤。这样能显著降低“AI 自以为成功了，但工程里其实什么都没变”的问题。
6. 从实验性自动化到可维护的生产流水线
6.1 不要放开全自动修改权限
在个人 Demo 里，你可以让 Claude 任意创建节点、执行脚本。但进入多人协作项目前半成品状态时，必须收紧权限。推荐做法是：
- 让 AI 只生成脚本和素材清单，不直接修改核心场景。
- AI 生成的脚本统一输出到
ai_output/generated_scripts/，人工审阅后复制到scripts/。 - 所有场景改动通过 git diff 检查，确认无意外删除和路径变化后再提交。
- 不要在 MCP Server 配置里暴露整个磁盘的读写权限，只暴露项目目录。
这样做不是不信任 AI，而是 MCP 操作的是真实项目文件，一旦出错影响面远大于聊天框里生成一段错误代码。
6.2 项目文件规范建议
在接入自动化流程之前，先定好项目规范，可以避免后期大量返工。规范建议至少包含：
- 节点命名：用
Cutscene_XXX、CameraRig_XXX这种功能前缀，不用默认的Node2D、Node3D。 - 素材命名：
类型_场景_描述_版本，禁止final_final_v2这类命名。 - 场景组织：过场动画统一放在
scenes/cutscene/，不混入玩法场景。 - 脚本职责：每个脚本只负责一个功能，禁止把镜头、动画、素材播放全写进一个
_ready()。
这些规范对人类开发者同样有效，但在 AI 参与的流程里更关键。AI 没有长期记忆，它下次生成代码时看到规范文件，才能保持风格一致。你可以在项目根目录加一个AI_WORKFLOW.md，把规范和常用任务写进去，每次让 Claude 操作前先读取这个文件。
6.3 素材版本管理
Higgsfield 生成的素材需要做版本管理。不要直接覆盖旧素材，建议生成结果先放到assets/media/staging/，确认可用后移动到assets/media/release/。对应的素材元信息可以记录在 CSV 或 JSON 文件里：
{ "fog_corridor_v01": { "source": "higgsfield", "prompt": "暗红色雾气缓慢向镜头流动，纯黑背景，半透明", "resolution": "1920x1080", "duration": 8, "status": "released" } }这个文件可以作为素材清单，让 Claude 在生成场景时读取，只引用status为released的资源。这样能避免 AI 引用了还没验证过的草稿素材。
6.4 发布前检查清单
每次准备把过场动画提交到版本分支前，建议按以下清单检查：
- 场景文件能否正常打开，没有丢失节点或引用。
- 所有 AI 生成的脚本都在 git 中有 diff 记录。
- 所有视频素材格式被 Godot 支持，且能在目标平台正常解码。
- 透明素材边缘没有明显黑边或白边。
- AnimationPlayer 每个关键帧时间点都在过场时长范围内。
- 镜头路径在起始和结束位置没有穿墙或穿模。
- 素材资源没有引用绝对路径，全部使用
res://相对路径。 ai_output中的提示词日志已保存，方便追溯生成来源。
这份清单可以在每次提交前过一遍。尤其是多人合作时，AI 自行创建的节点需要让美术和程序都能看懂。
6.5 后续扩展方向
跑通基础流程后，可以往几个方向扩展。
一是多镜头序列。把单个 12 秒镜头扩展成三四个连续镜头，由 Claude 根据分镜表批量在同一个场景里创建多个CameraRig。二是参数批量调整。你可以让 Claude 读取当前过场脚本，生成多个参数版本，比如镜头推进速度、动画曲线、视频透明度，然后逐个运行验证。三是与音效联动。目前只处理了画面，后续可以让 Claude 在动画轨道关键帧位置插入声音事件标记，再配合音频总线控制音量。
扩展时要坚持一个原则：每次只让 AI 增加一个维度的复杂度。先保证现有的镜头路径、素材播放、动画控制都稳定，再逐步加入新功能。否则问题叠加在一起，日志里全是报错，很难判断是 MCP 链路问题、脚本问题还是素材问题。
整个流程走下来，你实际得到的不只是一段自动生成的过场动画，而是一条可以复用的自动化链路。MCP 负责打通 AI 与 Godot 编辑器，Higgsfield 负责提供动态素材，Claude 负责把任务翻译成场景操作。接下来最值得做的，是挑一个你自己项目里的短过场，先手动做一遍，记录下操作步骤，再把它作为提示词交给这套流程。跑通过一次，后续的场景装配、素材替换和参数调整就会快很多。
