games-development-ai/docs/architecture/运营/变现与单位经济.md

---
topic: 变现与单位经济
canonical: true
date: 2026-06-12
---

# 变现与单位经济

> **这是什么**:绘境AI 的钱怎么进、怎么算、怎么发,以及这门生意在单位经济上到底成不成立。它把"收益闭环 + 成本来源 + 单位经济模型 + 资金一致性红线"四件事讲清楚,既回答"平台靠什么赚钱、成本花在哪",也回答"一款游戏在最细的颗粒度上是赚是赔"。
> **给谁看**:创始人、财务、运营、负责变现链路的后端工程师,以及做融资尽调时关心资本效率的投资人。
> **怎么读**:先读 §1 建立"两个平面、两套钱包"的全局认知,这是本域所有规则的地基;再按需深入收益闭环(§2)、成本侧(§3)、单位经济模型(§4)、资金一致性红线(§5)。具体的敏感性数字(各档 eCPM、回本 DAU、提现门槛可达性)在 `docs/mvp/单位经济敏感性模型.md`,本页只取结论。
> **和[商业定位](../产品/商业定位.md)的区别**:商业定位讲"我们靠什么赢"(战略叙事);本页讲"账具体怎么算、钱怎么流"(可执行的财务与工程口径)。

---

## 1. 一张图看懂:两个平面、两套钱包

变现这件事最容易出错的地方,是把"花出去的钱"和"赚回来的钱"混在一起算。绘境AI 用一条铁律把它们隔开:**钱往外花和钱往回赚,是两个方向、两套系统,永不混淆。**

具体拆成三道硬边界:

- **生成计费平面**(钱往外花)由 **new-api** 负责。new-api 是一个开源的 LLM(大语言模型)统一网关——所有对 DeepSeek、通义千问、MiniMax 这些底层模型的调用都从它走,它顺带记账、限额、做可观测。它只管"创作者生成游戏时消耗了多少额度",配额只减不增,既不结算也不碰合规。
- **收益与支付平面**(钱往回赚)由后端的 **game-module-trade / game-module-pay** 两个业务模块负责。广告分成入账、提现、结算、合规,全在这里。
- 为什么不能把广告分成塞进 new-api 的配额里?因为"配额只减"是钱的反方向;赚回来的钱必须经过业务钱包结算、过合规面,把收益硬塞进一个只会扣减的计量系统是**范畴错误**。

在收益平面内部,还要再分两套钱包,因为它们是两个账户、两个钱流方向:

- **创作者收益钱包**(在 trade 模块):创作者挣到广告分成、提现到微信/支付宝。**已建成。**
- **消费钱包**(在 pay 模块):用户充值、形成余额、扣减内购。**尚未接入单体。**

最后还有一道精度边界,跨平面对账时必须显式换算:**成本侧全程用"元"**(浮点数,活在编排器域),**收益侧全程用"分"**(BIGINT 整数,活在后端数据库域)。两个精度域**严禁放在同一列里直接做减法**。

```mermaid
flowchart TB
  subgraph GEN["生成计费平面 = new-api(权威成本源 · 别自建)"]
    NT["创作者 token<br/>生成调用走自己的 token 扣额"]
    NL["logs.quota 表<br/>每次调用的真实倍率成本"]
    NT --> NL
  end
  subgraph REV["收益侧 = game-module-trade/pay(业务钱包)"]
    AD["SDK 广告 → ad 计费<br/>game_ad_revenue(分 · 带 game_id)"]
    SET["SettlementJob T+1 结算<br/>recordIncome 逐笔入账"]
    TI["game_trade_income<br/>+ 创作者钱包余额"]
    WD["提现:冻结 → 审核 0→1→2/3/4<br/>→ 异步打款"]
    AD --> SET --> TI --> WD
  end
  subgraph PAY["消费侧 = pay(未接入单体)"]
    WAL["充值 → 消费钱包余额<br/>reduceWalletBalance 内购扣款"]
  end
  NL -.->|读 logs.quota 为权威| COST["成本台账<br/>newapi_cost.py"]
  classDef boundary fill:#fee,stroke:#c33,stroke-width:2px;
  class REV,PAY boundary;
```

> 红框是边界铁律:**trade/pay 的钱永不写进 new-api**(已用 grep 确认 new-api 里没有任何收益写入路径);广告分成只出现在 trade。这条边界一旦破掉,成本和收益就会互相污染,账再也对不平。

---

## 2. 收益闭环:从一次广告展示到创作者提现

这是平台对创作者最核心的承诺——**当天创作、当天有人玩、当天看到收益**。整条链路从玩家看到一次广告开始,经过计费、T+1(次日)结算、入账,最后到创作者点击提现,每一步都已落地并有单元测试覆盖(对应交付件 HJ-M4-REAL-001,已合入主干)。

```mermaid
flowchart LR
  A["创作者发布游戏"] --> B["游戏信息流曝光<br/>玩家试玩"]
  B --> C["广告展示<br/>激励视频 / 插屏 / Banner"]
  C --> D["广告计费<br/>合规校验 + 幂等 + 归因"]
  D --> E["T+1 自动结算<br/>逐笔入账创作者钱包"]
  E --> F["满 ¥5 即可提现<br/>微信 / 支付宝"]
```

按链路顺序拆解每一步在做什么:

1. **广告计费。** 玩家触发一次广告后,先做合规校验(屏蔽未成年人,内部叫 `blockMinor`),再用一个唯一追踪键 `uk_trace` 做幂等(保证同一次广告事件不会被重复计费),通过 `ProjectApi` 把这笔收入归因到具体项目,最后落到 `game_ad_revenue` 表。激励视频按 reward(奖励)收入口径单独计,避免和普通展示双算。
2. **分账结算。** `SettlementService` 把广告收入逐条入账到创作者钱包,用 `uk_source` 唯一键防重,并遵循"先入账、后回标"的补偿顺序(先把钱记进去,再把这笔来源标记为已结算,即便中途失败也不会丢账)。这个结算任务挂在 XXL-Job(一个分布式定时任务调度框架)上,T+1 自动跑。
3. **提现。** 创作者发起提现时,先看是否达到门槛(可在 Nacos 配置中心动态调,键名 `withdraw-min`,当前是满 5 元),再用 CAS(比较并交换,一种乐观锁,保证并发下余额不会被扣两次)冻结金额,然后走一个审核状态机:`0(待审)→1(审核通过/打款中)→2(成功)/3(驳回)/4(打款失败)`。
4. **广告渠道可插拔。** 对接不同广告联盟靠一个 SPI(服务提供接口)扩展点 `AdProvider` 加上工厂 `AdProviderFactory`;没注册真实渠道时自动降级到 mock(假数据)。穿山甲(csj)、优量汇(gdt)两家只差一个实现类,业务代码零改动即可切真。
5. **打款异步化。** 审核从 `0→1` 时发起 `PayTransferApi` 转账,但这一步**不阻塞审核事务**;真正的成功/失败由支付回调(pay notify)驱动:回调成功推 `1→2`,失败推 `1→4` 并把冻结金额退回余额。数据库里有一列 `transfer_ref`(在迁移 V14 引入)作为对账锚点。
6. **打赏现金发放。** 用 `recordIncome(source=TIP, ...)` 入账 + 打赏记录状态 CAS `0→1`,补齐了打赏(TIP)这个唯一真实入口。

**每一个动钱的动作都有自己的幂等键。** 这是资金安全的命门——总共 7 个资金动作,逐个都挂了防重保护,任何重放都不会让钱多发或多记:

| 资金动作 | 幂等键 |
|---|---|
| 广告计费 | `game_ad_revenue.uk_trace(trace_id, event_type, tenant)` |
| 分账入账 | `game_trade_income.uk_source(source, source_ref, tenant)` |
| 结算回标 | `markSettled` 仅 `0→1`(`WHERE settle=0`) |
| 提现申请 | `game_trade_withdraw.uk_biz_no` |
| 审核流转 | CAS `WHERE status=expect` |
| 打款回调 | pay `out_trade_no=withdraw.id` + 状态 CAS(`1→2` / `1→4`) |
| 打赏发放 | `recordIncome` 的 `uk_source` + 打赏状态 CAS(`0→1`) |

> **对比竞品的意义。** 极逸 SOON 要做到商业级才有收益,门槛极高;TapTap 制造分成低、月结、创作者几乎感知不到。绘境AI 的差异不在"能不能赚",而在"当天就能看到收益"这个即时反馈——这正是把创作者留下来的关键。

---

## 3. 成本侧:new-api 是唯一的权威成本源

绘境AI 的整套技术哲学是**用开源生态组合而非烧钱自研**(详见[投资人版概要设计](../_archive/系统概要设计-投资人版.md)),把钱省下来花在竞品做不了的事上——游戏流分发和变现闭环。这一节回答"那生成一款游戏到底花多少钱"。

结论先行:**文本生成根本不是成本瓶颈。** ¥0.031 是**旧填参路径(LLM 填参)的文本 token 下界**实测值(merge-prod-20 这一批 20 个创意、57 次调用、19 个被采纳的实测口径,单次 LLM 调用约 ¥0.0103)。注意 2026-06-12 创始人拍板「模板=引擎能力插件、每款游戏=agent 写码、填参主线作废」后,文本 token 成本只是这条链的一小部分,**单款 per-gen 的成本红线统一以运行时 SoT [`生成引擎/agentic运行时架构图说`](../架构/生成引擎/agentic运行时架构图说.md) §5.2 为唯一源:轻量 AI 深度档 per-gen <¥10、复杂档 per-gen <¥50(图 / 音另算)**——本页不再自带便宜档的预算数值,凡谈 per-gen 成本闸都 repoint 到那里。轻量 AI 深度档(对应 A-model 写真 src/ 的便宜线)单款实测远低于 ¥10 这道闸。另一条路、由 tier2 自治富游戏轨产出的 premium 富游戏,因为要 agent 多轮迭代地写一整套多系统工程,走低产量、高价值的账:**tier2 单局实测约 ¥1.29,落在复杂档 <¥50 闸内。** 真正可能咬人的成本是图片/音乐这类素材生成的 GPU 开销(目前 ComfyUI 未部署,零数据)和人工审核兜底,这两项列为后续单位经济埋点(内部代号 **W4**,即按游戏粒度的成本/收益数据回路)的测量项。

成本来源与口径有几条硬规定:

- **谁是权威源。** 成本数据**直读 new-api 的 PostgreSQL 日志表 `logs.quota`**,因为里面含每个模型的真实计费倍率(new-api 的计费引擎已经算好)。客户端用 token 数自己估算的那套(`llm_client.py`)**降级为 fallback 和交叉校验**,不再作为权威。读取工具是 `git show 6d2f8789^:docs/agent-specs/2026-06-09-agent-loop-v1/orchestrator/newapi_cost.py`。
- **换算口径。** new-api 内部用一个抽象单位记额度,换算关系是 `QuotaPerUnit = 500000/USD`(这是 new-api 编译时的默认值,数据库里查不到这个 key),再乘 USD→¥ 的汇率假设 7.2。
- **new-api 能力的真实边界**(2026-06-11 实查):`users / tokens / logs / channels` 这四张表已被 917 条日志的真实流量验证过,是可信的;但 `redemptions / top_ups / subscription_*`(兑换码/充值/订阅)这些表**schema 在、却从未跑过一行数据**(这个 fork 没验证过这些功能,不要当成就绪能力)。
- **🔴 P0 级安全红线(开通任何创作者账户前必修)。** new-api 网关当前运行于 Tailscale 内网(`100.64.0.8:3000`,100.64.x.x 为 Tailscale CGNAT 段),拓扑已是「3000 收到内网」;但**开通公网 / 创作者账户前仍须确认** 3000 未直接绑 `0.0.0.0`、ufw 已对非内网封禁——因为 `channels` 表里存着上游厂商的 API key,一旦公网可达且泄露就是直接被盗刷上游账单(此项在 2026-06-16 任务普查里登记为「上线前必修」)。另外,给每个创作者发的 per-creator token 本质是支付工具,**绝不能明文落进 `game_player` 表**。

---

## 4. 单位经济模型:这门生意在数字上成不成立

### 4.1 分账公式(R3 拍板,唯一口径)

这套分成规则在 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
```

这里的几个术语:**IAA** 指 In-App Advertising,游戏内广告变现(区别于内购);**eCPM** 指每千次广告展示的有效收入。关键设计是:无论用不用 IP 素材,**平台永远恒留 20%**;IP 授权方的分成是从创作者那一份里出的,不额外加码。所以"创作者 80%"和"创作者 55-65% + IP 方 15-25%"说的是同一个模型的两种表述。自有端(远期、过合规闸门后)走广告联盟时,把渠道 40% 替换成联盟实际扣率即可,公式不变,基数仍是实收净额。

### 4.2 敏感性结论(数字明细见敏感性模型)

eCPM 取三档做敏感性扫描:**悲观 15 / 基准 30 / 乐观 60 元/千次**(激励视频口径)。注意这是用来摸边界的扫描,**不是收入预测**——外部核查只拿到从业者给的 20-80 区间,低置信。

这里必须钉一个口径地雷,否则跨页引用会得出自相矛盾的结论(创始人 2026-06-22 历史回收判定捡回):**绘境AI 内部存在两套不同口径的 eCPM,差约一个数量级,对照前必须先对齐。** 本页和敏感性模型用的是"激励视频每次曝光"口径的 eCPM 15/30/60;而另一份《全成本收益测算 v2》用的是"完整观看单价"口径——单价 ¥0.4/0.75/1.2,折算成激励位 eCPM 约 200/562.5/1080。两者算的不是同一个量:前者按每次广告曝光摊,后者按每次完整观看摊,完整观看率远低于曝光数,所以折算下来差了约一个数量级。任何人拿全成本 v2 的回本月份去对照本页的"1.33 万 DAU 回本",如果没先对齐这两套口径,会得出矛盾结论却不自知。所以引用 eCPM 数字时务必标清是哪套口径,跨两份模型对照前先做口径换算,别把曝光口径的 30 和完整观看口径折算的 562.5 当成同一回事。

这个模型最重要的一句话,也是它对战略的真正贡献:

> **自有端 IAA 是"万级 DAU 才回本"的规模游戏。** 在基准档(eCPM 30、人均 3 次展示/日)下,覆盖 ¥4,300/月基建成本需要约 **1.33 万 DAU**(日活用户)。种子期只有百级 DAU 时,月留存只有几十元量级。

这条结论直接决定了变现三线的排序:**近期现金只能来自 B 端定制 / IP 项目制收费(与 DAU 无关),IAA 广告是远期的规模账。** 把希望寄托在 IAA 早期回本是不现实的。

关于"满 5 元提现"对创作者的可达性:头部款可达(eCPM 30 时需单款约 12 次激励展示/日),长尾款不可达。因此**对创作者宣传"能赚钱"时,必须用头部款的口径,不能做普遍性承诺**——这是审计 R3 连带的诚信红线。

这条诚信红线不能只活在经济模型档里,要落到创作者引导/激励的文案层(创始人 2026-06-22 历史回收判定捡回)。"满 5 元提现"对长尾款长期不可达,如果产品在创作者引导、激励页、收益预期这些文案里暗示"做了就能提现赚钱",那就是一笔面向用户的潜在诚信债——种子期绝大多数创作者的广告收益接近零,提现门槛长期够不着,落差会反噬留存和口碑。所以面向创作者的收益预期管理要做实:文案讲收益时用头部款口径、不做普遍性承诺,把"收益取决于作品表现、长尾款可能长期达不到提现门槛"这层预期诚实地前置给创作者,而不是只在内部经济模型档里写一句诚信红线、对外却用"能赚钱"做钩子。

上面 eCPM 三档摸的是"单位收入"的边界,但回本快慢的头号变量并不是 eCPM(创始人 2026-06-22 历史回收判定捡回)。《全成本收益测算 v2》的九宫格敏感性给出一个更要命的结论:**回本月份对月增速的敏感度,高于对 eCPM 的敏感度——月增速才是回本的头号杠杆。** 在零投流假设下取月增速 15%/25%/35% 三档扫描,同一个 eCPM 基准档里,月增速从 15% 升到 35%,回本月份近乎减半(基准列从 24 个月缩到 12 个月)。而这个最主导回本的变量,恰恰是当前**最没把握、完全未经验证**的一个——它建立在"零付费投流也能撑住这个月增速"的强假设上,而"不花钱买量能不能持续拉到这么高的自然增长"还没有任何实测数据支撑。

这条直接关系到对外讲回本周期时的诚实度:拿乐观月增(35%)算出来的"一年回本"和拿悲观月增(15%)算出来的"近三年回本",差着一整个融资窗口,而决定走哪条路的恰恰是这个最不确定的变量。所以**对外讲回本周期时必须连带声明这个头号假设**——讲任何回本月份,都要同时说清"这个结论的头号假设是零投流下的月增速、属低置信、待 W4 拉新埋点实测验证",不能拿乐观月增算出的回本数字单独抛出去给人一个过于乐观的预期。这条和下面 §4.3"拿到真实账单前不对外锁价"、以及创作者收益文案的诚信红线是一组对外口径纪律:凡是对外抛数字,都要把它背后最不确定的那个假设一并交代清楚。

还有一条成功率的对外口径要钉清,避免对外讲"生成成功率"时虚高或自相矛盾(创始人 2026-06-22 历史回收判定捡回):**绘境AI 有两个不同的成功率指标,对应两件不同的事,对外口径统一前要做双指标声明。** 一个是**王蓝莓窄域 ≥90%**——单 IP × 单点玩法(1 个 IP 配 2 种玩法)打透的可行性验证门,衡量的是"单点能不能做到极致";另一个是**生成工厂宽域 ≥80%**——海量 UGC 任意题材的平台能力门(对应 W-G1 开闸验收的 ≥80% 现行口径),衡量的是"广域随机生成能不能稳"。这两个数不能混为一谈:窄域是收窄了输入空间打深的成绩,宽域是放开输入空间求稳的成绩,窄域天然比宽域高。对外讲成功率时若不区分,要么拿 90% 的窄域数去冒充平台普遍能力(虚高),要么把两个口径混着引用导致自相矛盾。所以引用成功率务必标清是窄域单点验证(≥90%)还是宽域平台能力(≥80%)。

### 4.3 三个假设值的红线

成本侧涉及三个还没拿到真实账单、暂时占位的假设值。创始人 2026-06-11 已采纳一条红线:**在拿到真实账单前,这三个值一律标注【假设·待测】,不作为预测口径,不对外锁价。**

| 假设值 | 当前占位 | 含义 |
|---|---|---|
| `PRICE_PER_MTOKEN_YUAN` | 2.0 | 每百万 token 的人民币单价 |
| `QUOTA_PER_UNIT` | 500000 | new-api 额度单位换算(每 USD) |
| `USD_CNY` | 7.2 | 美元兑人民币汇率 |

这条红线不能只管内部成本测算,要一路延伸到对外材料(创始人 2026-06-22 历史回收判定捡回)。这三个假设值真实化依赖创始人提供 new-api 网关的真实账单口径(关联 A1 闸门里的 LLM 实名充值闸门),在账单到手前它们只是占位值。这意味着任何由它们推导出来的单款成本、毛利、回本测算,**对外都不能当成锁定的数字承诺**——无论是护城河话术、对外收益叙事还是融资材料,凡引用单款成本或单位经济结论,都要带上"基于待测假设值、未拿到真实账单前不锁价"这层声明,与 §4.2 那条"对外讲回本要连带声明头号假设"是同一条对外口径纪律。把这条对内的成本待办和对外的承诺纪律挂钩,是为了堵住一个真实的口子:内部档老老实实标了【假设·待测】,对外材料却把同一个数字抄成确定的成本承诺——这种落差一旦被尽调戳穿,伤的是可信度。

### 4.4 生成分级即订阅转化漏斗,第一笔收益激活即留存钩子(创始人 2026-06-22 历史回收判定捡回)

订阅这条收入线的核心产品逻辑,是把"生成能力的分级"直接做成"免费到付费的转化漏斗"。三级生成(L1/L2/L3)对应小白、进阶、专业三类创作者:小白用免费的 L1 体验把游戏做出来,进阶和专业能力(更高的生成级别、更大的额度、premium 品类)放在订阅后解锁。这个梯度本身就是付费墙——复杂能力不打扰小白(他们不需要、也不会因为看到锁而流失),想要更强能力的人自然撞上订阅入口。所以生成分级不只是产品功能的分层,它是订阅收入的转化机制设计:用"生成级别和额度"做付费墙,比单独立一个会员页更顺,因为创作者是在真实创作受限的那一刻遇到升级点的。它和创作者等级体系(Doc A 的 P-INC-02)、会员订阅(P-PAY-02)是同一套逻辑的两端——等级是身份、订阅是权益、生成分级是把两者挂钩的那道闸。

与之配套的是"第一笔收益激活路径"这个留存钩子。要把创作者留存从"工具使用"升级成"收益驱动",光让他生成出一个游戏不够,必须有一条显式的产品引导,把他从"生成一个游戏"一路推到"发布、进信息流、拿到第一笔广告收益"。第一笔收益是创作者从"试用一次就走"转成"为了收益留下"的关键拐点——他亲眼看到自己做的东西真的赚到了哪怕几毛钱,留存逻辑就从工具好不好用变成了这里能不能持续赚。这条激活路径要做成明确的 onboarding 设计(和 Doc A 的新人任务 P-INC-01 衔接),而不是把发布和收益当成创作者自己会去摸索的功能。

> **战略优先级提醒(对接 012):** 上面这套订阅漏斗的回报、以及任何关于"靠订阅/广告规模化回本"的判断,都依赖每款游戏真实的单位经济数据(见 §6 的 W4 按游戏粒度成本/收益埋点)。在单位经济测准之前,订阅漏斗的转化假设、第一笔收益的金额预期都还是假设值——"先把单位经济测准、再谈规模"这条战略优先级判断的完整论述在[商业定位](../产品/商业定位.md)§4.1,本页只承载它在变现侧的落点。

---

## 5. 资金一致性红线(执行时必守)

下面四条是动钱代码必须遵守的不变量。它们看似细节,但每一条背后都对应一类真实会丢钱或多发钱的事故。

1. **打款"发起"不等于"到终态"。** 资金状态以支付回调(pay notify)为准,转账发起和 `1→2`(打款成功)必须解耦;**严禁在审核事务里同步置为"已打款"**(mock 渠道除外,但它仍走状态 CAS)。万一回调丢失,要有对账补偿任务定期扫描 `status=1` 的超时单,主动去查支付方的真实状态来补推进度(用幂等 CAS 保证不重复)。
2. **降级要 fail-fast(快速失败),不能静默。** 广告计费降级到 mock 是可接受的(顶多少算一点收入);但**打款降级到 mock = 假装打了款却吞掉真钱**——这种情况必须 fail-fast 把提现单挂起,**绝不允许静默降级发真钱**。
3. **逐笔向下取整,禁止用聚合总额反推。** 链路上有两次独立的向下取整(广告侧按 eCPM/1000 算、结算侧 `setScale DOWN`),导致"逐笔净额之和"不等于"总毛额 × 0.80"。所以**对账必须以逐笔为权威**(单笔净额 == `floor(毛额 × 比例)`),**禁止用"总额 × 0.80"反推**;日期键统一取上游的 `stat_date`。
4. **mock 不变式(接真实联盟前的前置)。** 当前 MVP 下 `revenue_amount` 恒等于净额 N(渠道扣率为 0,即 G == N)。**真实接入广告联盟前,必须先定清楚 `revenue_amount` 到底存毛额 G 还是净额 N**:如果存 G,trade 就得先 ×(1−渠道扣率) 再 ×创作者份额(即先 ×0.6 再 ×0.8),否则既违反 R3 公式,历史快照也无法回算。这是支付真实化的阻塞前置项。

---

## 6. 现状与待办

**✅ 已落地:** 收益闭环(广告计费 / 分账 / 提现 / 打款异步 / 打赏到账 / 广告回调骨架,sandbox 与 staging 环境的端到端测试均可验)+ 成本侧 new-api 权威成本接通。对应交付件 HJ-M4-REAL-001(收益闭环)与 W4 成本薄片。

**⏸ 待办与推迟:**

- **按游戏粒度的成本/收益埋点(W4 ③④,未落)。** 广告产值侧走只读聚合 `group by game_id`(`game_ad_revenue` 已有 `game_id` 列和索引,零建表);创作者应得侧要补 `game_trade_income.game_id` 打通四步链(契约 `ad.yaml` 加字段 + DTO 加 `gameId` + 数据库 ALTER 加列 + `recordIncome` 透传,缺一即断)。**这里有一条防重计数的硬约束**:所有写入和透传只能发生在"首次真实入账"分支(`firstRecord/firstBilling`),命中幂等键的回查分支绝不能累加,否则同一来源重放会把统计虚高;验收必须包含 staging 重放后按游戏汇总不变(不能只靠单测 mock)。**这里有一条架构裁决**:否决了"往 telemetry 的统计表加 ad/income 列"的做法——那条路径实为新建跨模块写接缝(telemetry 没有对应写 API、签名已冻结、trade 也不依赖 telemetry),还会把"恰好一次"的保证从 ad/trade 错位到 telemetry,得不偿失。
- **per-creator 计量 + 支付→配额同步 + 订阅/充值 + UI 购买流(推迟)。** 被支付通道真实化阻塞(ICP 备案 7-20 工作日 + 微信进件 1-3 周,3-5 周内无法端到端;订阅定价也未定)。还有一个可行性硬阻塞:new-api 的 admin API **无法替他人铸 token**(`AddToken` 硬编码成调用者自己的 UserId),得重新设计一套"凭证引导"流程;而且支付→配额**不是本地事务**,真实机制是三方对账(微信交易号 ↔ 平台订单 ↔ new-api 充值记录,后者的 `trade_no` 是 UNIQUE 幂等锚)。
- **消费侧钱包最小闭环(新增范围,待创始人 go/no-go)。** pay 模块尚未接入单体;好在 admin 手动加余额的能力已落地(U2 R-ECON,commit `ca53a0db`:trade 侧 `game_trade_grant` 流水表 + admin 赋余额接口,审计已实测接入后启动干净、零冲突;底层框架另自带 `PUT /pay/wallet/update-balance`)。最小闭环 = 接入 pay + 复用现成的 admin 加余额 + 1 条内购扣款。**裁断:属 v2.0,非 MVP 必需**(MVP 关键路径仍是日历闸门 + IAA 广告闭环)。
- **会员订阅(已建后端,自助购买待支付通道)。** 后端订阅域已端到端建成(U2 R-ECON,commit `ca53a0db`,迁移 V21):`game_trade_subscription`(套餐 + 到期 + 状态)+ `game_trade_subscription_grant`(每笔赋订阅一行 + `uk_biz_no` 幂等账本,经 Codex 评审修订幂等 P0)三表,admin 侧 `/subscription/grant` 赋订阅、C 端 `/subscription/mine` 查订阅态(active/plan/expire),契约 `trade.yaml` 已扩。**仍缺 = 自助购买订阅**(接 pay 下单回调开通,被日历闸门阻塞;订阅定价也未定)——本轮订阅由 admin 手动赋(运营/B 端开通)。
- **真实广告联盟(csj/gdt)+ 真实打款渠道(微信企业付款)(被合规日历闸门阻塞)。** 代码侧切真**零改业务码**:广告侧注入 `CsjAdProvider`/`GdtAdProvider` 并改配置;打款侧在 Nacos 把 `trade.payout-channel` 设为 `wxpay` 并填商户密钥即可。

---

## 7. 资本效率视角:成本、团队、Runway

这一节从投资人尽调的角度收口——把上面的单位经济放进整体资本效率的叙事里。源头是[投资人版概要设计](../_archive/系统概要设计-投资人版.md)(文档编号 HJ-ARCH-002)。

### 7.1 一句话:技术资本效率

绘境AI 的核心打法是**把别人烧钱自研的部分用开源组合替掉,把省下的钱投到竞品的最大空白——流量和变现上**。同等功能,绘境AI 的技术投入约为头部自研竞品的 1/5,时间约为 1/3。

| 能力 | 竞品做法 | 绘境AI 做法 | 节省 |
|---|---|---|---|
| AI 生成引擎 | 自研(6-12 月,投入千万) | new-api 网关直连通用 LLM + 模板/插件库驱动,数周集成 | 约 80% 时间和成本 |
| 后台管理系统 | 自建(3-6 月) | Huijing Cloud 开源二次开发,60%+ 能力开箱即用 | 约 3 个月 |
| 工作流 / 审核 | 自建 | Flowable 工作流引擎(Huijing 内置) | 零开发成本 |
| 多模型切换 | 绑定单一供应商 | new-api 网关原生支持多 LLM 热切换 | 零锁定风险 |
| 游戏运行时 | 自研重型引擎 | LittleJS 增强发行版(Tier1)+ Cocos Creator(远期) | 零许可费 |

### 7.2 MVP 阶段月度成本:¥4,300/月

整个 MVP 跑起来一个月只要 **¥4,300**(年化约 5 万)。这也是 §4.2 那条"覆盖基建需 1.33 万 DAU"结论里的成本基数。

| 项目 | 月费 | 说明 |
|---|---|---|
| 云服务器 | ¥2,400 | 3 台 4C16G(业务[含轻量档进程内编排] + new-api 网关 + 中间件;图片/音乐及生成 LLM 走外部 API,不占自建算力) |
| 数据库 | ¥400 | MySQL RDS |
| 对象存储 + CDN | ¥300 | 游戏包 / 素材 / 封面 |
| LLM API | ¥1,000 | 约 10,000 次生成/月 |
| 其他(域名/SSL/短信) | ¥200 | — |
| **合计** | **¥4,300/月** | 年化约 5 万 |

> 这里的进程内编排指**轻量档生成主线的现存实现 SAA**(Spring AI Alibaba,后端进程内的 AI 编排框架),用它的 StateGraph 编排生成流程、跑在业务进程内,无需额外部署独立编排服务,所以不占新增机器成本。生成框架已于 2026-06-25 收敛到 AgentScope、SAA 降为最低优先级;tier2 富游戏档的 AgentScope 是独立 Python service(另算,不在这三台的进程内编排里),本行成本只覆盖轻量档的进程内编排。

**这张 ¥4,300/月 的表算的是"跑 demo 的账",不是"真实经营的账"——真实上线要补一批它漏掉的成本(创始人 2026-06-22 历史回收判定捡回)。** 三向审计早就点名这张表系统性低估了真实经营成本。漏掉的有两类。第一类是**直接漏算的运营开销**,真实经营时都会发生、却没进表:

- **GPU 算力**——图片/音乐这类素材生成的 GPU 开销。现在 ComfyUI 未部署、零数据,所以表里是空的;一旦素材生成真跑起来,这是真正可能咬人的一项(§3 已点名)。
- **审核 API**——阿里云内容安全是按调用量收费的,成本随产能线性涨。这张表压根没算它,而[审核台运营](审核台运营.md)§5.2 已明确"放量前要把审核 API 成本单列进成本台账",否则单位经济测算偏乐观。
- **WAF 高防**——Web 应用防火墙 + DDoS 高防(阿里云/Cloudflare),技术决策版明确写了是"上线前"必须接的安全防护成本,尤其开公网前。
- **短信验证码**——表里"其他"那 ¥200 含了短信,但只是个占位估值;真切到真实短信渠道、有了限频防护与真实发送量后,要按实际量重核(防短信轰炸的滥用成本另见[变现端到端]资金红线一脉)。
- **支付通道费**——广告分成提现、内购收单都有第三方通道费率,这部分在表里完全没体现。

第二类是**全成本测算 v2 里有意排除、但规模化时要补回的成本**:税费、渠道 T+N 结算账期带来的资金占用成本、对账差与坏账。这三项模型保守起见没纳入是对的,但"它们是被有意排除、规模化与融资测算时要单列补回"这层边界声明不能丢——渠道结算有 T+N 账期会占用现金流,广告分成有对账差和坏账风险,真实经营里都会咬人。少了这句声明,容易让人误以为成本已经算全了。

这张表适合讲"种子期跑 demo 要花多少";对外做融资或单位经济测算时,必须把上面这两类成本补进去重算,否则真实上线成本被系统性低估。

### 7.3 团队与 Runway

MVP 阶段 **5 人核心团队**(2 后端 + 1 前端 + 1 AI/生成 + 1 产品运营),年人力成本约 150-214 万。以种子轮 3000 万计算,**Runway(资金可支撑的时长)为 18-24 个月**。团队的演进路径是:

```mermaid
flowchart LR
  A["MVP 阶段 · 5 人<br/>2 后端 + 1 前端<br/>1 AI + 1 产品运营"] --> B["增长期 · 15 人<br/>补齐设计 / 安全 / 数据 / 测试"]
  B --> C["规模期 · 30-50 人<br/>分拆为<br/>创作 / 分发 / 变现 / 平台 四团队"]
```

> **结论(资本效率)**:5 人团队 + ¥4,300/月基础设施 + 11 周做出 MVP,先验证核心假设(生成成功率 ≥80%、信息流首屏 P75 < 3s、当天创作当天有收益的闭环),再按数据加人。所有核心组件都是开源/可替换的,没有单点供应商锁定。

---

## 8. 关键指针

本页只承载结论与口径。落地细节、决策史、数字明细分别去这些地方:

| 你要找 | 去哪里 |
|---|---|
| 单位经济的全部敏感性数字(各档 eCPM、回本 DAU、提现可达性、成本结构明细) | `docs/mvp/单位经济敏感性模型.md` |
| 变现链路的工程落地(模块、状态机、契约) | `.agents/skills/`(`staging-ops` / `add-business-module`) |
| 契约与数据库迁移 | `contracts/api-schemas/{ad,trade}.yaml`;迁移 V6(ad)/ V7(trade)/ V14(M4 的 `transfer_ref`)/ V21(订阅与赋余额三表);**Flyway 现行最高 = V25,新增 ALTER(如给 `game_trade_income.game_id` 加列)须用 V26**——版本号易过时,落地前以迁移目录 `game-cloud/huijing-server/src/main/resources/db/migration/` 实时核对为准 |
| 成本台账工具 | `docs/agent-specs/2026-06-09-agent-loop-v1/orchestrator/{newapi_cost.py, report.py}` |
| 商业定位与竞争战略 | [商业定位](../产品/商业定位.md) |
| 完整技术资本效率叙事 | [投资人版概要设计](../_archive/系统概要设计-投资人版.md) |

> **加列纪律(给后端):** 给已有表加列必须 `NOT NULL DEFAULT 0`(不进唯一键、兼容存量行);全仓零外键,数据归属隔离靠 Mapper 的 `WHERE` 条件加 `getLoginUserId()`,不靠 `@DataPermission`。同一列在多个副本间必须字节一致,禁止出现第三个副本(V7 残留三副本是反面教材)。