AI 工具能生成命名了,为什么团队协作还是会卡住?

这是“用AI解决真实业务问题”系列的第2个case，也是游戏资产命名工具的第2篇复盘。

上一篇先解决了最小闭环：让资产命名从人工传递，变成按规则自动生成，并记录到工具里。

●先看命名信息是怎么流动的

继续以游戏资产命名信息为例，我们看下命名信息在团队中的流转链路：

从信息流中，已经基本可以看出：

- PM是规则制定者和信息收口人，确保信息的准确性；

- 美术模型同学、供应商、策划运营程序都是信息需求方，他们主要是能拿到准确的命名，他们不需要维护这些信息；

- 信息需求方发现问题后不是让他们直接修改命名，而是反馈问题给到信息收口人PM，因为 PM 更清楚这次修改会不会影响其他环节。

- 为确保信息的准确性，PM承担最终确认和更新责任，所以PM需要可以修改（这里可以思考：为了协作高效性，修改权限是否也可以给到其他人？）

- 修改后的信息还需要同步给到所有涉及到的参与者；

进而可以推导出资产命名工具至少有3个角色，各角色权限大致如下：

- 管理员/信息维护人（本案例中，如PM）：新增、修改、确认、同步、查看记录；

- 协作成员/执行成员（本案例中，如程策美）：查询、复制、反馈问题、部分执行成员可新增/生成命名，但修改已有命名需审批；

- 协作方/查阅者（本案例中，如供应商）：查看指定命名、复制使用，不参与内容修改流程；

每个角色具体的权限可以根据具体业务情况收缩或拓展，比如业务保密要求高，甚至就不给外部供应商查阅权限，只能从对接人处获取命名信息。

●把协作机制转成AI能理解的需求

当整个团队的协作机制、信息流转都思考清晰后，接下来就是把这些规则转成AI能理解的产品需求。

我当时是把前面梳理的信息流和角色权限发给AI，用文字补充说明了一遍：

“这个工具涉及到的人有：PM、美术、程序、策划、运营。其中PM负责增删成员和信息的统一把关；美术同学可以自己到这个工具生成命名后使用，但如果美术同学要修改已经生成的命名信息，需要走申请给到PM审批同意，相关的修改审批要留痕；程序、策划、运营只是阅读和查询，不可以生成和修改命名。”

在前面的信息流梳理中，提出了一个思考：为了协作高效性，修改权限是否也可以给到其他人？在这里可以回答了。

从PM的角度，或者说PM的终极目标来看，不是把所有信息继续攥在自己手里，而是设计一套机制，让团队能在规则内自运转。这也是 PM 很重要的一部分工作价值。

所以在权限设计这里，我给到了美术同学自主生成命名的权限，但涉及已有命名信息的修改，审批确认权仍在PM手里。

这样既能让大家能在规则内自己完成查询、生成、反馈，PM又能将精力集中在关键确认和异常判断上。

最后回过头来看，我没有一上来就先拍脑袋设计权限，而是先梳理了业务信息到底怎么流动的，基于业务出发来思考权限设计。

●AI输出原型后，重点验收什么

功能增加后，重点就是跑完每个角色的使用流程，是不是该有的权限都能正常用，不该有的权限是受限制的。我是直接让AI给了我每个角色的测试账号，我挨个进行测试：

- 美术能不能生成新命名；

- 美术能不能对已有命名提交修改申请，而不是直接改；

- PM能不能审批并留痕；

- 程序/策划/运营是否只有查询和复制权限。

除此之外，有些问题，自己跑不一定能测到，我还会让AI自己写测试用例进行功能测试，告诉AI要全面测试一遍，每个角色的使用路径、权限是否都正常、是否会有越权等等，最终让AI汇总发现的问题并给到优先级建议，由我来最终决定修不修、先修哪些。

*AI 根据不同角色的使用路径和权限限制做了一轮测试，并按影响范围给出修复优先级。图中为脱敏后的部分测试结果。

我还是附上操作图给大家看下，协作闭环只靠文字描述不直观。

图1：执行者可以生成新命名，但修改已有命名需要提交申请。

图2：PM 审批通过后，命名更新并留下审批记录。

图3：查阅者只能查询、复制，并接收命名变更通知。

到这一步，资产命名工具就不只是一个“能生成命名”的个人工具，已经可以承接一部分团队协作维护流程了。

美术资产命名信息怎么被规则化、怎么做团队协作维护，到这里就分享完了。

下一篇会继续写：这个工具实际跑起来后暴露了哪些问题，以及我怎么继续让AI帮我测试、调整和迭代。

上一篇可以看这里：用 AI 干掉一个真实业务痛点：游戏资产命名，怎么从人工传递变成规则生成

这里是 AI Second。

我会持续分享用AI解决真实业务问题的case复盘，也记录AI工具、产品思维和个人工作流实践。

计划每周更新 1 篇，我们下篇见～