1
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 自动消除,最终清空圆形空间内全部物品即胜利。
|
||||
|
||||
---
|
||||
|
||||
@@ -99,8 +99,8 @@ Match3D 必须形成独立玩法域,后续技术方案至少需要覆盖:
|
||||
- 2D 素材风格
|
||||
- 难度选项
|
||||
4. `需要消除次数` 与难度 `1~10` 数值不再作为独立输入框展示,由难度选项派生。
|
||||
5. 生成抓大鹅草稿固定消耗 `10` 光点,生成按钮必须显式展示。
|
||||
6. 结果页背景音乐重新生成固定消耗 `5` 光点;UI 背景重新生成固定消耗 `2` 光点;批量新增物品素材按实际可新增物品名每 `5` 个消耗 `2` 光点,不足 `5` 个向上取整。
|
||||
5. 生成抓大鹅草稿固定消耗 `10` 泥点,生成按钮必须显式展示。
|
||||
6. 结果页背景音乐重新生成固定消耗 `5` 泥点;UI 背景重新生成固定消耗 `2` 泥点;批量新增物品素材按实际可新增物品名每 `5` 个消耗 `2` 泥点,不足 `5` 个向上取整。
|
||||
7. 结果页支持编辑游戏名称、标签、封面图等基础发布信息。
|
||||
8. 发布前支持试玩,并允许随时停止和修改配置。
|
||||
9. 发布不要求试玩通关。
|
||||
|
||||
@@ -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. 属性面板是否首版关闭,还是只对内部白名单开启。
|
||||
|
||||
@@ -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. 页面不出现冗长规则说明文案
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
## 重点入口
|
||||
|
||||
- [宝贝识物寓教于乐模板 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:参考 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` 支持文本和图像多模态输入,明确模板选择、积分范围、草稿字段填充、单关卡/多关卡图片生成、立即试玩、自然语言修改和可并行任务拆分。
|
||||
|
||||
@@ -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