PanteraCapital以前我跟AI协作做Unity项目，总觉得AI像是隔着一层玻璃看编辑器：代码它能改，场景却碰不到；报错它能看到，但真正在Unity里帮我摆一个Cube、挂一个组件、跑一下Play模式，它完全插不上手。直到我把MCP接进来，这个问题才算有了正解。MCP（Model Context Protocol，模型上下文协议）解决的就是“AI能理解工具，但够不到工具”的鸿沟，在Unity场景里，它相当于给AI装了一根专用的数据和控制通道，让Claude、Cursor这类AI客户端可以直接操作Unity编辑器里的场景、资源、Console和菜单命令。
这篇文章我打算从原理讲到落地，把“Unity MCP使用”的完整路径走一遍：为什么需要它、环境怎么搭、默认能力有哪些、真实项目里怎么用、以及我在配置和日常使用中踩过的坑。无论你是刚听说MCP的新手，还是想把它接入工作流的资深开发者，照着这篇文章走，基本都能把这条链路跑通。
1. 为什么说MCP是Unity开发者的“新遥控器”
1.1 AI读得懂代码，却摸不到编辑器
先说一个很多人在实际工作中都会撞到的尴尬局面。你用Cursor或者Claude Code在Unity项目里写C#脚本，AI可以帮你把PlayerController.cs写得有模有样，但写完以后呢？你得自己回Unity编辑器，手动创建空物体、挂脚本、拖引用、调参数。如果这套操作一天重复二十次，人很快就会烦躁。
问题出在哪？Unity是一个强编辑器导向的引擎，大量核心操作——场景搭建、Prefab处理、材质绑定、Play模式验证——都必须在编辑器环境里完成。Unity的特性决定了这些操作不是单纯的代码生成，而是“代码 + 编辑器状态”的双重改动。AI编程助手再聪明，它默认只能读写文件，碰不到编辑器内部那套场景层级、Inspector属性、资源管线。换句话说，AI不是不会干活，是手不够长。
1.2 MCP把“编辑器操作”变成了标准接口
MCP出现之前，大家也想过各种办法。有的项目写一堆自定义Editor脚本，把重复操作封装成菜单项，再让AI去生成调用这些菜单项的代码。技术上可行，但每一套都是私有的，换个AI客户端就要重新对接，效率很低。
MCP的思路则是把这件事标准化。打个比方，它就是AI世界的USB-C接口：不管你是Claude、Cursor还是其他支持MCP的客户端，只要实现了协议，就能用同一套方式去连接任意一个暴露了MCP能力的工具。在Unity这个场景里，社区开源实现一般包含两块：
- 一个跑在Unity编辑器里的C#桥接脚本，启动本地HTTP服务，把编辑器能力包装成接口；
- 一个跑在AI客户端侧的MCP Server进程，负责把客户端的JSON-RPC请求转译成HTTP请求，发给Unity。
整个链路大概是这样的：
text复制AI客户端（Claude/Cursor） <-> MCP Server（Python进程） <-> HTTP <-> Unity编辑器内的C#桥接
这种架构的好处是职责清晰。AI客户端不需要知道Unity内部任何细节，它只跟MCP Server打交道；Unity桥接脚本也不关心对面是哪款AI，它只响应HTTP请求。替换客户端、替换Server实现，都不影响另一侧。这一点对Unity这种长期维护、工具链复杂的项目来说非常关键。
1.3 和Computer Use的区别在哪里
经常有人把MCP和Computer Use混为一谈，实际上两者是两条路线。Computer Use是让AI像人一样去“看屏幕、动鼠标、敲键盘”，模拟真实用户操作界面。听起来很通用，但Unity编辑器的界面层级非常复杂，一个菜单点错位置、一个弹窗挡路，整个过程就废了，速度也慢。
MCP走的是结构化通道。AI不需要找按钮在哪里，直接通过API调用说“创建Cube，位置（0, 1, 0）”，Unity桥接脚本收到请求后执行GameObject.CreatePrimitive并设置Transform，一步到位。后者在Unity这种工具里明显更可靠，也因此成了我推荐给团队的首选方案。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 搭建Unity MCP环境，从零到能对话
2.1 准备清单：版本与依赖
动手之前先确认几个基础条件：
- Unity版本：建议2021 LTS或更高。老版本理论上可以通过改代码兼容，但很多Editor API的用法在不同版本间有