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 归档,供下游消费:校准品类资产(few-shot / skill 数值锚 / 脚手架)的"哪些品类骨架更容易过门又留得住人"、给质量模型出 rubric 档位观测线与 D11 权重的修订提案、为推荐排序产出建议信号(算法与 quality_score 机制不动)、以及远期自训小模型的"生成什么更容易赚钱"。它要复用 agentic 集成架构的统一 trace 契约,不重复造数据管线;从语料到资产的机制(校准单)见 §3.3。

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

---

3. 方案

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

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

源侧(可维护层)记"派生意图"。 现状:source-project.schema.json 顶层(现行 schemaVersion: const "2.0" = A-model 多文件源工件)是 schemaVersion/sourceHash/buildInputHash/profile/files/entry/globalName/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 带父源工程 src/,默认前者见 §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/ 统一轨迹契约,向收益侧延伸,不另造管线。后半环管改进:从语料里学出赢家模式,经人审治理固化回设计资产,再用验证窗口证明改动没变差——回流单元叫「校准单」,机制于 2026-07-02 随回流环设计折入本节(创始人决策包⑦已批准、草案值生效;机制推理与评审史见 docs/agent-specs/2026-07-02-数据飞轮回流环-设计.md)。缺后半环的后果很具体:品类四件套(设计 skill / 脚手架 / few-shot / rubric)与质量模型的档位观测线、D11 就绪分权重,上线之日就是冻结之日——飞轮只进数据、不出改进,资产层就不是「越积越厚」而是静态存量。

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

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["品类资产校准(去向①②③)<br/>few-shot / skill 数值锚 / 脚手架"]
  D1 --> E4["质量模型修订提案(去向④⑤)<br/>rubric·档位观测线 / D11 权重"]
  D1 --> E2["推荐排序建议信号(去向⑥)<br/>算法与 quality_score 机制不动"]
  D1 --> E3["远期自训小模型语料<br/>生成什么更容易赚钱"]

归档语料的一条记录,以 gameId 为主键,把三源的特征拼到一起: 生成侧的特征(品类原型 archetype、三维画像、就绪分、九门是否一次过、用了哪个模型档、血缘 depth/origin)、rubric 三分组小计(L2 丰富 / L3 留存结构 / L4 传播结构,已随评分尺 v2 落库,commit ba82e63c)、留存信号(次留、完玩率、播放量)、收益信号(该游戏累计广告分账、是否产生过收益)、成本维(单款生成成本,供 D11 efficiency 维复核)。这张归档表是离线的、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 落地"的待建项。

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

从语料到资产:回流半环与校准单

上面的语料解决"数据怎么串成一条",回流半环解决"语料怎么变成资产的改进"——谁在什么节奏下做分析、赢家怎么定义、分析结果能改动哪些资产、改动谁批准、改坏了怎么退。回流半环的原子动作是校准单:一张单 = 一次"从数据到提案"的完整闭环,按触发、输入、分析、产出、治理、验证六段定义。学出来的永远是人类可读的设计模式(范式、数值锚、正例),固化永远过人审治理门,改完必须在验证窗口对照"同品类未更新款"证明没变差。

触发:放量后按自然月出单——月度节奏管的是治理带宽(人审可持续),不管结论资格;窗口内累计新增 ≥100 款可提前出单,防高产量期积压。低产量期月度单允许只出"观察单"(仅观察、无提案),这是常态不是失败。首单 = 质量模型 SoT(架构/生成引擎/游戏质量与爆火能力.md)的 D5:rubric 分组小计 × 留存真数据相关性 → 档位观测线与 D11 权重复审,含 D11 efficiency 维(BUDGET_RMB 与便宜档实际成本错配)的复核——该项是质量模型交给质量轨的首个复核件,随首单一并做。

输入:回流语料的窗口切片,特征集逐字承接上文归档记录:生成侧特征(品类原型 archetype、三维画像、就绪分、九门是否一次过、模型档、血缘 depth/origin)+ rubric 三分组小计(L2 丰富 / L3 留存结构 / L4 传播结构)+ 留存信号(D1 留存、完玩率)+ 收益信号(累计分账)+ 成本维(单款成本,供 efficiency 复核)。首单暂不消费三维画像与血缘 origin——留作特征库、消费面随后续单扩展,是有意暂缓,不是遗漏。

分析:赢家对照先行、回归其次,不上黑盒;分两层,样本资格各自独立。品类层出品类资产与档位观测线提案:品类内按"D1 留存 + 完玩率"双指标取头部分位(top 20%)为赢家组,对照其余组找特征差;出品类级提案的门槛 = 切片 ≥50 款且赢家组绝对数 ≥10,切片 30–49 款只出描述性观察,不足 30 不出品类结论。全局层出 D11 权重与 rubric 通用底座维度提案:必须按品类分层后再合并(品类内标准化或分层对照),禁止全体裸取头部分位——跨品类留存基线不可比,裸取会让"特征差"实为"品类差";全体窗口 ≥100 款才出全局级结论。放量初期(四品类均分、每品类 ≈25 款)首单大概率只够全局层:结论口径 = 分层合并的方向性结论 + 各品类描述性观察。收益信号在广告真实计费稳定前只作旁证、不作分组依据(稀疏期噪声大,与上文"数据线成型后的增量"同一判断)。这里的样本量是放量后真数据统计的固有要求,与生成侧 spike 验证的 n=5 收敛环(创始人既定口径)是两回事,不冲突。

产出:修订提案,人类可读、逐条给证据(特征差数据 + 建议改动 + 预期影响),绝不直接改资产;提案对象限于下面的六去向清单。治理:按去向分级过门,所有资产更新走 git(版本化、可 revert)。验证:每次更新绑定验证窗口,对照与判据都成立才算数。对照基线 = 同品类的存量未更新款:资产更新只作用于新生成款,存量款天然是对照组;跨窗品类曝光配比或玩家来源发生显著变化时,结论降级为观察;相邻未更新品类作旁证。判据分两类:即时判据(过门率、rubric 分布)在下一窗口坐实;滞后判据(留存)因"发布→玩→次日→聚合"的物理延迟,允许跨一个窗口延后坐实——坐实前该更新标"观察期",观察期内不对同一去向追加变更。劣化即 revert 并在下一张单记因;改进主张只有过了验证窗口才算坐实,校准单自身不宣称成功。

校准单的产出去向限定六类、三种性质,权责不同:

去向	例子	性质	治理门
① few-shot 过门正例	用赢家款替换品类 few-shot 正例	直接改(低风险)	新正例本身过九门 + 用新正例生成的品类小批 n=3–5 过门率与 rubric 分布不降
② 品类设计 skill 的数值锚与范式权重	客流节奏区间、组合配方偏好、成长曲线锚	直接改(中风险)	Codex+Opus 双评审 + 品类小批复跑
③ 脚手架默认值与结构	_template-* 骨架默认参数、结构件增删	直接改(高风险)	双评审 + 脚手架独立过九门 + 品类小批
④ rubric 维度、档位观测线	某维度与留存零相关 → 重审;线区间锁值	转提案	归质量模型 SoT 管辖:双评审 + 创始人;评分尺变更须金标复验(分组小计漂移 ≤±1)
⑤ D11 就绪分权重	效率维错配、维度权重回归	转提案	校准单提案 + 创始人拍;可整体回退上一版
⑥ 推荐侧建议	品类池配比、新品类扶持建议	建议报告	为推荐排序产出建议信号(算法与 quality_score 机制不动),只产报告交运营

三种性质的分界:①②③是治理后由回流半环直接落改的资产;④⑤只产提案,落地走质量模型 SoT 自己的修订治理;⑥不改任何资产。上文归档图里的消费方向与六去向一一对应——品类资产校准 = ①②③,质量模型修订提案 = ④⑤,推荐排序 = ⑥(只产建议信号,feed 算法与 quality_score 既有回灌机制不动),远期自训小模型语料不经校准单、语料备好即可。金标 play-spec 与验收基准有意不纳入回流面:验收基准若随数据漂移,跨窗可比性与防 Goodhart 的锚都会被破坏;基准变更只能走品类件修订 + 质量模型 SoT 治理,不走数据回流。另有三条并发与时序纪律防污染:同一窗口对同一品类只动一类去向(否则验证窗口归因不了功过);skill / 脚手架 / few-shot 的变更一律走各自既有的过门验收,回流半环不另立验收;品类四件套(W-GENRE)批产收工后才对该品类启动回流校准——批产期与校准期重叠,验证窗口就归因失效。

防学偏(Goodhart)五条。 其一,优化锚永远是真数据(留存 / 完玩,收益作旁证),rubric 分只是特征、不是优化目标——学"什么特征伴随留得住人",不学"怎么把 rubric 分刷高"。其二,固化物永远是人类可读的设计模式(范式描述、数值区间、正例),不是模型参数、不是自动 prompt 改写——每次固化都过人审,审的人看得懂改了什么。其三,质量模型的权力红线不因回流而变:L2–L4 依旧非阻塞,回流半环无权把任何分数升成门,升门动议只能走质量模型 SoT 修订。其四,验证窗口强制:没有"改完即成功",只有"对照组不劣化才算数"。其五,多样性非劣化门:校准单每期附多样性侧写(品类分布 + 品类小批的 AST 相似度,复用既有"多款不雷同"口径),提案采纳的前提是侧写不低于基线(阈值随首单定标);低于基线的提案默认不采纳,创始人显式豁免才放行。侧写与 D9 反同质化互补不重复:D9 观测生成批内相似度(微观、实时),侧写看回流导致的跨窗品类收窄(宏观、慢性)——后者正是"回流环把平台学窄"这个失败模式的探测器。

回流半环启动前,数据面有五项前置,项项有主:

#	前置	现状	归属与工单指针
①	game_trade_income 加 game_id(W4 四步链)	缺列,join 不上	变现线既有挂账(变现与单位经济 §按游戏粒度埋点),即本节前文两连接键之一
②	次留聚合(D1 留存口径)	聚合表无次留	工单已立 = MVP 作战清单 W-REAL R6:初期用旁路聚合表按"game_id × 日"粒度存 D1 回访数,不动既有聚合表结构、quality_score 回灌链路零风险;登录态用 userId,未登录对齐 telemetry 契约既有匿名标识口径
③	rubric 三分组小计落库	已落:评分尺 v2 升 11 条 + L2/L3/L4 三分组小计落库(commit ba82e63c)	生成线前置小工单,已完成
④	统一 trace 归档载体	契约位已立(contracts/trace/ 核心五字段、tier2/saa 两 schema),tier2 adapter 已接;cheap 线接入与统一落表待接	契约位 = agentic 集成架构既有;归档 job = 本节自有实现项
⑤	离线归档 join job	未建	本节自有实现项,随①②④齐后落

五项齐 = 首单(D5)输入完整。降级路径分两类:①②未齐可降级跑(缺收益列则收益轴空、留存用完玩率 + 互动率代理),结论显式标注降级;③没有替代轴——rubric 分组小计是 D5 的自变量,它若断档(如后续评分尺变更未同步落库),首单只能退化为"纯留存 / 生成特征观察单"并显式标注,rubric×留存相关性结论顺延到落库恢复后的下一单,不可用别的轴降级替代。

回流半环自身也要仪器化。产单 owner = 质量轨,治理按六去向分级,运营建议(⑥)抄送人办侧;每张校准单尾部记两个健康度数——本窗"提案数 / 采纳数"、既往更新的"验证窗口通过率",校准单序列本身就是台账。连续两窗提案零采纳,或验证窗口通过率 < 50%,由质量轨发起机制修订(走双评审)——那说明分析口径或治理门有问题,修机制而不是硬出单。隐私边界不变:回流半环不引入新的玩家个体数据面,分析一律在游戏粒度聚合之上(脱敏对齐 §5 风险四)。

---

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——携带父游戏的 src/ 源工程作生成上下文,让模型基于已有玩法做变体,这要撞上"便宜模型在受约束的变体生成下能不能稳产"这个还没过的 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 成语料、离线产出对线上零影响;语料能支撑校准单出单(品类资产校准提案、质量模型修订提案、推荐排序建议信号,口径见 §3.3 六去向);归档复用统一 trace 契约、不存第二份生成数据。回流半环自身的验收在机制层:首单(D5)产出 ≥1 条有证据的修订提案且治理门走通,首个被采纳更新过验证窗口(留存判据允许跨窗坐实)。

风险集中在四处。

第一,血缘字段加在源 schema 上要确认是否随之升版本。源项目 schema 现行是 schemaVersion: const "2.0"(A-model 多文件源工件;1.0 的 gamedef 声明式表示已于 2026-06-21 随错误路线删除,gamedef→src 迁移已完成),加 lineage 是 additive(可选属性、不破 additionalProperties:false),但要确认是否需要随之升版本号——如果升,要同步两端读取方(Java 落库侧、引擎适配器消费侧)和 CI 一致性校验。迁移既已收尾,这块不再与那条线的 schema 改动撞车。

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

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

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

---

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

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

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

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

4. 资产市场的"只读半"在支付接通前可以先上(创始人 2026-07-05 已定)。 跨创作者素材货架浏览、自有授权范围内选用(免费)这一半不依赖支付,先于支付落地,先把资产沉淀和复用习惯养起来。边界也同时拍死:这个中间态只能做"能浏览、能选用、暂不能买卖",不接购买、授权支付和分成;流通半等真实支付收单、trade source=ASSET、采购/授权单和法务口径齐后再启动。

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

6. P-FED-12 正式升 P0(创始人 2026-06-22 已定:走 RTM 升 P0)。 创始人拍板正式升 P0:Doc A(产品/需求清单.md)的 P-FED-12 已由 P1 改 P0,前端档 §7.3 口径校准同步。阶段一据此按 P0 核心功能投入。注:P-FED-12 已计入 Doc A 现行的 55 P0(实测计数 = 55、含 P-FED-12;P-PUB-01 一键多渠道按"外部渠道受日历闸门阻塞"降 P1 抵平),所以全局"55 P0"头号口径不变、无需上调。

---

变更记录

• 2026-07-02 §3.3 折入回流半环机制(创始人决策包⑦批准、草案值生效):新增"从语料到资产:回流半环与校准单"一节——校准单六段(触发/输入/分析/产出/治理/验证)、六去向三性质治理、防学偏五条、数据就绪清单五项;消费方清单同步改写,消除两套并列分类——品类骨架校准细化为去向①②③,rubric 档位观测线与 D11 权重(去向④⑤)为质量模型修订提案面,推荐排序改为"为推荐排序产出建议信号(算法与 quality_score 机制不动)",远期自训语料不变;§2 目标与 §5 阶段四验收措辞随之对齐。机制推理与评审史 = docs/agent-specs/2026-07-02-数据飞轮回流环-设计.md(该档随本次折账降留痕)。