1

docs/design/CUSTOM_WORLD_CREATOR_INPUT_AND_AI_BOUNDARY_DESIGN_2026-04-06.md

@@ -1,4 +1,4 @@
-# 自定义世界创作者输入与 AI 分工边界设计
+# 自定义世界陶泥主输入与 AI 分工边界设计
 
 更新时间：`2026-04-06`
 
@@ -6,9 +6,9 @@
 
 这份文档回答一个非常关键的问题：
 
-**在“低创作门槛、高创作自由度”的前提下，自定义世界里哪些内容应该交给创作者直接定义，哪些内容应该交给 AI 和系统完成。**
+**在“低创作门槛、高创作自由度”的前提下，自定义世界里哪些内容应该交给陶泥主直接定义，哪些内容应该交给 AI 和系统完成。**
 
-这里默认我们的创作者：
+这里默认我们的陶泥主：
 
 - 不需要有专业作家背景
 - 不需要有专业游戏设计背景
@@ -16,33 +16,33 @@
 
 一句话目标：
 
-**让创作者把精力放在“决定这个世界为什么值得被创作”，把 AI 用在“把这个世界展开、编译、铺开、校验、补足”。**
+**让陶泥主把精力放在“决定这个世界为什么值得被创作”，把 AI 用在“把这个世界展开、编译、铺开、校验、补足”。**
 
 ## 1. 总体结论
 
 自定义世界的分工边界应该遵守 3 条硬原则：
 
-1. 灵魂归创作者，杂活归 AI。
-   - 凡是决定作品气质、主题、冲突、人物关系、审美方向的内容，都应由创作者掌握。
+1. 灵魂归陶泥主，杂活归 AI。
+   - 凡是决定作品气质、主题、冲突、人物关系、审美方向的内容，都应由陶泥主掌握。
 
-2. 重点对象归创作者，长尾铺量归 AI。
-   - 创作者应重点塑造少量关键角色、关键地点、关键冲突、关键意象，而不是被迫手填几十个 NPC、几十个场景、几百条描述。
+2. 重点对象归陶泥主，长尾铺量归 AI。
+   - 陶泥主应重点塑造少量关键角色、关键地点、关键冲突、关键意象，而不是被迫手填几十个 NPC、几十个场景、几百条描述。
 
-3. 决策归创作者，编译归 AI / 系统。
-   - 创作者负责说“这个世界要成为什么样”，AI / 系统负责把它编译成可运行的数据、规则、文本、关系钩子和运行时结构。
+3. 决策归陶泥主，编译归 AI / 系统。
+   - 陶泥主负责说“这个世界要成为什么样”，AI / 系统负责把它编译成可运行的数据、规则、文本、关系钩子和运行时结构。
 
 这意味着：
 
-- 创作者应该主要编辑“高杠杆创作锚点”
+- 陶泥主应该主要编辑“高杠杆创作锚点”
 - AI 应该主要承担“批量展开 + 结构编译 + 一致性维护 + 专业执行”
 
-## 2. 什么内容应该交给创作者
+## 2. 什么内容应该交给陶泥主
 
-真正应该交给创作者的，不是大量表格字段，而是下面这些会显著决定作品质量、且 AI 不擅长替代的内容。
+真正应该交给陶泥主的，不是大量表格字段，而是下面这些会显著决定作品质量、且 AI 不擅长替代的内容。
 
 ## 2.1 世界核心命题
 
-创作者应该直接定义：
+陶泥主应该直接定义：
 
 - 这个世界的一句话设定
 - 这个世界最吸引人的核心幻想
@@ -56,7 +56,7 @@
 
 ## 2.2 主题、气质与边界
 
-创作者应该直接定义：
+陶泥主应该直接定义：
 
 - 主题关键词
 - 情绪基调
@@ -71,7 +71,7 @@
 
 ## 2.3 玩家身份与开局处境
 
-创作者应该直接定义：
+陶泥主应该直接定义：
 
 - 玩家扮演的是什么人
 - 玩家一开始最缺什么、最想要什么
@@ -85,7 +85,7 @@
 
 ## 2.4 核心冲突与关键势力
 
-创作者应该直接定义少量高价值内容：
+陶泥主应该直接定义少量高价值内容：
 
 - 世界当前最重要的 `2~4` 条明面冲突
 - 世界背后最关键的 `1~3` 条暗面问题
@@ -96,13 +96,13 @@
 
 - 冲突结构决定世界是否“有戏”
 - 势力关系是 AI 最容易写散、写平、写成百科介绍的部分
-- 这一层由创作者把握，才能真正提高作品的辨识度
+- 这一层由陶泥主把握，才能真正提高作品的辨识度
 
 ## 2.5 关键角色与关系张力
 
-创作者应该直接定义少量关键角色，而不是所有 NPC。
+陶泥主应该直接定义少量关键角色，而不是所有 NPC。
 
-建议重点交给创作者的，是：
+建议重点交给陶泥主的，是：
 
 - `3~8` 个关键角色
 - 玩家与这些人的潜在关系
@@ -113,11 +113,11 @@
 
 - 角色关系是最能显著提升作品质量的部分之一
 - 这也是 AI 最容易写得“完整但无味”的部分
-- 创作者不需要写长篇背景，但应掌握这些角色真正的关系骨架
+- 陶泥主不需要写长篇背景，但应掌握这些角色真正的关系骨架
 
 ## 2.6 关键地点与空间记忆点
 
-创作者应该直接定义：
+陶泥主应该直接定义：
 
 - `4~12` 个关键地点 / 区域 / 地标
 - 这些地方为什么重要
@@ -131,7 +131,7 @@
 
 ## 2.7 标志性意象、物件、怪物、制度与规则
 
-创作者应该优先控制世界里最能代表它的东西：
+陶泥主应该优先控制世界里最能代表它的东西：
 
 - 标志性物件
 - 标志性怪物 / 生物
@@ -144,9 +144,9 @@
 - 这些内容决定世界的“手感”
 - 它们不是普通细节，而是会反复影响命名、剧情、视觉、对话与玩法解释的母题
 
-## 2.8 创作者应直接控制的“禁止事项”
+## 2.8 陶泥主应直接控制的“禁止事项”
 
-创作者必须能明确锁定：
+陶泥主必须能明确锁定：
 
 - 什么绝对不能改
 - 什么不能被 AI 自动扩写到别的方向
@@ -156,7 +156,7 @@
 原因：
 
 - 高自由度不等于所有内容都开放漂移
-- 如果没有“锁定机制”，AI 会把创作者真正关心的内容稀释掉
+- 如果没有“锁定机制”，AI 会把陶泥主真正关心的内容稀释掉
 
 ## 3. 什么内容应该交给 AI 和系统
 
@@ -176,7 +176,7 @@
 原因：
 
 - 这些内容数量大、重复度高
-- 它们需要“贴合世界”，但不需要都由创作者逐个手写
+- 它们需要“贴合世界”，但不需要都由陶泥主逐个手写
 - AI 很适合做“围绕锚点的批量铺量”
 
 ## 3.2 从创作锚点到系统结构的编译
@@ -186,7 +186,7 @@
 - 从自然语言世界设定中提取题材词汇
 - 从关键冲突中编译出世界叙事图谱
 - 从关键角色卡编译出角色叙事档案
-- 从创作者输入里自动生成标签、钩子、隐藏线索、章节摘要
+- 从陶泥主输入里自动生成标签、钩子、隐藏线索、章节摘要
 - 从地点和关系中编译出场景连接、事件触发和叙事回响
 
 对应当前仓库，下面这些结构更适合由 AI / 系统生成，而不是让玩家直接编辑：
@@ -203,7 +203,7 @@
 
 原因：
 
-- 这些是运行时结构，不是创作者真正想表达的作品内容
+- 这些是运行时结构，不是陶泥主真正想表达的作品内容
 - 直接暴露给玩家，会把创作过程变成专业数据填表
 
 ## 3.3 专业化、规则化的任务
@@ -223,7 +223,7 @@
 原因：
 
 - 这些工作要么重复、要么专业、要么容易做脏活累活
-- 让非专业创作者处理，会显著提高门槛，却不一定显著提高质量
+- 让非专业陶泥主处理，会显著提高门槛，却不一定显著提高质量
 
 ## 3.4 一致性、纠错与查漏补缺
 
@@ -240,15 +240,15 @@
 原因：
 
 - 这是 AI 比人更适合做的“维护型工作”
-- 它属于创作支持，不属于创作者必须亲手完成的创作
+- 它属于创作支持，不属于陶泥主必须亲手完成的创作
 
 ## 4. 最合理的边界不是二分法，而是三层分工
 
 自定义世界最合理的结构，不是“玩家写”与“AI 写”的简单二选一，而是三层。
 
-## 4.1 第一层：创作者必控层
+## 4.1 第一层：陶泥主必控层
 
-这一层必须给创作者高自由度，且能被锁定：
+这一层必须给陶泥主高自由度，且能被锁定：
 
 - 世界核心命题
 - 主题与气质
@@ -264,9 +264,9 @@
 
 **少而重。**
 
-## 4.2 第二层：创作者可选强化层
+## 4.2 第二层：陶泥主可选强化层
 
-这一层不应强制填写，但应该允许创作者继续深挖：
+这一层不应强制填写，但应该允许陶泥主继续深挖：
 
 - 明线 / 暗线种子
 - 角色之间的旧事
@@ -301,17 +301,17 @@
 
 ## 5. 具体模块的建议归属
 
-| 模块 | 建议归属 | 创作者应控制什么 | AI / 系统应负责什么 |
+| 模块 | 建议归属 | 陶泥主应控制什么 | AI / 系统应负责什么 |
 | --- | --- | --- | --- |
-| 世界一句话设定、核心幻想、核心卖点 | 创作者直接控制 | 直接写、直接改、可锁定 | 给出备选表述和扩展方向 |
-| 主题、基调、审美、禁忌 | 创作者直接控制 | 选择 / 改写 / 锁定 | 生成风格词、避雷词、提示词约束 |
-| 玩家身份、开局处境、玩家目标 | 创作者直接控制 | 直接定义 | 补足开局钩子和初始叙事包装 |
-| 关键势力与核心冲突 | 创作者主控，AI 辅助 | 定义核心关系和立场 | 扩展冲突支路、生成世界线程 |
-| 关键角色 | 创作者主控，AI 辅助 | 定义角色骨架、关系张力、秘密方向 | 生成长背景、章节拆分、技能、物品、叙事档案 |
-| 关键地点 | 创作者主控，AI 辅助 | 定义地点意义、气氛、秘密 | 扩展场景细节、连接关系、遭遇分布 |
-| 标志性物件 / 怪物 / 制度 / 规则 | 创作者主控，AI 辅助 | 定义代表性要素与硬边界 | 扩展变体、命名、说明、运行时挂钩 |
+| 世界一句话设定、核心幻想、核心卖点 | 陶泥主直接控制 | 直接写、直接改、可锁定 | 给出备选表述和扩展方向 |
+| 主题、基调、审美、禁忌 | 陶泥主直接控制 | 选择 / 改写 / 锁定 | 生成风格词、避雷词、提示词约束 |
+| 玩家身份、开局处境、玩家目标 | 陶泥主直接控制 | 直接定义 | 补足开局钩子和初始叙事包装 |
+| 关键势力与核心冲突 | 陶泥主控，AI 辅助 | 定义核心关系和立场 | 扩展冲突支路、生成世界线程 |
+| 关键角色 | 陶泥主控，AI 辅助 | 定义角色骨架、关系张力、秘密方向 | 生成长背景、章节拆分、技能、物品、叙事档案 |
+| 关键地点 | 陶泥主控，AI 辅助 | 定义地点意义、气氛、秘密 | 扩展场景细节、连接关系、遭遇分布 |
+| 标志性物件 / 怪物 / 制度 / 规则 | 陶泥主控，AI 辅助 | 定义代表性要素与硬边界 | 扩展变体、命名、说明、运行时挂钩 |
 | 普通 NPC / 路人 / 杂兵 / 次级地点 | 主要交给 AI | 仅在需要时抽查或替换 | 批量生成与风格保持 |
-| 角色长背景、章节 teaser、context snippet | 主要交给 AI | 创作者只改关键角色即可 | 自动拆章、压缩、解锁节奏整理 |
+| 角色长背景、章节 teaser、context snippet | 主要交给 AI | 陶泥主只改关键角色即可 | 自动拆章、压缩、解锁节奏整理 |
 | 技能、初始物品、标签、构筑倾向 | 主要交给 AI / 系统 | 提供偏好或少量 override | 按角色和世界规则自动编译 |
 | 世界图谱、知识事实、可见性、导演指令 | AI / 系统内部层 | 不应默认暴露给玩家 | 运行时编译与维护 |
 | 一致性检查、冲突检查、越权检查 | AI / 系统内部层 | 查看报告、决定是否采纳修改 | 自动扫描并提出修正建议 |
@@ -328,7 +328,7 @@
 - 精确数值型 build 倾向
 - 复杂掉落预算
 
-更合理的做法是让创作者填写直觉表达，例如：
+更合理的做法是让陶泥主填写直觉表达，例如：
 
 - `初见就戒备`
 - `容易合作`
@@ -351,7 +351,7 @@
 
 原因：
 
-- 这些字段属于系统运行结构，不属于创作者自然的创作语言
+- 这些字段属于系统运行结构，不属于陶泥主自然的创作语言
 - 直接让玩家填，会把工具变成只有懂系统的人才能用
 
 ## 6.3 不应该要求玩家逐个补完所有人物设定字段
@@ -378,7 +378,7 @@
 
 ## 7. 推荐的创作输入形态
 
-要让非专业创作者也能高自由度创作，输入形态必须改成“自然语言创作卡”，而不是“系统字段表单”。
+要让非专业陶泥主也能高自由度创作，输入形态必须改成“自然语言创作卡”，而不是“系统字段表单”。
 
 ## 7.1 世界层卡片
 
@@ -397,10 +397,10 @@
 ## 7.2 每张卡片都允许 3 种输入方式
 
 1. 一句话自由输入
-   - 适合低门槛创作者
+   - 适合低门槛陶泥主
 
 2. 标签 / 选项 / 语气滑条
-   - 适合不想写太多字的创作者
+   - 适合不想写太多字的陶泥主
 
 3. 高级补充
    - 适合愿意继续深挖的人
@@ -414,7 +414,7 @@
 
 这是高创作自由度里非常关键的一点。
 
-创作者应当能：
+陶泥主应当能：
 
 - 锁定一个角色
 - 锁定一个地点
@@ -422,13 +422,13 @@
 - 只重生成未锁定部分
 - 围绕锁定内容重写其余世界
 
-否则创作者每次调用 AI，都会有“好不容易想好的东西被洗掉”的感受。
+否则陶泥主每次调用 AI，都会有“好不容易想好的东西被洗掉”的感受。
 
 ## 8. 面向当前仓库的结构映射建议
 
 为了便于后续落实现有系统，这份边界建议可以直接映射到当前结构：
 
-## 8.1 创作者输入层
+## 8.1 陶泥主输入层
 
 建议主要映射到：
 
@@ -445,7 +445,7 @@
 
 ## 8.2 AI 编译层
 
-由 AI / 系统从创作者输入自动补出：
+由 AI / 系统从陶泥主输入自动补出：
 
 - `themePack`
 - `storyGraph`
@@ -465,7 +465,7 @@
 - `CarrierStoryFingerprint`
 - `StorySignal`
 
-这些内容应该是“系统如何把世界跑起来”，不是“创作者必须亲手写完的创作内容”。
+这些内容应该是“系统如何把世界跑起来”，不是“陶泥主必须亲手写完的创作内容”。
 
 ## 9. 产品层面的最终结论
 
@@ -480,12 +480,12 @@
 
 它应该做成这样：
 
-1. 创作者决定世界的灵魂锚点。
-2. 创作者重点塑造少量关键人、关键地、关键冲突、关键物。
+1. 陶泥主决定世界的灵魂锚点。
+2. 陶泥主重点塑造少量关键人、关键地、关键冲突、关键物。
 3. AI 围绕这些锚点批量展开长尾内容。
 4. 系统把这些内容编译成可运行的图谱、可见性、任务、物件和关系结构。
-5. 创作者随时可以锁定核心创意，并局部重生成其余部分。
+5. 陶泥主随时可以锁定核心创意，并局部重生成其余部分。
 
 一句话收束：
 
-**创作者应该写“这个世界为什么动人”，AI 应该负责“让这个世界长出来并跑起来”。**
+**陶泥主应该写“这个世界为什么动人”，AI 应该负责“让这个世界长出来并跑起来”。**

docs/design/CUSTOM_WORLD_CREATOR_MANUAL_AI_SYSTEM_BALANCE_DESIGN_2026-04-12.md

@@ -6,17 +6,17 @@
 
 这份文档用于回答一个更具体的问题：
 
-**参考 RPG 专业剧情策划全流程后，在自定义世界创作工具里，哪些设定必须要求创作者手动填写，哪些设定应该由 AI 先生成但允许创作者修改，哪些设定应完全交给系统托管，才能在“尽可能降低门槛”和“尽可能提高作品质量”之间取一个平衡。**
+**参考 RPG 专业剧情策划全流程后，在自定义世界创作工具里，哪些设定必须要求陶泥主手动填写，哪些设定应该由 AI 先生成但允许陶泥主修改，哪些设定应完全交给系统托管，才能在“尽可能降低门槛”和“尽可能提高作品质量”之间取一个平衡。**
 
-这份文档不再只回答“创作者与 AI 怎么分工”，而是进一步把创作工作台收束成一个更可执行的三层输入结构：
+这份文档不再只回答“陶泥主与 AI 怎么分工”，而是进一步把创作工作台收束成一个更可执行的三层输入结构：
 
-1. 创作者必须手填的高杠杆锚点
-2. AI 先生成、创作者可修改的内容草稿层
+1. 陶泥主必须手填的高杠杆锚点
+2. AI 先生成、陶泥主可修改的内容草稿层
 3. 系统自动编译和运行的托管层
 
 一句话结论：
 
-**让创作者只负责决定作品的灵魂、视角、冲突和关系钩子，让 AI 负责把这些锚点展开成可编辑的剧情草稿，让系统负责把草稿编译成可运行的结构。**
+**让陶泥主只负责决定作品的灵魂、视角、冲突和关系钩子，让 AI 负责把这些锚点展开成可编辑的剧情草稿，让系统负责把草稿编译成可运行的结构。**
 
 ---
 
@@ -25,27 +25,27 @@
 这套平衡设计要同时满足 5 个目标：
 
 1. 低门槛
-   - 新创作者不需要写长篇设定，也不需要理解底层系统结构。
+   - 新陶泥主不需要写长篇设定，也不需要理解底层系统结构。
 
 2. 高辨识度
-   - 创作者写出来的世界，不应该只是“像一个世界”，而应该保留明显的个人方向。
+   - 陶泥主写出来的世界，不应该只是“像一个世界”，而应该保留明显的个人方向。
 
 3. 高可编辑性
-   - AI 不能一次生成后就不可控，创作者必须能改关键对象、关键关系和关键章节。
+   - AI 不能一次生成后就不可控，陶泥主必须能改关键对象、关键关系和关键章节。
 
 4. 高稳定性
-   - 任务、章节、关系、物件和可见性等运行层结构不能依赖创作者手填专业字段。
+   - 任务、章节、关系、物件和可见性等运行层结构不能依赖陶泥主手填专业字段。
 
 5. 可扩展
-   - 愿意深挖的创作者可以继续补充世界上限，不愿深挖的人也能快速产出质量不错的作品。
+   - 愿意深挖的陶泥主可以继续补充世界上限，不愿深挖的人也能快速产出质量不错的作品。
 
 ---
 
 ## 2. 核心原则
 
-## 2.1 创作者手填的必须是“高杠杆决策”，不是“高工作量字段”
+## 2.1 陶泥主手填的必须是“高杠杆决策”，不是“高工作量字段”
 
-应该要求创作者手填的内容，必须同时满足下面两个条件：
+应该要求陶泥主手填的内容，必须同时满足下面两个条件：
 
 1. 会显著决定作品气质和辨识度
 2. AI 很难替代判断
@@ -67,9 +67,9 @@
 - 章节拆分
 - 运行时信号结构
 
-## 2.2 创作者可改层应该承接“专业策划初稿”，而不是“原始底层字段”
+## 2.2 陶泥主可改层应该承接“专业策划初稿”，而不是“原始底层字段”
 
-AI 生成后允许创作者修改的，不应该是一堆技术型字段，而应该是一批已经成形的内容卡片，例如：
+AI 生成后允许陶泥主修改的，不应该是一堆技术型字段，而应该是一批已经成形的内容卡片，例如：
 
 - 关键角色卡
 - 势力卡
@@ -81,11 +81,11 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 也就是说：
 
-**AI 先给创作者一个像策划初稿的东西，而不是给一堆系统字段让创作者自己拼。**
+**AI 先给陶泥主一个像策划初稿的东西，而不是给一堆系统字段让陶泥主自己拼。**
 
 ## 2.3 系统托管层必须彻底隐藏专业运行结构
 
-以下这类结构不应该默认要求创作者理解或编辑：
+以下这类结构不应该默认要求陶泥主理解或编辑：
 
 - `ThemePack`
 - `WorldStoryGraph`
@@ -98,7 +98,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 - 稀有度映射
 - 掉落和 build 权重
 
-创作者应该编辑的是自然语言与内容卡，而不是运行时图结构。
+陶泥主应该编辑的是自然语言与内容卡，而不是运行时图结构。
 
 ## 2.4 先少量必填，再逐层展开
 
@@ -107,9 +107,9 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 ```text
 先填最小必填卡
 -> AI 生成世界初稿
--> 创作者修改关键对象
+-> 陶泥主修改关键对象
 -> 系统继续展开长尾
--> 创作者决定是否进入高级补充
+-> 陶泥主决定是否进入高级补充
 ```
 
 ## 2.5 默认清爽，深度能力后置
@@ -127,27 +127,27 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 ## 3. 最终建议：三层分工
 
-## 3.1 第一层：必须要求创作者手动填写
+## 3.1 第一层：必须要求陶泥主手动填写
 
 这一层只保留最影响作品质量的高杠杆锚点，建议默认强制填写 6 张卡。
 
-## 3.2 第二层：AI 生成后支持创作者修改
+## 3.2 第二层：AI 生成后支持陶泥主修改
 
-这一层由 AI 根据第一层锚点自动展开成专业剧情策划初稿，创作者可以逐项修改、锁定、局部重生成。
+这一层由 AI 根据第一层锚点自动展开成专业剧情策划初稿，陶泥主可以逐项修改、锁定、局部重生成。
 
 ## 3.3 第三层：其余都交给系统
 
-这一层是把前两层编译成可运行游戏结构所需的系统字段、数值和运行时指令，默认不要求创作者处理。
+这一层是把前两层编译成可运行游戏结构所需的系统字段、数值和运行时指令，默认不要求陶泥主处理。
 
 ---
 
 ## 4. 最低门槛方案：只强制手填 6 张卡
 
-如果目标是尽可能降低门槛，同时又保留作品辨识度，建议只强制创作者填写以下 6 张卡。
+如果目标是尽可能降低门槛，同时又保留作品辨识度，建议只强制陶泥主填写以下 6 张卡。
 
 ## 4.1 卡 1：世界一句话与核心幻想
 
-创作者必须手填：
+陶泥主必须手填：
 
 - 世界一句话设定
 - 玩家来到这个世界最想体验的感觉
@@ -165,7 +165,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 ## 4.2 卡 2：玩家身份与开局困境
 
-创作者必须手填：
+陶泥主必须手填：
 
 - 玩家是谁
 - 玩家开局最缺什么
@@ -179,7 +179,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 ## 4.3 卡 3：主题气质与禁忌边界
 
-创作者必须手填：
+陶泥主必须手填：
 
 - 主题关键词
 - 情绪基调
@@ -199,7 +199,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 ## 4.4 卡 4：核心冲突
 
-创作者必须手填：
+陶泥主必须手填：
 
 - 当前世界最重要的 `1~3` 个明面冲突
 - 至少 `1` 个隐藏问题或暗面危机
@@ -212,9 +212,9 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 ## 4.5 卡 5：关键关系钩子
 
-这里不强制创作者一开始填写完整角色档案，只要求填写更高杠杆的“关系骨架”。
+这里不强制陶泥主一开始填写完整角色档案，只要求填写更高杠杆的“关系骨架”。
 
-创作者必须手填：
+陶泥主必须手填：
 
 - `2~4` 条关键关系钩子
 - 每条钩子至少说明：
@@ -229,7 +229,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 ## 4.6 卡 6：标志性要素与硬规则
 
-创作者必须手填：
+陶泥主必须手填：
 
 - `2~5` 个标志性要素
   - 物件
@@ -247,11 +247,11 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 ---
 
-## 5. 不建议强制手填，但应该让 AI 生成后支持创作者修改的设定
+## 5. 不建议强制手填，但应该让 AI 生成后支持陶泥主修改的设定
 
 这一层是平衡“低门槛”和“高质量”的关键。
 
-创作者不需要从零填写这些内容，但 AI 生成后必须能看、能改、能锁定、能局部重生成。
+陶泥主不需要从零填写这些内容，但 AI 生成后必须能看、能改、能锁定、能局部重生成。
 
 ## 5.1 世界外观层
 
@@ -282,7 +282,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 原因：
 
 - 势力很重要，但让新手一开始手写完整势力表太重
-- 更合理的做法是让 AI 基于核心冲突先出草稿，再由创作者修正
+- 更合理的做法是让 AI 基于核心冲突先出草稿，再由陶泥主修正
 
 ## 5.3 关键角色层
 
@@ -302,8 +302,8 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 原因：
 
-- 创作者已经通过“关系钩子”给出最关键的人物骨架
-- AI 负责把钩子展开成可编辑角色卡，创作者再做精修
+- 陶泥主已经通过“关系钩子”给出最关键的人物骨架
+- AI 负责把钩子展开成可编辑角色卡，陶泥主再做精修
 
 ## 5.4 关键地点层
 
@@ -319,7 +319,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 原因：
 
 - 地点是世界感的重要来源
-- 但新创作者未必能一开始就写出完整地点网络
+- 但新陶泥主未必能一开始就写出完整地点网络
 
 ## 5.5 世界线程层
 
@@ -335,7 +335,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 原因：
 
 - 线程是专业剧情结构，适合 AI 先搭骨架
-- 但创作者必须有权修正哪条线更重要、哪条线该隐藏
+- 但陶泥主必须有权修正哪条线更重要、哪条线该隐藏
 
 ## 5.6 主线章节层
 
@@ -350,9 +350,9 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 原因：
 
-- 创作者已经给出了世界目标、冲突和关系
+- 陶泥主已经给出了世界目标、冲突和关系
 - AI 可以先把它们编成主线章节初稿
-- 创作者再选择保留、删减或重排
+- 陶泥主再选择保留、删减或重排
 
 ## 5.7 支线、角色线、阵营线层
 
@@ -367,7 +367,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 原因：
 
 - 这是最适合 AI 拉开内容宽度的部分
-- 也是最需要创作者局部精修的部分
+- 也是最需要陶泥主局部精修的部分
 
 ## 5.8 场景章节层
 
@@ -384,7 +384,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 原因：
 
 - 当前项目已经在走“场景 = 章节单元”的方向
-- 这层非常适合 AI 编排出第一版，再由创作者补强记忆点
+- 这层非常适合 AI 编排出第一版，再由陶泥主补强记忆点
 
 ## 5.9 叙事载体层
 
@@ -397,7 +397,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 - 场景遗物
 - 怪物命名及其故事指向
 
-创作者主要修改：
+陶泥主主要修改：
 
 - 哪些载体最重要
 - 哪些载体和哪条线程绑定
@@ -417,13 +417,13 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 原因：
 
 - 这些内容适合 AI 批量铺量
-- 创作者只需要挑、改、锁定，不必从零起草
+- 陶泥主只需要挑、改、锁定，不必从零起草
 
 ---
 
 ## 6. 其余设定应交给系统托管
 
-以下内容不建议默认暴露给创作者编辑，应由系统根据前两层自动编译和维护。
+以下内容不建议默认暴露给陶泥主编辑，应由系统根据前两层自动编译和维护。
 
 ## 6.1 题材与术语编译层
 
@@ -450,7 +450,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 原因：
 
-- 创作者要的是“故事线能对”，不是维护图数据库
+- 陶泥主要的是“故事线能对”，不是维护图数据库
 
 ## 6.3 可见性和 prompt 裁剪层
 
@@ -465,7 +465,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 原因：
 
 - 这层必须稳定、严格、自动化
-- 不适合依赖创作者手动维护
+- 不适合依赖陶泥主手动维护
 
 ## 6.4 运行时导演层
 
@@ -494,7 +494,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 说明：
 
-- 创作者可以编辑“任务卡”和“章节卡”
+- 陶泥主可以编辑“任务卡”和“章节卡”
 - 但不应默认编辑底层 contract 结构
 
 ## 6.6 数值与配置层
@@ -511,7 +511,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 说明：
 
-- 创作者可以给“偏向”
+- 陶泥主可以给“偏向”
 - 系统负责编译成具体数值
 
 ## 6.7 QA 与一致性层
@@ -547,7 +547,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 | 主线 | 不强制首轮手写完整主线 | 幕结构、章节卡、高潮与 handoff | 章节状态编译 |
 | 支线/角色线 | 不强制首轮手写完整矩阵 | 支线种子、角色线事件、阵营线分歧 | 任务 contract 编译 |
 | 场景章节 | 不强制首轮手写全量章节 | 场景章节卡、阶段内容、章节载体 | signal 与导演层 |
-| 运行时结构 | 不建议创作者接触 | 不建议默认编辑 | 可见性、导演、信号、编译、QA |
+| 运行时结构 | 不建议陶泥主接触 | 不建议默认编辑 | 可见性、导演、信号、编译、QA |
 
 ---
 
@@ -555,7 +555,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 ## 8.1 第一步：只填写最小必填集
 
-创作者只需要完成：
+陶泥主只需要完成：
 
 1. 世界一句话与核心幻想
 2. 玩家身份与开局困境
@@ -584,9 +584,9 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 这里的重点不是一次补满全世界，而是先形成一个像样的内容骨架。
 
-## 8.3 第三步：创作者只精修高价值卡片
+## 8.3 第三步：陶泥主只精修高价值卡片
 
-建议默认优先让创作者编辑这 4 类卡片：
+建议默认优先让陶泥主编辑这 4 类卡片：
 
 1. 关键角色
 2. 核心冲突与线程
@@ -606,7 +606,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 - 任务包装
 - 文案变体
 
-## 8.5 第五步：创作者按需进入高级模式
+## 8.5 第五步：陶泥主按需进入高级模式
 
 高级模式只对愿意深挖的人开放：
 
@@ -665,7 +665,7 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 ## 10.2 每张卡只保留自然语言输入
 
-不要强迫创作者在首轮填写：
+不要强迫陶泥主在首轮填写：
 
 - tags
 - ids
@@ -676,20 +676,20 @@ AI 生成后允许创作者修改的，不应该是一堆技术型字段，而
 
 更合理的做法是：
 
-- 让创作者输入自然语言或选择直觉标签
+- 让陶泥主输入自然语言或选择直觉标签
 - 再由系统编译成结构化字段
 
 ## 10.3 首轮生成后默认先看“精修建议”
 
-AI 初稿生成后，不应该把创作者直接扔进一个大编辑器。
+AI 初稿生成后，不应该把陶泥主直接扔进一个大编辑器。
 
 更好的做法是先给出：
 
 1. 哪些卡片最值得改
 2. 哪些内容已经比较稳定
-3. 哪些内容仍然偏泛，需要创作者补个性
+3. 哪些内容仍然偏泛，需要陶泥主补个性
 
-这样能明显提高创作者的修改效率。
+这样能明显提高陶泥主的修改效率。
 
 ## 10.4 移动端优先只保留高杠杆操作
 
@@ -707,15 +707,15 @@ AI 初稿生成后，不应该把创作者直接扔进一个大编辑器。
 
 ## 11. 最后结论
 
-如果目标是在自定义世界创作中真正平衡“降低门槛”和“提高作品质量”，最好的做法不是让创作者填更多字段，也不是把一切都交给 AI。
+如果目标是在自定义世界创作中真正平衡“降低门槛”和“提高作品质量”，最好的做法不是让陶泥主填更多字段，也不是把一切都交给 AI。
 
 更合理的平衡是：
 
-1. 创作者必须手填最小但高杠杆的 6 张卡，掌握世界灵魂。
+1. 陶泥主必须手填最小但高杠杆的 6 张卡，掌握世界灵魂。
 2. AI 根据这 6 张卡生成一套可编辑的专业剧情初稿，负责把骨架展开成角色、地点、线程、章节和载体。
-3. 创作者只精修最有价值的关键对象，锁定真正重要的内容。
+3. 陶泥主只精修最有价值的关键对象，锁定真正重要的内容。
 4. 其余运行结构、数值、可见性、任务编译和 QA 检查都交给系统托管。
 
 一句话收束：
 
-**创作者负责决定“这个世界为什么值得被创作”，AI 负责把它整理成可修改的策划初稿，系统负责把它稳定地跑成一个游戏世界。**
+**陶泥主负责决定“这个世界为什么值得被创作”，AI 负责把它整理成可修改的策划初稿，系统负责把它稳定地跑成一个游戏世界。**

docs/design/CUSTOM_WORLD_CREATOR_PURE_AGENT_COMPARISON_AND_CONVERSION_DESIGN_2026-04-12.md

@@ -10,7 +10,7 @@
    - 基于“最小必填锚点 + AI 初稿卡片 + 系统托管层”的结构化创作方案
 
 2. 纯 Agent 式方向
-   - 以前台对话为唯一主交互，创作者主要通过和 Agent 聊天来完成世界构建、角色塑造、剧情扩展和修改
+   - 以前台对话为唯一主交互，陶泥主主要通过和 Agent 聊天来完成世界构建、角色塑造、剧情扩展和修改
 
 文档需要回答 3 个问题：
 
@@ -34,7 +34,7 @@
 
 当前方案的核心是：
 
-1. 创作者手填最小高杠杆锚点
+1. 陶泥主手填最小高杠杆锚点
 2. AI 生成一批可编辑的剧情策划初稿卡片
 3. 系统把内容编译成运行时结构
 
@@ -42,7 +42,7 @@
 
 **结构化工作台 + AI 协作生成。**
 
-创作者的主要行为是：
+陶泥主的主要行为是：
 
 1. 填写关键卡片
 2. 修改关键角色、地点、势力、章节等内容卡
@@ -53,9 +53,9 @@
 
 纯 Agent 式不是指“系统内部没有结构”，而是指：
 
-**创作者前台几乎不需要面对表单和卡片编辑器，主要通过自然语言对话来完成创作。**
+**陶泥主前台几乎不需要面对表单和卡片编辑器，主要通过自然语言对话来完成创作。**
 
-创作者的主要行为变成：
+陶泥主的主要行为变成：
 
 1. 用自然语言描述世界想法
 2. 回答 Agent 的追问
@@ -77,7 +77,7 @@
 
 1. 前台用户主要通过什么方式思考和输入？
 2. 后台系统是否仍然有稳定的世界模型和编译层？
-3. 创作者是否还能看见摘要、锁定内容和修改范围？
+3. 陶泥主是否还能看见摘要、锁定内容和修改范围？
 
 对当前项目来说，真正危险的不是“转成聊天”，而是：
 
@@ -93,11 +93,11 @@
 
 它更擅长：
 
-1. 帮不擅长表单和结构思考的创作者起步
-2. 在创作者思路模糊时做追问和陪创作
+1. 帮不擅长表单和结构思考的陶泥主起步
+2. 在陶泥主思路模糊时做追问和陪创作
 3. 把“我要做一个世界”变成一次自然聊天
 4. 动态决定追问深度，而不是一上来摆很多字段
-5. 让创作者感觉自己是在和一个懂 RPG 的剧情搭档共创
+5. 让陶泥主感觉自己是在和一个懂 RPG 的剧情搭档共创
 
 ## 2.2 纯 Agent 式的主要问题
 
@@ -110,7 +110,7 @@
 1. 聊天很多，但世界状态越来越难总览
 2. 角色、地点、势力和章节信息散落在多轮消息里
 3. 锁定范围不清，重生成容易误伤已有内容
-4. Agent 很容易“替创作者决定太多”
+4. Agent 很容易“替陶泥主决定太多”
 5. 长会话越来越贵，越来越慢，也越来越容易漂移
 
 ## 2.3 对当前项目的判断
@@ -197,7 +197,7 @@
 
 纯 Agent 式更弱的地方在于：
 
-1. 世界模型隐藏得太深时，创作者会失去整体掌控感
+1. 世界模型隐藏得太深时，陶泥主会失去整体掌控感
 2. 多轮对话后，已确定内容不容易被清晰回看
 3. 局部重做和精确编辑边界会变模糊
 4. Agent 容易过度代写、过度主导
@@ -223,7 +223,7 @@
 
 因为这些环节的关键问题不是“字段如何摆放”，而是：
 
-**创作者有没有被真正引导出自己想做的世界。**
+**陶泥主有没有被真正引导出自己想做的世界。**
 
 ## 4.2 不值得直接转成纯聊天黑箱的部分
 
@@ -261,8 +261,8 @@
 
 即使转成纯 Agent 式，也仍然要保留这三层：
 
-1. 创作者必须确认的高杠杆锚点
-2. AI 生成但允许创作者修改的策划初稿层
+1. 陶泥主必须确认的高杠杆锚点
+2. AI 生成但允许陶泥主修改的策划初稿层
 3. 系统托管的运行时编译层
 
 变化的只是：
@@ -339,7 +339,7 @@
 2. 会阶段性总结
 3. 会把聊天结果沉淀成结构化世界状态
 4. 会提醒风险和冲突
-5. 会在创作者要求时进行局部重写和定向扩展
+5. 会在陶泥主要求时进行局部重写和定向扩展
 
 ## 6.2 正确理解
 
@@ -349,7 +349,7 @@
 
 也就是说：
 
-1. 创作者看到的是对话
+1. 陶泥主看到的是对话
 2. 系统内部维护的是世界模型、锁定状态、摘要和编译结果
 
 ---
@@ -389,7 +389,7 @@ Agent 首轮不应该直接铺满全世界，而应该给出一份简明底稿
 2. 建议内容
 3. 待确认内容
 
-## 7.3 阶段 C：创作者锁定锚点
+## 7.3 阶段 C：陶泥主锁定锚点
 
 在纯 Agent 模式里，锁定行为必须被显式支持。
 
@@ -455,7 +455,7 @@ Agent 不应该每轮都继续扩全局，而应该支持“单对象工作模
 
 | 结构 | 作用 |
 | --- | --- |
-| `creatorIntentProfile` | 当前创作者最初和最新的创作意图 |
+| `creatorIntentProfile` | 当前陶泥主最初和最新的创作意图 |
 | `lockedAnchors` | 已确认不可自动改写的内容 |
 | `worldDraftSnapshot` | 当前世界底稿快照 |
 | `editableDraftCards` | 角色、地点、势力、章节等可编辑初稿 |
@@ -530,7 +530,7 @@ Agent 不能像问卷系统，也不能一次追问太多。
 1. 一次最多追问 `1~3` 个问题
 2. 问题必须是当前最缺的高杠杆信息
 3. 每次追问都给默认建议方向
-4. 如果创作者不想细答，允许 Agent 先代补一个版本再确认
+4. 如果陶泥主不想细答，允许 Agent 先代补一个版本再确认
 
 这样才能保持“像聊天”，而不是“像客服表单”。
 
@@ -614,14 +614,14 @@ Agent 应能识别这些常见修改类型：
 3. 锁定内容固定展示
 4. 提供“当前世界圣经”入口
 
-## 11.2 风险 2：Agent 过度代写，创作者失去作品归属感
+## 11.2 风险 2：Agent 过度代写，陶泥主失去作品归属感
 
 防护方式：
 
 1. 高杠杆锚点必须要求确认
 2. 重要改动前先说“我准备改什么”
 3. 默认优先给多个候选，而不是直接盖写
-4. 允许创作者随时回退到旧版本
+4. 允许陶泥主随时回退到旧版本
 
 ## 11.3 风险 3：局部修改带出全局漂移
 

docs/design/CUSTOM_WORLD_SELF_OWNED_SETTING_LAYER_OPTIMIZATION_2026-04-08.md

@@ -37,8 +37,8 @@
    - 不能先删旧字段，再补新结构。
    - 必须先补新设定层，再逐步迁读，最后再让旧模板字段退化成兼容层。
 
-4. 不能增加创作者负担
-   - 这次不是让创作者多填一堆底层 schema。
+4. 不能增加陶泥主负担
+   - 这次不是让陶泥主多填一堆底层 schema。
    - 这些设定仍然应由 AI / 系统编译出来，只是所有权从模板世界转移到自定义世界自己。
 
 ---

docs/design/CUSTOM_WORLD_TEMPLATE_DECOUPLING_AND_CROSS_GENRE_GENERALIZATION_DESIGN_2026-04-08.md

@@ -102,9 +102,9 @@
 
 这不是真正跨题材，只是换了名字。
 
-## 3.3 不能让创作者承担更多底层配置工作
+## 3.3 不能让陶泥主承担更多底层配置工作
 
-这次优化不是让创作者额外填写：
+这次优化不是让陶泥主额外填写：
 
 - 怪物模板表
 - 场景参考池

docs/design/LEVEL_PROGRESS_AND_CHAPTER_NPC_AUTO_SCALING_DESIGN_2026-04-20.md

@@ -349,7 +349,7 @@ export interface ChapterProgressionPlan {
 }
 ```
 
-建议作为后端运行时编译结果缓存，不作为创作者直接编辑字段。
+建议作为后端运行时编译结果缓存，不作为陶泥主直接编辑字段。
 
 ## 3.7 章节经验记账
 
@@ -636,7 +636,7 @@ chapterXpBudget =
 3. 非主角色友方 NPC
    - `support` 或 `ambient`
 
-如需修正，再允许章节蓝图加可选 override，但不要求创作者每次手填。
+如需修正，再允许章节蓝图加可选 override，但不要求陶泥主每次手填。
 
 ## 7.2 等级锚点
 

docs/design/MOBILE_CREATION_NEW_WORK_COMPACT_LAYOUT_2026-04-24.md

@@ -17,10 +17,13 @@
 3. 卡片高度控制在约 4rem 内，标题与状态信息并排组织，避免大留白。
 4. 模块本体使用 `max-height: 33svh` 作为硬约束，内容超出时优先在模板入口行内横向滚动，不撑高页面。
 5. 桌面端保持网格入口，但同步收紧内边距和卡片留白，避免移动端与桌面端表现割裂。
+6. 横向滚动模板行必须隐藏原生滚动条，保留滑动能力，避免底部出现过粗的视觉条。
 
 ## 文案约束
 
 - UI 不新增规则说明类文案。
 - 原有“直接选择游戏创作模板，立刻进入对应的共创工作台。”说明在移动端隐藏，桌面端保留为辅助说明。
-- 锁定、可创建、正在开启等状态继续来自既有模板元数据或忙碌状态。
-
+- 可创建的模板卡不展示“可创建”状态标签，只保留标题、短副标题和进入箭头。
+- 锁定的模板卡统一以“敬请期待”作为状态标注，不再显示“锁定”。
+- RPG 入口展示为“角色扮演 / 剧情演绎，冒险成长”，拼图入口展示为“拼图 / 创意礼物，生活分享”。
+- 忙碌状态仅保留在模块标题行的轻量状态中，避免占用每张可用卡片的首要视觉层级。

docs/design/MOBILE_CREATION_WORK_LIST_TWO_COLUMN_LAYOUT_2026-04-29.md

@@ -0,0 +1,46 @@
+# 移动端创作页作品列表统一卡片设计 2026-04-29
+
+## 背景
+
+创作页的作品模块需要同时承载 RPG、拼图和大鱼吃小鱼等玩法。不同玩法卡片不能各自展示阶段、素材、主题等细节标签，否则作品列表会在移动端显得拥挤，并且草稿作品会暴露过多编辑态信息。
+
+本次将作品列表卡片收口成统一信息结构：草稿只用于快速识别和继续创作，已发布作品才展示公开数据与分享入口。
+
+## 落地范围
+
+- 列表容器：`src/components/custom-world-home/CustomWorldCreationHub.tsx`
+- 作品卡片：`src/components/custom-world-home/CustomWorldWorkCard.tsx`
+- 不改动作品数据聚合、筛选、打开和体验逻辑。
+- 已发布作品右上角动作从删除改为分享；草稿仍保留删除入口。
+
+## 卡片结构规则
+
+1. 标题上方只显示两个标签：作品状态与游戏类型。
+2. 不再显示阶段、主题、素材完成度、作者、作品号等额外标签。
+3. 标签下方依次显示作品名称与作品描述。
+4. 草稿卡片到作品描述为止，不显示其他统计、作品号或体验按钮。
+5. 已发布卡片在描述下方显示三项公开指标：游玩数、改造数、点赞数。
+6. 已发布卡片右上角显示分享 icon，点击后复制作品分享文案，不触发卡片打开。
+7. 草稿卡片右上角继续显示删除 icon，点击删除不触发卡片打开。
+
+## 公开指标重点展示补充
+
+1. 已发布作品的三项公开指标不得继续使用标签样式展示，必须参考作品详情页的统计区，采用“小标签 + 大数字 + 单位”的重点信息结构。
+2. 指标文案统一为“游玩”“改造”“点赞”，不得在创作页卡片中展示 `Remix` 英文。
+3. 用户每次进入创作页时，前端读取上一次进入该页面缓存的公开指标快照；当已发布作品卡片滑动进入视口后，数字从缓存值增长到本次接口返回的最新值。
+4. 若最新值高于缓存值，动画完成后在对应指标右下角展示红色向上箭头和本次上涨的具体数值，字号低于主数字，避免抢占主信息层级。
+5. 若没有缓存值、缓存值不低于最新值或作品仍是草稿，则直接显示最新值，不展示上涨标记。
+6. 每张作品卡片继续使用作品封面作为整卡背景，封面需要有透明度和渐变遮罩，确保标题、描述和指标在亮色与暗色主题下都清晰可读。
+
+## 移动端布局规则
+
+1. 作品列表默认仍使用 2 列网格，保证草稿可以快速扫视。
+2. 已发布作品卡片在移动端固定 `col-span-2`，即占据一整行，避免公开指标和分享入口互相挤压。
+3. `sm` 及以上视口恢复普通网格跨度，由卡片自然进入多列布局。
+4. 小屏卡片降低高度、内边距、标题字号和徽标尺寸，避免长标题或中文描述撑破容器。
+
+## 文案约束
+
+- 不新增功能说明类文案。
+- 空态和错误态沿用现有文案。
+- 中文标题、描述和指标需要在卡片内截断或换行，不得因长文本破坏布局。

docs/design/PLATFORM_HOME_CATEGORY_AND_RANKING_TAB_REDESIGN_2026-04-29.md

@@ -0,0 +1,82 @@
+# 平台首页分类入口与排行 Tab 调整设计
+
+更新时间：`2026-04-29`
+
+## 1. 本次目标
+
+1. 首页移动端频道只保留“推荐、今日游戏、游戏分类”，删除“PC游戏、即点即玩”。
+2. 原底部“分类” Tab 改为“排行” Tab，不再单独承载分类页。
+3. 原分类 Tab 的标签筛选移动到首页移动端“游戏分类”频道中，作品展示从双列网格改为应用商店式纵向列表。
+4. 排行页参考榜单式纵向布局，提供热门榜、改造榜、新品榜、点赞榜四个榜单切换。
+5. 页面继续使用平台主题变量、现有字号层级与卡片组件，避免新增大段功能说明文案。
+
+## 2. 数据口径
+
+当前公开作品聚合列表已经透传后端读模型字段：
+
+- `playCount`：历史游玩次数。
+- `remixCount`：历史改造次数。
+- `likeCount`：历史点赞次数。
+- `recentPlayCount7d`：近 7 日新增游玩次数。
+- `publishedAt / updatedAt`：发布时间或更新时间。
+
+本次新增 `public_work_play_daily_stat` 日桶读模型，所有公开玩法的正式游玩入口在累加历史 `playCount` 时同步写入该表。公开列表返回时按作品聚合最近 7 个 UTC 自然日的 `recentPlayCount7d`，前端只负责展示与排序。
+
+1. 热门榜按 `playCount` 降序。
+2. 改造榜按 `remixCount` 降序。
+3. 点赞榜按 `likeCount` 降序。
+4. 新品榜按 `recentPlayCount7d` 降序。
+
+## 3. 交互规则
+
+### 3.1 首页移动端
+
+- 顶部搜索框保持不变。
+- 频道横滑 Tab 顺序为：推荐、今日游戏、游戏分类。
+- 推荐展示精选与最新去重后的作品流。
+- 今日游戏只展示 `publishedAt` 落在玩家当前浏览器自然日内的新发布公开作品；跨日旧作品即使仍在最新列表前排，也不能进入该频道。
+- 游戏分类展示原分类页内容：筛选胶囊 + 横向标签 + 当前标签下纵向作品列表。
+- 游戏分类列表参考移动应用商店结构，不再使用双列卡片：左侧方形封面，中间为作品名、状态角标、评分/题材、摘要或热度短句，右侧为“启动/试玩”主按钮。
+- 分类频道的筛选区只保留短标签，不写功能说明文案；筛选按钮展示当前标签数量，横向标签展示可切换的分类入口。
+
+### 3.2 底部导航
+
+- 登录态：`首页 / 排行 / 创作 / 存档 / 我的`。
+- 未登录态：`首页 / 创作 / 排行`。
+- 底部排行入口仍复用原 `category` Tab 的路由值，减少导航状态迁移风险，但所有用户可见文案改为“排行”。
+
+### 3.3 排行页
+
+- 顶部为横向榜单 Tab：热门榜、改造榜、新品榜、点赞榜。
+- 下方为纵向榜单列表，每行展示排名、封面、作品名、榜单指标、玩法类别、两个标签与进入按钮。
+- 公开作品名称在列表与卡片中统一限制为最多 8 字；公开作品标签统一限制为最多 4 字。
+- 排行榜单条目正文固定为三行：第一行作品名，第二行榜单数据与玩法类别，第三行展示两个标签；不再显示发布时间、作者名等第四行信息。
+- 无数据或加载中沿用现有短空态文案。
+
+## 4. 编码落点
+
+- `src/components/rpg-entry/RpgEntryHomeView.tsx`
+  - 精简首页频道枚举。
+  - 增加排行榜单构造、榜单切换状态与榜单行组件。
+  - 将分类内容移动到移动端首页“游戏分类”频道。
+  - 增加游戏分类纵向列表条目组件，替换移动端分类频道的双列作品网格。
+  - 将底部/桌面侧边导航文案从“分类”改为“排行”。
+- `src/index.css`
+  - 增加榜单行、榜单切换按钮、游戏分类筛选栏和纵向列表条目的主题化样式。
+- `server-rs/crates/spacetime-module/src/runtime/profile.rs`
+  - 增加公开作品每日游玩统计表与 7 日聚合 helper。
+- `server-rs/crates/spacetime-module/src/migration.rs`
+  - migration 表清单对齐 `public_work_play_daily_stat`。
+- `server-rs/crates/shared-contracts/src/*_works.rs`、`packages/shared/src/contracts/*`
+  - 公开作品响应补齐 `recentPlayCount7d`。
+
+## 5. 验收点
+
+1. 移动端首页不再显示“PC游戏、即点即玩”。
+2. 点击首页“游戏分类”能看到原分类标签与作品列表。
+   - 移动端分类作品必须为纵向列表，不能回退为两列网格。
+   - 单条作品在 390px 宽度下必须保持封面、标题、按钮同一行可扫读，摘要截断且不挤压右侧按钮。
+3. 点击首页“今日游戏”只显示当天新发布作品；仅更新时间为今天但发布时间不在今天的作品不能进入今日频道。
+4. 底部导航显示“排行”，不再显示“分类”。
+5. 排行页可切换四个榜单，排序口径符合当前字段约束。
+6. 不修改 server-node，不新增 PostgreSQL 相关实现。

docs/design/PLATFORM_HOME_MOBILE_FEED_CARD_REDESIGN_2026-04-28.md

@@ -28,6 +28,24 @@ likeCount: number
 3. 大鱼公开广场：`BigFishWorkSummary` 返回 `likeCount`，当前由 Rust facade 返回 `0`，`playCount` 继续仅表示游玩次数。
 4. 前端聚合类型 `PlatformPublicGalleryCard` 透传 `likeCount`，`WorldCard` 不再依赖 `badge/metaLabel` 决定主要信息结构。
 
+### 2.3 首页读链路核对
+
+首页公开作品流的读取链路固定为：
+
+```text
+RpgEntryHomeView
+→ platformPublicGalleryClient / puzzleGalleryClient / bigFishGalleryClient
+→ Rust api-server
+→ spacetime-client 生成绑定
+→ spacetime-module procedure
+→ SpacetimeDB 表
+```
+
+1. 公开读取必须匿名可用，前端 `GET` 列表与详情统一传 `skipAuth: true`、`skipRefresh: true`，避免未登录首页被刷新 token 链路阻断。
+2. 拼图公开广场走 `list_puzzle_gallery` / `get_puzzle_gallery_detail`，返回 `coverImageSrc`、`summary`、`themeTags`、`playCount`、`remixCount`、`likeCount`。
+3. 大鱼公开广场走 `list_big_fish_works(published_only=true)`；由于部分已部署模块会在公开列表分支前仍校验 `owner_user_id` 非空，客户端与模块内部公共列表输入都使用 `public-big-fish-gallery` 占位 owner。该字段在 `published_only` 分支不参与筛选，只用于兼容旧校验。
+4. 自定义世界公开广场走 `list_custom_world_gallery_entries`，当前主云数据为空时应返回成功空列表，而不是错误态。
+
 ## 3. 移动端布局
 
 1. 移动端首页只在 `RpgEntryHomeView` 的 mobile content 内重排。
@@ -57,3 +75,7 @@ likeCount: number
 2. 桌面端首页布局区块顺序不变，只替换公开作品卡内部结构。
 3. RPG、拼图、大鱼三类公开作品卡都有 `likeCount` 字段，前端聚合后能统一展示。
 4. 运行编码检查、前端定向测试和必要的 Rust 检查。
+5. HTTP 验收需覆盖：
+   - `GET /api/runtime/custom-world-gallery` 成功返回 `entries`。
+   - `GET /api/runtime/puzzle/gallery` 成功返回 `items` 且包含 `likeCount`。
+   - `GET /api/runtime/big-fish/gallery` 成功返回 `items`，旧部署模块不再因 `big_fish.owner_user_id 不能为空` 阻断首页。

docs/design/PLATFORM_HOME_PUBLIC_BROWSE_AND_LOGIN_MODAL_GATING_DESIGN_2026-04-19.md

@@ -96,7 +96,7 @@
 - 同时开放短信与密码登录时，面板顶部展示两个居中的文字页签，当前页签使用深色字重和短下划线强调。
 - 只渲染当前页签对应的输入区；切换页签不弹出新面板，不展示二维码入口。
 - `短信登录` 页签包含手机号、验证码、获取验证码和主按钮。
-- `密码登录` 页签只包含手机号、密码、主按钮和忘记密码入口；不支持邮箱、用户名或叙世号。
+- `密码登录` 页签只包含手机号、密码、主按钮和忘记密码入口；不支持邮箱、用户名或陶泥号。
 - 密码登录只是手机号验证码登录的补充方式：只有已登录并设置过密码的手机号账号才能使用，不能在密码页签创建账号。
 - `密码登录` 主按钮固定为 `登录`，不得使用 `注册/登录`。
 - 未开放某个登录方式时不展示对应页签，避免用户进入不可用表单。

docs/design/PLATFORM_UI_NON_PIXEL_REFRESH_2026-04-19.md

@@ -59,8 +59,8 @@
 ### 3.2 排版
 
 - 平台层正文、按钮、说明、功能标签统一使用非像素字体
-- 左上角 `叙世 / GENARRATIVE` 品牌字标允许单独做成像素化 logo
-- `GENARRATIVE` 与 `叙世` 都优先直接使用游戏内同款 `Fusion Pixel`
+- 左上角 `陶泥 / GENARRATIVE` 品牌字标允许单独做成像素化 logo
+- `GENARRATIVE` 与 `陶泥` 都优先直接使用游戏内同款 `Fusion Pixel`
 - 品牌字标默认保持正常像素字观感，禁止再叠双层粗阴影或手动加粗到影响识别
 - 品牌字标直接使用字体文件内原字形，不额外做运行时描字、轮廓拼字或伪粗体处理
 - 主标题保留明显层级，但不再做像素描边效果

docs/design/PLATFORM_WORK_DETAIL_AND_REMIX_DESIGN_2026-04-28.md

@@ -1,11 +1,11 @@
 # 平台统一作品详情页与 Remix 数据链路设计
 
-更新时间：`2026-04-28`
+更新时间：`2026-04-29`
 
 ## 1. 本次目标
 
 1. 平台首页、公开广场、分类列表中的每个公开作品点击后，统一先进入作品详情页，不再直接启动玩法。
-2. 作品详情页结构参考 TapTap 详情页：顶部封面图、作品基础信息、右侧 Remix 按钮、四项统计、简介内容、底部启动按钮。
+2. 作品详情页结构参考 TapTap 详情页：顶部封面图、作品基础信息、右侧“作品改造”按钮、四项统计、简介内容、底部启动按钮。
 3. 删除参考图顶部 Tab，不接入评价和论坛功能，不展示“开发者的话”模块。
 4. 统计数据必须从数据库读模型贯穿到前端展示，禁止在前端用假字段、游玩数冒充点赞数或固定文案代替真实字段。
 5. Remix 按钮必须由后端事务复制公开作品为当前用户草稿，并同步增加原作品改造次数，成功后前端进入新草稿详情/结果页。
@@ -15,18 +15,21 @@
 统一详情页只做作品展示与动作入口，不承担规则说明。
 
 1. 顶部导航：返回按钮、标题“详情”、更多按钮占位；不展示“统计 / 详情 / 评价 / 论坛”Tab。
-2. 封面区：使用作品封面图作为主视觉，背景可用同图弱化铺底；缺图时只显示平台主题底，不新增说明文字。
+2. 封面区：固定 `16:9` 比例，使用作品封面图 `cover` 填满整块主视觉；背景可用同图弱化铺底；缺图时只显示平台主题底，不新增说明文字。
 3. 基础信息区：
    - 左侧作品图标使用作品封面或首图。
-   - 中间展示作品名、作者名、玩法类型。
-   - 右侧原 TapTap 评分位置替换为 `Remix` 按钮。
+   - 中间展示作品名、作者头像、作者名、玩法类型；作者头像读取公开用户资料 `avatarUrl`，缺失时使用作者昵称首字占位。
+   - 右侧原 TapTap 评分位置替换为 `作品改造` 按钮。
 4. 统计区固定四项：
-   - 改造次数：`remixCount`
-   - 游玩次数：`playCount`
-   - 点赞次数：`likeCount`
-   - 上线日期：`publishedAt`
+   - 改造：`remixCount`，显示为“数字 + 次”，单位放在数字后方。
+   - 游玩：`playCount`，显示为“数字 + 次”，单位放在数字后方。
+   - 点赞：`likeCount`，显示为“数字 + 赞”，单位放在数字后方。
+   - 最近更新：优先展示 `updatedAt`，缺失时回退 `publishedAt`；前端只负责格式化显示，必须兼容后端当前 `seconds.microsZ` 与 ISO 字符串两种真实时间文本，显示为完整 `YYYY-MM-DD`，使用更小字号并保持单行不换行。
+   - 四项统计需要使用浅色图标底强化识别，但不得追加规则说明类文案。
 5. 简介区：展示玩法标签和作品简介；不追加说明类文案。
 6. 底部动作：主按钮为“启动”，点击后进入对应玩法运行态并记录游玩次数。
+7. 页面配色必须跟随平台明暗主题变量；亮色主题使用平台浅色底、深色文字和主按钮渐变，暗色主题使用平台暗色底、亮色文字和对应主按钮渐变，不在详情页写死独立黑色皮肤。
+8. 字号规范跟随平台页面既有节奏：标题/主按钮使用 `1rem` 级别，作品名使用卡片标题同级 `1rem`，辅助信息与简介使用 `0.8125rem` / `0.875rem`，标签与统计标签使用 `0.75rem`，避免在详情页使用随视口放大的独立大字号。
 
 ## 3. 数据真相源
 
@@ -55,7 +58,7 @@
 ### 3.3 大鱼吃小鱼作品
 
 1. `big_fish_creation_session` 现有 `play_count` 继续作为游玩统计，新增 `remix_count`、`like_count`、`published_at`。
-2. `publish_big_fish_game` 写入 `published_at`，公开列表和详情用它展示上线日期。
+2. `publish_big_fish_game` 写入 `published_at` 与 `updated_at`，公开列表和详情优先用 `updated_at` 展示最近更新。
 3. `record_big_fish_play` 继续作为游玩次数递增入口。
 4. `remix_big_fish_work` 在同一事务内：
    - 校验源 session 为已发布作品。
@@ -65,7 +68,8 @@
 
 ## 4. API 与前端接入
 
-1. 三类公开作品摘要统一返回：`playCount`、`remixCount`、`likeCount`、`publishedAt`。
+1. 三类公开作品摘要统一返回：`playCount`、`remixCount`、`likeCount`、`publishedAt`、`updatedAt`。
+   - 作者头像不固化到作品读模型；详情页按 `authorPublicUserCode` 或 `ownerUserId` 读取公开用户摘要中的 `avatarUrl`，确保头像跟随账号资料更新。
 2. Remix API：
    - RPG：`POST /api/runtime/custom-world-gallery/{owner_user_id}/{profile_id}/remix`
    - 拼图：`POST /api/runtime/puzzle/gallery/{profile_id}/remix`
@@ -76,6 +80,8 @@
    - RPG：进入复制出的草稿详情。
    - 拼图：进入复制出的拼图结果页草稿。
    - 大鱼：进入复制出的大鱼结果页草稿。
+6. 拼图作品详情页启动时复用当前详情页已经展示的公开作品读模型，直接调用 `POST /api/runtime/puzzle/runs` 记录游玩并进入运行态；不得在启动前额外依赖 `GET /api/runtime/puzzle/gallery/{profile_id}`，避免开发代理或详情读取短断点阻塞启动链路。
+7. 本地开发时 `localhost:3000` 是 Vite 前端端口，`/api/**` 默认代理到 Rust `api-server:3100`；若 3100 未监听，点击启动或作品改造会在浏览器显示 `/api/... 500`，此时真实断点是 Rust 后端未启动，不允许用前端假数据替代后端事务。
 
 ## 5. 验收点
 

docs/design/README.md

@@ -4,12 +4,13 @@
 
 ## 文档列表
 
-- [CUSTOM_WORLD_CREATOR_INPUT_AND_AI_BOUNDARY_DESIGN_2026-04-06.md](./CUSTOM_WORLD_CREATOR_INPUT_AND_AI_BOUNDARY_DESIGN_2026-04-06.md)：自定义世界里创作者输入与 AI 分工边界设计。
+- [CUSTOM_WORLD_CREATOR_INPUT_AND_AI_BOUNDARY_DESIGN_2026-04-06.md](./CUSTOM_WORLD_CREATOR_INPUT_AND_AI_BOUNDARY_DESIGN_2026-04-06.md)：自定义世界里陶泥主输入与 AI 分工边界设计。
 - [CUSTOM_WORLD_CREATOR_MANUAL_AI_SYSTEM_BALANCE_DESIGN_2026-04-12.md](./CUSTOM_WORLD_CREATOR_MANUAL_AI_SYSTEM_BALANCE_DESIGN_2026-04-12.md)：自定义世界创作里“手填锚点 / AI 可改初稿 / 系统托管层”的平衡设计。
 - [CUSTOM_WORLD_CREATOR_PURE_AGENT_COMPARISON_AND_CONVERSION_DESIGN_2026-04-12.md](./CUSTOM_WORLD_CREATOR_PURE_AGENT_COMPARISON_AND_CONVERSION_DESIGN_2026-04-12.md)：纯 Agent 式创作工具与结构化工作台方案的优缺点对比，以及转型设计。
 - [CUSTOM_WORLD_TEMPLATE_DECOUPLING_AND_CROSS_GENRE_GENERALIZATION_DESIGN_2026-04-08.md](./CUSTOM_WORLD_TEMPLATE_DECOUPLING_AND_CROSS_GENRE_GENERALIZATION_DESIGN_2026-04-08.md)：把自定义世界从武侠/仙侠模板依赖迁到跨题材通用设定层的优化设计。
 - [CUSTOM_WORLD_SELF_OWNED_SETTING_LAYER_OPTIMIZATION_2026-04-08.md](./CUSTOM_WORLD_SELF_OWNED_SETTING_LAYER_OPTIMIZATION_2026-04-08.md)：把模板依赖逐步迁成自定义世界自有设定层，并保证不破坏当前生成流程的优化方案。
 - [MOBILE_CREATION_NEW_WORK_COMPACT_LAYOUT_2026-04-24.md](./MOBILE_CREATION_NEW_WORK_COMPACT_LAYOUT_2026-04-24.md)：移动端创作页新建作品模块最多占用首屏约 1/3 高度的紧凑布局设计。
+- [MOBILE_CREATION_WORK_LIST_TWO_COLUMN_LAYOUT_2026-04-29.md](./MOBILE_CREATION_WORK_LIST_TWO_COLUMN_LAYOUT_2026-04-29.md)：移动端创作页作品列表至少 2 列的紧凑布局设计。
 - [PLATFORM_HOME_MOBILE_FEED_CARD_REDESIGN_2026-04-28.md](./PLATFORM_HOME_MOBILE_FEED_CARD_REDESIGN_2026-04-28.md)：平台首页移动端参考图式信息流、双端公开作品卡 16:9 封面结构与点赞数读模型设计。
 - [PLATFORM_CATEGORY_AND_CREATE_TAB_DESIGN_2026-04-24.md](./PLATFORM_CATEGORY_AND_CREATE_TAB_DESIGN_2026-04-24.md)：平台入口新增分类 Tab、登录态导航裁剪与创作 Tab 视觉强化设计。
 - [PLATFORM_BIG_FISH_ENTRY_HIDE_2026-04-28.md](./PLATFORM_BIG_FISH_ENTRY_HIDE_2026-04-28.md)：平台入口暂时隐藏大鱼吃小鱼创作卡片，但保留现有玩法链路。
@@ -28,8 +29,8 @@
 
 - 做物品、Build、锻造相关需求时，先看前两份。
 - 做 RPG 全剧情规划、主支线矩阵、角色线、场景章节与剧情交付模板时，先看新增的全剧情策划流程。
-- 做自定义世界创作工作台、创作者输入边界、AI 分工设计时，先看第一份。
-- 做“哪些内容必须让创作者手填、哪些适合 AI 先生成再改、哪些必须系统托管”这类分层设计时，优先看新增的输入平衡设计稿。
+- 做自定义世界创作工作台、陶泥主输入边界、AI 分工设计时，先看第一份。
+- 做“哪些内容必须让陶泥主手填、哪些适合 AI 先生成再改、哪些必须系统托管”这类分层设计时，优先看新增的输入平衡设计稿。
 - 做“是否应该转成纯 Agent 式创作工具、转了之后前后台各该怎么收口”这类产品方向评估时，优先看新增的纯 Agent 对比与转型设计稿。
 - 做自定义世界去模板依赖、跨题材泛化、兼容迁移设计时，优先看新增的去模板化优化设计稿。
 - 做“模板依赖如何真正变成自定义世界自有设定层”的具体迁移方案时，优先看新增的自有设定层优化方案。