games-development-ai/docs/architecture/产品/README.md

产品域 · 设计主文档

这是什么：绘境AI 产品域的设计主文档,回答"产品对用户提供什么"(WHAT),不涉及"用什么技术实现"(HOW——那部分在架构域)。 给谁看:产品经理、新加入的同事、外部评审、投资人尽调。 怎么读:先读本页建立全局认知,再按需深入文末的三份子文档。

---

1. 一句话与一张图:绘境AI 是什么

绘境AI 是一个面向大众的 AI 游戏创作与变现平台。它把三件过去彼此割裂的事——做得出游戏、有人来玩、能赚到钱——接成一条完整的闭环。

一个没有任何编程基础的普通人,可以从一句话出发,做出一款能上线、能变现的轻量小游戏;玩家在类似短视频的"游戏信息流"里刷到它、即点即玩;平台则通过广告、订阅会员、B 端定制三条线变现。

竞品大多停在"生成工具"这一步——做完没人玩、也不赚钱。绘境AI 的差异化在于把"生成 + 流量 + 变现"串成一条链,这条闭环就是所有产品功能挂靠的主干:

flowchart LR
  A["创作者<br/>一句话 / 选模板"] --> B["AI 生成<br/>可试玩游戏"]
  B --> C["预览 & 迭代"]
  C --> D["多渠道发布"]
  D --> E["游戏信息流<br/>即刷即玩"]
  E --> F["玩家互动<br/>点赞 / 分享 / 评论"]
  F --> G["广告 / 内购 / 订阅<br/>变现"]
  G --> H["收益 & 行为数据"]
  H --> A
  H -. "行为数据 → 推荐优化" .-> E

闭环里的每一环都对应一组产品功能:创作(创作者侧)→ 分发与游玩(玩家侧)→ 变现与数据(双方)。数据回流又反哺推荐,让好游戏被更多人刷到——这是平台越用越聪明的来源。

---

2. 产品全貌:19 个产品域

产品功能按"用户能感知的能力"聚成 19 个产品域。为便于把握,可以再归成五大块:

flowchart TB
  subgraph 创作侧["创作侧 — 把游戏做出来"]
    MAT[素材中心] --- TPL[玩法模板] --- CRT[自定义创作]
    LIC[授权 IP 创作] --- PUB[发布分发]
  end
  subgraph 玩家侧["玩家侧 — 让游戏被玩到"]
    PLZ[游戏广场] --- FED[游戏信息流] --- SOC[社区互动]
  end
  subgraph 变现侧["变现侧 — 把钱赚回来"]
    WAL[创作者钱包] --- PAY[付费变现] --- ADV[广告变现]
  end
  subgraph 成长侧["成长侧 — 让创作者留下来"]
    OPS[数据经营] --- GRW[创作者成长] --- INC[创作者激励] --- NTF[消息通知]
  end
  subgraph 平台侧["平台侧 — 让生态转起来"]
    IPX[IP 孵化与版权] --- BIZ[B 端定制] --- OPN[运营管理] --- ACC[账号与合规]
  end

• 创作侧:从挑素材、选玩法模板,到一句话自定义生成,再到基于授权 IP(如知名形象)创作,最后一键发布到多个渠道。
• 玩家侧:游戏广场按专区浏览,游戏信息流竖屏即刷即玩,再加上评论、关注、排行榜等社区互动。
• 变现侧:创作者钱包收益与提现、面向用户的付费(充值/会员/内购)、以及广告(激励视频/插屏等)。
• 成长侧:让创作者看到数据、得到诊断与激励、收到关键通知,从而持续留下来创作。
• 平台侧:IP 孵化与版权交易、B 端定制业务、运营审核管理,以及账号与合规告知。

---

3. 怎么读懂一条需求(术语先解释)

需求清单里每一行是一条产品功能,带四个属性。第一次接触的人只需记住:

• 编号 P-{域}-{序号}:例如 P-CRT-01 表示"自定义创作"域的第 1 条需求。域用三字母缩写(MAT 素材、TPL 模板、CRT 创作……)。
• 端:这条功能服务谁——创作者、玩家、经营(创作者查看自己作品的数据)、运营(平台管理员)、B端(企业客户)、或通用。
• 优先级:P0 = MVP 阶段必须验收的功能(全部 158 条里有 55 条 P0);P1 / P2 = 后续迭代。另有一档 P0-lite(创作者基础播放数据 P-OPS-01),是供给侧留存断点的轻量必做,独立于 55 P0 头号口径。
• 来源:demo = 早期原型演示里出现过;v2.0 = 延续既有能力;G# = demo 暴露出的缺口编号。

---

4. MVP 的边界:158 选 55

完整产品有 158 条需求(2026-06-22 历史回收补登 3 条入口/账号面后,从 155 升到 158),分布在 19 个域。MVP 阶段不全做,而是聚焦其中 55 条 P0——它们刚好串起一条"种子用户可试用的全链路":创建 → 生成 → 预览 → 发布 → 信息流 → 游玩 → 互动 → 广告 → 收益。

flowchart LR
  P158["158 条产品需求<br/>(完整产品)"] --> P55["55 条 P0<br/>(MVP 验收口径)"]
  P55 --> LOOP["覆盖全链路闭环<br/>create → play → earn"]

换句话说:MVP 不追求功能多,而追求这条闭环每一环都能真实跑通。P1/P2 是闭环跑通之后的加厚。

---

5. 子文档导航

文档	回答什么
需求清单	完整的 158 条产品需求,按 19 个域逐条列出
需求模块映射	每条产品需求由哪些技术模块实现(连接架构域)
护城河话术	对外融资沟通时,产品与商业层面的统一口径

纪律:产品域只讲"用户能感知什么";一条需求由哪些技术功能实现,记在需求模块映射里,技术功能本身的设计在架构域。三者各司其职、互不重复。