770 lines
29 KiB
Markdown
770 lines
29 KiB
Markdown
# MVP PRD
|
||
|
||
# 绘境AI生态平台 MVP 版本 PRD
|
||
|
||
### TL;DR
|
||
|
||
绘境AI致力于打造“全民游戏创作与变现生态引擎”，以AI驱动零门槛游戏创作、短视频流式沉浸游玩与一键多渠道分发为核心，形成创作、试玩、传播、变现的生态闭环。MVP阶段聚焦“AI生成轻量游戏原型、游戏流发现与游玩、创作者发布与基础数据反馈”的最小可用集合，优先验证创作者供给、玩家消费和平台冷启动效率。
|
||
|
||
---
|
||
|
||
## Goals
|
||
|
||
### Business Goals
|
||
|
||
- 在MVP上线后8周内验证AI游戏创作平台的供需闭环，完成从创作、发布、游玩到基础数据反馈的核心链路。
|
||
- 获取首批高质量创作者种子用户，目标为500名注册创作者，其中100名完成至少1款游戏发布。
|
||
- 形成可持续的内容供给，目标MVP阶段累计上线300款可试玩AI小游戏，其中30款达到平台推荐标准。
|
||
- 验证游戏流消费模式，目标玩家端7日留存达到15%以上，平均单次会话游玩3款以上游戏。
|
||
- 为后续商业化建立基础，完成广告、内购、打赏或创作者分成等至少1种商业化机制的技术预留和数据埋点。
|
||
|
||
### User Goals
|
||
|
||
- 创作者可以用自然语言、素材上传或模板选择快速生成可玩的轻量游戏，无需专业编程能力。
|
||
- 玩家可以像刷短视频一样发现、试玩、收藏和分享AI生成游戏，降低寻找新游戏的成本。
|
||
- 创作者可以一键发布游戏并获得播放、试玩、完玩、点赞、收藏等基础反馈，指导后续迭代。
|
||
- 平台运营人员可以审核、推荐和管理游戏内容，保障内容安全与基础体验质量。
|
||
- 早期团队可以通过数据看板快速判断哪些游戏类型、创作模板和推荐策略有效。
|
||
|
||
### Non-Goals
|
||
|
||
- MVP不追求完整商业化闭环，不做复杂广告竞价、付费道具商城、创作者结算系统和跨平台收入分账。
|
||
- MVP不支持大型多人在线游戏、复杂3D开放世界、重度实时竞技或高并发同步玩法。
|
||
- MVP不提供完整专业级游戏编辑器能力，例如高级脚本系统、复杂物理引擎编辑、多版本协作和插件市场。
|
||
- MVP不覆盖所有分发渠道，优先支持站内发布和1至2个外部渠道的可验证分发路径。
|
||
|
||
---
|
||
|
||
## User Stories
|
||
|
||
### 创作者：无代码游戏创作者
|
||
|
||
- As a 创作者, I want to 用一句话描述游戏想法, so that 我可以快速生成一个可试玩的小游戏原型。
|
||
- As a 创作者, I want to 选择平台提供的玩法模板, so that 我可以在更稳定的结构下快速完成创作。
|
||
- As a 创作者, I want to 修改角色、关卡、规则和美术风格, so that 游戏更符合我的创意表达。
|
||
- As a 创作者, I want to 预览并反复调试游戏, so that 发布前能发现明显体验问题。
|
||
- As a 创作者, I want to 查看游戏发布后的基础数据, so that 我知道玩家是否喜欢并决定如何迭代。
|
||
|
||
### 玩家：轻量游戏消费者
|
||
|
||
- As a 玩家, I want to 在游戏流中连续浏览和试玩小游戏, so that 我可以快速发现有趣内容。
|
||
- As a 玩家, I want to 点赞、收藏和分享喜欢的游戏, so that 我可以表达偏好并推荐给朋友。
|
||
- As a 玩家, I want to 快速跳过不感兴趣的游戏, so that 我的时间不会被低质量内容浪费。
|
||
- As a 玩家, I want to 看到游戏玩法说明和开始提示, so that 我能在几秒内理解如何玩。
|
||
- As a 玩家, I want to 举报违规或低质内容, so that 平台体验更安全可信。
|
||
|
||
### 平台运营：内容与生态运营人员
|
||
|
||
- As a 运营人员, I want to 查看新发布游戏列表和审核状态, so that 我可以及时处理风险内容。
|
||
- As a 运营人员, I want to 标记推荐、下架或限制曝光的游戏, so that 游戏流内容质量可控。
|
||
- As a 运营人员, I want to 查看创作者与游戏表现数据, so that 我可以识别高潜创作者和优质玩法。
|
||
- As a 运营人员, I want to 配置首页或游戏流的基础推荐规则, so that 冷启动阶段可以人工干预内容质量。
|
||
|
||
### 管理员：平台系统管理员
|
||
|
||
- As a 管理员, I want to 管理用户、权限和内容安全策略, so that 平台可以稳定运营。
|
||
- As a 管理员, I want to 监控生成任务、发布任务和系统异常, so that 我可以快速定位链路故障。
|
||
- As a 管理员, I want to 导出关键运营数据, so that 团队可以进行阶段复盘和投资人汇报。
|
||
|
||
---
|
||
|
||
## Functional Requirements
|
||
|
||
### AI游戏创作工作台（Priority: P0）
|
||
|
||
- 自然语言生成游戏
|
||
|
||
- 支持创作者输入游戏概念、玩法、角色、关卡、风格等描述。
|
||
- 系统基于输入生成轻量小游戏原型，包括基础玩法逻辑、初始关卡、默认素材和操作说明。
|
||
- 生成结果必须可在浏览器内直接预览。
|
||
- 模板化创作入口
|
||
|
||
- MVP优先提供3至5个稳定玩法模板，例如跑酷、躲避、射击、解谜、点击收集。
|
||
- 每个模板支持可配置参数，例如主题、角色、速度、敌人数量、胜负条件、关卡长度。
|
||
- 模板需提供示例Prompt，降低首批创作者的学习成本。
|
||
- 素材与风格配置
|
||
|
||
- 支持创作者选择美术风格标签，例如像素风、卡通风、赛博朋克、童话风、国风。
|
||
- 支持上传少量图片素材作为角色、背景或参考图。
|
||
- 对上传素材进行格式、大小和安全校验。
|
||
- 预览与轻量编辑
|
||
|
||
- 创作者可以在生成完成后立即试玩。
|
||
- 支持修改标题、简介、封面、操作说明、标签和基础参数。
|
||
- 支持重新生成或局部调整，但MVP不做复杂可视化关卡编辑器。
|
||
- 生成任务状态
|
||
|
||
- 展示生成中、生成成功、生成失败、排队中等状态。
|
||
- 生成失败时提供可理解的错误提示和重试入口。
|
||
- 对超时任务进行自动终止并提示用户重新生成。
|
||
|
||
### 游戏发布与管理（Priority: P0）
|
||
|
||
- 站内发布
|
||
|
||
- 创作者确认游戏可玩后可发布到平台游戏流。
|
||
- 发布前必须填写游戏标题、简介、封面、标签和适龄提示。
|
||
- 发布后游戏进入待审核或机器审核通过状态，依据平台策略配置。
|
||
- 游戏版本管理
|
||
|
||
- MVP支持基础版本覆盖，即创作者可以更新当前线上版本。
|
||
- 系统记录发布时间、最近更新时间和当前状态。
|
||
- 暂不支持面向玩家的多版本分流测试。
|
||
- 游戏状态管理
|
||
|
||
- 支持草稿、待审核、已发布、审核拒绝、已下架等状态。
|
||
- 创作者可以查看每个状态的说明和下一步操作。
|
||
- 运营可以对违规或严重低质游戏进行下架。
|
||
- 分享能力
|
||
|
||
- 每款已发布游戏生成独立分享链接。
|
||
- 分享页支持游戏封面、标题、简介和立即游玩入口。
|
||
- 分享链接需可用于社群传播和外部渠道测试。
|
||
|
||
### 游戏流与玩家体验（Priority: P0）
|
||
|
||
- 游戏流浏览
|
||
|
||
- 玩家进入首页后默认进入连续游戏流。
|
||
- 支持上下滑或点击切换下一款游戏。
|
||
- 每款游戏需在短时间内加载并展示基础玩法说明。
|
||
- 即点即玩
|
||
|
||
- 玩家无需下载即可在Web环境直接试玩。
|
||
- 游戏加载前展示封面、进度和跳过入口。
|
||
- 游戏无法加载时自动切换下一款，并记录错误。
|
||
- 互动反馈
|
||
|
||
- 支持点赞、收藏、分享和举报。
|
||
- 支持简单评论可作为P1能力，MVP可先通过反馈按钮替代。
|
||
- 玩家行为用于推荐和内容质量评估。
|
||
- 基础推荐
|
||
|
||
- MVP采用规则推荐和简单行为信号结合。
|
||
- 冷启动优先展示运营精选、最新发布和高互动游戏。
|
||
- 对高跳出、加载失败、举报高的游戏降低曝光。
|
||
|
||
### 创作者数据看板（Priority: P1）
|
||
|
||
- 单游戏数据概览
|
||
|
||
- 展示曝光次数、点击/进入次数、试玩次数、平均游玩时长、点赞、收藏、分享、举报。
|
||
- 展示近7天趋势，帮助创作者理解内容表现。
|
||
- 创作者主页
|
||
|
||
- 展示创作者已发布游戏列表。
|
||
- 展示总播放、总互动和代表作品。
|
||
- MVP可先做公开主页的简化版本。
|
||
- 数据反馈建议
|
||
|
||
- 根据基础数据提供简单提示，例如“封面点击率较低，建议优化标题和封面”。
|
||
- 该能力作为P1，可在数据积累后增强。
|
||
|
||
### 内容审核与运营后台（Priority: P0）
|
||
|
||
- 审核队列
|
||
|
||
- 展示待审核游戏的标题、封面、简介、创作者、标签、生成时间。
|
||
- 运营可以试玩游戏并查看AI生成描述。
|
||
- 支持通过、拒绝、下架和备注。
|
||
- 内容安全检测
|
||
|
||
- 对文本输入、游戏标题、简介、封面和上传素材进行基础安全检测。
|
||
- 风险内容进入人工审核。
|
||
- 对明显违规内容进行自动拒绝并提示原因。
|
||
- 推荐管理
|
||
|
||
- 运营可以将游戏加入精选池。
|
||
- 支持按标签、发布时间、互动数据筛选游戏。
|
||
- MVP不做复杂推荐策略后台，只提供必要人工干预入口。
|
||
|
||
### 账号与权限（Priority: P0）
|
||
|
||
- 用户登录
|
||
|
||
- 支持手机号、邮箱或第三方登录中的至少一种。
|
||
- 玩家可匿名试玩，但点赞、收藏、发布和举报需要登录。
|
||
- 角色权限
|
||
|
||
- 支持玩家、创作者、运营、管理员四类基础角色。
|
||
- 不同角色访问不同页面与操作权限。
|
||
- 用户资料
|
||
|
||
- 支持昵称、头像、简介等基础信息。
|
||
- 创作者需有唯一主页标识。
|
||
|
||
### 外部分发验证（Priority: P1）
|
||
|
||
- 分享页适配
|
||
|
||
- 分享页适配移动端社交平台内置浏览器。
|
||
- 分享卡片包含封面、标题和简介。
|
||
- 渠道参数
|
||
|
||
- 分享链接支持渠道参数，用于识别来源。
|
||
- 数据看板可按渠道粗略区分访问与试玩表现。
|
||
- 自动多渠道发布预留
|
||
|
||
- MVP阶段不实现复杂多渠道自动发布。
|
||
- 需预留游戏包导出、渠道元数据和审核状态字段。
|
||
|
||
---
|
||
|
||
## User Experience
|
||
|
||
### Entry Point & First-Time User Experience
|
||
|
||
- 创作者首次访问平台时，通过首页“开始创作”进入创作工作台。
|
||
- 系统提供两种创作路径：一句话生成和选择模板开始。
|
||
- 首次使用时展示简短引导：
|
||
|
||
- 说明AI可以生成什么类型的游戏。
|
||
- 给出3个可直接点击的示例Prompt。
|
||
- 提醒用户MVP更适合轻量小游戏，不适合复杂大型游戏。
|
||
- 玩家首次访问平台时进入游戏流，可无需登录试玩。
|
||
- 玩家在触发点赞、收藏、发布评论或举报时，引导登录。
|
||
- 运营人员通过独立后台入口登录，进入审核和推荐管理页面。
|
||
|
||
### Core Experience
|
||
|
||
Step 1：创作者发起游戏创作
|
||
|
||
- 用户点击“开始创作”。
|
||
- 页面展示输入框、玩法模板、风格选择和示例Prompt。
|
||
- 用户可以输入：“做一个像素风太空躲避游戏，玩家控制飞船躲避陨石，收集能量块，坚持60秒获胜。”
|
||
- 系统进行输入校验：
|
||
|
||
- 文本不能为空。
|
||
- 超出长度时提示压缩描述。
|
||
- 命中安全风险时提示修改。
|
||
- 成功后进入生成任务页。
|
||
|
||
Step 2：AI生成并展示任务状态
|
||
|
||
- 系统展示生成进度，例如“正在理解玩法”“正在生成关卡”“正在打包预览”。
|
||
- 生成时间过长时展示预计等待提示和后台通知选项。
|
||
- 生成成功后自动进入预览页。
|
||
- 生成失败时展示失败原因分类：
|
||
|
||
- 输入描述不清晰。
|
||
- 内容不符合安全要求。
|
||
- 系统繁忙或生成超时。
|
||
- 用户可以一键重试或返回修改Prompt。
|
||
|
||
Step 3：创作者预览与调整
|
||
|
||
- 预览页左侧展示可玩游戏区域，右侧展示基础信息编辑区。
|
||
- 用户可以立即试玩并检查游戏是否符合预期。
|
||
- 用户可以调整：
|
||
|
||
- 游戏标题。
|
||
- 游戏简介。
|
||
- 封面图。
|
||
- 标签。
|
||
- 操作说明。
|
||
- 模板参数。
|
||
- 用户可以选择“重新生成”或“保存草稿”。
|
||
- 保存草稿后可在个人工作台继续编辑。
|
||
|
||
Step 4：创作者发布游戏
|
||
|
||
- 用户点击“发布”。
|
||
- 系统展示发布前检查清单：
|
||
|
||
- 是否可正常加载。
|
||
- 是否填写标题与简介。
|
||
- 是否设置封面与标签。
|
||
- 是否通过基础内容安全检测。
|
||
- 检查通过后提交审核或直接发布。
|
||
- 发布成功后展示：
|
||
|
||
- 游戏详情页链接。
|
||
- 分享按钮。
|
||
- 查看数据入口。
|
||
|
||
Step 5：玩家在游戏流中发现游戏
|
||
|
||
- 玩家打开首页后进入全屏或半全屏游戏流。
|
||
- 第一屏展示游戏封面、标题、创作者、玩法说明和“开始玩”按钮。
|
||
- 游戏自动预加载，减少等待时间。
|
||
- 玩家可以：
|
||
|
||
- 点击开始。
|
||
- 上滑跳过。
|
||
- 点赞。
|
||
- 收藏。
|
||
- 分享。
|
||
- 举报。
|
||
- 系统根据停留时长、试玩完成度和互动行为更新推荐信号。
|
||
|
||
Step 6：玩家试玩与反馈
|
||
|
||
- 玩家进入游戏后，界面提供最小必要操作提示。
|
||
- 游戏结束后展示结果页：
|
||
|
||
- 分数或通关结果。
|
||
- 再玩一次。
|
||
- 点赞收藏。
|
||
- 分享给好友。
|
||
- 继续下一个游戏。
|
||
- 若游戏加载失败或运行报错：
|
||
|
||
- 展示轻量错误提示。
|
||
- 提供跳过到下一款。
|
||
- 后台记录错误日志并降低该游戏曝光。
|
||
|
||
Step 7：创作者查看数据并迭代
|
||
|
||
- 创作者进入“我的游戏”。
|
||
- 每款游戏展示基础数据卡片。
|
||
- 用户点击某款游戏进入详情数据页。
|
||
- 数据页展示近7天表现和关键漏斗：
|
||
|
||
- 曝光。
|
||
- 进入。
|
||
- 开始试玩。
|
||
- 游玩超过30秒。
|
||
- 点赞或收藏。
|
||
- 系统提供简单诊断建议。
|
||
- 创作者可点击“编辑并更新”进入创作工作台。
|
||
|
||
### Advanced Features & Edge Cases
|
||
|
||
- 生成内容与用户预期不一致
|
||
|
||
- 提供“我想调整”入口，引导用户补充更明确描述。
|
||
- 保留原Prompt与修改记录，便于后续优化模型。
|
||
- 游戏运行失败
|
||
|
||
- 前端捕获加载和运行错误。
|
||
- 玩家侧自动降级为封面页并提供跳过。
|
||
- 创作者侧提示“该游戏存在运行异常，建议重新生成或修改参数”。
|
||
- 低质量或重复内容
|
||
|
||
- 对重复标题、重复素材和重复Prompt进行基础识别。
|
||
- 对低互动且高跳出的内容降低推荐权重。
|
||
- 运营可将明显低质内容从推荐池移除。
|
||
- 违规内容
|
||
|
||
- 文本、图片、玩法描述和用户资料均需经过安全检测。
|
||
- 高风险内容进入人工审核。
|
||
- 严重违规用户可被限制发布。
|
||
- 未登录用户
|
||
|
||
- 可浏览和试玩。
|
||
- 尝试点赞、收藏、举报或创作时触发登录。
|
||
- 登录后回到原操作上下文。
|
||
- 移动端性能不足
|
||
|
||
- 对游戏资源大小设置上限。
|
||
- 加载超时后自动跳过。
|
||
- 对低端设备启用低画质或低帧率模式。
|
||
|
||
### UI/UX Highlights
|
||
|
||
- 创作入口要明显，首屏突出“一句话生成游戏”。
|
||
- Prompt输入区域应提供示例，减少空白输入焦虑。
|
||
- 游戏流体验需接近短视频产品，强调连续消费、低决策成本和快速反馈。
|
||
- 游戏加载等待需有明确反馈，避免用户误以为页面卡死。
|
||
- 创作者后台应以卡片化呈现，突出发布状态和关键数据。
|
||
- 审核后台优先保障效率，列表、筛选、试玩、处理动作应在同一工作流内完成。
|
||
- 移动端为优先体验，桌面端需兼容创作工作台和后台管理。
|
||
- 所有关键按钮需具备明确状态，包括可用、不可用、加载中、失败重试。
|
||
- 可访问性要求：
|
||
|
||
- 文本与背景对比度满足基础可读性。
|
||
- 核心操作支持键盘访问。
|
||
- 错误提示不能只依赖颜色表达。
|
||
|
||
---
|
||
|
||
## Narrative
|
||
|
||
小林是一名喜欢游戏和短视频的大学生，经常有很多有趣的游戏点子，但他不会写代码，也没有美术资源。过去，他最多只能把想法写在社交平台上，真正做成可玩的游戏几乎不可能。
|
||
|
||
在绘境AI中，小林输入一句话：“做一个国风跑酷游戏，玩家操控小狐狸穿过竹林，收集灵石并躲避机关。”几分钟后，系统生成了一个可试玩的小游戏。小林试玩后发现节奏有点慢，于是调整速度和障碍数量，重新生成后发布到平台。游戏进入游戏流后，玩家像刷短视频一样快速试玩，有人点赞、收藏，也有人分享到社群。
|
||
|
||
第二天，小林在创作者后台看到这款游戏获得了不错的完玩率，但封面点击率一般。平台建议他优化标题和封面，他更新后数据进一步提升。对于玩家而言，他们获得了源源不断的新鲜小游戏；对于创作者而言，创意第一次可以低成本变成作品；对于平台而言，内容供给、消费和反馈形成了早期生态闭环，为后续分发和商业化奠定基础。
|
||
|
||
---
|
||
|
||
## Success Metrics
|
||
|
||
### User-Centric Metrics
|
||
|
||
- 创作者激活率
|
||
|
||
- 定义：注册创作者中完成首次生成任务的比例。
|
||
- MVP目标：不低于40%。
|
||
- 首次发布转化率
|
||
|
||
- 定义：完成首次生成的创作者中，至少发布1款游戏的比例。
|
||
- MVP目标：不低于25%。
|
||
- 玩家7日留存率
|
||
|
||
- 定义：首日试玩过游戏的玩家，在第7天仍有访问或试玩行为的比例。
|
||
- MVP目标：不低于15%。
|
||
- 单次会话试玩游戏数
|
||
|
||
- 定义：玩家每次访问平均试玩的游戏数量。
|
||
- MVP目标：不低于3款。
|
||
- 游戏互动率
|
||
|
||
- 定义：点赞、收藏、分享等互动次数除以试玩次数。
|
||
- MVP目标：不低于8%。
|
||
|
||
### Business Metrics
|
||
|
||
- 创作者规模
|
||
|
||
- MVP上线8周内获得500名注册创作者。
|
||
- 内容供给规模
|
||
|
||
- MVP上线8周内累计发布300款可试玩游戏。
|
||
- 优质内容占比
|
||
|
||
- 定义：达到平台推荐标准的游戏数除以已发布游戏数。
|
||
- MVP目标：不低于10%。
|
||
- 外部分发贡献
|
||
|
||
- 定义：来自分享链接或外部渠道的访问占比。
|
||
- MVP目标：不低于20%。
|
||
|
||
### Technical Metrics
|
||
|
||
- 游戏生成成功率
|
||
|
||
- 定义：生成任务成功完成并可预览的比例。
|
||
- MVP目标：不低于85%。
|
||
- 游戏首屏加载时间
|
||
|
||
- 定义：玩家进入游戏详情或游戏流后可开始互动的时间。
|
||
- MVP目标：P75低于3秒，P95低于6秒。
|
||
- 游戏运行错误率
|
||
|
||
- 定义：游戏加载或运行中出现阻断性错误的次数除以试玩次数。
|
||
- MVP目标：低于3%。
|
||
- 平台可用性
|
||
|
||
- 定义：核心链路服务可用时间占比。
|
||
- MVP目标：不低于99%。
|
||
|
||
### Tracking Plan
|
||
|
||
- 用户事件
|
||
|
||
- `user_signup`
|
||
- `user_login`
|
||
- `creator_onboarding_start`
|
||
- `creator_onboarding_complete`
|
||
- 创作事件
|
||
|
||
- `prompt_submit`
|
||
- `template_select`
|
||
- `generation_start`
|
||
- `generation_success`
|
||
- `generation_failed`
|
||
- `game_preview_start`
|
||
- `draft_save`
|
||
- `game_publish_submit`
|
||
- `game_publish_success`
|
||
- 玩家事件
|
||
|
||
- `feed_view`
|
||
- `game_impression`
|
||
- `game_load_start`
|
||
- `game_load_success`
|
||
- `game_load_failed`
|
||
- `game_play_start`
|
||
- `game_play_30s`
|
||
- `game_complete`
|
||
- `game_skip`
|
||
- `game_like`
|
||
- `game_favorite`
|
||
- `game_share`
|
||
- `game_report`
|
||
- 运营事件
|
||
|
||
- `review_queue_view`
|
||
- `game_review_approve`
|
||
- `game_review_reject`
|
||
- `game_unpublish`
|
||
- `game_feature_add`
|
||
- `game_feature_remove`
|
||
- 渠道与转化事件
|
||
|
||
- `share_link_open`
|
||
- `external_channel_visit`
|
||
- `visitor_to_player_convert`
|
||
- `player_to_creator_convert`
|
||
|
||
---
|
||
|
||
## Technical Considerations
|
||
|
||
### Technical Needs
|
||
|
||
- AI生成服务
|
||
|
||
- 负责解析用户Prompt、选择或组合玩法模板、生成配置和素材描述。
|
||
- 需要任务队列支持异步生成。
|
||
- 需要生成失败重试和超时处理机制。
|
||
- 游戏运行容器
|
||
|
||
- 支持在Web环境中运行轻量小游戏。
|
||
- 对资源大小、运行时权限和脚本能力进行限制。
|
||
- 提供统一的生命周期事件，例如加载、开始、暂停、结束、报错。
|
||
- 创作工作台前端
|
||
|
||
- 包含Prompt输入、模板选择、风格配置、生成状态、预览和发布流程。
|
||
- 需要兼容桌面端优先的编辑体验，同时保留移动端基础可用性。
|
||
- 玩家端游戏流
|
||
|
||
- 包含游戏推荐列表、预加载、滑动切换、互动反馈和分享。
|
||
- 需要针对移动端体验进行性能优化。
|
||
- 运营后台
|
||
|
||
- 包含审核队列、内容详情、试玩预览、推荐管理和下架能力。
|
||
- 权限控制必须清晰，避免普通用户访问后台接口。
|
||
- 数据分析系统
|
||
|
||
- 统一埋点采集创作、发布、试玩、互动和审核事件。
|
||
- 支持基础漏斗、留存、内容表现和渠道分析。
|
||
|
||
### Integration Points
|
||
|
||
- 用户认证系统
|
||
|
||
- 支持登录、注册、匿名用户识别和角色权限。
|
||
- 内容安全服务
|
||
|
||
- 用于文本、图片、用户资料和游戏描述的安全检测。
|
||
- 文件与素材存储
|
||
|
||
- 存储封面、上传素材、生成素材和游戏包资源。
|
||
- 消息与通知服务
|
||
|
||
- 用于生成完成、审核结果和发布状态通知。
|
||
- 外部分享平台
|
||
|
||
- 支持常见社交渠道的链接预览和分享卡片配置。
|
||
- 数据分析工具
|
||
|
||
- 对接事件采集、看板和导出能力。
|
||
|
||
### Data Storage & Privacy
|
||
|
||
- 核心数据对象
|
||
|
||
- User：用户ID、昵称、头像、角色、注册时间、状态。
|
||
- CreatorProfile：创作者主页信息、简介、代表作品。
|
||
- Game：游戏ID、标题、简介、封面、标签、作者、状态、版本、发布时间。
|
||
- GameBuild：生成配置、资源地址、运行入口、生成状态、错误信息。
|
||
- PromptRecord：用户输入、模板、风格参数、安全检测结果。
|
||
- Interaction：点赞、收藏、分享、举报、试玩行为。
|
||
- ReviewRecord：审核人、审核结果、原因、备注、处理时间。
|
||
- 数据隐私
|
||
|
||
- 用户输入Prompt和上传素材需明确用于生成游戏和改善体验。
|
||
- 若后续用于模型训练，应提供清晰授权选项。
|
||
- 用户可删除草稿和下架已发布游戏。
|
||
- 对未成年人、敏感内容和版权素材需设置更严格策略。
|
||
- 数据安全
|
||
|
||
- 上传文件需做类型校验、大小限制和恶意内容扫描。
|
||
- 游戏运行环境需沙箱隔离，避免执行危险脚本。
|
||
- 后台接口需鉴权并记录关键操作日志。
|
||
|
||
### Scalability & Performance
|
||
|
||
- MVP容量假设
|
||
|
||
- 日活玩家：1,000至5,000。
|
||
- 日活创作者：100至500。
|
||
- 日生成任务：300至1,000。
|
||
- 日试玩次数：10,000至50,000。
|
||
- 性能要求
|
||
|
||
- 游戏流首屏应优先加载封面和元数据，再预加载游戏资源。
|
||
- 生成任务采用异步队列，避免阻塞用户界面。
|
||
- 热门游戏资源需要缓存和CDN加速。
|
||
- 埋点上报应异步处理，不影响游戏运行。
|
||
- 扩展策略
|
||
|
||
- 生成服务、运行服务、推荐服务和数据服务应保持模块化边界。
|
||
- 游戏模板与生成配置应可扩展，便于后续新增玩法类型。
|
||
- 推荐策略先规则化，后续可逐步引入个性化模型。
|
||
|
||
### Potential Challenges
|
||
|
||
- AI生成质量不稳定
|
||
|
||
- 风险：用户输入自由度高，生成结果可能不可玩或不符合预期。
|
||
- 应对：MVP优先采用模板约束，确保基础可玩性。
|
||
- 内容安全与版权风险
|
||
|
||
- 风险：用户可能输入违规内容或上传侵权素材。
|
||
- 应对：引入文本与图片安全检测，发布前设置审核流程。
|
||
- 游戏流留存不足
|
||
|
||
- 风险：AI生成内容早期质量参差不齐，玩家可能快速流失。
|
||
- 应对：运营精选池、质量阈值和冷启动推荐规则必须优先实现。
|
||
- 移动端性能压力
|
||
|
||
- 风险：部分生成游戏资源过大或运行效率低。
|
||
- 应对：限制资源体积、统一运行容器、监控加载和错误率。
|
||
- 创作者学习成本
|
||
|
||
- 风险：用户不知道如何描述游戏，首次生成失败后放弃。
|
||
- 应对：提供模板、示例Prompt和失败后的修改建议。
|
||
|
||
---
|
||
|
||
## Milestones & Sequencing
|
||
|
||
### Project Estimate
|
||
|
||
- 项目规模：Medium
|
||
- 建议周期：4至6周完成MVP可上线版本
|
||
- 交付原则：先跑通端到端闭环，再优化生成质量和推荐效率
|
||
|
||
### Team Size & Composition
|
||
|
||
建议采用小而快的启动团队，避免过早组织复杂化。
|
||
|
||
- 产品负责人：1人
|
||
|
||
- 负责PRD、范围控制、数据指标、验收标准和跨角色协调。
|
||
- 全栈工程师：2人
|
||
|
||
- 负责创作工作台、玩家端、后端接口、任务队列、数据模型和基础后台。
|
||
- AI/生成工程师：1人
|
||
|
||
- 负责Prompt解析、模板生成、生成任务稳定性和质量评估。
|
||
- 设计师：0.5至1人
|
||
|
||
- 负责核心流程、移动端游戏流、创作工作台和后台基础UI。
|
||
- 运营/内容审核：0.5至1人
|
||
|
||
- 负责种子创作者招募、审核规则、精选池和上线冷启动。
|
||
|
||
总计：4至5名核心成员，可通过兼职设计和运营支持保持轻量。
|
||
|
||
### Suggested Phases
|
||
|
||
Phase 1：范围冻结与原型验证（3至5天）
|
||
|
||
- Key Deliverables
|
||
|
||
- 产品负责人输出MVP范围、核心用户路径和验收标准。
|
||
- 设计师完成创作工作台、游戏流、发布流程和审核后台低保真原型。
|
||
- 工程团队确认游戏运行容器、生成任务队列和数据模型方案。
|
||
- Dependencies
|
||
|
||
- 明确首批支持的玩法模板。
|
||
- 明确内容安全底线和审核规则。
|
||
|
||
Phase 2：端到端核心链路开发（2周）
|
||
|
||
- Key Deliverables
|
||
|
||
- 全栈工程师完成账号、创作工作台、生成任务、预览、发布和游戏详情页。
|
||
- AI/生成工程师完成3个稳定玩法模板和Prompt到配置的生成链路。
|
||
- 工程团队完成游戏运行容器基础事件和错误日志。
|
||
- 运营后台完成待审核列表、审核通过、拒绝和下架。
|
||
- Dependencies
|
||
|
||
- 玩法模板配置格式确定。
|
||
- 素材存储和资源加载方案确定。
|
||
|
||
Phase 3：游戏流、数据埋点与冷启动运营（1至2周）
|
||
|
||
- Key Deliverables
|
||
|
||
- 全栈工程师完成游戏流、点赞、收藏、分享、举报和基础推荐规则。
|
||
- 数据埋点覆盖创作、发布、试玩、互动和审核事件。
|
||
- 创作者数据看板完成曝光、试玩、互动等基础指标。
|
||
- 运营建立首批精选池和种子创作者名单。
|
||
- Dependencies
|
||
|
||
- 核心埋点口径确认。
|
||
- 首批测试内容准备完成。
|
||
|
||
Phase 4：质量优化与灰度上线（1周）
|
||
|
||
- Key Deliverables
|
||
|
||
- 修复生成失败、加载失败、运行错误和审核流程问题。
|
||
- 优化移动端加载性能和首屏体验。
|
||
- 完成基础安全测试和权限检查。
|
||
- 面向小范围创作者和玩家灰度发布。
|
||
- Dependencies
|
||
|
||
- 灰度用户名单准备完成。
|
||
- 运营反馈通道建立。
|
||
|
||
Phase 5：MVP复盘与下一阶段决策（2至3天）
|
||
|
||
- Key Deliverables
|
||
|
||
- 输出MVP数据复盘，包括创作者激活、游戏发布、玩家留存、内容质量和技术稳定性。
|
||
- 确定下一阶段优先级：增强编辑器、推荐算法、商业化、外部分发或创作者激励。
|
||
- 梳理高频失败Prompt、热门玩法类型和优质创作者画像。
|
||
- Dependencies
|
||
|
||
- 至少积累1至2周真实用户数据。
|
||
|
||
---
|
||
|
||
## MVP Acceptance Criteria
|
||
|
||
### 创作链路验收
|
||
|
||
- 用户可以从Prompt或模板生成至少3类轻量游戏。
|
||
- 生成成功后可以直接在浏览器中预览和试玩。
|
||
- 用户可以编辑标题、简介、封面、标签和操作说明。
|
||
- 用户可以保存草稿并发布游戏。
|
||
- 生成失败时有明确提示和重试入口。
|
||
|
||
### 玩家链路验收
|
||
|
||
- 玩家可以进入游戏流连续浏览游戏。
|
||
- 玩家可以无需下载直接试玩游戏。
|
||
- 玩家可以点赞、收藏、分享和举报。
|
||
- 加载失败时可跳过，且系统记录错误。
|
||
- 移动端核心体验可用。
|
||
|
||
### 运营链路验收
|
||
|
||
- 运营可以查看待审核游戏。
|
||
- 运营可以试玩、通过、拒绝和下架游戏。
|
||
- 运营可以将游戏加入精选池。
|
||
- 管理员可以区分普通用户、创作者、运营和管理员权限。
|
||
|
||
### 数据链路验收
|
||
|
||
- 核心事件成功上报，包括生成、发布、曝光、试玩、互动和审核。
|
||
- 创作者可以查看单游戏基础表现。
|
||
- 团队可以导出或查看MVP核心指标。
|
||
|
||
---
|
||
|
||
## Open Questions
|
||
|
||
- MVP首发应优先面向移动Web、桌面Web，还是两者同时支持？建议玩家端移动优先，创作端桌面优先。
|
||
- AI生成游戏的底层实现采用模板配置生成、代码生成，还是二者结合？建议MVP优先模板配置生成，以保障稳定性。
|
||
- 发布审核策略是先审后发还是先发后审？建议早期采用机器检测加人工精选，普通公开曝光前进入审核。
|
||
- 是否允许用户上传自有素材？建议MVP允许小规模上传，但必须限制格式、大小和安全检测。
|
||
- 创作者激励机制是否在MVP上线？建议先用曝光、榜单和精选作为非现金激励，暂不做结算。
|
||
|
||
---
|
||
|
||
## Future Considerations
|
||
|
||
- 更强的可视化编辑器，包括关卡编辑、角色行为编辑和规则编辑。
|
||
- 个性化推荐系统，根据玩家偏好推荐游戏类型和创作者。
|
||
- 创作者分成体系，包括广告分成、打赏、付费模板和游戏内购。
|
||
- 多渠道自动发布，包括小游戏平台、社交平台和嵌入式试玩广告。
|
||
- 创作者社区，包括教程、挑战赛、素材市场和协作创作。
|
||
- AI助手增强，包括自动诊断游戏体验问题、生成优化建议和自动制作宣传素材。
|