Simplify custom world result editing controls
This commit is contained in:
@@ -0,0 +1,398 @@
|
||||
# 自定义世界依赖的模板设定清单
|
||||
|
||||
更新时间：`2026-04-08`
|
||||
|
||||
## 0. 这份清单回答什么
|
||||
|
||||
这份文档只回答一个问题：
|
||||
|
||||
**当前仓库里，自定义世界仍然依赖哪些“模板世界设定”。**
|
||||
|
||||
这里的“模板世界设定”不是指玩家还能进入的 `武侠 / 仙侠` 预设世界流程，而是指：
|
||||
|
||||
1. 自定义世界在生成时仍借用哪些模板锚点。
|
||||
2. 自定义世界在运行时仍复用哪些模板 schema、词库、怪物池、角色模板、图片参考池。
|
||||
3. 哪些引用是“必须保留”，否则会直接伤到自定义世界。
|
||||
4. 哪些引用只是编辑器 / 审计 / 测试残留，不属于自定义世界主链硬依赖。
|
||||
|
||||
一句话结论先说：
|
||||
|
||||
**当前主流程虽然已经不再让玩家进入武侠 / 仙侠预设世界，但自定义世界底层仍明确依赖“模板世界锚点层”。**
|
||||
|
||||
---
|
||||
|
||||
## 1. 依赖总览
|
||||
|
||||
自定义世界当前仍依赖的模板设定，主要分成 7 类：
|
||||
|
||||
1. 模板世界锚点类型
|
||||
2. 主题判定与规则回退
|
||||
3. 属性 schema 与术语体系
|
||||
4. 角色模板与技能骨架
|
||||
5. 场景图参考池与营地图像逻辑
|
||||
6. 怪物 / 敌对实体模板池
|
||||
7. 叙事 ThemePack 与生成 prompt 兼容字段
|
||||
|
||||
除此之外，还有一类是：
|
||||
|
||||
8. 编辑器 / 审计 / 测试中的残留模板引用
|
||||
|
||||
这类不一定属于自定义世界正式运行时硬依赖，但当前仓库里仍然存在。
|
||||
|
||||
---
|
||||
|
||||
## 2. 核心硬依赖
|
||||
|
||||
## 2.1 模板世界锚点类型
|
||||
|
||||
这是最底层、也是目前最不能直接删的部分。
|
||||
|
||||
相关文件：
|
||||
|
||||
- `src/types/core.ts`
|
||||
- `src/types/customWorld.ts`
|
||||
- `src/services/customWorld.ts`
|
||||
- `src/data/customWorldLibrary.ts`
|
||||
|
||||
当前依赖点：
|
||||
|
||||
1. `WorldType.WUXIA / WorldType.XIANXIA / WorldType.CUSTOM`
|
||||
- 自定义世界虽然运行时是 `CUSTOM`，但其模板锚点仍通过 `WUXIA / XIANXIA` 表达。
|
||||
|
||||
2. `WorldTemplateType = Exclude<WorldType, WorldType.CUSTOM>`
|
||||
- 这就是“自定义世界挂靠哪个模板锚”的类型定义。
|
||||
|
||||
3. `CustomWorldProfile.templateWorldType`
|
||||
- 当前自定义世界 profile 里明确保存这个字段。
|
||||
- 它是兼容字段，但目前仍被多个系统直接消费。
|
||||
|
||||
4. `buildCustomWorldFrameworkPrompt(...)`
|
||||
- 生成框架 prompt 仍要求模型输出：
|
||||
- `"templateWorldType": "WUXIA|XIANXIA"`
|
||||
|
||||
5. `customWorldLibrary.normalizeProfile(...)`
|
||||
- 本地读取自定义世界时，也会把 `templateWorldType` 归一化到：
|
||||
- `WUXIA`
|
||||
- `XIANXIA`
|
||||
|
||||
结论：
|
||||
|
||||
**如果直接删掉 `WUXIA / XIANXIA / WorldTemplateType / templateWorldType` 这层，自定义世界的生成、存档归一化和多处运行时回退都会直接断。**
|
||||
|
||||
---
|
||||
|
||||
## 2.2 主题判定与规则回退
|
||||
|
||||
相关文件：
|
||||
|
||||
- `src/services/customWorldTheme.ts`
|
||||
- `src/data/customWorldRuntime.ts`
|
||||
- `src/services/storyEngine/themePack.ts`
|
||||
|
||||
当前依赖点：
|
||||
|
||||
1. `detectCustomWorldThemeMode(profile)`
|
||||
- 先把自定义世界识别成：
|
||||
- `martial`
|
||||
- `arcane`
|
||||
- `machina`
|
||||
- `tide`
|
||||
- `rift`
|
||||
- `mythic`
|
||||
|
||||
2. `resolveCustomWorldAnchorWorldType(profile)`
|
||||
- 再把主题模式压回模板锚点：
|
||||
- `arcane -> XIANXIA`
|
||||
- 其它默认回到 `WUXIA`
|
||||
|
||||
3. `resolveRuleWorldType(worldType, customWorldProfile)`
|
||||
- 这是当前运行时非常关键的桥接函数。
|
||||
- 当 `worldType === CUSTOM` 时，它会把规则世界解析成模板锚点。
|
||||
- 如果没有 profile，还会默认回退到 `WUXIA`。
|
||||
|
||||
4. `buildThemePackFromWorldProfile(profile)`
|
||||
- 自定义世界最终的 `ThemePack` 并不是纯空中生成。
|
||||
- 它是从预设的主题包底板开始，再用自定义世界自己的词汇补进去。
|
||||
|
||||
结论：
|
||||
|
||||
**自定义世界现在不是完全脱离模板世界独立运行，而是“先判定自己的主题模式，再回落到模板锚点做规则支撑”。**
|
||||
|
||||
---
|
||||
|
||||
## 2.3 属性 schema 与术语体系
|
||||
|
||||
相关文件：
|
||||
|
||||
- `src/data/worldAttributeSchemas.ts`
|
||||
- `src/services/attributeSchemaGenerator.ts`
|
||||
- `src/services/customWorldPresentation.ts`
|
||||
- `src/data/economy.ts`
|
||||
|
||||
当前依赖点：
|
||||
|
||||
1. `PRESET_WORLD_ATTRIBUTE_SCHEMAS`
|
||||
- 当前仓库里有两套预设属性 schema：
|
||||
- 武侠：`江湖六脉`
|
||||
- 仙侠：`灵界六轴`
|
||||
|
||||
2. `getPresetWorldAttributeSchema(...)`
|
||||
- 多个地方仍然用它作为生成自定义世界 schema 的参考底板。
|
||||
|
||||
3. `generateWorldAttributeSchema(...)`
|
||||
- 自定义世界自己的 attribute schema 虽然是生成的，
|
||||
- 但内部会参考预设世界 schema 的槽位结构和 fallback 逻辑。
|
||||
|
||||
4. `getAttributeLabelsForWorld(...) / getResourceLabelsForWorld(...)`
|
||||
- 如果当前没有显式自定义 world presentation，会按 `WUXIA / XIANXIA` 走回退术语。
|
||||
|
||||
5. `getCurrencyName(...) / getInitialPlayerCurrency(...)`
|
||||
- 经济层仍按模板世界决定初始货币命名和初始数量。
|
||||
|
||||
结论：
|
||||
|
||||
**自定义世界现在虽然有自己的 presentation 和 attribute schema，但模板世界仍然是它们的 fallback 和参考骨架。**
|
||||
|
||||
---
|
||||
|
||||
## 2.4 角色模板与技能骨架
|
||||
|
||||
相关文件：
|
||||
|
||||
- `src/data/characterPresets.ts`
|
||||
|
||||
当前依赖点：
|
||||
|
||||
1. `PRESET_CHARACTERS`
|
||||
- 自定义世界的可玩角色 / 场景角色运行时形态，是从现有预设角色模板变体化出来的。
|
||||
|
||||
2. `pickCustomWorldRoleTemplateCharacter(...)`
|
||||
- 会从 `PRESET_CHARACTERS` 里挑一个模板角色作为骨架。
|
||||
|
||||
3. `buildCustomWorldRoleCharacter(...)`
|
||||
- 会把自定义世界角色内容覆盖到模板角色上：
|
||||
- 名字
|
||||
- 背景
|
||||
- 描述
|
||||
- 技能文案
|
||||
- 外观
|
||||
- 等等
|
||||
|
||||
4. `buildCustomWorldSkillVariant(...)`
|
||||
- 自定义世界角色技能的数值和命名，也是从模板技能定义变体生成出来的。
|
||||
|
||||
5. `adventureOpenings`
|
||||
- 当前实现里，自定义世界角色 opening 同时写入：
|
||||
- `WUXIA`
|
||||
- `XIANXIA`
|
||||
- `CUSTOM`
|
||||
- 说明角色开局结构仍沿用模板世界的旧接口习惯。
|
||||
|
||||
6. `getCharacterHomeSceneId / getCharacterNpcSceneIds`
|
||||
- 对 `CUSTOM` 路径已经优先走自定义世界自己的 landmark 映射；
|
||||
- 但非 CUSTOM 路径仍大量依赖模板世界的基础场景绑定表。
|
||||
|
||||
结论：
|
||||
|
||||
**自定义世界角色并不是从零独立建模，而是“自定义内容 + 预设角色模板骨架”的组合。**
|
||||
|
||||
---
|
||||
|
||||
## 2.5 场景图参考池与营地图像逻辑
|
||||
|
||||
相关文件：
|
||||
|
||||
- `src/data/customWorldVisuals.ts`
|
||||
- `src/services/customWorldCamp.ts`
|
||||
|
||||
当前依赖点：
|
||||
|
||||
1. `WUXIA_SCENE_IMAGE_REFERENCES`
|
||||
2. `XIANXIA_SCENE_IMAGE_REFERENCES`
|
||||
3. `WORLD_SCENE_IMAGE_REFERENCES`
|
||||
|
||||
当前自定义世界场景图不是纯随机抽图，而是：
|
||||
|
||||
1. 先确定模板锚点世界
|
||||
2. 再从对应模板世界的场景参考词池里匹配：
|
||||
- 场景名称
|
||||
- 关键词
|
||||
- 图片参考
|
||||
|
||||
具体依赖：
|
||||
|
||||
1. `collectWorldSceneImagePool(worldType)`
|
||||
- 按模板世界从背景包里抽参考池。
|
||||
|
||||
2. `buildSceneReferencePool(worldType)`
|
||||
- 用武侠 / 仙侠各自的场景参考名和关键词构造图像匹配池。
|
||||
|
||||
3. `getDefaultCustomWorldSceneImage(...)`
|
||||
- 自定义世界 landmark / camp / 场景默认图，会基于模板世界参考池挑选。
|
||||
|
||||
4. `resolveCustomWorldCampSceneImage(profile)`
|
||||
- 开局归处场景图也依赖 `templateWorldType` 和主题判定。
|
||||
|
||||
结论：
|
||||
|
||||
**当前自定义世界的场景视觉虽然是独立输出，但“默认图像匹配逻辑”仍然是挂在武侠 / 仙侠两套参考池上的。**
|
||||
|
||||
---
|
||||
|
||||
## 2.6 怪物 / 敌对实体模板池
|
||||
|
||||
相关文件：
|
||||
|
||||
- `src/data/customWorldNpcMonsters.ts`
|
||||
- `src/data/hostileNpcPresets.ts`
|
||||
- `src/data/hostileNpcs.ts`
|
||||
- `src/data/scenePresets.ts`
|
||||
|
||||
当前依赖点：
|
||||
|
||||
1. `resolveCustomWorldNpcMonsterPreset(...)`
|
||||
- 自定义世界中带敌意的 NPC / 怪物，会从模板怪物池里找最接近的 preset。
|
||||
|
||||
2. `getMonsterPresetPool(worldType?)`
|
||||
- 如果传了 worldType，就取对应模板世界的怪物池。
|
||||
- 如果没传，就把武侠和仙侠怪物池拼起来一起选。
|
||||
|
||||
3. `resolveRuleWorldType(...)`
|
||||
- `hostileNpcPresets.ts` 和 `hostileNpcs.ts` 在处理 `CUSTOM` 时，会先解析到模板锚点，再决定取哪个怪物 preset / schema。
|
||||
|
||||
4. `getMonsterPresetsByWorld(...) / getHostileNpcPresetById(...)`
|
||||
- 自定义世界的运行时怪物表现，目前仍然依赖这套模板怪物 preset 查询接口。
|
||||
|
||||
结论：
|
||||
|
||||
**自定义世界当前没有完全独立的怪物体系，仍然是基于武侠 / 仙侠预设怪物池做匹配和包装。**
|
||||
|
||||
---
|
||||
|
||||
## 2.7 叙事 ThemePack 与 prompt 兼容字段
|
||||
|
||||
相关文件：
|
||||
|
||||
- `src/services/customWorld.ts`
|
||||
- `src/services/storyEngine/themePack.ts`
|
||||
- `src/services/ai.ts`
|
||||
|
||||
当前依赖点：
|
||||
|
||||
1. 自定义世界框架 prompt 仍强制要求 `templateWorldType`
|
||||
2. `normalizeCustomWorldGenerationFramework(...)`
|
||||
- 会把模型输出的模板世界字段规范化
|
||||
3. `buildThemePackFromWorldProfile(...)`
|
||||
- 会以预设主题包为底，再混入自定义世界词汇
|
||||
4. `ai.ts` 里某些 fallback 逻辑仍根据 `templateWorldType` 决定主题包回退
|
||||
|
||||
结论：
|
||||
|
||||
**自定义世界的 AI 生成链条目前明确假设“世界框架里存在模板锚点字段”。**
|
||||
|
||||
---
|
||||
|
||||
## 3. 运行时硬依赖 vs 非运行时残留
|
||||
|
||||
## 3.1 自定义世界正式运行时硬依赖
|
||||
|
||||
这些目前不能轻易删：
|
||||
|
||||
1. `WorldType.WUXIA / WorldType.XIANXIA / WorldTemplateType`
|
||||
2. `CustomWorldProfile.templateWorldType`
|
||||
3. `detectCustomWorldThemeMode / resolveCustomWorldAnchorWorldType / resolveRuleWorldType`
|
||||
4. `PRESET_WORLD_ATTRIBUTE_SCHEMAS / getPresetWorldAttributeSchema`
|
||||
5. `PRESET_CHARACTERS` 作为自定义角色模板骨架
|
||||
6. 武侠 / 仙侠场景图参考池
|
||||
7. 武侠 / 仙侠怪物 preset 池
|
||||
8. `buildThemePackFromWorldProfile` 的模板底板
|
||||
9. `customWorld.ts` 里生成框架 prompt 的 `templateWorldType` 字段约束
|
||||
|
||||
## 3.2 不是主流程硬依赖，但仓库里仍存在的残留引用
|
||||
|
||||
这些更多是编辑器 / 工具 / 审计 / 测试引用：
|
||||
|
||||
1. 预设编辑器
|
||||
- `preset-editor/*`
|
||||
|
||||
2. 一些开发工具页
|
||||
- 例如 `ItemCatalogEditor.tsx`
|
||||
- `StateFunctionEditor.tsx`
|
||||
|
||||
3. 审计 / 报告工具
|
||||
- `storyAuditReport.ts`
|
||||
|
||||
4. 各类基于武侠 / 仙侠的测试
|
||||
|
||||
5. 一些 UI 图标与世界按钮贴图
|
||||
- 例如 `uiAssets.ts` 里的图标键位仍保留
|
||||
|
||||
这些不一定影响当前玩家主流程，但如果目标是“代码库级彻底清理”，它们也需要后续处理。
|
||||
|
||||
---
|
||||
|
||||
## 4. 当前最不能动的边界
|
||||
|
||||
如果前提是：
|
||||
|
||||
**不要动素材和自定义世界的任何设定。**
|
||||
|
||||
那么当前最不能直接删除的是：
|
||||
|
||||
1. `templateWorldType`
|
||||
2. `WorldTemplateType`
|
||||
3. `resolveRuleWorldType(...)`
|
||||
4. `detectCustomWorldThemeMode(...)`
|
||||
5. `resolveCustomWorldAnchorWorldType(...)`
|
||||
6. `PRESET_WORLD_ATTRIBUTE_SCHEMAS`
|
||||
7. `PRESET_CHARACTERS`
|
||||
8. `customWorldVisuals.ts` 里的模板场景参考池
|
||||
9. `customWorldNpcMonsters.ts` 对模板怪物池的映射
|
||||
10. `themePack.ts` 的模板底板
|
||||
|
||||
原因很简单：
|
||||
|
||||
**这些不是“预设世界可玩入口”，而是自定义世界当前仍在使用的模板支撑层。**
|
||||
|
||||
---
|
||||
|
||||
## 5. 可以安全理解为“已从玩家主流程移除”的部分
|
||||
|
||||
目前已经可以视作从正式玩家流程移除的，是：
|
||||
|
||||
1. 世界选择页里的武侠 / 仙侠入口
|
||||
2. 主流程的世界选择 API
|
||||
3. 继续游戏入口中的武侠 / 仙侠旧存档
|
||||
|
||||
但这不等于：
|
||||
|
||||
- 代码库内部已经完全不再依赖模板世界
|
||||
|
||||
这两件事要分开看。
|
||||
|
||||
---
|
||||
|
||||
## 6. 最后结论
|
||||
|
||||
当前仓库里，自定义世界对模板设定的依赖，本质上是：
|
||||
|
||||
**“不再复用预设世界的玩家入口，但仍然复用预设世界的模板支撑层。”**
|
||||
|
||||
最准确的理解是：
|
||||
|
||||
1. 玩家已经不能直接进入武侠 / 仙侠预设世界
|
||||
2. 但自定义世界仍借用武侠 / 仙侠作为：
|
||||
- 模板锚点
|
||||
- 规则回退
|
||||
- 属性 schema 参考
|
||||
- 角色模板骨架
|
||||
- 场景图参考池
|
||||
- 怪物模板池
|
||||
- ThemePack 底板
|
||||
|
||||
所以如果后续要继续“深度清理”，正确顺序不是直接删光 `WUXIA / XIANXIA`，而应该是：
|
||||
|
||||
1. 先识别哪些是主流程入口，哪些是模板支撑层
|
||||
2. 再决定是否要把自定义世界从“模板依赖型”重构成“完全自足型”
|
||||
|
||||
在那一步没做完之前，模板支撑层仍然是自定义世界当前可用性的真实依赖。
|
||||
@@ -3,8 +3,11 @@
|
||||
## 当前入口
|
||||
|
||||
- [FUNCTION_SCRIPT_CATALOG_2026-04-04.md](./FUNCTION_SCRIPT_CATALOG_2026-04-04.md)：Function 独立脚本目录与分类速查。
|
||||
- [TASK_GENERATION_TRACE_2026-04-08.md](./TASK_GENERATION_TRACE_2026-04-08.md)：任务描述、达成条件与奖励生成链路梳理。
|
||||
- [CUSTOM_WORLD_TEMPLATE_DEPENDENCY_INVENTORY_2026-04-08.md](./CUSTOM_WORLD_TEMPLATE_DEPENDENCY_INVENTORY_2026-04-08.md)：自定义世界当前仍依赖哪些模板世界设定的清单。
|
||||
|
||||
## 使用建议
|
||||
|
||||
- 需要快速定位 Function 脚本，而不是阅读长篇方案时，优先看这里。
|
||||
- 需要判断“武侠 / 仙侠模板层”哪些还能删、哪些不能删时，优先看自定义世界模板依赖清单。
|
||||
- 如果要评估 Function 分层是否合理，再配合 `docs/audits/FUNCTION_DESIGN_AUDIT_2026-04-03.md` 一起看。
|
||||
|
||||
248
docs/reference/TASK_GENERATION_TRACE_2026-04-08.md
Normal file
248
docs/reference/TASK_GENERATION_TRACE_2026-04-08.md
Normal file
@@ -0,0 +1,248 @@
|
||||
# 任务生成链路与简化建议
|
||||
|
||||
更新时间：`2026-04-08`
|
||||
|
||||
## 0. 简化版结论
|
||||
|
||||
推荐把任务系统收敛成一条主链：
|
||||
|
||||
1. `npcInteractions.ts`
|
||||
- 只负责判断“现在是否适合接任务”，不再提前本地造整份任务预览。
|
||||
2. `npcEncounterActions.ts`
|
||||
- 玩家真正点击“接下委托”时，才调用 AI 任务导演。
|
||||
3. `questDirector.ts + questPrompt.ts`
|
||||
- 用 AI 原生剧情引擎根据当前局势生成任务意图。
|
||||
4. `questFlow.ts`
|
||||
- 只负责把 AI 意图编译成可追踪任务、生成本地奖励、推进步骤。
|
||||
5. `goalDirector.ts`
|
||||
- 把任务编译成“当前目标 / 下一步”。
|
||||
6. `AdventurePanelOverlays.tsx`
|
||||
- 只负责展示，不再自己承载任务生成逻辑。
|
||||
|
||||
一句话：
|
||||
|
||||
**任务内容主要由 AI 原生剧情引擎生成，本地代码只保留状态推进、奖励结算和失败兜底。**
|
||||
|
||||
## 1. 现在建议保留的主流程
|
||||
|
||||
## 1.1 接任务
|
||||
|
||||
推荐主流程：
|
||||
|
||||
`npcInteractions.ts`
|
||||
-> 展示“可接任务”入口
|
||||
-> `npcEncounterActions.ts`
|
||||
-> `generateQuestForNpcEncounter(...)`
|
||||
-> `questDirector.ts`
|
||||
-> `questPrompt.ts`
|
||||
-> `questFlow.ts`
|
||||
-> 写入 `QuestLogEntry`
|
||||
|
||||
当前已经做的简化：
|
||||
|
||||
- NPC 面板不再为了预览，先本地生成一整份 fallback 任务。
|
||||
- 现在只做任务机会判断，并提示“接取后将由 AI 剧情引擎根据当前局势生成具体目标、步骤与奖励”。
|
||||
|
||||
这样可以直接消掉一层不必要的双轨：
|
||||
|
||||
- 旧流程：
|
||||
- 预览先本地生成
|
||||
- 正式接取再 AI 生成
|
||||
- 新流程：
|
||||
- 预览只判断有没有任务机会
|
||||
- 正式接取时再真正生成任务
|
||||
|
||||
## 1.2 任务描述
|
||||
|
||||
简化后应理解成：
|
||||
|
||||
- 任务描述的主来源是 AI 生成的 `QuestIntent.description`
|
||||
- 本地只负责把它写入 `QuestLogEntry.description`
|
||||
- UI 只负责展示 `quest.description`
|
||||
|
||||
主脚本：
|
||||
|
||||
- `src/services/questPrompt.ts`
|
||||
- `src/services/questDirector.ts`
|
||||
- `src/data/questFlow.ts`
|
||||
|
||||
## 1.3 达成条件
|
||||
|
||||
简化后应理解成：
|
||||
|
||||
- AI 负责给出“这件事大概要怎么做”的意图
|
||||
- 本地把意图编译成 `steps / objective`
|
||||
- UI 根据当前 `activeStep` 生成最短的“下一步”
|
||||
|
||||
也就是：
|
||||
|
||||
**AI 决定任务方向，本地决定可追踪步骤，UI 只显示当前这一步。**
|
||||
|
||||
主脚本：
|
||||
|
||||
- `src/data/questFlow.ts`
|
||||
- `src/components/adventure-panel/AdventurePanelOverlays.tsx`
|
||||
|
||||
## 1.4 奖励
|
||||
|
||||
奖励不建议交给 AI 直接写死。
|
||||
|
||||
更稳的边界是：
|
||||
|
||||
- AI 只给 `rewardTheme`
|
||||
- 本地生成具体金币、物品、好感奖励
|
||||
- 交付时由本地状态系统结算
|
||||
|
||||
主脚本：
|
||||
|
||||
- `src/data/questFlow.ts`
|
||||
- `src/data/runtimeItemDirector.ts`
|
||||
- `src/hooks/story/sessionActions.ts`
|
||||
- `src/hooks/story/npcEncounterActions.ts`
|
||||
|
||||
## 2. 你这次最关心的三个问题
|
||||
|
||||
## 2.1 任务描述怎么生成
|
||||
|
||||
主生成链：
|
||||
|
||||
- `src/services/questPrompt.ts`
|
||||
- 约束 AI 输出 `title / description / summary / rewardTheme`
|
||||
- `src/services/questDirector.ts`
|
||||
- 请求 AI，得到 `QuestIntent`
|
||||
- `src/data/questFlow.ts`
|
||||
- `compileQuestIntentToQuest(...)` 把 `description` 写入 `QuestLogEntry`
|
||||
|
||||
前台展示：
|
||||
|
||||
- `src/components/adventure-panel/AdventurePanelOverlays.tsx`
|
||||
- 优先显示 `quest.description`
|
||||
|
||||
## 2.2 达成条件怎么生成
|
||||
|
||||
主生成链：
|
||||
|
||||
- `src/data/questFlow.ts`
|
||||
- `buildPrimaryQuestStep(...)`
|
||||
- `buildTalkBackStep(...)`
|
||||
- 把 AI 任务意图编译成 `steps`
|
||||
|
||||
前台展示：
|
||||
|
||||
- `src/components/adventure-panel/AdventurePanelOverlays.tsx`
|
||||
- `buildQuestConditionText(...)`
|
||||
- 根据当前 `activeStep / objective` 重算成一句玩家看得懂的话
|
||||
|
||||
## 2.3 任务奖励怎么生成
|
||||
|
||||
主生成链：
|
||||
|
||||
- `src/data/questFlow.ts`
|
||||
- `buildQuestReward(...)`
|
||||
- `src/data/runtimeItemContext.ts`
|
||||
- 给奖励物品生成器准备上下文
|
||||
- `src/data/runtimeItemDirector.ts`
|
||||
- 根据 seed 和频道生成奖励物品
|
||||
- `src/data/runtimeItemNarrative.ts`
|
||||
- 把奖励物品摊平回 `reward.items`
|
||||
|
||||
结算链：
|
||||
|
||||
- `src/hooks/story/sessionActions.ts`
|
||||
- `src/hooks/story/npcEncounterActions.ts`
|
||||
|
||||
## 3. 哪些预设逻辑应该收缩
|
||||
|
||||
## 3.1 应该保留
|
||||
|
||||
- `buildFallbackQuestIntent(...)`
|
||||
- 保留
|
||||
- 但只作为 AI 失败兜底
|
||||
- `buildQuestReward(...)`
|
||||
- 保留
|
||||
- 因为奖励和数值应该继续走本地规则
|
||||
- `buildPrimaryQuestStep(...) / buildTalkBackStep(...)`
|
||||
- 保留
|
||||
- 因为任务必须能被本地追踪和结算
|
||||
|
||||
## 3.2 应该降级
|
||||
|
||||
- `buildQuestForEncounter(...)`
|
||||
- 不再作为 NPC 面板预览主路径
|
||||
- 只保留给 fallback 和测试使用
|
||||
- `buildFallbackQuestIntent(...)` 里的多套模板
|
||||
- 可以继续精简
|
||||
- 最终只保留最小 2 到 3 种兜底 archetype 即可
|
||||
|
||||
## 3.3 应该谨慎接线
|
||||
|
||||
- `buildChapterQuestForScene(...)`
|
||||
- 当前更像“备用章节任务生成器”
|
||||
- 但我还没有在运行时主链里找到直接调用点
|
||||
- `SCENE_CHAPTER_OVERRIDES`
|
||||
- 不应该继续扩大
|
||||
- 只保留少量关键样板场景
|
||||
|
||||
如果要坚持“AI 原生任务引擎”为主，这部分不应继续膨胀成大规模预设系统。
|
||||
|
||||
## 4. 脚本解释速查
|
||||
|
||||
| 脚本 | 作用 | 简化方案中的定位 |
|
||||
| --- | --- | --- |
|
||||
| `src/data/npcInteractions.ts` | 生成 NPC 面板选项、礼物/交易/帮助等交互入口 | 只负责任务机会判断和入口展示，不再预生成整任务 |
|
||||
| `src/hooks/story/npcEncounterActions.ts` | 处理点击“接任务 / 交任务 / 切磋 / 离开”等真实执行逻辑 | 任务接取与交付的运行时主入口 |
|
||||
| `src/services/questDirector.ts` | 调用 AI，拿到任务意图 `QuestIntent` | AI 原生任务生成主入口 |
|
||||
| `src/services/questPrompt.ts` | 组织任务 prompt，约束 AI 输出格式 | AI 任务生成的提示词层 |
|
||||
| `src/data/questFlow.ts` | 把任务意图编译成 quest、推进 steps、生成 reward、做 fallback | 任务数据层主脚本，保留但收缩预设分支 |
|
||||
| `src/services/storyEngine/goalDirector.ts` | 把 quest / chapter / journeyBeat 编译成当前目标和下一步 | 负责“目标感”，不是负责生成任务本身 |
|
||||
| `src/components/adventure-panel/AdventurePanelOverlays.tsx` | 展示任务描述、达成条件、奖励和日志 | 纯展示层 |
|
||||
| `src/data/runtimeItemContext.ts` | 给奖励物品生成器准备上下文 | 奖励生成辅助层 |
|
||||
| `src/data/runtimeItemDirector.ts` | 生成奖励物品 | 奖励物品生成主脚本 |
|
||||
| `src/data/runtimeItemNarrative.ts` | 整理奖励物品和叙事 hint | 奖励辅助层 |
|
||||
| `src/hooks/story/sessionActions.ts` | 统一处理领奖、章节同步等动作 | 非 NPC 面板路径下的奖励结算入口 |
|
||||
|
||||
## 5. 当前代码现状
|
||||
|
||||
截至这次整理，任务主链可以这样理解：
|
||||
|
||||
### 已经对齐到“AI 优先”的部分
|
||||
|
||||
- 真正点击“接下委托”时，优先调用 `generateQuestForNpcEncounter(...)`
|
||||
- AI 返回任务意图后，再由 `questFlow.ts` 编译成本地任务
|
||||
|
||||
### 仍然是本地规则负责的部分
|
||||
|
||||
- `steps / objective` 推进
|
||||
- 奖励数值和奖励物品
|
||||
- 领奖与状态结算
|
||||
|
||||
### 仍然偏预设、但建议继续收缩的部分
|
||||
|
||||
- `buildFallbackQuestIntent(...)`
|
||||
- `buildChapterQuestForScene(...)`
|
||||
- `SCENE_CHAPTER_OVERRIDES`
|
||||
|
||||
## 6. 推荐后的最简架构
|
||||
|
||||
如果后面继续收缩，我建议把目标定成下面这版：
|
||||
|
||||
1. NPC 面板只判断“能不能接任务”
|
||||
2. 点击接任务后，统一走 `questDirector.ts`
|
||||
3. AI 只产出：
|
||||
- `title`
|
||||
- `description`
|
||||
- `summary`
|
||||
- `recommendedObjectiveKinds`
|
||||
- `rewardTheme`
|
||||
4. `questFlow.ts` 只负责：
|
||||
- 编译 steps
|
||||
- 生成 reward
|
||||
- 推进 status
|
||||
5. `goalDirector.ts` 只负责把 quest 变成“当前目标 / 下一步”
|
||||
6. 章节任务生成器只做少量 fallback，不再做大规模场景预设扩张
|
||||
|
||||
这样之后，代码层的职责会更清楚：
|
||||
|
||||
- AI 负责“这件事讲什么”
|
||||
- 本地规则负责“这件事怎么追踪、怎么结算”
|
||||
- UI 负责“把当前最重要的一步展示给玩家”
|
||||
Reference in New Issue
Block a user