游戏发行获客工程 2026：AI 素材工厂与归因闭环
把发行素材从一次性交付的图片改造成带配方账本、规格版本与效果外键的实验单元：生成侧用工作流引擎保证可复现，平台侧用规格矩阵与 AI 披露做自动门禁，决策侧用分层 bandit 加止损规则处理延迟归因，把跨周期可累积的发行知识真正建起来。
约 54 分钟阅读16,041 字2 次阅读博主
把发行素材从一次性交付的图片改造成带配方账本、规格版本与效果外键的实验单元：生成侧用工作流引擎保证可复现，平台侧用规格矩阵与 AI 披露做自动门禁，决策侧用分层 bandit 加止损规则处理延迟归因，把跨周期可累积的发行知识真正建起来。
在游戏行业的 AI 落地叙事里，注意力几乎全部集中在运行时：NPC 会说话、行为树会推理、强化学习会打 Dota、QA Agent 会自动复现 Bug。但发行侧——也就是一款游戏被多少人看见、多少人点进来、多少人留下来——这条链路上的 AI 几乎没有被系统地工程化过。它同时具备生成式 AI 最擅长的特征（素材是高度可枚举的离散变体）和最难的部分（效果反馈延迟、归因数据被隐私框架切碎、投放算法在你和创意之间插了一层）。本文给出一套可落地的发行获客工程架构：把素材生产建模成受约束的变体搜索问题，把素材工厂做成带配方账本的工作流引擎，把平台规格与 AI 披露做成自动门禁，把归因回传建模成结构化约束而非单一开关，最后在延迟奖励下用分层 bandit 做素材组合决策。
先看一组不对称。在一个中型团队里，AI 的工程投入分布大致是：运行时玩法 AI 拿走了绝大部分注意力与预算，因为它离玩家最近、演示效果最好、也最容易在技术分享里讲故事。而发行侧的现状是：素材需求仍然靠「设计出图 → 外包批量 → 剪辑 → 投放」这条链路，迭代周期以周计；一次买量活动上线后，素材效果好坏基本靠人肉看报表，遇到 CTR 波动才改一版。
这条链路被低估的根源在于它同时踩中了两类通常被认为「不值得用 AI」的理由。第一类是「创意不可自动化」：发行素材确实包含品味判断，但品味的产出成本并非均匀分布——从零创作一张主视觉的成本极高，而在既定风格与既定规格下生产几百个受控变体的成本极低。第二类是「效果无法归因」：确实难，但难的只是因果归因，不是相关性归因，而工程上能立刻兑现收益的恰恰是后者。把这两点拆开，「发行侧不适合 AI」这个判断就站不住了。
另一个被忽略的事实是：主流广告平台已经把素材选择这件事接管了一部分。AppLovin 官方页面宣称「每天有超过十亿人玩移动游戏」，其广告位是全屏的，在游戏体验的自然停顿期出现，或以奖励形式换取玩家注意力；页脚同时挂着归因（Adjust）与创意（Wurl）两条产品线。这意味着创意与效果闭环正在向平台内部收拢，开发者自己这一侧反而丢失了「哪条素材真正起作用」的原始证据。这不是坏消息，但它把「自建素材-效果对照表」从一个可选项变成了必选项。
Google Ads 官方文档里有一句话，比任何行业白皮书都更能说明生成式 AI 在发行侧的真实位置：「Use AI assets for variety: Leverage AI tools to create more assets for your campaign.」——用 AI 工具为你的投放活动创造更多素材资产。这不是「AI 替代美术」，而是「AI 替代素材数量的组织成本」。数量从来不是瓶颈吗？不，数量恰恰是瓶颈，但瓶颈不在绘制，在于管理：命名、版本、规格适配、审批、去重、效果关联。AI 真正替代的是中间这段管理摩擦。
那么真正的工程问题是什么？我的答案是三个，每一个都可以被拆成可断言的约束：
下面按这三条展开。
为了让讨论能被工程化，先把问题写下来。
意图 ：一个发行素材要表达的内容意图，由题材、核心卖点、目标人群、情绪基调、平台语境共同确定。它是自然语言与业务约束的混合体，不是单一向量。
规格集 ：每个投放渠道或商店位对素材的硬性要求，包括像素尺寸与宽高比、字符数上限、文案安全区、是否允许真人肖像、是否允许合成内容、需要披露什么。这类约束是可枚举、可版本化的。
生成器族 ：由提示词模板、LoRA 或参考图、结构控制条件（ControlNet 一类）、采样器、步数、CFG、随机种子、以及底模与算子版本共同决定的参数集合。每一组完整参数指向一个确定性输出——前提是算子与权重被固定。
素材 ，其中 是生成器实例， 是目标规格。素材的完整身份是它的配方（recipe），而不是它的像素。
目标：在预算 （算力成本、外包成本、人审工时）与合规约束下，最大化素材集合 的期望增量收益：
这里有三个刻意的设计选择需要解释。
第一， 是增量收益，不是点击率。素材维度的点击率是一个几乎无争议的代理指标，但它对长线留存几乎没有预测力——这也是 id=813 那篇讲的 LTV 预测要在这条链路上被使用的位置。在工程实现上， 常常退化为「点击率 × 安装率 × 首日留存 × ARPU」的乘积近似，误差肯定存在，但比纯 CTR 靠谱一个数量级。
第二， 是一条硬门禁，不是加权项。一条不合规的素材不是「价值低一点」，而是「价值为零且有法律风险」，把它放进加权求和里等于告诉优化器可以拿合规风险换收益。所以合规必须走过滤而非惩罚。
第三， 里必须包含人审工时。这一项经常被漏掉，导致系统持续生成大量需要人看、但看不完的变体。第 8 节会展开为什么这是生成式 AI 在发行侧最反直觉的一个坑。
这个形式化带来一个直接的工程结论：素材不是资产，是可复现的实验单元。一次买量活动结束后，如果三个月后有人问「那条 CTR 0.8% 的素材是怎么生成的」，你必须能答出完整的配方。这是后面所有章节的基础设施要求。
把生成模型当成「一个出图接口」是发行侧 AI 最常见的建模错误。ComfyUI 之所以在生态里占据主导位置（142904 stars，GPL-3.0，最近推送 2026-10-25），关键不在于它生成的图更好，而在于它把生成过程表达成了一张有向无环图：加载器、采样器、条件控制、VAE 解码之间的连线本身就是资产。这个资产可以 JSON 序列化、可以 diff、可以被代码 review、可以被两台机器分别复现出同一张图。
这正是配方账本所需要的形态。对比之下，如果用一段 Python 脚本调用 diffusers（34805 stars，Apache-2.0，最近推送 2026-10-25）来出图，配方就散落在代码与命令行参数里，事后复现需要考古。
生成侧推荐的分工是：diffusers 用于集成与批量导出，ComfyUI 用于需要人工介入调试的工作流，两者不冲突，因为最终落到账本里的都是一份可序列化的配方。依赖管理用 ComfyUI-Manager（16573 stars，GPL-3.0，最近推送 2026-10-24）承接，注意它与 ComfyUI 同样是 GPL-3.0，商用场景需要评估传染性；训练侧若需要自建 LoRA，kohya-ss/sd-scripts（7249 stars，Apache-2.0，最近推送 2026-10-24）的许可更宽松。底模侧，Stability-AI/generative-models（27313 stars，MIT，最近推送 2025-12-16）、black-forest-labs/flux（26037 stars，Apache-2.0，最近推送 2025-07-31）、Stability-AI/sd3.5（1539 stars，MIT，最近推送 2025-01-08）都是可商用的选项，但许可条款与具体权重的可用性要逐一核对，不能只看仓库标签。
风格一致性是发行素材的生死线——同一个角色在 40 张图里长得不一样，整套素材的可信度直接崩塌。业界的标准解法大致三类：参考图条件（IP-Adapter 一类）、结构控制（ControlNet 一类）、自训练 LoRA。
这里有一个必须写进技术选型文档的事实：这两个上游组件都已经明显停滞。tencent-ailab/IP-Adapter 实测 6700 stars、Apache-2.0、最近推送 2024-06-28；lllyasviel/ControlNet 实测 34137 stars、Apache-2.0、最近推送 2024-02-25。两者都仍然可用且效果可靠，但两年多没有新的推进意味着：新的基础模型架构出现时，一致性插件会滞后于底模。
这个观察的工程含义不是「别用」，而是「一致性不能完全外包给上游」。一条更稳的路径是：以 LoRA 固化角色与画风，把参考图与结构控制当作辅助约束而非唯一手段。理由是 LoRA 是你自己训练的，权重与数据都在自己手里，底模换代时你可以重新训练而不是等社区。代价是训练与美术审核的前期投入，这笔投入应该被算进 §2 里 的人审工时项。
账本每一行是一条素材的完整身份。字段设计如下：
recipe_id 唯一标识，与投放平台侧的素材 ID 一一映射
workflow_hash 工作流 DAG 的内容哈希（版本变了哈希就变）
base_model 底模仓库与权重的具体版本/哈希
lora_refs LoRA 集合及其校验和
control_refs 参考图 / 结构控制条件与其哈希
prompt_template 提示词模板 ID 与渲染后的完整提示词
negative_prompt 负向提示词
seed / sampler 随机种子、采样器名称、步数、CFG、分辨率
spec_id 目标规格 ID（指向 §4 的规格表）
asset_type 静态图 / 短视频 / 文案 / 多规格集合
compliance_tags AI 使用披露分类、肖像授权、审核状态
review_state 未审 / 已审 / 已驳回 / 已上线
effect_ref 关联的效果记录（§6 展开）
账本必须满足三条工程性质：可复现（给定 recipe_id 能重建像素）、可追溯（给定效果记录能定位到配方）、可失效（规格或政策变更时能批量标记受影响的素材）。第三条最容易被忽略，下面两节就是它的理由。
配套的存储与实验设施可以按需引入：素材与训练数据用 DVC（15942 stars，Apache-2.0，最近推送 2026-10-19）做版本，实验参数与产物用 MLflow（28529 stars，Apache-2.0，最近推送 2026-10-25）记录，归因特征用 Feast（7347 stars，Apache-2.0，最近推送 2026-10-25）统一物化，素材库去重用 faiss（41209 stars，MIT，最近推送 2026-10-25）做向量检索——去重这一步不是洁癖：平台算法会自动组合素材，重复素材会挤占组合空间并拉低广告强度指标。
推理侧的部署可以再优化一步：如果生成链路要稳定跑在自有算力上，把子图导出成 ONNX 并用 onnxruntime（22171 stars，MIT，最近推送 2026-10-25）执行，比每次调用远端服务更可控，配套示例见 microsoft/onnxruntime-inference-examples（1701 stars，MIT，最近推送 2026-10-25）。视频类素材（预告片切片、动态创意）可以关注 VACE（3991 stars，Apache-2.0，最近推送 2025-10-17）与 CogVideo（13107 stars，Apache-2.0，最近推送 2025-11-04）；需要把静态角色图转成表情/口型动画时，LivePortrait（19310 stars，最近推送 2026-06-01）与 Wav2Lip（13256 stars，最近推送 2025-06-22）是常用选项，但两者仓库许可字段均未声明明确 SPDX 标识，商用前需自行核实条款。
素材工厂的第一道门不是审美，是规格。以 Steam 为例，Steamworks 官方文档给出的商店位素材规格是一张必须被完整实现的表：Header Capsule 920×430（必填）、Small Capsule 462×174（必填）、Main Capsule 1232×706（必填）、Vertical Capsule 748×896（必填）、截图最小 1920×1080 且 16:9（必填）、Page Background 1438×810（可选）、快捷方式图标 256×256（必填）、App 图标 184×184（必填）、Library Capsule 600×900（必填）、Library Hero 3840×1240（必填）、Library Logo 宽 1280 或高 720（必填）、Event Cover 800×450（必填）、Event Header 宽 1920 高 622（可选）。
这张表有几个工程后果。第一，比例是冲突的：主胶囊 1232×706 约为 1.745:1，垂直胶囊 748×896 约为 0.835:1，同一张主视觉想同时满足两者，必然要放弃部分画面内容。因此素材工厂必须采用「母版 + 安全区」设计——生成高分辨率母版，预留一个能同时容纳横竖两种裁切的核心区域，安全区规则写进提示词模板并在校验时检查，而不是指望裁剪阶段随机裁。
第二，规格会变，而且变更有明确时间戳。Steamworks 文档在图形资产章节标注：2024 年 8 月起 Steam 接受大多数胶囊的更大尺寸，旧尺寸不再被接受。这意味着你的素材库里的存量资产存在「规格失效」状态。规格表必须版本化，规格表一改，就要能批量查出哪些历史素材已经不合规。这正是 §3.3 账本第三条性质（可失效）的用武之地。
第三，规格是派生的，不是并列的。同一份母版按规格表派生出多个投放位，这个映射关系应当显式建模为 母版 → 派生集，而不是把每个尺寸都当成一次独立生成。前者成本低且风格天然一致，后者会引入批间差异（同一角色在不同尺寸的图里长得不一样），这是发行素材最容易被观众察觉的破绽。
Valve 在更新后的 Content Survey 中专设了「生成式人工智能内容」一节，把 AI 使用分成两类。Pre-Generated 指开发过程中借助 AI 工具创造的任何内容（美术、代码、声音等）；开发者承诺内容不含侵权内容，且与营销材料一致，Valve 会在发行前评审中以与非 AI 内容相同的标准检查。Live-Generated 指游戏运行时用 AI 工具创造的内容，除了同样要满足上述要求，还额外需要在 Content Survey 中说明你设置了什么样的护栏（guardrails）以确保 AI 不生成非法内容。
Valve 的官方公告补充了两个对工程设计影响很大的点。第一，披露内容会有相当一部分被展示在游戏商店页上给玩家看，所以披露口径本身就是对外沟通材料，不能随便写。第二，Valve 在 Steam 上线了新的举报机制：Live-Generated AI 内容的游戏内可以使用覆盖层（overlay），让玩家在遇到本应被护栏拦下的违规内容时直接提交举报。这把护栏从上线前的一次性合规检查，变成了需要长期运行的产品能力——举报通道、审核队列、人工复核 SLA、误报处理，全部要建。
变现侧还有一个容易被混淆的点。Steamworks FAQ 明确说明，若游戏连接了产生持续调用成本的 Live-Generated AI 服务，开发者需要自行处理这笔成本：可以把成本摊进游戏本体定价，也可以用 Steam 支持的支付方式按次收费（微交易），或者用订阅制，或者用一个单独购买的 DLC 解锁无限次交互。这说的是运行时成本。营销素材的生成成本属于另一本账，混在一起会让单位经济模型彻底失真。
还有两条与 AI 无关但同样是发行侧的硬约束值得写进流程：Steamworks 的 Onboarding 文档规定每个产品需缴纳 100 美元提交费、付款后需等待 21 天才能发布游戏、商店页「即将推出」页面至少公开两周、商店页与构建审核需 1 到 5 天；同文档还明确禁止把「以广告为商业模式的应用程序」发布到 Steam，并禁止与已发售产品无关的视频内容。前者意味着素材流水线必须能在「两周公开期」之前跑完至少一轮完整的生成-审核-上线循环，后者意味着如果一个团队打算做纯广告变现的 AI 玩法产品，在分发端就会撞墙——这是 AI 时代游戏商业化里最硬的一条红线。
把上面所有约束落成工程，需要在流水线里放三个卡点：
spec_id 与意图，检查是否存在合规的提示词模板与安全区定义；缺失则拒绝生成，不浪费算力。三个卡点都应该是可自动断言的，而不是靠人看。这一点和 id=844 讲的合规与溯源是同一个思路，但落点不同：那篇讲的是资产本身的溯源链路，这里讲的是发行流水线的关卡设计。
投放平台不是被动接收素材的。它们会自动组合、自动测试、自动把预算压向表现好的组合。Google Ads 的响应式搜索广告是最清晰的样本：单条 RSA 最多可填 15 条标题与 4 条描述（至少 3 条标题、2 条描述），平台会持续测试不同组合并学习哪些组合表现最好，还支持跨广告组借用未使用的标题与描述素材（enhanced flexibility）。
这组数字背后的机制是：你不再决定「哪条素材上线」，你决定的是「提供一个什么样的素材池，让平台的组合空间足够有信息量」。Google 官方给的效果数据（均为 Google 内部数据，注明了不同时间窗）：把 RSA 的广告强度从 Poor 提到 Excellent，广告主平均获得 15% 更多点击与转化（2025-08-15 至 08-20）；只有一条 RSA 的广告组加到两条，转化平均提升 6.6%（同成本下）；加到三条，再提升 3.7%（同成本下）。另一份 AI-powered Search 指南给出的口径是 Poor→Excellent 带来 12% 更多转化（2023-02-28 至 03-01）。同一份文档引用 tails.com 案例：采用 broad match + Smart Bidding + RSA 的组合后，在德国的注册量较通用广告活动提升 182%，点击提升 258%。
把这些数字串起来，能得到一个对发行侧工程设计很关键的推论：素材数量本身是一种收益。不是「多即是好」的玄学，而是平台在固定预算下需要足够的组合多样性来找到对的路，而组合多样性直接由你提供的素材池的规模与结构决定。这正是 Google 官方那句「用 AI 工具创造更多素材资产」背后的机制。
直接把上述结论理解成「生成越多越好」会立刻撞墙。平台的组合机制有两条约束会惩罚同质素材：一是算法会自动规避冗余组合，二是重复素材会挤占有限的展示位与预算。既然 enhanced flexibility 允许素材在广告组之间互相借用，那么你的整个广告组矩阵里如果都是「同一张图换标题」，平台能探索的组合空间实际上塌缩成了一个点。
所以素材工厂真正的技术指标不是数量，而是正交性：在风格、构图、卖点主张、情绪、场景、色调这几个维度上，素材之间要有可测量的差异度。faiss 之类的向量索引在这里的作用是工程化的去重与聚类：把候选素材向量化，剔除落在同一簇内的近重复，只保留每个簇的代表，然后检查各维度的覆盖度是否达标。这个「聚类去重 + 维度覆盖检查」的步骤应该成为生成后的自动卡点之一，而不是等投放数据告诉你素材互相打架。
如果团队做中文或日韩市场，生成式文案接进来之前必须先吃下一个约束：Google 明确说明，标题字段支持最多 30 字符、描述字段最多 90 字符、路径字段最多 15 字符，并且中日韩等双宽字符按 2 个字符计。也就是说中文标题的真实预算是 15 个汉字，不是 30 个。
这个约束必须硬编码进文案生成模板并作为自动断言项，因为它是那种「模型自己绝不会主动提醒你」的规则——让 LLM 写一条 30 字符的中文广告语，它会很乐意给你 30 个汉字，然后用不了。描述字段的 90 字符对应 45 个汉字。文档里还有一个细节值得记下来：标题与描述可以出现在任何顺序，因此每一条都必须单独读得通，且组合起来不能违规——这又回到 5.2 的正交性要求上。
另外，Google 文档提到 RSA 素材可出现在 AI Overviews 上下方或内部，公开说明该能力当时仅在英语、且在澳大利亚、加拿大、印度、印度尼西亚、肯尼亚、马来西亚、新西兰、菲律宾、新加坡、美国共 11 个国家的移动端与桌面端可用。截至本文写作时，官方文档未公开「素材被 AI 摘要引用时如何计入效果」的具体机制，因此这一块只能标注为「公开数据不足」，不做推断。
Apple 的 AdAttributionKit 文档把归因这件事的结构讲得非常清楚，而这个结构直接决定了素材级效果评估能做什么、不能做什么。
参与方有三类：签署广告并在转化后收到回传的广告网络、展示广告的发行方应用、更新转化价值并把回传转给开发者的被推广应用。关键的机制细节有五条：
did-win=true 的回传；did-win=false 的落败回传；把这五条翻译成素材工程的语言，会得到几个不太舒服但必须接受的结论。
结论一：iOS 侧不存在「最后一触归因」这个可信假设。 一个安装最多有 6 个网络拿到回传（1 赢 + 5 落败），把收益完全归给最后一个点击会系统性偏置素材评估，而且偏置方向与竞价结构强相关，不是随机误差。用素材维度的 LTV 排序时，必须显式建模这层结构。
结论二：落败回传是最被浪费的数据。 did-win=false 的回传看起来「没用」，实际上它是受控的增量对照信息——它告诉你某次曝光如果换一个网络承接会是什么结果。用它做倾向得分或分层的稳健性检查，比只用赢家数据要可信得多。
结论三：再互动场景的归因是残缺的。 没有落败回传，意味着老玩家回流这条链路上的素材效果无法用同样的方法评估，必须另设口径，不能和首装素材混在一张表里比较。
结论四：粒度受数据层级约束。 你拿到的归因字段组合是被 Apple 判定的层级决定的。素材级分析必须按层级设计 schema，否则会遇到「上周还有的字段这周没了」的断档。
结论五：归因不是隐私开关的附属品。 不需要 ATT 也能收归因回传，意味着归因基础设施不该被挂到「隐私合规项目」下面拖延，它属于发行数据基建本身。
上面五条合起来给出的现实是：素材级效果的因果评估在当前隐私框架下不可能做到干净。工程上唯一稳定的做法是承认这一点，转而经营一组代理指标，并明确每个代理的偏差方向：
不要试图用一个指标做决策。合理的结构是：快指标（CTR/CVR）负责在小时到天级筛除明显失败的素材，慢指标（留存/LTV）负责在周级决定预算分配，而两者之间的差异本身要被监控——快指标与慢指标持续背离，是素材过度承诺（clickbait）的可靠信号，应当触发素材下线或返工。
AppLovin 页面上同时挂着归因（Adjust）与创意（Wurl）产品线，这说明创意生产与效果归因正在同一供应商体系内闭环。对开发者的直接后果是：你可能永远拿不到跨平台的、可交叉验证的素材效果真相。
因此有一张表必须自己维护，且它的优先级高于任何单个投放平台的报表：
material_id 平台侧素材 ID 与内部 recipe_id 的映射
platform 投放渠道与版本
segment 定向包 / 受众 / 地域
spend / impressions / clicks / installs
d1_d7_retention 分层留存
predicted_ltv 预测值 + 预测版本 + 校准时间戳
attribution_tier 该条记录对应的归因数据层级
win_loss_flag 赢家/落败标记（来自回传时写入）
这张表的价值不在于它比平台报表更准，而在于它是唯一一份在平台更换、账户迁移、政策变化后仍然存在的资产。素材工厂的产物如果只存在于广告平台的账户后台，那这轮迭代学到的东西在下一轮合作里会归零。
素材选择形式上是一个 bandit 问题：每次投放一个素材臂，获得奖励。但它比教科书 bandit 难得多，有三重困难。
困难一：奖励延迟且有偏。 你今天投的素材，价值要几天后才在 LTV 上体现；而买量预算每天都在消耗。UCB 这类算法假设奖励及时返回，直接用会让乐观估计持续膨胀。
困难二：环境非平稳。 版本更新、节假日、竞争对手出价、平台算法改版，都会让「素材 i 的历史平均收益」迅速失真。非平稳 bandit 的处理要求滑动窗口或时间衰减权重，静态历史表是错的。
困难三：预算耦合。 臂之间共享同一个预算池，探索某条新臂的机会成本是其他臂的真实收益。忽略这一点会系统性高估探索价值。
据此，一套可落地的分层策略是这样的。
外层：受约束的组合实验，按规格配比固定预算。 每个规格（不同的画幅、文案长度、人群包）分配固定预算份额，在份额内做内部竞争。外层不做探索，只保证每个规格都有稳定的对照基数——这是让层内结论可外推的前提。
层内：先用快指标做 Thompson Sampling 快速筛除，再用慢指标做长跑。 在秒到小时级就能拿到的奖励（CTR、安装率）上跑 Thompson Sampling，把明显失败的臂尽早剪掉，节省下后续的算力与预算；通过初筛的臂进入以留存/LTV 为奖励的长跑阶段，这时候可以用探索预算受控的 UCB，但必须配「止损条件」——例如单条素材当日花费超过基准 CPA 的 X 倍且零安装，立即下线。
为什么止损规则比奖励函数更关键：在延迟归因的现实里，探索的代价是延迟发现的亏损。一个设计不当的探索可能在三天后才发现，而三天的预算已经烧掉了。止损规则是对这个延迟的对冲，它把探索的最大损失从「几天」压缩到「小时」。这条经验比任何 bandit 超参调优都值钱。
工程实现的选型：在线学习与上下文 bandit 可以用 Vowpal Wabbit（8731 stars，最近推送 2026-10-15，仓库许可字段未声明明确 SPDX 标识，商用前需核实）——它把 contextual bandit 作为一等公民支持；实验编排与算法基线可以参考 google/vizier（1680 stars，Apache-2.0，最近推送 2026-10-20）；算法本身的选择与复现用 pytorch/rl（3611 stars，MIT，最近推送 2026-10-25）或 ray-project/ray（44122 stars，Apache-2.0，最近推送 2026-10-25）。
最后一条不可妥协的工程要求：素材 ID 必须能反向解析回配方。否则三个月后 bandit 学到的「哪类素材有效」无法映射回具体的提示词、种子与 LoRA，学到的只是无法使用的相关性。§3.3 的配方账本与 §6.3 的效果对照表之间的外键，是这套体系成立的支点。
下面这些判断没有公开数据支撑，是工程实践层面的主观评估，但它们直接影响资源分配，值得写明。
最被高估的：「AI 能替代发行侧的概念美术」。 发行素材的真实成本结构与运行时资产不同。运行时资产的成本在制作，发行素材的成本在审批与合规——每一张对外的图都要过品牌、法务、平台政策三道关。生成变体把绘制成本压到接近零的同时，把待审基数放大了 N 倍，而人审是 O(N) 的。这直接构成 §2 里 中人审工时项的主导部分，也是很多团队「素材量上去了、迭代速度反而变慢」的原因。解法不是少生成，而是在生成侧就把审核维度结构化：风格一致性、元素出现与否、文案合规、肖像授权分别做成独立的自动断言，人只看机器判不了的部分。
最被高估的：「素材越多效果越好」。 见 §5.2，数量只有在正交的前提下才转化为组合空间。同质素材会让平台的自动组合退化，此时增加数量只是在浪费预算和稀释注意力。
最被低估的：素材工程的元数据与复现层。 这是一个纯软件工程项目，没有任何 AI 成分，也没有任何创意成分，但它决定了 AI 生成的部分能不能被使用。配方账本、规格版本化、效果外键——这三样东西做不扎实，生成侧做得再好也只是在生产一堆无法追溯的图。
最难解决的：归因黑盒与平台内闭环。 当创意生产与效果归因在同一个供应商体系里，「哪条素材真正带来留存」这个问题可能从根本上无法被外部独立回答。可行的缓解是保持多平台并行、保持自建对照表、保持素材配方可迁移，而不是试图在单一平台内部得到确定答案。
最大的外部风险：规则与规格的持续变更。 2024 年 8 月的胶囊尺寸调整只是最近的一次；AI 披露规则、AI Overviews 投放能力、各平台的合成内容政策都在演进。素材流水线的正确形态不是一次性交付物，而是可重跑的配方——把「当前有效的规格表、当前的披露口径、当前的归因 schema」当作流水线的输入版本，这样规则变化时你重跑一遍，而不是推倒重来。
一个诚实的空白：截至本文写作时，公开渠道没有关于「生成式素材在游戏买量中的真实增量收益」的系统性对照数据。Google、AppLovin 等平台公布的是自己的产品级指标，不等于游戏场景下的素材级增量。市面上流传的「用了 AI 素材后提升 X%」这类说法多数无法查证其口径（是同素材对比还是跨素材、是否控制了竞价与人群差异、观察窗口多长）。因此本文给出的所有框架都刻意停留在「结构」层面而非「效果结论」层面：结构是团队自己可以验证的，效果结论必须由每个团队在自己的数据上跑出来。
按投入产出顺序排列，每一项都对应前文的具体机制。
收束成一句话：游戏发行侧的 AI 化，不在于生成更多素材，而在于把素材从「一次性交付的图片」改造成「带配方、带规格版本、带效果外键的实验单元」，并把合规、归因、决策这三件事的约束全部前置到流水线里。 谁先把配方账本和效果外键建起来，谁就拥有了跨周期可累积的发行知识；谁只把生成 API 接进投放后台，谁每一轮都在从零开始。
一句话摘要：把发行素材从「一次性交付的图片」改造成「带配方账本、规格版本与效果外键的实验单元」——生成侧用 ComfyUI 之类的工作流引擎保证可复现，平台侧用 Steam 规格矩阵与 AI 披露做自动门禁，决策侧用分层 bandit 加止损规则处理延迟归因，谁先把这三层建起来，谁就拥有了跨周期可累积的发行知识。
Conversation
0 条