何去何从？
文 / 以撒
如果离游戏行业的距离没那么近，大多数圈外从业者或玩家对「AI x 游戏」的认知，很可能还停留在 AIGC 层面——说白了就是，这家公司是不是偷偷用 AI 美术素材了？
但圈内人应该都有个感觉：游戏公司，恐怕是对 AI 技术应用嗅觉最敏感、FOMO 最深、策略最激进的群体之一。在 AI 浪潮卷起来之后，AI 应用对游戏公司来说，已经完全从可选项变成了必选项。
这也让游戏行业，成了为数不多把 AI 利用得极其普遍，普遍到每一根毛细血管上的行业——根据中国音数协游戏工委与清华大学的专项调研，AI 在游戏研发环节的应用率已达 86.36%。
也提到了相关数据
最近，葡萄君和一些从业者聊了聊这件事，他们也提到：过去两年，如果去问游戏公司的老板们对 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 组把 Agent 接入了开发引擎和内部 IM 工具，让策划可以直接向 Agent 描述自己的需求，自动构建白盒测试。在阿里云游戏分论坛上，崩坏系列 AI NPC & Gameplay 技术团队负责人银河就展示了几个内部案例——包括赛车、2D 战斗等小玩法。
看到这些，你或许能意识到，AI Agent/Vibe Coding 应用的想象空间，已经发展到很多人的想象力都跟不上了……阿里云智能集团公共云事业部高级解决方案架构师陈海生也提到，「很多运维原来自己也要写代码做系统，但现在不是写代码，而是写需求——把需求描述清楚，晚上交给千问大模型让它自己跑，第二天生成代码，植入到自己的工程里。」
但对大多数团队来说，最大的问题在于：市面上大把的 AI 大模型，其实根本不懂游戏开发怎么做。人为的研究和底层适配，目前是没法避开的。
换句话说：API 调用不等于工业化生产，模型能力不等于产品能力。
银河在现场就分享了一个他们遇到过的痛点：绝大部分大模型的 Coding Agent 只擅长纯文本或常规网页开发，但游戏研发重度依赖 Windows 底层 API。如果大模型连 Windows 的命令行或 Power Shell 都用不溜，它根本无法介入真实的研发环境。
这其实就是横在游戏团队面前的 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 把过去的记忆全部卸载给数据库，只专注于推演当前这一步。
为了解决这些数据打架的问题，开发团队和阿里云深入提示词的最末端，反复微调权重，不断调整约束机制。经过调优，千问大模型最终在游戏里实现了 98.7% 的推演前提正确率，以及 99.86% 的Function Call 匹配率。
追青算了一笔账：在游戏场景里，如果让玩家等上 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 帕姆？银河在论坛上提到，随着长线运营，《崩坏：星穹铁道》背后的世界观和养成系统已经很庞大、有深度了。玩家为了弄懂新角色怎么配队、之前的剧情是什么，不得不在游戏和外部攻略站之间反复横跳，体验会越来越重。
但稍微想想就知道，《崩坏：星穹铁道》做这事是最难的：一方面是游戏体量已经有千万 DAU，对 AI 有很大压力；另一方面它还是个二游，怎么保证帕姆在千万玩家的交互（甚至是调戏）下不崩溃、不 OOC，也是个关键。
为了让帕姆活过来，项目组的做法是：额外交叉比对帕姆与事件 / 人物的关系网络、过往印象与主观态度，将这些因素转化为特定情绪，对客观信息进行「情绪染色」与二次重构，以此来保证帕姆说话合理自然，玩家也不会觉得违和。
同时，为了让帕姆拥有像人类一样的连贯交流能力，《崩坏：星穹铁道》专门设计了复杂的三重记忆机制：短期记忆——当前对话上下文；中期记忆——利用千问 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 渗入骨髓的时间足够久，新的血肉自然会长出来。
点击「阅读原文」可了解详情
推荐阅读
（星标可第一时间收到推送和完整封面）
