games-development-ai/docs/architecture/运营/渠道发行.md

渠道发行 · 运营设计文档

这是什么：绘境AI 的「渠道发行」设计文档,回答"平台上做出来的游戏,怎么走到微信/抖音这类外部渠道、又要过哪些合规关卡"。它是渠道发行这个子系统的单一事实源(single source of truth,简称 SoT,意为"想了解这件事看这一份就够,不必再翻别处")。 给谁看:运营负责人、合规与法务、负责渠道对接的工程师、做投资尽调时关心"能不能上架、风险在哪"的人。 怎么读:先读第 1–2 节建立"为什么这么分工、卡在哪些合规关"的全局认知,再按需深入第 3 节往后的架构与引擎选型细节。内部代号(如 L1/L2、一壳多游、备案锁等)都会在首次出现时用一句话解释。 本档定位:对应内部编号 HJ-CH-001(渠道发行子系统的判定文档编号)。它讲清楚四件事——一壳多游(L1)的发行模式、为什么 L2 不上渠道、有哪些合规闸门、两个候选游戏引擎怎么竞标定胜负。落地的实现手册在 .agents/skills/runtime-and-multichannel.md,完整决策史在 git 历史里。

---

1. 一句话与一张图:渠道发行是什么

绘境AI 平台上,创作者用一句话就能生成一款轻量小游戏。这些游戏要被玩家玩到,有两条路:一条是平台自有的 H5 流(H5 = 直接在手机浏览器里打开的网页游戏,无需下载安装),另一条是把游戏推到微信小游戏、抖音小游戏这类外部渠道。这份文档讲的就是第二条路——渠道发行。

这里有一个绕不开的技术现实,它决定了整个分工:微信和抖音的小游戏平台,对"远程下发的代码"有严格管控。 它们会自动剥离掉远程包里的代码,并且明文禁止在小游戏里塞 JavaScript 解释器(比如 eval5 这类能在运行时执行任意脚本的库)。而浏览器没有这种禁令——网页天然就能跑动态生成的代码。

这一条差异,把两条发行路线的角色彻底分开了:

flowchart LR
  GEN["创作者一句话<br/>AI 生成游戏"] --> SPLIT{"走哪条<br/>发行路线?"}
  SPLIT -->|"海量 UGC · 即时发布<br/>(主线)"| H5["自有 H5 流<br/>浏览器无代码禁令<br/>任意动态生成都能跑"]
  SPLIT -->|"精选款 · 固化进包<br/>(渠道线)"| CH["微信 / 抖音小游戏<br/>一壳多游 · L1 整包过审"]
  H5 --> PLAY1["玩家在游戏信息流里<br/>即刷即玩"]
  CH --> PLAY2["玩家在微信/抖音<br/>原生入口里玩"]

几个内部术语,在这里一次说清:

• UGC(User Generated Content,用户生成内容):指普通创作者源源不断造出来的游戏。绘境AI 的核心卖点就是让零基础用户海量造游戏,所以"海量 UGC"是平台的主战场。
• 一壳多游:渠道线的核心打法。在一个微信/抖音 appid(应用唯一标识)的"壳工程"里,放固定不变的模板代码,然后用远程下发的纯数据配置去驱动出不同的游戏——一个壳,装多款游戏。
• L1 / L2:游戏的两个"层级"。L1 指用平台预置模板、只调数据参数就能产出的精选游戏(代码固定、只换数据);L2 指允许改动游戏逻辑代码的进阶玩法。下文会反复用到这组概念。

一句话总结分工:渠道线只做 L1 精选整包过审,对外口径是"主题小游戏合集",而不是"开放的 UGC 平台";自有 H5 流才是 UGC 海量生成、以及 L2 改码玩法的主场。两条线互不上跳、不外导(即微信渠道内的游戏之间不互相跳转、也不把用户往外部网页导流),以符合渠道对"内容边界清晰"的要求。

对外统一措辞,定为一句话:「自研流即时发布 + 双渠道精选发行」。

---

2. 为什么这么分工:三条根因

把"海量 UGC 留在 H5、只让精选款上渠道"这件事拆开,背后是三条扎实的理由。

根因一:技术管控。 如前所述,微信/抖音对远程包会自动剥离代码、禁止 JS 解释器,所以渠道里只能跑"包内固定的模板代码 + 远程下发的纯数据配置"。浏览器没这个限制,自研 H5 因此成为动态生成代码的唯一容身之处。这不是产品选择,是平台规则倒逼出来的架构。

根因二:审核颗粒度。 渠道的内容审核是针对"每一款具体游戏的内容"做的,而不是针对一个 appid 一次性放行。这意味着,如果想让成千上万款 UGC 游戏各自挤上渠道,审核根本不可行——每款都要单独过审。所以海量长尾只能留在 H5,渠道只接得住"精选"。

根因三:发布节奏。 每款游戏在绘境AI 里都是一个 agent(AI 智能体)独立生成的代码。常规的新游戏,跟着渠道"壳版本"的发布节奏整批进渠道,这与"精选整包发行"的对外口径是自洽的——不是"每出一款就单独提审",而是"攒一批、随壳版本一起提审"。

由此得出 L2/L3 这些进阶层级的渠道命运:默认主线永远是自研 H5 流(它的"即时生成—发布"闭环是完整的);上渠道只有两种特例——要么把某款精选游戏固化进包版本去提审,要么给某款重点游戏(B 端定制、IP 旗舰、已验证的爆款)单独配一游一 appid。

---

3. 合规闸门:能不能上架,卡在这几道关

渠道发行最大的不确定性不在技术,而在合规。下面把平台规则核查后的活结论逐条列出——每一条都是"上线前必须确认"的硬约束。(每条结论的置信度评级与原始政策出处 URL 已归档在 git 历史与第 8 节指针里,此处只留落地结论。)

3.1 版号与 IAA 通道

版号指游戏正式商用前需要的出版审批号。这里有个关键通道:纯 IAA 游戏可以免版号上架。 IAA(In-App Advertising,应用内广告)指游戏只靠广告变现、不卖任何内购道具。纯 IAA 游戏走的是"软件著作权登记(软著)/ 电子版权认证 + 自审自查 + ICP 备案(网站经营性备案)"这条路上架,资质审核大约 1–3 个自然日;个人主体也可以上架并开通流量主(即接入广告分成)。版号只对有内购的游戏强制。

但有一个真实存在的风险:审核员有裁量权,可能要求纯广告游戏补版号材料。 已有真实判例是纯广告游戏被要求补交材料,而且 2025–2026 年是政策敏感区,落地前必须复核。(此前流传的"4–6 月集中清退无版号存量"已确认是谣言,警报解除。)

3.2 备案锁——比版号更紧的决定性闸门

这是整套合规里最关键、最容易踩的一道关,务必看清:

官方规则写明——备案完成后,不支持再改游戏内容、icon、代码;任何实质性变更,都必须重新备案。 我们内部把这条规则叫**「备案锁」**(意为:一旦备案,游戏内容就被"锁死"了)。

这条规则直接把"一壳多游"从"灰区可行"降级为"高风险待裁"——因为"壳合规"不等于"壳里每款游戏的内容都合规",而备案锁恰恰锁的是内容。面对它有三条出路:

1. 每款精选游戏各自独立备案(最稳,但成本最高);
2. 把壳内的游戏集合稳定下来,任何变更都统一走"重新备案 + 整包提审",节奏放到月级;
3. 并入法务/律所议题,由律所给出权威裁决(挂在内部 W3 工作流议题下)。

一个必须收回的旧叙事:「当日热发新游进渠道」这个说法被收回了。 在渠道线里,所谓"热发"只能是对既有游戏做非实质性的参数微调(具体边界等律所结论)。注意——这条只约束渠道线,完全不影响自有 H5 流(H5 没有备案锁)。

3.3 其余四条合规结论

• 公测=运营(目前仍是草案):有一份《网络游戏管理办法(草案)》第 21 条,把"公测"定性为"运营行为"。但截至 2026 年 6 月它仍是草案、未生效。对应到我们的灰度测试,合规出口是:测试人数 ≤ 2 万人 + 不接广告 + 报备并删档——这条写进发布流程红线。也就是说,种子创作者做外部测试时,只要挂了广告就构成"运营",必须先备案。
• 抖音口径:抖音执行**「一软著一游戏」**——每款游戏对应一份软著,且备案是上架前置(平台代为申报,不是"先上线后备案")。两个平台口径一致,未见 2026 年有额外收紧。
• 题材黑名单:棋牌、捕鱼这类题材,即便是纯 IAA 也需要律所出具季度更新的合规报告。因此把它们列入生成侧的题材审查——在游戏生成之前就拦掉。
• 运营事实(保留一行):流量主开通门槛是日活跃用户(UV)≥ 1000;IAA 广告分成比例,微信约 50%~90%、抖音约 70%~90%(分别来自微信流量主、以及字节的穿山甲/巨量平台)。

---

4. 渠道发行流程:从生成到上架

把上面的分工与合规串起来,一款游戏走渠道线的完整流程如下。这张图也回答了"为什么渠道发布是月级节奏、而不是即时"。

flowchart TD
  A["创作者生成 / 平台精选<br/>一款 L1 游戏"] --> B{"题材审查<br/>(生成前闸门)"}
  B -->|"棋牌/捕鱼等黑名单"| BX["拦截 · 转律所合规报告"]
  B -->|"通过"| C["产出 GameConfig 纯数据<br/>(零构建 · Linux 工厂全自动)"]
  C --> D{"GameConfig 合规红线校验<br/>schema + hash + 静态扫描"}
  D -->|"含可执行串/远程代码<br/>命中违规"| DX["打回 · 修正配置"]
  D -->|"纯数据 · 全枚举白名单"| E["攒入精选游戏集<br/>随壳版本节奏"]
  E --> F["软著登记 + 备案<br/>(备案锁:此后内容不可改)"]
  F --> G["整包提审<br/>miniprogram-ci 无人化上传"]
  G --> H{"平台审核<br/>(内容颗粒度)"}
  H -->|"驳回"| HX["归因分类<br/>engine/package/compliance"]
  H -->|"通过"| I["上架微信 / 抖音<br/>玩家原生入口即玩"]
  I --> J["广告变现<br/>showRewarded → 平台原生广告"]

  style F fill:#ffe6e6
  style D fill:#fff2cc

图里两道带色的关卡是渠道线的"生死线":黄色的 GameConfig 合规红线(第 5 节详述)决定下发的数据是否纯净,粉色的 备案锁 决定上架后还能不能改。正是备案锁的存在,让"攒一批 → 统一备案 → 整包提审"成为月级节奏,而非即时热发。

---

5. 现行架构:Channel Runner v1 与 GameConfig 合规红线

渠道线在技术上不复用平台自有 H5 流的 Runner v2(Runner 指"游戏运行时容器",负责把游戏跑起来),而是新增一套专门的双形态架构。需要说明:信息流(feed)轻量档用 LittleJS 引擎的决定不动;但 feed 并非只跑这一种引擎——第二条生成轨 tier2 的富游戏另有一条 Phaser 装载路渲入 feed(见tier2 富游戏设计(并入运行时 SoT §4.2/§5)),feed 因此是双产物承载面。这里只裁渠道线这一面的引擎竞标,与 feed 跑什么引擎是两回事。

flowchart LR
  subgraph PKG["壳工程随包提审 · 微信/抖音各一份"]
    A["渠道 SDK / 广告 / 遥测<br/>+ canvas-input-audio-storage<br/>四件 adapter"] --> B["模板注册表<br/>templateId 仅命中包内白名单"]
    B --> C["L1 模板代码 + 核心层 + SDK<br/>(全部随包,固定不变)"]
  end
  D[("远程 GameConfig<br/>gameId / versionId / configHash")] -->|"schema + hash 校验后实例化"| C
  C -->|"SDK postMessage 同上下文直连<br/>ad.showRewarded 直调 wx/tt API"| E["平台 wx / tt 运行时"]
  F["安全边界:静态代码扫描<br/>+ schema 红线 + 域名白名单<br/>+ 包 hash + 真机取证"] -.->|"替代浏览器的 iframe+CSP 隔离"| C

读图要点:壳工程(随包提审的那部分)里,模板代码、核心层、SDK 全都打进包里、固定不变;真正区分出不同游戏的,是那份远程 GameConfig——一份纯数据配置,带 gameId、versionId 和 configHash(配置内容的哈希指纹,用于防篡改)。配置经过 schema 与 hash 双重校验后,才被实例化成具体游戏。由于渠道里不能用浏览器的 iframe 沙箱隔离,安全边界改由"静态扫描 + schema 红线 + 域名白名单 + 包 hash + 真机取证"这一组手段来守。

5.1 GameConfig 合规红线(渠道生死线)

这是渠道线最不能破的一条线,转正后会成为契约库里的 9c 契约(契约 = 跨端共享、不可随意改动的数据格式约定;9c 是其中第 9 类的 c 子项,专管渠道版 GameConfig)。它的硬性规定:

• 禁一切可执行/可解释的字符串——比如 condition: "score>10" 这种"把逻辑写成字符串、运行时再解释执行"的写法,一律禁止;
• 禁远程下发 entry / templateUrl / WASM / JS / HTML / 脚本化 SVG 等任何形式的代码;
• 剧情和关卡逻辑必须写成有限状态机的枚举(用 conditionType + params、actionType + params 这种"类型 + 参数"的固定结构表达),禁止使用任何通用的 DSL(领域特定语言,这里指能自由编程的脚本);
• templateId、actionType、assetId、adSlotId 等关键字段,全部必须是枚举白名单里的值;
• schema 设 additionalProperties: false(不允许出现未声明的字段),并对数值范围、字符串长度、文件 MIME 类型、大小全部加限制;
• 远程素材只允许图片/音频/图集(atlas)/json,且必须带 hash、且只能来自白名单域名。

一句话:渠道里的"游戏逻辑"必须是数据,不能是代码。 这是整条渠道线能成立的根基。

5.2 广告与遥测

广告这条线,接口是 showRewarded(slotId)(展示一支激励视频广告,slotId 是广告位逻辑标识),它会映射到平台原生的 wx/tt.createRewardedVideoAd,把逻辑广告位 slotId 翻译成平台的 adUnitId;此外增补 showBanner / hideBanner 管理横幅广告。这里有一条不容造假的红线:rewarded=true(用户完整看完广告应得奖励)只认平台返回的"完整观看"回调;如果走兜底发奖,必须标记 reward_fallback=true,绝不能把兜底奖励伪装成真实广告收益。

还有一条运行时体验红线,和上面计费侧的口径是两码事:广告在玩家端加载失败时,必须跳过广告、让游戏继续,绝不能因为广告问题把游戏卡死(创始人 2026-06-22 历史回收判定捡回)。变现端到端§2.1 讲的是后端计费侧的降级口径——广告联盟没注册时降级到 mock 可接受,代价只是少算些收入;这条讲的是玩家正在玩的运行时侧——广告 SDK 拉不出来(load-fail)、超时(timeout)、无填充(no-fill)是常态而非异常,SDK 适配层遇到这些必须静默吞掉、把控制权还给游戏循环,玩家该玩玩、该结算的奖励按兜底发(reward_fallback=true 计入),绝不能让一支拉不出来的广告把整局游戏阻塞在等待态。对一个靠广告吃饭的 IAA 平台,广告偶发失败把游戏卡死,对留存的伤害远比少算一笔收入严重——广告体验直接是留存生命线。这条红线跨在变现与前端运行时的交界上,两侧各以为对方会守、结果都漏了,所以在渠道线的广告接口这里钉死:showRewarded / showBanner 的实现契约里,所有加载失败路径都不得向上抛出阻断游戏的异常。

这条红线和 §8.1 P1 真机门里的 G4 广告五路径(success / close-before-complete / load-fail / timeout / no-fill)是同一件事的验收面——G4 要求 load-fail/timeout/no-fill 三种失败情况都被正确处理,而"正确处理"的判据正是这里定的"跳过广告、游戏继续",不是把失败当致命错误。

遥测(telemetry,即埋点数据采集)方面,渠道专属字段作为 9g 转正候选 补入——与上面 §5.1 的 9c 同属"渠道线转正后才落库"的命名,现行遥测事件仍是契约 #5(events.schema.json,这些渠道字段尚未并入)。要补的字段是:channel、channelAppId、adUnitId、logicalSlotId、packageVersion、configHash、requestId、ad_event_type、platform_callback、settlement_batch。性能监测的"七锚点"在渠道版里展开为一串时序埋点:t_launch → t_runner_boot → t_canvas_ready → t_sdk_ready → t_config_loaded → t_first_paint → t_input_bound → t_game_start,用来精确度量从启动到游戏可玩的每一段耗时。

---

6. 生产管线:Win/Mac 依赖只在一个环节

有人会问:Cocos(一款游戏引擎,见下节)不能在 Linux 服务器上无人化构建,那渠道游戏的生产岂不是处处要人工?答案是——对 Win/Mac 桌面环境的依赖只落在三层里的第②层,而且仅当 Cocos 这个候选最终胜出时才需要。 把生产管线拆成三层就清楚了:

flowchart TB
  L1["① 每游戏生产(高频 · 主路径)<br/>GameConfig + 资产<br/>Linux 工厂全自动 · 零构建 · 不碰引擎"]
  L2["② Runner 壳版本发布(周/月 · 低频)<br/>C-A=LittleJS:esbuild 纯 Node 全 Linux ✓<br/>C-B=Cocos:须 Win/Mac 构建机"]
  L3["③ 上传提审(平台强制 · 低频)<br/>微信 miniprogram-ci 纯 Node 可 Linux<br/>抖音 tt-ide-cli 同类(待核实)"]
  L1 --> L2 --> L3
  NOTE["绕不开人工的只有<br/>平台审核节奏本身 · 与引擎无关"]
  L3 -.-> NOTE
  style L2 fill:#fff2cc

• 第①层是高频主路径:每款新游戏的生产,本质是产出 GameConfig 和资产,由 Linux 工厂全自动完成、热下发到线上,完全不碰引擎构建。这正是"禁动态代码"反过来带来的架构红利——逻辑都是数据,生产就能零构建。
• 第②层是低频的壳版本发布:只有壳工程升级时才发生(周/月级)。这一层才区分两个引擎候选:LittleJS 用 esbuild 纯 Node 即可在 Linux 全自动构建(已实证);Cocos 则需要 Win/Mac 构建机(Mac mini 或云端 runner,是真实运维成本,但不阻断流程)。
• 第③层是平台强制的上传提审:微信官方提供 miniprogram-ci(纯 Node 工具,可在 Linux 无人化上传和预览);抖音的 tt-ide-cli 是同类工具(待 P1 阶段核实)。

结论:真正绕不开人工的,只有平台审核节奏本身,这跟用哪个引擎无关。下一节提到的"三件套"(微信 AppID + Win/Mac + 安卓真机)是 P1 人工取证阶段的需求,不是生产常态。

---

7. 渠道引擎竞标:LittleJS 对决 Cocos

渠道线该用哪个游戏引擎来打包,没有在"层"这一级锁死,而是在"场景"级锁定默认 LittleJS、并保留创始人复议权(2026-06-12 拍板)。这件事用一场竞标来定胜负,内部代号 W-CH-α(渠道引擎对比 spike,spike 指"为验证某决策而做的小型探索性实验")。

另:tier2 设计对"Cocos 的渠道优势"做了一套祛魅论证(weapp-adapter 官方已不再维护、变现 SDK 各引擎都得手接、快手全平权、纯代码引擎全 Linux 出包反而占优,见 tier2 富游戏设计(并入运行时 SoT) ../架构/生成引擎/agentic运行时架构图说.md §4.2/§5 渠道一节)。那是从"无头自治生成"角度来的、与本竞标"轻量档渠道发行"维度正交,不改本竞标结论;但作为新信息,W-CH-α 终裁时一并参考、别漏。

先解释两个候选:

• C-A = LittleJS + 自研 adapter:LittleJS 是一款极轻量的 2D 游戏引擎(压缩后约 55KB),配上我们自研的微信(weapp)/抖音(tt)适配层(adapter,负责把引擎对接到各平台 API)。
• C-B = Cocos 原生导出:Cocos Creator 是一款成熟的商业游戏引擎(3.8.x 版本),用它的官方"原生导出"功能直接产出小游戏包。

竞标在 统一场景 下进行,以保证公平:同一套 L1 模板(主测 tycoon「模拟经营」玩法 + 用 clicker「点击」玩法测量边际成本)、字节级完全相同的 GameConfig(公平性红线——禁止为某个候选单独调参),微信/抖音双端各出一个包。其中 clicker 只进"体积"与"每加一个模板的边际成本"两项计分,不进真机门(出于时间盒约束)。

	C-A	C-B
引擎	LittleJS 1.18.x(锁定 T1 终裁版本)+ 自研 weapp/tt adapter	Cocos Creator 3.8.x(精确小版本写入报告)原生导出
入包内容	壳 + adapter + engine(经 tree-shaking 摇树裁剪)+ 核心层 + 双模板 + 基础素材	壳(官方模板冻结基线)+ core + 同样的双模板 + 基础素材
出包	微信 + 抖音各一包	同左

7.1 决策规则与翻盘条件

怎么判胜负:如果 LittleJS 的 adapter 能过全部的门、且后续维护面可控,那就优先选单代码库方案(C-A)——好处是"模板工艺只做一次";反过来,如果 adapter 太脆弱、或在体积/性能上出线,那就让 Cocos 接渠道线(C-B,复用已有的引擎投资)。无论谁赢,GameConfig 都做到引擎无关,保证 Linux 工厂不会因引擎而分叉。

翻盘条件:被判输的一方,如果在真机或审核环节出现了对方没有的"结构性阻断"(比如某平台根本跑不通),可以持证据复议。

计分维度(G1–G6 等):通过的门数量 / 主包余量 / 真机首屏 ≤ 2s / 双实现成本三列(首个模板迁移的一次性成本 · 后续每加一个模板的边际成本〔用 clicker 增量实测〕· 平台 API 漂移的维护归属) / agent 友好度(纯代码 vs 编辑器+MCP) / 构建管线能否服务器化。为防止"单代码库"被一次性成本系统性抬分,敏感性分析必须包含两个变体:① 把裁量分拉平后再比一次;② 剔除首模板一次性迁移成本后再比一次。

7.2 公平性生命线

竞标的公平性被置于一切产出之上,具体手段:所有候选共用一份只读的 channel-probe(探针脚本,各 lane〔即各候选的独立工作目录〕禁止改动,由主会话做 diff 校验)+ 八锚点的字段级定义 + JSONL 哈希链作为主证据(每条记录带 seq 序号、单调时钟、前一条的哈希、device、configHash,形成防篡改链)+ 真机测试全程禁止状态注入(禁用一切 evaluate/调试器手段改游戏状态)。一条铁律:主证据必须是机器可校验的文件,录屏和截图一律降为辅证。

7.3 LayaAir 为什么出局(写死,复评前不重问)

竞标本来有第三个候选 LayaAir(另一款国产 2D/3D 引擎),但已尽调出局,两条硬理由:

1. 没有面向 agent 的 MCP 工具面——它宣传的"AI 引擎"其实是 IDE 内嵌的人工 AIGC,官方把"AI 代码生成"标为"规划中";反观 Cocos 的 cocos-mcp(让 agent 直接驱动引擎的工具集)已有 158 个工具、相当成熟。绘境AI 是 AI 驱动开发,引擎能不能被 agent 直接操控是硬指标。
2. 体积比 LittleJS 重一到两个数量级——LittleJS 压缩后约 55KB,LayaAir 远超于此。

复评触发条件(满足才重新评估 LayaAir):它出现官方或成熟社区的 MCP server,或官方公布"2D-only 小游戏核心体积"数字且远小于 Cocos。

---

8. 当前进展与关键指针

8.1 已完成 / 在飞 / 待办

已完成(DONE):HJ-CH-001 判定定稿,加三项创始人拍板——

• C1:分工口径确定为「自研流即时发布 + 双渠道精选发行」;
• C2:一壳多游以渠道合规为准绳(默认走月级"重新备案 + 整包提审";若律所判定必须每游独立备案则照办——合规优先于经济性);
• C3:W-CH-α 升级为渠道引擎对比竞标制。

W-CH-α 的 P0 先行段五件产物已交付(adapter v0 + 体积清单 SIZES + 合规 schema + 扫描器 30 个测试用例〔15 合规 / 15 违规〕+ Channel Runner 壳骨架 + channel-probe + 操作手册 RUNBOOK),验证门 6/6 全部 PASS(提交 bb12d30c)。

在飞(暂停中):W-CH-α 的 P1 真机测试段七道门——

• G1 装载:主包 ≤ 4MB;
• G2 模拟器全循环:在平台模拟器里跑通完整游戏循环;
• G2b 真机真输入:双端 × 双候选,各 3 次真实触摸,完成 tycoon 闭环(含终局);
• G3 真机首屏:三开协议,判定值 = 杀进程冷启动,从 t_launch 到 t_game_start ≤ 2s;
• G4 广告五路径:success / close-before-complete(没看完就关) / load-fail / timeout / no-fill 五种情况都要正确处理;
• G5 审核门:预检计分 + 真实提审观察,驳回归因分类(engine/package/compliance 计入,资质/类目/IP 类驳回入残差);
• G6 网络门:只允许访问白名单域名。

P1 的硬前置是创始人提供三件套:微信 AppID + Win/Mac 构建机 + 安卓千元机(及测试号)。

待办:W-CH-β 渠道线正式建设(两个壳工程 → 分发中台〔按"一壳多游·主题合集"口径〕→ 广告 adapter + 9g 字段 → 渠道评估门),等竞标过门后开工。还有几项非工程前置(需法务/律所):一壳多游的类目报备 / 软著申报节奏 / H5 站资质的律所结论(挂 W3) / IAA 政策敏感区上线前复核。

8.2 关键指针(契约 / 代码 / skill / 上游)

• 代码资产(请勿误清理):docs/agent-specs/2026-06-12-channel-spike/ 下三个 lane——lane-littlejs-adapter/(含 src/test 与 REPORT/SIZES/RUNBOOK)、lane-cocos/、shared/(channel-probe.js / runner-shell.js / game-config / schema,只读区,各 lane 不得改动)。P0 产物与 P1 执行册作为竞标资产保留。
• 契约:GameConfig 渠道版 schema 转正后 → 契约库 contracts/game-package.schema.json 的 9c;遥测渠道字段 → 9g。
• skill 手册:.agents/skills/runtime-and-multichannel.md 第 6 节"多渠道导出"。
• 上游回写:HJ-GEN-001(生成主线判定文档)的 D13/§3/§7,以及 .agents/knowledge/tech-decisions.md §1.1(导出枢纽 = 微信小游戏格式包;快手无专用接口,走"微信格式兼容转换";LayaAir 清单里没有快手)。
• 终裁物:渠道引擎计分终裁包(格式同 T1 引擎终裁:计分表 + 裁量分声明 + 敏感性分析 + 翻盘条件),P1 跑完后产出,经 Codex 评审、创始人终裁,再回写 HJ-CH-001 / HJ-GEN-001,最后过 wave-close 七步收口。原始政策出处 URL 索引,保留在判定文档原档的 git 历史里。