美术资产命名看似简单，实则是游戏研发中的关键信息枢纽。从模型本体到配件、状态版本的复杂组合，一个错误的命名可能引发连锁反应，甚至影响玩家体验。本文深度拆解游戏资产命名的管理难题，揭秘如何将业务规则转化为可执行的工具闭环，并分享AI如何辅助实现从规范到工具的跨越，为团队协作效率带来质的提升。
在游戏研发里，资产命名看起来只是给文件起名字，但实际是在给资产建立索引，就像图书馆的索引系统一样。如果每个人都按自己的习惯起名，又或者命名信息传递错误，后面引擎引用、配置表、程序联调都可能跟着出问题。
在游戏美术资产制作中，每一个美术资产都会有一个独一无二的名字，就类似人类的身份证，在游戏引擎、策划配置表中，很多时候都是以这个名字来进行索引和引用。有些线上 bug 就是资产名传错或配置错导致的，名字一旦错了，后面引用到的就可能是错误资产，最终影响现网展示和玩家体验。
〔资产命名流转链路〕
简单业务中，例如共用一套模型本体（躯干+肢体合并），只是换颜色、换贴图，角色要么穿 A 套装，要么穿 B 套装，是整套替换，不需要把 A 的袖子换到 B 的身上。这种情况下，我们确实可以通过《命名规范》+ Excel《资产命名列表》两个文档就把资产信息管理起来，资产也可以简单命名为 Hero_01、Hero_02、Hero_03 往下顺序编号，规律很明显。
但在复杂业务中，有的每个角色都是一套独立的模型本体，额外还有饰品、道具、武器等各类配件（甚至有的业务躯干和肢体是分开的，如魔兽，玩家可以自由组合头盔、护肩、手套、靴子），甚至还有狂暴状态，角色发怒狂暴后模型有形变、特效变化。这些一叠加，角色资产的复杂度一下就上来了。
不同业务中的资产要怎么拆，都是由具体游戏玩法以及性能要求决定的，但要解决的问题都是一致的：
拆出的这些模块资产用什么缩写、按什么公式命名？
由谁来统一输出命名，要不要下放给美术同学自己输出？
生成的命名要怎么同步给大家、以什么方式管理？
这些都将影响整个团队的协作效率。如果没有统一管理、信息不透明，PM 就会沦为信息中转站——这是我自己踩过的坑，更严重的是，一旦信息传递错误，可能会影响现网配置和玩家体验。
〔没有工具时，PM 变成信息中转站〕
为什么先做模型？我想了几点。虽然游戏美术制作的第一环节是原画，但原画只用于模型制作参考，不需要进引擎，更适合用另一套方式管理，本文不赘述。
模型是所有后续美术环节的开始，它决定了后续动画、特效怎么挂载和协作，所以模型命名一旦不稳定，后面环节都会受影响。而且只要模型的命名定好了，动画、特效主要改一些特定前缀就行，后续环节的命名成本也会明显降低。
还有就是，我本身在模型环节深入比较多，模型命名一直是我这边的重灾区，需要优先解决。
以一套脱敏后的角色模型规则为例，模型资产可能包括：模型本体、材质、角色附属资产（武器、道具、饰品等配件）、不同皮肤品级、不同状态版本，以及不同资产类型对应的不同数量的材质或子资源。
这些规则不一定适用于所有业务，但它们说明了一个问题：当资产拆得越来越细，命名就不再是简单的顺序编号了，重点是要把业务规则转成稳定、可查询、可复用的信息结构。
我初步设想的第一版工具最小闭环：
1、输入：角色的中文名、英文名、外观版本品质、状态版本、配件信息、对应的原画等必要信息；
2、按《资产命名规范》生成规则，即把上面输入的信息按规定的形式组合，最终输出资产名，如“SM_PRJ_Hero_Prop_01”，并存入工具中，用户可自主查询或复制；
3、生成后支持复制，方便粘贴到企业微信、飞书等内部沟通工具，或其他协作场景；
4、做基础自检：资产名不能重复，同时对照当前录入的命名规则，检查生成结果是否符合预期。
为了第一版的范围聚焦在最小闭环中，第一版中暂不考虑做的内容：
（本文截图用的是后续脱敏 demo 页面，当前版本已经有更多模块，这篇只看资产管理页里的录入、生成、查询、自检闭环。）
在我的上一篇文章里就提到：规则清楚、重复劳动、输入输出明确、小范围使用风险可控、还能快速验证对错的场景，非常适合借助 AI 来改进。美术资产的命名基本符合这个条件。
这个工具我也是用 CodeBuddy 来辅助开发实现的。我本身已经制定好了《资产命名规范》（命名规范其实就是命名公式，如 [项目名]_[角色名]_[部件名]_[类型]），就直接把现成的规范文档发给 AI，先和它沟通澄清：规范里的字段是什么意思、以什么形式组合成一个命名、生成后的命名信息要能保存在工具里方便查询和复制。
AI 第一轮输出的就是工具原型。当时第一版没有截图，这里用当前版本的资产管理页示意，第一版核心也是“资产管理”这一页：录入信息、生成命名、进入命名表。
〔脱敏 demo 页面示意（虚构命名规则和角色数据）〕
第一轮的重点是看 AI 有没有把规范里的字段关系转成功、理解有没有偏差，当时也花了比较多时间调整“录入新资产”这部分。
因为命名规范里给的示例直接就是英文名，工具一开始没有区分中英文名字。是我后来想到日常上下游的沟通其实以中文名为主，只是命名要求用英文或字母，所以工具这里需要有中英文对照，我就增加了这个输入字段。还有一开始序号要手动填，我更希望能自动编号，这也是在体验过程中反馈给 AI 优化的。
其实命名规范是活的，不同业务的规范都可以不一样，所以验证的重点不是“命名好不好看”，而是它是否能严格按照当前工具里录入的规范生成命名。
因此，我第一版重点验证三件事：
1、输入一组角色模型信息后，工具能不能按当前录入的命名规则生成资产名；
2、同一个角色连续录入多套版本时，序号能不能自动递增；
3、基础自检能不能识别重复命名，避免同一个资产名被反复使用。
〔完整命名规范 + 工具实际生成截图，版本序号会自动填充为下一个编号〕
像中英文名输错时的提示这类功能，放在后续体验优化。它不是第一版能不能跑通的核心，只是会影响工具好不好用，属于用户体验层的优化。
最后想说，我两篇文章里关于 AI 的应用，都不是让 AI 从 0 到 1 来制定规则、规范。因为规则、规范的制定需要对业务有足够多的了解和判断才能形成，这个必须人来把控。当人把规范制定好后，我们可以让 AI 辅助判断有没有漏洞，再让 AI 把我已经能说清楚的规则，变成可以执行、查询、校验的工具。我认为这也是 AI 切入业务的一个具体可行的方向。
本文由 @AI Second 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。