games-development-ai/docs/architecture/架构/生成引擎/数据飞轮.md

topic, canonical, date

topic	canonical	date
数据飞轮-数据护城河	true	2026-06-24

数据飞轮:生成侧的护城河机制

🚧 设计稿 · 待落地 —— 创始人 2026-06-21 立位、README §10 挂出的"数据飞轮生成侧落点"的正式设计。三条飞轮有先后依赖:溯源链 + 同款创作先落,资产市场依赖素材中心与支付,收益回流依赖数据线成型。代码执行归 Mac,前端入口与 admin 落点随本稿一并定。

绘境AI 的护城河叙事里反复出现一句话:生成引擎本身不是壁垒,大模型迟早追上,真正搬不走的是数据、网络效应、资产、合规这四层。但这四层落到生成侧,一直只有口号没有工程。生成主线这半年把精力放在把 Tier0 一句话产线焊稳上,镜头收窄到当下产线后,这些机制虽然在 HJ-GEN-001 意图基线里被创始人亲拍过"全采纳",却没有进任何现行架构档。这份设计把它们补回来——它们不是新发明,是欠的账。

护城河的三层(资产沉淀、网络效应、数据回流)在生成侧对应三条互相咬合的飞轮:玩家在信息流里看到一款游戏,一键"做个同款",生成时带上血缘,把消费侧的流量导回创作侧;创作者反复生成时沉淀下来的素材、配置、玩法骨架,长成可检索可复用可流通的资产层;生成全过程的数据加上线上真实的收益与留存,回流成训练语料,反过来抬升生成质量与商业化判断。三条飞轮转起来,平台就有了竞品复制不了的东西——不是更强的模型,而是越积越厚的血缘网络、资产库和真实收益信号。

---

1. 现状与缺口:这三条飞轮现在缺什么

设计要落在现状上,所以先核清这三条飞轮当前在库里有什么、缺什么。

溯源链——契约层零血缘,产品层 P-FED-12 还压在 P1。 翻遍 contracts/agent-loop/source-project.schema.json 和 contracts/events.schema.json,跨游戏的血缘字段一个都没有(grep lineage/origin/parent/remix 零命中)。后端 game_aigc_task 表里有一个 retry_of 列,但那记的是"同一款游戏的某次重生成"的血缘,不是"玩家 A 照着创作者 B 的游戏做了个新游戏"这种跨项目派生。game_source_project.base_version_id 记的也只是 modify/extend 在同一款游戏内的版本血缘。所以"这款游戏是谁的同款、原作是哪一款、原作者是谁"这条信息,当前在库里完全无处落脚。产品侧,P-FED-12 同款创作跳转工作坊 在现行 Doc A(docs/architecture/产品/需求清单.md)里仍标 P1 · 来源 demo,RTM(需求模块映射.md)也只登记了它到 studio 模块的映射、没标 P0;两次历史审计(三向审计、demo 审计)都建议它升 P0,理由是它是玩家流量导回创作供给的唯一杠杆、网络效应飞轮的关键一环,但这个建议至今没落进 Doc A。创始人 2026-06-21 定了这条飞轮先落——但"先做设计与接缝"不等于"P-FED-12 已是 P0":升 P0 要走 RTM 同步改 Doc A 的优先级,前端档也明示优先级调整另走评审。P-FED-12 已由创始人 2026-06-22 拍板升 P0、Doc A 已改(见开放问题#6);本稿做溯源链的设计接缝。

好消息是地基不空:生成入口的三条路由 /studio/{create,modify,extend} 已经建好(AppStudioController),feed 卡片、试玩页都已经在跑,game_feed_interact_log 已有点赞/收藏/分享/举报四种互动埋点。同款创作要补的是"从 feed 卡片发起一次带血缘的 create",链路两端都现成,缺的是中间那段血缘的记录与回放。

资产市场——素材库刚建好,市场化的授权与分成还没有。 game_material 表是 V24 才建的创作者私有素材库:按 creator_user_id 归属隔离,category 冻结成 sprite/character/effect/scene/ui/music 六类,字节存储归 infra 的 FileApi、表里只登记引用。这是资产沉淀层的第一块砖,但它现在是私有的、不可检索流通的——没有跨创作者的素材货架、没有授权范围标记、没有采购与分成。产品侧 P-MAT 整组(浏览授权库、UGC 孵化库、选用加入草稿、授权采购、查看分成规则、版权声明)全是 P1、标注 demo/v2.0,是显式的远期。要把私有素材库升级成资产市场,缺两样东西:一是素材契约 P-MAT 把素材的授权类型、锁风标签、分成规则结构化(这是素材中心模块的活,不是生成侧能单独做的);二是授权采购要走支付与分成,而玩家自助掏钱这条线当前是断的:huijing-module-pay 当前只暴露了 PayWalletApi 的 addWalletBalance/getOrCreateWallet(钱包余额操作,不是收单),真正的支付订单充值收单(微信/支付宝)还没接进 game 业务,trade 侧也只有 admin 手动赋余额。所以资产市场天然排在"素材中心建成 + 支付真实化"之后。这三条线(钱包余额 API / 支付订单充值收单 API / trade 入账)的区分见 §3.2。

收益回流——进化语料只覆盖了生成侧自增强,漏了收益这一半,且收益侧的 join 键还不成立。 现行设计里有一条"进化语料半自动萃取品类模板"(见设计合理性裁决改动六),但它学的是"生成侧怎么把游戏做对"——从成功的生成产物里抽 Debug Skill、Template Skill。它没有覆盖更宽的那一半:线上真实的收益与留存数据,回流去校准"生成什么更容易赚钱"。 而这一半的数据现状是:生成侧的数据确实在库里(game_aigc_task.trace_json 是九门轨迹账本、readiness_score 是就绪分,game_source_project.source_json 是源工件),但收益侧和留存侧并不是拿来即用的:game_trade_income 当前没有 game_id 列(它只有 source/source_ref/gross/share_rate/net/settle_date,source_ref 指广告收入单或打赏单,要把分账金额追溯到具体哪一款游戏,得先把 game_id 透传进这条入账链——这正是变现与单位经济 §"按游戏粒度的成本/收益埋点"写明的待建 W4 四步链:契约 ad.yaml 加字段 + DTO 加 gameId + 数据库 ALTER 加列 + recordIncome 透传,缺一即断);game_telemetry_game_stat 也没有次留/留存字段(它只有 play_count/play_end_count/completed_count/total_duration_ms/like_count/favorite_count,要拿"次留"得先定义留存口径并新增聚合)。所以"某款游戏从生成到赚钱"这条全过程,现在没有一张表能按统一 schema 串起来当训练语料——不只是没归档,连最关键的两个连接键(收益→game_id、留存口径)都还没建。这两个前置补齐之前,收益回流标"待前置数据补齐",不是已能实现。而 agentic 集成架构已经为归档载体预留了一个立位:contracts/trace/ 那个"还没建、随控制面 phase-1 落地"的统一轨迹契约类。收益回流不该另起炉灶,它就是这条轨迹契约向收益侧的延伸(前提是上面两个连接键先补上)。

三条缺口有个共同点:机制都被想过、被创始人采纳过,但收窄到 Tier0 当下产线时丢了。现在按创始人定的"三条全做"补回来,落地有先后,§4 单列分期。

---

2. 设计目标

三条飞轮各自要做成什么样,决定了后面的数据模型和接口。

溯源链要做成一张可追溯、防滥用的血缘网络。 任意一款由"做同款"产生的游戏,都能查到它的直接原作(parent)和原作者;试玩页能展示"改编自 XX 的作品";血缘要能防刷——不能让人靠批量刷同款污染原作者的派生数,也不能让血缘链无限深导致归因混乱。血缘是后面资产市场分成、网络效应度量、原创激励的共同地基,所以它要先于另外两条落,且字段要一次设计到位。

资产市场要做成可检索、可复用、可流通、权利链清晰的资产层。 创作者的私有素材库能升级成跨创作者可浏览的货架;每个素材带清晰的授权范围、锁风标签、分成规则;选用别人的素材进自己的草稿要走授权采购,采购产生的收益按分成规则结算给素材作者。它的工程边界是:素材的结构化、授权类型属于素材中心模块,流通的钱走 trade 模块,生成侧只负责"把选用的素材透传进生成上下文"并在血缘里记下素材来源。

收益回流要做成统一 schema 的训练与评估语料,把生成数据和线上结果串成一条数据线。 把生成全过程数据(输入/中间产物/九门裁决/就绪分)和线上数据(播放/留存/收益)按一张统一 schema 归档,供三个下游消费:校准 Template/Debug Skill 的"哪些品类骨架更容易过门"、校准推荐排序的"哪些游戏更容易留住玩家"、未来自训小模型的"生成什么更容易赚钱"。它要复用 agentic 集成架构的统一 trace 契约,不重复造数据管线。

三条共享一条总原则:不重写任何主干,全部 additive。 血缘是源项目 schema 的新增可选顶层字段加一张新血缘表;资产市场复用 game_material 加 trade 的入账原语;收益回流复用已有的 trace_json/trade_income/game_stat,只新增一层归档。任何一条都不动 GamePackage 产物 schema、不动九门、不动现有发布链。

---

3. 方案

3.1 溯源链:血缘怎么记、怎么防滥用

血缘的数据落点分两处,各管一段,职责不重叠。

源侧(可维护层)记"派生意图"。 现状:source-project.schema.json 顶层只有 schemaVersion/sourceHash/buildInputHash/profile/gameDefinition/assets/config,没有 lineage;V18 建的 game_source_project 表也没有跨游戏血缘列(只有 base_version_id 记同一款游戏内的 modify 版本血缘)。本设计在 schema 顶层新增一个可选字段 lineage,描述这份源项目派生自谁。它是 additive 的——schema 仍是 additionalProperties:false,新增一个已声明的可选属性不破坏存量,首次原创生成(无父)就不带这个字段。结构如下:

"lineage": {
  "type": "object",
  "description": "派生血缘:本源项目做同款自哪一款。原创生成不带此字段。",
  "required": ["parentGameId", "originGameId", "depth"],
  "additionalProperties": false,
  "properties": {
    "parentGameId":   { "type": "string", "description": "直接父游戏的 gameId(玩家照着哪一款做的)" },
    "parentVersionId":{ "type": "string", "description": "父游戏被同款时的生效版本(快照锚点,防父游戏后续改版影响归因)" },
    "originGameId":   { "type": "string", "description": "血缘链根游戏(同款的同款,根永远指向最初原作)" },
    "originCreatorId":{ "type": "string", "description": "根游戏的原作者 userId(用于原创激励与展示)" },
    "depth":          { "type": "integer", "minimum": 1, "maximum": 10, "description": "派生深度=min(真实链深, 10):原作直接同款=1 逐层+1,真实链深超 10 后恒为 10(截顶,见防滥用第一道)" },
    "assetRefs":      { "type": "array", "items": { "type": "string" }, "description": "本款复用的素材 materialId(为资产市场分成预留字段;仅当本次创作走了选素材通道才有值,同款本身不自动填,默认空数组)" }
  }
}

这里两个设计选择要解释。第一,同时记直接父(parent)和血缘根(origin),而不是只记父。只记父的话,要算"这条链最初的原作是谁"得递归回溯,既慢又容易因为中间某款游戏被删而断链;直接把 origin 冗余进来,展示原作、给原作者归因、算"某原作总共衍生了多少款"都是一次查询的事。origin 在生成时由父的 lineage 直接继承(父有 lineage 就取父的 origin,父没有就说明父是原作、origin=父),不需要回溯。第二,记 parentVersionId 快照锚点:玩家做同款时父游戏是某个版本,父游戏后续可能改版甚至下架,血缘要锚在做同款那一刻的版本上,归因才稳定。

派生关系表(归因层)记"可查询的血缘边"。 源侧的 lineage 是嵌在源 JSON 里的,适合构建时携带,但不适合做"查某款游戏的所有同款"这种反向查询。所以另立一张轻量的血缘边表 game_lineage_edge,在源项目落库成功、拿到新游戏的 gameId 后写一条边:

列	说明
id	主键
child_game_id	派生出的新游戏 gameId
child_creator_id	派生者 userId(去重派生声誉的聚合键,见下文防滥用第三道)
parent_game_id	直接父游戏 gameId
parent_version_id	父被同款时的版本快照
origin_game_id	血缘根游戏
origin_creator_id	根原作者 userId
depth	派生深度
status	血缘边状态:0 pending(源已落库、边已建但未激活)/ 1 active(同款已过九门且发布/审核通过)/ 2 voided(同款被弃用/下架后失活)
source	派生方式:1 feed 同款 / 2 资产复用(预留)
审计列 + uk_child(child_game_id, deleted, tenant_id)	一款游戏只有一条出生血缘
索引 idx_origin_creator(origin_game_id, child_creator_id)	支撑"被 N 个独立创作者做了同款"的去重聚合

这张表是软关联(无物理外键,遵全平台惯例),uk_child 保证一款派生游戏只有一条血缘边、写入幂等(补偿重试命中唯一键即更新 status,不插重复行)。有了它,"查 X 的所有直接同款"、"查 X 作为根衍生了多少款"、"查某创作者的作品被多少个独立创作者做了同款"都是索引查询。

血缘边的写入与激活时机(关键,避免坏同款污染网络)。 边不是源落库后立刻就生效。源落库拿到新 gameId 后,先写一条 status=0 pending 的边(此刻只是占位、不进任何对外的派生统计);等这款同款游戏走完构建、过了九门、且发布或审核通过,才把边翻成 status=1 active,这时它才计入原作者的派生数、才在试玩页对外展示溯源。如果同款没过九门、被弃用或下架,边停在 pending 或转 voided,坏同款进不了血缘网络。uk_child 唯一键让"激活"这个动作天然幂等:补偿重试时命中唯一键就更新 status,不会插出第二条边。这条把"边在源落库后建"和"九门不过不算数"两件事用状态机协调起来——边先建是为了拿到 child_game_id 这个写入锚点,激活后置是为了不让没过门的游戏污染归因。

溯源链的 contract-first 清单(全是新契约面,实现前先落契约)。 这条飞轮新增的跨端契约与落库项集中列在这里,缺一即断:

契约面	改动	兼容策略
contracts/agent-loop/source-project.schema.json	顶层新增可选 lineage 对象(parentGameId/parentVersionId/originGameId/originCreatorId/depth/assetRefs)	additive:可选属性、不破 additionalProperties:false、原创生成不带;schemaVersion 是否随之升(见 §5 风险一)与 lineage 一并定(注:gameDefinition 路已废、廉价线现行 A-model 真 src/,无 gamedef→src 迁移待协调)
contracts/api-schemas/studio.yaml	StudioCreateReqVO 新增可选 remixFrom(父 gameId);新增血缘回放查询接口(查某游戏的直接同款列表 / 查某游戏作为根的派生计数 / 查某创作者作品被同款的去重创作者数)	additive:remixFrom 缺省=普通原创生成,老调用不传不受影响
Flyway 迁移	新建 game_lineage_edge 表(列见上表,含 child_creator_id、status、idx_origin_creator);版本号取迁移目录当前最高 +1(变现 W4 已占 V26 规划位,落地前以 game-cloud/huijing-server/src/main/resources/db/migration/ 实时核对、顺延取下一个空位)	纯新建表,不改存量表;软关联无外键
VO/DTO	StudioCreateReqVO 加 remixFrom 字段 + 血缘回放响应 VO	additive
DO/Mapper	GameLineageEdgeDO + Mapper(写边 / 激活 / 去重聚合查询)	新增,不动现有 DO
events.schema.json	新增 remix_click / remix_submit 事件(见 §3.1 末漏斗埋点)	additive:新事件名,老消费者忽略未知事件

防滥用,分三道。 血缘一旦和原创激励、派生数排行挂钩,就会被刷,所以从一开始就要把闸门设进去:

• 深度封顶 + 根锚定。 depth 的语义是 min(真实链深, 10):真实链深在 10 以内时逐层 +1,超过 10 之后 depth 恒为 10(截顶),但 parentGameId 仍记真实父、originGameId 仍锚最初原作。截顶只压 depth 这个展示/计数用的数字,不改变父子与根的真实指向。这避免有人靠制造超深链来稀释或冒充归因。验收口径见 §5(未到上限区间严格递增、到上限后恒为 10)。
• 同款产能受生成控制平面 D12 的配额与并发管,但 D12 当前的边界要看准。 做同款走的就是一次 create 生成,会过 D12 生成控制平面。D12 现在覆盖的是 per-creator×level 的当日配额、并发、背压、降级、记账骨架(见 agentic 集成架构 §71),它没有 prompt-hash 维度的频控——所以"同一句话连刷一百遍命中频控被拦"这种能力,D12 现在并不提供,别把它当现成依靠。更关键的是 D12 默认关闭、开闸前 off(零行为变更进主干,开闸时创始人才显式打开)。这带来一个真实空窗:如果溯源链阶段一先于开闸上线,那段时间 D12 不生效,生成入口的配额/并发限流等于不存在,血缘层不能把防刷全甩给 D12。空窗兜底有两条可选——要么阶段一上线时间对齐到 D12 开闸之后,要么在血缘激活侧补一道轻量闸(下文第三道"去重独立创作者数"本身就化解了刷量收益,可作空窗期的主要兜底)。这条要在阶段一落地时明确。
• 派生数排行用"去重独立创作者数"而非"总派生次数"。 给原作者展示"被 N 人做了同款"时,N 取独立 child_creator_id 的去重计数(COUNT(DISTINCT child_creator_id),走 idx_origin_creator(origin_game_id, child_creator_id)),而不是 child 游戏总数。聚合时显式过滤:只统计 status=1 active 的边(排除 pending/voided=排除未过门/未发布/已下架的同款)、排除逻辑删除行(deleted=0)。这样一个人狂刷一百个同款,对原作者的派生声誉只贡献 1,刷量没有收益;没过门或被下架的同款也不计入。这条规则放在查询/聚合层,不污染血缘边表本身(边表如实记录每一条)。

从 feed 到生成的链路(溯源链的产品主路):

sequenceDiagram
  participant U as 玩家(feed 试玩页)
  participant FE as studio 前端
  participant ST as AppStudioController
  participant SAA as SAA 生成工作室
  participant SP as game_source_project
  participant LE as game_lineage_edge

  U->>FE: 点"做同款"(携带 parentGameId)
  FE->>ST: POST /studio/create { remixFrom: parentGameId }
  ST->>ST: 解析父游戏 currentVersion + 父 lineage
  ST->>ST: 组装 lineage(继承 origin / depth+1 / 截顶)
  ST->>SAA: create 生成(注入 lineage;brief 视形态:轻量跳转预填一句话 / 真 remix 带父 gameDefinition,默认前者见 §4)
  SAA->>SP: 源落库(source_json 内嵌 lineage)
  SP-->>ST: 落库成功 → 新 gameId
  ST->>LE: 写血缘边(child=新 gameId, parent, origin, status=pending)
  Note over SAA,LE: 后续构建/九门/发布走既有链,零改;<br/>过九门且发布/审核通过后,边 status→active 才计数与展示

关键点:/studio/create 当前的 StudioCreateReqVO 只有 title/prompt/templateId/assetContext/idempotencyKey,本设计加一个可选入参 remixFrom(父 gameId);controller 在生成前解析父游戏的当前版本和父的 lineage,组装出新的 lineage 注入生成上下文和源项目;血缘边在源落库拿到新 gameId 之后写成 pending(因为 child_game_id 此刻才存在),发布/审核通过后再激活成 active。生成本身完全复用现有的 create 路,SAA 图、九门、发布链一行不改——同款创作对生成引擎来说就是"一次带了血缘元数据和参考 brief 的普通生成"。

试玩页展示溯源。 feed/试玩页读 game_lineage_edge,若当前游戏有 active 血缘边,展示"改编自 [原作标题] · @[原作者]"的溯源条,点击可跳回原作。原作者侧在创作者中心能看到"我的 [作品] 被 N 人做了同款"——这个去重聚合 API 与入口是后端要新建的活(查询走 idx_origin_creator、过滤 active 边),阶段一范围里一并算上,不是顺带就有。这两个展示点是溯源链对用户可见的出口,没有它们血缘就是孤儿数据。

血缘边是软关联、无物理外键,所以要处理父被删的断链:玩家做完同款后,父游戏可能被原作者删掉或下架,这时 parentGameId 指向的目标已不存在(软关联不会报错,但点进去会断链)。降级口径:溯源条仍然展示(originGameId/标题快照可保留),但"改编自 XX"做成不可跳转的灰态,或直接显示"原作已下架"。这样既不丢溯源事实,也不给用户一个点了 404 的死链。同理,若 origin 根游戏被删,展示降级到只显示标题文本、不提供跳转。

网络效应漏斗要有埋点,否则升 P0 的核心 KPI 量不出来。 P-FED-12 升 P0 的理由是它是"玩家流量导回创作供给的唯一杠杆",可这个杠杆的转化率要能度量才能验证它配得上 P0。血缘边只记结果态(谁最终生成了同款),量不出"feed 曝光→点了做同款→真的提交了生成"这条漏斗的衰减——点了做同款但没提交、提交了但生成失败,这些都不会留下血缘边。现状是 events.schema.json(契约⑤)里只有 feed_view/like/favorite/share/report 这类互动事件,没有任何 remix/做同款事件。所以阶段一 additive 新增两个事件:remix_click(在 feed/试玩页点了"做同款",props 带 parentGameId)、remix_submit(真的提交了带 remixFrom 的生成,props 带 parentGameId+新 taskId)。它们与 like/share 同构(走同一条 envelope、同一批量上报通道),老消费者忽略未知事件,零兼容风险。有了这两个事件,"曝光→点同款→提交→生成成功"的漏斗才连得起来,P-FED-12 升 P0 后才有可观测的转化指标。

产品口径(创始人 2026-06-22 已定):同款创作出来的游戏首期纯展示溯源、不对原作者分成(assetRefs 字段为资产市场分成预留,但同款本身不触发),钱的事留到资产市场那条线统一处理。

3.2 资产市场:与素材契约、支付的对接边界

资产市场不是生成侧单独能做的,它横跨素材中心、trade、studio 三个模块。所以这一节先划清边界——生成侧管什么、不管什么——而不是把素材中心和支付的活也揽过来。

flowchart TB
  subgraph MAT["素材中心模块(P-MAT,负责结构化与货架)"]
    M1["game_material 升级<br/>+授权类型 +锁风标签 +分成规则"]
    M2["跨创作者素材货架<br/>(按 IP/类目检索)"]
  end
  subgraph GEN["生成侧(只负责透传与血缘)"]
    G1["asset 上下文注入<br/>选用素材→生成输入"]
    G2["血缘 assetRefs<br/>记本款复用了哪些 materialId"]
  end
  subgraph TRADE["trade 模块(负责钱)"]
    T1["授权采购入账<br/>game_trade_income source=ASSET"]
    T2["分成结算<br/>素材作者按 share_rate 收益"]
  end
  subgraph PAY["支付(硬前置依赖)"]
    P1["真实收单<br/>PayWalletApi 接入 · 当前未接"]
  end
  M1 --> G1
  G1 --> G2
  M2 -->|采购触发| T1
  T1 --> T2
  P1 -.被依赖.-> T1
  style PAY fill:#fee,stroke:#c33
  style GEN fill:#e6ffe6,stroke:#3a3

生成侧的职责只有两件,都很薄。 第一,把创作者选用的素材(无论自己私有库的还是市场买的)透传进生成上下文——这复用的是 P-CRT-04 附件驱动创作那条已有通道,六类资产规格的枚举(sprite/character/effect/scene/ui/music)定义在 source-project.schema.json 的 assetSpec.category(由 asset 节点写入),把"用户选的现成素材"作为输入装配进去即可。第二,在血缘的 assetRefs 里记下本款游戏复用了哪些 materialId。这里要纠正一个容易过度承诺的点:同款创作并不必然选素材——选不选素材走的是 P-CRT-04 的 assetContext 这条正交通道,跟"是不是同款"无关。所以 assetRefs 不是同款创作的自然副产物:它只是为资产市场分成预留的字段,实际归因数据要等创作者真的走了选素材通道才产生。别让阶段二误以为阶段一会自动把分成依据攒好——阶段一攒下的是血缘,素材复用归因要等选素材通道接进来才有。生成侧不做素材的授权类型管理、不做素材货架检索、不做采购支付——那些是素材中心和 trade 的活。

素材契约 P-MAT 是这条线的前置。 要让素材可流通,game_material 得先升级:加授权类型(原创自有/UGC 孵化/授权 IP)、锁风标签、分成规则(素材作者分成比例)、可见范围(私有/公开货架)。这是素材中心模块的设计,本稿只声明依赖、不替它设计。资产市场启动的前提是 P-MAT 这组从 P1 实质落地。

授权采购的分账可复用 trade 入账原语,但收入来源枚举、采购单表都要新建,且整条卡在支付。 先讲现状:trade 的入账原语 recordIncome 已经支持按 source 区分收入类型、用 uk_source(source, source_ref, tenant) 幂等、按 share_rate 算净额——但 game_trade_income.source 当前的枚举只有 1=AD 广告 / 2=TIP 打赏,没有 ASSET。所以资产市场的"买素材→素材作者分成"要复用入账原语,得先补一组新契约面:

• trade 收入来源新增 ASSET 枚举(trade.yaml 的 source enum 从 [1,2] 扩到含 ASSET,game_trade_income.source 注释同步),source_ref 指采购单 id,素材作者按 share_rate 入账,uk_source 天然防重复分账。账户、提现整套现成,不重建。
• 采购单 / 授权单表是新建的:game_material 当前是私有素材登记,没有"谁买了谁的素材、授权范围多大、单价多少"的成交记录。需要新建采购单表(买家 userId / 素材 materialId / 素材作者 / 成交价 / 授权范围 / 状态)作为成交凭证,它的 id 就是上面入账的 source_ref;授权关系(买家对某素材取得了什么范围的使用权)要么并进采购单、要么单列授权单表,由素材中心模块设计定。采购单要有自己的幂等键(同一买家对同一素材的同一次采购不重复扣款)。
• 退款 / 撤权口径要先定:素材被下架、版权争议、买家退款时,已入账的分成怎么冲、买家的授权怎么撤,是带钱的逆向流程,口径要和 trade 的冲正机制对齐(不是简单删行)。这条挂律所与 trade 模块,本稿先标出口径缺口、不替它拍。

还有一道硬墙:真实支付收单没接,而且要区分三条线别混。 玩家自助掏钱买素材,涉及三条不同的线:① 钱包余额操作 API(PayWalletApi.addWalletBalance/getOrCreateWallet,这是已有的,但它只是给钱包加减余额,不产生真实现金流入);② 支付订单充值收单 API(真实微信/支付宝把钱打进来,当前没接进 game 业务);③ trade 入账(分账记账,上面那组)。这三条现在只有①③有地基,②是断的。资产市场的"流通"那一半依赖②——而②受日历闸门约束(支付牌照/二清风险),不是写几行代码能解决的。所以资产市场的流通半物理上排在支付真实化之后,这不是工程优先级选择,是外部闸门决定的。在②接通前,trade 也只有 admin 手动赋余额,没有玩家自助付费这条路。

资产市场的分期落地由此清晰:先有素材契约(P-MAT 升级),并在创作者走选素材通道时用血缘 assetRefs 把"谁用了谁的素材"记起来(注意这要靠选素材通道接入、不是溯源链顺带产出);再等支付接通,才开授权采购与分成。 在支付接通前,资产市场可以先做"只读"的一半——跨创作者素材货架的浏览、选用(免费/自有授权范围内),把流通的钱那一半留到支付就绪。

3.3 收益回流:训练语料的数据管线形态

收益回流做的事,是把散在三个模块的数据按一张统一 schema 归档成训练与评估语料。它复用 agentic 集成架构预留的 contracts/trace/ 统一轨迹契约,向收益侧延伸,不另造管线。

数据三源,生成侧已在库、收益与留存侧的连接键待补。 缺的不只是归档,还有把三源"按一款游戏的生命周期串起来"所需的两个连接键(下图标⚠️处):

flowchart LR
  subgraph 生成侧["生成全过程(已落库)"]
    A1["game_aigc_task<br/>trace_json 九门轨迹<br/>readiness_score 就绪分"]
    A2["game_source_project<br/>source_json + lineage"]
  end
  subgraph 遥测["线上留存(部分落库 · 留存字段待补)"]
    B1["game_telemetry_game_stat<br/>play/end/complete/like/fav ×日<br/>⚠️无次留/留存字段,待定义口径新增"]
  end
  subgraph 变现["真实收益(入账已落 · join 键待补)"]
    C1["game_trade_income<br/>分账后真实入账<br/>⚠️无 game_id 列,待 W4 透传"]
  end
  subgraph 语料["收益回流语料(新增归档层)"]
    D1["统一 schema:<br/>一款游戏 = 生成特征 + 留存信号 + 收益信号"]
  end
  A1 --> D1
  A2 --> D1
  B1 --> D1
  C1 --> D1
  D1 --> E1["Template/Debug Skill 校准<br/>哪些品类骨架更容易过门"]
  D1 --> E2["推荐排序校准<br/>哪些游戏更容易留住玩家"]
  D1 --> E3["未来自训小模型语料<br/>生成什么更容易赚钱"]

归档语料的一条记录,以 gameId 为主键,把三源的特征拼到一起: 生成侧的特征(品类原型 archetype、三维画像、就绪分、九门是否一次过、用了哪个模型档、血缘 depth/origin)、留存信号(次留、完玩率、播放量)、收益信号(该游戏累计广告分账、是否产生过收益)。这张归档表是离线的、append-only 的、按时间窗批量产出的——它不在生成热路径上,由一个离线 job 定期把三源 join 出来落档,所以对线上零影响。但有个现状前提:"以 gameId join 三源"现在还做不到,因为收益侧 game_trade_income 没有 game_id 列(join 不上)、留存侧 game_telemetry_game_stat 没有次留字段(口径还没有)。所以收益回流的前置不只是建归档 job,而是先把 §1 列的两个连接键补上(W4 给 trade_income 加 game_id、定义并新增留存聚合),否则这张归档表能拼出来的只有生成侧特征,收益和留存两列是空的。这条语料要学的是 HJ-GEN-001 GC10 那条——"什么样的生成特征,最终既过了门、又留住了人、又赚到了钱",正是现行进化语料漏掉的那一半,但它的原料(收益、留存的真实标签)依赖前置补齐才存在。

为什么挂在统一 trace 契约下而不是新造。 agentic 集成架构已经定了 contracts/trace/ 要做成"一个公共核心子集 + JSON 扩展列"的统一轨迹,记每次生成发生了什么。收益回流要的"生成全过程特征"和它高度重叠——轨迹本就含九门裁决、成本、就绪分。所以收益回流语料 = 统一 trace 的归档记录 + 一层从 telemetry/trade join 进来的"线上结果标签"。把它实现成 trace 契约的下游归档,而不是平行的第二套数据管线,避免"生成数据存两份、口径漂移"。这条依赖关系决定了收益回流排在统一 trace 契约落地之后——而统一 trace 契约本身是 agentic 集成架构标着"随控制面 phase-1 落地"的待建项。

为什么是数据线(自有端内测)成型后的增量。 收益信号要有意义,得先有真实收益——而真实收益依赖广告真实投放、依赖一定量的真实玩家留存数据。在自有端内测、数据量还小的时候,收益信号稀疏、噪声大,回流语料训不出有用的东西。所以创始人把它定为"数据线成型后的增量"是对的:先让生成跑起来、让玩家玩起来、让广告真实计费,攒够数据,收益回流才有原料。 它是飞轮转起来之后的加速器,不是飞轮的起点。

---

4. 分期落地:先后依赖

创始人定了"三条全做",但落地有硬性的先后依赖,把它们排错(比如把资产市场当 MVP 第一步)会撞上支付闸门和数据稀疏两堵墙。依赖关系和阶段如下图:

flowchart TB
  P1["阶段一 · 溯源链 + 同款创作<br/>取轻量跳转形态时最轻 · 不依赖新支付 · 先落"]
  P2["阶段二 · 资产市场(只读半)<br/>依赖素材契约 P-MAT"]
  P3["阶段三 · 资产市场(流通半)<br/>依赖真实支付收单"]
  P4["阶段四 · 收益回流语料<br/>依赖统一 trace 契约 + 数据线成型"]

  P1 -->|血缘 assetRefs 产出<br/>谁用了谁的素材| P2
  P2 -->|授权采购触发分成| P3
  PMAT["素材中心 P-MAT 升级<br/>(素材中心模块的活)"] -.前置.-> P2
  PAY["支付真实化<br/>(日历闸门)"] -.前置.-> P3
  TRACE["统一 trace 契约<br/>(agentic 集成架构 phase-1)"] -.前置.-> P4
  DATA["数据线成型<br/>(广告真计费 + 留存攒够)"] -.前置.-> P4

  style P1 fill:#e6ffe6,stroke:#3a3
  style PAY fill:#fee,stroke:#c33
  style TRACE fill:#fff7e6,stroke:#d90

阶段一(溯源链 + 同款创作)排在第一步,但"最轻"的前提是同款取轻量跳转形态。 同款的产品形态不先定一个默认值,阶段一的工程量就是浮动的——两种形态工程量差一个量级:一种是轻量跳转——点"做同款"就跳到工作坊、预填一句话 brief(可带原作标题/品类提示),不读父游戏的源项目,生成走的还是普通一句话生成那条已验过的路,只多挂血缘;另一种是真 remix——携带父游戏的 gameDefinition 作生成上下文,让模型基于已有玩法做变体,这要撞上"便宜模型在受约束的变体生成下能不能稳产"这个还没过的 80% 门(见 §5 风险二),工程与验证成本高得多。本稿默认取轻量跳转形态,把真 remix 列为后续(待便宜模型变体能力验过再上)。只有在轻量跳转形态下,阶段一才当得起"最轻":链路两端(feed 卡片、生成路由)都现成,新增项是源 schema 的 lineage 字段、一张 game_lineage_edge 血缘边表、/studio/create 的 remixFrom 入参、试玩页溯源展示、创作者中心"被 N 人做了同款"的去重聚合 API 与入口、以及 remix_click/remix_submit 两个漏斗事件。配套的 P-FED-12 升 P0 已由创始人 2026-06-22 拍板:走 RTM 正式升,Doc A 的 P-FED-12 已由 P1 改 P0(见开放问题#6)。另外,血缘的 assetRefs 不会"顺带"攒出素材复用归因——素材复用要等创作者真的走选素材通道(P-CRT-04)才产生,阶段一攒下的是血缘本身,不是分成依据。

阶段二、三(资产市场)拆成只读半和流通半,被两道前置卡着。 只读半(跨创作者素材货架、浏览、自有授权范围内选用)依赖素材中心 P-MAT 那组把素材结构化、加授权类型——这是素材中心模块的活,生成侧只等它就绪后做薄薄的"选用素材透传"。流通半(授权采购、分成结算)依赖真实支付收单接通,而支付受日历闸门(牌照/二清)约束,物理上做不快。所以资产市场绝不能排进 MVP 第一步——它的前置不是工程量,是外部闸门。

阶段四(收益回流)是数据线成型后的增量。 它被两道前置卡着:统一 trace 契约(agentic 集成架构 phase-1 待建)给它提供"生成全过程"的归档载体;数据线成型(广告真实计费 + 留存数据攒够)给它提供"线上结果标签"的真实原料。在数据稀疏期它训不出东西,所以它排在最后,作为飞轮转起来之后的加速器。

三条的排序是真实的物理约束,不是优先级偏好:溯源链先落(取轻量跳转形态时轻、自足);资产市场等素材契约和支付(被外部闸门卡);收益回流等数据线、连接键和 trace 契约(被原料、join 键和载体卡)。

---

5. 验收与风险

怎么算做对了,分阶段给判据。

阶段一(溯源链):从 feed 任一卡片点"做同款",能生成一款新游戏,且新游戏的源项目带 lineage、血缘边表有对应记录(初始 pending、过九门发布后转 active)、origin 正确继承到最初原作;depth 判据=未到上限的区间严格递增(原作直接同款=1 逐层 +1)、真实链深超 10 后恒为上限 10(截顶生效);试玩页能展示"改编自 XX",父被删时降级为不可跳/"原作已下架"不出死链;原作者侧能看到被同款的去重创作者数(只数 active 边、排除逻辑删除);批量刷同款时原作者的派生声誉数不被刷量污染(去重计数生效);remix_click/remix_submit 漏斗事件正确上报。生成入口配额生效一条要分情况:若 D12 已开闸则验配额拦截,若阶段一在 D12 开闸前上线则改验空窗兜底(去重计数化解刷量收益)。这些都是确定性可验的。

阶段二、三(资产市场):跨创作者素材货架可检索;选用市场素材进草稿、透传进生成、血缘 assetRefs 正确记录;支付接通后,授权采购走 trade 入账、素材作者按分成比例收到余额、uk_source 幂等不重复分账、账户恒等式 balance+frozen+total_withdraw=total_income 不破。

阶段四(收益回流):前置先验——game_trade_income.game_id 已透传(W4 四步链落地)、留存口径已定义并有聚合字段、统一 trace 契约已落地,这三者齐了 join 才成立;在此之上,归档 job 能把生成特征+留存+收益按 gameId join 成语料、离线产出对线上零影响;语料能喂给 Template/Debug Skill 校准与推荐排序;归档复用统一 trace 契约、不存第二份生成数据。

风险集中在四处。

第一,血缘字段加在还在 1.0 的源 schema 上。源项目 schema 当前是 schemaVersion: const "1.0",加 lineage 是 additive(可选属性、不破 additionalProperties:false),但要确认是否需要随之升版本号——如果升,要同步两端读取方(Java 落库侧、引擎适配器消费侧)和 CI 一致性校验。这块要和正在进行的 gameDefinition→src/ 终态迁移协调,别和那条线的 schema 改动撞车。

第二,同款创作的生成质量与归因可信度耦合。如果同款生成出来的游戏质量很差(便宜模型在"基于父玩法做变体"这种约束下能不能稳定产出还没验证),会反噬原作者声誉——"被做了一堆烂同款"。所以同款生成同样要过九门:血缘边在源落库时先建成 pending,只有过了九门且发布/审核通过才激活成 active、才计入派生数与对外展示,过不了门的同款边停在 pending/voided,坏同款进不了血缘网络(机制见 §3.1 血缘边激活时机)。这条和生成主线 80% 成功率门是同一道闸。

第三,资产市场的法务口径(派生授权)挂律所通道。素材复用、IP 派生涉及著作权,"用了授权 IP 素材做的游戏能不能商用、分成怎么算"是法务问题,不是工程能拍的。这条要等律所意见,工程侧先把归因数据(assetRefs、分成规则字段)备好,口径留空。

第四,收益回流的隐私与合规边界。把玩家留存、收益数据回流成训练语料,要确认数据脱敏口径(语料里不能带玩家个人身份信息),这条对齐 agentic 集成架构里 trace 契约的脱敏规则,不另立。

---

6. 开放问题(留给创始人拍板)

1. 同款创作要不要对原作者收益分成?(创始人 2026-06-22 已定:首期不分成) 首期纯展示溯源、不对原作者分成(类似"致敬"而非"翻唱分成"),素材 / IP 的分成统一留到资产市场那条线。已拍板,阶段一不接同款分成、保持最轻。

2. 同款的产品形态——本稿默认取轻量跳转,确认是否接受、真 remix 何时上。 两种形态:轻量跳转(跳工作坊预填一句话 brief、不读父源项目,实现轻、但"同款"相似度弱)和真 remix(携带父游戏 gameDefinition 作生成上下文做变体,血缘与复用关系强、但要撞便宜模型受约束变体生成那个还没过的 80% 门)。§4 已默认取轻量跳转、把真 remix 列后续,据此 lineage 阶段一不携带父 gameDefinition。需要创始人确认:是否接受首期只做轻量跳转的弱相似度同款,真 remix 是否等便宜模型变体能力验过(W-G1 之后)再排期。

3. 派生深度上限定多少、超限怎么处理? 本稿建议 depth 上限 10、depth=min(真实链深,10)(超限只把 depth 数字截在 10,parent 仍记真实父、origin 仍锚根,不改父子与根的真实指向)。需要确认的是这个上限值、以及"超限后是拒绝同款还是允许但 depth 不再加深"——拒绝更干净但会卡住合理的深层创作,允许但截顶更宽容但 depth 这个数字会失真(虽不影响 parent/origin 的真实性)。

4. 资产市场的"只读半"在支付接通前能不能先上? 跨创作者素材货架浏览、自有授权范围内选用(免费)这一半不依赖支付,可以先于支付落地、先把资产沉淀和复用习惯养起来。但这要确认产品上是否接受"能浏览能选用、暂不能买卖"的中间态,还是要等支付齐了一次性推出完整市场。

5. 收益回流语料的归属与使用授权。 把创作者的生成数据、玩家的留存数据用作训练语料,需要在用户协议层面拿到授权(尤其未来用于自训小模型)。这条是产品/法务口径,工程上随 trace 脱敏规则走,但"能不能用、怎么告知用户"要创始人和律所定。

6. P-FED-12 正式升 P0(创始人 2026-06-22 已定:走 RTM 升 P0)。 创始人拍板正式升 P0:Doc A(产品/需求清单.md)的 P-FED-12 已由 P1 改 P0,前端档 §7.3 口径校准同步。阶段一据此按 P0 核心功能投入。注:升 P0 使 P0 总数 55→56,全局"55 P0"口径(AGENTS / knowledge)待同步。