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

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

---

上一篇聊的是一个比较大的方向：AI 适合做哪些开发里的杂活。这一篇可以把其中一类单独拎出来讲，因为它几乎是 AI 辅助 Unity 开发里最容易落地的部分：配置表、数据类和编辑器工具。

如果你做过稍微完整一点的 Unity 项目，大概都会遇到这些东西。敌人要有配置，塔要有配置，子弹要有配置，关卡要有配置，波次也要有配置。光有配置还不够，还要有对应的数据类、导入工具、检查工具，有时候还要做一些批量生成、批量更新、批量校验。

这些工作不一定难，但很容易耗时间，而且做起来没什么即时反馈。你写完一个 EnemyData，不会觉得游戏突然变好玩；写完一个 CSV 导入器，也不会马上看到炫酷效果。但没有这些东西，项目后面又会很难推进。

所以我觉得，这类工作反而是 AI 很适合切入的地方。

不是因为它能替你想清楚整个游戏，而是因为这些任务有一个共同点：规则比较明确，输入输出比较清楚，做完以后也比较容易检查。

配置表本来就是规则化的东西

游戏里的配置表，本质上就是把一堆规则写成数据。

比如敌人配置，可能会有：

enemyIdnamehpmoveSpeedarmorrewardGoldprefabPath

塔配置，可能会有：

towerIdtowerNamedamageattackRangeattackIntervalbulletIdbuildCostupgradeCost

波次配置，可能会有：

waveIdenemyIdcountspawnIntervalstartDelaypathId

这些字段本身其实都很常见。它们就是项目需要读、需要查、需要在运行时用到的数据。

但问题在于，配置一多，手写就很烦。字段要对齐，命名要统一，类型要一致，CSV 表头要对应 C# 字段，导入工具也要知道每一列代表什么。这里任何一个地方写错，运行时就可能出问题。

比如 attackInterval 在表里写成 attack_interval，代码里写成 attackInterval，导入器没有处理好，最后可能就是一个默认值。你调半天塔的攻速，才发现根本没读进去。

这类问题不是难，而是烦。

AI 在这里能帮你做的，是先把这些字段、类型、默认值、导入逻辑整理出来，至于“塔的攻击间隔应该是多少”这种具体数值，还是要你自己决定。

你可以这样问它：

我在做一个 2D 塔防游戏，请帮我整理第一版 TowerData 配置字段。要求：1. 只包含 MVP 阶段需要的字段。2. 每个字段说明用途。3. 给出字段类型。4. 给出一行示例数据。5. 不要加入皮肤、稀有度、养成系统等后续内容。

这比直接说“帮我设计塔系统”要靠谱得多。

因为这个任务很小，边界很清楚。AI 只需要围绕“第一版塔配置”做整理，不需要自己发挥成一整套商业化塔防系统。

数据类适合让 AI 先生成一版

配置表定下来以后，下一步通常就是数据类。

比如你已经确定了塔配置字段，就可以让 AI 生成一个最简单的数据类：

请根据下面字段生成 Unity C# 数据类。要求：1. 使用 [System.Serializable]。2. 字段使用 public。3. 字段名保持 camelCase。4. 不要写业务逻辑。5. 不要写读取 CSV 的代码。字段：towerId:stringtowerName:stringdamage:intattackRange:floatattackInterval:floatbulletId:stringbuildCost:intupgradeCost:int

它可能生成：

[System.Serializable]publicclassTowerData{publicstring towerId;publicstring towerName;publicint damage;publicfloat attackRange;publicfloat attackInterval;publicstring bulletId;publicint buildCost;publicint upgradeCost;}

这段代码不复杂，人当然也能写。但项目里不是只有一个 TowerData。你后面还会有 EnemyData、BulletData、WaveData、StageData、BuffData、SkillData，每个都差不多，但每个又不完全一样。

这种重复代码最容易让人进入一种机械状态：复制、粘贴、改字段、改类型、改注释。写久了以后，真正需要思考的事情反而被这些小事打断了。

AI 做这类事的价值就在这里。它可以帮你先生成一版，然后你再检查字段、类型、命名是否符合项目规范。

不过这里有一个前提：不要让 AI 在数据类里顺手写业务逻辑。

配置类最好保持简单。它只负责描述数据，不要又写计算伤害，又写加载资源，又写升级逻辑。否则后面配置、运行时状态、表现逻辑会慢慢混在一起。

比如 TowerData 里放 damage、attackRange 没问题，但如果它开始写 FindTarget()、Fire()、Upgrade()，那就有点越界了。

你给 AI 的任务里最好明确写：

只生成数据结构，不要生成任何战斗逻辑。

这句话很简单，但能避免它过度发挥。

ScriptableObject 也适合先做基础版本

Unity 项目里，很多配置最后会做成 ScriptableObject。

比如塔配置可以是 TowerDataAsset，敌人配置可以是 EnemyDataAsset，关卡配置可以是 StageDataAsset。这样做的好处是，在 Inspector 里可以直接编辑，也方便资源引用。

AI 很适合帮你先生成一个基础版本。

比如：

请帮我生成一个 TowerDataAsset，用于 Unity 塔防项目。要求：1. 继承 ScriptableObject。2. 使用 CreateAssetMenu。3. 包含 towerId、towerName、damage、attackRange、attackInterval、bulletPrefab、buildCost。4. 只做静态配置，不存储运行时状态。5. 不要写攻击逻辑。

它可能生成：

using UnityEngine;[CreateAssetMenu(menuName = "GameData/TowerData")]publicclassTowerDataAsset : ScriptableObject{publicstring towerId;publicstring towerName;publicint damage;publicfloat attackRange;publicfloat attackInterval;public GameObject bulletPrefab;publicint buildCost;}

这种代码本身不难，但 AI 可以很快给你一版。

你需要检查的是：字段命名是否和项目一致，bulletPrefab 是不是应该直接引用，还是应该写成 bulletId 或 bulletPrefabPath。如果你的项目后面要接 Addressables，那直接引用 GameObject 未必合适。如果只是小项目或早期原型，直接引用也能接受。

这其实就是比较合理的分工：AI 先把基础代码搭出来，人再判断它是否符合当前项目的资源管理方式。

导入工具很适合交给 AI 起草

配置表和数据类有了以后，下一步就是导入。

很多项目会经历这个阶段：一开始字段写死在脚本里，后来改成 Inspector 配置，再后来改成 CSV 或 Excel 表，再导入成 ScriptableObject。这个过程本身不复杂，但很容易占时间。

比如你想把 TowerData.csv 导入成 ScriptableObject，可以让 AI 先写一个 Editor 工具：

请帮我写一个 Unity Editor 工具，用于把 TowerData.csv 导入成 TowerDataAsset。要求：1. 工具放在 Editor 文件夹下。2. CSV 第一行是表头。3. 每一行生成或更新一个 TowerDataAsset。4. asset 文件名使用 towerId。5. 输出目录为 Assets/GameData/Towers。6. 如果同名 asset 已存在，则更新字段，不重复创建。7. 导入完成后调用 AssetDatabase.SaveAssets 和 AssetDatabase.Refresh。8. 只写编辑器代码，不要写运行时代码。

这种任务特别适合 AI 起草，因为输入输出很明确。读哪个文件，生成什么资源，放到哪个目录，怎么命名，是否覆盖，都可以说清楚。

但这里也要注意，AI 生成的 CSV 解析代码通常比较简单。它很可能直接用：

line.Split(',')

这在简单配置表里能跑，但一旦字段里有逗号、引号、换行、多语言文本，就可能出问题。如果你的项目配置很复杂，就要用更可靠的 CSV 解析方式，或者干脆走 Excel、JSON、自定义格式。

所以这类工具适合让 AI 先搭框架，不适合完全不看就直接长期使用。

更稳的做法是：先让 AI 写一个能跑的版本，再让它列出这个导入器的风险点。比如：

请审查这个 CSV 导入工具，重点看：1. 逗号、引号、换行是否会解析错误。2. 字段缺失时有没有报错。3. 类型转换失败时有没有提示。4. 是否会覆盖已有资源。5. 是否会破坏已有引用。

这样 AI 不只是写工具，也能帮你做第一轮风险检查。

编辑器工具的价值

Unity 编辑器工具有一个很大的特点：它们经常不是正式玩法，但能明显提升开发效率。

比如批量检查 Prefab 是否缺组件，批量检查资源命名是否规范，批量截图关卡预览图，批量把场景里的障碍物保存到关卡数据。这些工具玩家看不到，但开发者每天都可能用到。

AI 很适合先帮你写这类工具的第一版。

比如你想检查某个目录下所有塔 Prefab 是否挂了 TowerBase，可以这样写任务：

请写一个 Unity EditorWindow，用于检查指定目录下所有 Prefab 是否缺少 TowerBase 组件。要求：1. 可以选择一个 Assets 下的目录。2. 扫描该目录下所有 .prefab 文件。3. 加载 Prefab 后检查根节点或子节点是否包含 TowerBase。4. 在窗口中列出缺失组件的 Prefab 路径。5. 不要自动修改资源，只做检查。

这里最重要的是最后一句：不要自动修改资源，只做检查。

很多编辑器工具都涉及资源操作，一旦写错，可能会影响大量 Prefab 或场景对象。AI 写工具很快，但越是批量操作，越要先做只读版本。

也就是说，第一步可以是“扫描并列出问题”，第二步才是“确认后批量修复”。

这类流程适合固定下来。以后你让 AI 写编辑器工具时，可以默认要求：

第一版只扫描，不修改。列出将要修改的对象。确认逻辑没问题后，再写修改版本。

这样风险会低很多。

为什么这些任务适合 AI？

配置表、数据类、编辑器工具之所以适合交给 AI，不是因为它们简单，而是因为它们有几个共同特点：输入输出清楚，规则能提前写明，结果也容易检查。

你给它字段，它生成数据类。你给它 CSV 格式，它生成导入工具。你给它目录和检查规则，它生成扫描工具。这类任务不像“设计一个好玩的战斗系统”那么模糊，也不太依赖创意判断。

它们更偏执行和整理，不需要 AI 判断“这个游戏好不好玩”。这刚好避开了 AI 比较容易空泛发挥的地方。

所以我觉得，AI 在游戏开发里最先落地的地方，往往不是玩法本身，而是玩法周围这些支撑工作。

它们不显眼，但会持续影响项目效率。

但不要把数据结构完全交给 AI 拍板

虽然配置表和数据类适合让 AI 辅助整理，但不能完全交给它拍板。

比如 AI 可能会给你一个很完整的 TowerData：

towerIdtowerNamedescriptionrarityelementTypedamageattackRangeattackIntervalbulletPrefabupgradeCostsellPriceunlockLeveliconsoundEffectskillIdskinId

这看起来很丰富，但第一版可能根本用不上这么多字段。

字段一多，项目就会变重。你后面写 UI、导入工具、校验工具、默认值、空字段处理，都要跟着处理。很多时候，配置表不是越完整越好，而是要刚好够用。

所以让 AI 设计配置字段时，最好加一句：

只列 MVP 阶段真正需要的字段，不要加入后续商业化、皮肤、稀有度、复杂养成相关内容。

这句话很有用。

因为 AI 很容易把一个简单塔防配置扩成完整商业游戏配置。它不是故意乱写，而是它觉得“完整”就是好。但项目早期需要的不是完整，而是够用、清楚、能跑。

编辑器工具也不能直接信任

AI 写编辑器工具很方便，但也要谨慎。

因为编辑器工具经常有权限修改资源。比如批量改 Prefab、批量生成 Asset、批量重命名、批量删除、批量修改场景对象。这类代码一旦写错，影响范围很大。

所以编辑器工具最好遵循几个习惯。

第一，先只读扫描。

先让工具列出将要处理的资源，不要一上来就改。

第二，加确认步骤。

真正修改前，最好有按钮确认，或者至少在控制台输出明确日志。

第三，保留 Undo 或备份思路。

如果是修改场景对象，尽量用 Undo.RecordObject。如果是修改资源或 Prefab，也要考虑 EditorUtility.SetDirty、保存资源和版本管理。

第四，不要默认递归全项目。

扫描范围最好限制在指定目录，不要一上来扫整个 Assets。

这些规则，你都可以直接写进给 AI 的任务里。

比如：

请写一个只读版本。不要修改任何 Prefab。不要删除任何资源。只扫描指定目录。输出将要处理的资源列表。

这类限制越明确，AI 写出来的工具越不容易出大问题。

写在最后

配置表、数据类、编辑器工具，看起来都不是游戏里最酷的部分。

它们不像战斗系统那样直接影响手感，也不像关卡设计那样能马上看到体验变化。但一个游戏项目真正做起来以后，这些东西会一直跟着你。

配置表乱，后面调数值会很痛苦。 数据类乱，代码会越来越难接。 编辑器工具缺失，很多工作就只能靠人手动点。

AI 在这些地方很有价值，因为这些任务规则清楚、重复度高、容易检查。它可以帮你先生成一版，让你不用把时间浪费在大量机械工作上。

但最后还是那句话：AI 适合起草，不适合完全放飞。

字段要不要保留，资源怎么加载，工具能不能直接修改 Prefab，配置表要不要支持复杂格式，这些决定还是要人来做。

比较稳的用法是：

先让 AI 整理字段。 再让 AI 生成数据类。 再让 AI 起草导入工具。 最后让 AI 帮你写检查清单和风险点。

这样一套流程下来，它能帮你省不少时间，也不会轻易把项目带偏。

AI 不一定能替你做出好玩的游戏。 但它很适合帮你把这些基础工作先铺平。

---

结尾

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

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

---

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

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

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

主笔：欧米

数据，排版：枫叶君

有想法，有趣的项目，合作都可以加我哈！

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

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

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

任何游戏类型都可以。

可以加我哈