企业官网建设流程全解析

做 TABS 隐藏兵种 MOD 的朋友，大概率都遇到过这几类情况：配置文件写完了，进游戏兵种列表里却找不到；单位能刷出来，但贴图全白；打包之后一点开始就闪退；换了游戏版本，之前好好的 MOD 直接失效。这些问题不是玄学，绝大多数都出在资源路径、配置字段、加载顺序这三层上。本文围绕 TABS 隐藏兵种 MOD 的更新流程，把单位从"拆解定位"到"配置编写"再到"打包验证"的完整链路拆开讲一遍，同时给出常见报错的排查表和工程化建议，适合已经会基本操作、想系统整理一遍流程的玩家和 MOD 作者，也适合刚接触 Unity 资源与 JSON 配置、想拿一个真实场景练手的新手。读完之后，你应该能独立完成一个可展示、可维护、不乱改游戏原始文件的自定义兵种包。

1. TABS 隐藏兵种 MOD 的核心概念与本次更新范围

1.1 TABS 里的"单位"到底由什么组成

在动手改任何东西之前，先把概念理顺。TABS（Totally Accurate Battle Simulator）里的一个兵种，并不是"一个模型"这么简单，它实际是由几层数据叠加起来的复合体。最底层是美术资源，包含骨骼网格（Skinned Mesh）、材质球（Material）、贴图（Texture），决定这个单位长什么样；往上一层是预制体（Prefab），把模型、碰撞体、武器挂点、动画控制器组装在一起，决定这个单位的"形体结构"；再往上是行为配置，包含生命值、移动速度、攻击力、攻击间隔、攻击范围、阵营归属等数值，决定这个单位在战场上的表现；最上层是解锁与展示信息，包含名称、图标、描述、所属阵营页签，决定它怎么出现在玩家面前。

隐藏兵种之所以"隐藏"，本质上就是这四层里最上面那层被做了限制——资源可能完整存在于游戏包里，行为配置也存在，但解锁条件被设成了需要达成某种触发，或者在默认的兵种列表里被过滤掉。理解了这一点，后面很多问题就顺了：你做的 MOD 更新，其实就是在"补齐展示层"和"替换资源层"，而不是凭空创造一个游戏不认识的东西。

1.2 隐藏兵种、自定义兵种与替换兵种的区别

这三个词经常被混着用，但工程含义完全不同，混淆了会导致你做了一堆无用功。

隐藏兵种指的是游戏本体已经实现、但默认不给玩家直接使用的单位。这类单位的数据结构是完整的，你做的更多是"解锁"和"展示"工作。自定义兵种指的是通过游戏内置的单位创建器（Unit Creator）从零拼装出来的单位，它由游戏提供的部件库组合而成，配置是玩家自己生成的，可以导出成文件分享。替换兵种则是把已有单位的外观资源换成别的模型或贴图，行为配置保持不变。

从风险角度看，隐藏兵种解锁和自定义兵种分享是最稳妥的两条路，因为都在游戏设计允许的框架内；替换兵种涉及直接改动游戏资源包，一旦版本更新就会失效，而且容易和别人的 MOD 冲突。本文的实操部分以前两条主线为主，资源层的内容只作为原理讲解，并且强调只在本机单机环境、做好备份的前提下尝试。

1.3 MOD 的加载链路：资源、配置、逻辑三层

把加载过程想成一条流水线会更容易排查问题。游戏启动时先扫描 MOD 目录，读取清单文件，确定有哪些 MOD 要加载、加载顺序如何；然后按顺序加载资源包，把模型、贴图、预制体注册到资源索引里；接着读取配置文件，把数值和展示信息绑定到具体单位上；最后在进入战场或打开兵种列表时，把前面注册好的内容实例化出来。

这条链路的关键在于它是"顺序敏感"的。如果清单里写了某个 MOD 但资源包没找到，加载会中断；如果配置引用的资源名拼错了，资源索引里查不到，就表现为贴图丢失或单位不显示；如果两个 MOD 都想覆盖同一个单位，后加载的会覆盖先加载的，这就是为什么"多装了几个 MOD 之后某个兵种就变样了"这种问题特别常见。排查时按这条链路从后往前倒推，比盲目重装效率高得多。

1.4 本次更新到底"更新"了什么

一次 MOD 大更新，通常包含四类改动：新增单位、调整数值、修复资源、优化展示。新增单位是主体工作量，需要新模型或新配置；调整数值是平衡性改动，改的是配置文件里的数字；修复资源是处理贴图、骨骼、材质的问题；优化展示则是把名称、图标、描述、阵营归属这些"门面"做规范。

这里建议养成一个习惯：每次更新维护一份变更清单，逐条写明"改了哪个文件、改了什么字段、为什么要改"。MOD 做到后面单位数量上去了，没有清单基本没法维护，尤其是别人反馈某个单位数值不对的时候，你连自己上次改成多少都记不清。这个习惯的成本很低，收益极高。

2. 开发环境与工具链准备

2.1 运行环境与版本说明

TABS 是跨平台的，Windows 和 macOS 都能跑，但 MOD 相关的工具链在 Windows 上更成熟，下面的示例以 Windows 环境为主。需要强调的是：游戏版本、Unity 版本、资源包格式这几项在不同版本之间可能有差异，本文不会写死具体版本号，因为版本迭代较快，写死了反而误导。你的实际环境请以自己游戏安装目录里的信息为准，本文重点讲配置思路和排查方法，思路是跨版本通用的。

在开始之前请确认三件事：第一，游戏是从正规渠道购买的，尊重开发者的劳动成果；第二，你只在自己本机做单机环境下的修改，不涉及任何联机场景；第三，你已经完整备份了游戏目录和存档。第三点不是客套话，我见过太多人改到一半发现游戏起不来，又没有备份，只能整个重装。

2.2 必备工具清单

下面这张表把常用工具按用途分类，注意工具的具体版本请以官方发布页为准，不要随意下载来路不明的改版工具。

关于编码这一项要单独提醒：配置文件请统一保存为 UTF-8 无 BOM 格式。很多"配置明明写了但游戏读不出来"的问题，根因就是编辑器默认保存成了带 BOM 的 UTF-8 或者 GBK，游戏解析时在第一个字符就报错了。这个坑非常隐蔽，因为文件用记事本打开看起来完全正常。

2.3 工作目录结构规划

强烈建议不要把 MOD 工程直接建在游戏目录里。正确做法是在游戏目录之外单独建一个工程目录，开发完成后通过脚本复制过去。这样做的好处是：游戏更新覆盖目录时你的工程不会丢，出问题的时候删掉游戏目录里的副本就能干净还原。推荐的目录结构如下：

# 工程根目录示例（与游戏安装目录分离） tabs-mod-workspace/ ├── assets/ # 原始美术资源，未做任何处理 │ ├── models/ │ ├── textures/ │ └── prefabs/ ├── build/ # 构建产物输出目录 ├── config/ # 单位配置文件 │ ├── units/ │ │ ├── unit_hidden_001.json │ │ └── unit_hidden_002.json │ └── manifest.json # MOD 清单 ├── scripts/ # 校验、打包、部署脚本 │ ├── validate_config.py │ └── deploy.ps1 ├── docs/ # 变更清单、说明文档 │ └── CHANGELOG.md └── backups/ # 游戏原始文件备份

这个结构里，assets是源材料，build是可抛弃的产物，config是核心资产，scripts是提效工具，backups是保险。等级分清楚之后，你就不容易在"到底哪个文件是最新版"这个问题上纠结了。每次构建产物都从config和assets重新生成，build目录随时可以整个删掉重来。

2.4 首次改动前的备份与还原点

在动第一个文件之前，先把备份做完。备份范围包括游戏安装目录下的资源目录、配置目录、存档目录。推荐用带时间戳的压缩包备份，这样即使连续改了几次，也能回到任意一个状态：

# 在 PowerShell 中执行：创建带时间戳的游戏目录备份 $gameDir = "D:\Games\TABS" $backupRoot = "D:\tabs-mod-workspace\backups" $stamp = Get-Date -Format "yyyyMMdd_HHmmss" $target = Join-Path $backupRoot "game_$stamp" New-Item -ItemType Directory -Path $target -Force | Out-Null Copy-Item -Path $gameDir -Destination $target -Recurse -Force Write-Host "备份完成：$target"

这段脚本做的事情很直白：取当前时间生成时间戳，在备份根目录下创建同名文件夹，然后把整个游戏目录递归复制过去。执行完之后你应该能在一个新窗口里看到备份目录里确实有文件，而不是只有一个空文件夹——这一步一定要肉眼确认，我就见过路径写错导致备份到了别处的情况。备份完成之后，再在docs/CHANGELOG.md里写第一行记录，标注"初始状态，未经改动"，这样后续的任何问题都能定位到干净起点。

3. 单位资源的结构与定位思路

3.1 资源包的基本结构

Unity 打包出来的资源包，本质上是一个"索引 + 数据"的容器。索引部分记录了包内有哪些资源、资源的类型、以及在数据区的偏移量；数据区则是序列化后的资源本体。用查看工具打开时，你看到的列表就是索引解析出来的结果，能直接看出这个包里有哪些预制体、哪些贴图、哪些文本资源。

理解这个结构对排查问题很有帮助。比如"单位能刷出来但贴图是白的"，说明预制体被成功加载了，但预制体引用的材质或贴图没有找到——问题出在引用关系断裂，而不是文件缺失。再比如"整个 MOD 加载失败"，多半是资源包本身构建有问题或者清单路径不对，连索引都没读进来。遇到问题先判断是"索引层"还是"数据层"，能省掉大量无效尝试。

3.2 定位隐藏兵种相关的资源

定位的思路是"从名字找线索"。游戏内的资源命名一般有规律，比如同类单位会共享前缀，隐藏单位可能在命名上带特殊标记。你可以先用查看工具按名称排序，观察命名模式，再按兵种类型（近战、远程、大型单位）分组核对。如果名字上看不出规律，可以换个思路：先在游戏内确认这个隐藏兵种的外观特征（比如武器形状、体型、配色），再在预览里逐个比对，虽然慢一点但最可靠。

这里要注意一个细节：不要只看模型名字就直接断定，模型和配置之间是通过引用名关联的，模型叫 A、配置里引用 B 的情况并不少见。稳妥的做法是把"模型名、预制体名、配置中引用的资源名"三者的对应关系记录成一张表，写进docs/目录。这张表在后续新增单位时会反复用到，早整理早省事。

3.3 导出与重命名的规范

导出资源时有一个原则：原始资源原样保留，所有改动在副本上做。assets/目录下的东西就当它是只读的，需要调整时复制一份到工作目录再改。这样做的好处是任何时候都能对比"原始长什么样、改成了什么样"，出问题能快速定位是自己改坏的还是原素材本身的问题。

重命名要统一规则。推荐使用"类型_来源_序号"的格式，比如mdl_hidden_golem_01、tex_hidden_golem_01_albedo。前缀区分类型（mdl 模型、tex 贴图、mat 材质、prefab 预制体），中间标来源（hidden 表示隐藏兵种系列），后面跟具体名称和序号。统一命名不只是好看，批量脚本处理时全靠这个规则来分组，命名乱的工程根本没法脚本化。

3.4 素材使用与分享的边界

这一节必须说清楚。把游戏本体的美术资源提取出来，用在自己的 MOD 里再分发出去，涉及版权问题，不属于可以随意做的事。合理的做法是：自己制作模型和贴图，或者使用明确标注可商用、可修改的第三方素材，并在发布说明里注明素材来源和授权方式。仅仅为了自己在本机研究学习而提取资源查看结构，和使用他人资源制作并公开分发，性质是完全不同的。

如果你只是想做一个"展示向"的更新，把重点放在配置组织、数值设计、展示信息完善上，用自制或授权素材，这样既避免了版权风险，作品也能长期维护。这一点在下面的实操部分会贯彻：所有示例配置都以自建资源为前提。

4. 单位配置结构拆解：决定兵种行为的关键字段

4.1 单位基础属性字段

配置是 MOD 的灵魂。一个单位配置的骨架通常包含标识信息、基础属性、战斗属性、展示信息四块。下面是一份示例配置，字段命名和层级以常见组织方式给出，实际字段名必须按你所用版本的实际结构来写，不要直接照抄：

{ "id": "unit_hidden_golem_01", "displayName": "岩甲守卫", "category": "melee", "faction": "hidden", "unlock": { "type": "campaign_clear", "target": "campaign_map_03", "description": "完成第三章后解锁" }, "stats": { "health": 1200, "moveSpeed": 1.8, "turnSpeed": 90, "mass": 12.0 }, "combat": { "attackType": "melee_smash", "damage": 180, "attackInterval": 2.4, "attackRange": 2.2, "knockback": 3.5 }, "visual": { "prefab": "prefab_hidden_golem_01", "icon": "tex_hidden_golem_01_icon", "scale": 1.35 } }

逐块看。id是这个单位的唯一标识，命名要唯一且稳定，后续更新时不要改，因为其他配置或存档可能引用它。category决定它归到哪一类，影响列表里的分组和 AI 的寻敌逻辑。stats.mass这个字段很多人忽略，但它直接影响被击飞的距离和单位之间的推挤效果，大型单位如果 mass 太小，会出现被小兵顶飞的滑稽场面。

再看combat.attackInterval，这是攻击间隔，单位通常按秒计。这个值和damage要放在一起考虑：单次伤害高但间隔长，实际输出可能还不如伤害低但出手机快的单位。设计和调平衡时，建议用"每秒理论输出 = damage / attackInterval"这个简单的比值先做横向对比，再去实战验证，比拍脑袋填数字靠谱。

4.2 攻击逻辑与命中判定

attackType这个字段看起来只是一个字符串，实际上它决定了整套攻击行为：出招动画怎么播、命中判定在动画的哪一帧触发、命中时施加什么效果。常见的类型包括近战挥击、突刺、范围砸地、远程投射等。如果你新增了一个单位但发现它"站着不动不攻击"，第一件事就是检查这个字段填的值在游戏里是否存在对应实现——拼错一个字母，行为就完全不会触发。

命中判定还有一个容易被忽略的点：攻击范围不是只有attackRange一个参数在起作用。有些实现里，碰撞体的尺寸、武器挂点的位置、攻击判定的碰撞形状都会影响实际打到谁。所以调"总是打不中"的问题时，不要只盯着attackRange反复改，还要确认武器模型挂点是否正确、碰撞体有没有被缩放得过头。

下面是一个校验脚本，用来在打包前统一检查配置文件里的常见低级错误，避免把问题带到游戏里才发现：

# 文件路径：scripts/validate_config.py import json import os import sys REQUIRED_FIELDS = ["id", "displayName", "category", "stats", "combat", "visual"] REQUIRED_STATS = ["health", "moveSpeed", "mass"] REQUIRED_COMBAT = ["attackType", "damage", "attackInterval", "attackRange"] def validate_unit(path): errors = [] with open(path, "r", encoding="utf-8") as f: try: data = json.load(f) except json.JSONDecodeError as e: return [f"JSON 解析失败：{e}"] for field in REQUIRED_FIELDS: if field not in data: errors.append(f"缺少顶层字段：{field}") stats = data.get("stats", {}) for field in REQUIRED_STATS: if field not in stats: errors.append(f"缺少 stats.{field}") combat = data.get("combat", {}) for field in REQUIRED_COMBAT: if field not in combat: errors.append(f"缺少 combat.{field}") interval = combat.get("attackInterval") if isinstance(interval, (int, float)) and interval <= 0: errors.append("combat.attackInterval 必须大于 0") health = stats.get("health") if isinstance(health, (int, float)) and health <= 0: errors.append("stats.health 必须大于 0") return errors def main(config_dir): total, failed = 0, 0 for name in sorted(os.listdir(config_dir)): if not name.endswith(".json"): continue total += 1 path = os.path.join(config_dir, name) errors = validate_unit(path) if errors: failed += 1 print(f"[失败] {name}") for e in errors: print(f" - {e}") else: print(f"[通过] {name}") print(f"\n共检查 {total} 个配置，失败 {failed} 个") return 1 if failed else 0 if __name__ == "__main__": target = sys.argv[1] if len(sys.argv) > 1 else "config/units" sys.exit(main(target))

这个脚本的思路是"先用最小成本拦住最低级的错误"。它做三件事：确认能正常解析 JSON（防止少了逗号或括号）、确认必备字段存在（防漏写）、确认关键数值合法（防止填 0 或负数）。运行方式很简单：

python scripts/validate_config.py config/units

预期输出是每个文件一行"通过"或"失败 + 原因"，最后一行给出统计。建议把它接进打包流程，做到"校验不过就不打包"，这一条能省掉大量来回测试的时间。

4.3 阵营归属与解锁条件

faction和unlock这两个字段是隐藏兵种 MOD 的核心。faction决定单位出现在哪个阵营页签下，值必须和游戏里已有的阵营标识对应，随便造一个新的标识大概率会导致整个列表渲染异常。unlock则决定它什么时候可用：可以设为默认可见，也可以设成达成某个条件后解锁，还可以先做成未解锁状态用于测试。

这里常见的误区是把解锁条件写得太复杂。如果unlock里引用的目标标识不存在，有些实现会直接判定为"永不满足"，表现为这个单位永远不出现，而且没有任何报错。排查这种问题的方法是：先把unlock临时改成默认可见，确认单位本身能正常展示，再改回条件解锁逐步验证。先排除"单位本身有问题"，再排查"条件没触发"，这个顺序能避免在一堆条件里瞎猜。

4.4 配置文件的缩进与编码校验

JSON 对格式是严格的，多一个逗号、少一个花括号都会解析失败。除了用上面那个脚本做字段校验，还建议做两件事：一是在编辑器里开启 JSON 语法检查，写的时候就能看到红线；二是统一缩进为两个空格或四个空格（团队协作选一种，不要混），并确保文件末尾保留一个换行符。

编码问题前面提过，这里再强调一次检查方法：用支持显示编码的编辑器打开文件，确认右下角显示的是 UTF-8 而不是 UTF-8 with BOM 或 GBK。如果你的配置里有中文名称，编码不对会直接导致游戏里显示乱码，甚至解析失败。批量检查可以用脚本读取每个文件的前几个字节，看有没有 BOM 标记：

# 文件路径：scripts/check_bom.py import os import sys BOM = b"\xef\xbb\xbf" def check(folder): bad = [] for name in sorted(os.listdir(folder)): if not name.endswith(".json"): continue path = os.path.join(folder, name) with open(path, "rb") as f: head = f.read(3) if head == BOM: bad.append(name) if bad: print("以下文件带有 BOM，请另存为 UTF-8 无 BOM：") for name in bad: print(" -", name) return 1 print("全部文件编码正常") return 0 if __name__ == "__main__": sys.exit(check(sys.argv[1] if len(sys.argv) > 1 else "config/units"))

这个脚本只读不写，安全性很高，可以随时跑。但它只能检查 BOM，发现之后还是需要你手动在编辑器里另存一次。批量转码的建议是单独写一个转换脚本，并且转换前先备份——批量操作配置文件的唯一原则就是先备份再动手。

5. 完整实战：制作一个可展示的自定义隐藏兵种

5.1 建立 MOD 工程与清单

按照第 2.3 节的目录结构建好工程，然后先写清单文件。清单的作用是告诉加载器"这个 MOD 叫什么、版本多少、包含哪些单位配置、资源包在哪"。下面是一个示例结构：

{ "modId": "hidden_units_pack", "modName": "隐藏兵种扩展包", "version": "1.1.0", "author": "your_name", "description": "新增若干隐藏兵种单位，各自带有独立的数值与展示信息。", "gameVersionRange": "按实际游戏版本填写", "units": [ "config/units/unit_hidden_golem_01.json", "config/units/unit_hidden_archer_01.json" ], "assetBundle": "build/hidden_units_pack.bundle", "loadOrder": 100 }

几个字段的用途说明白：modId是唯一标识，改动它等于换了一个 MOD，用户那边的旧配置就对不上了；version建议语义化版本，格式为主版本.次版本.修订号，新增单位升次版本、修 bug 升修订号；loadOrder控制加载顺序，数值小的先加载、大的后加载，如果你需要覆盖其他 MOD 的内容就把它调大，但要注意由此带来的冲突；gameVersionRange是给用户看的兼容提示，具体取值请按你的实际测试环境填写，不要随手写一个没验证过的范围。

5.2 分发单位配置并做数值分组

写好第一个单位之后，第二个、第三个单位不要复制粘贴了事。推荐先把单位按"定位"分组，比如重型近战、轻型骚扰、远程输出、特殊效果，每组建立一套数值基线，同一组内的单位只在关键指标上做差异化。这样做的原因是：如果每个单位都独立拍数字，游戏里会出现极端的强弱差距，玩家一试就觉得不平衡。

具体操作上可以建一份docs/balance_baseline.md，把每组的参考值写清楚：重型单位的 health 区间、moveSpeed 上限、damage 与 attackInterval 的搭配范围。新增单位时先按基线填，再根据特色调整一到两个指标。比如一个"高血量低移速"的守卫，就在重型组基线基础上把 health 拉高、moveSpeed 压低，其他保持不动。这个方法对新手特别友好，因为不需要一开始就有很强的平衡直觉。

5.3 编写资源构建脚本

如果单位使用了自建模型和贴图，就需要把它们打包成 Unity 能加载的资源包。Unity 提供了构建资源包的接口，写一个编辑器脚本就能一键构建，避免每次手动点菜单：

// 文件路径：Assets/Editor/BuildHiddenUnitsBundle.cs using UnityEditor; using UnityEngine; using System.IO; public class BuildHiddenUnitsBundle { // 所有需要打进包内的资源目录 private static readonly string[] AssetDirs = { "Assets/HiddenUnits/Prefabs", "Assets/HiddenUnits/Textures", "Assets/HiddenUnits/Materials" }; [MenuItem("Tools/Build Hidden Units Bundle")] public static void Build() { string outputDir = Path.Combine(Directory.GetCurrentDirectory(), "Build"); if (!Directory.Exists(outputDir)) { Directory.CreateDirectory(outputDir); } // 为每个资源目录建立独立的资源包标记 foreach (string dir in AssetDirs) { if (!Directory.Exists(dir)) { Debug.LogWarning($"目录不存在，已跳过：{dir}"); continue; } string[] guids = AssetDatabase.FindAssets("", new[] { dir }); foreach (string guid in guids) { string path = AssetDatabase.GUIDToAssetPath(guid); if (AssetDatabase.IsValidFolder(path)) { continue; } // 同一个包名保证资源被打进同一个包内 AssetImporter importer = AssetImporter.GetAtPath(path); if (importer == null) { continue; } importer.assetBundleName = "hidden_units_pack.bundle"; importer.SaveAndReimport(); } } BuildPipeline.BuildAssetBundles( outputDir, BuildAssetBundleOptions.ChunkBasedCompression, EditorUserBuildSettings.activeBuildTarget); Debug.Log($"资源包构建完成，输出目录：{outputDir}"); } }

这段脚本做三件事：遍历指定目录，把里面的每个资源都打上同一个包名标记；调用构建接口输出到Build目录；打印日志。几个细节值得说明：ChunkBasedCompression是分块压缩模式，加载时不需要把整个包读进内存，适合资源比较多的包；EditorUserBuildSettings.activeBuildTarget表示按当前激活的平台构建，如果你的用户在多个平台上游玩，需要分别构建。另外要注意，构建产物里除了.bundle文件还会有一个同名的清单文件，部署时两个都要带上，只复制.bundle是跑不起来的。

5.4 编写部署脚本

工程目录到游戏目录的复制过程，手动操作容易漏文件或者复制到错误位置。用脚本固定流程：

# 文件路径：scripts/deploy.ps1 param( [string]$GameModDir = "D:\Games\TABS\Mods\hidden_units_pack", [string]$ProjectRoot = "D:\tabs-mod-workspace" ) $configSrc = Join-Path $ProjectRoot "config" $buildSrc = Join-Path $ProjectRoot "build" if (-not (Test-Path $configSrc)) { throw "配置目录不存在：$configSrc" } if (-not (Test-Path $buildSrc)) { throw "构建目录不存在，请先执行资源构建：$buildSrc" } # 确保目标目录存在 New-Item -ItemType Directory -Path $GameModDir -Force | Out-Null # 复制配置与资源 Copy-Item -Path (Join-Path $configSrc "*") -Destination $GameModDir -Recurse -Force Copy-Item -Path (Join-Path $buildSrc "*") -Destination $GameModDir -Recurse -Force Write-Host "部署完成 -> $GameModDir" Get-ChildItem -Path $GameModDir -Recurse | Select-Object FullName

脚本里两个if判断是必要的防御。如果没有它们，构建目录不存在时脚本会静默复制不到资源包，到了游戏里表现为"配置生效但模型丢失"，你会以为是配置写错了，实际上是复制环节就没成功。最后那句Get-ChildItem会把复制结果打印出来，让你肉眼确认文件确实到位了。

5.5 运行验证与结果说明

部署完之后按下面的顺序验证，每一步都对应一类检查点，跳步会浪费时间：

第一步，启动游戏，进入 MOD 管理或兵种列表，看这个单位有没有出现。出现说明清单、配置、资源三层都通了；不出现说明链路在更前面就断了，直接跳第 6 节的排查表。

第二步，把单位放到沙盒地图里单独出场一次，观察模型有没有正常显示、动画有没有正常播放、移动和转向是否自然。这一步能发现资源引用问题，比如贴图丢失、材质发白、骨骼错位。

第三步，和标准单位做一场对战，观察攻击动作的触发时机、命中判定范围、击飞效果是否符合预期。这一步是验证attackType和各项战斗数值。

第四步，同时出 20 个以上这个单位，观察帧率。TABS 的乐趣就在大规模混战，单个单位跑得再好，二十个一起就卡成幻灯片也没意义。这一步的结果要记进变更清单，作为后续优化的依据。

6. 隐藏兵种"不显示"的常见问题排查

6.1 症状对照排查表

大部分问题都能在这张表里找到方向。注意"可能原因"列一般有多个，排查时按从上到下的顺序试，前面的概率更高、检查成本更低。

6.2 按链路倒推的排查顺序

遇到问题时，建议固定按这个顺序走，不要跳着试：

1. 清单层：清单文件能否正常解析？units里列的文件是否都存在？
2. 配置层：单个配置能否被校验脚本通过？字段名有没有拼错？
3. 资源层：资源包是否存在、是否完整、是否包含清单文件？
4. 引用层：配置里引用的资源名，和资源包里实际注册的名字是否一致？
5. 逻辑层：attackType等行为字段填的值，在游戏里是否真实存在？
6. 冲突层：是否有其他 MOD 覆盖了同名资源或同一单位？

这个顺序的逻辑是"从便宜到贵"：前面几层检查只要几十秒，最后一层可能要反复装卸 MOD 测试半小时。先把便宜的都排除掉，能覆盖八成的问题。

6.3 建立自己的排查清单

排查经验最好的沉淀方式，是维护一份属于自己的检查清单文档。每次踩到一个新坑，就把它记进docs/FAQ.md，格式固定为"现象 - 原因 - 解决 - 如何避免"。

举一个真实会遇到的例子：现象是"单位在列表里有图标，但进战场后不出现"，原因是visual.prefab指向的预制体名字和资源包里注册的名字差了一个下划线。这类问题的特点是没有任何报错，只能靠对比名字发现。记进清单之后，下次遇到类似症状就能在两分钟内定位。这份文档的价值会随着你做的单位数量线性增长。

7. 性能、稳定性与兼容性优化建议

7.1 资源规格控制

TABS 的战场经常出现几十上百个单位同屏，所以单个单位的资源规格必须克制。模型面数建议控制在合理范围，不要拿高精度雕刻模型直接扔进去；贴图尺寸也不要盲目用最大的，图标类贴图几百像素足够，模型主贴图按需选择，能用小图解决的问题不要用大图。

判断标准很简单：单个单位的资源体积乘以同屏最大数量，得出来的内存占用在你机器上跑得动就行。一个单位看着不大，二十个一起出场就是二十倍。另外，材质球数量也要控制，能用一张贴图表达的就不要拆成三张，材质球切换是渲染开销的来源之一。

7.2 大量单位同屏的表现优化

除了资源规格，行为逻辑也会影响性能。攻击间隔极短的单位（比如 0.1 秒一次）会让命中判定频繁触发，单位数量一多计算量就上去了。设计高频攻击单位时，建议先在小规模下测试效果，再放到大场面里压测。

还有一个容易忽略的点：特效。单位攻击时附带粒子特效看着很帅，但如果每个单位每次攻击都生成一堆粒子，二十个单位一起打就是灾难。建议把特效做得轻量，或者只在关键动作（比如重击命中）时触发，不要每次普攻都放。

7.3 多 MOD 共存的兼容策略

只要你打算把 MOD 发出去，就必须考虑用户同时装了其他 MOD 的情况。规避冲突的核心是"命名空间唯一"：所有资源名、单位 id 都加上你自己的前缀，不要用unit_01这种通用名字。这样即使用户装十个 MOD，各自的资源也不会撞车。

加载顺序方面，如果你的 MOD 不依赖也不覆盖其他 MOD，loadOrder给个中间值就行；如果确实需要覆盖某些内容，一定要在发布说明里写清楚"本 MOD 会覆盖 XX，与 YY 不兼容"。把兼容性写在文档里，比让用户自己去试要负责得多。

7.4 游戏版本升级后的适配

游戏更新是 MOD 作者最头疼的事。适配的基本流程是：先看更新说明有没有涉及单位系统、资源配置的改动；然后把旧配置在纯净环境下跑一遍，看哪些字段报错或失效；最后逐项对照修正。

为了降低这个成本，建议在配置里尽量少写"依赖具体实现"的内容。比如能用通用攻击类型就不要用某个特定动画绑定的类型，能通过参数调整达到的效果就不要硬编码。配置越"通用"，跨版本的存活率越高。另外，在清单里认真填写gameVersionRange，至少能让用户在版本不匹配时有个心理预期，而不是装完了发现用不了来骂你。

8. 工程化建议与发布规范

8.1 目录与命名规范

前面已经讲了命名格式，这里补充目录层面的约定。建议config/units/下的文件按单位类型再分子目录，比如melee/、ranged/、special/，单位数量超过二十个之后，平铺在一个目录里找文件会非常痛苦。文件名的前缀和单位 id 保持一致，做到"看到文件名就知道这是哪个单位"。

资源目录同理。Prefabs、Textures、Materials三类分开，每类内部按单位分组。这个规范看起来啰嗦，但它直接决定了你后面能不能用脚本批量处理。工程乱到一定程度，脚本写起来全是特判，最后只能手动操作，效率会掉得很厉害。

8.2 版本记录与回滚

每次发布前更新CHANGELOG.md，格式建议固定为三段：新增、修改、修复。每条写清楚"改了什么、为什么改"。这个文档不只是给别人看的，更是给三个月后的自己看的。

回滚能力同样重要。因为配置是纯文本，最省事的做法是用版本管理工具管起来，每次改动提交一次，出问题直接回退到上一个提交。如果不用版本管理，至少要做到"每次发布前把整个工程打包备份一份"，并且在备份文件名里带上版本号。这一条是底线，没有回滚能力的工程，一次失误就可能让你几天的活白干。

8.3 日志与用户反馈收集

自己开发时，出问题可以直接调试；发布出去之后，你只能靠用户的描述来判断问题。所以建议在 MOD 包里附带一份README.md，写清楚：如何安装、如何卸载、已知问题、如何反馈。反馈模板里明确要求用户提供游戏版本、MOD 版本、以及出问题时的具体表现（是列表看不到、还是进战场才出问题）。

这些信息能把排查范围缩小一大截。经验上，用户说"不生效"，可能是清单没读到、配置没解析、资源没加载、冲突被覆盖，四种完全不同的原因，没有版本和现象描述根本没法判断。

8.4 单机环境与合规边界

最后必须强调这一点。本文所有内容都限定在单机环境、本地文件、自己购买的游戏这个范围内。不要把这些方法用于任何联机场景，不要修改他人的作品再以自己的名义发布，不要把游戏本体资源打包分发。做 MOD 的乐趣在于创造，而不是绕过设计。

如果你只是想展示自己的设计能力，用自制素材做原创单位、把配置组织得漂亮、把文档写清楚，这样的作品才是能长期维护、也值得别人尊重的。

9. 后续可以继续深入的方向

到这里，一条从资源定位、配置编写、脚本校验、打包部署到排查优化的完整链路就走完了。回顾一下几个最关键的点：配置文件的编码和字段拼写是最容易出错也最容易被忽略的地方，一个 BOM 或者一个下划线就能让你排查半小时；资源引用是"能刷出来但不正常"类问题的根源，名字对不上就断链；加载顺序和命名空间是多 MOD 共存的核心，前缀不统一迟早撞车；而校验脚本和部署脚本这两个小工具，能把你从重复劳动里解放出来。

想继续深入的话，有几个方向值得投入。一是把校验脚本做得更细，比如自动检查资源引用名是否真的存在于资源包内，这个检查能拦掉一大类问题。二是研究单位行为之间的组合效果，比如击退、范围伤害、召唤这几类机制叠加时的表现，这是 TABS 最好玩也最难平衡的部分。三是把工程文档体系建起来，包括单位设计表、数值基线、变更清单、FAQ，这套东西做得越早，后面新增单位的速度就越快。

另外提醒一句，动手前一定要备份，改动一定要在副本上做，发布前一定要在纯净环境里验证一遍。这三点看着是废话，但每一条背后都是真实踩过的坑。建议你现在就挑一个单位，从写配置、跑校验、打包部署到进游戏验证，完整走一遍，比看十遍教程都管用。如果实际操作中遇到本文没覆盖的情况，可以先把现象和版本信息记录下来，再按第 6.2 节的链路顺序逐层排查，大部分问题都能自己定位出来。