Merge remote-tracking branch 'origin/master' into hermes/hermes-1e775b03
# Conflicts: # server-rs/crates/api-server/src/app.rs # server-rs/crates/api-server/src/creation_entry_config.rs # server-rs/crates/api-server/src/puzzle.rs # server-rs/crates/spacetime-client/src/lib.rs # src/components/platform-entry/PlatformEntryFlowShellImpl.tsx
This commit is contained in:
@@ -394,7 +394,7 @@ MVP 阶段不需要单独设置密码。
|
||||
|
||||
落地规则:
|
||||
|
||||
- 入参只允许 `phone` 和 `password`,不支持邮箱、用户名或百梦号。
|
||||
- 入参只允许 `phone` 和 `password`,不支持邮箱、用户名或陶泥号。
|
||||
- 手机号不存在时,不创建账号,返回统一的登录失败。
|
||||
- 手机号存在但账号未设置过密码时,不允许密码登录。
|
||||
- 首次设置密码只能在已登录账号中心内完成;用户必须先通过手机号验证码或已绑定手机号的微信账号进入已登录态。
|
||||
@@ -734,7 +734,7 @@ MVP 阶段建议至少提供一个轻量账号中心,包含:
|
||||
|
||||
约束:
|
||||
|
||||
- 不支持邮箱、用户名或百梦号。
|
||||
- 不支持邮箱、用户名或陶泥号。
|
||||
- 不承担注册能力。
|
||||
- 只有已存在、已验证手机号、且 `passwordLoginEnabled=true` 的账号可以登录。
|
||||
|
||||
|
||||
@@ -55,7 +55,7 @@
|
||||
- 调用 `POST /admin/api/profile/redeem-codes` 创建/更新兑换码。
|
||||
- 调用 `POST /admin/api/profile/redeem-codes/disable` 停用兑换码。
|
||||
- 支持 `public`、`unique`、`private` 三种模式。
|
||||
- 私有码支持输入内部 `userId` 和公开百梦号,提交给后端统一解析。
|
||||
- 私有码支持输入内部 `userId` 和公开陶泥号,提交给后端统一解析。
|
||||
7. 邀请码管理页:
|
||||
- 调用 `POST /admin/api/profile/invite-codes` 创建/更新注册邀请码。
|
||||
- 支持输入 JSON 对象 metadata,提交前做基础 JSON 对象校验,最终校验以服务端为准。
|
||||
@@ -114,7 +114,7 @@ API 调试页是受控接口调试台,不是通用代理工具:
|
||||
4. maxUses:必须为正整数,最终校验以服务端为准。
|
||||
5. enabled:创建/更新时可切换。
|
||||
6. allowedUserIds:私有码允许的内部用户 ID 列表。
|
||||
7. allowedPublicUserCodes:私有码允许的公开百梦号列表。
|
||||
7. allowedPublicUserCodes:私有码允许的公开陶泥号列表。
|
||||
|
||||
提交成功后展示后端返回的兑换码记录;失败时展示后端错误消息。
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
## 1. 一句话定义
|
||||
|
||||
`2048` 是一个主题化数字合成玩法模板:百梦主通过 Agent 设定棋盘主题、合成链、视觉皮肤、目标格和难度参数,系统生成可试玩、可发布的 2048 作品;玩家通过滑动方向移动棋盘格,相同等级方块合并升级,直到达成目标格或棋盘无可行动作。
|
||||
`2048` 是一个主题化数字合成玩法模板:陶泥儿主通过 Agent 设定棋盘主题、合成链、视觉皮肤、目标格和难度参数,系统生成可试玩、可发布的 2048 作品;玩家通过滑动方向移动棋盘格,相同等级方块合并升级,直到达成目标格或棋盘无可行动作。
|
||||
|
||||
---
|
||||
|
||||
@@ -108,7 +108,7 @@ Agent 型创作至少收集下面 5 个锚点:
|
||||
|
||||
Agent 行为要求:
|
||||
|
||||
1. 优先接住百梦主的一句话灵感,不把创作变成问卷。
|
||||
1. 优先接住陶泥儿主的一句话灵感,不把创作变成问卷。
|
||||
2. 每轮最多追问 1 个最影响成品质量的问题。
|
||||
3. 当主题和合成链已经足够明确时,优先生成草稿。
|
||||
4. 合成链必须围绕同一主题递进,不允许出现互不相关的方块名。
|
||||
@@ -860,4 +860,4 @@ npm run check:encoding
|
||||
|
||||
## 20. 一句话结论
|
||||
|
||||
`2048` 在 Genarrative 中应被做成一个可创作、可换皮、可发布、可排行的主题合成棋盘模板:创作端让百梦主定义合成链和视觉承诺,运行端保持经典 2048 的滑动合并手感,服务端负责正式棋盘裁决、作品状态和成绩真相。
|
||||
`2048` 在 Genarrative 中应被做成一个可创作、可换皮、可发布、可排行的主题合成棋盘模板:创作端让陶泥儿主定义合成链和视觉承诺,运行端保持经典 2048 的滑动合并手感,服务端负责正式棋盘裁决、作品状态和成绩真相。
|
||||
|
||||
@@ -31,7 +31,7 @@
|
||||
|
||||
大鱼吃小鱼玩法是一个 `Agent-First` 的轻量实时成长玩法创作链:
|
||||
|
||||
**百梦主先与 Agent 共创“进化母题、等级阶梯、生态风格与场地气质”,系统再自动编译出一个竖屏全屏、摇杆移动、吞噬收编、三合一进化、持续刷怪、升到最高级即通关的可运行玩法作品。**
|
||||
**陶泥儿主先与 Agent 共创“进化母题、等级阶梯、生态风格与场地气质”,系统再自动编译出一个竖屏全屏、摇杆移动、吞噬收编、三合一进化、持续刷怪、升到最高级即通关的可运行玩法作品。**
|
||||
|
||||
---
|
||||
|
||||
@@ -115,26 +115,26 @@
|
||||
|
||||
`Agent-First 大鱼吃小鱼玩法创作工具`
|
||||
|
||||
玩法运行态对外展示名可由百梦主自定义,不强绑平台内部域名。
|
||||
玩法运行态对外展示名可由陶泥儿主自定义,不强绑平台内部域名。
|
||||
|
||||
## 5.2 目标用户
|
||||
|
||||
目标用户主要是 3 类:
|
||||
|
||||
1. 轻百梦主
|
||||
1. 轻陶泥儿主
|
||||
- 想快速做一个可玩的成长吞噬小游戏,但不懂完整关卡编辑器
|
||||
|
||||
2. 视觉驱动型百梦主
|
||||
2. 视觉驱动型陶泥儿主
|
||||
- 更关心“每级长什么样、动作怎么样、背景氛围如何”
|
||||
|
||||
3. 玩法原型百梦主
|
||||
3. 玩法原型陶泥儿主
|
||||
- 想快速验证一套吞噬成长节奏、等级曲线和场地压迫感
|
||||
|
||||
## 5.3 成功标准
|
||||
|
||||
本期上线后,至少要满足下面这些结果:
|
||||
|
||||
1. 百梦主可在 `5~12` 分钟内通过 Agent 聊天形成一版可用锚点草稿。
|
||||
1. 陶泥儿主可在 `5~12` 分钟内通过 Agent 聊天形成一版可用锚点草稿。
|
||||
2. 系统默认能编译出 `8` 级实体阶梯的初版玩法草稿。
|
||||
3. 每一级实体都能在结果页单独生成和重生成主图。
|
||||
4. 每一级实体都能在结果页单独生成和重生成动作。
|
||||
@@ -179,9 +179,9 @@
|
||||
|
||||
Agent 在这一玩法里不负责实时玩法裁决,它只负责 3 件事:
|
||||
|
||||
1. 帮百梦主明确高杠杆锚点
|
||||
2. 帮百梦主把模糊灵感总结成可编译结构
|
||||
3. 帮百梦主收束出第一版等级阶梯与视觉方向
|
||||
1. 帮陶泥儿主明确高杠杆锚点
|
||||
2. 帮陶泥儿主把模糊灵感总结成可编译结构
|
||||
3. 帮陶泥儿主收束出第一版等级阶梯与视觉方向
|
||||
|
||||
## 7.2 前台交互原则
|
||||
|
||||
@@ -222,7 +222,7 @@ Agent 在这一玩法里不负责实时玩法裁决,它只负责 3 件事:
|
||||
3. `成长阶梯`
|
||||
- 这一玩法一共大致有几级,以及每一级如何逐步升级、变大、变强、变异
|
||||
- 最高级终局形态也并入这一锚点统一确定
|
||||
- 若百梦主没有明确总层数,本期默认按 `8` 级编译,可配置范围固定为 `6~12` 级
|
||||
- 若陶泥儿主没有明确总层数,本期默认按 `8` 级编译,可配置范围固定为 `6~12` 级
|
||||
|
||||
4. `风险节奏`
|
||||
- 玩家周围应该更偏压迫、平衡还是偏爽快
|
||||
@@ -235,7 +235,7 @@ Agent 在这一玩法里不负责实时玩法裁决,它只负责 3 件事:
|
||||
2. `等级总层数` 并入 `成长阶梯`
|
||||
3. `升级轮廓` 并入 `成长阶梯`
|
||||
4. `终局形态` 并入 `成长阶梯`
|
||||
5. `开局成长方式` 改为系统固定规则,不再作为百梦主锚点
|
||||
5. `开局成长方式` 改为系统固定规则,不再作为陶泥儿主锚点
|
||||
|
||||
后续 Agent 追问时,不再把这些内容拆成独立必答题。
|
||||
|
||||
@@ -302,7 +302,7 @@ Agent 在这一玩法里不负责实时玩法裁决,它只负责 3 件事:
|
||||
|
||||
## 9.1 默认草稿规模
|
||||
|
||||
当百梦主没有特别指定时,第一版玩法草稿必须默认编译为:
|
||||
当陶泥儿主没有特别指定时,第一版玩法草稿必须默认编译为:
|
||||
|
||||
1. `8` 级实体阶梯
|
||||
2. `1` 张活动区域背景图
|
||||
|
||||
@@ -680,7 +680,7 @@ assistant 回复应包含:
|
||||
|
||||
1. 对 seedText / 用户消息的简要复述
|
||||
2. 当前仍缺哪些世界锚点
|
||||
3. 建议百梦主下一步回答什么
|
||||
3. 建议陶泥儿主下一步回答什么
|
||||
|
||||
#### 用户后续消息
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@
|
||||
|
||||
那么第二阶段的目标就是:
|
||||
|
||||
**让 Agent 会话真正开始理解百梦主输入,并把自然语言聊天沉淀成结构化创作锚点。**
|
||||
**让 Agent 会话真正开始理解陶泥儿主输入,并把自然语言聊天沉淀成结构化创作锚点。**
|
||||
|
||||
一句话定义:
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@
|
||||
|
||||
那么第四阶段的目标就是:
|
||||
|
||||
**让百梦主直接修改这版草稿设定,并且继续用 AI 为这版草稿扩出新的角色和场景。**
|
||||
**让陶泥儿主直接修改这版草稿设定,并且继续用 AI 为这版草稿扩出新的角色和场景。**
|
||||
|
||||
一句话定义:
|
||||
|
||||
@@ -100,7 +100,7 @@
|
||||
|
||||
一句话目标:
|
||||
|
||||
**让第四阶段结束时,百梦主第一次能像在真正做作品一样修改草稿、继续长出新对象。**
|
||||
**让第四阶段结束时,陶泥儿主第一次能像在真正做作品一样修改草稿、继续长出新对象。**
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -200,7 +200,7 @@
|
||||
|
||||
1. 主线关键角色
|
||||
2. 可扮演角色
|
||||
3. 百梦主重点想看的角色
|
||||
3. 陶泥儿主重点想看的角色
|
||||
|
||||
## 7.2 入口位置
|
||||
|
||||
|
||||
@@ -42,21 +42,21 @@
|
||||
|
||||
## 1.2 一句话定义
|
||||
|
||||
让百梦主通过与一个懂 RPG 剧情策划方法的 Agent 对话,逐步完成世界锚点收集、关键对象塑造、剧情骨架搭建和长尾内容展开;同时由 Express 后端持续维护结构化世界状态、锁定边界、局部重生成和质量检查。
|
||||
让陶泥儿主通过与一个懂 RPG 剧情策划方法的 Agent 对话,逐步完成世界锚点收集、关键对象塑造、剧情骨架搭建和长尾内容展开;同时由 Express 后端持续维护结构化世界状态、锁定边界、局部重生成和质量检查。
|
||||
|
||||
## 1.3 目标用户
|
||||
|
||||
目标用户分三类:
|
||||
|
||||
1. 轻百梦主
|
||||
1. 轻陶泥儿主
|
||||
|
||||
- 有世界灵感,但不擅长结构化填表
|
||||
|
||||
2. 中度百梦主
|
||||
2. 中度陶泥儿主
|
||||
|
||||
- 愿意精修角色、地点、主线第一幕,但不想维护大量底层字段
|
||||
|
||||
3. 重度百梦主
|
||||
3. 重度陶泥儿主
|
||||
- 需要局部重生成、锁定、版本化和导出世界圣经
|
||||
|
||||
## 1.4 产品成功标准
|
||||
@@ -76,7 +76,7 @@
|
||||
|
||||
1. 不把整套系统做成纯聊天黑箱。
|
||||
2. 不让前端继续承担锁定合并、重生成裁决、结构编译等核心逻辑。
|
||||
3. 不要求百梦主直接编辑 `ThemePack / WorldStoryGraph / VisibilitySlice / ThreadContract` 等运行时结构。
|
||||
3. 不要求陶泥儿主直接编辑 `ThemePack / WorldStoryGraph / VisibilitySlice / ThreadContract` 等运行时结构。
|
||||
4. 不把长项目世界管理完全交给一条无限增长的聊天记录。
|
||||
5. 不再保留“生成完直接回世界列表并自动保存”的旧流程。
|
||||
6. 不允许角色主图、角色动作、场景背景图继续停留在临时候选状态后直接发布世界。
|
||||
@@ -151,7 +151,7 @@
|
||||
|
||||
1. `src/services/customWorldCreatorIntent.ts`
|
||||
|
||||
- 已有百梦主意图、锚点包、锁定状态的基础结构
|
||||
- 已有陶泥儿主意图、锚点包、锁定状态的基础结构
|
||||
|
||||
2. `src/types/customWorld.ts`
|
||||
|
||||
@@ -228,7 +228,7 @@
|
||||
|
||||
后台必须持续维护:
|
||||
|
||||
1. 百梦主意图
|
||||
1. 陶泥儿主意图
|
||||
2. 锁定状态
|
||||
3. 世界底稿快照
|
||||
4. 可编辑草稿对象列表
|
||||
@@ -271,11 +271,11 @@
|
||||
-> 打开 Agent 创作入口
|
||||
-> Agent 收集最小锚点
|
||||
-> Agent 输出首轮世界底稿
|
||||
-> 百梦主锁定/修改关键内容
|
||||
-> 陶泥儿主锁定/修改关键内容
|
||||
-> Agent 局部生成关键角色/地点/主线第一幕
|
||||
-> 进入角色与场景资产工坊,生成主形象 / 动作 / 背景图
|
||||
-> Agent 扩展长尾内容
|
||||
-> 百梦主发布世界
|
||||
-> 陶泥儿主发布世界
|
||||
-> 保存到世界库并进入世界
|
||||
```
|
||||
|
||||
@@ -2077,4 +2077,4 @@ Agent 会话每次 operation 完成后自动保存 session snapshot。
|
||||
|
||||
这次新创作工具的正确方向,不是把现有工作台换成一个更大的聊天框,而是:
|
||||
|
||||
**让 Agent 成为百梦主的主交互入口,让 Express 后端成为真正的世界状态管理者,让锁定、局部重生成、摘要、质量护栏和发布链把整个创作过程牢牢收住。**
|
||||
**让 Agent 成为陶泥儿主的主交互入口,让 Express 后端成为真正的世界状态管理者,让锁定、局部重生成、摘要、质量护栏和发布链把整个创作过程牢牢收住。**
|
||||
|
||||
@@ -37,15 +37,15 @@
|
||||
|
||||
## 1.3 目标用户
|
||||
|
||||
目标用户仍然是当前自定义世界创作工具的三类百梦主,但本流程更偏向解决其中两类人的起步问题:
|
||||
目标用户仍然是当前自定义世界创作工具的三类陶泥儿主,但本流程更偏向解决其中两类人的起步问题:
|
||||
|
||||
1. 轻百梦主
|
||||
1. 轻陶泥儿主
|
||||
- 有模糊灵感,但不知道先想什么
|
||||
|
||||
2. 中度百梦主
|
||||
2. 中度陶泥儿主
|
||||
- 有一些设定点子,但缺少把设定收束成可运行剧情骨架的方法
|
||||
|
||||
重度百梦主也可使用本流程,但他们更关心的是:
|
||||
重度陶泥儿主也可使用本流程,但他们更关心的是:
|
||||
|
||||
- Agent 是否会少问废话
|
||||
- 摘要是否准确
|
||||
@@ -1190,7 +1190,7 @@ Agent 不应回复成八问表:
|
||||
|
||||
## 13.2 后续可编辑范围
|
||||
|
||||
进入世界底稿阶段后,百梦主默认优先精修:
|
||||
进入世界底稿阶段后,陶泥儿主默认优先精修:
|
||||
|
||||
1. 关键角色
|
||||
2. 核心冲突与线程
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AI 原生自定义世界生成流程优化 PRD
|
||||
# AI 原生自定义世界生成流程优化 PRD
|
||||
|
||||
更新时间:`2026-04-06`
|
||||
|
||||
@@ -8,11 +8,11 @@
|
||||
|
||||
目标不是推翻当前已经存在的多阶段生成链,而是解决下面这个核心错位:
|
||||
|
||||
**当前仓库已经开始把世界生成拆成 `framework -> themePack -> storyGraph -> role outline -> dossier -> narrativeProfile` 的分阶段 AI 编译流程,但百梦主入口仍然是“一段大文本”,结果页又把大量低杠杆字段重新扔回给百梦主人工兜底。**
|
||||
**当前仓库已经开始把世界生成拆成 `framework -> themePack -> storyGraph -> role outline -> dossier -> narrativeProfile` 的分阶段 AI 编译流程,但陶泥儿主入口仍然是“一段大文本”,结果页又把大量低杠杆字段重新扔回给陶泥儿主人工兜底。**
|
||||
|
||||
一句话定义本次优化:
|
||||
|
||||
**让百梦主先定义世界灵魂锚点,再让 AI / 系统围绕锚点分层生成、分层展开、分层可控地完成长尾内容。**
|
||||
**让陶泥儿主先定义世界灵魂锚点,再让 AI / 系统围绕锚点分层生成、分层展开、分层可控地完成长尾内容。**
|
||||
|
||||
## 1. 当前流程现状
|
||||
|
||||
@@ -64,7 +64,7 @@
|
||||
|
||||
## 1.3 当前流程的核心问题
|
||||
|
||||
## 1.3.1 百梦主入口过于粗糙
|
||||
## 1.3.1 陶泥儿主入口过于粗糙
|
||||
|
||||
当前创建入口只有一块大文本输入框。
|
||||
|
||||
@@ -72,23 +72,23 @@
|
||||
|
||||
1. 不会写长描述的用户很难开局。
|
||||
2. 愿意精细创作的用户没有结构化落点。
|
||||
3. 系统无法明确分辨“哪些是百梦主真正想锁定的锚点,哪些只是随口补充的描述”。
|
||||
3. 系统无法明确分辨“哪些是陶泥儿主真正想锁定的锚点,哪些只是随口补充的描述”。
|
||||
|
||||
结果就是:
|
||||
|
||||
**输入端自由,但信息信号不稳定;AI 虽然能生成很多内容,却不一定生成的是百梦主真正关心的内容。**
|
||||
**输入端自由,但信息信号不稳定;AI 虽然能生成很多内容,却不一定生成的是陶泥儿主真正关心的内容。**
|
||||
|
||||
## 1.3.2 百梦主与 AI 的职责发生倒置
|
||||
## 1.3.2 陶泥儿主与 AI 的职责发生倒置
|
||||
|
||||
当前流程实际上是:
|
||||
|
||||
- 百梦主先写一段泛化设定
|
||||
- 陶泥儿主先写一段泛化设定
|
||||
- AI 再把整个世界铺满
|
||||
- 百梦主最后回到结果页,人工修改大量角色、章节、技能、初始物品、场景连接等细节
|
||||
- 陶泥儿主最后回到结果页,人工修改大量角色、章节、技能、初始物品、场景连接等细节
|
||||
|
||||
这与“低创作门槛、高创作自由度”的目标相反。
|
||||
|
||||
因为真正应该由百梦主控制的,是:
|
||||
因为真正应该由陶泥儿主控制的,是:
|
||||
|
||||
- 世界核心命题
|
||||
- 主题与气质
|
||||
@@ -98,7 +98,7 @@
|
||||
- 关键地点
|
||||
- 标志性物件 / 怪物 / 禁忌
|
||||
|
||||
而不是让百梦主在结果页里逐个补:
|
||||
而不是让陶泥儿主在结果页里逐个补:
|
||||
|
||||
- `backstoryReveal.chapters`
|
||||
- `skills`
|
||||
@@ -117,13 +117,13 @@
|
||||
|
||||
问题不在数量本身,而在于系统并没有明确区分:
|
||||
|
||||
1. 哪些是百梦主应重点塑造的关键对象
|
||||
1. 哪些是陶泥儿主应重点塑造的关键对象
|
||||
2. 哪些只是 AI 应自动展开的长尾铺量
|
||||
|
||||
这会导致两个问题:
|
||||
|
||||
1. AI 在早期就花大量成本生成长尾内容,等待时间长。
|
||||
2. 百梦主在结果页里面对的是一整套“全部都生成了”的世界,而不是“先抓关键锚点,再决定是否继续铺开”。
|
||||
2. 陶泥儿主在结果页里面对的是一整套“全部都生成了”的世界,而不是“先抓关键锚点,再决定是否继续铺开”。
|
||||
|
||||
## 1.3.4 当前结果页暴露了过多低杠杆字段
|
||||
|
||||
@@ -134,7 +134,7 @@
|
||||
- 场景 NPC 分配
|
||||
- 场景连接网络
|
||||
|
||||
这对“专业百梦主”当然有帮助,但对目标用户来说,容易把工具变成:
|
||||
这对“专业陶泥儿主”当然有帮助,但对目标用户来说,容易把工具变成:
|
||||
|
||||
**看起来自由度很高,实际上需要承担很多系统编辑工作。**
|
||||
|
||||
@@ -144,11 +144,11 @@
|
||||
|
||||
这意味着:
|
||||
|
||||
1. 百梦主一旦修改过内容,就会担心被覆盖。
|
||||
1. 陶泥儿主一旦修改过内容,就会担心被覆盖。
|
||||
2. 没有“锁定关键内容,只重生成长尾部分”的机制。
|
||||
3. AI 无法真正成为创作搭档,只像一次性大批量生成器。
|
||||
|
||||
## 1.3.6 当前生成阶段是“模型视角”,不是“百梦主视角”
|
||||
## 1.3.6 当前生成阶段是“模型视角”,不是“陶泥儿主视角”
|
||||
|
||||
当前生成页展示的是系统批次和阶段进度,这很好,但它主要回答的是:
|
||||
|
||||
@@ -156,7 +156,7 @@
|
||||
|
||||
没有回答的是:
|
||||
|
||||
- 百梦主最关心的关键角色是否已经成型
|
||||
- 陶泥儿主最关心的关键角色是否已经成型
|
||||
- 世界冲突是否已经稳定
|
||||
- 当前这轮已经锁定了哪些核心创意
|
||||
- 接下来生成的是关键锚点,还是长尾内容
|
||||
@@ -170,19 +170,19 @@
|
||||
这次优化要同时满足 6 个目标:
|
||||
|
||||
1. 降低输入门槛
|
||||
- 不要求百梦主一上来写长文,不要求理解系统字段。
|
||||
- 不要求陶泥儿主一上来写长文,不要求理解系统字段。
|
||||
|
||||
2. 提高高杠杆创作自由度
|
||||
- 让百梦主直接控制世界灵魂锚点,而不是低价值细节。
|
||||
- 让陶泥儿主直接控制世界灵魂锚点,而不是低价值细节。
|
||||
|
||||
3. 明确百梦主与 AI 的职责边界
|
||||
- 百梦主负责“决定什么值得创作”,AI 负责“把它展开并跑起来”。
|
||||
3. 明确陶泥儿主与 AI 的职责边界
|
||||
- 陶泥儿主负责“决定什么值得创作”,AI 负责“把它展开并跑起来”。
|
||||
|
||||
4. 保留现有分阶段生成骨架
|
||||
- 不推翻 `framework -> themePack -> storyGraph -> role/landmark` 的已有结构。
|
||||
|
||||
5. 引入锁定与局部重生成
|
||||
- 让百梦主能保住自己在乎的内容,只重做其余部分。
|
||||
- 让陶泥儿主能保住自己在乎的内容,只重做其余部分。
|
||||
|
||||
6. 把结果页从“数据总表”升级成“创作工作台”
|
||||
- 让编辑界面按创作价值组织,而不是按底层对象堆字段。
|
||||
@@ -192,11 +192,11 @@
|
||||
优化后的自定义世界流程应该改为:
|
||||
|
||||
```text
|
||||
百梦主输入世界锚点
|
||||
-> AI 编译百梦主意图摘要
|
||||
-> 百梦主确认 / 锁定关键锚点
|
||||
陶泥儿主输入世界锚点
|
||||
-> AI 编译陶泥儿主意图摘要
|
||||
-> 陶泥儿主确认 / 锁定关键锚点
|
||||
-> AI 先生成关键角色与关键地点
|
||||
-> 百梦主可局部修改 / 局部重生成
|
||||
-> 陶泥儿主可局部修改 / 局部重生成
|
||||
-> AI 再展开长尾 NPC、长尾场景与运行时编译结构
|
||||
-> 结果页以“锚点 / 关键对象 / 扩展内容 / 运行时摘要”方式组织
|
||||
-> 保存并进入世界
|
||||
@@ -204,7 +204,7 @@
|
||||
|
||||
一句话:
|
||||
|
||||
**先做创作决策,再做内容展开;先做关键对象,再做长尾铺量;先让百梦主锁定灵魂,再让 AI 扩散世界。**
|
||||
**先做创作决策,再做内容展开;先做关键对象,再做长尾铺量;先让陶泥儿主锁定灵魂,再让 AI 扩散世界。**
|
||||
|
||||
## 4. 输入层优化方案
|
||||
|
||||
@@ -251,7 +251,7 @@
|
||||
2. 卡片模式
|
||||
- 用户直接按结构化方式输入世界锚点
|
||||
|
||||
两种模式最终都编译成统一的百梦主意图对象。
|
||||
两种模式最终都编译成统一的陶泥儿主意图对象。
|
||||
|
||||
## 4.3 必填与选填要分开
|
||||
|
||||
@@ -272,7 +272,7 @@
|
||||
- 标志性要素
|
||||
- 禁止事项
|
||||
|
||||
这样既能保证世界最小成型,又不会把百梦主门槛抬高。
|
||||
这样既能保证世界最小成型,又不会把陶泥儿主门槛抬高。
|
||||
|
||||
## 4.3.1 抽象统一“聊天补充设定”能力
|
||||
|
||||
@@ -307,11 +307,11 @@ RPG 创作工作台、拼图创作工作台、大鱼吃小鱼创作工作台都
|
||||
|
||||
1. AI 不得在重生成时覆盖该内容
|
||||
2. 长尾内容只能围绕它展开
|
||||
3. 结果页里应明确显示其为“百梦主锚点”
|
||||
3. 结果页里应明确显示其为“陶泥儿主锚点”
|
||||
|
||||
## 5. 生成链路优化方案
|
||||
|
||||
## 5.1 新增“百梦主意图编译层”
|
||||
## 5.1 新增“陶泥儿主意图编译层”
|
||||
|
||||
在真正开始世界生成前,先新增一个轻量阶段:
|
||||
|
||||
@@ -324,19 +324,19 @@ RPG 创作工作台、拼图创作工作台、大鱼吃小鱼创作工作台都
|
||||
|
||||
输出:
|
||||
|
||||
- 百梦主意图摘要
|
||||
- 陶泥儿主意图摘要
|
||||
- 世界锚点摘要
|
||||
- 系统识别出的关键角色 / 冲突 / 地点 / 禁忌
|
||||
|
||||
这一步的作用不是生成世界,而是先回答:
|
||||
|
||||
1. 系统理解到的世界核心是什么
|
||||
2. 哪些内容将被视为百梦主强锚点
|
||||
2. 哪些内容将被视为陶泥儿主强锚点
|
||||
3. 哪些内容将交给 AI 扩展
|
||||
|
||||
## 5.2 把当前生成链改成“关键先行、长尾后补”
|
||||
|
||||
当前 `generateCustomWorldProfile(...)` 的分阶段结构可以保留,但生成顺序需要更百梦主化。
|
||||
当前 `generateCustomWorldProfile(...)` 的分阶段结构可以保留,但生成顺序需要更陶泥儿主化。
|
||||
|
||||
建议改成 5 层:
|
||||
|
||||
@@ -347,9 +347,9 @@ RPG 创作工作台、拼图创作工作台、大鱼吃小鱼创作工作台都
|
||||
- 世界框架
|
||||
- ThemePack
|
||||
- StoryGraph 的基础版
|
||||
- 百梦主锚点摘要
|
||||
- 陶泥儿主锚点摘要
|
||||
|
||||
这一层完成后,系统应能让百梦主看到:
|
||||
这一层完成后,系统应能让陶泥儿主看到:
|
||||
|
||||
- 世界现在到底被理解成了什么
|
||||
- 哪些冲突 / 势力 / 意象被识别出来了
|
||||
@@ -362,11 +362,11 @@ RPG 创作工作台、拼图创作工作台、大鱼吃小鱼创作工作台都
|
||||
- 关键场景角色
|
||||
- 关键地点
|
||||
|
||||
这一层优先围绕百梦主明确输入的角色和地点,而不是先铺满全部数量。
|
||||
这一层优先围绕陶泥儿主明确输入的角色和地点,而不是先铺满全部数量。
|
||||
|
||||
### 第三层:百梦主校对层
|
||||
### 第三层:陶泥儿主校对层
|
||||
|
||||
在继续展开长尾内容前,应允许百梦主做一次轻量校对:
|
||||
在继续展开长尾内容前,应允许陶泥儿主做一次轻量校对:
|
||||
|
||||
- 确认关键角色是否对
|
||||
- 确认关键地点是否对
|
||||
@@ -408,7 +408,7 @@ RPG 创作工作台、拼图创作工作台、大鱼吃小鱼创作工作台都
|
||||
这样做的价值很高:
|
||||
|
||||
1. 降低首次等待焦虑
|
||||
2. 让百梦主更早介入关键对象校正
|
||||
2. 让陶泥儿主更早介入关键对象校正
|
||||
3. 避免系统在创作方向还没稳定前,先铺满大量长尾内容
|
||||
|
||||
## 5.4 角色与场景生成要改成“锚点优先 + 长尾补位”
|
||||
@@ -417,11 +417,11 @@ RPG 创作工作台、拼图创作工作台、大鱼吃小鱼创作工作台都
|
||||
|
||||
优化后应改为:
|
||||
|
||||
1. 先生成百梦主明确指定的关键角色 / 地点
|
||||
1. 先生成陶泥儿主明确指定的关键角色 / 地点
|
||||
2. 再根据世界冲突自动补位缺失的角色原型和场景功能位
|
||||
3. 最后再铺长尾
|
||||
|
||||
这样生成出来的世界会更像“围绕百梦主意图长出来”,而不是“先生成了一个完整世界,再让百梦主去认领”
|
||||
这样生成出来的世界会更像“围绕陶泥儿主意图长出来”,而不是“先生成了一个完整世界,再让陶泥儿主去认领”
|
||||
|
||||
## 6. 结果页与编辑工作台优化方案
|
||||
|
||||
@@ -439,7 +439,7 @@ RPG 创作工作台、拼图创作工作台、大鱼吃小鱼创作工作台都
|
||||
优化后建议改成 4 层工作台:
|
||||
|
||||
1. 创作锚点
|
||||
- 展示百梦主输入和锁定内容
|
||||
- 展示陶泥儿主输入和锁定内容
|
||||
|
||||
2. 关键对象
|
||||
- 关键角色、关键地点、关键冲突对象
|
||||
@@ -448,11 +448,11 @@ RPG 创作工作台、拼图创作工作台、大鱼吃小鱼创作工作台都
|
||||
- AI 自动展开的长尾角色、长尾地点、补位内容
|
||||
|
||||
4. 世界编译摘要
|
||||
- 展示世界线程、题材包、运行时摘要,但默认不要求百梦主编辑
|
||||
- 展示世界线程、题材包、运行时摘要,但默认不要求陶泥儿主编辑
|
||||
|
||||
## 6.2 编辑界面应遵守“高价值字段前置,低价值字段折叠”
|
||||
|
||||
对百梦主默认暴露的应是:
|
||||
对陶泥儿主默认暴露的应是:
|
||||
|
||||
- 角色一句话定位
|
||||
- 角色表面面貌
|
||||
@@ -507,7 +507,7 @@ RPG 创作工作台、拼图创作工作台、大鱼吃小鱼创作工作台都
|
||||
|
||||
## 7.1 新增 `CustomWorldCreatorIntent`
|
||||
|
||||
建议新增百梦主输入的统一结构:
|
||||
建议新增陶泥儿主输入的统一结构:
|
||||
|
||||
```ts
|
||||
interface CustomWorldCreatorIntent {
|
||||
@@ -529,7 +529,7 @@ interface CustomWorldCreatorIntent {
|
||||
|
||||
作用:
|
||||
|
||||
- 把“百梦主真正输入了什么”从最终 `CustomWorldProfile` 中分离出来
|
||||
- 把“陶泥儿主真正输入了什么”从最终 `CustomWorldProfile` 中分离出来
|
||||
|
||||
## 7.2 新增 `CustomWorldAnchorPack`
|
||||
|
||||
@@ -583,7 +583,7 @@ interface CustomWorldGenerationDraft {
|
||||
|
||||
作用:
|
||||
|
||||
- 让“百梦主输入、AI 编译、结果编辑”成为连续工作流,而不是只有最终成品对象
|
||||
- 让“陶泥儿主输入、AI 编译、结果编辑”成为连续工作流,而不是只有最终成品对象
|
||||
|
||||
## 8. 与当前仓库的接入建议
|
||||
|
||||
@@ -597,7 +597,7 @@ interface CustomWorldGenerationDraft {
|
||||
目标:
|
||||
|
||||
- 把单 textarea 升级为“快速模式 + 卡片模式”
|
||||
- 新增百梦主意图状态
|
||||
- 新增陶泥儿主意图状态
|
||||
- 新增锁定和局部重生成入口
|
||||
|
||||
## 8.2 prompt 与生成服务层
|
||||
@@ -623,7 +623,7 @@ interface CustomWorldGenerationDraft {
|
||||
|
||||
目标:
|
||||
|
||||
- 为 `CustomWorldProfile` 增加百梦主意图与锚点相关扩展字段
|
||||
- 为 `CustomWorldProfile` 增加陶泥儿主意图与锚点相关扩展字段
|
||||
- 保持旧档兼容
|
||||
- 让现有 builder 能同时消费 `creatorIntent + anchorPack + profile seed`
|
||||
|
||||
@@ -647,28 +647,28 @@ interface CustomWorldGenerationDraft {
|
||||
本次优化不做以下事情:
|
||||
|
||||
1. 不推翻当前自定义世界最终输出仍是 `CustomWorldProfile` 的兼容目标
|
||||
2. 不把所有运行时结构都暴露给百梦主直接编辑
|
||||
3. 不要求百梦主理解 `themePack / storyGraph / knowledgeFacts / threadContracts` 等系统结构
|
||||
4. 不把复杂数值平衡、掉落预算、build 预算转移给百梦主
|
||||
2. 不把所有运行时结构都暴露给陶泥儿主直接编辑
|
||||
3. 不要求陶泥儿主理解 `themePack / storyGraph / knowledgeFacts / threadContracts` 等系统结构
|
||||
4. 不把复杂数值平衡、掉落预算、build 预算转移给陶泥儿主
|
||||
5. 不把“高自由度”理解成“所有字段都手工可改”
|
||||
|
||||
## 10. 验收标准
|
||||
|
||||
做到以下几点,才算这次优化真正成立:
|
||||
|
||||
1. 百梦主可以不用写长文,只靠卡片输入也能完成自定义世界创建。
|
||||
2. 系统会明确区分“百梦主锚点”和“AI 自动展开内容”。
|
||||
3. 百梦主不再需要默认手改大量 `skills / initialItems / backstoryReveal / scene connections` 才能得到可用世界。
|
||||
1. 陶泥儿主可以不用写长文,只靠卡片输入也能完成自定义世界创建。
|
||||
2. 系统会明确区分“陶泥儿主锚点”和“AI 自动展开内容”。
|
||||
3. 陶泥儿主不再需要默认手改大量 `skills / initialItems / backstoryReveal / scene connections` 才能得到可用世界。
|
||||
4. 结果页支持锁定关键角色、关键地点、关键冲突,并支持局部重生成。
|
||||
5. 重新生成不再默认覆盖整个世界。
|
||||
6. 当前 `framework -> themePack -> storyGraph -> role/landmark` 生成主链可以继续复用,而不是被废弃。
|
||||
7. 结果页默认展示的是高创作价值对象,而不是系统级低层字段。
|
||||
8. 长尾内容生成明显后置于关键对象生成,百梦主能更早看到并修正关键对象。
|
||||
8. 长尾内容生成明显后置于关键对象生成,陶泥儿主能更早看到并修正关键对象。
|
||||
9. 旧的自由文本输入模式仍然可用,但不再是唯一入口。
|
||||
|
||||
## 11. 推荐落地顺序
|
||||
|
||||
## 阶段 A:先加百梦主意图层
|
||||
## 阶段 A:先加陶泥儿主意图层
|
||||
|
||||
先做:
|
||||
|
||||
@@ -678,7 +678,7 @@ interface CustomWorldGenerationDraft {
|
||||
|
||||
目标:
|
||||
|
||||
- 先把百梦主输入从“单一大文本”升级成“可识别的创作锚点”
|
||||
- 先把陶泥儿主输入从“单一大文本”升级成“可识别的创作锚点”
|
||||
|
||||
## 阶段 B:再加锚点包与锁定能力
|
||||
|
||||
@@ -721,4 +721,4 @@ interface CustomWorldGenerationDraft {
|
||||
|
||||
当前自定义世界流程最需要优化的,不是“让 AI 再多生成一点内容”,而是:
|
||||
|
||||
**把百梦主从低价值字段编辑里解放出来,让百梦主负责世界灵魂锚点,让 AI 负责围绕这些锚点分层生成、分层展开、分层可控地把世界长出来。**
|
||||
**把陶泥儿主从低价值字段编辑里解放出来,让陶泥儿主负责世界灵魂锚点,让 AI 负责围绕这些锚点分层生成、分层展开、分层可控地把世界长出来。**
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
|
||||
## 1. 一句话定义
|
||||
|
||||
让百梦主在创作页通过表单确认题材主题和难度选项,系统根据难度选项派生需要消除次数与难度数值,并编译出一个可试玩、可发布的单局抓大鹅玩法作品;玩家在 `10` 分钟倒计时内点击圆形空间中可见物品,把物品放入下方 `7` 格备选栏,每凑齐 `3` 个同物品 id 自动消除,最终清空圆形空间内全部物品即胜利。
|
||||
让陶泥儿主在创作页通过表单确认题材主题和难度选项,系统根据难度选项派生需要消除次数与难度数值,并编译出一个可试玩、可发布的单局抓大鹅玩法作品;玩家在 `10` 分钟倒计时内点击圆形空间中可见物品,把物品放入下方 `7` 格备选栏,每凑齐 `3` 个同物品 id 自动消除,最终清空圆形空间内全部物品即胜利。
|
||||
|
||||
---
|
||||
|
||||
@@ -96,22 +96,23 @@ Match3D 必须形成独立玩法域,后续技术方案至少需要覆盖:
|
||||
2. 创建流程采用入口表单收集关键配置。
|
||||
3. 表单必须在进入结果页前确认:
|
||||
- 题材主题
|
||||
- 3D 素材风格
|
||||
- 2D 素材风格
|
||||
- 难度选项
|
||||
4. `需要消除次数` 与难度 `1~10` 数值不再作为独立输入框展示,由难度选项派生。
|
||||
5. 生成抓大鹅草稿消耗 `20` 光点,生成按钮必须显式展示。
|
||||
6. 结果页支持编辑游戏名称、标签、封面图等基础发布信息。
|
||||
7. 发布前支持试玩,并允许随时停止和修改配置。
|
||||
8. 发布不要求试玩通关。
|
||||
9. 单局运行态使用 `10` 分钟倒计时。
|
||||
10. 下方备选栏固定为 `7` 个格子。
|
||||
11. 玩家点击可见物品后,物品飞入备选栏。
|
||||
12. 备选栏中每凑齐 `3` 个相同物品 id 自动消除。
|
||||
13. 清空圆形空间中全部物品即胜利。
|
||||
14. 倒计时结束或备选栏满即失败。
|
||||
15. 胜利 / 失败后展示结算界面。
|
||||
16. 入口页的 3D 素材风格选择会进入素材图提示词,并作为结果页手动 Rodin 3D 模型生成的默认提示词依据。
|
||||
17. 点击、入槽、消除、失败、胜利的即时反馈效果由前端先行呈现,后端负责权威确认、状态落库和成绩可信性。
|
||||
5. 生成抓大鹅草稿固定消耗 `10` 泥点,生成按钮必须显式展示。
|
||||
6. 结果页背景音乐重新生成固定消耗 `5` 泥点;UI 背景重新生成固定消耗 `2` 泥点;批量新增物品素材按实际可新增物品名每 `5` 个消耗 `2` 泥点,不足 `5` 个向上取整。
|
||||
7. 结果页支持编辑游戏名称、标签、封面图等基础发布信息。
|
||||
8. 发布前支持试玩,并允许随时停止和修改配置。
|
||||
9. 发布不要求试玩通关。
|
||||
10. 单局运行态使用 `10` 分钟倒计时。
|
||||
11. 下方备选栏固定为 `7` 个格子。
|
||||
12. 玩家点击可见物品后,物品飞入备选栏。
|
||||
13. 备选栏中每凑齐 `3` 个相同物品 id 自动消除。
|
||||
14. 清空圆形空间中全部物品即胜利。
|
||||
15. 倒计时结束或备选栏满即失败。
|
||||
16. 胜利 / 失败后展示结算界面。
|
||||
17. 入口页的 2D 素材风格选择会进入素材图提示词,并作为后续物品素材新增和重绘的默认提示词依据。
|
||||
18. 点击、入槽、消除、失败、胜利的即时反馈效果由前端先行呈现,后端负责权威确认、状态落库和成绩可信性。
|
||||
|
||||
---
|
||||
|
||||
@@ -124,7 +125,7 @@ Match3D 必须形成独立玩法域,后续技术方案至少需要覆盖:
|
||||
3. 不做排行榜正式展示。
|
||||
4. 不做道具,但需要预留功能口。
|
||||
5. 不做洗牌、重置、旋转、放大等局内操作。
|
||||
6. 不做多批次真实 3D 模型生成;当前草稿生成只固定产出 `3` 个 GLB 模型并写入 OSS。
|
||||
6. 不做首屏真实 3D 模型生成;当前草稿生成以多视角 2D 物品素材为主,并写入 OSS。
|
||||
7. 不做真实 3D 物理遮挡。
|
||||
8. 不做真实物理碰撞结算。
|
||||
9. 不做必须试玩通关才能发布的门槛。
|
||||
@@ -143,7 +144,7 @@ Match3D 首版参考拼图后期的入口表单收集方式,而不是早期的
|
||||
表单的职责是帮助用户确认可以直接编译 demo 的最小配置:
|
||||
|
||||
1. 题材主题。
|
||||
2. 3D 素材风格。
|
||||
2. 2D 素材风格。
|
||||
3. 游戏难度选项。
|
||||
|
||||
`需要消除次数` 与游戏难度数值仍属于后端会话配置,但不再要求用户手填。当前入口页固定采用以下映射:
|
||||
@@ -152,7 +153,7 @@ Match3D 首版参考拼图后期的入口表单收集方式,而不是早期的
|
||||
轻松 -> 需要消除 8 次,难度 2
|
||||
标准 -> 需要消除 12 次,难度 4
|
||||
进阶 -> 需要消除 16 次,难度 6
|
||||
硬核 -> 需要消除 20 次,难度 8
|
||||
硬核 -> 需要消除 21 次,难度 8
|
||||
```
|
||||
|
||||
## 6.2 必填配置
|
||||
@@ -161,7 +162,7 @@ Match3D 首版参考拼图后期的入口表单收集方式,而不是早期的
|
||||
|
||||
题材决定后续生成或选择物品素材的方向。用户可以自定义主题,例如水果、玩具、食物、符号等。
|
||||
|
||||
当前抓大鹅草稿生成会固定生成 `3` 个题材物品:素材图切割出的独立图片会作为 Rodin 图生 3D 参考图,生成出的 GLB 模型必须转存 OSS,并随作品 profile 的 `generatedItemAssets` 持久化。运行态优先使用这些生成模型;只有模型缺失、加载失败或未进入 3D 渲染模式时,才回退到 25 个默认积木件视觉键。默认素材不使用透明气泡,也不在图案上放文字标识。
|
||||
当前抓大鹅草稿会按难度生成题材物品:素材图切割出的多视角 2D 图片必须转存 OSS,并随作品 profile 的 `generatedItemAssets` 持久化。运行态优先使用这些生成图片;只有图片缺失、读取失败或未进入生成素材模式时,才回退到默认积木件视觉键。默认素材不使用透明气泡,也不在图案上放文字标识。
|
||||
|
||||
可消除物尺寸使用五档相对体积规则:XL 型相对体积为 `1.60~2.30`,L 型为 `1.25~1.60`,M 型为 `1.00`,XS 型为 `0.65~0.85`,S 型为 `0.35~0.50`。单局中 XL / L / M / XS / S 按本局使用的消除物类型数的 `20% / 30% / 30% / 15% / 5%` 分配;非整数配额按最大余数补齐,确保总数等于本局使用类型数量。同一关卡内同一个颜色和造型的物品只能对应一个尺寸档位;可存在同尺寸但不同颜色和造型的物品。后端运行态通过 `radius` 下发权威尺寸,前端只按快照表现。
|
||||
|
||||
@@ -183,19 +184,27 @@ Match3D 首版参考拼图后期的入口表单收集方式,而不是早期的
|
||||
|
||||
首版 demo 中,用户只需凭感觉选择难度;具体难度规则由系统内部解释。后续优化阶段再细化难度曲线、生成算法和遮挡策略。
|
||||
|
||||
### 3D 素材风格
|
||||
### 2D 素材风格
|
||||
|
||||
入口页在题材主题与难度之间展示 `3D素材风格` 横向滑动选择。首批固定选项为:
|
||||
入口页在题材主题与难度之间展示 `2D素材风格` 横向滑动选择。首批固定选项为:
|
||||
|
||||
```text
|
||||
黏土手作 / 低多边形 / 玩具塑料 / 木质雕刻 / 体素积木 / 金属机甲 / 自定义
|
||||
扁平图标 / 赛璐璐卡通 / 像素复古 / 手绘水彩 / 贴纸描边 / 厚涂图标 / 自定义
|
||||
```
|
||||
|
||||
每个内置选项使用 VectorEngine `gpt-image-2-all` 生成的画风参考图展示;参考图保存在 `public/match3d-style-references/`,只作为入口选择的视觉提示,不作为用户上传参考图。选择内置风格时,前端提交 `assetStyleId`、`assetStyleLabel` 与对应 `assetStylePrompt`。选择 `自定义` 时必须弹出独立面板,用户填写描述后才允许应用;自定义描述作为 `assetStylePrompt` 进入后端生成链路。
|
||||
每个内置选项使用 VectorEngine `gpt-image-2-all` 生成的画风参考图展示;参考图保存在 `public/match3d-style-references/`,只作为入口选择的视觉提示,不作为用户上传参考图。每张参考图只展示 `1` 个完整独立物品,不能展示 `5` 个物品样张或多物品散点图,避免用户误判为物品数量配置。选择内置风格时,前端提交 `assetStyleId`、`assetStyleLabel` 与对应 `assetStylePrompt`。选择 `自定义` 时必须弹出独立面板,用户填写描述后才允许应用;自定义描述作为 `assetStylePrompt` 进入后端生成链路。
|
||||
|
||||
`像素复古` 的 `assetStylePrompt` 必须是强约束而不是泛化描述:真正复古像素 2D 游戏道具 sprite,先按约 `64x64` 低分辨率像素块绘制再整数倍放大,硬边方块像素清晰可见,有限色板 `12-24` 色,并禁止抗锯齿、柔焦、平滑渐变、真实 3D 渲染、PBR 材质和摄影光照。后端收到 `assetStyleId = pixel-retro` 时必须兜底补齐这组约束。
|
||||
|
||||
## 6.3 参考图片
|
||||
|
||||
抓大鹅入口页不展示参考图片上传。题材表现由题材文本和草稿切割图片链路承接;草稿生成阶段会直接以切割图片作为 Rodin 图生模型参考图生成首批 GLB。结果页 `3D素材` Tab 仍可对单个素材触发重新生成。
|
||||
抓大鹅入口页不展示参考图片上传。题材表现由题材文本和草稿切割图片链路承接;草稿生成阶段会生成多视角 2D 物品素材并写入作品 profile。结果页 `素材配置 > 物品` 继续承接物品素材预览、删除、批量新增和音效配置。
|
||||
|
||||
## 6.4 生成音效入口
|
||||
|
||||
抓大鹅入口页不展示 `生成音效` Toggle。草稿生成阶段只保存 `generatedItemAssets[].soundPrompt`,不调用 Vidu 生成点击音效,也不产生点击音效相关扣费。
|
||||
|
||||
结果页仍保留单个物品音效的手动补生成入口。用户在 `素材配置 > 物品` 详情面板中生成点击音效时,后端复用通用创作音频接口和资产落点,把结果写入对应 `generatedItemAssets[].clickSound`。
|
||||
|
||||
---
|
||||
|
||||
@@ -222,9 +231,15 @@ Match3D 首版参考拼图后期的入口表单收集方式,而不是早期的
|
||||
|
||||
## 7.3 素材生成边界
|
||||
|
||||
抓大鹅草稿生成链路会生成首批 `3` 个题材物品素材:文本模型生成物品名,VectorEngine 生成 `2*2` 素材图并切割独立图片,再以每张独立图片调用 Rodin 图生 3D,下载 `.glb` 并转存 OSS。入口页选择的 `assetStylePrompt` 必须写入素材图提示词;结果页手动 Rodin 图生模型时,继续以该物品图片和默认提示词作为起点。
|
||||
抓大鹅草稿生成链路会根据难度生成题材物品素材:文本模型生成物品名,VectorEngine 分批生成 `1:1` 素材图并切割为每个物品 `5` 张不同视角图片,再转存 OSS。实际生成数量必须向上补齐为 `5` 的倍数,并生成补齐物品的名称和对应图片;例如标准难度玩法使用 `9` 种物品,但素材实际生成 `10` 种。入口页选择的 `assetStylePrompt` 必须写入素材图提示词;结果页批量新增物品时继续以该风格作为默认提示词起点。
|
||||
|
||||
生成出的独立图片与 GLB 模型都必须作为草稿页 `3D素材` Tab 的预览资产返回。模型生成成功时 `generatedItemAssets[].status = model_ready`,并携带 `modelSrc`、`modelObjectKey`、`modelFileName`、`taskUuid` 和 `subscriptionKey`;正式平台资产绑定和更完整的二次编辑流程以后续技术方案为准。
|
||||
批量新增物品素材与草稿生成使用同一素材图处理流程:先按用户实际新增名称补齐到 `5` 的倍数,整图生成完成后丢弃补齐用临时物品,只对用户实际新增项继续绿幕抠背景、切割和 OSS 上传,并只把这些真实新增物品写入 `generatedItemAssets`;补齐用临时物品不进入作品资产列表、不参与发布校验和运行态映射。计费数量按清洗、去重、排除已有物品并截断到容量上限后的实际新增数量计算。
|
||||
|
||||
素材图提示词必须固定要求 `5*5` 严格均匀排布,每格主体完整居中,不得跨格、贴边或越界,避免切割成独立图片后出现相邻物品内容污染。
|
||||
|
||||
生成出的独立图片必须作为结果页 `素材配置 > 物品` 的预览资产返回。图片素材生成成功时 `generatedItemAssets[].status = image_ready`,并携带 `imageViews[]`,兼容字段 `imageSrc` / `imageObjectKey` 指向首张视角图;正式平台资产绑定和更完整的二次编辑流程以后续技术方案为准。
|
||||
|
||||
局内 UI 生成分为两类图片:`9:16` 纯背景图和 `1:1` 中心容器 UI 图。纯背景图只表现题材氛围和环境,不得生成锅、圆盘、托盘、拼图槽、物品槽、HUD、文字、按钮、倒计时、分数或物品;中心容器 UI 图单独生成,贴合题材设定,用于覆盖运行态默认圆形竞技容器。容器图必须参考 `public/match3d-background-references/pot-fused-reference.png` 的大尺寸轻俯视构图:容器外轮廓接近画布四边,宽度约占画布 `86%-92%`、高度约占 `82%-90%`,内口为横向椭圆,不能生成小圆盘、正俯视扁盘、侧视碗或小托盘。底部备选栏、顶部控件和拼图/物品槽位继续使用运行态默认 UI,不烘进生成背景。
|
||||
|
||||
## 7.4 发布前试玩
|
||||
|
||||
@@ -261,8 +276,8 @@ Match3D 首版参考拼图后期的入口表单收集方式,而不是早期的
|
||||
运行时主交互空间是一个有边界的圆形空间。
|
||||
|
||||
1. 圆形空间使用俯视角。
|
||||
2. 背景环境资源后续可以尝试伪 3D 视角效果。
|
||||
3. 圆形空间边界是中间交互图案的边界。
|
||||
2. 背景环境资源只作为纯背景层,不承接圆形空间边界。
|
||||
3. 圆形空间边界由运行态默认容器或生成出的中心容器 UI 图承接,不能烘进纯背景图。
|
||||
4. 物品不能超出圆形边界,也不能被边界压住或裁切。
|
||||
5. 运行态快照中的 `x / y / radius` 使用前端可直接渲染的 `0~1` 归一化坐标;圆心固定为 `(0.5, 0.5)`,圆形可用半径为 `0.5`。
|
||||
6. 后端生成和前端兜底渲染都必须满足 `distance((x, y), (0.5, 0.5)) + radius <= 0.5 - safeMargin`,`safeMargin` 至少覆盖圆形边框和视觉阴影,避免可消除图案贴边裁切。
|
||||
@@ -277,13 +292,16 @@ totalItemCount = clearCount * 3
|
||||
|
||||
每种物品数量必须是 `3` 的倍数,避免生成无法通关的局。
|
||||
|
||||
生成的消除物类型数由用户填写的需要消除次数决定:
|
||||
生成的消除物类型数由难度档位决定:
|
||||
|
||||
```text
|
||||
itemTypeCount = clearCount <= 25 ? clearCount : 25
|
||||
轻松 = 3
|
||||
标准 = 9
|
||||
进阶 = 15
|
||||
硬核 = 21
|
||||
```
|
||||
|
||||
当 `clearCount <= 25` 时,本局生成的 `itemTypeId` 数量等于 `clearCount`,每种类型默认生成 `3` 件;当 `clearCount > 25` 时,本局最多生成 `25` 种 `itemTypeId`,后续消除组按这 `25` 种类型轮转补齐,且每种类型最终数量仍必须保持 `3` 的倍数。
|
||||
当前四档难度分别生成 `3 / 9 / 15 / 21` 种 `itemTypeId`。历史草稿若仍保留 `clearCount = 20` 的硬核配置,运行时和素材生成都必须兼容映射为 `21` 种物品,不得回退成 `20` 种。
|
||||
|
||||
同一局内这些类型必须分别使用不同的形状和颜色组合,不能出现两个组看起来像同一种物体的情况。
|
||||
|
||||
@@ -297,13 +315,13 @@ itemTypeCount = clearCount <= 25 ? clearCount : 25
|
||||
|
||||
## 8.5 物品资产
|
||||
|
||||
当前 demo 使用生成 GLB 优先、默认积木兜底的物品资产策略。
|
||||
当前 demo 使用生成 2D 图片优先、默认积木兜底的物品资产策略。
|
||||
|
||||
1. demo 至少提供 `25` 种彼此不同的颜色与几何造型组合默认素材,支撑 `clearCount > 25` 时的类型上限和 GLB 缺失兜底。
|
||||
2. 有 `generatedItemAssets[].modelSrc` 或 `modelObjectKey` 时,运行态与备选栏必须优先读取该 GLB;默认积木件只作为加载失败、模型缺失或 2D 回退时的兜底素材池。
|
||||
3. 前端读取生成模型必须通过 `/api/assets/read-bytes` 获取私有 OSS 字节,再交给 Three.js `GLTFLoader` 解析;不得直接把 `/generated-match3d-assets/...` 当裸 URL 请求。
|
||||
4. 当前固定 `clearCount = 3` 的生成草稿中,运行态 `match3d-type-01/02/03` 按类型编号顺序映射到生成出的 `3` 个模型;后续恢复更大生成数量时,模型列表顺序必须继续与类型编号稳定对应。
|
||||
5. 默认积木视觉键仍需映射为无文字的纯色 2D 图标和程序化 3D 积木模型,不能显示为透明气泡或文字标记。
|
||||
1. demo 至少提供 `25` 种彼此不同的颜色与几何造型组合默认素材,支撑 `clearCount > 25` 时的类型上限和图片缺失兜底。
|
||||
2. 有 `generatedItemAssets[].imageViews`、`imageSrc` 或 `imageObjectKey` 时,运行态与备选栏必须优先读取该 2D 图片素材;默认积木件只作为加载失败或图片缺失时的兜底素材池。
|
||||
3. 前端读取 generated legacy 图片必须通过 `/api/assets/read-url` 换签后加载;不得直接把 `/generated-match3d-assets/...` 当裸 URL 请求。
|
||||
4. 运行态 `match3d-type-01/02/03` 等类型按类型编号顺序映射到生成出的图片素材列表;后续更大生成数量时,素材列表顺序必须继续与类型编号稳定对应。
|
||||
5. 默认积木视觉键仍需映射为无文字的纯色 2D 图标,不能显示为透明气泡或文字标记。
|
||||
6. 用户题材主题后续会映射为符合常识预期的物品集合。
|
||||
|
||||
示例:水果题材可以对应红色苹果、黄色香蕉、紫色葡萄等。
|
||||
@@ -334,7 +352,7 @@ itemTypeCount = clearCount <= 25 ? clearCount : 25
|
||||
|
||||
飞行动画过程中,物品不再与其他物品产生碰撞。
|
||||
|
||||
当前 3D 实验模式下,物品进入备选栏后必须从圆形空间的物理世界移除;备选栏只展示该物品同款 3D 模型的独立预览,固定为斜 `45` 度便于识别,不再参与场内碰撞、重力或堆叠。
|
||||
物品进入备选栏后必须从圆形空间的可点击列表移除;备选栏展示该物品同款 2D 素材图,不再参与场内点击、遮挡或堆叠。
|
||||
|
||||
前端播放即时反馈的同时,必须向后端提交点击意图。后端确认后固化入槽结果;后端拒绝时,前端恢复物品位置和备选栏表现。
|
||||
|
||||
@@ -344,7 +362,7 @@ itemTypeCount = clearCount <= 25 ? clearCount : 25
|
||||
|
||||
1. 每次点击进入即时反馈流程后,前端先把物品表现为进入备选栏。
|
||||
2. 备选栏中每出现 `3` 个相同物品 id,前端立即播放自动消除效果并腾出格子。
|
||||
3. 3D 模式下,备选栏格子展示从场内取出的同款 3D 模型预览,视角固定斜 `45` 度,不使用另一套不一致的 UI 图标;托盘预览必须共享一个 WebGL renderer,并按 `7` 格容器实际宽高把模型居中摆放到对应格子,不能因多个预览上下文导致中心场地模型不可见;WebGL 回退或 `2D` 模式下才使用保留的 2D 图标。
|
||||
3. 备选栏格子展示从场内取出的同款 2D 素材图,不使用另一套不一致的 UI 图标;图片缺失或读取失败时才使用保留的默认图标。
|
||||
4. 后端确认后固化真实备选栏和消除结果;若后端返回状态不一致,前端必须以最新后端快照校正。
|
||||
5. 如果备选栏满且无法消除,前端可以立即展示失败过渡,最终失败状态以后端确认为准。
|
||||
|
||||
@@ -674,7 +692,7 @@ GET /api/runtime/match3d/runs/:runId
|
||||
入口表单只展示三个输入块:
|
||||
|
||||
1. `想做一个什么题材的抓大鹅?` 大文本输入框。
|
||||
2. `3D素材风格` 横向滑动风格卡,最后一个为 `自定义`。
|
||||
2. `2D素材风格` 横向滑动风格卡,最后一个为 `自定义`。
|
||||
3. `难度` 选项按钮。
|
||||
|
||||
入口页不展示参考图、`需要消除次数` 数值输入、`难度数值` 滑杆,也不展示 `题材 / 物品 / 难度` 三个摘要框。`需要消除次数` 和 `difficulty` 由难度选项派生后提交给后端。
|
||||
@@ -685,6 +703,8 @@ GET /api/runtime/match3d/runs/:runId
|
||||
|
||||
结果页保持清爽,复用平台已有作品结果页风格。
|
||||
|
||||
结果页 `难度配置` 中的四档难度使用横向离散拖动条呈现,拖动条只允许停在 `轻松 / 标准 / 进阶 / 硬核` 四个刻度上,刻度标签可点击切换,仍按同一映射派生 `需要消除次数`、`difficulty` 和 `物品种类`。
|
||||
|
||||
点击按钮弹出独立面板时,不实现成在当前面板下面展开内容。
|
||||
|
||||
## 14.4 运行态
|
||||
@@ -704,24 +724,25 @@ GET /api/runtime/match3d/runs/:runId
|
||||
首版 PRD 对应 demo 验收标准:
|
||||
|
||||
1. 用户可从平台创作入口进入“抓大鹅”模板。
|
||||
2. 入口表单能确认题材主题、3D 素材风格和难度选项,并提交派生后的消除次数与难度数值。
|
||||
2. 入口表单能确认题材主题、2D 素材风格和难度选项,并提交派生后的消除次数与难度数值。
|
||||
3. 入口页不展示参考图上传。
|
||||
4. 内置风格显示画风参考图,自定义风格通过独立面板填写并进入提交 payload。
|
||||
5. 移动端入口页所有内容一屏展示,不产生纵向滚动。
|
||||
6. 系统可生成待发布结果页,并在草稿中返回首批切割图片与 OSS GLB 模型素材预览。
|
||||
7. 用户可编辑游戏名称、标签、封面图等基础信息。
|
||||
8. 用户可发布前试玩,且试玩失败不阻断发布。
|
||||
9. 运行态能展示圆形空间、倒计时、物品和 `7` 格备选栏;存在 `generatedItemAssets` 模型时必须优先展示生成 GLB,而不是默认积木素材。
|
||||
10. 物品可重叠、遮挡、堆叠。
|
||||
11. 被完全遮挡物品不可点击,露出可点击区域的物品可点击。
|
||||
12. 点击通过后物品飞入备选栏。
|
||||
13. 备选栏中 `3` 个相同物品 id 自动消除。
|
||||
14. 清空空间中全部物品后胜利。
|
||||
15. 倒计时结束或备选栏满后失败。
|
||||
16. 胜利结算展示使用时间。
|
||||
17. 失败结算展示完成进度和重新开始按钮。
|
||||
18. 局内即时反馈由前端先行呈现,关键状态以后端确认快照校正。
|
||||
19. 相关中文文档通过编码检查。
|
||||
6. 入口页不展示 `生成音效` Toggle;草稿生成不产生 `clickSound`,结果页物品详情仍可手动生成点击音效。
|
||||
7. 系统可生成待发布结果页,并在草稿中返回首批多视角 2D 切割图片素材预览。
|
||||
8. 用户可编辑游戏名称、标签、封面图等基础信息。
|
||||
9. 用户可发布前试玩,且试玩失败不阻断发布。
|
||||
10. 运行态能展示圆形空间、倒计时、物品和 `7` 格备选栏;存在 `generatedItemAssets` 图片素材时必须优先展示生成 2D 素材,而不是默认积木素材。
|
||||
11. 物品可重叠、遮挡、堆叠。
|
||||
12. 被完全遮挡物品不可点击,露出可点击区域的物品可点击。
|
||||
13. 点击通过后物品飞入备选栏。
|
||||
14. 备选栏中 `3` 个相同物品 id 自动消除。
|
||||
15. 清空空间中全部物品后胜利。
|
||||
16. 倒计时结束或备选栏满后失败。
|
||||
17. 胜利结算展示使用时间。
|
||||
18. 失败结算展示完成进度和重新开始按钮。
|
||||
19. 局内即时反馈由前端先行呈现,关键状态以后端确认快照校正。
|
||||
20. 相关中文文档通过编码检查。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@
|
||||
-> 选择“拼图玩法”
|
||||
-> Agent 聊天收束高杠杆锚点
|
||||
-> 生成拼图结果页
|
||||
-> 百梦主生成并确认拼图图片
|
||||
-> 陶泥儿主生成并确认拼图图片
|
||||
-> 发布到拼图广场
|
||||
-> 玩家从广场进入第 1 关
|
||||
-> 全屏拼图运行时
|
||||
@@ -26,7 +26,7 @@
|
||||
|
||||
## 1. 一句话定义
|
||||
|
||||
让百梦主通过 Agent 对话确定拼图作品的高杠杆视觉锚点,再由系统生成结果页、AI 生成拼图图片并发布到广场;玩家进入游戏后,在全屏拼图画布中通过交换、合并、拖动和拆分完成关卡,并沿着“相似题材优先、同作者次优先”的关卡链持续游玩。
|
||||
让陶泥儿主通过 Agent 对话确定拼图作品的高杠杆视觉锚点,再由系统生成结果页、AI 生成拼图图片并发布到广场;玩家进入游戏后,在全屏拼图画布中通过交换、合并、拖动和拆分完成关卡,并沿着“相似题材优先、同作者次优先”的关卡链持续游玩。
|
||||
|
||||
---
|
||||
|
||||
@@ -78,7 +78,7 @@
|
||||
- 拼图关卡名
|
||||
- AI 生成拼图图片的功能
|
||||
- 图片题材标签
|
||||
4. 百梦主发布后的拼图作品必须进入平台广场。
|
||||
4. 陶泥儿主发布后的拼图作品必须进入平台广场。
|
||||
5. 玩家从广场进入某个作品时,第 1 关必须先显示当前作品本身。
|
||||
6. 第 2 关及以后必须按照“标签相似度权重 `70%` + 同作者权重 `30%`”选择下一关。
|
||||
7. 游戏运行时必须全屏展示拼图画布。
|
||||
@@ -129,7 +129,7 @@
|
||||
创建拼图作品
|
||||
-> Agent 聊天收束 5 个视觉锚点
|
||||
-> 生成结果页
|
||||
-> 百梦主确认关卡名、标签、图片
|
||||
-> 陶泥儿主确认关卡名、标签、图片
|
||||
-> 发布到拼图广场
|
||||
```
|
||||
|
||||
@@ -137,12 +137,12 @@
|
||||
|
||||
### 5.1.1 已发布作品二次编辑
|
||||
|
||||
百梦主在“我的创作”中点击自己已发布的拼图作品时,不进入只读详情页,而是回到该作品绑定的拼图结果页继续编辑。独立的“体验”按钮仍然直接进入第 1 关,不与编辑入口混用。
|
||||
陶泥儿主在“我的创作”中点击自己已发布的拼图作品时,不进入只读详情页,而是回到该作品绑定的拼图结果页继续编辑。独立的“体验”按钮仍然直接进入第 1 关,不与编辑入口混用。
|
||||
|
||||
落地规则:
|
||||
|
||||
1. 已发布拼图作品必须优先通过 `sourceSessionId` 恢复原 Agent session。
|
||||
2. 恢复后的结果页沿用原草稿、当前正式图、标题、摘要和标签;百梦主可以继续改标题、摘要、标签,并重新生成图片。
|
||||
2. 恢复后的结果页沿用原草稿、当前正式图、标题、摘要和标签;陶泥儿主可以继续改标题、摘要、标签,并重新生成图片。
|
||||
3. 再次点击发布时不得创建新作品,必须覆盖同一个 `profileId / workId`。
|
||||
4. 覆盖发布只更新作品内容、更新时间、发布时间与广场投影;不得清零 `playCount`,不得改变作品归属。
|
||||
5. 如果历史作品缺少 `sourceSessionId`,前端只能退回作品详情,不伪造编辑 session。
|
||||
@@ -210,9 +210,9 @@
|
||||
|
||||
拼图 Agent 必须做到:
|
||||
|
||||
1. 优先接住百梦主的画面灵感,而不是立刻列问卷。
|
||||
1. 优先接住陶泥儿主的画面灵感,而不是立刻列问卷。
|
||||
2. 每轮只追问当前最影响图片生成质量的 `1` 个问题。
|
||||
3. 当百梦主已经说出足够信息时,优先总结,不重复追问。
|
||||
3. 当陶泥儿主已经说出足够信息时,优先总结,不重复追问。
|
||||
4. 当会话至少完成 `2` 轮后,工作区必须提供 `补充剩余关键字` 快捷动作。
|
||||
- 该动作沿用 RPG 聊天链路,仍走发送消息接口,但请求体必须携带 `quickFillRequested: true`。
|
||||
- 前端不补数据、不伪造锚点状态,只发送“请补充剩余关键字。”作为本轮用户消息。
|
||||
@@ -255,7 +255,7 @@ interface PuzzleAnchorPack {
|
||||
|
||||
## 7.1 结果页定位
|
||||
|
||||
拼图结果页是百梦主从 Agent 共创转入正式发布前的最小工作台。
|
||||
拼图结果页是陶泥儿主从 Agent 共创转入正式发布前的最小工作台。
|
||||
|
||||
它至少承担 5 件事:
|
||||
|
||||
@@ -303,7 +303,7 @@ interface PuzzleAnchorPack {
|
||||
关卡名生成规则建议如下:
|
||||
|
||||
1. 默认由 Agent 根据锚点自动生成 `1` 个正式候选名。
|
||||
2. 百梦主可直接手改。
|
||||
2. 陶泥儿主可直接手改。
|
||||
3. 关卡名长度建议控制在 `4~12` 个中文字符。
|
||||
4. 不允许空标题发布。
|
||||
|
||||
@@ -357,6 +357,7 @@ interface PuzzleAnchorPack {
|
||||
4. 历史素材入口与添加参考图并列放在输入框右下角,打开独立素材选择面板,不在当前面板下方展开。
|
||||
5. UI 不默认写玩法规则说明,只展示必要状态、预览和操作。
|
||||
6. 移动端中输入框右下角按钮必须可点且不遮挡正文输入;输入框需要预留底部内边距。
|
||||
7. 本地上传的非正方形拼图图片进入平台通用正方形图片裁剪弹窗;该弹窗的拖拽裁剪框、八向边界手柄、九宫格辅助线、遮罩和触控行为同时服务拼图图片上传与头像上传,后续不得在头像或拼图侧各自维护一套裁剪交互。
|
||||
|
||||
后端落地契约:
|
||||
|
||||
@@ -678,7 +679,7 @@ V1 规则如下:
|
||||
|
||||
1. 点击道具必须弹出独立确认窗口。
|
||||
2. 确认窗口期间暂停游戏时间。
|
||||
3. 正式后端运行态每次确认消耗 `1` 光点。
|
||||
3. 正式后端运行态每次确认消耗 `1` 泥点。
|
||||
4. 本地调试 run 不伪造钱包扣费,只保持确认、暂停和表现一致。
|
||||
|
||||
---
|
||||
@@ -1160,7 +1161,7 @@ interface PuzzleRunSnapshot {
|
||||
|
||||
完成标准:
|
||||
|
||||
1. 百梦主能从平台进入拼图 Agent 工作区
|
||||
1. 陶泥儿主能从平台进入拼图 Agent 工作区
|
||||
2. 能通过聊天生成结果页草稿
|
||||
|
||||
## 阶段 B:再做结果页与图片资产
|
||||
@@ -1174,7 +1175,7 @@ interface PuzzleRunSnapshot {
|
||||
|
||||
完成标准:
|
||||
|
||||
1. 百梦主能生成正式拼图图片并发布
|
||||
1. 陶泥儿主能生成正式拼图图片并发布
|
||||
2. 作品能进入拼图广场
|
||||
|
||||
## 阶段 C:再做拼图运行时核心循环
|
||||
@@ -1232,4 +1233,4 @@ interface PuzzleRunSnapshot {
|
||||
|
||||
这次平台新增拼图玩法,正确的做法不是只补一个拼图画布,而是:
|
||||
|
||||
**把拼图作为平台内独立玩法类型接进现有 Agent-first 创作中心、结果页、发布链、广场分发链和运行时链,让百梦主先收束高杠杆视觉锚点,让玩家在全屏交换-合并-拆分的拼图循环中持续游玩。**
|
||||
**把拼图作为平台内独立玩法类型接进现有 Agent-first 创作中心、结果页、发布链、广场分发链和运行时链,让陶泥儿主先收束高杠杆视觉锚点,让玩家在全屏交换-合并-拆分的拼图循环中持续游玩。**
|
||||
|
||||
@@ -630,7 +630,7 @@ SSE 事件:
|
||||
|
||||
1. 增加背景音乐和环境音,但不改变四帧三段主链。
|
||||
2. 为移动端生成 `9:16` 竖版裁切版本。
|
||||
3. 支持百梦主手动上传某张关键帧,再生成相邻视频。
|
||||
3. 支持陶泥儿主手动上传某张关键帧,再生成相邻视频。
|
||||
4. 支持发布后版本化替换开场动画。
|
||||
5. 支持用第四幕直接生成开局场景动态背景。
|
||||
6. 支持把开场动画拆出的关键帧回流为作品详情页轮播素材。
|
||||
|
||||
@@ -22,7 +22,7 @@
|
||||
|
||||
接成一条新的稳定流程:
|
||||
|
||||
**每个场景由百梦主在工具中配置为 `2~5` 幕;每一幕都绑定独立背景图和相遇 NPC 顺序;每一幕的第一个 NPC 视为主角色;运行时按幕切换背景和可遇对象,并根据主角色当前好感度裁决聊天轮数与第 5 轮收束方式。**
|
||||
**每个场景由陶泥儿主在工具中配置为 `2~5` 幕;每一幕都绑定独立背景图和相遇 NPC 顺序;每一幕的第一个 NPC 视为主角色;运行时按幕切换背景和可遇对象,并根据主角色当前好感度裁决聊天轮数与第 5 轮收束方式。**
|
||||
|
||||
本次还追加一条必须和草稿生成阶段一起落地的约束:
|
||||
|
||||
@@ -31,13 +31,13 @@
|
||||
补充口径修正:
|
||||
|
||||
1. `scene_chapter` 在本期继续保留为数据层 / 编译层 / 运行时层概念。
|
||||
2. `scene_chapter` 不作为百梦主可见的独立 Tab、独立卡片或独立导航入口。
|
||||
3. 百梦主配置多幕的唯一入口,是现有“场景”列表里的场景编辑弹层。
|
||||
2. `scene_chapter` 不作为陶泥儿主可见的独立 Tab、独立卡片或独立导航入口。
|
||||
3. 陶泥儿主配置多幕的唯一入口,是现有“场景”列表里的场景编辑弹层。
|
||||
4. 每一幕的 NPC 配置区必须直接叠在当前幕背景预览上,以“对面角色站位”的方式呈现;三个站位既是预览,也是编辑入口。
|
||||
5. 幕编辑站位中每个角色只显示角色形象与名称,不展示额外信息块、规则说明或说明性标签。
|
||||
6. 幕内小预览的构图固定为左侧玩家、右侧当前幕角色;右侧三个站位采用一前两后。
|
||||
前排主角色的 y 轴必须与玩家角色对齐;后排两个角色必须同一列、x 轴对齐,上下分布,且后排整体的 y 轴中点与前排主角色保持一致。
|
||||
7. 新建幕默认仅预置 1 个主角色槽位内容,其余槽位留空,等待百梦主补充。
|
||||
7. 新建幕默认仅预置 1 个主角色槽位内容,其余槽位留空,等待陶泥儿主补充。
|
||||
8. 角色名称显示在角色形象上方,角色渲染不附带方形 UI 底板。
|
||||
9. 世界档案的场景详情页不再单独展示“场景图片”和“场景内 NPC”字段;相关兼容数据统一由多幕配置自动同步回场景对象。
|
||||
|
||||
@@ -55,7 +55,7 @@
|
||||
|
||||
本次迭代必须同时满足以下目标:
|
||||
|
||||
1. 百梦主可以在现有创作页面中为每个场景章节配置多幕内容。
|
||||
1. 陶泥儿主可以在现有创作页面中为每个场景章节配置多幕内容。
|
||||
2. 每一幕都必须绑定一张正式背景图。
|
||||
3. 每一幕都可以配置玩家会遇到哪些 NPC,并且保留顺序。
|
||||
4. 每一幕配置的第一个 NPC 必须被系统认定为该幕主角色。
|
||||
@@ -89,7 +89,7 @@
|
||||
|
||||
1. 不新建独立的“场景编辑器”页面。
|
||||
2. 不把幕推进逻辑放到前端本地计算。
|
||||
3. 不让百梦主直接编辑底层运行时 `ChapterState` 或聊天状态对象。
|
||||
3. 不让陶泥儿主直接编辑底层运行时 `ChapterState` 或聊天状态对象。
|
||||
4. 不做多 NPC 并行聊天。
|
||||
5. 不做每一幕的复杂分支树可视化编辑器。
|
||||
6. 不把“规则说明文案”默认堆到创作页或游戏 UI 面板里。
|
||||
@@ -122,7 +122,7 @@
|
||||
1. 场景章节没有“幕”这一层结构化对象。
|
||||
2. 背景图是场景级资产,不是幕级资产。
|
||||
3. NPC 与场景的关系主要还是地点级归属,不是幕级相遇编排。
|
||||
4. 百梦主无法在创作页里明确控制“这一幕谁先出场、谁是主角色”。
|
||||
4. 陶泥儿主无法在创作页里明确控制“这一幕谁先出场、谁是主角色”。
|
||||
|
||||
## 4.2 游戏运行侧现状
|
||||
|
||||
@@ -185,7 +185,7 @@
|
||||
|
||||
这意味着:
|
||||
|
||||
1. 百梦主在工具里编辑的是“第几幕”。
|
||||
1. 陶泥儿主在工具里编辑的是“第几幕”。
|
||||
2. 运行时仍然只认现有章节阶段枚举。
|
||||
3. `chapterDirector` 可以继续复用,只是数据来源从“纯 quest 推导”升级成“quest + 幕蓝图联合推导”。
|
||||
|
||||
@@ -214,7 +214,7 @@
|
||||
- `name`
|
||||
- `description`
|
||||
- `imageSrc`
|
||||
- `sceneNpcIds`(仅作为兼容字段,由多幕配置自动派生,不再作为百梦主可编辑字段)
|
||||
- `sceneNpcIds`(仅作为兼容字段,由多幕配置自动派生,不再作为陶泥儿主可编辑字段)
|
||||
- `connections`
|
||||
- `sceneChapterBlueprints` 对应的多幕配置
|
||||
2. 场景配置面板中,开局场景必须复用普通场景同级的配置 UI,而不是继续保留一套缩水版表单。
|
||||
@@ -251,7 +251,7 @@
|
||||
原因:
|
||||
|
||||
1. 当前创作工作区已经进入“先收关键锚点、再逐步扩写”的阶段。
|
||||
2. 一次铺太多 playable、场景和长尾对象,会稀释百梦主对第一版底稿的掌控感。
|
||||
2. 一次铺太多 playable、场景和长尾对象,会稀释陶泥儿主对第一版底稿的掌控感。
|
||||
3. 本期还要把幕级背景图和角色主形象自动挂回草稿,如果对象规模不收束,等待时间和生成成本都会直接失控。
|
||||
|
||||
### 5.5.2 幕级出演角色与背景必须由剧情引擎判定
|
||||
@@ -309,7 +309,7 @@
|
||||
- 角色主形象是否就绪
|
||||
- 场景幕背景是否就绪
|
||||
|
||||
这样百梦主一进入草稿精修工作区,就能直接看到:
|
||||
这样陶泥儿主一进入草稿精修工作区,就能直接看到:
|
||||
|
||||
1. 角色已经带主形象
|
||||
2. 每个场景章节的每一幕已经带背景图
|
||||
@@ -369,7 +369,7 @@ interface CustomWorldFoundationDraftSceneChapter {
|
||||
1. `primaryNpcId` 必须等于 `encounterNpcIds[0]`,不允许单独填写成别的角色。
|
||||
2. 每幕必须至少有 `1` 个 NPC。
|
||||
3. 每幕必须有 `backgroundImageSrc` 或 `backgroundAssetId`。
|
||||
4. `advanceRule` 由系统按幕位置默认编译,第一版不要求百梦主手改。
|
||||
4. `advanceRule` 由系统按幕位置默认编译,第一版不要求陶泥儿主手改。
|
||||
|
||||
## 6.2 发布到运行时的蓝图结构
|
||||
|
||||
@@ -416,7 +416,7 @@ sceneChapterBlueprints?: SceneChapterBlueprint[] | null;
|
||||
原因:
|
||||
|
||||
1. 现有 `landmarks` 只足够表达地点,不足够表达幕顺序。
|
||||
2. 现有 `ChapterState` 是运行时状态,不适合直接兼做百梦主蓝图。
|
||||
2. 现有 `ChapterState` 是运行时状态,不适合直接兼做陶泥儿主蓝图。
|
||||
3. 独立蓝图层更适合后端编译和发布校验。
|
||||
|
||||
## 6.3 聊天状态扩展
|
||||
@@ -483,9 +483,9 @@ type NpcChatTurnResult = {
|
||||
|
||||
新增规则:
|
||||
|
||||
1. 百梦主从现有“场景”列表点击任一场景卡,进入对应场景编辑弹层。
|
||||
1. 陶泥儿主从现有“场景”列表点击任一场景卡,进入对应场景编辑弹层。
|
||||
2. 多幕配置必须作为场景编辑弹层内的一个区块出现,归属于该场景。
|
||||
3. `scene_chapter` 仅作为保存层和运行时蓝图存在,不单独暴露在百梦主导航里。
|
||||
3. `scene_chapter` 仅作为保存层和运行时蓝图存在,不单独暴露在陶泥儿主导航里。
|
||||
4. 场景卡片可增加“幕数量”轻量摘要,但第一版不是阻塞项。
|
||||
|
||||
## 7.2 场景编辑弹层展示要求
|
||||
@@ -498,8 +498,8 @@ type NpcChatTurnResult = {
|
||||
|
||||
补充约束:
|
||||
|
||||
1. “场景图片”不再作为场景详情页里的独立字段展示,百梦主只能通过每一幕的“配置背景”入口管理视觉。
|
||||
2. “场景内 NPC”不再作为场景详情页里的独立字段展示,百梦主只能通过每一幕角色槽位配置相遇 NPC。
|
||||
1. “场景图片”不再作为场景详情页里的独立字段展示,陶泥儿主只能通过每一幕的“配置背景”入口管理视觉。
|
||||
2. “场景内 NPC”不再作为场景详情页里的独立字段展示,陶泥儿主只能通过每一幕角色槽位配置相遇 NPC。
|
||||
3. 为兼容现有运行时与旧数据结构,场景对象上的 `imageSrc / sceneNpcIds` 仍然保留,但必须由多幕配置自动回填,前台不再暴露单独编辑控件,且不能再用 `sceneNpcIds` 限制每幕可选角色。
|
||||
|
||||
多幕区块至少展示:
|
||||
@@ -566,11 +566,11 @@ NPC 配置面板必须支持:
|
||||
3. 不允许把不存在于当前世界角色池中的 id 写入幕配置。
|
||||
4. 若主角色未与当前场景或线程建立任何关联,给出发布警告。
|
||||
5. 存储时继续落到 `encounterNpcIds` 有序数组,槽位从左到右按顺序压缩写入。
|
||||
6. `sceneNpcIds` 不再作为百梦主字段,也不再作为幕角色选择范围;保存时只从所有幕的 `encounterNpcIds` 自动派生兼容值。
|
||||
6. `sceneNpcIds` 不再作为陶泥儿主字段,也不再作为幕角色选择范围;保存时只从所有幕的 `encounterNpcIds` 自动派生兼容值。
|
||||
|
||||
## 7.6 幕预览
|
||||
|
||||
百梦主在场景编辑弹层里点击“幕预览”后,必须直接进入当前幕的运行时预览。
|
||||
陶泥儿主在场景编辑弹层里点击“幕预览”后,必须直接进入当前幕的运行时预览。
|
||||
|
||||
要求如下:
|
||||
|
||||
@@ -633,7 +633,7 @@ interface SceneActRuntimeState {
|
||||
|
||||
## 8.3 幕推进规则
|
||||
|
||||
第一版不要求百梦主手填推进条件,而是由系统按幕位置默认编译:
|
||||
第一版不要求陶泥儿主手填推进条件,而是由系统按幕位置默认编译:
|
||||
|
||||
1. 第 `1` 幕默认 `after_primary_contact`
|
||||
- 玩家与主角色发生首次有效接触后可进入下一幕判定
|
||||
@@ -871,7 +871,7 @@ Adventure 主面板在本次迭代中至少增加下面这些表现:
|
||||
|
||||
当下面这些结果都成立时,视为本次 PRD 已被正确落地:
|
||||
|
||||
1. 百梦主可以在现有场景编辑弹层中配置每个场景的多幕。
|
||||
1. 陶泥儿主可以在现有场景编辑弹层中配置每个场景的多幕。
|
||||
2. 每个场景章节都可以配置 `2~5` 幕。
|
||||
3. 每一幕都可以绑定独立背景图。
|
||||
4. 每一幕都可以配置有序 NPC 列表,第一位自动成为主角色。
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
## 1. 一句话定义
|
||||
|
||||
“方洞挑战”是一个反直觉形状分拣玩法:百梦主通过 Agent 设定形状主题、洞口规则、误导节奏和反差演出,系统生成一个移动端优先的单局挑战;玩家在限时内把连续出现的形状投入正确洞口,后端根据当前关卡的真实兼容规则裁决成功、失败和连击。
|
||||
“方洞挑战”是一个反直觉形状分拣玩法:陶泥儿主通过 Agent 设定形状主题、洞口规则、误导节奏和反差演出,系统生成一个移动端优先的单局挑战;玩家在限时内把连续出现的形状投入正确洞口,后端根据当前关卡的真实兼容规则裁决成功、失败和连击。
|
||||
|
||||
---
|
||||
|
||||
@@ -130,7 +130,7 @@ Agent 需要把玩家一句灵感收束为上述锚点,不允许逐项盘问
|
||||
|
||||
落地约束:
|
||||
|
||||
1. `replyText` 是直接展示给百梦主的中文回复,不得出现 JSON、字段名、内部结构等说明。
|
||||
1. `replyText` 是直接展示给陶泥儿主的中文回复,不得出现 JSON、字段名、内部结构等说明。
|
||||
2. `nextConfig` 必须是完整配置,不允许只输出 patch;缺失字段只能由后端用当前会话配置兜底。
|
||||
3. `shapeCount` 由后端限制在 `6` 到 `24`,`difficulty` 限制在 `1` 到 `10`。
|
||||
4. `quickFillRequested=true` 时,模型应直接补齐剩余配置,后端把 `progressPercent` 固定为 `100`。
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
## 1. 一句话定义
|
||||
|
||||
`survivor` 是一个 AI 原生幸存者类游戏模板:百梦主通过 Agent 设定主角幻想、敌潮母题、武器技能、成长流派和战场节奏,系统编译出一个移动端优先的俯视角割草生存作品;玩家通过移动躲避敌潮,武器自动攻击,拾取经验升级,在若干分钟内完成生存挑战、击败首领或倒下结算。
|
||||
`survivor` 是一个 AI 原生幸存者类游戏模板:陶泥儿主通过 Agent 设定主角幻想、敌潮母题、武器技能、成长流派和战场节奏,系统编译出一个移动端优先的俯视角割草生存作品;玩家通过移动躲避敌潮,武器自动攻击,拾取经验升级,在若干分钟内完成生存挑战、击败首领或倒下结算。
|
||||
|
||||
---
|
||||
|
||||
@@ -90,7 +90,7 @@
|
||||
3. 不做复杂地形寻路、真实物理碰撞和高精度弹幕编辑器。
|
||||
4. 不做多地图章节战役,只做单局挑战。
|
||||
5. 不做局外装备养成、抽卡、永久技能树或付费强化。
|
||||
6. 不要求百梦主逐帧编辑怪物 AI、弹道曲线或数值公式。
|
||||
6. 不要求陶泥儿主逐帧编辑怪物 AI、弹道曲线或数值公式。
|
||||
7. 不把玩法规则说明长文默认写进 UI 面板。
|
||||
8. 不把按钮弹出的资产、升级或参数编辑做成当前卡片下方展开内容,统一使用独立面板。
|
||||
9. 不让前端本地结算直接写入正式成绩、钱包、任务或排行榜。
|
||||
@@ -161,7 +161,7 @@ Agent 必须围绕用户灵感收束这些锚点,不允许把创作入口做
|
||||
|
||||
落地约束:
|
||||
|
||||
1. `replyText` 是直接展示给百梦主的中文回复,不得出现 JSON、字段名或内部协议说明。
|
||||
1. `replyText` 是直接展示给陶泥儿主的中文回复,不得出现 JSON、字段名或内部协议说明。
|
||||
2. `progressPercent` 只能由后端校验后采纳,范围 `0~100`。
|
||||
3. `nextDraftPatch` 只允许写入幸存者草稿字段,不允许修改平台账号、钱包或作品归属。
|
||||
4. 模型不可用或结果无法解析时,接口返回明确错误,不用固定模板伪装 AI 回复。
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## 0. 文档目的
|
||||
|
||||
这份 PRD 用于设计 `Genarrative / 百梦` 内的 AI 文字游戏模板,暂定工程 ID 为 `text-game`,展示名可用“幕间”或“幕间文字”。它参考 MOKU / 幕间类 AI 互动平台的剧本游乐场、低门槛创作、自由行动、AI 记忆和模拟器强反馈经验,但不迁入任何外部平台工程、账号体系、社区、支付、榜单、论坛或私有存档。
|
||||
这份 PRD 用于设计 `Genarrative / 陶泥儿` 内的 AI 文字游戏模板,暂定工程 ID 为 `text-game`,展示名可用“幕间”或“幕间文字”。它参考 MOKU / 幕间类 AI 互动平台的剧本游乐场、低门槛创作、自由行动、AI 记忆和模拟器强反馈经验,但不迁入任何外部平台工程、账号体系、社区、支付、榜单、论坛或私有存档。
|
||||
|
||||
外部参考只用于提炼产品模式:
|
||||
|
||||
@@ -13,13 +13,13 @@
|
||||
3. TextGame.ai 体现 AI Game Master、模板即玩、自定义世界、AI 队友和持久世界状态。
|
||||
4. Aventura 体现 lorebook、智能记忆、分支故事和本地/隐私优先的创作辅助理念。
|
||||
|
||||
本文只冻结百梦自己的模板落地口径。若后续实现与旧 TXT / visual novel 文档冲突,应按本文与当前后端 DDD 总纲重新修正文档后再编码。
|
||||
本文只冻结陶泥儿自己的模板落地口径。若后续实现与旧 TXT / visual novel 文档冲突,应按本文与当前后端 DDD 总纲重新修正文档后再编码。
|
||||
|
||||
---
|
||||
|
||||
## 1. 一句话定义
|
||||
|
||||
`text-game` 是一个 AI 原生文字游戏模板:百梦主可以用一句话、文档、空白或改作入口创建一个可玩的文字互动剧本,系统把题材、玩家身份、角色、地点、目标、机制、记忆和 GM 规则编译成结构化草稿;玩家进入后通过自由输入或快捷选项推动剧情,后端 AI GM 根据世界状态、长期记忆和阶段目标生成下一轮叙事、状态变化、关系变化和可继续行动。
|
||||
`text-game` 是一个 AI 原生文字游戏模板:陶泥儿主可以用一句话、文档、空白或改作入口创建一个可玩的文字互动剧本,系统把题材、玩家身份、角色、地点、目标、机制、记忆和 GM 规则编译成结构化草稿;玩家进入后通过自由输入或快捷选项推动剧情,后端 AI GM 根据世界状态、长期记忆和阶段目标生成下一轮叙事、状态变化、关系变化和可继续行动。
|
||||
|
||||
---
|
||||
|
||||
@@ -35,7 +35,7 @@
|
||||
|
||||
### 2.2 不等同于 RPG 主运行时
|
||||
|
||||
RPG 主运行时承载百梦现有视觉 RPG、场景探索、战斗、NPC、物品和章节系统。
|
||||
RPG 主运行时承载陶泥儿现有视觉 RPG、场景探索、战斗、NPC、物品和章节系统。
|
||||
|
||||
`text-game` 首版是轻量互动剧本模板,不接入完整地图移动、战斗演出、装备背包、NPC 商店和 RPG 章节任务系统。它可以在以后把成熟剧本升级为 RPG 世界,但 V1 不做自动升级。
|
||||
|
||||
@@ -55,11 +55,11 @@ RPG 主运行时承载百梦现有视觉 RPG、场景探索、战斗、NPC、物
|
||||
|
||||
### 3.1 核心目标
|
||||
|
||||
1. 让百梦主在 3 分钟内从一个想法生成可试玩的文字游戏。
|
||||
1. 让陶泥儿主在 3 分钟内从一个想法生成可试玩的文字游戏。
|
||||
2. 让玩家每一轮行动都看到世界状态、关系或目标推进的反馈。
|
||||
3. 让模板支持高复用题材:恋爱养成、古代言情、宫斗宅斗、修仙仙侠、末日生存、灵异怪谈、科幻未来、经营养成、校园都市、娱乐圈。
|
||||
4. 让剧本不只是聊天对象,而是一个有目标、规则、记忆和结局的轻量模拟器。
|
||||
5. 让作品可以进入百梦作品架、草稿、发布、广场、存档和继续体验链路。
|
||||
5. 让作品可以进入陶泥儿作品架、草稿、发布、广场、存档和继续体验链路。
|
||||
|
||||
### 3.2 首版不追求
|
||||
|
||||
@@ -100,7 +100,7 @@ RPG 主运行时承载百梦现有视觉 RPG、场景探索、战斗、NPC、物
|
||||
3. AI 可以填补空位,作为队友、对手或观众角色参与。
|
||||
4. 世界状态、队伍、库存、任务进度需要持久化。
|
||||
|
||||
百梦落点:
|
||||
陶泥儿落点:
|
||||
|
||||
1. V1 支持单人玩家 + AI 角色群。
|
||||
2. AI 角色群只作为剧本内角色,不做多人房间。
|
||||
@@ -115,7 +115,7 @@ RPG 主运行时承载百梦现有视觉 RPG、场景探索、战斗、NPC、物
|
||||
3. 分支故事需要保存 alternate timeline 的结构,而不是只保存最终文本。
|
||||
4. 创作者需要能查看和修正 AI 记住了什么。
|
||||
|
||||
百梦落点:
|
||||
陶泥儿落点:
|
||||
|
||||
1. V1 只做当前主线历史与局部重生成,不做多时间线编辑器。
|
||||
2. 记忆分为剧本静态设定、运行时事件摘要、角色记忆、玩家画像和未解决伏笔。
|
||||
@@ -125,9 +125,9 @@ RPG 主运行时承载百梦现有视觉 RPG、场景探索、战斗、NPC、物
|
||||
|
||||
## 5. 用户角色
|
||||
|
||||
### 5.1 百梦主
|
||||
### 5.1 陶泥儿主
|
||||
|
||||
百梦主负责创建、编辑、试玩和发布文字游戏。核心诉求是:
|
||||
陶泥儿主负责创建、编辑、试玩和发布文字游戏。核心诉求是:
|
||||
|
||||
1. 用少量输入生成可玩的剧本。
|
||||
2. 控制题材、关系张力、目标、结局和禁区。
|
||||
@@ -197,7 +197,7 @@ RPG 主运行时承载百梦现有视觉 RPG、场景探索、战斗、NPC、物
|
||||
|
||||
### 7.1 一句话创建 `idea`
|
||||
|
||||
输入:百梦主写一句或几句话。
|
||||
输入:陶泥儿主写一句或几句话。
|
||||
|
||||
示例语义:
|
||||
|
||||
@@ -1013,12 +1013,12 @@ src/components/text-game-runtime/TextGameRuntimeShell.tsx
|
||||
|
||||
V1 默认不新增第二套消费单位。若运行时需要扣费:
|
||||
|
||||
1. 使用平台“光点”钱包。
|
||||
1. 使用平台“泥点”钱包。
|
||||
2. 扣费由 `api-server` 编排,不能在前端自行计算。
|
||||
3. 幂等依赖 `clientEventId`。
|
||||
4. 测试 run 是否扣费需要产品确认。
|
||||
|
||||
本文不冻结具体光点数。
|
||||
本文不冻结具体泥点数。
|
||||
|
||||
---
|
||||
|
||||
@@ -1268,10 +1268,10 @@ cargo check -p api-server
|
||||
|
||||
1. 展示名最终用“幕间”“幕间文字”还是“AI文字游戏”。
|
||||
2. V1 是否开放 `remix`。
|
||||
3. V1 测试 run 是否消耗光点。
|
||||
3. V1 测试 run 是否消耗泥点。
|
||||
4. V1 是否允许创作者配置封面图。
|
||||
5. V1 是否开放 `allowOutOfCharacterCommand`。
|
||||
6. V1 是否需要接入内容审核队列后才允许公开发布。
|
||||
7. 作品发现页是否单独展示文字游戏分类入口。
|
||||
|
||||
无论这些默认值如何选择,三条硬边界不变:只做百梦内的 AI 文字游戏模板,复用平台接口,不迁入外部平台和 replay。
|
||||
无论这些默认值如何选择,三条硬边界不变:只做陶泥儿内的 AI 文字游戏模板,复用平台接口,不迁入外部平台和 replay。
|
||||
|
||||
@@ -683,7 +683,7 @@ GET /api/runtime/profile/save-archives
|
||||
|
||||
1. 创作底稿生成和运行时 GM 输出由 `api-server` 编排 `platform-llm`,SpacetimeDB reducer 不直接调用 LLM。
|
||||
2. 图片和音乐生成 / 上传由 `api-server` 编排平台资产服务,不把二进制写入 SpacetimeDB。
|
||||
3. 消耗光点时走平台钱包流水;不得迁入外部仓库积分表。
|
||||
3. 消耗泥点时走平台钱包流水;不得迁入外部仓库积分表。
|
||||
4. prompt 必须输出可解析 JSON step 或工具调用结果;解析失败时由后端 repair,不让前端猜测业务状态。
|
||||
|
||||
---
|
||||
@@ -1801,7 +1801,7 @@ cargo check -p api-server
|
||||
|
||||
这些问题不阻塞本文冻结边界,但进入编码前需要产品确认默认值:
|
||||
|
||||
1. 视觉小说运行时 AI 推进是否首版收费,以及单次推进默认光点数。
|
||||
1. 视觉小说运行时 AI 推进是否首版收费,以及单次推进默认泥点数。
|
||||
2. 文档上传首版支持的最大大小和格式。
|
||||
3. 角色立绘、场景图是否首版自动生成,还是仅提供手动上传和后续生成按钮。
|
||||
4. 属性面板是否首版关闭,还是只对内部白名单开启。
|
||||
|
||||
101
docs/prd/BABY_LOVE_DRAWING_EDUTAINMENT_LEVEL_PRD_2026-05-13.md
Normal file
101
docs/prd/BABY_LOVE_DRAWING_EDUTAINMENT_LEVEL_PRD_2026-05-13.md
Normal file
@@ -0,0 +1,101 @@
|
||||
# 宝贝爱画寓教于乐独立关卡 PRD 2026-05-13
|
||||
|
||||
## 1. 目标
|
||||
|
||||
新增寓教于乐内容线独立关卡:
|
||||
|
||||
```text
|
||||
宝贝爱画
|
||||
```
|
||||
|
||||
工程 ID 固定为:
|
||||
|
||||
```text
|
||||
baby-love-drawing
|
||||
```
|
||||
|
||||
该关卡默认出现在“发现 / 寓教于乐”板块下方。当前阶段只做本地 Demo 保存,验证完成后再补正式持久化。
|
||||
|
||||
## 2. 关卡结构
|
||||
|
||||
启动宝贝爱画后进入绘画运行态:
|
||||
|
||||
1. 屏幕中央是带边框的空白画板;
|
||||
2. 画板边框内是可绘画区域;
|
||||
3. 画板外左侧展示彩虹 7 色;
|
||||
4. 画板外右侧中下方展示画笔和橡皮;
|
||||
5. 用户进入内容后默认手持画笔;
|
||||
6. 手持画笔或橡皮时,屏幕上实时显示跟随右手位置的工具图案标识。
|
||||
|
||||
## 3. 输入规则
|
||||
|
||||
颜色选择:
|
||||
|
||||
1. 仅检测左手;
|
||||
2. 左手悬停在某个颜色区域 1.5 秒后,选中该颜色;
|
||||
3. 颜色固定为彩虹 7 色。
|
||||
|
||||
工具切换:
|
||||
|
||||
1. 右手移动到画笔或橡皮工具区域;
|
||||
2. 右手握拳后,将手里的工具切换为对应工具。
|
||||
|
||||
绘画与擦除:
|
||||
|
||||
1. 右手在画布区域握拳时,当前工具生效;
|
||||
2. 当前工具为画笔时留下轨迹;
|
||||
3. 当前工具为橡皮时擦除轨迹;
|
||||
4. 右手张开时,画笔或橡皮抬起,不在画布上生效。
|
||||
|
||||
按钮选择:
|
||||
|
||||
1. 完成;
|
||||
2. 使用绘画魔法;
|
||||
3. 保存;
|
||||
4. 再画一张;
|
||||
5. 返回。
|
||||
|
||||
以上按钮都使用任一手悬停 2 秒完成选中。
|
||||
|
||||
## 4. 绘画魔法
|
||||
|
||||
用户完成绘画后,可使用“绘画魔法”。
|
||||
|
||||
绘画魔法使用 image-2,以用户绘画内容和笔触轨迹生成对应绘本风格图片内容。
|
||||
|
||||
前端不得直接读取、拼接或暴露图片生成密钥。image-2 调用必须通过后端代理。
|
||||
|
||||
## 5. 保存规则
|
||||
|
||||
当前只做本地 Demo 保存。
|
||||
|
||||
保存规则:
|
||||
|
||||
1. 魔法生成前保存,只保存一张原图;
|
||||
2. 若用户未保存原图,直接点击魔法生成,则魔法生成后保存时同时保存原图和魔法图;
|
||||
3. 保存完毕后,可继续“再画一张”或“返回”。
|
||||
|
||||
## 6. 展示与开关
|
||||
|
||||
宝贝爱画只属于寓教于乐内容线。
|
||||
|
||||
`VITE_ENABLE_EDUTAINMENT_ENTRY` 关闭时:
|
||||
|
||||
1. 不展示“发现 / 寓教于乐”频道;
|
||||
2. 不展示宝贝爱画默认卡片;
|
||||
3. 不允许通过 `/runtime/baby-love-drawing` 直达运行态。
|
||||
|
||||
## 7. 验收
|
||||
|
||||
1. 寓教于乐开启时,“发现 / 寓教于乐”下方展示“宝贝爱画”默认关卡卡片;
|
||||
2. 寓教于乐关闭时,不展示宝贝爱画,也不能直达运行态;
|
||||
3. 进入后展示空白画板、彩虹 7 色、画笔和橡皮;
|
||||
4. 默认工具为画笔;
|
||||
5. 左手悬停颜色 1.5 秒后选中颜色;
|
||||
6. 右手移动到工具区并握拳后切换画笔或橡皮;
|
||||
7. 右手握拳在画布内绘制或擦除,张开时不生效;
|
||||
8. 任一手悬停按钮 2 秒后触发按钮;
|
||||
9. 完成后可保存原图;
|
||||
10. 完成后可使用绘画魔法生成绘本风格图片;
|
||||
11. 未保存原图直接使用绘画魔法后,保存会同时保存原图和魔法图;
|
||||
12. 保存后可再画一张或返回。
|
||||
@@ -0,0 +1,117 @@
|
||||
# 宝贝识物寓教于乐模板 PRD 2026-05-11
|
||||
|
||||
## 1. 目标
|
||||
|
||||
新增寓教于乐内容线的创作模板:
|
||||
|
||||
```text
|
||||
宝贝识物
|
||||
```
|
||||
|
||||
创作者必须通过该模板创作并发布作品后,用户才能在寓教于乐板块体验对应关卡。
|
||||
|
||||
本模板只服务儿童动作 Demo 内容线,不把普通教育题材作品自动归入寓教于乐。
|
||||
|
||||
## 2. 创作输入
|
||||
|
||||
创作者必须填写两个物品名称:
|
||||
|
||||
1. 物品 A 名称;
|
||||
2. 物品 B 名称。
|
||||
|
||||
两个名称都必须去除首尾空白后非空。当前阶段不新增题材、难度、计时、失败次数、分数、体力或递增规则。
|
||||
|
||||
## 3. 生成规则
|
||||
|
||||
提交后生成一份宝贝识物草稿,草稿包含:
|
||||
|
||||
1. 模板 ID:`baby-object-match`;
|
||||
2. 模板名称:`宝贝识物`;
|
||||
3. 两个物品;
|
||||
4. 两个物品图;
|
||||
5. 游戏视觉主题包;
|
||||
6. 作品标签。
|
||||
|
||||
物品图使用 VectorEngine `gpt-image-2-all` / image-2 生成。图片生成只能走后端接口,前端不得读取、拼接或暴露 `VECTOR_ENGINE_API_KEY`。
|
||||
|
||||
每个关键词只生成一张围绕该关键词的单一物品形象。生成 prompt 必须锁定寓教于乐板块统一的卡通绘本草地舞台插画风,但最终画面不生成背景、场景、氛围渲染、人物、手、篮子、礼物盒、文字、水印或 UI。服务端必须把生成结果转成透明 PNG,并执行透明抠图后处理;只有透明抠图后的素材才允许写入草稿 `itemAssets` 并进入游戏运行态。
|
||||
|
||||
同一次创作还必须使用 image-2 生成游戏视觉主题包,包含背景环境、UI 装饰框、礼物盒、篮子和烟雾弹出特效资源。主题包必须继续保持寓教于乐插画风,并根据用户填写的两个物品关键词匹配主题:例如关键词偏动漫角色或玩具时,背景环境和元素可使用动漫、玩具主题;关键词偏水果时,背景环境和元素可匹配果园、自然主题;其它关键词按其语义匹配合适主题。主题包不得改变关卡玩法规则,不新增文字说明、额外按钮或额外判定规则。
|
||||
|
||||
视觉主题包的资源边界:
|
||||
|
||||
1. 背景环境图不做透明抠图,但必须保证屏幕中间、中下方和底部左右篮子区域清爽,不遮挡放大后的物品、礼物盒和篮子;
|
||||
2. UI 装饰框用于字幕条和计数器风格化包装,只生成装饰边框和主题点缀,不生成文字、数字或按钮;
|
||||
3. 礼物盒资源输出为透明 PNG,运行态按当前礼盒视觉的 2 倍尺寸展示,素材主体必须饱满清晰;
|
||||
4. 篮子资源输出为透明 PNG,运行态按当前篮子视觉的 1.5 倍尺寸展示,左右篮子仍固定为两个物品对应选项,篮子造型资源可以复用同一张主题篮子图;
|
||||
5. 烟雾弹出特效资源输出为透明 PNG,用于礼物盒打开瞬间覆盖开盒区域并承接中央物品弹出,不生成物品、篮子、礼物盒或文字。
|
||||
|
||||
当前本地 Demo 阶段已接入真实 image-2 资源链路。创作提交必须成功获得 `generationProvider = "vector-engine-gpt-image-2"` 的两个物品透明 PNG 和完整视觉主题包后,才能进入结果页、试玩或发布;若后端接口、登录态、VectorEngine 配置或上游生成失败,前端必须停留在生成失败状态并展示错误,不得静默回退为占位图。历史草稿中若仍存在 `generationProvider = "placeholder"` 的占位资源,结果页必须提示重新生成,试玩和发布前必须先补齐 image-2 资源。
|
||||
|
||||
## 4. 标签规则
|
||||
|
||||
发布作品必须携带精确标签:
|
||||
|
||||
```text
|
||||
寓教于乐
|
||||
```
|
||||
|
||||
标签识别只接受精确等于 `寓教于乐`。不接受 `儿童教育`、`动作教育`、`寓教于乐 ` 等近似标签。
|
||||
|
||||
宝贝识物草稿与发布 payload 中都必须保留该标签。发布后的公开展示、搜索、深链和入口开关继续遵循 `CHILD_MOTION_EDUTAINMENT_DISCOVER_ENTRY_2026-05-09.md`。
|
||||
|
||||
## 5. 结果页能力
|
||||
|
||||
结果页展示:
|
||||
|
||||
1. 作品名称;
|
||||
2. 两个物品名称;
|
||||
3. 两个物品图;
|
||||
4. 标签;
|
||||
5. 保存草稿;
|
||||
6. 发布;
|
||||
7. 试玩。
|
||||
|
||||
结果页不展示长规则说明文案。试玩按钮直接进入宝贝识物首关本地运行态。
|
||||
|
||||
试玩按钮进入宝贝识物首关运行态,运行态消费当前草稿中的两个物品名称和两张物品图,不重新生成或改写物品内容。
|
||||
|
||||
若草稿包含视觉主题包,运行态还必须消费该主题包中的背景环境、UI 装饰、礼物盒、篮子和烟雾弹出特效资源;旧草稿或接口失败时允许回退到当前 CSS 绘本风兜底。
|
||||
|
||||
## 6. 发布后体验
|
||||
|
||||
发布完成后作品应进入寓教于乐内容线,并在寓教于乐入口开启时可被板块消费。
|
||||
|
||||
入口关闭时,发布作品完全不可见,不能通过推荐、发现普通频道、搜索、作品号、公开详情深链或浏览历史访问。
|
||||
|
||||
## 7. 与运行时线程的边界
|
||||
|
||||
本 PRD 同步约束首关运行态,已确认规则包括:
|
||||
|
||||
1. 进入关卡后礼物盒自动打开并弹出首个随机物品;
|
||||
2. 每轮仅中间礼物盒跳出的物品随机;左右两侧篮子固定为当前草稿两个物品的顺序;
|
||||
3. 下一关按钮当前占位;
|
||||
4. 不新增用户未确认的计时、失败次数、分数、体力或难度递增。
|
||||
5. 屏幕中上方字幕固定为“将物品放入对应的篮子里”。
|
||||
6. 礼物盒位于屏幕中下方并按当前视觉放大一倍,首次进入关卡和每次正确反馈结束后的新轮次都从上方落下后自动打开。
|
||||
7. 屏幕下方左侧和右侧分别展示两个固定篮子,左侧固定使用草稿第一个物品图,右侧固定使用草稿第二个物品图。
|
||||
8. 左右篮子按当前视觉放大 50%。
|
||||
9. 礼物盒打开时播放烟雾特效,中央物品从烟雾特效中弹出;物品弹出后礼物盒从舞台移除。
|
||||
10. 明确左手连续横向移动达到阈值时将当前物品送入左侧篮子,明确右手连续横向移动达到阈值时将当前物品送入右侧篮子;选篮不使用动作名判定,侧别未知的手部轨迹不参与选篮。
|
||||
11. 正确时展示“真棒”字幕和正确特效;错误时展示“再想一想吧”字幕和错误特效,物品回到中央。
|
||||
12. 成功 20 次后展示“恭喜你!小朋友!”字幕和特效,并展示“再来一次”和“下一关”按钮。
|
||||
13. 当前本地 Demo 阶段音效与语音播报接口只预留调用点,不在前端写死外部硬件或服务接口。
|
||||
|
||||
## 8. 验收
|
||||
|
||||
1. 创作入口显示 `宝贝识物` 并可进入模板表单。
|
||||
2. 未填写任一物品名称时不能生成草稿。
|
||||
3. 生成草稿后进入结果页,展示两个物品名称和物品图。
|
||||
4. 生成草稿后包含视觉主题包,主题包含背景环境、UI 装饰框、礼物盒、篮子和烟雾弹出特效资源。
|
||||
5. 草稿标签中始终包含精确 `寓教于乐`。
|
||||
6. 发布 payload 始终包含精确 `寓教于乐`。
|
||||
7. 发布完成后出现分享弹窗或发布完成状态。
|
||||
8. 前端不读取或暴露 VectorEngine 密钥。
|
||||
9. 结果页试玩进入宝贝识物运行态,不再显示“试玩关卡正在接入中”。
|
||||
10. 运行态通过鼠标左键拖动映射左手横向移动,通过鼠标右键拖动映射右手横向移动。
|
||||
11. 成功 20 次后出现“再来一次”和“下一关”按钮。
|
||||
@@ -12,7 +12,7 @@ Phase 1 的目标不是重做现有拼图创作系统,也不是把 Agent 降
|
||||
|
||||
## 1. 一句话定义
|
||||
|
||||
Phase 1 是一个“只开放拼图模板的创意互动内容生成 Agent”:它必须先展示多个拼图模板候选,用户选择某个模板后,再确认该模板下的关卡模式、关卡数和预计光点范围;确认后才通过拼图模块 Tool 填充同一份 `PuzzleResultDraft` 草稿字段,并复用现有 `puzzle-result` 和 `puzzle-runtime` 完成表单编辑、自然语言修订和立即试玩闭环。
|
||||
Phase 1 是一个“只开放拼图模板的创意互动内容生成 Agent”:它必须先展示多个拼图模板候选,用户选择某个模板后,再确认该模板下的关卡模式、关卡数和预计泥点范围;确认后才通过拼图模块 Tool 填充同一份 `PuzzleResultDraft` 草稿字段,并复用现有 `puzzle-result` 和 `puzzle-runtime` 完成表单编辑、自然语言修订和立即试玩闭环。
|
||||
|
||||
---
|
||||
|
||||
@@ -91,7 +91,7 @@ APIMart Responses 请求必须按多模态内容块组织:
|
||||
1. 新增 `platform-agent` PoC crate,封装 LangChain-Rust 的 Function Calling / AgentExecutor 能力。
|
||||
2. 新增创意 Agent shared contract,支持阶段、消息、模板选择、积分范围、关卡图片计划、目标拼图 session 绑定。
|
||||
3. 新增拼图模板协议,当前只提供一个可用拼图模板,但仍必须显式展示选择步骤。
|
||||
4. 拼图模板卡必须展示模板标题、预览、选择理由、单关卡/多关卡能力、计划关卡数、预计光点范围。
|
||||
4. 拼图模板卡必须展示模板标题、预览、选择理由、单关卡/多关卡能力、计划关卡数、预计泥点范围。
|
||||
5. 用户确认模板后,Agent 才能创建或复用拼图 session,并填充 `PuzzleResultDraft`。
|
||||
6. Agent 可写草稿字段只允许:
|
||||
- `PuzzleResultDraft.workTitle`
|
||||
@@ -133,7 +133,7 @@ APIMart Responses 请求必须按多模态内容块组织:
|
||||
-> Agent 思考并选择拼图模板
|
||||
-> 前端展示多个拼图模板卡
|
||||
-> 用户选择一个模板
|
||||
-> 前端弹出该模板的关卡模式、关卡数和预计光点范围确认面板
|
||||
-> 前端弹出该模板的关卡模式、关卡数和预计泥点范围确认面板
|
||||
-> Agent 调用拼图模块 Tool 生成草稿字段和图片计划
|
||||
-> 拼图模块创建 / 更新 puzzle_agent_session
|
||||
-> 拼图模块生成单关卡或多关卡图片候选
|
||||
@@ -174,7 +174,7 @@ Agent 生成草稿前必须展示独立确认卡。确认卡字段:
|
||||
| 选择理由 | `reason` | 一到两句中文,不展示内部推理链。 |
|
||||
| 关卡模式 | `selectedLevelMode` | 单关卡 / 多关卡。 |
|
||||
| 计划关卡数 | `plannedLevelCount` | 在模板 min/max 内。 |
|
||||
| 预计光点 | `costRange` | 显示 `minPoints` 到 `maxPoints` 光点。 |
|
||||
| 预计泥点 | `costRange` | 显示 `minPoints` 到 `maxPoints` 泥点。 |
|
||||
|
||||
交互:
|
||||
|
||||
@@ -529,7 +529,7 @@ done
|
||||
事件要求:
|
||||
|
||||
1. `messages/stream` 首轮必须先返回 `puzzle_template_catalog`,并把 `puzzleTemplateCatalog` 写入 session,`puzzleTemplateSelection` 保持为空。
|
||||
2. 用户点击某个模板后,前端基于模板协议打开独立配置确认面板,确认关卡模式、关卡数和预计光点范围。
|
||||
2. 用户点击某个模板后,前端基于模板协议打开独立配置确认面板,确认关卡模式、关卡数和预计泥点范围。
|
||||
3. `confirm-template` 后才允许写入 `puzzle_template_selection`、`puzzle_level_plan` 并创建拼图草稿。
|
||||
4. `target_session` 必须带 `targetSessionId` 和可跳转 stage。
|
||||
5. 流式失败时保留已显示文字,并发送结构化 `error`。
|
||||
@@ -719,7 +719,7 @@ Agent 必须被提示为:
|
||||
1. 你是创意互动内容生成 Agent,不是规则分类器。
|
||||
2. 当前产品只开放拼图模板。
|
||||
3. 你要相信自己的图文理解能力,主动形成拼图创意。
|
||||
4. 即使只有拼图可用,也必须显式选择模板并展示预计光点范围。
|
||||
4. 即使只有拼图可用,也必须显式选择模板并展示预计泥点范围。
|
||||
5. 未经用户确认模板,不得创建草稿。
|
||||
6. 你只能调用已注册工具。
|
||||
7. 可写草稿字段只限 `workTitle`、`workDescription`、`workTags`、`levels[].levelName`、`levels[].pictureDescription`、`levels[].pictureReference`。
|
||||
@@ -996,7 +996,7 @@ npm run test -- PuzzleResultView
|
||||
4. `PuzzleResultView` 已显示并编辑 `levels[].pictureReference`,并在智能创作链路进入结果页时显示自然语言修订输入条,调用 `streamCreativeDraftEdit` 后回写同一份拼图 session。
|
||||
5. 前端定向验证已通过:`npm run typecheck`、`npm run check:encoding`、`npx eslint src/services/creative-agent/creativeAgentClient.ts src/services/creative-agent/creativeAgentSse.ts src/services/creative-agent/index.ts src/components/creative-agent/CreativeAgentWorkspace.tsx src/components/creative-agent/CreativeAgentInputComposer.tsx src/components/creative-agent/CreativeAgentTemplateConfirmPanel.tsx src/components/creative-agent/CreativeAgentStageTimeline.tsx src/components/creative-agent/creativeAgentViewModel.ts src/components/platform-entry/PlatformEntryFlowShellImpl.tsx src/components/platform-entry/platformEntryCreationTypes.ts src/components/platform-entry/PlatformEntryCreationTypeModal.tsx src/components/puzzle-result/PuzzleResultView.tsx --max-warnings 0`、`npm run test -- src/services/creative-agent/creativeAgentSse.test.ts`、`npm run test -- src/components/puzzle-result/PuzzleResultView.test.tsx`、`npm run test -- src/components/platform-entry/platformEntryCreationTypes.test.ts src/components/custom-world-home/CustomWorldCreationHub.interaction.test.tsx`、`npm run test -- src/components/rpg-entry/RpgEntryFlowShell.agent.interaction.test.tsx -t "create hub hides RPG"`。
|
||||
|
||||
6. 2026-05-05 补充:智能创作工作区的过程区不再只展示最近 6 个短进度标签,改为基于 SSE 事件生成详细过程项,覆盖阶段切换、工具开始/完成、模板选择、预计光点、关卡计划、反思、目标绑定、错误和完成事件;刷新或非流式恢复时会从 session 快照补模板、关卡计划和目标绑定,移动端使用紧凑可滚动列表。
|
||||
6. 2026-05-05 补充:智能创作工作区的过程区不再只展示最近 6 个短进度标签,改为基于 SSE 事件生成详细过程项,覆盖阶段切换、工具开始/完成、模板选择、预计泥点、关卡计划、反思、目标绑定、错误和完成事件;刷新或非流式恢复时会从 session 快照补模板、关卡计划和目标绑定,移动端使用紧凑可滚动列表。
|
||||
|
||||
7. 2026-05-05 补充:流式过程新增 `thought_summary_delta` 事件,只展示可给用户看的“思考摘要”,例如素材理解、模板选择摘要和关卡规划摘要;该事件不承载模型内部推理链,前端按 `thoughtId` 合并多段 delta 后在过程面板中显示为一条持续更新的“思考摘要”。
|
||||
8. 2026-05-06 补充:智能创作 Agent 的模板步骤拆成两段,`messages/stream` 只返回 `puzzle_template_catalog` 和 session 里的 `puzzleTemplateCatalog`;前端先展示多个模板卡,用户选中后才打开独立确认面板并提交 `confirm-template`。`puzzle_template_selection`、`puzzle_cost_range` 和 `puzzle_level_plan` 不再由首轮消息流自动发送。工作区在 `sessionId` 变化时必须清空本地待确认模板,避免上一会话已点开的确认面板残留到新会话。
|
||||
@@ -1051,7 +1051,7 @@ cargo check -p api-server
|
||||
|
||||
1. 任务 G 已补 API facade 回归:`cargo test -p api-server creative_agent` 覆盖未确认模板时 `draft-edits/stream` 返回错误且不绑定 `targetBinding`,以及 `rpg.unsupported` 非拼图模板确认被拒绝且不创建目标 session。
|
||||
2. 任务 G 已补拼图模块回归:`cargo test -p module-puzzle creative` 同时覆盖单关卡、多关卡 draft 和 `pictureReference` / `workDescription -> summary` / `workTags -> themeTags` 的 Phase 1 映射。
|
||||
3. 任务 G 已补前端回归:`CreativeAgentTemplateConfirmPanel.test.tsx` 覆盖模板确认卡光点范围,`CreativeAgentWorkspace.test.tsx` 覆盖 target ready 后展示打开草稿入口,并通过 `resolveCreativeAgentTargetSelectionStage` 固定 `puzzle-result` 跳转落点;`creativeAgentSse.test.ts` 覆盖 creative Agent SSE 事件与 draft edit payload。
|
||||
3. 任务 G 已补前端回归:`CreativeAgentTemplateConfirmPanel.test.tsx` 覆盖模板确认卡泥点范围,`CreativeAgentWorkspace.test.tsx` 覆盖 target ready 后展示打开草稿入口,并通过 `resolveCreativeAgentTargetSelectionStage` 固定 `puzzle-result` 跳转落点;`creativeAgentSse.test.ts` 覆盖 creative Agent SSE 事件与 draft edit payload。
|
||||
4. 定向验收已通过:`npm run check:encoding`、`npm run test -- src/components/creative-agent/CreativeAgentWorkspace.test.tsx src/components/creative-agent/CreativeAgentTemplateConfirmPanel.test.tsx src/services/creative-agent/creativeAgentSse.test.ts`、`npm run test -- src/components/puzzle-result/PuzzleResultView.test.tsx`、`cargo test -p module-puzzle creative`、`cargo test -p module-puzzle puzzle_draft`、`cargo test -p shared-contracts creative_agent`、`cargo test -p api-server creative_agent`、`cargo check -p api-server`。
|
||||
5. 全量 `npm run typecheck` 当前被视觉小说链路既有类型错误阻塞,包含 `packages/shared/src/contracts/visualNovel.ts`、`src/components/platform-entry/PlatformEntryFlowShellImpl.tsx` 的 `onSelectVisualNovel` 缺失和 `src/components/visual-novel-result/VisualNovelResultView.tsx`;全量 `npm run test` 当前被既有 RPG 首页搜索 / 拼图 workspace 旧断言等非本任务用例阻塞。上述阻塞不来自本次 creative-agent Task G 回归补测。
|
||||
|
||||
@@ -1095,7 +1095,7 @@ cargo check -p api-server
|
||||
1. 用户从创作中心进入创意 Agent。
|
||||
2. 用户输入文字和 1 张图片后,SSE 显示感知和思考阶段。
|
||||
3. Agent 显式展示拼图模板确认卡。
|
||||
4. 确认卡显示预计光点范围。
|
||||
4. 确认卡显示预计泥点范围。
|
||||
5. 未确认模板时不会创建拼图草稿。
|
||||
6. 确认模板后进入草稿生成。
|
||||
7. 生成的草稿字段对齐 `workTitle`、`workDescription`、`workTags`、`levels[].levelName`、`levels[].pictureDescription`、`levels[].pictureReference`。
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## 0. 目标
|
||||
|
||||
把“光点 / 游戏时长 / 玩过”这一排信息卡,从静态数字展示升级成稳定的个人数据看板,让玩家在进入“我的”页时一眼知道自己的账号资产和游玩投入。
|
||||
把“泥点 / 游戏时长 / 玩过”这一排信息卡,从静态数字展示升级成稳定的个人数据看板,让玩家在进入“我的”页时一眼知道自己的账号资产和游玩投入。
|
||||
|
||||
---
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
当前三个数字来源并不统一:
|
||||
|
||||
1. 光点来自当前存档上下文,不等于账号总资产
|
||||
1. 泥点来自当前存档上下文,不等于账号总资产
|
||||
2. 游戏时长依赖当前快照,不代表全账号累计
|
||||
3. 玩过当前几乎是硬编码推导,不是真实统计
|
||||
|
||||
@@ -39,11 +39,11 @@
|
||||
|
||||
## 3. 指标定义
|
||||
|
||||
## 3.1 光点
|
||||
## 3.1 泥点
|
||||
|
||||
定义:
|
||||
|
||||
- 当前账号可立即消费的光点余额
|
||||
- 当前账号可立即消费的泥点余额
|
||||
|
||||
不使用:
|
||||
|
||||
@@ -80,7 +80,7 @@
|
||||
|
||||
点击行为:
|
||||
|
||||
1. 光点卡
|
||||
1. 泥点卡
|
||||
- 打开资产流水抽屉
|
||||
2. 游戏时长卡
|
||||
- 打开游玩统计抽屉
|
||||
@@ -125,7 +125,7 @@
|
||||
|
||||
返回:
|
||||
|
||||
- 光点流水列表
|
||||
- 泥点流水列表
|
||||
|
||||
### `GET /api/profile/play-stats`
|
||||
|
||||
|
||||
@@ -73,7 +73,7 @@
|
||||
|
||||
首期奖励建议采用可控方案:
|
||||
|
||||
1. 邀请人获得光点
|
||||
1. 邀请人获得泥点
|
||||
2. 被邀请人获得新手奖励
|
||||
|
||||
所有奖励必须走台账,不允许前端本地加值。
|
||||
@@ -164,4 +164,4 @@
|
||||
1. 用户能看到自己的邀请码与邀请链接
|
||||
2. 可以一键复制或分享
|
||||
3. 邀请成功后能看到正确统计
|
||||
4. 奖励到账后光点余额同步变化
|
||||
4. 奖励到账后泥点余额同步变化
|
||||
|
||||
@@ -51,11 +51,11 @@
|
||||
首期只保留两种状态:
|
||||
|
||||
1. `普通用户`
|
||||
2. `百梦会员`
|
||||
2. `陶泥儿会员`
|
||||
|
||||
会员权益首期建议控制在直接可编码的范围:
|
||||
|
||||
1. 每日额外光点领取额度
|
||||
1. 每日额外泥点领取额度
|
||||
2. 高级世界模板或创作槽位
|
||||
3. 更高的云存档上限
|
||||
4. 会员专属标识
|
||||
@@ -119,7 +119,7 @@
|
||||
支付成功后:
|
||||
|
||||
1. 刷新会员状态
|
||||
2. 刷新光点余额
|
||||
2. 刷新泥点余额
|
||||
3. 刷新权益标签
|
||||
|
||||
---
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
1. 头像编辑
|
||||
2. 昵称编辑
|
||||
3. 百梦号展示与复制
|
||||
3. 陶泥号展示与复制
|
||||
4. 登录方式与绑定状态展示
|
||||
5. 进入资料编辑抽屉
|
||||
|
||||
@@ -22,7 +22,7 @@
|
||||
|
||||
- 头像占位
|
||||
- 昵称
|
||||
- 百梦号
|
||||
- 陶泥号
|
||||
- 登录方式
|
||||
- 绑定状态
|
||||
|
||||
@@ -31,7 +31,7 @@
|
||||
1. 头像按钮和昵称编辑按钮都直接打开账号弹窗,信息架构混在一起
|
||||
2. 头像当前只是视觉壳,没有真正的上传与裁剪能力
|
||||
3. 昵称缺少明确的编辑规则与唯一性策略
|
||||
4. 百梦号只是前端拼接值,不适合长期作为正式公开识别码
|
||||
4. 陶泥号只是前端拼接值,不适合长期作为正式公开识别码
|
||||
|
||||
---
|
||||
|
||||
@@ -43,7 +43,7 @@
|
||||
2. 资料编辑抽屉
|
||||
3. 头像上传、裁切、保存
|
||||
4. 昵称编辑、校验、保存
|
||||
5. 百梦号固定生成与复制
|
||||
5. 陶泥号固定生成与复制
|
||||
6. 登录方式与账号状态标签展示
|
||||
|
||||
## 2.2 本期不做
|
||||
@@ -63,7 +63,7 @@
|
||||
|
||||
- 用户头像
|
||||
- 用户昵称
|
||||
- `百梦号`
|
||||
- `陶泥号`
|
||||
- 登录方式标签
|
||||
- 账号状态标签
|
||||
- 资料编辑入口
|
||||
@@ -85,7 +85,7 @@
|
||||
- 打开“编辑资料”抽屉,并默认聚焦头像编辑区域
|
||||
2. 点击昵称右侧编辑按钮
|
||||
- 打开“编辑资料”抽屉,并默认聚焦昵称输入框
|
||||
3. 点击百梦号复制按钮
|
||||
3. 点击陶泥号复制按钮
|
||||
- 直接复制,并给出轻提示
|
||||
4. 点击登录方式/状态标签
|
||||
- 不跳页,不弹复杂说明
|
||||
@@ -103,6 +103,7 @@
|
||||
3. 上传后进入正方形裁切
|
||||
4. 服务端生成 `256x256` 主图和 `96x96` 缩略图
|
||||
5. 超过大小或格式限制时直接拦截
|
||||
6. 头像裁切工具必须复用平台通用正方形图片裁剪弹窗,并与拼图图片上传裁剪保持同一套拖拽裁剪框、八向边界手柄、九宫格辅助线、遮罩和移动端触控行为;不得在头像侧保留独立的缩放/横向/纵向滑杆实现
|
||||
|
||||
支持格式:
|
||||
|
||||
@@ -125,9 +126,9 @@
|
||||
4. 不要求全站唯一,但要允许后端做敏感词审核
|
||||
5. 审核失败时返回明确错误
|
||||
|
||||
## 4.3 百梦号
|
||||
## 4.3 陶泥号
|
||||
|
||||
百梦号规则:
|
||||
陶泥号规则:
|
||||
|
||||
1. 作为公开可复制识别码
|
||||
2. 用户创建后固定生成,不允许用户修改
|
||||
@@ -207,6 +208,6 @@
|
||||
|
||||
1. 用户可以上传并保存头像
|
||||
2. 用户可以修改昵称并实时看到更新
|
||||
3. 百梦号由后端返回,复制后可正常使用
|
||||
3. 陶泥号由后端返回,复制后可正常使用
|
||||
4. 未登录或待绑定状态下,不出现无效编辑入口
|
||||
5. 页面不出现冗长规则说明文案
|
||||
|
||||
@@ -0,0 +1,90 @@
|
||||
# “我的”页签法律信息与登录协议确认 PRD
|
||||
|
||||
## 1. 目标
|
||||
|
||||
在平台“我的”页签底部补齐法律信息入口和备案信息;同时在登录弹窗中增加协议确认,用户首次登录必须手动勾选同意后才能继续登录。
|
||||
|
||||
## 2. 入口与布局
|
||||
|
||||
### 2.1 “我的”页签常用功能
|
||||
|
||||
- 已登录用户在“我的”页签看到常用功能区。
|
||||
- 常用功能区移动端和网页端都使用 3 列网格。
|
||||
- 每个功能入口保持图标、主标题、短副标题结构。
|
||||
- 不新增独立“我的”页面,只扩展现有个人页签。
|
||||
|
||||
### 2.2 法律信息区
|
||||
|
||||
法律信息区放在“我的”页签底部、设置入口之后。
|
||||
|
||||
区块内容:
|
||||
|
||||
- 区块标题:`法律信息`。
|
||||
- 三个列表入口:
|
||||
- `用户协议`
|
||||
- `隐私政策`
|
||||
- `免责声明`
|
||||
- 每个入口点击后打开独立模态面板,不在当前页签下方展开内容。
|
||||
- 备案信息固定显示在法律入口下方:
|
||||
- 文案:`京ICP备2026025677号`
|
||||
- 点击跳转到 `https://beian.miit.gov.cn/`
|
||||
- 外链在新窗口打开,并使用 `rel="noreferrer"`。
|
||||
|
||||
## 3. 法律内容面板
|
||||
|
||||
### 3.1 内容来源
|
||||
|
||||
三份法律内容读取仓库现有 Markdown 文件:
|
||||
|
||||
- `media/files/user_agreement.md`
|
||||
- `media/files/privacy_policy.md`
|
||||
- `media/files/disclaimer.md`
|
||||
|
||||
### 3.2 展示规则
|
||||
|
||||
- 使用平台主题变量渲染,暗色和亮色主题都必须可读。
|
||||
- 面板最大高度不超过视口,正文区域内部滚动。
|
||||
- 标题固定在面板顶部,底部保留确认按钮 `我知道了`。
|
||||
- Markdown 首版只需要支持标题、段落、列表和加粗文本。
|
||||
- 不把 Markdown 原文作为纯文本整段堆叠,必须保留基本阅读层级。
|
||||
|
||||
## 4. 登录协议确认
|
||||
|
||||
### 4.1 展示位置
|
||||
|
||||
登录弹窗的短信登录和密码登录表单都在提交按钮上方展示协议确认行:
|
||||
|
||||
`我已阅读并同意《用户协议》《隐私政策》和《免责声明》`
|
||||
|
||||
其中三段蓝色链接分别打开对应法律内容面板。
|
||||
|
||||
### 4.2 勾选规则
|
||||
|
||||
- 使用本地存储 key `genarrative.auth.legal-consent.v1` 记录是否已经确认。
|
||||
- 首次打开登录弹窗时,如果没有本地确认记录,勾选框默认为未选中。
|
||||
- 后续打开登录弹窗时,如果本地已有确认记录,勾选框默认为选中。
|
||||
- 用户未勾选时:
|
||||
- 登录按钮禁用。
|
||||
- 点击法律链接只打开内容面板,不自动勾选。
|
||||
- 用户勾选后:
|
||||
- 立即写入本地确认记录。
|
||||
- 短信登录和密码登录都可继续使用。
|
||||
|
||||
## 5. 验收
|
||||
|
||||
- 已登录“我的”页签常用功能区为 3 列。
|
||||
- “我的”页签底部出现 `法律信息`、三个入口和 `京ICP备2026025677号`。
|
||||
- 三个法律入口都能打开独立可滚动面板。
|
||||
- 备案号点击打开 `https://beian.miit.gov.cn/`。
|
||||
- 首次登录弹窗协议勾选为空,登录按钮禁用。
|
||||
- 勾选协议后登录按钮恢复可用,并持久化本地确认状态。
|
||||
- 再次打开登录弹窗时协议勾选默认选中。
|
||||
|
||||
## 6. 2026-05-12 落地记录
|
||||
|
||||
- 法律文档解析与弹窗复用 `src/components/common/legalDocuments.ts` 和 `src/components/common/LegalDocumentModal.tsx`。
|
||||
- “我的”页签在 `src/components/rpg-entry/RpgEntryHomeView.tsx` 中接入 3 列常用功能、法律入口和备案链接。
|
||||
- 登录协议确认在 `src/components/auth/LoginScreen.tsx` 中接入,短信登录和密码登录共用同一确认行。
|
||||
- 定向验证:
|
||||
- `npm run test -- src/components/auth/AuthGate.test.tsx src/components/rpg-entry/RpgEntryHomeView.recharge.test.tsx`
|
||||
- `npx eslint src/components/auth/LoginScreen.tsx src/components/auth/AuthGate.test.tsx src/components/common/LegalDocumentModal.tsx src/components/common/legalDocuments.ts src/components/rpg-entry/RpgEntryHomeView.tsx src/components/rpg-entry/RpgEntryHomeView.recharge.test.tsx --max-warnings 0`
|
||||
@@ -4,7 +4,9 @@
|
||||
|
||||
## 重点入口
|
||||
|
||||
- [AI 原生幕间文字游戏模板 PRD:参考 MOKU 的剧本模拟器闭环](./AI_NATIVE_TEXT_GAME_TEMPLATE_MOKU_REFERENCE_PRD_2026-05-05.md):参考 MOKU / 幕间类 AI 文游的剧本游乐场、自由行动、AI GM、记忆和模拟器强反馈经验,但只落为百梦 `text-game` 模板,复用平台接口,不迁入外部社区、支付、私有存档或回放。
|
||||
- [宝贝爱画寓教于乐独立关卡 PRD](./BABY_LOVE_DRAWING_EDUTAINMENT_LEVEL_PRD_2026-05-13.md):定义寓教于乐内容线的 `宝贝爱画` 独立本地 Demo 关卡,覆盖画板、七色选择、画笔/橡皮、手部绘画、完成、image-2 绘画魔法、本地保存和关闭入口隐藏边界。
|
||||
- [宝贝识物寓教于乐模板 PRD](./BABY_OBJECT_MATCH_EDUTAINMENT_TEMPLATE_PRD_2026-05-11.md):定义寓教于乐内容线的 `宝贝识物` 创作模板,覆盖两个物品名称输入、image-2 物品图生成、精确 `寓教于乐` 标签、结果页和发布边界。
|
||||
- [AI 原生幕间文字游戏模板 PRD:参考 MOKU 的剧本模拟器闭环](./AI_NATIVE_TEXT_GAME_TEMPLATE_MOKU_REFERENCE_PRD_2026-05-05.md):参考 MOKU / 幕间类 AI 文游的剧本游乐场、自由行动、AI GM、记忆和模拟器强反馈经验,但只落为陶泥儿 `text-game` 模板,复用平台接口,不迁入外部社区、支付、私有存档或回放。
|
||||
- [AI 原生视觉小说模板 PRD:TXT 玩法平台化接入](./AI_NATIVE_VISUAL_NOVEL_TEMPLATE_PRD_2026-05-05.md):参考 `Interactive-fiction-backend` / `Interactive-fiction-frontend` 的 TXT 玩法经验,但只保留视觉小说模板创作与运行闭环,完全使用 Genarrative 平台接口,并明确删除回放和外部平台功能。
|
||||
- [AI 原生幸存者类游戏模板 PRD](./AI_NATIVE_SURVIVOR_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-05-05.md):定义 `survivor` 幸存者挑战模板,从 Agent 创作、结果页、资产、试玩、发布到后端权威配置与前端高频运行表现的完整闭环。
|
||||
- [创意互动内容生成 Agent Phase 1 PRD:LangChain-Rust PoC + 拼图闭环](./CREATIVE_INTERACTIVE_AGENT_PHASE1_LANGCHAIN_RUST_PUZZLE_LOOP_PRD_2026-05-05.md):首版只支持拼图模板,Agent 使用 APIMart Responses `gpt-5` 支持文本和图像多模态输入,明确模板选择、积分范围、草稿字段填充、单关卡/多关卡图片生成、立即试玩、自然语言修改和可并行任务拆分。
|
||||
@@ -12,6 +14,7 @@
|
||||
- [AI 原生拼图玩法创作工具与玩法系统 PRD](./AI_NATIVE_PUZZLE_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-04-22.md):拼图玩法创作、结果页、发布、广场和运行时主链路。
|
||||
- [AI 原生方洞挑战玩法创作工具与玩法系统 PRD](./AI_NATIVE_SQUARE_HOLE_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-05-04.md):方洞挑战创作、发布与试玩闭环。
|
||||
- [后台管理独立前端工程 PRD](./ADMIN_WEB_CONSOLE_PRD_2026-04-30.md):后台管理端产品边界。
|
||||
- [“我的”页签法律信息与登录协议确认 PRD](./PROFILE_LEGAL_INFO_AND_AUTH_AGREEMENT_PRD_2026-05-12.md):定义个人页法律入口、备案链接、法律内容弹窗和首次登录协议勾选规则。
|
||||
|
||||
## 使用规则
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ TXT 模式核心玩法是一个包含“创作编辑器 -> 测试体验 -> 正
|
||||
|
||||
1. 支持创建 TXT 模式作品。
|
||||
2. 支持 TXT 模式作品的完整创作流程。
|
||||
3. 支持百梦主测试体验。
|
||||
3. 支持陶泥儿主测试体验。
|
||||
4. 支持玩家正式游玩。
|
||||
5. 支持文本模式运行。
|
||||
6. 支持双会话机制。
|
||||
@@ -176,9 +176,9 @@ TXT 模式核心玩法必须完整保留双会话机制。
|
||||
2. 正式继续体验
|
||||
3. 正式游玩推进
|
||||
|
||||
## 7.2 百梦主测试/读档会话
|
||||
## 7.2 陶泥儿主测试/读档会话
|
||||
|
||||
百梦主测试/读档会话用于:
|
||||
陶泥儿主测试/读档会话用于:
|
||||
|
||||
1. 编辑器内测试体验
|
||||
2. 指定存档加载
|
||||
|
||||
Reference in New Issue
Block a user