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

变现与单位经济

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

---

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

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

具体拆成三道硬边界:

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

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

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

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

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,已合入主干)。

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 的整套技术哲学是用开源生态组合而非烧钱自研(详见投资人版概要设计),把钱省下来花在竞品做不了的事上——游戏流分发和变现闭环。这一节回答"那生成一款游戏到底花多少钱"。

结论先行:文本生成根本不是成本瓶颈。 ¥0.031 是旧填参路径(LLM 填参)的文本 token 下界实测值(merge-prod-20 这一批 20 个创意、57 次调用、19 个被采纳的实测口径,单次 LLM 调用约 ¥0.0103)。注意 2026-06-12 创始人拍板「模板=引擎能力插件、每款游戏=agent 写码、填参主线作废」后,当前主线单款成本改按分档工程预算 L1-agentic P75≤¥0.15/款【假设·待 W-G1 实测】(约旧值 4.8 倍),不要把 ¥0.031 误读为当前主线现价。即便按 ¥0.15 的新口径,单款也远不到 1 元。真正可能咬人的成本是图片/音乐这类素材生成的 GPU 开销(目前 ComfyUI 未部署,零数据)和人工审核兜底,这两项列为后续单位经济埋点(内部代号 W4,即按游戏粒度的成本/收益数据回路)的测量项。

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

• 谁是权威源。 成本数据直读 new-api 的 PostgreSQL 日志表 logs.quota,因为里面含每个模型的真实计费倍率(new-api 的计费引擎已经算好)。客户端用 token 数自己估算的那套(llm_client.py)降级为 fallback 和交叉校验,不再作为权威。读取工具是 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 区间,低置信。

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

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

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

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

4.3 三个假设值的红线

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

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

---

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

这一节从投资人尽调的角度收口——把上面的单位经济放进整体资本效率的叙事里。源头是投资人版概要设计(文档编号 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(业务[含 SAA 进程内编排] + 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 编排生成流程,无需额外部署独立的编排服务,所以不占新增机器成本。

7.3 团队与 Runway

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

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}
商业定位与竞争战略	商业定位
完整技术资本效率叙事	投资人版概要设计

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