本文来自微信公众号： 游戏葡萄 ，作者：游戏葡萄君
何去何从？
如果离游戏行业的距离没那么近，大多数圈外从业者或玩家对「AI x游戏」的认知，很可能还停留在AIGC层面——说白了就是，这家公司是不是偷偷用AI美术素材了？
但圈内人应该都有个感觉：游戏公司，恐怕是对AI技术应用嗅觉最敏感、FOMO最深、策略最激进的群体之一。在AI浪潮卷起来之后，AI应用对游戏公司来说，已经完全从可选项变成了必选项。
这也让游戏行业，成了为数不多把AI利用得极其普遍，普遍到每一根毛细血管上的行业——根据中国音数协游戏工委与清华大学的专项调研，AI在游戏研发环节的应用率已达86.36%。
昨天（5月20日）阿里云AI游戏分论坛
也提到了相关数据
最近，葡萄君和一些从业者聊了聊这件事，他们也提到：过去两年，如果去问游戏公司的老板们对AI的态度，得到的回答大多是「会不计成本地尝试，绝不能掉队。」
到了2026年的GDC，AI x游戏的议题突然飙升到700多个，行业风向也在这时突然变了：「以前大家问的，是‘AI能帮我做什么？’；后来大家问的，是‘游戏行业有哪些成熟场景，我们需要怎么做？’」
不过在另一侧呢，如此普遍的AI应用，也没有大多数游戏人想得那么轻松。
可以说，今年就像是一个临界点：AI以罕见的速度渗入了游戏行业的骨髓。但渗透得越深，各种团队碰到的硬骨头越多，再强的大厂用起来都一样要焦虑。
昨天，葡萄君正好在阿里云AI游戏分论坛听到了不少信息，其中包含米哈游、阿里云的分享，也有独游工作室、TapTap相关团队的讨论，或许可以归纳起来，供大家参考参考。
01
关于AI Agent，
米哈游崩坏IP有什么前沿实践？
虽然不是渗透速度最快的，但AI Agent/Vibe Coding这种AI编码层面的技术应用，应该是在行业里引起最大反响的一项。
这一点大家多少都有点感受吧——过完年之后，OpenClaw突然间爆火，太多人都好奇和追逐起了原本陌生的AI Agent。游戏行业不少团队尤其如此，陈海生就提到，那一阵有不少技术/运维负责人，都去找他探讨AI Agent的技术边界与数据安全顾虑问题。
而在Claude Opus4.6、Qwen3.6-Plus上线之后，Vibe Coding的门槛更是被压到了地板上，AI的应用在游戏行业也开始大规模蔓延了——现在几乎没有研发不用AI，很多公司会直接给员工每个月2000~4000元，或是一定Token量的固定报销额度。前一阵我们写过的吉比特内部Vibe Coding大赛，甚至是无限Token、没有任务、只有奖品。
这个层面的技术应用，对游戏研发到底有多大影响？其实目前还很难说得准。
不过，米哈游已经在这方面探索了很久，他们还真的总结出了一些实际的认知和应用方式：
首先，AI Agent的发展应用可以分为3个阶段：阶段一是简单的聊天和代码补全，阶段二是能理解整个工程上下文的AI辅助IDE，而第三阶段，也是崩坏项目组正在展望与探索的方向——让多个Agent协同，像数字员工一样自主完成任务。
在Agent这个词火起来之前，米哈游内部就已经开发了多个自研Agent平台，来匹配不同的应用场景。这次峰会，主要分享了崩坏项目组内应用比较多的Echo Agent——一个能托管多个Agent、执行复杂任务的生态平台。各个业务部门可以在这个平台上创建自己的Agent模板，用来做包体冒烟测试、配置助手、PPT生成等等。
接入多模态工具后，这个平台还能实现分析游戏截图、UI、游戏资产结构等功能，介入更复杂的研发场景；甚至他们还建了一个内部Skill社区，让同事可以用Agent写下Skill，一键分享给同组，大家协作起来更能节省工作量，避免重复踩坑。
崩坏IP组还尝试用Echo Agent来查找了冒烟测试的崩溃原因：他们发现，随着基础模型能力的提升，只要给Agent提供一个足够健壮的执行循环，并挂上足够多的分析工具，模型就能自主定位bug。
除此之外，如果策划需要快速验证一个想法，也可以用这个平台搞定：崩坏IP组把Agent接入了开发引擎和内部IM工具，让策划可以直接向Agent描述自己的需求，自动构建白盒测试。在阿里云游戏分论坛上，崩坏系列AI NPC&Gameplay技术团队负责人银河就展示了几个内部案例——包括赛车、2D战斗等小玩法。
看到这些，你或许能意识到，AI Agent/Vibe Coding应用的想象空间，已经发展到很多人的想象力都跟不上了……阿里云智能集团公共云事业部高级解决方案架构师陈海生也提到，「很多运维原来自己也要写代码做系统，但现在不是写代码，而是写需求——把需求描述清楚，晚上交给千问大模型让它自己跑，第二天生成代码，植入到自己的工程里。」
但对大多数团队来说，最大的问题在于：市面上大把的AI大模型，其实根本不懂游戏开发怎么做。人为的研究和底层适配，目前是没法避开的。
换句话说：API调用不等于工业化生产，模型能力不等于产品能力。
银河在现场就分享了一个他们遇到过的痛点：绝大部分大模型的Coding Agent只擅长纯文本或常规网页开发，但游戏研发重度依赖Windows底层API。如果大模型连Windows的命令行或Power Shell都用不溜，它根本无法介入真实的研发环境。
所以在开发Echo Agent的时候，他们团队专门针对游戏开发的特殊环境做了大量适配。比如游戏打包管线重度依赖Windows底层API，市面上的主流AI Coding工具对Power Shell或Windows命令行支持很弱，Echo就对这些做了原生封装，让Agent能在Windows环境下跑通。
这其实就是横在游戏团队面前的AI工业化门槛。在论坛的圆桌环节，青干工作室制作人追青也吐槽了这一点：「真正开发起来你才会发现，AI根本不是接个API、给套提示词就能开干的。我们之前跑Benchmark去测并发，结果发现API直接挂了，排查下来是因为那段时间龙虾太火，每到整点大家都去请求，接口根本扛不住。」
这就意味着，如果没有一套强悍的基础设施兜底，AI很有可能让整个管线停摆。
在昨天的峰会上，阿里云发布的Agentic Cloud架构，或许正是为了解决这个问题。全新上线的千问云聚合了Qwen、Kimi等150多款主流模型API，将所有能力封装为「Agent可直接调用的Skills和CLI工具」，推动云服务从传统资源售卖转向「按Token卖智能」的新模式。这意味着游戏团队不再需要自己去适配多个模型的接口，而是可以通过统一的Agent调用层来完成复杂任务。
02
营销侧真刀真枪的管线化
如果说代码层面更多还在探索，那美术和营销管线的AI应用，真可以说已经到了真刀真枪算ROI的阶段了。
具体怎么做，葡萄君应该也不用赘述了，各家有各家的用法和认知。不过在这个环节，大部分游戏团队踩过最大的坑在于：以为买个大模型的API，就等同于拥有了工业化生产力。
但现实情况是，很多团队接入生图API之后，才发现大模型每次出图的效果都不一样，角色一致性极差，废稿率高得离谱。最后算下来，改AI图耗费的时间之久，比直接画还更划不来。
行业数据显示，早在2024年，就已有游戏公司在真实项目中，通过AI美术生成节省了约80%的美术成本——但前提是管线跑通。在管线跑通之前，试错成本可能相当高昂。
为什么会这样？阿里云对接过大量游戏团队，他们很有发言权。阿里云内部游戏专家告诉我，这种摩擦在大多时候，本质上是业务语言与机器语言的错位。
他举了个例子：在实际生产中，主美或制作人的需求，通常是角色要好看、符合设定。但大模型听不懂这种感性描述，需要技术团队先把需求翻译成工程参数——参考图权重给到多少？面部相似度的阈值卡在零点几？
有过这些轻量微调，再加上类似ComfyUI这种节点化的工作流，把工作拆分成一个个可控的自动化节点之后，AI美术生产才真正开始对游戏研发有意义。
在这一点上，TapTap在营销素材方面的实践，算是一个典型的管线化案例。
过去，如果要帮一款游戏制作买量广告视频，流程非常传统：整理核心卖点、找外包团队策划、人工剪辑、反复沟通修改，周期和花销都不低。
为了把这块成本打下来，TapTap基于阿里云百炼平台的Dify知识库与Agent方案，构建了一条端到端的自动化流水线：
第一步，由Dify知识库结合大语言模型，自动生成多个版本的广告文案；
第二步，大模型将文案关键词转化为查询指令，在ADB（云原生数据仓库）中通过向量检索，自动找回匹配的原始游戏素材；
第三步，工作流嵌入Python节点，自动完成视频片段的拼接、添加字幕和语音；
第四步，调用Qwen3.6-Plus大模型，通过视觉能力对批量生成的视频进行理解和打分，把最优解挑出来给到开发者。
这一套流程之后，整个素材的生成时间就可以被压到分钟级别。
值得补充的是，Qwen3.6-Plus在多模态能力上进一步升级，模型能够更有效地整合跨模态信息，并完成更复杂的分析与决策。因此新版本在处理图表、界面截图、产品摄影和设计排版时的准确率大幅提升，这对游戏营销素材的AI自动生成和审核，意味着更可靠的底层支撑。
当管线被AI重构后，一个直接的结果是：游戏公司的组织形态正在发生变化。
在论坛的圆桌上，Dirichlet（原TapADN）VP曹擎宇就提到了一个很现实的观察：在AI之前，那种一两人的游戏工作室虽然存在，但非常少。而现在有了AI补齐代码、美术的短板，再配合上TapTap制造这种提供商业化闭环的工具，这类「一人工作室」直接出现了井喷现象。
曹擎宇认为，在这种趋势下，精简的团队就得围绕明确目标快速迭代、有错犯错，只要方向对就行——这可能也会是未来越来越多中小团队的常态。
03
AI原生游戏，知易行难
在降本提效之外，还有一个AI话题是游戏行业绝对绕不开的：AI Native Game。
其实目前吧……大部分人还会觉得AI Native Game是个伪命题。行业里呢，很多团队对AI原生游戏的理解，也还停留在给NPC加个大语言模型对话框。但真正下场做的人会发现，这个想法属于知易行难。
正好，最近青干工作室推出了国内首款AI原生历史策略游戏《历史模拟器：崇祯》。我们可以用它来讲讲具体的实践细节。
就像所有人对AI Native Game最基础的想象那样——《崇祯》里没有预设分支，玩家直接用自然语言下令，AI就会实时推演蝴蝶效应。比如你决定裁撤驿站，后续可能引起的变化可能就会走向激化民变、逼反李自成。
听起来很自由，但制作人追青在论坛上倒了一肚子苦水：如果要真正在底层跑通这个逻辑，开发团队要面临的，是一个完全颠覆以往游戏架构的烂摊子。
首先被颠覆的，是AI的记忆处理方式。
在常规的对话场景里，大家习惯用超长上下文来让AI记住过去聊了什么。但在《崇祯》这种重度策略游戏里，单局有100个回合，每回合玩家输入上千字，整个游戏跑下来消耗的，可能就是几千万甚至上亿Token。
追青发现，如果硬塞上下文，不仅成本爆炸，而且大模型的检索能力会断崖式下降。更要命的是，AI会被玩家的情绪带着走。如果玩家表达出强烈的某种倾向，AI很容易迎合玩家，导致推演失去客观性。
为了填这个坑，《崇祯》放弃了长上下文，转而采用了一套在游戏里极少见的架构：步进式状态机+底层数据库。
简单来说，他们构建了一个包含明末财政、军事、灾荒等数千个维度的底层数据库。玩家每下一道圣旨，AI只负责做两件事：理解自然语言，再实时生成Function Call代码，去精准修改数据库里的对应数值。这个操作，允许AI把过去的记忆全部卸载给数据库，只专注于推演当前这一步。
在阿里云帮他们调试的过程中，还有过一个典型的案例：玩家明明已经成功把海盗郑芝龙招安成了朝廷命官，但在随后的推演中，郑芝龙又变回了海盗。阿里云团队排查后发现，问题出在Prompt的Few-shot举例上——举例里写死了郑芝龙是个海盗，导致模型产生了优先级误判。
为了解决这些数据打架的问题，开发团队和阿里云深入提示词的最末端，反复微调权重，不断调整约束机制。经过调优，千问大模型最终在游戏里实现了98.7%的推演前提正确率，以及99.86%的Function Call匹配率。
解决了逻辑问题后，最后横在AI原生游戏面前的问题是两个字：成本。
追青算了一笔账：在游戏场景里，如果让玩家等上2分钟才出结果，体验绝对是灾难性的——这就要求模型每秒钟必须输出80-120个Token（目前主流大模型通常只有50-60）。
当然了，你还不能光考虑速度，因为每一次推演都是在烧钱。如果算下账来，AI调用的成本比雇人写文案的成本还贵，那这就不是一个能跑通的娱乐产品。
既要速度快，又要成本低，怎么搞？
《崇祯》的解法，是依靠阿里云的PolarDB数据库做底层支撑。由于抛弃了超长上下文，转而把成千上万维度的世界线数据卸载到数据库。同时，基于阿里云百炼平台的AI基础设施，游戏即使在每天消耗几百亿Token的情况下，也没有出现过超时或调用失败。陈海生提到，在AI原生游戏走向产品化的过程中，百炼平台提供的高并发低时延、安全合规、AI链路监控全覆盖等能力是关键性的。
逻辑、成本问题都解决后，《崇祯》终于跑通了AI Native Game的商业化。产品也在数据方面初步印证了这一点，游戏日均在线时长接近7小时，留存率也达到了78.3%。
这也印证了追青的一个判断：重度AI Agent的体验，不应该只停留在程序员的Coding工具里，也完全可以被转化为大众玩家愿意买单的娱乐产品。
04
千万级DAU的游戏，
怎么用AI做好服务？
在游戏行业，AI还有一个很有意思的地方：不管团队多大多小，AI都有最好的用武之地，都有可能带来颠覆性的改变。
小到个人开发的中小团队，可以用AI做原生玩法；大到千万级DAU的商业手游大作，也可以用AI做玩家服务。
不过到了这个规模，面临的就会是非常极限的压力测试了——《崩坏：星穹铁道》在游戏内置的AI工具「帕姆帮帮」，就是非常典型的一个样本。
为什么要做这个AI帕姆？银河在论坛上提到，随着长线运营，《崩坏：星穹铁道》背后的世界观和养成系统已经很庞大、有深度了。玩家为了弄懂新角色怎么配队、之前的剧情是什么，不得不在游戏和外部攻略站之间反复横跳，体验会越来越重。
而他们希望用AI帕姆来实现一个逻辑转变：不是让玩家去费力理解越来越复杂的系统，而是让系统主动去适应和理解每一个玩家。
但稍微想想就知道，《崩坏：星穹铁道》做这事是最难的：一方面是游戏体量已经有千万DAU，对AI有很大压力；另一方面它还是个二游，怎么保证帕姆在千万玩家的交互（甚至是调戏）下不崩溃、不OOC，也是个关键。
按传统的思路来设计，一开始就应该用上RAG（检索增强生成）技术，但在《崩铁》这里可能行不通。因为绝大多数游戏接入RAG后，AI只会相对机械复述检索出来的维基百科文档，人机感极重。
为了让帕姆活过来，项目组的做法是：额外交叉比对帕姆与事件/人物的关系网络、过往印象与主观态度，将这些因素转化为特定情绪，对客观信息进行「情绪染色」与二次重构，以此来保证帕姆说话合理自然，玩家也不会觉得违和。
同时，为了让帕姆拥有像人类一样的连贯交流能力，《崩坏：星穹铁道》专门设计了复杂的三重记忆机制：短期记忆——当前对话上下文；中期记忆——利用千问Plus模型，定期总结和压缩历史对话；长期记忆——针对每个玩家，分维度抽取专属的记忆档案。
但把这些复杂的机制叠加在一起之后，真正的问题才刚刚浮现：算力成本与高并发运维。
为了扛住千万级别的并发，项目组从零构建了一套异构推理集群，其中阿里云与千问等模型提供支持。在模型层，他们被迫采用了稀疏MoE（混合专家）架构，并且在后训练中把COT（思维链）直接蒸馏进模型，辅以FP8和NVFP4等极限推理加速手段——如果不这么干，响应时间和推理费用根本撑不住。
阿里云方面向葡萄君透露，为了保障AI帕姆在千万级并发下的稳定体验，技术团队在上线前进行了多轮极限压测，针对高并发场景下的响应延迟和异常捕获做了定向优化，确保大版本更新绝不炸服。
此外，由于《崩坏：星穹铁道》每个版本都会更新大量新内容，如果每次更新都要重新训练模型，时间和成本将不可估量。所以，整个系统的架构原则被严格设定为模型与知识库绝对分离。这样一来，每次发版就只需要更新后端的知识库了。
从米哈游的Agent平台到青干的《崇祯》，从TapTap的自动化营销管线到「一人工作室」的井喷——这些案例共同指向一个问题：当AI真的渗入游戏的每一个环节，游戏公司真正要面对的难题是什么？
看过这些案例之后，你可能会更加确信，AI的确能给游戏行业带来更有颠覆性的改变；但你大概也不得不承认：在这之前，把AI在工业化层面用好、跑通，仍然是游戏行业最需要攻坚的一个课题。
05
当下最大的问题是什么？
说实话，对大部分游戏团队来说，探索AI在短期看起来并不是一门好生意。大多数时候它确实能降本提效，但还不怎么能赚钱，反而特别容易耗费大量精力、成本。
这其中最核心的一个原因，就是当游戏公司把AI投入到量产环节时，往往会发现一个真相：做AI应用，80%的精力可能都耗在和模型/设计本身无关的脏活累活上。
Prompt怎么写，Skill怎么炼，这些勉强还算相对有趣亲民的部分；但首包延迟能不能压住、模型幻觉怎么控制、千万并发下数据库会不会死锁、海量Token的算力成本能不能压低……这些最硬的工程化门槛，才是横在所有团队面前的生死线。
这样的工程化需求，正是阿里云擅长解决的。
根据第三方研究机构数据，阿里云已连续五年在中国游戏云市场位列第一，在游戏云解决方案、基础设施两大细分市场份额分别为42%和39%。当游戏公司对AI底座的要求发生质变时，这套设施的意义可能也在改变。
过去，游戏公司买云服务，买的是IaaS（服务器、带宽和存储）；但在AI时代，游戏公司买的东西，就变成了一整套设施：包括但不限于算力底座+大模型+向量数据库+工程化平台。
不过与此同时，在各方的推动下，底层的技术门槛也一样在被拉平。阿里云百炼平台提供从数据处理、模型训练、测评、推理部署端到端的能力，大厂可以用百炼平台做规模化部署，小厂也可以用百炼平台快速启动AI项目，比如某客户从零开始做AI客服，在两周内完成从数据准备到上线的全流程。
更值得注意的是模型能力的持续进化。阿里云峰会最新发布的全新一代千问旗舰模型Qwen3.7-Max，正在成为下一代智能体基座。
面向当下智能体需求全新设计，实现了编程、推理等核心能力的持续突破，甚至可自主完成一项长达35小时、超过1000次工具调用的全自主内核优化实验，并保持了连贯推理，推理速度较原版本提升10倍。对于游戏行业来说，这意味着AI Agent可以处理更复杂的研发任务，而Qwen3.7-Max在视觉理解方向的强化，不只是更会看，更是让模型在真实任务中能用、会推理、更能执行，也将直接惠及游戏营销素材生成和审核环节。
在全球分发层面，阿里云也在全球31个公共云地域、101个可用区构建了全球一体化网络，为游戏出海提供低延迟、高稳定的技术底座。一些在海外知名度颇高的大DAU游戏，就基于这套基建设施和千问系列模型实现了低延迟、高性价比的多语言翻译和内容审核。
总的来说，AI在短期内，还不至于让游戏行业天翻地覆。但AI的确在让这个行业，发生着一些分化——不是谁取代谁这么简单，真正决定差距的可能是两件事：一是工程化能力，二是对AI边界的认知。
追青对这一点很感慨，他觉得AI未必带来平权，更可能导致两极分化。超级大厂在基模能力和基础设施上的优势会持续放大，小而灵活的团队能快速抓住机会，真正危险的可能是中间层——「团队成本大了，产品却没被用户认可，收入也没提高上来，这是一个比较致命的陷阱。」
但中型团队，其实也有自己的优势：大厂有自研技术栈，决策链长；小厂预算有限。而中型研发商（年收入10-50亿档位）和出海团队往往在AI应用上推进最快，因为中型厂既有明确的降本增效诉求，组织架构也相对更灵活。
不过不管对谁来说，这种情况都挺让人难熬的。因为AI发展起来日新月异，你可能真不知道哪天就被人甩得连尾气都吃不到了。游戏行业的FOMO完全可以理解。
既然如此，做什么才是对的？葡萄君这儿倒是有一个听起来很俗的大实话：先别管技术成熟不成熟，先上手用起来再说。
这一点，圆桌环节的嘉宾基本也都认同。曹擎宇的原话是「多去使用、多去体验，它的边界随着下一个版本模型的更新又会变化」；陈海生的建议更直接：「不要等AI技术成熟了再动，现在就要入场，从一些小场景或者已经比较成熟的场景跑通闭环。」
只能说，在AI渗入游戏研发骨髓的这个阶段，「先跑起来」本身就是最优策略。当AI渗入骨髓的时间足够久，新的血肉自然会长出来。