Merge remote-tracking branch 'origin/master'
Some checks failed
CI / verify (push) Has been cancelled
Some checks failed
CI / verify (push) Has been cancelled
This commit is contained in:
@@ -394,7 +394,7 @@ MVP 阶段不需要单独设置密码。
|
||||
|
||||
落地规则:
|
||||
|
||||
- 入参只允许 `phone` 和 `password`,不支持邮箱、用户名或陶泥号。
|
||||
- 入参只允许 `phone` 和 `password`,不支持邮箱、用户名或百梦号。
|
||||
- 手机号不存在时,不创建账号,返回统一的登录失败。
|
||||
- 手机号存在但账号未设置过密码时,不允许密码登录。
|
||||
- 首次设置密码只能在已登录账号中心内完成;用户必须先通过手机号验证码或已绑定手机号的微信账号进入已登录态。
|
||||
@@ -734,7 +734,7 @@ MVP 阶段建议至少提供一个轻量账号中心,包含:
|
||||
|
||||
约束:
|
||||
|
||||
- 不支持邮箱、用户名或陶泥号。
|
||||
- 不支持邮箱、用户名或百梦号。
|
||||
- 不承担注册能力。
|
||||
- 只有已存在、已验证手机号、且 `passwordLoginEnabled=true` 的账号可以登录。
|
||||
|
||||
|
||||
@@ -12,6 +12,7 @@
|
||||
2. 管理数据、业务规则、权限校验和写操作继续统一走 `server-rs/crates/api-server`。
|
||||
3. v1 只接管已有管理能力:管理员登录、当前管理员信息、服务/数据库概览、受控 API 调试、兑换码管理、注册邀请码管理。
|
||||
4. 保持管理端清爽、可扫读、移动端可用,不在界面堆大段规则说明。
|
||||
5. 发布包内由 Web 网关把独立后台前端挂到同域 `/admin/`;Rust `api-server` 自身仍不恢复旧的 `GET /admin` 内嵌页面。
|
||||
|
||||
## 2. 用户与使用场景
|
||||
|
||||
@@ -54,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 对象校验,最终校验以服务端为准。
|
||||
@@ -66,7 +67,7 @@
|
||||
3. 不新增 SpacetimeDB 表结构。
|
||||
4. 不实现完整用户管理、作品审核、资产审核、充值订单后台。
|
||||
5. 不实现多角色权限体系、管理员 refresh session、多端会话管理。
|
||||
6. 不保留 `GET /admin` 同源内嵌页面作为正式后台入口。
|
||||
6. 不保留 Rust `api-server` 的 `GET /admin` 同源内嵌页面作为正式后台入口;部署态 `/admin/` 只允许由独立后台前端静态产物承接。
|
||||
|
||||
## 4. 页面与交互要求
|
||||
|
||||
@@ -113,7 +114,7 @@ API 调试页是受控接口调试台,不是通用代理工具:
|
||||
4. maxUses:必须为正整数,最终校验以服务端为准。
|
||||
5. enabled:创建/更新时可切换。
|
||||
6. allowedUserIds:私有码允许的内部用户 ID 列表。
|
||||
7. allowedPublicUserCodes:私有码允许的公开陶泥号列表。
|
||||
7. allowedPublicUserCodes:私有码允许的公开百梦号列表。
|
||||
|
||||
提交成功后展示后端返回的兑换码记录;失败时展示后端错误消息。
|
||||
|
||||
@@ -144,7 +145,7 @@ API 调试页是受控接口调试台,不是通用代理工具:
|
||||
5. API 调试页可通过后端调试接口访问 `/healthz`。
|
||||
6. 兑换码管理页可创建/更新、停用兑换码,并展示返回记录。
|
||||
7. 邀请码管理页可创建/更新注册邀请码,并展示返回记录。
|
||||
8. `GET /admin` 保持 404,不恢复旧内嵌页面。
|
||||
8. 直连 Rust `api-server` 时 `GET /admin` 保持 404,不恢复旧内嵌页面;通过发布包 Web 网关访问 `/admin/` 时返回独立后台前端。
|
||||
9. `npm run check:encoding` 通过。
|
||||
|
||||
## 7. 首版任务拆解
|
||||
|
||||
@@ -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. 核心冲突与线程
|
||||
|
||||
@@ -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. 一句话定义
|
||||
|
||||
让陶泥主通过 Agent 对话确认题材、需要消除次数和难度,系统编译出一个可试玩、可发布的单局抓大鹅玩法作品;玩家在 `10` 分钟倒计时内点击圆形空间中可见物品,把物品放入下方 `7` 格备选栏,每凑齐 `3` 个同物品 id 自动消除,最终清空圆形空间内全部物品即胜利。
|
||||
让百梦主通过 Agent 对话确认题材、需要消除次数和难度,系统编译出一个可试玩、可发布的单局抓大鹅玩法作品;玩家在 `10` 分钟倒计时内点击圆形空间中可见物品,把物品放入下方 `7` 格备选栏,每凑齐 `3` 个同物品 id 自动消除,最终清空圆形空间内全部物品即胜利。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -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. 不允许空标题发布。
|
||||
|
||||
@@ -678,7 +678,7 @@ V1 规则如下:
|
||||
|
||||
1. 点击道具必须弹出独立确认窗口。
|
||||
2. 确认窗口期间暂停游戏时间。
|
||||
3. 正式后端运行态每次确认消耗 `1` 陶泥币。
|
||||
3. 正式后端运行态每次确认消耗 `1` 光点。
|
||||
4. 本地调试 run 不伪造钱包扣费,只保持确认、暂停和表现一致。
|
||||
|
||||
---
|
||||
@@ -1160,7 +1160,7 @@ interface PuzzleRunSnapshot {
|
||||
|
||||
完成标准:
|
||||
|
||||
1. 陶泥主能从平台进入拼图 Agent 工作区
|
||||
1. 百梦主能从平台进入拼图 Agent 工作区
|
||||
2. 能通过聊天生成结果页草稿
|
||||
|
||||
## 阶段 B:再做结果页与图片资产
|
||||
@@ -1174,7 +1174,7 @@ interface PuzzleRunSnapshot {
|
||||
|
||||
完成标准:
|
||||
|
||||
1. 陶泥主能生成正式拼图图片并发布
|
||||
1. 百梦主能生成正式拼图图片并发布
|
||||
2. 作品能进入拼图广场
|
||||
|
||||
## 阶段 C:再做拼图运行时核心循环
|
||||
@@ -1232,4 +1232,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 列表,第一位自动成为主角色。
|
||||
|
||||
@@ -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. 点击登录方式/状态标签
|
||||
- 不跳页,不弹复杂说明
|
||||
@@ -125,9 +125,9 @@
|
||||
4. 不要求全站唯一,但要允许后端做敏感词审核
|
||||
5. 审核失败时返回明确错误
|
||||
|
||||
## 4.3 陶泥号
|
||||
## 4.3 百梦号
|
||||
|
||||
陶泥号规则:
|
||||
百梦号规则:
|
||||
|
||||
1. 作为公开可复制识别码
|
||||
2. 用户创建后固定生成,不允许用户修改
|
||||
@@ -207,6 +207,6 @@
|
||||
|
||||
1. 用户可以上传并保存头像
|
||||
2. 用户可以修改昵称并实时看到更新
|
||||
3. 陶泥号由后端返回,复制后可正常使用
|
||||
3. 百梦号由后端返回,复制后可正常使用
|
||||
4. 未登录或待绑定状态下,不出现无效编辑入口
|
||||
5. 页面不出现冗长规则说明文案
|
||||
|
||||
@@ -108,6 +108,16 @@
|
||||
- 最后游玩时间
|
||||
- 游戏信息
|
||||
|
||||
### 3.3.0 拼图存档字段与视觉层级
|
||||
|
||||
拼图玩法的存档列表项必须按作品维度展示,不把关卡名当作作品名:
|
||||
|
||||
- 主标题展示作品名,来源为服务端存档投影的 `worldName`,视觉层级必须是卡片内最醒目的文本。
|
||||
- 副标题展示当前可继续入口,格式为 `第 N 关 · 关卡名`;无关卡名时只展示 `第 N 关`。
|
||||
- 卡片中不展示英文 `Archive` / `ARCHIVE` 标签。
|
||||
- 封面缩略图固定为 `1:1` 正方形比例,使用当前可继续关卡图片。
|
||||
- 封面图上不再覆盖“最近存档”标签;保存时间独立展示在信息区内。
|
||||
|
||||
### 3.3.1 移动端卡片布局约束
|
||||
|
||||
- 移动端列表卡片中的封面只能作为独立缩略图或弱化背景层使用,不能直接占满整张卡片并压在正文信息下方。
|
||||
|
||||
@@ -35,7 +35,7 @@ TXT 模式核心玩法是一个包含“创作编辑器 -> 测试体验 -> 正
|
||||
|
||||
1. 支持创建 TXT 模式作品。
|
||||
2. 支持 TXT 模式作品的完整创作流程。
|
||||
3. 支持陶泥主测试体验。
|
||||
3. 支持百梦主测试体验。
|
||||
4. 支持玩家正式游玩。
|
||||
5. 支持文本模式运行。
|
||||
6. 支持双会话机制。
|
||||
@@ -174,9 +174,9 @@ TXT 模式核心玩法必须完整保留双会话机制。
|
||||
2. 正式继续体验
|
||||
3. 正式游玩推进
|
||||
|
||||
## 7.2 陶泥主测试/读档会话
|
||||
## 7.2 百梦主测试/读档会话
|
||||
|
||||
陶泥主测试/读档会话用于:
|
||||
百梦主测试/读档会话用于:
|
||||
|
||||
1. 编辑器内测试体验
|
||||
2. 指定存档加载
|
||||
|
||||
Reference in New Issue
Block a user