AI 写的 Unity 代码能编译、进游戏却坏了，是为什么？

10 月 16 日那篇 devlog 举了三个编造名字作例子：GameObject.FindByTag、Rigidbody.AddVelocity、transform.GetChildByName。Devlog 直说它们不存在，给的修复是一条规则而不是代码补丁：告诉 agent 只用有文档的 API，拿不准就说拿不准、不要猜。这类失败只是烦人而不是危险，因为它在你能看到的地方打断构建。真正的危险在它周围的工作流：如果你不编译就接受 AI 输出，编造名字会躺在你以为已完成的文件里；如果你不查文档就粘贴同一助手给的修复，可能用一个编造名字换另一个。

静默失败反过来：能编译，游戏一直跑，直到恰好那个错误的时刻。第一项是假 null。UnityEngine.Object 的官方文档解释，某个实例的原生对应物在托管对象被垃圾回收前被销毁时，该实例可能处于 detached 状态。在这种状态下，对象通过 Unity 自定义的相等运算符比较时仍等于 null，但它并不是真正的 null：用 Object.ReferenceEquals 对 null 比较返回 false，而且该对象不能用来调用方法或访问属性。同一文档页还说明，null 条件运算符和 null 合并运算符不受 Unity 对象支持，因为它们无法被重写以同样对待 detached 对象，只有在确认被检查对象绝不会 detached 时才安全使用。

10 月 25 日那篇 devlog 完整给出了改名例子。AI 被要求清理脚本，把序列化的 speed 字段改名为 moveSpeed。Unity 按字段名存储 Inspector 值，所以 devlog 说，所有把 speed 调到 7.5 的 prefab 和场景都会悄悄回到默认值 5。没有任何报错，开发者几天后才发现，游戏手感不对了。7.5 变 5 的数字请当作作者例子，不要当作 Unity 文档结论；文档确认的是机制与修复。FormerlySerializedAsAttribute 文档用一句话说明用途：用这个属性改名而不丢失序列化值。它是仅编辑器属性，接受旧字段名，文档例子把 hitpoints 改名为 health 同时保留数值。公开变量默认序列化，私有变量需要 SerializeField 属性。

同一篇 devlog 还提到了第三种静默模式——订阅事件后不取消订阅，但本文范围只限标题里的三项检查，那个模式留待以后。贯穿三项的共同教训是检查顺序：编译错误由编译器免费帮你检查；静默 bug 只有你主动去找才会被检查，所以下面的清单按静默程度排序：假 null 第一、改名第二、编造名字第三，因为第三项至少会出声。

下面的步骤都不是所谓 devlog 作者针对某款已上线游戏的修复，因为没有点名任何已上线游戏。它们是依据文档与 devlog 例子推导出的检查规则，写出来是为了让你周一早上就能用在自己的项目上，而不需要碰别人的代码。