games-development-ai/docs/architecture/06-运营图说.md

date, topic, status

date	topic	status
2026-06-22	运营图说——绘境AI 架构图集（按领域拆分·06）	现行为主 · 每图具体映射源档见该图脚注 / 内联小注 · 通用图例见 00-系统总览图说

06 · 运营图说

本篇是绘境AI 架构图集的一部分(全 8 篇:00 系统总览 + 01–07 各域)。通用图例、状态码、按角色读路径见 00 · 系统总览图说。 本域命门(最该据图 review 的设计缝):元素级被阻塞部分别画成已建;8 项法定 P0 待律所。

---

本域讲什么故事:运营域接在产品域与架构域之后,回答三件相互咬合的事——一款游戏被造出来之后,怎么合规上线、怎么把钱赚回来、怎么发行到各渠道。它的十一张图讲清 12+1 合规闸门的日历临界路径、合规死锁三环 + 双层定性破解、分账公式钱流(平台恒留 0.2N)、两平面两钱包三道硬边界、三线变现排序、四层护城河、发行双路线、一壳多游 L1 精选整包、变现端到端钱流地图、审核台双层审核。读完这个域,你知道「这套上线 / 变现 / 发行方案是不是想要的那个」。

最该据图 review 的命门缝:运营域十一张图整体都是「现」(已拍板的现行设计逻辑),但它的特殊之处在元素级——同一张图里常常一半是「已建真跑」、一半是「被合规日历闸门或外部资质阻塞、尚未接线 / mock / 留待后续波次」。评审最该盯的是这条纪律:绝不能因为整图是现行设计,就把图里那些被阻塞的部分画成已建好——变现侧的打款 mock 桩(降级即吞真钱、必须 fail-fast)、消费钱包未接、自助购买订阅被支付闸门阻塞;审核台的检测原子全是桩恒返回 pass(框架在、判定空、处置半通);渠道侧的备案锁(把「一壳多游」从灰区可行降级为高风险待律所裁)与引擎竞标 P1 段暂停。还有一处全局阻塞:8 项 C 端法定 P0 的换血边界要等律所对两核心问给出书面意见,这是仍卡着全局的最大未决项。

本域阅读约定与同步纪律:本图说不另立设计,只把运营域六份 canonical 设计档画出来——三件事的咬合骨架与分账公式出自 运营/README.md;两平面 / 两钱包 / 单位经济出自 变现与单位经济.md;三线钱流的工程地图出自 变现端到端.md;一壳多游与渠道合规红线出自 渠道发行.md;合规死锁与 12+1 闸门出自 合规闸门.md;双层审核与处置联动出自 审核台运营.md。frontmatter 记了这六份相关源档的当前 commit hash 作为防漂移门。设计一变动,本图说与对应 SVG 必须同步更新。本域状态分布——整体是「现」,但布满设计缝,必须看清:运营域不像运维域那样有「整图待接 / 整图缓做」的图;这里 11 张图的整体状态都是「现」(讲的都是已拍板的现行设计逻辑)。它的特殊之处在元素级——同一张图里常常一半是「已建真跑」、一半是「被合规日历闸门或外部资质阻塞、尚未接线 / mock / 留待后续波次」。所以本域守的纪律点是:绝不能因为整图是现行设计,就把图里那些被阻塞的部分也画成已建好。

本域徽章(主要关心其中三个,个别图点到第四个):安全(#dc2626):合规即护城河、new-api 上游 API key 不明文 / 防盗刷、打款 fail-fast 绝不发假钱、审核降级朝保守、审核台端点权限强制在后端可信边界。数据(#475569):备案 / 资质合规、成本与精度域隔离(元 ≠ 分)、配置即数据(GameConfig 禁代码)、内测养行为数据飞轮、审核台账留证 ≥180 天。成本(#16a34a):单款生成成本远不到 1 元、自有端 IAA 万级 DAU 才回本的单位经济、渠道零构建生产红利、快检把审核大面在本地消化。可靠(#16a34a):变现侧 7 个资金动作各有幂等键、账户恒等式、发起 ≠ 终态的打款异步化、对账锚点链与补偿 job——这是变现端到端图的主轴。运营域的徽章里,安全与成本两个维度是一体两面:同一套合规资质,对自己是必须翻过的闸门(成本 / 时间),对后来者就是 6-12 个月才能补齐的护城河(安全壁垒)。本域图说里,虚线同样额外承担一层状态语义:凡是被合规日历闸门或外部资质阻塞、尚未接线 / mock / 留待后续波次的元素,一律虚线框 + 文字小标;红色虚线 / 红框则用于「绝不能跨越的硬边界」与「合规生死线」。

运营图 1 · 运营三件事咬合〔引·流·现〕

这张图回答「运营域到底要解决什么」。它把上线、变现、发行三件事的咬合关系一句话说清:合规闸门是总闸,没过就不能商业化;发行决定钱从哪里进来(自有 H5 流 + 微信 / 抖音渠道);变现决定钱怎么分出去(广告 / B 端 / 远期内购订阅 → 分账 → 创作者钱包 → 提现)。三条线在「现金流」这个点上汇合。

flowchart LR
  subgraph 上线["上线 · 合规闸门(总闸)"]
    G["12+1 法定/审计闸门<br/>ICP · 实名防沉迷 · AIGC 标识<br/>大模型登记 · 算法备案"]
  end
  subgraph 发行["发行 · 流量从哪来"]
    H5["自有 H5 游戏流<br/>即时生成发布 · UGC 主场"]
    CH["微信 / 抖音小游戏<br/>精选整包发行"]
  end
  subgraph 变现["变现 · 钱怎么分"]
    AD["广告(IAA)"]
    B2B["B 端 / IP 项目制"]
    PAY["内购 / 订阅(远期)"]
    SHARE["分账 → 创作者钱包 → 提现"]
  end
  G ==>|过闸才可商业化| 发行
  H5 --> AD
  CH --> AD
  AD --> SHARE
  B2B --> SHARE
  PAY --> SHARE
  G -. 合规定性约束 .-> 变现

(图源:运营/README.md §1)

读这张图最该抓住的是它顶上那个反直觉但关键的战略判定:绘境AI 的差异化护城河不在「自有 feed 形态」本身(那块早有现任者——摸摸鱼 / 233 / 4399 占着),而在 AI 供给侧的成本结构(用 agent 闭环把游戏的生成与质检全自动化,产能成本远低于人工)+ IP 锁风保真。运营域的所有安排,都服务于把这个成本优势,在监管窗口期内滚成内容资产与数据飞轮。这就是为什么后面的图里,合规、变现、发行三条线看似各管一摊,实则都指向同一个目标。

运营图 2 · 12+1 合规闸门依赖与日历临界路径〔SVG升·流·现〕

这张图回答「合规要过哪些闸门、按什么顺序拆」。它把 README §2.1 与合规闸门 §4 那张依赖 Mermaid 升成高保真大图,要让人一眼看出三条主线。第一条:经营主体已经具备(0 号闸门,创始人 2026-06-10 确认,图上用绿色实心块画出),所以下游各项可以立即并行起跑,没有多米诺式的等待——这是把整条链从「串行等待」变成「并行冲刺」的关键事实。第二条:ICP 备案是临界路径(7-20 工作日,图上用红边加粗框强调),它一通过,支付进件和广告资质两条线才能动;这条链由日历时间而非工作量决定,人再多也压不短。第三条:律所意见是另一个分叉点,它到位后才能定分账方案(#12)、确认大模型登记与算法备案(#9/#10)的属地路径与触发时点。

图上还钉了两件最该记住的事。其一是「谁能压、谁压不动」那条红线:AI 一秒也压不动这些闸门,材料准备(报备文案 / 备案说明 / 隐私协议占位稿)可以由 AI 代劳,但提交、实名、付费三类动作只有创始人本人能做——这正是日历临界路径的本质。其二是状态纪律:每道闸门的实时状态、负责人、最晚提交日是会变的活数据,本图只画不变的依赖逻辑、不抄状态,唯一跟踪面是《A1 闸门看板》,看板变了即真相变了。这张图的「设计缝」画在最右侧那一栏:8 项 C 端法定 P0(实名 / 防沉迷 / AIGC 标识等)当前仍是国家强制义务的全集,但它们的换血边界要等律所对两核心问给出书面意见后才能定稿——这是仍阻塞全局的最大未决项,图上据实标出。

运营图 3 · 合规死锁三环 + 双层定性破解〔SVG新·讲·现〕

这张图回答「为什么做得出游戏却不能直接公开经营、又怎么解开」。它是理解整个运营域合规逻辑的主干,左半边画死锁、右半边画破局。左边的死锁是三条互相咬合的链:第一环,UGC 小游戏无版号 → 接不进官方实名 / 防沉迷系统(版号是接入前提)→ 自有端作为运营方无法履行法定义务(有 Roblox 停服、罚没 111 万元量级的先例);第二环,IAA 免版号的豁免只在微信 / 抖音备案制内成立,搬到自有 H5 站就落进监管灰区;第三环,平台代收广告费再分账给个人创作者,等于无牌照资金归集,踩二清红线。这三环不是并列而是连环——「想合法经营 → 需版号 → UGC 拿不到 → 接不进官方系统 → 履行不了义务 → 真变现又必触发资金归集 → 碰二清」形成闭环,任何单点突破都解不开。

右边的破局办法是双层定性,把「自有端」和「变现渠道」在合规上彻底分开:自有端收敛为邀请制内测(邀请码注册、不公开经营、不接真钱),按「试玩 demo / 内测」定性,规避公开运营才触发的出版与防沉迷义务;真实变现全部放到渠道线(微信 / 抖音备案 + IAA),豁免通道成立、实名 / 防沉迷由渠道代管、资金经渠道结算绕开二清。这样三环锁同时解开。这张图最该让人看清的设计缝,是右侧那个橙色虚线框标出的事实:「邀请制内测能否稳稳落在试玩 demo 定性上」,其成立边界(人数上限 / 链接可否分享 / 能否有任何收入)目前是工程判断、不是已经验证的法律结论——这正是要约律所的核心两问之一。在律所书面意见到位前,自有端按「不接真钱」运行(这也是现状、不引入新增风险),公开经营推迟到什么条件满足,要等律所答。

运营图 4 · 分账公式钱流〔引·流·现〕

这张图回答「广告挣的钱按什么规则分」。它画的是 R3 拍板(创始人 2026-06-10)的唯一分账口径:总广告消耗 G,渠道扣 40%(微信 IAA 现金分成 60%)后平台实收净额 N = 0.6G;无 IP 时创作者拿 0.8N、平台留 0.2N,带 IP 时创作者 0.550.65N、IP 方从创作者份额内出 0.150.25N、平台恒留 0.2N。

flowchart LR
  G["总广告消耗 G"] -->|渠道扣 40%| N["平台净额 N = 0.6G"]
  N -->|无 IP| C1["创作者 0.8N"]
  N -->|无 IP| P1["平台 0.2N"]
  N -->|带 IP| C2["创作者 0.55~0.65N"]
  N -->|带 IP| IP["IP 方 0.15~0.25N<br/>(从创作者份额内出)"]
  N -->|带 IP| P2["平台恒留 0.2N"]

(图源:运营/README.md §2.2;同口径在 变现与单位经济.md §4.1 也有公式块)

读这张图要抓住它精妙的那一点——平台恒留 0.2N:带 IP 时,IP 方的分成是从创作者那一份里出的,所以无论带不带 IP,平台都稳定留 20%,而对外宣传创作者「拿 55%~65%」和内部「80% 分成」用的是同一个模型的两种表述,账永远不会算成负数。这正是规避资金纠纷与二清风险的会计前提。配套这条公式还有一条贯穿全域的诚信红线:对创作者宣传「能赚钱」必须用「头部款」口径(eCPM 30 时单款约需每日 12 次激励视频观看才达 5 元提现门槛,头部款可达、长尾款达不到),绝不做普遍性承诺。这个公式背后的单位经济结论(自有端 IAA 是万级 DAU 才回本的规模生意,约 1.33 万 DAU 覆盖 ¥4,300/月基建成本,所以近期现金只能靠 B 端),直接决定了图 6 的三线变现排序。

运营图 5 · 两平面、两钱包、三道硬边界〔SVG新·架·现〕

这张图回答「钱往外花和钱往回赚怎么隔开」。变现这件事工程上最容易出错的,是把不同方向的钱混在一起算;绘境AI 用三道永不混淆的硬边界把它钉死,图上用红色虚线把三道边界一条条画出来。边界①:生成计费平面(钱往外花)由 new-api 网关负责,配额只减不增、既不结算也不碰合规;收益与支付平面(钱往回赚)由后端 trade / pay 模块负责,广告分成入账、提现、结算、合规全在这里——把广告分成塞进只会扣减的 new-api 配额是范畴错误。边界②:收益平面内部再分两套钱包——创作者收益钱包(trade 模块,挣广告分成 / 提现用,已建成,图上实心绿块)与消费钱包(pay 模块,用户充值 / 扣减内购用,尚未接入单体,图上虚线框 + 「未接入」)。边界③:成本侧全程用浮点「元」(活在编排器域)、收益侧全程用 BIGINT「分」(活在后端数据库域),两个精度域跨平面对照必须显式换算、严禁同列求差。

读这张图要抓住它把已建与未建严格分层的纪律。已建的实心块只有创作者收益钱包那条链(广告台账 → T+1 结算 → 物化账户,带恒等式与单测);其余都用虚线标清:消费钱包未接入、自助购买订阅被支付通道阻塞(现由 admin 手动赋)、打款渠道是 mock 桩。图底那个红框是边界铁律:trade/pay 的钱永不写进 new-api(已 grep 确认 new-api 里没有任何收益写入路径),而且 new-api 的 redemptions / top_ups / subscription_* 表 schema 在、却从未跑过数据,不要当成就绪能力。这张图的设计缝就在这些虚线处:消费钱包最小闭环属 v2.0、非 MVP 必需,自助购买订阅同被日历闸门阻塞——它们是「设计已留好接口、被外部资质卡住」,不是已经建好。图上还单标了一条 P0 安全红线:new-api 的 channels 表存着上游厂商 API key,开通公网 / 创作者账户前必须确认 3000 端口未绑 0.0.0.0、ufw 已封非内网,否则公网可达即被盗刷上游账单。

运营图 6 · 三线变现排序〔引·流·现〕

这张图回答「三条变现线按什么先后次序走」。它画的是绘境AI 现行战略主轴的一条有先后的三线变现:① B 端 / IP 营销小游戏(现金线·首位)→ ② 自有端邀请制内测(数据资产线)→ ③ 渠道线(规模线·微信 / 抖音 IAA),B 端的标杆案例还能反哺渠道线。

flowchart LR
  L1["① B端/IP 营销小游戏<br/>现金线 · 首位"] -->|供血| L2["② 自有端邀请制内测<br/>数据资产线"]
  L2 -->|养飞轮种子| L3["③ 渠道线<br/>规模线 · 微信/抖音 IAA"]
  L1 -.标杆案例.-> L3

(图源:运营/README.md §3)

读这张图要理解每一线为什么是这个合规定性、它产出什么,而排序的根因正是图 4 / 图 5 的单位经济结论。B 端排首位,是因为推广内容不是网络出版物、版号争议最小、回款最早(已有「王蓝莓」案例点火),产出现金流 + 标杆案例;自有端排第二,按「试玩 demo」定性、不公开经营、不接真钱,产出行为数据 + 产品迭代(飞轮种子,必须诚实地讲成未来式);渠道线排第三,豁免通道成立、平台代管实名 / 防沉迷,产出规模化曝光 + 真实 eCPM。这条排序对外讲给投资人的故事主轴是:单人 + AI agent 体系的资本效率(已实证)→ 用 B 端 / IP 现金线供血 → 在监管窗口期里把供给侧的成本优势,滚成内容资产与数据飞轮(后半段是未来式,必须诚实标注)。这张图的设计缝就在「②③ 的产出是未来式」——飞轮和规模化 eCPM 都还没发生,图与口径都把它讲成未来式,不画成既成事实。

运营图 7 · 四层护城河〔引·讲·现〕

这张图回答「真正难被复制的壁垒在哪」。它的核心论点是一句反直觉的判断:绘境AI 的护城河不在生成引擎本身(通用大模型 12-18 个月就会把纯生成能力追平),而在时间沉淀出来的四层壁垒——数据(玩家行为 + 质量评分 + 推荐信号,需真实流量积累、无法购买)、网络效应(创作者多 → 内容富 → 玩家多 → 创作者更多,飞轮转起后追赶成本指数级增长)、资产(模板库 + 素材市场 + IP 合约,时间沉淀型资产)、合规(ICP + 文网文 + 广告资质 + 渠道关系,6-12 个月才齐备)。

flowchart TB
  subgraph 壁垒["四层护城河 — 越往后越难复制"]
    D["数据壁垒<br/>玩家行为 + 质量评分 + 推荐信号<br/>(需真实流量积累,无法购买)"]
    N["网络效应<br/>创作者多→内容富→玩家多→创作者更多<br/>(飞轮转起后追赶成本指数级增长)"]
    A["资产壁垒<br/>模板库 + 素材市场 + IP 合约<br/>(时间沉淀型资产)"]
    C["合规壁垒<br/>ICP + 文网文 + 广告资质 + 渠道关系<br/>(牌照+关系+流程,6-12 个月才齐备)"]
  end

(图源:运营/README.md §3「这套商业模型为什么成立」)

读这张图最该看出的,是它和图 2 / 图 3 的呼应——合规壁垒恰恰是那串闸门的另一面:同一套资质,对自己是必须翻过的门槛,对后来者就是 6-12 个月才能补齐的护城河。所以「先把合规闸门跑通」既是上线的前置,也是在攒护城河。绘境AI 的窗口期判断是 6-12 个月,竞争路线上不追求技术深度第一,追求生态完整度第一——技术够用即可,生态无法复制。这张图本身没有现行 / 远期的灰度(四层壁垒都是战略判定),它的「设计缝」是:四层里只有合规壁垒是当下就在攒的(闸门在跑),数据 / 网络效应 / 资产三层都依赖真实流量与时间沉淀,是未来式的长期优势,不是已经筑成的墙。

运营图 8 · 发行双路线 H5 / 渠道〔引·流·现〕

这张图回答「游戏造出来铺到哪、怎么铺」。它画的是绘境AI 两条互补的发行路线,分工的根因是底层技术能力的硬差异:自有 H5 流 = 海量 UGC 与「改码」的主场(浏览器对动态生成的代码没有禁令,agent 生成的每款游戏都能即时发布、即时被刷到,这是「创作 → 生成 → 发布」闭环最完整的形态);微信 / 抖音小游戏 = 精选整包过审的分发面(这两个渠道对远程包会自动剥离代码、明文禁止 JS 解释器,所以渠道里只能跑「包内固定的模板代码 + 远程下发的纯数据配置」)。

flowchart TB
  GEN["agent 生成游戏<br/>(每款独立代码)"] --> H5["自有 H5 流<br/>即时发布 · 动态代码无禁令"]
  GEN -. 精选款固化进包 .-> PKG["微信/抖音整包<br/>固定模板代码 + 远程 GameConfig"]
  PKG --> AUDIT["平台审核<br/>(备案锁:内容变更须重新备案)"]
  AUDIT --> CH["渠道游戏流<br/>一壳多游 · 主题合集"]
  H5 --> FEED["自有 feed 即刷即玩"]

(图源:运营/README.md §2.3;更细的分工根因与流程在 渠道发行.md §1-2)

读这张图要记住对外统一措辞——「自研流即时发布 + 双渠道精选发行」,以及那条「不互跳、不外导」的边界。它和图 9 是一对:图 8 给发行分工的全局轮廓,图 9 把渠道线那条「一壳多游」的架构与合规红线放大。这张图的设计缝在渠道这一支:渠道线只做 L1 精选整包过审,对外口径是「主题小游戏合集」而非「开放 UGC 平台」,且受备案锁约束(详见图 9);而自有 H5 流没有备案锁、是 UGC 海量生成与 L2 改码玩法的主场。两条线的命运截然不同,绝不能混为一谈。

运营图 9 · 一壳多游 · L1 精选整包发行〔SVG新·架·现〕

这张图把图 8 渠道这一支放大,回答「渠道里的游戏到底怎么装、怎么过审」。它的起点是一个技术现实:微信 / 抖音自动剥离远程代码 + 明文禁 JS 解释器,浏览器无此禁令——所以海量 UGC 留 H5,渠道只做 L1 精选整包过审。图分三块讲清「一壳多游」:左边是壳工程(随包提审、微信 / 抖音各一份、固定不变),模板代码、核心层、SDK、四件 adapter 全打进包、固定不变,模板注册表只命中包内白名单;中间是远程 GameConfig(纯数据),玩法的差异全靠它表达,经 schema + hash 双重校验后才实例化——而它必须守住渠道生死线:禁一切可执行 / 可解释的字符串、禁远程下发任何代码、剧情关卡只能用有限状态机枚举,一句话「渠道里的游戏逻辑必须是数据、不能是代码」(这条红线转正后成为契约第 9c 条);右边是平台运行时 + 备案锁 + 上架。

读这张图要抓住两个最该看清的设计缝。其一是备案锁(图上用红边加粗框 + 「待律所裁」标出):官方规定备案完成后不支持改游戏内容 / icon / 代码,实质变更须重新备案,这条锁的是「内容」,于是把「一壳多游」从「灰区可行」降级为「高风险待裁」——「当日热发新游进渠道」的叙事已经收回,热发只限既有游戏的非实质参数微调,实质变更要走月级的「重新备案 + 整包提审」(具体边界待律所裁定);注意这条锁只约束渠道,完全不影响自有 H5 流。其二是渠道引擎竞标 W-CH-α(图上虚线框 + 「待裁」):C-A=LittleJS+自研 adapter 对决 C-B=Cocos 原生导出,P0 先行段五件产物已交付、6/6 PASS,但 P1 真机段七道门暂停中、待创始人提供三件套(微信 AppID + Win/Mac 构建机 + 安卓千元机)。这张图还点出「禁动态代码」反而带来的架构红利:每游生产是产 GameConfig + 资产、Linux 工厂全自动零构建,对 Win/Mac 的依赖只落在低频的壳版本发布层、且仅 Cocos 胜出才需——真正绕不开人工的只有平台审核节奏本身。

运营图 10 · 变现端到端钱流地图〔SVG新·时·现〕

这张图回答「钱具体怎么从一次广告 / 一笔订阅 / 一单定制,流到创作者钱包或平台营收」。它是图 5 的下钻——图 5 立两平面 / 两钱包 / 三边界的架构,图 10 画三条线的工程钱流地图,凡 mock / 未接段一律虚线标清。① 广告分成线(最长、已建真跑,图上整条绿色实心):玩家看广告 → ad 计费 bill()(合规校验 blockMinor + 幂等 uk_trace + 归因 getCreatorUserId)→ 落 game_ad_revenue 台账 → T+1 SettlementJob 逐笔 recordIncome 入账 → game_trade_income,中间隔着 ad→trade 的 AdRevenueApi 接缝(单体 @Primary 就地解析)。② 订阅会员线(trade 独管,入账已建 / 收单未建):admin 赋订阅 → 幂等账本 subscription_grant → 续期 → C 端实时查态;自助购买那一半被支付通道阻塞,现由 admin 手动赋。③ B 端定制线(biz 独管,图上整条红色虚线):只走业务状态机、完全不碰钱,收款 / 在线签章 / 分账整段留 M4,现仅 signed_offline 兜底标记。

读这张图要抓住右侧三条线汇合后的钱流终态,以及它最硬的可靠性纪律。三条线在创作者收益钱包 game_trade_account 上汇合,账户恒等式 balance + frozen + total_withdraw = total_income 必须永远成立,四个原子动作更新 0 行就抛错回滚、绝不允许「状态已置、资金未动」的半态 commit。提现 → 异步打款这一段最该看清的是「发起 ≠ 终态」(图上红框):审核事务内只 CAS 0→1,终态由回调驱动,且 打款渠道是 mock 桩(图上虚线 + 「打款 mock 桩」)——因为 PayoutClient 只有 MockPayoutClient,真实 wxpay / alipay 被合规日历闸门阻塞,但抽象已做对、补真实现即零改业务码切真;这条线的降级口径与广告线正好相反:广告渠道缺失降级 mock 可接受(少算收入),打款渠道缺失若降级 mock 就是吞真钱,必须 fail-fast。图底的控制平面画清「钱不会自己流」——三个 XXL-Job + 单体 Feign 接缝 + 打款双路驱动(正常路回调、异常路补偿 job,两条路都过 CAS 故重复驱动安全),以及那条端到端的对账锚点链(ad_revenue.id —source_ref→ trade_income —余额→ account 恒等式 —→ withdraw.transfer_ref,stat_date 统一取上游)。这张图的设计缝集中在三处虚线:订阅自助购买未接、打款 mock、B 端钱留 M4——它们都是「逻辑早已真实落地或抽象做对、被外部资质 / 后续波次卡住」,图上据实标层、不画成已通。

运营图 11 · 审核台:双层机审 + 锁风三档 + 人审 BPM + 处置联动〔SVG新·流·现〕

这张图回答「门开了以后,每条内容怎么一条条审过去、违规怎么处置」——它和合规闸门是两件事:合规闸门是把平台这台机器通上电的总开关(一次性、日历驱动),审核台是机器跑起来之后的质检线和安全阀(持续运转)。设计的核心不在「调三个检测器」,而在路由——什么内容在哪一层被放掉、什么必须往下一层送。图的主干是一个三段瀑布:第一层自部署快检(safe-content-ai,挡掉大面、明显 OK 放行 / 明显违规拦截,只把灰带样本往下送,价值在成本——快检把大部分流量本地消化、省阿里云调用量);第二层阿里云内容安全(灰带样本送阿里云拿有合规背书的权威结论,接入时点是接真实公开流量前 / 渠道线③上线前,代码接缝现在留好、实现挂 feature flag);第三层人审队列(两道机审都判 review 或锁风人工档建工单,MVP 用轻量状态机 + admin 队列、重型 Flowable 留远期,人审终裁是最高权威)。瀑布之上还有一个锁风三档选档器(标准 / 严格 / 人工复核),按内容的 IP 归属 + 类型自动选档,档位源现阶段是过渡表 lock_strength_policy、终态收敛进 IP 实体授权属性。

读这张图最该守的是它把现状与待补严格分层的诚实。现行已建(实心绿块)只有锁风门聚合那条框架:ComplianceGateApi.evaluate 按 block > review > pass 取最严裁决、落 game_compliance_gate_result 台账、在发布前检查被真注入——但聚合进来的原子目前都是桩、恒返回 pass,意味着今天的发布链对违规内容零自动拦截、纯靠人工兜底。其余全是本设计要补的待建(虚线框):双层机审的两层、人审队列底座、feed 自动降权接缝、创作者信用。处置联动这一栏要看清四类处置各自的现状落差——下架走 feed 现有的跨模块接缝 FeedApi.offlineRank(现成可用、封禁联动下架已在走它),降权则因为 setExposureLimit 现在只是管理端 HTTP 端点、不在跨模块 FeedApi 上,要 contract-first 新建 feed 降权 -api(创始人 2026-06-22 定放第一期、单独做);封禁台账已建,但封账号联动断着(不置 player.status=DISABLE、不连带下架全部内容,validateCreator 也不查 ban 表,所以今天封号拦不住本人继续创作,是本设计要补的两条断链);创作者信用现在一点没有、第一期建简单扣分台账(只记不连带、保守形态、防误伤)。图上还钉了两条贯穿铁律:审核降级朝保守(阿里云超时 / 报错降级到 review、绝不降级到 pass,与打款 fail-fast 同理),以及审核状态唯一权威在 compliance(project 只接回写、不双写,避免脑裂)。这张图的设计缝几乎布满全图——它如实画出了「框架在、判定空、处置半通」的真实现状,而非假装审核台已经建好。

运营图 12 · 运营对象状态机合集〔SVG·状态机·现〕

这张图回答「运营域里到底有几台状态机、各自怎么转、谁已经真跑」。前面几张图里,状态机被压成钱流图或瀑布图里的一行散文标签——提现五态在图 10 里只是钱流终点的一个小框,B 端五态、订阅续期同样被一笔带过。这张图把运营域四个核心对象的状态机抽出来并排画在一处:提现、B 端询单、审核工单、订阅续期各占一格,让人一眼看清每台机的触发条件、各自的终态,以及哪些动作是幂等的。读它的正确方式不是逐格细看字段,而是先对比四台机的「成熟度差异」——它们恰好分布在「已建真跑」「整段不碰钱」「第一期待建」「半建半阻塞」四种状态上,正是运营域「整图是现、元素级布满设计缝」这条命门纪律的最集中体现。

四台机各有一处最该记住的设计点。提现五态(左上,trade,实线整片已真跑)最硬的纪律是「发起 ≠ 终态」:审核事务内只把单子从「待审 0」CAS 到「打款中 1」,绝不在审核里直接置「已打款」;真正的终态由打款回调驱动,成功走 1→2、失败走 1→4 退回冻结。它的终点是 mock 桩(图上右侧虚线红框标清)——只有 MockPayoutClient,真实微信/支付宝渠道被合规日历闸门阻塞,且这条线的降级口径是「绝不静默降级 mock」,因为打款降级 mock 就是吞真钱、必须 fail-fast,这一点和广告线「缺渠道降级 mock 可接受」正好相反。B 端询单五态(右上,biz,整条画成虚线红框)是四台机里唯一「完全不碰钱」的——待跟进→已报价→制作中→待验收→已交付单线推进,它的「终态」是交付而不是收款,在线签章/收款/分账整段留在 M4,现在唯一能标的只有 signed_offline 线下签兜底;把它整条画成虚线红框,正是要提醒读者:B 端虽是近期现金线,但工程钱流尚未建,真正的资金动作在提现线、不在这里。

下面两台机讲的是「待建」与「半建」。审核工单(左下,compliance,整台虚线)是第一期才建的——今天 compliance 只有「申诉」一种人工单,没有带认领/分派/SLA 的内容审核队列底座;它的状态机里「超时告警」是旁路态(介入后回到审核中)、不是终态,只有「已通过/已拒绝」是真终态,而人工 approve/reject 是最高权威、覆盖机审结论。把它整台画成虚线是诚实的:今天的发布链对违规内容零自动拦截、纯靠人工兜底。订阅续期(右下,trade,入账实线已真跑、收单虚线红框未接)有一处和其他三台都不同的终态语义——它没有「彻底结束」的吸收态,「过期」可以被下一次续期重新拉回「生效中」,是可逆回落,所以图上画成双向箭头;它被卡住的只是「自助购买收单」这一半(需接真实支付),admin 手动赋订阅那一半早已真跑、入创作者钱包恒等式。这张图的设计缝因此可以一句话收束:四台机里没有一台是凭空设想的,但它们各自被卡在不同的位置——读图时分清「实线方框=已真跑」与「虚线框+小标=被资质/波次阻塞」,就不会把待建的审核工单或被阻塞的打款 mock、订阅收单误当成已经建好。

运营图 13 · IP 库 · 素材授权与锁风档位来源 概念模型〔Mer新·概念·现〕

flowchart TB
  subgraph IPLIB["IP 库（ip 模块 · 现以 seam 寄宿 compliance · 授权链待建）"]
    direction TB
    OWNER["IP 所有者 / 授权方<br/>(迪士尼 / 王蓝莓 / 品牌方)"] -->|签授权| GRANT["IP 授权档<br/>授权范围 + 敏感度 + 合同约束"]
    GRANT --> IPENT["注册 IP 实体<br/>(终态:lockStrength 作为授权属性挂在这)"]
  end
  subgraph SRC["档位源（现阶段=过渡表 · 终态=IP 实体属性）"]
    POLICY["lock_strength_policy 过渡表<br/>按 ipId / 题材关键词映射档位 · admin 可配"]
    BLACK["题材黑名单兜底规则<br/>(棋牌 / 捕鱼即便纯 UGC 也强拉人工复核)"]
  end
  IPENT -. 终态收敛(IP 授权模型成熟后) .-> POLICY
  CONTENT["待审内容<br/>生成时声明 ipId（无则纯 UGC）"] --> SEL["锁风三档选档器"]
  POLICY -->|查 lockStrength| SEL
  BLACK -->|叠一层兜底拉档| SEL
  SEL -->|无 IP / 低敏| STD["标准档<br/>机审瀑布正常跑"]
  SEL -->|IP 中高敏| STRICT["严格档<br/>降低放行阈值 · review 一律转人审"]
  SEL -->|IP 最高敏 / 命中黑名单| MANUAL["人工复核档<br/>跳过机审放行 · 直接进人审队列"]
  STD --> GATE["锁风门聚合<br/>block&gt;review&gt;pass 取最严 · 落 game_compliance_gate_result"]
  STRICT --> GATE
  MANUAL --> GATE

(图源:审核台运营.md §3.3「锁风三档与 IP 库怎么绑」;选档器下游的机审瀑布见图 11)

这张图回答的是图 11 没答完的一个问题:锁风门有标准/严格/人工复核三档,但「这条内容该走哪一档」是谁、按什么决定的?图 11 只画了锁风门聚合的 owner 与三层瀑布,把「选档」当成一个黑盒输入;这张图把那个黑盒拆开,讲清档位的来源链——它不该让运营对每条内容手动选,而该由内容的 IP 归属自动推导出来。读这张图,新人能看出一条从上到下的推导链:IP 所有者签下授权时,授权档里就带了这个 IP 的敏感度与合同约束;每个注册 IP 据此带一个 lockStrength(标准/严格/人工复核);一条内容生成时声明了用哪个 IP,选档器就拿这个 IP 去查它的档位;没声明 IP 的纯 UGC 默认走标准档,内容类型再叠一层题材黑名单兜底(棋牌/捕鱼这类即便是纯 UGC 也强制拉到人工复核档)。三档选出来后,才进入图 11 那条机审瀑布——标准档正常跑、严格档把放行阈值压低、人工复核档直接送人审。

这张图最该让人看清的设计缝,是「档位源」现在和将来不是同一个东西。终态设计是把 lockStrength 作为 IP 的一个授权属性,直接挂在 IP 实体上,录入授权时由运营按 IP 方敏感度定下来;但现状是——IP 库目前只是个 seam,授权链还没建,根本没有承载 lockStrength 的 IP 实体。所以图上把「档位源」这一簇明确标成「现阶段=过渡表 lock_strength_policy、终态=IP 实体属性」,中间那条从 IP 实体指向过渡表的箭头特意画成虚线、注明「终态收敛(IP 授权模型成熟后)」:现在先用一张轻量过渡表按 ipId 或题材关键词映射档位、admin 可配,等 IP 授权模型成熟了再把档位策略收敛进 IP 实体。这样三档不被 IP 库的进度卡死,又不至于产生两套并行的策略源。这条「现在用过渡表、将来收敛进 IP 实体」的迁移,正是评审最该盯住的设计意图——别把过渡表当成终态,也别因为 IP 库还是 seam 就以为三档无从落地。

运营图 14 · 短信报备闸门 vs 邀请码旁路(C方案)切换纪律〔Mer新·时·现〕(P2)

sequenceDiagram
  participant U as 玩家
  participant P as 绘境AI 平台
  participant S as 短信供应商
  participant G as 合规闸门(#3 短信签名报备)
  Note over G: 报备周期 1-2 周不可压缩 · 报备完成前验证码不可用
  Note over U,P: 内测期:报备未完成,但注册漏斗不能被一道审批闸门卡死
  U->>P: 用邀请码注册(C 方案旁路 · 不依赖短信验证码)
  P-->>U: 注册成功(漏斗跑通,报备未完成也不影响内测)
  Note over G,S: 依赖串联:部分短信供应商要求域名已备案(#2 ICP)<br/>→ 选不强制备案的供应商先行,或等 ICP 完成,二者择一
  G->>P: 报备完成(签名通过)→ 才允许全量切验证码
  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: 登录成功(切到验证码全量)

(图源:合规闸门.md §6「短信报备这道闸门如何不卡死漏斗」+ §4 依赖串联;鉴权切渠道两项验证出自 HJ-PASSPORT-EXEC-001 §7.2)

这张图回答一个很实际的运营纪律问题:有一道合规闸门(#3 短信签名报备)周期 1-2 周不可压缩、且报备完成前短信验证码根本用不了,那内测期的玩家怎么注册?如果硬等这道闸门,注册漏斗在内测期就被卡死了——这正是「合规闸门是日历驱动、一秒也压不动」这条铁律,撞上「产品要尽快验证」这件事时的典型冲突。图上半部分画的就是绘境AI 的解法:把「鉴权」与「短信报备」解耦,内测期玩家用邀请码注册(C 方案旁路),完全不依赖短信验证码,所以报备没完成也不影响内测漏斗跑通。这一旁路同时还顺带服务了另一件事——自有端按「邀请制内测、不公开注册」定性(见图 3 的双层定性),邀请码注册恰好是这个定性的落地形态。

这张图最该让人记住的是下半部分那条红框纪律:邀请码旁路不是永久方案,等报备完成、要切到短信验证码全量时,不允许「只切一个配置开关就上线」。切渠道的硬规矩是「配置切换 + 两项验证绑定,缺一不可」——既要确认 huijing.captcha.enable 这个开关真正对发码链路生效(配置生效是一回事),又必须先把「按 IP 的日/时发码上限」用 Redis 计数部署好(发码频率有上限是另一回事);少了后者,验证码接口会被刷爆、烧出一个短信费用黑洞。图上还钉了一条容易被忽略的依赖串联:部分短信供应商要求域名已备案(#2 ICP 回执),所以这道报备和 ICP 之间有先后约束,要么选不强制备案的供应商先行、要么等 ICP 完成,二者择一。这张图标了 (P2) ——它讲的是一个会随日历推进真实发生的切换动作的运营纪律,不是当下就要执行的开发项;在邀请码内测阶段,它是「设计已想清、待时点到了再按纪律切」的待办,评审该确认的是这条「切换前置」别被简化成「改一行配置」,而非现在就去接短信验证码。

运营域图清单与状态表

#	图名	家族	形式	状态	覆盖内容
1	运营三件事咬合	流	引(内联 README §1)	现	上线(合规总闸)/ 变现(钱怎么分)/ 发行(钱从哪来)三件事咬合 + 护城河在 AI 供给侧成本结构的战略判定
2	12+1 合规闸门依赖	流	SVG升	现	经营主体已具备(0 号)→ 全链并行;ICP 临界路径 7-20 工作日;律所分叉;8 项法定 P0 换血待律所;状态去 A1 看板
3	合规死锁三环 + 双层定性破解	讲	SVG新	现	死锁三环(无版号 / IAA 豁免仅渠道 / 二清)+ 双层定性(自有端内测 ‖ 变现走渠道);内测成立边界待律所问 1
4	分账公式钱流	流	引(内联 README §2.2)	现	R3 唯一口径:N=0.6G,平台恒留 0.2N,账永不为负;头部款口径诚信红线
5	两平面、两钱包、三道硬边界	架	SVG新	现	生成计费(new-api)≠收益(trade/pay);创作者收益钱包(已建)≠消费钱包(未接);元≠分;边界铁律 + API key 安全红线
6	三线变现排序	流	引(内联 README §3)	现	① B端现金线 → ② 自有端内测数据线 → ③ 渠道规模线;②③产出诚实讲成未来式
7	四层护城河	讲	引(内联 README §3)	现	数据 / 网络效应 / 资产 / 合规 四层;护城河不在生成引擎;合规壁垒=闸门的另一面
8	发行双路线 H5 / 渠道	流	引(内联 README §2.3)	现	自有 H5 流(UGC + 改码主场)‖ 微信 / 抖音(精选整包过审);不互跳不外导
9	一壳多游 · L1 精选整包发行	架	SVG新	现	固定壳 + 远程 GameConfig(禁代码·9c 红线)+ 备案锁(待律所裁)+ 引擎竞标(P1 暂停)+ 零构建生产红利
10	变现端到端钱流地图	时	SVG新	现	三线(广告全真 / 订阅半真 / B 端仅状态机)→ 创作者钱包(恒等式)+ 提现 mock 打款;控制平面三 job + 对账锚点链
11	审核台双层审核	流	SVG新	现	快检 + 阿里云兜底 + 人审 BPM + 锁风三档 + 处置联动(下架现成 / 降权·信用·封账号联动待建);锁风门框架真·原子桩
12	运营对象状态机合集	状态机	SVG	现	四台机并排:提现五态(真跑·终点 mock)‖ B 端询单五态(不碰钱·钱留 M4)‖ 审核工单(第一期待建·超时告警为旁路态)‖ 订阅续期(入账真·收单未接·过期可逆回落);各机触发/终态/幂等键
13	IP 库 · 锁风档位来源概念模型	概念	Mer新	现	选档器 lockStrength 来源链:IP 授权档→IP 实体属性(终态)/ 现阶段过渡表 lock_strength_policy + 题材黑名单兜底;补图 11 未答的档位来源
14	短信报备闸门 vs 邀请码旁路(C方案)	时	Mer新	现(P2)	合规闸门(日历)交注册漏斗:邀请码旁路内测不卡注册 / 报备完成才切验证码;切渠道硬规矩=配置+两项验证绑定;依赖 ICP 串联

状态分布:14 张图整体状态全为「现」(讲的都是已拍板的现行设计逻辑);状态差异在元素级——已建真跑 / 框架真用实心块,待接线 / 待建 / mock / 钱留 M4 / 待律所 / 远期账用虚线框 + 文字小标。本域无「整图待接 / 整图缓做」的图,其纪律点是不把现行设计里被合规日历闸门或外部资质阻塞的部分画成已建好。防漂移门:本文 frontmatter 记运营域六份源档的 commit hash(README/合规闸门 @ 3e71715a、变现与单位经济 @ 7ecd616e、变现端到端 @ 38357c3d、渠道发行 @ 5cadf504、审核台运营 @ 15b707fd),源档变更即比对。

---