- 注册表:docs/architecture/README.md §2,37 份 canonical(frontmatter topic+canonical:true)与表双向机器对账
- 门:.agents/tools/docs-gate.py 六检(品牌根/canonical唯一/死链/入口卫生/留痕隔离/设计档申报),挂 .githooks/pre-commit(本仓已激活)+ .gitea/workflows/docs-gate.yml(待runner)+ wave-close 第8步;旧 check-deadlinks.sh 退役并入 G3
- 清缩:删 54 项历史档(plans 16/agent-specs 设计与spike 20/brainstorms 5/memorys 3/goals+作战清单完成史归档/王蓝莓design/SAA现状html/add-game-template);channel-spike 564K 代码资产迁仓级 spikes/;六件删前蒸馏已迁(代码评审16条open项→进度总账§5、prefix-cache字段表→cheap-model skill、意图基线29条→需求清单附录、九门降级rationale→验收门、A11 TODO→tech-decisions、3layer边界→littlejs-game-dev 指针)
- 修口径约90处:六处SAA『现行主线』旧标、Nacos/RocketMQ『未部署』旧述(07-01反转)、gameDefinition残留、全部死链改 git show 定位;AGENTS.md 249→136行(决策史归tech-decisions);_index 改纯在飞板;对外演示版 md→html
- 依据:docs/agent-specs/2026-07-02-文档治理-{全量普查与裁决-report,SoT注册表与治理门-设计}.md(四路普查191份md+Codex/Opus双评审必修项已折入);恢复基线 8ea97234(单档 git checkout 8ea97234 -- <路径>)
topic, canonical, date
| topic | canonical | date |
|---|---|---|
| 运营域总览 | true | 2026-06-10 |
运营域 · 设计主文档
这是什么:绘境AI 运营域的设计主文档,回答"一款游戏被造出来之后,怎么合规上线、怎么把钱赚回来、怎么发行到各渠道"。它衔接在产品域(用户能感知什么)与架构域(系统怎么搭)之后,讲的是商业与合规这条"落地链"。 给谁看:运营负责人、商务/BD、合规与法务对接人、创始人,以及做投资尽调时关心商业模型与风险的读者。 怎么读:先读本页建立全局认知——三件事(上线 / 变现 / 发行)各是什么、彼此怎么咬合;需要某一块的细节(分账公式、渠道合规红线、闸门状态)时,再深入文末的三份子文档。 读这一页 = 运营域的当前真相骨架。明细数字、公式、逐项闸门状态都在子文档里,本页只做综述与导航,不重复其内容。
1. 一句话与一张图:运营域要解决什么
产品域把"做得出游戏、有人来玩、能赚到钱"接成了一条产品闭环。运营域负责的是这条闭环里"赚钱"那半段能不能在现实世界里真正跑起来——而这取决于三件相互咬合的事:
- 上线(合规):在中国做面向公众的 UGC(User Generated Content,用户生成内容)游戏平台,必须先过一串法定资质与监管闸门(ICP 备案、实名防沉迷、AIGC 标识等)。这些闸门是日历驱动的硬约束,一秒也压不动,是整个商业化的前置门。
- 变现:游戏被玩到之后,靠广告、内购、订阅、B 端定制把收入收回来,再按规则分给创作者。这里既有钱怎么流的工程问题,也有"靠它能不能回本"的单位经济问题。
- 发行:把游戏铺到玩家在的地方——自有的 H5 游戏流,以及微信 / 抖音小游戏渠道。不同渠道的技术能力和合规口径天差地别,决定了"什么游戏能上哪个渠道、怎么上"。
三者的关系可以一张图说清:合规闸门是总闸,没过就不能商业化;发行决定钱从哪里进来;变现决定钱怎么分出去。三条线在"现金流"这个点上汇合。
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 -. 合规定性约束 .-> 变现
这里有一个反直觉但关键的战略判定:绘境AI 的差异化护城河 不在"自有 feed 形态"本身(那块早有现任者——摸摸鱼 / 233 / 4399 占着),而在 AI 供给侧的成本结构(用 agent 闭环把游戏的生成与质检全自动化,产能成本远低于人工)+ IP 锁风保真(下文 §2.3 解释)。运营域的所有安排都服务于把这个成本优势,在监管窗口期内滚成内容资产与数据飞轮。这一判定的来由与四颗"雷"的收口结论,见战略与合规。
2. 三件事各是什么
2.1 上线:合规闸门是日历驱动的硬约束
绘境AI 想做的是"普通人发布、平台分发、能接广告变现"的 UGC 游戏平台。在中国,这件事一旦面向公众、一旦接真钱,就会同时撞上几道监管:游戏需要版号(国家新闻出版署核发的游戏出版批文)才能商业化运营,平台需要 ICP 备案(网站经营许可的工信部备案)才能合法提供互联网服务,接广告变现需要相应广告资质,资金归集需要支付牌照,生成式 AI 还要做内容标识与大模型登记。
这套约束之所以特别棘手,是因为它构成一个连环死锁(我们内部称之为"合规死锁"):
- "IAA 免版号"(IAA = In-App Advertising,纯广告变现不内购)这条豁免通道,只在微信 / 抖音的渠道备案制内成立;搬到自有 H5 站就不再适用,落进监管灰区(已有 Roblox 在国内停服、被罚没 111 万元的先例)。
- 自有端没有版号,就无法接入出版署官方的实名 / 防沉迷系统,也就无法履行自有端本应承担的合规义务——这是第二环锁。
- 平台若代收广告费再分账给个人创作者,等于"无牌照资金归集",踩到**"二清"风险**("二次清算"的简称,指无支付牌照的主体经手他人资金的清结算,属违规)——这是第三环锁。
绘境AI 的破解办法是双层定性,把"自有端"和"变现渠道"在合规上彻底分开:自有端收敛为邀请制内测(不公开经营、不接真钱,按"试玩 demo"定性,只用来养数据回路);真正的变现走微信 / 抖音渠道(豁免通道成立,且由平台代管实名 / 防沉迷)。这样三环锁同时解开。
至于具体要过哪些闸门、各自卡在哪一步,有一张唯一跟踪面——A1 闸门看板。它把闸门列成 12 + 1 项(代号里 A1 = 作战清单中"日历临界路径"这条任务线):8 项法定 P0(P0 = MVP 阶段必须满足的最高优先级)——C 端实名、防沉迷时长 / 宵禁、未成年充值限制、AIGC 显式标识、青少年模式、关闭个性化推荐、账号注销、提现实名税务——加上审计新增的 3 项(大模型登记、算法备案、分账 / 灵活用工选型),再加 1 项律所合规咨询。
flowchart TB
M0["0 · 经营主体 ✅ 已具备"] --> DOM["1 · 域名+实名"]
M0 --> SMS["3 · 短信签名报备"]
M0 --> LLM["4 · LLM 实名充值"]
M0 --> LAW["11 · 律所合规咨询"]
DOM --> ICP["2 · ICP 备案<br/>(7-20 工作日 · 临界路径)"]
ICP --> PAYM["5 · 支付商户进件"]
ICP --> ADQ["6 · 广告联盟资质"]
LAW --> SPLIT["12 · 分账/灵工选型"]
LAW --> REG["9/10 · 大模型登记 / 算法备案"]
这张图要读出的几条主线:经营主体已经具备(0 号闸门 ✅,创始人 2026-06-10 确认),所以下游各项可以立即并行起跑,没有多米诺式的等待;ICP 备案是临界路径(7-20 个工作日,最长),它一通过,支付进件和广告资质两条线才能动;律所意见是另一个分叉点,它到位后才能定分账方案、确认大模型登记与算法备案的属地路径。
闸门状态是会变的活数据,本页只给骨架,不抄状态——任何一项的当前进度、owner、最晚提交日,都以 A1 闸门看板为准,看板变了即真相变了。律所要问的两个核心问题(UGC 的出版物定性 / 防沉迷如何接入)整理在律所合规咨询 brief。
2.2 变现:两个平面、两套钱包,加一道单位经济检验
变现这件事,工程上最容易出错的是把不同方向的钱混在一起算。绘境AI 用三条永不混淆的硬边界把它钉死:
- 生成计费平面 ≠ 收益 / 支付平面。"生成计费"指创作者调用大模型造游戏花掉的额度,走 new-api 网关(一个自部署的、对外 OpenAI 兼容的多模型 LLM 网关)的 token 配额,这个配额只减不增;而"赚回来的钱"(广告分成、内购)必须经业务钱包结算并过合规,走后端的 trade / pay 模块。把广告分成塞进 new-api 配额是范畴错误——一个是花出去、一个是赚回来,方向相反。
- 创作者收益钱包 ≠ 消费钱包。前者是创作者挣广告、提现用的(已建);后者是玩家充值、扣减内购用的(尚未接入)。两套账户、两个钱流方向。
- 成本侧用"元" ≠ 收益侧用"分"。成本台账在编排器里用浮点的"元",收益账在后端数据库里用 BIGINT 的"分",两个精度域跨平面对照必须显式换算,禁止同列求差。
变现最重要的不是"能不能跑通"(逻辑早已真实落地并有单测),而是靠它到底能不能回本——这是单位经济问题。绘境AI 把分账规则拍成了唯一口径(创始人 2026-06-10,代号 R3 收口):
总广告消耗 G ── 渠道扣 40%(微信 IAA 现金分成 60%)──> 平台实收净额 N = 0.6G
├ 无 IP:创作者拿 0.8N(= 0.48G) | 平台留 0.2N(= 0.12G)
└ 带 IP:创作者 0.55~0.65N | IP 方 0.15~0.25N(从创作者份额内出) | 平台恒留 0.2N
这个公式的精妙之处是平台恒留 0.2N:带 IP 时,IP 方的分成是从创作者那一份里出的,所以无论带不带 IP,平台都稳定留 20%,而对外宣传创作者"拿 55%~65%"和内部"80% 分成"用的是同一个模型,账永远不会算成负数。
基于这个模型做敏感性扫描(eCPM 三档:悲观 15 / 基准 30 / 乐观 60 元每千次曝光;eCPM = 每千次广告展示的收入)得出一个关键结论:自有端的 IAA 广告变现,是万级 DAU(基准约 1.33 万日活)才回本的规模化生意,刚好覆盖 ¥4,300/月 的 MVP 基础设施成本。所以近期的现金流只能靠 B 端 / IP 项目制(与 DAU 无关、回款最早),IAA 是远期账。这条认知直接决定了下面 §3 的三线变现排序。
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"]
诚信红线:对创作者宣传"能赚钱",必须用"头部款"口径(eCPM 30 时,单款约需每日 12 次激励视频观看才能达到 5 元提现门槛——头部款可达,长尾款达不到),绝不做普遍性承诺。分账的工程实现(7 个资金动作各自的幂等键、打款异步化、资金一致性红线)与完整敏感性模型,见变现与单位经济。
2.3 发行:自有 H5 流 + 双渠道精选,两条腿走路
游戏造出来要铺到玩家在的地方,绘境AI 走两条互补的发行路线,分工的根因是底层技术能力的硬差异(代号 HJ-CH-001 判定):
- 自有 H5 游戏流 = 海量 UGC 与"改码"的主场。浏览器对动态生成的代码没有禁令,所以 agent 生成的每款游戏都能即时发布、即时被刷到,这是"创作→生成→发布"闭环最完整的形态。
- 微信 / 抖音小游戏 = 精选整包过审的分发面。这两个渠道对远程包会自动剥离代码、明文禁止 JS 解释器(像 eval5 这类在运行时解释字符串为代码的库一律禁用),所以渠道里只能跑"包内固定的模板代码 + 远程下发的纯数据配置"。
这就是内部说的"一壳多游 · L1 精选整包"模式——一个小游戏 appid(应用 ID)里装固定的模板代码,玩法的差异全靠远程下发的 GameConfig(纯数据的游戏配置)来表达,不互跳、不外导,对外口径是"主题小游戏合集"而非"开放 UGC 平台"。"L1"指这一层只跑包内白名单内的模板,是相对受限但能稳定过审的发行层级。
flowchart TB
GEN["agent 生成游戏<br/>(每款独立代码)"] --> H5["自有 H5 流<br/>即时发布 · 动态代码无禁令"]
GEN -. 精选款固化进包 .-> PKG["微信/抖音整包<br/>固定模板代码 + 远程 GameConfig"]
PKG --> AUDIT["平台审核<br/>(备案锁:内容变更须重新备案)"]
AUDIT --> CH["渠道游戏流<br/>一壳多游 · 主题合集"]
H5 --> FEED["自有 feed 即刷即玩"]
发行侧有几条不能破的合规红线,因为它们直接决定渠道里的游戏会不会被下架:
- GameConfig 合规红线(渠道生死线):配置里禁止任何可执行 / 可被解释为代码的字符串(例如
condition: "score>10"这种把逻辑写进数据的写法一律禁),剧情 / 关卡只能用有限状态机的枚举来表达,所有templateId / actionType / assetId都走枚举白名单,schema 关闭额外属性、限死数值与长度。这条红线转正后会成为契约里的第 9c 条。 - 备案锁是比版号更紧的决定性闸门:官方规定"备案完成后不支持改游戏内容 / icon / 代码,实质变更须重新备案",这让"一壳多游"从"灰区可行"降级为"高风险待裁"。因此"当日热发新游进渠道"这个叙事被收回了——热发只限既有游戏的非实质参数微调,实质变更要走"重新备案 + 整包提审"的月级节奏(具体边界待律所裁定)。注意:这条锁只约束渠道,不影响自有 H5 流(H5 无备案锁)。
至于渠道线该用哪个引擎打包(LittleJS 自研适配 vs Cocos 原生导出)、双端各出一包的工程细节、真机取证的七道验证门,见渠道发行。
3. 三件事怎么咬合:三线变现排序
把上线、变现、发行三件事合起来看,绘境AI 的现行战略主轴是一条有先后次序的三线变现(与所有既有裁定自洽):
flowchart LR
L1["① B端/IP 营销小游戏<br/>现金线 · 首位"] -->|供血| L2["② 自有端邀请制内测<br/>数据资产线"]
L2 -->|养飞轮种子| L3["③ 渠道线<br/>规模线 · 微信/抖音 IAA"]
L1 -.标杆案例.-> L3
| 线 | 定位 | 为什么是这个合规定性 | 它产出什么 |
|---|---|---|---|
| ① B 端 / IP 营销小游戏(现金线·首位) | 给 IP 方 / 品牌方做推广小游戏,项目收费 + 分成 | 推广内容不是网络出版物,版号争议最小、回款最早(已有"王蓝莓"案例点火) | 现金流 + 标杆案例 |
| ② 自有端邀请制内测(数据资产线) | 内测灰度,养数据回路 / 质量评分 / agent 闭环 | 按"试玩 demo"定性,不公开经营、不接真钱 | 行为数据 + 产品迭代(飞轮种子,诚实地讲成未来式) |
| ③ 渠道线(规模线) | 微信 / 抖音小游戏备案 + IAA 广告变现 | 豁免通道成立,平台代管实名 / 防沉迷 | 规模化曝光 + 真实 eCPM |
这条排序对外讲给投资人的故事主轴是:单人 + AI agent 体系的资本效率(已实证)→ 用 B 端 / IP 现金线供血 → 在监管窗口期里把供给侧的成本优势,滚成内容资产与数据飞轮(后半段是未来式,必须诚实标注)。
这套商业模型为什么成立(战略论证见商业定位,本页不重复)
资本效率(开源生态组合而非烧钱自研、技术投入约为头部竞品 1/5、5 人核心团队 + ¥4,300/月 跑通 MVP)与四层护城河(数据 / 网络效应 / 资产 / 合规——越往后越难复制)的完整论证属于战略叙事,单一事实源在产品域 · 商业定位与护城河话术,本页不再展开。这里只钉住与运营直接相关的一条:合规壁垒恰是 §2.1 那串闸门的另一面——同一套资质,对自己是必须翻过的门槛,对后来者就是 6-12 个月才能补齐的护城河,所以"先把合规闸门跑通"既是上线前置、也是在攒护城河。合规闸门的设计单一事实源在运营 · 合规闸门。
4. 还没拍板的事(活 · 阻塞 · 不可擅改)
运营域里有几件事还压在创始人手上,agent 不可擅自改动,登记在此以防失踪(明细见战略与合规 §6):
- 合规死锁的最后一公里:Doc A(产品需求清单)里那 8 项法定 P0 的换血,要等律所就两个核心问题(UGC 的出版物定性 / 防沉迷接入方式)给出意见后才能定。这是当前最大的外部阻塞。
- 示例模板 / 创作起步面的去留:早期 demo 里的"模板浏览 / 玩法模板中心"等入口要删除、降级还是重定义为"示例 Prompt 库 / 灵感画廊",会直接增删 55 项 P0 的验收集。
- 对外叙事的单值收敛:团队表述与唯一融资口径(早期 BP 改造版里有互斥的区间),需要创始人对外定一个单值——属对外叙事,不影响工程。
这类"灰色地带判断"(哪份文档过期了、两份冲突文档哪份胜出、一个补丁是不是架构信号)按项目治理约定,由创始人 + 文档 / 设计线这个有状态的主体担责,机器门做不出的判断不交给无状态的临时 agent。
5. 子文档导航
本页是运营域的入口与骨架,讲清了三件事各是什么、怎么咬合。每一块的明细——公式、红线、逐项闸门状态——在下列子文档,需要细节时再深入:
| 文档 | 回答什么 |
|---|---|
| 变现与单位经济 | 两平面 / 两钱包的架构边界、广告分账→钱包→提现的收益闭环、7 个资金动作的幂等键、分账公式与 eCPM 敏感性、资金一致性红线 |
| 变现端到端 | 三线钱流的工程地图——钱从广告 / 订阅 / 定制出发,经哪些表、后台 job、跨模块接缝、回调,落到创作者钱包 / 平台营收;与上行"算账"分工 = 本份"讲钱具体怎么流" |
| 渠道发行 | 自有 H5 流与微信 / 抖音渠道的分工根因、L1 一壳多游模式、GameConfig 合规红线(契约 9c)、渠道引擎竞标(LittleJS vs Cocos)、真机取证七门 |
| 战略与合规 | 战略总判定(四颗雷收口)、三线变现排序、合规死锁与双层定性、单位经济地基、demo↔产品定位纠偏、待创始人拍板项 |
| 审核台运营 | 内容安全日常运营:双层审核(自部署快检 + 阿里云兜底 + 人审 BPM)、锁风门三档、违规处置联动 feed 曝光与创作者信用、admin 审核台;含 contract-first 清单与 3 个开放问题 |
跨域的两个跟踪 / 计算面(状态会变,以它们为准):
| 跟踪面 | 用途 |
|---|---|
| A1 闸门看板 | 12+1 项合规闸门的唯一跟踪面——每项的 owner、最晚提交日、阻塞状态,变了即真相变了 |
| 单位经济敏感性模型 | 分账公式、eCPM 假设档、回本 DAU 测算与埋点测量计划的唯一计算面 |
纪律:运营域只讲"怎么合规上线、怎么变现、怎么发行";用户能感知什么在产品域,系统怎么搭、关键技术决策为什么在架构域。各域各司其职、互不重复。本页的源头是两份长文档——
系统概要设计-投资人版.md(HJ-ARCH-002,商业合理性与资本效率)与战略与合规.md(子系统 SoT,战略 / 合规 / 经济活结论的汇总入口);需要逐条考据时回溯它们。