我坐在电脑前随手打开终端cd进一个除了名字之外什么都没有的空目录然后敲下claude。接下来发生的事简单说就是一个空文件夹最后真的变成了一个能打开、能操作、能玩下去的 Unity 游戏。整个过程里Claude Code 负责写代码、改逻辑MCP 负责让 AI 能伸手进 Unity 编辑器里布置场景、挂脚本、调参数。这篇就从一个亲历者的角度把这条从零到一的完整链路拆开讲环境怎么搭、MCP 到底在中间扮演什么角色、实战迭代时每一步长什么样以及我踩过的那些坑。1. 空文件夹起步看似离谱其实是 AI 辅助开发的合理延伸1.1 一个什么都没有的起点先还原一下当时的场景。项目文件夹是全新创建的里面没有 Unity 工程结构没有任何 C# 脚本连最基础的Assets目录都是我手动建出来的。传统做法下我得先打开 Unity Hub 创建项目等编辑器加载然后手动创建场景、摆物体、写脚本、调参数没两三个小时出不来一个像样的原型。而这次我想试的是另一条路径让 AI 从头帮我搭。Claude Code 是一个跑在终端里的 AI 编码工具它可以读取项目文件、写文件、执行命令而你只需要用自然语言告诉它你要什么。配合 MCP 协议它还能调用外部工具——这里就是 Unity 侧的 MCP 服务器让 AI 不再只是活在文件系统里而是可以直接操作运行中的 Unity 编辑器。结果证明这条路是通的。虽然中间有不少波折但一个下午的时间从空目录到一个包含完整玩法的小型 3D 游戏是能做到的。这篇文章写出来就是想把这个工作流的真实面貌还原给大家看哪些环节顺畅哪些环节需要人盯以及为什么说这不是AI 一键生成游戏的魔术而是一套需要理解原理才能玩转的开发方式。1.2 为什么选择 Claude Code 而不是网页对话式 AI用网页版 AI 也能生成 Unity 脚本这是很多人的第一反应。但稍微试过就会知道网页对话式 AI 最大的问题是断手断脚它可以给你一段完整的PlayerController.cs但你得自己把它保存成文件、放进Assets目录、创建 GameObject、挂脚本、调 Inspector 参数。步骤一多来回切换窗口消耗的精力比自己写都累。Claude Code 不一样的地方在于它附着在项目目录上和文件系统是通的。它可以直接创建目录结构、写脚本、改文件操作之后你能立刻在本地看到结果。再加上 MCP 这层AI 就能通过工具调用读写 Unity 编辑器的当前场景、查询场景里的对象、创建新的 GameObject、修改组件属性、执行菜单命令。这相当于把 AI 从只出一张嘴写代码升级成了能动手改编辑器状态。从这个角度说Claude Code MCP 的组合本质上是把 AI 集成进了开发闭环里而不是让它停留在建议者的角色。这也是整个项目能跑通的关键前提。1.3 这条工作流适合谁先说结论这套玩法适合有一定 Unity 基础、想提高原型制作效率的人。如果你完全不懂 Unity连 GameObject、Transform、Prefab 是什么都没概念那 AI 生成的脚本出了问题你连排查方向都没有最后只会陷入让 AI 改、报错、再让 AI 改的死循环。反过来如果你已经熟悉 Unity 的基础操作对自己的需求也很明确那这套工作流会非常高效。因为 AI 不需要你教它写一个类继承 MonoBehaviour这种细节你能用一句话表达清楚玩家控制方块移动、收集金币、碰到障碍扣血它就能把对应的脚本结构、场景布置方案、参数调节建议一起给出来。人是提需求、做判断的AI 是写代码、做执行的MCP 是连接两者的手。2. 环境搭建把 Claude Code、MCP 服务器和 Unity 编辑器接成一条通路2.1 需要准备的工具清单整个链路由三部分组成缺一不可。第一部分是 Claude Code 本身需要安装到本地命令行环境里第二部分是 Unity 侧的 MCP 服务器它负责监听来自 Claude Code 的请求并把这些请求翻译成针对 Unity 编辑器的操作第三部分是 Unity 编辑器本身项目实际加载和运行都在这里。我建议使用 Unity 官方的长期支持版本也就是常说的 LTS 版本。选 LTS 的理由很实在社区里的 MCP 服务器适配最多的就是 LTS网上能搜到的实践案例也大多基于这个版本遇到问题时更容易排查。过于新的版本反而可能因为 API 变动导致 MCP 服务器连不上。2.2 Claude Code 与 MCP 服务器的配置在 Claude Code 里添加 MCP 服务器一般是通过命令行的配置操作完成的。格式大致是添加一个名为unity的服务器启动命令指向 MCP 服务器的可执行文件同时指定通信端口号。配置完成后可以执行查看命令确认服务器列表里已经出现unity且状态正常。这里有一个值得新手留意的细节MCP 服务器的启动依赖本地运行环境。如果启动失败大多数情况下不是协议本身的问题而是这台机器上缺了对应的运行时依赖。所以如果你在配置阶段就发现服务器起不来优先检查本地环境的安装情况而不是急着怀疑配置写错了。配置文件方面Claude Code 会把 MCP 服务器配置记录在用户主目录下的配置文件中。需要手动改配置时可以用内置命令打开配置文件也可以直接去文件里改。我个人的习惯是优先用命令来管理因为命令操作至少会帮你做格式校验手改 JSON 一旦漏掉一个逗号排查起来纯粹浪费时间。2.3 Unity 侧的项目加载方式工程结构方面没有太多讲究我甚至建议直接从空目录开始让 Claude Code 帮你建立最基本的文件夹结构。比如Assets、ProjectSettings、Packages这些目录AI 会按 Unity 工程的标准布局来创建。但有一个关键点必须说清楚MCP 服务器真正能操作的是正在运行 Unity 编辑器里的那个项目。也就是说你需要用编辑器打开这个目录等项目加载完成MCP 服务器的连接状态显示正常Claude Code 的工具调用才能真正落地。如果编辑器都没打开AI 生成的脚本文件可以写进磁盘但它无法帮你创建场景里的物体因为场景这个概念只存在于运行中的编辑器里。这一点是整个工作流的认知核心Claude Code 负责文件层面的操作MCP 负责编辑器层面的操作两者通过同一个项目目录和编辑器状态同步起来。理解了这个分层后面遇到脚本生成了但场景里什么都没发生之类的问题你就能很快定位是哪一层断了。3. 实战回放一个 3D 收集小游戏从零到可玩的完整迭代过程3.1 第一轮用自然语言描述需求生成基本框架我在 Claude Code 里给出的第一段提示词大意是创建一个 Unity 3D 项目做一个第三人称视角的收集游戏玩家控制一个方块角色在平面上移动场景里出现若干可以拾取的金币吃到金币加分同时散落一些障碍物碰到障碍物会扣掉一条命。第一条回复并没有直接甩代码而是先把需求拆解成了几个模块玩家控制脚本、金币的旋转与拾取逻辑、障碍物检测、计分与胜负条件、场景布局。随后它在项目里生成了对应的目录结构和核心脚本文件。这一步虽然没有直接产生能玩的结果但为后续所有工作打了底。我也注意到它合理地补全了一些我嘴上没说但游戏必需的东西主摄像机要跟随玩家、地面需要碰撞体、金币需要触发器而不是实体碰撞。这些是典型的游戏开发常识属于看着简单、但缺了就完全玩不起来的细节。3.2 第二轮脚本生成之后MCP 开始布置场景脚本文件都就位之后真正体现 MCP 价值的一步来了。我让 Claude Code 直接操作场景创建地面、生成玩家方块、摆放若干金币并把这些对象按逻辑命名好。MCP 服务器接到这些请求后在 Unity 编辑器里依次执行了创建对象、设置位置、添加组件、挂脚本等一系列操作。我能从 Unity 编辑器的 Scene 视图里看到变化过程一个方块出现在原点附近周围散落着旋转的金币地面铺开平行光把场景照亮。这些不是幻觉也不是脚本里写死的假数据而是实实在在出现在编辑器层级面板里的 GameObject。这个过程中还发生了一个有意思的细节Claude Code 生成金币时没有在场景里摆十个一模一样的空对象而是创建了一个金币 Prefab再用代码批量实例化。这说明它在处理重复对象时选择了合理的技术方案。它不是死板地执行摆十个而是理解了批量生成才是游戏开发的常规做法。3.3 第三轮运行测试处理编译错误与逻辑问题场景布置完成之后我在编辑器里点下了播放按钮。结果当然不是一次就跑通——能一次跑通才不正常。第一次报错是脚本里一个方法签名有出入具体来说是某个碰撞回调的方法参数类型写错了。麻烦的地方在于Unity 的编译错误并不会直接弹到 Claude Code 的终端里编辑器会停在播放前并显示编译失败。这时候我的做法是把编辑器 Console 面板里的报错信息复制出来粘回 Claude Code 的对话里。它能立刻定位到是哪个文件、哪一行、哪个方法并给出修复版本。第一次修复后编译通过但运行时又出现了一个更隐蔽的问题——玩家方块没有碰撞体直接从地面掉下去了。这个问题的根源在于脚本里用了transform.Translate来控制移动却没有给方块添加Rigidbody和Collider。AI 分析了原因之后通过 MCP 直接给方块添加了刚体组件同时把移动方式改成了更适合物理环境的Rigidbody控制。改完之后方块能稳定地站在地面上移动也不会出现抖动。3.4 第四轮手感调优与可玩性验证游戏能跑之后下一步是让它变得能玩而不是能动。手感调优是游戏开发里最靠感觉的环节AI 在这里的表现比较微妙它能给参数但不能替你感受。我说方块移动太慢转向也迟钝它会根据当前的速度参数给出合理的调整建议比如把移动速度从 3 调高到 6让移动方式改成直接朝向输入方向而不是缓慢转向。我把这些参数通过对话反馈给它它再通过 MCP 去改 Inspector 里的数值。来回两三次之后手感确实好了不少。金币的旋转速度、拾取范围、障碍物的扣血数值也都是这样反复调出来的。我特别提了金币旋转速度要看起来舒服不要太晕它给出的方案是让金币沿 Y 轴以每秒 90 度的角速度旋转这个数值确实比较温和。到了这个阶段游戏已经具备了基本的可玩循环移动方块、吃金币、躲障碍、分数上涨、碰到障碍掉命。我甚至拉到场景里试了几分钟作为一个小原型它是成立的。4. MCP 究竟做了什么为什么 AI 写代码不等于 AI 开发游戏4.1 只靠文本 AI 的困境代码生成了场景还是空的很多人对 AI 编程的理解停留在生成代码这个层面。但 Unity 游戏开发不是代码写对了就等于游戏做好了它高度依赖编辑器的场景状态哪个物体挂在哪个层级下、脚本挂在哪个对象上、物理参数是多少、摄像机摆在哪里。这些信息绝大部分存在于.unity场景文件里而不是 C# 脚本里。如果只有 Claude Code 没有 MCP它能做的就是生成一个又一个.cs文件。然后呢你得自己打开 Unity、手动创建物体、把脚本一个个拖上去、设置灯光和摄像机。一个十多个物体的场景做下来手动操作的量不比从零手写少多少。AI 省掉的只是敲代码的时间场景搭建的时间一分没省。4.2 MCP 把文件级 AI升级成了编辑器级 AIMCP 做的事情可以概括为一句话让 AI 能读写运行中的 Unity 编辑器状态。它通过一套标准化的工具接口把 Unity 编辑器里的常见操作暴露给 Claude Code包括但不限于创建和删除 GameObject、查询场景内对象、获取或修改组件属性、执行编辑器菜单命令、读取 Console 日志。有了这层能力之后开发闭环才算真正闭环Claude Code 写脚本 → MCP 把脚本挂到对象上 → 运行报错 → 从 MCP 读取报错信息 → 修改脚本 → 再挂载。整个过程里我可以完全不碰编辑器只需要在终端里看反馈、在一轮一轮的对话里下指令。我打一个不那么严谨但很好理解的比方没有 MCP 的 Claude Code 像一个只能写方案的书生他会给你一份特别详细的施工图纸但不会帮你砌墙MCP 让 AI 长出了手和眼睛能拿工具、能看现场你只需要不断下达这里建一堵墙、那里开一扇窗的指令。4.3 理解 MCP 的工作边界才能用好它MCP 也不是万能的它有明确的边界。最典型的一点是它操作的粒度受限于工具接口如果某个 MCP 服务器没有暴露修改 Terrain 地形的工具那 AI 就改不了地形即使它完全知道怎么改。这种限制不是 AI 能力的限制而是接口覆盖范围的限制。AI 也无法主动感知编辑器里发生的、未经 MCP 上报的变化。举例来说如果你手动在 Unity 里拖了一个物体进去而 MCP 服务器没有做变更通知Claude Code 对话里并不会自动知道这个物体的存在除非它主动调用查询工具刷新状态。所以实践中的工作纪律非常重要要么明确告诉 AI场景里多了个东西你先查询再操作要么尽量把场景改动都集中在 AI 自己的 MCP 操作里避免人手和 AI 混着改。混着改是后面要讲的坑之一。5. 实测中踩过的坑与绕坑方案5.1 编译错误循环把报错原样喂回去而不是让 AI 盲猜第一个折磨人的问题是编译错误。我最初的习惯是直接把编译没通过这句话丢给 Claude Code希望它能自己意识到哪里写错了。但它看不到 Unity 编辑器的编译信息在没有任何反馈的情况下它只能基于代码本身去猜。猜对的时候有猜错的时候更多有时候一个错误能来回三四轮。后来我换了个方法把 Console 面板里的报错日志完整复制贴进对话里。报错日志里包含了文件路径、行号、错误类型和描述AI 拿到这些信息以后基本一次就能定位并修复问题。这个坑表面上是个操作习惯问题本质上反映的是 AI 开发的核心约束AI 需要即时反馈。你给它越明确的反馈它收敛得越快。跟它说报错了不如给它看报错本身给它看报错不如让它自己通过 MCP 去拉取日志。5.2 场景文件冲突人和 AI 不要同时改场景有一轮我手痒想自己拖一个装饰物体进场景看看效果。结果接下来 Claude Code 生成的场景操作把我手动加进去的东西给覆盖掉了。原因在于 MCP 在生成新场景时会基于它上一次查询到的场景状态如果你的手动改动没有同步进它的认知它的操作就会产生覆盖。这个问题很难完全避免只能通过规范操作来规避。我后来的做法是只要这一轮在让 AI 改场景我就完全不碰编辑器如果我要手动调整就在对话里先告诉它我改了一些东西你重新查询场景再继续。Unity 场景文件的合并问题本来就是多人协作的痛点现在变成你和 AI 协作的痛点道理是一样的。5.3 MCP 连接不稳定编辑器休眠与服务器重启有一段时间 MCP 服务器频繁断开连接现象是 Claude Code 调用工具时报超时。排查后发现是我这边 Unity 编辑器长时间处于后台状态等再切回来时MCP 服务器和编辑器之间的本地连接已经断开了。解决方法不复杂保持编辑器窗口在前台尤其是长时间没有操作之后要执行 AI 指令之前先在编辑器里点一下唤醒它。另外如果发现连接断了直接重启 MCP 服务器通常能解决不用重启整个编辑器。这个坑技术上不难绕但第一次碰到时确实会卡住很久因为你会怀疑是配置问题而不是连接问题。5.4 版本三角Unity 版本、MCP 服务器版本、Claude Code 版本要匹配最后一个值得单独说的问题是版本兼容。Unity 编辑器的 API 在不同版本之间会有调整MCP 服务器需要跟上这些变化才能正常工作。Claude Code 本身也在持续更新它的 MCP 客户端实现偶尔会改变对工具调用结果的处理方式。这三者的版本关系我用一个词总结就是三角匹配。我的建议是如果你参考某篇教程或某个案例来复现环境尽量保持三个部分的版本和作者一致。如果自己组合优先选 Unity LTS再选更新时间最近的 MCP 服务器遇到问题先在兼容性上找原因而不是在代码逻辑里找原因。我一次莫名其妙的工具调用失败最终定位到的原因就是 Unity 版本太旧MCP 服务器调用的某个编辑器 API 在那个版本上还不存在。6. 这套开发方式的边界以及它延伸出的更广用法6.1 适合做什么原型、小玩法、工具类验证经过这次实践我对什么项目适合这套工作流有了比较清楚的判断。首当其冲是游戏原型。当你想验证一个玩法到底有没有意思用 Claude Code MCP 搭一个简陋但可玩的场景效率远高于手写。其次是工具类的小项目比如场景批量管理、资源重命名、自动化检查之类的编辑器扩展工具。这类需求逻辑简单、边界清晰正是 AI 代码生成最擅长的场景。让 AI 写一个编辑器脚本、通过 MCP 在编辑器里执行再根据结果迭代一两次一个能省下不少重复劳动的编辑器工具就出来了。小型的休闲游戏、简单的 2D 平面玩法也非常合适。玩法越接近规则明确、表现简单AI 就越能快速产出有效代码而不用陷进复杂的表现层和美术资源里。6.2 不适合做什么重美术、复杂网络、大型架构反过来也要说清楚有几类需求我目前不推荐用这套方式来做。第一类是重美术依赖的游戏。AI 能生成代码、布置场景但生成不了高质量的角色模型、动作和特效资源。你用 MCP 能摆一个白模进去但让它做一个像样的角色动作它做不到。第二类是复杂网络同步的项目。多人联机的架构设计牵扯到服务器权威、状态同步、预测补偿这些概念AI 能写出代码结构但很难替你做架构决策而且调试网络问题的过程远比本地单机玩法痛苦。让 AI 在这种复杂度下迭代反馈链路太长效率会急剧下降。第三类是大型商业项目。几十万行代码、上百个模块的系统里AI 能处理局部但很难维持全局一致性。这个阶段 AI 更适合做副驾驶而不是主驾驶人的架构把控依然是核心。6.3 举一反三这套思路不限于 Unity最后想多说一句Claude Code MCP 这套模式的思路其实完全可以平移到其他领域。核心是找到那个让 AI 能作用于真实环境的中间层就能在更多场景里复制类似的效率提升。比如数据处理领域可以让 AI 通过 MCP 连接数据库直接查询表结构、执行数据清洗脚本、看运行结果Web 开发领域可以让 AI 通过 MCP 操作浏览器调试工具实时查看页面渲染效果而不只是改代码文件。这种AI 生成内容 协议连接工具 即时反馈迭代的三段式才是这套实践留给我的最大收获而不是某个具体的游戏 Demo。回到游戏本身现在这个项目文件夹已经不再是空的了里面有完整的脚本目录、能运行的场景、基本成型的玩法。整个过程谈不上轻松但技术上的每一步都是可复现、可排查的。如果你也想试试这套流程我给的建议只有一条先从一个你完全想明白了玩法的小游戏开始别怕报错把报错原样交给 AI把即时反馈这四个字刻进操作习惯你会发现这套组合比想象中靠谱得多。