Godot MCP vs 手写脚本：什么时候该让 AI 操控编辑器

在 Godot 4 里做功能，多数时间花在两件事上：改场景树，以及写/改 GDScript。手写脚本精确，但重复劳动多；Godot MCP 让 Cursor、Claude Code 等客户端通过自然语言直接操作编辑器。问题不是「要不要用 AI」，而是哪一类改动交给 MCP 更划算。

两种方式差在哪里

	手写脚本	Godot MCP
工作方式	你在脚本与场景里实现细节	你描述意图，模型经 MCP 改节点、场景、脚本
强项	边界条件、性能、可审查的设计	批量样板、快速试玩、跨文件接线
风险	慢、易陷入重复 CRUD	结构若松散，生成结果难维护

Godot MCP（产品页）面向 Godot 4.x，原生 C++ GDExtension，MIT 开源；工具数量与类别以产品页为准（撰写时约 62 个工具 / 23 个类别）。兼容 Claude Desktop、Claude Code、Cursor、Windsurf、Cline 等 MCP 客户端。它操控的是编辑器上下文，不是单独的代码补全插件。

安装步骤见：Godot MCP 安装教程。

先守住 Godot 开发规范

无论是否用 MCP，项目仍应按 Godot 官方与社区共识组织，否则 AI 只会在错误结构上加速返工：

• 场景自包含：子场景尽量不依赖外部环境的硬编码路径；对外用信号、导出属性或公开方法，而不是深层 get_node("…/…")（参见 Scene organization）
• 组合优于堆继承：移动、生命、视觉拆成可复用节点/场景，单一职责
• 信号用于「响应」：命名用过去式（如 item_collected）；避免多层冒泡转发；跨远距离模块可考虑集中事件总线，但不要滥用 Autoload 当全局垃圾桶（参见 Autoloads vs nodes）
• 场景表达结构，脚本表达行为：复杂节点树优先 .tscn，行为用脚本挂载

向 MCP 下指令时，把这些约束写进提示（例如「用信号连接血量与 HUD，不要跨场景硬引用节点路径」），产出会更接近可维护工程。

什么时候用 Godot MCP

适合把意图清晰、模式常见的工作交给 MCP：

1. 原型试玩——移动手感、敌人巡逻、临时 HUD，需要快速改参数并进 Play
2. 样板系统——血条绑定、简单背包格、保存/读档骨架、菜单场景脚手架
3. 批量接线——为多个同类节点挂脚本、连信号、统一重命名
4. 对照学习——让模型按现有场景风格生成一版，再自己读 diff 理解惯例

典型提示应包含目标节点、文件路径与约束，例如：

在 res://player/player.tscn 上为 CharacterBody2D 增加冲刺（冷却 1s）；用信号通知 HUD，不要新建 Autoload。

什么时候坚持手写

以下情况优先手写，或 MCP 出草稿后必须人工重写关键路径：

1. 性能敏感路径——大量单位寻路、每帧分配、热循环数据结构
2. 强定制机制——独特规则、强耦合玩法，提示很难一次说清
3. 长期核心模块——战斗结算、存档兼容、联机同步：需要你能完整讲清控制流
4. 排障——信号未触发、状态机竞态：先读现有代码与场景，再决定是否让 MCP 改

经验法则：你无法在 Code Review 里解释清楚的生成代码，就不要合进主干。

推荐工作方式

1. 先定场景边界与信号契约（纸面或注释即可）
2. 用 MCP 搭脚手架并跑通最小可玩版本
3. 手写或精修核心逻辑与热路径
4. 再用 MCP 做外围迭代（UI 接线、调试打印、批量改名）

UI / 美术交付仍可走 AI Studio；引擎内脚本与场景树归 Godot MCP 或手写——两者不要混为一谈。

下一步

1. 按 Godot MCP 安装教程 接好 Cursor
2. 选一个已有规范场景，用一条带约束的提示做「只读检查 → 小改」
3. 对照 diff，只保留符合场景组织与信号约定的改动

延伸：用 Godot MCP 做 2D 平台跳跃、AI Studio + 引擎 MCP 端到端实录。