企业官网建设流程全解析

1. 先说结论：这套组合到底能帮你省多少事

如果你也在用 Godot 做 2D 游戏，并且最近被各种 MCP 相关的内容刷屏，那这篇教程应该能让你少走不少弯路。标题里那个“超级粉碎兄弟”，本质上就是用 Godot 复刻一个 3D/2D 平台格斗游戏的战斗逻辑——百分比伤害、击飞、边界淘汰这些经典机制，而我会结合 Godot MCP 这套工具链，把 Claude Code 和 Gemini Anti-Gravity 两个 AI 编程助手拉进来，做成一个“我动口，AI 动手”的试作流程。

先说我能给你保证的结论：MCP 协议本身不是一个新东西，但当它和 Godot 编辑器打通之后，AI 不再只是“写脚本”的角色，它可以直接看场景树、改节点属性、启动游戏跑测试，甚至根据运行日志来调参。也就是说，AI 真正变成了一个能上手碰项目文件的协作者，而不是一个“帮你想代码但代码能不能跑全靠运气”的文本生成器。Claude Code 和 Gemini Anti-Gravity 恰好是目前最典型的两个 AI 代理形态，一个偏传统但够稳，一个偏前沿但迭代快，把它们都接到同一个 Godot 项目里做横向对比，本身就是件很有意思的事。

这篇教程适合谁？正在用 Godot 做玩法原型、觉得调试角色手感太费时间的人，或者已经听说过 MCP 但不知道具体怎么应用到游戏开发里的朋友。里面会有环境搭建、Node 配置、战斗系统拆解、AI 提示词设计的完整过程，以及我真实踩过的坑，文章末尾还能拿去做扩展。当然，基础要求在下面会说清楚：你至少得装好了 Godot 4.x，有一点 GDScript 的底子，不然 AI 给你的代码你也没法判断对错。

2. Godot 开发里的 MCP 到底扮演什么角色

2.1 MCP 不是一个插件，而是协议

先把这个概念讲透。MCP 全称 Model Context Protocol，是一个把 AI 模型和外部工具/数据源连接起来的开放协议。类比一下，它像 USB 接口：不管你是鼠标、键盘还是 U 盘，只要遵循 USB 规范，插上电脑就能用。MCP 的规范做的事就是定义 AI 程序和“工具服务端”之间的通讯方式——包括如何发现一个工具、如何调用它、如何传递结果。所以“godot-mcp”并不是一个 Godot 内置功能，它同时包含一个在本地跑的 MCP server（服务端），这个服务端通过编辑器插件的方式，把 Godot 的项目信息暴露给 AI 客户端。

我以前试过把 AI 接进 Godot 开发的几种姿势：直接往对话框里贴代码，AI 看不到项目结构，出来的代码经常挂在命名上；走文件系统读整个项目，AI 每次分析半天，很费 token 也没必要；最接近实用的是把关键脚本让 AI 读了再让它改，但改完你还是得切回编辑器看结果，来回拉扯很痛苦。MCP 的思路完全不一样——AI 客户端可以直接调工具，比如“读取当前场景树”“修改某个节点的 position”“新建一个 CharacterBody2D 并挂在场景下”“运行游戏”“拿当前调试输出”。这就跟人打开 Godot 编辑器从头到尾操作一遍项目差不多，只不过操作者变成了 AI。

2.2 godot-mcp 到底能暴露哪些能力

在真正动手之前，最好先对 godot-mcp 的能力边界有个概念，不然你以为它无所不能，实际访问起来会觉得自己被骗了。常见的实现会暴露以下几类工具：

• 场景树相关：获取当前打开场景的节点树，查询某个节点的属性、子节点列表、脚本资源等；
• 编辑操作相关：创建节点、重命名节点、设置属性、重新加载场景、保存场景；
• 运行时相关：启动当前项目、连接远程调试器、读取运行时的调试输出/错误日志；
• 文件相关：列出项目里的脚本文件、读取脚本内容、在不打开编辑器的情况下快速改脚本。

不同类型 MCP server 的功能是可能有差异的，你用的项目如果只实现了其中前两类，那 AI 就只能做静态编辑，不能替你跑测试。我实际用的这款（Godot MCP，GitHub 上能搜到）基本覆盖了上面四类，不过它的安装方式、端口号、启停方式都和人家的 README 强相关，所以如果碰到连不上的情况，优先回去翻它文档里的版本要求。

2.3 为什么格斗游戏特别适合用这个工作流

超级粉碎兄弟这种玩法，最大的痛点就是“手感”和“数值”调起来非常烦。它的角色移动、跳跃高度、攻击判定框大小、击飞动画曲线，每一个参数都在影响对战体验，而你很难一遍写对。传统流程是：改代码 → F5 跑游戏 → 试玩 → 发现不对 → 再改代码，循环往复。如果 AI 可以修改脚本，还能替你启动游戏、抓取运行日志，那这个过程就能自动化一大部分：你在对话里说“把前击重击的击飞力度调低 20%，启动游戏让我试一下”，AI 改完参数、运行项目、等你说下一个问题。这等于把调节奏从“人盯着参数表一遍遍试”变成了“人和 AI 像结对编程一样反复做实验”。

这也是我为什么把教程项目选成打斗玩法，因为它的参数耦合度高，最能体现“AI + 实时调试”的组合优势。如果你是做数值 RPG、解谜或者平台跳跃，这套流程同样能用，只是需要把关注点放到各自领域的“参数馒头”上。

3. 工具选型：Claude Code 还是 Gemini Anti-Gravity

3.1 两个 AI 代理的定位差别

先从形态说起。Claude Code 是终端里的 AI 编程代理，你在命令行里启动它，它会读取工程目录、给出执行计划，并且可以通过 MCP 配置外接工具。它的核心优势在于“稳定”和一个逐步拆解的思考过程，适合做需要理解项目的复杂任务。Gemini Anti-Gravity 是 Google 出的 AI 代理环境（对应 Gemini 模型体系），它解决的问题和 Claude Code 类似，但它背后同时接入了 Google 的 Gemini 模型和一套相对更新的工具调用能力，在部分场景下反馈速度更快、多模态理解更强，比如你可以直接给它一张截图让它分析 UI 布局问题。

用一句话概括：Claude Code 像一位经验丰富但比较保守的坐班架构师，Gemini Anti-Gravity 像一位手速极快、思路跳脱的年轻开发。放到 Godot 这个具体场景，Claude Code 更擅长理解玩家状态机、战斗逻辑这类需要全局考虑的项目结构；Gemini 则在快速生成某个模块的代码、写 UI 相关脚本时更得心应手，因为它对图片和空间排布的理解天然有优势（GDScript 它也没问题，毕竟代码量级和训练语料充足）。

3.2 Claude Code 的接入与实战感受

我的主力工具目前是 Claude Code。就说一个细节：它的 MCP 配置是通过命令行完成的，添加 godot-mcp server 之后，进入项目目录它就会自动发现可用的工具。你在对话里问“现在玩家节点的 velocity 是多大”，它真的会去调 MCP 里的属性查询接口，把当前的值返回给你，而不是凭空猜。这个“真实数据回传”的特性非常关键，因为这意味着 AI 的决策基于项目实际状态，而不是训练数据里的平均预期。

配置方式比较直观，在终端里执行类似“claude mcp add godot -- ..."的命令，把 server 启动脚本指向本地运行的服务即可。如果你用 VSCode 扩展来跑 Claude Code，也可以直接在图形界面里管理 MCP 连接，不过原理都一样，底层仍是 JSON-RPC 通信。

一个补充：Claude Code 对上下文窗口的管理比较有自己的风格，你在同一个会话里让它改并保存文件，然后启动项目几次，它会把过程拆得清清楚楚。但注意不要让一个会话里堆积太多轮次的“改代码 — 运行 — 报错 — 再改”，像人类同事一样，它也会开始混乱。后面的实战环节我会具体演示怎么拆分任务。

3.3 Gemini Anti-Gravity 的接入与独有优势

Gemini Anti-Gravity 的配置稍微有点不一样，因为它更像一个集成了 AI 能力的云端/本地环境，而不仅仅是一个终端工具。我把它接到 Godot MCP 的时候，主要方式是给它注册一个自定义 agent（或者说一个 action），让它可以通过 MCP server 去操作本地 Godot 项目。它的天然优势在于：如果我用截图把当前游戏的画面发给它，它能直接把“UI 里血条颜色不对”这种模糊描述转化成“HUD 节点中 TextureProgressBar 的 modulate 值需要调整”这样精确的行动指令。

它也有一些让我不太满意的地方。首先是当你需要修改大量现有脚本时，它对“既有代码风格”的遵循程度不如 Claude Code，经常自作主张引入新的命名风格；其次它执行步骤的“展示感”更强，但实际成功率偶尔还不如预期。所以我的建议是：如果你想找一个“全局架构理解强”的助手，Claude Code 是首选；如果你希望“视觉反馈 + 快速生成新模块”，Gemini Anti-Gravity 更合适。

3.4 选型对比表与我的最终建议

最终我的建议不是“二选一”，而是“两个都接”。它们能共存在同一个项目里，不会互相冲突，不同阶段用不同工具：搭建战斗框架和状态机时用 Claude Code，打磨 UI 表现和做快速原型时用 Gemini Anti-Gravity。这套流程在后面的实战中会频繁出现，你就能看到切换的实际节奏。

4. Godot + MCP 环境搭建：从零到一把跑通

4.1 前置准备清单

先别急着装工具，把环境搞清楚，能省下一大半排错时间。你需要准备：

• Godot 4.2 或 4.3 版本（某些 MCP server 对 4.4 的兼容性还没完全验证，所以我的建议是先用稳定版）；
• Git，用于下载 MCP server 源码或者直接 clone 到本地；
• Python 3.10+，大部分 godot-mcp server 是用 Python 写的；
• 一个能正常联网的终端环境，因为 Claude Code 和 Gemini Anti-Gravity 的服务端要访问远端模型 API；
• 一个测试用的空 Godot 项目，专门用来做连通性验证，别一开始就往正式项目里乱接。

这些做完之后，你还需要决定：你是想把 MCP server 作为一个独立的 python 进程跑起来，还是通过 npx/uvx 这类工具号令式启动。普通项目我推荐 python + venv 的方式，可控性最强；如果你只是临时体验，可以用 npx 一类的包管理工具，一条命令就能起服务。

4.2 启动 MCP Server 的完整步骤

拿到 godot-mcp 的源码后，在项目根目录下创建一个虚拟环境，然后安装依赖。以下命令基于 Linux/macOS 的终端，Windows 上把激活命令换成你的环境对应写法即可。

git clone https://github.com/您的源/godot-mcp cd godot-mcp python -m venv .venv source .venv/bin/activate pip install -r requirements.txt

安装完成后，启动 server。不同实现启动参数略有区别，但通常你会看到它监听在本地的一个端口上，比如 9000 或 8000。我们把它跑在前台，方便看日志。

python server.py

看到“listening on 127.0.0.1:9000”之类的输出，说明服务端已经能接收 MCP 请求了。但注意，这个 server 本身不会主动去找 Godot，你需要先在 Godot 编辑器里装一个配套插件，一般是把插件文件夹（比如 addons/godot_mcp）拷贝到项目的 addons 目录下。然后在 Godot 的“项目设置 -> 插件”里启用它，它会启动一个轻量级编辑器插件，主动连到那个端口。

4.3 在 Claude Code 里接入 Godot

Claude Code 接入 MCP 的方式很直接，只需要在项目目录下执行一条配置命令，后面跟你的 server 地址即可。以我的配置为例：

claude mcp add godot -- python /path/to/godot-mcp/server.py

如果你已经把 server 作为独立进程跑起来了，这里可以把启动命令换成 HTTP 连接方式（具体参数看你选用的 SDK 支持哪种）。配置完成后，进入 Claude Code 会话，输入类似“列出当前项目可用的 MCP 工具”的问题，它应该会把 godot 相关的工具名列出来。如果没看到，八成是配置命令里的路径不对或端口冲突，去检查 server 的日志。

连上之后，试着让它读一下当前场景树的根节点：

用 godot 工具获取当前场景的根节点，并输出它的节点类型和子节点列表。

如果它能基于 MCP 接口返回真实数据，说明整条链路已经通了。

4.4 在 Gemini Anti-Gravity 里接入 Godot

Gemini Anti-Gravity 的配置方式相对依赖你用的客户端形态。以我目前在用的环境为例，它允许你在配置文件中定义一个 MCP 端点。核心是你要让它知道服务地址和传输协议，配置片段类似：

{ "mcpServers": [ { "name": "godot", "url": "http://127.0.0.1:9000", "transport": "http" } ] }

有些版本走的是 stdio 模式，那你要改成命令和一串参数的形式。最需要注意的是，很多 AI 代理环境出于安全考虑，默认不允许“本地回环地址 + http”这种组合，你需要在安全设置里把本地回环调用放行。这一步卡住不少人，因为它不像 Claude Code 那样会明确提示，有时候 AI 只是沉默地不调用工具，你不会知道它其实已经连不上了。

接通后再做一次类似的验证：让它读取当前项目里的 player.gd 文件内容，并简单解释其中“跳跃状态”的实现。如果它能正常读取。

4.5 连通性自检的五个黄金问题

我每换一个项目，都会用五个问题做自检，全部答对才算真正打通 MCP 链路，不然我会认为“能用”只是偶发的运气。

1. 当前场景的根节点类型是什么？
2. 玩家节点的子节点里有没有 CollisionShape2D？
3. player.gd 中 jump_velocity 的默认值是几？
4. 启动游戏 3 秒后，打印出来的调试日志是什么？
5. 如果我把玩家节点名字改成 player_new，场景树里会立即反映出来吗？

前两个问题检验的是读场景树，第三个是读文件，第四个是运行游戏并捕获输出，第五个是修改编辑器状态后的同步反馈。五项全过，你就可以放心开始开发了。

5. 打造“超级粉碎兄弟”式战斗原型：AI 协作全流程

5.1 场景结构与玩家基础

超级粉碎兄弟的核心战斗是在一个横板平台场景里进行的，玩家控制角色在平台上移动、跳跃，用各种攻击把对手打出屏幕边界。为了让 AI 协作的效果最显眼，我先把这个原型拆成几个清晰的小模块：场景、角色、攻击判定、伤害百分比、击飞逻辑、HUD、淘汰与重生。

场景我建了一个基础的 Main.tscn，里面只有一个 Node2D 根节点（命名为 Main）、一个玩家节点（Player，CharacterBody2D）、一个简单的平台（StaticBody2D）、一个 Camera2D 和一个 CanvasLayer（用于挂 HUD）。最开始的节点搭建，我是让 Claude Code 直接通过 MCP 创建的，它先在编辑器里创建了 Player 节点，然后再添加 CollisionShape2D，整个过程不用我手动画。虽然从效率上讲手点更快，但好处是它理解了结构之后，后面修改场景树的指令它都执行得比较准确。

玩家角色一共有三种子节点：CollisionShape2D（碰撞体）、Sprite2D（用来显示角色的 ColorRect 占位即可，等美术资源出来再换）、一个 Area2D 子节点用来做攻击判定框。这里最值得让 AI 帮忙的地方是“攻击判定框的位置和大小怎么调”，通过对话即可改属性，非常舒服。

5.2 状态机与角色控制的实现

战斗类角色最忌讳把所有的逻辑塞到 _physics_process 里一通 if/else。我让 Claude Code 先搭一个轻量的状态机框架，状态包括 idle（待机）、run（跑动）、jump（跳跃）、attack1（普通攻击）、attack2（强攻击）、hit（受击）。它给的 GDScript 骨架大致是这样：

extends CharacterBody2D enum State { IDLE, RUN, JUMP, ATTACK1, ATTACK2, HIT } var current_state: State = State.IDLE var speed: float = 300.0 var jump_velocity: float = -400.0 var damage_percent: float = 0.0 var knockback_modifier: float = 1.0 func _physics_process(delta: float) -> void: match current_state: State.IDLE: handle_idle(delta) State.RUN: handle_run(delta) State.JUMP: handle_jump(delta) State.ATTACK1: handle_attack1(delta) State.ATTACK2: handle_attack2(delta) State.HIT: handle_hit(delta)

这段代码本身不难，但 Claude Code 帮我顺手把“状态切换时的动画播放节点”和“输入映射”也处理了。我只需要告诉它“进入 RUN 状态时播放 walk 动画，moving 速度如果低于 10 就转回 IDLE”。这种细节，AI 在写的时候就能自动补全。

提到输入映射，我建议让 AI 在项目设置的 Input Map 里注册这些动作：move_left、move_right、jump、light_attack、heavy_attack。这个也能通过 MCP 的编辑器操作接口来配置，但实际体验下来，让 AI 通过 GDScript 里的 is_action_pressed 读取输入是更顺手的方式，不过要注意 Input Map 里没有注册这些动作时，Godot 会直接报错。

5.3 攻击判定生成与伤害累计

接下来是重头戏：如何把“一拳打出去”这件事变成代码。超级粉碎系列的特色是伤害百分比，也就是说角色不是一眼看血条，而是看一个越打越高的百分比数字，这个数字同时决定了后续击飞的距离。我用 Area2D 来做攻击判定框。玩家按下攻击键时，攻击判定的子节点会被激活一段时间，如果在这个窗口内碰到另一个玩家的 Hurtbox（另一个 Area2D），就触发伤害。

这里的关键点在于要用“进入判定时给一次伤害”而不是每帧给伤害。可以用一个标志位 safe_zone——碰撞进入时给伤害，然后立刻禁用攻击框。Claude Code 给的实现逻辑就非常干净：攻击框 active 时间为 attack_duration，当 body/area 进入信号触发时，判断是否是对手，如果是就调用 apply_damage() 函数。

signal player_took_damage(damage: float) func apply_damage(base_damage: float, knockback_dir: Vector2) -> void: damage_percent += base_damage knockback_modifier = damage_percent / 100.0 + 1.0 current_state = State.HIT velocity = knockback_dir * (base_damage * 12.0 + damage_percent * 2.5) player_took_damage.emit(damage_percent) move_and_slide()

这一段值得解释一下“为什么”：knockback_modifier 和 damage_percent 挂钩，意味着你被打得越痛，后续被击飞越夸张，这正是“super smash”手感的核心。你不需要读懂每一行，但你得能告诉 AI 你希望“伤害和击飞呈曲线增长”，AI 才能写出这个公式，不然它默认用线性也说得过去。

5.4 击飞方向与边界淘汰判定

要不要有“击飞朝向”？我的答案是不仅要，而且最好在战斗原型里体现出来。最简单的实现方式：攻击本身不提供一个固定的击飞方向，而是根据“攻击判定框自身朝向 + 被击者相对位置”计算。比如你往右出拳，右边缘碰到对手，那击飞方向就应该偏右下；如果你出招时对手站在身后，击飞方向就要反过来。

我把这个规则作为一句话补充给 AI：“击飞方向向量 = 攻击框前端方向 * 1.0 + 竖直向上 * 0.4，然后根据当前玩家 facing 方向做翻转。” 你看，这句描述完全是游戏设计语言，AI 能直接落成代码。Gemini Anti-Gravity 在生成这一类“设计意图转公式”的场景里表现得比较自然，可能是因为它训练数据中对这类玩法描述素材更多。

边界淘汰的规则也简单：场景四周设置一个看不见的边界矩形，玩家一旦越界，就触发淘汰，延迟一秒后重生到出生点。这个逻辑我用 CLI 让它快速生成，Gemini 写这个特别快，几乎没让我改过，代码里就是 Rect2 的 has_point 检查加 timer。

5.5 HUD 与画面反馈

这里 Gemini Anti-Gravity 的优势就出来了。我给它的描述是：“在 CanvasLayer 用 Label 显示玩家血条和百分比，位置居中靠下，同步玩家的 damage_percent”，它直接给出了包含 HBoxContainer、Label、StyleBox 的完整节点结构，甚至自己在代码里加了 modulate 颜色变化——血量百分比高的时候，颜色从绿变红。虽然这个功能做起来不复杂，但它在没有我明确指令的情况下主动做了“战斗反馈”的优化，节省了我不少手动节点搭建时间。

画面反馈里还有一个很实用的屏幕震动效果：给 Camera2D 添加一个小的噪声偏移。这部分我是让 Claude Code 实现的，因为它要改动 _process 和设置 camera offset，涉及状态切换，它对全局结构的把握更稳。

6. 实战中一定会遇到的坑与排查技巧

6.1 MCP Server 连不上的高频原因

这是最让人头疼的启动报错，实际上 80% 的原因可以归为三类：端口被占用、Godot 插件没有启用、客户端配置里的 server 地址写错。我的排查顺序是：先在浏览器或 curl 访问一下 http://127.0.0.1:9000 看看有没有响应，如果没有，再看 server 进程在不在；如果 server 正常，再看 Godot 右侧的“远程调试”是否已经标绿。记住，Godot 编辑器插件虽然启动了，但如果项目没有打开任意场景，有些实现会返回空数据而不是报错，这也容易被误判为“连接失败”。

6.2 AI 改了代码但游戏一启动就崩

这种情况通常不是因为 AI 的 GDScript 语法错了，而是它依赖了它“以为存在”的节点或者信号。比如它写了一个对某个 Timer 节点的引用，但实际场景里根本不存在这个 Timer。Godot 的报错信息会精确到“Invalid access to property or key 'timeout' on a base object of type 'null instance'”，你能拿到这个信息之后，直接让 AI 看错误日志修改即可。这里有个非常实用的技巧：不要让 AI 凭空写“节点引用”，先通过 MCP 的功能查询场景树再改代码。例如我每次都会提醒 Claude Code：“先获取 Main 场景的子节点结构，再修改 player.gd 里对 Timer 的引用。”这样它基本不会踩到空引用的雷。

6.3 提示词设计：远程指挥的沟通艺术

把 AI 当成一个刚入职、手上有编辑器权限但完全没上下文的新人，你的提示词决定了它的表现。我的经验是：

• 说得具体。“把攻击伤害改成 8”永远不如“把 light_attack 的 base_damage 改成 8，然后启动游戏让我感受一下手感”；
• 分步操作比一次做完更好。让 AI 一次性“创建节点、写脚本、启动游戏、修改动画”通常会让它思维过载；
• 要求它先输出“准备做的步骤”，再操作。这样你在动手前就能拦截那些明显有问题的方案；
• 出错时把 Godot 输出的错误日志直接复制给 AI，不要自己转述“好像崩了”，它看到原始日志能定位得更准。

6.4 两个 AI 工具交叉使用的协作技巧

最后是我个人最满意的部分：让 Claude Code 和 Gemini Anti-Gravity 在同一个项目里各司其职。我的调配方式是：Claude Code 负责全局结构，比如搭建状态机、解决编译错误、优化战斗逻辑；Gemini Anti-Gravity 负责视觉反馈、快速生成 UI 节点代码、做玩法原型。这个分工不是绝对的，但能大幅减少“交替代价”——两个工具切换时，我会在对话开头给一段项目说明：“当前项目是一个 Godot 2D 对战原型，场景根节点是 Main，玩家脚本在 player.gd，请先读取这两处再开始。”这能有效避免新工具大改全局结构，然后我才能放心让它们成为真正的左膀右臂。

这一套玩下来，我最大的感受是：Godot 加 MCP 这类工具，核心价值不是让 AI 替你写代码，而是让你的游戏开发过程变成“语言指挥 + 快速试错 + 实时反馈”的闭环。你不需要懂每一个 API，但你得懂玩法设计的“为什么”，剩下的体力活交给 AI 去跑就行。希望这篇教程能帮你把这条链路搭起来，也欢迎用这套原型继续做你自己的对战玩法实验。