GenarrativeAI/Genarrative
5
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity
Files
master
Genarrative/docs/audits/CUSTOM_WORLD_CREATOR_TOOL_AUDIT_2026-04-08.md
高物 87fbf41fab 1
2026-05-01 20:29:09 +08:00

14 KiB
Raw Permalink Blame History

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

更新时间：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、流程和后端边界上。

Reference in New Issue View Git Blame Copy Permalink