团队生产工作流

个人工具能否变成团队能力，取决于接口、责任、评测和治理。信息截至 2026-07-14。

结论先行

2023 年的观察把游戏公司的 AI 组织大致分成探索、平台或中台、自研并贴近项目等形态。2026 年的文章重新归纳为产品、探索、服务三个方向，并指出个人用工具容易，团队稳定复用困难。两篇文章相隔两年半，却指向同一个组织问题：实验 Demo 的价值由少数人证明，生产价值必须穿过需求、资产、引擎、审查、权利、维护和交付责任。

最有效的团队模式通常不是单建一个“AI 万能组”，而是三层组合：小型平台团队维护模型接入、权限、日志和共用工具；嵌入业务的研发与美术共同定义工作流；探索角色负责高不确定原型和外部跟踪。项目是否采用某条工作流，由可测的周期、返工、采纳率、质量和风险决定，不以生成数量、模型榜单或内部演示热度决定。

原文演进

这两篇不是企业普查，而是作者在不同时期的经验归纳。本专题把它们当作组织假设，再用公开一手报告作现状对照，不把个别公司做法写成全行业标准。

有效方法

以工作流问题立项，不以模型能力立项

“接入一个新视频模型”不是完整项目。“把技能特效白模从两天缩短到两小时，同时保证可导入、可编辑和预算合格”才是可验证目标。立项表应写清当前流程、瓶颈、用户、输入输出、人工检查点、失败回退和成功指标。

建立三类能力组合

三类能力可以由同一小团队兼任，但责任和交付物必须区分。探索原型不承诺 SLA，服务工具需要版本、支持和弃用计划。

用服务目录管理团队预期

每条 AI 服务应标明维护者、目标用户、输入数据级别、可用项目、模型与版本、成本上限、输出权利、已知限制、验收方式和联系方式。状态可分为实验、试点、支持、弃用。没有维护者的 Demo 不进入服务目录。

建立阶段门

1. 发现： 真实用户是否反复遇到同一问题，传统自动化是否已经足够。
2. 原型： 在小样本上证明输入到输出闭环，主动收集失败样本。
3. 试点： 在真实项目中与原流程并行，记录人工修订与返工。
4. 生产： 明确所有者、权限、数据、预算、监控、回退和支持。
5. 复盘： 根据采用率与质量继续、收缩或弃用，不因沉没成本保留。

把项目知识做成可版本化接口

设计 token、资产目录、Prefab 规范、命名、测试、审核清单和领域 Skill 才是可积累资产。提示词可以是其中一部分，但不能单独承担团队知识。接口变更要有迁移说明，生成产物要能追溯到输入、模型和工具版本。

失败原因

个体提效常把成本转移给下游

一个人更快生成了代码或资产，下游可能花更多时间审查、重命名、修引用、清理版权和统一风格。只测生成时间会得到虚假收益。应测从需求进入到可合并、可导入或可发布的完整周期。

探索团队容易形成 Demo 队列

模型更新快，做演示总能获得即时反馈；维护、数据清理和评测却不显眼。若没有阶段门，团队会不断开始新方向，很少把一条工作流做成可靠服务。失败实验也可能因为缺少记录而被下一批人重复。

中台远离项目会抽象过早

没有真实美术、策划、程序共同参与，中台容易构建通用提示平台，却不能输出项目需要的 PSD、Prefab、动画或测试证据。通用能力应从两到三个真实工作流中提取，而不是先设计一个覆盖所有部门的抽象层。

权利、安全和数据问题发现太晚

资产到了上线前才检查许可，代码进入主干后才发现外部服务保存输入，都会造成高额返工。数据分类、允许的供应商、日志保留、密钥管理、生成标识和商店申报应在试点前定义。

指标奖励错误行为

生成图片数、调用次数、活跃用户和节省工时自报都容易被高估。团队应关注采纳后指标：合格率、平均人工修订、周期、返工、缺陷、性能、成本和用户满意度。对创意质量保留盲评或配对评审。

当前技术进展

Unity 的 2026 Game Development Report 基于一项 300 名开发者的调查和约 500 万名 Unity 生态开发者的匿名平台数据。报告称，受访开发者主要把后端 AI 用于代码辅助和写作或叙事，50% 的受访者称使用 MCP，主要用途包括连接引擎、编辑器与生产管理。报告还指出较小项目和较短原型周期受到关注。Unity 2026 Game Development Report，访问于 2026-07-14

这些数据有明确来源范围，不能解释为“全行业一半工作室已经成熟部署 MCP”，更不能直接证明投入回报。供应商报告也可能更关注其生态可见的数据。

Unity AI 公开测试将 Assistant、官方 MCP Server、Gateway 和 Generators 放在同一产品中，并提供集中模型接入、使用控制、安全和审计方向。这说明团队级产品开始把治理与生成并列，而不再只有单人聊天界面。Unity AI Open Beta，访问于 2026-07-14

编辑判断： 工具集成正在降低，组织采纳成本没有同步归零。能进入项目上下文只是起点，评测、责任和变更管理仍需要团队自己建立。

推荐工作流

组合式组织

探索与评测
  -> 真实项目试点
  -> 平台沉淀共同接口
  -> 项目内所有者负责质量
  -> 治理审查数据、权利和成本
  -> 指标复盘与弃用

每条工作流指定业务 owner 和技术 owner。业务 owner 决定是否达到可用质量，技术 owner 负责工具稳定、版本和故障。平台团队提供基础能力，不替代这两个责任。

最小评测卡

评测集必须包含失败样本和真实项目长尾，不只使用展示效果最好的输入。模型升级先在固定集回归，再小流量试点。

适用边界

适合团队化：高频、输入相对规范、可验证、能回退、多人共享的任务，例如资源检查、白模生成、测试、检索和结构化导入。

保持个人辅助更合适：低频探索、纯灵感、结果主要由个人消费且风险低的任务。

不应上线：没有 owner；无法追踪输入输出；权利不清；失败会直接伤害玩家或资产；没有基线却声称提效；工具维护成本持续高于节省成本。

原始文章与延伸阅读

本专题收录 2 篇原文，完整元数据见文章索引。