games-development-ai/docs/architecture/架构/13模块.md

架构域 · 13 个后端业务模块

这是什么:绘境AI 后端 13 个业务模块的逐个详解——每个模块管什么、内部包含哪些技术功能、跟谁有依赖、现在建到了什么程度。它是架构域主文档 §3–4("13 模块总览 + 依赖方向")的下钻细化。 给谁看:要动某个模块的工程师、做模块边界评审的架构师、想知道"这块功能落在哪个模块"的人。 怎么读:先看 §1 的全景图与依赖图建立空间感,再按需跳到 §3 对应模块的卡片;每张卡片自带一句"现在建到哪了",想看全局完成度就读 §4 的状态总表。 读这一页 = 模块结构的当前真相,但有一条铁律:结构、实现、状态三者冲突时,以"状态"为准(详见文末注)。本页讲的是"应该怎么切"(结构权威);"实际建成多少"以 docs/mvp/MVP进度总账.md 为准。

---

1. 一张图看清 13 个模块怎么分工

绘境AI 的后端把全部业务能力按领域边界(domain boundary,即"一类职责归一处")切成 13 个模块,追求高内聚、低耦合——每个模块对内是一件完整的事,对外只通过窄接口交互。这 13 个模块物理上不是 13 个独立服务,而是以 jar(Java 打包单元)聚合进 Huijing 单体一起运行(Huijing 是我们 fork 的开源 Java 后台框架);逻辑上它们各自独立、互不越界,为将来从单体平滑拆成微服务预留了天然的切割线。

每个模块有一个三字母前缀(如 studio = STU),内部的每一项技术功能用 T-{模块}-{编号} 来标识——例如 T-AGC-04 是 aigc 模块的第 4 项技术功能。这套 T-id 是整套架构的"结构注册表",全平台共 204 项技术功能,只增不改号,废弃的打墓碑标记保留(这样引用它的其他文档不会因为重新编号而失效)。

按它们在业务闭环里的位置,13 个模块可以归成四组:

flowchart TB
  subgraph 创作["创作链路 — 把游戏做出来"]
    STU["studio · 创作编排 / 编辑器域"]
    AGC["aigc · 无状态生成原子"]
    RT["runtime · 编译 / 沙箱 / 多渠道发布"]
    PRJ["project · 项目生命周期 + 专区 Zone"]
  end
  subgraph 分发["分发与数据 — 让游戏被玩到、被看清"]
    FED["feed · 游戏流推荐 / 互动 / 分享"]
    TEL["telemetry · 事件摄取 / 聚合 / 质量评分"]
  end
  subgraph 变现["变现链路 — 把钱赚回来"]
    PAY["pay · 支付收单 / 订单 / 退款对账"]
    TRD["trade · 分账 / 结算 / 钱包 / 财税"]
    AD["ad · 广告联盟 / 植入 / 曝光计费 / 归因"]
  end
  subgraph 生态["平台与合规 — 让生态转得起来、守得住"]
    CMU["community · 社交 / 互动 / 排行 / 通知"]
    IP["ip · 素材安全 / 授权链 / IP 风格原子"]
    CMP["compliance · 内容安全 / 审核 / 锁风门 / RBAC"]
    BIZ["biz · B/G 端定制工程底座"]
  end

• 创作链路:用户从这里把游戏做出来。studio 是有状态的创作工作台,它把活分派下去;aigc 负责"一次请求出一个产物"的无状态生成;runtime 把生成结果编译成能跑的包;project 把项目和版本落库管起来。
• 分发与数据:feed 把已发布的游戏排成竖屏游戏流推给玩家;telemetry 把全链路的行为事件收上来、算出质量分,再回喂给 feed。两者互相依赖,构成"越用越聪明"的数据回路。
• 变现链路:pay 统一收钱,trade 把多来源的收入分账结算到创作者钱包,ad 把游戏内广告从植入到计费做成后端原子。
• 平台与合规:community 承载社交关系与全渠道通知;ip 为素材和授权资产提供安全可信的底座;compliance 是内容安全与审核中枢、也是锁风门的裁决方;biz 支撑 B/G 端(企业 / 政府客户)定制业务。

---

2. 模块之间怎么依赖:为什么是这个方向

模块间是单向、低耦合的依赖——A 依赖 B、B 绝不反向依赖 A,且只通过每个模块的 -api 包(只声明数据结构 DTO 与远程调用接口、不含实现)交互。这样任何一个模块都能独立演进、独立测试。下图箭头 A→B 表示"A 依赖 B":

graph LR
  STU[studio] --> AGC[aigc]
  STU --> RT[runtime]
  STU --> IP[ip]
  STU --> PRJ[project]
  STU --> CMP[compliance]
  AGC --> CMP
  AGC --> PRJ
  RT --> PRJ
  RT --> TEL[telemetry]
  FED[feed] --> PRJ
  FED --> TEL
  TEL --> FED
  IP --> CMP
  IP --> TRD[trade]
  CMP --> AGC
  CMP --> IP
  PRJ --> CMP
  TRD --> PAY[pay]
  TRD --> AD[ad]
  AD --> RT
  BIZ[biz] --> PRJ
  BIZ --> AGC
  BIZ --> TRD
  CMU[community] --> PRJ

读这张图有四条主线:

• 创作侧 studio 站在最上游,把活分派给 aigc(生成)、runtime(编译)、ip(素材)、project(落库)、compliance(安全裁决)。它自己几乎不被别人依赖——这是"工作台"该有的位置。
• 生成原子 aigc 保持无状态,只向下依赖 compliance(做 Prompt 安全检测)和 project(写入结果),自己不持有任何会话或项目状态。无状态意味着它天然可重放、可横向扩容。
• 数据回路 telemetry ↔ feed 互相依赖:feed 消费 telemetry 算出的质量分来排序,telemetry 回收 feed 上的互动信号来计算——这是图里唯一一处双向边,也正是平台"越用越聪明"的机制所在。
• 资金侧 trade 向下收口:它依赖 pay(收单)和 ad(广告收入)拿到资金原始数据,自己只管分账、结算、对账。compliance ↔ ip ↔ aigc 之间还有一处"风格-版权"裁决的环路,下面专门讲。

两个跨模块的关键概念(横切关注点)

有些能力不属于单一模块,而是横跨多个模块协作完成。为避免出现"人人都管、结果没人管"的灰色地带,每个横切关注点都指定唯一的 owner(责任主)。MVP 阶段有两个:

横切关注点	owner(责任主)	谁供原料 / 谁消费	标识
锁风门 Gate(风格-版权一致性门)	compliance	aigc 的风格检测原子(T-AGC-19)、ip 的 IP 风格校验原子(T-IP-04)供原料;project 的发布前检查(T-PRJ-05)消费	T-CMP-12
专区 Zone(运营双轨分区)	project	feed 据它分区推荐(T-FED-15);ip 据它做双轨归类(T-IP-10);studio 决定创作去向	T-PRJ-07

• 锁风门 Gate:一道"风格-版权一致性"门。"锁风"= 锁定风格、防止侵权。它本身不会检测风格,而是聚合 aigc 和 ip 各自产出的风格检测原子(原子 = 最小的、可独立调用的检测单元),综合裁决出 pass(放行)/ review(转人工)/ block(拦截)三种结论,挂在 project 的发布前检查上。owner 是 compliance,因为它是全平台的内容安全与裁决中枢。
• 专区 Zone:运营用的双轨分区——授权 IP 区(放基于授权形象创作的游戏)和 UGC 区(UGC = User Generated Content,用户原创内容)。Zone 的实体归 project 所有(owner),feed 据它分区推荐、ip 据它给素材双轨归类。MVP 阶段 Zone 还没有独立的数据库实体,是用字段承载的(有意简化)。

建设形态注记(2026-06-10 审计):13 模块是逻辑划分,物理上以 jar 聚合进 Huijing 单体运行。其中 ip 不独立建模块,而是以 seam(接缝/预留位)寄宿在 compliance 里(D5 裁定);pay 是 Huijing 原生模块,当前尚未接入单体启动器;community / biz 属 Wave4(第四批开发波)、目前未建。这些形态在下面各模块卡片里会逐一标注。

---

3. 13 个模块逐个看

下面每张卡片包含四件事:职责(这个模块负责什么)、边界(IN = 它管什么 / OUT = 它不管什么,委托给谁)、依赖(它向下依赖哪些模块)、以及它内部的技术功能 T-id 清单。卡片末尾用一句话给出"现在建到哪了"(完整状态表见 §4)。

卡片里偶尔出现的 📌 标记,表示这一项的 MVP 现实形态与原蓝图设计有出入——蓝图是远期形态,📌 后面是 MVP 当下的落地方式。

3.1　studio — 创作编排 / 编辑器域　★新增

studio 是有状态的创作工作台后端。它的活是:把一次"创作会话"编排成一份可试玩的草稿——调度 aigc 的生成原子、把多种资产装配到一起、管理角色的骨骼绑定(rig)/ 对白分支树 / 任务链,最后落地成 project 的草稿。它是创作链路的总指挥,但自己不干脏活:不跑大模型、不持久化版本、不编译、不拥有素材库、不做锁风裁决,这些都委托出去。

• 边界 IN:创作会话、资产图、角色 rig、对白分支树、任务链编排、附件上下文装配、六类资产生成调度、批量 / 可视化工作流编排。
• 边界 OUT:不跑 LLM / 扩散模型(委托 aigc)｜不持久化项目版本(交 project)｜不编译 / 沙箱(交 runtime)｜不拥有素材库(读 ip)｜不做锁风裁决(调 compliance)。
• 依赖:aigc · runtime · ip · project · compliance。

ID	技术功能
T-STU-01	创作会话状态机与持久化
T-STU-02	资产图模型(多资产组合关系)
T-STU-03	角色骨骼 rig 数据结构与动作编辑
T-STU-04	对白分支树(编辑 + 实时写入预览节点)
T-STU-05	agentic 任务链编排引擎(7 步生成链)
T-STU-06	附件上下文装配(生成产物 / 上传 → 生成上下文)
T-STU-07	SSE 进度推送　📌 MVP = 同步轮询,SSE 后置
T-STU-08	草稿装配与 project 移交契约
T-STU-09	六类资产模块化生成调度(按资产种类编排 aigc 原子)
T-STU-10	用户工作流编排(可视化,创作者自定义流程节点)·远期
T-STU-11	批量游戏生成调度 · 远期

SSE = Server-Sent Events,服务器主动向浏览器推送进度的技术;MVP 先用更简单的同步轮询代替。T-STU-10/11(可视化工作流、批量生成)是远期能力,产品出口待定,当前未映射。

现在建到哪了:🟡 部分。创作编排的委托层是真的(草稿装配 + aigc 接缝 + 血缘追溯),但所谓"7 步生成链"其实不在 studio、而在 aigc 的 SAA 生成图里;六类资产 / 角色 rig / 对白树 / 可视化编排目前都还是桩(stub,即只有壳、无真实实现)。

3.2　aigc — 无状态生成原子　收敛

aigc 是生成侧的原子工厂,也是平台护城河的核心路径。它的契约非常干净:单个 Prompt / 请求 → 单个确定性产物(结构化参数 / GameConfig / 图 / 音 / 剧情 / 封面 / 校验结果 / 风格指纹),无状态、幂等(同样输入给同样输出)、可重放。所有"会话""多资产装配""进度链"这类有状态的编排都不归它,归 studio。

• 边界 IN:Prompt 解析 / 安全、模板匹配 / Schema、LLM 编排 / 熔断、生成任务队列 / 状态机、Fallback 兜底、图 / 音 / 剧情 / 封面生成原子、风格标签、内置素材库、质量评估。
• 边界 OUT:不管会话 / 编辑 / 多资产装配与进度链编排(交 studio)｜不持久化项目(交 project)｜不编译 / 沙箱(交 runtime)｜不做锁风裁决(只供风格原子给 compliance)。
• 依赖:compliance(Prompt 安全)· project(写入结果)· 基础设施(文件)。

ID	技术功能	ID	技术功能
T-AGC-01	Prompt 解析与归一化	T-AGC-12	内置素材库管理
T-AGC-02	Prompt 安全检测	T-AGC-13	素材上传校验 + SHA256 去重
T-AGC-03	模板分类匹配 / 注册 / 扩展	T-AGC-14	图像 AI 生成原子
T-AGC-04	GameConfig 结构化生成 + JSON Schema 校验	T-AGC-15	音乐 / 音效 AI 生成原子
T-AGC-05	模板参数校验与兜底	T-AGC-16	剧情 / 对话 AI 生成原子
T-AGC-06	LLM 调用编排 / 熔断 / 重试 / 多供应商	T-AGC-17	封面 / 宣传图 AI 生成原子
T-AGC-07	生成任务异步队列调度　📌 MVP 用执行器轮询	T-AGC-18	节点配置参数化(载体 = SAA,非自研引擎)
T-AGC-08	生成任务状态机(queued/running/succeeded/failed/timed_out/canceled)	T-AGC-19	生成风格一致性检测原子(供锁风门)
T-AGC-09	确定性 Fallback 生成	T-AGC-20	Golden Config 回归测试
T-AGC-10	生成失败原因分类(结构化错误码)	T-AGC-21	生成结果质量自动评估
T-AGC-11	风格标签体系

几个名词的一句话解释:GameConfig 是描述一款游戏的结构化配置(玩法参数、资产引用等),是生成链的核心产物;SHA256 去重是用内容哈希识别重复素材;T-AGC-18 的"自研 DAG / 工作流引擎"表述已作废——agentic 编排基建统一改用 SAA 裸图(Spring AI Alibaba 的状态图编排,见架构主文档 §2.2),编排不自研,此项保留为远期"专业创作者可视化编排"占位、载体改 SAA;T-AGC-07 的 RocketMQ 异步队列是远期形态,MVP 用进程内执行器轮询代替。

现在建到哪了:🟡 部分。执行器主链是真的(M2 阶段已 e2e 实测:一句话生成 18–27s 出可玩游戏,成功率约 80%);但 SAA 控制平面属于"建成但未默认上生产"。最大缺口是 W-G1 worker 尚未接为 staging 默认产线(W-G1 = 便宜模型造游戏的工作器,worker = 后台生成进程),且玩法模板注册未建。

3.3　runtime — 编译 / 预览 / 渠道发布　扩

runtime 把 aigc 产出的 GameConfig 变成能真正跑起来的东西:编译成版本化的可运行 Web 包、在沙箱里预览、转换成各渠道(微信 / 抖音 / 快手小游戏、TapTap 试玩包)的格式并驱动发布状态机。它不决定"能不能发"(那是 compliance 的裁决),只负责"怎么把它做出来、推出去"。

• 边界 IN:编译 / Manifest(产物清单)/ 打包、沙箱与事件桥接、体积与完整性校验、预加载与缓存、渠道转换与提审、发布状态机、运行时质量采集。
• 边界 OUT:不决定发布放行(交 compliance)｜不做推荐分发(交 feed)｜不持久化项目(读 project)｜不跑生成(消费 aigc 产物)。
• 依赖:project · aigc · telemetry · compliance(渠道合规,被动)。

runtime 是技术功能最密集的模块之一(32 项),覆盖了从编译、资源优化、沙箱安全到多渠道转换的全链路。核心几项:

ID	技术功能	ID	技术功能
T-RT-01	GameConfig → 可运行 Web 包编译	T-RT-04	iframe 沙箱隔离 + CSP
T-RT-02	GameManifest 生成与打包	T-RT-05	Game SDK 事件桥接
T-RT-03	资源打包上传 OSS(版本化路径)	T-RT-08	资源体积限制(≤10MB / 首屏 ≤2MB)
T-RT-11	预加载与三容器策略	T-RT-14	postMessage 来源与 schema 校验
T-RT-21~23	小游戏转换(微信 / 抖音 / 快手)	T-RT-27	游戏可玩性自动测试　📌 自研 CDP 客户端
T-RT-26	统一工程转译引擎	T-RT-31	TapTap 试玩包提审通道
T-RT-28	运行时链路追踪(trace_id)	T-RT-32	渠道发布状态机(待开通→申请→开通→上线)
T-RT-30	云游戏即时运行容器 · 远期		(另含 FPS 监控、素材压缩、CDN 刷新等共 32 项)

iframe 沙箱 = 浏览器内嵌的隔离框架,与平台彻底隔离;CSP = 内容安全策略,限制游戏内的网络与脚本行为;postMessage = iframe 与宿主页之间唯一的通信通道。T-RT-27 的可玩性自动测试原蓝图写的是 Playwright(浏览器自动化框架),实现现状是自研 CDP 客户端 player_cdp.py(CDP = Chrome DevTools Protocol,直接驱动 Chrome 的协议),已在尽调补录中说明。

现在建到哪了:🟡 部分。存包 / 取包、engineBundle 内嵌(engineBundle = 把引擎打进游戏包一起发的产物形态)、沙箱桥接都是真的;但真实编译引擎目前是桩,微信 / 抖音 / 快手 / TapTap 渠道转换未建,OSS 存取也是桩。

3.4　project — 项目生命周期 + 专区 Zone　扩

project 是全仓最成熟的模块,管的是项目 / 版本 / 草稿的全生命周期与状态流转,并编排发布。它还是专区 Zone 实体的 owner。它的纪律很清晰:只驱动状态、不裁决结论——审核结论由 compliance 给,它只负责把状态机往前推。

• 边界 IN:项目 / 版本 CRUD、状态机、草稿持久化、发布前检查、发布审核流程对接、统一发布编排、Zone 实体 / 归属 / 运营位。
• 边界 OUT:不生成内容(aigc / studio)｜不裁决审核结论(compliance,本模块只驱动状态)｜不编译 / 转换(runtime)｜不做推荐排序(feed)。
• 依赖:compliance · runtime · feed · BPM(工作流引擎)· 基础设施。

ID	技术功能
T-PRJ-01	项目 CRUD(元数据持久化 + 字段约束校验)
T-PRJ-02	游戏状态机(draft…published/rejected/unpublished/deleted + 下架 / 封禁迁移)
T-PRJ-03	版本管理(自增 / 覆盖 / 历史 / current_version_id 切换)
T-PRJ-04	草稿保存与恢复机制
T-PRJ-05	发布前检查清单(聚合锁风门 + 性能 + 版权)
T-PRJ-06	发布审核 BPM 对接　📌 MVP = 轻量状态机 + admin 审核队列,Flowable 为远期
T-PRJ-07	专区 Zone 实体 + 游戏归属 + 运营位(精选 / 新游 / 全部)+ launchZone
T-PRJ-08	统一发布编排(compliance→runtime→feed,失败回滚)
T-PRJ-09	游戏工程包导出(+ 多渠道审核元数据预留)
T-PRJ-10	版本回退

CRUD = 增删改查;BPM = 业务流程 / 工作流引擎,Flowable 是一种重型 BPM 实现,MVP 先用轻量状态机 + admin 审核队列代替。T-PRJ-08 的统一发布编排是全仓唯一一处真正的跨表原子发布(把 compliance 裁决、runtime 出包、feed 入流串成一个事务,任一步失败就回滚),是脊柱级能力。

现在建到哪了:✅ 完成。全仓最成熟:状态机 + 唯一真原子跨表发布编排 + 审核队列真查库都已落地。已知缺口仅 Zone 没有独立实体(用字段承载,MVP 有意简化)。

3.5　feed — 游戏流 + 专区分区　扩

feed 把已发布的游戏按规则推荐排序成竖屏游戏流(类似短视频信息流),回收玩家的互动信号,提供分享外链,并按 Zone 分区。它不存游戏本体(读 project)、不算质量分(消费 telemetry)、不裁决举报(转 compliance),只做"排序 + 分发 + 信号回收"这一件事。

• 边界 IN:推荐打分 / 候选集、保底 / 降权 / 冷启动、cursor 分页 / 去重、互动信号写入、分享页 / OG、按 Zone 分区、A/B 实验框架。
• 边界 OUT:不存游戏本体 / Zone 实体(读 project)｜不算质量分(消费 telemetry)｜不裁决举报(转 compliance)。
• 依赖:project · telemetry · compliance。

ID	技术功能	ID	技术功能
T-FED-01	规则推荐打分	T-FED-09	分享落地页渲染 + OG 元数据
T-FED-02	候选集缓存　📌 MVP 直查 MySQL,Redis TTL 60s 为增长期	T-FED-10	渠道参数解析(utm / channel)
T-FED-03	新人保底曝光	T-FED-11	行为信号加权排序
T-FED-04	低质内容降权	T-FED-12	推荐策略 A/B 实验框架
T-FED-05	冷启动策略	T-FED-13	个性化推荐算法 · 增长期
T-FED-06	cursor 分页	T-FED-14	精选池管理接口
T-FED-07	Feed 去重	T-FED-15	按 Zone 分区推荐(授权 IP / UGC 双区独立候选)
T-FED-08	互动信号写入(赞 / 藏 / 享 / 举报 → 权重)

cursor 分页 = 用游标(而非页码)翻页,适合无限流;OG 元数据 = Open Graph,决定分享链接在社交平台的卡片预览;A/B 实验 = 同时跑两套策略对比效果。MVP 阶段推荐是"规则 + 信号"、不上机器学习,候选集可直查 MySQL(Redis 缓存是增长期形态)。

现在建到哪了:🟡 部分。互动信号、getZones、quality 排序都是真的(B2 阶段已 e2e 实证"互动回灌翻转排序");但游标分页是桩(永远返回第一页),候选集纯查 MySQL 无 Redis,举报转 compliance 也是桩。

3.6　telemetry — 遥测与数据底座

telemetry 是平台的数据底座。它统一摄取全链路的行为事件(创作、生成、游玩、互动),治理事件 Schema(数据格式规范),做增量聚合,计算每款游戏的 quality_score(质量分),并产出监控告警与数据质量信号。它只负责"把数据收上来、算清楚、喂出去",不渲染看板(那是产品域)、不做推荐决策(只产信号给 feed)。

• 边界 IN:事件摄取 / SDK 上报、Schema 治理、聚合、质量 / 漏斗 / 留存 / 归因计算、埋点采集、健康监控、告警、数据质量、重复检测原子。
• 边界 OUT:不渲染看板 / 建议 / 导出 UI(供数据给产品域)｜不做推荐决策(产信号给 feed)｜不生成迭代内容(建议交 studio / aigc)。
• 依赖:feed · project · compliance。

telemetry 共 22 项技术功能,核心是"摄取 → 聚合 → 质量分 → 监控"四段:

ID	技术功能	ID	技术功能
T-TEL-01	事件批量摄取(/events/batch)	T-TEL-08	玩家留存计算
T-TEL-02	事件 Schema 治理	T-TEL-09	创作者复创率计算
T-TEL-03	埋点批量上报通道(sendBeacon 兜底)	T-TEL-13~15	实时监控(服务 / 生成 / Runtime 健康)
T-TEL-04	quality_score 计算	T-TEL-16	异常检测与告警
T-TEL-05	增量聚合(GameDailyStats)	T-TEL-17	生成失败根因聚合
T-TEL-06	创作漏斗计算	T-TEL-18	渠道归因计算
T-TEL-07	游戏流消费漏斗计算	T-TEL-22	重复内容检测原子

quality_score = 综合质量分,是 feed 排序的核心输入;sendBeacon = 浏览器在页面关闭时仍能可靠上报埋点的 API;GameDailyStats = 按天聚合的游戏统计表。

现在建到哪了:✅ 完成。唯一真端到端的数据底座:事件落库 + quality 真算分 + 日聚合 upsert(有则更新无则插入)+ 创作者 stats 都打通了。已知缺口仅 MQ 异步聚合是桩(有意),广告营收字段占位。

3.7　pay — 支付收单 / 订单 / 退款对账

pay 把各类付费统一收单为可追溯、可对账、可幂等的支付订单,对上层屏蔽不同支付渠道的差异。它只管"把钱收进来",不定义会员 / 积分 / 内购的产品形态与定价(那是产品域配置),也不做分账 / 钱包 / 提现(交 trade)。

• 边界 IN:支付渠道抽象、订单状态机、退款、对账、幂等。
• 边界 OUT:不定义会员 / 积分 / 内购产品形态与定价(产品域配置)｜不做分账 / 钱包 / 提现(交 trade)。
• 依赖:huijing-system · trade · 微信 / 支付宝 / Apple IAP · Redis。

ID	技术功能
T-PAY-01	支付网关抽象(微信 / 支付宝 / Apple IAP)
T-PAY-02	支付订单状态机
T-PAY-03	退款处理
T-PAY-04	支付对账
T-PAY-05	支付幂等(Redis 防重复扣款 / 回调)

Apple IAP = 苹果应用内购买;幂等 = 同一笔操作重复执行不会重复扣款(靠 Redis 去重 + 订单状态机保证)。

现在建到哪了:◻ 未接单体。pay 是 yudao(Huijing 上游开源框架)的原生模块,server 启动器里被显式注释排除。真实支付收单全未接入,卡在"支付进件"这类不可压缩的日历闸门(指必须等监管 / 渠道审批的外部环节)。

3.8　trade — 分账 / 结算 / 对账域

trade 是无感的资金清算后端。它把多来源的收入(广告、渠道分发、素材交易)按规则分账、归集、结算、对账,并出财税报表。它不收单(交 pay)、不产广告原始数据(读 ad)、不提供钱包 UI(只供数据给 studio),只做"钱进来之后怎么分、怎么结、怎么对账"。

• 边界 IN:分账规则、收入归集与台账、T+1 / 月结、对账、佣金、税务、营收聚合、应收账款、提现门槛与打款、奖金 / 补贴发放执行。
• 边界 OUT:不做支付收单(交 pay)｜不产广告收益原始数据(读 ad)｜不撮合素材交易(读 ip)｜不提供看板 / 钱包 UI(供数据给 studio)。
• 依赖:pay · ad · ip · telemetry。

ID	技术功能	ID	技术功能
T-TRD-01	广告分成分账引擎(80% / 75% / 70%)	T-TRD-07	平台营收报表聚合
T-TRD-02	多渠道广告收入归集	T-TRD-08	渠道分发收入统一台账
T-TRD-03	T+1 / 月结结算周期调度	T-TRD-09	B 端应收账款管理
T-TRD-04	对账引擎	T-TRD-10	财务合规(增值税 / 发票 / 个税)
T-TRD-05	素材交易佣金计算(抽 30%)	T-TRD-11	提现门槛校验与自动打款执行
T-TRD-06	税务代扣与凭证生成	T-TRD-12	奖金 / 补贴发放执行引擎

T+1 = 交易次日结算;广告分成的 80% / 75% / 70% 是分给创作者的三档分账比例(按创作者等级 / 渠道区分);素材交易平台抽佣 30%。

现在建到哪了:✅ 完成。资金状态机真(逐笔入账 + 冻结用 CAS 比较交换 + 对账补偿),41 个单元测试;打款做了 fail-fast(快速失败)防止打出假钱。已知缺口是真 pay 对接还是桩,受支付进件闸门 mock-gated(被 mock 挡在闸门前)。

3.9　community — 社交 / 互动 / 通知底座

community 承载社交关系、互动计数、排行 / 成就计算与全渠道通知投递。它是底座——提供能力原子,不定义"可感知的社交玩法形态"(那是产品侧的事)。它不渲染社区前端、不裁决内容安全(调 compliance)、不算质量分(读 telemetry)、不结算奖金(交 trade)。

• 边界 IN:社交关系图谱、互动计数、排行计算、成就引擎、动态扇出、站内信、推送 / 邮件 / 短信通道、通知编排、等级自动升降计算。
• 边界 OUT:不渲染社区前端 / 不定义玩法(产品侧)｜不裁决内容安全(调 compliance)｜不算质量分(读 telemetry)｜不结算奖金分成(交 trade)。
• 依赖:project · telemetry · compliance · huijing-system · huijing-infra · trade。

ID	技术功能	ID	技术功能
T-CMU-01	社交关系图谱存储(关注 / 粉丝 / 好友)	T-CMU-07	推送通道适配(APNs / FCM / 厂商)
T-CMU-02	互动数据存储与计数(评论 / 赞 / 弹幕)	T-CMU-08	邮件投递通道
T-CMU-03	多维排行榜计算与缓存	T-CMU-09	短信投递通道
T-CMU-04	成就规则引擎与进度计数	T-CMU-10	事件驱动通知编排(路由 / 模板 / 去重)
T-CMU-05	创作者动态扇出 / timeline	T-CMU-11	创作者等级自动升降计算引擎
T-CMU-06	站内信投递与已读

动态扇出(fan-out)= 创作者发动态时把它推送到所有粉丝的时间线;APNs / FCM = 苹果 / 谷歌的推送服务。

现在建到哪了:✅ 完成(MVP 裁剪后的范围)。通知底座 + 等级引擎是真的,三个上游(生成 / 审核 / 收益)的通知挂点全通,22 个单元测试。后续 plan002(U3,commit 3f35acb4,Flyway V23)又补齐了评论 CRUD + 关注 + 排行 Redis ZSET(排行真算:afterCommit 写 ZSET + rebuildFromDb 对账保 ZSET↔DB 一致)+ 弹幕 WS,再叠 35 测(共 57 绿)。真缺口收窄为:成就引擎(achievement)仍未建(MVP 有意裁剪)、弹幕多实例(sender-type=redis)与多通道未建、举报转 compliance 受理的 -api 待交付。口径与 docs/mvp/MVP进度总账.md 对齐。

3.10　ip — 素材安全 / 授权 / IP 风格原子　扩

ip 为素材和 IP(知识产权)资产提供安全可信、授权可溯、风格可校的底座原子,并按 Zone 双轨归类。它供给原子、不做最终裁决(锁风裁决归 compliance)、不做资金结算(交 trade)、不跑生成(aigc)。

• 边界 IN:素材安全扫描、授权链追溯、授权 / 分成数据、IP 风格校验原子、冻结、盗用监测、模型训练对接、Zone 双轨归类。
• 边界 OUT:不做最终锁风裁决(供原子给 compliance)｜不做资金结算(交 trade)｜不跑生成(aigc)｜不承载素材 / 模板市场交互(供料给产品域)。
• 依赖:compliance · trade · project · aigc · 基础设施 / OSS。

ID	技术功能	ID	技术功能
T-IP-01	素材安全扫描(涉黄 / 暴 / 政)	T-IP-06	IP 盗用监测
T-IP-02	商用授权链建模与追溯	T-IP-07	IP 风格模型训练对接
T-IP-03	授权 / 分成范围数据与计费口径	T-IP-08	音色克隆训练对接 · 远期
T-IP-04	IP 风格一致性校验原子(供锁风门)	T-IP-09	模板授权分成原子
T-IP-05	高风险素材冻结	T-IP-10	素材按 Zone 双轨归类(授权 IP / UGC)

授权链 = 一份素材"谁授权给谁、能用在什么范围"的可追溯链条;T-IP-04 是锁风门两大原料之一(另一个是 aigc 的 T-AGC-19)。

现在建到哪了:◻ seam(接缝寄宿)。ip 有意不独立建模块,而是寄宿在 compliance 里。当前风格原子是桩,ip 模块自身的素材安全扫描 / 授权链 / 盗用监测原子全未建(属远期)。注:面向用户的素材浏览 / 选用 / 上传最小后端不在 ip、而由 studio 域承载(plan002 U6,game_material 表 V24),别误读成"素材相关后端零代码"。

3.11　compliance — 内容安全 / 审核 / 锁风门　扩

compliance 是内容安全与审核中枢——它做安全检测、跑审核状态机与人工复核、聚合风格原子做锁风裁决,并承载 RBAC(基于角色的访问控制)、审计、加密、安全基线、防沉迷。它是被 project / aigc / feed 共同依赖的横切地基,技术功能多达 38 项,是 13 个模块里最重的一个。

• 边界 IN:文本 / 图片 / AI 产物安全检测、违禁词、审核状态机 / 分层 / 人工复核、举报降权、锁风门聚合裁决、RBAC、审计、安全基线、防沉迷接入、分级判定、渠道合规、封禁、备份。
• 边界 OUT:不自产风格检测原子(由 aigc / ip 供给)｜不拥有项目实体(读 project)｜不做推荐(产降权信号给 feed)｜不展示隐私 / 申诉 UI(产品功能,交 studio)。
• 依赖:aigc(T-AGC-19)· ip(T-IP-04)· project · feed · huijing-system / bpm · 内容安全 API · Vault。

compliance 的 38 项技术功能可归为四块:内容安全检测(T-CMP-0105)、审核流程(T-CMP-0615,含核心的锁风门)、权限与审计(T-CMP-1620)、安全基线(T-CMP-2138)。核心几项:

ID	技术功能
T-CMP-01~03	文本 / 图片 / AI 生成内容安全检测
T-CMP-05	Prompt 注入防护
T-CMP-06	审核决策与状态机
T-CMP-09	人工审核队列
T-CMP-12	锁风门 Gate(聚合 T-AGC-19 + T-IP-04 → pass / review / block + 标准 / 严格 / 人工复核;挂 T-PRJ-05)
T-CMP-16	RBAC 权限控制
T-CMP-17	匿名用户权限约束
T-CMP-23	OWASP Top 10 安全基线
T-CMP-27	Secrets 管理(Vault)
T-CMP-36	未成年人防沉迷接入
	(另含违禁词库、SSRF 防护、CORS/CSP、数据加密、审计日志 ≥180 天等共 38 项)

RBAC = 基于角色的访问控制;OWASP Top 10 = 业界公认的十大 Web 安全风险清单;Vault = 密钥管理工具;SSRF = 服务端请求伪造攻击;T-CMP-12 锁风门是全平台的发布合规闸门——它聚合 aigc 与 ip 的风格原子,裁决 pass / review / block,挂在 project 的发布前检查上。

现在建到哪了:🟡 部分。锁风门框架 + 真注入发布链 + RBAC 都是真的;但核心检测原子全是桩、恒返回 pass(风格 / IP / 内容安全),意味着发布链对违规内容目前零自动拦截、纯靠人工兜底——这是放量 / 接广告 / 上渠道前必须硬化的合规死锁。

3.12　biz — B/G 端定制工程底座

biz 为 B 端(企业)/ G 端(政府)定制业务提供报价、BPM 编排、签章、CRM、交付验收状态机与效果报告聚合。它不生成游戏(aigc)、不持久化项目(project)、不收款结算(trade)、不裁决合规(compliance),只承载定制业务的"工程流程骨架"。

• 边界 IN:报价计算、BPM 实例编排、电子签章对接、CRM 对接、交付验收状态机、效果数据聚合、代办工单跟踪。
• 边界 OUT:不生成游戏(aigc)｜不持久化项目(project)｜不收款结算(trade)｜不裁决合规(compliance)｜不承载 B 端 UI 语义(产品域)。
• 依赖:project · aigc · trade · compliance · bpm · 电子签章 · CRM。

ID	技术功能	ID	技术功能
T-BIZ-01	B 端项目报价引擎	T-BIZ-05	交付验收状态机
T-BIZ-02	BPM 定制项目编排(需求→报价→签约→交付)	T-BIZ-06	B 端效果数据聚合
T-BIZ-03	电子签章服务对接	T-BIZ-07	代办流程外部工单与状态跟踪(软著 / 渠道 / 资质)
T-BIZ-04	CRM 客户 / 合同数据对接	T-BIZ-08	收费与变更管理(预付 / 尾款 / 变更单)

CRM = 客户关系管理;软著 = 软件著作权登记。

现在建到哪了:🟡 部分。lead(销售线索)状态机 + 报价落库是真的,13 个单元测试;但模板硬编码 4 个(而非完整 32 套),报价引擎 / 签章 / CRM 纯未建。

3.13　ad — 广告引擎(植入 → 展示 → 计费 → 优化)

ad 把联盟接入、广告位 AI 植入、曝光计费、eCPM 优化与归因做成游戏内广告的后端原子。它不渲染广告 UI(那由 runtime 的 SDK 在游戏内呈现)、不做结算提现(交 trade)、不产看板视图(telemetry / biz 消费它的归因信号)。

• 边界 IN:联盟 SDK 对接、AI 植入、曝光上报与计费、eCPM 优化、合规植入校验、效果归因。
• 边界 OUT:不渲染广告 UI(runtime SDK 在游戏内呈现)｜不做结算提现(trade)｜不产看板视图(telemetry / biz 消费归因信号)。
• 依赖:runtime · trade · telemetry。

ID	技术功能	ID	技术功能
T-AD-01	广告位 AI 自动植入	T-AD-06	展示上报与有效曝光计费
T-AD-02~05	联盟对接(穿山甲 / 优量汇 / 快手 / 百青藤)	T-AD-07	eCPM 优化与精准匹配
T-AD-08	广告合规植入校验	T-AD-09	广告位效果归因

eCPM = 每千次展示有效收入,是衡量广告变现效率的核心指标;穿山甲 / 优量汇 = 国内主流广告联盟;归因 = 把一次收益正确算到对应的游戏 / 渠道上。

现在建到哪了:✅ 完成。计费全链真(合规 → 幂等 → 归因 → 台账)+ 验签 fail-fast,24 个单元测试。已知缺口是真联盟 SDK(穿山甲 / 优量汇)是桩,受广告审核闸门 mock-gated。

广告曝光反作弊补登(2026-06-10):ad 的两个计费端点(impression 曝光 / reward 激励)已随鉴权波放开匿名访问。MVP 形态的反作弊 = 幂等键 traceId + 按 IP 维度限流 + 消费 telemetry 的异常剔除桩(AnomalyFilterService,按匿名 ID / IP 滑窗,已实证 IP 维拦截);真接广告联盟前,必须升级为正式反作弊项(曝光 / 激励计费事件异常剔除 + 对账闸门)。

---

4. 13 个模块现在各建到了什么程度

把上面每张卡片末尾的状态汇成一张表,这是判断"哪里能用、哪里是债"的快速索引。口径三档:✅ implemented-real(真端到端、可验收)、🟡 partial-stub(有壳 / 半真 / 部分接线)、◻ 特殊形态(seam 寄宿或未接单体)。状态以代码 / 测试 / e2e 实测为准,不以文档声称为准。

#	模块	状态	一句话	最大缺口 / 债
1	project 项目	✅ 完成	全仓最成熟:状态机 + 唯一真原子跨表发布编排 + 审核队列真查库	Zone 无独立实体(字段承载,MVP 有意简化)
2	aigc 生成	🟡 部分	执行器主链真(M2 e2e,一句话 18–27s 可玩,80% 成功);SAA 控制平面"建成未默认生产"	W-G1 worker 未接为 staging 默认产线;玩法模板注册未建
3	runtime 运行时	🟡 部分	存包 / 取包 / engineBundle 内嵌真,沙箱桥接真	真实编译引擎 = 桩;渠道转换(微信 / 抖音 / 快手 / TapTap)未建;OSS 存取桩
4	feed 信息流	🟡 部分	互动信号 / getZones / quality 排序真,B2 回灌翻转 e2e 实证	游标分页 = 桩(永远第一页);候选集纯查 MySQL 无 Redis;举报转 compliance 桩
5	telemetry 遥测	✅ 完成	唯一真端到端数据底座:事件落库 + quality 真算分 + 日聚合 upsert + 创作者 stats	MQ 异步聚合 = 桩(有意);广告营收字段占位
6	ad 广告	✅ 完成	计费全链真(合规 → 幂等 → 归因 → 台账)+ 验签 fail-fast,24 单测	真联盟 SDK(穿山甲 / 优量汇)= 桩,受广告审核闸门 mock-gated
7	trade 资金	✅ 完成	资金状态机真(逐笔入账 + 冻结 CAS + 对账补偿),41 单测;打款 fail-fast 防假钱	真 pay 对接 = 桩,受支付进件闸门 mock-gated
8	community 社区	✅ 完成	通知底座 + 等级引擎真,3 上游 notify 挂点全通;plan002 又补评论 / 关注 / 排行 Redis ZSET / 弹幕 WS(57 单测)	成就引擎仍未建(MVP 裁剪);弹幕多实例(redis)/多通道未建;举报转 compliance 受理 -api 待交付
9	studio 工作室	🟡 部分	创作编排委托层真(草稿装配 + aigc 接缝 + 血缘)	"7 步生成链"不在 studio(在 aigc SAA 图);六资产 / 角色 rig / 对白树 / 可视化全桩
10	compliance 合规	🟡 部分	锁风门框架 + 真注入发布链 + RBAC 真	核心检测原子全桩恒 pass(风格 / IP / 内容安全)→ 发布链零自动拦截,纯人工兜底
11	biz B 端	🟡 部分	lead 状态机 + 报价落库真,13 单测	模板硬编码 4 个(非 32 套);报价引擎 / 签章 / CRM 纯未建
12	ip 版权	◻ seam	有意不独立建,寄宿 compliance	风格原子桩;素材安全 / 授权链 / 盗用监测全未建(远期)
13	pay 支付	◻ 未接单体	yudao 原生模块,server 显式注释排除出启动器	真实支付收单全未接,受支付进件闸门

合计:✅ 完成 5(project / telemetry / ad / trade / community)· 🟡 部分 6(aigc / runtime / feed / studio / compliance / biz)· ◻ 特殊 2(ip / pay)· 🔴 纯未建 0。

生成轨现状(读 aigc 卡片前先看这条):上面 aigc 那张卡片描述的是现行轻量档生成线——便宜模型直出经 new-api 网关、A-model 直接写真 src/ 多文件工程那条已实测在跑的生成线(旧 gameDefinition 已废)。三档生成(Tier0/1/2,按 AI 参与深度切分)统一收敛到 AgentScope 框架。轻量档之外,还有第二条 tier2 自治富游戏轨:让一个能自治工作的 AI agent 去造合成、经营、挂机这类轻量档做不出来的多系统富游戏。tier2 的核心已落、0 号 spike feie-005 已 accept(2026-06-24:M3 自治写出面包店经营合成富游戏,9 道 L1 门加富游戏三门全过、finished=True、无熔断,服务化已部署 mini-desktop:8200),与轻量档解耦并存、不替换它。tier2 验证走 n=5 收敛环(并发跑 5、有错追加 5、收敛即 go),不是统计批跑;阶段 1 工作室 Agent Team、控制面 / 管理面、feed 第二装载分支留 Phase B。设计见 生成引擎/agentic运行时架构图说.md。三档生成之上还有一层共用的控制面 / 管理面(配置注册表 + 观测审计仓 + D12 治理门 + 管理面 UI),负责把各档配置、观测、审计、管起来,设计同见该 SoT。tier2 是独立 service、不在 13 后端模块内,本页的 13 模块结构不为它另立模块卡片。

几条值得单独记住的判断:

• 地基稳:单体真启、Flyway(数据库迁移)V1–V25 全绿(06-17~06-18 又叠了 V18 源项目表 / V19 aigc modify / V20 uk / V21 trade 订阅 / V22 compliance 政策+申诉 / V23 community 社交 / V24 素材 / V25 feed 限曝光)、12 份契约 yaml 锁定、project 真原子跨表发布、telemetry 真闭环——脊柱可承重,不存在 split-brain(指"代码两套各跑各的、互不一致"的脑裂状态)。
• 生成主线单独评 🟡(护城河关键路径):W-G1 worker 已实证 HJ-GEN-001 成立(便宜模型在 LittleJS 插件库里写出可真玩的轻游戏,经 7 道 CDP 真机真玩验证,单款成本 ¥0.01–0.06,远低于 ¥0.15 的成本闸)。但 worker 尚未接为默认产线,玩法模板未建,插件库还有 4 项短板(文本 HUD / grid / CCD / drag)。
• 三处合规与变现的"逻辑已真、卡在闸门":ad / trade 的业务逻辑都已是真的、有几十个单元测试,但真广告联盟 / 真支付渠道被 mock 挡着——卡的不是代码,而是 ICP 备案、支付进件、广告审核这类不可压缩的日历闸门(必须等外部审批的时间)。策略是先把逻辑建好,闸门到位即接。

结构权威的边界:本页给的是"应该怎么切"(模块边界与 T-id 注册表),不是验收清单、也不是实现设计。当结构、实现、状态三者出现冲突时,优先级是:状态 > 实现 > 结构——以 docs/mvp/MVP进度总账.md 的真 / 桩 / 未建状态为最高口径,以 docs/agent-specs/_archive/2026-06-09-核心功能技术实现方案.md 为实现细节,本页只定结构。各模块的产品出口(哪条产品需求由它实现)见需求模块映射。

---

5. 相关文档

文档	回答什么
架构域主文档	整体分层、关键技术决策的"为什么"、一条生成请求怎么跑通(本页是它 §3–4 的下钻)
生成引擎	aigc / runtime 生成主线的深层架构:SAA 节点拓扑、new-api 接入、九门 harness;另含 tier2 自治富游戏轨(spike accept)与三档生成共用的控制 / 管理面
需求模块映射	每条产品需求由哪些技术模块(T-id)实现的 M:N 映射
docs/mvp/MVP进度总账.md	13 模块真 / 桩 / 未建的实时状态(状态冲突时的最高口径)

源头长文档(需逐条考据时回溯):技术架构与模块.md(HJ-TECH-002,13 模块完整卡片与 204 项 T-id 注册表)、2026-06-17-产品功能与技术模块-完成度与优先级总账.md(逐条读码核实的完成度)。