对话Unity中国CEO：“我不相信一句话生成游戏”

本文来自微信公众号： 游戏葡萄 ，作者：游戏葡萄君

拥抱AI。

“我认同AI会颠覆软件，但不认为它会颠覆引擎行业。”

7月28日，在团结引擎2.0发布会后的采访中，Unity中国CEO张俊波给出了这个判断。当日，Unity中国发布了团结引擎2.0，以及能独立执行游戏开发任务的AI Agent「团结Codely」，意在将团结引擎完全升级为AI时代的游戏生产基础设施。

所谓“独立执行”，是指开发者给出需求后，Codely可以继续写代码、搭场景、跑测试、分析报错和修复问题，最后交付可供检查的结果。

为了完成这套工作流，团结引擎2.0也在不断改造底层数据格式、文档和API，让AI能够理解和调用引擎。除此之外，新版本还升级了渲染等引擎能力，并补上了对主机平台的支持。

发布会后，张俊波在媒体群访期间，聊了聊Codely的开发过程、团结引擎2.0的定位变化，以及AI会怎样影响游戏开发、发行和行业竞争。

以下为经游戏葡萄整理的采访内容：

01

团结引擎2.0：一次新生

Q：如果总结团结引擎2.0这次最大的进展，您认为是什么？

A：这次团结引擎2.0在AI上的方向，我们称为“Agent all in”，用AI创作游戏。我们改造了引擎的底层架构，让AI更容易理解和调用引擎。

传统Unity工程落到本地，主要是C#脚本和YAML文件。YAML记录的是状态，无法完整反映开发者使用引擎的过程。团结引擎2.0会深度改造Bridge并调整数据格式，产生一种对AI更加友好的新数据格式。

Codely是一个类似Cowork的工具。两年前我们内部研发引擎开始接入AI，出于安全考虑，开发了Codely。今年5月，我们把它开放给开发者，并进一步加强它与团结引擎的集成。

这项工作是双向的。一方面，Codely作为Agent，需要完善Agent Loop，包括任务调度、Skill和上下文管理；另一方面，引擎本身也要调整，会提供更多便于AI吸收、理解和调度引擎的模式。

下一步，我们还会用AI加快传统引擎功能的研发，包括渲染和平台适配方面的迭代，也会把神经渲染、世界模型等有用的技术集成到引擎里。

Q：过去大家认为团结引擎相比海外版本稍微落后一些。2.0是否算是团结引擎的一次“新生”？

A：这要从团结引擎的定位变化说起。2022年，我们成立中国合作公司并开始打造团结引擎，早期主要服务中国开发者，补充小游戏、鸿蒙、车机、跨端和开放世界等能力，并没有跟着全球版本更新所有功能。开发者需要全球版本的新功能，仍然可以选择全球版本。

到了2024年底，随着引擎逐渐云化、AI化，编辑器数据和AI基础设施开始涉及境内外切分与合规问题。2025年，全球团队决定后续产品不再面向中国市场提供服务，团结引擎也需要补齐全球版本已有、国内开发者又确实需要的功能。

我们起步晚了两年，团队和研发资源也有限，目前仍在追赶。但我们不会机械地同步所有功能，而是选择全球版本中好用、开发者确实需要的部分进行支持。

2.0会继续优化原有能力，尤其是移动端，同时还会补上Switch、PlayStation等海外平台。另一个重要方向是Codely所代表的AI转型，这部分需要由团结引擎独立推进。

Q：近两年国内自研引擎赛道竞争激烈，一些大厂也有自己的引擎。相比之下，团结引擎的差异化优势是什么？

A：据我们了解，国内真正长期使用自研引擎的大厂已经非常少了。近几年，引擎技术越来越复杂。自研引擎不只要承担维护成本，还要建立生态，并解决新员工上手和老员工流动后留下的问题。

总体来看，自研引擎对商业引擎的影响不会特别大，因为成本会更高。

Q：团结引擎主要利好哪些团队？对这些团队来说，它还能带来多大的提升？

A：中小团队。团结引擎的产品比较成熟，很多功能经过验证，开发者可以相信它所见即所得，不必反复猜测某个功能会不会出问题。对于有丰富创意、表达诉求，且希望做出差异化精品的中小团队来说，团结引擎用起来会比较便捷。

当然，不是说换到大团队那边，团结引擎就不好用了。只是我们发现很多大团队做的是跨端项目，从主机端、PC端扩展到其他平台时，大家首先考虑的是引擎能否深度魔改。在这点上团结引擎存在自己的局限性，因此部分大厂大项目会选择其他方案。

02

Tuanjie Codely：

不会为了AI而AI

Q：Codely开发过程中遇到的最大技术难点是什么？相比能够读取代码库、修改文件和运行命令的通用Agent，它的差异和未来壁垒在哪里？

A：Unity本身是一个多模态的开发环境，大语言模型在编程脚本上的进步很快，但游戏制作不会一次生成后就结束。开发者会在已有工程上不断增加、删除和修改功能，也就是持续做增量修改。

“一句话生成游戏”可以先给出一个模板，真正体现创意的是之后如何在模板上修改。现有大模型缺少这类增量操作的数据。即使拿到完整的Unity工程训练，大模型学到的也更接近一次性完成整个项目，很难处理“把这盏灯变成绿色”之类看似简单的具体要求。

Codely开放后，我们能实时看到开发者遇到的问题，其中有不少频繁出现的简单操作，AI目前仍然做不好。一方面，团队在补齐各种Skill，让常见问题可以快速解决；另一方面，我们也在与清华合作，尝试从底层训练垂直模型。Unity和团结引擎的游戏创作是一个高度垂直的知识领域，我们有机会用规模相对较小的模型，做到更高效、更准确。

这里的差异主要有两个方面，一是行业Know-how，二是数据的准确性和简洁性。使用Unity或团结引擎能完成的事情相对明确，通用大模型则包含大量跨领域数据。即使经过清洗，其中仍可能混有不同版本的重复信息和过期知识，直接用通用模型操作引擎时，问题还比较多。

我们内部把界面称为“左边”和“右边”：左边是对话框，右边是Agent需要主动操作的引擎。现阶段，从左边理解需求到右边准确执行，中间仍有不少问题。垂直Agent可以让这个过程更可控。

我们的目标是，在Unity这个特定场景里，让300B模型达到通用2.8T模型的处理效果，同时降低Token、上下文和整体调用成本。垂直知识，以及Agent与工具之间更深的耦合，会构成Codely的差异。

Q：Codely目前使用了智谱的模型。你们选择模型的标准是什么？未来是否会接入更多模型？

A：我们的模型选择是开放的。现阶段主要使用智谱，因为Codely最常处理的是编程和编辑器操作，很多任务最终都通过脚本实现，所以会优先选择编程能力强的模型。

目前也有一些问题。GLM还不是多模态模型，需要先切换到VLM读图，再把信息转回GLM，中间可能发生信息损失。我们一边等待后续GLM补充多模态能力，一边在Codely内部弥补模型切换造成的缺口。目前，团队也在部署Kimi-3。

最后的标准很实际：一是模型能完成任务，二是性价比合适。现阶段GLM-5.2在能力、可用性和性价比上是首选，不过模型迭代很快，我们每个月都在更新。

Q：AI辅助游戏创作从“勉强可用”跨越到“稳定好用”的决定性因素是什么？Codely现在已经到了“稳定好用”的阶段吗？

A：这件事要看使用者的情况。Codely上线十周后，我们看到会用AI和不会用AI的开发者差别很大。用得比较多的人知道怎样引导AI解决问题，任务成功率会高得多。一些新增用户的次周留存大约只有30%至40%，因为他们问不出有效的问题，遇到困难后很容易放弃。

目前大约三分之一的用户每天会在Codely里投入两小时到十几个小时，基本已经改变了工作方式。公司内部一半以上的开发工程师在用自然语言对话，很多人甚至直接用麦克风工作。

是否可用实际上取决于使用者的经验。有经验、愿意学习和容忍AI现阶段缺点的人，往往能把它用好；另一类适应很快的是“AI原住民”，一些刚毕业的学生已经习惯通过AI完成编程任务。

Q：有开发者会用AI自己开发编辑器，将重复且消耗算力的功能固化下来。这会不会与Codely的商业模式形成矛盾？

A：引擎里的每个功能模块，理论上都可以自己写。但Unity能够发展起来，是因为它已经做好了大量经过优化和验证的“脚手架”，开发者不必每次从头开始。

如果开发者要重复开发这些能力，编写脚手架同样会消耗Token和算力。本来一次Function Call、调用一个Unity API就能完成的事情，如果先自己写一套API，成本反而更高。成熟引擎把功能封装到足够大的颗粒度，同一项任务需要的Token会更少。比如实现一项抗锯齿算法，在Unity里可能只需要勾选一个选项；如果选择重新编写整套算法，就会产生更多Token消耗。

Q：Codely在训练数据合规、生成内容版权界定方面做了哪些设计？后续会不会提供配套的版权保障机制？

A：合规和知识产权非常重要。目前模型训练还处在比较早期的探索阶段，首先会使用合成数据。内部产品经理和测试团队会根据产品文档、教程，生成Unity自己的第一手数据，这些数据更加准确、精练，也更有效。

未来是否会使用线上开发者的数据，我们会在服务条款中明确说明。针对部分个人用户或非付费用户，可能会按照通用协议将数据用于训练；如果企业用户选择不提供数据，我们会尊重并严格执行。

Q：现在一些团队在尝试机制建立在AI能力上的“AI原生游戏”。Codely对这类游戏有没有相应规划？

A：我们不太在意游戏是否被称为“AI原生”，还是要看AI具体用在游戏的哪一部分。AI可以生成数值、叙事和渲染，也可以参与对话、实时调整世界。未来端侧AI还会帮助开发者降低算力成本，为游戏提供更多个性化和多样性，世界模型、动态故事等能力也可以通过模型实现。

但游戏，尤其是数值系统，需要相对确定的规则。如果交给AI，还要考虑未知的运营成本，以及传统引擎能否实现同样的体验。我们更关心玩家想玩什么、游戏本身是什么。团结引擎会拥抱AI，也有自己的技术路线，但不会为了AI而AI。

03

AI时代：

“我不相信一句话生成游戏”

Q：您认为AI给游戏开发带来的根本变化是什么？随着更多没有编程和游戏开发经验的人进入行业，游戏引擎公司的价值会发生什么变化？

A：降本增效肯定存在，第二个变化是降低门槛。商业引擎普及前，游戏公司往往要先自己做引擎，行业参与者很少。商业引擎出现后，团队不用再从引擎开始做起，生产效率已经提升了很多倍，但他们仍然需要会用引擎的程序员。AI会进一步降低这部分门槛，让更多人进入游戏行业。

过去要做出一款好游戏，绕不开优秀的程序员和美术，需要创意、程序和美术同时到位。一个制作人背后，可能要有十个工程师和美术支持。随着AI能力提升，这个比例可能逐步反转，更多人负责想法和创意，AI完成执行工作。一个Agent不够，还可以同时使用多个Agent，前提是有足够的Token。对游戏引擎公司来说，用户和创作者越多，当然是一件好事。

Vibe Coding确实能大幅提效。对于休闲、简单、规模不大的游戏，现阶段已经比较方便。但是面对拥有数百万、数千万用户的长期运营项目，完全依靠Vibe Coding，后续代码可能很难维护。

我们公司已经有很多代码由AI完成，但如果工程师从未真正看过自己提交的代码，等Bug报告进来，很难知道该找谁负责。当然也可以让AI修Bug，但调试堆栈的成本可能比生成代码更高。

我不太相信“一句话生成游戏”。游戏是创意行业，一句话本身能承载多少创意？如果只说一句话就能生成游戏，最后的创意可能其实来自AI。我们更希望服务真正有创意的人，让他们把自己的想法做出来。

Q：AI 3D公司和游戏引擎公司目前是生态上的合作关系。随着AI替代更多软件能力，游戏引擎会不会最终被改变或取代？

A：我们是影眸商业化后的第一个客户，也在和其他AI 3D公司合作。游戏开发除了在编辑器里写代码、组装功能，还有很大一部分投入用于3D资产、纹理、贴图和动画。这些内容过去主要来自Blender、Maya等DCC软件，也可能来自Asset Store等素材渠道。Unity不直接生产这类资产，因此AI 3D公司天然处在上游，是我们的合作伙伴。

我不太明白为什么很多AI公司进入游戏行业后，都想做引擎。全球引擎行业的规模可能只有10亿美元左右，游戏行业本身的空间要大得多，也足以容纳更多公司。

我认同AI会颠覆软件，大幅提高软件生产效率，但不认为它会颠覆引擎行业。它更可能改变游戏行业的格局，对引擎公司来说反而是件好事，可以扩大引擎在游戏开发中的覆盖范围。当然，这只是我的个人判断，其他人可能有不同看法。

Q：国内开发者对AI工具进入核心开发环节的真实接受度如何？他们提出过哪些负面意见？和您最初的设想有落差吗？

A：游戏行业整体比较支持AI，但不同环节的接受度不一样。美术和模型直接呈现在玩家面前，一旦有明显的“AI味”，大家很容易看出来，因此一些公司会用AI做原型，正式上线时仍会重新制作。

Unity主要处理工程、代码、组装和优化，很多结果不会被终端玩家直接看见。游戏公司对在这些环节使用AI提效整体没有那么排斥。

最近大家主要警醒两个方面。第一个是IP和数据安全。5月之前，很多团队都在追求“Token最大化”，想办法使用最新模型来证明自己对AI的理解。过去几个星期，我们收到的反馈谨慎了很多。大家开始收紧外部AI的使用，也会有更多私有化部署的诉求，尤其不希望尚未上线的重大项目资料进入外部模型。大模型公司可能承诺不使用这些数据训练，但开发者仍然会担心潜在漏洞。

第二个是综合成本。最近有一种说法叫“AI比人还贵”。AI生成代码时未必比人贵，问题常常出在维护阶段。用好AI需要一个磨合过程。我们相信AI能提高工作效率，也会改变工作结构，但这些变化会逐步发生，很难一步到位。

AI的权限同样是风险。为了让它完成更多任务，使用者往往会开放很高的权限，它可能执行一些意料之外的操作，给公司的知识产权和隐私带来隐患。未来使用AI肯定是大方向，但短期内，一些团队会选择相对谨慎的方式。

Q：如果引擎公司的程序员能用AI写代码，你们的招聘标准会发生什么变化？

A：我们希望他既会用AI，也有扎实的编程能力。手写代码未必是最重要的，读懂代码和Debug仍然是刚需。现阶段，人最终要给AI兜底。大模型公司可能不太在意Token成本，但我们不可能为了一个引擎Bug，让AI在几千万行代码里反复穷举，有经验的工程师仍然很重要。

至少在很长一段时间内，从事引擎开发仍然需要代码、算法、数据结构、系统架构和图形渲染等基本功。

AI可以显著缩短新人的上手周期。过去一个毕业生进入引擎团队，可能三个月后才能开始修第一个Bug；现在AI可以帮他快速理解代码，但我们仍然要求他真正看懂这些代码。

Q：现在越来越多大厂从业者出来组建小团队，甚至用多个Agent开发游戏。您怎么看OPC和小团队兴起的趋势？团结引擎2.0会提供哪些支持？

A：比起一人公司，未来的小团队可能会更多。几个有主意、有创意的人凑在一起做项目，会成为一种趋势。现阶段团队里仍然需要有人懂程序，为AI生成的代码兜底，美术也很难完全缺席。除非一个人本身就是全能型选手，否则真正的项目依然需要协作。随着AI能力提高，这类小团队会越来越多。

另一方面，AI会降低存量项目的维护成本和人力需求，也可能从这些项目中释放一批有经验、对游戏行业有深入理解的从业者。他们会出来组成更多小团队。团结引擎的AI能力，希望更好地服务这些人。一方面，让更少的人也能维护存量项目；另一方面，让他们有余力开发更多内容。

这些大厂从业者出来创业，通常不会只做非常轻量或超休闲的产品。他们可能更希望做一些有意义、有创意、相对严肃的精品游戏。

Q：Codely等AI工具加入后，会不会让行业的新游戏数量进一步膨胀？在发行和竞争方面，您会给开发者什么建议？

A：AI提高了工作效率，团队也能生产更多内容。过去需要三个月完成的游戏，现在三周就能做完，很多团队仍按过去的完成度和内容量上架，于是大量新应用迅速进入市场。

供给增加后，竞争也会更激烈，游戏的筛选机制可能随之变化。现在很多人看一段15秒买量视频就决定是否下载，未来可能由手机里的AI Agent先试玩和评测，再判断游戏是否符合用户需求。选择维度变多后，完成度低、内容少、彼此雷同的产品会更快被筛掉。

我认为行业最终会形成动态平衡。效率提升带来的变化不只体现在数量，也会体现在玩法广度和制作精细度上。过去很多项目上线，是因为钱和时间用完了，只能放弃修Bug、砍掉功能。今后团队可以把更多资源用于落实制作人的创意，做出更完整的内容。眼下这批达到过去标准的游戏只是一个阶段，最后仍然要靠内容赢下来。

Q：团结引擎在国内小游戏市场处于比较领先的位置。您怎样判断这个市场的下一阶段？研发厂商接下来面对的问题会更多来自技术，还是发行？

A：2023年以前，受微信、抖音H5渲染器限制，Unity游戏基本无法在小游戏平台直接运行，需要进行很深的定制。经过几年与微信、抖音等平台的共同优化，现在大多数老Unity项目和团结引擎项目都能运行，可能只有不到1%的重度游戏仍然无法适配。

过去大家对小游戏的理解是即点即玩、偏超休闲，甚至认为游戏如果不能在五秒内启动，用户就会离开。现在用户习惯已经发生变化，愿意为想玩的内容等待更长时间，小游戏也逐渐成为一种新的获客方式。当然，前期流程和新手阶段仍然要控制长度，让玩家尽快进入体验。

我判断，小游戏会经历类似2015年至2016年手游从2D转向3D的过程，从轻量、超休闲逐渐走向接近原生移动游戏的形态，也会在一定程度上分流APK和iOS游戏。它的营收模式正在从广告变现转向IAP，越来越多严肃、重度的产品开始出现。部分厂商会走向精品化，开发方式也会从“一周做十个游戏”，转向在单款产品上投入更多资源。

小游戏的发行方式，也会随之变化，单靠15秒素材吸引用户，这个打法会越来越难用，产品质量会变得更重要。AI可以进一步降低精品游戏的制作门槛，让团队在相同时间和投入下，把游戏做得更好。总体来看，小游戏还会继续向精品化发展。