docs(architecture): 重构为产品/技术/映射三文档 + MVP 迁移产品功能口径
- 去版本化：能力清单拆为三文档（产品需求清单/技术架构与模块/需求模块映射）， 文件名去 v2.1 版本号为唯一权威副本；删除混合视角旧档《业务能力全景与模块归属》， ~20 处交叉引用重定向（git 留史） - 模块 12→13：新增 game-module-studio（创作编排域），aigc 收敛为无状态生成原子； 锁风门 Gate(owner=compliance)、专区 Zone(owner=project) 两横切显式建模 - MVP 口径迁移：验收单位由"能力项(131)"改为 Doc A 的 55 项 P0 产品功能， 工作量≈137 技术项；CLAUDE/AGENTS/mvp-scope/执行 spec §7/工作流 全链同步 - 三轮评审（人工 + 3 独立 Opus）findings 已修复：0 断链/0 孤儿/0 重复 ID， 计数 155/204/137 实测自洽；glossary 补锁风门/专区/创作会话/资产图术语 - 新增 docs/memorys 任务记忆与 agent-specs 重划/prompt 治理评审依据 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
zizi
parent
bf457e88a6
commit
824183864e
@ -27,9 +27,9 @@
|
||||
|
||||
| 文件 | 一句话说明 |
|
||||
|---|---|
|
||||
| `knowledge/product-and-architecture.md` | 产品定位、12 模块与依赖、三仓三端架构蒸馏 |
|
||||
| `knowledge/product-and-architecture.md` | 产品定位、13 模块与依赖、三仓三端架构蒸馏 |
|
||||
| `knowledge/tech-decisions.md` | 技术栈与关键选型理由 |
|
||||
| `knowledge/mvp-scope-and-milestones.md` | MVP 的 131 项 P0 范围、里程碑与验收指标 |
|
||||
| `knowledge/mvp-scope-and-milestones.md` | MVP 的 55 项 P0 产品功能范围、里程碑与验收指标 |
|
||||
| `knowledge/glossary.md` | 术语表 |
|
||||
|
||||
**rules/**
|
||||
@ -47,6 +47,7 @@
|
||||
| `skills/ai-generation-pipeline.md` | AI 生成链路（Dify + OpenGame + aigc 壳）开发手册 |
|
||||
| `skills/runtime-and-multichannel.md` | 运行时打包、沙箱、SDK 与多渠道导出手册 |
|
||||
| `skills/contract-first-development.md` | 契约先行：契约对齐与并行解耦 |
|
||||
| `skills/prompt-governance.md` | Prompt 即第 8 契约：Registry/加载注入/eval 门禁/HITL 治理手册 |
|
||||
|
||||
**workflows/**
|
||||
|
||||
|
||||
@ -22,15 +22,19 @@
|
||||
| **降权**（低质降权） | 高跳出/加载失败/高举报的内容自动下调推荐权重（error_rate 为硬降权；report_rate 达阈值触发人工审核）。 |
|
||||
| **idempotency_key** | 幂等键，防止"重复点击生成/重复提交/MQ 重复消费/支付回调重复"导致重复处理（Redis 5min 去重 + 状态机 + 乐观锁）。 |
|
||||
| **DataPermission** | Yudao 数据权限机制，实现行级数据隔离（如创作者只看自己的项目/资产）。 |
|
||||
| **单体启动** | 12 个业务模块编译为同一 JAR（game-server），用 Spring Profile 控制模块加载；需独立扩缩时改 Nacos 配置即拆为独立微服务（Yudao Cloud 原生支持）。 |
|
||||
| **契约先行**（contract-first） | Day 0 先锁定 7 个契约文件（API/DB/SDK/GamePackage/事件/Dify IO/广告位）写入 `contracts/` 提交 git，各工位据此 mock 并行开发，联调延后至 Day 11。 |
|
||||
| **单体启动** | 13 个业务模块编译为同一 JAR（game-server），用 Spring Profile 控制模块加载；需独立扩缩时改 Nacos 配置即拆为独立微服务（Yudao Cloud 原生支持）。 |
|
||||
| **契约先行**（contract-first） | Day 0 先锁定契约文件写入 `contracts/` 提交 git，各工位据此 mock 并行开发，联调延后至 Day 11。原 7 个（API/DB/SDK/GamePackage/事件/Dify IO/广告位）+ 2026-06-07 增 **Prompt Registry** 为第 8 类契约。 |
|
||||
| **门禁（7 道）** | 创作全链路 7 道质量/合规阻断点：①Prompt 安全 ②AI 产出合规 ③资产入库版权+风格 ④组装 Schema 完整性 ⑤编译后性能（≤10MB/首屏≤2MB/无外网） ⑥预览可玩性自测 ⑦发布终审（合规+适龄）。 |
|
||||
| **Fallback 生成器**（确定性 Fallback） | LLM 不可用/超时/熔断时退化为"模板填充"的确定性生成，保证生成链路不全断。 |
|
||||
| **Game SDK 降级铁律** | Plugin 层代码全部 try-catch 包裹、异常不向游戏抛；游戏主循环（requestAnimationFrame）永不被 SDK 阻塞——"游戏稳定性 > 数据完整性"。 |
|
||||
| **WS1-WS5** | MVP 5 个工位：WS1 平台基座、WS2 AI 生成、WS3 运行时与分发、WS4 产品前端、WS5 数据与变现（详见 mvp-scope-and-milestones.md）。 |
|
||||
| **M0-M5** | MVP 6 个里程碑：M0 契约锁定 / M1 全栈可启动 / M2 创作链路 / M3 分发链路 / M4 变现链路 / M5 MVP 交付。 |
|
||||
| **三仓库** | game-cloud（后端 Yudao fork）/ game-admin（Vue3+Element Plus 管理后台）/ game-studio（Vue3+Vant 产品端），三个独立 Git 仓库。 |
|
||||
| **game-module-{name}** | 游戏领域自研业务模块统一命名；12 个：project/aigc/runtime/feed/telemetry/pay/trade/community/ip/compliance/biz/ad，按 `-api`/`-biz` 分层。 |
|
||||
| **game-module-{name}** | 游戏领域自研业务模块统一命名；13 个：studio/project/aigc/runtime/feed/telemetry/pay/trade/community/ip/compliance/biz/ad，按 `-api`/`-biz` 分层。 |
|
||||
| **锁风门 Gate**（style-lock gate） | 发布前风格/版权/性能聚合检查门，owner=compliance（T-CMP-12）；MVP 做 pass/block 二态，承载 demo"发布前检查通过才可发布"，强度策略(标准/严格/人工)为远期。 |
|
||||
| **专区 Zone（双轨）** | 广场/游戏流的双轨分区（现象级授权IP区 / UGC孵化IP区）：Zone 实体与归属 owner=project(T-PRJ-07)、分区推荐 owner=feed(T-FED-15)、发布去向 launchZone 选择。 |
|
||||
| **创作会话**（studio 会话） | studio 的有状态创作上下文（会话状态机+持久化 T-STU-01），承载草稿装配/六资产调度/任务链/附件，是 aigc 收敛后"有状态编排域"核心（区别于 aigc 无状态生成原子）。 |
|
||||
| **资产图**（Asset Graph） | studio 的多资产组合关系模型(T-STU-02)：描述图元/角色/特效/场景/界面/音乐六类资产如何组装成一款游戏；区别于"资产空间"(创作者素材仓库)。 |
|
||||
| **三种创作模式** | 覆盖小白到专业：模式 A 一句话生成（Prompt→成品，AI 主导）、模式 B 资产驱动创作（先攒资产再组装，AI 辅助单项）、模式 C 工作流编排（专业创作者在 Dify 可视化自定义节点）。 |
|
||||
| **资产空间**（Asset Workspace） | 每个创作者独立、归其所有的素材空间，含视觉/音频/设计/商业化四类资产；每类资产支持 AI 生成、手动上传、市场获取三种产出方式。 |
|
||||
| **DataPermission 之外的隔离** | 匿名玩家通过 framework 层扩展的"匿名 Token"机制接入，只能浏览试玩、不能发布/收藏/进后台。 |
|
||||
@ -42,3 +46,8 @@
|
||||
| **Golden Config 回归** | 用模板标准配置样例做比对回归，确保模型/模板迭代后生成质量不退化。 |
|
||||
| **trace_id** | Gateway 入口注入、全链路透传（含 Dify/OpenGame 调用与运行时 SDK）的追踪 ID，是调试与可观测的主线。 |
|
||||
| **DAU** | 日活跃用户；MVP 目标 1,000 DAU，正式目标 100,000 DAU。 |
|
||||
| **分层运行时（Tier1/2/3）** | 游戏产物三层（2026-06-07 二次裁决）：Tier1 极轻量H5/2D=自研 Canvas<15KB+OpenGame（MVP 唯一交付层）；Tier2 复杂2D+3D / Tier3 独立App=Cocos Creator 3.8.8+MCP（移除 Three.js）。详见 tech-decisions §1.1。 |
|
||||
| **Cocos-MCP** | 用 MCP 协议(158 工具)让 AI 驱动 Cocos Creator 3.8.8 编辑器做复杂2D/3D/原生游戏；属有状态 agentic 编排、归 studio（区别于 OpenGame 单次文生代码归 aigc）。 |
|
||||
| **Prompt Registry（Prompt 即契约）** | git `contracts/prompts/` 为全生命周期 prompt 的单一事实源（第 8 类契约）：版本化 + 输入输出 Schema 绑定 + 约束块 + Golden 集 + owner，运行时按 `id@version` 加载注入、不内嵌引擎内核。 |
|
||||
| **Prompt 轻量门禁** | prompt 改动 PR 触发的效果验证：Schema 通过率 + 生成成功率≥80% + Golden 回归 + 成本/延迟不劣化 + 人工抽检；可玩性靠行为指标反哺、不做结构化自动评分。 |
|
||||
| **T-AGC-09 测试脚本生成** | aigc 新增无状态原子：GameConfig→可玩性测试脚本，由 runtime 编译流水线执行为入库门禁（2026-06-07 prompt 治理顺带补的能力缺口 owner）。 |
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# MVP 范围与里程碑事实蒸馏
|
||||
|
||||
> 蒸馏来源：`docs/superpowers/specs/2026-06-07-mvp-execution-spec-design.md`（HJ-MVP-SPEC-001，执行权威）、`docs/architecture/2026-06-06-v2业务能力全景与模块归属.md`（§6 能力统计、§8 MVP 范围）、`docs/architecture/2026-06-06-系统概要设计-技术决策版.md`（§1.2 指标、§9 路线）、`docs/architecture/2026-06-06-v2模块架构与MVP覆盖度.md`（PRD 覆盖核对）。
|
||||
> 蒸馏来源：`docs/superpowers/specs/2026-06-07-mvp-execution-spec-design.md`（HJ-MVP-SPEC-001，执行权威）、`docs/architecture/2026-06-07-产品需求清单.md`（Doc A 产品功能）、`docs/architecture/2026-06-07-需求模块映射.md`（Doc C 需求↔模块 RTM）、`docs/architecture/2026-06-06-系统概要设计-技术决策版.md`（§1.2 指标、§9 路线）、`docs/architecture/2026-06-06-v2模块架构与MVP覆盖度.md`（PRD 覆盖核对）。
|
||||
> 目的：让后续 Agent 一篇掌握 MVP 端到端闭环、量化验收线、范围口径、5 工位分工、M0-M5 里程碑、契约先行要点。
|
||||
> 相关：架构模块见 [`product-and-architecture.md`](./product-and-architecture.md)；选型与"范围张力"见 [`tech-decisions.md`](./tech-decisions.md)；术语见 [`glossary.md`](./glossary.md)。契约先行 playbook 见 [`../skills/contract-first-development.md`](../skills/contract-first-development.md)。
|
||||
|
||||
@ -18,7 +18,7 @@
|
||||
|
||||
| 指标 | 标准 | 出处与备注 |
|
||||
|---|---|---|
|
||||
| P0 能力覆盖 | **131 / 131** 项全部可用且可验证 | 执行 spec（范围由 105 扩到 131，见下文第 4 节） |
|
||||
| **P0 产品功能覆盖** | **55 / 55** 项 Doc A 的 P0 产品功能全部可用且可验证 | Doc A 产品口径（2026-06-07 迁移，取代旧"131 能力项"线，详见 §3）|
|
||||
| 端到端链路 | 创作→生成→预览→发布→审核→游戏流→试玩→互动→广告→收益 全走通 | 执行 spec |
|
||||
| **生成成功率** | **≥ 80%**（基于 3-5 个模板，MVP 验收线） / **≥ 85%**（技术决策版蓝图远期目标） | 两个数字并存：执行 spec §1.2 与 AI 链路验收均为 **80%**；技术决策版 §1.2/§4.1 为 **85%**。**MVP 验收按 80% 判定** |
|
||||
| 游戏流首屏 | **P75 < 3s**（技术决策版另列 P95 < 6s） | 执行 spec + 技术决策版 §7.1 |
|
||||
@ -27,38 +27,48 @@
|
||||
|
||||
---
|
||||
|
||||
## 3. 能力总量与 MVP 范围口径
|
||||
## 3. MVP 范围口径（2026-06-07：迁移到「产品功能」口径）
|
||||
|
||||
能力全景去重合并后共 **299 项**独立业务能力，按优先级：
|
||||
> **重要变更**：MVP 不再用旧"能力项(299/131)"口径，改用 **Doc A 产品功能**作为验收单位（用户可感知）。三文档体系下三个独立计数互不混用：
|
||||
|
||||
| 维度 | P0 | P1 | P2 | 合计 |
|
||||
|---|---|---|---|---|
|
||||
| 全平台 | **131** | 113 | 54 | **299** |
|
||||
| 文档 | 计数单位 | 总量 | 其中 MVP |
|
||||
|---|---|---|---|
|
||||
| **Doc A 产品需求清单** | 产品功能 `P-id` | 155 | **55 项 P0**（= MVP 验收线）|
|
||||
| **Doc B 技术架构与模块** | 技术功能 `T-id` | 204 | 由 Doc C 反查（= MVP 实现范围）|
|
||||
| **Doc C 需求↔模块映射** | RTM 行 | 155 | — |
|
||||
|
||||
各模块 P0 分布（合计 131）：project 11 / aigc 16 / runtime 19 / feed 16 / telemetry 16 / pay 3 / trade 7 / community 6 / ip 1 / compliance 27 / biz 5 / ad 4。
|
||||
**MVP 验收 = Doc A 的 55 项 P0 产品功能全部走通**；其技术实现范围 = 这 55 项经 Doc C 反查到的 `T-id` 集合（不在此重复罗列，**Doc C 即唯一桥接**，改任一侧只动 Doc C）。
|
||||
|
||||
**两套范围口径（重要，存在张力）**：
|
||||
**55 项 P0 产品功能按首要 owner（Doc C）分布：**
|
||||
|
||||
- **保守口径（能力全景 §8）**：MVP = **105 项 P0 核心闭环**，仅 project(11)+aigc(16)+runtime(19)+feed(16)+telemetry(16)+compliance(27)；pay/trade/community/ip/biz/ad **仅预留接口与数据模型，不实现业务逻辑**。
|
||||
- **执行口径（mvp-execution-spec）**：MVP = **131 项 P0 全量**；pay/trade/community/ip/biz/ad 的那部分 P0（共 26 项 = 3+7+6+1+5+4）也由 **WS5 真实交付**（钱包/分成/广告/站内信/B 端表单等），非仅预留接口。
|
||||
| owner 模块 | P0 数 | owner 模块 | P0 数 |
|
||||
|---|---|---|---|
|
||||
| feed | 13 | community | 5 |
|
||||
| studio | 7 | aigc | 3 |
|
||||
| compliance | 6 | runtime | 3 |
|
||||
| biz | 6 | trade | 3 |
|
||||
| project | 5 | ad | 2 |
|
||||
| telemetry | 1 | pay | 1 |
|
||||
| ip | 0 | **合计** | **55** |
|
||||
|
||||
口径取舍：**以执行 spec 的 131 全量为准**（更新、更具体）。能力全景"仅预留接口"是更早的保守范围，已被取代。张力分析见 [`tech-decisions.md`](./tech-decisions.md) §4。
|
||||
> **demo 缺口(G1–G7)闭环骨架已并入 MVP**：双轨专区(P-PLZ-01·**P-LIC-06↑P0**)、锁风门二态(P-LIC-05·P-PUB-03)、统一发布编排+渠道状态机(P-PUB-01)、按 Zone 分区(P-PLZ-01) 均为 P0 产品功能；其后端 `T-PRJ-07/08·T-CMP-12·T-RT-32·T-FED-15` 经 Doc C 自动纳入实现范围。**编辑器精修**(骨骼/动画/对白 P-CRT-06/07·P-LIC-04)、素材双轨(P-MAT-*)、TapTap 提审、智能体多轮会话(P-CRT-05) 保持 P1 → MVP 后增量。
|
||||
> **工作量参照**：旧"131 能力项"经 12→13 模块重划后约 **137**（aigc 拆出 studio + 6 项骨架净增），仅用于 §4 人天估算；**验收口径以 55 P0 产品功能为准**。历史保守口径(能力全景 §8 的 105)已废弃。张力分析见 [`tech-decisions.md`](./tech-decisions.md) §4。
|
||||
|
||||
---
|
||||
|
||||
## 4. 5 工位编制（WS1-WS5）与职责边界
|
||||
|
||||
10 人、3 周（15 工作日），每项 P0 平均 1 人天（10×15=150 人天 > 131 项，留约 19 人天缓冲）。
|
||||
10 人、3 周（15 工作日 = 150 人天）。**验收按 55 P0 产品功能**；**人天按技术功能(T-id)工作量**估算（≈137 能力项，留约 13 人天缓冲）。下表"P0 数"为各工位 owner 模块的 **P0 产品功能数**（合计 55）。
|
||||
|
||||
| 工位 | 代号 | 人数 | 角色 | 职责边界 | 负责 P0 数 |
|
||||
| 工位 | 代号 | 人数 | 角色 | 职责边界（owner 模块）| MVP P0 产品功能数 |
|
||||
|---|---|---|---|---|---|
|
||||
| 平台基座 | **WS1** | 2 | 后端 Senior×2 | Yudao fork / Gateway / DB / CI-CD / **project / compliance** | 38（project 11 + compliance 27） |
|
||||
| AI 生成 | **WS2** | 2 | AI 工程师 + 后端 | Dify / OpenGame / ComfyUI / **aigc** / 质量门禁 | 16（aigc） |
|
||||
| 运行时与分发 | **WS3** | 2 | 后端 + 前端(SDK) | **runtime / SDK / 多渠道导出 / feed** / 互动 / 分享 | 35（runtime 19 + feed 16）+ SDK |
|
||||
| 产品前端 | **WS4** | 2 | 前端×2 | game-studio 全页面 / game-admin 审核+模板+看板（承载所有 P0 的 UI） | 全 P0 的前端表现 |
|
||||
| 数据与变现 | **WS5** | 2 | 后端 + 产品运营 | **telemetry / ad / trade / pay / community / biz** / seed / 验收 | 41（telemetry16+ad4+trade7+pay3+community6+biz5） |
|
||||
| 平台基座 | **WS1** | 2 | 后端 Senior×2 | Yudao fork / Gateway / DB / CI-CD / **project + compliance** | 11（project 5 + compliance 6）|
|
||||
| AI 生成 | **WS2** | 2 | AI 工程师 + 后端 | Dify / OpenGame / ComfyUI / **aigc + studio**（创作编排域）/ 质量门禁 | 10（aigc 3 + studio 7）|
|
||||
| 运行时与分发 | **WS3** | 2 | 后端 + 前端(SDK) | **runtime + feed** / SDK / 多渠道导出 / 互动 / 分享 | 16（runtime 3 + feed 13）|
|
||||
| 产品前端 | **WS4** | 2 | 前端×2 | game-studio 全页面 / game-admin 审核+模板+看板（**承载 55 项 P0 的 UI**）| 不单算 |
|
||||
| 数据与变现 | **WS5** | 2 | 后端 + 产品运营 | **telemetry + ad + trade + pay + community + biz** / seed / 验收 | 18（tel1+ad2+trade3+pay1+cmu5+biz6）|
|
||||
|
||||
> 注：WS1 38 + WS2 16 + WS3 35 + WS5 41 = 130；WS4 不重复计数（承载 UI）。源档 WS5 小标题「ad 4 / trade 7」与其下逐条列举（ad 列 5 条、trade 列 8 条）数目略有出入，属文案漂移，以实际契约为准。
|
||||
> 注：WS1 11 + WS2 10 + WS3 16 + WS5 18 = **55**；WS4 不重复计数（承载 UI）。**studio 为 v2.1 新增后端模块，归 WS2**（与 aigc 同工位、调用链最紧密）；其编辑器重交互在 game-studio 前端(WS4)，后端 `game-module-studio` 只持久化会话/资产图/对白树/任务链状态并编排（UX≠后端模块）。**人天**按 T-id 工作量核算（产品功能数 ≠ 人天，一项功能常展开多个 T-id）；6 项骨架净增主要压在 WS1(project/compliance)、WS3(runtime/feed)，3 周窗口可吸收。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# 产品与架构事实蒸馏
|
||||
|
||||
> 蒸馏来源：`docs/architecture/2026-06-06-系统概要设计-投资人版.md`、`docs/architecture/2026-06-06-v2业务能力全景与模块归属.md`、`docs/architecture/2026-06-06-v2架构选型审阅版.md`、`docs/architecture/2026-06-06-v2模块架构与MVP覆盖度.md`、`docs/architecture/2026-06-06-系统概要设计-技术决策版.md`、`docs/architecture/2026-06-07-系统概要设计-开发团队版.md`
|
||||
> 目的：让后续 Agent 读本篇即掌握产品定位、用户角色、分层架构、三仓库、12 模块与依赖、Yudao 复用边界、SDK 定位，不必重读原始长文档。
|
||||
> 蒸馏来源：`docs/architecture/2026-06-06-系统概要设计-投资人版.md`、`docs/architecture/2026-06-07-产品需求清单.md`、`docs/architecture/2026-06-07-技术架构与模块.md`、`docs/architecture/2026-06-07-需求模块映射.md`、`docs/architecture/2026-06-06-v2架构选型审阅版.md`、`docs/architecture/2026-06-06-v2模块架构与MVP覆盖度.md`、`docs/architecture/2026-06-06-系统概要设计-技术决策版.md`、`docs/architecture/2026-06-07-系统概要设计-开发团队版.md`
|
||||
> 目的：让后续 Agent 读本篇即掌握产品定位、用户角色、分层架构、三仓库、13 模块与依赖、Yudao 复用边界、SDK 定位，不必重读原始长文档。
|
||||
> 相关：决策见 [`tech-decisions.md`](./tech-decisions.md)；MVP 范围见 [`mvp-scope-and-milestones.md`](./mvp-scope-and-milestones.md)；术语见 [`glossary.md`](./glossary.md)。
|
||||
|
||||
---
|
||||
@ -46,10 +46,10 @@
|
||||
接入层 CDN（静态资源/游戏包） + Nginx（前端托管/SSL 终结）
|
||||
前端应用 game-studio（Vue3+Vant，创作者+玩家） / game-admin（Vue3+Element Plus，运营+管理）
|
||||
网关层 Spring Cloud Gateway（路由/限流/鉴权/灰度/CORS）
|
||||
业务服务层 12 个 game-module（project/aigc/runtime/feed/telemetry/pay/trade/community/ip/compliance/biz/ad）
|
||||
业务服务层 13 个 game-module（studio/project/aigc/runtime/feed/telemetry/pay/trade/community/ip/compliance/biz/ad）
|
||||
基础设施层 Yudao 原生：system（用户/权限/OAuth2） / infra（文件/任务/日志） / bpm（工作流 Flowable）
|
||||
AI 引擎层 Dify（DAG 编排/多模型） + OpenGame（Python 代码生成） + ComfyUI（图片素材） + Stability Audio / Fish Audio·CosyVoice（音频/音色）
|
||||
运行时栈 分层：Tier1 自研轻量 Canvas Runtime（<15KB，2D 游戏流）/ Tier2 Three.js（3D）/ Tier3 独立App 引擎待定；导出以微信小游戏格式包为枢纽；详见 tech-decisions.md §1.1
|
||||
运行时栈 分层：Tier1 自研轻量 Canvas Runtime（<15KB，2D 游戏流，OpenGame 生成）/ Tier2-3 复杂2D·3D·原生 用 Cocos Creator 3.8.8+MCP（2026-06-07 二次裁决，移除 Three.js）；导出以微信小游戏格式包为枢纽；详见 tech-decisions.md §1.1
|
||||
中间件层 Nacos / MySQL 8.0 / Redis 7 / RocketMQ 5 / MinIO（本地）·阿里云 OSS（生产）
|
||||
可观测性 Prometheus / Grafana / Sentry / Jaeger（链路追踪）
|
||||
```
|
||||
@ -70,16 +70,19 @@ AI 引擎层 Dify（DAG 编排/多模型） + OpenGame（Python 代码生成
|
||||
|
||||
后端二开原则：不改 yudao-framework 层（通过 SPI/扩展点接入，保持可升级）；新模块遵循 yudao 规范（`-api` / `-biz` 分层，VO/DTO/DO 分离）；用 DataPermission 做数据隔离；用 bpm 驱动审核流程。包命名 `cn.huijing.game.module.{模块}.{层}`。新增模块流程见 [`../skills/add-business-module.md`](../skills/add-business-module.md)。
|
||||
|
||||
**单体启动**：12 个业务模块编译为同一 JAR（`game-server`），Spring Profile 控制模块加载；需独立扩缩时改 Nacos 配置即拆为独立服务（Yudao Cloud 原生支持）。
|
||||
**单体启动**：13 个业务模块编译为同一 JAR（`game-server`），Spring Profile 控制模块加载；需独立扩缩时改 Nacos 配置即拆为独立服务（Yudao Cloud 原生支持）。
|
||||
|
||||
---
|
||||
|
||||
## 5. 12 个业务模块速查表
|
||||
## 5. 13 个业务模块速查表
|
||||
|
||||
> 2026-06-07：12→13 模块，新增 **studio**（创作编排/编辑器域），**aigc 收敛为无状态生成原子**；能力清单改为产品功能/技术功能/映射三文档分离（见 `docs/architecture/2026-06-07-产品需求清单.md`、`…-技术架构与模块.md`、`…-需求模块映射.md`）。
|
||||
|
||||
| 模块 ID | 一句话职责 | 面向端 | 被依赖 |
|
||||
|---|---|---|---|
|
||||
| studio | 创作编排/编辑器域（会话/资产图/角色 rig/对白树/任务链） | studio | — |
|
||||
| project | 游戏项目全生命周期（创建/版本/草稿/发布/审核/状态机） | studio + admin | aigc, runtime, feed, community, ip, biz, compliance |
|
||||
| aigc | AI 生成引擎（Prompt 解析/模板匹配/LLM 编排/DAG 工作流/生成任务） | studio + admin | runtime, biz |
|
||||
| aigc | 无状态生成原子（Prompt/LLM/图/音/剧情/模板/校验/风格指纹；编辑器职责已迁出 studio） | studio + admin | studio, runtime, biz |
|
||||
| runtime | 运行时与包交付（编译/打包/Manifest/沙箱/小游戏导出/调试） | studio + admin | feed, ad |
|
||||
| feed | 游戏流推荐与玩家互动（Feed/推荐/互动/举报/分享） | studio + admin | telemetry（反哺） |
|
||||
| telemetry | 遥测与数据智能（事件摄取/聚合/看板/质量评分/告警） | studio + admin | feed, aigc, trade, community |
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# 技术决策事实蒸馏（ADR 风格）
|
||||
|
||||
> 蒸馏来源：`docs/architecture/2026-06-06-系统概要设计-技术决策版.md`（§6 决策记录、§6.6/6.7/6.8 工具链，最权威）、`docs/architecture/2026-06-06-v2业务能力全景与模块归属.md`（§7 技术栈理由）、`docs/architecture/2026-06-06-v2架构选型审阅版.md`（§8 取舍、§11 待确认项）、`docs/architecture/2026-06-07-系统概要设计-开发团队版.md`、`docs/superpowers/specs/2026-06-07-mvp-execution-spec-design.md`（执行约束）。
|
||||
> 蒸馏来源：`docs/architecture/2026-06-06-系统概要设计-技术决策版.md`（§6 决策记录、§6.6/6.7/6.8 工具链，最权威）、`docs/architecture/2026-06-07-技术架构与模块.md`（各模块技术栈/边界）、`docs/architecture/2026-06-06-v2架构选型审阅版.md`（§8 取舍、§11 待确认项）、`docs/architecture/2026-06-07-系统概要设计-开发团队版.md`、`docs/superpowers/specs/2026-06-07-mvp-execution-spec-design.md`（执行约束）。
|
||||
> 目的：让后续 Agent 一篇掌握"为什么这么选、放弃了什么、风险在哪、哪些还没拍板、哪些源档互相打架"。
|
||||
> 相关：架构与模块见 [`product-and-architecture.md`](./product-and-architecture.md)；范围里程碑见 [`mvp-scope-and-milestones.md`](./mvp-scope-and-milestones.md)；术语见 [`glossary.md`](./glossary.md)；红线约束见 [`../rules/security-and-reliability.md`](../rules/security-and-reliability.md)、[`../rules/engineering-conventions.md`](../rules/engineering-conventions.md)。
|
||||
|
||||
@ -17,8 +17,8 @@
|
||||
| **前端** | Vue3 + Element Plus（game-admin）/ Vue3 + Vant（game-studio，移动优先适配 360-430px） | Element Plus 版是 Yudao 官方主推、社区最活跃、文档最全、二开友好度最高；Vant 适配游戏流滑动体验 | **React + Next.js**：与 Yudao 前端生态不一致，二开成本高（v1 用的就是 Next.js，v2 切 Vue3） | 两端两套组件库；C 端游戏流须独立 H5，admin 风格不适用 |
|
||||
| **数据库** | MySQL 8.0 | Yudao 默认，社区方案最多，迁移成本最低；需 JSONB/全文检索时再加 PostgreSQL/ES | **PostgreSQL**：JSONB/全文检索更强但 Yudao 适配成本高 | 复杂检索能力弱，靠后续叠加 ES/PG 补 |
|
||||
| **消息队列** | RocketMQ 5 | Yudao 默认集成；延迟消息/事务消息/死信队列完整，适合生成任务调度、审核通知、事件摄取、结算触发 | **Kafka**：偏大数据流、运维重，MVP 过度；**Redis Stream**：可靠性不足，无死信/事务消息 | 运维复杂度高于 Redis Stream，但生产更可靠 |
|
||||
| **游戏运行时**（分层，见 §1.1） | Tier1 自研轻量 Canvas Runtime(<15KB)；Tier2 3D 用 Three.js；Tier3 独立App引擎 MVP 后定 | 首屏极快（P75<3s），AI 生成纯 JS 直接可运行，平台完全控制沙箱/SDK 注入；Three.js 与 Tier1 同构、OpenGame 已支持直出 | **Phaser 3 全栈**：纯 2D、多渠道导出弱（仍否决）；**LayaAir 全栈**：200-500KB 过重、不适合 AI 生成；**Cocos 全栈**：项目重（但 2026 有 headless MCP，已列为 Tier3 候选）；**Unity**：AI 适配差、启动重（否决） | 复杂游戏仿真能力有限（非目标，模板约束兜底）；Tier3 引擎待定 |
|
||||
| **多渠道导出** | **以"微信小游戏格式包"为统一中转**；具体工具随 Tier3 引擎选型定（MVP 不锁单一 CLI） | 快手无专用导出接口，标准路径=导出微信包→快手开发者工具"微信格式兼容转换"；抖音有自有导出接口；导出可异步离线、不影响实时预览 | ⚠️ 旧文档"LayaAir CLI 一键含快手"为**事实错误**：LayaAir 官方平台清单无快手（2026 核实） | DevTool import 仍需真机验证；三平台各自真机 |
|
||||
| **游戏运行时**（分层，见 §1.1） | Tier1 自研轻量 Canvas Runtime(<15KB)；**Tier2/3 复杂2D·3D·原生 用 Cocos Creator 3.8.8 + MCP**（2026-06-07 二次裁决，移除 Three.js） | Tier1 首屏极快（P75<3s）、AI 生成纯 JS 直接可运行、平台完全控制沙箱；Tier2/3 用 Cocos 因 MCP(158工具)可 AI 驱动、出功能快、一栈覆盖复杂2D+3D+原生/小游戏导出 | **Three.js**：仅 web3D、与 Cocos 重复（移除）；**Phaser 3 全栈**：纯 2D、导出弱（否决）；**LayaAir**：无 MCP 生态、清单无快手（否决）；**Unity**：AI 适配差、启动重（否决） | Cocos web 包体较重(MB级)→Tier2/3 不进游戏流、走渠道/App 分发；Tier1 仍自研薄壳保首屏 |
|
||||
| **多渠道导出** | **以"微信小游戏格式包"为统一中转**；Tier2/3 用 Cocos 官方一键导出，Tier1 自研 Canvas 自做 adapter | 快手无专用导出接口，标准路径=导出微信包→快手开发者工具"微信格式兼容转换"；抖音有自有导出接口；导出可异步离线、不影响实时预览 | ⚠️ 旧文档"LayaAir CLI 一键含快手"为**事实错误**：LayaAir 官方平台清单无快手（2026 核实） | DevTool import 仍需真机验证；三平台各自真机 |
|
||||
| **AI 素材工具链** | 图片/角色/场景/封面→ComfyUI（自部署）；音乐/音效→Stability Audio API；语音/音色→Fish Audio / 阿里 CosyVoice | ComfyUI 节点化、可训 IP 风格 LoRA 出系列一致素材、可被 Dify 编排、自部署无审查/无限频、长期成本低于商用 API；Stability Audio 版权清晰（全授权训练数据）；Fish/CosyVoice 中文效果最佳、支持 few-shot 音色克隆 | 直接调 **Midjourney/DALL-E API**：无法训风格 LoRA、游戏场景（武器/战斗）易被拒、按次付费贵 | ComfyUI 需 GPU（无 GPU 走 CPU 慢 10x 或 mock/外部 API） |
|
||||
| **内容安全** | 图片→safe-content-ai（自部署快检）+ 阿里云内容安全（高风险兜底确认）；文本/音频→阿里云审核 API；AI 输出→Dify Guardrails 节点 | 自部署做首道快检（免费/低延迟），高风险样本二次送阿里云确认；阿里云违禁词库持续更新、语义强于规则；Dify 节点内做 Prompt 注入检测 + 输出 schema 校验 | 单一商用 API：成本高且首道检测延迟大 | 双层链路一致性需治理；阈值（block 0.7 / review 0.4）须在 Nacos 调优 |
|
||||
|
||||
@ -28,19 +28,19 @@
|
||||
|
||||
### 1.1 分层运行时设计（2026-06-07 创始人确认 + 运行时选型研究）
|
||||
|
||||
游戏产物分三层，对应不同运行时。**MVP 锁定 Tier1+Tier2 技术选型，Tier3 引擎推迟到 MVP 后定**；非目标保持收敛（3D/App 仅远期探针，见 §7）。
|
||||
游戏产物分三层，对应不同运行时。**2026-06-07 二次裁决：Tier1 自研 Canvas + OpenGame 生成；Tier2/3 统一用 Cocos Creator 3.8.8 + MCP，移除 Three.js。** MVP 仅交付 Tier1；非目标保持收敛（Tier2/3 仅远期探针，见 §7）。
|
||||
|
||||
| 层 | 定位 | 选型（2026-06-07） | 状态 |
|
||||
|---|---|---|---|
|
||||
| **Tier1 极轻量2D** | 游戏流即点即玩，首屏 P75<3s | **自研轻量 Canvas Runtime(<15KB)** + iframe 沙箱 + SDK 注入 | ✅ 锁定。OpenGame 直出 plain Canvas/JS，自研壳=护城河 |
|
||||
| **Tier2 3D** | 中等复杂度含 3D | **Three.js**（备选 PlayCanvas） | ✅ 锁定技术。OpenGame 已支持直出 three.js，与 Tier1 同构；MVP 至多 1 个探针 demo |
|
||||
| **Tier3 独立App** | 打包为原生应用 | 引擎**待 MVP 后定**：Cocos Creator 3.8.8(研究推荐) / LayaAir / Capacitor 包装 | ⏳ 推迟。否决 Unity（AI 适配差、启动重） |
|
||||
| 层 | 定位 | 选型（2026-06-07 二次裁决） | 生成路径 | 状态 |
|
||||
|---|---|---|---|---|
|
||||
| **Tier1 极轻量H5/2D** | 游戏流即点即玩，首屏 P75<3s | **自研轻量 Canvas Runtime(<15KB)** + iframe 沙箱 + SDK 注入 | **OpenGame** 文生代码 | ✅ 锁定。直出 plain Canvas/JS，自研壳=护城河，**MVP 唯一交付层** |
|
||||
| **Tier2 复杂2D+3D** | 中重度含 3D，渠道分发 | **Cocos Creator 3.8.8 + MCP**（备选 PlayCanvas） | **Cocos-MCP** agentic 工具编排（studio 编排） | ✅ 锁定。MCP 158 工具可 AI 驱动；MVP 至多 1 个探针 demo |
|
||||
| **Tier3 独立App** | 打包为原生应用 | **Cocos 原生导出**（同 Tier2 引擎） | 同 Tier2 + 打包 | ✅ 锁定引擎。否决 Unity（AI 适配差、启动重）；MVP 后投入 |
|
||||
|
||||
**自研工期评估（为什么不自研 Tier2/Tier3）**：Tier1 薄壳约 0.5–1.5 人月（可行，且必须自研以控沙箱/SDK/三容器预加载）；自研 3D 引擎数十人月~数年、自研原生框架数十人月——3 周窗口下绝不可行，必须复用成熟引擎（与"开源组合替代烧钱自研"总原则一致）。
|
||||
**自研工期评估（为什么 Tier2/3 复用 Cocos 而非自研）**：Tier1 薄壳约 0.5–1.5 人月（可行，且必须自研以控沙箱/SDK/三容器预加载）；自研 3D 引擎数十人月~数年、自研原生框架数十人月——3 周窗口下绝不可行，必须复用成熟引擎。选 Cocos 因其一栈覆盖复杂2D+3D+原生/小游戏导出，且 MCP(158工具)使 AI 驱动可行（与"开源组合替代烧钱自研"总原则一致）。
|
||||
|
||||
**导出枢纽 = 微信小游戏格式包**（修正既有事实错误）：微信=引擎导出官方格式；抖音=自有导出接口；**快手=无专用接口，走"微信格式兼容转换"**（快手开发者工具）。⚠️ 旧文档称"LayaAir CLI 一键含快手"为事实错误——**LayaAir 官方平台清单无快手**（2026 核实）。具体导出工具随 Tier3 引擎选型确定，MVP 不锁单一工具。
|
||||
**导出枢纽 = 微信小游戏格式包**（修正既有事实错误）：微信=引擎导出官方格式；抖音=自有导出接口；**快手=无专用接口，走"微信格式兼容转换"**（快手开发者工具）。⚠️ 旧文档称"LayaAir CLI 一键含快手"为事实错误——**LayaAir 官方平台清单无快手**（2026 核实）。Tier2/3 用 Cocos 官方一键导出微信包，Tier1 自研 Canvas 自做 adapter。
|
||||
|
||||
> 研究依据（2026-06 核实）：Three.js r184/MIT/113k★（周级维护）；Cocos 3.8.8/MIT + headless MCP(158 工具) 使 AI 适配可行；LayaAir 2.1k★、无 AI/MCP 生态、清单无快手；Unity 启动 7-10s×2-3 与 P75<3s 冲突。属跨模块/改用户可见行为级决策，已按协议先评审后落地。
|
||||
> 研究依据（2026-06 核实）：Cocos 3.8.8/MIT + headless MCP(158 工具) 使 AI 驱动游戏开发可行、出功能快、一栈覆盖2D/3D/原生导出，故 Tier2/3 统一选 Cocos；Three.js r184/MIT/113k★ 仅 web3D、与 Cocos 重复故移除；LayaAir 2.1k★、无 AI/MCP 生态、清单无快手（否决）；Unity 启动 7-10s×2-3 与 P75<3s 冲突（否决）。属跨模块/改用户可见行为级决策，已按协议先评审后落地。
|
||||
|
||||
---
|
||||
|
||||
@ -60,7 +60,7 @@
|
||||
| 2 | v1 运行时资产移植方式 | Canvas2D 渲染 + 小游戏转换逻辑：移植为 Java 服务，还是保留 Node 微服务 | 选型审阅版 §11.2 |
|
||||
| 3 | 产品端域名方案 | game-studio 与 game-admin 同域不同路径，还是不同子域名 | 选型审阅版 §11.3 |
|
||||
| 4 | MVP 登录方式 | 手机号验证码 / 邮箱+密码 / 微信扫码（均经 Yudao OAuth2/SMS 支持） | 选型审阅版 §11.4 |
|
||||
| 5 | **Tier3 独立App 运行时引擎** | Cocos Creator 3.8.8（研究推荐，2026 已有 headless MCP）/ LayaAir / Web 包装(Capacitor)；**MVP 后定** | 2026-06-07 运行时选型研究 |
|
||||
| 5 | ~~Tier3 独立App 运行时引擎~~ | **✅ 已确认（2026-06-07 二次裁决）：Cocos Creator 3.8.8 + MCP 统一 Tier2/3、移除 Three.js（见 §1.1）** | 2026-06-07 运行时选型研究 |
|
||||
|
||||
---
|
||||
|
||||
@ -70,12 +70,14 @@
|
||||
|
||||
| 张力点 | 各源档表述 | 冲突实质 | 建议以哪份为准 |
|
||||
|---|---|---|---|
|
||||
| **运行时技术栈** | 能力全景+投资人版写 Phaser 3；技术决策版/开发团队版写自研轻量 Canvas+LayaAir | 早期 Phaser3 与后期自研轻量不一致 | **✅ 已确认(2026-06-07)：升级为分层运行时（见 §1.1）。** Tier1=自研<15KB Canvas、Tier2=Three.js 锁定；Tier3 引擎推迟 MVP 后；Phaser3 全栈仍否决；LayaAir 降为 Tier3 候选之一（且无快手） |
|
||||
| **运行时技术栈** | 能力全景+投资人版写 Phaser 3；技术决策版/开发团队版写自研轻量 Canvas+LayaAir | 早期 Phaser3 与后期自研轻量不一致 | **✅ 二次裁决(2026-06-07)：Tier1=自研<15KB Canvas+OpenGame；Tier2/3=Cocos Creator 3.8.8+MCP，移除 Three.js（见 §1.1）。** 一次裁决曾定 Tier2=Three.js，因 Cocos 一栈覆盖2D/3D/原生+MCP 可 AI 驱动而被取代；Phaser3/LayaAir/Unity 仍否决 |
|
||||
| **生成成功率指标** | 技术决策版 §1.2/§4.1：**≥ 85%**；执行 spec §1.2 验收 + AI 生成链路验收：**≥ 80%**（基于 3-5 个模板） | 蓝图目标值 vs MVP 验收值口径不同（85% 是远期目标，80% 是 3 周 MVP 验收线） | **✅ 已确认(2026-06-07)：80% 验收 / 85% 蓝图并存。** 验收按 80% 判定，勿用 85% 卡 MVP |
|
||||
| **时间线** | 技术决策版 §9 + 投资人版：**约 11 周（5 人，5 个 Phase）**；执行 spec：**10 人 × 3 周（15 工作日）131 项 P0 全量** | 两套并存的实施节奏（11 周/5 人 vs 3 周/10 人），人力与周期完全不同 | 执行排期**以 mvp-execution-spec 为准**（更新、最具体、含逐日计划与里程碑）；11 周版作为更宽松的备用蓝图 |
|
||||
| **MVP 范围** | 能力全景 §8：**MVP = 105 项 P0 核心闭环**（project+aigc+runtime+feed+telemetry+compliance），pay/trade/community/ip/biz/ad **仅预留接口与数据模型，不实现业务逻辑**；执行 spec：**131 项 P0 全量交付**，pay/trade/community/ip/biz/ad 的部分 P0 由 WS5 真实交付 | 范围被执行 spec 从 105 扩到 131；"仅预留接口"的旧表述与"WS5 真实交付变现/社区/B 端 P0"冲突 | **✅ 已确认(2026-06-07)：以 131 全量为准**；能力全景"仅预留接口"是更早、更保守的范围，已被执行 spec 取代。详见 [`mvp-scope-and-milestones.md`](./mvp-scope-and-milestones.md) |
|
||||
| **时间线** | 技术决策版 §9 + 投资人版：**约 11 周（5 人，5 个 Phase）**；执行 spec：**10 人 × 3 周（15 工作日）；MVP 验收 = 55 项 P0 产品功能（原 131 能力项，工作量≈137）** | 两套并存的实施节奏（11 周/5 人 vs 3 周/10 人），人力与周期完全不同 | 执行排期**以 mvp-execution-spec 为准**（更新、最具体、含逐日计划与里程碑）；11 周版作为更宽松的备用蓝图 |
|
||||
| **MVP 范围/口径** | 历史口径并存：能力全景 §8 = 105 P0（仅 6 模块实现）；执行 spec = 131 P0 能力项全量；**2026-06-07 迁移 = Doc A 的 55 项 P0 产品功能** | 计数单位历经"能力项→产品功能"迁移；105/131/137 均为旧"能力项"口径，55 为新"产品功能"口径，**勿混用** | **✅ 已确认(2026-06-07)：MVP 验收以 Doc A 的 55 项 P0 产品功能为准**；技术实现范围经 Doc C 反查 Doc B（工作量≈137 能力项）。105"仅预留接口"口径废弃。详见 [`mvp-scope-and-milestones.md`](./mvp-scope-and-milestones.md) §3 |
|
||||
|
||||
其他次要不一致（非阻塞，提示存在即可）：开发团队版内 Dify 端口在 §1.3 与 §10/速查链接间有 3000/3001 漂移、后端端口有 48080/48090 漂移；执行 spec §7 中 WS5「ad 4 项 / trade 7 项」的小标题与其下逐条列举（ad 实列 5 条、trade 实列 8 条）数目对不上——均属文案层面，以实际契约/Swagger 为准。
|
||||
**模块划分（2026-06-07 已定）**：v2.0《业务能力全景》为 12 模块且混合产品/技术能力；v2.1 重划为 **13 模块**（新增 game-module-studio 创作编排域、aigc 收敛为无状态生成原子），并把能力清单拆为**产品功能(Doc A)/技术功能(Doc B)/映射(Doc C)** 三文档分离（`docs/architecture/2026-06-07-{产品需求清单,技术架构与模块,需求模块映射}.md`，评审依据 `docs/agent-specs/2026-06-07-模块重划分-review.md`）。引用模块数（12 vs 13）与能力归属以 v2.1 为准。
|
||||
|
||||
其他次要不一致（非阻塞，提示存在即可）：开发团队版内 Dify 端口在 §1.3 与 §10/速查链接间有 3000/3001 漂移、后端端口有 48080/48090 漂移；执行 spec §7 多个模块（compliance/feed/telemetry/ad/trade 等）的小标题数与其下逐条列举存在 ±1 文案漂移（community 缺项已补）——均属文案层面，以实际契约/Swagger 为准。
|
||||
|
||||
---
|
||||
|
||||
@ -104,4 +106,4 @@
|
||||
|
||||
**MVP/近期非目标（保持收敛，2026-06-07 确认）**：MVP 不做 3D、不做专业级游戏引擎（Unity/Unreal 级）、不做海外市场；不做完全开放式代码生成（模板约束——创作者通过**配置**而非写 JS 驱动游戏）；不自研大模型（接入通用 LLM + 开源 Agent 框架）。
|
||||
|
||||
**远期分层路线（仅探针，不进 MVP）**：Tier2 3D（Three.js）、Tier3 独立App（引擎待定，见 §1.1）为远期方向；MVP 至多做 1 个 Three.js 探针验证链路可行性，不投入工程。**Unity 始终否决。**
|
||||
**远期分层路线（仅探针，不进 MVP）**：Tier2 复杂2D+3D、Tier3 独立App（统一 Cocos+MCP，见 §1.1）为远期方向；MVP 至多做 1 个 Cocos-MCP 探针验证链路可行性，不投入工程。**Unity 始终否决。**
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# 安全、合规、可靠性与一致性硬底线
|
||||
|
||||
> 本文是绘境AI 不可逾越的**红线**。涉及安全、合规、幂等、一致性、可靠性、可观测性与 SDK 降级。任何设计/实现违反即驳回。
|
||||
> 蒸馏来源：`docs/architecture/2026-06-06-系统概要设计-技术决策版.md`（§3.4 SDK 降级 / §7.1-7.5 非功能 / §8 风险）、`docs/architecture/2026-06-07-系统概要设计-开发团队版.md`（§4.2 / §10.5 内容安全）、`docs/architecture/2026-06-06-v2业务能力全景与模块归属.md`（§3.10 compliance 27 项 P0）。
|
||||
> 蒸馏来源：`docs/architecture/2026-06-06-系统概要设计-技术决策版.md`（§3.4 SDK 降级 / §7.1-7.5 非功能 / §8 风险）、`docs/architecture/2026-06-07-系统概要设计-开发团队版.md`（§4.2 / §10.5 内容安全）、`docs/architecture/2026-06-07-技术架构与模块.md`（compliance 模块 T-CMP-* 技术功能，含锁风门 Gate）。
|
||||
> 配套：编码/契约规范见 [`engineering-conventions.md`](engineering-conventions.md)；元流程见 [`../workflows/ai-development-protocol.md`](../workflows/ai-development-protocol.md)；事实蓝图见 [`../knowledge/product-and-architecture.md`](../knowledge/product-and-architecture.md)；运行时/沙箱手册见 [`../skills/runtime-and-multichannel.md`](../skills/runtime-and-multichannel.md)。
|
||||
|
||||
---
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# AI 生成链路开发与联调手册（ai-generation-pipeline）
|
||||
|
||||
> 蒸馏来源：`docs/architecture/2026-06-06-系统概要设计-技术决策版.md`（§4.1 AI 生成链路 / §6.2 §6.7 选型 / §7.10 产物缓存 / §8 风险）、`docs/architecture/2026-06-06-v2业务能力全景与模块归属.md`（3.2 aigc 能力清单）、`docs/architecture/2026-06-07-系统概要设计-开发团队版.md`（§10 外部工具层开发指南 / §6.2 联调）。
|
||||
> 蒸馏来源：`docs/architecture/2026-06-06-系统概要设计-技术决策版.md`（§4.1 AI 生成链路 / §6.2 §6.7 选型 / §7.10 产物缓存 / §8 风险）、`docs/architecture/2026-06-07-技术架构与模块.md`（aigc/studio 模块 T-AGC-*/T-STU-* 技术功能）、`docs/architecture/2026-06-07-系统概要设计-开发团队版.md`（§10 外部工具层开发指南 / §6.2 联调）。
|
||||
> 适用：开发/调试 aigc 模块与其外部 AI 引擎（Dify / OpenGame / ComfyUI）。
|
||||
> 配套：降级/可靠性红线见 [`../rules/security-and-reliability.md`](../rules/security-and-reliability.md)；选型背景见 [`../knowledge/tech-decisions.md`](../knowledge/tech-decisions.md)；模块全景见 [`../knowledge/product-and-architecture.md`](../knowledge/product-and-architecture.md)；新模块流程见 [`./add-business-module.md`](./add-business-module.md)；契约见 [`./contract-first-development.md`](./contract-first-development.md)。
|
||||
|
||||
@ -43,6 +43,8 @@
|
||||
```
|
||||
|
||||
> 分工铁律：企业级监控/链路 trace/高并发优化都在 **Dify 壳外侧（Java 壳）** 做，**不改 Dify/OpenGame 内核**，保证可升级、可替换（技术决策版 §6.2）。
|
||||
>
|
||||
> **本手册聚焦 Tier1（OpenGame 文生代码 → 自研 Canvas Runtime）。** Tier2/3 复杂2D·3D·原生游戏走 **Cocos-MCP**（agentic 工具编排，归 studio，见 [`../knowledge/tech-decisions.md`](../knowledge/tech-decisions.md) §1.1），非本手册范围。所有节点 prompt 统一取自 **Prompt Registry**（git `contracts/prompts/`，第 8 类契约，按 `id@version` 加载注入、不内嵌 Dify/OpenGame 内核）；改 prompt 走 PR + eval 门禁，详见 [`../../docs/agent-specs/2026-06-07-prompt治理体系-review.md`](../../docs/agent-specs/2026-06-07-prompt治理体系-review.md)。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@
|
||||
|
||||
## 前置
|
||||
|
||||
- 已读 [`../knowledge/product-and-architecture.md`](../knowledge/product-and-architecture.md)，对齐 12 模块边界与端（`/app` vs `/admin`）。
|
||||
- 已读 [`../knowledge/product-and-architecture.md`](../knowledge/product-and-architecture.md)，对齐 13 模块边界与端（`/app` vs `/admin`）。
|
||||
- 工位划分明确（MVP spec：WS1 基座 / WS2 AI / WS3 运行时+SDK / WS4 前端 / WS5 数据变现）。
|
||||
|
||||
---
|
||||
|
||||
148
.agents/skills/prompt-governance.md
Normal file
148
.agents/skills/prompt-governance.md
Normal file
@ -0,0 +1,148 @@
|
||||
# Prompt 工程治理手册（prompt-governance）
|
||||
|
||||
> 蒸馏来源：评审版 [`../../docs/agent-specs/2026-06-07-prompt治理体系-review.md`](../../docs/agent-specs/2026-06-07-prompt治理体系-review.md)（HJ-PROMPT-GOV-001，2026-06-07 六项裁决全采纳 a）。
|
||||
> 适用：新增/修改任何生命周期 prompt（意图/代码生成/素材/剧情/锁风/测试/平台转换/运营诊断）、搭建 Prompt Registry 与 eval 门禁、对接人在环（HITL）节点。
|
||||
> 配套：契约先行见 [`./contract-first-development.md`](./contract-first-development.md)；AI 生成链路见 [`./ai-generation-pipeline.md`](./ai-generation-pipeline.md)；运行时/Cocos 见 [`./runtime-and-multichannel.md`](./runtime-and-multichannel.md)；选型见 [`../knowledge/tech-decisions.md`](../knowledge/tech-decisions.md) §1.1；降级红线见 [`../rules/security-and-reliability.md`](../rules/security-and-reliability.md)。
|
||||
|
||||
---
|
||||
|
||||
## 核心理念：Prompt 即第 8 类契约资产
|
||||
|
||||
所有 prompt 进 git `contracts/prompts/` **单一事实源**，与 Day-0 七契约同级。每条 prompt 绑定一份完整契约：`输入 Schema + 输出 Schema + 硬约束块 + Golden 样本集 + owner + version`。**运行时按 `id@version` 加载注入，不在 Dify/OpenGame/Cocos 内核里内嵌**——延续"能力增强放壳层、不动内核"的纪律（与 ai-generation-pipeline 同源）。
|
||||
|
||||
> 为什么必须治理：双引擎（OpenGame + Cocos-MCP）使 prompt 数量与形态膨胀；无单一事实源 → 跨引擎无法统一治理、改动无法回归验证。
|
||||
|
||||
---
|
||||
|
||||
## 1. Registry 目录结构
|
||||
|
||||
```
|
||||
contracts/prompts/
|
||||
├── registry.yaml # 索引：所有 prompt 的 id/版本/owner/绑定 schema/eval 集
|
||||
├── _schemas/ # 输入/输出 JSON Schema（prompt 的契约）
|
||||
├── intent/ # 意图解析、模板匹配（owner=aigc）
|
||||
├── codegen-opengame/ # Tier1 文生代码（owner=aigc）
|
||||
├── codegen-cocos-mcp/ # Tier2/3 agentic 工具编排（owner=studio）
|
||||
├── asset/ # 素材生成（图/音/角色/特效）+ IP LoRA 约束（owner=aigc）
|
||||
├── narrative/ # 剧情/分支对白/关卡（owner=studio）
|
||||
├── lockstyle/ # 锁风约束（风格-版权一致性，owner=compliance）
|
||||
├── qa/ # 测试用例 + 可玩性脚本（owner=aigc，T-AGC-09）
|
||||
├── convert/ # 打包/平台转换约束（尺寸/资质/违禁词，owner=runtime）
|
||||
└── ops/ # AI 诊断/改版任务（owner=telemetry）
|
||||
```
|
||||
|
||||
每条 prompt = frontmatter 契约头 + 模板体：
|
||||
|
||||
```yaml
|
||||
---
|
||||
id: codegen-opengame.scaffold # 唯一 id（目录.阶段）
|
||||
version: 1.2.0 # 语义化版本
|
||||
owner: WS2/aigc # 唯一负责工位/模块
|
||||
tier: tier1 # tier1 | tier2 | tier3
|
||||
engine: opengame # opengame | cocos-mcp | dify | comfyui | runtime
|
||||
stage: scaffold
|
||||
input_schema: _schemas/codegen-input.json
|
||||
output_schema: _schemas/game-config.json
|
||||
constraints: # 硬约束块（产物必须满足）
|
||||
- 首屏≤2MB, 总包≤10MB
|
||||
- 游戏内零网络请求（CSP connect-src none）
|
||||
eval_set: eval/codegen-opengame.scaffold/
|
||||
guardrails: [injection-detect, schema-validate, asset-ref-check]
|
||||
---
|
||||
{{system_prompt}}
|
||||
... 模板体，带 {{变量槽}} ...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. 加载 / 注入机制
|
||||
|
||||
- **aigc / studio 壳层** 持有 `PromptRegistryLoader`：按 `id@version` 取 prompt 文本并用变量渲染。
|
||||
- **Dify 节点**：prompt 用 `{{registry:intent.parse@1.2.0}}` 引用，壳层调用前注入实际文本。
|
||||
- **OpenGame / Cocos-MCP / ComfyUI**：壳层把对应 prompt 作为参数/ system prompt 传入。
|
||||
- **DB 镜像（可选）**：只读，仅为运行时热加载提速；写入路径唯一为 git。
|
||||
|
||||
> 部署时强制校验 registry 版本一致；CI 卡 Schema。改 prompt = 改 git → PR → eval 门禁 → 合入 → 同步运行时。
|
||||
|
||||
---
|
||||
|
||||
## 3. 两套 Prompt 形态
|
||||
|
||||
| 维度 | OpenGame prompt（Tier1） | Cocos-MCP prompt（Tier2/3） |
|
||||
|---|---|---|
|
||||
| 形态 | 生成式：文本 → 游戏代码 | agentic：驱动 158 个编辑器工具的工具编排 |
|
||||
| 调用 | 单次/6 阶段 pipeline | 多步、有状态、多轮工具调用 |
|
||||
| 归属 | **aigc**（无状态生成原子） | **studio**（有状态创作编排，T-STU-05） |
|
||||
| 失败降级 | 退化为模板填充 | 退化为 Tier1/OpenGame；MVP 仅探针 |
|
||||
|
||||
> 目录分治（`codegen-opengame/` vs `codegen-cocos-mcp/`），加载器按 `engine` 字段分发，不强行统一模板。
|
||||
|
||||
---
|
||||
|
||||
## 4. 新增一条 Prompt（操作步骤）
|
||||
|
||||
1. 在对应阶段目录建 prompt 文件，写全 frontmatter（id/version/owner/tier/engine/stage）。
|
||||
2. 定义或复用 `_schemas/` 下的输入/输出 JSON Schema，frontmatter 绑定。
|
||||
3. 写硬约束块 + guardrails（注入检测/Schema 校验/资源引用校验）。
|
||||
4. 建 Golden eval 集 `eval/<id>/`：`inputs.jsonl`（5–10 条核心样本）+ `expect.yaml`（期望属性/阈值）+ `baseline/`（基线产物快照）。
|
||||
5. 在 `registry.yaml` 登记索引。
|
||||
6. 提 PR → eval 门禁绿 + 人工抽检 → 合入 → 部署同步。
|
||||
|
||||
## 5. 修改一条 Prompt 并验证效果（操作步骤）
|
||||
|
||||
1. 改 prompt 文件，**version 必须 bump**（语义化）。
|
||||
2. PR 触发 eval：跑绑定的 Golden 集 → 四道闸比对（见 §6）。
|
||||
3. 全绿 + 人工抽检 K 条 → 合入；任一红 → 阻断 PR + 给 diff 报告。
|
||||
4. 合入后**灰度新版本** → 观察 telemetry 行为指标（完玩/重玩率）→ 全量或一键回滚（version 切换）。
|
||||
|
||||
> 常用 prompt 预留**参数槽**：运营改参数（如难度/时长）不改结构，免 PR；改结构才走 PR+eval。
|
||||
|
||||
---
|
||||
|
||||
## 6. Eval 轻量门禁（四道闸）
|
||||
|
||||
| 闸 | 判定 | 来源 |
|
||||
|---|---|---|
|
||||
| ① Schema 通过率 | 输出符合 output_schema 的比例 ≥ 阈值 | 评审版 §4.4 |
|
||||
| ② 生成成功率 | 可运行 + 质量通过 ≥ **80%** | MVP 验收线 |
|
||||
| ③ Golden 回归 | 与 `baseline/` 关键字段 diff，防退化 | 泛化自 T-AGC-08 |
|
||||
| ④ 成本/延迟 | token/耗时不劣化 | 评审版 §4.4 |
|
||||
|
||||
四闸全绿 → 人工抽检 K 条（主观质量/可玩性）→ 合入。**可玩性 MVP 不自动评分**（结构校验测不了"好玩"），靠人工抽检 + 上线后行为指标反哺下一轮。
|
||||
|
||||
---
|
||||
|
||||
## 7. HITL 人在环节点
|
||||
|
||||
- **创作者（C 端·每次生成）**：输入一句话/选 IP 附件 → 任务链进度可中断 → 预览试玩 → 接受/带修改重生成 → 锁风强度 → 对白调试 → 发布前检查 → AI 诊断一键迭代。（P-CRT-01/04/05/08/09、P-LIC-04/05、P-PUB-03、P-OPS-03/04）
|
||||
- **运营（B 端·Prompt 生命周期）**：提 PR 改 prompt → eval 门禁+人工抽检批准 → 模板库策展 → 人工复核队列（T-CMP-05）→ 新版灰度+回滚。
|
||||
|
||||
---
|
||||
|
||||
## 8. 测试脚本生成（T-AGC-09）
|
||||
|
||||
aigc 新增**无状态原子**：输入 GameConfig → 输出可玩性测试脚本（启动/输入响应/边界）；由 **runtime 编译流水线执行**为入库门禁的一环。其 prompt 归 `contracts/prompts/qa/`。不新增模块。
|
||||
|
||||
---
|
||||
|
||||
## 9. 降级铁律
|
||||
|
||||
| 失败点 | 降级 |
|
||||
|---|---|
|
||||
| prompt 加载失败（缺 id/version） | 回退**内置默认 prompt** + 告警，不中断生成 |
|
||||
| LLM 不可用 | 退化为确定性 Fallback 生成器（模板填充，见 ai-generation-pipeline §7） |
|
||||
| Cocos-MCP 工具调用失败 | 降级 Tier1/OpenGame 路径；MVP Tier2/3 仅探针 |
|
||||
| eval CI 跑不通（LLM 限流） | 标记 skip + 人工兜底审，不阻塞紧急修复 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 常见坑
|
||||
|
||||
| 坑 | 排查 / 应对 |
|
||||
|---|---|
|
||||
| 改了 prompt 没 bump version | CI 卡：version 未变拒绝合入（防静默覆盖） |
|
||||
| Golden 集过拟合 | 样本要覆盖典型+边界，bad case 增量补；勿只放"好跑"的样本 |
|
||||
| registry 与运行时不同步 | 部署强制版本校验；DB 镜像只读；改 prompt 必同步 registry.yaml |
|
||||
| Cocos-MCP prompt 当文生代码写 | 它是 agentic 工具编排（多步），不是单次文本；归 studio 编排 |
|
||||
| 运营绕过 eval 直接改 DB | DB 是 git 只读镜像，无写入路径；改 prompt 唯一入口=PR |
|
||||
| prompt 注入攻击 | guardrails 内置 injection-detect + 输出 Schema 校验，与内容安全双层链路同治理 |
|
||||
@ -1,6 +1,6 @@
|
||||
# 运行时、Game SDK 与多渠道导出手册（runtime-and-multichannel）
|
||||
|
||||
> 蒸馏来源：`docs/architecture/2026-06-06-系统概要设计-技术决策版.md`（§3.4 Game SDK / §4.2 运行时三容器 / §6.6 运行时与导出选型）、`docs/architecture/2026-06-06-v2业务能力全景与模块归属.md`（3.3 runtime 能力清单）、`docs/architecture/2026-06-07-系统概要设计-开发团队版.md`（§2 模块地图 / §10.4 LayaAir CLI）。
|
||||
> 蒸馏来源：`docs/architecture/2026-06-06-系统概要设计-技术决策版.md`（§3.4 Game SDK / §4.2 运行时三容器 / §6.6 运行时与导出选型）、`docs/architecture/2026-06-07-技术架构与模块.md`（runtime 模块 T-RT-* 技术功能）、`docs/architecture/2026-06-07-系统概要设计-开发团队版.md`（§2 模块地图 / §10.4 LayaAir CLI）。
|
||||
> 适用：开发/调试 runtime 模块、HuijingGameSDK、多渠道（微信/抖音/快手）小游戏导出。
|
||||
> 配套：SDK 降级铁律与沙箱安全红线见 [`../rules/security-and-reliability.md`](../rules/security-and-reliability.md)；工程规范见 [`../rules/engineering-conventions.md`](../rules/engineering-conventions.md)；架构全景见 [`../knowledge/product-and-architecture.md`](../knowledge/product-and-architecture.md)；上游生成见 [`./ai-generation-pipeline.md`](./ai-generation-pipeline.md)；契约见 [`./contract-first-development.md`](./contract-first-development.md)。
|
||||
|
||||
@ -12,7 +12,7 @@
|
||||
|
||||
## 前置
|
||||
|
||||
- OSS（本地 MinIO）+ CDN 可用。导出工具随 Tier3 引擎选型确定（见 [`../knowledge/tech-decisions.md`](../knowledge/tech-decisions.md) §1.1），MVP 不锁定单一 CLI。
|
||||
- OSS（本地 MinIO）+ CDN 可用。Tier2/3 用 Cocos 官方一键导出微信包，Tier1 自研 Canvas 自做 adapter（见 [`../knowledge/tech-decisions.md`](../knowledge/tech-decisions.md) §1.1）。
|
||||
- SDK Core 体积达标（< 8KB 压缩）；上游 aigc 产出的 GamePackage 符合 `game-package.schema.json` 契约。
|
||||
|
||||
---
|
||||
@ -25,11 +25,11 @@
|
||||
| Manifest 生成 | runtimeVersion / configUrl / assetList / hash / preloadPolicy / bundleSize |
|
||||
| 包存储版本化 | `service/package/`：checksum(sha256) + CDN，路径 `/games/{gameId}/versions/{versionId}/` |
|
||||
| 预览交付端点 | `controller/app/`：按版本返回 manifest + 资源 URL（`GET /app/runtime/preview/:versionId`） |
|
||||
| 多渠道转换 | `service/conversion/`：导出微信小游戏格式包为枢纽 → 抖音(自有接口)/快手(微信格式兼容转换)；工具随 Tier3 选型定 |
|
||||
| 多渠道转换 | `service/conversion/`：导出微信小游戏格式包为枢纽 → 抖音(自有接口)/快手(微信格式兼容转换)；Tier2/3 用 Cocos 官方导出、Tier1 自研 adapter |
|
||||
|
||||
渲染层：**自研轻量 Canvas Runtime（< 15KB）**，iframe sandbox + SDK Core 注入，AI 生成的纯 JS 直接可运行，平台完全控制沙箱（技术决策版 §6.6）。
|
||||
|
||||
> 本手册聚焦 **Tier1（极轻量 2D，游戏流）**。分层运行时（Tier1 2D / Tier2 Three.js 3D / Tier3 独立App）见 [`../knowledge/tech-decisions.md`](../knowledge/tech-decisions.md) §1.1。
|
||||
> 本手册聚焦 **Tier1（极轻量 2D，游戏流，OpenGame 生成）**。分层运行时（Tier1 自研Canvas / Tier2-3 复杂2D·3D·原生用 Cocos+MCP，2026-06-07 移除 Three.js）见 [`../knowledge/tech-decisions.md`](../knowledge/tech-decisions.md) §1.1。
|
||||
|
||||
---
|
||||
|
||||
@ -116,7 +116,7 @@ runtime 编译 GamePackage 时：
|
||||
|
||||
> ⚠️ **事实纠错**：旧文档（含开发团队版 §10.4）称 `layaair2-cmd publish -p kuaishou` 一键导出快手——**LayaAir 官方平台清单无快手**。快手统一走"微信格式包兼容转换"。"统一工具链"实质 = 统一产出微信格式包，再分发抖音/快手。详见 [`../knowledge/tech-decisions.md`](../knowledge/tech-decisions.md) §1.1。
|
||||
|
||||
**导出工具随 Tier3 引擎选型确定**（Cocos 官方一键 / Three.js 社区 adapter / 自研 Canvas 自做 adapter 均可产出微信包），MVP **不锁定单一 CLI**。Java（runtime `service/conversion/`）统一以 `ProcessBuilder` 调用所选工具 → 异步等待进程 → 产物上传 OSS。
|
||||
**导出工具（2026-06-07 已定）**：Tier2/3 用 **Cocos 官方一键**导出微信包，Tier1 自研 Canvas 自做 adapter。Java（runtime `service/conversion/`）统一以 `ProcessBuilder` 调用对应工具 → 异步等待进程 → 产物上传 OSS。
|
||||
|
||||
渠道适配器（开发团队版 §2.1）各自处理**尺寸 / 资质 / 文案 / 违禁词**：
|
||||
- `WechatAdapter.java` — 微信小游戏适配规则
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# MVP 执行编排与复利提效（mvp-execution-orchestration）
|
||||
|
||||
> 适用：以 AI Agent 编排方式交付 MVP——**10 个 Agent × 3 周（15 工作日）× 131 项 P0**。本篇是"我（编排者）怎么把活分下去、怎么让效率随推进**复利增长**"的作战手册。
|
||||
> 适用：以 AI Agent 编排方式交付 MVP——**10 个 Agent × 3 周（15 工作日）× 55 项 P0 产品功能（工作量≈137 技术项）**。本篇是"我（编排者）怎么把活分下去、怎么让效率随推进**复利增长**"的作战手册。
|
||||
> 决策来源：创始人确认（2026-06-07）——"你是执行者，10 人 = 10 个 Agent，3 周交付 MVP；规划如何做、如何复利提效。"
|
||||
> 配套：承接任意任务的通用流程见 [`./ai-development-protocol.md`](./ai-development-protocol.md)；工位/范围/里程碑见 [`../knowledge/mvp-scope-and-milestones.md`](../knowledge/mvp-scope-and-milestones.md)；契约先行见 [`../skills/contract-first-development.md`](../skills/contract-first-development.md)；新增模块见 [`../skills/add-business-module.md`](../skills/add-business-module.md)。
|
||||
|
||||
@ -89,4 +89,4 @@ project 黄金模板 ──固化──▶ add-business-module.md ──克隆
|
||||
|
||||
## 7. 与通用协议的关系
|
||||
|
||||
本篇是 [`./ai-development-protocol.md`](./ai-development-protocol.md) 在"MVP 大规模并行"场景下的**特化实例**：通用协议讲"单个任务怎么承接→评审→执行→验证→沉淀"，本篇讲"把 131 项 P0 拆给 10 个 Agent 怎么并行且复利"。两者一致，冲突时以通用协议的证据规则与停止规则为准。
|
||||
本篇是 [`./ai-development-protocol.md`](./ai-development-protocol.md) 在"MVP 大规模并行"场景下的**特化实例**：通用协议讲"单个任务怎么承接→评审→执行→验证→沉淀"，本篇讲"把 55 项 P0 产品功能（≈137 技术项）拆给 10 个 Agent 怎么并行且复利"。两者一致，冲突时以通用协议的证据规则与停止规则为准。
|
||||
|
||||
10
AGENTS.md
10
AGENTS.md
@ -13,12 +13,12 @@
|
||||
| 顺序 | 文档 | 定位 |
|
||||
|---|---|---|
|
||||
| 1 | `docs/architecture/2026-06-06-系统概要设计-投资人版.md` | 商业定位、资本效率、壁垒与窗口期 |
|
||||
| 2 | `docs/architecture/2026-06-06-v2业务能力全景与模块归属.md` | 12 模块 / 299 项能力 / P0 范围全景 |
|
||||
| 2 | 三文档套件：`docs/architecture/2026-06-07-产品需求清单.md`(Doc A·产品WHAT) / `…-技术架构与模块.md`(Doc B·技术HOW·13模块) / `…-需求模块映射.md`(Doc C·RTM) | 产品需求 / 技术模块 / M:N 映射（取代原"业务能力全景"） |
|
||||
| 3 | `docs/architecture/2026-06-06-v2架构选型审阅版.md` | 选型权衡与审阅结论 |
|
||||
| 4 | `docs/architecture/2026-06-06-v2模块架构与MVP覆盖度.md` | 模块架构与 MVP 覆盖度核对 |
|
||||
| 5 | `docs/architecture/2026-06-06-系统概要设计-技术决策版.md` | 技术决策全貌（架构基线） |
|
||||
| 6 | `docs/architecture/2026-06-07-系统概要设计-开发团队版.md` | 日常开发手册：环境/目录/规范/联调/提交 |
|
||||
| 7 | `docs/superpowers/specs/2026-06-07-mvp-execution-spec-design.md` | MVP 执行 spec：10 人×3 周、131 项 P0、契约先行 |
|
||||
| 7 | `docs/superpowers/specs/2026-06-07-mvp-execution-spec-design.md` | MVP 执行 spec：10 人×3 周、契约先行（验收=55 项 P0 产品功能 / 工作量≈137 技术项，正文已同步）|
|
||||
|
||||
> 提示：原始文档很长，直接全读会拖慢任务。**蒸馏版位于 `.agents/knowledge/`，是日常默认入口。**
|
||||
|
||||
@ -32,9 +32,9 @@
|
||||
|
||||
| 文件 | 一句话说明 |
|
||||
|---|---|
|
||||
| [`.agents/knowledge/product-and-architecture.md`](.agents/knowledge/product-and-architecture.md) | 产品定位、12 模块与依赖、三仓三端架构蒸馏 |
|
||||
| [`.agents/knowledge/tech-decisions.md`](.agents/knowledge/tech-decisions.md) | 技术栈与关键选型理由（Yudao/Dify/OpenGame/自研Runtime+LayaAir 等） |
|
||||
| [`.agents/knowledge/mvp-scope-and-milestones.md`](.agents/knowledge/mvp-scope-and-milestones.md) | MVP 的 131 项 P0 范围、里程碑与验收指标 |
|
||||
| [`.agents/knowledge/product-and-architecture.md`](.agents/knowledge/product-and-architecture.md) | 产品定位、13 模块与依赖、三仓三端架构蒸馏 |
|
||||
| [`.agents/knowledge/tech-decisions.md`](.agents/knowledge/tech-decisions.md) | 技术栈与关键选型理由（Yudao/Dify/OpenGame/自研Canvas+Cocos-MCP/Prompt 治理 等） |
|
||||
| [`.agents/knowledge/mvp-scope-and-milestones.md`](.agents/knowledge/mvp-scope-and-milestones.md) | MVP 的 55 项 P0 产品功能范围、里程碑与验收指标 |
|
||||
| [`.agents/knowledge/glossary.md`](.agents/knowledge/glossary.md) | 术语表（游戏流/GameConfig/Manifest/质量分等） |
|
||||
|
||||
### rules/ —— 硬约束，回答"**必须怎样**"
|
||||
|
||||
@ -31,11 +31,11 @@ MVP 目标：交付一个**种子用户可试用的全链路闭环**——创作
|
||||
| 游戏流首屏加载 | **P75 < 3s** | MVP 执行 spec |
|
||||
| 服务可用性 | **≥ 99.5%** | 可用性目标 |
|
||||
| MVP 基础设施成本 | **< 5000 元/月**（投资人版核算约 ¥4,300/月，年化 ~5 万） | 投资人版 |
|
||||
| P0 能力覆盖 | **131/131 项全量可验证** | MVP 执行 spec |
|
||||
| P0 产品功能覆盖 | **55/55 项 P0 产品功能可验证**（Doc A 产品口径）| 三文档套件 Doc A/C |
|
||||
|
||||
> **两份路线来源不同，如实标注差异，勿混用：**
|
||||
> - **投资人版（HJ-ARCH-002）**：**5 人核心团队 + ¥4,300/月基础设施 + 11 周 MVP**，强调资本效率与窗口期验证。
|
||||
> - **MVP 执行 spec（HJ-MVP-SPEC-001）**：**10 人 × 3 周（15 工作日）全量交付 131 项 P0**，强调契约先行 + 五工位并行。
|
||||
> - **MVP 执行 spec（HJ-MVP-SPEC-001）**：**10 人 × 3 周（15 工作日）**，强调契约先行 + 五工位并行。**MVP 验收口径 2026-06-07 迁移为 Doc A 的 55 项 P0 产品功能**（旧"131 项 P0 能力项"经 12→13 模块重划后工作量 ≈137 技术项，spec 正文已同步）。
|
||||
> - 生成成功率：投资人版未直接给数值，**spec 明确为 ≥80%**（非 85%）。引用指标时以对应文档为准。
|
||||
|
||||
---
|
||||
@ -46,7 +46,7 @@ MVP 目标：交付一个**种子用户可试用的全链路闭环**——创作
|
||||
|
||||
| 仓库 | 定位 | 技术栈 |
|
||||
|---|---|---|
|
||||
| **game-cloud** | 后端（Yudao Cloud fork + 12 个游戏业务模块） | Java 17 + Spring Cloud Alibaba + MySQL + RocketMQ + Redis + Nacos + Dify + OpenGame |
|
||||
| **game-cloud** | 后端（Yudao Cloud fork + 13 个游戏业务模块） | Java 17 + Spring Cloud Alibaba + MySQL + RocketMQ + Redis + Nacos + Dify + OpenGame |
|
||||
| **game-admin** | 管理后台前端（运营/管理员用） | Vue3 + Element Plus（yudao-ui-admin-vue3 fork） |
|
||||
| **game-studio** | 产品端前端（创作者 + 玩家用） | Vue3 + Vant + 自研轻量 Canvas Runtime(<15KB, Tier1) + HuijingGameSDK；3D/独立App 为远期分层（详见 [.agents tech-decisions §1.1](.agents/knowledge/tech-decisions.md)） |
|
||||
|
||||
|
||||
3713
docs-design/zaomeng-ai-demo.html
Normal file
3713
docs-design/zaomeng-ai-demo.html
Normal file
File diff suppressed because it is too large
Load Diff
156
docs/agent-specs/2026-06-07-prompt治理体系-execution.md
Normal file
156
docs/agent-specs/2026-06-07-prompt治理体系-execution.md
Normal file
@ -0,0 +1,156 @@
|
||||
# 绘境AI — 全生命周期 Prompt 工程治理体系（执行版）
|
||||
|
||||
> 文档类型：**执行版**（供 agent 实现，含落地步骤/接口契约/验证/回滚，不预写无法验证的代码细节）
|
||||
> 文档 ID：HJ-PROMPT-GOV-EXEC-001 ｜ 生成时间：2026-06-07
|
||||
> 上游：评审版 [`./2026-06-07-prompt治理体系-review.md`](./2026-06-07-prompt治理体系-review.md)（HJ-PROMPT-GOV-001，六项裁决全采纳 a）
|
||||
> 配套 playbook：[`../../.agents/skills/prompt-governance.md`](../../.agents/skills/prompt-governance.md)
|
||||
> 选型依据：[`../../.agents/knowledge/tech-decisions.md`](../../.agents/knowledge/tech-decisions.md) §1.1（引擎二次裁决）
|
||||
|
||||
---
|
||||
|
||||
## 1. 目标与范围边界
|
||||
|
||||
**目标**：把分散在 6 个消费点的所有 prompt 收为 git `contracts/prompts/` 单一事实源（第 8 类契约），实现版本化管理、改动可自动回归验证、HITL 治理节点落地。
|
||||
|
||||
**范围（MVP，按 §9-6 裁决 a）**：覆盖 **Tier1 全链路** prompt —— `intent / codegen-opengame / asset / narrative / lockstyle / qa / convert / ops`。`codegen-cocos-mcp` 仅留探针目录，不投入工程。
|
||||
|
||||
**非目标**：LLM-as-judge 自动打分、eval 看板、运营 DB 热改、prompt 可玩性自动评分（均 MVP 后）。
|
||||
|
||||
---
|
||||
|
||||
## 2. 前置条件
|
||||
|
||||
- `contracts/` 目录已存在（Day-0 契约已锁，本体系作为**第 8 类契约**纳入，§9-3 裁决 a）。
|
||||
- aigc Java 壳已可运行（DifyClient/TaskDispatcher 已就位，见 ai-generation-pipeline §1）。
|
||||
- Dify workflow 已发布；OpenGame `/generate` 可调通。
|
||||
- CI（GitHub Actions 或等价）可对 PR 跑脚本。
|
||||
|
||||
---
|
||||
|
||||
## 3. 涉及模块与文件路径
|
||||
|
||||
| 模块/位置 | 新增/改动 | 说明 |
|
||||
|---|---|---|
|
||||
| `contracts/prompts/` | **新增** | Registry 目录（结构见 playbook §1） |
|
||||
| `contracts/prompts/registry.yaml` | 新增 | prompt 索引 |
|
||||
| `contracts/prompts/_schemas/*.json` | 新增 | 输入/输出 JSON Schema |
|
||||
| `contracts/prompts/eval/<id>/` | 新增 | 每条 prompt 的 Golden 集 |
|
||||
| game-cloud `aigc/.../prompt/PromptRegistryLoader.java` | 新增 | 加载/渲染 prompt |
|
||||
| game-cloud `aigc/.../prompt/PromptTemplate.java` | 新增 | prompt 数据结构（frontmatter+body） |
|
||||
| game-cloud `aigc/.../service/qa/TestScriptService.java` | 新增 | T-AGC-09 测试脚本生成原子 |
|
||||
| game-cloud `runtime/.../service/compiler/` | 改动 | 编译后执行测试脚本为入库门禁 |
|
||||
| Dify workflow LLM 节点 | 改动 | prompt 文本改为 `{{registry:id@ver}}` 引用 |
|
||||
| game-admin `views/prompt/` | 新增（P1） | 运营查看/触发 prompt PR 流程页 |
|
||||
| `.github/workflows/prompt-eval.yml` | 新增 | PR 触发 eval 门禁 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 数据流与依赖
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
GIT["contracts/prompts/（git 单一事实源）"] --> LOADER["PromptRegistryLoader（aigc/studio 壳）"]
|
||||
LOADER -->|id@version 注入| DIFY["Dify 节点"]
|
||||
LOADER -->|参数传入| OG["OpenGame"]
|
||||
LOADER -->|system prompt| CC["Cocos-MCP（studio，探针）"]
|
||||
PR["Prompt 改动 PR"] --> CI["prompt-eval CI"]
|
||||
CI -->|读| GIT
|
||||
CI --> GATE["四道闸 + 人工抽检"]
|
||||
GATE -->|绿| MERGE["合入→部署同步"]
|
||||
TEL["telemetry 行为指标"] -.反哺.-> PR
|
||||
```
|
||||
|
||||
依赖方向：壳层 → Registry（读）；CI → Registry（读）+ LLM/OpenGame（跑样本）；runtime → T-AGC-09（执行测试）。**不引入新的跨模块强耦合**（Registry 是文件契约，非服务）。
|
||||
|
||||
---
|
||||
|
||||
## 5. 接口 / 数据契约
|
||||
|
||||
### 5.1 Prompt frontmatter schema（`_schemas/prompt-frontmatter.json`）
|
||||
|
||||
必填：`id`(string, 唯一)、`version`(semver)、`owner`(string)、`tier`(enum tier1/2/3)、`engine`(enum)、`stage`(string)、`input_schema`(path)、`output_schema`(path)。选填：`constraints`(string[])、`eval_set`(path)、`guardrails`(string[])。
|
||||
|
||||
### 5.2 PromptRegistryLoader 接口（契约，非实现）
|
||||
|
||||
```
|
||||
PromptTemplate load(String id, String version) // 取一条 prompt（含 frontmatter+body）；缺失抛 PromptNotFoundException
|
||||
String render(String id, String version, Map<String,Object> vars) // 变量渲染为最终文本
|
||||
List<PromptMeta> list(String stageOrEngine) // 按 stage/engine 列出
|
||||
boolean validate(PromptTemplate t) // 校验 frontmatter + schema 绑定有效
|
||||
```
|
||||
|
||||
加载策略：优先 DB 只读镜像（命中即返回），未命中回源 git checkout；启动期全量校验 registry.yaml 与文件一致。
|
||||
|
||||
### 5.3 Eval 配置格式（`eval/<id>/`）
|
||||
|
||||
- `inputs.jsonl`：每行一个输入样本（符合 input_schema）。
|
||||
- `expect.yaml`：`schema_pass_rate`(≥)、`success_rate`(≥0.8)、`golden_diff_fields`(关键字段列表)、`max_cost_delta`、`max_latency_delta`。
|
||||
- `baseline/`：基线产物快照（合入新基线时更新）。
|
||||
|
||||
### 5.4 T-AGC-09 契约
|
||||
|
||||
```
|
||||
TestScript generate(GameConfig config) // 输入 GameConfig → 输出测试脚本（启动/输入响应/边界断言）
|
||||
// runtime 编译后执行：通过=可入库；失败=拒绝入库 + 原因分类
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 关键实现步骤（分阶段，按 MVP 节奏）
|
||||
|
||||
| 阶段 | 步骤 | 完成判据 |
|
||||
|---|---|---|
|
||||
| **P0 骨架** | 建 `contracts/prompts/` 目录树 + `registry.yaml` + `_schemas/`；把现有散落 prompt（Dify 节点/OpenGame）抽取迁入 Tier1 全链路目录 | 8 个阶段目录就位，现有 prompt 全部入库且有 frontmatter |
|
||||
| **P1 加载** | 实现 `PromptRegistryLoader` + `PromptTemplate`；Dify 节点改 `{{registry:id@ver}}` 引用；壳层注入 | Dify 跑通时 prompt 来自 Registry（非内嵌），改文件即生效 |
|
||||
| **P2 门禁** | 写 `prompt-eval.yml` CI + 四道闸脚本；为每条 prompt 建 Golden 集（5–10 样本） | 改一条 prompt 的 PR 能被 eval 拦截/放行 |
|
||||
| **P3 测试原子** | 实现 `T-AGC-09 TestScriptService`；runtime 编译流水线挂载执行 | 生成游戏入库前自动跑可玩性测试脚本 |
|
||||
| **P4 HITL** | 创作者侧复用现有"重生成/锁风"节点；运营侧 game-admin prompt 管理页（P1，可先用 PR 流程文档替代） | 运营能走"改 prompt→eval→批准"闭环 |
|
||||
|
||||
---
|
||||
|
||||
## 7. 边缘失败路径
|
||||
|
||||
| 失败 | 处理 |
|
||||
|---|---|
|
||||
| prompt id/version 不存在 | `load` 抛异常 → 壳层回退**内置默认 prompt** + 告警，不中断生成 |
|
||||
| frontmatter/schema 校验失败 | 启动期/CI 拒绝该 prompt 上线，报具体字段 |
|
||||
| eval 跑不通（LLM 限流/超时） | CI 标记 skip + 通知人工兜底审，不阻塞紧急修复 |
|
||||
| 改 prompt 未 bump version | CI 卡：version 未变 → 拒绝合入 |
|
||||
| registry.yaml 与文件不一致 | 启动期校验失败 → 阻止部署 |
|
||||
| Cocos-MCP 工具调用失败（探针） | 降级 Tier1/OpenGame；不影响 MVP 主链路 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 验证方法
|
||||
|
||||
- **registry lint**（CI）：frontmatter schema 校验 + registry.yaml 一致性。
|
||||
- **loader 单测**：load/render/validate 覆盖正常 + 缺失 + 校验失败。
|
||||
- **eval 门禁端到端**：故意改坏一条 prompt → PR 应被四道闸拦截；正常改 → 放行。
|
||||
- **T-AGC-09 验证**：对 3 个模板生成游戏跑测试脚本，确认能拦住"不可运行"产物。
|
||||
- **注入注入注入回归**：prompt 注入样本应被 guardrails 拦截。
|
||||
|
||||
---
|
||||
|
||||
## 9. 完成条件
|
||||
|
||||
1. `contracts/prompts/` Tier1 全链路 prompt 入库 + `registry.yaml` 索引完整。
|
||||
2. `PromptRegistryLoader` 跑通：Dify 生成时 prompt 真实来自 Registry。
|
||||
3. `prompt-eval` CI 对至少 1 条 prompt 生效（能拦截退化）。
|
||||
4. `T-AGC-09` 产出测试脚本，runtime 编译流水线执行为入库门禁。
|
||||
5. 运营"改 prompt→eval→批准"闭环可走（页面或文档化流程）。
|
||||
|
||||
---
|
||||
|
||||
## 10. 回滚策略
|
||||
|
||||
| 层级 | 回滚 |
|
||||
|---|---|
|
||||
| 单条 prompt | version 切换 / `git revert` 该 prompt 文件 |
|
||||
| 加载机制 | loader 失败回退内置默认 prompt（不中断生成） |
|
||||
| 整体体系 | 关闭 Registry 加载开关，回到 **Dify-native**（保留旧 workflow 内嵌 prompt 作兜底） |
|
||||
|
||||
> 整体回滚成本低：Registry 是**叠加层**，旧 Dify-native prompt 不删除、仅不被引用；开关回切即恢复。
|
||||
|
||||
---
|
||||
|
||||
> 执行版"通过"= 你确认 §6 阶段拆分与 §5 接口契约无异议；通过后由子代理按阶段拆分 spec 并子代理评审（按 CLAUDE.md 两轮评审）。
|
||||
327
docs/agent-specs/2026-06-07-prompt治理体系-review.md
Normal file
327
docs/agent-specs/2026-06-07-prompt治理体系-review.md
Normal file
@ -0,0 +1,327 @@
|
||||
# 绘境AI — 全生命周期 Prompt 工程治理体系（评审版）
|
||||
|
||||
> 文档类型：**评审版**（供人决策，结论先行，不含代码级执行细节）
|
||||
> 文档 ID：HJ-PROMPT-GOV-001 ｜ 生成时间：2026-06-07
|
||||
> 触发来源：创始人提出"游戏生成全生命周期都需清晰 Prompt 约束 + 修改效果可验证 + 用户参与节点"，并定引擎分层（OpenGame 轻量 / Cocos-MCP 复杂2D·3D）
|
||||
> 已裁决（2026-06-07）：① 引擎=Cocos 统一 Tier2/3、移除 Three.js；② Prompt 载体=Git 契约化 Registry；③ 验证=轻量门禁
|
||||
> 配套：技术分层见 [`../../.agents/knowledge/tech-decisions.md`](../../.agents/knowledge/tech-decisions.md) §1.1；模块边界见 `2026-06-07-技术架构与模块-试点.md`（Doc B）；生成链路见 [`../../.agents/skills/ai-generation-pipeline.md`](../../.agents/skills/ai-generation-pipeline.md)
|
||||
> ✅ 已确认（2026-06-07）：§9 六项待确认项全部采纳推荐(a)。引擎决策已回填 `.agents` 蒸馏（tech-decisions/product-and-architecture/runtime-and-multichannel）；下一步产出执行版 + playbook，走两轮评审（见 §10）。**注：本仓库文档正被并行重构（P0 口径已迁移为 Doc A 的 55 项产品功能），§6.3 的"131 P0"为旧口径，回填执行版时以最新口径为准。**
|
||||
|
||||
---
|
||||
|
||||
## 0. 结论（先看这段）
|
||||
|
||||
1. **把分散在 6 个消费点（Dify 节点 / OpenGame / Cocos-MCP / ComfyUI / runtime 转换 / telemetry 诊断）的所有 Prompt，统一抽到 git 单一事实源**，作为与 Day-0 七契约**同级的第 8 类契约资产**——版本化、输入/输出 Schema 绑定、PR + eval 门禁治理。运行时**加载**而非内嵌，延续"不动 Dify/OpenGame 内核、能力增强放壳层"的纪律。
|
||||
|
||||
2. **引擎分层落定**：Tier1 极轻量H5/2D = OpenGame 生成 + 自研Canvas<15KB｜Tier2 复杂2D+3D = **Cocos+MCP**｜Tier3 独立App = **Cocos 原生导出**。**Three.js 移除**。两套 Prompt 形态（OpenGame 文生代码 / Cocos-MCP agentic 工具编排）同一 Registry 容纳、目录分治。
|
||||
|
||||
3. **修改效果验证 = 轻量门禁**：Golden 回归 + Schema 通过率 + 生成成功率≥80% + 成本/延迟不劣化 + 人工抽检。**可玩性不做结构化自动评分**（测不了"好玩"），靠人工抽检 + 上线后 telemetry 行为指标反哺下一轮。
|
||||
|
||||
4. **人在环（HITL）两类节点**：创作者 7 个运行时节点（输入→进度→预览→接受/重生成→锁风→对白→发布→诊断迭代）；运营 5 个治理节点（改 prompt PR→eval 评审→模板策展→人工复核队列→灰度回滚）。
|
||||
|
||||
5. **顺带补一个缺口**：你提的"自动化测试用例/脚本生成"在 Doc B 13 模块无 owner——建议新增 aigc 无状态原子 `T-AGC-09 测试脚本生成`，由 runtime 编译流水线执行为入库门禁，不新增模块。
|
||||
|
||||
> 一句话：**把"prompt"从埋在代码与 workflow 里的字符串，升级为像 API/DB/SDK 契约一样被版本化、Schema 约束、评审门禁的一等资产**——这既是"修改效果可验证"的前提，也是跨 OpenGame/Cocos 两引擎统一治理的唯一办法。
|
||||
|
||||
---
|
||||
|
||||
## 1. 背景与问题
|
||||
|
||||
### 1.1 现状：Prompt 散落、无契约、无回归
|
||||
|
||||
| 消费点 | 今天 prompt 在哪 | 问题 |
|
||||
|---|---|---|
|
||||
| Dify 意图/模板匹配 | 埋在 Dify workflow 节点内（Dify-native） | 散落、跨环境难同步、无 git 历史 |
|
||||
| OpenGame 6 阶段 codegen | 埋在 OpenGame 代码/配置 | 改要动微服务、无法独立治理 |
|
||||
| Cocos-MCP（新增） | 尚无 | 全新 agentic 编排 prompt 待建 |
|
||||
| ComfyUI 素材生成 | 埋在 ComfyUI workflow JSON | 与游戏风格/IP 约束脱节 |
|
||||
| runtime 平台转换 | 散在转换代码常量 | 各渠道违禁词/尺寸约束硬编码 |
|
||||
| telemetry 诊断/改版 | 尚无统一模板 | 诊断建议质量不可控 |
|
||||
|
||||
**三个直接痛点**（正是你问的）：
|
||||
- **怎么管理**：无单一事实源，改一处 prompt 要进多个系统，跨引擎无法统一；
|
||||
- **怎么验证修改效果**：无版本、无回归基线，改完不知道变好还是变坏；
|
||||
- **谁参与、在哪参与**：没有"谁能改 prompt、改了谁批准上线"的人在环流程。
|
||||
|
||||
### 1.2 为什么现在必须治理
|
||||
|
||||
引擎分层落地后，**生成链路从单引擎（OpenGame）变为双引擎（OpenGame + Cocos-MCP）**，prompt 数量与形态都会膨胀。若不先立治理地基，prompt 会像早期"能力散落各模块 P2"一样失控——这与你刚在模块重划中解决的"横切无主"是同类病。
|
||||
|
||||
---
|
||||
|
||||
## 2. 目标 / 非目标
|
||||
|
||||
**目标**
|
||||
- 全生命周期所有 prompt 有**唯一事实源（git）**、版本化、输入/输出 Schema 契约、唯一 owner。
|
||||
- prompt 修改有**可自动执行的效果验证门禁**（防退化），回答"修改效果怎么验证"。
|
||||
- 明确**创作者 / 运营两类 HITL 参与节点**，回答"用户在哪些节点参与"。
|
||||
- 同一体系容纳 **OpenGame 生成式 + Cocos-MCP agentic** 两种 prompt 形态。
|
||||
- 为"测试脚本生成"补唯一 owner。
|
||||
|
||||
**非目标（MVP 阶段保持收敛）**
|
||||
- 不做 LLM-as-judge 自动打分 / eval 可视化看板（验证重量档，MVP 后演进）。
|
||||
- 不做 prompt 可玩性自动评分（结构校验测不了"好玩"，靠行为指标反哺）。
|
||||
- 不做运营 DB 热改 prompt（裁决=Git；运营改走 PR + 自动 eval）。
|
||||
- 不自研 prompt 编排引擎（复用 Dify + Java 壳层 + MCP）。
|
||||
- 本评审版**不**产出代码、DB 表、loader 实现、五工位排期——确认后进执行版。
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心理念：Prompt 即契约资产（Prompt-as-Contract）
|
||||
|
||||
把 prompt 与 Day-0 七契约并列为**第 8 类契约**。每条 prompt 绑定一份完整契约：
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph 一条 Prompt 契约
|
||||
P["Prompt 模板体<br/>(system + {{变量槽}})"]
|
||||
IN["输入 Schema<br/>(调用参数契约)"]
|
||||
OUT["输出 Schema<br/>(产物结构契约)"]
|
||||
C["硬约束块<br/>(违禁词/资源上限/风格锁)"]
|
||||
G["Golden 样本集<br/>(回归基线)"]
|
||||
M["元数据<br/>(id/version/owner/tier/engine)"]
|
||||
end
|
||||
IN --> P --> OUT
|
||||
C --> P
|
||||
G -.验证.-> P
|
||||
M -.索引.-> P
|
||||
```
|
||||
|
||||
**纪律**：prompt 文件是 source of truth；运行时按 `id@version` **加载注入**，不在 Dify/OpenGame/Cocos 内核里内嵌。改 prompt = 改 git → PR → eval 门禁 → 合入 → 同步运行时。
|
||||
|
||||
---
|
||||
|
||||
## 4. 推荐方案
|
||||
|
||||
### 4.1 Prompt Registry 结构（挂在 `contracts/` 下）
|
||||
|
||||
```
|
||||
contracts/prompts/
|
||||
├── registry.yaml # 索引：所有 prompt 的 id/版本/owner/绑定 schema/eval 集
|
||||
├── _schemas/ # 输入/输出 JSON Schema（prompt 的契约）
|
||||
├── intent/ # 意图解析、模板匹配
|
||||
├── codegen-opengame/ # Tier1 文生代码（owner=aigc）
|
||||
├── codegen-cocos-mcp/ # Tier2/3 agentic 工具编排（owner=studio）
|
||||
├── asset/ # 素材生成（图/音/角色/特效）+ IP LoRA 约束
|
||||
├── narrative/ # 剧情/分支对白/关卡
|
||||
├── lockstyle/ # 锁风约束（风格-版权一致性）
|
||||
├── qa/ # 测试用例 + 可玩性测试脚本生成
|
||||
├── convert/ # 打包/平台转换约束（尺寸/资质/违禁词）
|
||||
└── ops/ # AI 诊断/改版任务
|
||||
```
|
||||
|
||||
每条 prompt = frontmatter 契约头 + 模板体（结构示例，非实现代码）：
|
||||
|
||||
```yaml
|
||||
---
|
||||
id: codegen-opengame.scaffold # 唯一 id（目录.阶段）
|
||||
version: 1.2.0 # 语义化版本
|
||||
owner: WS2/aigc # 唯一负责工位/模块
|
||||
tier: tier1 # tier1 | tier2 | tier3
|
||||
engine: opengame # opengame | cocos-mcp | dify | comfyui | runtime
|
||||
stage: scaffold # 生命周期阶段
|
||||
input_schema: _schemas/codegen-input.json
|
||||
output_schema: _schemas/game-config.json
|
||||
constraints: # 硬约束块（产物必须满足）
|
||||
- 首屏≤2MB, 总包≤10MB
|
||||
- 游戏内零网络请求（CSP connect-src none）
|
||||
eval_set: eval/codegen-opengame.scaffold/ # 绑定 Golden 集
|
||||
guardrails: [injection-detect, schema-validate, asset-ref-check]
|
||||
---
|
||||
{{system_prompt}}
|
||||
... 模板体，带 {{变量槽}} ...
|
||||
```
|
||||
|
||||
> 目录按**生命周期阶段**分治；`engine` 字段标记形态，加载器据此分发。`owner` 保证每条 prompt 单一负责人（与 Doc B 模块 owner 对齐）。
|
||||
|
||||
### 4.2 加载 / 注入机制（怎么落地到运行时）
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
REG["contracts/prompts/ — Git Registry（唯一事实源）"]
|
||||
DBM["DB 只读镜像（可选，仅热加载用，不可绕过 git 改）"]
|
||||
LOADER["aigc / studio 壳层：PromptRegistryLoader（按 id@version 注入）"]
|
||||
REG --> DBM --> LOADER
|
||||
REG --> LOADER
|
||||
LOADER --> D["Dify 节点：{{registry:intent.parse@1.2.0}}"]
|
||||
LOADER --> OG["OpenGame：codegen prompt 作参数传入 /generate"]
|
||||
LOADER --> CC["Cocos-MCP：编排 prompt 作 system prompt（studio 侧）"]
|
||||
LOADER --> CF["ComfyUI：素材 prompt + IP LoRA 约束"]
|
||||
LOADER --> CV["runtime：平台转换约束 prompt"]
|
||||
LOADER --> OPS["telemetry：诊断/改版 prompt"]
|
||||
```
|
||||
|
||||
要点：DB 镜像（若启用）**只读**，仅为运行时热加载提速，写入路径唯一为 git；部署时强制校验 registry 版本一致，CI 卡 Schema。
|
||||
|
||||
### 4.3 两套 Prompt 形态：OpenGame vs Cocos-MCP（关键）
|
||||
|
||||
| 维度 | OpenGame prompt（Tier1） | Cocos-MCP prompt（Tier2/3） |
|
||||
|---|---|---|
|
||||
| 形态 | 生成式：文本 → 游戏代码 | **agentic：驱动 158 个编辑器工具的工具编排** |
|
||||
| 调用 | 单次/6 阶段 pipeline | 多步、有状态、多轮工具调用 |
|
||||
| 输出 | plain Canvas/JS + GameConfig | Cocos 工程 → 导出（web/小游戏/原生） |
|
||||
| 归属 | **aigc**（无状态生成原子） | **studio**（有状态创作编排，Doc B T-STU-05 任务链） |
|
||||
| 失败降级 | 退化为模板填充（确定性 Fallback） | 退化为 Tier1/OpenGame 路径；MVP 仅探针 |
|
||||
|
||||
> 归属遵循 Doc B 已立的边界：**aigc=无状态生成原子、studio=有状态编排**。Cocos-MCP 是多步 agentic、有状态，天然归 studio；OpenGame 单次文生代码作 aigc 原子。这避免把"编辑器驱动"又塞回 aigc（重蹈上轮 aigc 过载）。
|
||||
|
||||
### 4.4 Eval 轻量门禁（验证修改效果）
|
||||
|
||||
复用并泛化 Doc B `T-AGC-08 Golden Config 回归`——从"GameConfig 级"升到"Prompt 级"。
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
PR["Prompt 改动 PR"] --> E["跑绑定的 Golden eval 集（固定 N 条输入）"]
|
||||
E --> G1["①Schema 通过率 ≥ 阈值"]
|
||||
E --> G2["②生成成功率 ≥ 80%"]
|
||||
E --> G3["③Golden 回归 diff（关键字段防退化）"]
|
||||
E --> G4["④成本/延迟不劣化"]
|
||||
G1 --> M["人工抽检 K 条<br/>主观质量/可玩性"]
|
||||
G2 --> M
|
||||
G3 --> M
|
||||
G4 --> M
|
||||
M --> MERGE["批准合入 → 同步运行时"]
|
||||
M -.任一红.-> BLOCK["阻断 PR + diff 报告"]
|
||||
TEL["上线后行为指标(完玩/重玩率)"] -.反哺下轮.-> PR
|
||||
```
|
||||
|
||||
**Golden 集结构**（每条 prompt 绑定一份）：`eval/<prompt-id>/` 含 `inputs.jsonl`（固定输入样本，5–10 条起步，随 bad case 增量）+ `baseline/`（基线产物快照）+ `expect.yaml`（期望属性/阈值）。
|
||||
|
||||
**可玩性**：MVP **不**自动评分；人工抽检 K 条把关主观质量，上线后 telemetry 行为指标（完玩率/重玩率/时长）作为下一轮 prompt 迭代输入——形成"生成→分发→数据→prompt 优化"闭环，呼应 quality_score 反哺 feed 的既有数据回路。
|
||||
|
||||
### 4.5 HITL 人在环节点
|
||||
|
||||
**创作者（C 端·每次生成的运行时节点）**
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A["①输入一句话<br/>+选IP/模板/附件"] --> B["②任务链进度<br/>可视/可中断"]
|
||||
B --> C["③预览试玩"]
|
||||
C --> D{"④接受?"}
|
||||
D -->|带修改重生成| A
|
||||
D -->|是| E["⑤锁风强度<br/>标准/严格/人工复核"]
|
||||
E --> F["⑥对白调试<br/>实时写入预览"]
|
||||
F --> G["⑦发布前检查<br/>锁风+性能+版权"]
|
||||
G --> H["上线后→AI诊断→一键迭代"]
|
||||
H -.改版任务.-> A
|
||||
```
|
||||
对应需求：P-CRT-01/04/05/08/09、P-LIC-04/05、P-PUB-03、P-OPS-03/04。
|
||||
|
||||
**运营 / 管理员（B 端·Prompt 生命周期治理节点）**
|
||||
|
||||
| 节点 | 参与动作 | 关联 |
|
||||
|---|---|---|
|
||||
| Prompt 改动 | 提 PR 改 prompt → review | git |
|
||||
| Eval 评审 | 门禁结果 + 人工抽检 → 批准上线 | §4.4 |
|
||||
| 模板库策展 | 新增/下架 prompt、调约束块 | registry.yaml |
|
||||
| 人工复核队列 | 锁风/内容安全高风险样本人工裁决 | Doc B T-CMP-05 |
|
||||
| 灰度回滚 | prompt 新版本灰度 + 一键回滚（version 切换） | 语义化版本 |
|
||||
|
||||
### 4.6 测试缺口归位
|
||||
|
||||
"自动化测试用例/脚本生成"建议落为 **aigc 新增无状态原子 `T-AGC-09 测试脚本生成`**（输入 GameConfig → 输出可玩性测试脚本），由 **runtime 编译流水线执行**为入库门禁的一环；其 prompt 归 `contracts/prompts/qa/`。不新增模块，符合"最小新增"。（owner/计数见 §9 待确认）
|
||||
|
||||
### 4.7 引擎分层最终态（Three.js 移除）
|
||||
|
||||
| 层 | 定位 | 选型（最终） | 生成路径 | prompt 目录 |
|
||||
|---|---|---|---|---|
|
||||
| **Tier1 极轻量H5/2D** | 游戏流即点即玩，P75<3s | 自研 Canvas<15KB + iframe 沙箱 | **OpenGame** 文生代码 | codegen-opengame/ |
|
||||
| **Tier2 复杂2D+3D** | 中重度，渠道分发 | **Cocos Creator 3.8.8 + MCP** | **Cocos-MCP** agentic | codegen-cocos-mcp/ |
|
||||
| **Tier3 独立App** | 原生应用 | **Cocos 原生导出** | 同 Tier2 + 打包 | codegen-cocos-mcp/ + convert/ |
|
||||
|
||||
> Three.js 移除原因：Cocos 覆盖复杂2D+3D+原生/小游戏导出且有 MCP（AI 可驱动、出功能快），保留 Three.js 等于双 3D 栈、维护与 AI 适配成本翻倍。Tier1 仍自研薄壳保首屏极快——**Tier1 轻、Tier2/3 重**的分工不变。
|
||||
|
||||
---
|
||||
|
||||
## 5. 关键取舍
|
||||
|
||||
| 取舍点 | 选择 | 放弃 | 理由 |
|
||||
|---|---|---|---|
|
||||
| Prompt 载体 | **Git 契约化 Registry** | DB 热改 / Dify-native | 与契约先行文化一致、可回归可审计、跨引擎统一；运营改走 PR+eval |
|
||||
| 验证力度 | **轻量门禁** | 中量(自动A/B)/重量(LLM-judge+看板) | 3 周可落地，先守"改坏了能拦住"的底线；重档后置 |
|
||||
| 3D/复杂引擎 | **Cocos 统一 Tier2/3，移除 Three.js** | 双栈 / 维持 Three.js 锁定 | 单栈降复杂度、MCP 可 AI 驱动、原生导出一并解决 |
|
||||
| Cocos-MCP 归属 | **studio（有状态编排）** | 塞进 aigc | 守 Doc B "aigc 无状态原子 / studio 有状态编排"边界，防 aigc 再过载 |
|
||||
| 测试脚本生成 | **aigc 新增原子 T-AGC-09** | 新增 qa 模块 | 最小新增，无状态原子天然属 aigc，runtime 执行 |
|
||||
| 可玩性验证 | **人工抽检 + 行为指标反哺** | 结构化自动评分 | 结构校验测不了"好玩"，强行自动化是测错对象 |
|
||||
|
||||
---
|
||||
|
||||
## 6. 爆炸半径与兼容性
|
||||
|
||||
### 6.1 受影响文档（确认后回填）
|
||||
|
||||
| 文档 | 影响 | 动作 |
|
||||
|---|---|---|
|
||||
| `.agents/knowledge/tech-decisions.md` | §1.1 Tier 表（Three.js→移除、Cocos 升 Tier2/3）、§3 待确认项5、§7 非目标、研究依据行；§1 新增"Prompt 治理"决策行 | 改 |
|
||||
| `.agents/knowledge/product-and-architecture.md` | runtime/studio 技术栈行；新增"Prompt Registry"基建说明 | 改 |
|
||||
| `.agents/skills/runtime-and-multichannel.md` | 渲染层/导出工具（Three.js 相关）、Tier2/3 引擎=Cocos | 改 |
|
||||
| `.agents/skills/ai-generation-pipeline.md` | 新增 Cocos-MCP 路径 + Prompt Registry 加载机制 | 改 |
|
||||
| `.agents/knowledge/glossary.md` | 移除/调整 Three.js；新增 Prompt Registry/契约资产/Cocos-MCP/Golden eval | 改 |
|
||||
| **新增** `.agents/skills/prompt-governance.md` | Prompt 治理 playbook（Registry/loader/eval/HITL） | 建 |
|
||||
| `contracts/prompts/`（新增目录） | Day-0 第 8 类契约（见 §9-3） | 建 |
|
||||
| `CLAUDE.md`（项目） | §3.1 game-studio 行的"3D"分层指向 Cocos | 视情况微调 |
|
||||
|
||||
### 6.2 不破坏的既定结论
|
||||
|
||||
- **强化**契约先行文化（prompt 成第 8 契约），不冲突。
|
||||
- Yudao `-api/-biz` 约定、`cn.huijing.game.module.*` 命名、单体启动可拆 —— 不变。
|
||||
- aigc 无状态 / studio 有状态边界 —— **强化**（Cocos-MCP 明确归 studio）。
|
||||
- 80% 生成成功率验收线、游戏流 Tier1 自研薄壳 —— 不变。
|
||||
- 不改 yudao-framework 层、不动 Dify/OpenGame 内核 —— 不变。
|
||||
|
||||
### 6.3 对 131 P0 / 五工位的影响（不擅自改数）
|
||||
|
||||
- Prompt Registry 是**工程基建（契约层）**，不直接增 P0 业务能力。
|
||||
- `T-AGC-09 测试脚本生成` 是**新增能力项**，可能 +1 P0。
|
||||
- 引擎从 Three.js→Cocos 是**选型替换**，不增 P0（Tier2/3 本就远期/探针）。
|
||||
- 计数变更口径列入 §9 待确认，沿用上轮"新增项默认进 v2.1 增量、不硬塞 MVP"原则。
|
||||
|
||||
---
|
||||
|
||||
## 7. 风险与缓解
|
||||
|
||||
| 风险 | 概率/影响 | 缓解 |
|
||||
|---|---|---|
|
||||
| Cocos web 包体重（MB 级）拖慢加载 | 高/中 | Tier2/3 **不进游戏流**，走渠道/App 分发；游戏流只跑 Tier1 自研<15KB |
|
||||
| Cocos-MCP agentic 不稳定/工具调用失败 | 高/中 | 同 LLM 降级铁律：失败退化为 Tier1/OpenGame 路径；MVP 仅 1 个探针验证链路 |
|
||||
| Git 流程拖慢运营迭代 | 中/中 | 轻量 PR 模板 + 自动 eval；常用 prompt 预留**参数槽**（运营改参数不改结构，免 PR） |
|
||||
| registry 与运行时不同步 | 中/高 | 部署强制校验 registry 版本；CI 卡 Schema；DB 镜像只读 |
|
||||
| Golden 集维护成本 | 中/中 | 每 prompt 5–10 条核心样本起步，bad case 增量补；不追全覆盖 |
|
||||
| 双引擎 prompt 形态差异大，Registry 抽象漏 | 中/中 | frontmatter `engine` 字段区分，加载器按 engine 分发；目录分治不强行统一模板 |
|
||||
| prompt 注入攻击 / 越权 | 中/高 | guardrails 内置 injection-detect + 输出 Schema 校验；与内容安全双层链路同治理 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 验收标准（本评审版"通过"= 你确认以下五点）
|
||||
|
||||
1. 采纳 **Prompt-as-Contract + Git Registry**（§3/§4.1/§4.2）。
|
||||
2. 采纳 **Eval 轻量门禁四道闸 + 人工抽检**（§4.4），可玩性靠行为指标反哺。
|
||||
3. 采纳 **HITL 两类节点**（§4.5）。
|
||||
4. 采纳 **引擎最终态**：Cocos 统一 Tier2/3、移除 Three.js（§4.7）。
|
||||
5. §9 待确认项给出选择。
|
||||
|
||||
---
|
||||
|
||||
## 9. 待确认项（✅ 2026-06-07 全部采纳推荐(a)）
|
||||
|
||||
| # | 待确认 | 选项 | 我的建议 |
|
||||
|---|---|---|---|
|
||||
| 1 | **测试脚本生成归属** | (a) aigc 新增 `T-AGC-09` 原子；(b) 新增 qa 模块；(c) 并入 runtime | **(a)**：无状态原子属 aigc，runtime 执行，最小新增 |
|
||||
| 2 | **Cocos-MCP 编排归属** | (a) studio；(b) aigc；(c) 新模块 | **(a)**：有状态 agentic 符合 studio 边界，防 aigc 过载 |
|
||||
| 3 | **Prompt Registry 是否纳入 Day-0 契约** | (a) 是，7→**8 契约**，Day-0 锁；(b) 否，作后续基建 | **(a)**：prompt 是生成链路的契约源，应与 API/DB/SDK 同期锁 |
|
||||
| 4 | **新增项的 131 P0 计数** | (a) 进 v2.1 增量批次；(b) 并入 MVP 重算 | **(a)**：守 3 周窗口，沿用上轮原则 |
|
||||
| 5 | **引擎回填载体** | (a) in-place 改 tech-decisions 等；(b) 新建 v2.1 | **(a)**：引擎决策已定，直接改蒸馏文件 + 登记决策行 |
|
||||
| 6 | **MVP 阶段 prompt 覆盖范围** | (a) 先覆盖 Tier1 全链路(intent/codegen-opengame/asset/narrative/lockstyle/qa/convert/ops)；(b) 含 Cocos-MCP 探针 | **(a)**：Tier1 是 MVP 唯一交付层，Cocos-MCP 仅留探针 prompt |
|
||||
|
||||
---
|
||||
|
||||
## 10. 落地路径（确认后）
|
||||
|
||||
1. **执行版文档** `2026-06-07-prompt治理体系-execution.md`：Registry 目录落地、`PromptRegistryLoader` 接口契约、eval CI 流程、`T-AGC-09` 契约、HITL 节点对接点。
|
||||
2. **并行回填**引擎决策（§6.1 清单）+ 新建 `.agents/skills/prompt-governance.md` playbook。
|
||||
3. 按 CLAUDE.md **两轮评审** → 子代理拆分阶段 spec → 子代理评审。
|
||||
4. **Day-0** 把 `contracts/prompts/` 作为第 8 契约纳入（若 §9-3 选 a）。
|
||||
|
||||
---
|
||||
|
||||
> 评审反馈请直接在本文件批注或回话；§9 给出选择后，我产出执行版并开始回填。
|
||||
290
docs/agent-specs/2026-06-07-模块重划分-review.md
Normal file
290
docs/agent-specs/2026-06-07-模块重划分-review.md
Normal file
@ -0,0 +1,290 @@
|
||||
# 绘境AI v2.0 → v2.1 模块重划分（评审版）
|
||||
|
||||
> ✅ **已执行（2026-06-07）**：本评审结论已落地——能力清单拆为三文档（`产品需求清单`/`技术架构与模块`/`需求模块映射`），模块 12→13（新增 game-module-studio）。本文存档为**决策依据**；文中"待确认/动作"等列保留为**决策当时状态**，不再回填。
|
||||
|
||||
> 文档类型：评审版（供人决策，结论先行，不含代码级执行细节）
|
||||
> 文档 ID：HJ-ARCH-RDIV-001
|
||||
> 生成时间：2026-06-07
|
||||
> 触发来源：`docs-design/zaomeng-ai-demo.html`（产品视角）与原《业务能力全景与模块归属》（技术视角，已拆分为三文档并删除，历史见 git）的覆盖差分析（G1–G7）
|
||||
> 决策方式：方案 B（新增编辑器域 + 显式化两个横切关注点），创始人已选定力度（2026-06-07）
|
||||
> 待你确认后，再回填：能力全景、`.agents/knowledge`、受影响架构文档
|
||||
|
||||
---
|
||||
|
||||
## 1. 结论（先看这段）
|
||||
|
||||
1. **demo 不是技术文档的子集，而是同一系统的另一视角投影。** demo 讲"创作者看到/操作什么"（产品视角），能力全景讲"工程如何分解"（技术视角）。两者本不该 1:1，但 demo 暴露出三类**技术文档没有干净归属**的能力，必须补建模并重划模块。
|
||||
|
||||
2. **核心动作 = 12 → 13 模块，新增 `game-module-studio`（创作编排/编辑器域）**，把 demo "工作坊"承载的**有状态创作能力**（六资产模块化调度、角色骨骼/动画编辑、对白分支调试、附件驱动、agentic 任务链）从 aigc 中剥离；**aigc 收敛为无状态"生成原子"**。这是本次重划唯一的新增模块。
|
||||
|
||||
3. **两个横切关注点显式建模、指定 owner，不新增模块**：
|
||||
- **锁风门（风格-版权一致性 Gate）** → owner = compliance，aigc/ip 供检测原子；
|
||||
- **专区运营（Zone 双轨）** → owner = project，feed/ip/studio 消费。
|
||||
两者今天散落在 3 个模块的 P2 能力里、无单一负责人，是 demo 主骨架却在技术文档里"虚线存在"。
|
||||
|
||||
4. **runtime 扩"渠道发布状态机 + TapTap 提审通道"**，把 demo 的"自有必选 / 外部待开通"一键多渠道发布补成真实状态机。
|
||||
|
||||
5. **不踩翻已裁定结论**：保持 Yudao `-api/-biz` 模块约定与单体启动；不改 framework 层；MVP 阶段 studio 可在单体内以薄层运行。**但新增/提升的工程能力项会改变 131 P0 计数**——这一项我**不擅自改数**，列入待确认（§10）。
|
||||
|
||||
> 一句话：**demo 暴露的不是几个漏掉的功能，而是一个被 aigc 吞掉的"创作编辑器领域"，外加两条没人负责的横切主线。** 重划就是给它们各自一个干净的家。
|
||||
|
||||
---
|
||||
|
||||
## 2. 背景与问题
|
||||
|
||||
### 2.1 两视角差（你的判断，落到工程上）
|
||||
|
||||
| | demo（产品视角） | 能力全景（技术视角） |
|
||||
|---|---|---|
|
||||
| 回答 | WHAT：用户看到/操作什么 | HOW：工程怎么分解部署 |
|
||||
| 组织轴 | 信息架构（素材→模板→工作坊→广场/流→数据→B端），脊柱是**授权IP / UGC 双轨** | 12 个后端业务模块 + Yudao 原生层 |
|
||||
| 粒度 | 交互面 / 页面 | 模块 / 能力项 / 依赖 |
|
||||
|
||||
### 2.2 上一轮分析暴露的 7 个缺口（G1–G7）
|
||||
|
||||
| 缺口 | demo 现象 | 技术文档现状 | 性质 |
|
||||
|---|---|---|---|
|
||||
| G1 | 双专区（现象级授权IP / UGC孵化）贯穿广场/素材/工作坊/信息流 | 仅散落"精选池(P0)、IP孵化(P2)、外部IP(P1)"，无统一 Zone | **横切主线无 owner** |
|
||||
| G2 | 锁风（标签/强度/人工复核），调试通过率=锁风+性能+版权 | 散在 aigc 风格标签 / ip 风格校验(P2) / compliance 审核，无统一 Gate | **横切主线无 owner** |
|
||||
| G3 | 角色骨骼拆件 + 多动作编辑 + 动作包导出 | aigc/runtime 均无此能力项 | **能力缺失** |
|
||||
| G4 | 六类资产模块化生成（图元/角色/特效/场景/界面/音乐）+ 拖拽附件驱动 | aigc 图/音/剧情生成均为 P2 且未模块化 | **粒度/优先级错位** |
|
||||
| G5 | 授权IP 分支对白调试台（选分支→实时写入试玩节点） | 仅"剧情对话生成(aigc36, P2)" | **能力缺失** |
|
||||
| G6 | 一键多渠道发布（自有必选 + 抖音/微信/快手/TapTap 待开通） | runtime 小游戏转换（微信/抖音/快手），无 TapTap、无渠道状态机 | **能力不完整** |
|
||||
| G7 | 造梦智能体对话式 + 任务链可视化（7步） | aigc 偏"单次 Prompt → pipeline" | **范式分歧** |
|
||||
|
||||
### 2.3 根因（为什么"增量塞"不行）
|
||||
|
||||
- **aigc 过载**：G3/G4/G5/G7 全是**有状态、面向创作者、有自己数据模型**（创作会话 / 资产图 / 角色 rig / 对白树）的能力。塞进 aigc 会把"无状态生成原子服务"和"有状态编辑器领域"揉在一起，违反职责单一，也正是你 CLAUDE.md 明令拒绝的"拼接式设计"。
|
||||
- **横切无主**：G1/G2 是平台级主线，但被切成各模块的零散 P2 能力，没有任何一个模块为"专区运营""锁风一致性"负总责 → 落地时必然出现三个模块各做一半、接口对不齐。
|
||||
|
||||
---
|
||||
|
||||
## 3. 目标 / 非目标
|
||||
|
||||
**目标**
|
||||
- 为 G1–G7 的工程级能力项找到**唯一清晰的 owner 模块**。
|
||||
- 用**最小新增（仅 1 个模块）**消化 demo 暴露的"创作编辑器领域"。
|
||||
- 把两条横切主线（锁风、专区）从"虚线"升级为"显式建模 + 指定 owner"。
|
||||
- 保持与 Yudao 模块约定、单体启动、`.agents` 既有蒸馏、MVP 执行 spec 的兼容。
|
||||
|
||||
**非目标**
|
||||
- 不按产品 IA 重构全部模块边界（方案 C，已否决：过度设计 + 冲击 131 P0/五工位）。
|
||||
- 不改 yudao-framework 层。
|
||||
- 本评审版**不**产出代码、不产出 DB 表结构、不重排五工位排期——那是确认后的执行版工作。
|
||||
- 不在本轮擅自改 131 P0 的数字（见 §10）。
|
||||
|
||||
---
|
||||
|
||||
## 4. 推荐方案（方案 B 详解）
|
||||
|
||||
### 4.1 重划后的模块全景（13 模块）
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph 创作面["创作面（新增编辑器域）"]
|
||||
STUDIO["<b>game-module-studio</b><br/>创作编排/编辑器域 ★新增<br/>会话/资产图/rig/对白树/任务链"]
|
||||
end
|
||||
subgraph 生成与运行["生成与运行"]
|
||||
AIGC["aigc<br/>生成原子(收敛)<br/>LLM/图/音/模板/校验"]
|
||||
RUNTIME["runtime<br/>编译/沙箱/预览<br/>+渠道发布状态机/TapTap ★扩"]
|
||||
end
|
||||
subgraph 项目与分发["项目与分发"]
|
||||
PROJECT["project<br/>生命周期<br/>+专区Zone实体 ★扩"]
|
||||
FEED["feed<br/>游戏流<br/>+专区分区推荐 ★扩"]
|
||||
end
|
||||
subgraph 资产与合规["资产与合规"]
|
||||
IP["ip<br/>素材市场/版权<br/>+风格检测原子 ★扩"]
|
||||
COMPLIANCE["compliance<br/>合规/审核<br/>+锁风门Gate(owner) ★扩"]
|
||||
end
|
||||
subgraph 其余["其余（不变）"]
|
||||
TELEMETRY[telemetry]
|
||||
PAY[pay]
|
||||
TRADE[trade]
|
||||
COMMUNITY[community]
|
||||
BIZ[biz]
|
||||
AD[ad]
|
||||
end
|
||||
|
||||
STUDIO --> AIGC
|
||||
STUDIO --> RUNTIME
|
||||
STUDIO --> IP
|
||||
STUDIO --> PROJECT
|
||||
STUDIO --> COMPLIANCE
|
||||
```
|
||||
|
||||
> ★ = 本次受影响模块。新增 1（studio），扩容 4（aigc 收敛 / runtime / project / feed / ip / compliance）。其余 6 模块不动。
|
||||
|
||||
### 4.2 设计要点一：`game-module-studio` 与 aigc 的边界（最关键）
|
||||
|
||||
新模块只有在边界足够锋利时才不是"为拆而拆"。两者职责切面：
|
||||
|
||||
| 维度 | aigc（生成原子） | studio（创作编排/编辑器域） |
|
||||
|---|---|---|
|
||||
| 输入 | 单个 Prompt（+参考素材） | 创作会话（已选素材+模板+附件+历史） |
|
||||
| 输出 | **单个产物**（图/音/文本/GameConfig/代码片段） | **可试玩草稿**（多资产组合+编辑结果） |
|
||||
| 状态 | 无状态（任务级，幂等） | 有状态（会话/资产图/角色 rig/对白树） |
|
||||
| 调用关系 | 被 studio / biz 调用 | 调用 aigc/runtime/ip，最终落地 project |
|
||||
| 工程类比 | "纯函数 / 生成 API" | "IDE / 编排器 / 工作台后端" |
|
||||
|
||||
**studio 承载的工程能力（G3/G4/G5/G7 翻译为工程项）**：
|
||||
- 创作会话与草稿装配（会话 → project draft）
|
||||
- 六类资产模块化生成调度（按资产种类编排 aigc 原子）
|
||||
- 附件驱动创作上下文（生成产物/上传 → 统一附件 → 生成上下文）
|
||||
- agentic 任务链编排与进度流（7 步多资产组合链 + SSE；区别于 aigc 单任务进度）
|
||||
- 角色骨骼拆件管理 + 多动作编辑 + 动作包导出
|
||||
- 对白分支树编辑 + 实时写入预览节点
|
||||
|
||||
**前后端切分（避免误解）**：角色拆件/动画条/对白分支这些**重交互在 game-studio 前端（Vue）**；后端 `game-module-studio` 只持久化**会话、资产图、rig 数据、对白树、任务链状态**并做编排。编辑器 UX ≠ 后端模块。
|
||||
|
||||
### 4.3 设计要点二：锁风门（横切，owner = compliance）
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph 检测原子["检测原子（各模块供给）"]
|
||||
A1["aigc：生成风格一致性检测<br/>(产物是否符合声明风格)"]
|
||||
A2["ip：IP 风格一致性校验<br/>(是否偏离/侵犯已授权IP形象)"]
|
||||
end
|
||||
GATE["<b>compliance：锁风门 Gate</b><br/>聚合检测→分级决策<br/>pass / review / block<br/>强度:标准/严格/人工复核"]
|
||||
CHECK["project：发布前检查清单<br/>(锁风+性能+版权)"]
|
||||
A1 --> GATE
|
||||
A2 --> GATE
|
||||
GATE --> CHECK
|
||||
```
|
||||
|
||||
把 demo 的"锁风强度 / 调试通过率 / 人工复核"建模为**一个 Gate 决策 + 一组检测原子 + 一个挂载点（发布前检查 / 工作坊调试台）**。今天三处脱节的 P2 能力，升级为一条有负责人的关卡。
|
||||
|
||||
### 4.4 设计要点三：专区运营 Zone（横切，owner = project）
|
||||
|
||||
| 概念 | 工程建模 | owner | 消费方 |
|
||||
|---|---|---|---|
|
||||
| 专区实体 | Zone（licensed / ugc，可扩展）| project | 全线 |
|
||||
| 游戏→专区归属 | 游戏 zoneId | project | feed/广场 |
|
||||
| 专区运营位 | 精选 / 新游 / 全部（复用现"精选池"并泛化）| project + feed | studio/广场 |
|
||||
| 发布去向 | launchZone（demo 的"目标专区"下拉）| project | studio/runtime |
|
||||
| 专区分区推荐/浏览 | feed 按 zoneId 分区 | feed | 广场/信息流 |
|
||||
| 素材库双轨归类 | 素材按 Zone 来源归类（授权/UGC）| ip | 素材中心/studio |
|
||||
|
||||
demo 的"双轨脊柱"由此成为**一个实体 + 若干消费契约**，而非散落的精选池/孵化/外部IP。
|
||||
|
||||
### 4.5 设计要点四：runtime 渠道发布状态机 + TapTap
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> 自有已上线: 自有游戏流(必选, 无需转换)
|
||||
[*] --> 待开通: 外部渠道(抖音/微信/快手/TapTap)
|
||||
待开通 --> 申请中: 提交资质/提审
|
||||
申请中 --> 已开通: 渠道通过
|
||||
已开通 --> 已上线: 转换包推送成功
|
||||
申请中 --> 待开通: 驳回(可重提)
|
||||
```
|
||||
|
||||
- 统一发布编排链：**project（发布申请）→ compliance（锁风门+审核）→ runtime（各渠道转换/提审 + 状态机）→ feed（自有游戏流上架）**。
|
||||
- **TapTap ≠ 小游戏转换**：走"社区预约 + 试玩包提审"（APK/试玩包路径），与微信/抖音/快手的小游戏格式包是两条链路（与 `tech-decisions §1.1` 一致：快手无专用接口走微信格式转换；导出枢纽=微信小游戏格式包）。
|
||||
|
||||
---
|
||||
|
||||
## 5. 能力归位映射（G1–G7 → 工程能力项 → owner → 优先级）
|
||||
|
||||
> 优先级为**建议值**，最终 P0 计数变更见 §10。`提升` = 现有 P2/P1 能力升级；`新增` = net-new。
|
||||
|
||||
| # | 工程能力项 | owner 模块 | 来源 | 建议优先级 | 性质 |
|
||||
|---|---|---|---|---|---|
|
||||
| 1 | 创作会话与草稿装配 | studio | G7 | P0 | 新增 |
|
||||
| 2 | 六类资产模块化生成调度 | studio→aigc | G4 | P0 | 提升 |
|
||||
| 3 | 附件驱动创作上下文 | studio | G4/G7 | P0 | 新增 |
|
||||
| 4 | agentic 任务链编排与进度流 | studio | G7 | P1 | 提升 |
|
||||
| 5 | 角色骨骼拆件管理 | studio | G3 | P1 | 新增 |
|
||||
| 6 | 角色多动作编辑 + 动作包导出 | studio | G3 | P1 | 新增 |
|
||||
| 7 | 对白分支树编辑 | studio | G5 | P1 | 新增 |
|
||||
| 8 | 对白分支实时写入预览节点 | studio | G5 | P1 | 新增 |
|
||||
| 9 | 锁风门 Gate 聚合与分级决策 | compliance | G2 | P0 | 提升 |
|
||||
| 10 | 锁风强度策略（标准/严格/人工复核） | compliance | G2 | P1 | 新增 |
|
||||
| 11 | IP 风格一致性检测原子 | ip | G2 | P1 | 提升(ip16) |
|
||||
| 12 | 生成风格一致性检测原子 | aigc | G2 | P1 | 新增 |
|
||||
| 13 | 专区 Zone 实体与游戏归属 | project | G1 | P0 | 新增 |
|
||||
| 14 | 专区运营位（精选/新游/全部） | project+feed | G1 | P0 | 提升(精选池) |
|
||||
| 15 | 发布去向 launchZone | project | G1 | P0 | 新增 |
|
||||
| 16 | 专区分区推荐/浏览 | feed | G1 | P0 | 提升 |
|
||||
| 17 | 素材库按专区双轨归类 | ip | G1 | P1 | 提升 |
|
||||
| 18 | 渠道发布状态机 | runtime | G6 | P0 | 提升 |
|
||||
| 19 | TapTap 试玩包提审通道 | runtime | G6 | P1 | 新增 |
|
||||
| 20 | 统一发布编排（跨模块链） | project | G6 | P0 | 新增 |
|
||||
|
||||
合计约 **20 项**（净新增约 11，提升约 9）。其中建议 **P0 9 项 / P1 11 项**。
|
||||
|
||||
---
|
||||
|
||||
## 6. 关键取舍
|
||||
|
||||
| 取舍点 | 选择 | 放弃 | 理由 |
|
||||
|---|---|---|---|
|
||||
| 编辑器领域归属 | **独立 studio 模块** | 塞进 aigc（方案 A） | aigc 必须保持"无状态生成原子"纯度；编辑器是有状态领域，揉一起=拼接式设计 |
|
||||
| 重划力度 | **方案 B（13 模块）** | 方案 C（按 IA 重构） | C 打散 12 模块、偏离 Yudao 约定、冲击 131 P0/五工位，过度设计 |
|
||||
| 锁风/专区 | **横切显式建模，指定单一 owner** | 维持各模块零散 P2 | 横切主线必须有总负责人，否则接口对不齐、各做一半 |
|
||||
| TapTap | **独立提审通道** | 并入小游戏转换 | 路径不同（试玩包/APK vs 小游戏格式包），并入会污染转换逻辑 |
|
||||
| studio 部署 | **MVP 单体内薄层，全景中独立模块** | MVP 即独立服务 | 与"单体启动可平滑拆"原则一致，不提前增加运维成本 |
|
||||
|
||||
---
|
||||
|
||||
## 7. 爆炸半径与兼容性
|
||||
|
||||
### 7.1 受影响文档（确认后需回填）
|
||||
|
||||
| 文档 | 影响 | 动作 |
|
||||
|---|---|---|
|
||||
| 原《业务能力全景与模块归属》 | 12→13 模块、新增 ~20 能力项、模块依赖图 | 改：拆为 Doc A/B/C 三文档（落地见顶部横幅）|
|
||||
| `architecture/...v2模块架构与MVP覆盖度.md` | 该文仅 8 后端模块；需明确 studio 在 MVP 的薄层定位 | 改：补 studio + 锁风/专区映射 |
|
||||
| `.agents/knowledge/product-and-architecture.md` | §5 "12 模块速查"、§6 依赖图 | 改：13 模块 + studio 边界 |
|
||||
| `.agents/knowledge/tech-decisions.md` | §4 张力表新增"模块划分"条目；TapTap 链路 | 改：登记本次决策 |
|
||||
| `.agents/knowledge/mvp-scope-and-milestones.md` | 131 P0 计数 + 五工位归属可能变 | 改：见 §10 确认后 |
|
||||
| `.agents/knowledge/glossary.md` | 新增术语：创作会话/资产图/锁风门/专区Zone | 改：补术语 |
|
||||
| `CLAUDE.md`（项目） | §3.1 game-studio 技术栈行可补"创作会话编排" | 视情况微调 |
|
||||
|
||||
### 7.2 不破坏的既定结论
|
||||
|
||||
- Yudao `-api/-biz` 分层、`cn.huijing.game.module.{模块}` 命名、单体启动可拆 —— **studio 完全遵循**。
|
||||
- 不改 framework 层。
|
||||
- 131 P0 / 80% 生成成功率 / 五工位并行 —— **本评审版不改，变更项全部进 §10 待确认**。
|
||||
- 分层运行时（Tier1<15KB / Three.js / Tier3 待定）—— 不受影响；TapTap 提审属 Tier3 路径，与"MVP 后定引擎"不冲突。
|
||||
|
||||
### 7.3 风险点：MVP 五工位归属
|
||||
|
||||
新增 studio 会引出"工作坊编辑能力归哪个工位"的问题。建议（待确认）：studio 的 P0 能力（会话/资产调度/附件）并入现 AI 生成工位（WS 与 aigc 同工位协作），P1 编辑器能力（rig/动画/对白）排到 MVP 后或作为 P1 增量——避免冲击 3 周窗口。
|
||||
|
||||
---
|
||||
|
||||
## 8. 风险与缓解
|
||||
|
||||
| 风险 | 概率/影响 | 缓解 |
|
||||
|---|---|---|
|
||||
| studio 与 aigc 边界在落地时被侵蚀（又退回揉在一起） | 中/高 | §4.2 边界表写进执行版契约；code review 守"studio 不直接调 LLM/Diffusion" |
|
||||
| 锁风门聚合三方检测，链路一致性难 | 中/中 | 与内容安全双层链路同治理（阈值进 Nacos）；MVP 先做 pass/block 二态，review 态后置 |
|
||||
| 重划被误读为"推翻 131" | 中/高 | 本文 §10 明确：先裁定计数口径再动；新增项默认进 v2.1 增量而非硬塞 MVP |
|
||||
| 13 模块增加单体复杂度 | 低/中 | MVP 单体内薄层，Nacos profile 控制加载，不提前微服务化 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 验收标准（本评审版）
|
||||
|
||||
评审版"通过"= 你确认以下三点：
|
||||
1. 采纳方案 B（13 模块 = 12 + studio；锁风/专区横切显式化；runtime 扩渠道状态机）。
|
||||
2. §5 能力归位映射的 **owner 归属** 无异议（尤其 studio/aigc 边界、锁风=compliance、专区=project）。
|
||||
3. §10 待确认项给出选择。
|
||||
|
||||
通过后，下一轮交付：执行版文档（`...-模块重划分-execution.md`）+ 回填能力全景/`.agents`/受影响文档，并按你 CLAUDE.md 跑两轮评审。
|
||||
|
||||
---
|
||||
|
||||
## 10. 待确认项（需你拍板，影响下一轮回填）
|
||||
|
||||
| # | 待确认 | 选项 | 我的建议 |
|
||||
|---|---|---|---|
|
||||
| 1 | **131 P0 计数如何处理**（§5 约 20 项里 P0 建议 9 项） | (a) 维持 131，新增 P0 进 v2.1 增量批次；(b) 并入 MVP，131→重算；(c) 部分并入（仅专区/锁风/渠道状态机基础 4–5 项 P0） | **(c)**：双轨/锁风/发布是 demo 首屏骨架，基础项进 MVP；编辑器精修（rig/动画/对白）进 v2.1 |
|
||||
| 2 | **专区 Zone 的 owner** | (a) project；(b) feed | **(a) project**：Zone 是游戏运营归类+上架去向，属生命周期；feed 仅消费 |
|
||||
| 3 | **新模块命名** | `game-module-studio` / `game-module-editor` / `game-module-craft` | **studio**：与产品端 game-studio 同名呼应"创作工作台后端"，语义最贴 |
|
||||
| 4 | **回填载体** | 你已选"先评审后回填"；但回填时改 v2.0 全景 in-place 还是新建 v2.1？ | **新建 v2.1**：保留 v2.0 快照，v2.1 承载 13 模块，旧档加指针 |
|
||||
| 5 | **MVP 五工位归属**（§7.3） | (a) studio P0 并入 AI 生成工位；(b) 单独工位 | **(a)**：3 周窗口不宜加工位，studio 与 aigc 同工位协作 |
|
||||
|
||||
---
|
||||
|
||||
> 评审反馈请直接在本文件批注或回话；确认后我产出执行版并开始回填。
|
||||
@ -1,713 +0,0 @@
|
||||
# 绘境AI v2.0 -- 业务能力全景与模块归属
|
||||
|
||||
> 生成时间：2026-06-06
|
||||
> 基于 6 个子代理穷举结果去重合并，对齐已确认架构（Yudao Cloud fork）
|
||||
> 技术栈：Java 17 + Spring Cloud Alibaba + MySQL + RocketMQ + Vue3
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块总览
|
||||
|
||||
| 模块 ID | 一句话职责 | 面向端 | 核心技术栈 |
|
||||
|---|---|---|---|
|
||||
| game-module-project | 游戏项目全生命周期管理（创建/版本/草稿/发布/审核/状态机） | studio + admin | Java/Spring Boot + MySQL + BPM(Flowable) |
|
||||
| game-module-aigc | AI 生成引擎（Prompt 解析/模板匹配/LLM 编排/DAG 工作流/生成任务） | studio + admin | Java/Spring Boot + RocketMQ + LLM API |
|
||||
| game-module-runtime | 游戏运行时与包交付（编译/打包/Manifest/沙箱/小游戏转换/调试） | studio + admin | Java + OSS + 前端 Phaser3/Canvas |
|
||||
| game-module-feed | 游戏流推荐与玩家互动（Feed/推荐算法/互动/举报/分享） | studio + admin | Java + Redis + MySQL |
|
||||
| game-module-telemetry | 遥测与数据智能（事件摄取/聚合/看板/质量评分/告警） | studio + admin | Java + RocketMQ + MySQL(ClickHouse 远期) |
|
||||
| game-module-pay | 支付与订阅（积分充值/会员/游戏内购/打赏） | studio + admin | Java + 微信支付/支付宝/Apple IAP |
|
||||
| game-module-trade | 商业化与结算（广告分成/创作者钱包/素材交易/B端收款/财务对账） | studio + admin | Java + 广告联盟 API + 分账引擎 |
|
||||
| game-module-community | 社区与互动（评论/关注/动态/弹幕/排行/成就/创作者主页/消息通知） | studio + admin | Java + Redis + RocketMQ |
|
||||
| game-module-ip | IP 资产与版权（素材市场/版权管理/IP 孵化/授权/模型训练对接） | studio + admin | Java + DRM + 图像检测 API |
|
||||
| game-module-compliance | 合规与安全（内容安全/审核/RBAC/审计/隐私/防沉迷/渠道合规） | admin 为主 | Java + 内容安全 API + Redis |
|
||||
| game-module-biz | B/G 端业务（定制/教育/文旅/代运营/资质代办/项目管理） | admin + 独立 B 端门户 | Java + BPM + CRM |
|
||||
| game-module-ad | 广告引擎（广告位管理/AI 植入/联盟对接/展示上报/eCPM 优化） | studio + admin | Java + 广告联盟 SDK |
|
||||
|
||||
---
|
||||
|
||||
## 2. 模块依赖关系
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
PROJECT[project<br/>项目生命周期]
|
||||
AIGC[aigc<br/>AI 生成引擎]
|
||||
RUNTIME[runtime<br/>运行时与包]
|
||||
FEED[feed<br/>游戏流推荐]
|
||||
TELEMETRY[telemetry<br/>遥测与数据]
|
||||
PAY[pay<br/>支付与订阅]
|
||||
TRADE[trade<br/>商业化结算]
|
||||
COMMUNITY[community<br/>社区]
|
||||
IP[ip<br/>IP 资产版权]
|
||||
COMPLIANCE[compliance<br/>合规安全]
|
||||
BIZ[biz<br/>B/G 端业务]
|
||||
AD[ad<br/>广告引擎]
|
||||
|
||||
AIGC --> PROJECT
|
||||
RUNTIME --> PROJECT
|
||||
FEED --> PROJECT
|
||||
FEED --> TELEMETRY
|
||||
TRADE --> PAY
|
||||
TRADE --> AD
|
||||
AD --> RUNTIME
|
||||
IP --> PROJECT
|
||||
IP --> COMPLIANCE
|
||||
BIZ --> PROJECT
|
||||
BIZ --> AIGC
|
||||
COMMUNITY --> PROJECT
|
||||
COMPLIANCE --> PROJECT
|
||||
TELEMETRY --> FEED
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 各模块能力清单
|
||||
|
||||
### 3.1 game-module-project（项目生命周期）
|
||||
|
||||
**职责**：管理游戏从创建到下架的全生命周期，包括版本、草稿、发布审核、状态流转。
|
||||
|
||||
**依赖中间件**：MySQL, Redis, RocketMQ, BPM(Flowable), OSS(封面/素材存储)
|
||||
|
||||
**模块依赖**：yudao-system(用户/权限), yudao-bpm(审核工作流), yudao-infra(文件/通知)
|
||||
|
||||
| # | 能力名称 | 描述 | 优先级 | 前端归属 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 项目 CRUD | 创建/编辑/删除游戏项目，设置标题/slug/类型/标签 | P0 | studio + admin |
|
||||
| 2 | 游戏状态机 | draft/generating/generated/pending_review/published/rejected/unpublished/deleted 流转 | P0 | studio + admin |
|
||||
| 3 | 版本管理 | 版本号自增、覆盖更新、历史追溯、current_version_id 切换 | P0 | studio + admin |
|
||||
| 4 | 草稿保存与恢复 | 未发布游戏以 draft 状态云端保存，支持恢复编辑 | P0 | studio |
|
||||
| 5 | 标题/简介/封面/标签编辑 | 标题(80字)/简介(500字)/封面/标签(10个)/操作说明 | P0 | studio |
|
||||
| 6 | 发布前检查清单 | 自动校验可加载/标题/简介/封面/标签/适龄/安全通过 | P0 | studio + admin |
|
||||
| 7 | 发布审核(BPM) | 提交审核走 Flowable 工作流，对接 compliance 模块 | P0 | studio + admin |
|
||||
| 8 | 审核决策与操作 | 通过/拒绝/下架/加入精选/限制曝光 | P0 | admin |
|
||||
| 9 | 审核拒绝反馈 | 展示拒绝原因/修改建议/重新提交入口 | P0 | studio + admin |
|
||||
| 10 | 版本回退 | 保留历史 GameVersion 记录，可切换版本 | P1 | admin |
|
||||
| 11 | 游戏包导出 | 导出标准游戏工程包，预留多渠道审核元数据 | P1 | studio + admin |
|
||||
| 12 | 创作者主页 | 展示已发布游戏/数据/代表作品/粉丝数 | P0 | studio |
|
||||
| 13 | 精选池管理 | 运营将优质游戏加入/移出精选池 | P0 | admin |
|
||||
| 14 | 下架/封禁 | 运营对违规游戏执行下架或限制 | P0 | admin |
|
||||
|
||||
### 3.2 game-module-aigc（AI 生成引擎）
|
||||
|
||||
**职责**：接收自然语言 Prompt，通过 DAG 工作流编排完成模板匹配、LLM 调用、GameConfig 生成、代码生成、资源绑定。
|
||||
|
||||
**核心实现方案：Dify（自部署）+ OpenGame（二开）组合架构**
|
||||
|
||||
```
|
||||
┌────────────────────────────────────────────────────────┐
|
||||
│ game-module-aigc（Java 壳，Spring Boot） │
|
||||
│ ├─ Controller：接收创作请求 │
|
||||
│ ├─ TaskDispatcher：RocketMQ 异步调度 │
|
||||
│ ├─ DifyClient：HTTP 调用 Dify Workflow API │
|
||||
│ └─ ResultWriter：写入 project 模块（草稿/版本） │
|
||||
├────────────────────────────────────────────────────────┤
|
||||
│ Dify 实例（Docker 自部署） │
|
||||
│ ├─ DAG 可视化编排（管理员配置节点/条件/重试） │
|
||||
│ ├─ 多 LLM 适配（通义千问/DeepSeek/OpenAI 热切换） │
|
||||
│ ├─ 节点：Prompt 安全检测 → 意图解析 → 模板匹配 │
|
||||
│ ├─ 节点：GameConfig 生成 → JSON Schema 校验 │
|
||||
│ ├─ 节点：素材绑定/AI 图片生成 │
|
||||
│ ├─ 节点：OpenGame Agent 代码生成（HTTP 调用） │
|
||||
│ ├─ 节点：质量评估（结构完整性/资源有效性） │
|
||||
│ └─ 输出：完整 GamePackage（config + code + assets） │
|
||||
├────────────────────────────────────────────────────────┤
|
||||
│ OpenGame Agent（Python 微服务，HTTP API） │
|
||||
│ ├─ 6 阶段 Pipeline 复用（脚手架/设计/素材/代码/验证/修正）│
|
||||
│ ├─ 通用 LLM（DeepSeek-Coder/GPT-4o，先不用 GameCoder） │
|
||||
│ ├─ Game Skill 经验积累（模板级 few-shot） │
|
||||
│ └─ 输出：可运行 Web 游戏代码（HTML/JS/CSS + assets） │
|
||||
└────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**选型理由**：
|
||||
- Dify：开源、DAG 编排开箱即用、多模型切换、可观测性、API 发布、后续可开放给高级创作者自定义节点
|
||||
- OpenGame：CUHK MMLab 2025 SOTA，6 阶段 pipeline 经论文验证，开源框架+模型+benchmark
|
||||
- 组合 vs 自研：核心链路 4-6 周跑通 vs 自研 6-12 个月
|
||||
- 中后期增强：企业级监控/链路 trace/高并发优化在 Dify 壳外侧做，不改 Dify 内核
|
||||
|
||||
**依赖中间件**：RocketMQ(异步任务), Redis(状态/限流/熔断), MySQL, OSS, Dify(Docker), OpenGame(Docker/Python)
|
||||
|
||||
**模块依赖**：project(写入生成结果), compliance(Prompt 安全检测), infra(文件存储)
|
||||
|
||||
| # | 能力名称 | 描述 | 优先级 | 前端归属 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 自然语言 Prompt 解析 | LLM 理解意图并提取玩法/角色/规则/风格等结构化参数 | P0 | studio |
|
||||
| 2 | 模板分类与匹配 | 基于语义将创作意图映射到预制玩法模板(躲避/跑酷/射击/解谜/点击收集等) | P0 | studio |
|
||||
| 3 | GameConfig 结构化生成 | 将解析结果转为符合 JSON Schema 的游戏配置 | P0 | studio |
|
||||
| 4 | 模板参数校验与兜底 | 对 LLM 输出进行数值范围/必填字段/资源引用规则校验 | P0 | -- |
|
||||
| 5 | 生成任务异步队列调度 | RocketMQ 异步，管理优先级/重试/超时/削峰 | P0 | -- |
|
||||
| 6 | 生成任务状态机 | queued/running/succeeded/failed/timed_out/canceled 流转 | P0 | studio |
|
||||
| 7 | LLM 调用编排与熔断 | 超时(30s)/重试(2次)/熔断降级/供应商故障切换 | P0 | -- |
|
||||
| 8 | 多 LLM 供应商适配 | ProviderAdapter 抽象层支持通义/DeepSeek/OpenAI 切换 | P1 | admin(配置) |
|
||||
| 9 | Prompt 安全检测 | 违禁词/敏感内容/风险等级检测，拦截违规 | P0 | -- |
|
||||
| 10 | 确定性 Fallback 生成 | LLM 不可用时退化为模板填充 | P0 | -- |
|
||||
| 11 | 生成失败原因分类与提示 | 描述不清/违规/超时/匹配低/校验失败分类+可操作建议 | P0 | studio |
|
||||
| 12 | 生成进度实时展示 | SSE/轮询展示步骤(理解→配置→资源→预览)和百分比 | P0 | studio |
|
||||
| 13 | 生成超时后台通知 | 超 120s 提示用户可离开，完成后通知 | P0 | studio |
|
||||
| 14 | 玩法模板注册与管理 | 模板库(含 Schema/默认参数/示例)的 CRUD | P0 | admin |
|
||||
| 15 | 模板扩展与新增 | 低成本接入新玩法模板 | P1 | admin |
|
||||
| 16 | 风格标签体系 | 像素/卡通/赛博朋克/国风等标签影响素材和参数 | P0 | studio + admin |
|
||||
| 17 | 内置素材库管理 | 系统级美术/音效/UI 素材按风格/玩法分类 | P0 | admin |
|
||||
| 18 | 素材上传与校验 | MIME/扩展名/大小(5MB)/尺寸校验 | P0 | studio |
|
||||
| 19 | 素材去重与 hash 校验 | SHA256 hash 去重/完整性/CDN 缓存优化 | P0 | -- |
|
||||
| 20 | 示例 Prompt 库 | 每个模板 3-5 个可用示例 Prompt | P0 | studio |
|
||||
| 21 | 创作引导与新手教程 | 首次使用路径引导/类型说明/示例推荐 | P0 | studio |
|
||||
| 22 | 一键重新生成 | 不满意可一键重新生成或带修改描述重新生成 | P0 | studio |
|
||||
| 23 | Prompt 归一化与记录 | 原始 Prompt 存储+关联模板+风格标签 | P1 | -- |
|
||||
| 24 | 模板参数可调编辑 | 速度/敌人数量/关卡时长/胜负条件等参数调整 | P1 | studio |
|
||||
| 25 | DAG 工作流编排引擎 | 节点化生成流程(解析→匹配→LLM→校验→资源→打包)，支持条件/并行/重试 | P1 | admin(可视化) |
|
||||
| 26 | 节点配置与参数化 | 每个节点可独立配置(LLM 模型/温度/模板版本/素材源) | P2 | admin |
|
||||
| 27 | 用户工作流编排(可视化) | 创作者自定义创作流程节点编排 | P2 | studio |
|
||||
| 28 | 批量游戏生成 | 进阶创作者批量提交多个 Prompt | P2 | studio |
|
||||
| 29 | AI 玩法优化建议 | 根据行为数据输出时长/难度/交互优化建议 | P2 | studio |
|
||||
| 30 | AI 美术风格优化建议 | 推荐更受欢迎的美术风格调整方向 | P2 | studio |
|
||||
| 31 | AI 赛道洞察与趋势推荐 | 分析热门品类/竞品动态推荐高潜力方向 | P2 | studio |
|
||||
| 32 | 一键迭代生成 | 收到优化建议后一键生成新版本 | P2 | studio |
|
||||
| 33 | 游戏流专属版本自动生成 | 自动适配竖屏/短时长/3秒钩子格式 | P2 | -- |
|
||||
| 34 | 图像 AI 生成 | 根据风格标签生成角色/场景/UI 素材 | P2 | studio |
|
||||
| 35 | 音乐/音效 AI 生成 | AI 生成匹配风格的 BGM 和音效 | P2 | studio |
|
||||
| 36 | 剧情/对话 AI 生成 | AI 生成剧情/NPC 对话/关卡描述 | P2 | studio |
|
||||
| 37 | 封面/宣传图 AI 生成 | AI 为游戏生成社交分享封面和宣传素材 | P2 | studio |
|
||||
| 38 | Golden Config 回归测试 | 模板标准配置样例比对确保质量不退化 | P1 | admin |
|
||||
| 39 | 生成结果质量自动评估 | 基于结构完整性/资源有效性/运行成功率评分 | P1 | admin |
|
||||
|
||||
### 3.3 game-module-runtime（运行时与包）
|
||||
|
||||
**职责**：将 GameConfig 编译为可运行 Web 包，管理 Manifest/资源/版本化交付，提供沙箱运行环境和多渠道转换。
|
||||
|
||||
**依赖中间件**：OSS(包存储), Redis(缓存), CDN(资源分发), MySQL
|
||||
|
||||
**模块依赖**：project(读取版本信息), aigc(接收生成产物), telemetry(上报运行事件)
|
||||
|
||||
| # | 能力名称 | 描述 | 优先级 | 前端归属 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | GameConfig → 可运行 Web 包编译 | 编译 config + logic + assets → web bundle | P0 | -- |
|
||||
| 2 | GameManifest 生成与打包 | runtimeVersion/configUrl/assetList/hash/preloadPolicy/bundleSize | P0 | -- |
|
||||
| 3 | 游戏资源打包与上传 | 素材/配置/Bundle 打包上传 OSS，版本化路径组织 | P0 | -- |
|
||||
| 4 | Web 沙箱 iframe 隔离 | CSP + iframe sandbox 禁止访问父页面 DOM/Cookie/网络 | P0 | studio |
|
||||
| 5 | Game SDK 事件桥接 | postMessage 上报 load/start/30s/complete/error 生命周期事件 | P0 | studio |
|
||||
| 6 | Canvas/WebGL 渲染容器 | Phaser 3 + WebGL 轻量 2D 游戏引擎 | P0 | studio |
|
||||
| 7 | GameConfig 运行时注入 | 从 Manifest 加载配置驱动游戏逻辑 | P0 | studio |
|
||||
| 8 | 游戏实时预览 | 生成完成后立即在浏览器内试玩 | P0 | studio |
|
||||
| 9 | 游戏资源大小限制 | 总资源 <=10MB, 首屏 <=2MB, 超出则失败 | P0 | -- |
|
||||
| 10 | 资源 hash 命名长期缓存 | hash 文件名启用 CDN 永久缓存 | P0 | -- |
|
||||
| 11 | 资源版本化路径 | /games/{gameId}/versions/{versionId}/ 路径组织 | P0 | -- |
|
||||
| 12 | 预加载与三容器策略 | 当前游戏播放时预加载下一款 Manifest+关键资源，只保留前/当/后三容器 | P0 | studio |
|
||||
| 13 | 加载超时自动跳过 | 超时后自动切换下一款并记录 game_load_failed | P0 | studio |
|
||||
| 14 | 运行错误捕获与上报 | 前端捕获加载/运行错误，记录日志并降权 | P0 | studio |
|
||||
| 15 | 多端适配(移动/桌面) | 触控 + 键盘两套控制方式 | P0 | studio |
|
||||
| 16 | 竖屏全屏适配 | 统一竖屏滑动游玩模式 | P0 | studio |
|
||||
| 17 | postMessage 来源校验 | 校验 iframe 事件来源和 schema 防伪造 | P0 | studio |
|
||||
| 18 | Manifest 完整性校验 | 资源列表/hash/字段完整性校验 | P0 | -- |
|
||||
| 19 | GameConfig 静态校验 | 模板级 JSON Schema 校验 | P0 | -- |
|
||||
| 20 | 低端设备降级(低画质模式) | 限制粒子/音频预加载，帧率锁 30fps | P1 | studio |
|
||||
| 21 | 帧率监控 | 采集运行 FPS 用于质量评估和降级决策 | P1 | -- |
|
||||
| 22 | 弱网/离线兜底 | 重试按钮 + sendBeacon + Service Worker 短缓存 | P1 | studio |
|
||||
| 23 | 素材压缩与处理 | WebP/AVIF 转换/尺寸裁剪/压缩 | P1 | -- |
|
||||
| 24 | 多尺寸封面裁剪 | 封面多尺寸版本按设备加载 | P1 | -- |
|
||||
| 25 | 音频延迟加载 | 非关键音频懒加载降低首屏时间 | P1 | studio |
|
||||
| 26 | CDN 缓存刷新 | 发布时刷新需更新的 HTML/Manifest CDN 缓存 | P0 | -- |
|
||||
| 27 | 小游戏转换(微信) | 源工程打包为微信小程序格式 | P1 | admin |
|
||||
| 28 | 小游戏转换(抖音) | 源工程打包为抖音小游戏格式 | P1 | admin |
|
||||
| 29 | 小游戏转换(快手) | 源工程打包为快手小游戏格式 | P1 | admin |
|
||||
| 30 | 渠道适配规则库 | 各渠道尺寸/资质/文案/违禁词自动适配规则 | P1 | admin |
|
||||
| 31 | 自动图标封面生成 | 自动生成各渠道规格图标/封面/截图 | P1 | -- |
|
||||
| 32 | 渠道合规简介改写 | AI 改写各渠道合规简介/关键词 | P1 | admin |
|
||||
| 33 | 统一工程转译引擎 | 一份源自动编译成各渠道打包格式 | P1 | -- |
|
||||
| 34 | 游戏可玩性自动测试 | Playwright 加载验证资源/启动/SDK 事件/帧率 | P1 | admin |
|
||||
| 35 | 运行时链路追踪(调试) | 开发模式下 trace_id 贯穿生成→编译→加载→运行全链路 | P1 | studio(开发模式) |
|
||||
| 36 | 游戏包体积监控 | 监控资源大小，超限阻止发布 | P0 | admin |
|
||||
| 37 | 云游戏即时运行容器(远期) | 0 秒加载云游戏运行环境 | P2 | studio |
|
||||
|
||||
### 3.4 game-module-feed（游戏流与推荐）
|
||||
|
||||
**职责**：管理游戏流 Feed 推荐、玩家互动（点赞/收藏/分享/举报）、分享页、冷启动与降权策略。
|
||||
|
||||
**依赖中间件**：Redis(候选集缓存/限流), MySQL, CDN(分享页静态资源)
|
||||
|
||||
**模块依赖**：project(读取已发布游戏), telemetry(quality_score/行为信号), compliance(举报处理)
|
||||
|
||||
| # | 能力名称 | 描述 | 优先级 | 前端归属 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | Feed 推荐列表 | 规则排序(精选+新发布+质量分+互动率+错误率+保底曝光) | P0 | studio |
|
||||
| 2 | Feed cursor 分页 | lastScore/lastPublishedAt/lastGameId 无限滚动 | P0 | studio |
|
||||
| 3 | Feed 候选集缓存 | Redis 预计算短 TTL(60s) 缓存 | P0 | -- |
|
||||
| 4 | 新人保底曝光 | 新作品固定基础曝光量 | P0 | -- |
|
||||
| 5 | 低质内容降权 | 高跳出/加载失败/举报高自动降权 | P0 | admin |
|
||||
| 6 | 冷启动策略 | 精选+最新+高互动组合，人工干预 | P0 | admin |
|
||||
| 7 | 上下滑切换 | 移动端纵向滑动/桌面滚轮键盘切换 | P0 | studio |
|
||||
| 8 | Feed 去重 | 同一会话不重复推送同 gameId | P1 | -- |
|
||||
| 9 | 点赞功能 | 玩家点赞，影响推荐权重 | P0 | studio |
|
||||
| 10 | 收藏功能 | 玩家收藏到个人收藏夹 | P0 | studio |
|
||||
| 11 | 分享功能 | 分享到微信/抖音/快手等社交平台 | P0 | studio |
|
||||
| 12 | 举报功能 | 玩家举报违规/低质/抄袭 | P0 | studio |
|
||||
| 13 | 独立分享链接 | 已发布游戏生成独立可访问分享 URL | P0 | studio |
|
||||
| 14 | Open Graph 元数据 | OG title/description/image 供社交平台预览 | P0 | studio |
|
||||
| 15 | 分享落地页 | 展示封面/标题/简介/立即游玩入口 | P0 | studio |
|
||||
| 16 | 渠道参数(utm) | 支持 utm_source/utm_medium/utm_campaign/channel | P1 | -- |
|
||||
| 17 | Web Share API | 移动端系统原生分享或复制链接 | P1 | studio |
|
||||
| 18 | 行为信号推荐 | 停留时长/复玩率/完关率/点赞分享加权排序 | P0 | -- |
|
||||
| 19 | 推荐策略 A/B 测试 | 不同排序公式/权重/曝光比例对照实验 | P1 | admin |
|
||||
| 20 | 个性化推荐算法 | 千人千面推荐(增长阶段) | P2 | -- |
|
||||
| 21 | 加载进度反馈 | 封面/进度条/跳过入口 | P0 | studio |
|
||||
| 22 | 首屏封面展示 | 封面/标题/作者/玩法说明/开始按钮 | P0 | studio |
|
||||
| 23 | 精选池管理接口 | 运营操作精选加入/移出 API | P0 | admin |
|
||||
|
||||
### 3.5 game-module-telemetry（遥测与数据）
|
||||
|
||||
**职责**：统一采集全链路事件，聚合质量评分，提供创作者/运营/管理层数据看板，驱动告警。
|
||||
|
||||
**依赖中间件**：RocketMQ(事件异步入库), MySQL(聚合表)/ClickHouse(远期), Redis(限流/计数), Prometheus+Grafana
|
||||
|
||||
**模块依赖**：feed(反哺 quality_score), project(关联游戏), compliance(安全事件)
|
||||
|
||||
| # | 能力名称 | 描述 | 优先级 | 前端归属 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 事件批量摄取 | /events/batch 端点，异步入库 | P0 | studio(上报) |
|
||||
| 2 | 事件 Schema 治理 | 统一事件名/字段/类型/版本管理 | P0 | -- |
|
||||
| 3 | 埋点批量上报 | 前端每 10 条或 5s flush，sendBeacon 兜底 | P0 | studio |
|
||||
| 4 | 内容质量评分(quality_score) | 基于完成率/30s 留存/点赞率/收藏率/举报率/失败率计算 | P0 | admin |
|
||||
| 5 | 事件聚合(GameDailyStats) | 增量聚合曝光/试玩/互动/留存反哺推荐 | P0 | -- |
|
||||
| 6 | 创作者数据看板 | 单游戏曝光/试玩/互动/加载失败率/7 天趋势 | P1 | studio |
|
||||
| 7 | 创作漏斗分析 | prompt_submit→generation_success→publish 转化率 | P0 | admin |
|
||||
| 8 | 游戏流消费漏斗 | impression→load→start→30s→complete→interaction 逐级转化 | P0 | admin |
|
||||
| 9 | 运营数据看板 | 审核积压/供给量/生成成功率/失败率/举报率 | P0 | admin |
|
||||
| 10 | 管理层经营看板 | MAU/留存/收入/成本/创作者规模 CEO 级指标 | P1 | admin |
|
||||
| 11 | 玩家留存分析 | 次日/7 日/30 日留存按渠道/设备/内容细分 | P0 | admin |
|
||||
| 12 | 创作者复创率追踪 | 发布后 7 日再次创作比例 | P0 | admin |
|
||||
| 13 | 平台 Product Metrics | activation/success_rate/publish_conversion/session_games/d7_retention | P0 | admin |
|
||||
| 14 | 游戏加载时间埋点 | load_start/load_success/load_failed 及耗时 | P0 | -- |
|
||||
| 15 | 运行时 FPS 采集 | 平均帧率用于质量和性能告警 | P1 | -- |
|
||||
| 16 | 实时监控-服务健康 | API 延迟/错误率/队列积压/DB 连接/Redis 命中率 | P0 | admin |
|
||||
| 17 | 实时监控-生成任务健康 | 成功率/失败分布/平均耗时/队列等待 | P0 | admin |
|
||||
| 18 | 实时监控-Runtime 健康 | 加载成功率/运行错误率/FPS/资源加载时长 | P0 | admin |
|
||||
| 19 | 异常检测与告警 | 5xx>2%/P95>800ms/成功率<70%/积压>500/失败>8% 自动告警 | P0 | admin |
|
||||
| 20 | 生成失败根因分析 | 按 error_code 聚合失败原因 | P0 | admin |
|
||||
| 21 | 渠道归因分析 | utm/channel 追踪渠道访问/试玩/转化 | P1 | admin |
|
||||
| 22 | 数据导出(投资人/复盘) | CSV/JSON 导出核心指标 | P1 | admin |
|
||||
| 23 | 数据质量监控 | 埋点丢失率/字段缺失率/异常值监控 | P1 | admin |
|
||||
| 24 | 推荐效果监控 | 曝光均匀度/保底消耗/精选 CTR/马太效应 | P1 | admin |
|
||||
| 25 | 玩家设备/性能画像 | 设备型号/分辨率/网络/FPS/加载时长 | P1 | admin |
|
||||
| 26 | AI 优化建议-封面/标题 | 曝光高点击低时建议优化 | P1 | studio |
|
||||
| 27 | 简单优化建议(规则) | 封面 CTR 低/加载失败率高等规则提示 | P1 | studio |
|
||||
| 28 | 重复内容检测 | 重复标题/素材/Prompt 基础识别 | P1 | admin |
|
||||
|
||||
### 3.6 game-module-pay（支付与订阅）
|
||||
|
||||
**职责**：管理用户付费行为（积分充值/会员订阅/游戏内购/打赏），统一支付网关抽象。
|
||||
|
||||
**依赖中间件**：MySQL, Redis(幂等/限流), 微信支付/支付宝/Apple IAP
|
||||
|
||||
**模块依赖**：yudao-system(用户), trade(提供余额给结算)
|
||||
|
||||
| # | 能力名称 | 描述 | 优先级 | 前端归属 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 积分充值 | 创作者付费充值积分用于 AI 生成操作 | P0 | studio |
|
||||
| 2 | 支付网关抽象 | 统一对接微信支付/支付宝/Apple IAP | P0 | -- |
|
||||
| 3 | 会员订阅体系 | 进阶创作者月度订阅(29.9元/月)，享全站素材/高流量权益 | P1 | studio |
|
||||
| 4 | 付费推广流量包 | 创作者购买推广套餐(99/299 元)提升曝光 | P1 | studio |
|
||||
| 5 | 游戏内购-道具 | 玩家付费购买复活/加速/特殊能力 | P2 | studio |
|
||||
| 6 | 游戏内购-皮肤与角色 | 玩家付费解锁角色皮肤/外观 | P2 | studio |
|
||||
| 7 | 游戏内购-关卡解锁 | 玩家付费解锁高级关卡/剧情 | P2 | studio |
|
||||
| 8 | 打赏创作者 | 玩家直接打赏喜爱的创作者 | P2 | studio |
|
||||
| 9 | 支付订单管理 | 订单状态/退款/对账 | P0 | admin |
|
||||
| 10 | 会员等级与权益 | 不同会员解锁功能(多人协同/高级模板/批量生成/优先队列) | P1 | studio + admin |
|
||||
| 11 | B 端项目在线支付 | B/G 端客户在线支付定制费用(预付/分期/尾款) | P2 | admin |
|
||||
|
||||
### 3.7 game-module-trade（商业化与结算）
|
||||
|
||||
**职责**：管理广告分成结算、创作者钱包、素材交易佣金、B 端收款、财务对账报表。
|
||||
|
||||
**依赖中间件**：MySQL, Redis, 广告联盟结算 API, 银行转账/支付宝/微信企业付款
|
||||
|
||||
**模块依赖**：pay(支付入口), ad(广告收益数据), ip(素材交易), telemetry(收益数据)
|
||||
|
||||
| # | 能力名称 | 描述 | 优先级 | 前端归属 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 广告分成结算 | 平台与创作者按层级比例分成(小白 80%/进阶 75%/专业 70%) | P0 | admin |
|
||||
| 2 | 多渠道广告收入归集 | 统一归集自有+抖音+微信+快手渠道广告分成 | P0 | admin |
|
||||
| 3 | T+1 对账与结算周期 | 自有 T+1，外部按月结算 | P0 | admin |
|
||||
| 4 | 创作者钱包-余额管理 | 实时查看广告/素材/商单各类收入余额 | P0 | studio |
|
||||
| 5 | 创作者钱包-提现 | 银行卡/支付宝/微信提现，满 5 元即可 | P0 | studio |
|
||||
| 6 | 创作者钱包-收益明细 | 每日/每周/每月各渠道收益明细 | P0 | studio |
|
||||
| 7 | 素材交易佣金 | 素材市场交易平台抽取 30% | P1 | admin |
|
||||
| 8 | 税务处理 | 代扣个税/税务申报凭证 | P1 | admin |
|
||||
| 9 | 平台营收报表 | 按日/周/月汇总广告/充值/会员/佣金/推广/B 端收入 | P0 | admin |
|
||||
| 10 | 渠道分发收入归集 | 多渠道收入统一台账 | P0 | admin |
|
||||
| 11 | B 端项目应收管理 | 应收账款/账期/催收 | P1 | admin |
|
||||
| 12 | 财务合规(增值税/发票) | 平台税务申报/创作者个税/B 端发票 | P1 | admin |
|
||||
| 13 | 最低提现门槛与打款 | 5 元门槛/周月自动打款/即时到账 | P0 | -- |
|
||||
| 14 | 创作者收益透明度看板 | 实时展示收益/结算状态/提现进度 | P1 | studio |
|
||||
|
||||
### 3.8 game-module-community（社区）
|
||||
|
||||
**职责**：管理玩家社区互动（评论/关注/动态/排行/成就）、创作者社区（教程/赛事/协作）、消息通知。
|
||||
|
||||
**依赖中间件**：MySQL, Redis(排行/计数), RocketMQ(事件驱动推送), 推送服务(极光/Firebase)
|
||||
|
||||
**模块依赖**：project(关联游戏), yudao-system(用户), yudao-infra(站内信/短信/邮件)
|
||||
|
||||
| # | 能力名称 | 描述 | 优先级 | 前端归属 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 评论系统 | 玩家评论/创作者回复 | P1 | studio |
|
||||
| 2 | 关注创作者 | 玩家关注，获得新作推送 | P1 | studio |
|
||||
| 3 | 粉丝体系 | 粉丝列表/画像/私域池 | P1 | studio |
|
||||
| 4 | 创作者动态 Feed | 关注创作者发布新作品时动态页通知 | P1 | studio |
|
||||
| 5 | 排行榜(创作者/作品) | 按热度/收益/新人/圈层排行 | P1 | studio + admin |
|
||||
| 6 | 排行榜(玩家) | 按游戏/全局展示玩家成绩 | P1 | studio |
|
||||
| 7 | 成就系统 | 试玩 100 款/连续登录等成就徽章 | P2 | studio |
|
||||
| 8 | 弹幕互动 | 游戏中实时弹幕(可选) | P2 | studio |
|
||||
| 9 | 玩家个人主页 | 游玩记录/收藏/点赞/成就 | P2 | studio |
|
||||
| 10 | 好友系统 | 添加好友/查看好友在玩 | P2 | studio |
|
||||
| 11 | 组队/多人游玩 | 答题 PK/闯关合作 | P2 | studio |
|
||||
| 12 | 创作者教程体系 | 入门到进阶教程(视频/图文/示例) | P1 | studio |
|
||||
| 13 | 创作挑战赛 | 按主题/圈层/节日创作大赛 | P1 | studio + admin |
|
||||
| 14 | 多人协同创作(远期) | 团队多人同时编辑同一项目 | P2 | studio |
|
||||
| 15 | 创作者社群/圈子 | 按圈层交流社群 | P2 | studio |
|
||||
| 16 | 热门玩法拆解 | 爆款玩法/数据/设计拆解内容 | P1 | studio |
|
||||
| 17 | 圈层共创计划 | 垂类圈层专属模板和主题活动 | P2 | studio + admin |
|
||||
| 18 | 站内信系统 | 系统通知/运营公告/审核结果/收益变动 | P0 | studio + admin |
|
||||
| 19 | App 推送通知 | APNs/FCM/厂商通道推送 | P1 | studio |
|
||||
| 20 | 邮件通知 | 注册验证/审核/收益周报/活动 | P1 | -- |
|
||||
| 21 | 短信通知 | 验证码/安全提醒/提现到账 | P0 | -- |
|
||||
| 22 | 生成任务完成通知 | AI 生成完成/失败时通知 | P0 | studio |
|
||||
| 23 | 审核结果通知 | 通过/拒绝/下架即时通知 | P0 | studio |
|
||||
| 24 | 新粉丝/互动通知 | 关注/点赞/收藏/评论时通知 | P1 | studio |
|
||||
| 25 | 收益变动通知 | 入账/提现成功/结算完成通知 | P0 | studio |
|
||||
| 26 | 活动/赛事通知 | 新大赛/活动上线通知目标用户 | P1 | studio |
|
||||
| 27 | 创作者新作品通知 | 关注创作者发新作推送给粉丝 | P1 | studio |
|
||||
|
||||
### 3.9 game-module-ip（IP 资产与版权）
|
||||
|
||||
**职责**：管理素材市场（上架/交易/授权）、版权保护（投诉/仲裁）、IP 孵化（筛选/签约/授权/衍生）、模型训练对接。
|
||||
|
||||
**依赖中间件**：MySQL, OSS(素材存储), Redis, 内容安全 API, 图像检测服务
|
||||
|
||||
**模块依赖**：project(关联游戏), trade(交易结算), compliance(版权合规), aigc(素材生成)
|
||||
|
||||
| # | 能力名称 | 描述 | 优先级 | 前端归属 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 素材市场上架与定价 | 创作者上传美术/音效/UI/特效资源并定价 | P1 | studio |
|
||||
| 2 | 素材市场检索与推荐 | 按分类/风格/玩法/热度检索，AI 推荐适配素材 | P1 | studio |
|
||||
| 3 | 素材交易 | 买卖素材，平台抽佣 30% | P1 | studio |
|
||||
| 4 | 素材版权声明与管理 | 上传需版权证明或选择授权类型 | P1 | studio + admin |
|
||||
| 5 | 商用素材授权链 | 版权归属/授权范围/使用限制完整追溯 | P1 | admin |
|
||||
| 6 | 版权侵权投诉受理 | 接收投诉/冻结争议内容/启动调查 | P1 | admin |
|
||||
| 7 | DMCA/侵权下架 | 有效通知限时下架，支持反通知申诉 | P1 | admin |
|
||||
| 8 | 高风险素材冻结 | 疑似侵权素材立即冻结公开访问 | P1 | admin |
|
||||
| 9 | 素材安全扫描 | 对上传素材进行涉黄涉暴涉政检测 | P0 | -- |
|
||||
| 10 | 爆款筛选与签约 | 基于数据筛选高潜力爆款并独家签约 | P2 | admin |
|
||||
| 11 | IP 代运营 | 签约作品专业化运营(版本/推广/优化) | P2 | admin |
|
||||
| 12 | IP 周边衍生 | 表情包/壁纸/实体周边衍生 | P2 | admin |
|
||||
| 13 | IP 跨界联动 | 与外部品牌/影视/动漫联名合作 | P2 | admin |
|
||||
| 14 | IP 授权分成 | 对外授权收取费用并与创作者分成 | P2 | admin |
|
||||
| 15 | 外部成熟 IP 合作 | 引入外部 IP 做联名小游戏 | P1 | admin |
|
||||
| 16 | IP 风格校验 | 检测是否侵犯已知 IP 形象风格 | P2 | -- |
|
||||
| 17 | IP 盗用监测 | 监测外部平台未授权使用 | P2 | admin |
|
||||
| 18 | IP 风格模型训练对接 | 基于爆款 IP 美术风格训练生成模型(数据集导出/标注/训练触发) | P2 | admin |
|
||||
| 19 | 音色克隆对接(远期) | 基于 IP 角色声音训练音色模型 | P2 | admin |
|
||||
| 20 | 模板市场 | 创作者发布/购买可商用游戏模板 | P1 | studio + admin |
|
||||
| 21 | 模板授权分成 | 向第三方授权优质模板获取收益 | P2 | admin |
|
||||
| 22 | 创作大赛赞助 | 举办创作大赛收取品牌赞助费 | P2 | admin |
|
||||
|
||||
### 3.10 game-module-compliance（合规与安全）
|
||||
|
||||
**职责**：内容安全检测、审核流程、RBAC 权限、审计日志、隐私保护、防沉迷、渠道合规。
|
||||
|
||||
**依赖中间件**：MySQL, Redis(限频/违禁词缓存), 内容安全 API(阿里云/腾讯云), Sentry
|
||||
|
||||
**模块依赖**：yudao-system(RBAC/OAuth2), yudao-bpm(审核流), project(审核对象), feed(降权联动)
|
||||
|
||||
| # | 能力名称 | 描述 | 优先级 | 前端归属 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 文本内容安全检测 | Prompt/标题/简介/标签违禁词+语义检测 | P0 | -- |
|
||||
| 2 | 图片内容安全检测 | 封面/素材/AI 生成图涉黄涉暴涉政识别 | P0 | -- |
|
||||
| 3 | AI 生成内容风控 | LLM 输出 GameConfig/描述/角色合规校验 | P0 | -- |
|
||||
| 4 | 违禁词库管理 | 平台级违禁词/敏感词/行业黑名单动态更新 | P0 | admin |
|
||||
| 5 | 举报受理与处理 | 记录/限频/达阈值降权/进入复核队列 | P0 | admin |
|
||||
| 6 | 举报阈值自动降权 | 达阈值限制曝光+运营复核 | P0 | -- |
|
||||
| 7 | 人工审核队列 | 中高风险内容等待人工处理 | P0 | admin |
|
||||
| 8 | 审核决策与状态机 | 通过/拒绝/下架/精选/限制曝光 | P0 | admin |
|
||||
| 9 | 自动审核(机审通过) | 低风险按配置自动通过 | P1 | admin(配置) |
|
||||
| 10 | 风险等级分层策略 | low/medium/high 三级配置不同处理策略 | P0 | admin |
|
||||
| 11 | 管理员操作审计日志 | actor/action/target/metadata/ip/ua 全记录 | P0 | admin |
|
||||
| 12 | 审计日志长期保存 | 至少 180 天保留 | P0 | -- |
|
||||
| 13 | 安全日志与告警 | 登录失败/权限异常/未授权访问告警 | P0 | admin |
|
||||
| 14 | RBAC 权限控制 | 基于角色严格限制接口和操作 | P0 | admin |
|
||||
| 15 | 游戏沙箱隔离(CSP) | iframe sandbox + CSP 限制 | P0 | studio |
|
||||
| 16 | 上传文件安全校验 | MIME/扩展名/大小/恶意内容扫描 | P0 | -- |
|
||||
| 17 | Prompt 注入防护 | 防止用户 Prompt 控制 LLM 超出预期 | P0 | -- |
|
||||
| 18 | OWASP Top 10 防护 | 注入/访问控制/加密/SSRF 等安全基线 | P0 | -- |
|
||||
| 19 | Secrets 管理 | 密钥从 Secret Manager 读取，不写入代码 | P0 | -- |
|
||||
| 20 | 敏感数据加密存储 | 密码 Argon2/bcrypt，敏感字段加密脱敏 | P0 | -- |
|
||||
| 21 | 数据传输加密 | 全站 HTTPS | P0 | -- |
|
||||
| 22 | 日志脱敏 | Token/Key/密码/手机号不输出日志 | P0 | -- |
|
||||
| 23 | 登录安全与限频 | 登录失败限频/Refresh Token 轮换/设备撤销 | P0 | -- |
|
||||
| 24 | 匿名用户权限约束 | 匿名只能浏览试玩，不能发布/收藏/后台 | P0 | studio |
|
||||
| 25 | CORS 与 CSP 配置 | 严格 CORS 白名单 + CSP 头 | P0 | -- |
|
||||
| 26 | SSRF 防护 | URL allowlist + 内网 IP 阻断 | P1 | -- |
|
||||
| 27 | 依赖漏洞扫描 | PR 阶段 npm audit/Snyk/Trivy | P1 | -- |
|
||||
| 28 | 用户隐私政策 | 用户协议/隐私政策展示 | P0 | studio |
|
||||
| 29 | 用户数据最小化采集 | 只采集业务必需数据 | P0 | -- |
|
||||
| 30 | 用户数据删除权 | 删除草稿/下架/注销时清理数据 | P1 | studio |
|
||||
| 31 | GDPR/个保法预留 | 数据导出/删除/撤回授权接口 | P2 | studio |
|
||||
| 32 | 未成年人防沉迷 | 接入防沉迷限制时长和消费 | P1 | studio |
|
||||
| 33 | 实名认证 | 识别未成年人启用保护策略 | P1 | studio |
|
||||
| 34 | 适龄提示 | 全年龄/青少年/成人分级标签 | P0 | studio + admin |
|
||||
| 35 | 渠道审核规则库 | 微信/抖音/快手/TapTap 审核规则/违禁词 | P1 | admin |
|
||||
| 36 | 多渠道合规自动检测 | 提交前自动过滤敏感词/违规画面 | P1 | -- |
|
||||
| 37 | 创作者申诉机制 | 审核拒绝/下架后申诉/查看原因/修改建议 | P1 | studio + admin |
|
||||
| 38 | 用户封禁与限制发布 | 严重违规封禁/限制发布 | P0 | admin |
|
||||
| 39 | 数据备份与恢复 | 自动备份/定期验证/支持恢复 | P0 | -- |
|
||||
|
||||
### 3.11 game-module-biz（B/G 端业务）
|
||||
|
||||
**职责**：B/G 端定制服务（品牌营销/教育/文旅/政务）、项目管理、报价、交付、代运营。
|
||||
|
||||
**依赖中间件**：MySQL, BPM(Flowable), 电子签章服务, CRM
|
||||
|
||||
**模块依赖**：project(游戏项目), aigc(AI 生成), trade(收款结算), compliance(资质合规)
|
||||
|
||||
| # | 能力名称 | 描述 | 优先级 | 前端归属 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | B 端需求表单提交 | 企业客户标准化表单提交定制需求 | P0 | 独立 B 端门户 |
|
||||
| 2 | 模板库选择与预览 | B 端从分场景模板库选择并预览 | P0 | 独立 B 端门户 |
|
||||
| 3 | 定制进度看板 | 客户实时查看项目进度 | P0 | 独立 B 端门户 |
|
||||
| 4 | 交付验收流程 | 在线试玩验收/反馈/确认/签署 | P0 | 独立 B 端门户 |
|
||||
| 5 | B 端项目报价系统 | 根据复杂度/定制深度/渠道数自动报价 | P1 | admin |
|
||||
| 6 | B 端数据效果报告 | 互动数据/传播效果/用户画像报告 | P1 | admin |
|
||||
| 7 | B 端年度服务套餐 | 多次定制/运维/迭代年度合同 | P1 | admin |
|
||||
| 8 | B 端代运营服务 | 作品优化/推广/数据/版本迭代 | P1 | admin |
|
||||
| 9 | 品牌营销小游戏定制 | 门店引流/团建/品牌裂变/抽奖闯关 | P0 | admin |
|
||||
| 10 | 企业私域嵌入分发 | 嵌入企业微信/小程序/H5 活动页 | P1 | -- |
|
||||
| 11 | 青少年 AI 游戏创作课程 | 面向中小学/培训机构标准课程 | P1 | 独立 B 端门户 |
|
||||
| 12 | 课程授权体系 | 培训机构/高校课程包年度授权 | P1 | admin |
|
||||
| 13 | 教师培训服务 | 师资培训(线上+线下) | P1 | admin |
|
||||
| 14 | 学生作品展示平台 | 学生游戏作品专属展示页 | P1 | studio |
|
||||
| 15 | 校园创作大赛 | 联合学校举办 AI 创作比赛 | P1 | admin |
|
||||
| 16 | 教育场景答题科普模板 | 答题/科普/知识闯关教育模板 | P1 | admin |
|
||||
| 17 | 学生账号与防沉迷 | 教育场景学生专用账号+防沉迷+家长管控 | P0 | studio |
|
||||
| 18 | 景区互动小游戏 | 地理位置/景点知识互动游戏 | P1 | admin |
|
||||
| 19 | 博物馆科普游戏 | 展品/历史故事互动科普 | P1 | admin |
|
||||
| 20 | 城市宣传互动游戏 | 城市形象宣传/旅游推广 | P1 | admin |
|
||||
| 21 | 政务科普小游戏 | 政策/安全/垃圾分类游戏化 | P2 | admin |
|
||||
| 22 | 文旅节庆活动游戏 | 节庆限时互动活动(线上线下联动) | P1 | admin |
|
||||
| 23 | 文旅模板快速交付 | 7-15 天标准化交付 | P0 | admin |
|
||||
| 24 | 软著代办 | 代办游戏软件著作权登记 | P1 | admin |
|
||||
| 25 | 渠道上架代办 | 代办 App Store/安卓/Steam 审核 | P1 | admin |
|
||||
| 26 | ICP/文网文资质代办 | 代办互联网经营许可等合规资质 | P2 | admin |
|
||||
| 27 | 报价与项目收费管理 | 标准报价/自定义需求/预付/尾款/变更 | P1 | admin |
|
||||
|
||||
### 3.12 game-module-ad（广告引擎）
|
||||
|
||||
**职责**：管理广告位定义/AI 自动植入/广告联盟对接/展示上报/eCPM 优化，完整覆盖游戏内广告从植入到收益的全链路。
|
||||
|
||||
**依赖中间件**：MySQL, Redis, 广告联盟 SDK(穿山甲/优量汇/快手/百青藤)
|
||||
|
||||
**模块依赖**：runtime(广告位注入游戏包), trade(收益结算), telemetry(效果归因)
|
||||
|
||||
| # | 能力名称 | 描述 | 优先级 | 前端归属 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | 广告位定义与 AI 自动植入 | AI 生成时自动在关键节点植入激励视频/插屏/Banner/原生广告位 | P1 | -- |
|
||||
| 2 | 广告联盟对接(穿山甲) | 统一申请媒体资质/获取广告位 ID/SDK 集成 | P0 | -- |
|
||||
| 3 | 广告联盟对接(优量汇) | 腾讯优量汇 SDK 接入 | P0 | -- |
|
||||
| 4 | 广告联盟对接(快手) | 快手广告联盟 SDK 接入 | P1 | -- |
|
||||
| 5 | 广告联盟对接(百青藤) | 百度百青藤 SDK 接入 | P1 | -- |
|
||||
| 6 | 激励视频广告 | 玩家看 30s 广告换复活/道具/解锁 | P0 | studio(game) |
|
||||
| 7 | 插屏广告 | 过关/游戏结束自然间断弹出全屏广告 | P0 | studio(game) |
|
||||
| 8 | Banner 广告 | 游戏底部常驻横幅 | P1 | studio(game) |
|
||||
| 9 | 原生广告 | 融合游戏场景的信息流式广告 | P2 | studio(game) |
|
||||
| 10 | 广告展示上报与有效曝光计费 | 追踪有效观看/曝光事件并计费 | P0 | -- |
|
||||
| 11 | 广告触发逻辑配置 | 在关键节点(过关/结算/复活)配置广告触发 | P1 | admin |
|
||||
| 12 | eCPM 优化与精准匹配 | 游戏内容标签+玩家画像提升广告单价 | P1 | admin |
|
||||
| 13 | 广告收益实时统计 | 广告曝光/观看收益实时计入创作者看板 | P1 | studio |
|
||||
| 14 | 广告位可视化配置 | 创作者配置激励视频/插屏/Banner 触发时机和位置 | P2 | studio |
|
||||
| 15 | AI 广告位优化建议 | 分析点击数据推荐最佳广告位时机和格式 | P2 | studio |
|
||||
| 16 | 广告合规植入 | 确保广告位符合各平台展示规范 | P1 | -- |
|
||||
| 17 | 广告位效果归因 | 区分各广告位 eCPM/观看率/流失影响 | P2 | admin |
|
||||
| 18 | B 端品牌广告投放 | B 端客户在游戏流投放品牌广告 | P2 | admin |
|
||||
|
||||
---
|
||||
|
||||
## 4. 创作者激励体系（跨模块能力汇总）
|
||||
|
||||
创作者激励涉及多模块协作，此处统一列出归属关系：
|
||||
|
||||
| # | 能力 | 优先级 | 主模块 | 协作模块 | 前端归属 |
|
||||
|---|---|---|---|---|---|
|
||||
| 1 | 新人任务奖励(发 3 作品领流量+现金) | P0 | community | trade, feed | studio |
|
||||
| 2 | 新人保底曝光(不买量有初始流量) | P0 | feed | -- | -- |
|
||||
| 3 | 创作者等级体系(小白/进阶/专业) | P1 | community | trade, feed | studio + admin |
|
||||
| 4 | 等级权益分层(分成/流量/功能) | P1 | community | pay, feed | studio |
|
||||
| 5 | 自动升降级机制 | P1 | community | telemetry | -- |
|
||||
| 6 | 创作者认证 | P2 | community | compliance | admin |
|
||||
| 7 | 精选推荐 | P0 | feed | project | admin |
|
||||
| 8 | 流量扶持 | P0 | feed | -- | admin |
|
||||
| 9 | 创作大赛奖金 | P1 | community | trade | admin |
|
||||
| 10 | 创作者补贴 | P1 | trade | community | admin |
|
||||
| 11 | 算法加权优质内容 | P0 | feed | telemetry | -- |
|
||||
| 12 | 创作者收益看板 | P0 | trade | telemetry | studio |
|
||||
|
||||
---
|
||||
|
||||
## 5. 模块卡片总结
|
||||
|
||||
### game-module-project
|
||||
- **职责**：游戏项目全生命周期
|
||||
- **能力数**：14 项（P0: 11, P1: 2, P2: 0）
|
||||
- **技术栈**：Java 17 / Spring Boot / MySQL / BPM(Flowable) / OSS
|
||||
- **中间件**：MySQL, Redis, RocketMQ, MinIO/OSS
|
||||
- **依赖模块**：yudao-system, yudao-bpm, yudao-infra
|
||||
- **被依赖**：aigc, runtime, feed, community, ip, biz, compliance
|
||||
|
||||
### game-module-aigc
|
||||
- **职责**：AI 生成引擎与创作工具链
|
||||
- **实现方案**：Dify（自部署 DAG 编排）+ OpenGame（Python 微服务代码生成）+ Java 壳（任务调度/结果写入）
|
||||
- **能力数**：39 项（P0: 16, P1: 10, P2: 13）
|
||||
- **技术栈**：Java 17(壳) / Dify(编排) / Python(OpenGame Agent) / RocketMQ / LLM API(通义/DeepSeek/OpenAI)
|
||||
- **中间件**：RocketMQ, Redis, MySQL, OSS, Dify Docker, OpenGame Docker
|
||||
- **依赖模块**：project, compliance, yudao-infra
|
||||
- **被依赖**：runtime, biz
|
||||
|
||||
### game-module-runtime
|
||||
- **职责**：游戏包编译/运行时沙箱/多渠道转换/调试链路
|
||||
- **能力数**：37 项（P0: 19, P1: 16, P2: 2）
|
||||
- **技术栈**：Java(编译/打包) + 前端(Phaser3/Canvas/WebGL) / OSS / CDN
|
||||
- **中间件**：OSS/MinIO, CDN, Redis, MySQL
|
||||
- **依赖模块**：project, aigc, telemetry
|
||||
- **被依赖**：feed, ad
|
||||
|
||||
### game-module-feed
|
||||
- **职责**：游戏流推荐/互动/分享
|
||||
- **能力数**：23 项（P0: 16, P1: 5, P2: 2）
|
||||
- **技术栈**：Java 17 / Spring Boot / Redis(缓存/排序) / MySQL
|
||||
- **中间件**：Redis, MySQL
|
||||
- **依赖模块**：project, telemetry, compliance
|
||||
- **被依赖**：telemetry(反向反哺)
|
||||
|
||||
### game-module-telemetry
|
||||
- **职责**：全链路事件采集/聚合/看板/告警
|
||||
- **能力数**：28 项（P0: 16, P1: 11, P2: 1）
|
||||
- **技术栈**：Java 17 / RocketMQ / MySQL(ClickHouse 远期) / Prometheus+Grafana
|
||||
- **中间件**：RocketMQ, MySQL/ClickHouse, Redis, Prometheus, Grafana, Sentry
|
||||
- **依赖模块**：feed, project, compliance
|
||||
- **被依赖**：feed, aigc, trade, community
|
||||
|
||||
### game-module-pay
|
||||
- **职责**：支付网关/充值/订阅/内购
|
||||
- **能力数**：11 项（P0: 3, P1: 4, P2: 4）
|
||||
- **技术栈**：Java 17 / 微信支付SDK / 支付宝SDK / Apple IAP
|
||||
- **中间件**：MySQL, Redis
|
||||
- **依赖模块**：yudao-system
|
||||
- **被依赖**：trade
|
||||
|
||||
### game-module-trade
|
||||
- **职责**：广告分成/创作者钱包/财务对账
|
||||
- **能力数**：14 项（P0: 7, P1: 6, P2: 1）
|
||||
- **技术栈**：Java 17 / 分账引擎 / 银行转账API
|
||||
- **中间件**：MySQL, Redis
|
||||
- **依赖模块**：pay, ad, ip, telemetry
|
||||
- **被依赖**：community(激励), biz
|
||||
|
||||
### game-module-community
|
||||
- **职责**：社区互动/创作者社区/通知
|
||||
- **能力数**：27 项（P0: 6, P1: 14, P2: 7）
|
||||
- **技术栈**：Java 17 / Redis(排行/计数) / RocketMQ(推送) / 极光推送
|
||||
- **中间件**：MySQL, Redis, RocketMQ, 推送服务
|
||||
- **依赖模块**：project, yudao-system, yudao-infra
|
||||
- **被依赖**：--
|
||||
|
||||
### game-module-ip
|
||||
- **职责**：素材市场/版权/IP 孵化/模型训练
|
||||
- **能力数**：22 项（P0: 1, P1: 10, P2: 11）
|
||||
- **技术栈**：Java 17 / OSS / 图像检测API / DRM
|
||||
- **中间件**：MySQL, OSS, Redis
|
||||
- **依赖模块**：project, trade, compliance, aigc
|
||||
- **被依赖**：trade
|
||||
|
||||
### game-module-compliance
|
||||
- **职责**：内容安全/审核/权限/审计/隐私/防沉迷
|
||||
- **能力数**：39 项（P0: 27, P1: 9, P2: 3）
|
||||
- **技术栈**：Java 17 / 内容安全API / Redis / Sentry / Vault
|
||||
- **中间件**：MySQL, Redis, 内容安全API(阿里云/腾讯云), Vault
|
||||
- **依赖模块**：yudao-system, yudao-bpm, project, feed
|
||||
- **被依赖**：aigc, ip, biz, project
|
||||
|
||||
### game-module-biz
|
||||
- **职责**：B/G 端定制/教育/文旅/代运营
|
||||
- **能力数**：27 项（P0: 5, P1: 17, P2: 5）
|
||||
- **技术栈**：Java 17 / BPM(Flowable) / CRM / 电子签章
|
||||
- **中间件**：MySQL, BPM, OSS
|
||||
- **依赖模块**：project, aigc, trade, compliance
|
||||
- **被依赖**：--
|
||||
|
||||
### game-module-ad
|
||||
- **职责**：广告引擎全链路(植入→展示→收益)
|
||||
- **能力数**：18 项（P0: 4, P1: 9, P2: 5）
|
||||
- **技术栈**：Java 17 / 广告联盟SDK(穿山甲/优量汇/快手/百青藤) / 前端SDK
|
||||
- **中间件**：MySQL, Redis, 广告联盟API
|
||||
- **依赖模块**：runtime, trade, telemetry
|
||||
- **被依赖**：trade
|
||||
|
||||
---
|
||||
|
||||
## 6. 能力总量统计
|
||||
|
||||
| 模块 | P0 | P1 | P2 | 合计 |
|
||||
|---|---|---|---|---|
|
||||
| project | 11 | 2 | 0 | 14 |
|
||||
| aigc | 16 | 10 | 13 | 39 |
|
||||
| runtime | 19 | 16 | 2 | 37 |
|
||||
| feed | 16 | 5 | 2 | 23 |
|
||||
| telemetry | 16 | 11 | 1 | 28 |
|
||||
| pay | 3 | 4 | 4 | 11 |
|
||||
| trade | 7 | 6 | 1 | 14 |
|
||||
| community | 6 | 14 | 7 | 27 |
|
||||
| ip | 1 | 10 | 11 | 22 |
|
||||
| compliance | 27 | 9 | 3 | 39 |
|
||||
| biz | 5 | 17 | 5 | 27 |
|
||||
| ad | 4 | 9 | 5 | 18 |
|
||||
| **合计** | **131** | **113** | **54** | **299** |
|
||||
|
||||
去重合并后共计 **299 项** 独立业务能力（原始 6 个子代理合计约 450+ 条，去除重复和同义表述后）。
|
||||
|
||||
---
|
||||
|
||||
## 7. 技术栈选择理由
|
||||
|
||||
| 技术选型 | 理由 |
|
||||
|---|---|
|
||||
| Java 17 + Spring Cloud Alibaba | Yudao Cloud 原生栈，60%+ 后台能力开箱即用，二开友好 |
|
||||
| **Dify（自部署）** | AI 生成编排引擎：DAG 可视化、多模型切换、变量传递、条件分支、重试、API 发布、可观测性开箱即用；中后期加企业级监控/trace/高并发优化 |
|
||||
| **OpenGame（Python 微服务）** | AI 代码生成核心：CUHK MMLab 2025 SOTA，6 阶段 pipeline 论文验证，通用 LLM 驱动，HTTP API 对外暴露 |
|
||||
| MySQL | Yudao 默认，社区方案最多，需要 JSONB/全文检索时加 PostgreSQL/ES |
|
||||
| RocketMQ | Yudao 默认集成，生产可靠，适合异步生成/审核/事件摄取 |
|
||||
| Redis | 候选集缓存/限流/排行/熔断状态/分布式锁 |
|
||||
| MinIO/阿里云 OSS | 游戏包/素材/封面存储，Docker Compose 本地用 MinIO |
|
||||
| Nacos | 注册中心+配置中心，Yudao 原生支持 |
|
||||
| Flowable(BPM) | 审核流程/发布流程/下架流程开箱即用 |
|
||||
| Vue3 + Element Plus(admin) | Yudao 官方主推，二开友好度最高 |
|
||||
| Vue3 + Vant(studio) | 移动优先产品端，轻量组件库适配 360-430px |
|
||||
| Phaser 3 + WebGL(runtime) | v1 已验证，轻量 2D 游戏最成熟方案 |
|
||||
| Prometheus + Grafana | 可观测性标准方案，告警+看板 |
|
||||
| ClickHouse(远期) | 事件量爆增后从 MySQL 迁移，列式存储适合分析 |
|
||||
| 广告联盟 SDK | 穿山甲(字节)+优量汇(腾讯) 覆盖 80%+ 国内移动广告市场 |
|
||||
|
||||
---
|
||||
|
||||
## 8. MVP 优先实现范围（P0 能力分布）
|
||||
|
||||
```
|
||||
project(11) + aigc(16) + runtime(19) + feed(16) + telemetry(16) + compliance(27)
|
||||
= 105 项 P0 能力构成 MVP 核心闭环
|
||||
```
|
||||
|
||||
MVP 阶段 pay/trade/community/ip/biz/ad 模块仅预留接口和数据模型，不实现业务逻辑。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,4 +1,6 @@
|
||||
# 绘境AI v2.0 — 项目模块架构与 MVP 覆盖度
|
||||
# 绘境AI — 项目模块架构与 MVP 覆盖度（前端覆盖核对版）
|
||||
|
||||
> ⚠️ **模块结构部分已被取代（2026-06-07）**：本文所列为旧 **8 后端模块** 视角（无 `game-module-studio`、无锁风门 Gate / 专区 Zone 映射）。**模块清单与技术功能以 Doc B `2026-06-07-技术架构与模块.md`（13 模块）为准；MVP 范围以 `.agents/knowledge/mvp-scope-and-milestones.md` 与 `docs/agent-specs/2026-06-07-模块重划分-review.md` 为准。** 本文保留价值在于其独有的「PRD → 三仓三端**前端页面**覆盖核对」与 game-cloud 目录结构细节（这两部分 Doc B 未覆盖）。
|
||||
|
||||
> 生成时间：2026-06-06
|
||||
> 命名约定：game-cloud / game-admin / game-studio
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
> **关联文档**：
|
||||
> - 业务需求：`docs-design/MVP PRD.md`、`docs-design/Product Strategy Document.md`
|
||||
> - 竞品分析：`docs-design/竞品分析报告.md`
|
||||
> - 能力全景：`docs/architecture/2026-06-06-v2业务能力全景与模块归属.md`
|
||||
> - 产品需求/技术模块/映射 三文档：`docs/architecture/2026-06-07-产品需求清单.md`、`…-技术架构与模块.md`、`…-需求模块映射.md`
|
||||
> - 架构选型：`docs/architecture/2026-06-06-v2架构选型审阅版.md`
|
||||
|
||||
---
|
||||
@ -487,7 +487,7 @@ graph LR
|
||||
end
|
||||
|
||||
subgraph 业务服务容器
|
||||
game_all[game-server:48090<br/>单体模式含全部12个业务模块]
|
||||
game_all[game-server:48090<br/>单体模式含全部13个业务模块]
|
||||
end
|
||||
|
||||
subgraph AI引擎容器
|
||||
@ -508,7 +508,7 @@ graph LR
|
||||
end
|
||||
```
|
||||
|
||||
**MVP 阶段单体启动**：所有 12 个业务模块编译为同一个 JAR（`game-server`），通过 Spring Profile 控制模块加载。需要独立扩缩时，Nacos 配置一改即拆为独立服务。
|
||||
**MVP 阶段单体启动**：所有 13 个业务模块编译为同一个 JAR（`game-server`），通过 Spring Profile 控制模块加载。需要独立扩缩时，Nacos 配置一改即拆为独立服务。
|
||||
|
||||
### 3.3 模块间通信
|
||||
|
||||
@ -1414,7 +1414,7 @@ gantt
|
||||
|
||||
section Phase 1：基座（2周）
|
||||
Fork yudao-cloud + 本地跑通全栈 :p1a, 2026-06-09, 3d
|
||||
创建 12 个 game-module 骨架 :p1b, after p1a, 3d
|
||||
创建 13 个 game-module 骨架 :p1b, after p1a, 3d
|
||||
Dify + OpenGame Docker 部署 :p1c, after p1a, 3d
|
||||
game-admin fork + game views 骨架 :p1d, after p1a, 4d
|
||||
game-studio 项目初始化 :p1e, after p1a, 3d
|
||||
@ -1497,7 +1497,7 @@ gantt
|
||||
| 决策 | 文档位置 |
|
||||
|---|---|
|
||||
| 整体选型（Yudao + Element Plus + Vant） | `2026-06-06-v2架构选型审阅版.md` |
|
||||
| 模块划分（12 个业务模块） | `2026-06-06-v2业务能力全景与模块归属.md` |
|
||||
| 模块划分（13 个业务模块） | `2026-06-07-技术架构与模块.md` |
|
||||
| AI 引擎选型（Dify + OpenGame） | 本文 §6.2 |
|
||||
| 前端两端分离 | `2026-06-06-v2架构选型审阅版.md` §5 |
|
||||
|
||||
|
||||
249
docs/architecture/2026-06-07-产品需求清单.md
Normal file
249
docs/architecture/2026-06-07-产品需求清单.md
Normal file
@ -0,0 +1,249 @@
|
||||
# 绘境AI — 产品需求清单（Doc A）
|
||||
|
||||
> 文档类型：**Doc A｜产品需求清单**（面向用户/产品，回答 WHAT）
|
||||
> 文档 ID：HJ-PRD-002 ｜ 生成时间：2026-06-07
|
||||
> 三文档套件：技术分解 = Doc B `2026-06-07-技术架构与模块.md`；需求↔模块映射 = Doc C `2026-06-07-需求模块映射.md`（本文不出现任何模块/技术词）
|
||||
>
|
||||
> **纪律**：只写用户可感知的功能。需求由哪些技术模块支撑（M:N）见 Doc C。
|
||||
> **ID**：`P-{域}-{nn}`。**端**：创作者/玩家/经营/运营/B端/通用。**来源**：demo=原型呈现｜v2.0=能力全景已有｜G#=demo 暴露缺口。
|
||||
|
||||
---
|
||||
|
||||
## 域 1 素材中心（MAT）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-MAT-01 | 浏览授权 IP 素材库（按 IP 分组、四类素材货架） | 创作者 | P1 | demo/v2.0 |
|
||||
| P-MAT-02 | 浏览 UGC 孵化 IP 素材库 | 创作者 | P1 | demo/v2.0 |
|
||||
| P-MAT-03 | 素材选用加入项目草稿 | 创作者 | P1 | demo |
|
||||
| P-MAT-04 | 素材授权采购 | 创作者 | P1 | demo/v2.0 |
|
||||
| P-MAT-05 | 查看素材授权范围/锁风标签/分成规则 | 创作者 | P1 | demo/G2 |
|
||||
| P-MAT-06 | 素材版权声明与管理（上传需声明授权类型） | 创作者 | P1 | v2.0 |
|
||||
|
||||
## 域 2 玩法模板（TPL）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-TPL-01 | 浏览玩法模板 + 蓝图步骤 | 创作者 | P0 | demo/v2.0 |
|
||||
| P-TPL-02 | 配置模板参数（推荐时长/运营点位） | 创作者 | P1 | demo/v2.0 |
|
||||
| P-TPL-03 | 应用模板到草稿并带入工作坊 | 创作者 | P0 | demo |
|
||||
| P-TPL-04 | 收藏模板 | 创作者 | P2 | demo |
|
||||
| P-TPL-05 | 购买商用模板（模板市场） | 创作者 | P1 | demo/v2.0 |
|
||||
|
||||
## 域 3 自定义创作（CRT）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-CRT-01 | 自然语言一句话生成可试玩游戏 | 创作者 | P0 | demo/v2.0 |
|
||||
| P-CRT-02 | 六类资产模块化生成（图元/角色/特效/场景/界面/音乐） | 创作者 | P0 | demo/G4 |
|
||||
| P-CRT-03 | 图生 / 文生角色 | 创作者 | P1 | demo/G4 |
|
||||
| P-CRT-04 | 附件驱动创作（拖入资产/上传作上下文） | 创作者 | P0 | demo/G4 |
|
||||
| P-CRT-05 | 智能体对话式创作 + 任务链分步进度可视 | 创作者 | P1 | demo/G7 |
|
||||
| P-CRT-06 | 角色骨骼拆件与多动作编辑 | 创作者 | P1 | demo/G3 |
|
||||
| P-CRT-07 | 导出角色动作包到草稿 | 创作者 | P2 | demo/G3 |
|
||||
| P-CRT-08 | 生成结果实时预览试玩 | 创作者 | P0 | demo/v2.0 |
|
||||
| P-CRT-09 | 一键重新生成 / 带描述迭代 | 创作者 | P0 | demo/v2.0 |
|
||||
| P-CRT-10 | 创作引导与新手教程 | 创作者 | P0 | v2.0 |
|
||||
| P-CRT-11 | 示例 Prompt 库（每模板 3-5 条） | 创作者 | P0 | v2.0 |
|
||||
| P-CRT-12 | 生成进度实时展示（步骤+百分比） | 创作者 | P0 | demo/v2.0 |
|
||||
| P-CRT-13 | 生成超时后台通知 | 创作者 | P0 | v2.0 |
|
||||
| P-CRT-14 | 模板参数可调编辑（速度/敌数/时长/胜负） | 创作者 | P1 | v2.0 |
|
||||
| P-CRT-15 | 游戏流专属版本一键适配（竖屏/短时长/3秒钩子） | 创作者 | P2 | v2.0 |
|
||||
|
||||
## 域 4 授权 IP 创作（LIC）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-LIC-01 | 选择现象级授权 IP 作为项目母体 | 创作者 | P1 | demo/v2.0 |
|
||||
| P-LIC-02 | 选玩法模板 + 调用已授权美术功能包 | 创作者 | P1 | demo |
|
||||
| P-LIC-03 | 补充自定义资产 / 导入图片视频 | 创作者 | P1 | demo |
|
||||
| P-LIC-04 | 分支对白调试（选分支→实时写入试玩节点） | 创作者 | P1 | demo/G5 |
|
||||
| P-LIC-05 | 锁风调试（强度：标准/严格/人工复核） | 创作者 | P0 | demo/G2 |
|
||||
| P-LIC-06 | 选择发布去向专区（双轨专区 launchZone） | 创作者 | P0 | demo/G1 |
|
||||
|
||||
## 域 5 发布分发（PUB）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-PUB-01 | 一键多渠道发布（自有必选 + 抖音/微信/快手/TapTap） | 创作者 | P0 | demo/G6 |
|
||||
| P-PUB-02 | 查看外部渠道开通状态（待开通/申请中/已上线） | 创作者 | P1 | demo/G6 |
|
||||
| P-PUB-03 | 发布前检查（锁风+性能+版权通过才可发布） | 创作者 | P0 | demo/G2 |
|
||||
| P-PUB-04 | 保存发布配置 | 创作者 | P2 | demo |
|
||||
| P-PUB-05 | 多渠道合规简介自动改写 | 创作者+运营 | P1 | v2.0 |
|
||||
|
||||
## 域 6 游戏广场（PLZ）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-PLZ-01 | 双专区浏览（现象级授权IP / UGC孵化IP） | 玩家 | P0 | demo/G1 |
|
||||
| P-PLZ-02 | 专区内分组（优秀案例/新游推荐/全部） | 玩家 | P1 | demo |
|
||||
| P-PLZ-03 | 点击封面即试玩 | 玩家 | P0 | demo/v2.0 |
|
||||
|
||||
## 域 7 游戏信息流（FED）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-FED-01 | 竖屏即刷即玩 | 玩家 | P0 | demo/v2.0 |
|
||||
| P-FED-02 | 上下滑/按钮切换 | 玩家 | P0 | demo/v2.0 |
|
||||
| P-FED-03 | 点赞 | 玩家 | P0 | demo/v2.0 |
|
||||
| P-FED-04 | 收藏 | 玩家 | P0 | demo/v2.0 |
|
||||
| P-FED-05 | 分享到社交平台 | 玩家 | P0 | demo/v2.0 |
|
||||
| P-FED-06 | 举报违规/低质/抄袭 | 玩家 | P0 | demo/v2.0 |
|
||||
| P-FED-07 | 生成独立分享链接 | 玩家 | P0 | v2.0 |
|
||||
| P-FED-08 | 分享落地页（封面/标题/简介/立即玩） | 玩家 | P0 | v2.0 |
|
||||
| P-FED-09 | 原生分享 / 复制链接 | 玩家 | P1 | v2.0 |
|
||||
| P-FED-10 | 加载进度反馈（封面/进度条/跳过） | 玩家 | P0 | v2.0 |
|
||||
| P-FED-11 | 首屏封面展示（封面/标题/作者/玩法/开始） | 玩家 | P0 | v2.0 |
|
||||
| P-FED-12 | 同款创作跳转工作坊 | 玩家 | P1 | demo |
|
||||
| P-FED-13 | 信息流推荐池 | 玩家 | P0 | demo/v2.0 |
|
||||
| P-FED-14 | 多端适配操控（触控+键盘） | 玩家 | P0 | v2.0 |
|
||||
| P-FED-15 | 低端设备低画质模式 | 玩家 | P1 | v2.0 |
|
||||
| P-FED-16 | 弱网/离线游玩兜底 | 玩家 | P1 | v2.0 |
|
||||
|
||||
## 域 8 创作者数据经营（OPS）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-OPS-01 | 创作者数据看板（留存/完玩/广告转化/素材复用） | 经营 | P1 | demo/v2.0 |
|
||||
| P-OPS-02 | 七日留存与播放趋势 | 经营 | P1 | demo/v2.0 |
|
||||
| P-OPS-03 | AI 内容诊断（短板定位 + 建议） | 经营 | P1 | demo/v2.0 |
|
||||
| P-OPS-04 | 一键迭代优化 / 生成改版任务 | 经营 | P1 | demo |
|
||||
| P-OPS-05 | 生成 A/B 测试版本 | 经营 | P2 | v2.0 |
|
||||
| P-OPS-06 | AI 玩法/美术/赛道洞察建议 | 经营 | P2 | v2.0 |
|
||||
|
||||
## 域 9 创作者钱包收益（WAL）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-WAL-01 | 钱包余额管理（广告/素材/商单各类收入） | 创作者 | P0 | v2.0 |
|
||||
| P-WAL-02 | 提现（银行卡/支付宝/微信，满 5 元） | 创作者 | P0 | v2.0 |
|
||||
| P-WAL-03 | 收益明细（日/周/月各渠道） | 创作者 | P0 | v2.0 |
|
||||
| P-WAL-04 | 收益透明度看板（结算状态/提现进度） | 创作者 | P1 | v2.0 |
|
||||
|
||||
## 域 10 付费变现（PAY）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-PAY-01 | 积分充值 | 创作者 | P0 | v2.0 |
|
||||
| P-PAY-02 | 会员订阅体系 | 创作者 | P1 | v2.0 |
|
||||
| P-PAY-03 | 付费推广流量包 | 创作者 | P1 | v2.0 |
|
||||
| P-PAY-04 | 会员等级与权益 | 创作者 | P1 | v2.0 |
|
||||
| P-PAY-05 | 游戏内购-道具 | 玩家 | P2 | v2.0 |
|
||||
| P-PAY-06 | 游戏内购-皮肤与角色 | 玩家 | P2 | v2.0 |
|
||||
| P-PAY-07 | 游戏内购-关卡解锁 | 玩家 | P2 | v2.0 |
|
||||
| P-PAY-08 | 打赏创作者 | 玩家 | P2 | v2.0 |
|
||||
| P-PAY-09 | B 端项目在线支付 | B端 | P2 | v2.0 |
|
||||
|
||||
## 域 11 广告变现（ADV）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-ADV-01 | 激励视频广告（看 30s 换复活/道具/解锁） | 玩家 | P0 | demo/v2.0 |
|
||||
| P-ADV-02 | 插屏广告（过关/结束全屏） | 玩家 | P0 | v2.0 |
|
||||
| P-ADV-03 | Banner 广告 | 玩家 | P1 | v2.0 |
|
||||
| P-ADV-04 | 原生广告 | 玩家 | P2 | v2.0 |
|
||||
| P-ADV-05 | 广告触发逻辑配置 | 创作者 | P1 | v2.0 |
|
||||
| P-ADV-06 | 广告收益实时统计 | 创作者 | P1 | demo/v2.0 |
|
||||
| P-ADV-07 | 广告位可视化配置 | 创作者 | P2 | v2.0 |
|
||||
| P-ADV-08 | AI 广告位优化建议 | 创作者 | P2 | v2.0 |
|
||||
| P-ADV-09 | B 端品牌广告投放 | B端 | P2 | v2.0 |
|
||||
|
||||
## 域 12 社区互动（SOC）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-SOC-01 | 评论与回复 | 玩家+创作者 | P1 | v2.0 |
|
||||
| P-SOC-02 | 关注创作者 | 玩家 | P1 | demo/v2.0 |
|
||||
| P-SOC-03 | 粉丝体系（列表/画像/私域池） | 创作者 | P1 | v2.0 |
|
||||
| P-SOC-04 | 创作者动态 Feed | 玩家 | P1 | v2.0 |
|
||||
| P-SOC-05 | 排行榜（创作者/作品） | 玩家+创作者 | P1 | v2.0 |
|
||||
| P-SOC-06 | 排行榜（玩家成绩） | 玩家 | P1 | v2.0 |
|
||||
| P-SOC-07 | 成就徽章系统 | 玩家 | P2 | v2.0 |
|
||||
| P-SOC-08 | 弹幕互动 | 玩家 | P2 | v2.0 |
|
||||
| P-SOC-09 | 玩家个人主页 | 玩家 | P2 | v2.0 |
|
||||
| P-SOC-10 | 好友系统 | 玩家 | P2 | v2.0 |
|
||||
| P-SOC-11 | 组队/多人游玩 | 玩家 | P2 | v2.0 |
|
||||
|
||||
## 域 13 创作者成长（GRW）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-GRW-01 | 创作者教程体系 | 创作者 | P1 | v2.0 |
|
||||
| P-GRW-02 | 创作挑战赛 | 创作者 | P1 | v2.0 |
|
||||
| P-GRW-03 | 热门玩法拆解 | 创作者 | P1 | v2.0 |
|
||||
| P-GRW-04 | 创作者社群/圈子 | 创作者 | P2 | v2.0 |
|
||||
| P-GRW-05 | 圈层共创计划 | 创作者 | P2 | v2.0 |
|
||||
| P-GRW-06 | 多人协同创作（远期） | 创作者 | P2 | v2.0 |
|
||||
|
||||
## 域 14 创作者激励（INC）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-INC-01 | 新人任务奖励（发 3 作品领流量+现金） | 创作者 | P0 | v2.0 |
|
||||
| P-INC-02 | 创作者等级体系（小白/进阶/专业） | 创作者 | P1 | v2.0 |
|
||||
| P-INC-03 | 等级权益分层（分成/流量/功能） | 创作者 | P1 | v2.0 |
|
||||
| P-INC-04 | 创作者认证 | 创作者 | P2 | v2.0 |
|
||||
| P-INC-05 | 创作大赛奖金 | 创作者 | P1 | v2.0 |
|
||||
| P-INC-06 | 创作者补贴 | 创作者 | P1 | v2.0 |
|
||||
|
||||
## 域 15 消息通知（NTF）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-NTF-01 | 站内消息中心（系统/公告/审核/收益） | 通用 | P0 | demo/v2.0 |
|
||||
| P-NTF-02 | 生成任务完成通知 | 创作者 | P0 | v2.0 |
|
||||
| P-NTF-03 | 审核结果通知 | 创作者 | P0 | v2.0 |
|
||||
| P-NTF-04 | 新粉丝/互动通知 | 通用 | P1 | v2.0 |
|
||||
| P-NTF-05 | 收益变动通知 | 创作者 | P0 | v2.0 |
|
||||
| P-NTF-06 | 活动/赛事通知 | 通用 | P1 | v2.0 |
|
||||
| P-NTF-07 | 创作者新作品通知 | 玩家 | P1 | v2.0 |
|
||||
|
||||
## 域 16 IP 孵化与版权（IPX）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-IPX-01 | 素材市场上架与定价 | 创作者 | P1 | v2.0 |
|
||||
| P-IPX-02 | 素材市场检索与推荐 | 创作者 | P1 | v2.0 |
|
||||
| P-IPX-03 | 素材交易（买卖/抽佣） | 创作者 | P1 | v2.0 |
|
||||
| P-IPX-04 | 版权侵权投诉受理 | 运营 | P1 | v2.0 |
|
||||
| P-IPX-05 | DMCA/侵权下架与反通知申诉 | 运营 | P1 | v2.0 |
|
||||
| P-IPX-06 | 爆款筛选与签约 | 运营 | P2 | v2.0 |
|
||||
| P-IPX-07 | IP 代运营 | 运营 | P2 | v2.0 |
|
||||
| P-IPX-08 | IP 周边衍生 | 运营 | P2 | v2.0 |
|
||||
| P-IPX-09 | IP 跨界联动 | 运营 | P2 | v2.0 |
|
||||
| P-IPX-10 | IP 授权分成 | 运营 | P2 | v2.0 |
|
||||
| P-IPX-11 | 外部成熟 IP 合作（联名小游戏） | 运营 | P1 | v2.0 |
|
||||
| P-IPX-12 | 模板授权分成 | 运营 | P2 | v2.0 |
|
||||
| P-IPX-13 | 创作大赛赞助 | 运营 | P2 | v2.0 |
|
||||
|
||||
## 域 17 B 端定制（BIZ）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-BIZ-01 | B 端需求表单提交 | B端 | P0 | demo/v2.0 |
|
||||
| P-BIZ-02 | 分场景模板库选择与预览 | B端 | P0 | demo/v2.0 |
|
||||
| P-BIZ-03 | 定制进度看板 | B端 | P0 | demo/v2.0 |
|
||||
| P-BIZ-04 | 交付验收（试玩/反馈/确认/签署） | B端 | P0 | demo/v2.0 |
|
||||
| P-BIZ-05 | B 端数据效果报告 | 运营 | P1 | v2.0 |
|
||||
| P-BIZ-06 | B 端年度服务套餐 | 运营 | P1 | v2.0 |
|
||||
| P-BIZ-07 | B 端代运营服务 | 运营 | P1 | v2.0 |
|
||||
| P-BIZ-08 | 品牌营销小游戏定制 | 运营 | P0 | demo/v2.0 |
|
||||
| P-BIZ-09 | 企业私域嵌入分发 | 运营 | P1 | v2.0 |
|
||||
| P-BIZ-10 | 教育课程体系（创作课/授权/培训/展示/大赛/答题模板） | B端+运营 | P1 | v2.0 |
|
||||
| P-BIZ-11 | 学生账号与防沉迷 | B端 | P0 | v2.0 |
|
||||
| P-BIZ-12 | 文旅定制（景区/博物馆/城市/节庆/快速交付） | 运营 | P0/P1 | demo/v2.0 |
|
||||
| P-BIZ-13 | 政务科普小游戏 | 运营 | P2 | v2.0 |
|
||||
| P-BIZ-14 | 资质代办（软著/渠道上架/ICP文网文） | 运营 | P1/P2 | v2.0 |
|
||||
|
||||
## 域 18 运营管理（OPN，admin）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-OPN-01 | 审核决策与操作（通过/拒绝/下架/加精选/限曝光） | 运营 | P0 | demo/v2.0 |
|
||||
| P-OPN-02 | 审核拒绝反馈与重提交 | 运营+创作者 | P0 | demo/v2.0 |
|
||||
| P-OPN-03 | 精选池运营管理 | 运营 | P0 | demo/v2.0 |
|
||||
| P-OPN-04 | 下架/封禁操作 | 运营 | P0 | v2.0 |
|
||||
| P-OPN-05 | 运营数据看板（审核积压/供给/成功率/举报率） | 运营 | P0 | v2.0 |
|
||||
| P-OPN-06 | 管理层经营看板（MAU/留存/收入/成本） | 运营 | P1 | v2.0 |
|
||||
| P-OPN-07 | 数据导出（投资人/复盘） | 运营 | P1 | v2.0 |
|
||||
| P-OPN-08 | 创作者主页（公开展示） | 创作者 | P0 | demo/v2.0 |
|
||||
| P-OPN-09 | 游戏包导出（用户触发） | 创作者+运营 | P1 | v2.0 |
|
||||
|
||||
## 域 19 账号与合规告知（ACC）
|
||||
| ID | 需求 | 端 | 优先级 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| P-ACC-01 | 账号信息与会员状态 | 通用 | P1 | demo |
|
||||
| P-ACC-02 | 用户隐私政策/用户协议展示 | 通用 | P0 | v2.0 |
|
||||
| P-ACC-03 | 适龄分级提示展示 | 通用 | P0 | v2.0 |
|
||||
| P-ACC-04 | 创作者审核申诉 | 创作者 | P1 | v2.0 |
|
||||
| P-ACC-05 | 帮助中心 / 退出登录 | 通用 | P2 | demo |
|
||||
|
||||
---
|
||||
|
||||
## 计数与说明
|
||||
|
||||
共 **155 项产品需求**，分 19 个产品域。其中 demo 暴露的缺口需求（G1–G7）已并入：双专区(P-LIC-06/P-PLZ-01)、锁风(P-MAT-05/P-LIC-05/P-PUB-03)、六资产+附件(P-CRT-02/03/04)、智能体任务链(P-CRT-05)、骨骼动画(P-CRT-06/07)、对白调试(P-LIC-04)、多渠道发布(P-PUB-01/02)。
|
||||
|
||||
> 每项需求由哪些技术功能(T-id)实现、首要 owner 是谁——见 Doc C 需求↔模块映射。
|
||||
348
docs/architecture/2026-06-07-技术架构与模块.md
Normal file
348
docs/architecture/2026-06-07-技术架构与模块.md
Normal file
@ -0,0 +1,348 @@
|
||||
# 绘境AI — 技术架构与模块（Doc B）
|
||||
|
||||
> 文档类型：**Doc B｜技术架构与模块**（面向工程/领域，回答 HOW + 对象边界）
|
||||
> 文档 ID：HJ-TECH-002 ｜ 最近修订：2026-06-07 ｜ 修订摘要：自原《业务能力全景与模块归属》拆出"技术分解"，落地 12→13 模块重划分（该旧档已删除，历史见 git）
|
||||
> 三文档套件：产品需求 = Doc A `2026-06-07-产品需求清单.md`；需求↔模块映射 = Doc C `2026-06-07-需求模块映射.md`
|
||||
>
|
||||
> **本文纪律**：纯技术分解，按领域边界组织、高内聚低耦合。**不出现任何产品功能/需求条目**。每个技术功能以 `T-{模块}-{nn}` 标识，供 Doc C 引用。
|
||||
> **与 v2.0 关系**：v2.0 的 299 条"业务能力"混合了产品功能与技术功能；v2.1 将其二分——产品功能入 Doc A，工程内生项入本文，并落地 12→13 模块重划分（详见 `docs/agent-specs/2026-06-07-模块重划分-review.md`）。
|
||||
|
||||
---
|
||||
|
||||
## 0. 模块总览（13 模块）
|
||||
|
||||
| 模块 | 前缀 | 一句话职责 | 重划状态 |
|
||||
|---|---|---|---|
|
||||
| studio | STU | 创作编排/编辑器域（会话/资产图/rig/对白树/任务链） | ★新增 |
|
||||
| aigc | AGC | 无状态生成原子（LLM/图/音/剧情/模板/校验/风格指纹） | 收敛 |
|
||||
| runtime | RT | 编译/沙箱预览/多渠道转换/发布状态机 | 扩 |
|
||||
| project | PRJ | 项目生命周期 + 专区 Zone 实体 | 扩 |
|
||||
| feed | FED | 游戏流推荐/互动/分享 + 按 Zone 分区 | 扩 |
|
||||
| telemetry | TEL | 事件摄取/聚合/质量评分/监控告警 | — |
|
||||
| pay | PAY | 支付收单/订单/退款对账 | — |
|
||||
| trade | TRD | 分账/结算/对账/钱包打款/财税 | — |
|
||||
| community | CMU | 社交关系/互动计数/排行成就/通知投递 | — |
|
||||
| ip | IP | 素材安全/授权链/IP 风格原子/Zone 双轨归类/模型训练对接 | 扩 |
|
||||
| compliance | CMP | 内容安全/审核状态机/锁风门 Gate/RBAC/审计/安全基线 | 扩 |
|
||||
| biz | BIZ | B/G 端报价/BPM 编排/签章/CRM/交付验收 | — |
|
||||
| ad | AD | 广告联盟对接/AI 植入/曝光计费/eCPM/归因 | — |
|
||||
|
||||
### 模块依赖（单向、低耦合）
|
||||
|
||||
```mermaid
|
||||
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
|
||||
```
|
||||
|
||||
### 横切关注点（指定唯一 owner）
|
||||
|
||||
| 横切 | owner | 供原子 / 消费 | 关键技术功能 |
|
||||
|---|---|---|---|
|
||||
| 锁风门（风格-版权一致性 Gate） | compliance | aigc T-AGC-19、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 |
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块卡片
|
||||
|
||||
### game-module-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 进度推送 |
|
||||
| T-STU-08 | 草稿装配与 project 移交契约 |
|
||||
| T-STU-09 | 六类资产模块化生成调度（按资产种类编排 aigc 原子） |
|
||||
| T-STU-10 | 用户工作流编排（可视化，创作者自定义流程节点） |
|
||||
| T-STU-11 | 批量游戏生成调度 |
|
||||
|
||||
> 来源：T-STU-01..08 为创作编辑器核心能力；T-STU-09 为 aigc 收敛迁出（六资产调度）。**T-STU-10/11（可视化工作流编排、批量生成调度）为远期能力，产品出口待 Doc A 定义后再建 Doc C 映射，当前暂未映射。**
|
||||
|
||||
### game-module-aigc 收敛｜无状态生成原子
|
||||
|
||||
- **职责**：单 Prompt/请求 → 单确定性产物（结构化参数/GameConfig/图/音/剧情/封面/校验/风格指纹），无状态、幂等、可重放。
|
||||
- **边界 IN**：Prompt 解析/安全、模板匹配/Schema、LLM 编排/熔断、生成任务队列/状态机、Fallback、图/音/剧情/封面生成原子、风格标签、内置素材库、DAG 引擎、质量评估。
|
||||
- **边界 OUT**：不管会话/编辑/多资产装配与进度链编排（交 studio）｜不持久化项目（交 project）｜不编译/沙箱（交 runtime）｜不做锁风裁决（供风格原子给 compliance）。
|
||||
- **依赖**：compliance（Prompt 安全）· project（写入结果）· infra（文件）。
|
||||
|
||||
| ID | 技术功能 |
|
||||
|---|---|
|
||||
| T-AGC-01 | Prompt 解析与归一化 |
|
||||
| T-AGC-02 | Prompt 安全检测 |
|
||||
| T-AGC-03 | 模板分类匹配 / 注册 / 扩展 |
|
||||
| T-AGC-04 | GameConfig 结构化生成 + JSON Schema 校验 |
|
||||
| T-AGC-05 | 模板参数校验与兜底 |
|
||||
| T-AGC-06 | LLM 调用编排 / 熔断 / 重试 / 多供应商 |
|
||||
| T-AGC-07 | 生成任务异步队列调度（RocketMQ） |
|
||||
| T-AGC-08 | 生成任务状态机（queued/running/succeeded/failed/timed_out/canceled） |
|
||||
| T-AGC-09 | 确定性 Fallback 生成 |
|
||||
| T-AGC-10 | 生成失败原因分类（结构化错误码） |
|
||||
| T-AGC-11 | 风格标签体系 |
|
||||
| T-AGC-12 | 内置素材库管理 |
|
||||
| T-AGC-13 | 素材上传校验 + SHA256 去重 |
|
||||
| T-AGC-14 | 图像 AI 生成原子 |
|
||||
| T-AGC-15 | 音乐 / 音效 AI 生成原子 |
|
||||
| T-AGC-16 | 剧情 / 对话 AI 生成原子 |
|
||||
| T-AGC-17 | 封面 / 宣传图 AI 生成原子 |
|
||||
| T-AGC-18 | DAG 工作流引擎 + 节点配置参数化 |
|
||||
| T-AGC-19 | 生成风格一致性检测原子（供锁风门） |
|
||||
| T-AGC-20 | Golden Config 回归测试 |
|
||||
| T-AGC-21 | 生成结果质量自动评估 |
|
||||
|
||||
### game-module-runtime 扩｜编译 / 预览 / 渠道发布
|
||||
|
||||
- **职责**：GameConfig→版本化可运行包，沙箱预览，多渠道（小游戏/试玩包）转换与发布状态机。
|
||||
- **边界 IN**：编译/Manifest/打包、沙箱与事件桥接、体积与完整性校验、预加载与缓存、渠道转换与提审、发布状态机、运行时质量采集。
|
||||
- **边界 OUT**：不决定发布放行（交 compliance）｜不做推荐分发（交 feed）｜不持久化项目（读 project）｜不跑生成（消费 aigc 产物）。
|
||||
- **依赖**：project · aigc · telemetry · compliance（渠道合规，被动）。
|
||||
|
||||
| ID | 技术功能 | ID | 技术功能 |
|
||||
|---|---|---|---|
|
||||
| T-RT-01 | GameConfig→可运行 Web 包编译 | T-RT-17 | 帧率 FPS 监控采集 |
|
||||
| T-RT-02 | GameManifest 生成与打包 | T-RT-18 | 素材压缩（WebP/AVIF/裁剪） |
|
||||
| T-RT-03 | 资源打包上传 OSS（版本化路径） | T-RT-19 | 多尺寸封面裁剪 |
|
||||
| T-RT-04 | iframe 沙箱隔离 + CSP | T-RT-20 | CDN 缓存刷新 |
|
||||
| T-RT-05 | Game SDK 事件桥接 | T-RT-21 | 小游戏转换-微信 |
|
||||
| T-RT-06 | Canvas/WebGL 渲染容器 | T-RT-22 | 小游戏转换-抖音 |
|
||||
| T-RT-07 | GameConfig 运行时注入 | T-RT-23 | 小游戏转换-快手 |
|
||||
| T-RT-08 | 游戏资源体积限制（≤10MB/首屏≤2MB） | T-RT-24 | 渠道适配规则库 |
|
||||
| T-RT-09 | 资源 hash 命名长期缓存 | T-RT-25 | 自动图标/封面/截图生成 |
|
||||
| T-RT-10 | 资源版本化路径 | T-RT-26 | 统一工程转译引擎 |
|
||||
| T-RT-11 | 预加载与三容器策略 | T-RT-27 | 游戏可玩性自动测试（Playwright） |
|
||||
| T-RT-12 | 加载超时自动跳过 | T-RT-28 | 运行时链路追踪（trace_id） |
|
||||
| T-RT-13 | 运行错误捕获与上报 | T-RT-29 | 游戏包体积监控 |
|
||||
| T-RT-14 | postMessage 来源与 schema 校验 | T-RT-30 | 云游戏即时运行容器（远期） |
|
||||
| T-RT-15 | Manifest 完整性校验 | T-RT-31 | **TapTap 试玩包提审通道**（试玩包/APK 路径） |
|
||||
| T-RT-16 | GameConfig 静态校验 | T-RT-32 | **渠道发布状态机**（自有必选/待开通→申请→开通→上线） |
|
||||
|
||||
### game-module-project 扩｜项目生命周期 + 专区 Zone
|
||||
|
||||
- **职责**：项目/版本/草稿全生命周期与状态流转，编排发布，承载专区 Zone 实体（owner）。
|
||||
- **边界 IN**：项目/版本 CRUD、状态机、草稿持久化、发布前检查、发布审核 BPM 对接、统一发布编排、Zone 实体/归属/运营位/launchZone。
|
||||
- **边界 OUT**：不生成内容（aigc/studio）｜不裁决审核结论（compliance，本模块只驱动状态）｜不编译/转换（runtime）｜不做推荐排序（feed）。
|
||||
- **依赖**：compliance · runtime · feed · bpm · infra。
|
||||
|
||||
| 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 对接（Flowable，回写状态） |
|
||||
| T-PRJ-07 | 专区 Zone 实体 + 游戏归属 + 运营位（精选/新游/全部）+ launchZone |
|
||||
| T-PRJ-08 | 统一发布编排（compliance→runtime→feed，失败回滚） |
|
||||
| T-PRJ-09 | 游戏工程包导出（+ 多渠道审核元数据预留） |
|
||||
| T-PRJ-10 | 版本回退 |
|
||||
|
||||
### game-module-feed 扩｜游戏流 + 专区分区
|
||||
|
||||
- **职责**：已发布游戏按规则推荐排序成竖屏游戏流，回收互动信号，分享外链，按 Zone 分区。
|
||||
- **边界 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 | 候选集缓存（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 | 互动信号写入（赞/藏/享/举报→权重） | | |
|
||||
|
||||
### game-module-telemetry ｜遥测与数据底座
|
||||
|
||||
- **职责**：统一摄取全链路事件，治理 Schema、增量聚合、算 quality_score，产出监控告警与数据质量信号。
|
||||
- **边界 IN**：事件摄取/SDK 上报、Schema 治理、聚合、质量/漏斗/留存/归因计算、埋点采集、健康监控、告警、数据质量、重复检测原子。
|
||||
- **边界 OUT**：不渲染看板/建议/导出 UI（供数据交 Doc A 产品域）｜不做推荐决策（产信号给 feed）｜不生成迭代内容（建议交 studio/aigc）。
|
||||
- **依赖**：feed · project · compliance。
|
||||
|
||||
| ID | 技术功能 | ID | 技术功能 |
|
||||
|---|---|---|---|
|
||||
| T-TEL-01 | 事件批量摄取（/events/batch） | T-TEL-12 | 运行时 FPS 采集 |
|
||||
| T-TEL-02 | 事件 Schema 治理 | T-TEL-13 | 实时监控-服务健康 |
|
||||
| T-TEL-03 | 埋点批量上报通道（sendBeacon 兜底） | T-TEL-14 | 实时监控-生成任务健康 |
|
||||
| T-TEL-04 | quality_score 计算 | T-TEL-15 | 实时监控-Runtime 健康 |
|
||||
| T-TEL-05 | 增量聚合（GameDailyStats） | T-TEL-16 | 异常检测与告警 |
|
||||
| T-TEL-06 | 创作漏斗计算 | T-TEL-17 | 生成失败根因聚合 |
|
||||
| T-TEL-07 | 游戏流消费漏斗计算 | T-TEL-18 | 渠道归因计算 |
|
||||
| T-TEL-08 | 玩家留存计算 | T-TEL-19 | 数据质量监控 |
|
||||
| T-TEL-09 | 创作者复创率计算 | T-TEL-20 | 推荐效果监控 |
|
||||
| T-TEL-10 | 平台 Product Metrics 计算 | T-TEL-21 | 玩家设备/性能画像计算 |
|
||||
| T-TEL-11 | 游戏加载时间埋点 | T-TEL-22 | 重复内容检测原子 |
|
||||
|
||||
### game-module-pay ｜支付收单 / 订单 / 退款对账
|
||||
|
||||
- **职责**：把各类付费统一收单为可追溯、可对账、可幂等的支付订单，对上层屏蔽渠道差异。
|
||||
- **边界 IN**：支付渠道抽象、订单状态机、退款、对账、幂等。
|
||||
- **边界 OUT**：不定义会员/积分/内购产品形态与定价（产品域配置）｜不做分账/钱包/提现（交 trade）。
|
||||
- **依赖**：yudao-system · trade · 微信/支付宝/Apple IAP · Redis。
|
||||
|
||||
| ID | 技术功能 |
|
||||
|---|---|
|
||||
| T-PAY-01 | 支付网关抽象（微信/支付宝/Apple IAP） |
|
||||
| T-PAY-02 | 支付订单状态机 |
|
||||
| T-PAY-03 | 退款处理 |
|
||||
| T-PAY-04 | 支付对账 |
|
||||
| T-PAY-05 | 支付幂等（Redis 防重复扣款/回调） |
|
||||
|
||||
### game-module-trade ｜分账 / 结算 / 对账域
|
||||
|
||||
- **职责**：把多源收入按规则分账、归集、结算、对账并出财税报表，无感资金清算后端。
|
||||
- **边界 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 | 奖金/补贴发放执行引擎 |
|
||||
|
||||
### game-module-community ｜社交 / 互动 / 通知底座
|
||||
|
||||
- **职责**：承载社交关系、互动计数、排行/成就计算与全渠道通知投递，不定义可感知社交玩法形态。
|
||||
- **边界 IN**：社交关系图谱、互动计数、排行计算、成就引擎、动态扇出、站内信、推送/邮件/短信通道、通知编排、等级自动升降计算。
|
||||
- **边界 OUT**：不渲染社区前端/不定义玩法（产品侧）｜不裁决内容安全（调 compliance）｜不算质量分（读 telemetry）｜不结算奖金分成（交 trade）。
|
||||
- **依赖**：project · telemetry · compliance · yudao-system · yudao-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 | 站内信投递与已读 | | |
|
||||
|
||||
### game-module-ip 扩｜素材安全 / 授权 / IP 风格原子
|
||||
|
||||
- **职责**：为素材/IP 资产提供安全可信、授权可溯、风格可校的底座原子，并按 Zone 双轨归类。
|
||||
- **边界 IN**：素材安全扫描、授权链追溯、授权/分成数据、IP 风格校验原子、冻结、盗用监测、模型训练对接、Zone 双轨归类。
|
||||
- **边界 OUT**：不做最终锁风裁决（供原子给 compliance）｜不做资金结算（交 trade）｜不跑生成（aigc）｜不承载素材/模板市场交互（供料 Doc A）。
|
||||
- **依赖**：compliance · trade · project · aigc · infra/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） |
|
||||
|
||||
### game-module-compliance 扩｜内容安全 / 审核 / 锁风门
|
||||
|
||||
- **职责**：内容安全与审核中枢——安全检测、审核状态机与人工复核、聚合风格原子做锁风裁决，并承载 RBAC/审计/加密/安全基线/防沉迷。
|
||||
- **边界 IN**：文本/图片/AI 产物安全检测、违禁词、审核状态机/分层/人工复核、举报降权、锁风门聚合裁决、RBAC、审计、安全基线、防沉迷接入、分级判定、渠道合规、封禁、备份。
|
||||
- **边界 OUT**：不自产风格检测原子（aigc/ip 供给）｜不拥有项目实体（读 project）｜不做推荐（产降权信号给 feed）｜不展示隐私/申诉 UI（产品功能，交 studio）。
|
||||
- **依赖**：aigc（T-AGC-19）· ip（T-IP-04）· project · feed · yudao-system/bpm · 内容安全 API · Vault。
|
||||
|
||||
| ID | 技术功能 | ID | 技术功能 |
|
||||
|---|---|---|---|
|
||||
| T-CMP-01 | 文本内容安全检测 | T-CMP-20 | 审计日志长期保存（≥180 天） |
|
||||
| T-CMP-02 | 图片内容安全检测 | T-CMP-21 | 安全日志与告警 |
|
||||
| T-CMP-03 | AI 生成内容风控 | T-CMP-22 | 上传文件安全校验 |
|
||||
| T-CMP-04 | 违禁词库管理 | T-CMP-23 | OWASP Top 10 安全基线 |
|
||||
| T-CMP-05 | Prompt 注入防护 | T-CMP-24 | SSRF 防护 |
|
||||
| T-CMP-06 | 审核决策与状态机 | T-CMP-25 | CORS 与 CSP 配置 |
|
||||
| T-CMP-07 | 风险等级分层策略 | T-CMP-26 | 游戏沙箱隔离安全策略（供 runtime 落地） |
|
||||
| T-CMP-08 | 自动审核（机审通过） | T-CMP-27 | Secrets 管理（Vault） |
|
||||
| T-CMP-09 | 人工审核队列 | T-CMP-28 | 敏感数据加密存储 |
|
||||
| T-CMP-10 | 举报受理与处理 | T-CMP-29 | 数据传输加密（全站 HTTPS） |
|
||||
| T-CMP-11 | 举报阈值自动降权 | T-CMP-30 | 日志脱敏 |
|
||||
| **T-CMP-12** | **锁风门 Gate**（聚合 T-AGC-19+T-IP-04→pass/review/block + 标准/严格/人工复核；挂 T-PRJ-05） | T-CMP-31 | 登录安全与限频 |
|
||||
| T-CMP-13 | 分级标签判定 | T-CMP-32 | 依赖漏洞扫描 |
|
||||
| T-CMP-14 | 渠道审核规则库（微信/抖音/快手/TapTap） | T-CMP-33 | 用户数据最小化采集 |
|
||||
| T-CMP-15 | 多渠道合规自动检测 | T-CMP-34 | 用户数据删除权 |
|
||||
| T-CMP-16 | RBAC 权限控制 | T-CMP-35 | GDPR/个保法预留 |
|
||||
| T-CMP-17 | 匿名用户权限约束 | T-CMP-36 | 未成年人防沉迷接入 |
|
||||
| T-CMP-18 | 用户封禁与限制发布 | T-CMP-37 | 实名认证接入 |
|
||||
| T-CMP-19 | 管理员操作审计日志 | T-CMP-38 | 数据备份与恢复 |
|
||||
|
||||
### game-module-biz ｜B/G 端定制工程底座
|
||||
|
||||
- **职责**：为 B/G 端定制提供报价、BPM 编排、签章、CRM、交付验收状态机与效果报告聚合。
|
||||
- **边界 IN**：报价计算、BPM 实例编排、电子签章对接、CRM 对接、交付验收状态机、效果数据聚合、代办工单跟踪。
|
||||
- **边界 OUT**：不生成游戏（aigc）｜不持久化项目（project）｜不收款结算（trade）｜不裁决合规（compliance）｜不承载 B 端 UI 语义（Doc A）。
|
||||
- **依赖**：project · aigc · trade · compliance · bpm · 电子签章 · CRM。
|
||||
|
||||
| ID | 技术功能 |
|
||||
|---|---|
|
||||
| T-BIZ-01 | B 端项目报价引擎 |
|
||||
| T-BIZ-02 | BPM 定制项目编排（需求→报价→签约→交付） |
|
||||
| T-BIZ-03 | 电子签章服务对接 |
|
||||
| T-BIZ-04 | CRM 客户/合同数据对接 |
|
||||
| T-BIZ-05 | 交付验收状态机 |
|
||||
| T-BIZ-06 | B 端效果数据聚合 |
|
||||
| T-BIZ-07 | 代办流程外部工单与状态跟踪（软著/渠道/资质） |
|
||||
| T-BIZ-08 | 收费与变更管理（预付/尾款/变更单） |
|
||||
|
||||
### game-module-ad ｜广告引擎（植入→展示→计费→优化）
|
||||
|
||||
- **职责**：把联盟接入、广告位 AI 植入、曝光计费、eCPM 优化与归因做成游戏内广告后端原子。
|
||||
- **边界 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 | 联盟对接·穿山甲 | T-AD-07 | eCPM 优化与精准匹配 |
|
||||
| T-AD-03 | 联盟对接·优量汇 | T-AD-08 | 广告合规植入校验 |
|
||||
| T-AD-04 | 联盟对接·快手 | T-AD-09 | 广告位效果归因 |
|
||||
| T-AD-05 | 联盟对接·百青藤 | | |
|
||||
|
||||
---
|
||||
|
||||
## 2. 技术功能计数
|
||||
|
||||
| 模块 | T-features | 模块 | T-features |
|
||||
|---|---|---|---|
|
||||
| studio | 11 | trade | 12 |
|
||||
| aigc | 21 | community | 11 |
|
||||
| runtime | 32 | ip | 10 |
|
||||
| project | 10 | compliance | 38 |
|
||||
| feed | 15 | biz | 8 |
|
||||
| telemetry | 22 | ad | 9 |
|
||||
| pay | 5 | **合计** | **204** |
|
||||
|
||||
> v2.0 的 299 条混合能力，二分后：技术功能 204 项入本文，产品功能 155 项入 Doc A（155+204=359，其中约 60 项能力同时有产品面与工程面、两侧各计一次，故和 > 299）。映射见 Doc C。
|
||||
@ -7,7 +7,7 @@
|
||||
> **生成时间**：2026-06-07
|
||||
> **前置阅读**：
|
||||
> - 技术决策版（架构全貌）：`2026-06-06-系统概要设计-技术决策版.md`
|
||||
> - 模块能力全景：`2026-06-06-v2业务能力全景与模块归属.md`
|
||||
> - 技术架构与模块（Doc B，13 模块）：`2026-06-07-技术架构与模块.md`
|
||||
|
||||
---
|
||||
|
||||
@ -613,7 +613,7 @@ layaair2-cmd publish -p kuaishou -i ./game-output/ -o ./dist/kuaishou/
|
||||
| MinIO 文件管理 | http://localhost:9001 |
|
||||
| Grafana 监控 | http://localhost:3002 |
|
||||
| 设计文档目录 | `docs/architecture/` |
|
||||
| 业务能力全景 | `docs/architecture/2026-06-06-v2业务能力全景与模块归属.md` |
|
||||
| 技术架构与模块（Doc B） | `docs/architecture/2026-06-07-技术架构与模块.md` |
|
||||
| Yudao 官方文档 | https://cloud.iocoder.cn |
|
||||
| LayaAir 文档 | https://www.layaair.com/3.x/doc/ |
|
||||
| ComfyUI 文档 | https://docs.comfy.org |
|
||||
|
||||
258
docs/architecture/2026-06-07-需求模块映射.md
Normal file
258
docs/architecture/2026-06-07-需求模块映射.md
Normal file
@ -0,0 +1,258 @@
|
||||
# 绘境AI — 需求↔模块 映射（Doc C）
|
||||
|
||||
> 文档类型：**Doc C｜产品功能 ↔ 技术功能 追溯映射**（唯一承载 M:N 关系的文档）
|
||||
> 文档 ID：HJ-MAP-002 ｜ 生成时间：2026-06-07
|
||||
> 两端：产品功能 = Doc A 的 `P-id`（`2026-06-07-产品需求清单.md`）；技术功能 = Doc B 的 `T-id`（`2026-06-07-技术架构与模块.md`）
|
||||
>
|
||||
> **本文存在的理由**：Doc A 与 Doc B 互不引用、各自高内聚；二者的多对多映射是易变耦合点，单独隔离在本文。改产品或改模块，只动本文。
|
||||
> **读法**：每行一个产品功能；**首要 owner** = 该功能的主要负责模块（问责/排期归属）；**★主技术功能** = 主要实现；**辅** = 支撑/兜底。`T-id` 前缀即所属模块。
|
||||
|
||||
---
|
||||
|
||||
## 域 1 素材中心（MAT）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-MAT-01 浏览授权 IP 库 | ip | T-IP-10 Zone双轨归类 · T-IP-02 授权链 | T-IP-01 安全扫描 |
|
||||
| P-MAT-02 浏览 UGC 库 | ip | T-IP-10 Zone双轨归类 | T-IP-02 授权链 |
|
||||
| P-MAT-03 选用入草稿 | studio | T-STU-08 草稿装配 · T-STU-06 附件装配 | T-PRJ-04 草稿 · T-IP-02 |
|
||||
| P-MAT-04 采购授权包 | ip | T-IP-03 授权/分成数据 | T-PAY-01 · T-TRD-05 |
|
||||
| P-MAT-05 授权/锁风/分成标签 | ip | T-IP-02 授权链 · T-IP-04 IP风格原子 | T-CMP-12 锁风门 |
|
||||
| P-MAT-06 版权声明与管理 | ip | T-IP-02 授权链 | T-IP-01 安全扫描 |
|
||||
|
||||
## 域 2 玩法模板（TPL）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-TPL-01 浏览模板+蓝图 | aigc | T-AGC-03 模板分类/注册 | T-IP-09 模板市场 |
|
||||
| P-TPL-02 配置参数 | aigc | T-AGC-03 模板 · T-AGC-05 参数校验 | T-AD-01 运营点位 |
|
||||
| P-TPL-03 应用模板到草稿 | studio | T-STU-08 草稿装配 · T-STU-09 六资产调度 | T-AGC-03 · T-PRJ-04 |
|
||||
| P-TPL-04 收藏模板 | ip | T-IP-09 模板市场 | — |
|
||||
| P-TPL-05 购买商用模板 | ip | T-IP-03 授权/分成 · T-IP-09 模板授权分成 | T-PAY-01 · T-TRD-05 |
|
||||
|
||||
## 域 3 自定义创作（CRT）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-CRT-01 自然语言生成 | studio | T-STU-05 任务链 · T-AGC-04 GameConfig · T-AGC-06 LLM编排 | T-AGC-01 解析 · T-AGC-02 安全 · T-PRJ-04 草稿 |
|
||||
| P-CRT-02 六资产模块化生成 | studio | T-STU-09 六资产调度 · T-STU-02 资产图 · T-AGC-14 图原子 · T-AGC-15 音原子 | — |
|
||||
| P-CRT-03 图/文生角色 | studio | T-STU-03 角色rig · T-AGC-14 图原子 | T-AGC-16 剧情原子 |
|
||||
| P-CRT-04 附件驱动创作 | studio | T-STU-06 附件上下文装配 | — |
|
||||
| P-CRT-05 智能体任务链可视 | studio | T-STU-05 任务链 · T-STU-07 SSE | T-AGC-08 生成状态机 |
|
||||
| P-CRT-06 骨骼拆件/动作编辑 | studio | T-STU-03 角色rig | — |
|
||||
| P-CRT-07 导出动作包 | studio | T-STU-03 rig · T-STU-08 移交 | — |
|
||||
| P-CRT-08 实时预览试玩 | runtime | T-RT-01 编译 · T-RT-06 渲染容器 · T-RT-07 注入 · T-RT-04 沙箱 | T-STU-07 SSE |
|
||||
| P-CRT-09 重生成/迭代 | studio | T-STU-05 任务链 · T-AGC-08 状态机 · T-AGC-09 Fallback | T-AGC-06 LLM编排 |
|
||||
| P-CRT-10 创作引导教程 | studio | T-STU-01 会话 | T-AGC-03 模板 |
|
||||
| P-CRT-11 示例 Prompt 库 | aigc | T-AGC-03 模板注册(内置示例) | T-AGC-01 解析 |
|
||||
| P-CRT-12 生成进度展示 | studio | T-STU-07 SSE · T-STU-05 任务链 | T-AGC-08 状态机 |
|
||||
| P-CRT-13 生成超时通知 | aigc | T-AGC-08 状态机 · T-AGC-07 队列 | T-CMU-10 通知编排 |
|
||||
| P-CRT-14 模板参数编辑 | studio | T-STU-08 装配 · T-AGC-05 参数校验 | T-AGC-04 GameConfig |
|
||||
| P-CRT-15 游戏流专属版本适配 | studio | T-STU-09 资产调度 · T-AGC-04 GameConfig | T-AGC-14 图原子 |
|
||||
|
||||
## 域 4 授权 IP 创作（LIC）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-LIC-01 选授权 IP 母体 | ip | T-IP-02 授权链 · T-IP-10 Zone归类 | T-STU-01 会话 |
|
||||
| P-LIC-02 模板+授权美术包 | studio | T-STU-08 装配 · T-IP-09 模板市场 | T-AGC-03 模板 |
|
||||
| P-LIC-03 补充/导入资产 | studio | T-STU-06 附件装配 | T-AGC-14 图原子 |
|
||||
| P-LIC-04 分支对白调试 | studio | T-STU-04 对白分支树 | T-AGC-16 剧情原子 |
|
||||
| P-LIC-05 锁风调试 | compliance | T-CMP-12 锁风门 Gate | T-AGC-19 生成风格原子 · T-IP-04 IP风格原子 |
|
||||
| P-LIC-06 发布去向专区 | project | T-PRJ-07 Zone/launchZone | — |
|
||||
|
||||
## 域 5 发布分发（PUB）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-PUB-01 一键多渠道发布 | project | T-PRJ-08 统一编排 · T-CMP-12 锁风门 · T-RT-32 渠道状态机 · T-RT-21/22/23 转换 · T-FED-15 分区上架 | T-RT-31 TapTap · T-CMP-06 审核状态机 |
|
||||
| P-PUB-02 渠道开通状态 | runtime | T-RT-32 渠道发布状态机 | — |
|
||||
| P-PUB-03 发布前检查 | project | T-PRJ-05 检查清单 · T-CMP-12 锁风门 | T-RT-08 体积限制 · T-RT-29 体积监控 |
|
||||
| P-PUB-04 保存发布配置 | project | T-PRJ-08 编排 · T-PRJ-05 检查清单 | — |
|
||||
| P-PUB-05 渠道简介自动改写 | runtime | T-RT-24 渠道适配规则库 | T-CMP-15 多渠道合规 · T-AGC-16 剧情原子 |
|
||||
|
||||
## 域 6 游戏广场（PLZ）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-PLZ-01 双专区浏览 | feed | T-FED-15 按Zone分区 | T-PRJ-07 Zone实体 |
|
||||
| P-PLZ-02 专区分组 | feed | T-FED-15 分区 · T-FED-01 推荐打分 | T-PRJ-07 运营位 |
|
||||
| P-PLZ-03 点击即试玩 | runtime | T-RT-01 编译 · T-RT-04 沙箱 · T-RT-07 注入 | T-FED-02 候选集 |
|
||||
|
||||
## 域 7 游戏信息流（FED）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-FED-01 竖屏即玩 | feed | T-FED-06 cursor · T-RT-04 沙箱 · T-RT-11 三容器 | T-FED-01 推荐打分 |
|
||||
| P-FED-02 上下切换 | feed | T-FED-06 cursor | T-RT-11 三容器预加载 |
|
||||
| P-FED-03 点赞 | feed | T-FED-08 互动信号 | T-FED-01 推荐回灌 |
|
||||
| P-FED-04 收藏 | feed | T-FED-08 互动信号 | T-CMU-02 计数(收藏夹) |
|
||||
| P-FED-05 分享到社交平台 | feed | T-FED-09 分享页/OG · T-FED-10 渠道参数 | T-RT-21 渠道转换 |
|
||||
| P-FED-06 举报 | feed | T-FED-08 互动信号 | T-CMP-10 举报受理 |
|
||||
| P-FED-07 独立分享链接 | feed | T-FED-09 分享页/OG | T-FED-10 渠道参数 |
|
||||
| P-FED-08 分享落地页 | feed | T-FED-09 分享页/OG | T-PRJ-01 项目元信息 |
|
||||
| P-FED-09 原生分享/复制链接 | feed | T-FED-09 分享页/OG | — |
|
||||
| P-FED-10 加载进度反馈 | feed | T-FED-02 候选集 | T-RT-11 三容器 · T-RT-12 超时跳过 |
|
||||
| P-FED-11 首屏封面展示 | feed | T-FED-01 推荐打分 | T-PRJ-01 封面/作者元信息 · T-AGC-17 封面生成原子 |
|
||||
| P-FED-12 同款创作跳转 | studio | T-STU-01 会话承接 | T-FED-09 导航 |
|
||||
| P-FED-13 推荐池 | feed | T-FED-01 推荐打分 · T-FED-02 候选集 | T-FED-11 行为加权 |
|
||||
| P-FED-14 多端适配操控 | runtime | T-RT-06 渲染容器 | — |
|
||||
| P-FED-15 低画质模式 | runtime | T-RT-17 帧率监控 · T-RT-18 素材压缩 | — |
|
||||
| P-FED-16 弱网/离线兜底 | runtime | T-RT-13 错误捕获 · T-RT-20 CDN刷新 | — |
|
||||
|
||||
## 域 8 创作者数据经营（OPS）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-OPS-01 创作者数据看板 | telemetry | T-TEL-05 聚合 · T-TEL-04 quality_score | T-TEL-11 加载埋点 · T-AD-09 广告归因 |
|
||||
| P-OPS-02 七日趋势 | telemetry | T-TEL-05 聚合 · T-TEL-08 留存 | — |
|
||||
| P-OPS-03 AI 内容诊断 | telemetry | T-TEL-07 消费漏斗 · T-TEL-20 推荐效果 | T-AGC-16 建议生成 |
|
||||
| P-OPS-04 一键迭代/改版任务 | telemetry | T-TEL-07 漏斗 | T-STU-05 任务链 · T-AGC-08 状态机 |
|
||||
| P-OPS-05 A/B 测试版本 | telemetry | T-TEL-04 quality · T-PRJ-03 版本 | T-FED-12 A/B 框架 |
|
||||
| P-OPS-06 AI 玩法/美术/赛道建议 | telemetry | T-TEL-07 漏斗 · T-TEL-20 推荐效果 | T-AGC-11 风格标签 |
|
||||
|
||||
## 域 9 创作者钱包收益（WAL）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-WAL-01 钱包余额管理 | trade | T-TRD-02 多渠道归集 · T-TRD-05 佣金计算 | T-TRD-01 分账 |
|
||||
| P-WAL-02 提现 | trade | T-TRD-11 提现门槛与打款 | T-PAY-01 付款通道 · T-TRD-06 税务 |
|
||||
| P-WAL-03 收益明细 | trade | T-TRD-02 归集 · T-TRD-03 结算周期 | T-TRD-04 对账 · T-TRD-07 报表 |
|
||||
| P-WAL-04 收益透明度看板 | trade | T-TRD-03 结算周期 · T-TRD-11 提现进度 | T-TRD-04 对账 |
|
||||
|
||||
## 域 10 付费变现（PAY）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-PAY-01 积分充值 | pay | T-PAY-01 网关 · T-PAY-02 订单状态机 | T-PAY-05 幂等 |
|
||||
| P-PAY-02 会员订阅体系 | pay | T-PAY-01 网关 · T-PAY-02 订单状态机 | T-PAY-05 幂等 |
|
||||
| P-PAY-03 付费推广流量包 | pay | T-PAY-01 · T-PAY-02 | T-FED-01 流量(消费方) |
|
||||
| P-PAY-04 会员等级与权益 | pay | T-PAY-02 订单状态机 | T-PAY-01 网关 |
|
||||
| P-PAY-05 游戏内购-道具 | pay | T-PAY-01 网关 · T-PAY-02 订单状态机 | T-PAY-05 幂等 |
|
||||
| P-PAY-06 游戏内购-皮肤与角色 | pay | T-PAY-01 网关 · T-PAY-02 订单状态机 | T-PAY-05 幂等 |
|
||||
| P-PAY-07 游戏内购-关卡解锁 | pay | T-PAY-01 网关 · T-PAY-02 订单状态机 | T-PAY-05 幂等 |
|
||||
| P-PAY-08 打赏创作者 | pay | T-PAY-01 网关 · T-PAY-02 订单状态机 | T-PAY-05 幂等 |
|
||||
| P-PAY-09 B 端在线支付 | pay | T-PAY-01 · T-PAY-02 · T-PAY-03 退款 | T-PAY-04 对账 |
|
||||
|
||||
## 域 11 广告变现（ADV）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-ADV-01 激励视频广告 | ad | T-AD-01 AI植入 · T-AD-06 曝光计费 | T-RT-05 SDK渲染 · T-TRD-01 结算 |
|
||||
| P-ADV-02 插屏广告 | ad | T-AD-01 AI植入 · T-AD-06 曝光计费 | T-RT-05 SDK渲染 · T-TRD-01 结算 |
|
||||
| P-ADV-03 Banner 广告 | ad | T-AD-01 AI植入 · T-AD-06 曝光计费 | T-RT-05 SDK渲染 · T-TRD-01 结算 |
|
||||
| P-ADV-04 原生广告 | ad | T-AD-01 AI植入 · T-AD-06 曝光计费 | T-RT-05 SDK渲染 · T-TRD-01 结算 |
|
||||
| P-ADV-05 广告触发配置 | ad | T-AD-01 AI植入 | T-AD-08 合规植入 |
|
||||
| P-ADV-06 广告收益实时统计 | ad | T-AD-06 计费 · T-AD-09 归因 | T-TEL-05 看板 · T-TRD-01 结算 |
|
||||
| P-ADV-07 广告位可视化配置 | ad | T-AD-01 AI植入 | T-AD-08 合规植入 |
|
||||
| P-ADV-08 AI 广告位优化建议 | ad | T-AD-09 归因 · T-AD-07 eCPM | T-TEL-07 漏斗 |
|
||||
| P-ADV-09 B 端品牌广告投放 | ad | T-AD-07 eCPM | T-FED-01 游戏流位 · T-AD-06 计费 |
|
||||
|
||||
## 域 12 社区互动（SOC）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-SOC-01 评论与回复 | community | T-CMU-02 互动计数 | T-CMU-10 通知 · T-CMP-01 文本安全 |
|
||||
| P-SOC-02 关注创作者 | community | T-CMU-01 关系图谱 | T-CMU-05 扇出 · T-CMU-10 通知 |
|
||||
| P-SOC-03 粉丝体系 | community | T-CMU-01 关系图谱 | T-CMU-02 计数 |
|
||||
| P-SOC-04 创作者动态 Feed | community | T-CMU-05 动态扇出 | T-CMU-01 · T-CMU-10 |
|
||||
| P-SOC-05 排行榜(创作者/作品) | community | T-CMU-03 排行计算 | T-CMU-02 · T-TEL-04 quality |
|
||||
| P-SOC-06 排行榜(玩家) | community | T-CMU-03 排行计算 | — |
|
||||
| P-SOC-07 成就徽章 | community | T-CMU-04 成就引擎 | T-CMU-10 通知 |
|
||||
| P-SOC-08 弹幕互动 | community | T-CMU-02 互动计数 | T-CMP-01 安全 |
|
||||
| P-SOC-09 玩家个人主页 | community | T-CMU-02 计数 | T-CMU-04 · T-CMU-01 |
|
||||
| P-SOC-10 好友系统 | community | T-CMU-01 关系图谱 | — |
|
||||
| P-SOC-11 组队/多人游玩 | community | T-CMU-01 关系图谱 | T-RT-06 对局 · （远期：feed 房间待 Doc B 定义）|
|
||||
|
||||
## 域 13 创作者成长（GRW）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-GRW-01 创作者教程体系 | community | T-CMU-02 互动计数 | — |
|
||||
| P-GRW-02 创作挑战赛 | community | T-CMU-05 扇出 · T-CMU-03 榜单 | T-CMU-10 通知 · T-TRD-12 奖金 |
|
||||
| P-GRW-03 热门玩法拆解 | community | T-CMU-02 计数 | T-TEL-07 数据 |
|
||||
| P-GRW-04 创作者社群/圈子 | community | T-CMU-05 扇出 · T-CMU-02 | — |
|
||||
| P-GRW-05 圈层共创计划 | community | T-CMU-05 扇出 | T-IP-09 圈层模板 · T-CMU-03 |
|
||||
| P-GRW-06 多人协同创作(远期) | studio | T-STU-01 会话（远期：协同主实现待建）| T-CMU-01 关系 |
|
||||
|
||||
## 域 14 创作者激励（INC）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-INC-01 新人任务奖励 | community | T-CMU-11 等级引擎 | T-TRD-12 发放 · T-FED-03 流量 · T-CMU-10 |
|
||||
| P-INC-02 创作者等级体系 | community | T-CMU-11 等级引擎 | T-TEL-04 行为信号 |
|
||||
| P-INC-03 等级权益分层 | community | T-CMU-11 等级引擎 | T-PAY-02 功能 · T-FED-01 流量 · T-TRD-01 分成 |
|
||||
| P-INC-04 创作者认证 | community | T-CMU-01 认证标识 | T-CMP-37 资质核验 |
|
||||
| P-INC-05 创作大赛奖金 | trade | T-TRD-12 发放执行 | T-CMU-03 榜单 · T-CMU-10 通知 |
|
||||
| P-INC-06 创作者补贴 | trade | T-TRD-12 发放执行 | T-CMU-11 等级 |
|
||||
|
||||
## 域 15 消息通知（NTF）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-NTF-01 站内消息中心 | community | T-CMU-06 站内信 | T-CMU-10 通知编排 |
|
||||
| P-NTF-02 生成任务完成通知 | community | T-CMU-10 通知编排 | T-CMU-06/07 · T-AGC-08 事件源 |
|
||||
| P-NTF-03 审核结果通知 | community | T-CMU-10 通知编排 | T-CMU-06 · T-CMP-06 事件源 |
|
||||
| P-NTF-04 新粉丝/互动通知 | community | T-CMU-10 通知编排 | T-CMU-07 推送 · T-CMU-01 |
|
||||
| P-NTF-05 收益变动通知 | community | T-CMU-10 通知编排 | T-CMU-09 短信 · T-TRD 事件源 |
|
||||
| P-NTF-06 活动/赛事通知 | community | T-CMU-10 通知编排 | T-CMU-08 邮件 |
|
||||
| P-NTF-07 创作者新作品通知 | community | T-CMU-10 通知编排 | T-CMU-05 扇出 · T-CMU-07 |
|
||||
|
||||
## 域 16 IP 孵化与版权（IPX）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-IPX-01 素材市场上架定价 | ip | T-IP-01 安全扫描 · T-IP-10 Zone归类 | T-IP-02 授权链 |
|
||||
| P-IPX-02 素材检索推荐 | ip | T-IP-10 Zone归类 | T-IP-02 |
|
||||
| P-IPX-03 素材交易 | ip | T-IP-03 授权/分成数据 | T-TRD-05 佣金结算 |
|
||||
| P-IPX-04 版权投诉受理 | ip | T-IP-05 冻结 | T-IP-02 · T-IP-06 盗用监测 |
|
||||
| P-IPX-05 DMCA 下架与申诉 | ip | T-IP-05 冻结 | T-CMP-06 审核状态机 |
|
||||
| P-IPX-06 爆款筛选与签约 | ip | T-IP-10 Zone归类 | T-TEL-04 数据筛选 |
|
||||
| P-IPX-07 IP 代运营 | ip | T-IP-10 Zone归类 | T-TRD-01 收益 |
|
||||
| P-IPX-08 IP 周边衍生 | ip | T-IP-02 授权链 | T-TRD-01 分成 |
|
||||
| P-IPX-09 IP 跨界联动 | ip | T-IP-02 授权链 | T-IP-04 风格原子 |
|
||||
| P-IPX-10 IP 授权分成 | ip | T-IP-03 授权/分成数据 | T-TRD-01 结算 |
|
||||
| P-IPX-11 外部成熟 IP 合作 | ip | T-IP-02 授权链 · T-IP-04 风格原子 | T-IP-07 风格训练 |
|
||||
| P-IPX-12 模板授权分成 | ip | T-IP-09 模板授权分成原子 | T-TRD-01 结算 |
|
||||
| P-IPX-13 创作大赛赞助 | ip | T-IP-03 授权/分成 | T-TRD-09 收款 |
|
||||
|
||||
## 域 17 B 端定制（BIZ）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-BIZ-01 需求表单提交 | biz | T-BIZ-02 BPM编排 | T-BIZ-04 CRM |
|
||||
| P-BIZ-02 模板选择与预览 | biz | T-BIZ-02 BPM | T-AGC-03 模板 · T-IP-09 模板市场 |
|
||||
| P-BIZ-03 定制进度看板 | biz | T-BIZ-02 BPM | T-BIZ-05 验收状态机 |
|
||||
| P-BIZ-04 交付验收 | biz | T-BIZ-05 验收状态机 · T-BIZ-03 签章 | T-RT-04 沙箱预览 |
|
||||
| P-BIZ-05 数据效果报告 | biz | T-BIZ-06 效果聚合 | T-TEL-05 聚合 · T-AD-09 广告转化 |
|
||||
| P-BIZ-06 年度服务套餐 | biz | T-BIZ-08 收费变更 | T-BIZ-04 CRM · pay/trade |
|
||||
| P-BIZ-07 代运营服务 | biz | T-BIZ-02 BPM | T-TEL-07 建议 · T-STU-05 任务链 |
|
||||
| P-BIZ-08 品牌营销定制 | biz | T-BIZ-02 BPM · T-BIZ-01 报价 | T-PRJ-01 项目 · T-AGC-06 LLM |
|
||||
| P-BIZ-09 企业私域嵌入分发 | biz | T-BIZ-02 BPM | T-RT-21 渠道转换 |
|
||||
| P-BIZ-10 教育课程体系 | biz | T-BIZ-02 BPM · T-BIZ-04 CRM | T-IP-09 模板授权 · pay/trade |
|
||||
| P-BIZ-11 学生账号与防沉迷 | compliance | T-CMP-36 防沉迷 · T-CMP-37 实名 | T-BIZ-04 CRM(家长管控) |
|
||||
| P-BIZ-12 文旅定制 | biz | T-BIZ-02 BPM · T-BIZ-01 报价 · T-BIZ-05 验收 | T-AGC-03 模板 · T-RT-21 转换 |
|
||||
| P-BIZ-13 政务科普 | biz | T-BIZ-02 BPM · T-BIZ-01 报价 | T-AGC-03 模板 · T-CMP-14 渠道规则 |
|
||||
| P-BIZ-14 资质代办 | biz | T-BIZ-07 代办工单跟踪 | T-RT-31 TapTap提审 · T-CMP-14 |
|
||||
|
||||
## 域 18 运营管理（OPN）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-OPN-01 审核决策与操作 | compliance | T-CMP-06 审核状态机 · T-PRJ-02 游戏状态机 | T-CMP-12 锁风门 |
|
||||
| P-OPN-02 审核拒绝反馈 | project | T-PRJ-06 BPM 对接 | T-CMP-06 审核状态机 |
|
||||
| P-OPN-03 精选池管理 | feed | T-FED-14 精选池接口 · T-PRJ-07 运营位 | T-FED-15 分区 |
|
||||
| P-OPN-04 下架/封禁 | compliance | T-CMP-18 封禁 · T-PRJ-02 状态机 | T-CMP-11 降权 |
|
||||
| P-OPN-05 运营数据看板 | telemetry | T-TEL-05 聚合 · T-TEL-06 创作漏斗 · T-TEL-14 生成健康 | T-TEL-16 告警 |
|
||||
| P-OPN-06 管理层经营看板 | telemetry | T-TEL-10 Product Metrics · T-TEL-08 留存 | T-TEL-18 归因 |
|
||||
| P-OPN-07 数据导出 | telemetry | T-TEL-10 · T-TEL-05 聚合 | T-TEL-08 留存 |
|
||||
| P-OPN-08 创作者主页 | project | T-PRJ-01 项目 CRUD | T-TEL-05 看板数据 |
|
||||
| P-OPN-09 游戏包导出 | project | T-PRJ-09 工程包导出 | T-RT-26 转译引擎 |
|
||||
|
||||
## 域 19 账号与合规告知（ACC）
|
||||
| 产品功能 | 首要 owner | ★主技术功能 | 辅 |
|
||||
|---|---|---|---|
|
||||
| P-ACC-01 账号与会员状态 | system | system 原生（用户/OAuth2） | T-PAY-02 会员订单 |
|
||||
| P-ACC-02 隐私政策/协议展示 | compliance | T-CMP-35 隐私政策/GDPR | T-CMP-33 最小化采集（展示由 studio 前端承载）|
|
||||
| P-ACC-03 适龄分级提示 | compliance | T-CMP-13 分级判定 | T-CMP-14 渠道规则 |
|
||||
| P-ACC-04 创作者审核申诉 | compliance | T-CMP-06 审核状态机 · T-CMP-09 人工队列 | T-CMP-19 审计 |
|
||||
| P-ACC-05 帮助/退出 | system | system 原生 | — |
|
||||
|
||||
---
|
||||
|
||||
## 方法说明：三文档如何消解"混淆"
|
||||
|
||||
以 **runtime** 为例，对照 v2.0 把两类东西并列的问题：
|
||||
|
||||
| 原 runtime 下的条目 | 现三文档归属 |
|
||||
|---|---|
|
||||
| 「游戏实时预览」「即点即玩」（用户可感知） | → Doc A：P-CRT-08 / P-PLZ-03 / P-FED-01 |
|
||||
| 「postMessage 校验」「Manifest 校验」「三容器预加载」（用户无感） | → Doc B：T-RT-14 / T-RT-15 / T-RT-11 |
|
||||
| 两者的对应关系 | → Doc C：本表 P-CRT-08 → ★T-RT-01·T-RT-06·T-RT-07·T-RT-04 |
|
||||
|
||||
**Doc A 不知道 T-id、Doc B 不知道 P-id**，各自高内聚；唯一耦合隔离在本文，任一侧变更只动本表。
|
||||
|
||||
> 155 个产品功能 × 204 个技术功能的多对多映射；首要 owner 已逐条指定，供 MVP 排期与问责归属。
|
||||
> 注：owner=`system` 指 yudao 平台基座（账号/OAuth2 等原生能力），非 13 个业务模块之一。
|
||||
51
docs/memorys/2026-06-07-三文档与MVP口径迁移.md
Normal file
51
docs/memorys/2026-06-07-三文档与MVP口径迁移.md
Normal file
@ -0,0 +1,51 @@
|
||||
# 2026-06-07 三文档体系重构 + MVP 产品功能口径迁移
|
||||
|
||||
> 任务记忆：供后续相似任务读取参考。结论先行。
|
||||
|
||||
## 一句话结论
|
||||
|
||||
架构能力清单从「混合视角单档」拆为**产品/技术/映射三文档**（唯一权威副本、无版本号文件名）；模块 **12→13**（新增 `game-module-studio`）；MVP 验收口径从「能力项(131)」**迁移为 Doc A 的 55 项 P0 产品功能**（工作量参照 ≈137 技术项）。
|
||||
|
||||
## 一、三文档体系（唯一权威，改任一侧只动映射）
|
||||
|
||||
| 文档 | 路径 | 单位 | 总量 | 纪律 |
|
||||
|---|---|---|---|---|
|
||||
| **Doc A 产品需求清单** | `docs/architecture/2026-06-07-产品需求清单.md` | 产品功能 `P-{域}-nn` | 155 | 只写用户可感知，**不得出现模块/技术术语** |
|
||||
| **Doc B 技术架构与模块** | `docs/architecture/2026-06-07-技术架构与模块.md` | 技术功能 `T-{模块}-nn` | 204 | 纯工程分解，**不得出现产品功能** |
|
||||
| **Doc C 需求↔模块映射** | `docs/architecture/2026-06-07-需求模块映射.md` | RTM 行 | 155 | **唯一承载 M:N**；列=产品功能·首要owner·★主T·辅 |
|
||||
|
||||
- 产品(WHAT) 与 技术(HOW) 是两视角，关系**多对多**；映射是易变耦合点，单独隔离成文，A/B 保持解耦纯净。
|
||||
- 文件名**不带版本号**（去掉了 `v2.1-`）；版本历史交给 git，文档内只记「最近修订 + 摘要」。
|
||||
- 旧混合档《业务能力全景与模块归属》已删除（git 留史），其 8 章节内容已二分进三文档 + 存活概要设计档，~20 处「蒸馏来源」引用已重定向。
|
||||
|
||||
## 二、13 模块（前缀）
|
||||
|
||||
STU(studio·新增创作编排域) / AGC(aigc·收敛为无状态生成原子) / RT / PRJ(含专区Zone实体) / FED(含按Zone分区) / TEL / PAY / TRD / CMU / IP / CMP(含锁风门Gate) / BIZ / AD。
|
||||
两条横切关注点显式建模、单一 owner：**锁风门 Gate**(owner=compliance, T-CMP-12)、**专区 Zone 双轨**(owner=project, T-PRJ-07)。
|
||||
|
||||
## 三、MVP 口径（**三个单位勿混用**）
|
||||
|
||||
| 口径 | 单位 | MVP 值 | 用途 |
|
||||
|---|---|---|---|
|
||||
| **验收**（对用户） | Doc A 产品功能 | **55 项 P0** | 唯一验收线（55/55 走通）|
|
||||
| 工作量（排期/人天） | 技术项/能力项 | **≈137** | 人天估算（150 人天，缓冲≈13）|
|
||||
| 实现范围 | Doc B 技术功能 | 经 Doc C 反查 | 不单列，Doc C 即桥 |
|
||||
|
||||
- 历史换算：旧 105(保守口径,废弃) / 131(能力项) → 重划后 ≈137 → **验收改用 55 P0 产品功能**。
|
||||
- 55 P0 按首要 owner 分布：feed13 / studio7 / compliance6 / biz6 / project5 / community5 / aigc3 / runtime3 / trade3 / ad2 / pay1 / telemetry1 / ip0。
|
||||
- 工位：WS1(project+compliance) / WS2(aigc+studio) / WS3(runtime+feed) / WS4(前端承载UI) / WS5(telemetry+ad+trade+pay+community+biz)。studio 归 WS2。
|
||||
- demo 缺口 G1–G7 闭环骨架已并入 MVP（双轨专区/锁风门/统一发布编排/渠道状态机/按Zone分区）；编辑器精修(骨骼/动画/对白)、素材双轨、TapTap 等保持 P1 → MVP 后增量。
|
||||
|
||||
## 四、关键文件影响（同步口径）
|
||||
|
||||
`CLAUDE.md`(头条指标 55/55) · `AGENTS.md`/`README`(指针) · `.agents/knowledge/{mvp-scope-and-milestones,tech-decisions,product-and-architecture,glossary}.md` · `docs/superpowers/specs/2026-06-07-mvp-execution-spec-design.md`(§1.2 验收 + §7 工位映射全表) · `.agents/workflows/mvp-execution-orchestration.md`。模块重划评审依据：`docs/agent-specs/2026-06-07-模块重划分-review.md`（方案 B）。
|
||||
|
||||
## 五、评审结论（3 独立 Opus 评审，已修复）
|
||||
|
||||
0 Critical。独立复核确认：三文档 0 断链/0 孤儿/0 重复ID/0 非法前缀；55 口径全仓一致、owner 分布合计 55；删档零内容丢失零悬挂引用。已修：spec §7 合计校正为 137（补 ip + community 缺项）、glossary 补 4 术语（锁风门/专区Zone/创作会话/资产图）、Doc C 个别 owner/★ 修正。
|
||||
|
||||
## 六、复用要点
|
||||
|
||||
- 写架构/能力文档先分层：需求清单(产品语言) / 模块文档(领域边界,无产品功能) / 映射(RTM) 三分离。
|
||||
- 设计文档「一份即唯一事实」，不做多版本文件；版本走 git，文内记修订日期+摘要。
|
||||
- MVP 范围用**产品功能**作验收单位（用户可感知），技术工作量经 RTM 反查——别把两个单位相加。
|
||||
@ -1,11 +1,11 @@
|
||||
# MVP 总执行 Spec — 10人×3周×131项P0全量交付
|
||||
# MVP 总执行 Spec — 10人×3周（验收 55 项 P0 产品功能 · 工作量≈137 技术项）
|
||||
|
||||
> **文档编号**：HJ-MVP-SPEC-001
|
||||
> **版本**：v1.0
|
||||
> **受众**：全体开发团队 + 产品运营
|
||||
> **生成时间**：2026-06-07
|
||||
> **前置**：系统概要设计-技术决策版、业务能力全景与模块归属
|
||||
> **约束**：10 人团队、3 周（15 个工作日）、131 项 P0 能力全量不砍
|
||||
> **前置**：系统概要设计-技术决策版、产品需求清单(Doc A)/技术架构与模块(Doc B)/需求模块映射(Doc C)
|
||||
> **约束**：10 人团队、3 周（15 个工作日）；**MVP 验收 = Doc A 的 55 项 P0 产品功能**（旧"131 P0 能力项"经 12→13 模块重划后工作量≈137 技术项），核心闭环不砍
|
||||
|
||||
---
|
||||
|
||||
@ -26,7 +26,7 @@
|
||||
|
||||
| 指标 | 标准 |
|
||||
|---|---|
|
||||
| P0 能力覆盖 | 131/131 项全部可用（可验证） |
|
||||
| P0 产品功能覆盖 | 55/55 项 Doc A 的 P0 产品功能全部可用（可验证）|
|
||||
| 端到端链路 | 创作→生成→预览→发布→审核→游戏流→试玩→互动→广告→收益 全走通 |
|
||||
| 生成成功率 | ≥ 80%（基于 3-5 个模板） |
|
||||
| 游戏流首屏 | P75 < 3s |
|
||||
@ -75,7 +75,7 @@
|
||||
|---|---|---|
|
||||
| 1 | Fork yudao-cloud + 本地跑通 + docker-compose.middleware.yml | 全栈中间件可启动 |
|
||||
| 1 | CI/CD pipeline 搭建（GitHub Actions / GitLab CI） | push→lint→test→build 流水线 |
|
||||
| 2 | 创建 12 个 game-module Maven 骨架 + game-server 单体入口 | 编译通过 |
|
||||
| 2 | 创建 13 个 game-module Maven 骨架（含 studio）+ game-server 单体入口 | 编译通过 |
|
||||
| 2 | DB 迁移 V1（project + compliance + telemetry + feed 核心表） | Flyway migrate 成功 |
|
||||
| 3 | project 模块：CRUD + 状态机 + 版本管理 | Swagger 可调 |
|
||||
| 3 | Gateway 路由配置 + CORS + 匿名Token | 前端可调通 API |
|
||||
@ -274,11 +274,13 @@
|
||||
|
||||
---
|
||||
|
||||
## 7. 131 项 P0 能力到工位的映射
|
||||
## 7. P0 工作量到工位的映射（≈137 技术项 · 验收口径见 §1.2 = 55 项 P0 产品功能）
|
||||
|
||||
### WS1 负责（38 项）
|
||||
> 2026-06-07：aigc 16 拆为 **aigc（无状态生成原子）+ studio（创作编排域）**；并入 6 项 demo 缺口"首屏骨架"（专区 Zone 实体 / 发布去向 launchZone / 统一发布编排 → project，锁风门 Gate 二态 → compliance，渠道发布状态机 → runtime，按 Zone 分区推荐 → feed）。下列为**工作量分解**（技术项粒度；各模块标题为口径数，与逐条列举存在历史文案漂移 ±1，仍漂移的模块含 compliance/feed/telemetry/ad/trade，一律以 Doc B 的 T-id 与契约为准）；逐条产品功能↔技术功能映射见 Doc C，验收以 55 项 P0 产品功能为准。
|
||||
|
||||
**project 模块（11 项 P0）**：
|
||||
### WS1 负责（42 项）
|
||||
|
||||
**project 模块（14 项 P0）**：
|
||||
1. 项目 CRUD
|
||||
2. 游戏状态机
|
||||
3. 版本管理
|
||||
@ -290,32 +292,38 @@
|
||||
9. 审核拒绝反馈
|
||||
10. 创作者主页
|
||||
11. 精选池管理 + 下架/封禁
|
||||
12. **专区 Zone 实体与游戏归属（双轨）** ←G1
|
||||
13. **发布去向 launchZone 选择** ←G1
|
||||
14. **统一发布编排（compliance→runtime→feed，失败回滚）** ←G6
|
||||
|
||||
**compliance 模块（27 项 P0）**：
|
||||
文本安全 / 图片安全 / AI 输出风控 / 违禁词库 / 举报处理 / 举报阈值降权 / 人工审核队列 / 审核状态机 / 风险分层 / 操作审计 / 审计长期保存 / 安全日志告警 / RBAC / 游戏沙箱CSP / 文件安全校验 / Prompt 注入防护 / OWASP 防护 / Secrets 管理 / 敏感数据加密 / 数据传输加密 / 日志脱敏 / 登录安全限频 / 匿名用户约束 / CORS+CSP / 隐私政策 / 数据最小化 / 适龄提示 / 用户封禁
|
||||
**compliance 模块（28 项 P0）**：
|
||||
文本安全 / 图片安全 / AI 输出风控 / 违禁词库 / 举报处理 / 举报阈值降权 / 人工审核队列 / 审核状态机 / 风险分层 / 操作审计 / 审计长期保存 / 安全日志告警 / RBAC / 游戏沙箱CSP / 文件安全校验 / Prompt 注入防护 / OWASP 防护 / Secrets 管理 / 敏感数据加密 / 数据传输加密 / 日志脱敏 / 登录安全限频 / 匿名用户约束 / CORS+CSP / 隐私政策 / 数据最小化 / 适龄提示 / 用户封禁 / **锁风门 Gate 二态(pass/block) ←G2**
|
||||
|
||||
### WS2 负责（16 项）
|
||||
### WS2 负责（16 项：studio 6 + aigc 10）
|
||||
|
||||
**aigc 模块（16 项 P0）**：
|
||||
Prompt 解析 / 模板匹配 / GameConfig 生成 / 参数校验兜底 / 异步队列调度 / 任务状态机 / LLM 熔断 / Prompt 安全检测 / 确定性 Fallback / 失败原因分类 / 生成进度展示 / 超时通知 / 模板注册管理 / 风格标签 / 内置素材库 / 示例 Prompt 库
|
||||
**studio 模块（6 项 P0，创作编排，自 aigc 迁出 + demo 缺口）**：
|
||||
创作会话与草稿装配 / 六类资产模块化生成调度 / 附件驱动创作上下文 / agentic 任务链编排 / 生成进度流(SSE) / 重生成迭代编排
|
||||
|
||||
### WS3 负责（35 项 + SDK）
|
||||
**aigc 模块（10 项 P0，无状态生成原子）**：
|
||||
Prompt 解析 / 模板匹配 / GameConfig 生成 / 参数校验兜底 / LLM 熔断 / Prompt 安全检测 / 确定性 Fallback / 失败原因分类 / 模板注册管理 / 示例 Prompt 库
|
||||
|
||||
**runtime 模块（19 项 P0）**：
|
||||
Web 包编译 / Manifest 生成 / 资源打包上传 / Web 沙箱隔离 / SDK 事件桥接 / Canvas 渲染容器 / GameConfig 注入 / 实时预览 / 资源大小限制 / hash 缓存 / 版本化路径 / 预加载策略 / 超时跳过 / 错误捕获上报 / 多端适配 / 竖屏适配 / postMessage 校验 / Manifest 校验 / GameConfig 静态校验
|
||||
### WS3 负责（37 项 + SDK）
|
||||
|
||||
**feed 模块（16 项 P0）**：
|
||||
Feed 推荐列表 / cursor 分页 / 候选集缓存 / 新人保底 / 低质降权 / 冷启动策略 / 上下滑切换 / 点赞 / 收藏 / 分享 / 举报 / 分享链接 / OG 元数据 / 分享落地页 / 行为信号推荐 / 首屏封面展示 / 精选池接口
|
||||
**runtime 模块（20 项 P0）**：
|
||||
Web 包编译 / Manifest 生成 / 资源打包上传 / Web 沙箱隔离 / SDK 事件桥接 / Canvas 渲染容器 / GameConfig 注入 / 实时预览 / 资源大小限制 / hash 缓存 / 版本化路径 / 预加载策略 / 超时跳过 / 错误捕获上报 / 多端适配 / 竖屏适配 / postMessage 校验 / Manifest 校验 / GameConfig 静态校验 / **渠道发布状态机(待开通/申请中/已上线) ←G6**
|
||||
|
||||
**feed 模块（17 项 P0）**：
|
||||
Feed 推荐列表 / cursor 分页 / 候选集缓存 / 新人保底 / 低质降权 / 冷启动策略 / 上下滑切换 / 点赞 / 收藏 / 分享 / 举报 / 分享链接 / OG 元数据 / 分享落地页 / 行为信号推荐 / 首屏封面展示 / 精选池接口 / **按 Zone 分区推荐/浏览 ←G1**
|
||||
|
||||
**SDK**：Core(lifecycle/telemetry/error-track) + Plugin.Ad + Plugin.Pay 桩
|
||||
|
||||
### WS4 负责（前端页面承载所有 P0 的 UI 表现）
|
||||
|
||||
**game-studio**：登录 / 创作工作台（项目列表/资产管理/Prompt/生成状态/组装/预览/发布） / 游戏流（滑动/卡片/互动/分享） / 创作者中心（主页/数据/收益）
|
||||
**game-studio**：登录 / 创作工作台（项目列表/资产管理/Prompt/生成状态/组装/预览/发布/**专区选择**） / 游戏流（滑动/卡片/互动/分享/**双专区**） / 创作者中心（主页/数据/收益）
|
||||
|
||||
**game-admin**：审核队列 / 模板管理 / 精选池 / 数据看板 / 内容安全
|
||||
|
||||
### WS5 负责（41 项）
|
||||
### WS5 负责（42 项）
|
||||
|
||||
**telemetry（16 项 P0）**：事件批量摄取 / Schema 治理 / 前端批量上报 / 质量评分 / 事件聚合 / 创作漏斗 / 消费漏斗 / 运营看板 / 玩家留存 / 创作者复创率 / Product Metrics / 加载时间埋点 / 服务健康监控 / 生成任务健康 / Runtime 健康 / 异常告警 / 失败根因
|
||||
|
||||
@ -325,10 +333,12 @@ Feed 推荐列表 / cursor 分页 / 候选集缓存 / 新人保底 / 低质降
|
||||
|
||||
**pay（3 项 P0）**：积分充值 / 支付网关抽象 / 订单管理
|
||||
|
||||
**community（6 项 P0）**：站内信 / 短信通知 / 生成完成通知 / 审核结果通知 / 收益变动通知
|
||||
**community（6 项 P0）**：站内信 / 短信通知 / 生成完成通知 / 审核结果通知 / 收益变动通知 / 新人任务奖励(T-CMU-11 等级引擎)
|
||||
|
||||
**biz（5 项 P0）**：B 端需求表单 / 模板选择预览 / 进度看板 / 交付验收 / 品牌营销模板
|
||||
|
||||
**ip（1 项 P0）**：素材安全扫描(T-IP-01 版权基础原子；ip 域无 P0 产品功能出口，仅此基础原子计入工作量)
|
||||
|
||||
---
|
||||
|
||||
## 8. 技术约束与规范
|
||||
@ -363,7 +373,7 @@ Feed 推荐列表 / cursor 分页 / 候选集缓存 / 新人保底 / 低质降
|
||||
| 联调期 bug 过多 | 高 | Week 3 前 2 天只联调不加功能；P0 优先 |
|
||||
| 广告联盟审核未通过 | 中 | 先用 mock 广告；真实对接可延到 MVP 后 1 周 |
|
||||
| 某工位进度落后 | 中 | Day 5/Day 10 两次检查点；落后则其他工位支援 |
|
||||
| 3 周内 10 人无法完成 131 项 | 低 | 每项 P0 平均 1 人天；10人×15天=150 人天 > 131 项 |
|
||||
| 3 周内 10 人无法完成 | 低 | 工作量≈137 技术项，每项约 1 人天；10人×15天=150 人天 > 137，留约 13 人天缓冲 |
|
||||
|
||||
---
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user