247 lines
24 KiB
Markdown
247 lines
24 KiB
Markdown
# 渠道发行 · 运营设计文档
|
||
|
||
> **这是什么**：绘境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` 这类能在运行时执行任意脚本的库)。而浏览器没有这种禁令——网页天然就能跑动态生成的代码。
|
||
|
||
这一条差异,把两条发行路线的角色彻底分开了:
|
||
|
||
```mermaid
|
||
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. 渠道发行流程:从生成到上架
|
||
|
||
把上面的分工与合规串起来,一款游戏走渠道线的完整流程如下。这张图也回答了"为什么渠道发布是月级节奏、而不是即时"。
|
||
|
||
```mermaid
|
||
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(见[自治富游戏引擎](../架构/生成引擎/自治富游戏引擎.md)),feed 因此是双产物承载面。这里只裁渠道线这一面的引擎竞标,与 feed 跑什么引擎是两回事。
|
||
|
||
```mermaid
|
||
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`,绝不能把兜底奖励伪装成真实广告收益。
|
||
|
||
遥测(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 这个候选最终胜出时才需要。** 把生产管线拆成三层就清楚了:
|
||
|
||
```mermaid
|
||
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 指"为验证某决策而做的小型探索性实验")。
|
||
|
||
先解释两个候选:
|
||
|
||
- **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 历史里。
|