我整理了一下这些年做过的 Unity 工程：从 VR/AR 到游戏，从 PC 到移动端，再到自动驾驶仿真等若干个工程。但翻到最后我惊讶地发现一件事——几乎所有的工程，都跑在 Unity 2021 LTS 以及更早的版本上。

现在是 2026 年。我不由得想问自己一个问题：

我还能用 2021 LTS 撑多久？

这不是一个人的焦虑。这是一个行业现状。而更让我不安的是，Unity 全球和团结引擎这两条线，似乎都离我（一个普通移动端业务开发者）越来越远。

一、割裂之后：围绕引擎的"小作坊"生态

自从 Unity 拆分成了 Unity 全球与 Unity 中国，"团结引擎"便进入国内开发者视野。它从"本土化"的角度出发，为国内做抖音小游戏、开发鸿蒙系统、做车载 HMI 的提供各种解决方案。团结引擎的基础是 Unity 2022 LTS，换句话说，如果不是做这几个垂直领域，团结引擎对开发者而言就是"2022 LTS"的换皮。

同时，团结引擎的整个运行的 Runtime 还是基于 Mono。在 CPU 侧大规模 C# 逻辑处理上，Mono 效率很难有大提升。主要卡在几个地方：

• JIT 编译优化（这正是 Unity 7 用 CoreCLR 要解决的）
• GC 垃圾回收
• 多线程调度
• SIMD 优化
• 泛型优化
• 内存访问效率

每一项单拎出来都能写一篇长文，但合在一起就是一句话——移动端上跑重逻辑，Mono 拖后腿。

在 7 月 21 号 Unity 全球宣发会上，Unity 官方提出了 Unity 7，其中最关键的提升是使用 CoreCLR 代替 Mono。CoreCLR 和我们熟悉的 IL2CPP、Mono 在对 Unity 中撰写的 C# 代码的解析过程如图：

放一张对比图，展示三者对 C# 代码的编译与运行时处理差异：Mono（JIT/AOT 混合）、IL2CPP（转译 C++ 再编译）、CoreCLR（现代 .NET 运行时）。

幸运的是，Unity 官方承诺"IL2CPP 是一个长期存在的解决方案"。对国内开发者而言，这点至关重要：我们大多数岗位的业务在移动端，而在 Android 和 iOS 上，CoreCLR 还存在不少挑战。尤其是在 iOS 上，系统不允许动态生成机器码，JIT 这条路被苹果的政策堵死。所以移动端短期内指望不上 CoreCLR，IL2CPP 仍是主力。

这就解释了一个悖论：Unity 7 把 CoreCLR 当核心卖点，但对以移动端为主的国内开发者，CoreCLR 的红利基本摸不到。

是否意味着 Unity 7 作为"下一代"，对国内移动端开发者的影响，是不是就远比想象中小呢？

二、渲染：URP 收敛与团结引擎的追赶

现代 3D 引擎要看三个维度：Runtime、渲染，以及越来越重要的 AI 集成。讲完 Runtime，我们来看渲染。

Unity 7 在 7 月 21 号的发布会 PPT 的第 65 页提到了一句话：

“URP is our Focus.”

Unity 7 彻底拥抱 URP，保留 HDRP，废弃 Built-in 渲染管线，这是一次干净的结构性收敛。其实，团结引擎这些年也开发很多硬核技术：虚拟几何体 VG、TuanjieGI 全局实时光照、屏幕空间与距离场光追，样样不弱，并且这些技术已经应用在 Android 和 iOS 上。

在这一方面我认为团结引擎领先 Unity 7 有 1 到 1.5 年。

当然我做过的项目更扎心，清一色是 Built-in 渲染管线的 2019、2021 LTS。我相信我不是个例，甚至可能是大多数。在国内游戏/应用开发圈，Built-in 管线依然可能是"事实上的长期支持版"。

放弃 BiRP 对新项目或许是好事，但对于我们这些 Built-in 存量项目来说，这反而意味着——我们彻底地留在了过去。

三、AI + Unity：当前最大的变量

除了讲 Runtime 运行时和图形渲染，在 AI 的时代，我们一定会讨论"AI + Unity"。作为当前最大的变量，抛开 AI 谈两个版本的未来是不完整的——如果是在 4 年前 ChatGPT 还没出现以前可能还行。

AI 在开发上目前还没有区分移动开发、PC 开发，但可以分为：

• 代码撰写
• 资源生成
• 编辑器 Agent
• Runtime 下的 AI 推理支持

前三个属于 Editor 侧。Unity 7 的思路是提供 AI Assistant（编辑器交互界面），AI Gateway 做"连接器"，允许接入 Claude Code、Cursor、Codex 等代理。团结引擎则是推出 Codely，是 Tuanjie AI 的"编程助手"，主要专注于代码生成和 Unity 编辑器下的自动化任务等。如果国内开发者希望体验团结引擎的 AI 编程能力，那么就需要去了解 Codely 工具。

对于开发者来说，AI Coding、Editor Agent 的进度或许是影响不大的——毕竟以前自己完成日常项目需求时通过 VSCode 的 Cline、或者直接 Codex 等编辑器工具也能实现，并不一定要在 Editor 下做很多事情。说白了，两边在 Editor 侧打个平手。我觉得真正拉开差距的——是 Runtime AI 推理能力。

但当我们有在 Runtime 下 AI 推理小模型的需求时（当然大模型的边缘推理在 2026 年还是无法实现！），Unity 的 Sentis 工具就显得十分重要。

在这方面，团结引擎因为是基于 Unity 2022 LTS，目前最高仅支持 Sentis 1.6.0——这是旧一代的版本，在 2024 年 7 月发布，已经过去 2 年，团结引擎也没法跟进迭代，因为 Sentis 已升级到新一代 2.x 版本，感兴趣的开发者可以去搜索 com.unity.sentis。

目前 Unity 6 已经最高支持到了 Sentis 2.6.1（毕竟 Unity 7 还没真正出）。未来在 CoreCLR 的加持下，使用 Unity 7 进行 PC 开发的开发者将得到更多的收益！

四、Vibe Coding：当对话变了性质

在 AI 爆发的趋势下，可能讨论不该是"国产引擎 vs Unity 全球"的二选一。

现在在 Unity 技术群里，开发者聊的，已经不再是代码细节、功能模块怎么写、Bug 截图分析。聊的全是——

• 用哪个大模型？
• Token 消耗多少？
• 价格多少？
• Token 上限多少？

这就是所谓的 “Vibe Coding”（氛围编程）。
当对话从"怎么实现"变成"用哪个模型、烧多少 Token"，这件事的性质就变了。代码本身在贬值，指挥代码的判断力在升值。

五、写在最后：开发者应该怎么办？

我做过游戏、做过数字孪生和自动驾驶仿真，比较了解虚拟仿真当前的现状。之前写的一篇文章主要表现了我对仿真的"不乐观"看法，现在我觉得具身智能仿真或许是下一个方向。

我也做了一些相关的调查研究，收集归纳以后再发出来。**“Unity + 机器人"或者更广泛地说"3D + 机器人”**是下一个调查主题。