企业官网建设流程全解析

1. 为什么我会用“空文件夹”当起点

先说结论：这个项目本质上不是“写游戏”，而是“验证一套自动化开发流程能不能跑通”。

事情起因是我在某次分享里看到有人用自然语言描述需求、让 AI 直接生成完整项目，我当时第一反应是不信。原因很简单，AI 写代码和 AI 从零搭出一个能运行、能交互、有画面的 Unity 工程，中间差着十万八千里。Unity 工程不仅仅是.cs脚本，还有资源管线、场景序列化、编译配置、包的依赖关系，任何一个环节断了，整个项目就是一堆无法打开的文件夹。

但好奇心挡不住。我决定自己试一次：从一个完全空白的目录开始，靠 Claude Code 配合 MCP（Model Context Protocol）工具链，看能不能真的做出一个“能玩”的 Unity 游戏。

结果很意外，不仅做出来了，而且整个过程给了我对 AI 编程工具完全不同的认知。

下面这篇文章不聊理论，只讲实操。我会把我踩过的坑、试对的路、以及对“AI 开发游戏”这件事的真实判断，全部摊开来讲。

2. 项目拆解：一个“能玩的游戏”到底需要什么

很多人对“做游戏”有误解，觉得写几个脚本、放几个方块，就算游戏了。但如果你打开任何一个 Unity 项目，会发现真正的成本根本不在一行行 C# 代码里，而在那些看不见的工程结构里。

从零构建一个 Unity 游戏，至少要解决下面几个问题：

第一，工程结构。Unity 项目必须有Assets文件夹、ProjectSettings文件夹，以及一堆 meta 文件。Assets里管资源，ProjectSettings里管项目级配置，比如渲染管线、输入系统、音频设置。没有这些，Unity 打开就是一个空壳。

第二，场景与对象。一个“能玩”的游戏至少需要一个场景（Scene），场景里要有玩家对象、摄像机、光源，可能还要有地面。Unity 的场景文件是 YAML 格式，手写 YAML 并不难，难的是让其中的每个 GUID 对得上。

第三，脚本逻辑。这一层相对简单，纯 C# 代码，AI 生成起来很顺手。包括角色控制、碰撞检测、得分逻辑、UI 显示等。

第四，编译和运行验证。这才是最残酷的一步。脚本写完了不一定能编译通过，编译通过了的场景不一定正常，运行时还可能冒出空引用、坐标异常、输入不响应等一堆问题。

我当时的策略很简单：让 Claude Code 负责所有文件的生命周期——从创建目录、写脚本、写场景配置，到调用 Unity 命令行完成编译、读取日志、再修复问题，全部通过 MCP 工具串联起来。

用一句话概括这个项目：用自然语言驱动一套自动化工具链，让它具备从零构建 Unity 工程的能力。

3. MCP 在这里到底扮演了什么角色

先解释一下 MCP。Model Context Protocol，本质上是给 AI 模型提供“读外部工具”的能力。Claude Code 本身有很强的代码生成能力，但它最大的限制是“只能聊，不能碰环境”。它看不到你有什么文件，也不知道运行结果怎么样。MCP 就是那座桥。

在我这个项目里，MCP 起到了四个具体作用：

3.1 文件系统操作：让 AI 真正“动手”

第一个 MCP 服务是文件系统操作。Claude Code 通过它可以直接创建目录、写入文本文件、读取项目状态、批量替换内容。

你可能觉得这没什么，但实际过程中的体验很不一样。过去让 AI 生成代码，你只能复制粘贴到编辑器里，然后自己手动建目录、放文件。一旦文件多了，你根本搞不清哪个该放哪。而有了文件系统 MCP，AI 自己就能完成整套工程骨架的搭建。

举一个具体例子。生成 Unity 工程时，AI 会一次性创建这样的结构：

Assets/ Scripts/ PlayerController.cs GameManager.cs Scenes/ Main.unity ProjectSettings/ ProjectVersion.txt EditorBuildSettings.asset

而且它会自动生成对应的.meta文件。这点非常重要，Unity 里每个资源都有一个带 GUID 的 meta 文件，GUID 一旦缺失或对不上，引用就会断裂。AI 在生成 meta 文件时有没有规划 GUID 对应关系，决定了这个工程能不能被 Unity 正常识别。

3.2 Bash 命令执行：让 AI 自己“编译”和“运行”

第二个 MCP 服务是 Bash 命令执行。只创建文件还不够，你得编译器跑一遍才知道代码有没有问题。

Claude Code 通过 Bash MCP 直接调用 Unity 的批处理模式。比如：

Unity -batchmode -quit -projectPath ./MyGame -executeMethod BuildScript.BuildGame

这个命令的意思是：以无人值守模式打开项目、执行指定的构建脚本、完成后自动退出。构建脚本里定义好输出平台和路径，Unity 就会把整个项目打包成可执行文件。

有了 Bash MCP，AI 就不用等你去敲命令，它自己就能循环起来：写代码 -> 编译 -> 看日志 -> 改代码 -> 再编译。这个循环能力是整个项目能成功的关键。

3.3 日志读取与错误解析：让 AI 自己“看病”

编程里最花时间的往往不是写代码，而是排查错误。AI 生成代码也一样，一次写对的概率低，但只要能看见错误日志，它就能快速修正。

我配置了日志读取 MCP 服务，Claude Code 可以读取 Unity 生成的.log文件。很多编译报错、空引用异常、场景加载失败，日志里都会给出明确的行号和原因。AI 基于这些反馈去做针对性修改，准确率会大幅提升。

3.4 工具链的编排：真正的“胶水层”

除了上面这些基础能力，我当时还额外配置了一个脚本编排服务，让 AI 可以调用一组预设的构建脚本、启动脚本和环境检查脚本。这相当于把常用操作封装成了“工具”，AI 不需要记住所有命令行参数，只需要调用工具名称即可。

打个比方。如果 MCP 是一双手，那工具编排就是给这双手配了一套完整的工具箱。手套本身只能握住东西，配上工具后，才能敲钉子、拧螺丝、切割。

没有这套 MCP 配置，Claude Code 就是一个非常聪明但困在对话框里的“军师”；配上之后，它变成了一个能自己动手、自己检查、自己返工的“实习生”。

4. 实操过程：从空文件夹到第一个可玩场景

接下来我把整个实操流程原原本本拆开讲。我会保留过程中的关键命令、文件内容，以及每次失败后的调整思路。你可以把它当成一份可以直接复现的参考。

4.1 准备环境与初始化 MCP 配置

首先你得有一台装了 Unity 的电脑，以及一个安装了 Claude Code 的开发终端。Unity 版本我用的是 2022.3 LTS，这个版本稳定，命令行支持也成熟。

然后要配置 MCP 服务。Claude Code 的 MCP 配置通常在项目目录下的配置文件中声明。我这里用的是claude_desktop_config.json类似的格式，注册了文件访问、命令执行和日志读取三个服务：

{ "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "./"] }, "bash": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-bash"] }, "unity-log": { "command": "python", "args": ["./mcp_servers/log_reader.py"] } } }

这里要特别说明一下，MCP 服务的稳定性和宿主环境关系很大。不同版本的 Node 环境、Python 环境，都可能导致服务启动失败。我建议第一步先把三个 MCP 服务单独测试一遍，确认它们能正常响应，再进 Unity 项目环节。

4.2 创建 Unity 工程骨架：让 AI 先“搭架子”

我当时的命令非常简单，就是直接问 Claude Code：

“创建一个名为 TestGame 的 Unity 项目，包含基本的三维场景，场景中有一个玩家胶囊体、一个地面、一盏平行光、一个主摄像机，玩家可以通过方向键移动。”

AI 拿到这个指令后，第一步做的就是创建工程目录和必要的配置文件。Unity 项目的识别依赖于ProjectSettings/ProjectVersion.txt，里面写明了使用的 Unity 版本。如果没有这个文件，Unity 会弹窗提示你选择一个版本。

AI 还会生成Packages/manifest.json，这个文件管理项目的包依赖。最基本的内容大概长这样：

{ "dependencies": { "com.unity.render-pipelines.universal": "14.0.8", "com.unity.ugui": "1.0.0" } }

这一步非常容易出错。版本号不对、包名拼错、依赖缺失，都会导致 Unity 打开项目时报错。我的建议是：不要盲目追求新版本，先用 Unity 默认模板中最常见的包版本。

接着是场景文件。Unity 的场景 YAML 格式不复杂，但里面每个对象的m_LocalRotation、m_LocalPosition、m_Component引用都必须正确。AI 在这时会直接生成一个带默认地形、灯光、相机和玩家的场景。

4.3 编写玩家控制脚本：最顺利的一环

C# 脚本是 AI 最擅长的部分。我让 Claude Code 生成一个简单的角色控制器，支持 WASD 和方向键移动，并让角色的朝向跟随移动方向。

当时生成的核心代码逻辑大致如下：

using UnityEngine; public class PlayerController : MonoBehaviour { public float moveSpeed = 5f; void Update() { float h = Input.GetAxis("Horizontal"); float v = Input.GetAxis("Vertical"); Vector3 move = new Vector3(h, 0f, v).normalized; transform.position += move * moveSpeed * Time.deltaTime; if (move.magnitude > 0.01f) { transform.rotation = Quaternion.LookRotation(move); } } }

就这个脚本而言，AI 一次通过。不过游戏逻辑不能只用transform.position移动，后续我让它增加了刚体碰撞检测，改用Rigidbody驱动移动，防止玩家穿透地面。

这给我们一个很重要的经验：AI 生成单文件能力确实强，但如果你不提醒它“注重物理交互”，它默认就会用最简单、最不安全的写法。所以在描述需求时，一定要把约束条件写清楚。比如“使用刚体实现移动”“碰撞后停止”这类限制性描述，能极大提升生成代码的可用度。

4.4 配置构建脚本：让 Unity 能自己打包

要让 AI 完成“从写代码到出成品”的闭环，就得给它一个构建入口。

我让 Claude Code 生成了一个BuildScript.cs，放在Assets/Editor目录下。Unity 中Editor文件夹下存放的脚本只参与编辑器阶段，不会被打进游戏里。这个脚本的意思就是通知 Unity 命令行：“你只要执行这个方法，就按指定场景、指定平台、指定输出目录打包。”

using UnityEditor; using UnityEngine; public class BuildScript { public static void BuildGame() { string[] scenes = { "Assets/Scenes/Main.unity" }; string outputPath = "Builds/TestGame.exe"; BuildPipeline.BuildPlayer(scenes, outputPath, BuildTarget.StandaloneWindows64, BuildOptions.None); } }

这个文件的价值在于：AI 可以通过 Bash MCP 调用它，实现自动化构建。每次修改代码后，AI 都能自己跑一遍构建，验证输出是否正常。

4.5 第一次构建：日志报错与修复循环

构建脚本写好之后，我让 Claude Code 自己执行构建命令。第一次构建几乎必然失败，日志里给出了好几条错误。

印象比较深的有两个：

第一个错误是场景 GUID 不匹配。AI 生成场景文件时，meta 文件里的 GUID 和场景内部引用的 GUID 对不上，Unity 无法加载场景。这时 Claude Code 读取日志后，会自动重新生成所有 meta 文件并统一 GUID 对应关系。

第二个错误是脚本编译顺序问题。某个脚本里引用了还没定义的类型，严格说不是错误，而是编译顺序造成的。Unity 是按程序集依赖顺序编译的，如果你把脚本放在Assets/Scripts，并引用了Assets/Editor下的类型，编译就会失败。这个问题的调整方式是把相关代码全部放进同一个命名空间，并让普通脚本不要引用 Editor 脚本。

修复后，我再次让 AI 构建。这次成功生成了TestGame.exe和一堆依赖文件。

4.6 运行验证：启动、控制、物理反馈

有可执行文件不是终点。我打开运行程序，发现角色移动正常、碰撞正常，但有几个体验上的问题：移动速度太快，相机视角固定看着不太舒服，退出时没有交互反馈。

我通过文字告诉 Claude Code：“在 TestGame 中，角色移动速度设置成 3，让摄像机用一个平滑跟随脚本，增加 ESC 键退出游戏的逻辑。” AI 随即修改对应脚本、重新构建、再次打包。

整个过程大概重复了三轮，最终版达到了我认为“能玩”的标准。整个过程从空文件夹到可玩版本，大约花了两个小时，其中一半时间都在等编译。

5. 避坑指南：AI 开发 Unity 的五个真实教训

这部分是我最想写的，因为我踩过的坑比 AI 修过的错还多。

5.1 不要给模糊需求

AI 生成代码的能力强，但思维能力其实是“单线程的”。你说“做个简单的移动”，它可能给你一个没有物理碰撞的平移方案。说“让场景好看一点”，它可能只会给你调一下光源颜色。

我的教训是：需求描述必须具体到“参数级别”。比如“角色用胶囊体碰撞器，刚体质量 1，移动速度 3，按空格键起跳，跳跃高度 1.2”。AI 对具体描述的执行力，远超模糊描述。

5.2 场景生成是重灾区

AI 写脚本很快，但生成场景文件是另一个复杂度级别。手写 Unity 场景 YAML 难度不大，但要保证所有引用一致，就需要 AI 有非常强的上下文能力。

我的建议是：尽量让 AI 生成脚本逻辑，而场景文件用 Unity 编辑器手动搭。或者，让 AI 生成一个最简单的场景骨架，再在 Unity 里手动补地面、光源和装饰物。这样可以大幅减少由于场景引用错误而导致的加载失败。

5.3 Unity 版本和包管理是隐性炸弹

AI 不知道你本地的 Unity 版本，它只从对话中判断项目需求。如果你没告诉它版本，它可能会默认用最新版，这会造成两种问题：一是项目无法用你本地的 Unity 版本打开，二是某些包版本在你的版本里不存在。

我的做法是，在项目开始前，先把下面这些信息写进对话上下文：

• Unity 版本号，比如 2022.3.20f1
• 渲染管线，比如 URP
• 目标平台，比如 Windows 64 位
• 项目目录绝对路径

5.4 MCP 服务不是越多越好

我一开始配置了六七个 MCP 服务，有数据库读取、图像处理、网页搜索等等。结果 Claude Code 的响应变慢，而且很多服务根本用不上。

最终我只保留了三个：文件系统、Bash、日志。工具越精简，AI 越容易聚焦，出错概率也越低。

5.5 一定保留“人工审批”环节

AI 能自动改文件、自动敲命令，这很爽。但你必须留一道人工确认的闸门。特别是在删除文件、覆盖场景、执行构建命令时，我始终保留了“确认后执行”的模式。

原因很简单：AI 没有语义判断能力。它可能会在修改 bug 时，顺手把好的配置也重置了。我在一次构建过程中就碰到过，AI 为了解决玩家碰撞问题，把整个场景里的所有碰撞器都删掉了。这要是没有人工干预，我根本不会发现场景已经被悄悄改空了。

6. 经验和技巧：如何让 AI 真正“干活”而不是“生成代码”

如果你准备用 Claude Code + MCP 走一遍类似流程，下面这几个技巧会大概率帮你避开弯路。

6.1 一次只做一件事

AI 的多任务并行能力其实很弱。你让它“生成一个项目，顺便添加跳跃功能，再优化一下摄像机”，结果大概率是每个功能都做得很粗糙。

我推荐的分步方式是：

• 第一步：搭建完整工程结构，什么功能都不要加
• 第二步：让 AI 做玩家移动，编译通过后再继续
• 第三步：添加交互物品，比如金币或障碍物
• 第四步：加入 UI 和游戏状态
• 第五步：整体测试、修复

这种方式的优势在于：每次只引入一个变量，出了问题能立刻知道是哪个功能导致的。

6.2 写“验收标准”给 AI

就像你给实习生布置任务一样，要告诉 AI“做成什么样才算好”。我通常会在需求里附加验收条件，比如：

• “场景中至少包含 3 个障碍物，碰撞后玩家退回起点”
• “得分 UI 在左上角，字体大小为 24”
• “构建成功后，可执行文件大小不超过 200MB”

AI 看到这种约束条件，生成的代码质量会明显提升。

6.3 让 AI 自己解释每一步

Claude Code 有一个特点，它在执行完文件写入和命令返回后，会自动总结它做了什么。我强烈建议你要求它把每个步骤的逻辑写清楚，而不仅仅是给出最终状态。

比如它会输出：

“我已创建 PlayerController.cs，并在 Start 方法中获取 Rigidbody 引用。移动逻辑放在 FixedUpdate 中，这样可以保持物理同步。下一步准备构建项目验证。”

这种习惯让你能一眼看出 AI 的理解和你的预期是否一致。不一致就立刻打断，而不是等它全部做完再返工。

6.4 利用构建日志建立“反馈闭环”

我这次项目能成功的最大功臣，不是 AI 的代码生成能力，而是那套循环：构建 -> 出日志 -> AI 读日志 -> 改代码。

你不一定需要复杂的日志读取服务，最简单的做法是：构建完成后，让 Claude Code 用 Bash 执行类似cat Editor.log，然后把日志内容直接喂回给它。这样它就能基于真实报错来修正代码。这比让 AI 从零推导正确代码，可靠性高一倍都不止。

7. 聊聊我对“AI 开发游戏”这件事的真实看法

说实话，这个项目做完之后，我反而更清醒了。

AI 确实很强，但它的强，是“快”，不是“懂”。

你让它生成 1000 行移动代码，它能瞬间完成；你让它理解游戏手感、玩家预期、关卡节奏这些要靠审美和经验的东西，它完全无能为力。游戏开发真正的门槛，永远不在于“能不能把代码写出来”，而在于“写出来的东西有没有人愿意玩”。

Claude Code 加 MCP 的真正价值，不在于替代开发者，而在于把开发者的执行时间压缩到极致。以前一个原型要写三天，现在一个下午就能跑起来。剩下的时间全被释放给了玩法设计和体验打磨。

我个人的体会是：AI 工具越强，人反而越要回归“游戏设计师”的角色，而不是变成执行者。你花在描述需求上的思考，最终决定了 AI 产出的下限。如果你连自己要什么都不知道，AI 给你的只会是一堆“标准答案”拼起来的平庸品。

最后分享一个我后来一直在用的小技巧。当我需要让 Claude Code 完成一套复杂任务时，我会先让它输出一份完整的“任务清单”，包括每一步的文件路径、预期效果、验证方法。确认无误后，再让它开始执行。这个习惯让我省下了至少一半的无用劳动。希望这个经验也能帮你少走几步弯路。