391
docs/audits/AGENT_TO_DRAFT_TO_WORLD_PIPELINE_AUDIT_2026-04-20.md
Normal file
391
docs/audits/AGENT_TO_DRAFT_TO_WORLD_PIPELINE_AUDIT_2026-04-20.md
Normal file
@@ -0,0 +1,391 @@
|
||||
# Agent 聊天到草稿生成到进入游戏世界链路审计
|
||||
|
||||
更新时间：`2026-04-20`
|
||||
|
||||
## 0. 审计目标
|
||||
|
||||
本次审计只看一条链：
|
||||
|
||||
`Agent 聊天 -> 世界草稿生成 -> 结果页/作品库 -> 进入游戏世界`
|
||||
|
||||
聚焦回答四类问题：
|
||||
|
||||
1. 哪些数据在链路中断掉了
|
||||
2. 哪些地方在代码里同时存在多条 pipeline
|
||||
3. 哪些字段、功能、组件已经变成冗余或主链弱消费
|
||||
4. 哪些能力在 contract、PRD 或代码结构里已经定义，但并没有真正实装到当前游戏主流程
|
||||
|
||||
---
|
||||
|
||||
## 1. 结论先行
|
||||
|
||||
当前系统还没有形成“Agent 会话是唯一真相源、发布后再进入世界”的单一主链，而是处在多条 pipeline 并存、多个桥接层临时粘合的状态。
|
||||
|
||||
最关键的结论有 8 条：
|
||||
|
||||
1. 当前至少并存 `5` 条相关 pipeline，其中真正影响可玩流程的主链至少有 `3` 条。
|
||||
2. 最大的数据断点是：`CustomWorldAgentSessionSnapshot.draftProfile` 不直接进入 runtime，前端 `buildCustomWorldProfileFromAgentDraft()` 会先把它本地编译成 legacy `CustomWorldProfile`，后面的结果页、自动保存、进入世界都只认这个 legacy profile。
|
||||
3. 服务端内部也存在一次“先编成 legacy runtime profile，再转回 foundation draft”的双重编译，`draftProfile.legacyResultProfile` 是这个桥接层留下来的强耦合字段。
|
||||
4. `packages/shared/src/contracts/customWorldAgent.ts`、`server-node/src/routes/customWorldAgent.ts`、`server-node/src/services/customWorldAgentOrchestrator.ts` 三层定义不一致，`publish_world / generate_scene_assets / sync_scene_assets / expand_long_tail / lock_cards / unlock_cards / regenerate_scope` 等关键动作没有形成真实可用链路。
|
||||
5. `CustomWorldResultView.tsx` 仍保留“直接对 legacy profile 生成角色/地点、直接编辑 profile”的旧流程，会绕过 Agent session，是当前最明显的并行 pipeline 和冗余功能源。
|
||||
6. “进入世界”和“发布世界”目前是两套平行逻辑。Agent 草稿结果页可以自动保存并直接进入世界，但 `publish_world` action 仍不可用，`qualityFindings / blocker` 校验也没有真正接入。
|
||||
7. `listCustomWorldWorks()` 与 `CustomWorldWorkSummaryService` 已能聚合 Agent 草稿和已发布 profile，但平台 `create` tab 仍主要展示 `myEntries`，Agent draft session 不能自然回到主入口，恢复创作主要依赖 `activeSessionId`。
|
||||
8. Agent 工作区主 UI 只接了头部、进度、线程、输入框、操作横幅等极简子集，PRD 里规划的锁定条、草稿抽屉、详情面板、澄清面板、快捷动作、发布校验结果等大部分还没有真正进入当前游戏主流程。
|
||||
|
||||
---
|
||||
|
||||
## 2. 目标链路
|
||||
|
||||
按 `docs/prd/AI_NATIVE_AGENT_FIRST_CUSTOM_WORLD_CREATOR_PRD_2026-04-12.md` 和 `docs/prd/AI_NATIVE_AGENT_FIRST_EIGHT_ANCHOR_CO_CREATION_FLOW_PRD_2026-04-16.md`，目标链路应当是：
|
||||
|
||||
```text
|
||||
Agent 对话
|
||||
-> Express 后端维护结构化 eight-anchor / creatorIntent / lockState / draftSnapshot
|
||||
-> foundation draft
|
||||
-> 角色资产工坊 / 场景资产工坊
|
||||
-> sync 回 Agent session draft
|
||||
-> expand long tail
|
||||
-> publish_world
|
||||
-> 服务端执行 quality / blocker 校验
|
||||
-> 服务端编译最终 CustomWorldProfile
|
||||
-> 持久化到世界库
|
||||
-> 进入世界
|
||||
```
|
||||
|
||||
这条目标链路有 4 个硬约束：
|
||||
|
||||
1. Express 后端才是真实状态源，前端只负责展示和输入，不负责结构化草稿编译。
|
||||
2. 未发布的 Agent 草稿不应该直接污染正式世界库，主入口里应该通过“继续创作”恢复。
|
||||
3. 进入世界前应先经过 `publish_world`，并由发布校验阻止缺角色资产、缺场景资产、缺主线第一幕等 blocker。
|
||||
4. 结果页不再是旧自定义世界编辑器的平移副本，而应更接近“最终预览 / 发布确认 / 进入世界”的收口层。
|
||||
|
||||
---
|
||||
|
||||
## 3. 当前真实链路
|
||||
|
||||
## 3.1 Agent 会话草稿链
|
||||
|
||||
当前新链路实际是：
|
||||
|
||||
```text
|
||||
PreGameSelectionFlow.tsx
|
||||
-> /api/runtime/custom-world/agent/sessions
|
||||
-> CustomWorldAgentSessionStore
|
||||
-> CustomWorldAgentOrchestrator
|
||||
-> CustomWorldAgentFoundationDraftService
|
||||
-> CustomWorldAgentAutoAssetService
|
||||
-> session.draftProfile / draftCards / assetCoverage
|
||||
-> 前端 buildCustomWorldProfileFromAgentDraft()
|
||||
-> generatedCustomWorldProfile
|
||||
-> upsertCustomWorldProfile()
|
||||
-> handleCustomWorldSelect(profile)
|
||||
-> runtime
|
||||
```
|
||||
|
||||
关键特点：
|
||||
|
||||
1. Agent session 不是 runtime 直接消费的对象。
|
||||
2. Agent 草稿完成后，会在前端先转成 `CustomWorldProfile`。
|
||||
3. 结果页阶段会自动调用 `upsertCustomWorldProfile()`，把当前 profile 写进 `custom-world-library`。
|
||||
4. “进入世界”按钮直接把这个 profile 送给 `handleCustomWorldSelect(...)`，不需要 `publish_world`。
|
||||
|
||||
主要证据：
|
||||
|
||||
- `src/components/game-shell/PreGameSelectionFlow.tsx`
|
||||
- `src/services/customWorldAgentDraftResult.ts`
|
||||
- `src/hooks/useGameFlow.ts`
|
||||
|
||||
## 3.2 旧自定义世界 session 链
|
||||
|
||||
旧链路仍然完整存在：
|
||||
|
||||
```text
|
||||
aiService.generateCustomWorldProfile()
|
||||
-> /api/runtime/custom-world/sessions
|
||||
-> answerCustomWorldSessionQuestion()
|
||||
-> /generate/stream
|
||||
-> generateCustomWorldProfile()
|
||||
-> CustomWorldProfile
|
||||
-> 结果页 / 作品库 / 进入世界
|
||||
```
|
||||
|
||||
关键特点：
|
||||
|
||||
1. `src/services/aiService.ts` 里的 `generateCustomWorldProfile()` 仍然会创建旧 `custom-world/sessions`。
|
||||
2. 前端会先根据 `world_hook / player_premise / opening_situation / core_conflict` 自动补默认回答，再触发流式生成。
|
||||
3. 这条链已经与 Agent 八锚点链并行存在，且依然可用。
|
||||
|
||||
主要证据：
|
||||
|
||||
- `src/services/aiService.ts`
|
||||
- `server-node/src/routes/runtimeRoutes.ts`
|
||||
- `server-node/src/services/customWorldSessionStore.ts`
|
||||
|
||||
## 3.3 已保存 profile / 作品库链
|
||||
|
||||
当前作品库链是：
|
||||
|
||||
```text
|
||||
custom-world-library
|
||||
-> upsert / delete / publish / unpublish
|
||||
-> PlatformHomeView / saved profile detail
|
||||
-> CustomWorldResultView
|
||||
-> handleCustomWorldSelect(profile)
|
||||
```
|
||||
|
||||
关键特点：
|
||||
|
||||
1. 这条链直接消费 `CustomWorldProfile`，不依赖 Agent session。
|
||||
2. Agent 结果页自动保存后，也会落入这条链。
|
||||
3. `publish/unpublish` 作用在作品库 profile 上，而不是 Agent session 上。
|
||||
|
||||
主要证据：
|
||||
|
||||
- `server-node/src/routes/runtimeRoutes.ts`
|
||||
- `src/components/game-shell/PlatformHomeView.tsx`
|
||||
- `src/components/game-shell/PreGameSelectionFlow.tsx`
|
||||
|
||||
## 3.4 结果页 legacy profile 直改链
|
||||
|
||||
`CustomWorldResultView.tsx` 仍保留旧能力：
|
||||
|
||||
1. `generateCustomWorldPlayableNpc({ profile })`
|
||||
2. `generateCustomWorldStoryNpc({ profile })`
|
||||
3. `generateCustomWorldLandmark({ profile })`
|
||||
4. `CustomWorldEntityEditorModal`
|
||||
|
||||
这意味着结果页不仅是预览层，还是一套独立的“legacy profile 直改工作台”。这一套能力不会回写 Agent session 的结构化状态，也不会走 Agent action route。
|
||||
|
||||
主要证据：
|
||||
|
||||
- `src/components/CustomWorldResultView.tsx`
|
||||
- `src/services/aiService.ts`
|
||||
|
||||
## 3.5 创作中心 works 聚合链
|
||||
|
||||
后端已经能聚合两类作品：
|
||||
|
||||
1. `sourceType: 'agent_session'`
|
||||
2. `sourceType: 'published_profile'`
|
||||
|
||||
但主平台 `create` tab 现在仍主要展示 `myEntries`，没有把 `CustomWorldCreationHub.tsx` 作为主入口接上。
|
||||
|
||||
这导致：
|
||||
|
||||
1. works 聚合链存在
|
||||
2. create tab 真实消费的是另一条链
|
||||
3. Agent draft session 的继续创作入口没有真正收口到主平台
|
||||
|
||||
主要证据：
|
||||
|
||||
- `server-node/src/services/customWorldWorkSummaryService.ts`
|
||||
- `src/components/custom-world-home/CustomWorldCreationHub.tsx`
|
||||
- `src/components/game-shell/PlatformHomeView.tsx`
|
||||
|
||||
---
|
||||
|
||||
## 4. 数据断点
|
||||
|
||||
| 断点 | 当前现状 | 影响 | 主要证据 |
|
||||
| --- | --- | --- | --- |
|
||||
| Agent session -> runtime | `buildCustomWorldProfileFromAgentDraft()` 在前端把 `session.draftProfile` 编译成 legacy `CustomWorldProfile`，后续结果页、自动保存、进入世界都只认 profile | 后端不再是最终唯一真相源，前端承担了结构化编译与字段裁决，容易产生字段丢失、语义漂移、状态失真 | `src/components/game-shell/PreGameSelectionFlow.tsx`、`src/services/customWorldAgentDraftResult.ts` |
|
||||
| foundation draft 内部双重编译 | `CustomWorldAgentFoundationDraftService` 会先 `buildCompiledCustomWorldProfile(...)`，再 `convertRuntimeProfileToFoundationDraft(...)`，并把结果塞进 `legacyResultProfile` | Agent draft 不是原生生成，而是绕了一次 legacy profile，再回 draft；后续桥接层依赖这个字段继续工作 | `server-node/src/services/customWorldAgentFoundationDraftService.ts` |
|
||||
| 创作态元数据进入最终 profile | 前端桥接时会把 `anchorContent / creatorIntent / anchorPack / lockState` 一并塞进 legacy profile；同时固定写入 `generationMode: 'fast'`、`generationStatus: 'key_only'` | 创作态数据污染运行时 profile 存储；`generationMode / generationStatus` 还会覆盖真实阶段语义 | `src/services/customWorldAgentDraftResult.ts` |
|
||||
| Agent session 元数据在结果页后被截断 | `draftCards / pendingClarifications / suggestedActions / qualityFindings / checkpoints / operations` 大多停留在 session 层；结果页与 runtime 只继续消费 profile | 进入结果页后，Agent 会话层的大量结构化上下文被切断，发布门槛、锁定、局部重生成等信息无法自然继承 | `packages/shared/src/contracts/customWorldAgent.ts`、`server-node/src/services/customWorldAgentSessionStore.ts`、`src/components/custom-world-agent/CustomWorldAgentWorkspace.tsx` |
|
||||
| works 聚合 -> 平台 create tab | 后端 `listCustomWorldWorkSummaries(...)` 能返回 draft 与 published，但 create tab 仍只渲染 `myEntries` | Agent draft session 无法稳定出现在主入口“我的创作”里，恢复创作入口割裂 | `server-node/src/services/customWorldWorkSummaryService.ts`、`src/components/game-shell/PlatformHomeView.tsx` |
|
||||
| 发布状态 -> 可玩状态 | 结果页会自动 `upsertCustomWorldProfile()` 并允许直接 `onEnterWorld`；但 `publish_world` action 仍不可用 | “可玩”与“已发布”没有统一门槛，发布校验无法阻止未完成草稿进入世界 | `src/components/game-shell/PreGameSelectionFlow.tsx`、`server-node/src/services/customWorldAgentOrchestrator.ts` |
|
||||
|
||||
---
|
||||
|
||||
## 5. 多条 Pipeline
|
||||
|
||||
## 5.1 主链级 pipeline
|
||||
|
||||
| pipeline | 真相源 | 当前是否在主流程可达 | 问题 |
|
||||
| --- | --- | --- | --- |
|
||||
| Agent 会话草稿链 | `CustomWorldAgentSessionStore` + `draftProfile` | 是 | 后半段通过前端桥接成 legacy profile，未形成端到端单一真相源 |
|
||||
| 旧 custom-world session 链 | `CustomWorldSessionStore` | 是 | 与 Agent 八锚点链重复，且前端仍在补默认回答 |
|
||||
| 已保存 / 已发布 profile 链 | `custom-world-library` 中的 `CustomWorldProfile` | 是 | 与 Agent draft session 发布链平行存在 |
|
||||
| 结果页 legacy profile 直改链 | 结果页本地 `profile` | 是 | 绕过 Agent session，属于并行编辑器 |
|
||||
| works 创作中心链 | `listCustomWorldWorks()` 聚合数据 | 否，主平台未接主入口 | 后端已有聚合，但 UI 没真正切过去 |
|
||||
|
||||
## 5.2 资产子链 pipeline
|
||||
|
||||
资产相关还存在“自动补齐”和“人工工坊写回”并存：
|
||||
|
||||
1. `draft_foundation` 后，`CustomWorldAgentAutoAssetService` 会自动补角色主图和幕背景图。
|
||||
2. 角色资产又存在 `generate_role_assets -> sync_role_assets` 的手动工坊写回链。
|
||||
3. 场景资产在 contract 层定义了 `generate_scene_assets / sync_scene_assets`，但主 action 链未打通。
|
||||
|
||||
这导致当前资产链不是一条统一 pipeline，而是：
|
||||
|
||||
```text
|
||||
自动补角色 / 自动补幕背景
|
||||
并存
|
||||
手动角色工坊 -> sync_role_assets
|
||||
缺失
|
||||
手动场景工坊 -> sync_scene_assets
|
||||
```
|
||||
|
||||
主要证据：
|
||||
|
||||
- `server-node/src/services/customWorldAgentAutoAssetService.ts`
|
||||
- `server-node/src/services/customWorldAgentRoleAssetStateService.ts`
|
||||
- `packages/shared/src/contracts/customWorldAgent.ts`
|
||||
- `server-node/src/services/customWorldAgentOrchestrator.ts`
|
||||
|
||||
---
|
||||
|
||||
## 6. 冗余字段与主链悬空字段
|
||||
|
||||
这里区分两类：
|
||||
|
||||
1. 已经明显承担桥接残留职责的冗余字段
|
||||
2. 在 contract / session 里存在，但当前主流程几乎不消费的悬空字段
|
||||
|
||||
| 字段 | 类型 | 当前状态 | 判断 |
|
||||
| --- | --- | --- | --- |
|
||||
| `draftProfile.legacyResultProfile` | 桥接残留字段 | foundation draft 服务端先生成 legacy runtime profile，再把它塞回 draft，前端桥接又优先读它 | 明显冗余，属于临时兼容字段，不应长期成为主链依赖 |
|
||||
| `generationMode: 'fast'` | 固定写死字段 | `buildCustomWorldProfileFromAgentDraft()` 固定写入 | 不是草稿真实状态，更像桥接层补丁 |
|
||||
| `generationStatus: 'key_only'` | 固定写死字段 | `buildCustomWorldProfileFromAgentDraft()` 固定写入 | 同上，会掩盖真实生成阶段 |
|
||||
| `anchorContent / creatorIntent / anchorPack / lockState` 被直接塞进 legacy profile | 创作态元数据 | 会跟随自动保存一起写进作品库 profile，但 runtime 并不以这些字段为正式运行时输入 | 当前更像创作态元数据泄漏进运行时 profile |
|
||||
| `qualityFindings` | session / contract 字段 | contract、session store、测试里存在，但没形成生成、渲染、发布阻断闭环 | 当前主链悬空 |
|
||||
| `checkpoints` | session 字段 | session store 会记录，但主工作区和结果页没有真实展示入口 | 当前主链悬空 |
|
||||
| `suggestedActions` | session 字段 | session 会生成，但主工作区没有接 `QuickActions` 等面板 | 当前主链悬空 |
|
||||
| `pendingClarifications` | session 字段 | session 有数据，但澄清面板未接入主工作区 | 当前主链悬空 |
|
||||
| `operations` 历史 | session 字段 | 主工作区只展示当前 `activeOperation` 横幅，不展示完整历史 | 当前主链弱消费 |
|
||||
| `roleAssetSummaryLabel / cover* / counts` 等 works 字段 | works 聚合字段 | 后端能返回，但主平台 create tab 没走 `works` 入口 | 当前主链弱消费 |
|
||||
|
||||
---
|
||||
|
||||
## 7. 冗余功能与冗余组件
|
||||
|
||||
## 7.1 冗余功能
|
||||
|
||||
| 功能 | 当前状态 | 问题 |
|
||||
| --- | --- | --- |
|
||||
| 结果页直接生成 playable/story/landmark | `CustomWorldResultView.tsx` 仍可直接调用 AI 生成 | 与 Agent 对象精修链重复，且不会同步回 session |
|
||||
| 结果页直接编辑 `CustomWorldProfile` | `CustomWorldEntityEditorModal` 仍挂在结果页 | 把结果页继续维持成旧编辑器，而不是 Agent 流程的收口层 |
|
||||
| 旧 `custom-world/sessions` 世界生成 | `aiService.generateCustomWorldProfile()` 仍完整可用 | 与 Agent 八锚点世界创建重复 |
|
||||
| 作品库 `publish/unpublish` 与 Agent `publish_world` | 两套“发布”概念并行 | 一套作用于 library profile，一套想作用于 Agent session，但后者还未打通 |
|
||||
| 结果页自动保存 | `generatedCustomWorldProfile` 变化时自动 `upsertCustomWorldProfile()` | 让“草稿保存”“作品库存档”“正式发布”语义混在一起 |
|
||||
|
||||
## 7.2 冗余或未接线组件
|
||||
|
||||
`src/components/custom-world-agent/CustomWorldAgentWorkspace.tsx` 当前只真正接了：
|
||||
|
||||
1. `CustomWorldAgentHeader`
|
||||
2. `EightAnchorProgressBar`
|
||||
3. `CustomWorldAgentOperationBanner`
|
||||
4. `CustomWorldAgentThread`
|
||||
5. `CustomWorldAgentComposer`
|
||||
|
||||
但同目录下已经存在且主工作区未接线的组件包括：
|
||||
|
||||
1. `CustomWorldAgentLockBar.tsx`
|
||||
2. `CustomWorldAgentDraftDrawer.tsx`
|
||||
3. `CustomWorldAgentDraftDetailPanel.tsx`
|
||||
4. `CustomWorldAgentQuickActions.tsx`
|
||||
5. `CustomWorldAgentSummaryPanel.tsx`
|
||||
6. `CustomWorldAgentIntentSummaryPanel.tsx`
|
||||
7. `CustomWorldAgentClarificationPanel.tsx`
|
||||
8. `CustomWorldGenerateEntityModal.tsx`
|
||||
|
||||
另外，`src/components/custom-world-home/CustomWorldCreationHub.tsx` 也已存在，但平台 `create` tab 还没有把它接成主入口。
|
||||
|
||||
---
|
||||
|
||||
## 8. 当前没有真正实装到游戏主流程中的项
|
||||
|
||||
| 能力 | 设计 / 定义位置 | 当前状态 |
|
||||
| --- | --- | --- |
|
||||
| `publish_world` 真正发布链 | contract、PRD、route、orchestrator | route 能接，orchestrator 直接 `throw badRequest('publish_world is not available in phase5')` |
|
||||
| `generate_scene_assets` | contract、PRD | contract 定义了，但 action route 未接，主链无执行实现 |
|
||||
| `sync_scene_assets` | contract、PRD | contract 定义了，但 action route 未接，主链无执行实现 |
|
||||
| `expand_long_tail` | contract、PRD | contract 定义了，但主 action 链未接 |
|
||||
| `lock_cards / unlock_cards` | contract、PRD | contract 定义了，但 route / UI / orchestrator 主链未接 |
|
||||
| `regenerate_scope` | contract、PRD | contract 定义了，但 route / UI / orchestrator 主链未接 |
|
||||
| `qualityFindings` 与 blocker 发布门禁 | contract、PRD、技术进度文档 | 字段存在，但没有真实的生成、展示、阻止发布闭环 |
|
||||
| 场景资产工坊从 Agent workspace 打开并写回 | PRD | 主工作区未接详情面板与场景资产 action |
|
||||
| 通过 works 统一恢复 Agent draft / 已发布作品 | works service + creation hub | 后端已有聚合，主平台入口未收口 |
|
||||
| 发布前只允许预览、发布后再进入世界 | PRD | 当前 Agent 草稿结果页可自动保存并直接进入世界 |
|
||||
|
||||
补充说明：
|
||||
|
||||
`docs/technical/SCENE_MULTI_ACT_CREATOR_IMPLEMENTATION_PROGRESS_2026-04-20.md` 已明确写到，发布期 `qualityFindings / blocker` 正式接入仍未完成，这与当前代码状态一致。
|
||||
|
||||
---
|
||||
|
||||
## 9. 优先级建议
|
||||
|
||||
## P0：先收一条真正的单一主链
|
||||
|
||||
建议明确把下面这条定为唯一正式主链：
|
||||
|
||||
```text
|
||||
Agent session
|
||||
-> 服务端 draft snapshot
|
||||
-> 服务端质量检查 / 发布动作
|
||||
-> 服务端编译 final CustomWorldProfile
|
||||
-> 世界库
|
||||
-> runtime
|
||||
```
|
||||
|
||||
对应动作：
|
||||
|
||||
1. 结果页不再承担“主编辑器”职责，至少对 Agent draft 结果页关闭 legacy profile 直改能力。
|
||||
2. 用服务端 preview / compile 接口替代前端 `buildCustomWorldProfileFromAgentDraft()` 的最终裁决职责。
|
||||
3. `publish_world` 打通后，再决定是否允许“发布后立即进入世界”。
|
||||
|
||||
## P0：把“进入世界”和“发布世界”重新绑回同一门槛
|
||||
|
||||
建议收口为：
|
||||
|
||||
1. 未发布 Agent 草稿只能继续创作或查看预览。
|
||||
2. 只有 `publish_world` 成功后，才产出正式 `CustomWorldProfile` 并允许主入口进入世界。
|
||||
3. `qualityFindings / blocker` 必须在 foundation draft 完成、资产写回后、publish 前持续重跑。
|
||||
|
||||
## P1：决定旧 world session 流程的命运
|
||||
|
||||
当前最容易继续制造重复复杂度的是旧 `custom-world/sessions` 链。
|
||||
|
||||
建议二选一：
|
||||
|
||||
1. 明确保留为“快速世界生成兼容模式”，但从主入口降级。
|
||||
2. 明确进入淘汰路径，逐步下线 `generateCustomWorldProfile()` 这条旧链。
|
||||
|
||||
不建议继续让它和 Agent 八锚点链同时作为主入口长期并存。
|
||||
|
||||
## P1：把 works 创作中心接回主平台
|
||||
|
||||
建议：
|
||||
|
||||
1. 平台 `create` tab 改成消费 `listCustomWorldWorks()`。
|
||||
2. 草稿 session 通过“继续创作”恢复。
|
||||
3. 已发布 profile 通过“进入世界”或“查看详情”进入。
|
||||
4. `myEntries` 退回为作品库子集，而不是 create tab 的唯一数据源。
|
||||
|
||||
## P1：补齐 Agent workspace 的最小闭环
|
||||
|
||||
建议优先接上：
|
||||
|
||||
1. `CustomWorldAgentQuickActions`
|
||||
2. `CustomWorldAgentDraftDrawer`
|
||||
3. `CustomWorldAgentDraftDetailPanel`
|
||||
4. `CustomWorldAgentClarificationPanel`
|
||||
|
||||
如果这几个面板不接上，`suggestedActions / pendingClarifications / draftCards` 这些 session 字段会长期处于悬空状态。
|
||||
|
||||
## P2：等主链收口后再清桥接字段
|
||||
|
||||
下面这些字段不建议现在立刻删，但应在主链收口后尽快移除：
|
||||
|
||||
1. `draftProfile.legacyResultProfile`
|
||||
2. 前端桥接里固定写死的 `generationMode / generationStatus`
|
||||
3. 仅为兼容旧编辑器而塞进 legacy profile 的创作态元数据
|
||||
|
||||
---
|
||||
|
||||
## 10. 一句话总评
|
||||
|
||||
当前“Agent 聊天 -> 草稿生成 -> 进入世界”已经能跑通一条可玩链，但它还不是 PRD 要求的“后端单一真相源 + 发布门禁收口”的正式链路，而是 `Agent session`、`legacy profile`、`旧 session`、`作品库` 四层并存、靠前端桥接和结果页兼容能力临时拼起来的过渡态。
|
||||
@@ -17,7 +17,7 @@
|
||||
|
||||
结论不是“只有一套 prompt”，而是：
|
||||
|
||||
**当前角色资产链路至少有两层 prompt，且这两层在仓库里被不同文件承担。**
|
||||
**当前角色资产链路仍然有两层 prompt，但“默认描述文本”已经统一成单一主源。**
|
||||
|
||||
### 1.1 默认描述文本层
|
||||
|
||||
@@ -95,10 +95,6 @@
|
||||
|
||||
## 2.2 生成默认角色形象描述文本的提示词在哪
|
||||
|
||||
当前仓库需要分两种情况：
|
||||
|
||||
### 情况 A：当前自定义世界资产工坊真实主链
|
||||
|
||||
当前资产工坊默认输入框实际使用：
|
||||
|
||||
- `src/prompts/customWorldRolePromptDefaults.ts`
|
||||
@@ -110,34 +106,6 @@
|
||||
- `role.visualDescription`
|
||||
- 或回退到 `role.description`
|
||||
|
||||
### 情况 B：仓库里保留的“默认 bundle 编译接口”
|
||||
|
||||
仓库里仍保留一条后端接口：
|
||||
|
||||
- `/api/assets/character-prompts/generate`
|
||||
|
||||
对应文件：
|
||||
|
||||
- `server-node/src/prompts/characterAssetPrompts.ts`
|
||||
|
||||
这条链使用：
|
||||
|
||||
- `CHARACTER_PROMPT_BUNDLE_SYSTEM_PROMPT`
|
||||
- `buildCharacterPromptBundleUserPrompt`
|
||||
|
||||
它的职责是：
|
||||
|
||||
**让 LLM 从角色卡摘要里编译出一组默认文本 bundle。**
|
||||
|
||||
但当前实际问题是：
|
||||
|
||||
**自定义世界角色资产工坊初始化默认值，并没有走这条接口。**
|
||||
|
||||
因此当前状态更准确地说是：
|
||||
|
||||
- 仓库里有一条“LLM 编译默认文本 bundle”的保留链
|
||||
- 但当前资产工坊真实初始默认值主链，走的是前端本地映射
|
||||
|
||||
---
|
||||
|
||||
## 3. 角色动作生成链路
|
||||
@@ -181,17 +149,6 @@
|
||||
|
||||
这仍然是**默认描述文本层**，不是最终动作模型 prompt。
|
||||
|
||||
仓库里也保留了 LLM 编译 bundle 的接口链：
|
||||
|
||||
- `CHARACTER_PROMPT_BUNDLE_SYSTEM_PROMPT`
|
||||
- `buildCharacterPromptBundleUserPrompt`
|
||||
|
||||
这条链也会生成：
|
||||
|
||||
- `animationPromptText`
|
||||
|
||||
但当前资产工坊真实初始默认值并没有实际调用它。
|
||||
|
||||
---
|
||||
|
||||
## 4. `characterAssetPrompts.ts` 里的 `visualPromptText` / `animationPromptText` 到底是什么
|
||||
@@ -264,32 +221,30 @@
|
||||
|
||||
## 6. 冗余流程与当前问题
|
||||
|
||||
## 6.1 明确存在的冗余点：默认 bundle 双链并存
|
||||
## 6.1 默认描述文本双链已收口
|
||||
|
||||
当前仓库里“默认描述文本”其实有两套来源：
|
||||
此前默认描述文本同时存在：
|
||||
|
||||
### 第一套：前端本地字段映射
|
||||
1. 前端本地字段映射
|
||||
2. 后端 bundle 编译接口
|
||||
|
||||
本轮已经统一为：
|
||||
|
||||
- `src/prompts/customWorldRolePromptDefaults.ts`
|
||||
|
||||
### 第二套：后端 LLM bundle 编译接口
|
||||
也就是：
|
||||
|
||||
- `server-node/src/prompts/characterAssetPrompts.ts`
|
||||
- `/api/assets/character-prompts/generate`
|
||||
**默认描述文本现在只有一条真实主源。**
|
||||
|
||||
问题不在于“两套都存在”，而在于：
|
||||
对应变化：
|
||||
|
||||
**当前自定义世界资产工坊真实默认值只走第一套，第二套保留但没有进入当前主 UI 链。**
|
||||
|
||||
这意味着：
|
||||
|
||||
1. 从业务视角看，默认描述文本存在双份真相。
|
||||
2. 从维护视角看，两个地方都在描述 `visualPromptText / animationPromptText / scenePromptText` 的生成语义。
|
||||
3. 从测试视角看，后端 bundle 接口仍有测试，但 UI 主链没有使用它。
|
||||
1. 不再保留后端独立的默认 bundle 编译接口。
|
||||
2. 不再保留前端对应的 bundle 生成 API 壳层。
|
||||
3. `server-node/src/prompts/characterAssetPrompts.ts` 只保留正式模型 prompt builder。
|
||||
|
||||
判断：
|
||||
|
||||
**这是当前最明显的冗余流程。**
|
||||
**默认描述文本层的双份真相已经被消除。**
|
||||
|
||||
## 6.2 `scenePromptText` 结构存在，但当前资产工坊没有完整承接
|
||||
|
||||
@@ -338,13 +293,13 @@
|
||||
|
||||
因此它们不能算“无效代码”。
|
||||
|
||||
真正更接近“保留接口但未进入当前 UI 主链”的，是：
|
||||
真正已经被清理掉的保留链路，是此前未接入主 UI 的默认 bundle 接口：
|
||||
|
||||
- `CHARACTER_PROMPT_BUNDLE_SYSTEM_PROMPT`
|
||||
- `buildCharacterPromptBundleUserPrompt`
|
||||
- `/api/assets/character-prompts/generate`
|
||||
|
||||
这套链路仍有测试、仍可工作，但当前不属于自定义世界资产工坊的真实默认值主链。
|
||||
这套链路已经不再保留在当前仓库主线中。
|
||||
|
||||
---
|
||||
|
||||
@@ -352,11 +307,9 @@
|
||||
|
||||
如果后续要继续收口，建议按顺序处理：
|
||||
|
||||
1. 先明确“资产工坊默认值唯一主源”到底选前端本地映射还是后端 LLM bundle 接口。
|
||||
2. 如果继续保留前端本地映射为主链，则把后端 bundle 接口标注为备用 / 实验 / 非主链能力。
|
||||
3. 如果准备切回后端 bundle 接口为主链，则要把当前 UI 初始化逻辑真正接上，并补场景描述输入框闭环。
|
||||
4. 对 `scenePromptText` 做完整承接，不要继续停留在结构存在但 UI 不消费的状态。
|
||||
5. 继续保留 `packages/shared/src/prompts/qwenSprite.ts` 与工具链 prompt 分层，但在文档里强制写清“正式主链 / 工具链”边界。
|
||||
1. 继续以前端本地映射作为默认描述文本唯一主源。
|
||||
2. 对 `scenePromptText` 做完整承接，不要继续停留在结构存在但 UI 不消费的状态。
|
||||
3. 继续保留 `packages/shared/src/prompts/qwenSprite.ts` 与工具链 prompt 分层，但在文档里强制写清“正式主链 / 工具链”边界。
|
||||
|
||||
---
|
||||
|
||||
@@ -376,4 +329,4 @@
|
||||
|
||||
一句话总结就是：
|
||||
|
||||
**当前角色资产系统把“默认描述文本”和“正式模型 prompt”拆成了两层，这是合理的；真正的问题不是有两层，而是“默认描述文本层”现在同时保留了前端本地映射和后端 LLM 编译两条链，而当前 UI 主链只用了前者，导致出现明显的冗余和认知混乱。**
|
||||
**当前角色资产系统把“默认描述文本”和“正式模型 prompt”拆成了两层，这是合理的；默认描述文本层已经统一为前端本地映射单一主源，当前剩余主要问题不再是双主源，而是 `scenePromptText` 仍未形成完整 UI 闭环。**
|
||||
|
||||
@@ -15,6 +15,7 @@
|
||||
- [FUNCTION_RUNTIME_FULL_TEST_AUDIT_2026-04-16.md](./FUNCTION_RUNTIME_FULL_TEST_AUDIT_2026-04-16.md)：Function 运行时完整测试、服务端承接验证与当前门禁缺口。
|
||||
- [ITEM_AND_BUILD_PRD_AUDIT_2026-04-05.md](./ITEM_AND_BUILD_PRD_AUDIT_2026-04-05.md)：物品生成与 Build 标签系统对 PRD 的落地情况。
|
||||
- [CUSTOM_WORLD_CREATOR_TOOL_AUDIT_2026-04-08.md](./CUSTOM_WORLD_CREATOR_TOOL_AUDIT_2026-04-08.md)：自定义世界创作工具当前问题、体验断层和优化优先级审计。
|
||||
- [AGENT_TO_DRAFT_TO_WORLD_PIPELINE_AUDIT_2026-04-20.md](./AGENT_TO_DRAFT_TO_WORLD_PIPELINE_AUDIT_2026-04-20.md)：Agent 聊天、草稿生成、作品库存储与进入世界之间的断点、多 pipeline、冗余与未实装项审计。
|
||||
- [CHARACTER_ASSET_PROMPT_CHAIN_AUDIT_2026-04-20.md](./CHARACTER_ASSET_PROMPT_CHAIN_AUDIT_2026-04-20.md)：角色资产默认描述文本、正式图像/动作 prompt、共享模板与保留接口的分层与冗余审计。
|
||||
- [engineering/ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-20.md](./engineering/ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-20.md)：对 `2026-04-19` 工程清理审计的当前仓库复核，区分已完成项、仍存边界问题和新的热点迁移。
|
||||
- [engineering/ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-19.md](./engineering/ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-19.md)：未引用垃圾、旧入口残留、前后端双份真相与后端迁移项的专项审计。
|
||||
|
||||
@@ -0,0 +1,369 @@
|
||||
# 当前工程优化点盘点（2026-04-20）
|
||||
|
||||
更新时间：`2026-04-20`
|
||||
|
||||
## 0. 盘点目标
|
||||
|
||||
这份文档用于回答一个更直接的问题：
|
||||
|
||||
**基于当前仓库状态，接下来最值得投入工程时间的优化点是什么。**
|
||||
|
||||
本轮只做文档盘点，不直接修改业务代码；结论同时参考了当前工作区现状。
|
||||
需要注意，仓库当前存在一批未提交改动，尤其集中在 `custom world`、`assets`、`platform shell` 相关模块，所以本文更强调“优先级与切入方式”，而不是要求做大范围整仓改写。
|
||||
|
||||
---
|
||||
|
||||
## 1. 当前快照
|
||||
|
||||
## 1.1 本轮复核方式
|
||||
|
||||
本轮主要复核了以下内容：
|
||||
|
||||
1. 现有工程优化审计文档与目录索引
|
||||
2. `package.json`、`vite.config.ts`、`.eslintrc.cjs` 等门禁脚本
|
||||
3. 当前前端、后端、脚本目录的大文件热点
|
||||
4. 运行时、鉴权、自定义世界、资产链路的边界实现
|
||||
5. 当前 `typecheck / lint / build` 状态
|
||||
|
||||
---
|
||||
|
||||
## 1.2 当前门禁结果
|
||||
|
||||
| 项目 | 结果 | 当前判断 |
|
||||
| --- | --- | --- |
|
||||
| `npm run typecheck` | 失败 | 当前第一优先级问题，类型基线已失真 |
|
||||
| `npm run lint:eslint` | 失败 | `136` 个 error、`4` 个 warning，且 `95` 个可自动修复 |
|
||||
| `npm run build` | 通过 | 发布链路未红，但体积压力仍明显存在 |
|
||||
|
||||
### 关键说明
|
||||
|
||||
当前状态和 `2026-04-10` 那轮“build warning 直接拦截”的状态不同：
|
||||
|
||||
1. **构建现在可以通过。**
|
||||
2. **真正变成第一阻塞项的是 `typecheck` 与 `lint`。**
|
||||
3. **构建虽然通过，但主包、功能包、CSS 体积依然偏重，说明性能类优化仍然值得做。**
|
||||
|
||||
---
|
||||
|
||||
## 1.3 当前热点文件快照
|
||||
|
||||
本轮按源码目录统计的大文件热点如下：
|
||||
|
||||
| 文件 | 当前行数 | 判断 |
|
||||
| --- | --- | --- |
|
||||
| `src/components/CustomWorldEntityEditorModal.tsx` | `6122` | 当前前端最大热点 |
|
||||
| `server-node/src/app.test.ts` | `3568` | 后端测试聚合度过高 |
|
||||
| `server-node/src/modules/assets/characterAssetRoutes.ts` | `2802` | 资产路由职责过重 |
|
||||
| `src/services/ai.ts` | `2432` | 浏览器侧 AI 编排仍然偏重 |
|
||||
| `server-node/src/modules/story/storyActionRoutes.test.ts` | `2402` | 运行时路由测试聚合度过高 |
|
||||
| `src/data/npcInteractions.ts` | `2274` | NPC 规则数据仍然集中 |
|
||||
| `src/prompts/storyPromptBuilders.ts` | `1728` | prompt 构造成为新的复杂度中心 |
|
||||
| `server-node/src/modules/custom-world/runtimeProfile.ts` | `1623` | custom world runtime 编译热点 |
|
||||
| `src/hooks/story/npcEncounterActions.ts` | `1582` | NPC 行动流仍然偏重 |
|
||||
| `src/components/game-shell/PlatformHomeView.tsx` | `1474` | 平台首页壳层继续膨胀 |
|
||||
| `src/components/game-shell/PreGameSelectionFlow.tsx` | `1418` | 前置选择流程职责过多 |
|
||||
| `src/services/customWorld.ts` | `1383` | 自定义世界服务虽然收缩，但仍偏大 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 结论先行
|
||||
|
||||
当前仓库的优化重点，已经不是“继续清旧 Vite 插件链路”或者“继续讨论前后端是否要分离”。
|
||||
|
||||
更准确地说，当前最值得做的优化点已经收敛成四类：
|
||||
|
||||
1. **先恢复可信的工程基线。**
|
||||
`typecheck` 与 `lint` 当前都是红线，继续扩功能会放大返工成本。
|
||||
2. **拆掉正在持续膨胀的新热点。**
|
||||
热点已经从早期运行时主链，迁移到 `custom world`、`asset routes`、`platform shell`、`prompt builders`。
|
||||
3. **继续把前端退出“运行时真相”和“鉴权真相”。**
|
||||
当前前端仍保留本地快照镜像与自动登录凭证持久化。
|
||||
4. **补一轮入口归档，减少疑似孤岛模块和大测试聚合文件。**
|
||||
这部分不一定最急，但会持续拉低仓库可维护性。
|
||||
|
||||
一句话判断：
|
||||
|
||||
**当前最值得投入的不是横向加功能，而是把质量门禁重新拉绿，再把 custom world / asset / platform 这批新复杂度中心拆开。**
|
||||
|
||||
---
|
||||
|
||||
## 3. 优化点清单
|
||||
|
||||
## 3.1 P0：先恢复类型基线
|
||||
|
||||
这是当前最优先的工程优化点。
|
||||
|
||||
### 证据
|
||||
|
||||
`npm run typecheck` 当前失败，主要问题集中在两类：
|
||||
|
||||
1. `CustomWorldCampScene` 结构漂移
|
||||
- `src/components/CustomWorldEntityEditorModal.test.tsx`
|
||||
- `src/data/customWorldLibrary.ts`
|
||||
- `src/services/customWorld.ts`
|
||||
- `src/services/customWorldCamp.ts`
|
||||
2. 局部实现与类型定义不同步
|
||||
- `src/components/auth/AccountModal.test.tsx` 的测试数据缺少新增字段
|
||||
- `src/components/game-canvas/GameCanvasShared.tsx` 引用了未定义的 `DEFAULT_IMAGE_STYLE`
|
||||
|
||||
### 影响
|
||||
|
||||
1. 类型系统已经不能提供可信回归信号。
|
||||
2. 自定义世界链路当前正在迭代，如果继续在红线状态叠加修改，后续会反复出现“改 A 崩 B”的情况。
|
||||
3. 测试 fixture 与正式类型脱节，会让测试文件逐渐失去文档价值。
|
||||
|
||||
### 建议
|
||||
|
||||
1. 先补一个统一的 `CustomWorldCampScene` 构造/归一化入口，禁止在多个文件里手写不完整字面量。
|
||||
2. 把 `auth`、`custom world` 的测试 fixture 改成工厂函数，避免字段新增后多处漏改。
|
||||
3. 单独清掉 `GameCanvasShared.tsx` 这类“编译即失败”的确定性问题，优先恢复 `typecheck` 绿色基线。
|
||||
|
||||
---
|
||||
|
||||
## 3.2 P0：恢复 lint 可信度，区分机械问题和真实问题
|
||||
|
||||
这项和类型基线同级。
|
||||
|
||||
### 证据
|
||||
|
||||
`npm run lint:eslint` 当前结果是：
|
||||
|
||||
- `136` 个 error
|
||||
- `4` 个 warning
|
||||
- 其中 `95` 个问题可自动修复
|
||||
|
||||
当前 lint 问题明显分成两层：
|
||||
|
||||
1. 机械问题
|
||||
- import 排序
|
||||
- export 排序
|
||||
- 未使用导入
|
||||
2. 真实问题
|
||||
- `server-node/src/modules/inventory/inventoryStoryActionService.ts` 出现 React Hook 规则错误
|
||||
- `server-node/src/migrate.ts` 仍触发 `no-console`
|
||||
- `packages/shared/src/http.ts` 触发 `@typescript-eslint/ban-types`
|
||||
- 若干文件存在真正未使用变量、转义和规则误配问题
|
||||
|
||||
### 影响
|
||||
|
||||
1. 当前 lint 信号噪音仍然较高，不利于 review。
|
||||
2. 真实问题会被大量机械问题掩盖。
|
||||
3. 团队会更倾向于跳过 lint，而不是信任 lint。
|
||||
|
||||
### 建议
|
||||
|
||||
1. 先跑一轮仅机械修复的清理批次，优先吃掉 import sort、unused imports 这类低风险项。
|
||||
2. 再单独处理 Hook 误用、共享契约类型、脚本规则豁免这类语义问题。
|
||||
3. 之后把“自动可修复问题”与“必须人工处理的问题”拆成两个门禁视角，减少下次再次堆积。
|
||||
|
||||
---
|
||||
|
||||
## 3.3 P1：拆 custom world / asset / platform 新热点
|
||||
|
||||
这是当前最有性价比的结构性优化点。
|
||||
|
||||
### 证据
|
||||
|
||||
当前复杂度最高的业务热点，已经集中在这些模块：
|
||||
|
||||
1. `src/components/CustomWorldEntityEditorModal.tsx`
|
||||
2. `server-node/src/modules/assets/characterAssetRoutes.ts`
|
||||
3. `src/services/ai.ts`
|
||||
4. `src/prompts/storyPromptBuilders.ts`
|
||||
5. `server-node/src/modules/custom-world/runtimeProfile.ts`
|
||||
6. `src/components/game-shell/PlatformHomeView.tsx`
|
||||
7. `src/components/game-shell/PreGameSelectionFlow.tsx`
|
||||
8. `src/hooks/story/npcEncounterActions.ts`
|
||||
|
||||
### 问题本质
|
||||
|
||||
这些文件并不是单纯“代码多”，而是同时承载了多类职责：
|
||||
|
||||
1. UI 状态
|
||||
2. 领域规则
|
||||
3. 请求编排
|
||||
4. 文本构造
|
||||
5. 运行时映射
|
||||
6. 面板切换与流程控制
|
||||
|
||||
### 建议
|
||||
|
||||
1. `CustomWorldEntityEditorModal.tsx`
|
||||
- 先按“实体列表/表单区/资源区/高级设置/预览区”拆组件
|
||||
- 再把数据准备与提交编排抽成 hook
|
||||
2. `characterAssetRoutes.ts`
|
||||
- 拆成 route、prompt payload、job orchestration、产物发布、错误响应五层
|
||||
3. `PlatformHomeView.tsx` 与 `PreGameSelectionFlow.tsx`
|
||||
- 把页面壳层、数据加载、卡片渲染、弹层控制拆开
|
||||
4. `storyPromptBuilders.ts` 与 `runtimeProfile.ts`
|
||||
- 把“模板片段”“上下文归一化”“规则裁剪”“最终拼接”分层
|
||||
|
||||
---
|
||||
|
||||
## 3.4 P1：继续控制构建产物体积
|
||||
|
||||
构建虽通过，但体积已经给出明显信号。
|
||||
|
||||
### 当前证据
|
||||
|
||||
本轮 `npm run build` 输出里，几个值得关注的点是：
|
||||
|
||||
1. `dist/assets/AuthenticatedApp-*.js`：`794.77 kB`
|
||||
2. `dist/assets/index-*.js`：`197.44 kB`
|
||||
3. `dist/assets/CustomWorldResultView-*.js`：`163.38 kB`
|
||||
4. `dist/assets/ai-*.js`：`131.73 kB`
|
||||
5. `dist/assets/PreGameSelectionFlow-*.js`：`96.39 kB`
|
||||
6. `dist/assets/index-*.css`：`201.44 kB`
|
||||
|
||||
### 影响
|
||||
|
||||
1. 虽然还没触发新的 build gate 红线，但首屏、缓存和移动端体验会继续承压。
|
||||
2. `AuthenticatedApp` 主包偏大，说明平台壳层仍然装入了过多首屏不必需能力。
|
||||
3. CSS 体积继续上涨，说明样式正在跨模块相互堆叠。
|
||||
|
||||
### 建议
|
||||
|
||||
1. 继续把 custom world、asset studio、平台详情页、角色资产工具从主壳层路径中抽离。
|
||||
2. 审查 `ai.ts`、`custom world result view`、`pregame selection` 是否还能再延迟加载。
|
||||
3. 对全局样式做一次按模块归属清理，减少公共样式无限增长。
|
||||
|
||||
---
|
||||
|
||||
## 3.5 P1：继续收紧前端与后端边界
|
||||
|
||||
这项已经不是“要不要做”的问题，而是“还剩多少尾巴没收完”。
|
||||
|
||||
### 当前证据
|
||||
|
||||
1. `src/services/apiClient.ts`
|
||||
- 当前仍把 `access token`
|
||||
- 自动登录用户名
|
||||
- 自动登录密码
|
||||
写入 `window.localStorage`
|
||||
2. `src/hooks/story/runtimeStoryCoordinator.ts`
|
||||
- 当前仍会在调用后端运行时前先 `putSaveSnapshot(...)`
|
||||
- 响应后继续 `rehydrateSavedSnapshot(...)`
|
||||
3. `src/hooks/story/npcEncounterActions.ts`
|
||||
- 当前仍从前端动作流触发 `generateQuestForNpcEncounter(...)`
|
||||
- 说明 NPC 任务“换单/重抽”分支尚未完全后端化
|
||||
|
||||
### 影响
|
||||
|
||||
1. 前端仍保留了一部分运行时真相与鉴权真相。
|
||||
2. 自动登录凭证持久化在边界和安全上都不理想。
|
||||
3. 运行时快照前置写入，会让“前端镜像状态”和“后端会话状态”继续纠缠。
|
||||
|
||||
### 建议
|
||||
|
||||
1. 优先移除自动登录用户名/密码本地持久化，收敛到服务端 session / refresh 机制。
|
||||
2. 把运行时快照改为“展示缓存”而不是“提交前真相源”。
|
||||
3. 把 NPC 任务更换动作补齐到后端 runtime/session 边界，不再由前端直接发起生成决策。
|
||||
|
||||
---
|
||||
|
||||
## 3.6 P2：做一次疑似孤岛模块与旧入口归档
|
||||
|
||||
这项不一定最紧急，但现在做会明显降低后续维护噪音。
|
||||
|
||||
### 当前现象
|
||||
|
||||
从当前入口关系看，以下模块值得做一次正式复核：
|
||||
|
||||
1. `src/components/GameShell.tsx`
|
||||
2. `src/components/custom-world-home/CustomWorldCreationHub.tsx`
|
||||
3. `src/components/custom-world-home/CustomWorldCreationLauncherModal.tsx`
|
||||
4. `src/components/custom-world-agent/CustomWorldAgentLauncherModal.tsx`
|
||||
5. `src/components/custom-world-agent/CustomWorldAgentDraftDrawer.tsx`
|
||||
6. `src/hooks/story/storyBootstrap.ts`
|
||||
7. `src/hooks/useEquipmentFlow.ts`
|
||||
8. `src/hooks/useForgeFlow.ts`
|
||||
9. `src/hooks/useInventoryFlow.ts`
|
||||
10. `src/services/typewriter.ts`
|
||||
|
||||
### 当前判断
|
||||
|
||||
这批模块不一定全部是垃圾代码，但至少说明一件事：
|
||||
|
||||
**仓库里仍然存在一批“不是正式入口、也没有清晰归档标签”的过渡实现。**
|
||||
|
||||
### 建议
|
||||
|
||||
把这类模块统一分成三类：
|
||||
|
||||
1. 正式保留并接回入口
|
||||
2. 明确标记为实验稿
|
||||
3. 直接归档或删除
|
||||
|
||||
这样可以减少后续开发时的误判成本。
|
||||
|
||||
---
|
||||
|
||||
## 3.7 P2：拆测试聚合文件，恢复测试的定位能力
|
||||
|
||||
当前测试文件也已经出现“大一统热点”。
|
||||
|
||||
### 证据
|
||||
|
||||
1. `server-node/src/app.test.ts`：`3568` 行
|
||||
2. `server-node/src/modules/story/storyActionRoutes.test.ts`：`2402` 行
|
||||
3. `server-node/src/modules/assets/characterAssetRoutes.test.ts`：`1235` 行
|
||||
4. `src/hooks/story/npcEncounterActions.test.ts`：`1199` 行
|
||||
|
||||
### 影响
|
||||
|
||||
1. 失败定位成本高。
|
||||
2. fixture 复用差，字段一变容易整片测试跟着漂移。
|
||||
3. 测试文件本身开始变成新的维护热点。
|
||||
|
||||
### 建议
|
||||
|
||||
1. 按领域动作拆测试文件，而不是继续堆到单一总测文件中。
|
||||
2. 补 fixture builder / factory，减少字面量散落。
|
||||
3. 对 `runtime / auth / custom world / assets` 这几条链路增加更明确的契约测试分层。
|
||||
|
||||
---
|
||||
|
||||
## 4. 推荐执行顺序
|
||||
|
||||
如果只按工程收益排序，建议按下面的顺序推进：
|
||||
|
||||
1. 先修 `typecheck`
|
||||
2. 再把 `lint` 分成机械修复和语义修复两轮
|
||||
3. 然后拆 `custom world / asset / platform` 热点
|
||||
4. 再继续收前端运行时与鉴权边界
|
||||
5. 最后处理孤岛模块归档和测试拆分
|
||||
|
||||
---
|
||||
|
||||
## 5. 当前不建议优先做的事
|
||||
|
||||
1. 不建议在 `typecheck` 和 `lint` 仍为红线时继续横向扩功能。
|
||||
2. 不建议直接在 `CustomWorldEntityEditorModal.tsx`、`characterAssetRoutes.ts`、`PlatformHomeView.tsx` 里继续堆新逻辑。
|
||||
3. 不建议把 bundle 体积问题简单理解为“先放宽阈值”，当前更适合继续拆职责和延迟加载。
|
||||
4. 不建议在未确认入口关系前随手删除可疑旧模块，先做归档分类更稳。
|
||||
|
||||
---
|
||||
|
||||
## 6. 本文依据
|
||||
|
||||
文档依据：
|
||||
|
||||
1. `docs/audits/engineering/README.md`
|
||||
2. `docs/audits/engineering/CURRENT_ENGINEERING_OPTIMIZATION_PRIORITIES_2026-04-10.md`
|
||||
3. `docs/audits/engineering/ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-20.md`
|
||||
4. `docs/experience/PROJECT_WORK_EXPERIENCE_PLAYBOOK.md`
|
||||
|
||||
当前仓库复核依据：
|
||||
|
||||
1. `package.json`
|
||||
2. `.eslintrc.cjs`
|
||||
3. `vite.config.ts`
|
||||
4. `scripts/build-gate.mjs`
|
||||
5. `src/App.tsx`
|
||||
6. `src/services/apiClient.ts`
|
||||
7. `src/hooks/story/runtimeStoryCoordinator.ts`
|
||||
8. `src/hooks/story/npcEncounterActions.ts`
|
||||
9. 当前源码大文件体量扫描结果
|
||||
10. `npm run typecheck`
|
||||
11. `npm run lint:eslint`
|
||||
12. `npm run build`
|
||||
@@ -4,25 +4,29 @@
|
||||
|
||||
## 当前推荐入口
|
||||
|
||||
1. [ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-20.md](./ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-20.md)
|
||||
1. [CURRENT_ENGINEERING_OPTIMIZATION_OPPORTUNITIES_2026-04-20.md](./CURRENT_ENGINEERING_OPTIMIZATION_OPPORTUNITIES_2026-04-20.md)
|
||||
这一版是面向当前仓库状态的优化点盘点，适合直接拿来排优先级和拆执行批次。
|
||||
2. [ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-20.md](./ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-20.md)
|
||||
这一版是对 `2026-04-19` 基线的当前仓库复核，明确哪些问题已经处理、哪些表述需要纠正、热点又迁移到了哪里。
|
||||
2. [ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-19.md](./ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-19.md)
|
||||
3. [ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-19.md](./ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-19.md)
|
||||
这一版保留原始问题快照和执行回填，适合回看“为什么会有这轮清理与边界收口”。
|
||||
3. [ENGINEERING_OPTIMIZATION_REVIEW_2026-04-01.md](./ENGINEERING_OPTIMIZATION_REVIEW_2026-04-01.md)
|
||||
4. [ENGINEERING_OPTIMIZATION_REVIEW_2026-04-01.md](./ENGINEERING_OPTIMIZATION_REVIEW_2026-04-01.md)
|
||||
这一版最适合作为当前工程基线，重点从“是否真正绿色”“门禁有没有覆盖真实风险”来判断仓库状态。
|
||||
4. [ENGINEERING_OPTIMIZATION_REVIEW_2026-03-30.md](./ENGINEERING_OPTIMIZATION_REVIEW_2026-03-30.md)
|
||||
5. [ENGINEERING_OPTIMIZATION_REVIEW_2026-03-30.md](./ENGINEERING_OPTIMIZATION_REVIEW_2026-03-30.md)
|
||||
适合回看运行时主链路、Story/Combat 边界、分层过渡期问题。
|
||||
5. [ENGINEERING_OPTIMIZATION_REVIEW_2026-03-29.md](./ENGINEERING_OPTIMIZATION_REVIEW_2026-03-29.md)
|
||||
6. [ENGINEERING_OPTIMIZATION_REVIEW_2026-03-29.md](./ENGINEERING_OPTIMIZATION_REVIEW_2026-03-29.md)
|
||||
适合看第一轮系统性工程扫描，了解最早的问题基线。
|
||||
|
||||
## 融合结论
|
||||
|
||||
- 当前仓库已经完成“旧 dev 插件链路删除、根目录噪音清理、`server-node -> src/**` 反向依赖切断”这批第一阶段任务。
|
||||
- 当前如果想直接判断“今天先优化什么”，优先看 `CURRENT_ENGINEERING_OPTIMIZATION_OPPORTUNITIES_2026-04-20.md`。
|
||||
- 当前的新重点已经进一步收敛到三类：未接线孤岛模块、前端残留的运行时/鉴权真相、热点向 prompt/runtime profile/平台入口壳层迁移。
|
||||
- 三轮结论是一致收敛的：问题不在“有没有开始工程化”，而在“工程化是否真正覆盖了最危险的主链路”。
|
||||
- 最新一轮已经把关注点集中到质量门禁、真实绿色基线、关键模块豁免和 build warning 上。
|
||||
- `2026-04-19` 这一轮把问题压实到了四类：仓库噪音、旧 dev 入口残留、前端越界运行时逻辑、巨型热点文件。
|
||||
- `2026-04-20` 这一轮进一步确认：前两类已经阶段性完成，当前真正剩下的是边界尾巴和新热点迁移。
|
||||
- 如果只是为了判断现在先做什么，直接从 `2026-04-01` 开始即可。
|
||||
- 如果是要看当前清理和边界收口的最新状态，优先看 `2026-04-20`。
|
||||
- 如果是要看当前清理和边界收口的最新状态，优先看 `ENGINEERING_CLEANUP_AND_BACKEND_BOUNDARY_AUDIT_2026-04-20.md`。
|
||||
- 如果是要看“当前可执行的优化点清单”，优先看 `CURRENT_ENGINEERING_OPTIMIZATION_OPPORTUNITIES_2026-04-20.md`。
|
||||
- 如果是要做长期重构方案，再按 `2026-03-29 -> 2026-03-30 -> 2026-04-01 -> 2026-04-19 -> 2026-04-20` 的顺序回看演进。
|
||||
|
||||
@@ -141,6 +141,25 @@
|
||||
- 后续如果继续调整平台主 Tab 视觉，优先改 `src/index.css` 的平台主题 token 和 remap 规则；只有 token 无法表达时，再做局部组件样式补丁，避免亮色主题再次出现“页面整体是亮的，但局部卡片仍是暗的”。
|
||||
- 参考图方向已明确：平台亮色主题应以白色为主底色，粉红只承担背景气氛和重点 CTA，不应让整页主壳继续像深粉底板。
|
||||
- 移动端底部 `platform-bottom-nav` 的 Tab 激活态必须与默认态使用同一套盒模型；边框要预占位，不能在 onPress / active 时临时增加边框导致按钮尺寸和留白跳变。
|
||||
- 2026-04-20 第二轮细查补色时，继续把 `PlatformWorldDetailView.tsx`、`PlatformHomeView.tsx`、`PreGameSelectionFlow.tsx` 里落在白底/浅底面板上的标题、说明、次级标签、搜索栏和加载兜底文本显式切回平台亮色 token，避免亮色主题下继续出现浅底白字或过浅灰字。
|
||||
- 2026-04-20 第三轮修正方向后，平台首页移动端底部 `platform-bottom-nav` 的高度、内边距、按钮圆角、图标尺寸、标签字号统一收口到 `src/index.css` token；`PlatformHomeView.tsx` 只保留结构类，避免 `h-14`、容器 padding、按钮内部内容间距和 active 底座各自维护半套尺寸，导致选中态看起来比 Tab 槽位更矮或更高。
|
||||
- 2026-04-20 第四轮把平台亮色主题顶部过重的红色收轻：`--platform-body-fill`、`--platform-hero-fill`、`--platform-shell-glow-*` 与 `--platform-surface-glow-*` 改成更接近暖白 + 浅珊瑚的低饱和版本，首页 / 创作页 / 详情页 Hero 覆层统一改走 `--platform-hero-overlay-strong`，避免组件里继续写死高饱和粉红渐变。
|
||||
|
||||
---
|
||||
|
||||
## 11. 2026-04-20 创作 Agent 聊天工作台亮色主题补色
|
||||
|
||||
- `src/components/custom-world-agent/*` 这一条创作 Agent 工作台链路已统一切回 `platform-subpanel`、`platform-input`、`platform-button`、`platform-banner`、`platform-progress-track`，亮色主题下不再继续裸露 `bg-[#111318]`、`bg-black/*`、`bg-white/*`、`text-white` 这类历史深色残留。
|
||||
- 聊天线程中的用户气泡、助手气泡、系统消息、推荐回复按钮、流式回复态统一映射到平台 token；后续如果继续调整创作 Agent 聊天视觉，优先改平台 token 或平台 class，不要在组件里再单独写一套聊天色板。
|
||||
- 顶栏、操作横幅、进度条、输入框的状态色统一复用平台亮暗主题变量，避免再次出现“页面整体已切亮色，但 Agent 局部还是旧暗色弹层”的割裂感。
|
||||
|
||||
---
|
||||
|
||||
## 12. 2026-04-20 NPC 聊天退出恢复与文本阅读性修正
|
||||
|
||||
- `AdventurePanel.tsx` 的叙事 `storyText` 已取消斜体，改为更大的正文尺寸，避免长段阅读时发飘。
|
||||
- 冒险面板里的 `actionText` 统一上调到聊天态同级字号；`detailText` 不再默认渲染，保持底部选项区更清爽。
|
||||
- `npcEncounterActions.ts` 在“退出聊天”后重新续写剧情时，会优先把当前故事里最近一轮已经呈现给玩家的非聊天选项文案并回 `optionCatalog`，避免高好感聊天收束后又退回 NPC 静态 fallback 文案。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,388 @@
|
||||
# 当前 Agent 创作流程优化执行规划（大白话版）
|
||||
|
||||
更新时间：`2026-04-20`
|
||||
|
||||
## 先把话说死
|
||||
|
||||
这轮不再加新流程。
|
||||
|
||||
不再新增一套创作动线。
|
||||
不再为了“更完整”继续把 PRD 里没落完的所有阶段、面板、动作全补出来。
|
||||
不再把前端创作工具改成另一套长得不一样的新系统。
|
||||
|
||||
这轮只做一件事：
|
||||
|
||||
**把现在这条你已经满意的前端创作流程，收紧、理顺、删重、补通，让它从“能跑”变成“稳、顺、好维护、不会自己打自己”。**
|
||||
|
||||
这份规划就是基于 [AGENT_TO_DRAFT_TO_WORLD_PIPELINE_AUDIT_2026-04-20.md](../audits/AGENT_TO_DRAFT_TO_WORLD_PIPELINE_AUDIT_2026-04-20.md) 里已经确认的问题，重新收束出来的一版执行方案。
|
||||
|
||||
---
|
||||
|
||||
## 1. 现在最大的问题，用大白话讲是什么
|
||||
|
||||
不是界面丑。
|
||||
不是步骤不够多。
|
||||
不是入口不够花。
|
||||
|
||||
而是现在这条链里，很多地方在“一个流程里混着好几套脑子”。
|
||||
|
||||
具体就是：
|
||||
|
||||
1. 用户明明在走 Agent 创作，但走到一半，很多关键数据又偷偷变成了 old profile 流程在接手。
|
||||
2. 明明已经有 Agent session 这条主线，但结果页、作品库、旧生成接口、旧编辑器能力还都在同时干活。
|
||||
3. 明明有“发布世界”这个概念，但现在实际上“不发布也能直接进入世界”。
|
||||
4. 明明有一些 session 内的数据，比如建议动作、草稿卡、澄清项、质量检查，结果走到结果页之后就像断电了一样，后面没人接着用。
|
||||
5. 明明有些功能已经决定这轮不做，但代码里和文档里还留着很多“半做不做”的说法，会持续误导后续开发。
|
||||
|
||||
所以这轮优化的目标不是“让系统更大”，而是：
|
||||
|
||||
**让整条现有流程只认一条主线，别再一会儿 Agent、一会儿 legacy、一会儿旧 session、一会儿作品库各管各的。**
|
||||
|
||||
---
|
||||
|
||||
## 2. 这轮优化后的目标状态
|
||||
|
||||
我们要收敛到下面这个状态：
|
||||
|
||||
```text
|
||||
用户进入 Agent 创作
|
||||
-> 在现有工作区里聊天和生成草稿
|
||||
-> 草稿整理完成后进入现有结果页
|
||||
-> 结果页只做预览、少量必要确认、进入世界
|
||||
-> 进入世界时走一条明确、统一、可解释的数据链
|
||||
-> 平台“我的创作”能稳定找回这份草稿或这份作品
|
||||
```
|
||||
|
||||
注意，这里有两个关键词：
|
||||
|
||||
1. **还是现有动线**
|
||||
2. **但背后的数据链要统一**
|
||||
|
||||
也就是说：
|
||||
|
||||
前端看上去可以几乎不换流程。
|
||||
但后面谁是真相源、谁负责编译、谁负责保存、谁负责恢复、哪些能力要删掉，必须彻底讲清楚。
|
||||
|
||||
---
|
||||
|
||||
## 3. 这轮不做什么
|
||||
|
||||
为了避免后面又做散，先把“不做什么”写清楚。
|
||||
|
||||
### 3.1 不新增新的大流程
|
||||
|
||||
不做这些：
|
||||
|
||||
1. 不再新增“另一个 Agent 创作工作台”
|
||||
2. 不再新增“另一套草稿结果页”
|
||||
3. 不再新增“另一条作品发布流程”
|
||||
4. 不再新增“另一套创作中心入口”
|
||||
|
||||
### 3.2 不为了补 PRD 而硬补所有未完成能力
|
||||
|
||||
不做这些：
|
||||
|
||||
1. 不把所有 `lock / unlock / regenerate_scope / expand_long_tail / scene asset pipeline` 一次性全打完
|
||||
2. 不为了“文档里写过”就把所有没接线面板都接进来
|
||||
3. 不把当前工作区重新改造成一个更复杂的大后台
|
||||
|
||||
### 3.3 不把结果页继续当旧编辑器扩写
|
||||
|
||||
这轮明确不再鼓励：
|
||||
|
||||
1. 在结果页继续加更多直接生成角色 / 地点的按钮
|
||||
2. 在结果页继续加更多直接改 legacy profile 的编辑能力
|
||||
3. 让结果页承担越来越重的“补世界”职责
|
||||
|
||||
一句话：
|
||||
|
||||
**结果页要收口，不要继续发散。**
|
||||
|
||||
---
|
||||
|
||||
## 4. 接下来真正要做的 5 件事
|
||||
|
||||
## 4.1 第一件事：先定一条唯一主链，别再多套数据同时接力
|
||||
|
||||
这是第一优先级，也是最重要的一件事。
|
||||
|
||||
现在的问题不是“没东西可用”，而是“能用的东西太多了，而且互相抢活”。
|
||||
|
||||
接下来要明确：
|
||||
|
||||
1. 当前 Agent 创作流程里，`Agent session` 才是草稿阶段的真相源。
|
||||
2. 结果页只是这份草稿的展示和收口，不应该变成另一套独立编辑器。
|
||||
3. 进入世界时，只能走一条明确的编译出口，不能这里转一次、那里改一次、最后谁改得晚听谁的。
|
||||
|
||||
用大白话讲，就是：
|
||||
|
||||
**从聊天开始到点“进入世界”为止，中间只能有一条主水管。**
|
||||
|
||||
不能再出现：
|
||||
|
||||
1. Agent session 里一份数据
|
||||
2. 前端桥接后又一份 profile
|
||||
3. 结果页本地改完又一份 profile
|
||||
4. 自动保存到作品库后再来一份 profile
|
||||
|
||||
这样下去，后面谁出 bug 都说不清到底是哪一层改坏的。
|
||||
|
||||
所以这一阶段的目标不是改 UI，而是先把话语权统一：
|
||||
|
||||
1. 草稿阶段谁说了算
|
||||
2. 进入世界前谁负责最终编译
|
||||
3. 作品库里保存的到底是“正式世界”还是“当前草稿快照”
|
||||
|
||||
这件事不解决，后面所有优化都会继续打架。
|
||||
|
||||
---
|
||||
|
||||
## 4.2 第二件事：把结果页收口，只保留当前流程真正需要的事
|
||||
|
||||
现在结果页的问题很简单：
|
||||
|
||||
它干的活太多了。
|
||||
|
||||
它现在既像：
|
||||
|
||||
1. 草稿预览页
|
||||
2. 旧自定义世界编辑器
|
||||
3. AI 补角色/补地点的入口
|
||||
4. 自动保存中转页
|
||||
5. 进入世界前的最后一跳
|
||||
|
||||
这就是为什么它会越来越乱。
|
||||
|
||||
这轮要做的不是重做结果页，而是收口结果页。
|
||||
|
||||
收口方向很明确：
|
||||
|
||||
1. 结果页继续保留现在你满意的浏览和进入世界体验
|
||||
2. 但要逐步去掉“它自己偷偷改世界结构”的能力
|
||||
3. 让它更像“当前草稿的总览页”，而不是“另一套世界编辑器”
|
||||
|
||||
用大白话讲：
|
||||
|
||||
**结果页负责看，不负责偷偷再造一遍世界。**
|
||||
|
||||
所以这里建议后续逐步处理：
|
||||
|
||||
1. 把结果页里那些直接生成 playable/story/landmark 的旧能力下掉
|
||||
2. 把直接改 legacy profile 的重编辑能力从结果页移走或收紧
|
||||
3. 让“去 Agent 调整设定”真的是回主流程调，而不是结果页自己补完半套流程
|
||||
|
||||
这一步做完的好处很直接：
|
||||
|
||||
1. 结果页职责会清楚很多
|
||||
2. 进入世界前的状态会更稳定
|
||||
3. 不会再出现“用户以为还在 Agent 流里，实际上已经走到 legacy 编辑器里了”
|
||||
|
||||
---
|
||||
|
||||
## 4.3 第三件事：平台入口统一，不让草稿恢复和作品查看继续割裂
|
||||
|
||||
现在还有一个体验问题不是流程长短的问题，而是入口不统一。
|
||||
|
||||
简单说就是：
|
||||
|
||||
1. 后端已经能区分“草稿”和“已发布作品”
|
||||
2. 但平台页里“我的创作”主要还在看 `myEntries`
|
||||
3. Agent 草稿并不能自然地稳定出现在同一个主入口里
|
||||
|
||||
这会带来两个问题：
|
||||
|
||||
1. 用户做了一半的草稿，不容易稳定找回来
|
||||
2. 系统里其实已经有创作中心能力，但主入口没认它
|
||||
|
||||
所以接下来要做的不是新做一个创作中心，而是：
|
||||
|
||||
**把已经存在的聚合能力真正接回现在的平台入口。**
|
||||
|
||||
用户看到的应该是：
|
||||
|
||||
1. 还没进世界的草稿，可以继续创作
|
||||
2. 已经成型的作品，可以查看或进入世界
|
||||
|
||||
而不是：
|
||||
|
||||
1. 草稿在一套地方
|
||||
2. 已保存作品在另一套地方
|
||||
3. 恢复创作还得靠 sessionId 或隐藏状态兜底
|
||||
|
||||
这一步的核心价值不是“新功能”，而是“东西别丢、入口别分裂、用户心智别断”。
|
||||
|
||||
---
|
||||
|
||||
## 4.4 第四件事：删掉重复 pipeline，不再同时养两三套创作生成链
|
||||
|
||||
这一步很关键，而且一定要明确态度：
|
||||
|
||||
**既然你已经决定当前前端创作流程满意，那就不能继续默认保留那么多并行旧链。**
|
||||
|
||||
现在最典型的重复链有：
|
||||
|
||||
1. Agent 创作链
|
||||
2. 旧 `custom-world/sessions` 世界生成链
|
||||
3. 结果页 legacy profile 直改链
|
||||
|
||||
它们的共同问题是：
|
||||
|
||||
1. 都能生成世界
|
||||
2. 都能改世界
|
||||
3. 但不是同一套状态模型
|
||||
4. 后期维护会越来越痛苦
|
||||
|
||||
所以这一步不是说要立刻把所有旧东西物理删除，而是要明确分层：
|
||||
|
||||
1. 哪条是当前正式主链
|
||||
2. 哪条是兼容链
|
||||
3. 哪条只是暂时留着，但不能再往上继续加功能
|
||||
|
||||
用大白话讲，就是：
|
||||
|
||||
**该扶正的扶正，该降级的降级，该冻结的冻结。**
|
||||
|
||||
尤其是旧 `custom-world/sessions` 这条链，如果还要保留，也只能是兼容入口，不能再和 Agent 主链平起平坐。
|
||||
|
||||
---
|
||||
|
||||
## 4.5 第五件事：把文稿里那些“这轮不做”的未完成项从主叙事里移掉
|
||||
|
||||
这是你这次特别强调的点，我完全同意，而且它很重要。
|
||||
|
||||
现在很多文稿的问题不是“写错了”，而是：
|
||||
|
||||
1. 写了很多理论上该有的能力
|
||||
2. 但当前版本并不准备继续往那个方向扩
|
||||
3. 结果文档会不断把团队拉回“是不是还要把这些补完”的思路里
|
||||
|
||||
这会直接制造两种问题：
|
||||
|
||||
1. 开发判断会飘
|
||||
2. 后续审计会永远得到“未完成项很多”的结论
|
||||
|
||||
所以这轮文档治理要做的，不是把文稿全删空，而是分清三类内容：
|
||||
|
||||
1. **当前版本要继续优化的**
|
||||
2. **当前版本明确不做、先冻结的**
|
||||
3. **未来可以再看，但这轮不纳入执行规划的**
|
||||
|
||||
用大白话讲：
|
||||
|
||||
**文档也要学会闭嘴。**
|
||||
|
||||
不是所有想过的东西，都要继续挂在当前版本的主任务里。
|
||||
|
||||
---
|
||||
|
||||
## 5. 推荐执行顺序
|
||||
|
||||
这轮建议按下面顺序推进，不建议乱穿插。
|
||||
|
||||
## 第一阶段：先收主链
|
||||
|
||||
先做：
|
||||
|
||||
1. 定义当前正式主链
|
||||
2. 明确 Agent session、结果页、作品库、进入世界之间谁负责什么
|
||||
3. 停止继续增强结果页里的 legacy 编辑能力
|
||||
|
||||
这一阶段的目标是：
|
||||
|
||||
**先让水管只有一根。**
|
||||
|
||||
## 第二阶段：再收结果页和平台入口
|
||||
|
||||
再做：
|
||||
|
||||
1. 结果页职责收口
|
||||
2. 平台“我的创作”入口统一
|
||||
3. 草稿恢复和作品查看走同一套入口认知
|
||||
|
||||
这一阶段的目标是：
|
||||
|
||||
**让用户走起来更顺，让系统找回内容更稳定。**
|
||||
|
||||
## 第三阶段：再处理旧 pipeline 的降级和冻结
|
||||
|
||||
再做：
|
||||
|
||||
1. 旧 `custom-world/sessions` 链降级
|
||||
2. 结果页直改 profile 的旧能力收紧
|
||||
3. 兼容链保留边界写清楚
|
||||
|
||||
这一阶段的目标是：
|
||||
|
||||
**减少系统自己和自己打架。**
|
||||
|
||||
## 第四阶段：最后做文档清理
|
||||
|
||||
最后做：
|
||||
|
||||
1. 把当前版本不再追的未完成项，从主规划文稿里移出去
|
||||
2. 把“未来也许做”从“这轮要做”里拆开
|
||||
3. 让所有当前规划只服务当前版本
|
||||
|
||||
这一阶段的目标是：
|
||||
|
||||
**让接下来所有开发都围绕同一套现实目标执行。**
|
||||
|
||||
---
|
||||
|
||||
## 6. 每个阶段做完以后，应该看到什么效果
|
||||
|
||||
## 阶段一做完
|
||||
|
||||
应该看到：
|
||||
|
||||
1. 代码里谁是主链一眼能看明白
|
||||
2. 不会再出现一会儿 Agent、一会儿 legacy profile 接管全局的情况
|
||||
3. 进入世界时的数据来源更清楚
|
||||
|
||||
## 阶段二做完
|
||||
|
||||
应该看到：
|
||||
|
||||
1. 结果页更干净
|
||||
2. 平台页更容易找回自己的创作
|
||||
3. 用户对“草稿”“作品”“进入世界”这三个概念不会混
|
||||
|
||||
## 阶段三做完
|
||||
|
||||
应该看到：
|
||||
|
||||
1. 重复 pipeline 明显减少
|
||||
2. 旧链不再继续吞主流程职责
|
||||
3. 后续开发不会再不知道该往哪条链上接
|
||||
|
||||
## 阶段四做完
|
||||
|
||||
应该看到：
|
||||
|
||||
1. 文档和代码目标一致
|
||||
2. 团队不会再被一堆“理论上应该补”的项拉偏
|
||||
3. 后续迭代能真正围绕“优化已有流程”推进
|
||||
|
||||
---
|
||||
|
||||
## 7. 这轮最重要的判断标准
|
||||
|
||||
这轮不是看我们补了多少功能。
|
||||
|
||||
这轮的判断标准应该是下面 5 条：
|
||||
|
||||
1. 用户现在这条创作流程有没有被打断
|
||||
2. 同一个世界的数据是不是只走一条清楚的主链
|
||||
3. 结果页是不是还在偷偷承担旧编辑器职责
|
||||
4. 平台入口能不能稳定找回草稿和作品
|
||||
5. 文档是不是已经不再推动大家去补这轮明确不做的东西
|
||||
|
||||
如果这 5 条做好了，就说明这轮方向是对的。
|
||||
|
||||
---
|
||||
|
||||
## 8. 一句话总结
|
||||
|
||||
接下来的优化，不是再发明一套更复杂的创作流程，而是把当前你已经满意的这条前端动线背后的数据链、入口、职责和文档全部收紧到同一个方向上：
|
||||
|
||||
**少一点并行、少一点桥接、少一点重复、少一点“半做半留”，把现有流程真正打磨成一条稳定主链。**
|
||||
@@ -3,6 +3,7 @@
|
||||
## 当前入口
|
||||
|
||||
- [CURRENT_GAME_ITERATION_PRIORITIES_2026-04-03.md](./CURRENT_GAME_ITERATION_PRIORITIES_2026-04-03.md)：当前阶段最值得优先做什么、为什么，以及它和审计/PRD 的对应关系。
|
||||
- [CURRENT_AGENT_CREATION_FLOW_OPTIMIZATION_PLAN_2026-04-20.md](./CURRENT_AGENT_CREATION_FLOW_OPTIMIZATION_PLAN_2026-04-20.md)：在不新增前端创作流程的前提下，围绕当前 Agent 创作动线做收口、删重、补通和文档收束的大白话执行规划。
|
||||
- [EXPRESS_BACKEND_REFACTOR_PLAN_2026-04-08.md](./EXPRESS_BACKEND_REFACTOR_PLAN_2026-04-08.md)：基于“前端只做表现、逻辑与数据全部后端化”的工程重构规划。
|
||||
- [EXPRESS_BACKEND_PARALLEL_WORKSTREAM_PLAN_2026-04-08.md](./EXPRESS_BACKEND_PARALLEL_WORKSTREAM_PLAN_2026-04-08.md)：将后端化重构拆成可并行推进、尽量不冲突的任务流与协作顺序。
|
||||
- [BEIJING_POLICY_APPLICATION_OVERVIEW_13_21_24_2026-04-14.md](./BEIJING_POLICY_APPLICATION_OVERVIEW_13_21_24_2026-04-14.md)：北京市方向 13 / 21 / 24 的统一判断、共用材料框架和准备顺序。
|
||||
|
||||
@@ -825,6 +825,32 @@ isCardDetailLoading: boolean;
|
||||
|
||||
## 12. 接口与交互时序
|
||||
|
||||
## 12.0 生成草稿进度阶段
|
||||
|
||||
第三阶段的“整理一版世界底稿”不应再只显示粗略四阶段，而应贴近真实执行链路。
|
||||
|
||||
前端进度条至少按以下顺序归并展示：
|
||||
|
||||
1. 接收生成请求
|
||||
2. 整理世界骨架
|
||||
3. 生成可扮演角色
|
||||
4. 生成场景角色
|
||||
5. 生成关键场景
|
||||
6. 建立场景连接
|
||||
7. 补全可扮演角色细节
|
||||
8. 补全场景角色细节
|
||||
9. 编译世界底稿
|
||||
10. 生成角色主形象
|
||||
11. 生成幕背景图
|
||||
12. 编译草稿卡
|
||||
13. 准备精修工作区
|
||||
|
||||
说明：
|
||||
|
||||
1. 前端步骤名优先复用服务端 `phaseLabel` 的真实语义，不再单独发明一套四段式文案。
|
||||
2. 如果服务端处于批处理阶段，顶部 `phaseLabel` / `phaseDetail` 继续直接显示当前批次信息。
|
||||
3. 自动补主形象与幕背景图也属于草稿生成链路的一部分，不能在进度 UI 中被误折叠成“已完成”后的隐藏耗时。
|
||||
|
||||
## 12.1 生成底稿时序
|
||||
|
||||
```text
|
||||
|
||||
@@ -315,10 +315,10 @@ UI 主标题建议：
|
||||
按优先级取：
|
||||
|
||||
1. `draftProfile.cover.imageSrc`，当 `sourceType` 为 `uploaded / generated`
|
||||
2. `draftProfile.camp.imageSrc` 作为默认封面底图
|
||||
2. `draftProfile.sceneChapterBlueprints[0].acts[0].backgroundImageSrc` 作为默认封面底图
|
||||
3. 默认封面底图上叠加 `draftProfile.cover.characterRoleIds` 对应的角色主形象
|
||||
4. 若未显式指定角色，则按 `playableNpcs` 顺序取前 `3` 个有主图的角色
|
||||
5. 若开局场景图为空，则回退到第一张场景图；再不行才回退到首个角色主图或默认占位图
|
||||
5. 若开局场景第一幕图片为空，则依次回退到 `draftProfile.camp.imageSrc`、首个 `landmark.imageSrc`、首个角色主图或默认占位图
|
||||
|
||||
### 草稿卡片主操作
|
||||
|
||||
@@ -361,10 +361,10 @@ UI 主标题建议：
|
||||
按优先级取：
|
||||
|
||||
1. `CustomWorldProfile.cover.imageSrc`，当 `sourceType` 为 `uploaded / generated`
|
||||
2. 开局场景图作为默认封面底图
|
||||
2. 开局场景第一幕图片作为默认封面底图
|
||||
3. 默认封面底图上叠加 `cover.characterRoleIds` 指定的角色主形象
|
||||
4. 若未显式指定角色，则按 `playableNpcs` 顺序取前 `3` 个有主图的角色
|
||||
5. 若默认底图不可用，再回退到第一可扮演角色立绘或默认占位图
|
||||
5. 若默认底图不可用，则依次回退到 `camp.imageSrc`、首个 `landmark.imageSrc`、第一可扮演角色立绘或默认占位图
|
||||
|
||||
## 7.3 作品封面属性
|
||||
|
||||
@@ -387,7 +387,7 @@ interface CustomWorldCoverProfile {
|
||||
1. `sourceType = default`
|
||||
- 表示继续使用系统默认封面布局
|
||||
- `imageSrc` 不作为最终封面图使用
|
||||
- 底图固定取“开局场景图”
|
||||
- 底图固定优先取“开局场景第一幕图片”
|
||||
- 前景角色取 `characterRoleIds`
|
||||
|
||||
2. `sourceType = uploaded`
|
||||
@@ -399,24 +399,26 @@ interface CustomWorldCoverProfile {
|
||||
- 表示作者通过 AI 生成了一张最终封面
|
||||
- 卡片与详情页直接显示 `imageSrc`
|
||||
- 不再叠加默认角色前景
|
||||
- 生成时允许作者补一句封面描述，系统会结合世界主题、场景素材、角色素材共同构图
|
||||
|
||||
## 7.4 默认封面布局
|
||||
|
||||
默认封面布局不是单纯“取开局场景图”，而是：
|
||||
|
||||
```text
|
||||
开局场景图
|
||||
开局场景第一幕图片
|
||||
+ 前景主角色主形象 2~3 个
|
||||
+ 用于列表卡片和作品详情的统一封面预览
|
||||
```
|
||||
|
||||
明确规则：
|
||||
|
||||
1. 默认封面底图固定优先取 `camp.imageSrc`
|
||||
2. 默认前景角色固定从 `playableNpcs` 中取前 `3` 个有主图的角色
|
||||
3. 若作者在 `cover.characterRoleIds` 中显式指定角色，则优先按指定顺序展示
|
||||
4. 前端只负责把后端给出的“底图 + 角色主图列表”渲染成封面，不在前端做封面规则推理
|
||||
5. 已上传或已生成的最终封面，直接作为成品图显示，不再做默认布局叠加
|
||||
1. 默认封面底图固定优先取 `sceneChapterBlueprints[0].acts[0].backgroundImageSrc`
|
||||
2. 若开局场景第一幕图片不存在，则依次回退到 `camp.imageSrc` 与首个 `landmark.imageSrc`
|
||||
3. 默认前景角色固定从 `playableNpcs` 中取前 `3` 个有主图的角色
|
||||
4. 若作者在 `cover.characterRoleIds` 中显式指定角色，则优先按指定顺序展示
|
||||
5. 前端只负责把后端给出的“底图 + 角色主图列表”渲染成封面，不在前端做封面规则推理
|
||||
6. 已上传或已生成的最终封面，直接作为成品图显示，不再做默认布局叠加
|
||||
|
||||
## 7.5 作者操作
|
||||
|
||||
@@ -433,6 +435,64 @@ interface CustomWorldCoverProfile {
|
||||
2. 重置为默认后，`sourceType` 回到 `default`
|
||||
3. 草稿与已发布作品都读取同一份封面属性，不允许出现“草稿页是一个封面、发布后又自动换另一张”的漂移
|
||||
|
||||
## 7.6 AI 封面生成与上传约束
|
||||
|
||||
### AI 生成输入
|
||||
|
||||
作者点击 `AI 生成封面` 后，面板至少支持 3 类输入：
|
||||
|
||||
1. 一句封面图描述
|
||||
2. 可选参考图
|
||||
3. 角色出镜选择
|
||||
|
||||
系统生成封面时，后端必须自动拼接以下上下文，而不是只吃用户那一句描述：
|
||||
|
||||
1. 世界名、副标题、世界概述、主题基调、玩家目标
|
||||
2. 开局场景第一幕标题、摘要、背景图
|
||||
3. 营地图与关键场景图
|
||||
4. 可扮演角色主形象
|
||||
5. 已选择的封面角色顺序
|
||||
|
||||
结论：
|
||||
|
||||
**封面 AI 生成必须是“用户一句描述 + 系统世界素材拼接”的生成链，而不是裸 prompt。**
|
||||
|
||||
### AI 生成结果要求
|
||||
|
||||
1. 默认生成尺寸固定为 `16:9`
|
||||
2. 第一版统一生成 `1600 × 900`
|
||||
3. 结果图不允许出现标题字、水印、按钮、UI 边框
|
||||
4. 结果图要优先满足移动端卡片裁切后的主体可读性
|
||||
5. 结果图保存后直接写入作品封面资产目录
|
||||
|
||||
### 上传封面要求
|
||||
|
||||
作者点击 `上传封面` 后，不能直接把原图原样落库，必须经过独立裁剪面板处理。
|
||||
|
||||
裁剪链路要求：
|
||||
|
||||
1. 上传后先进入独立裁剪面板
|
||||
2. 裁剪框比例固定为 `16:9`
|
||||
3. 作者只能平移和缩放，不允许自由改比例
|
||||
4. 裁剪完成后，再提交给后端保存
|
||||
|
||||
### 上传大小与格式限制
|
||||
|
||||
第一版约束：
|
||||
|
||||
1. 仅支持 `png / jpg / webp`
|
||||
2. 上传原图大小上限固定为 `10 MB`
|
||||
3. 后端落库前必须统一裁剪并缩放到 `1600 × 900`
|
||||
4. 后端保存时需要做体积压缩，目标成品图不超过 `1.5 MB`
|
||||
5. 若压缩后仍超过限制，返回明确错误，不允许静默保存超标文件
|
||||
|
||||
### 前后端分工
|
||||
|
||||
1. 前端负责提供裁剪交互、预览与提交裁剪框
|
||||
2. 后端负责最终裁剪、缩放、压缩和大小校验
|
||||
3. 前端不能直接把本地裁剪结果当最终事实来源
|
||||
4. 同一张上传封面在草稿页、作品库、详情页必须读取同一后端成品地址
|
||||
|
||||
### 已发布卡片主操作
|
||||
|
||||
第一版必须有：
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
## 1. 一句话定义
|
||||
|
||||
玩家点击 `npc_chat` 后，进入 NPC 聊天模式；每次只完成一轮“玩家输入 -> NPC 回复 -> 关系变化消息 -> 下一轮 3 个建议选项 + 1 个自定义输入”，直到玩家主动退出聊天。
|
||||
玩家点击 `npc_chat` 后，进入 NPC 聊天模式；每次只完成一轮“玩家输入 -> NPC 回复 -> 角色形象播出好感度变化特效 -> 下一轮 3 个建议选项 + 1 个自定义输入”，直到玩家主动退出聊天。
|
||||
|
||||
---
|
||||
|
||||
@@ -42,7 +42,7 @@
|
||||
4. 每轮结束后稳定出现 `3` 个建议续聊选项。
|
||||
5. 每轮结束后稳定出现 `1` 个自定义输入框。
|
||||
6. 玩家选择建议项或提交自定义输入后，继续在同一消息队列中续写。
|
||||
7. 好感度增减必须作为“系统消息”插入到对话消息队列中。
|
||||
7. 好感度增减不能再作为聊天系统消息插入队列，必须改为角色形象上的数值特效反馈。
|
||||
8. NPC 回复必须支持流式传输，并在前端边接收边解析显示。
|
||||
9. 背包按钮所在行的最右侧必须新增“退出聊天”按钮。
|
||||
10. 退出聊天后恢复普通冒险态，不保留当前聊天输入框与聊天建议项。
|
||||
@@ -82,7 +82,7 @@
|
||||
1. 玩家通过“建议选项”或“自定义输入”提交一句话。
|
||||
2. 玩家消息立即进入消息队列。
|
||||
3. NPC 回复开始流式显示。
|
||||
4. 流式结束后，如果有关系变化，插入一条系统消息。
|
||||
4. 流式结束后，如果有关系变化，在角色形象上播放一次对应的数值特效。
|
||||
5. 系统刷新下一轮 `3` 个建议选项。
|
||||
6. 系统保留自定义输入入口，等待下一轮。
|
||||
|
||||
@@ -117,9 +117,17 @@
|
||||
1. 聊天态下，消息区按时间顺序展示：
|
||||
- 玩家消息
|
||||
- NPC 消息
|
||||
- 系统关系变化消息
|
||||
2. 系统关系变化消息必须和普通消息共用同一消息流容器。
|
||||
3. 系统关系变化消息视觉上应与玩家/NPC 气泡有明确区分。
|
||||
2. 好感度变化不再插入聊天消息流。
|
||||
3. 消息区不额外追加“关系升温 / 关系转冷”类文字提示。
|
||||
|
||||
### 角色形象特效
|
||||
|
||||
1. 若本轮好感度提升，必须在当前聊天对象的角色形象上飞出心形正向特效。
|
||||
2. 正向特效内必须显示本轮增加数值，例如：`+3`。
|
||||
3. 若本轮好感度下降，必须在当前聊天对象的角色形象上飞出负向特效。
|
||||
4. 负向特效内必须显示本轮减少数值，例如：`-2`。
|
||||
5. 特效应挂载在当前角色形象区域，而不是消息区、选项区或额外弹窗。
|
||||
6. 同一轮只播一次最近结算结果，不重复插入历史文本。
|
||||
|
||||
### 底部按钮区
|
||||
|
||||
@@ -162,7 +170,7 @@
|
||||
2. 渲染当前消息队列。
|
||||
3. 发送玩家本轮输入。
|
||||
4. 接收流式事件并实时更新 NPC 当前回复文本。
|
||||
5. 渲染系统关系变化消息。
|
||||
5. 渲染角色形象上的好感度变化特效。
|
||||
6. 渲染下一轮 `3` 个建议项与自定义输入框。
|
||||
|
||||
前端不负责：
|
||||
@@ -209,7 +217,7 @@ type StoryNpcChatState = {
|
||||
|
||||
## 8.2 聊天消息结构
|
||||
|
||||
消息队列需要支持系统消息：
|
||||
消息队列继续支持系统消息，用于战斗结算、流程收束等非好感提示：
|
||||
|
||||
```ts
|
||||
type StoryDialogueTurn = {
|
||||
@@ -223,7 +231,24 @@ type StoryDialogueTurn = {
|
||||
要求：
|
||||
|
||||
1. `system` 只用于关系变化、系统反馈类消息。
|
||||
2. `affinityDelta` 仅在关系变化消息中写入。
|
||||
2. `affinityDelta` 不再用于向聊天消息流插入好感提示。
|
||||
|
||||
新增聊天态特效事件：
|
||||
|
||||
```ts
|
||||
type StoryNpcAffinityEffect = {
|
||||
eventId: string;
|
||||
npcId: string;
|
||||
delta: number;
|
||||
};
|
||||
```
|
||||
|
||||
要求：
|
||||
|
||||
1. 仅在本轮聊天真实发生好感变化时写入。
|
||||
2. `delta > 0` 表示正向心形特效。
|
||||
3. `delta < 0` 表示负向减少特效。
|
||||
4. 该事件只负责驱动角色形象表现，不负责生成消息文本。
|
||||
|
||||
## 8.3 单轮接口契约
|
||||
|
||||
|
||||
@@ -24,6 +24,10 @@
|
||||
|
||||
**每个场景由创作者在工具中配置为 `2~5` 幕；每一幕都绑定独立背景图和相遇 NPC 顺序；每一幕的第一个 NPC 视为主角色；运行时按幕切换背景和可遇对象，并根据主角色当前好感度裁决聊天轮数与第 5 轮收束方式。**
|
||||
|
||||
本次还追加一条必须和草稿生成阶段一起落地的约束：
|
||||
|
||||
**Agent 在生成第一版世界草稿时，默认只生成 `1` 个可扮演角色、`2` 个场景章节、每个场景章节固定 `3` 幕、`5~10` 个场景角色；并且要在草稿生成过程中基于底层剧情引擎判定每一幕该由哪些角色出演、背景应该是什么样，再自动生成每幕背景图和每个角色的主形象。动作资产本期不生成。**
|
||||
|
||||
补充口径修正：
|
||||
|
||||
1. `scene_chapter` 在本期继续保留为数据层 / 编译层 / 运行时层概念。
|
||||
@@ -32,8 +36,10 @@
|
||||
4. 每一幕的 NPC 配置区必须直接叠在当前幕背景预览上，以“对面角色站位”的方式呈现；三个站位既是预览，也是编辑入口。
|
||||
5. 幕编辑站位中每个角色只显示角色形象与名称，不展示额外信息块、规则说明或说明性标签。
|
||||
6. 幕内小预览的构图固定为左侧玩家、右侧当前幕角色；右侧三个站位采用一前两后。
|
||||
前排主角色的 y 轴必须与玩家角色对齐；后排两个角色必须同一列、x 轴对齐，上下分布，且后排整体的 y 轴中点与前排主角色保持一致。
|
||||
7. 新建幕默认仅预置 1 个主角色槽位内容，其余槽位留空，等待创作者补充。
|
||||
8. 角色名称显示在角色形象上方，角色渲染不附带方形 UI 底板。
|
||||
9. 世界档案的场景详情页不再单独展示“场景图片”和“场景内 NPC”字段；相关兼容数据统一由多幕配置自动同步回场景对象。
|
||||
|
||||
这份文档必须能直接指导后续创作工具和游戏流程改造，避免需求落地漂移。
|
||||
|
||||
@@ -59,6 +65,21 @@
|
||||
8. 好感度小于 `0` 的主角色，在相遇后最多只允许聊天 `5` 轮，第 `5` 轮必须输出一段为后续剧情开展铺垫的收束回应。
|
||||
9. 前端继续只负责展示，幕切换、聊天限制、幕进度与数据裁决全部由 Express 后端负责。
|
||||
10. 默认复用现有创作页面、草稿抽屉、详情弹层、场景章节和聊天流程，不新开独立系统或新页面。
|
||||
11. 第一版世界草稿默认规模必须收束为：
|
||||
- `1` 个可扮演角色
|
||||
- `2` 个场景章节
|
||||
- 每个场景章节固定 `3` 幕
|
||||
- `5~10` 个场景角色
|
||||
12. 草稿生成阶段必须由后端基于底层剧情引擎直接判定每一幕的：
|
||||
- 出演角色顺序
|
||||
- 主角色
|
||||
- 幕目标
|
||||
- 幕背景语义
|
||||
13. 草稿生成完成时，系统必须自动产出：
|
||||
- 每一幕对应的背景图
|
||||
- 每个场景角色的主形象
|
||||
- 可扮演角色的主形象
|
||||
14. 本期不生成动作、不生成动作预览、不生成动作发布资产。
|
||||
|
||||
---
|
||||
|
||||
@@ -74,6 +95,7 @@
|
||||
6. 不把“规则说明文案”默认堆到创作页或游戏 UI 面板里。
|
||||
7. 不把“点击配置”实现成在当前卡片下面继续展开大段内容。
|
||||
8. 不重写现有高好感委托链路，只在本次规则下明确它什么时候还能触发。
|
||||
9. 不在草稿生成阶段默认补动作、待机、攻击、跑动或技能动作素材。
|
||||
|
||||
---
|
||||
|
||||
@@ -177,6 +199,124 @@
|
||||
3. 主角色承担该幕默认的首次相遇、聊天轮数裁决和幕推进优先级。
|
||||
4. 其余 NPC 视为辅助相遇角色，不直接承担本次“好感度聊天轮数规则”。
|
||||
|
||||
## 5.4 开局场景与普通场景的统一规则
|
||||
|
||||
本次新增一条必须落实到代码与数据结构的约束：
|
||||
|
||||
**开局场景不是一套特殊场景系统，只是“玩家开局所处的那一个场景”。**
|
||||
|
||||
因此，开局场景在创作工具、数据结构、保存链路、运行时编译上，都必须与普通场景保持同一套配置参数。
|
||||
|
||||
明确要求如下：
|
||||
|
||||
1. 开局场景允许配置的字段必须与普通场景一致，至少包括：
|
||||
- `name`
|
||||
- `description`
|
||||
- `dangerLevel`
|
||||
- `imageSrc`
|
||||
- `sceneNpcIds`
|
||||
- `connections`
|
||||
- `sceneChapterBlueprints` 对应的多幕配置
|
||||
2. 场景配置面板中，开局场景必须复用普通场景同级的配置 UI，而不是继续保留一套缩水版表单。
|
||||
3. 开局场景与普通场景的唯一产品差异，只能是：
|
||||
- 它是玩家进入世界时默认所在的初始场景
|
||||
- 它在列表或运行时可带“开局场景 / 初始场景”语义标记
|
||||
4. 除“初始所在场景”语义之外，不允许再因为它是开局场景而裁掉 NPC、连接、多幕、危险度等配置能力。
|
||||
5. 为兼容现有数据，当前 `camp` 字段可以继续保留，但其承载的结构必须与普通场景对齐，不能再是阉割版场景结构。
|
||||
6. 运行时编译时，开局场景也必须按普通场景规则参与：
|
||||
- 场景 NPC 池编译
|
||||
- 场景连接编译
|
||||
- 多幕蓝图读取
|
||||
- 场景图片 / 残痕 / 预览数据生成
|
||||
|
||||
一句话约束：
|
||||
|
||||
**“开局场景”是场景身份，不是场景能力分支。**
|
||||
|
||||
## 5.5 草稿默认规模与自动资产策略
|
||||
|
||||
为了让“生成游戏设定草稿”真正变成一个可直接进入精修的起点，而不是一份需要继续手动补骨架的半成品，本次新增下面这些硬约束：
|
||||
|
||||
### 5.5.1 第一版草稿固定规模
|
||||
|
||||
第一版 Agent 世界草稿必须默认产出：
|
||||
|
||||
1. `1` 个可扮演角色
|
||||
2. `5~10` 个场景角色
|
||||
3. `2` 个场景章节
|
||||
4. 每个场景章节固定 `3` 幕
|
||||
|
||||
这里不再沿用旧的“多 playable / 多 landmarks 先铺开”的策略。
|
||||
|
||||
原因：
|
||||
|
||||
1. 当前创作工作区已经进入“先收关键锚点、再逐步扩写”的阶段。
|
||||
2. 一次铺太多 playable、场景和长尾对象，会稀释创作者对第一版底稿的掌控感。
|
||||
3. 本期还要把幕级背景图和角色主形象自动挂回草稿，如果对象规模不收束，等待时间和生成成本都会直接失控。
|
||||
|
||||
### 5.5.2 幕级出演角色与背景必须由剧情引擎判定
|
||||
|
||||
这次不允许继续使用“先生场景，再把同一组 sceneNpcIds 平铺复制到所有幕里”的宽松策略。
|
||||
|
||||
后端在生成 `scene chapter -> act` 时，必须基于底层剧情引擎已有结构综合裁定：
|
||||
|
||||
1. `storyGraph.visibleThreads / hiddenThreads`
|
||||
2. 角色 `narrativeProfile / threadIds`
|
||||
3. 地点 `linkedLandmarkIds / linkedThreadIds`
|
||||
4. 当前场景章节的 `summary / actGoal / transitionHook`
|
||||
|
||||
最少要做出下面这几个结论：
|
||||
|
||||
1. 这一幕优先让哪些角色出场
|
||||
2. 谁是该幕主角色
|
||||
3. 这一幕的压力核心是什么
|
||||
4. 这一幕的背景图应该突出什么空间氛围、危险感和叙事残痕
|
||||
|
||||
一句话要求：
|
||||
|
||||
**每一幕的演员和背景，不是静态复制，而是“线程压力 + 角色挂钩 + 地点语义”联合裁定的结果。**
|
||||
|
||||
### 5.5.3 自动生成的资产范围
|
||||
|
||||
第一版草稿生成成功后，后端必须自动继续生成并写回：
|
||||
|
||||
1. 每一幕的背景图
|
||||
2. 每个场景角色的主形象
|
||||
3. 可扮演角色的主形象
|
||||
|
||||
本期明确不做：
|
||||
|
||||
1. 不自动生成动作
|
||||
2. 不自动生成精灵表
|
||||
3. 不自动生成技能动作
|
||||
4. 不自动生成 run / attack / hurt / die
|
||||
|
||||
也就是说，本期资产策略是：
|
||||
|
||||
**只产主形象和幕背景，不产动作。**
|
||||
|
||||
### 5.5.4 自动资产生成的回写要求
|
||||
|
||||
自动资产生成后，草稿层必须直接带回：
|
||||
|
||||
1. 角色：
|
||||
- `imageSrc`
|
||||
- `generatedVisualAssetId`
|
||||
2. 场景幕：
|
||||
- `backgroundImageSrc`
|
||||
- `backgroundAssetId`
|
||||
3. 资产覆盖摘要：
|
||||
- 角色主形象是否就绪
|
||||
- 场景幕背景是否就绪
|
||||
|
||||
这样创作者一进入草稿精修工作区，就能直接看到：
|
||||
|
||||
1. 角色已经带主形象
|
||||
2. 每个场景章节的每一幕已经带背景图
|
||||
3. 当前草稿哪些资产还缺失
|
||||
|
||||
而不是先看到一堆空白占位，再手工逐个点生成。
|
||||
|
||||
---
|
||||
|
||||
## 6. 数据结构要求
|
||||
@@ -353,10 +493,14 @@ type NpcChatTurnResult = {
|
||||
场景编辑弹层至少展示：
|
||||
|
||||
1. 场景名称与描述
|
||||
2. 场景主图
|
||||
3. 场景内 NPC
|
||||
4. 多幕配置区块
|
||||
5. 场景连接关系
|
||||
2. 多幕配置区块
|
||||
3. 场景连接关系
|
||||
|
||||
补充约束：
|
||||
|
||||
1. “场景图片”不再作为场景详情页里的独立字段展示，创作者只能通过每一幕的“配置背景”入口管理视觉。
|
||||
2. “场景内 NPC”不再作为场景详情页里的独立字段展示，创作者只能通过每一幕角色槽位配置相遇 NPC。
|
||||
3. 为兼容现有运行时与旧数据结构，场景对象上的 `imageSrc / sceneNpcIds` 仍然保留，但必须由多幕配置自动回填，前台不再暴露单独编辑控件。
|
||||
|
||||
多幕区块至少展示：
|
||||
|
||||
@@ -573,6 +717,10 @@ interface SceneActRuntimeState {
|
||||
- 自定义输入框隐藏
|
||||
- 当前聊天态结束
|
||||
- 恢复普通冒险态或进入后续 action 选择
|
||||
7. 如果玩家在当前幕主角色的本地战斗中取胜，NPC 会重新开启一段战后聊天：
|
||||
- 这段聊天必须把刚刚那场交锋的结果摘要与关键战斗日志带入上下文
|
||||
- 如果该主角色此时好感仍然 `< 0`，则战后聊天依然只允许 `5` 轮，并从战后这次重新开启时重新计数
|
||||
- 第 `5` 轮结束后 NPC 离开当前对话态，玩家可以继续承接后续 action，并在满足推进条件时前往下一幕
|
||||
|
||||
## 9.5 第 5 轮的“铺垫”定义
|
||||
|
||||
|
||||
412
docs/prd/TXT_MODE_CORE_GAMEPLAY_PRD_2026-04-20.md
Normal file
412
docs/prd/TXT_MODE_CORE_GAMEPLAY_PRD_2026-04-20.md
Normal file
@@ -0,0 +1,412 @@
|
||||
# TXT 模式核心玩法 PRD（2026-04-20）
|
||||
|
||||
更新时间：`2026-04-20`
|
||||
|
||||
## 0. 文档目的
|
||||
|
||||
这份 PRD 只定义 `Interactive-fiction-frontend` + `Interactive-fiction-backend` 中 TXT 模式在 `Genarrative` 落地时的**核心玩法闭环**。
|
||||
|
||||
这次明确**不讨论平台层功能**，包括但不限于：
|
||||
|
||||
1. 平台首页
|
||||
2. 平台详情页
|
||||
3. 平台广场
|
||||
4. 平台作品库
|
||||
5. 平台浏览历史
|
||||
6. 平台钱包与扣费落地
|
||||
7. 平台统一存档页
|
||||
8. 平台账号与公开态策略
|
||||
|
||||
本稿只关心一件事：
|
||||
|
||||
**把外部仓库 TXT 模式最小可玩的创作与运行闭环原样迁入，形成一个可以独立验证的视觉小说核心玩法。**
|
||||
|
||||
---
|
||||
|
||||
## 1. 一句话定义
|
||||
|
||||
TXT 模式核心玩法是一个包含“创作编辑器 -> 测试体验 -> 正式运行 -> 多槽位存档 -> 历史重生成”的视觉小说玩法闭环。
|
||||
|
||||
---
|
||||
|
||||
## 2. 本次目标
|
||||
|
||||
本次只做下面这些核心目标：
|
||||
|
||||
1. 支持创建 TXT 模式作品。
|
||||
2. 支持 TXT 模式作品的完整创作流程。
|
||||
3. 支持创作者测试体验。
|
||||
4. 支持玩家正式游玩。
|
||||
5. 支持文本模式运行。
|
||||
6. 支持双会话机制。
|
||||
7. 支持 5 槽位存档。
|
||||
8. 支持通过 `saveId` 读档创建会话。
|
||||
9. 支持历史记录查看。
|
||||
10. 支持历史重生成。
|
||||
11. 保留外部 TXT 模式提示词正文与功能需求，不改词、不改规则。
|
||||
12. 仅替换文本生成接口与生图接口为本项目现有能力。
|
||||
|
||||
---
|
||||
|
||||
## 3. 明确不做
|
||||
|
||||
本次 PRD 明确不做下面这些事：
|
||||
|
||||
1. 不做平台首页融合。
|
||||
2. 不做平台详情页融合。
|
||||
3. 不做平台广场、作品库、公开浏览。
|
||||
4. 不做平台浏览历史。
|
||||
5. 不做平台统一钱包与扣费实现。
|
||||
6. 不做平台统一存档页。
|
||||
7. 不做回放。
|
||||
8. 不做平台层账户策略改造。
|
||||
9. 不做其它玩法的统一抽象。
|
||||
10. 不把 TXT 模式扩展成平台总线工程。
|
||||
|
||||
一句话约束：
|
||||
|
||||
**先把 TXT 模式本体做成，再谈平台层融合。**
|
||||
|
||||
---
|
||||
|
||||
## 4. 核心范围
|
||||
|
||||
## 4.1 创作链路
|
||||
|
||||
本次必须完整保留外部 TXT 模式创作主链：
|
||||
|
||||
1. 选择 TXT 模式。
|
||||
2. 进入创作编辑器。
|
||||
3. 通过以下方式之一创建底稿：
|
||||
- 文档上传
|
||||
- 一句话生成
|
||||
- 空白创建
|
||||
4. 编辑以下内容：
|
||||
- 世界观
|
||||
- 角色
|
||||
- 场景
|
||||
5. 发起测试体验。
|
||||
6. 完成作品保存。
|
||||
|
||||
## 4.2 运行链路
|
||||
|
||||
本次必须完整保留外部 TXT 模式运行主链：
|
||||
|
||||
1. 新的开始
|
||||
2. 继续体验
|
||||
3. 读取存档
|
||||
4. 进入运行时页面
|
||||
5. 普通模式 / 文本模式
|
||||
6. 历史记录
|
||||
7. 存档管理
|
||||
8. 设置
|
||||
9. 属性面板白名单
|
||||
10. 历史重生成
|
||||
|
||||
---
|
||||
|
||||
## 5. 核心玩法冻结边界
|
||||
|
||||
后续实现时，以下内容必须按外部 TXT 模式原样保留：
|
||||
|
||||
1. 编辑器步骤顺序。
|
||||
2. 双会话机制。
|
||||
3. 流式动作协议事件：
|
||||
- `start`
|
||||
- `raw_text`
|
||||
- `step`
|
||||
- `complete`
|
||||
- `data`
|
||||
- `error`
|
||||
- `done`
|
||||
4. 5 槽位存档。
|
||||
5. 通过 `saveId` 读档创建会话。
|
||||
6. 存档载荷中的：
|
||||
- `stateLite`
|
||||
- `historyTail`
|
||||
7. 历史重生成语义。
|
||||
8. 属性面板白名单。
|
||||
9. 默认主 prompt 选择语义。
|
||||
10. prompt 正文。
|
||||
|
||||
---
|
||||
|
||||
## 6. 创作编辑器需求
|
||||
|
||||
## 6.1 创建方式
|
||||
|
||||
编辑器必须支持 3 种创建方式：
|
||||
|
||||
1. 上传文档
|
||||
2. 一句话生成
|
||||
3. 空白创建
|
||||
|
||||
三者都必须进入同一套 TXT 模式编辑器，而不是三套分裂流程。
|
||||
|
||||
## 6.2 编辑器模块
|
||||
|
||||
编辑器至少必须包含以下模块：
|
||||
|
||||
1. 世界观编辑
|
||||
2. 角色编辑
|
||||
3. 场景编辑
|
||||
4. 测试体验入口
|
||||
5. 保存/发布前准备入口
|
||||
|
||||
## 6.3 前后端边界
|
||||
|
||||
编辑器侧遵守下面这条边界：
|
||||
|
||||
1. 前端只负责编辑器表现与输入采集。
|
||||
2. 作品结构校验、编译、测试会话创建、正式数据写入由后端负责。
|
||||
|
||||
---
|
||||
|
||||
## 7. 双会话机制
|
||||
|
||||
TXT 模式核心玩法必须完整保留双会话机制。
|
||||
|
||||
## 7.1 玩家游玩会话
|
||||
|
||||
玩家游玩会话用于：
|
||||
|
||||
1. 正式开始作品
|
||||
2. 正式继续体验
|
||||
3. 正式游玩推进
|
||||
|
||||
## 7.2 创作者测试/读档会话
|
||||
|
||||
创作者测试/读档会话用于：
|
||||
|
||||
1. 编辑器内测试体验
|
||||
2. 指定存档加载
|
||||
3. 非正式发布态验证
|
||||
|
||||
## 7.3 禁止简化
|
||||
|
||||
禁止把这两类会话合并成一类“统一 session”。
|
||||
|
||||
---
|
||||
|
||||
## 8. 运行时页面需求
|
||||
|
||||
## 8.1 页面能力面
|
||||
|
||||
运行时页面至少要有：
|
||||
|
||||
1. 普通模式
|
||||
2. 文本模式
|
||||
3. 历史记录面板
|
||||
4. 存档面板
|
||||
5. 设置面板
|
||||
6. 属性面板
|
||||
|
||||
## 8.2 文本模式
|
||||
|
||||
文本模式必须按外部 TXT 模式语义保留：
|
||||
|
||||
1. 独立于普通模式的显示区域
|
||||
2. 与运行时主状态同步
|
||||
3. 可消费流式动作结果
|
||||
|
||||
## 8.3 属性面板
|
||||
|
||||
属性面板必须保留外部 TXT 模式的白名单语义：
|
||||
|
||||
1. 白名单用户显示
|
||||
2. 非白名单用户不显示
|
||||
|
||||
---
|
||||
|
||||
## 9. 流式动作协议
|
||||
|
||||
TXT 模式核心玩法必须保留外部流式动作协议。
|
||||
|
||||
## 9.1 事件类型
|
||||
|
||||
服务端必须推送下列事件：
|
||||
|
||||
1. `start`
|
||||
2. `raw_text`
|
||||
3. `step`
|
||||
4. `complete`
|
||||
5. `data`
|
||||
6. `error`
|
||||
7. `done`
|
||||
|
||||
## 9.2 前端职责
|
||||
|
||||
前端只负责：
|
||||
|
||||
1. 发起动作请求
|
||||
2. 解析流式事件
|
||||
3. 渲染逐步结果
|
||||
|
||||
前端不负责：
|
||||
|
||||
1. 本地推进正式运行状态
|
||||
2. 本地拼接替代结果
|
||||
|
||||
---
|
||||
|
||||
## 10. 存档机制
|
||||
|
||||
## 10.1 槽位规则
|
||||
|
||||
每个作品最多保留 5 个槽位。
|
||||
|
||||
必须支持：
|
||||
|
||||
1. 新建存档
|
||||
2. 覆盖存档
|
||||
3. 读取指定槽位
|
||||
|
||||
## 10.2 存档载荷
|
||||
|
||||
存档内容不能只有摘要，至少必须包含：
|
||||
|
||||
1. `stateLite`
|
||||
2. `historyTail`
|
||||
|
||||
## 10.3 读档语义
|
||||
|
||||
读取存档不是恢复前端本地状态，而是：
|
||||
|
||||
1. 传入 `saveId`
|
||||
2. 由后端创建新的测试/读档会话
|
||||
3. 前端消费会话结果
|
||||
|
||||
---
|
||||
|
||||
## 11. 历史机制
|
||||
|
||||
## 11.1 历史记录
|
||||
|
||||
运行时必须支持查看已有历史记录。
|
||||
|
||||
## 11.2 历史重生成
|
||||
|
||||
运行时必须支持历史重生成。
|
||||
|
||||
其语义必须是：
|
||||
|
||||
1. 用户选择某个历史节点
|
||||
2. 服务端基于该节点上下文重新生成后续
|
||||
3. 新结果成为新的有效运行轨迹
|
||||
|
||||
禁止把它简化成普通“再来一次下一步”。
|
||||
|
||||
---
|
||||
|
||||
## 12. 提示词与模型调用
|
||||
|
||||
## 12.1 Prompt 规则
|
||||
|
||||
后续实现时必须遵守：
|
||||
|
||||
1. 外部 TXT 模式 prompt 正文不改。
|
||||
2. 外部 TXT 模式 prompt 规则不改。
|
||||
3. 默认 prompt 选择语义不改。
|
||||
|
||||
## 12.2 允许替换的部分
|
||||
|
||||
只允许替换下面两项底层能力：
|
||||
|
||||
1. 文本生成接口
|
||||
- 替换为 `server-node/src/services/llmClient.ts`
|
||||
2. 生图接口
|
||||
- 替换为 `server-node/src/services/sceneImageService.ts`
|
||||
|
||||
除此之外，不允许借“接入本项目能力”之名修改玩法需求。
|
||||
|
||||
---
|
||||
|
||||
## 13. 核心后端职责
|
||||
|
||||
TXT 模式核心玩法的正式运行真相必须在后端。
|
||||
|
||||
后端至少负责：
|
||||
|
||||
1. 会话创建
|
||||
2. prompt 装载与上下文拼接
|
||||
3. 流式动作生成
|
||||
4. 存档读写
|
||||
5. `saveId` 读档会话创建
|
||||
6. 历史重生成
|
||||
7. 属性白名单裁决
|
||||
|
||||
---
|
||||
|
||||
## 14. 核心前端职责
|
||||
|
||||
前端只负责：
|
||||
|
||||
1. 编辑器页面表现
|
||||
2. 运行时页面表现
|
||||
3. 文本模式显示
|
||||
4. 流式事件解析
|
||||
5. 历史/存档/设置面板打开与关闭
|
||||
|
||||
前端不负责：
|
||||
|
||||
1. 正式运行时结算
|
||||
2. 会话语义判定
|
||||
3. 存档内容拼接
|
||||
4. 历史重生成裁决
|
||||
|
||||
---
|
||||
|
||||
## 15. 建议影响文件
|
||||
|
||||
本次核心玩法落地，优先会影响下面这些区域：
|
||||
|
||||
前端：
|
||||
|
||||
1. `src/components/game-shell/PlatformCreationTypeModal.tsx`
|
||||
2. `src/services/aiService.ts`
|
||||
3. 新增 TXT 模式编辑器页面或模块
|
||||
4. 新增 TXT 模式运行时页面或模块
|
||||
5. 新增 TXT 模式 SSE 解析模块
|
||||
|
||||
后端：
|
||||
|
||||
1. `server-node/src/routes/runtimeRoutes.ts`
|
||||
2. `server-node/src/services/llmClient.ts`
|
||||
3. `server-node/src/services/sceneImageService.ts`
|
||||
4. `server-node/src/repositories/runtimeRepository.ts`
|
||||
5. `server-node/src/prompts/`
|
||||
6. 新增 TXT 模式 services / contracts / repository modules
|
||||
|
||||
---
|
||||
|
||||
## 16. 验收标准
|
||||
|
||||
满足下面这些结果时，视为核心玩法闭环成立：
|
||||
|
||||
1. 可以创建 TXT 模式作品。
|
||||
2. 可以通过上传文档、一句话生成、空白创建进入同一编辑器。
|
||||
3. 编辑器可编辑世界观、角色、场景。
|
||||
4. 编辑器内可发起测试体验。
|
||||
5. 可创建正式游玩会话。
|
||||
6. 可创建测试/读档会话。
|
||||
7. 运行时支持普通模式与文本模式。
|
||||
8. 流式动作协议按外部事件名工作。
|
||||
9. 可查看历史记录。
|
||||
10. 可执行历史重生成。
|
||||
11. 支持 5 槽位存档。
|
||||
12. 支持通过 `saveId` 读档创建会话。
|
||||
13. 存档包含 `stateLite + historyTail`。
|
||||
14. 属性面板白名单逻辑生效。
|
||||
15. prompt 正文与功能需求未被改写。
|
||||
|
||||
---
|
||||
|
||||
## 17. 本稿结论
|
||||
|
||||
这次先不要把 TXT 模式做成平台工程。
|
||||
|
||||
先把下面这条链做通：
|
||||
|
||||
**创建 TXT 作品 -> 编辑世界/角色/场景 -> 测试体验 -> 正式游玩 -> 文本模式 -> 多槽位存档 -> 历史重生成**
|
||||
|
||||
只要这条链通了，TXT 模式核心玩法就成立；平台层融合、详情页整合、钱包接入、统一存档页，都可以放到下一阶段再做。
|
||||
@@ -59,7 +59,7 @@
|
||||
| `server-node/src/prompts/customWorldEntityPrompts.ts` | 世界编辑器实体生成 | `CUSTOM_WORLD_ENTITY_GENERATOR_SYSTEM_PROMPT`、`buildPlayablePrompt`、`buildStoryPrompt`、`buildLandmarkPrompt` |
|
||||
| `server-node/src/prompts/customWorldSceneNpcPrompts.ts` | 世界编辑器场景 NPC | `CUSTOM_WORLD_SCENE_NPC_SYSTEM_PROMPT`、`buildCustomWorldSceneNpcPrompt` |
|
||||
| `server-node/src/prompts/eightAnchorPrompts.ts` | 八锚点共创 | `BASE_SYSTEM_PROMPT`、`GLOBAL_HARD_RULES`、`MODE_RULES`、`USER_SIGNAL_RULES`、`buildPromptDynamicStateInferencePrompt`、`buildEightAnchorSingleTurnPrompt` |
|
||||
| `server-node/src/prompts/characterAssetPrompts.ts` | 角色形象 / 动作资产生成 | `CHARACTER_PROMPT_BUNDLE_SYSTEM_PROMPT`、`buildFallbackCharacterPromptBundle`、`buildCharacterPromptBundleUserPrompt`、`buildNpcVisualPrompt`、`buildNpcAnimationPrompt`、`buildArkCharacterAnimationPrompt` |
|
||||
| `server-node/src/prompts/characterAssetPrompts.ts` | 角色形象 / 动作资产生成 | `buildNpcVisualPrompt`、`buildNpcAnimationPrompt`、`buildArkCharacterAnimationPrompt`、`buildImageSequencePrompt`、`buildNpcVisualNegativePrompt` |
|
||||
|
||||
### 3.2 前端
|
||||
|
||||
@@ -72,7 +72,7 @@
|
||||
| `src/prompts/customWorldPrompts.ts` | 自定义世界分阶段生成 + 场景背景图 | 多个 `buildCustomWorld*Prompt`、`DEFAULT_CUSTOM_WORLD_SCENE_IMAGE_NEGATIVE_PROMPT` |
|
||||
| `src/prompts/customWorldOrchestratorPrompts.ts` | 世界 JSON 修复 / JSON only | `CUSTOM_WORLD_JSON_REPAIR_SYSTEM_PROMPT`、`CUSTOM_WORLD_GENERATION_JSON_ONLY_SYSTEM_PROMPT` |
|
||||
| `src/prompts/storyOrchestratorPrompts.ts` | 剧情中文修复 | `STORY_LANGUAGE_REPAIR_SYSTEM_PROMPT` |
|
||||
| `src/prompts/customWorldRolePromptDefaults.ts` | 角色资产工作台默认词 | `buildDefaultRolePromptBundle` |
|
||||
| `src/prompts/customWorldRolePromptDefaults.ts` | 角色资产工作台默认词唯一主源 | `buildDefaultRolePromptBundle` |
|
||||
| `src/prompts/customWorldEntityActionPrompts.ts` | 编辑器技能动作词 | `buildSkillActionPrompt` |
|
||||
| `src/prompts/qwenSpriteSheetToolPrompts.ts` | Qwen 精灵图工具 prompt 模型 | 主 prompt / sheet prompt / repair prompt / negative prompt 系列 |
|
||||
|
||||
|
||||
@@ -0,0 +1,174 @@
|
||||
# 世界草稿自动资产可见性修复说明 2026-04-20
|
||||
|
||||
更新时间：`2026-04-20`
|
||||
|
||||
## 1. 问题现象
|
||||
|
||||
在世界草稿生成完成后，用户反馈：
|
||||
|
||||
1. 草稿里看不到角色主形象
|
||||
2. 场景里看不到每一幕的背景图
|
||||
|
||||
这类反馈容易被误判成“自动资产没有生成”，但实际排查后发现，问题主要集中在**结果页展示链路**，同时叠加了一个**fallback 资源不可预览**的问题。
|
||||
|
||||
## 2. 链路排查结论
|
||||
|
||||
本轮检查后确认：
|
||||
|
||||
1. 服务端自动资产服务会把角色主形象写回 `draftProfile.playableNpcs[].imageSrc / generatedVisualAssetId`
|
||||
2. 服务端自动资产服务会把幕背景图写回 `draftProfile.sceneChapters[].acts[].backgroundImageSrc / backgroundAssetId`
|
||||
3. `agent draft -> result profile` 的适配层也会保留这些字段
|
||||
|
||||
真正的问题出在后续两个环节。
|
||||
|
||||
## 3. 根因
|
||||
|
||||
### 3.1 结果页可扮演角色卡优先用了运行时预览
|
||||
|
||||
结果页 `CustomWorldEntityCatalog` 的可扮演角色卡，之前优先显示：
|
||||
|
||||
1. `previewCharacter`
|
||||
2. 再回退到 `role.imageSrc`
|
||||
|
||||
这会导致：
|
||||
|
||||
1. 草稿里已经有真实生成主图
|
||||
2. 但界面仍优先渲染模板/运行时预览角色
|
||||
3. 用户视觉上看不到最新生成主形象
|
||||
|
||||
### 3.2 场景页没有把多幕背景图真正展示出来
|
||||
|
||||
结果页 `场景` Tab 之前只展示：
|
||||
|
||||
1. 开局场景
|
||||
2. 地点卡
|
||||
|
||||
但没有把：
|
||||
|
||||
`sceneChapterBlueprints[].acts[].backgroundImageSrc`
|
||||
|
||||
按可见结构渲染到结果页中。
|
||||
|
||||
因此即使后端已经生成并回写每一幕背景图，用户仍然只能看到“场景主图/地点图”，看不到“每一幕的图”。
|
||||
|
||||
### 3.3 fallback 自动资产写回的是 `.txt`
|
||||
|
||||
在没有 DashScope 图像能力时，`CustomWorldAgentAutoAssetService` 的 fallback 生成器之前会写：
|
||||
|
||||
1. 角色主形象：`master.txt`
|
||||
2. 幕背景图：`scene.txt`
|
||||
|
||||
这虽然保证了字段被回写，但前端无法把 `.txt` 当图片展示，于是会进一步加重“好像没生成”的感知。
|
||||
|
||||
### 3.4 Agent 结果页入口优先读取 legacyResultProfile，遮蔽了最新资产字段
|
||||
|
||||
世界草稿结果页不是直接读取当前 `draftProfile`，而是先经过：
|
||||
|
||||
1. `buildCustomWorldProfileFromAgentDraft`
|
||||
2. `normalizeCustomWorldProfileRecord`
|
||||
|
||||
如果 `draftProfile.legacyResultProfile` 存在，旧逻辑会直接优先返回这份历史编译结果。
|
||||
|
||||
但自动资产服务在 Phase3/Phase4 后续补齐时，更新的是当前 `draftProfile` 中的：
|
||||
|
||||
1. `playableNpcs[].imageSrc / generatedVisualAssetId`
|
||||
2. `storyNpcs[].imageSrc / generatedVisualAssetId`
|
||||
3. `landmarks[].imageSrc`
|
||||
4. `sceneChapters[].acts[].backgroundImageSrc / backgroundAssetId`
|
||||
|
||||
这会导致：
|
||||
|
||||
1. 服务端真实已经生成并回写了最新角色主图和分幕图
|
||||
2. 结果页入口却仍然取到一份更早的 `legacyResultProfile`
|
||||
3. 页面看到的是“旧草稿快照”，不是“当前带资产的草稿结果”
|
||||
|
||||
因此用户会表现为“完全看不到这轮刚生成出来的图片”。
|
||||
|
||||
## 4. 修复策略
|
||||
|
||||
### 4.1 结果页角色卡优先显示真实生成主图
|
||||
|
||||
在 `src/components/CustomWorldEntityCatalog.tsx` 中调整逻辑：
|
||||
|
||||
1. 若 `role.imageSrc` 已存在，则优先显示该图片
|
||||
2. 只有在缺失真实主图时，才回退到运行时角色预览
|
||||
|
||||
这样可扮演角色卡能直接展示当前草稿回写的角色主形象。
|
||||
|
||||
### 4.2 场景列表改为只展示场景卡，章节内容留在二级页
|
||||
|
||||
结合后续体验反馈，本轮又进一步收口了结果页结构：
|
||||
|
||||
1. `结果页 -> 场景列表` 不再直接展开章节与分幕内容
|
||||
2. 场景列表卡片只负责展示：
|
||||
- 场景名
|
||||
- 场景摘要
|
||||
- 场景图
|
||||
3. 场景卡图片优先取该场景章节的首幕 `backgroundImageSrc`
|
||||
4. 若首幕图缺失，再回退到场景主图 / 地标图
|
||||
5. 章节标题、幕标题、幕目标等信息只在点击场景后的二级编辑页中查看
|
||||
|
||||
这样结果页列表保持清爽，但用户仍然能在列表里直接看到当前场景已生成的图片。
|
||||
|
||||
### 4.3 fallback 改为可显示 PNG
|
||||
|
||||
在 `server-node/src/services/customWorldAgentAutoAssetService.ts` 中调整 fallback：
|
||||
|
||||
1. 不再写 `master.txt / scene.txt`
|
||||
2. 改为写合法可显示的占位 `png`
|
||||
3. prompt 信息单独写进 `manifest.json`
|
||||
4. 角色主形象 fallback PNG 统一输出为 `1:1`
|
||||
|
||||
这样即使当前环境没有真实图像生成能力，草稿层也仍然会回写“前端能直接显示的图片资源”。
|
||||
|
||||
### 4.4 结果页读取 legacy profile 时强制合并当前草稿的最新资产字段
|
||||
|
||||
在 `src/services/customWorldAgentDraftResult.ts` 中补上合并逻辑：
|
||||
|
||||
1. 若存在 `legacyResultProfile`，继续保留它的完整运行时字段
|
||||
2. 但会把当前 `draftProfile` 里最新回写的角色主图、地标图、分幕图再覆盖回结果页 profile
|
||||
3. 这样结果页既不会丢失旧 runtime profile 的完整结构，也不会再被旧快照遮蔽最新图片资产
|
||||
|
||||
这一层修的是结果页真实入口，而不是仅修展示组件。
|
||||
|
||||
## 5. 影响范围
|
||||
|
||||
本次修复涉及：
|
||||
|
||||
1. `src/components/CustomWorldEntityCatalog.tsx`
|
||||
2. `src/components/CustomWorldResultView.test.tsx`
|
||||
3. `src/services/customWorldAgentDraftResult.test.ts`
|
||||
4. `server-node/src/services/customWorldAgentAutoAssetService.ts`
|
||||
5. `server-node/src/services/customWorldAgentAutoAssetService.test.ts`
|
||||
6. `docs/technical/CUSTOM_WORLD_AUTO_ASSET_VISIBILITY_FIX_2026-04-20.md`
|
||||
7. 历史 saved profile 资产同步脚本 / 数据修复动作
|
||||
|
||||
## 6. 验收标准
|
||||
|
||||
修复后需要满足：
|
||||
|
||||
1. 世界草稿结果页的可扮演角色卡能直接看到生成主形象
|
||||
2. 世界草稿结果页的场景列表能直接看到场景图片，且优先展示首幕背景图
|
||||
3. 场景章节与分幕内容只在场景二级页中展示
|
||||
3. `agent draft -> result profile` 不会丢失角色主图与幕背景字段
|
||||
4. fallback 环境下回写的仍是前端可显示图片，而不是文本文件
|
||||
5. 角色主形象 fallback PNG 尺寸必须满足 `1:1`
|
||||
6. 即使存在 `legacyResultProfile`，结果页也必须展示当前草稿最新同步的角色主图与幕背景图
|
||||
|
||||
## 6.1 历史保存档案补充结论
|
||||
|
||||
本轮在真实 PostgreSQL 数据中又确认了一类历史问题：
|
||||
|
||||
1. `agent session` 中的草稿资产字段可能已经补齐
|
||||
2. 但较早时刻自动保存过的 `custom_world_profiles.payload_json` 仍停留在旧路径
|
||||
3. 用户如果从作品库打开的是 saved profile，就会继续看到旧图或空图
|
||||
|
||||
因此这次修复除了改默认生成与展示逻辑，还需要对受影响的历史 saved profile 做一次同步刷新。
|
||||
|
||||
## 7. 后续建议
|
||||
|
||||
后续继续迭代这条链路时，建议保持：
|
||||
|
||||
1. “资产已生成”必须和“用户已看见”同时验证，不能只验证字段回写
|
||||
2. 结果页与草稿工作区都要把多幕背景视为正式资产，不要只停留在编辑弹层里
|
||||
3. 所有 fallback 资源都应保持为 UI 可直接消费的媒体格式
|
||||
@@ -0,0 +1,149 @@
|
||||
# 世界草稿生成失败与等待页卡住问题分析 2026-04-20
|
||||
|
||||
更新时间：`2026-04-20`
|
||||
|
||||
## 1. 问题背景
|
||||
|
||||
本次问题表现为：
|
||||
|
||||
1. 世界草稿生成过程中实际已经失败。
|
||||
2. 前端等待页仍然停留在“编译草稿卡”步骤。
|
||||
3. 用户感知为“卡住不动”，而不是“这一轮失败了，可以返回或重试”。
|
||||
|
||||
这个问题不是单点 bug，而是由两类问题叠加造成：
|
||||
|
||||
1. 前端进度映射把 `failed + progress=100` 误解释成“已经跑到最后一个步骤附近”，导致视觉上像卡在 `编译草稿卡`。
|
||||
2. 服务端 `draft_foundation` 主链把自动资产补齐也视为硬依赖，一旦角色主形象或场景幕背景图失败，就会把整版世界底稿一起打成失败。
|
||||
|
||||
## 2. 本次链路梳理结论
|
||||
|
||||
当前世界草稿生成主链路为：
|
||||
|
||||
```text
|
||||
foundation_review
|
||||
-> draft_foundation action
|
||||
-> foundation draft service 生成世界底稿结构
|
||||
-> auto asset service 补角色主图与幕背景图
|
||||
-> draft compiler 编译 draftCards
|
||||
-> session 进入 object_refining
|
||||
-> 前端等待页切到结果或回工作区
|
||||
```
|
||||
|
||||
其中真正的“必须成功”主链只有两段：
|
||||
|
||||
1. `foundation draft` 结构生成成功。
|
||||
2. `draftCards` 编译成功。
|
||||
|
||||
角色主图与幕背景图属于增强链路，不应该阻断世界底稿首版落地。
|
||||
|
||||
## 3. 根因拆解
|
||||
|
||||
### 3.1 前端等待页状态映射问题
|
||||
|
||||
`src/services/customWorldAgentGenerationProgress.ts` 之前只对以下情况做了显式处理：
|
||||
|
||||
1. `completed`
|
||||
2. 匹配某个 `phaseLabel`
|
||||
3. 兜底按 `progress` 推断当前步骤
|
||||
|
||||
但没有对 `failed` 做单独分支。
|
||||
|
||||
于是当后端返回：
|
||||
|
||||
```text
|
||||
status = failed
|
||||
progress = 100
|
||||
phaseLabel = 底稿生成失败
|
||||
```
|
||||
|
||||
前端仍会按 `progress=100` 去推断步骤，结果高概率落在末尾附近，视觉上就像卡在：
|
||||
|
||||
```text
|
||||
编译草稿卡
|
||||
```
|
||||
|
||||
### 3.2 服务端把增强链路当成硬依赖
|
||||
|
||||
`server-node/src/services/customWorldAgentOrchestrator.ts` 中的 `processDraftFoundationOperation` 会在世界底稿生成后调用：
|
||||
|
||||
```ts
|
||||
autoAssetService.populateDraftAssets(...)
|
||||
```
|
||||
|
||||
而 `populateDraftAssets` 之前的行为是：
|
||||
|
||||
1. 角色主图生成失败直接 throw
|
||||
2. 场景幕背景图生成失败直接 throw
|
||||
|
||||
于是自动资产失败会直接中断后续：
|
||||
|
||||
```text
|
||||
draft compiler
|
||||
session replaceDerivedState
|
||||
checkpoint
|
||||
assistant summary
|
||||
operation completed
|
||||
```
|
||||
|
||||
这会把“本来已经可以用的世界底稿”一并拖死。
|
||||
|
||||
## 4. 修复策略
|
||||
|
||||
### 4.1 前端修复
|
||||
|
||||
在 `src/services/customWorldAgentGenerationProgress.ts` 中新增显式失败步骤：
|
||||
|
||||
1. `failed` 状态不再走 `progress` 推断。
|
||||
2. 失败时固定返回 `phaseId = failed`。
|
||||
3. 等待页保留已有步骤清单，但不再假装仍有某一步处于 active。
|
||||
|
||||
修复后，等待页会明确展示：
|
||||
|
||||
1. 当前状态已失败
|
||||
2. 失败文案与失败详情
|
||||
3. 用户可以返回工作区或重新生成
|
||||
|
||||
### 4.2 服务端修复
|
||||
|
||||
在 `server-node/src/services/customWorldAgentAutoAssetService.ts` 中把自动资产改成“尽力而为”：
|
||||
|
||||
1. 角色主形象生成失败时不再 throw，而是记录 warning。
|
||||
2. 幕背景图生成失败时不再 throw，而是记录 warning。
|
||||
3. 主链继续编译 `draftCards`，并让 `assetCoverage` 明确标记哪些资产仍缺失。
|
||||
|
||||
在 `server-node/src/services/customWorldAgentOrchestrator.ts` 中：
|
||||
|
||||
1. 如果草稿主链成功，只是资产补齐未完成，则 operation 仍记为 `completed`。
|
||||
2. `phaseDetail` 增加“有若干项资产补齐待后续处理”的说明。
|
||||
3. assistant summary 也同步说明“这不影响继续精修世界底稿”。
|
||||
4. 真正失败时，优先保留当前失败阶段的 `phaseLabel/phaseDetail`，避免统一抹平成模糊的“底稿生成失败”。
|
||||
|
||||
## 5. 影响范围
|
||||
|
||||
本次修改影响以下模块：
|
||||
|
||||
1. `src/services/customWorldAgentGenerationProgress.ts`
|
||||
2. `src/services/customWorldAgentGenerationProgress.test.ts`
|
||||
3. `server-node/src/services/customWorldAgentAutoAssetService.ts`
|
||||
4. `server-node/src/services/customWorldAgentAutoAssetService.test.ts`
|
||||
5. `server-node/src/services/customWorldAgentOrchestrator.ts`
|
||||
6. `server-node/src/services/customWorldAgentPhase3.test.ts`
|
||||
|
||||
## 6. 验收标准
|
||||
|
||||
修复后需要满足：
|
||||
|
||||
1. 世界草稿主链失败时，等待页明确显示失败，而不是视觉上卡在 `编译草稿卡`。
|
||||
2. 自动资产生成失败时，世界底稿和草稿卡仍然要能生成完成。
|
||||
3. session 能进入 `object_refining`，用户可以先继续精修结构内容。
|
||||
4. `assetCoverage` 能反映未补齐的角色图/场景图缺口。
|
||||
5. 助手消息和 operation 文案都能把“主链完成，增强链路待补”表达清楚。
|
||||
|
||||
## 7. 后续建议
|
||||
|
||||
后续若继续增强这条链路，建议保持以下原则：
|
||||
|
||||
1. 世界结构生成、草稿卡编译属于主链，必须最稳。
|
||||
2. 角色图、动作、场景图、长尾补齐都属于增强链路，应允许降级。
|
||||
3. 所有等待页都要有显式失败态映射，禁止仅靠 `progress` 推断最终阶段。
|
||||
4. 操作失败时优先保留最后一个真实阶段标签，方便定位到底是结构生成失败、资产生成失败，还是写回失败。
|
||||
@@ -0,0 +1,115 @@
|
||||
# 自定义世界 Phase4 数量字段语义对齐说明 2026-04-20
|
||||
|
||||
更新时间：`2026-04-20`
|
||||
|
||||
## 1. 背景
|
||||
|
||||
在排查世界草稿生成等待页问题后，继续执行 `server-node` 相关测试时，发现 Phase4 仍有两处失败：
|
||||
|
||||
1. `generate_characters` 后草稿作品卡的角色数量没有按预期增长。
|
||||
2. `generate_landmarks` 的 HTTP 用例对地点数量使用了过时的固定基线。
|
||||
|
||||
这两个问题本质上都和“数量字段语义不一致”有关。
|
||||
|
||||
## 2. 当前产品语义
|
||||
|
||||
创作中心草稿卡在前端展示的是：
|
||||
|
||||
```text
|
||||
角色 X
|
||||
地点 Y
|
||||
```
|
||||
|
||||
这里的“角色”从产品感知上表示：
|
||||
|
||||
**当前草稿中已经长出来、可继续精修的全部角色对象数量。**
|
||||
|
||||
而不是：
|
||||
|
||||
**仅 playable / 仅主角位角色数量。**
|
||||
|
||||
对应地，“地点”表示：
|
||||
|
||||
**当前草稿中已经存在的地点对象数量。**
|
||||
|
||||
## 3. 之前的偏差
|
||||
|
||||
### 3.1 角色数量偏差
|
||||
|
||||
`server-node/src/services/customWorldWorkSummaryService.ts` 在草稿态里原先只统计：
|
||||
|
||||
```ts
|
||||
draftProfile.playableNpcs.length
|
||||
```
|
||||
|
||||
但 Phase4 `generate_characters` 的实现是把新增角色插入：
|
||||
|
||||
```ts
|
||||
draftProfile.storyNpcs
|
||||
```
|
||||
|
||||
所以会出现：
|
||||
|
||||
1. 角色卡确实新增了
|
||||
2. `storyNpcs` 也确实变多了
|
||||
3. 创作中心草稿卡上的“角色数”却没有同步增加
|
||||
|
||||
这会让产品表现和数据真实状态不一致。
|
||||
|
||||
### 3.2 地点数量断言偏差
|
||||
|
||||
`server-node/src/app.test.ts` 的 `generate_landmarks` HTTP 用例里，之前写死了：
|
||||
|
||||
```ts
|
||||
assert.ok((sessionPayload.draftProfile?.landmarks?.length ?? 0) >= 6);
|
||||
```
|
||||
|
||||
但当前基础草稿阶段的地点基线已经调整为：
|
||||
|
||||
```ts
|
||||
FOUNDATION_DRAFT_LANDMARK_COUNT = 2
|
||||
```
|
||||
|
||||
所以 Phase4 的正确断言应该是：
|
||||
|
||||
```text
|
||||
在当前会话已有地点基线上，再新增 2 个地点
|
||||
```
|
||||
|
||||
而不是继续沿用旧版本里“基础草稿默认至少 4 个地点”的固定假设。
|
||||
|
||||
## 4. 本次修正
|
||||
|
||||
### 4.1 草稿摘要角色数
|
||||
|
||||
草稿态 `playableNpcCount` 在工作摘要里继续沿用既有字段名，但统计语义调整为：
|
||||
|
||||
```text
|
||||
全部草稿角色数量 = playableNpcs + storyNpcs 去重后的总数
|
||||
```
|
||||
|
||||
原因：
|
||||
|
||||
1. 前端现有 contract 和展示字段已经复用 `playableNpcCount`
|
||||
2. 这次目标是最小修复，不额外扩 contract
|
||||
3. 草稿态 UI 标签本身展示的是“角色”，不是“可扮演角色”
|
||||
|
||||
因此这次保留字段名，修正其在草稿态的统计语义。
|
||||
|
||||
### 4.2 Phase4 地点断言
|
||||
|
||||
`generate_landmarks` 的 HTTP 用例改为基于当前会话的 `draftProfile.landmarks.length` 做增量校验：
|
||||
|
||||
```text
|
||||
新增后数量 >= 基线数量 + 2
|
||||
```
|
||||
|
||||
这样可以避免未来基础草稿默认地点数再次调整时，Phase4 用例继续被写死基线误伤。
|
||||
|
||||
## 5. 约束建议
|
||||
|
||||
后续涉及草稿作品卡数量字段时，统一遵守：
|
||||
|
||||
1. 草稿态“角色”展示全部草稿角色数，不只统计 playable。
|
||||
2. 已发布态如果 UI 明确写“可扮演角色”，再单独按 playable 统计。
|
||||
3. 所有数量断言优先使用“当前基线 + 增量”的写法，不要硬编码旧阶段默认数量。
|
||||
@@ -77,7 +77,7 @@ src/prompts/
|
||||
- `customWorldSceneNpcPrompts.ts`
|
||||
- 世界编辑器场景 NPC 生成 prompt
|
||||
- `characterAssetPrompts.ts`
|
||||
- 角色主图 / 动作试片 / 角色关联场景 prompt
|
||||
- 角色主图 / 动作试片正式生成 prompt
|
||||
- `eightAnchorPrompts.ts`
|
||||
- 八锚点状态推断、模式规则与正式单轮共创 prompt
|
||||
- `src/prompts/customWorldPrompts.ts`
|
||||
@@ -85,7 +85,7 @@ src/prompts/
|
||||
- `src/prompts/qwenSpriteSheetToolPrompts.ts`
|
||||
- 精灵图工具主词 / 分镜词 / 修帧词 / 负面词
|
||||
- `src/prompts/customWorldRolePromptDefaults.ts`
|
||||
- 角色资产工作台默认 prompt 种子
|
||||
- 角色资产工作台默认 prompt 种子唯一主源
|
||||
- `src/prompts/customWorldEntityActionPrompts.ts`
|
||||
- 编辑器技能动作 prompt
|
||||
- `packages/shared/src/prompts/qwenSprite.ts`
|
||||
|
||||
@@ -6,6 +6,10 @@
|
||||
|
||||
- [REPO_NOISE_CLEANUP_BASELINE_2026-04-19.md](./REPO_NOISE_CLEANUP_BASELINE_2026-04-19.md)：落实工程清理审计第一阶段后的仓库噪音清理范围、忽略规则闭合点与后续约束。
|
||||
- [PROMPT_DIRECTORY_MANAGEMENT_2026-04-19.md](./PROMPT_DIRECTORY_MANAGEMENT_2026-04-19.md)：后端提示词收口到 `server-node/src/prompts/` 的目录方案、兼容策略与后续新增规则。
|
||||
- [CUSTOM_WORLD_DRAFT_GENERATION_FAILURE_ANALYSIS_AND_FIX_2026-04-20.md](./CUSTOM_WORLD_DRAFT_GENERATION_FAILURE_ANALYSIS_AND_FIX_2026-04-20.md)：世界草稿生成失败后等待页误显示为“卡在编译草稿卡”的根因拆解、主链与增强链路边界，以及本次修复策略。
|
||||
- [CUSTOM_WORLD_AUTO_ASSET_VISIBILITY_FIX_2026-04-20.md](./CUSTOM_WORLD_AUTO_ASSET_VISIBILITY_FIX_2026-04-20.md)：世界草稿里“资产已生成但结果页看不到”的根因拆解，包含角色主形象展示、分幕背景露出和 fallback 资源格式修复。
|
||||
- [CUSTOM_WORLD_PHASE4_COUNT_SEMANTICS_ALIGNMENT_2026-04-20.md](./CUSTOM_WORLD_PHASE4_COUNT_SEMANTICS_ALIGNMENT_2026-04-20.md)：Phase4 新增角色/地点后草稿作品卡数量统计与测试断言的语义对齐说明。
|
||||
- [TXT_MODE_VISUAL_NOVEL_MIGRATION_EXECUTION_PLAN_2026-04-20.md](./TXT_MODE_VISUAL_NOVEL_MIGRATION_EXECUTION_PLAN_2026-04-20.md)：把外部仓库 TXT 模式完整迁入当前项目的冻结边界、模块映射、分阶段计划与验收清单。
|
||||
- [NODE_SERVER_KNOWLEDGE_GRAPH_2026-04-08.md](./NODE_SERVER_KNOWLEDGE_GRAPH_2026-04-08.md)：当前 Node 运行时后端的技术栈、入口、鉴权、存储与接口知识图谱。
|
||||
- [EXPRESS_BACKEND_INTEGRATION_FREEZE_2026-04-09.md](./EXPRESS_BACKEND_INTEGRATION_FREEZE_2026-04-09.md)：Express 后端当前 contract 冻结版本、热点文件编辑规则与集成窗口清单。
|
||||
- [EXPRESS_BACKEND_WORKSTREAM_AUDIT_2026-04-09.md](./EXPRESS_BACKEND_WORKSTREAM_AUDIT_2026-04-09.md)：按并行工作流文档逐项核对后的完成度审计与剩余收口点。
|
||||
|
||||
@@ -69,6 +69,11 @@
|
||||
7. 角色槽位会把第一槽位写回 `primaryNpcId`，其余槽位顺序压缩写回 `encounterNpcIds`
|
||||
8. 每幕已补上“幕预览”入口，点击后会以独立全屏层启动当前幕运行时预览
|
||||
9. 保存场景时会把幕配置同步写回 `CustomWorldProfile.sceneChapterBlueprints`
|
||||
10. 世界档案里的场景详情页已移除“场景图片”和“场景内 NPC”字段，相关兼容字段改为从多幕配置自动同步回 `imageSrc / sceneNpcIds`
|
||||
|
||||
补充一条等待页体验收口：
|
||||
|
||||
10. 世界草稿生成等待页的第二模块标题已从“当前锚点信息”收口为“当前世界信息”，不再显示辅助说明小字，也不再在该模块头部提供“回到工作区”按钮，避免等待态出现重复返回入口
|
||||
|
||||
## 2.5 运行时基础层
|
||||
|
||||
@@ -82,6 +87,7 @@
|
||||
6. 幕编辑中的 3 个角色槽位已进一步收敛成贴在背景图上的站位式角色预览，交互与幕预览保持同一位置语义，只显示角色形象与名称
|
||||
7. 幕预览运行时已补 custom world NPC 的视觉兜底链路，优先使用 `visual / imageSrc` 渲染，避免角色形象或动画空白
|
||||
8. 当前幕小预览已调整为左侧玩家、右侧敌对/相遇角色的构图，NPC 站位采用一前两后
|
||||
前排主角色与玩家角色保持同一 y 轴；后排两个角色改为同一列、x 轴对齐并上下分布，且后排整体 y 轴中点与前排主角色一致
|
||||
9. 新增幕默认只带 1 个主角色，后续槽位由创作者按需补充
|
||||
10. 小预览里的名字已移动到角色头顶，角色渲染不再带方形底板，避免遮挡场景背景
|
||||
|
||||
@@ -95,6 +101,9 @@
|
||||
4. 第 `5` 轮会由后端 prompt 强约束生成“铺垫式收束”回复，不再继续生成下一轮聊天建议
|
||||
5. 第 `5` 轮返回后，前端会自动清掉 `npcChatState`，隐藏输入框，并给出 `继续` 的后续推进入口
|
||||
6. Adventure 面板会显示当前幕标题与有限聊天剩余轮数
|
||||
7. 当前幕主角色在本地战斗胜利后，会重新回到 NPC 聊天态，而不是直接掉回普通剧情续写
|
||||
8. 战后重新开启的聊天会把“战斗结果摘要 + 最近战斗日志”一起写入 `npc_chat` 上下文，保证 NPC 能承接刚刚那场交锋继续说话
|
||||
9. 若该主角色当前好感仍小于 `0`，战后重新开启的聊天仍按 `5` 轮有限聊天处理，轮数从战后这次重开重新计算
|
||||
|
||||
## 3. 当前仍未完成
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user