企业官网建设流程全解析

这篇聊点实操的。

上一个系列篇我讲过怎么把 unity-mcp 跑起来，也聊过 MCP 协议的基本概念。但很多朋友真正卡住的地方不是安装，而是“装完之后用不起来”——AI 能连上编辑器，但不知道怎么让它准确地帮你改东西。这篇是第二篇，我不重复环境安装，重点分享我实际用 unity-mcp 配合 Claude Code 和 Trae 做 Unity 开发时的完整工作流、踩过的坑，以及最终沉淀下来的一套可复用方法。适合已经了解 AI 编程助手基础操作、准备在真实 Unity 项目里跑一遍的朋友，也适合那些刚跑通 MCP 连接、但对后续使用方向还比较模糊的同学。

先说个结论：这组合不是让你彻底不写代码的，是让你把“找资源、查层级、改参数、补脚本、修报错”这类重复劳动交给 AI，把精力留在设计方案和关键逻辑上。这套东西能不能用，主要取决于你多会用 AI 的工具调用能力，以及你多敢让它去改你的项目。

1. 先梳理整体工作流：AI 辅助 Unity 开发到底怎么跑起来

1.1 组件定位：unity-mcp 提供什么，AI 助手如何使用它

MCP（Model Context Protocol）本质上是一个协议桥梁，它让 AI 模型能够调用外部工具。unity-mcp 做的就是把这个协议的另一头接到 Unity 编辑器上：它注册了一系列 Unity 编辑器操作工具，比如获取当前场景层级、搜索资源、创建 GameObject、添加组件、修改属性、执行编辑器菜单命令等。

AI 助手侧，Claude Code 和 Trae 都是 MCP 的客户端，它们能识别并调用服务端暴露的这些工具。你给 AI 发一句“在场景里创建一个 Cube，颜色改成红色”，AI 不会自己凭空知道流程，它会先调用 unity-mcp 提供的find_object找到合适的位置，再调用create_object创建一个物体，接着查找 MeshRenderer 组件并设置材质颜色。整个过程就像你给 AI 装了一双手，能直接操作 Unity 编辑器。

Claude Code 是一个运行在终端里的编程代理，适合接收指令后批量执行复杂任务，比如“找出所有挂在 Player 对象下的脚本，检查哪些方法没有被调用”。Trae 则更像一个集成了 AI 对话的 IDE，你能直接看到代码文件、场景结构和编辑器输出，适合边改边确认。两者各有侧重，但都基于同一套 MCP 协议，所以可以共用同一个 unity-mcp 服务。

1.2 为什么选择 Claude Code 与 Trae 并存

很多教程会劝你别一次装两个 AI 编程工具，用习惯一个就好。但我的实际体验恰恰相反，在 Unity 开发场景里，两个一起用反而更顺。

原因不复杂。Unity 编辑器不是一个纯文本项目，它除了 C# 脚本，还有场景文件、Prefab、材质、动画器等二进制资源。Claude Code 适合直接处理代码文件和跑自动化命令，但它在“看到编辑器当前画面”这件事上比较弱。Trae 是 IDE，能展示文件树和打开的文件，但真要让它执行一个 Unity 编辑器菜单命令，它也还是要通过 MCP 工具走一遍。所以我把工作流拆开了：

• 日常开发：Trae 负责对话式修改，比如“这个 UI 按钮帮我再加一层渐变遮罩”，我能一边看着脚本结构一边确认改动。
• 批量操作：Claude Code 负责执行重复性高的任务，比如“把所有带‘（临时）’后缀的材质找出来，批量移除”，它更适合长命令和脚本化操作。
• 调试和复盘：Claude Code 能直接在终端跑测试命令、看完整报错栈，拿它查代码逻辑比在 IDE 里复制粘贴更高效。

这套分工没有绝对边界，但实际用下来确实让 AI 的介入面更清晰。你不需要跟纠结点“哪个工具更聪明”，只需要把它俩当成两个入口，接入同一个 unity-mcp 服务，各自做擅长的活。

1.3 我实际采用的分工方式

我自己的小项目通常会开两个终端窗口，一个跑 Trae、一个跑 Claude Code，两个都指向同一个 unity-mcp 服务。启动顺序是这样的：先打开 Unity 工程和目标场景，确认 unity-mcp 服务已经开始监听；再启动 Claude Code 或 Trae，加载同一个 MCP 配置；最后通过一句“读取当前场景的层级结构”来验证连接。

之所以先验证连接，是因为工具连接好后，接下来所有的 AI 指令都会依赖这个通道。如果这一步是断的，后边你让 AI 做的所有操作都只会得到“工具未配置”或者“连接失败”的错误。

这样分工还有一个好处：同一个项目里，你可以让 Claude Code 处理一个任务，同时用 Trae 处理另一个任务，只要 Unity 编辑器能承受住频繁的 API 调用就行。实测下来，项目不大、操作不频繁的情况下不会冲突，但如果同时发起大量资源扫描，编辑器帧率会掉，最好错开时间做。

2. 环境搭建要点：别让配置环节卡住后面所有流程

2.1 安装并启动 unity-mcp 服务

先不讨论怎么从头写一个 MCP 服务，实际使用的时候，直接找项目现成的 release 包或者源码编译会更省心。我采用的是源码方式，流程大致是：克隆仓库、安装 Python 依赖、用配置文件指定 Unity 可执行文件路径和项目路径，然后运行启动命令。

这里有一个特别容易踩坑的地方：unity-mcp 服务默认绑定本地端口，你需要提前确定端口号，并且在 Unity 编辑器里安装并启用配套的 MCP 编辑器扩展。如果没有启用扩展，外部工具只能拿到项目文件信息，但无法执行创建、修改层级等操作。

配置完成后，启动命令通常是一条 Python 指令，比如：

python main.py --unity-port 8888 --project E:/UnityProjects/MyDemo

命令行参数不是固定的，不同版本差异比较大，建议先看仓库 README 里推荐的启动方式。启动成功之后，大概能看到类似“MCP server is running on port 8888”的日志。

2.2 在 Claude Code 中注册 MCP 服务

Claude Code 连接 MCP 服务是通过配置文件或交互式命令来设置的。如果你想在项目本地使用，可以在项目根目录创建一个配置文件，把 MCP 服务地址和协议模型写进去。常见格式是：

{ "mcpServers": { "unity-mcp": { "command": "python", "args": ["main.py", "--port", "8888", "--project", "E:/UnityProjects/MyDemo"], "env": {} } } }

如果配置正确，启动 Claude Code 时会自动加载这个服务，你可以在对话里请求“列出当前可用的 MCP 工具”，它会返回一长串工具清单，比如get_scene_hierarchy、find_object、create_object、add_component等。

这里有个细节：Claude Code 需要你主动允许它使用工具。首次执行一个工具调用时，它会弹确认请求，我建议不要全选“总是允许”，至少在项目初始阶段保留部分确认，等你对 AI 的每一步操作有把握了再放宽权限。

2.3 在 Trae 中启用 MCP

Trae 的 MCP 配置入口一般在 IDE 的设置界面里，你可以新增一个 MCP Server，类型选择配置命令或服务地址。如果启动 unity-mcp 时用的是标准输入输出通信模式，就把启动命令填进去；如果是网络模式，就填http://127.0.0.1:8888这样的地址。

配置好之后，Trae 的对话框里会出现一枚“MCP 工具”标识，点击可以看到当前可用的工具列表。你可以单独设置哪些工具允许 AI 调用，哪些不调用。我建议一开始只允许一些只读操作，比如搜索资源、获取层级、查看组件属性，把创建、删除、修改属性的权限先关掉。等 AI 的理解和你的约束都稳定后，再逐步放开。

2.4 验证连接：让 AI 获取一次场景层级

环境配置好之后，最关键的一步就是验证。我常用的测试指令是：“请调用 get_scene_hierarchy 工具，把当前场景的完整层级结构列出来。”如果返回了层级树，说明 unity-mcp 到编辑器的链路是通的。

如果这一步失败，优先检查三件事：第一，unity-mcp 服务是否还在后台运行，可以通过端口状态确认；第二，Unity 编辑器是否处于可交互状态，比如正在播放模式下有些 MCP 操作会被限制；第三，是不是防火墙策略拦住了端口。

实测过程中最常见的问题其实就是端口没对上，比如服务监听 8888，但客户端配置里写的 9999。还有一个隐患是 Unity 版本和 MCP 扩展版本兼容性问题，通常把两者都升级到最新就能解决。

3. 四个高频开发场景实测：从需求到落地的完整路径

3.1 场景一：让 AI 按需求创建 C# 脚本并挂载到物体

这是我的第一个实际测试场景：希望 AI 帮我创建一个名为PlayerController.cs的脚本，实现 WASD 控制物体移动，然后挂到场景里的 Player 物体上。

操作指令很简单：“在 Assets/Scripts 下创建 PlayerController 脚本，实现简单角色移动，使用 Input 系统，然后挂到 Player 物体上。”AI 会先调用 unity-mcp 工具创建并写入脚本文件，再去场景中定位 Player 物体，调用add_component把新脚本挂上去。

实际操作中，问题往往出在 AI 生成的脚本里。比如它可能会写一个需要CharacterController组件的方法，但场景物体上并没有加这个组件；或者它默认使用新的 Input System 包，而项目里用的还是旧版 API。我的对策是：要求 AI 先确认项目用的 Input 版本，再生成代码。更稳妥的写法是让 AI 先生成脚本，用 C# Compiler 工具先做一次编译检查，然后再挂载。

这里你可以要求 AI 调用“编译检查”工具，它会把编译错误返回到对话流里。实测下来，这一步能拦截大部分语法错误。如果再有一些历史包袱导致的 API 兼容问题，就得靠你自己的项目知识来补充约束了。

3.2 场景二：AI 修改场景层级与组件属性

第二个场景是修改 UI 层级。我给它下达了“在 Canvas 下创建一个按钮，显示文本‘开始游戏’，再把按钮的位置调整到屏幕中央下方”。这个任务听起来简单，但对 MCP 工具调用来说涉及了不少步骤：

• 找到 Canvas 物体并确认它的 Render Mode；
• 创建 UI 按钮，设置名字；
• 找到下层的 Text 子物体，修改显示文本；
• 设置 RectTransform 的 anchor 和 position。

AI 在第一次执行的时候，很可能把按钮建在了场景根节点而不是 Canvas 下，因为create_object的默认父级是场景根节点。遇到这种情况，我不会频繁手动纠正，而是直接要求 AI“先调用 find_object 获取 Canvas 的路径，再把新建对象挂到 Canvas 下”。经过一两次反馈，AI 就能记住这个约束。

我还发现，AI 对 RectTransform 的值特别容易“自创”，比如设置了一个 Unity 里并不存在的属性。我的建议是，在提示词里写清楚“使用 RectTransform 的 anchoredPosition”而不是“Position”，并且在 AI 完成后让它重新读取按钮的 RectTransform 属性确认结果。

3.3 场景三：批量资源整理与重命名

批量操作是 MCP 的强项。我试过让 AI 处理一个目录下所有带“（1）”后缀的贴图，要求它重命名并把对应材质更新为新贴图。

传统做法下，这个操作少说要几分钟手工操作，而 AI 通过调用资源搜索工具找到所有目标文件，再用脚本批量重命名，最后逐个把材质引用指向新文件。它只花了不到二十秒。

但这里必须提醒一点：批量操作属于高破坏性操作。AI 一旦对文件名判断出错，就可能影响一堆材质。我曾遇到它把图片文件名里的“（1）”误判为需要保留的字符，结果重命名后所有引用都丢了。

所以，涉及到批量修改和重命名时，我强烈建议你提前要求 AI “先输出修改清单，经我确认后再执行”。你可以在对话中明确加一句“先 dry-run，不要真正执行修改”。很多工具能力是支持“只计算不改动”的，你要善于利用这一点。

3.4 场景四：利用 AI 解读报错与修复运行时错误

项目运行时不可避免地会出现 NullReferenceException 这类报错。过去，我的排查流程是看日志、定位代码、猜原因、再跑一次。现在我可以直接把报错日志粘贴给 Claude Code，让它结合场景层级和代码文件来判断是哪个对象没初始化。

例如，报错日志说PlayerController.Update()里_audioSource为空。AI 会先读取 PlayerController 的代码，查看静态分析结果，然后通过 MCP 找到场景里的 Player 物体，确认它是否挂载了 AudioSource 组件。如果没有，它就会提出修改方案：要么在 Awake 里自动添加组件，要么在Start()里加一个空判断。

这种方式最大的收窄效果是：你不需要自己反复切换编辑器去看代码、查物体，AI 会代替你完成大部分“追踪”工作。但也要小心，如果 AI 在运行时直接调用UnityEditor.EditorApplication.isPlaying = true来再次运行项目，可能造成编辑器不稳定。我一般的做法是，让 AI 修改代码，再由我手动进入 Play 模式验证。

4. 常见问题排查：连接失败、误操作、上下文失控

4.1 MCP Server 无法启动

实战中，MCP Server 无法启动是最常见的，也是最让人恼火的问题。我总结过一张排查表，能覆盖大部分情况：

还有一个坑：某些版本需要在 Unity 里手动点击“Start MCP Server”，而不是只在命令行启动。如果你发现外部能连上端口但工具调用一直返回空，就去编辑器菜单里找找有没有启动按钮。

4.2 AI 操作了错误的物体或资源

AI 对“场景中名为 Player 的对象”的理解，可能与你的预期完全不同。比如场景里有多个名称含 Player 的对象，AI 可能选择了第一个。这个问题的根源在于 AI 在自然语言和场景对象之间做映射时缺乏空间理解，它很难感知哪个 Player 是你想操作的那个。

我的规避手段有三种：

• 在提到对象时，同时提供父路径，比如“Canvas/StartButton”，降低歧义；
• 使用唯一 ID 或名称约束，比如“查找名字完全等于 Player_Prefab_01 的对象”；
• 操作执行后，让 AI 回读它操作后的对象属性，确认结果。

我还会给项目里的重要物体加一个命名前缀，比如_START_、_PLAYER_，这样 AI 在搜索场景时更容易命中目标。

4.3 上下文溢出与记忆缺失

长时间会话之后，AI 经常会“忘记”你一开始约定的命名规范或项目结构。这不是模型能力不够，而是上下文窗口有限，又被中间几轮无关对话挤占了。

我的解决方式是把项目规则固化到一个项目说明文件里，然后在每轮开始时提醒 AI “先读取 CLAUDE.md 再操作”。这个文件里写清楚：

• Unity 版本和 Input 系统版本；
• 脚本目录结构；
• 命名规范；
• 常用 API 的写法示例；
• 哪些 MCP 工具允许用、哪些不允许。

这样 AI 即使忘了前面的话，也能从文件里重新拿到上下文。实测效果明显，至少能减少一半“AI 突然把命名风格搞得乱七八糟”的情况。

4.4 AI 生成的 C# 不能编译

AI 生成的 C# 脚本不能编译，几乎是可以预见的。常见原因有：Unity API 版本不对、漏掉了命名空间引用、脚本文件名和类名不匹配、以及非 ASCII 路径引起的编码问题。

我在实际项目里总结了一个“AI 生成脚本三原则”：

• 要求 AI 在生成脚本后立即调用编译检查工具；
• 如果项目使用中文路径，让 AI 在代码里避免直接硬编码中文路径；
• 每个生成的脚本文件名必须与类名保持一致，这是 AI 最容易忽视的地方。

如果编译错误集中出现，我会把报错全文贴回对话，让 AI 先不要改动代码，而是先解释报错原因，再给出修改方案，这样能在一定程度上避免它盲目乱改。

5. 让这套流程稳定运行的进阶习惯

5.1 用 CLAUDE.md 固化项目规范

前面提过 CLAUDE.md 的重要，但它的价值不止于防遗忘。我后来把项目里“AI 能碰目录”“AI 不能碰目录”也写进去了。这样即使 AI 在执行批量操作时，也会自动过滤掉某些目录，降低破坏风险。

示例内容可以很简单：

# Project Rules - Unity 2022.3 LTS - 使用 old Input Manager，不要用 Input System - 所有新增脚本放在 Assets/Scripts/Game - 禁止修改 Assets/Plugins 下的文件 - 场景主物体的命名必须带有前缀 - 生成脚本后必须执行编译检查

这些约束比我每次对话重复一遍要稳定得多。只要你在新会话开始时，第一句话是“请先读取 CLAUDE.md”，AI 就会按这些规矩来。

5.2 让 AI 自主执行“小任务闭环”

所谓小任务闭环，是指把一次需求从“理解”到“完成并验证”的完整链路交给 AI。我经常会给 AI 下达这种指令：

“在 Assets/Scripts/AI 下创建一个 ScoreManager.cs，包含增加分数、读取分数、重置分数三个方法，然后挂到一个新建的 ScoreManagerObject 上，最后运行编译检查并返回结果。”

这整个流程 AI 是可以完整做下来的。它需要调用创建文件工具、创建对象工具、挂载组件工具、编译检查工具。我只需要最后扫一眼结果，而不是一步一步地提醒。这个过程一旦稳定，就可以节省大量做“脚手架”的时间。

不过我仍然建议在项目里保留一个“人工复查点”，比如 AI 完成创建后，你先打开脚本快速看一遍。不要完全信任它，因为 AI 对项目业务逻辑的理解始终有限。

5.3 项目备份与回滚策略

AI 操作越“全能”，风险也越大。批量修改资源、批量移动文件，一旦出错，可能比手工操作更容易造成大范围破坏。我在使用 AI 操作 Unity 工程前，会确认 git 状态是干净的，然后让 AI 在执行关键操作前先提交一次代码快照。

最简单的做法是在对话里加一句：“在执行任何修改之前，先帮我执行 git add . 和 git commit。”这样如果 AI 操作出问题，我可以回退到上一个提交点。对于场景文件这类不可读的二进制资源，版本控制同样能救回误改的层级。

如果你不熟悉 git 命令，也可以在 Unity 编辑器里手动备份整个项目目录，但项目大一点就别手动复制了，慢且容易漏文件。用 git 反而更快。

5.4 复杂任务拆分与控制风险

最后一点经验是：不要一次给 AI 太多任务。比如“帮我做角色移动、再做个跳跃、加个 UI 血条、再加个敌人 AI”，这种大杂烩式任务，AI 会很快失去主线，操作容易跑偏。

我的方式是拆成一个最小任务单元，每个单元只涉及一个明确目标。比如先让 AI 创建 PlayerController，验证编译通过，再让 AI 添加跳跃逻辑，再验证一次。每完成一个单元，就检查一次项目状态，然后进入下一个单元。

这种节奏一开始可能让人觉得“太保守”，但我实测下来，返工率大幅下降。尤其是 AI 能直接操作编辑器后，一旦操作错了物体，排查和修复的成本比手动改高代码还高。

结尾

讲到现在，我回想这套 unity-mcp 配合 Claude Code 和 Trae 的组合，真正给我带来的最大改变不是“不用写代码了”，而是我可以把更多注意力放到玩法设计和整体体验上，不用再频繁切换编辑器去改 GameObject、查资源路径、重复挂组件。

最后再分享一个小技巧：如果你刚接好 MCP 服务，不知道从哪开始试，先别急着让 AI 做复杂功能。给它一个简单的日常任务，比如“找到场景里所有名字包含Gold的物体，把它们的Tag改成Pickup”，让 AI 跑一遍。这样既能验证全链路是否通顺，也能借机观察它对工具的使用习惯。等它摸清套路后，再做真正的功能开发，你会明显感觉到“它已经知道在我们的项目里要怎么下手里”。

这套流程我每天都在用，每次把日常琐事交给 AI 时，依然会觉得挺值的。希望这篇记录能帮你少走一点弯路。