games-development-ai/docs/architecture/运营/合规闸门.md

topic, canonical, date

topic	canonical	date
合规闸门	true	2026-06-10

运营域 · 合规闸门

这是什么：绘境AI 在中国大陆上线前必须穿越的一组合规闸门(compliance gate——一道必须通过的法定或资质前置条件,没过就不能上线对应功能)的设计说明。它回答"为什么会卡、卡在哪、按什么顺序拆"。 给谁看:创始人、运营、法务对接人,以及任何需要理解"产品做得出来但为什么还不能公开经营"的同事。 怎么读:先读本页建立全局认知(死锁的成因、双层定性的破局思路、12+1 道闸门的全貌);逐项的实时状态、负责人、最晚提交日不在本页,而在唯一跟踪面 A1 闸门看板——状态会变,看板才是当下真相,本页只讲不变的设计逻辑。 边界:本页只讲"合规"这半。战略叙事(三线变现排序、护城河、经济模型的对外口径)已归到产品域的商业定位,本页不重复。

---

1. 一句话与一张图:合规为什么是绕不开的主线

绘境AI 的工程能力可以把一款小游戏从一句话生成出来,但**"做得出来"不等于"能合法地公开经营"。在中国大陆,一款面向公众、可被陌生人玩到、并且能产生收入的网络游戏,要同时满足三组监管要求:游戏本身要有版号**(国家新闻出版署核发的网络游戏出版物号,是游戏合法商业化运营的前提)、要接入官方的实名与防沉迷系统、平台代收代付的资金要有合法的归集与分账资质。绘境AI 的产品形态——用户用一句话生成的 UGC(User-Generated Content,用户生成内容)小游戏,数量多、单款轻、无版号——恰好让这三组要求互相缠成一个死结。

破局的办法不是硬闯,而是双层定性:把"自有平台"和"渠道分发"拆成两条合规路径,各自走各自能成立的通道。下面这张图是理解整份文档的主干——它说明三组监管要求如何缠成死锁,以及双层定性如何把死锁解开:

flowchart TB
  subgraph 死锁["合规死锁:三条约束互相锁死"]
    direction TB
    A["无版号<br/>(UGC 小游戏拿不到/拿不起版号)"] --> B["接不进官方实名/防沉迷系统<br/>(版号是接入前提)"]
    B --> C["自有端无法履行<br/>实名/防沉迷法定义务"]
    A --> D["IAA 免版号豁免<br/>仅在微信/抖音备案制内成立"]
    D -.->|"自有 H5 不适用<br/>(监管灰区·有罚没先例)"| C
    E["平台代收广告费<br/>再分账给个人创作者"] --> F["无牌照资金归集<br/>=二清风险"]
  end
  subgraph 破局["双层定性:拆成两条路径"]
    direction TB
    G["自有端<br/>收敛为邀请制内测<br/>·不公开经营·不接真钱"] -->|"试玩 demo 定性<br/>规避出版/防沉迷义务"| H["合规成立"]
    I["变现走渠道<br/>(微信/抖音小游戏备案)"] -->|"豁免通道成立<br/>渠道代管实名/防沉迷"| H
  end
  C -.->|"解"| G
  F -.->|"解"| I

这条主线的含义很直接:短期内,绘境AI 的"真钱"只能从渠道线(微信/抖音小游戏的 IAA 广告)和 B 端项目制收费来;自有平台先以邀请制内测养数据,等律所意见明确、资质到位后再谈公开经营。 后面几节逐层展开这个判断。

术语补充——IAA:In-App Advertising,应用内广告变现,即游戏不向玩家收费、靠展示广告(激励视频、插屏等)赚钱。微信/抖音对走 IAA 的小游戏开了"备案制豁免版号"的通道,但这个豁免只在它们各自的渠道生态内成立,搬到自营 H5 网站就不适用。 术语补充——二清:二次清算的简称。指没有支付牌照的平台,先把多方资金归集到自己账户、再二次结算分发给各收款方的行为,属监管红线。

---

2. 死锁的三条链(为什么不能直接公开经营)

死锁不是单一障碍,而是三条彼此咬合的链条。把它们讲清楚,才能理解为什么"双层定性"是唯一能同时解开三条链的解法。

第一条链:版号 → 实名/防沉迷义务无法履行。 IAA 免版号的豁免只在微信/抖音的备案制框架内成立,自有 H5 平台不适用——这是监管灰区,且有先例:曾有平台(如 Roblox 在国内停服)因无版号运营被处理,绘境AI 内部记录里也明确提到过罚没 111 万元这一量级的先例。没有版号,就接不进出版署官方的实名认证与防沉迷系统;接不进,自有端作为运营方就无法履行法定的实名与防沉迷义务。义务无法履行,公开经营就站不住。

第二条链:平台代收代付 → 二清风险。 假设绘境AI 在自有平台接广告联盟,由平台统一代收广告费、再按比例分账给一个个个人创作者,这等于平台在做一笔无牌照的资金归集与二次清算,踩的就是二清红线。

第三条链:三条约束互为前提,形成连环锁。 上面两条不是并列的,而是连环的——无版号导致义务无法履行,而要做真实变现又必然触发资金归集,于是"想合法经营 → 需要版号 → UGC 拿不到 → 接不进官方系统 → 履行不了义务 → 还要碰二清"形成一个闭环。任何单点突破都解不开,必须换一种整体定性。

解 = 双层定性。 把平台收敛为邀请制内测(用邀请码注册,不开放公开注册),明确"不公开经营、不接真钱",从而落在"试玩 demo / 内测"的定性上,规避公开运营才会触发的出版与防沉迷义务;同时把真实变现全部放到渠道线,借微信/抖音的备案豁免通道成立,实名/防沉迷由渠道代管。这就是 §1 那张图右半边的两条路径。这一裁决对应内部审计 HJ-AUDIT-001(对整体战略做的一次三视角审计,代号 HJ-AUDIT-001,排查出四颗"雷")里的第二颗雷 R2"合规死锁",已收口为本节的双层定性结论。

重要边界——内测定性的成立条件尚待律所确认。 "邀请制内测"能否稳稳落在"试玩 demo"定性上,其边界(人数规模上限?链接是否可分享?是否允许有任何收入?)目前是绘境AI 的工程判断,不是已经验证的法律结论。这正是要约律所的核心两问之一(见 §5)。在律所书面意见到位前,自有端按"不接真钱"运行——这也是现状,所以不引入新增风险。

---

3. 12+1 道法定闸门的全貌

死锁的解法定了方向,但落地仍要逐项穿越一组具体的合规闸门。把它们汇总起来,一共是 12+1 道:8 项国家强制的 C 端(面向消费者)法定要求 + 审计新增的 3 项 + 1 次律所咨询。下表给出全貌与分组。注意:本表只解释每道闸门"是什么、为什么需要",它们的实时状态、负责人和最晚提交日不在这里,而在唯一跟踪面 A1 闸门看板。

代号说明——A1:这组闸门在内部作战清单里编号为 A1 任务项,故其跟踪看板称"A1 闸门看板"。"A1" 不含其他含义,就是任务编号。

3.1 八项 C 端法定 P0 要求(国家强制)

这八项是面向终端用户、监管强制要求的基础合规义务,在 MVP 阶段即被列为 P0(Priority 0,最高优先级、MVP 必须验收的功能):

法定要求	一句话说明
C 端实名	用户须完成真实身份核验后方可使用,是后续防沉迷的前提
防沉迷:时长 / 宵禁	未成年人游戏时长限制 + 夜间禁玩时段(宵禁)
未成年充值限制	按年龄分档的单次 / 单月充值上限
AIGC 显式标识	AI 生成内容须显著标注"AI 生成",依据《人工智能生成合成内容标识办法》(2025-09 施行)
青少年模式	为未成年人提供受限的内容与功能模式
关闭个性化推荐	必须为用户提供一键关闭算法个性化推荐的入口
账号注销	用户有权注销账号并删除个人数据
提现实名 / 税务	创作者提现须实名并完成税务代扣代缴

为什么 AIGC 标识对绘境AI 尤其关键:绘境AI 的核心产品就是"AI 生成游戏",平台上几乎每一款游戏都是 AIGC(AI-Generated Content,人工智能生成内容)产物。因此《人工智能生成合成内容标识办法》对绘境AI 不是边缘条款,而是直接命中主营业务的强制义务——生成的游戏必须带显式的"AI 生成"标识。

3.2 审计新增的三项(HJ-AUDIT-001 R2)

除了八项基础要求,内部审计 HJ-AUDIT-001 在排查 R2(合规死锁)时又识别出三项过去被忽略、但同样是硬性前置的闸门:

新增闸门	为什么需要
大模型登记	自建平台调用第三方大模型 API 对公众提供生成服务,须办理生成式 AI 服务的大模型登记。周期以"数月"计
算法备案	feed(游戏信息流)按质量分重排序属于算法推荐服务,须依《互联网信息服务算法推荐管理规定》做算法备案。周期同样以"数月"计
分账 / 灵工方案选型	为规避 §2 第二条链的二清风险,须在三个合法通道里选定一个资金分账方案

为什么大模型登记 / 算法备案不能拖:这两项的办理周期都以数月计,是全部闸门里最长的。绘境AI 在对外(奇绩)的口径里承诺"8 月中旬材料就绪",所以材料准备必须尽早启动——材料的拟写可以由 AI 代劳,但提交动作只有创始人能做。

3.3 加一:律所合规咨询(R2 修法落地件)

最后"+1"是一次律所合规咨询(千元级预算的单次会议)。它不是法定义务本身,而是"解锁其余闸门"的钥匙:很多闸门的定性边界(内测能否豁免、二清如何规避、备案是否在内测阶段就触发)需要专业法律意见才能拍板。详见 §5。

3.4 一张图看清这 12+1 道闸门

flowchart TB
  subgraph 法定8["八项 C 端法定 P0(国家强制)"]
    direction LR
    L1[C端实名] --- L2[时长/宵禁] --- L3[未成年充值限制] --- L4[AIGC显式标识]
    L5[青少年模式] --- L6[关闭个性化推荐] --- L7[账号注销] --- L8[提现实名/税务]
  end
  subgraph 新增3["审计新增 3 项(HJ-AUDIT-001 R2)"]
    direction LR
    N1[大模型登记<br/>·数月·] --- N2[算法备案<br/>·数月·] --- N3[分账/灵工选型<br/>·二清风险·]
  end
  subgraph 加1["+1:律所咨询(解锁钥匙)"]
    Q[律所合规咨询<br/>·两核心问·]
  end
  Q -.->|"定性意见解锁"| N3
  Q -.->|"路径/触发时点"| N1
  Q -.->|"路径/触发时点"| N2
  Q -.->|"内测豁免边界"| 法定8

谁能压、谁压不动:这组闸门的一个关键事实是——AI 一秒也压不动它们。材料准备(签名报备文案、备案说明、隐私协议占位稿)可以由 AI 代劳,但提交、实名、付费这三类动作只有创始人本人能做。这条约束是日历临界路径的本质,详见 A1 闸门看板 顶部的说明。

---

4. 闸门的依赖与临界路径(按什么顺序拆)

12+1 道闸门不是一字排开各自独立,而是有明确的前置依赖,形成一条日历临界路径(由日历时间而非工作量决定的最长依赖链——审批周期固定,人再多也压不短)。理解依赖关系,才能知道"先动哪几件能解锁最多后续"。

整条链的根前置是经营主体(开展经营所需的公司实体)。这一项是 0 号闸门,已于 2026-06-10 经创始人确认已具备(绘境AI 已有可用公司主体),因此全链可立即并行启动,没有多米诺式的等待。根前置解除后,依赖关系如下:

flowchart LR
  M["#0 经营主体<br/>✅ 已具备(06-10)"] --> DOM["#1 域名+实名"]
  DOM --> ICP["#2 ICP 备案<br/>7-20 工作日"]
  M --> SMS["#3 短信签名报备<br/>1-2 周不可压缩"]
  M --> LLM["#4 LLM 实名充值"]
  M --> LAW["#11 律所咨询"]
  ICP --> PAY["#5 支付商户进件<br/>1-3 周"]
  ICP --> AD["#6 广告联盟资质<br/>1-3 周"]
  LAW --> SPLIT["#12 分账/灵工选型"]
  LAW --> REG["#9 大模型登记 / #10 算法备案<br/>数月"]
  classDef week fill:#ffe0e0,stroke:#c00;
  class DOM,ICP,SMS,LAW week;

把这条图翻译成执行语言,就是 A1 闸门看板 反复强调的那句话——本周必须动的四件:

1. 域名购置 + ICP 备案提交(#1 → #2)。ICP 备案(网站开展经营前向工信部门做的互联网内容提供商备案)周期 7–20 工作日,是链上第一个长周期项;对外口径已承诺"8 月中旬前 ICP 完成 + 开放邀请制内测",本周不提交就吃掉全部缓冲。
2. 短信签名报备提交(#3)。周期 1–2 周且不可压缩——这一项直接关系玩家侧能不能用短信验证码登录(见 §6)。
3. 律所约谈(#11)。它是解锁分账选型、大模型登记 / 算法备案路径的钥匙。
4. LLM 实名口径确认(#4)。确认生成所依赖的大模型网关上游各厂商 API key 的实名 / 充值主体口径与发票路径。

短信签名报备(#3)还隐含一个串联约束:部分短信供应商要求域名已备案,因此要么选不强制要求备案域名的供应商先行、要么等 #2 完成,二者择一。其余依赖一目了然:ICP 回执到位才能做支付进件(#5)与广告资质(#6);律所意见到位才能定分账选型(#12)、确认两项备案(#9/#10)的属地路径与触发时点。

---

5. 律所合规咨询:解锁全局的两核心问

整组闸门里最该尽早做的,是那次律所咨询——因为它的两个核心结论会反向决定其余多道闸门的走向。绘境AI 已备好一份可直接转发给律所的会前 brief(律所合规咨询brief.md),期望律所对每个问题给出"定性结论 + 风险等级 + 可行通道 + 触发红线的边界条件"四件套。

核心两问(必答):

• 问 1 · 无版号 UGC 游戏在自有 H5 平台分发的出版定性。 "邀请制内测、不接真钱、不公开经营"这种运营形态,是否构成《网络出版服务管理规定》意义上的网络出版 / 游戏运营?"试玩 demo / 内测"定性的成立边界究竟在哪(人数规模?链接能否分享?能否有任何收入?)?以及——若未来公开经营,无版号条件下是否存在合规路径?这一问的答案直接决定自有端是否长期保持"邀请制内测"定性、公开经营推迟到什么条件满足。
• 问 2 · 防沉迷义务的履行路径。 无版号则接不进官方实名 / 防沉迷系统,自有端(内测形态)的义务如何履行?内测定性下是否有豁免空间或替代性履行(自建时长限制、宵禁等)?以及自营分发(平台作为第一责任人)与渠道分发(渠道代管)的义务边界差异。

附加两问(时间允许则答):

• 问 3 · 二清定性。 平台代收广告联盟结算款再分账给个人创作者是否构成二清?三个备选通道——持牌分账产品 / 银行存管 / 灵活用工平台代发 + 个税代扣——各自的适用性与成本量级。这一问决定 #12 分账方案选型;选型前绝不接真钱。
• 问 4 · 生成式 AI 备案义务。 自建平台调第三方大模型 API 对公众提供生成服务,是否需办大模型登记及算法备案?邀请制内测阶段是否触发?办理路径与周期?以及 AIGC 显式标识义务对平台生成游戏的具体适用方式。这一问决定 #9/#10 两项备案的启动时点与材料准备。

flowchart LR
  Q1["问1 出版定性"] --> R1["自有端是否长期内测<br/>+公开经营推迟条件"]
  Q2["问2 防沉迷履行"] --> R1
  Q3["问3 二清定性"] --> R3["#12 分账方案选型<br/>(选型前不接真钱)"]
  Q4["问4 生成式AI备案"] --> R4["#9/#10 备案启动时点<br/>+材料准备"]

可提供给律所的材料:业务描述(brief 本身)、平台 demo 试玩链接(内网,可会上演示)、现有 IP 合作协议文本、内容审核闸门机制说明(可后补)。

---

6. 鉴权件:短信报备这道闸门如何不卡死漏斗

合规闸门里有一道和产品体验直接挂钩、值得单独说明——玩家侧的短信验证码登录。它的合规前置是 §4 的 #3 短信签名报备,而这道报备1–2 周不可压缩、且报备完成前验证码不可用。如果硬等它,玩家注册漏斗在内测期就被卡死了。

绘境AI 的解法是把"鉴权"与"短信报备"解耦,采用 C 方案(邀请码旁路):内测期玩家用邀请码注册,不依赖短信验证码,因此报备未完成也不影响内测漏斗跑通;待报备完成后再切到验证码全量。这样既守住了合规底线,又不让一道审批闸门拖死产品验证。

切换到短信验证码时有一条硬规矩(出自鉴权执行规范 HJ-PASSPORT-EXEC-001 §7.2)——切渠道 = 配置切换 + 两项验证绑定,缺一不得只切配置:

sequenceDiagram
  participant U as 玩家
  participant P as 绘境AI 平台
  participant S as 短信供应商
  Note over P,S: 内测期:报备未完成
  U->>P: 用邀请码注册(C 方案旁路)
  P-->>U: 注册成功(不依赖验证码)
  Note over P,S: 报备完成后才允许全量切换
  rect rgb(255,235,235)
    Note over P: 切换前置(两项验证·缺一不可)
    P->>P: ① 确认 huijing.captcha.enable 对发码生效
    P->>P: ② 发码 IP 日/时上限已部署(Redis 计数)
  end
  U->>P: 输入手机号
  P->>S: 请求下发验证码
  S-->>U: 短信验证码
  U->>P: 提交验证码
  P-->>U: 登录成功

这两项绑定的意义在于:配置开关(huijing.captcha.enable,控制验证码功能是否启用的配置项)真正对发码链路生效是一回事,而发码频率必须有上限(按 IP 的日 / 时配额,用 Redis 计数实现,阈值与运营确认)是另一回事——少了后者,验证码接口会被刷爆、产生短信费用黑洞。所以规范要求两项一起绑定,不允许"只切配置就上线"。

---

7. 经济模型对合规的一处硬约束:分账不能为负

合规与经济模型在一个点上交汇——资金分账方案(#12)。这里只讲与合规相关的那条不变量,完整的敏感性测算在单位经济敏感性模型里。

绘境AI 的三层分成叠加规则(创始人 2026-06-10 拍板、对应审计 R3 收口)采用净额基数口径,确保账永不为负:渠道先扣 40%,平台拿到的是实收净额 N;创作者分 80%;带 IP(知识产权,如授权形象)的游戏,IP 方再从创作者份额内支出 15–25%,于是创作者实得 55–65%;而平台恒留 0.2N。这样一来,对内的"创作者 80%"与对外的"创作者实得 55–65%"是同一个模型的两种表述,不是两套数字,账面永远不会出现负值——这正是规避资金纠纷与二清风险的会计前提。

诚信红线:对创作者讲"能赚钱"时,必须用"头部款"口径,不得做普遍性的收入承诺。这条红线既是商业伦理,也是合规防线(避免被认定为虚假宣传)。

---

8. 跟踪与责任:状态去看板,逻辑看本页

最后明确本页与跟踪面的分工,避免出现"两份都在记状态、互相打架"的影子事实源:

你要找的东西	去哪里
每道闸门的实时状态 / 负责人 / 最晚提交日	A1 闸门看板(唯一跟踪面,状态变化直接改它)
闸门为什么存在、怎么缠成死锁、按什么逻辑拆(本页)	本文档(运营域 · 合规闸门)
律所会前材料与四问全文	律所合规咨询brief.md
分账 / eCPM 等经济模型明细与测算	单位经济敏感性模型
战略叙事(三线变现排序、护城河、对外口径)	产品域 · 商业定位
决策史与逐档证据	git 历史 + _archive/ 审计报告;战略叙事的决策史归 产品域 · 商业定位

纪律:本页只写"合规闸门的设计逻辑与不变量"。任何会随日历推进而变化的状态——某项是否已提交、卡在哪一步、谁负责——一律只记在 A1 闸门看板;本页不得复制这些状态,否则就会出现两份冲突的真相。仍然阻塞全局的最大未决项是:Doc A(产品需求清单)里的法定 8 项换血,待律所对两核心问给出书面意见后才能定稿。

---

9. 待补设计:审核台运营机制(创始人 2026-06-21 判定补充)

正式设计稿已出:审核台运营.md(双层审核判定流、锁风三档、违规处置联动 feed 与创作者信用、admin 审核台,含 contract-first 清单与 3 个开放问题)。本节保留立位与范围摘要,细节以正式稿为准。

前面几节把"法定要过哪些闸门"讲清楚了,但平台日常怎么把内容安全运营起来——也就是审核台这一摊——现行档基本空白。创始人判定:没有设计,需要补。这一节先立位,范围定了再展开。

要补的是三块:

• 内容审核的双层架构:自部署的快检模型先过一道(快、便宜、挡掉大面),阿里云内容安全做兜底(权威、有合规背书),拦不准的进人审队列(走 BPM 工作流)。
• 锁风门的三档强度:标准 / 严格 / 人工复核,按 IP 敏感度和内容类型选档,决定一款生成内容要不要、以多严的力度过保真与版权检查。
• 违规处置:封禁、举报降权、分级标签这套处置动作,以及它们怎么联动到信息流的曝光权重和创作者信用。

范围(创始人 2026-06-21 定:全做):四块都要——

1. 双层内容审核:自部署快检挡大面 + 阿里云内容安全兜底 + 人审队列(BPM)。阿里云兜底在接真实公开流量(渠道线③)前接入。
2. 锁风门三档:标准 / 严格 / 人工复核,按 IP 敏感度与内容类型选档;与 IP 库绑定,随素材 / IP 授权模型一起做。
3. 违规处置:封禁 / 举报降权 / 分级标签,联动 feed 曝光权重与创作者信用。
4. admin 审核台前端:队列、详情、处置操作、锁风档位配置。

跨 compliance + admin + BPM + 阿里云 API + feed(曝光联动)+ IP 库。下一步:由我出正式设计稿(接进运营 / 合规域),admin 审核台前端入口随稿定;代码执行归 Mac。