# 自定义世界创作工具问题审计与优化建议

更新时间：`2026-04-08`

## 0. 结论先说

当前自定义世界创作工具已经有了比较强的生成骨架、锚点结构和结果编辑能力，但整体仍处在一个很明显的“半收口状态”：

**设计目标已经走到“创作者工作台”，数据结构已经支持“锚点化输入”，但实际体验仍然更像“大文本生成器 + 大型结果总表编辑器”。**

如果用一句话概括当前问题，就是：

**高杠杆创作入口还不够强，低杠杆编辑负担还偏重，局部重生成与后端收口也还没有真正闭环。**

---

## 1. 审计范围

本次审计主要对照了三类信息：

1. 目标设计与 PRD
   - `docs/prd/AI_NATIVE_CUSTOM_WORLD_CREATION_FLOW_OPTIMIZATION_PRD_2026-04-06.md`
   - `docs/design/CUSTOM_WORLD_CREATOR_INPUT_AND_AI_BOUNDARY_DESIGN_2026-04-06.md`
   - `docs/design/CUSTOM_WORLD_SELF_OWNED_SETTING_LAYER_OPTIMIZATION_2026-04-08.md`
   - `docs/design/CUSTOM_WORLD_TEMPLATE_DECOUPLING_AND_CROSS_GENRE_GENERALIZATION_DESIGN_2026-04-08.md`

2. 当前前端主流程与工作台
   - `src/components/SelectionCustomizationModals.tsx`
   - `src/components/game-shell/PreGameSelectionFlow.tsx`
   - `src/components/CustomWorldGenerationView.tsx`
   - `src/components/CustomWorldResultView.tsx`
   - `src/components/CustomWorldEntityCatalog.tsx`
   - `src/components/CustomWorldEntityEditorModal.tsx`

3. 当前生成链与后端会话层
   - `src/services/ai.ts`
   - `src/services/aiService.ts`
   - `src/services/customWorldCreatorIntent.ts`
   - `src/services/customWorld.ts`
   - `server-node/src/services/customWorldSessionStore.ts`
   - `server-node/src/services/customWorldGenerationService.ts`
   - `server-node/src/bridges/legacyAiRuntimeBridge.ts`

---

## 2. 当前主要问题

## 2.1 输入层和意图结构已经脱节

当前数据结构已经支持：

- 世界一句话
- 主题关键词
- 气质约束
- 玩家身份
- 开局处境
- 核心冲突
- 关键势力
- 关键角色
- 关键地点
- 标志性要素
- 禁止事项

但实际入口 `src/components/SelectionCustomizationModals.tsx` 里，创作者弹窗仍然基本只有：

- 生成模式
- 一块大 textarea

这导致两个直接后果：

1. 设计里已经想清楚的“高杠杆锚点输入”，还没有真正变成主入口。
2. `CustomWorldCreatorIntent` 虽然已经能表达卡片化输入，但 UI 并没有把它转成真正可用的创作工作台。

目前 `card` 模式更多还停留在类型和测试层，没有成为真实用户路径。

可优化点：

- 把当前创建弹窗升级成“快速文本模式 / 创作卡片模式”双入口。
- 快速文本模式保留，但提交后应自动拆出建议锚点，而不是直接把整段文本原封不动送进生成链。
- 卡片模式先只做最关键的 `5~6` 张卡，不要一开始把所有高级字段都铺开。
- 允许空卡提交，但明确区分“已锁定锚点”和“允许 AI 自由补全”的内容。

---

## 2.2 澄清机制已经存在，但没有真正服务创作者

`server-node/src/services/customWorldSessionStore.ts` 已经支持：

- 根据输入缺口生成澄清问题
- 世界核心不足时追问
- 玩家身份缺失时追问
- 开局处境缺失时追问
- 核心冲突缺失时追问

但 `src/services/aiService.ts` 当前做法是：

- 创建 session
- 读取问题
- 直接用 fallback 文案自动回答
- 然后继续生成

这意味着：

**系统表面上已经有“先澄清再生成”的能力，但实际体验里，创作者并没有真正参与这一步。**

结果就是：

- 低信息量输入并没有被真正补强
- 澄清问题变成了内部兜底，而不是创作协作
- 很容易继续生成出“完整但不够像用户想要的世界”

可优化点：

- 把 session question 真正接到前端，作为生成前的二次确认步骤。
- 每次只问 `1~3` 个最关键问题，不要把它做成问卷。
- 支持“一键使用系统建议”，但必须让创作者可见，而不是静默自动填充。
- 把回答结果回写到 `creatorIntent`，而不是只作为一次性会话答案。

---

## 2.3 新建完成后的工作台闭环没有成立

设计文档里，自定义世界应该是：

`输入 -> 生成 -> 结果页确认/编辑 -> 保存并进入世界`

但当前 `src/components/game-shell/PreGameSelectionFlow.tsx` 里，新建世界生成成功后会：

- 直接保存到世界库
- 清空 `generatedCustomWorldProfile`
- 返回世界列表页

而不是进入 `custom-world-result` 结果工作台。

这会带来几个问题：

1. 新建后的第一时间确认感不够强。
2. 快速模式生成出的“关键对象预览”没有自然承接页。
3. 用户生成完后，如果想继续看结果、继续补全、继续编辑，还要再从世界列表里点一次“编辑”。

这条链路会让“创作中”与“已保存”之间的体验断开。

可优化点：

- 新建完成后默认进入结果工作台，而不是直接跳回世界列表。
- 保存动作留在结果页显式触发。
- 可以增加“自动保存草稿，但仍停留在结果页”的策略，兼顾安全感和连贯性。
- 世界列表更适合作为“已归档内容入口”，不适合作为新建完成页。

---

## 2.4 结果页仍然偏“数据总表”，低杠杆编辑负担偏重

当前结果页已经有 `世界 / 锚点 / 可扮演角色 / 场景角色 / 场景` 五个页签，这是正确方向。

但问题在于，进入编辑器后暴露出来的字段仍然太“底层”了，例如：

- `backstoryReveal`
- 技能列表
- 初始物品
- 场景 NPC 分配
- 场景连接关系

这些字段对少数深度编辑场景有用，但不应该成为默认主编辑内容。

当前 `src/components/CustomWorldEntityEditorModal.tsx` 已经变成一个非常重的综合编辑器，里面同时承担：

- 角色完整档案编辑
- 形象编辑入口
- AI 资产生成入口
- 背景章节编辑
- 技能与初始物品编辑
- 场景内 NPC 分配
- 场景连接维护

这会带来三层问题：

1. 创作者负担过重
   - 很多字段属于“系统编译层”，不属于“创作决策层”。

2. 移动端负担过重
   - 大量长表单、长弹窗和多级编辑，对手机创作并不友好。

3. 工程复杂度过高
   - 前端工作台承担了太多不同层级的编辑职责。

可优化点：

- 默认只暴露高杠杆编辑：
  - 世界核心命题
  - 主题与气质
  - 玩家身份与开局
  - 关键势力
  - 关键角色
  - 关键地点
  - 标志性要素
- 把技能、初始物品、章节 reveal、连接网络等移到“高级模式”或“系统层编辑”。
- 结果页结构从“按对象字段堆表单”改成“按创作价值组织”。
- 移动端优先改成分段式面板或底部工作台，不要把长表单都塞进同一个大 modal。

---

## 2.5 锁定与局部重生成机制还不完整

当前已经有两套看起来相关的能力：

1. `creatorIntent` 里的 `locked`
2. `lockState` 里的角色 / 地点 / 势力锁定字段

但实际重生成时，`src/components/game-shell/PreGameSelectionFlow.tsx` 里的合并逻辑只真正处理了：

- 已锁定角色
- 已锁定地点

而且还是按“名称匹配”保留，不是按稳定 id 或字段级锁定来处理。

这带来的问题很明显：

1. 角色或地点一旦重命名，锁定可能失效。
2. 势力、冲突、世界概述等高价值内容没有真正进入局部重生成保护范围。
3. 当前“锁定能力”更像一个早期过渡实现，还没有形成统一的重生成规则。

同时，结果页的“重新生成”提示文案仍然是“整世界覆盖式”的语义，这也会进一步削弱用户对重生成的信任感。

可优化点：

- 把锁定语义统一收口到后端，以 `lockState` 为唯一事实来源。
- 锁定粒度改成：
  - 世界字段锁定
  - 势力锁定
  - 关键角色锁定
  - 关键地点锁定
  - 长尾内容可重生成
- 局部重生成至少拆成几类：
  - 仅补长尾角色
  - 仅补长尾场景
  - 仅重做场景网络
  - 仅重做支持性 NPC
- 合并逻辑不要再靠名称匹配，改成稳定 id 或锚点映射。

---

## 2.6 快速模式还不够“快”，生成页也还不够“创作者视角”

当前快速模式的主要区别，是把数量降成：

- 可扮演角色 `3`
- 场景角色 `8`
- 场景 `4`

但主生成链本身仍然会继续跑：

- framework
- theme pack
- story graph
- role narrative
- role dossier
- narrative profile
- finalization

也就是说：

**现在的 fast 更像“缩数量版 full”，还不是“先出关键锚点与关键对象的创作预览模式”。**

同时，`src/components/CustomWorldGenerationView.tsx` 当前展示的重点仍然是：

- 当前批次
- 预计等待
- 计时
- 模型阶段

而不是创作者真正关心的：

- 关键角色有没有成型
- 核心冲突有没有稳定
- 哪些锚点已经锁定
- 当前正在补的是关键对象还是长尾内容

可优化点：

- 快速模式改成真正的“关键锚点预览模式”：
  - 先只生成关键角色、关键地点、核心冲突摘要
  - 暂不补全所有长尾档案
- 生成页改成“创作者视角进度”：
  - 世界灵魂已确定
  - 关键角色已成型
  - 关键地点已落地
  - 长尾扩展准备开始
- 把技术批次隐藏到二级信息里，默认只展示创作状态。

---

## 2.7 自定义世界底层仍然没有完全脱离模板世界依赖

这部分设计文档和参考清单已经说得比较清楚，代码里也能看到对应痕迹：

- `templateWorldType`
- `WUXIA / XIANXIA` 兼容字段
- 规则层 fallback
- 视觉参考池 fallback
- 角色骨架与怪物池 fallback

当前问题不在于“还没完全去模板化”本身，而在于：

**这层依赖仍然深入到了生成、运行时规则、表现词汇和参考资源，不只是一个兼容字段。**

这会限制：

1. 跨题材表达稳定性
2. 自定义世界的自有设定层独立性
3. 后续真正做到“任何题材都能稳定跑”

可优化点：

- 继续按现有设计稿，把模板依赖逐步迁成：
  - 语义锚层
  - 规则层
  - 表现层
  - 原型参考层
  - 兼容迁移层
- 在迁移完成前，保留兼容字段，但让新逻辑优先读取 `ownedSettingLayers`。
- 明确哪些是“兼容桥”，哪些还是“真实主依赖”，避免继续混用。

---

## 2.8 前后端边界仍处于过渡态，和项目约束还有距离

当前自定义世界已经有了：

- Node 路由
- session
- 流式生成
- 世界库存储接口

这是对的。

但问题是，`server-node/src/services/customWorldGenerationService.ts` 仍然通过 `server-node/src/bridges/legacyAiRuntimeBridge.ts` 去桥接 `src/services/ai.ts`。

这说明：

**核心生成逻辑虽然已经被路由包起来了，但真正的生成实现还没有完全成为 Express 侧自己的领域服务。**

同时，前端仍然承担了不少流程语义：

- 锁定内容合并
- 重生成确认
- 结果页覆盖提示
- 工作台状态切换

这和当前仓库“前端只负责表现，逻辑与数据尽量收口到 Express 后端”的方向还有距离。

可优化点：

- 把自定义世界生成链正式下沉到 `server-node` 领域服务。
- 把锁定、局部重生成、澄清会话、结果归档规则都放到后端。
- 前端只负责：
  - 输入展示
  - 进度展示
  - 结果工作台展示
  - 明确的用户确认动作

---

## 2.9 移动端工作台仍有明显压迫感

项目文档已经明确要求移动端优先，但当前自定义世界工作台里仍有几个典型问题：

- 大量长 modal
- 多段长表单
- `window.confirm / window.alert` 原生弹框较多
- 结果页与编辑器中同时承载太多操作密度

这些在桌面端还能勉强接受，但在手机上会很容易变成：

- 滚动层级混乱
- 退出成本高
- 修改焦点不明确
- 确认感不稳定

可优化点：

- 移动端改成底部工作台 / 分步面板 / 可折叠分区。
- 用项目内统一确认弹层替换 `window.confirm / window.alert`。
- 让“保存”“继续补全”“局部重生成”这些关键动作固定在底部安全区附近。
- 把搜索、批量删除、创建动作做成更轻的操作条，而不是持续挤压正文区。

---

## 3. 优先级建议

### P0：先修主链路闭环

- 补卡片化输入入口，至少把关键锚点输入真正开放出来。
- 把澄清问题正式接入创作者流程，不再静默自动兜底。
- 修正“新建完成后直接回世界列表”的流程，生成后默认进入结果工作台。
- 统一锁定与局部重生成规则，先让“创作者不怕重生成”成立。

### P1：再降低工作台负担

- 结果页默认只展示高杠杆编辑。
- 低杠杆字段进入高级模式。
- 快速模式改成真正的关键对象预览模式。
- 生成页改成创作者视角进度，而不是模型批次视角。

### P2：最后做架构收口与去模板化

- 把生成链、锁定规则、会话澄清彻底收回 Express 后端。
- 持续推进 `ownedSettingLayers` 成为真实主设定层。
- 逐步去掉自定义世界对模板世界的深依赖。
- 针对移动端重做工作台的操作密度和确认路径。

---

## 4. 推荐落地顺序

如果只按“最小投入、最大体验收益”排序，建议按下面四步做：

1. 先改输入与结果闭环
   - 卡片化最小入口
   - 澄清问题接入
   - 新建后进入结果页

2. 再改锁定与局部重生成
   - 用稳定 id
   - 用统一 lockState
   - 增加局部重生成类型

3. 再改结果工作台结构
   - 默认高杠杆
   - 高级模式收纳低杠杆字段
   - 移动端拆分长表单

4. 最后做后端收口与去模板化
   - 服务端领域化
   - 设定层自有化
   - 跨题材泛化

---

## 5. 一句话判断

当前自定义世界创作工具最需要的，不是再继续补更多字段或更多生成步骤，而是：

**把“创作者先决定灵魂锚点，系统再稳定展开世界”这条主逻辑真正落到 UI、流程和后端边界上。**