Implement scene-based chapter quest progression

docs/prd/AI_NATIVE_TASK_DRIVEN_GOAL_EXPERIENCE_PRD_2026-04-07.md

@@ -0,0 +1,876 @@
+# AI 原生任务驱动目标感增强 PRD
+
+更新时间：`2026-04-07`
+
+## 0. 目标
+
+这份 PRD 面向当前仓库，解决的是一个已经被用户明确反馈出来的问题：
+
+**当前游戏虽然已经具备任务、章节、旅程节拍、剧情线程等系统，但玩家在实际游玩里，仍然经常感受不到“我现在到底在朝什么目标推进”。**
+
+这里要增强的，不是单纯“多做一些任务”，而是把现有系统重新组织成一条玩家可感知的目标驱动链路，让玩家在大多数时刻都能快速回答 3 个问题：
+
+1. 我现在在做什么？
+2. 为什么这件事值得我去做？
+3. 我下一步应该去哪里、找谁、做哪件事？
+
+一句话目标：
+
+**把当前分散在任务、章节、旅程、线程里的推进信息，编译成玩家随时能感知到的“主目标 -> 当前委托 -> 下一步行动”体验。**
+
+---
+
+## 1. 当前问题定位
+
+## 1.1 当前项目其实已经有不少“目标相关系统”
+
+从现有仓库看，项目并不是没有目标系统，而是已经有了多套“部分成立”的目标表达：
+
+- `src/data/questFlow.ts`
+  - 已经有 `QuestIntent -> QuestContract -> QuestStep -> QuestProgressSignal` 的任务闭环。
+- `src/hooks/useStoryGeneration.ts`
+  - 已经在运行时维护 `chapterState`、`journeyBeat`、`storyEngineMemory.activeThreadIds`、`setpieceDirective` 等叙事推进信息。
+- `src/components/AdventurePanel.tsx`
+  - 已经有任务入口、章节入口、任务完成提示。
+- `src/components/adventure-panel/AdventurePanelOverlays.tsx`
+  - 已经能展示章节面板、任务面板、任务详情与奖励弹窗。
+- `src/types/storyEngine.ts`
+  - 已经有 `ChapterState`、`JourneyBeat`、`ThreadContract`、`SetpieceDirective` 这些中长线推进结构。
+
+这说明当前问题不是“系统完全缺失”，而是：
+
+**这些系统还没有被编译成一套稳定、持续、前台可见的目标体验。**
+
+## 1.2 为什么玩家仍然会觉得“没目标”
+
+结合现有实现，当前目标感不足主要来自 6 个原因。
+
+### 1.2.1 目标信息分散在多个系统里，但没有统一前台主语
+
+目前玩家可能同时受到这些信息影响：
+
+- 章节标题
+- 当前旅程节拍
+- 活跃任务
+- 任务当前 step
+- 活跃剧情线程
+- 当前场景异动
+
+但这些信息没有被统一编译成一句更强的玩家语义：
+
+- “你这章在追什么”
+- “你此刻最该先推进哪一件事”
+- “如果你现在只做一步，最有价值的是哪一步”
+
+结果就是后台系统知道很多，前台玩家却只感到“事情很多，但方向不够清楚”。
+
+### 1.2.2 任务存在，但任务不等于持续目标感
+
+当前任务系统已经能接受、推进、完成、交付，但它的可见性仍偏“日志型”：
+
+- 任务主要在任务面板里看
+- 任务完成时有提示，但完成前的存在感不够强
+- 玩家在主冒险视图里，并不会持续被提醒“这就是你当前的核心目标”
+
+这会导致：
+
+- 任务更像“可选记录”
+- 而不是“持续牵引当前行动的主线张力”
+
+### 1.2.3 章节 / 旅程节拍更像背景摘要，不像可执行目标
+
+现有 `chapterState` 和 `journeyBeat` 已经很接近“中长期目标骨架”，但当前更偏：
+
+- 章节氛围说明
+- 旅程阶段命名
+- 剧情回顾面板内容
+
+而不是：
+
+- 此刻最该推进哪条线程
+- 当前节拍对应的推荐行动
+- 这一步不推进会错过什么
+
+于是它们更像“叙事状态”，不够像“行动目标”。
+
+### 1.2.4 选项列表没有稳定表达“哪些动作在推进当前目标”
+
+当前 `StoryOption` 主要按 function 合法性和 priority 输出，玩家能看到：
+
+- 可以做什么
+
+但不总能一眼看出：
+
+- 哪个选项是在推进当前主目标
+- 哪个选项只是支线绕行
+- 哪个选项是补给、社交、整理状态
+
+当所有选项都以类似强度出现时，玩家会更容易进入“我每一步都像在随便试试”的体验。
+
+### 1.2.5 目标完成后的“下一目标交接”不够强
+
+当前一个任务完成后，系统能做的是：
+
+- 显示完成提示
+- 去任务日志领奖
+
+但目标体验更关键的一步其实是：
+
+**完成之后，系统要马上把下一段方向递到玩家手上。**
+
+如果这一步缺失，玩家就会在“完成一个点”之后重新掉回目标真空。
+
+### 1.2.6 探索和叙事已经有内容，但缺少“承诺感”
+
+当前系统已经能提供：
+
+- NPC 氛围
+- 场景异常
+- 宝藏调查
+- 战斗奖励
+- 关系推进
+
+但玩家未必知道这些碎片最后会指向什么。
+
+也就是说，项目已经有不少“局部有趣”，但还缺一层更明确的：
+
+- 这一章我正在靠近什么
+- 这一段我为什么继续走下去
+- 现在这次调查、切磋、汇报，和后面的更大目标是什么关系
+
+## 1.3 当前问题的根因总结
+
+可以把根因压缩成一句话：
+
+**项目已经有“任务系统”和“叙事阶段系统”，但还没有“玩家视角的统一目标导演层”。**
+
+---
+
+## 2. 设计原则
+
+## 2.1 目标感增强不等于满屏任务文案
+
+这个项目已经明确要求 UI 保持清爽、移动端优先，因此这次方案不能走：
+
+- 左上角一大堆任务文字
+- 常驻厚重任务列表
+- 密密麻麻的规则说明
+
+正确方向是：
+
+- 前台只突出 1 个当前主目标
+- 再给 1 个清晰的下一步
+- 其余信息折叠到任务 / 章节 / 地图面板中
+
+## 2.2 AI 负责叙事强化，本地规则负责目标裁决
+
+目标系统继续遵循当前项目已经验证有效的边界：
+
+AI 负责：
+
+- 当前目标为什么重要
+- 这一步在故事里的张力
+- 目标推进时的氛围和话术
+
+本地规则负责：
+
+- 当前目标从哪里来
+- 哪个目标优先级最高
+- 哪个选项算推进目标
+- 目标何时完成、阻塞、切换
+
+## 2.3 玩家应始终看到“短中长”三层目标
+
+真正稳定的目标感，不是只有任务，也不是只有主线，而是至少同时成立 3 层：
+
+1. 长目标
+   - 这一章 / 这一幕到底在逼近什么
+2. 中目标
+   - 当前正在处理哪条委托、哪条线程、哪段关系
+3. 短目标
+   - 下一步具体要去哪里 / 找谁 / 做什么
+
+## 2.4 至少保证一个明确前进方向，但保留探索自由
+
+目标驱动不是把玩家锁死在唯一按钮上。
+
+正确体验应该是：
+
+- 大多数时刻都有一个清晰可前进的方向
+- 但仍然允许补给、聊天、绕行、观察、整理 build
+- 玩家知道自己是在“主动偏离”，而不是“系统根本没方向”
+
+## 2.5 目标必须来自当前局面，而不是硬塞公告栏
+
+这次不做传统 MMO 式的固定任务板，而要让目标继续从这些上下文里长出来：
+
+- 当前章节主题
+- 当前旅程节拍
+- 活跃线程
+- 当前场景压力
+- 当前 NPC 关系
+- 当前资源缺口
+
+换句话说：
+
+**目标感要更强，但目标来源仍然要像从当前叙事局面里自然长出来。**
+
+---
+
+## 3. 核心方案：Goal Stack（目标栈）
+
+建议在现有 `quest + chapter + journeyBeat + threadContract` 之上，新增一层统一的玩家目标结构：
+
+**Goal Stack**
+
+它不替代现有系统，而是把现有系统编译成玩家当前最容易理解的目标层级。
+
+## 3.1 三层结构
+
+### 3.1.1 North Star Goal：章节承诺
+
+这是玩家当前阶段最大的“为什么继续往前”的理由。
+
+它来自：
+
+- `chapterState`
+- `actState`
+- `setpieceDirective`
+- 当前主线程组合
+
+玩家可感知的表达应该像：
+
+- 追查失踪背后的真正势力
+- 逼近这一区域的核心威胁
+- 弄清某位关键 NPC 为何始终在回避真相
+
+它回答的问题是：
+
+**这一章总体在往哪里去。**
+
+### 3.1.2 Active Contract Goal：当前主目标
+
+这是当前最应该推进的一件事。
+
+它通常来自：
+
+- 当前活跃任务
+- 当前线程合约
+- 当前旅程节拍对应的调查 / 汇报 / 前往 / 对峙目标
+
+它回答的问题是：
+
+**此刻最值得优先推进的事情是什么。**
+
+### 3.1.3 Immediate Step Goal：下一步行动
+
+这是玩家在当前回合、当前场景最容易执行的实际动作。
+
+它通常来自：
+
+- 当前任务 active step
+- 当前推荐场景
+- 当前推荐 NPC
+- 当前可触发 signal
+
+它回答的问题是：
+
+**如果我现在就迈一步，最合理的是先做什么。**
+
+## 3.2 支持目标
+
+除了主目标外，再允许最多 `2` 个支持目标，作为轻量附属存在：
+
+- 关系目标
+- 补给目标
+- 构筑目标
+- 探索支线
+
+它们应该存在，但不挤占主目标在前台的视觉优先级。
+
+## 3.3 3 秒规则
+
+Goal Stack 设计的核心验收标准是：
+
+**玩家在任意正常游玩时刻，用 3 秒就能看懂当前主目标和下一步。**
+
+---
+
+## 4. 目标导演层：Goal Director
+
+建议新增 `Goal Director`，负责把现有多个系统编译成一份统一的前台目标。
+
+## 4.1 输入来源
+
+目标导演层的输入应至少包含：
+
+- `chapterState`
+- `journeyBeat`
+- `storyEngineMemory.activeThreadIds`
+- `setpieceDirective`
+- `quests`
+- `currentScene`
+- `currentEncounter`
+- `npcStates`
+- 玩家资源状态
+- 最近若干 `StorySignal` / `QuestProgressSignal`
+
+## 4.2 输出目标
+
+输出应是一个稳定的 `GoalStackState`：
+
+```ts
+type GoalSourceKind =
+  | 'quest'
+  | 'chapter'
+  | 'journey_beat'
+  | 'thread_contract'
+  | 'setpiece'
+  | 'relationship'
+  | 'survival';
+
+type GoalTrack = 'main' | 'side' | 'relationship' | 'survival' | 'exploration';
+
+type GoalStatus =
+  | 'teased'
+  | 'active'
+  | 'blocked'
+  | 'ready_to_resolve'
+  | 'resolved'
+  | 'archived';
+
+interface GoalStackEntry {
+  id: string;
+  sourceKind: GoalSourceKind;
+  sourceId: string;
+  layer: 'north_star' | 'active_contract' | 'immediate_step' | 'support';
+  track: GoalTrack;
+  title: string;
+  promiseText: string;
+  whyNow: string;
+  nextStepText: string;
+  sceneHint?: string | null;
+  npcHint?: string | null;
+  progressLabel?: string | null;
+  status: GoalStatus;
+  urgency: 'low' | 'medium' | 'high';
+  relatedThreadIds: string[];
+}
+
+interface GoalStackState {
+  northStarGoal: GoalStackEntry | null;
+  activeGoal: GoalStackEntry | null;
+  immediateStepGoal: GoalStackEntry | null;
+  supportGoals: GoalStackEntry[];
+}
+```
+
+## 4.3 目标优先级裁决
+
+建议 Goal Director 按下面顺序裁决前台主目标：
+
+1. 若存在 `ready_to_turn_in` 的关键主目标任务，优先前台化“去交付”
+2. 若存在活跃任务 step，优先将该 step 作为 `immediate_step`
+3. 若当前无明确任务，但 `journeyBeat` 有推荐场景或推进方向，则编译成临时主目标
+4. 若当前有强 setpiece / showdown / boss_prelude，则将其提升为主目标承诺
+5. 若玩家资源严重不足，可生成支持型生存目标，但默认不覆盖主线目标
+
+## 4.4 目标切换规则
+
+目标切换不能随便抖动，建议满足以下规则：
+
+1. 主目标默认保持稳定，直到完成、阻塞或被更高优先级事件接管
+2. 支持目标可以进出，但不频繁替换主目标
+3. 章节目标只在章内关键阶段变化时更新
+4. 当前 step 完成后，必须立刻切到下一 step 或交付目标
+5. 如果玩家连续若干轮没有明确目标，系统必须主动重新生成一份当前 lead
+
+---
+
+## 5. 核心体验闭环：Promise -> Commit -> Advance -> Confirm -> Handoff
+
+这次目标感增强的关键，不是“加一个 HUD”，而是补齐完整闭环。
+
+## 5.1 Promise：先告诉玩家为什么值得追
+
+每一阶段都要先有一句承诺，回答：
+
+- 这件事背后有什么更大的意义
+- 当前章节到底在逼近什么
+
+这层主要来自：
+
+- `chapterState`
+- `journeyBeat`
+- `setpieceDirective`
+
+## 5.2 Commit：把大目标落成当前可接的委托或 lead
+
+大目标不能悬空，必须落到玩家当前能承接的一件事：
+
+- 接受委托
+- 去某处调查
+- 找某 NPC 对话
+- 回去交付
+- 前往某场景验证异常
+
+## 5.3 Advance：推进时持续看到自己在接近目标
+
+推进不能只在任务日志里发生。
+
+推进感需要在主流程里被持续表达：
+
+- 选项提示“推进当前目标”
+- 场景文本回响“你正在靠近这条线”
+- 进度提示明确“已完成哪一步”
+
+## 5.4 Confirm：完成后给明确确认
+
+推进成功后，系统要立即确认：
+
+- 你已经推进了
+- 你推进的是哪条目标
+- 这一步意味着什么
+
+而不只是静默更新后台进度。
+
+## 5.5 Handoff：立刻交接下一目标
+
+真正决定目标感是否持续的，是交接。
+
+完成一件事后，系统要尽快把下一句说出来：
+
+- 现在回去交付
+- 线索已经到手，下一步去找谁
+- 这一步已完成，更大的目标因此前进到了哪里
+
+如果没有 handoff，再好的任务系统也会出现“刚做完就空了”的断层。
+
+---
+
+## 6. UI 表达方案
+
+UI 目标是：
+
+**不增厚页面、不堆规则说明，但让目标在主冒险视图里持续可见。**
+
+## 6.1 冒险页新增常驻 Goal Ribbon
+
+建议在主冒险页增加一个轻量常驻的 `Goal Ribbon`，只展示当前最需要知道的目标信息。
+
+推荐展示字段：
+
+- 目标标题
+- 目标 track 标签
+- 一句 `nextStepText`
+- 一行极短 `sceneHint / npcHint`
+- 简短进度表达
+
+表现要求：
+
+- 默认只显示 1 个主目标
+- 风格轻，不做厚重说明板
+- 手机端优先单列、可折叠
+- 不抢占剧情区和选项区的核心空间
+
+## 6.2 主冒险视图要直接显示“下一步”
+
+对玩家而言，最重要的一句不是任务标题，而是：
+
+- 去哪里
+- 找谁
+- 做什么
+
+因此 Goal Ribbon 里最该强化的是 `nextStepText`，而不是一堆背景说明。
+
+例如：
+
+- 去遗迹外缘确认异动，再回来和林朔对话
+- 返回营地，把调查结果告诉同伴
+- 前往北桥，追上刚刚提到的敌对角色
+
+## 6.3 选项按钮增加目标关联标记
+
+建议给 `StoryOption` 增加目标关联信息：
+
+```ts
+interface StoryOptionGoalAffordance {
+  goalId: string;
+  relation: 'advance' | 'support' | 'detour';
+  label: string;
+}
+```
+
+然后在前台做极轻量表达：
+
+- 推进当前目标
+- 支持当前准备
+- 暂时绕开目标
+
+要求：
+
+- 只对关键选项打标
+- 不让所有按钮都挂一堆说明
+- 至少保证存在主目标时，通常有一个 `advance` 选项
+
+## 6.4 任务面板从“日志”转成“目标板”
+
+当前任务面板基础可复用，但信息组织建议升级为：
+
+1. 当前主目标
+2. 正在推进
+3. 可交付
+4. 支持目标
+5. 已归档
+
+这样玩家打开任务页时，看到的不是一排同权列表，而是更明确的目标优先级结构。
+
+## 6.5 章节面板只做“承诺 + 当前节拍 + 当前主目标”
+
+章节面板不需要继续扩成说明书。
+
+建议只保留：
+
+- 当前章节标题
+- 当前章节主题
+- 当前旅程节拍
+- 本章正在追的主问题
+- 当前建议推进方向
+
+## 6.6 任务完成提示要直接导向下一个动作
+
+当前“任务完成，可前往日志领奖”已经比没有强，但还不够。
+
+建议改成：
+
+- 任务完成
+- 现在去哪里交付 / 现在建议做什么
+- 一键打开当前目标详情
+
+这样完成提示本身也成为 handoff 的一部分。
+
+---
+
+## 7. 与叙事生成和选项生成的联动
+
+目标感不是纯 UI 问题，还必须进入叙事与选项生成。
+
+## 7.1 Prompt 上下文注入当前目标摘要
+
+建议在 `buildStoryContextFromState(...)` 产出的上下文中，增加统一目标摘要：
+
+```ts
+interface GoalPromptContext {
+  northStarSummary?: string | null;
+  activeGoalTitle?: string | null;
+  activeGoalWhyNow?: string | null;
+  immediateStepText?: string | null;
+  supportGoalTitles?: string[];
+}
+```
+
+AI 使用这层上下文的目的不是发明新目标，而是：
+
+- 在剧情文本里强化当前推进感
+- 在选项措辞里更明确表达“哪步是往前”
+- 在阶段切换时自然回写 handoff 语气
+
+## 7.2 本地规则保证前进选项存在
+
+当存在主目标且当前场景允许推进时，本地规则应尽量保证：
+
+- 至少一个选项能推进当前目标
+- `换一换` 不应把所有前进方向都刷掉
+
+换句话说：
+
+**选项池可以多样，但不能把方向感洗掉。**
+
+## 7.3 目标推进要进入剧情文本回响
+
+当 step 被推进时，剧情文本应更常出现这些反馈：
+
+- 你已经拿到了关键线索
+- 这一步让某人对你的判断改变了
+- 当前区域的异常已经被你确认
+- 现在该回去把结果说清楚
+
+这类文本能明显强化“我不是在原地刷新内容，而是在前进”。
+
+---
+
+## 8. 目标来源设计
+
+为了避免只有“NPC 发任务”才有目标，建议目标来源拆成 6 类。
+
+## 8.1 Quest Goal：委托型目标
+
+来自现有 `QuestContract / QuestStep`。
+
+适合表达：
+
+- 讨伐
+- 调查
+- 切磋
+- 回报
+- 交付
+
+## 8.2 Thread Goal：叙事线程型目标
+
+来自：
+
+- `ThreadContract`
+- `activeThreadIds`
+
+适合表达：
+
+- 当前章节的主要调查方向
+- 某条持续存在但暂未显式任务化的追查线
+
+## 8.3 Journey Goal：旅程阶段型目标
+
+来自：
+
+- `JourneyBeat`
+
+适合表达：
+
+- 现在是调查阶段
+- 现在该回营整备
+- 现在正在逼近冲突前奏
+
+## 8.4 Setpiece Goal：高潮前奏型目标
+
+来自：
+
+- `SetpieceDirective`
+
+适合表达：
+
+- 决战前奏
+- 对峙前整理
+- 余波中的关键善后
+
+## 8.5 Relationship Goal：关系推进型目标
+
+来自：
+
+- NPC 好感阶段
+- 同伴弧线
+- 当前营地事件 / 私聊机会
+
+适合表达：
+
+- 找某人谈清楚
+- 处理一次关系冲突
+- 在营地承接一段角色剧情
+
+## 8.6 Survival Goal：生存补给型目标
+
+来自：
+
+- 资源紧张
+- build 缺口
+- 路线压力
+
+适合表达：
+
+- 先补给
+- 先回营整理
+- 先准备能支撑下一段推进的资源
+
+但它默认只做支持目标，不轻易覆盖主线目标。
+
+---
+
+## 9. 数据结构与模块建议
+
+## 9.1 建议新增类型
+
+建议新增：
+
+- `src/services/storyEngine/goalTypes.ts`
+- 或直接扩展 `src/types/storyEngine.ts`
+
+核心结构建议包括：
+
+- `GoalStackEntry`
+- `GoalStackState`
+- `StoryOptionGoalAffordance`
+- `GoalPulseEvent`
+- `GoalHandoff`
+
+其中 `GoalPulseEvent` 用于前台反馈：
+
+```ts
+interface GoalPulseEvent {
+  id: string;
+  goalId: string;
+  pulseType: 'progress' | 'ready_to_turn_in' | 'resolved' | 'handoff';
+  title: string;
+  detail: string;
+}
+```
+
+## 9.2 建议新增模块
+
+建议新增：
+
+- `src/services/storyEngine/goalDirector.ts`
+- `src/services/storyEngine/goalCompiler.ts`
+- `src/services/storyEngine/goalSignals.ts`
+
+职责如下：
+
+- `goalDirector`
+  - 汇总章节 / 旅程 / 任务 / 线程 / 资源状态，裁决当前目标栈
+- `goalCompiler`
+  - 把不同来源编译成统一 GoalStackEntry
+- `goalSignals`
+  - 处理 progress、resolve、handoff 反馈事件
+
+## 9.3 建议改动的现有区域
+
+建议优先接入这些文件：
+
+- `src/hooks/useStoryGeneration.ts`
+  - 在返回值中新增 `goalUi`
+- `src/hooks/story/uiTypes.ts`
+  - 增加目标 UI 类型
+- `src/components/AdventurePanel.tsx`
+  - 增加 Goal Ribbon 与选项目标标记
+- `src/components/adventure-panel/AdventurePanelOverlays.tsx`
+  - 将任务 / 章节视图改成围绕主目标组织
+- `src/types/story.ts`
+  - 扩展 `StoryOption` 目标标记字段
+- `src/data/questFlow.ts`
+  - 暴露任务当前 step 与 handoff 所需摘要
+
+---
+
+## 10. MVP 落地顺序
+
+## 阶段 A：先做前台统一目标层，不重写底层任务系统
+
+先做：
+
+- Goal Director
+- Goal Stack 编译
+- Adventure 主视图 Goal Ribbon
+
+此阶段目标：
+
+- 玩家打开主冒险页就能看到当前主目标和下一步
+- 不要求任务生成逻辑大改
+
+## 阶段 B：补齐目标交接
+
+重点做：
+
+- 任务接受后的主目标接管
+- step 完成后的下一步切换
+- ready_to_turn_in 的前台提升
+- 领奖后的下一目标 handoff
+
+此阶段目标：
+
+- 目标不再只在“开始接任务”时存在
+- 完成后也能顺势接到下一步
+
+## 阶段 C：让选项和剧情文本都带目标感
+
+重点做：
+
+- `StoryOption.goalAffordance`
+- 目标推进相关 prompt 上下文
+- 目标推进反馈 pulse
+
+此阶段目标：
+
+- 玩家不仅在任务面板里看见目标
+- 也能在每一回合的文本和选项里感到自己在朝目标前进
+
+## 阶段 D：补非任务型目标来源
+
+重点做：
+
+- `journeyBeat -> goal`
+- `thread -> goal`
+- `relationship -> support goal`
+- `survival -> support goal`
+
+此阶段目标：
+
+- 即使没有显式任务，系统也仍然能给出清晰 lead
+
+---
+
+## 11. 验收标准
+
+做到以下几点，才能说明“任务驱动目标感”真的提升了，而不是只多了一层 UI。
+
+## 11.1 体验验收
+
+1. 新开局 `3` 次有效交互内，玩家必须看到一个明确主目标。
+2. 在存在主目标的正常游玩阶段，主冒险页必须持续可见“当前目标 + 下一步”。
+3. 任一目标完成后，下一目标或交付动作必须在 `1` 次交互内被明确交接。
+4. 玩家不打开任务面板，也能在多数时刻知道自己下一步该做什么。
+
+## 11.2 交互验收
+
+1. 有活跃目标时，选项池中应尽量存在至少 `1` 个推进当前目标的选项。
+2. `换一换` 不应把唯一前进方向刷没。
+3. 任务完成提示应直接导向当前后续动作，而不只是泛提示。
+
+## 11.3 UI 验收
+
+1. 手机竖屏下 Goal Ribbon 不应把主剧情区和底部操作区挤出首屏。
+2. 前台目标信息应控制在轻量级，不堆规则文案。
+3. 任务 / 章节 / 目标表达需保持当前项目的清爽游戏 UI 风格。
+
+## 11.4 叙事验收
+
+1. 当前章节承诺、当前主目标、下一步行动三层语义必须能同时成立。
+2. 任务推进、调查推进、关系推进都应在剧情文本里有回响。
+3. 玩家应明显感到“我正在逼近某件事”，而不只是“我又看了一段新文本”。
+
+---
+
+## 12. 为什么这套方案适合当前仓库
+
+这套方案不是推翻重做，而是顺着仓库已经形成的系统继续往前走：
+
+1. 当前仓库已经有任务 contract 和 step progression
+   - 所以短目标层并不是从零开始。
+2. 当前仓库已经有章节、旅程节拍、线程与 setpiece
+   - 所以中长目标层已经有素材，只差统一导演。
+3. 当前 Adventure UI 已有任务入口、章节入口和弹层体系
+   - 所以前台表达可以在现有壳层上增量升级。
+4. 当前项目强调移动端优先与清爽 UI
+   - 所以本方案明确走“一个主目标 + 一个下一步”的轻量表达，而不是堆面板。
+
+换句话说：
+
+**当前项目最需要的，不是再造一套新任务系统，而是把已有的任务、章节、线程、旅程节拍编译成一条持续存在的玩家目标体验。**
+
+---
+
+## 13. 最后结论
+
+用户反馈“缺乏任务驱动的目标感”，真正指向的问题不是“没有任务”，而是：
+
+- 任务没有持续站在前台
+- 章节和旅程没有转成行动承诺
+- 完成后的下一步交接不够强
+- 选项和剧情文本没有持续强化“你正在前进”
+
+因此，这次 PRD 的核心不是“继续扩任务数量”，而是补上一个统一的 `Goal Director + Goal Stack`：
+
+1. 用章节承诺给玩家长期方向
+2. 用当前主目标给玩家中程牵引
+3. 用下一步行动给玩家即时清晰的操作方向
+4. 用推进反馈与 handoff 把整条目标链接起来
+
+这样之后，玩家感受到的就不再是“系统里有任务”，而会更接近：
+
+**我知道自己为什么在这里、正在推进什么、下一步该去哪，这个世界也在不断回应我的前进。**

docs/prd/AI_NATIVE_TASK_SYSTEM_PRIMARY_UI_ADJUSTMENT_PRD_2026-04-07.md

@@ -0,0 +1,473 @@
+# AI 原生任务系统主前台化调整方案
+
+更新时间：`2026-04-07`
+
+## 0. 背景
+
+在当前迭代里，右上区域同时出现了：
+
+- `目标`
+- `章节`
+- `任务`
+
+从系统设计角度看，这 3 个概念分别对应：
+
+- `目标`：当前应该优先推进的事情
+- `章节`：当前叙事阶段与长期承诺
+- `任务`：玩家可执行、可追踪、可交付的实际推进载体
+
+但从玩家视角看，这 3 个入口被并列摆在同一层级时，会产生两个直接问题：
+
+1. 概念重复
+   - `目标` 和 `任务` 都在告诉玩家“下一步做什么”。
+2. 主次倒置
+   - 原本最该成为主前台的“任务系统”，反而被拆散到 `目标 / 章节 / 任务` 三个入口中，导致任务系统看起来像被边缘化。
+
+一句话判断：
+
+**当前不是“信息不够”，而是“前台概念过多，任务作为主推进载体没有站到 C 位”。**
+
+---
+
+## 1. 核心结论
+
+建议把当前前台结构调整为：
+
+**任务系统作为唯一主推进入口，目标与章节退到任务系统内部，成为任务的上层语义与背景语义。**
+
+也就是说：
+
+- `任务` 是玩家前台的主概念
+- `目标` 是任务面板里的当前聚焦态
+- `章节` 是任务面板里的背景上下文
+
+而不是 3 个并列一级入口。
+
+---
+
+## 2. 当前问题拆解
+
+## 2.1 三个并列入口会制造额外理解成本
+
+玩家进入第一个场景时，本来最需要快速理解的是：
+
+- 我当前接了什么事
+- 下一步去哪
+- 什么时候算推进
+
+但现在 UI 让玩家先面对的是：
+
+- 要不要看目标
+- 要不要看章节
+- 要不要看任务
+
+这会把本来应该非常直接的“任务驱动”体验，变成一次概念选择题。
+
+## 2.2 `目标` 和 `任务` 在玩家心智中高度重叠
+
+当前 `目标` 弹窗展示的是：
+
+- 当前主推进
+- 下一步
+
+而 `任务` 面板展示的是：
+
+- 当前主目标任务
+- 任务摘要
+- 任务详情
+
+这两者在玩家眼里并不是两套系统，而更像：
+
+- 一个是“任务的简版”
+- 一个是“任务的详版”
+
+如果它们并列出现，只会让玩家觉得重复。
+
+## 2.3 `章节` 不应与 `任务` 争夺同一前台优先级
+
+章节的作用更接近：
+
+- 给长期方向
+- 给叙事承诺
+- 给“这一章在讲什么”的理解坐标
+
+它并不直接回答：
+
+- 此刻去哪
+- 找谁
+- 做什么
+
+因此章节不适合做和任务并列的常驻一级入口，更适合做任务面板里的背景信息，或二级展开信息。
+
+## 2.4 移动端空间被重复入口浪费
+
+项目本身是移动端优先。
+
+当前右上连续摆 3 个入口，会带来：
+
+- 视觉拥挤
+- 首屏操作点过多
+- 玩家频繁在 3 个高度相似的入口之间来回切
+
+这类浪费在手机端尤其明显。
+
+## 2.5 当前实现会削弱“任务系统正在驱动我”的感受
+
+当 `目标` 被做成独立前台入口时，用户会更容易把“目标系统”理解成一个独立模块，而不是任务系统的前台头部。
+
+结果就是：
+
+- 任务系统负责记录
+- 目标系统负责提醒
+- 章节系统负责叙事
+
+三个系统各做一部分，但没有一个系统真正完整承担“驱动玩家前进”的主责任。
+
+---
+
+## 3. 调整原则
+
+## 3.1 前台只保留一个主推进概念：任务
+
+玩家最容易理解、最容易执行、也最容易形成长期习惯的前台概念，应该只有一个：
+
+**任务**
+
+因为任务天然同时满足：
+
+- 可接取
+- 可追踪
+- 可推进
+- 可交付
+- 可奖励
+
+这正是“目标感”最需要的系统壳。
+
+## 3.2 目标不是独立模块，而是任务的当前聚焦态
+
+目标仍然有价值，但它在前台的正确位置应是：
+
+- 任务面板顶部的“当前主任务”
+- 任务更新时的提示弹窗
+- 任务推进时的脉冲反馈
+
+也就是说：
+
+**目标是任务系统的呈现方式，不是另一个并列入口。**
+
+## 3.3 章节不是行动入口，而是任务背景
+
+章节保留，但它更适合表达：
+
+- 本章主题
+- 当前阶段
+- 当前长期承诺
+
+所以章节应该：
+
+- 在任务面板里提供轻量背景卡
+- 或在任务面板中提供“查看章节背景”二级展开
+
+而不是右上一级按钮。
+
+## 3.4 先让任务系统完整承担“承接、推进、反馈、交接”
+
+如果想真正让任务驱动体验成立，就必须让任务系统自己完成完整闭环：
+
+1. 接任务
+2. 看任务
+3. 推任务
+4. 知道自己推进了
+5. 知道什么时候可交付
+6. 领奖后获得下一任务方向
+
+只要这条链断在别的模块上，任务系统就会继续显得像“半个主系统”。
+
+---
+
+## 4. 新的信息架构
+
+## 4.1 顶层前台结构
+
+建议调整为：
+
+- 保留：`任务`
+- 保留：`设置`
+- 视情况保留：`统计`
+- 移除独立常驻入口：`目标`
+- 移除独立常驻入口：`章节`
+
+其中：
+
+- `目标` 被并入任务面板头部与任务更新弹窗
+- `章节` 被并入任务面板中的“章节背景卡”
+
+## 4.2 任务面板的新结构
+
+建议把当前任务面板重构为下面 4 层：
+
+### 第一层：当前主任务
+
+只展示玩家此刻最该看的内容：
+
+- 任务标题
+- 下一步
+- 地点 / 人物提示
+- 当前进度
+
+这是原 `目标` 面板应该承载的内容，但要回收到 `任务` 面板头部。
+
+### 第二层：活跃任务列表
+
+展示：
+
+- 当前主任务
+- 其他活跃任务
+- 可交付任务
+
+排序规则应继续保留：
+
+1. 当前主任务
+2. 可交付任务
+3. 其他活跃任务
+4. 已归档 / 已完成
+
+### 第三层：章节背景卡
+
+只显示：
+
+- 当前章节标题
+- 当前段落
+- 一句章节摘要
+
+不要再显示：
+
+- 近期回顾大段文本
+- 营地风向
+- 高光导演
+- 其他偏后台式的叙事结构信息
+
+这些信息可以保留在系统内部，但不应默认占据前台。
+
+### 第四层：任务详情页
+
+任务详情页继续保留，但内容也要收束为玩家信息：
+
+- 任务简介
+- 目标对象
+- 当前步骤
+- 奖励
+- 交付动作
+
+---
+
+## 5. 弹窗策略调整
+
+## 5.1 “目标弹窗”重命名为“任务更新弹窗”
+
+当前独立的目标弹窗不应继续以“目标”名义存在。
+
+建议改成：
+
+- `任务更新`
+- `已接取任务`
+- `任务可交付`
+- `下一步建议`
+
+这样玩家会直接把它理解成任务系统的反馈，而不是另一套系统。
+
+## 5.2 任务更新弹窗的触发时机
+
+建议只在这些关键节点弹出：
+
+1. 初次进入场景，生成当前主任务时
+2. 接受新任务时
+3. 当前任务关键步骤切换时
+4. 当前任务变为可交付时
+5. 领奖后 handoff 到下一目标时
+
+不建议在普通小幅状态变化时频繁弹出。
+
+## 5.3 任务更新弹窗展示内容
+
+只保留：
+
+- 当前任务标题
+- 当前为什么值得推进
+- 下一步做什么
+- 如有必要，给出地点 / 人物提示
+
+不要再展示：
+
+- 支持目标
+- 章节承诺大段说明
+- 过多后台状态信息
+
+---
+
+## 6. 章节信息的前台降级方案
+
+## 6.1 章节从一级入口降为任务系统内嵌信息
+
+章节仍然重要，但前台地位应该调整为：
+
+- 默认不单独抢入口
+- 默认只在任务面板中出现
+- 仅在必要时从任务面板中二级展开
+
+## 6.2 章节面板的最小展示集
+
+如果仍然保留章节面板，建议最小化到：
+
+- 当前章节标题
+- 当前阶段
+- 当前段落
+- 当前推进方向
+
+不再默认展示：
+
+- 近期回顾长文
+- 营地事件
+- setpiece 导演问题
+- 其他后台语义分层
+
+## 6.3 章节与任务的关系表达
+
+章节信息应服务于任务理解，而不是独立存在。
+
+推荐表达方式：
+
+- 在任务面板中显示：
+  - `所属章节：封桥旧案`
+  - `当前段落：调查`
+  - `当前推进方向：继续追查桥上的异常来源`
+
+让玩家知道：
+
+**任务是我现在在做的，章节是这件事属于哪一章。**
+
+---
+
+## 7. 系统语义重排
+
+建议把当前 3 层语义重新映射成：
+
+### 前台玩家语义
+
+1. 任务
+   - 玩家真正会去点击、追踪、推进的对象
+2. 当前主任务
+   - 任务中的当前聚焦项
+3. 章节背景
+   - 帮助理解任务所在的大方向
+
+### 后台系统语义
+
+1. `Quest`
+   - 主执行壳
+2. `GoalStack`
+   - 任务前台聚焦编译层
+3. `Chapter / JourneyBeat / Setpiece`
+   - 任务背景和长期语义来源
+
+也就是说：
+
+**Goal Stack 继续保留在系统内部，但在 UI 语义上不再和 Task 并列。**
+
+---
+
+## 8. 实现调整建议
+
+## 8.1 第一阶段：入口收口
+
+直接调整：
+
+- 删除右上独立 `目标` 按钮
+- 删除右上独立 `章节` 按钮
+- 保留 `任务` 按钮
+
+同时：
+
+- 将当前目标弹窗改名为任务更新弹窗
+- 从任务按钮进入任务面板
+
+## 8.2 第二阶段：任务面板吸收目标信息
+
+在任务面板中新增顶部区域：
+
+- 当前主任务
+- 下一步
+- 简短提示
+
+并用它替代当前独立 `目标` 入口的职责。
+
+## 8.3 第三阶段：章节信息降级
+
+调整章节信息展示为：
+
+- 任务面板中的轻量背景卡
+
+必要时：
+
+- 在任务面板内再点“查看章节背景”进入二级详情
+
+## 8.4 第四阶段：任务更新弹窗统一化
+
+把当前各种与目标相关的弹窗统一命名和风格：
+
+- 接取任务
+- 任务推进
+- 任务可交付
+- 下一步建议
+
+统一挂到任务系统语义下。
+
+---
+
+## 9. 对当前代码结构的建议映射
+
+建议后续实现时主要改这些位置：
+
+- `src/components/AdventurePanel.tsx`
+  - 去掉独立目标前台嵌入和独立章节入口
+- `src/components/adventure-panel/AdventurePanelOverlays.tsx`
+  - 重做任务面板顶部和章节卡结构
+- `src/services/storyEngine/goalDirector.ts`
+  - 保留 GoalStack，但只作为任务聚焦编译层
+- `src/hooks/useStoryGeneration.ts`
+  - 把 pulse / handoff 语义统一归到任务更新流
+- `src/hooks/useStoryOptions.ts`
+  - 保持选项与当前主任务的关联标记
+
+---
+
+## 10. 验收标准
+
+做到以下几点，才说明“任务系统为主”的调整真正成立：
+
+1. 右上不再同时并列出现 `目标 / 章节 / 任务` 三个入口。
+2. 玩家在前台只需要理解一个主推进概念：`任务`。
+3. 当前主任务、下一步、可交付状态，都能在任务系统内部闭环完成。
+4. 章节信息仍然存在，但不再和任务抢夺一级前台入口。
+5. 首个场景进入后，玩家首先感知到的是“接到了什么任务”，而不是“系统里还有一套目标模块”。
+6. 移动端右上操作区明显更简洁，主剧情区不再被多套并列语义干扰。
+
+---
+
+## 11. 最后结论
+
+当前右上同时摆 `目标 / 章节 / 任务`，本质上是在让三个语义层并列竞争前台注意力，这会直接削弱任务系统的主导感。
+
+正确的调整方向不是“继续优化三个入口”，而是重新明确主次：
+
+- **任务**：前台唯一主推进入口
+- **目标**：任务系统内部的当前聚焦态
+- **章节**：任务系统内部的背景语义
+
+这样调整之后，玩家前台感受到的就不再是：
+
+- “我该看目标、章节还是任务？”
+
+而会更接近：
+
+- “我当前的任务是什么，下一步去哪，章节只是告诉我这件任务属于哪一段故事。”