文｜游戏那点事｜零

｜团结引擎，正在走出自己的路。

团结引擎推出初期，Unity中国首先把重心放在开源鸿蒙、小游戏等Global版本暂未覆盖、本土开发者又有明确需求的平台上。张俊波在采访中回忆，开发者往往因为这些适配需求开始使用团结引擎。

项目有这些需求，开发者才会把工程迁过来。等迁移跑顺了，他们又不想长期维护两套管线，于是逐渐把其他平台也交给团结引擎。

（团结引擎2.0发布会现场，Unity中国CEO张俊波登台）

团结引擎由此找到的，并不是一条照着Unity Global再走一遍的路，而是一条从中国开发者的具体需求里长出来的路。

到了前两天的团结引擎2.0发布会（7月28日），这条路又向前走了一截。团结引擎一边补足渲染、性能和多端发布能力，尝试从“特定需求下的选择”变成能够承担完整项目的主力引擎；另一边把团结Codely更深地放进研发流程，让AI不止写代码，还能搭场景、跑测试、改工程。

如果说过去几年，Unity中国首先要证明团结引擎能够服务好本土平台，那么到了2.0，它想证明的已经不止于此：这套引擎正在沿着中国市场的需求，长出自己的技术方向和产品节奏。

一、从本土需求里，长出一套主力引擎

团结引擎从2022年开始研发，2024年发布创世版，2025年正式走到1.0。从开始研发到2.0，前后走了四年。

截至今年7月末，团结引擎下载量已经超过150万，月活用户超过7万；超过1.3万款基于团结引擎开发的小游戏已经上线，车机版则进入了60多家汽车品牌、300多款量产车型。

（团结引擎现场公布的关键规模数据）

这些数字勾勒出团结引擎过去几年的基本盘：小游戏、开源鸿蒙和车机等本土平台。但到了2.0，Unity中国显然不想再让它只在开发者遇到特定平台时才被想起。

这次发布披露了一批更偏底层的能力，包括Virtual Geometry虚拟几何体、实时动态全局光照、动画与特效系统、并行渲染、CoreCLR和移动端HDRP。团结引擎产品经理路平在现场介绍，Virtual Geometry已经可以在iPhone 13上流畅渲染约6亿三角面。

（团结引擎2.0的高画质与跨平台能力覆盖虚拟几何体、实时动态全局光照、动画、粒子与并行渲染）

比单一的性能数字更重要的是，团结引擎正在把高画质能力带向移动端。过去，开发者往往要为高端PC和移动设备维护两套渲染方案；如今，一条渲染管线有机会根据硬件能力自动适配。

在平台覆盖上，团结引擎2.0新增了PlayStation®5、XBOX Series X|S、Nintendo Switch™ 2和Nintendo Switch主机平台的开发支持。把它们与原有的PC、移动端、小游戏、开源鸿蒙和车机放在一起，团结引擎想要形成的是一套覆盖更多终端的生产能力。

（团结引擎2.0展示的平台支持矩阵）

平台数量变多只是表面。对游戏公司来说，更现实的意义，是让一套代码、一套资产覆盖更多终端：同一笔研发投入可以触达更多用户，也少维护一条割裂的生产管线。

这也解释了为什么团结引擎2.0把“提高创作效率”和“让作品走向更广阔的市场”放在一起：前者回答游戏怎么更快做出来，后者回答同一套成果如何覆盖更多市场。引擎的价值，也由此从技术工具延伸到项目经营层面。

也因此，即使AI是这场发布会的主角之一，Unity中国仍花了不少篇幅讲渲染、性能和多端适配。AI可以把活干得更快，但项目最终还得跑在不同设备上，要适配不同性能档位、迁移资产、修Bug、做版本更新。Agent生成得越快，底层工程是否扎实，越容易直接影响最终结果。

二、不追求“一句话做游戏”，而是让AI真正进工程

团结Codely并不是这次才第一次亮相。按照张俊波的说法，Unity中国内部大约两年前就开始用AI辅助引擎研发，今年5月才逐步向外部开发者开放。

（Codely通过同一个Agent连接引擎、IDE、命令行、网页与移动端）

这次发布会展示的，是它从编程助手继续往游戏开发Agent走的过程。Codely可以直接操作引擎，也可以从IDE、命令行、桌面端、网页和手机进入同一个项目。FIFA官方授权游戏《绿茵竞技》的中国版，已经让它参与前后端、引擎操作、服务端和测试等环节。

（《绿茵竞技》中国版已在前后端、引擎操作、服务端与测试等环节引入Codely）

比“它会写什么”更重要的，是代码写完之后，它能不能把结果跑通。

Codely完成修改后，会自己运行Play Mode和测试，读取控制台报错，再结合截图检查结果。如果发现问题，它会继续修改，再跑一遍。Unity中国把这套过程称为Loop Engineering。

（Codely现场演示了通过AutoLoop报告反复检查与优化工程表现）

说得直白一点，它不是把一段代码扔给开发者就算完事，而是要先自己跑起来、看报错、检查画面，尽量交出一份做过基本自检的作业。

这一步对游戏开发尤其重要。现在，让AI快速生成一个Demo已经不是难事。真正磨人的，往往是Demo后面的第十次、第二十次修改：灯光再暖一点，交互往前挪一点，再加一套系统，同时又不能把原本能跑的东西弄坏。

张俊波把这种不断迭代、增加和修改功能的过程称为Delta。在他看来，即使拿到完整的游戏工程，通用模型仍然缺少细小、连续的增量修改语料。

所以，Unity中国一边补Codely的Agent Loop、Skills和上下文管理，一边改造团结Bridge、工程数据格式，以及原本写给人看的文档和API。目的很直接：先让AI看懂项目里发生了什么，再让它动手去改。

张俊波在采访中直言：“我不太相信‘一句话生成游戏’。”

他给出的理由也很直接：如果只说一句话，让AI做出一个游戏，创意就来自AI，而不是开发者。工具真正该做的，是帮那些有想法的人把创意落地。

这和团结引擎此前的发展方式有些相似：不先追一个听起来足够大的概念，而是从开发者每天会碰到的问题入手，把工具一点点做进实际工作里。对一款正在寻找差异化的本土引擎来说，这或许比“一句话做游戏”更有价值。

三、AI越往前走，引擎的价值反而越清楚

如果AI已经能写代码、搭场景，甚至自己做测试，开发者以后还需要成熟的游戏引擎吗？

张俊波的答案很直接：轮子当然可以重新造，但成本未必更低。

成熟引擎已经把渲染、物理、动画等能力做成经过验证的模块。原本一次Function Call就能调用的成熟能力，如果非要从头生成，不仅要花更多Token写代码，还得重新补测试、找问题、做维护。

商业游戏做出第一版远远不是结束。项目还要长期更新，要交给大量玩家使用，出了问题也得有人能读懂代码、找到原因并承担责任。这些麻烦不会因为代码是AI写的就自动消失。

这也是团结引擎2.0最值得琢磨的地方。AI把开发速度提上去之后，引擎的价值可能不降反升——它不仅提供现成能力，还可以成为Agent理解和调用工程的底座，让验证、维护和多端发行有一个相对稳定的基础。

（张俊波以“让开发更简单，让创意更自由”概括团结引擎2.0的产品方向）

从最早服务特定本土需求，到把多端发布和AI能力放进同一套产品里，团结引擎正在渐渐摆脱“Unity中国版”这样简单的理解。它开始形成自己的问题意识，也给出自己的解法。

当然，一套本土引擎能否真正走出自己的路，不能只看发布会上展示了多少新功能，还要看它能否进入真实项目、承受长期维护，并回应AI给开发和发行带来的变化。

会后，Unity中国CEO张俊波接受了现场媒体采访。他还谈到了一个可能影响游戏发行的变化：以后替玩家挑游戏的，可能不再是一条15秒买量视频，而是手机里的AI Agent——它先把游戏玩一遍，再决定要不要推荐给你。

以下是采访的Q&A现场实录（为了提升阅读体验，内容有所调整）。

Q：团结引擎2.0在AI方面最大的突破是什么？

张俊波：核心是从底层让团结引擎对AI更友好。

传统Unity工程落到磁盘上，要么是C#脚本，要么是YAML文件。YAML主要描述项目状态，并不真正反映开发者如何使用引擎、修改场景和迭代功能。因此，我们会深度改造Bridge和数据格式，产生对AI更友好的工程数据。

团结Codely是我们自己开发的Agent。大约两年前，我们内部做引擎研发时就开始使用AI；今年5月，才逐步把它开放给外部开发者。

这种集成是双向的。一方面，Codely要解决Agent Loop、Skills调度和上下文管理；另一方面，引擎本身也要优化。过去的文档和API主要写给人看，今后仍然如此，但也需要增加更适合AI吸收、理解和调度的表达方式。

Q：Codely在开发过程中最大的技术难点是什么？

张俊波：Unity和团结引擎本身是多模态的。大语言模型在Coding和脚本生成方面迭代很快，但制作游戏不是一次性把代码写完，而是在工程里不断增加、修改和调整功能。

我们把这种过程叫作Delta。你可以一句话生成一个游戏模板，但真正的创意通常发生在模板之后：改一个参数、调一种颜色、增加一个系统、改变某段交互。开发者绝大部分时间是在做增量修改。

市场上的大模型没有足够的这种增量语料。即使拿到完整游戏工程训练，也容易学成“一次把游戏做完”，很少学习“把灯变成绿色”这类细小、连续、可验证的编辑过程。

现在通过Codely，我们可以看到开发者反复遇到哪些问题。一方面补齐各种Skills和Tools，另一方面也与清华大学合作，尝试训练更适合Unity和团结引擎场景的垂类模型。

Q：AI已经能写代码、做工具，成熟引擎还有什么价值？

张俊波：引擎本身就是很多功能模块的集合。任何人都可以不使用引擎，重新做一套图形引擎，但Unity能够成功，是因为做了大量经过优化和验证的抽象与“脚手架”。

原本通过一次Function Call调用引擎API就能完成的事，如果选择重新写一套，Token成本会更高。关键在于调用颗粒度：Agent能够直接调用的成熟模块越完整，完成同一件事消耗的Token就越少。

更麻烦的是验证。写一个模块之后，要写多少测试用例才能确认它正确？如果已经有成熟模块，却选择重新生成，不仅要生成代码，还要验证、维护。软件复杂度会随代码量增长，之后再让AI修补，成本可能更高。因此，我们不认为所有东西都从头生成是一条更好的路。

Q：AI给游戏开发带来的根本变化是什么？

张俊波：第一是降本增效，第二是降低门槛。

商业引擎的普及已经大幅降低了游戏开发门槛。AI会进一步提高生产效率，让更多人进入行业，但它不会完全替代专业能力。

做休闲、简单、规模不大的游戏，现阶段完全依赖Vibe Coding可能比较方便；但如果是面向几百万、几千万玩家、需要长期运营的大型游戏，完全依赖生成代码，很可能产生很大的维护风险。

我不太相信“一句话生成游戏”。如果只说一句话，让AI给你做出一个游戏，那么创意来自AI，不是来自你。我们更希望服务有创意的人，让他们把自己的创意做出来。

Q：AI工具加入后，游戏供给和发行会怎样变化？

张俊波：AI提高了工作效率，意味着可以生产更多内容。以前三个月做出来的产品，现在三个星期做出来，大家会觉得可以立刻上线；但随着供给增加，竞争也会更激烈，最终赢的仍然是游戏质量。

我预计，未来买量可能不再是拿一个15秒视频，就决定玩家要不要下载。也许是手机上的AI Agent先替你玩一下新游戏，通过游戏内测试工具评估它是不是你想要的，而不是只根据15秒素材判断。

这会要求游戏更加精品。完成度低、内容少、同质化严重的游戏会很快被筛掉。AI提效后，制作人可以把更多资源放到创意和打磨里，最后行业仍然会回到内容取胜。

Q：从引擎方和发行方的角度看，小游戏市场接下来会怎样发展？

张俊波：两三年前，受微信、抖音H5渲染器限制，Unity游戏要进入小游戏平台，需要做很深的手术式改造。经过团结引擎与微信、抖音等平台几年的优化，现在很多Unity游戏，甚至老项目和传统游戏，也可以高效运行。

以前大家认为小游戏就是“即点即玩”，应该偏向超休闲；现在MMO等重度品类也开始进入小游戏。用户看到加载界面，也愿意等一等再玩。因此，小游戏会越来越精品化。

整体趋势很像2015—2016年手游从2D向3D转换。小游戏也会从2D、轻量、超休闲，转向更接近传统移动游戏。过去小游戏大量营收来自广告变现，现在广告比例逐渐降低，越来越多重度产品以IAP为主。

Q：存量Unity项目为什么会迁移到团结引擎？

张俊波：团结引擎推出初期，很多开发者是因为开源鸿蒙、小游戏等平台的适配需求，开始使用团结引擎做Porting。

那时团队也是逐步建立起来的，工程能力有限，所以我们对增长比较保守，没有进行大规模市场推广，也没有主动鼓励Unity 2022及以前版本的客户迁移。

今年以来，团结引擎的使用量开始加速增长。开发者选择版本很现实：为了上鸿蒙、上小游戏，他们开始使用团结引擎；使用一段时间、建立信任后，又不愿意长期维护两套研发管线，于是逐渐转为用团结引擎做全平台部署。

我们也看到，不少专业团队开始把整个项目迁移到团结引擎。我们的目标是让存量游戏逐步迁移。为此，我们推出了AI迁移工具，可以自动处理老版本升级时遇到的一部分问题，帮助开发者更快迁移。