15人游戏团队:AI时代该合并的4类岗位

鼬游白书 · 第045期 · 方法论

AI 能压缩的是交接链，不能替你消失的是责任链。

4 个月，变成 4 周。

Wharton Generative AI Labs 今年访谈 20 家欧美游戏工作室，其中一家 AI-first 团队把垂直切片的制作时间压缩到原来的四分之一；开发与 QA 的评审循环，也从数周缩到一天。

但同一篇研究里，还有个更该被记住的数字：只有 3 家走到了 AI-first 阶段，而且全部从创立第一天就围绕 AI 组织。

所以，15 人以内的游戏团队该合并哪些岗位？先别从“谁能被 AI 替掉”开始。

先数一数：一个玩法需求，从提出到进包，要经过几道手、几次转述、几个人说“这不是我的问题”。

AI 游戏团队先合并交接，不是先裁岗位

很多团队对 AI 的组织想象，还停留在一张减法表：原画少一个、测试少一个、程序再少一个。

但 GDC《2026 游戏行业现状报告》显示，在使用生成式 AI 的受访者里，81% 用它做研究或脑暴，47% 用于邮件与代码辅助，35% 用于原型；真正用于资产生成的只有 19%，用于玩家向功能的只有 5%。

工具使用率高，不等于生产关系已经改变。给每个岗位各发一个账号，得到的往往只是每个孤岛都快了一点。

Wharton 观察到的跃迁发生在另一处：产品经理自己跑数据查询，工程师自己生成二维素材，原本跨团队的相邻任务被一个人接过去。它叫“越界执行”，不叫“岗位消灭”。

这就是 15 人以内团队的第一条组织原则：围绕交付物合岗，不围绕工具合岗。

15 人也不是行业公认的最佳编制。《Scrum 指南》给出的参考更小——通常 10 人以内、没有子团队与层级，所有人围绕同一个产品目标。真正重要的不是把人数压到某个整数，而是别让团队再长出一层传话者。

品类不同，编制当然不同。脱离玩法、平台和画质目标，直接发你一张“AI 时代标准 15 人配置表”的，多半是在卖模板。

游戏团队能合并的 4 类岗位，都在同一条交付链

岗位能不能并，不看名称像不像，看两个人是否在对同一件交付物负责。

第一类：系统策划、关卡策划、叙事策划，并为玩法体验负责人。

系统规则要落到关卡，关卡节奏要承接叙事，三者本来就在验收同一件事——玩家是否理解并愿意继续玩。Game Developer 早年总结小团队合岗经验时，也把这三者列为可行组合。

AI 可以补对白、列数值、出关卡变体，但“哪个版本更像我们的游戏”只能有一个最终答案。合并执行，集中定夺，别让三份 AI 草稿变成三个游戏。

第二类：技术美术、工具程序、性能优化，并为生产管线负责人。

他们共同交付的不是某张图或某段代码，而是“内容能否稳定进引擎、进包、跑到目标帧率”。AI 生成资产越多，格式、依赖、导入与性能就越需要同一个人看全链。

这不等于让程序顺便当美术，也不等于让美术顺便写底层。合的是工程接口，不是审美责任。

第三类：概念与 UI/UX，或 3D 美术与动画，并为视觉资产负责人。

注意这个“或”字。概念与 UI 共享信息层级和视觉语言；3D 与动画共享模型、绑定和运动结果。它们都是同一资产链的相邻工序。相反，2D 概念与 3D 制作硬并给一人，容易让创意向下迁就个人的制作短板。

AI 最适合把这种相邻执行接起来，却不该替美术总监决定风格。生成一百张图，不等于建立了一套视觉系统。

第四类：QA 与发布管理，并为质量与版本负责人。

测试计划、回归结果、构建稳定性和发布 checklist，本来就围绕同一个可发布版本。AI 能补测试用例、跑重复检查，就更需要一个人维护统一的完成定义（Definition of Done），而不是每个功能各自宣布“我这边没问题”。

但这位负责人必须能拒收开发交付。否则 QA 与发布合在一起，只会把错误更快地推上线。

AI 时代游戏团队有 3 种签字，不能合并

2019 年那篇 Game Developer 合岗指南，最值钱的不是推荐清单，而是三条警告：开发与 QA、策划与开发、项目管理与具体制作，都存在角色冲突。

到了 AI 时代，这个冲突没有消失，只是被更快地产出掩盖了。

第一种是创意签字。主策或创意负责人决定“这东西对不对味”。他可以写原型，却不能因为某种方案更容易生成、更容易实现，就悄悄把游戏改成工具最顺手的样子。

第二种是验收签字。QA 与版本负责人决定“这东西能不能进包”。他不能验收自己刚做完的功能——人很难给自己刚生成的代码挑出同一个错误假设，AI 更不能。

第三种是优先级签字。制作或产品负责人决定“先做什么、砍掉什么”。《Scrum 指南》特意把 Product Owner 写成一个人而非委员会，原因正是最终责任不能消失在集体讨论里。

可以一人多岗，不能一人独占生产、验收与定方向的全部权力。

人再少，也不必靠新增管理岗解决。让策划验收程序是否实现设计，让程序反验资产是否符合性能预算，让制作人对范围变化保留最后裁决——交叉签字，就比自我证明有效。

游戏团队合岗前，先写 4 张责任卡

别先改花名册。拿一条真实需求——比如“做一个带新手引导的战斗关卡”——把现有交接过程画出来，再给每条交付链写一张责任卡。

第一行写交付物：不是“负责 UI”，而是“玩家能完成首局的可玩版本”。交付物越模糊，合岗越是把模糊塞给一个人。

第二行写定夺权：玩法、视觉、范围分别由谁最后拍板。AI 能列十个方案，组织仍要知道选谁。

第三行写验收人：谁可以拒收，依据哪条可重复的标准。没有这一行，所谓提效只是验收前移给了玩家。

第四行写备份人：负责人离开时，谁能接管文档、工具链与未决问题。小团队最大的单点故障，往往不是一个程序，而是一套只存在某个人脑子里的管线。

四张卡写完，再做四个判断：交付物相同，可以并；验收目标冲突，不能并；隐性经验写不下来，先补文档再并；一个人无法在一次迭代内完成执行加自检，就拆开或外包。

执行顺序也只有四步：先把规则写下来，再选一条链路试并，跑一次完整版本复盘，最后才改岗位名称与薪酬。

Wharton 研究里，AI-first 团队把设计文档、流程与规范写成人与 AI 都能读的文本。这不是文书洁癖，而是合岗的前置条件——没有共享上下文，通才只是多接了几份陌生工作。

投资人看 AI 游戏团队，别数人头看 3 张表

“我们核心研发只有 8 个人”已经不是充分信息。真正该看的是三张表。

第一张是交接图：从创意到可玩版本经过几个人。人手少但每一步仍要等外包、等审批、等另一个部门，组织结构图再薄也快不起来。

第二张是验收表：AI 生成的代码、资产和测试分别由谁拒收。答不出名字的团队，省下的通常是检查时间，不是生产成本。

第三张是周期表：连续看几个版本从想法到试玩的时长，以及返工占多少。Wharton 的 4 周垂直切片是少数 AI-first 样本的结果，不是拿来套所有项目的承诺；能重复，才是能力。

上一篇我们谈外包与共研，核心是风险换手了，价格没换。小团队合岗是同一枚硬币的另一面：工作换手了，责任不能跟着消失。

AI 时代最值钱的小团队，不是每个人都能干五个人的活，而是每个人都清楚自己在对什么结果负责。

下一期，我们换一个更冷的约束：Steam 一年两万款新作，曝光稀缺会怎样改写游戏立项。《鼬游白书》，每周见。