Unity YAML序列化机制：批量替换与合并冲突实战指南

我印象里第一次被Unity的YAML“教育”到，是在一个赶工的项目里。当时美术一次性交付了三百多个预制体，要求把里面所有用到旧Shader的材质统一换成新版本。如果用编辑器一个个改，一个材质几秒钟，三百个就是两三个小时。我当时直接在项目目录里扫了一遍.prefab文件，把里面对应的一段引用用脚本批量替换，再打开Unity验证，完美通过，节省了至少一个下午。

这件事之后我才认真研究起Unity的YAML。说白了，Unity工程里的.prefab、.unity、.asset、.mat这些文件，只要序列化模式设置得当，它们全都是带一点Unity自定义标签的YAML文本。理解这套格式，不是让你以后都去手改文件，而是让你在批量修改、解决合并冲突、排查资源引用问题时，有一套底层的方法论。这篇内容我会把Unity的YAML底层机制、引用关系、批量替换、合并冲突和团队配置这几个场景一起讲清楚，适合正在做Unity项目、尤其是团队协作中频繁被场景和预制体冲突折磨的开发者。

1. 先看底牌：Unity序列化文件本身就是YAML

1.1 场景和预制体在磁盘上的真实形态

很多人用了两三年Unity，从来没有用文本编辑器打开过场景文件。其实你只要在项目文件夹里随便找一个.prefab或者.unity文件，用VS Code打开，看到的不是乱码，而是结构清晰的可读文本。

一个典型的Unity YAML文件头部长这样：

yaml复制%YAML 1.1
%TAG !u! tag:unity3d.com,2011:
--- !u!1 &100000000
GameObject:
  m_ObjectHideFlags: 0
  m_CorrespondingSourceObject: {fileID: 0}
  m_PrefabInstance: {fileID: 0}
  m_PrefabAsset: {fileID: 0}
  serializedVersion: 6
  m_Component:
  - component: {fileID: 100000001}
  m_Layer: 0
  m_Name: Cube
  m_TagString: Untagged
  m_Icon: {fileID: 0}
  m_NavMeshLayer: 0
  m_StaticEditorFlags: 0
  m_IsActive: 1

先说结论：Unity默认的序列化模式是Mixed，在绝大多数项目里，场景、预制体、材质、动画剪辑、ScriptableObject这些“由用户编辑产生”的资源，存到磁盘上的就是YAML文本。只有贴图、模型这类导入后生成的中间资源，才会走二进制。

为什么Unity要这么做？因为YAML文本可以人类阅读、可以进版本控制做diff、可以在紧急情况下用脚本批量修改。你想想，如果场景文件全部是二进制，那么多人协作时一合并就全毁，git连哪里改了什么都不知道。所以Unity从很早期就选择了YAML作为序列化格式，这个决策到今天都没有变。

1.2 Unity YAML的“方言”：%TAG指令、类ID与文件ID

Unity的YAML不是标准YAML，它有自己的“方言”。关键就在头部那两行：

yaml复制%YAML 1.1
%TAG !u! tag:unity3d.com,2011:

第一行声明了YAML版本，第二行是一个标签指令，意思是：文件中所有以!u!开头的标签，都对应unity3d.com,2011:这个命名空间下的类型。为什么需要这个？因为YAML本身不知道Unity的GameObject是什么，它需要一种方式把“这是一个GameObject”的信息写进文本里。

接着就是核心了：--- !u!1 &100000000。

• ---是YAML的文档分隔符。一个文件里可以有多个---，每个---表示一个顶层对象。
• !u!1表示这个对象的类型。1是Unity内部类ID，对应GameObject。
• &100000000是YAML的锚点，表示这个对象在本文件内的文件ID（fileID）。后面其他对象想引用它，就用{fileID: 100000000}。

所以Unity YAML的整体结构就是：文件由多个文档组成，每个文档是一个带类型标记的对象，对象之间通过fileID互相引用。

下面这张表是Unity中最常用的类ID，建议收藏，排查问题时你会反复用到。

你可以这样理解：!u!114开头的文档就是某个MonoBehaviour组件的序列化数据，里面会记录挂的是哪个脚本、各public字段的值。这也是后面手改YAML时最常碰到的类型。

1.3 不是所有资产都是YAML：Asset Serialization模式

Unity提供三种序列化模式，在Project Settings > Editor > Asset Serialization里设置：

• Mixed：默认模式。场景、预制体、材质等以YAML文本保存，导入资源保持二进制。
• Force Text：所有可序列化的资产都写成YAML文本。
• Force Binary：所有资产都写成二进制。

大部分团队建议直接切到Force Text。因为一旦某个文件被二进制化，git diff就完全失效，合并工具也拿它没办法。Force Text的代价是文件体积稍大，但在版本控制和排查问题上带来的收益远大于这点磁盘开销。

切换模式之前做好备份，切换之后Unity会重新导入所有资源，大项目可能要花一段时间。团队协作时，这个设置必须所有人保持一致，否则就会出现“你改的预制体在我这打开是二进制”的诡异问题。

2. 引用关系：看懂fileID、GUID与.meta的协作逻辑

2.1 锚点与别名：文件内部对象的互相引用

Unity场景里的对象不是孤立的，GameObject和它的Transform组件是双向引用的。在一个Prefab文件里，你经常能看到这样的结构：

yaml复制--- !u!1 &100000000
GameObject:
  m_Component:
  - component: {fileID: 100000001}
---
--- !u!4 &100000001
Transform:
  m_GameObject: {fileID: 100000000}

GameObject的组件列表里有一个{fileID: 100000001}指向Transform，Transform的m_GameObject字段又指回GameObject。这就是文件内部的引用关系。

这种“锚点定义、别名引用”的机制是YAML标准语法，Unity只是把fileID这个语义套用在了锚点上。你手动写脚本替换时，只要不改fileID本身，只是修改同一文档里的字段值，一般不会破坏这种内部链接。

2.2 跨文件引用：fileID + guid + type 三要素

文件内部的引用靠fileID就够了，但一个材质文件被几十个场景引用时怎么办？Unity需要在所有工程文件之间建立一个全局唯一的资源定位机制。答案就是guid。

每个资源在导入时都会生成一个.meta文件，里面有一个全局唯一的guid。当场景引用一个外部材质时，你会看到这样的字段：

yaml复制m_Materials:
- {fileID: 2100000, guid: 4a9d1f8c2b3e4d5f6a7b8c9d0e1f2a3b, type: 2}

这句话的意思是：引用一个fileID为2100000、guid为4a9d...、资源类型为2的资产。这里的fileID指向目标资源文件内部的子对象（比如Material文件内部的主材质对象），guid定位到具体文件，type用来区分资产类型。

MonoBehaviour引用脚本时也一样：

yaml复制m_Script: {fileID: 11500000, guid: 5f9a0b2c3d4e5f6a7b8c9d0e1f2a3b4, type: 3}

这里的11500000是MonoScript在主资产文件中的固定fileID，guid指向具体脚本文件，type为3表示MonoScript类型。所以，当你把脚本改名或移动位置后Inspector里出现Missing Script，本质就是guid找不到对应文件了。

2.3 .meta文件是资源的“身份证”，别随便丢

.meta文件平时在Unity里是隐藏的，很多人会忽略它。但它是Unity资源管理的命根子。一个.meta文件长这样：

yaml复制fileFormatVersion: 2
guid: 4a9d1f8c2b3e4d5f6a7b8c9d0e1f2a3b
PrefabImporter:
  externalObjects: {}
  userData:
  assetBundleName:
  assetBundleVariant:

一旦你删除了.meta文件，Unity会在下次导入时为这个资源生成一个新的guid。所有引用旧guid的场景、预制体、材质，会在一夜之间变成Missing。材质变粉色、场景里物体消失、组件找不到脚本，很大一部分根源就在这里。

这里有几个实际工作中容易踩的雷，我单独拎出来说：

• 在操作系统里直接“复制文件夹”到另一个工程时，如果连.meta一起复制，guid不会变，引用还能对上；如果只复制资源文件不复制.meta，等于创建了一堆新资源，所有引用全部断裂。
• 在Unity的Project窗口复制资源时，Unity自己会生成新的.meta和guid，这是安全的，但旧资源的所有引用不会转移到新资源上。
• 如果两个.meta文件里的guid碰巧一模一样，Unity会报重复guid错误，整个资源组都会异常。

所以我的习惯是：任何.meta文件都提交进版本控制，永远不要删，也不要手动改里面的guid。除非你非常清楚自己在干什么。

3. 批量替换实践：Shader替换与材质参数调整

3.1 先判断：编辑器脚本还是文本批处理

当你需要批量修改大量资源的某个字段时，有两条路：在Unity里写Editor脚本，或者在磁盘上直接改YAML文本。两条路各有适用场景。

如果你需要改的是材质上的Shader、Float参数、Prefab里某个组件的字段值，而且这个值可以通过Unity公开API设置，优先写Editor脚本。因为引擎会帮你处理引用关系，改完不用担心中间状态损坏。

但有些场景Editor脚本反而不好用，比如你要批量替换几百个Prefab中某个自定义组件的某个私有序列化字段，既没有现成API，还要启动Unity加载全部资源，耗时又长。这时候直接在磁盘上做文本替换就快得多，一个脚本扫完，几秒钟搞定。

我给的判断标准很简单：改动复杂、涉及对象间关系、需要依赖引擎规则时用Editor脚本；改动简单、字段模式固定、数量巨大时用文本批处理。

3.2 方式一：C# Editor脚本批量处理材质

先给一个最常用的例子：把项目里所有使用旧Shader的材质，统一替换成另一个Shader。

csharp复制using UnityEditor;
using UnityEngine;

public static class BatchReplaceMaterialTool
{
    [MenuItem("Tools/Batch/Replace Shader In All Materials")]
    public static void ReplaceShaderInAllMaterials()
    {
        Shader targetShader = Shader.Find("Universal Render Pipeline/Lit");
        if (targetShader == null)
        {
            Debug.LogError("目标Shader不存在，请检查Shader名字");
            return;
        }

        string[] guids = AssetDatabase.FindAssets("t:Material");
        int count = 0;
        foreach (string guid in guids)
        {
            string path = AssetDatabase.GUIDToAssetPath(guid);
            Material mat = AssetDatabase.LoadAssetAtPath<Material>(path);
            if (mat != null && mat.shader.name.StartsWith("Legacy Shaders/"))
            {
                mat.shader = targetShader;
                EditorUtility.SetDirty(mat);
                count++;
            }
        }

        AssetDatabase.SaveAssets();
        Debug.Log($"已替换 {count} 个材质");
    }
}

这里我用AssetDatabase.FindAssets而不是自己遍历文件夹，是因为它能直接按资源类型过滤，自动处理guid到路径的转换，不会有中文路径、文件夹权限之类的问题。所有修改过的资源都通过EditorUtility.SetDirty标记脏，最后统一SaveAssets落盘。

如果只是想批量设置某个Float参数，逻辑同理，在循环里加一行：

csharp复制if (mat.name.StartsWith("Building_"))
{
    mat.SetFloat("_Glossiness", 0.2f);
    EditorUtility.SetDirty(mat);
}

注意，这种方式的性能瓶颈在AssetDatabase.LoadAssetAtPath会真的把所有材质加载进内存。几百个材质没问题，上万个可能就要隔几百个调用一次Resources.UnloadUnusedAssets，否则内存容易顶不住。

3.3 方式二：Python离线替换YAML文本

再说文本批处理。场景是：你没有Unity授权、不想启动编辑器，或者只想在CI里做一个快速替换。

最典型的例子是批量替换材质文件里的Shader引用。一个.material文件里描述Shader引用的行是下面这样的：

yaml复制m_Shader: {fileID: 4800000, guid: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, type: 2}

你只要把guid从旧值换成新值，材质就指向了新的Shader。用Python写一个替换脚本很简单：

python复制import re
from pathlib import Path

old_guid = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
new_guid = "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"

pattern = re.compile(rf"fileID: 4800000, guid: {old_guid}, type: 2")

for path in Path(".").rglob("*.mat"):
    content = path.read_text(encoding="utf-8-sig")
    if old_guid not in content:
        continue
    new_content = pattern.sub(f"fileID: 4800000, guid: {new_guid}, type: 2", content)
    path.write_text(new_content, encoding="utf-8-sig")
    print(f"updated: {path}")

这里我特意用了utf-8-sig而不是utf-8，是为了兼容带BOM和不带BOM两种情况。Unity的YAML文件两种编码都能识别，但如果你用普通utf-8去读带BOM的文件，BOM字符会混进第一个字段名里，导致解析失败。

为什么不直接用PyYAML去解析？因为Unity YAML带有!u!这种自定义tag，PyYAML默认不识别，会直接报ConstructorError。就算你写了自定义Loader绕过它，序列化回去时也会丢掉tag和锚点，大概率把整个文件弄坏。对这种“只改一个值”的需求，用正则匹配特定模式反而比完整解析更安全。

还有一个关键点：脚本里匹配的pattern越具体越好。别用简单的old_guid.replace(...)，万一这个guid也出现在别的字段里（比如某处记录了一串历史guid），会误伤。把前后缀都带上的完整替换，才是可控的。

3.4 改完之后的验证清单

不管用哪种方式批量修改，改完必须验证。我自己的固定流程是这样：

1. 先git diff，确认改动范围和预期一致，没有多改其他字段。
2. 打开Unity，看Console有没有YAML解析报错。
3. 随机点开几个改过的Prefab或材质，看Inspector是否显示正常，字段是不是预期值。
4. 打开一个引用了这些资源的关键场景，确认物体没有消失、材质没有变粉。
5. 最后跑一次Play Mode或者一次构建，确保运行时没有问题。

无数人说“我明明就改了一个数字”，结果一提交整个场景打不开。多数时候不是数字改错了，而是编码变了、缩进坏了、或者改动落到了不相关的字段上。所以验证这步别省。

4. 合并冲突实战：让Prefab和Scene在Git里不再可怕

4.1 冲突的本质：每一行都是被跟踪的对象状态

Unity的YAML把每个对象的每个字段都拆成了独立行。git做合并时是按行比较的，两个分支如果改了同一行，就会产生冲突。问题在于，Unity场景文件里字段非常密集，哪怕你只是在Inspector里点击一下物体，都可能让几十行发生变化。

更麻烦的是，Unity序列化时并没有考虑“人类友好”，很多字段会在不同版本里调整顺序或增加serializedVersion。两个开发者各自改了一个互不相关的组件，但由于序列化顺序变了，git会看到大范围的行移动，冲突范围被无谓放大。

所以场景和Prefab合并冲突，本质上不是git的问题，而是Unity YAML的序列化稳定性问题。理解了这一点，你就知道为什么一定要用Unity提供的合并工具，而不是指望git自己搞定。

4.2 配置UnityYAMLMerge：Git属性与合并驱动

Unity官方提供一个合并工具叫UnityYAMLMerge，它在Unity安装目录的Tools文件夹下。Windows上大致路径是：

code复制C:/Program Files/Unity/Hub/Editor/2022.3.20f1/Editor/Data/Tools/UnityYAMLMerge.exe

macOS上是：

code复制/Applications/Unity/Hub/Editor/2022.3.20f1/Unity.app/Contents/Tools/UnityYAMLMerge

要让git在合并Unity文件时自动调用它，需要两件事：第一，在仓库根目录放一个.gitattributes文件，声明哪些扩展名使用unityyamlmerge驱动；第二，在git配置里注册这个驱动。

.gitattributes内容如下：

code复制*.unity merge=unityyamlmerge
*.prefab merge=unityyamlmerge
*.asset merge=unityyamlmerge
*.mat merge=unityyamlmerge
*.anim merge=unityyamlmerge
*.meta merge=unityyamlmerge

然后执行git config注册驱动：

bash复制git config merge.unityyamlmerge.name "Unity YAML Merge"
git config merge.unityyamlmerge.driver "'/Applications/Unity/Hub/Editor/2022.3.20f1/Unity.app/Contents/Tools/UnityYAMLMerge' merge -s -p %O %A %B %A"

Windows下命令类似，把路径换成UnityYAMLMerge.exe并注意引号转义。这里的参数含义是：merge是子命令，-s开启smart merge模式，后面四个路径分别对应git传入的base版本、当前分支版本、对方分支版本和合并输出文件。

还要在Unity里开启Smart Merge：Project Settings > Editor > Version Control，把Mode设为Smart Merge。这样UnityYAMLMerge会尝试理解场景结构，而不是纯粹按行合并。

4.3 手动处理一次真实冲突的完整链路

配置好之后，大部分不重叠的改动会被自动合并，但语义冲突依然要手动处理。我举一个实际场景。

假设你和同事基于同一个Main.unity分叉：你给Canvas下的Button加了锚点修改，同事移动了场景里Light的位置。两边各自提交后，git merge报告Main.unity冲突。

因为配置了UnityYAMLMerge，git会自动调用它，它会尝试合并。如果它认为两边改动不冲突，会直接生成合并文件，git接着正常提交。如果它拿不准，会留下冲突标记，你需要手动处理。

打开Main.unity，找到类似这样的冲突段：

yaml复制<<<<<<< HEAD
  m_LocalPosition: {x: 100, y: 200, z: 0}
=======
  m_LocalPosition: {x: 300, y: 200, z: 0}
>>>>>>> feature/fix-light

这里要判断保留哪一版，或者改成新值。大多数情况下，两个人改的是不同字段，冲突标记只出现在极小范围内。处理好后把<<<<<<<、=======、>>>>>>>标记全部删掉，保存文件。

然后打开Unity，确认场景能正常加载，你改的Button和同事改的Light都还在且位置正确。这一步别跳，因为YAML合并工具毕竟不是人，它可能把某些字段合并到奇怪的位置。

注意：如果在合并文件里看到冲突范围特别大，比如几百行连在一起，不要硬着头皮手动清。先用git checkout --ours或者git checkout --theirs恢复某个版本，再重新处理，或者直接在Unity里打开旧版本场景重新做一遍修改，都比逐行清理几百行冲突靠谱。

4.4 减少冲突的工程习惯

工具只能解决一部分问题，真正让冲突变少靠的是工程习惯。我整理了几条实战里非常有效的做法：

• 任务拆分时，尽量避免两个开发者同时改同一个场景或预制体。这个听起来简单，但很多团队根本没意识到这是冲突的主要来源。
• 大场景要拆Prefab。把UI、道具、角色各自拆成小预制体，而不是全部裸放在场景里。预制体越小，并发修改的概率越低。
• 高频修改的基础对象（比如通用的UI面板、通用的武器模型）优先做成Prefab变体，避免在多个场景里重复摆放同一棵树。
• 小步提交。一个场景文件动一次就提交一次，不要攒几十处改动再一次性提交，否则合并时根本不知道哪里跟哪里冲突。
• .gitattributes和UnityYAMLMerge配置要提交进仓库，并确保每个成员都拉到了配置。很多人配好了自己的环境，同事没配，于是每次合并还是走普通git，等于白搭。

5. 团队协作中的其他YAML：CI配置与工具链

5.1 用YAML声明Unity构建流水线

Unity开发中另一块大量使用YAML的地方，是CI/CD配置。GitLab CI、GitHub Actions、Azure Pipelines都用YAML来描述构建流程。对Unity项目来说，最常见的就是用YAML定义一个自动化构建流水线，把打包、跑测试、发布产物全部托管到远端执行。

下面是一个GitLab CI的最小示例：

yaml复制image: unityci/editor:ubuntu-2021.3.45f1-base

stages:
  - test
  - build

variables:
  UNITY_PROJECT_PATH: "."

test-editmode:
  stage: test
  script:
    - unity-editor -batchmode -nographics -projectPath $UNITY_PROJECT_PATH -runTests -testPlatform EditMode -quit

build-linux:
  stage: build
  script:
    - unity-editor -batchmode -nographics -projectPath $UNITY_PROJECT_PATH -buildLinux64Player ./Build/linux/Game.x86_64 -quit
  artifacts:
    paths:
      - Build/linux/

这段配置的核心逻辑是：定义test和build两个阶段，test阶段跑EditMode测试，build阶段执行Linux平台打包，并把产物上传为CI artifact。所有命令都通过-batchmode -nographics -quit让Unity以命令行模式运行，不需要弹出编辑器窗口。

这类YAML配置虽然不在Unity工程内部，但它同样要经过严格校验。一个缩进错误或者字段名拼写错误，CI就会挂掉。而且CI YAML的解析错误提示有时候相当隐晦，排查起来非常考验经验。

5.2 Addressables、DOTween等工具的YAML配置形态

除了引擎自身的序列化资产，很多插件的配置文件底层也是YAML。比如Addressables的Group配置、DOTween的Settings.asset，打开看都是标准的Unity YAML结构。

这意味着你在第2章学到的引用原则，在这些配置文件里同样适用。DOTween的Settings.asset里如果引用了某个资源，它也带guid和fileID。Addressables的AssetGroup配置同样有fileID引用关系。

也就是说，排查“插件配置突然失效”的问题时，不用去翻插件源码，先看它的配置文件是不是YAML，再检查里面的guid引用是否完整、fileID是否有重复。这一套排查思路是通用的。

5.3 在Unity项目里选JSON、YAML还是TOML

Unity项目里不止Unity自己用YAML。写编辑器工具、做数据配置、定义自动化规则时，你经常要选择配置文件格式。三者的定位差别很大，我列一个对比表：

Unity资产序列化选YAML不选JSON，很重要的一个原因是YAML可读性更强，且允许文档中包含多个对象（多个---文档）。JSON虽然解析快，但在版本控制diff时一行就是一大段，根本无法做字段级对比。TOML则在简单键值对场景很好用，但面对场景里那种深层的对象嵌套就力不从心了。

我的选择标准很简单：机器之间交换数据用JSON，人类要维护且结构不深的简单配置用TOML，需要嵌套、注释和长期人工维护的配置用YAML。Unity自身已经帮你做了选择，跟随它的选择通常不会错。

6. 手改YAML容易踩的坑与排查方法

6.1 编码和缩进：两个最隐蔽的坑

手改Unity YAML时，编码和缩进是高发事故区。

YAML标准不允许使用Tab缩进，Unity默认使用两个空格。很多人用脚本批量生成内容时喜欢用四个空格或者Tab，结果Unity打开直接报解析错误。正确的做法是严格保持两个空格，统一用空格，不要用Tab。

编码方面，Unity的YAML文件通常是UTF-8，带不带BOM都能加载。但如果你用脚本写回文件时把编码变成了UTF-16或者ANSI，Unity大概率会报“failed to load”或者打开后字段全部错乱。所以无论是编辑器脚本还是Python脚本，写回时一定要明确指定UTF-8。

还有一个很多人踩过的坑：用VS Code的格式化插件对Unity YAML做“美化”。这些插件是给通用YAML写的，一格式化可能就把!u!标签、锚点的位置重排了，甚至自动给你改成4空格缩进，整个文件直接报废。我只建议用带语法高亮的查看，永远不要对Unity生成的文件做自动格式化。

6.2 引用错乱的典型症状

手误改坏YAML后，症状通常集中在引用的断裂上。我总结了几种最常见的表现：

• 材质或模型变粉色。一般是Shader引用或者纹理引用的guid失效了。
• 组件消失或变成Missing Script。通常是MonoBehaviour区域里的脚本guid匹配不上，或者文件内部fileID损坏。
• 场景打开报错甚至直接崩掉。这是最严重的情况，通常是fileID重复、等号括号不匹配、文档分隔符缺失，整个YAML结构被破坏了。
• Inspector里字段显示红色。说明引用的对象不在了，比如某个数组里引用了一个不存在的fileID。

这些症状的共同点是“对象还在，但链接断了”。排查时先别急着改回内容，先确认引用关系是否完整。

6.3 我的排查顺序和兜底方案

如果你已经手改了一个文件，现在Unity打不开或者显示异常，按这个顺序排查能少走很多弯路：

1. 先运行git diff，查看这个文件相对于上一个可用版本的改动。你的改动应该只涉及预期的几行，如果改动范围很大，说明缩进或格式已经乱了。
2. 检查对应的.meta文件是否存在，guid是否被误改。这是引用问题最直接的来源。
3. 用文本编辑器打开，确认---文档分隔符数量没有变化，每个对象的&fileID没有重复。
4. 如果文件已经完全无法辨认，别犹豫，直接用git checkout -- 文件路径恢复到上一个提交版本，再重新做修改。
5. 如果项目没有版本控制，看看Library文件夹里有没有这个资源的缓存版本，或者找同事要一份可用的拷贝。

配合一个保险习惯：手改任何YAML之前，先copy一份副本或者在git里提交一次。我就是这样，改之前必先提交。哪怕改完发现完全不可用，也能一键回到安全点，而不是在焦虑中对着几千行YAML逐行找错误。

最后再分享一个我个人养成的小习惯：批量改完YAML之后，先别急着做下一个任务，打开Unity把改过的资源挨个过一眼，哪怕只看Inspector几秒。不要觉得这步浪费时间，我吃过好几次亏之后认识到，这几分钟能把九成的手改事故挡在提交之前。