这是欧米的第433篇游戏开发原创分享。

点击关注↑ 解锁价值百万的「灵感生产线」

前面几篇，我们一直在讲 AI 开发游戏之前要先做什么。

先拆需求。再拆模块。再把模块边界说清楚。

到这一步，再让 AI 开始写具体代码，就会稳一些。

但接下来还有一个问题：AI 写 Unity 代码确实快，却不代表它写出来的东西一定能直接放进你的项目里。

尤其是 Unity 这种开发环境，很多问题不是语法错，而是项目里的运行方式、对象引用、生命周期、组件挂载、场景结构没对上。

AI 写一段 C# 方法可能没问题。但 Unity 代码经常不是一段孤立方法。

它可能要挂在某个 GameObject 上。要引用 Inspector 里的对象。要区分运行时对象和资源文件。要知道什么时候初始化，什么时候销毁。还要和场景、Prefab、动画、UI、协程、事件系统配合。

这些地方一旦没说清楚，AI 就很容易写出那种“单独看没问题，放进项目里就不对”的代码。

最常见的问题：它不知道你的场景长什么样

AI 写 Unity 代码时，最大的问题之一，就是它并不知道你的场景结构。

你说：

“帮我写一个建塔功能。”

它可能会生成：

public GameObject towerPrefab;voidBuildTower(Vector3 position){    Instantiate(towerPrefab, position, Quaternion.identity);}

这段代码本身没错。

但项目里真正的问题可能是：

塔是不是只能建在格子上？格子有没有被占用？建塔要不要扣金币？建塔位置是世界坐标，还是 Tilemap 坐标？塔要不要放到 TowerRoot 节点下面？建完塔后 UI 要不要刷新？建塔失败时要不要提示？

这些东西 AI 如果不知道，就只能写一个最简单的版本。

所以 AI 写 Unity 代码出错，很多时候不是它不会写 Instantiate，而是它不知道这个对象应该放在哪里、怎么来的、和谁关联。

比如更接近项目实际的任务，应该写成这样：

请实现建塔逻辑，但不要只 Instantiate。已有结构：- TilemapBuildArea：负责可建造格子- BattleState：负责金币- TowerRoot：所有塔的父节点- TowerData：塔配置，包含 buildCost 和 prefabPath要求：1. 点击格子时，先判断是否可建造。2. 判断该格子是否已有塔。3. 判断金币是否足够。4. 扣除金币后，从 TowerData 加载塔 Prefab。5. 生成塔后挂到 TowerRoot 下。6. 记录该格子已被占用。7. 刷新金币 UI。

同样是建塔，这个任务就比“帮我写建塔功能”靠谱很多。

因为它把场景、数据、规则和对象关系都说清楚了。

生命周期很容易写错

Unity 代码里还有一个很常见的问题：生命周期。

AI 很容易写出能编译的代码，但它未必放在合适的生命周期里。

比如它可能在 Start() 里找对象：

voidStart(){    enemyManager = FindObjectOfType<EnemyManager>();    ui = FindObjectOfType<BattleUI>();}

这在小 Demo 里经常能跑。

但项目稍微复杂一点，就容易出问题。

有些对象可能是异步加载的。有些 UI 可能是进入战斗后才打开的。有些管理器可能跨场景存在。有些 Prefab 是运行时生成的。有些数据要等配置加载完成后才能初始化。

如果 AI 不知道这些，它就会按最普通的 Unity 写法来。

这时候你会看到很多熟悉的东西：

FindObjectOfType / FindFirstObjectByTypeGameObject.FindCamera.mainGetComponentStartUpdate

这些 API 不是不能用。

但如果 AI 在一段代码里到处 Find，到处自动找对象，通常说明它对你的项目结构不了解。

更好的做法是先告诉它：

不要使用 FindObjectOfType 和 GameObject.Find。本项目通过 BattleContext 在初始化时传入依赖。请把 EnemyManager、BattleState、BattleUI 都作为 Init() 参数传入。

然后让它按这个方式写：

publicclassBuildSystem{private BattleState battleState;private TowerFactory towerFactory;private BattleUI battleUI;publicvoidInit(BattleState battleState, TowerFactory towerFactory, BattleUI battleUI)    {this.battleState = battleState;this.towerFactory = towerFactory;this.battleUI = battleUI;    }}

这不一定是所有项目唯一正确的写法。但至少要让 AI 知道，你的对象是手动绑定、初始化传入，还是运行时查找。

Unity 代码最怕的不是多几行，而是对象关系不清楚。

AI经常分不清“资源”和“实例”

这也是 Unity 里很容易出问题的地方。

比如你让 AI 写一个塔配置，它可能会写：

publicclassTowerData{publicstring towerName;publicint damage;public GameObject towerObject;}

看起来没什么问题。

但这里就要想清楚：towerObject 到底是什么？

它是 Prefab 资源？是场景里已经生成出来的塔？是当前选中的塔实例？还是某个运行时对象的引用？

Unity 里资源和实例是两回事。

Prefab 是资源。场景里的塔是实例。ScriptableObject 是配置。运行时状态是实例上的数据。

AI 很容易把这些混在一起。

比如它可能在 TowerData 里记录当前血量、当前等级、当前目标。这就不太合适。

更稳的拆法是：

TowerData：静态配置- towerId- name- baseDamage- attackRange- attackInterval- prefab 或 prefabPathTowerInstance：运行时状态- currentLevel- currentTarget- currentCooldown- gridPosition

也就是说：

配置负责“这座塔本来是什么”。实例负责“这座塔现在是什么状态”。

如果你不提前说明，AI 很容易把配置和运行时状态写在一起。

短期看没事，后面做存档、升级、关卡编辑、数值表导入时就会很麻烦。

Update 里不要什么都塞

AI 写 Unity 代码时，很喜欢用 Update()。

比如敌人移动、塔索敌、子弹飞行、UI 刷新、胜负判断，全都放进 Update()。

这在早期 Demo 里很常见。

比如：

voidUpdate(){    MoveEnemy();    FindTarget();    FireBullet();    CheckWin();    RefreshUI();}

这个写法不是绝对不能用。

但如果你不管，很快就会变成每个脚本都在 Update() 里做很多事。

塔每帧找目标。UI 每帧刷新金币。波次每帧检查敌人数量。敌人每帧找路径点。子弹每帧查找目标是否还活着。

小规模没问题，东西一多就不好查，也不好优化。

更重要的是，AI 会把很多“不需要每帧做”的事情，也写进 Update()。

比如金币 UI，只有金币变化时刷新就行。塔升级 UI，只有选中塔或升级时刷新就行。胜负判断，也可以在敌人死亡、波次结束、基地扣血时触发。

所以你可以明确告诉 AI：

不要在 Update 中刷新 UI。金币变化通过 BattleState.OnGoldChanged 事件通知 UI。胜负判断只在波次结束、敌人死亡、基地扣血时触发。

这类限制很重要。

不是所有逻辑都不能进 Update()。敌人移动、子弹飞行这种每帧变化的东西当然可以放进去。

但不要让 AI 把所有东西都塞进去。

协程和异步逻辑容易写得很随意

Unity 里很多功能会用协程。

刷怪。延迟伤害。技能冷却。动画等待。UI 淡入淡出。关卡结算延迟。

AI 很容易写出这种代码：

IEnumerator SpawnWave(){for (int i = 0; i < enemyCount; i++)    {        SpawnEnemy();yield return new WaitForSeconds(1f);    }}

这段本身没问题。

但真正项目里，你还要考虑：

关卡暂停时怎么办？游戏失败后协程是否停止？切换场景时协程还会不会继续？敌人生成中途是否允许跳过？波次是否需要等待上一波清完？WaitForSeconds 是否受 Time.timeScale 影响？

AI 如果不知道这些，它通常会写一个最简单的协程。

刚开始能跑，后面状态一复杂就会出现问题。

所以涉及协程时，任务单里最好写清楚生命周期。

比如：

请实现 WaveSpawner 的刷怪协程。要求：1. 游戏暂停时不继续刷怪，明确暂停是通过 timeScale 还是战斗状态字段控制。2. 战斗结束后停止所有刷怪协程。3. 每波刷完后，等待场上敌人清空，再进入下一波。4. 不要在协程里直接判断胜负，把波次完成事件发给 BattleFlow。

协程不是不能用，但最好有明确的开始、停止和状态控制。

事件绑定和解绑经常漏掉

AI 写 Unity 代码时，还有一个很容易漏的地方：事件解绑。

比如它会写：

voidOnEnable(){    battleState.OnGoldChanged += RefreshGold;}

但不一定会写：

voidOnDisable(){    battleState.OnGoldChanged -= RefreshGold;}

如果订阅写在 OnEnable()，也要确认依赖对象已经在 Awake() 或初始化阶段准备好。不然 OnEnable() 先执行，battleState 还没赋值，也会直接出问题。

这在 UI、战斗事件、输入系统里都很常见。

一开始可能没问题。

但如果这个 UI 会反复打开关闭，或者战斗场景会反复进入退出，就容易出现：

重复刷新。空引用。旧对象还在响应事件。一个按钮点一次，逻辑执行两次。

这些问题都很烦，因为它们不一定马上报错。

所以让 AI 写事件相关代码时，最好明确写：

如果有事件订阅，必须在 OnDisable 或 Dispose 中解绑。不要只写订阅，不写解绑。如果在 OnEnable 里订阅，要确认依赖对象已经初始化完成。

这句话很简单，但很有用。

尤其是 UI 和战斗系统里，事件绑定和解绑要成对出现。

AI容易把编辑器代码和运行时代码混在一起

Unity 还有一个特殊点：有些代码只能在编辑器里跑。

比如：

UnityEditor.AssetDatabaseEditorUtilityMenuItemCustomEditorPrefabUtility

这些东西如果写进运行时代码，打包时就会出问题。

AI 有时候会为了方便，直接用 AssetDatabase.LoadAssetAtPath 加载资源：

var prefab = AssetDatabase.LoadAssetAtPath<GameObject>("Assets/Prefabs/Tower.prefab");

在编辑器里可能能跑。

但一打包就不对了。

因为 AssetDatabase 属于 UnityEditor 命名空间，不能用于最终运行时。

正确做法要看你的项目资源管理方式。

可能是 Inspector 直接引用。可能是 Resources.Load。可能是 Addressables。可能是 AssetBundle。可能是自己的资源加载管理器。

所以你一定要告诉 AI：

这是运行时代码，不允许使用 UnityEditor、AssetDatabase、EditorUtility。资源加载统一通过 ResourceManager.LoadPrefab(path)。

如果是编辑器工具，也要反过来说清楚：

这是 Editor 工具代码，请放在 Editor 文件夹下，可以使用 UnityEditor API。

Unity 里“能在编辑器里跑”和“能打包后跑”不是一回事。

AI 很容易忽略这一点。

Inspector引用和代码生成要对得上

AI 生成脚本时，经常会写很多字段：

public Button startButton;public Text goldText; // 或 TextMeshProUGUIpublic GameObject towerPrefab;public Transform towerRoot;

这些字段本身没问题。

问题是，它不会真的帮你把 Inspector 里的引用拖好。

所以代码看起来完整，真放进场景里运行时，才发现一堆引用没有绑。

这也是 Unity 项目里很常见的 AI 代码问题。

尤其是 UI 代码，它可能默认：

场景里有某个按钮。按钮已经绑定点击事件。文本已经拖到字段里。Prefab 已经赋值。Canvas 结构和它想的一样。

但你的项目未必是这样。

所以你让 AI 写 Unity 代码时，最好要求它在最后说明：

请说明这个脚本需要挂在哪个 GameObject 上。请说明 Inspector 中哪些字段需要手动绑定。请说明运行前场景里必须有哪些节点。如果字段为空，需要给出明确报错，而不是静默失败。

比如一个建塔脚本，AI 写完后至少应该告诉你：

挂在 BuildController 上。需要绑定 Camera、Tilemap、TowerRoot。需要配置 TowerDataList。需要场景里存在 BattleState。

否则代码再完整，你也不知道怎么放进项目里。

AI生成的代码，要防止“顺手改太多”

还有一个问题很常见。

你让 AI 改一个小功能，它顺手把整个类都重写了。

比如你只是想让子弹命中后支持减速效果，它可能会顺便改：

子弹基类。塔攻击逻辑。敌人受伤逻辑。Buff 系统结构。对象池。UI 显示。

有时候它是好心，觉得这样更完整。

但对真实项目来说，这很危险。

因为它不知道你原来的代码有哪些隐含规则。也不知道其他脚本是不是依赖了旧接口。更不知道某些看起来不优雅的写法，是不是为了兼容已有内容。

所以任务单里要写清楚修改范围。

比如：

只允许修改 SlowBullet.cs 和 BuffManager.cs。不要修改 TowerBase、EnemyBase、BulletBase 的公共接口。如果必须修改公共接口，请先说明原因，不要直接改。

这个限制在已有项目里很有用。

AI 写新代码很快，改旧代码也很快。但项目越往后，最怕的就是它把一个局部问题改成全局变动。

用AI写Unity代码时，最好让它顺手给检查清单

我现在比较推荐一个习惯：让 AI 写完代码后，顺手输出一份检查清单。

不是让它解释一大堆，而是列出你需要确认的东西。

比如：

请在代码后附上检查清单：1. 这个脚本挂在哪个对象上？2. Inspector 需要绑定哪些字段？3. 是否使用了 UnityEditor API？4. 是否有事件订阅和解绑？5. 是否用了 Update？如果用了，为什么必须每帧执行？6. 是否会影响已有公共接口？7. 如何在场景里验证功能是否正常？

这份清单比代码解释更有用。

因为 Unity 很多问题不是代码语法问题，而是放到场景以后才出问题。

这些检查项，刚好能覆盖脚本挂错、引用没拖、事件没解绑、Editor API 用错位置、Update 里做了不该每帧做的事这类常见问题。

写在最后

AI 写 Unity 代码，确实能省很多时间。

尤其是写工具脚本、数据类、简单组件、编辑器辅助功能、重复性逻辑时，它很好用。

但 Unity 项目不是普通 C# 控制台程序。

它有场景。有 Prefab。有 Inspector。有生命周期。有运行时和编辑器代码的区别。还有很多对象之间的引用关系。

AI 最容易出错的地方，往往不是语法，而是这些上下文。

所以让 AI 写 Unity 代码时，最好别只说：

“帮我写一个功能。”

而是尽量说清楚：

这个脚本挂在哪里。依赖哪些对象。数据从哪里来。哪些字段要配置。哪些代码只能运行时用。哪些代码只能编辑器用。哪些接口不能改。完成后怎么验证。

这些说明看起来多，但能省很多后面的返工。

AI 可以帮你把代码写出来。但 Unity 项目里，代码能不能真正跑起来，往往取决于代码之外的那些东西有没有说清楚。

结尾

好了，这就是今天分享的全部内容。

给欧米留言，分享你的心得！

点击"在看"让更多开发者看到

我是欧米，每天分享一点游戏开发小知识，希望能帮助到每一个走在实现梦想路上的游戏人。

本文由【欧米De游戏开发小屋】原创，抄袭必究

主笔：欧米

数据，排版：枫叶君

最近在做一个小的游戏创作者站点，

想先拉一个真的在做项目的小群内测。

你或者你的团队，现在如果有在做游戏，或者准备开始做，

任何游戏类型都可以。