Merge remote-tracking branch 'origin/master' into codex/ddd
# Conflicts: # docs/technical/README.md # docs/technical/RUST_API_SERVER_ROUTE_INDEX_2026-04-22.md # docs/technical/SPACETIMEDB_TABLE_CATALOG.md # scripts/generate-spacetime-bindings.mjs # server-rs/crates/api-server/src/app.rs # server-rs/crates/api-server/src/assets.rs # server-rs/crates/api-server/src/big_fish.rs # server-rs/crates/api-server/src/custom_world_ai.rs # server-rs/crates/api-server/src/llm.rs # server-rs/crates/api-server/src/main.rs # server-rs/crates/api-server/src/puzzle.rs # server-rs/crates/api-server/src/runtime_profile.rs # server-rs/crates/api-server/src/runtime_story/compat/ai.rs # server-rs/crates/api-server/src/runtime_story/compat/npc_actions.rs # server-rs/crates/api-server/src/runtime_story/compat/presentation.rs # server-rs/crates/api-server/src/runtime_story/compat/tests.rs # server-rs/crates/api-server/src/state.rs # server-rs/crates/module-auth/src/lib.rs # server-rs/crates/module-big-fish/src/lib.rs # server-rs/crates/module-custom-world/src/lib.rs # server-rs/crates/module-puzzle/src/lib.rs # server-rs/crates/module-runtime/src/lib.rs # server-rs/crates/spacetime-client/src/big_fish.rs # server-rs/crates/spacetime-client/src/lib.rs # server-rs/crates/spacetime-client/src/mapper.rs # server-rs/crates/spacetime-client/src/module_bindings/admin_disable_profile_redeem_code_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/admin_upsert_profile_redeem_code_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/advance_puzzle_next_level_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/append_ai_text_chunk_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/apply_chapter_progression_ledger_entry_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/attach_ai_result_reference_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/authorize_database_migration_operator_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/begin_story_session_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/big_fish_runtime_run_type.rs # server-rs/crates/spacetime-client/src/module_bindings/bind_asset_object_to_entity_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/cancel_ai_task_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/clear_platform_browse_history_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/compile_big_fish_draft_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/compile_custom_world_published_profile_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/compile_puzzle_agent_draft_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/complete_ai_stage_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/complete_ai_task_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/confirm_asset_object_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/consume_profile_wallet_points_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/continue_story_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/create_ai_task_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/create_battle_state_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/create_big_fish_session_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/create_custom_world_agent_session_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/create_profile_recharge_order_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/create_puzzle_agent_session_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/delete_big_fish_work_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/delete_custom_world_agent_session_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/delete_custom_world_profile_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/delete_puzzle_work_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/delete_runtime_snapshot_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/drag_puzzle_piece_or_group_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/execute_custom_world_agent_action_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/export_auth_store_snapshot_from_tables_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/export_database_migration_to_file_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/fail_ai_task_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/finalize_big_fish_agent_message_turn_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/finalize_custom_world_agent_message_turn_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/finalize_puzzle_agent_message_turn_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/generate_big_fish_asset_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_auth_store_snapshot_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_battle_state_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_big_fish_session_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_chapter_progression_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_custom_world_agent_card_detail_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_custom_world_agent_operation_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_custom_world_agent_session_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_custom_world_gallery_detail_by_code_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_custom_world_gallery_detail_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_custom_world_library_detail_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_player_progression_or_default_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_profile_dashboard_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_profile_play_stats_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_profile_recharge_center_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_profile_referral_invite_center_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_puzzle_agent_session_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_puzzle_gallery_detail_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_puzzle_run_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_puzzle_work_detail_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_runtime_inventory_state_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_runtime_setting_or_default_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_runtime_snapshot_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/get_story_session_state_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/grant_player_progression_experience_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/import_auth_store_snapshot_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/import_database_migration_from_file_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/import_database_migration_incremental_from_file_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/list_asset_history_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/list_big_fish_works_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/list_custom_world_gallery_entries_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/list_custom_world_profiles_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/list_custom_world_works_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/list_platform_browse_history_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/list_profile_save_archives_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/list_profile_wallet_ledger_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/list_puzzle_gallery_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/list_puzzle_works_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/mod.rs # server-rs/crates/spacetime-client/src/module_bindings/publish_big_fish_game_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/publish_custom_world_profile_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/publish_custom_world_world_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/publish_puzzle_work_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/record_big_fish_play_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/redeem_profile_referral_invite_code_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/redeem_profile_reward_code_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/refund_profile_wallet_points_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/resolve_combat_action_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/resolve_npc_battle_interaction_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/resolve_npc_interaction_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/resolve_npc_social_action_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/resolve_treasure_interaction_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/resume_profile_save_archive_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/revoke_database_migration_operator_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/save_puzzle_generated_images_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/select_puzzle_cover_image_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/start_puzzle_run_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/submit_big_fish_message_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/submit_custom_world_agent_message_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/submit_puzzle_agent_message_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/submit_puzzle_leaderboard_entry_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/swap_puzzle_pieces_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/unpublish_custom_world_profile_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/update_puzzle_work_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/upsert_auth_store_snapshot_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/upsert_chapter_progression_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/upsert_custom_world_agent_operation_progress_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/upsert_custom_world_profile_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/upsert_npc_state_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/upsert_platform_browse_history_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/upsert_runtime_setting_and_return_procedure.rs # server-rs/crates/spacetime-client/src/module_bindings/upsert_runtime_snapshot_and_return_procedure.rs # server-rs/crates/spacetime-module/src/auth/procedures.rs # server-rs/crates/spacetime-module/src/custom_world/mod.rs # server-rs/crates/spacetime-module/src/lib.rs # server-rs/crates/spacetime-module/src/migration.rs # server-rs/crates/spacetime-module/src/puzzle.rs # server-rs/crates/spacetime-module/src/runtime/profile.rs # src/components/platform-entry/PlatformEntryFlowShellImpl.tsx # src/components/rpg-entry/RpgEntryFlowShell.agent.interaction.test.tsx # src/services/aiService.ts # src/services/puzzle-runtime/puzzleRuntimeClient.ts
This commit is contained in:
+3
-1
@@ -11,7 +11,9 @@
|
||||
- [规划与优先级](./planning/README.md):当前阶段的迭代排序与落地优先级。
|
||||
- [参考目录](./reference/README.md):脚本/Function 速查入口。
|
||||
重点补充:RPG 创作与运行时脚本职责地图见 [RPG_CREATION_AND_RUNTIME_SCRIPT_RESPONSIBILITY_MAP_2026-04-28.md](./reference/RPG_CREATION_AND_RUNTIME_SCRIPT_RESPONSIBILITY_MAP_2026-04-28.md)。
|
||||
- [PRD](./prd):产品需求与阶段计划;新增 RPG 开场动画方案见 [AI_NATIVE_RPG_OPENING_ANIMATION_PRD_2026-04-25.md](./prd/AI_NATIVE_RPG_OPENING_ANIMATION_PRD_2026-04-25.md)。
|
||||
- [PRD](./prd):产品需求与阶段计划;后台管理独立前端工程见 [ADMIN_WEB_CONSOLE_PRD_2026-04-30.md](./prd/ADMIN_WEB_CONSOLE_PRD_2026-04-30.md),新增 RPG 开场动画方案见 [AI_NATIVE_RPG_OPENING_ANIMATION_PRD_2026-04-25.md](./prd/AI_NATIVE_RPG_OPENING_ANIMATION_PRD_2026-04-25.md),新增抓大鹅 Match3D 玩法方案见 [AI_NATIVE_MATCH3D_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-04-30.md](./prd/AI_NATIVE_MATCH3D_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-04-30.md)。
|
||||
|
||||
SpacetimeDB 表结构变更、自动迁移边界和保留旧数据的分阶段迁移流程见 [SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md](./technical/SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md);private 表迁移 JSON 导入导出、HTTP 413 分片导入和 Jenkins 数据库迁移流水线见 [SPACETIMEDB_JSON_STRING_MIGRATION_PROCEDURE_2026-04-27.md](./technical/SPACETIMEDB_JSON_STRING_MIGRATION_PROCEDURE_2026-04-27.md) 与 [JENKINS_SPACETIMEDB_DATABASE_MIGRATION_PIPELINES_2026-04-29.md](./technical/JENKINS_SPACETIMEDB_DATABASE_MIGRATION_PIPELINES_2026-04-29.md);后台管理独立前端工程技术方案见 [ADMIN_WEB_CONSOLE_TECHNICAL_SOLUTION_2026-04-30.md](./technical/ADMIN_WEB_CONSOLE_TECHNICAL_SOLUTION_2026-04-30.md)。
|
||||
|
||||
SpacetimeDB 表结构变更、自动迁移边界和保留旧数据的分阶段迁移流程见 [SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md](./technical/SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md)。
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
当前自定义世界创作工具已经有了比较强的生成骨架、锚点结构和结果编辑能力,但整体仍处在一个很明显的“半收口状态”:
|
||||
|
||||
**设计目标已经走到“创作者工作台”,数据结构已经支持“锚点化输入”,但实际体验仍然更像“大文本生成器 + 大型结果总表编辑器”。**
|
||||
**设计目标已经走到“百梦主工作台”,数据结构已经支持“锚点化输入”,但实际体验仍然更像“大文本生成器 + 大型结果总表编辑器”。**
|
||||
|
||||
如果用一句话概括当前问题,就是:
|
||||
|
||||
@@ -61,7 +61,7 @@
|
||||
- 标志性要素
|
||||
- 禁止事项
|
||||
|
||||
但实际入口 `src/components/SelectionCustomizationModals.tsx` 里,创作者弹窗仍然基本只有:
|
||||
但实际入口 `src/components/SelectionCustomizationModals.tsx` 里,百梦主弹窗仍然基本只有:
|
||||
|
||||
- 生成模式
|
||||
- 一块大 textarea
|
||||
@@ -82,7 +82,7 @@
|
||||
|
||||
---
|
||||
|
||||
## 2.2 澄清机制已经存在,但没有真正服务创作者
|
||||
## 2.2 澄清机制已经存在,但没有真正服务百梦主
|
||||
|
||||
`server-node/src/services/customWorldSessionStore.ts` 已经支持:
|
||||
|
||||
@@ -101,7 +101,7 @@
|
||||
|
||||
这意味着:
|
||||
|
||||
**系统表面上已经有“先澄清再生成”的能力,但实际体验里,创作者并没有真正参与这一步。**
|
||||
**系统表面上已经有“先澄清再生成”的能力,但实际体验里,百梦主并没有真正参与这一步。**
|
||||
|
||||
结果就是:
|
||||
|
||||
@@ -113,7 +113,7 @@
|
||||
|
||||
- 把 session question 真正接到前端,作为生成前的二次确认步骤。
|
||||
- 每次只问 `1~3` 个最关键问题,不要把它做成问卷。
|
||||
- 支持“一键使用系统建议”,但必须让创作者可见,而不是静默自动填充。
|
||||
- 支持“一键使用系统建议”,但必须让百梦主可见,而不是静默自动填充。
|
||||
- 把回答结果回写到 `creatorIntent`,而不是只作为一次性会话答案。
|
||||
|
||||
---
|
||||
@@ -175,7 +175,7 @@
|
||||
|
||||
这会带来三层问题:
|
||||
|
||||
1. 创作者负担过重
|
||||
1. 百梦主负担过重
|
||||
- 很多字段属于“系统编译层”,不属于“创作决策层”。
|
||||
|
||||
2. 移动端负担过重
|
||||
@@ -240,7 +240,7 @@
|
||||
|
||||
---
|
||||
|
||||
## 2.6 快速模式还不够“快”,生成页也还不够“创作者视角”
|
||||
## 2.6 快速模式还不够“快”,生成页也还不够“百梦主视角”
|
||||
|
||||
当前快速模式的主要区别,是把数量降成:
|
||||
|
||||
@@ -269,7 +269,7 @@
|
||||
- 计时
|
||||
- 模型阶段
|
||||
|
||||
而不是创作者真正关心的:
|
||||
而不是百梦主真正关心的:
|
||||
|
||||
- 关键角色有没有成型
|
||||
- 核心冲突有没有稳定
|
||||
@@ -281,7 +281,7 @@
|
||||
- 快速模式改成真正的“关键锚点预览模式”:
|
||||
- 先只生成关键角色、关键地点、核心冲突摘要
|
||||
- 暂不补全所有长尾档案
|
||||
- 生成页改成“创作者视角进度”:
|
||||
- 生成页改成“百梦主视角进度”:
|
||||
- 世界灵魂已确定
|
||||
- 关键角色已成型
|
||||
- 关键地点已落地
|
||||
@@ -391,16 +391,16 @@
|
||||
### P0:先修主链路闭环
|
||||
|
||||
- 补卡片化输入入口,至少把关键锚点输入真正开放出来。
|
||||
- 把澄清问题正式接入创作者流程,不再静默自动兜底。
|
||||
- 把澄清问题正式接入百梦主流程,不再静默自动兜底。
|
||||
- 修正“新建完成后直接回世界列表”的流程,生成后默认进入结果工作台。
|
||||
- 统一锁定与局部重生成规则,先让“创作者不怕重生成”成立。
|
||||
- 统一锁定与局部重生成规则,先让“百梦主不怕重生成”成立。
|
||||
|
||||
### P1:再降低工作台负担
|
||||
|
||||
- 结果页默认只展示高杠杆编辑。
|
||||
- 低杠杆字段进入高级模式。
|
||||
- 快速模式改成真正的关键对象预览模式。
|
||||
- 生成页改成创作者视角进度,而不是模型批次视角。
|
||||
- 生成页改成百梦主视角进度,而不是模型批次视角。
|
||||
|
||||
### P2:最后做架构收口与去模板化
|
||||
|
||||
@@ -441,4 +441,4 @@
|
||||
|
||||
当前自定义世界创作工具最需要的,不是再继续补更多字段或更多生成步骤,而是:
|
||||
|
||||
**把“创作者先决定灵魂锚点,系统再稳定展开世界”这条主逻辑真正落到 UI、流程和后端边界上。**
|
||||
**把“百梦主先决定灵魂锚点,系统再稳定展开世界”这条主逻辑真正落到 UI、流程和后端边界上。**
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# 自定义世界创作者输入与 AI 分工边界设计
|
||||
# 自定义世界百梦主输入与 AI 分工边界设计
|
||||
|
||||
更新时间:`2026-04-06`
|
||||
|
||||
@@ -6,9 +6,9 @@
|
||||
|
||||
这份文档回答一个非常关键的问题:
|
||||
|
||||
**在“低创作门槛、高创作自由度”的前提下,自定义世界里哪些内容应该交给创作者直接定义,哪些内容应该交给 AI 和系统完成。**
|
||||
**在“低创作门槛、高创作自由度”的前提下,自定义世界里哪些内容应该交给百梦主直接定义,哪些内容应该交给 AI 和系统完成。**
|
||||
|
||||
这里默认我们的创作者:
|
||||
这里默认我们的百梦主:
|
||||
|
||||
- 不需要有专业作家背景
|
||||
- 不需要有专业游戏设计背景
|
||||
@@ -16,33 +16,33 @@
|
||||
|
||||
一句话目标:
|
||||
|
||||
**让创作者把精力放在“决定这个世界为什么值得被创作”,把 AI 用在“把这个世界展开、编译、铺开、校验、补足”。**
|
||||
**让百梦主把精力放在“决定这个世界为什么值得被创作”,把 AI 用在“把这个世界展开、编译、铺开、校验、补足”。**
|
||||
|
||||
## 1. 总体结论
|
||||
|
||||
自定义世界的分工边界应该遵守 3 条硬原则:
|
||||
|
||||
1. 灵魂归创作者,杂活归 AI。
|
||||
- 凡是决定作品气质、主题、冲突、人物关系、审美方向的内容,都应由创作者掌握。
|
||||
1. 灵魂归百梦主,杂活归 AI。
|
||||
- 凡是决定作品气质、主题、冲突、人物关系、审美方向的内容,都应由百梦主掌握。
|
||||
|
||||
2. 重点对象归创作者,长尾铺量归 AI。
|
||||
- 创作者应重点塑造少量关键角色、关键地点、关键冲突、关键意象,而不是被迫手填几十个 NPC、几十个场景、几百条描述。
|
||||
2. 重点对象归百梦主,长尾铺量归 AI。
|
||||
- 百梦主应重点塑造少量关键角色、关键地点、关键冲突、关键意象,而不是被迫手填几十个 NPC、几十个场景、几百条描述。
|
||||
|
||||
3. 决策归创作者,编译归 AI / 系统。
|
||||
- 创作者负责说“这个世界要成为什么样”,AI / 系统负责把它编译成可运行的数据、规则、文本、关系钩子和运行时结构。
|
||||
3. 决策归百梦主,编译归 AI / 系统。
|
||||
- 百梦主负责说“这个世界要成为什么样”,AI / 系统负责把它编译成可运行的数据、规则、文本、关系钩子和运行时结构。
|
||||
|
||||
这意味着:
|
||||
|
||||
- 创作者应该主要编辑“高杠杆创作锚点”
|
||||
- 百梦主应该主要编辑“高杠杆创作锚点”
|
||||
- AI 应该主要承担“批量展开 + 结构编译 + 一致性维护 + 专业执行”
|
||||
|
||||
## 2. 什么内容应该交给创作者
|
||||
## 2. 什么内容应该交给百梦主
|
||||
|
||||
真正应该交给创作者的,不是大量表格字段,而是下面这些会显著决定作品质量、且 AI 不擅长替代的内容。
|
||||
真正应该交给百梦主的,不是大量表格字段,而是下面这些会显著决定作品质量、且 AI 不擅长替代的内容。
|
||||
|
||||
## 2.1 世界核心命题
|
||||
|
||||
创作者应该直接定义:
|
||||
百梦主应该直接定义:
|
||||
|
||||
- 这个世界的一句话设定
|
||||
- 这个世界最吸引人的核心幻想
|
||||
@@ -56,7 +56,7 @@
|
||||
|
||||
## 2.2 主题、气质与边界
|
||||
|
||||
创作者应该直接定义:
|
||||
百梦主应该直接定义:
|
||||
|
||||
- 主题关键词
|
||||
- 情绪基调
|
||||
@@ -71,7 +71,7 @@
|
||||
|
||||
## 2.3 玩家身份与开局处境
|
||||
|
||||
创作者应该直接定义:
|
||||
百梦主应该直接定义:
|
||||
|
||||
- 玩家扮演的是什么人
|
||||
- 玩家一开始最缺什么、最想要什么
|
||||
@@ -85,7 +85,7 @@
|
||||
|
||||
## 2.4 核心冲突与关键势力
|
||||
|
||||
创作者应该直接定义少量高价值内容:
|
||||
百梦主应该直接定义少量高价值内容:
|
||||
|
||||
- 世界当前最重要的 `2~4` 条明面冲突
|
||||
- 世界背后最关键的 `1~3` 条暗面问题
|
||||
@@ -96,13 +96,13 @@
|
||||
|
||||
- 冲突结构决定世界是否“有戏”
|
||||
- 势力关系是 AI 最容易写散、写平、写成百科介绍的部分
|
||||
- 这一层由创作者把握,才能真正提高作品的辨识度
|
||||
- 这一层由百梦主把握,才能真正提高作品的辨识度
|
||||
|
||||
## 2.5 关键角色与关系张力
|
||||
|
||||
创作者应该直接定义少量关键角色,而不是所有 NPC。
|
||||
百梦主应该直接定义少量关键角色,而不是所有 NPC。
|
||||
|
||||
建议重点交给创作者的,是:
|
||||
建议重点交给百梦主的,是:
|
||||
|
||||
- `3~8` 个关键角色
|
||||
- 玩家与这些人的潜在关系
|
||||
@@ -113,11 +113,11 @@
|
||||
|
||||
- 角色关系是最能显著提升作品质量的部分之一
|
||||
- 这也是 AI 最容易写得“完整但无味”的部分
|
||||
- 创作者不需要写长篇背景,但应掌握这些角色真正的关系骨架
|
||||
- 百梦主不需要写长篇背景,但应掌握这些角色真正的关系骨架
|
||||
|
||||
## 2.6 关键地点与空间记忆点
|
||||
|
||||
创作者应该直接定义:
|
||||
百梦主应该直接定义:
|
||||
|
||||
- `4~12` 个关键地点 / 区域 / 地标
|
||||
- 这些地方为什么重要
|
||||
@@ -131,7 +131,7 @@
|
||||
|
||||
## 2.7 标志性意象、物件、怪物、制度与规则
|
||||
|
||||
创作者应该优先控制世界里最能代表它的东西:
|
||||
百梦主应该优先控制世界里最能代表它的东西:
|
||||
|
||||
- 标志性物件
|
||||
- 标志性怪物 / 生物
|
||||
@@ -144,9 +144,9 @@
|
||||
- 这些内容决定世界的“手感”
|
||||
- 它们不是普通细节,而是会反复影响命名、剧情、视觉、对话与玩法解释的母题
|
||||
|
||||
## 2.8 创作者应直接控制的“禁止事项”
|
||||
## 2.8 百梦主应直接控制的“禁止事项”
|
||||
|
||||
创作者必须能明确锁定:
|
||||
百梦主必须能明确锁定:
|
||||
|
||||
- 什么绝对不能改
|
||||
- 什么不能被 AI 自动扩写到别的方向
|
||||
@@ -156,7 +156,7 @@
|
||||
原因:
|
||||
|
||||
- 高自由度不等于所有内容都开放漂移
|
||||
- 如果没有“锁定机制”,AI 会把创作者真正关心的内容稀释掉
|
||||
- 如果没有“锁定机制”,AI 会把百梦主真正关心的内容稀释掉
|
||||
|
||||
## 3. 什么内容应该交给 AI 和系统
|
||||
|
||||
@@ -176,7 +176,7 @@
|
||||
原因:
|
||||
|
||||
- 这些内容数量大、重复度高
|
||||
- 它们需要“贴合世界”,但不需要都由创作者逐个手写
|
||||
- 它们需要“贴合世界”,但不需要都由百梦主逐个手写
|
||||
- AI 很适合做“围绕锚点的批量铺量”
|
||||
|
||||
## 3.2 从创作锚点到系统结构的编译
|
||||
@@ -186,7 +186,7 @@
|
||||
- 从自然语言世界设定中提取题材词汇
|
||||
- 从关键冲突中编译出世界叙事图谱
|
||||
- 从关键角色卡编译出角色叙事档案
|
||||
- 从创作者输入里自动生成标签、钩子、隐藏线索、章节摘要
|
||||
- 从百梦主输入里自动生成标签、钩子、隐藏线索、章节摘要
|
||||
- 从地点和关系中编译出场景连接、事件触发和叙事回响
|
||||
|
||||
对应当前仓库,下面这些结构更适合由 AI / 系统生成,而不是让玩家直接编辑:
|
||||
@@ -203,7 +203,7 @@
|
||||
|
||||
原因:
|
||||
|
||||
- 这些是运行时结构,不是创作者真正想表达的作品内容
|
||||
- 这些是运行时结构,不是百梦主真正想表达的作品内容
|
||||
- 直接暴露给玩家,会把创作过程变成专业数据填表
|
||||
|
||||
## 3.3 专业化、规则化的任务
|
||||
@@ -223,7 +223,7 @@
|
||||
原因:
|
||||
|
||||
- 这些工作要么重复、要么专业、要么容易做脏活累活
|
||||
- 让非专业创作者处理,会显著提高门槛,却不一定显著提高质量
|
||||
- 让非专业百梦主处理,会显著提高门槛,却不一定显著提高质量
|
||||
|
||||
## 3.4 一致性、纠错与查漏补缺
|
||||
|
||||
@@ -240,15 +240,15 @@
|
||||
原因:
|
||||
|
||||
- 这是 AI 比人更适合做的“维护型工作”
|
||||
- 它属于创作支持,不属于创作者必须亲手完成的创作
|
||||
- 它属于创作支持,不属于百梦主必须亲手完成的创作
|
||||
|
||||
## 4. 最合理的边界不是二分法,而是三层分工
|
||||
|
||||
自定义世界最合理的结构,不是“玩家写”与“AI 写”的简单二选一,而是三层。
|
||||
|
||||
## 4.1 第一层:创作者必控层
|
||||
## 4.1 第一层:百梦主必控层
|
||||
|
||||
这一层必须给创作者高自由度,且能被锁定:
|
||||
这一层必须给百梦主高自由度,且能被锁定:
|
||||
|
||||
- 世界核心命题
|
||||
- 主题与气质
|
||||
@@ -264,9 +264,9 @@
|
||||
|
||||
**少而重。**
|
||||
|
||||
## 4.2 第二层:创作者可选强化层
|
||||
## 4.2 第二层:百梦主可选强化层
|
||||
|
||||
这一层不应强制填写,但应该允许创作者继续深挖:
|
||||
这一层不应强制填写,但应该允许百梦主继续深挖:
|
||||
|
||||
- 明线 / 暗线种子
|
||||
- 角色之间的旧事
|
||||
@@ -301,17 +301,17 @@
|
||||
|
||||
## 5. 具体模块的建议归属
|
||||
|
||||
| 模块 | 建议归属 | 创作者应控制什么 | AI / 系统应负责什么 |
|
||||
| 模块 | 建议归属 | 百梦主应控制什么 | AI / 系统应负责什么 |
|
||||
| --- | --- | --- | --- |
|
||||
| 世界一句话设定、核心幻想、核心卖点 | 创作者直接控制 | 直接写、直接改、可锁定 | 给出备选表述和扩展方向 |
|
||||
| 主题、基调、审美、禁忌 | 创作者直接控制 | 选择 / 改写 / 锁定 | 生成风格词、避雷词、提示词约束 |
|
||||
| 玩家身份、开局处境、玩家目标 | 创作者直接控制 | 直接定义 | 补足开局钩子和初始叙事包装 |
|
||||
| 关键势力与核心冲突 | 创作者主控,AI 辅助 | 定义核心关系和立场 | 扩展冲突支路、生成世界线程 |
|
||||
| 关键角色 | 创作者主控,AI 辅助 | 定义角色骨架、关系张力、秘密方向 | 生成长背景、章节拆分、技能、物品、叙事档案 |
|
||||
| 关键地点 | 创作者主控,AI 辅助 | 定义地点意义、气氛、秘密 | 扩展场景细节、连接关系、遭遇分布 |
|
||||
| 标志性物件 / 怪物 / 制度 / 规则 | 创作者主控,AI 辅助 | 定义代表性要素与硬边界 | 扩展变体、命名、说明、运行时挂钩 |
|
||||
| 世界一句话设定、核心幻想、核心卖点 | 百梦主直接控制 | 直接写、直接改、可锁定 | 给出备选表述和扩展方向 |
|
||||
| 主题、基调、审美、禁忌 | 百梦主直接控制 | 选择 / 改写 / 锁定 | 生成风格词、避雷词、提示词约束 |
|
||||
| 玩家身份、开局处境、玩家目标 | 百梦主直接控制 | 直接定义 | 补足开局钩子和初始叙事包装 |
|
||||
| 关键势力与核心冲突 | 百梦主控,AI 辅助 | 定义核心关系和立场 | 扩展冲突支路、生成世界线程 |
|
||||
| 关键角色 | 百梦主控,AI 辅助 | 定义角色骨架、关系张力、秘密方向 | 生成长背景、章节拆分、技能、物品、叙事档案 |
|
||||
| 关键地点 | 百梦主控,AI 辅助 | 定义地点意义、气氛、秘密 | 扩展场景细节、连接关系、遭遇分布 |
|
||||
| 标志性物件 / 怪物 / 制度 / 规则 | 百梦主控,AI 辅助 | 定义代表性要素与硬边界 | 扩展变体、命名、说明、运行时挂钩 |
|
||||
| 普通 NPC / 路人 / 杂兵 / 次级地点 | 主要交给 AI | 仅在需要时抽查或替换 | 批量生成与风格保持 |
|
||||
| 角色长背景、章节 teaser、context snippet | 主要交给 AI | 创作者只改关键角色即可 | 自动拆章、压缩、解锁节奏整理 |
|
||||
| 角色长背景、章节 teaser、context snippet | 主要交给 AI | 百梦主只改关键角色即可 | 自动拆章、压缩、解锁节奏整理 |
|
||||
| 技能、初始物品、标签、构筑倾向 | 主要交给 AI / 系统 | 提供偏好或少量 override | 按角色和世界规则自动编译 |
|
||||
| 世界图谱、知识事实、可见性、导演指令 | AI / 系统内部层 | 不应默认暴露给玩家 | 运行时编译与维护 |
|
||||
| 一致性检查、冲突检查、越权检查 | AI / 系统内部层 | 查看报告、决定是否采纳修改 | 自动扫描并提出修正建议 |
|
||||
@@ -328,7 +328,7 @@
|
||||
- 精确数值型 build 倾向
|
||||
- 复杂掉落预算
|
||||
|
||||
更合理的做法是让创作者填写直觉表达,例如:
|
||||
更合理的做法是让百梦主填写直觉表达,例如:
|
||||
|
||||
- `初见就戒备`
|
||||
- `容易合作`
|
||||
@@ -351,7 +351,7 @@
|
||||
|
||||
原因:
|
||||
|
||||
- 这些字段属于系统运行结构,不属于创作者自然的创作语言
|
||||
- 这些字段属于系统运行结构,不属于百梦主自然的创作语言
|
||||
- 直接让玩家填,会把工具变成只有懂系统的人才能用
|
||||
|
||||
## 6.3 不应该要求玩家逐个补完所有人物设定字段
|
||||
@@ -378,7 +378,7 @@
|
||||
|
||||
## 7. 推荐的创作输入形态
|
||||
|
||||
要让非专业创作者也能高自由度创作,输入形态必须改成“自然语言创作卡”,而不是“系统字段表单”。
|
||||
要让非专业百梦主也能高自由度创作,输入形态必须改成“自然语言创作卡”,而不是“系统字段表单”。
|
||||
|
||||
## 7.1 世界层卡片
|
||||
|
||||
@@ -397,10 +397,10 @@
|
||||
## 7.2 每张卡片都允许 3 种输入方式
|
||||
|
||||
1. 一句话自由输入
|
||||
- 适合低门槛创作者
|
||||
- 适合低门槛百梦主
|
||||
|
||||
2. 标签 / 选项 / 语气滑条
|
||||
- 适合不想写太多字的创作者
|
||||
- 适合不想写太多字的百梦主
|
||||
|
||||
3. 高级补充
|
||||
- 适合愿意继续深挖的人
|
||||
@@ -414,7 +414,7 @@
|
||||
|
||||
这是高创作自由度里非常关键的一点。
|
||||
|
||||
创作者应当能:
|
||||
百梦主应当能:
|
||||
|
||||
- 锁定一个角色
|
||||
- 锁定一个地点
|
||||
@@ -422,13 +422,13 @@
|
||||
- 只重生成未锁定部分
|
||||
- 围绕锁定内容重写其余世界
|
||||
|
||||
否则创作者每次调用 AI,都会有“好不容易想好的东西被洗掉”的感受。
|
||||
否则百梦主每次调用 AI,都会有“好不容易想好的东西被洗掉”的感受。
|
||||
|
||||
## 8. 面向当前仓库的结构映射建议
|
||||
|
||||
为了便于后续落实现有系统,这份边界建议可以直接映射到当前结构:
|
||||
|
||||
## 8.1 创作者输入层
|
||||
## 8.1 百梦主输入层
|
||||
|
||||
建议主要映射到:
|
||||
|
||||
@@ -445,7 +445,7 @@
|
||||
|
||||
## 8.2 AI 编译层
|
||||
|
||||
由 AI / 系统从创作者输入自动补出:
|
||||
由 AI / 系统从百梦主输入自动补出:
|
||||
|
||||
- `themePack`
|
||||
- `storyGraph`
|
||||
@@ -465,7 +465,7 @@
|
||||
- `CarrierStoryFingerprint`
|
||||
- `StorySignal`
|
||||
|
||||
这些内容应该是“系统如何把世界跑起来”,不是“创作者必须亲手写完的创作内容”。
|
||||
这些内容应该是“系统如何把世界跑起来”,不是“百梦主必须亲手写完的创作内容”。
|
||||
|
||||
## 9. 产品层面的最终结论
|
||||
|
||||
@@ -480,12 +480,12 @@
|
||||
|
||||
它应该做成这样:
|
||||
|
||||
1. 创作者决定世界的灵魂锚点。
|
||||
2. 创作者重点塑造少量关键人、关键地、关键冲突、关键物。
|
||||
1. 百梦主决定世界的灵魂锚点。
|
||||
2. 百梦主重点塑造少量关键人、关键地、关键冲突、关键物。
|
||||
3. AI 围绕这些锚点批量展开长尾内容。
|
||||
4. 系统把这些内容编译成可运行的图谱、可见性、任务、物件和关系结构。
|
||||
5. 创作者随时可以锁定核心创意,并局部重生成其余部分。
|
||||
5. 百梦主随时可以锁定核心创意,并局部重生成其余部分。
|
||||
|
||||
一句话收束:
|
||||
|
||||
**创作者应该写“这个世界为什么动人”,AI 应该负责“让这个世界长出来并跑起来”。**
|
||||
**百梦主应该写“这个世界为什么动人”,AI 应该负责“让这个世界长出来并跑起来”。**
|
||||
|
||||
@@ -6,17 +6,17 @@
|
||||
|
||||
这份文档用于回答一个更具体的问题:
|
||||
|
||||
**参考 RPG 专业剧情策划全流程后,在自定义世界创作工具里,哪些设定必须要求创作者手动填写,哪些设定应该由 AI 先生成但允许创作者修改,哪些设定应完全交给系统托管,才能在“尽可能降低门槛”和“尽可能提高作品质量”之间取一个平衡。**
|
||||
**参考 RPG 专业剧情策划全流程后,在自定义世界创作工具里,哪些设定必须要求百梦主手动填写,哪些设定应该由 AI 先生成但允许百梦主修改,哪些设定应完全交给系统托管,才能在“尽可能降低门槛”和“尽可能提高作品质量”之间取一个平衡。**
|
||||
|
||||
这份文档不再只回答“创作者与 AI 怎么分工”,而是进一步把创作工作台收束成一个更可执行的三层输入结构:
|
||||
这份文档不再只回答“百梦主与 AI 怎么分工”,而是进一步把创作工作台收束成一个更可执行的三层输入结构:
|
||||
|
||||
1. 创作者必须手填的高杠杆锚点
|
||||
2. AI 先生成、创作者可修改的内容草稿层
|
||||
1. 百梦主必须手填的高杠杆锚点
|
||||
2. AI 先生成、百梦主可修改的内容草稿层
|
||||
3. 系统自动编译和运行的托管层
|
||||
|
||||
一句话结论:
|
||||
|
||||
**让创作者只负责决定作品的灵魂、视角、冲突和关系钩子,让 AI 负责把这些锚点展开成可编辑的剧情草稿,让系统负责把草稿编译成可运行的结构。**
|
||||
**让百梦主只负责决定作品的灵魂、视角、冲突和关系钩子,让 AI 负责把这些锚点展开成可编辑的剧情草稿,让系统负责把草稿编译成可运行的结构。**
|
||||
|
||||
---
|
||||
|
||||
@@ -25,27 +25,27 @@
|
||||
这套平衡设计要同时满足 5 个目标:
|
||||
|
||||
1. 低门槛
|
||||
- 新创作者不需要写长篇设定,也不需要理解底层系统结构。
|
||||
- 新百梦主不需要写长篇设定,也不需要理解底层系统结构。
|
||||
|
||||
2. 高辨识度
|
||||
- 创作者写出来的世界,不应该只是“像一个世界”,而应该保留明显的个人方向。
|
||||
- 百梦主写出来的世界,不应该只是“像一个世界”,而应该保留明显的个人方向。
|
||||
|
||||
3. 高可编辑性
|
||||
- AI 不能一次生成后就不可控,创作者必须能改关键对象、关键关系和关键章节。
|
||||
- AI 不能一次生成后就不可控,百梦主必须能改关键对象、关键关系和关键章节。
|
||||
|
||||
4. 高稳定性
|
||||
- 任务、章节、关系、物件和可见性等运行层结构不能依赖创作者手填专业字段。
|
||||
- 任务、章节、关系、物件和可见性等运行层结构不能依赖百梦主手填专业字段。
|
||||
|
||||
5. 可扩展
|
||||
- 愿意深挖的创作者可以继续补充世界上限,不愿深挖的人也能快速产出质量不错的作品。
|
||||
- 愿意深挖的百梦主可以继续补充世界上限,不愿深挖的人也能快速产出质量不错的作品。
|
||||
|
||||
---
|
||||
|
||||
## 2. 核心原则
|
||||
|
||||
## 2.1 创作者手填的必须是“高杠杆决策”,不是“高工作量字段”
|
||||
## 2.1 百梦主手填的必须是“高杠杆决策”,不是“高工作量字段”
|
||||
|
||||
应该要求创作者手填的内容,必须同时满足下面两个条件:
|
||||
应该要求百梦主手填的内容,必须同时满足下面两个条件:
|
||||
|
||||
1. 会显著决定作品气质和辨识度
|
||||
2. AI 很难替代判断
|
||||
@@ -67,9 +67,9 @@
|
||||
- 章节拆分
|
||||
- 运行时信号结构
|
||||
|
||||
## 2.2 创作者可改层应该承接“专业策划初稿”,而不是“原始底层字段”
|
||||
## 2.2 百梦主可改层应该承接“专业策划初稿”,而不是“原始底层字段”
|
||||
|
||||
AI 生成后允许创作者修改的,不应该是一堆技术型字段,而应该是一批已经成形的内容卡片,例如:
|
||||
AI 生成后允许百梦主修改的,不应该是一堆技术型字段,而应该是一批已经成形的内容卡片,例如:
|
||||
|
||||
- 关键角色卡
|
||||
- 势力卡
|
||||
@@ -81,11 +81,11 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
也就是说:
|
||||
|
||||
**AI 先给创作者一个像策划初稿的东西,而不是给一堆系统字段让创作者自己拼。**
|
||||
**AI 先给百梦主一个像策划初稿的东西,而不是给一堆系统字段让百梦主自己拼。**
|
||||
|
||||
## 2.3 系统托管层必须彻底隐藏专业运行结构
|
||||
|
||||
以下这类结构不应该默认要求创作者理解或编辑:
|
||||
以下这类结构不应该默认要求百梦主理解或编辑:
|
||||
|
||||
- `ThemePack`
|
||||
- `WorldStoryGraph`
|
||||
@@ -98,7 +98,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
- 稀有度映射
|
||||
- 掉落和 build 权重
|
||||
|
||||
创作者应该编辑的是自然语言与内容卡,而不是运行时图结构。
|
||||
百梦主应该编辑的是自然语言与内容卡,而不是运行时图结构。
|
||||
|
||||
## 2.4 先少量必填,再逐层展开
|
||||
|
||||
@@ -107,9 +107,9 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
```text
|
||||
先填最小必填卡
|
||||
-> AI 生成世界初稿
|
||||
-> 创作者修改关键对象
|
||||
-> 百梦主修改关键对象
|
||||
-> 系统继续展开长尾
|
||||
-> 创作者决定是否进入高级补充
|
||||
-> 百梦主决定是否进入高级补充
|
||||
```
|
||||
|
||||
## 2.5 默认清爽,深度能力后置
|
||||
@@ -127,27 +127,27 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
## 3. 最终建议:三层分工
|
||||
|
||||
## 3.1 第一层:必须要求创作者手动填写
|
||||
## 3.1 第一层:必须要求百梦主手动填写
|
||||
|
||||
这一层只保留最影响作品质量的高杠杆锚点,建议默认强制填写 6 张卡。
|
||||
|
||||
## 3.2 第二层:AI 生成后支持创作者修改
|
||||
## 3.2 第二层:AI 生成后支持百梦主修改
|
||||
|
||||
这一层由 AI 根据第一层锚点自动展开成专业剧情策划初稿,创作者可以逐项修改、锁定、局部重生成。
|
||||
这一层由 AI 根据第一层锚点自动展开成专业剧情策划初稿,百梦主可以逐项修改、锁定、局部重生成。
|
||||
|
||||
## 3.3 第三层:其余都交给系统
|
||||
|
||||
这一层是把前两层编译成可运行游戏结构所需的系统字段、数值和运行时指令,默认不要求创作者处理。
|
||||
这一层是把前两层编译成可运行游戏结构所需的系统字段、数值和运行时指令,默认不要求百梦主处理。
|
||||
|
||||
---
|
||||
|
||||
## 4. 最低门槛方案:只强制手填 6 张卡
|
||||
|
||||
如果目标是尽可能降低门槛,同时又保留作品辨识度,建议只强制创作者填写以下 6 张卡。
|
||||
如果目标是尽可能降低门槛,同时又保留作品辨识度,建议只强制百梦主填写以下 6 张卡。
|
||||
|
||||
## 4.1 卡 1:世界一句话与核心幻想
|
||||
|
||||
创作者必须手填:
|
||||
百梦主必须手填:
|
||||
|
||||
- 世界一句话设定
|
||||
- 玩家来到这个世界最想体验的感觉
|
||||
@@ -165,7 +165,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
## 4.2 卡 2:玩家身份与开局困境
|
||||
|
||||
创作者必须手填:
|
||||
百梦主必须手填:
|
||||
|
||||
- 玩家是谁
|
||||
- 玩家开局最缺什么
|
||||
@@ -179,7 +179,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
## 4.3 卡 3:主题气质与禁忌边界
|
||||
|
||||
创作者必须手填:
|
||||
百梦主必须手填:
|
||||
|
||||
- 主题关键词
|
||||
- 情绪基调
|
||||
@@ -199,7 +199,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
## 4.4 卡 4:核心冲突
|
||||
|
||||
创作者必须手填:
|
||||
百梦主必须手填:
|
||||
|
||||
- 当前世界最重要的 `1~3` 个明面冲突
|
||||
- 至少 `1` 个隐藏问题或暗面危机
|
||||
@@ -212,9 +212,9 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
## 4.5 卡 5:关键关系钩子
|
||||
|
||||
这里不强制创作者一开始填写完整角色档案,只要求填写更高杠杆的“关系骨架”。
|
||||
这里不强制百梦主一开始填写完整角色档案,只要求填写更高杠杆的“关系骨架”。
|
||||
|
||||
创作者必须手填:
|
||||
百梦主必须手填:
|
||||
|
||||
- `2~4` 条关键关系钩子
|
||||
- 每条钩子至少说明:
|
||||
@@ -229,7 +229,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
## 4.6 卡 6:标志性要素与硬规则
|
||||
|
||||
创作者必须手填:
|
||||
百梦主必须手填:
|
||||
|
||||
- `2~5` 个标志性要素
|
||||
- 物件
|
||||
@@ -247,11 +247,11 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
---
|
||||
|
||||
## 5. 不建议强制手填,但应该让 AI 生成后支持创作者修改的设定
|
||||
## 5. 不建议强制手填,但应该让 AI 生成后支持百梦主修改的设定
|
||||
|
||||
这一层是平衡“低门槛”和“高质量”的关键。
|
||||
|
||||
创作者不需要从零填写这些内容,但 AI 生成后必须能看、能改、能锁定、能局部重生成。
|
||||
百梦主不需要从零填写这些内容,但 AI 生成后必须能看、能改、能锁定、能局部重生成。
|
||||
|
||||
## 5.1 世界外观层
|
||||
|
||||
@@ -282,7 +282,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
原因:
|
||||
|
||||
- 势力很重要,但让新手一开始手写完整势力表太重
|
||||
- 更合理的做法是让 AI 基于核心冲突先出草稿,再由创作者修正
|
||||
- 更合理的做法是让 AI 基于核心冲突先出草稿,再由百梦主修正
|
||||
|
||||
## 5.3 关键角色层
|
||||
|
||||
@@ -302,8 +302,8 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
原因:
|
||||
|
||||
- 创作者已经通过“关系钩子”给出最关键的人物骨架
|
||||
- AI 负责把钩子展开成可编辑角色卡,创作者再做精修
|
||||
- 百梦主已经通过“关系钩子”给出最关键的人物骨架
|
||||
- AI 负责把钩子展开成可编辑角色卡,百梦主再做精修
|
||||
|
||||
## 5.4 关键地点层
|
||||
|
||||
@@ -319,7 +319,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
原因:
|
||||
|
||||
- 地点是世界感的重要来源
|
||||
- 但新创作者未必能一开始就写出完整地点网络
|
||||
- 但新百梦主未必能一开始就写出完整地点网络
|
||||
|
||||
## 5.5 世界线程层
|
||||
|
||||
@@ -335,7 +335,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
原因:
|
||||
|
||||
- 线程是专业剧情结构,适合 AI 先搭骨架
|
||||
- 但创作者必须有权修正哪条线更重要、哪条线该隐藏
|
||||
- 但百梦主必须有权修正哪条线更重要、哪条线该隐藏
|
||||
|
||||
## 5.6 主线章节层
|
||||
|
||||
@@ -350,9 +350,9 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
原因:
|
||||
|
||||
- 创作者已经给出了世界目标、冲突和关系
|
||||
- 百梦主已经给出了世界目标、冲突和关系
|
||||
- AI 可以先把它们编成主线章节初稿
|
||||
- 创作者再选择保留、删减或重排
|
||||
- 百梦主再选择保留、删减或重排
|
||||
|
||||
## 5.7 支线、角色线、阵营线层
|
||||
|
||||
@@ -367,7 +367,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
原因:
|
||||
|
||||
- 这是最适合 AI 拉开内容宽度的部分
|
||||
- 也是最需要创作者局部精修的部分
|
||||
- 也是最需要百梦主局部精修的部分
|
||||
|
||||
## 5.8 场景章节层
|
||||
|
||||
@@ -384,7 +384,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
原因:
|
||||
|
||||
- 当前项目已经在走“场景 = 章节单元”的方向
|
||||
- 这层非常适合 AI 编排出第一版,再由创作者补强记忆点
|
||||
- 这层非常适合 AI 编排出第一版,再由百梦主补强记忆点
|
||||
|
||||
## 5.9 叙事载体层
|
||||
|
||||
@@ -397,7 +397,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
- 场景遗物
|
||||
- 怪物命名及其故事指向
|
||||
|
||||
创作者主要修改:
|
||||
百梦主主要修改:
|
||||
|
||||
- 哪些载体最重要
|
||||
- 哪些载体和哪条线程绑定
|
||||
@@ -417,13 +417,13 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
原因:
|
||||
|
||||
- 这些内容适合 AI 批量铺量
|
||||
- 创作者只需要挑、改、锁定,不必从零起草
|
||||
- 百梦主只需要挑、改、锁定,不必从零起草
|
||||
|
||||
---
|
||||
|
||||
## 6. 其余设定应交给系统托管
|
||||
|
||||
以下内容不建议默认暴露给创作者编辑,应由系统根据前两层自动编译和维护。
|
||||
以下内容不建议默认暴露给百梦主编辑,应由系统根据前两层自动编译和维护。
|
||||
|
||||
## 6.1 题材与术语编译层
|
||||
|
||||
@@ -450,7 +450,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
原因:
|
||||
|
||||
- 创作者要的是“故事线能对”,不是维护图数据库
|
||||
- 百梦主要的是“故事线能对”,不是维护图数据库
|
||||
|
||||
## 6.3 可见性和 prompt 裁剪层
|
||||
|
||||
@@ -465,7 +465,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
原因:
|
||||
|
||||
- 这层必须稳定、严格、自动化
|
||||
- 不适合依赖创作者手动维护
|
||||
- 不适合依赖百梦主手动维护
|
||||
|
||||
## 6.4 运行时导演层
|
||||
|
||||
@@ -494,7 +494,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
说明:
|
||||
|
||||
- 创作者可以编辑“任务卡”和“章节卡”
|
||||
- 百梦主可以编辑“任务卡”和“章节卡”
|
||||
- 但不应默认编辑底层 contract 结构
|
||||
|
||||
## 6.6 数值与配置层
|
||||
@@ -511,7 +511,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
说明:
|
||||
|
||||
- 创作者可以给“偏向”
|
||||
- 百梦主可以给“偏向”
|
||||
- 系统负责编译成具体数值
|
||||
|
||||
## 6.7 QA 与一致性层
|
||||
@@ -547,7 +547,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
| 主线 | 不强制首轮手写完整主线 | 幕结构、章节卡、高潮与 handoff | 章节状态编译 |
|
||||
| 支线/角色线 | 不强制首轮手写完整矩阵 | 支线种子、角色线事件、阵营线分歧 | 任务 contract 编译 |
|
||||
| 场景章节 | 不强制首轮手写全量章节 | 场景章节卡、阶段内容、章节载体 | signal 与导演层 |
|
||||
| 运行时结构 | 不建议创作者接触 | 不建议默认编辑 | 可见性、导演、信号、编译、QA |
|
||||
| 运行时结构 | 不建议百梦主接触 | 不建议默认编辑 | 可见性、导演、信号、编译、QA |
|
||||
|
||||
---
|
||||
|
||||
@@ -555,7 +555,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
## 8.1 第一步:只填写最小必填集
|
||||
|
||||
创作者只需要完成:
|
||||
百梦主只需要完成:
|
||||
|
||||
1. 世界一句话与核心幻想
|
||||
2. 玩家身份与开局困境
|
||||
@@ -584,9 +584,9 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
这里的重点不是一次补满全世界,而是先形成一个像样的内容骨架。
|
||||
|
||||
## 8.3 第三步:创作者只精修高价值卡片
|
||||
## 8.3 第三步:百梦主只精修高价值卡片
|
||||
|
||||
建议默认优先让创作者编辑这 4 类卡片:
|
||||
建议默认优先让百梦主编辑这 4 类卡片:
|
||||
|
||||
1. 关键角色
|
||||
2. 核心冲突与线程
|
||||
@@ -606,7 +606,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
- 任务包装
|
||||
- 文案变体
|
||||
|
||||
## 8.5 第五步:创作者按需进入高级模式
|
||||
## 8.5 第五步:百梦主按需进入高级模式
|
||||
|
||||
高级模式只对愿意深挖的人开放:
|
||||
|
||||
@@ -665,7 +665,7 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
## 10.2 每张卡只保留自然语言输入
|
||||
|
||||
不要强迫创作者在首轮填写:
|
||||
不要强迫百梦主在首轮填写:
|
||||
|
||||
- tags
|
||||
- ids
|
||||
@@ -676,20 +676,20 @@ AI 生成后允许创作者修改的,不应该是一堆技术型字段,而
|
||||
|
||||
更合理的做法是:
|
||||
|
||||
- 让创作者输入自然语言或选择直觉标签
|
||||
- 让百梦主输入自然语言或选择直觉标签
|
||||
- 再由系统编译成结构化字段
|
||||
|
||||
## 10.3 首轮生成后默认先看“精修建议”
|
||||
|
||||
AI 初稿生成后,不应该把创作者直接扔进一个大编辑器。
|
||||
AI 初稿生成后,不应该把百梦主直接扔进一个大编辑器。
|
||||
|
||||
更好的做法是先给出:
|
||||
|
||||
1. 哪些卡片最值得改
|
||||
2. 哪些内容已经比较稳定
|
||||
3. 哪些内容仍然偏泛,需要创作者补个性
|
||||
3. 哪些内容仍然偏泛,需要百梦主补个性
|
||||
|
||||
这样能明显提高创作者的修改效率。
|
||||
这样能明显提高百梦主的修改效率。
|
||||
|
||||
## 10.4 移动端优先只保留高杠杆操作
|
||||
|
||||
@@ -707,15 +707,15 @@ AI 初稿生成后,不应该把创作者直接扔进一个大编辑器。
|
||||
|
||||
## 11. 最后结论
|
||||
|
||||
如果目标是在自定义世界创作中真正平衡“降低门槛”和“提高作品质量”,最好的做法不是让创作者填更多字段,也不是把一切都交给 AI。
|
||||
如果目标是在自定义世界创作中真正平衡“降低门槛”和“提高作品质量”,最好的做法不是让百梦主填更多字段,也不是把一切都交给 AI。
|
||||
|
||||
更合理的平衡是:
|
||||
|
||||
1. 创作者必须手填最小但高杠杆的 6 张卡,掌握世界灵魂。
|
||||
1. 百梦主必须手填最小但高杠杆的 6 张卡,掌握世界灵魂。
|
||||
2. AI 根据这 6 张卡生成一套可编辑的专业剧情初稿,负责把骨架展开成角色、地点、线程、章节和载体。
|
||||
3. 创作者只精修最有价值的关键对象,锁定真正重要的内容。
|
||||
3. 百梦主只精修最有价值的关键对象,锁定真正重要的内容。
|
||||
4. 其余运行结构、数值、可见性、任务编译和 QA 检查都交给系统托管。
|
||||
|
||||
一句话收束:
|
||||
|
||||
**创作者负责决定“这个世界为什么值得被创作”,AI 负责把它整理成可修改的策划初稿,系统负责把它稳定地跑成一个游戏世界。**
|
||||
**百梦主负责决定“这个世界为什么值得被创作”,AI 负责把它整理成可修改的策划初稿,系统负责把它稳定地跑成一个游戏世界。**
|
||||
|
||||
+21
-21
@@ -10,7 +10,7 @@
|
||||
- 基于“最小必填锚点 + AI 初稿卡片 + 系统托管层”的结构化创作方案
|
||||
|
||||
2. 纯 Agent 式方向
|
||||
- 以前台对话为唯一主交互,创作者主要通过和 Agent 聊天来完成世界构建、角色塑造、剧情扩展和修改
|
||||
- 以前台对话为唯一主交互,百梦主主要通过和 Agent 聊天来完成世界构建、角色塑造、剧情扩展和修改
|
||||
|
||||
文档需要回答 3 个问题:
|
||||
|
||||
@@ -34,7 +34,7 @@
|
||||
|
||||
当前方案的核心是:
|
||||
|
||||
1. 创作者手填最小高杠杆锚点
|
||||
1. 百梦主手填最小高杠杆锚点
|
||||
2. AI 生成一批可编辑的剧情策划初稿卡片
|
||||
3. 系统把内容编译成运行时结构
|
||||
|
||||
@@ -42,7 +42,7 @@
|
||||
|
||||
**结构化工作台 + AI 协作生成。**
|
||||
|
||||
创作者的主要行为是:
|
||||
百梦主的主要行为是:
|
||||
|
||||
1. 填写关键卡片
|
||||
2. 修改关键角色、地点、势力、章节等内容卡
|
||||
@@ -53,9 +53,9 @@
|
||||
|
||||
纯 Agent 式不是指“系统内部没有结构”,而是指:
|
||||
|
||||
**创作者前台几乎不需要面对表单和卡片编辑器,主要通过自然语言对话来完成创作。**
|
||||
**百梦主前台几乎不需要面对表单和卡片编辑器,主要通过自然语言对话来完成创作。**
|
||||
|
||||
创作者的主要行为变成:
|
||||
百梦主的主要行为变成:
|
||||
|
||||
1. 用自然语言描述世界想法
|
||||
2. 回答 Agent 的追问
|
||||
@@ -77,7 +77,7 @@
|
||||
|
||||
1. 前台用户主要通过什么方式思考和输入?
|
||||
2. 后台系统是否仍然有稳定的世界模型和编译层?
|
||||
3. 创作者是否还能看见摘要、锁定内容和修改范围?
|
||||
3. 百梦主是否还能看见摘要、锁定内容和修改范围?
|
||||
|
||||
对当前项目来说,真正危险的不是“转成聊天”,而是:
|
||||
|
||||
@@ -93,11 +93,11 @@
|
||||
|
||||
它更擅长:
|
||||
|
||||
1. 帮不擅长表单和结构思考的创作者起步
|
||||
2. 在创作者思路模糊时做追问和陪创作
|
||||
1. 帮不擅长表单和结构思考的百梦主起步
|
||||
2. 在百梦主思路模糊时做追问和陪创作
|
||||
3. 把“我要做一个世界”变成一次自然聊天
|
||||
4. 动态决定追问深度,而不是一上来摆很多字段
|
||||
5. 让创作者感觉自己是在和一个懂 RPG 的剧情搭档共创
|
||||
5. 让百梦主感觉自己是在和一个懂 RPG 的剧情搭档共创
|
||||
|
||||
## 2.2 纯 Agent 式的主要问题
|
||||
|
||||
@@ -110,7 +110,7 @@
|
||||
1. 聊天很多,但世界状态越来越难总览
|
||||
2. 角色、地点、势力和章节信息散落在多轮消息里
|
||||
3. 锁定范围不清,重生成容易误伤已有内容
|
||||
4. Agent 很容易“替创作者决定太多”
|
||||
4. Agent 很容易“替百梦主决定太多”
|
||||
5. 长会话越来越贵,越来越慢,也越来越容易漂移
|
||||
|
||||
## 2.3 对当前项目的判断
|
||||
@@ -197,7 +197,7 @@
|
||||
|
||||
纯 Agent 式更弱的地方在于:
|
||||
|
||||
1. 世界模型隐藏得太深时,创作者会失去整体掌控感
|
||||
1. 世界模型隐藏得太深时,百梦主会失去整体掌控感
|
||||
2. 多轮对话后,已确定内容不容易被清晰回看
|
||||
3. 局部重做和精确编辑边界会变模糊
|
||||
4. Agent 容易过度代写、过度主导
|
||||
@@ -223,7 +223,7 @@
|
||||
|
||||
因为这些环节的关键问题不是“字段如何摆放”,而是:
|
||||
|
||||
**创作者有没有被真正引导出自己想做的世界。**
|
||||
**百梦主有没有被真正引导出自己想做的世界。**
|
||||
|
||||
## 4.2 不值得直接转成纯聊天黑箱的部分
|
||||
|
||||
@@ -261,8 +261,8 @@
|
||||
|
||||
即使转成纯 Agent 式,也仍然要保留这三层:
|
||||
|
||||
1. 创作者必须确认的高杠杆锚点
|
||||
2. AI 生成但允许创作者修改的策划初稿层
|
||||
1. 百梦主必须确认的高杠杆锚点
|
||||
2. AI 生成但允许百梦主修改的策划初稿层
|
||||
3. 系统托管的运行时编译层
|
||||
|
||||
变化的只是:
|
||||
@@ -339,7 +339,7 @@
|
||||
2. 会阶段性总结
|
||||
3. 会把聊天结果沉淀成结构化世界状态
|
||||
4. 会提醒风险和冲突
|
||||
5. 会在创作者要求时进行局部重写和定向扩展
|
||||
5. 会在百梦主要求时进行局部重写和定向扩展
|
||||
|
||||
## 6.2 正确理解
|
||||
|
||||
@@ -349,7 +349,7 @@
|
||||
|
||||
也就是说:
|
||||
|
||||
1. 创作者看到的是对话
|
||||
1. 百梦主看到的是对话
|
||||
2. 系统内部维护的是世界模型、锁定状态、摘要和编译结果
|
||||
|
||||
---
|
||||
@@ -389,7 +389,7 @@ Agent 首轮不应该直接铺满全世界,而应该给出一份简明底稿
|
||||
2. 建议内容
|
||||
3. 待确认内容
|
||||
|
||||
## 7.3 阶段 C:创作者锁定锚点
|
||||
## 7.3 阶段 C:百梦主锁定锚点
|
||||
|
||||
在纯 Agent 模式里,锁定行为必须被显式支持。
|
||||
|
||||
@@ -455,7 +455,7 @@ Agent 不应该每轮都继续扩全局,而应该支持“单对象工作模
|
||||
|
||||
| 结构 | 作用 |
|
||||
| --- | --- |
|
||||
| `creatorIntentProfile` | 当前创作者最初和最新的创作意图 |
|
||||
| `creatorIntentProfile` | 当前百梦主最初和最新的创作意图 |
|
||||
| `lockedAnchors` | 已确认不可自动改写的内容 |
|
||||
| `worldDraftSnapshot` | 当前世界底稿快照 |
|
||||
| `editableDraftCards` | 角色、地点、势力、章节等可编辑初稿 |
|
||||
@@ -530,7 +530,7 @@ Agent 不能像问卷系统,也不能一次追问太多。
|
||||
1. 一次最多追问 `1~3` 个问题
|
||||
2. 问题必须是当前最缺的高杠杆信息
|
||||
3. 每次追问都给默认建议方向
|
||||
4. 如果创作者不想细答,允许 Agent 先代补一个版本再确认
|
||||
4. 如果百梦主不想细答,允许 Agent 先代补一个版本再确认
|
||||
|
||||
这样才能保持“像聊天”,而不是“像客服表单”。
|
||||
|
||||
@@ -614,14 +614,14 @@ Agent 应能识别这些常见修改类型:
|
||||
3. 锁定内容固定展示
|
||||
4. 提供“当前世界圣经”入口
|
||||
|
||||
## 11.2 风险 2:Agent 过度代写,创作者失去作品归属感
|
||||
## 11.2 风险 2:Agent 过度代写,百梦主失去作品归属感
|
||||
|
||||
防护方式:
|
||||
|
||||
1. 高杠杆锚点必须要求确认
|
||||
2. 重要改动前先说“我准备改什么”
|
||||
3. 默认优先给多个候选,而不是直接盖写
|
||||
4. 允许创作者随时回退到旧版本
|
||||
4. 允许百梦主随时回退到旧版本
|
||||
|
||||
## 11.3 风险 3:局部修改带出全局漂移
|
||||
|
||||
|
||||
@@ -37,8 +37,8 @@
|
||||
- 不能先删旧字段,再补新结构。
|
||||
- 必须先补新设定层,再逐步迁读,最后再让旧模板字段退化成兼容层。
|
||||
|
||||
4. 不能增加创作者负担
|
||||
- 这次不是让创作者多填一堆底层 schema。
|
||||
4. 不能增加百梦主负担
|
||||
- 这次不是让百梦主多填一堆底层 schema。
|
||||
- 这些设定仍然应由 AI / 系统编译出来,只是所有权从模板世界转移到自定义世界自己。
|
||||
|
||||
---
|
||||
|
||||
+2
-2
@@ -102,9 +102,9 @@
|
||||
|
||||
这不是真正跨题材,只是换了名字。
|
||||
|
||||
## 3.3 不能让创作者承担更多底层配置工作
|
||||
## 3.3 不能让百梦主承担更多底层配置工作
|
||||
|
||||
这次优化不是让创作者额外填写:
|
||||
这次优化不是让百梦主额外填写:
|
||||
|
||||
- 怪物模板表
|
||||
- 场景参考池
|
||||
|
||||
@@ -349,7 +349,7 @@ export interface ChapterProgressionPlan {
|
||||
}
|
||||
```
|
||||
|
||||
建议作为后端运行时编译结果缓存,不作为创作者直接编辑字段。
|
||||
建议作为后端运行时编译结果缓存,不作为百梦主直接编辑字段。
|
||||
|
||||
## 3.7 章节经验记账
|
||||
|
||||
@@ -636,7 +636,7 @@ chapterXpBudget =
|
||||
3. 非主角色友方 NPC
|
||||
- `support` 或 `ambient`
|
||||
|
||||
如需修正,再允许章节蓝图加可选 override,但不要求创作者每次手填。
|
||||
如需修正,再允许章节蓝图加可选 override,但不要求百梦主每次手填。
|
||||
|
||||
## 7.2 等级锚点
|
||||
|
||||
|
||||
@@ -17,10 +17,14 @@
|
||||
3. 卡片高度控制在约 4rem 内,标题与状态信息并排组织,避免大留白。
|
||||
4. 模块本体使用 `max-height: 33svh` 作为硬约束,内容超出时优先在模板入口行内横向滚动,不撑高页面。
|
||||
5. 桌面端保持网格入口,但同步收紧内边距和卡片留白,避免移动端与桌面端表现割裂。
|
||||
6. 横向滚动模板行必须隐藏原生滚动条,保留滑动能力,避免底部出现过粗的视觉条。
|
||||
7. 模板入口排序以可创作为第一优先级:可创建卡片保持原配置内相对顺序排在前面,锁定且展示“敬请期待”的卡片保持原配置内相对顺序排在后面。
|
||||
|
||||
## 文案约束
|
||||
|
||||
- UI 不新增规则说明类文案。
|
||||
- 原有“直接选择游戏创作模板,立刻进入对应的共创工作台。”说明在移动端隐藏,桌面端保留为辅助说明。
|
||||
- 锁定、可创建、正在开启等状态继续来自既有模板元数据或忙碌状态。
|
||||
|
||||
- 可创建的模板卡不展示“可创建”状态标签,只保留标题、短副标题和进入箭头。
|
||||
- 锁定的模板卡统一以“敬请期待”作为状态标注,不再显示“锁定”。
|
||||
- RPG 入口展示为“角色扮演 / 剧情演绎,冒险成长”,拼图入口展示为“拼图 / 创意礼物,生活分享”。
|
||||
- 忙碌状态仅保留在模块标题行的轻量状态中,避免占用每张可用卡片的首要视觉层级。
|
||||
|
||||
@@ -0,0 +1,46 @@
|
||||
# 移动端创作页作品列表统一卡片设计 2026-04-29
|
||||
|
||||
## 背景
|
||||
|
||||
创作页的作品模块需要同时承载 RPG、拼图和大鱼吃小鱼等玩法。不同玩法卡片不能各自展示阶段、素材、主题等细节标签,否则作品列表会在移动端显得拥挤,并且草稿作品会暴露过多编辑态信息。
|
||||
|
||||
本次将作品列表卡片收口成统一信息结构:草稿只用于快速识别和继续创作,已发布作品才展示公开数据与分享入口。
|
||||
|
||||
## 落地范围
|
||||
|
||||
- 列表容器:`src/components/custom-world-home/CustomWorldCreationHub.tsx`
|
||||
- 作品卡片:`src/components/custom-world-home/CustomWorldWorkCard.tsx`
|
||||
- 不改动作品数据聚合、筛选、打开和体验逻辑。
|
||||
- 已发布作品右上角动作从删除改为分享;草稿仍保留删除入口。
|
||||
|
||||
## 卡片结构规则
|
||||
|
||||
1. 标题上方只显示两个标签:作品状态与游戏类型。
|
||||
2. 不再显示阶段、主题、素材完成度、作者、作品号等额外标签。
|
||||
3. 标签下方依次显示作品名称与作品描述。
|
||||
4. 草稿卡片到作品描述为止,不显示其他统计、作品号或体验按钮。
|
||||
5. 已发布卡片在描述下方显示三项公开指标:游玩数、改造数、点赞数。
|
||||
6. 已发布卡片右上角显示分享 icon,点击后复制作品分享文案,不触发卡片打开。
|
||||
7. 草稿卡片右上角继续显示删除 icon,点击删除不触发卡片打开。
|
||||
|
||||
## 公开指标重点展示补充
|
||||
|
||||
1. 已发布作品的三项公开指标不得继续使用标签样式展示,必须参考作品详情页的统计区,采用“小标签 + 大数字 + 单位”的重点信息结构。
|
||||
2. 指标文案统一为“游玩”“改造”“点赞”,不得在创作页卡片中展示 `Remix` 英文。
|
||||
3. 用户每次进入创作页时,前端读取上一次进入该页面缓存的公开指标快照;当已发布作品卡片滑动进入视口后,数字从缓存值增长到本次接口返回的最新值。
|
||||
4. 若最新值高于缓存值,动画完成后在对应指标右下角展示红色向上箭头和本次上涨的具体数值,字号低于主数字,避免抢占主信息层级。
|
||||
5. 若没有缓存值、缓存值不低于最新值或作品仍是草稿,则直接显示最新值,不展示上涨标记。
|
||||
6. 每张作品卡片继续使用作品封面作为整卡背景,封面需要有透明度和渐变遮罩,确保标题、描述和指标在亮色与暗色主题下都清晰可读。
|
||||
|
||||
## 移动端布局规则
|
||||
|
||||
1. 作品列表默认仍使用 2 列网格,保证草稿可以快速扫视。
|
||||
2. 已发布作品卡片在移动端固定 `col-span-2`,即占据一整行,避免公开指标和分享入口互相挤压。
|
||||
3. `sm` 及以上视口恢复普通网格跨度,由卡片自然进入多列布局。
|
||||
4. 小屏卡片降低高度、内边距、标题字号和徽标尺寸,避免长标题或中文描述撑破容器。
|
||||
|
||||
## 文案约束
|
||||
|
||||
- 不新增功能说明类文案。
|
||||
- 空态和错误态沿用现有文案。
|
||||
- 中文标题、描述和指标需要在卡片内截断或换行,不得因长文本破坏布局。
|
||||
@@ -29,5 +29,5 @@
|
||||
## 4. 验收点
|
||||
|
||||
- 平台“选择创作类型”弹层不再显示“大鱼吃小鱼”卡片。
|
||||
- RPG、拼图、“敬请期待”类卡片顺序与交互保持稳定。
|
||||
- 可创建卡片排在前面,展示“敬请期待”的锁定卡片排在后面,交互状态保持稳定。
|
||||
- 代码层不引入对 Big Fish 运行时或结果页的额外耦合修改。
|
||||
|
||||
@@ -0,0 +1,82 @@
|
||||
# 平台首页分类入口与排行 Tab 调整设计
|
||||
|
||||
更新时间:`2026-04-29`
|
||||
|
||||
## 1. 本次目标
|
||||
|
||||
1. 首页移动端频道只保留“推荐、今日游戏、游戏分类”,删除“PC游戏、即点即玩”。
|
||||
2. 原底部“分类” Tab 改为“排行” Tab,不再单独承载分类页。
|
||||
3. 原分类 Tab 的标签筛选移动到首页移动端“游戏分类”频道中,作品展示从双列网格改为应用商店式纵向列表。
|
||||
4. 排行页参考榜单式纵向布局,提供热门榜、改造榜、新品榜、点赞榜四个榜单切换。
|
||||
5. 页面继续使用平台主题变量、现有字号层级与卡片组件,避免新增大段功能说明文案。
|
||||
|
||||
## 2. 数据口径
|
||||
|
||||
当前公开作品聚合列表已经透传后端读模型字段:
|
||||
|
||||
- `playCount`:历史游玩次数。
|
||||
- `remixCount`:历史改造次数。
|
||||
- `likeCount`:历史点赞次数。
|
||||
- `recentPlayCount7d`:近 7 日新增游玩次数。
|
||||
- `publishedAt / updatedAt`:发布时间或更新时间。
|
||||
|
||||
本次新增 `public_work_play_daily_stat` 日桶读模型,所有公开玩法的正式游玩入口在累加历史 `playCount` 时同步写入该表。公开列表返回时按作品聚合最近 7 个 UTC 自然日的 `recentPlayCount7d`,前端只负责展示与排序。
|
||||
|
||||
1. 热门榜按 `playCount` 降序。
|
||||
2. 改造榜按 `remixCount` 降序。
|
||||
3. 点赞榜按 `likeCount` 降序。
|
||||
4. 新品榜按 `recentPlayCount7d` 降序。
|
||||
|
||||
## 3. 交互规则
|
||||
|
||||
### 3.1 首页移动端
|
||||
|
||||
- 顶部搜索框保持不变。
|
||||
- 频道横滑 Tab 顺序为:推荐、今日游戏、游戏分类。
|
||||
- 推荐展示精选与最新去重后的作品流。
|
||||
- 今日游戏只展示 `publishedAt` 落在玩家当前浏览器自然日内的新发布公开作品;跨日旧作品即使仍在最新列表前排,也不能进入该频道。
|
||||
- 游戏分类展示原分类页内容:筛选胶囊 + 横向标签 + 当前标签下纵向作品列表。
|
||||
- 游戏分类列表参考移动应用商店结构,不再使用双列卡片:左侧方形封面,中间为作品名、状态角标、评分/题材、摘要或热度短句,右侧为“启动/试玩”主按钮。
|
||||
- 分类频道的筛选区只保留短标签,不写功能说明文案;筛选按钮展示当前标签数量,横向标签展示可切换的分类入口。
|
||||
|
||||
### 3.2 底部导航
|
||||
|
||||
- 登录态:`首页 / 排行 / 创作 / 存档 / 我的`。
|
||||
- 未登录态:`首页 / 创作 / 排行`。
|
||||
- 底部排行入口仍复用原 `category` Tab 的路由值,减少导航状态迁移风险,但所有用户可见文案改为“排行”。
|
||||
|
||||
### 3.3 排行页
|
||||
|
||||
- 顶部为横向榜单 Tab:热门榜、改造榜、新品榜、点赞榜。
|
||||
- 下方为纵向榜单列表,每行展示排名、封面、作品名、榜单指标、玩法类别、两个标签与进入按钮。
|
||||
- 公开作品名称在列表与卡片中统一限制为最多 8 字;公开作品标签统一限制为最多 4 字。
|
||||
- 排行榜单条目正文固定为三行:第一行作品名,第二行榜单数据与玩法类别,第三行展示两个标签;不再显示发布时间、作者名等第四行信息。
|
||||
- 无数据或加载中沿用现有短空态文案。
|
||||
|
||||
## 4. 编码落点
|
||||
|
||||
- `src/components/rpg-entry/RpgEntryHomeView.tsx`
|
||||
- 精简首页频道枚举。
|
||||
- 增加排行榜单构造、榜单切换状态与榜单行组件。
|
||||
- 将分类内容移动到移动端首页“游戏分类”频道。
|
||||
- 增加游戏分类纵向列表条目组件,替换移动端分类频道的双列作品网格。
|
||||
- 将底部/桌面侧边导航文案从“分类”改为“排行”。
|
||||
- `src/index.css`
|
||||
- 增加榜单行、榜单切换按钮、游戏分类筛选栏和纵向列表条目的主题化样式。
|
||||
- `server-rs/crates/spacetime-module/src/runtime/profile.rs`
|
||||
- 增加公开作品每日游玩统计表与 7 日聚合 helper。
|
||||
- `server-rs/crates/spacetime-module/src/migration.rs`
|
||||
- migration 表清单对齐 `public_work_play_daily_stat`。
|
||||
- `server-rs/crates/shared-contracts/src/*_works.rs`、`packages/shared/src/contracts/*`
|
||||
- 公开作品响应补齐 `recentPlayCount7d`。
|
||||
|
||||
## 5. 验收点
|
||||
|
||||
1. 移动端首页不再显示“PC游戏、即点即玩”。
|
||||
2. 点击首页“游戏分类”能看到原分类标签与作品列表。
|
||||
- 移动端分类作品必须为纵向列表,不能回退为两列网格。
|
||||
- 单条作品在 390px 宽度下必须保持封面、标题、按钮同一行可扫读,摘要截断且不挤压右侧按钮。
|
||||
3. 点击首页“今日游戏”只显示当天新发布作品;仅更新时间为今天但发布时间不在今天的作品不能进入今日频道。
|
||||
4. 底部导航显示“排行”,不再显示“分类”。
|
||||
5. 排行页可切换四个榜单,排序口径符合当前字段约束。
|
||||
6. 不修改 server-node,不新增 PostgreSQL 相关实现。
|
||||
@@ -0,0 +1,91 @@
|
||||
# 平台首页移动端信息流与作品卡设计
|
||||
|
||||
更新时间:`2026-04-28`
|
||||
|
||||
## 1. 本次目标
|
||||
|
||||
1. 桌面端首页布局保持现有顶部栏、侧边导航、Hero、趋势区与下方网格结构,不调整桌面端区块顺序。
|
||||
2. 移动端首页改为参考图式信息流:顶部搜索框、横向频道 Tab、纵向作品列表、底部主导航。
|
||||
3. 双端公开作品卡统一结构:上方 `16:9` 封面图,下方作品名称、作者信息、作品描述与玩法类型。
|
||||
4. 点赞数必须来自作品读模型字段,前端只负责展示,不把游玩数或评分临时改名成点赞。
|
||||
|
||||
## 2. 数据契约
|
||||
|
||||
### 2.1 统一字段
|
||||
|
||||
公开作品卡和创作中心复用的作品摘要都增加:
|
||||
|
||||
```ts
|
||||
likeCount: number;
|
||||
```
|
||||
|
||||
当前阶段只做只读展示,不新增点赞按钮和点击 reducer。后端对尚未接入真实点赞表的作品返回 `0`,保证接口 shape 稳定,后续可无 UI 结构迁移地接入真实互动计数。
|
||||
|
||||
### 2.2 各玩法映射
|
||||
|
||||
1. RPG 公开广场:`CustomWorldLibraryEntry` 与 `CustomWorldGalleryCard` 返回 `likeCount`,当前由 Rust facade 返回 `0`。
|
||||
2. 拼图公开广场:`PuzzleWorkSummary` 返回 `likeCount`,当前由 Rust facade 返回 `0`,`playCount` 继续仅表示游玩次数。
|
||||
3. 大鱼公开广场:`BigFishWorkSummary` 返回 `likeCount`,当前由 Rust facade 返回 `0`,`playCount` 继续仅表示游玩次数。
|
||||
4. 前端聚合类型 `PlatformPublicGalleryCard` 透传 `likeCount`,`WorldCard` 不再依赖 `badge/metaLabel` 决定主要信息结构。
|
||||
|
||||
### 2.3 首页读链路核对
|
||||
|
||||
首页公开作品流的读取链路固定为:
|
||||
|
||||
```text
|
||||
RpgEntryHomeView
|
||||
→ platformPublicGalleryClient / puzzleGalleryClient / bigFishGalleryClient
|
||||
→ Rust api-server
|
||||
→ spacetime-client 生成绑定
|
||||
→ spacetime-module procedure
|
||||
→ SpacetimeDB 表
|
||||
```
|
||||
|
||||
1. 公开读取必须匿名可用,前端 `GET` 列表与详情统一传 `skipAuth: true`、`skipRefresh: true`,避免未登录首页被刷新 token 链路阻断。
|
||||
2. 拼图公开广场走 `list_puzzle_gallery` / `get_puzzle_gallery_detail`,返回 `coverImageSrc`、`summary`、`themeTags`、`playCount`、`remixCount`、`likeCount`。
|
||||
3. 大鱼公开广场走 `list_big_fish_works(published_only=true)`;由于部分已部署模块会在公开列表分支前仍校验 `owner_user_id` 非空,客户端与模块内部公共列表输入都使用 `public-big-fish-gallery` 占位 owner。该字段在 `published_only` 分支不参与筛选,只用于兼容旧校验。
|
||||
4. 自定义世界公开广场走 `list_custom_world_gallery_entries`,当前主云数据为空时应返回成功空列表,而不是错误态。
|
||||
|
||||
### 2.4 作者头像读取策略
|
||||
|
||||
1. 首页“推荐”和“今日游戏”作品卡不把 `avatarUrl` 固化到作品读模型里,避免作者修改头像后旧作品卡继续展示过期头像。
|
||||
2. 前端首页在聚合公开作品后,按作品摘要中的 `authorPublicUserCode` 优先读取公开用户摘要;没有公开用户码的玩法摘要,使用 `ownerUserId` 读取公开用户摘要。
|
||||
3. 作者头像查询必须走匿名公开接口,并在首页组件内按作者维度缓存;单个作者在推荐与今日游戏中重复出现时不能重复请求。
|
||||
4. 公开用户摘要返回 `avatarUrl` 时,作品卡展示真实头像;头像缺失、读取失败或作者身份字段缺失时,继续使用作者昵称首字占位。
|
||||
|
||||
## 3. 移动端布局
|
||||
|
||||
1. 移动端首页只在 `RpgEntryHomeView` 的 mobile content 内重排。
|
||||
2. 第一屏顺序:
|
||||
- 搜索框
|
||||
- 频道横滑 Tab:推荐、今日游戏、游戏分类、PC游戏、即点即玩
|
||||
- 作品信息流
|
||||
3. 作品信息流使用单列纵向列表,卡片宽度填满容器,卡片之间保留短间距。
|
||||
4. 不新增功能说明类长文案;空态仍沿用现有短状态文案。
|
||||
5. 移动端卡片视觉允许接近参考图的深色信息流,但仍走平台主题 token,避免写死不可维护的大面积色块。
|
||||
|
||||
## 4. 作品卡结构
|
||||
|
||||
每张公开作品卡固定为:
|
||||
|
||||
1. 封面区域:`aspect-ratio: 16 / 9`,图片 `object-cover`;无封面时使用轻量主题底。
|
||||
2. 封面左上角不展示“推荐”标签,也不展示作者昵称标签,避免遮挡作品主视觉。
|
||||
3. 封面右下角展示三项轻量指标:游玩、改造、点赞;统一为图标 + 紧凑数字,例如 `128`、`1.2万`,不写额外说明长文案。
|
||||
4. 信息区域:
|
||||
- 第一行:作品名称,右侧展示玩法类型。拼图玩法展示“拼图”,大鱼玩法展示“大鱼”,RPG 作品展示题材短标签。
|
||||
- 第二行:原副标题位置展示作者头像和昵称。当前公开列表只返回作者昵称时,头像使用昵称首字生成的轻量头像;后续接入作者头像 URL 后复用同一位置。
|
||||
- 第三行:作品描述,两行截断。
|
||||
- 第四行:最多三个标签。
|
||||
5. 点赞数仍必须来自作品读模型字段,只是展示位置从信息区右侧迁移到封面右下角。
|
||||
6. 不展示作品号;作品号仍只在详情页或分享路径中使用。
|
||||
|
||||
## 5. 验收
|
||||
|
||||
1. 390px 移动端首页不横向溢出,能看到搜索、频道和纵向作品列表。
|
||||
2. 桌面端首页布局区块顺序不变,只替换公开作品卡内部结构。
|
||||
3. RPG、拼图、大鱼三类公开作品卡都有 `likeCount` 字段,前端聚合后能统一展示。
|
||||
4. 运行编码检查、前端定向测试和必要的 Rust 检查。
|
||||
5. HTTP 验收需覆盖:
|
||||
- `GET /api/runtime/custom-world-gallery` 成功返回 `entries`。
|
||||
- `GET /api/runtime/puzzle/gallery` 成功返回 `items` 且包含 `likeCount`。
|
||||
- `GET /api/runtime/big-fish/gallery` 成功返回 `items`,旧部署模块不再因 `big_fish.owner_user_id 不能为空` 阻断首页。
|
||||
@@ -96,7 +96,7 @@
|
||||
- 同时开放短信与密码登录时,面板顶部展示两个居中的文字页签,当前页签使用深色字重和短下划线强调。
|
||||
- 只渲染当前页签对应的输入区;切换页签不弹出新面板,不展示二维码入口。
|
||||
- `短信登录` 页签包含手机号、验证码、获取验证码和主按钮。
|
||||
- `密码登录` 页签只包含手机号、密码、主按钮和忘记密码入口;不支持邮箱、用户名或叙世号。
|
||||
- `密码登录` 页签只包含手机号、密码、主按钮和忘记密码入口;不支持邮箱、用户名或百梦号。
|
||||
- 密码登录只是手机号验证码登录的补充方式:只有已登录并设置过密码的手机号账号才能使用,不能在密码页签创建账号。
|
||||
- `密码登录` 主按钮固定为 `登录`,不得使用 `注册/登录`。
|
||||
- 未开放某个登录方式时不展示对应页签,避免用户进入不可用表单。
|
||||
|
||||
@@ -59,8 +59,8 @@
|
||||
### 3.2 排版
|
||||
|
||||
- 平台层正文、按钮、说明、功能标签统一使用非像素字体
|
||||
- 左上角 `叙世 / GENARRATIVE` 品牌字标允许单独做成像素化 logo
|
||||
- `GENARRATIVE` 与 `叙世` 都优先直接使用游戏内同款 `Fusion Pixel`
|
||||
- 左上角 `百梦 / GENARRATIVE` 品牌字标允许单独做成像素化 logo
|
||||
- `GENARRATIVE` 与 `百梦` 都优先直接使用游戏内同款 `Fusion Pixel`
|
||||
- 品牌字标默认保持正常像素字观感,禁止再叠双层粗阴影或手动加粗到影响识别
|
||||
- 品牌字标直接使用字体文件内原字形,不额外做运行时描字、轮廓拼字或伪粗体处理
|
||||
- 主标题保留明显层级,但不再做像素描边效果
|
||||
|
||||
@@ -0,0 +1,106 @@
|
||||
# 平台统一作品详情页与 Remix 数据链路设计
|
||||
|
||||
更新时间:`2026-05-01`
|
||||
|
||||
## 1. 本次目标
|
||||
|
||||
1. 平台首页、公开广场、分类列表中的每个公开作品点击后,统一先进入作品详情页,不再直接启动玩法。
|
||||
2. 作品详情页结构参考 TapTap 详情页:顶部封面图、作品基础信息、右侧“点赞”按钮、四项统计、简介内容、底部“作品改造 + 启动”同行动作。
|
||||
3. 删除参考图顶部 Tab,不接入评价和论坛功能,不展示“开发者的话”模块。
|
||||
4. 统计数据必须从数据库读模型贯穿到前端展示,禁止在前端用假字段、游玩数冒充点赞数或固定文案代替真实字段。
|
||||
5. Remix 按钮必须由后端事务复制公开作品为当前用户草稿,并同步增加原作品改造次数,成功后前端进入新草稿详情/结果页。
|
||||
|
||||
## 2. 详情页 UI 结构
|
||||
|
||||
统一详情页只做作品展示与动作入口,不承担规则说明。
|
||||
|
||||
1. 顶部导航:返回按钮、标题“详情”、更多按钮占位;不展示“统计 / 详情 / 评价 / 论坛”Tab。
|
||||
2. 封面区:固定 `16:9` 比例,默认使用作品封面图 `cover` 填满整块主视觉;背景可用同图弱化铺底;缺图时只显示平台主题底,不新增说明文字。拼图作品详情页若详情数据包含多个关卡图,则顶部封面区优先按关卡正式图轮播展示,每张图对应一个关卡;无可用关卡图时再回退作品封面图。拼图多关封面只默认展示第一张真实图,轮播节奏与左右切换保持不变;未解锁的后续封面必须使用同图毛玻璃模糊底和大问号图标遮罩,不能展示真实清晰图,也不能追加规则说明文字。玩家完成对应前置关卡后,当前详情页可按本次 `PuzzleRunSnapshot.clearedLevelCount + 1` 即时解锁可见封面数;刷新后持久化解锁应由后端从当前用户的拼图运行记录汇总到详情读模型,前端只消费读模型或当前 run 状态。
|
||||
3. 移动端首页“推荐”和“今日游戏”列表中,只有最接近屏幕垂直中心的作品卡片进入封面轮播态;若该拼图作品有多张关卡封面,则按详情页同源封面序列自动轮换。用户滚动后,离开中心的旧卡片必须立即恢复首张封面,新中心卡片再开始轮播;“游戏分类”、排行、桌面端列表不启用该自动轮播。
|
||||
4. 基础信息区:
|
||||
- 左侧作品图标使用作品封面序列首图;顶部封面轮播切换时,该正方形图标保持首图不变,避免作品名称旁的身份标识跟随大图闪动。
|
||||
- 中间展示作品名、作者头像、作者名、玩法类型;作者头像读取公开用户资料 `avatarUrl`,缺失时使用作者昵称首字占位。
|
||||
- 右侧原 TapTap 评分位置替换为 `点赞` 按钮;点击后调用后端点赞接口,由后端记录当前登录用户对该公开作品的点赞关系并返回更新后的真实 `likeCount` 读模型,前端不伪造点赞增长。
|
||||
5. 统计区固定四项:
|
||||
- 游玩:`playCount`,显示为“数字 + 次”,单位放在数字后方。
|
||||
- 改造:`remixCount`,显示为“数字 + 次”,单位放在数字后方。
|
||||
- 点赞:`likeCount`,显示为“数字 + 赞”,单位放在数字后方。
|
||||
- 日期:优先展示 `updatedAt`,缺失时回退 `publishedAt`;前端只负责格式化显示,必须兼容后端当前 `seconds.microsZ` 与 ISO 字符串两种真实时间文本,显示为完整 `YYYY-MM-DD`,使用更小字号并保持单行不换行。
|
||||
- 四项统计需要使用浅色图标底强化识别,但不得追加规则说明类文案。
|
||||
6. 简介区:展示玩法标签和作品简介;不追加说明类文案。
|
||||
7. 底部动作:左侧按钮为“作品改造”,右侧主按钮为“启动”;两个按钮必须位于同一行,点击“启动”后进入对应玩法运行态并记录游玩次数。
|
||||
- 未登录用户可进入并浏览作品详情页,但点击“作品改造”和“启动”都必须先弹出登录入口面板;登录成功后自动继续刚才点击的动作,不直接发起 Remix、启动 run 或本地运行态。
|
||||
8. 页面配色必须跟随平台明暗主题变量;亮色主题使用平台浅色底、深色文字和主按钮渐变,暗色主题使用平台暗色底、亮色文字和对应主按钮渐变,不在详情页写死独立黑色皮肤。
|
||||
9. 字号规范跟随平台页面既有节奏:标题/主按钮使用 `1rem` 级别,作品名使用卡片标题同级 `1rem`,辅助信息与简介使用 `0.8125rem` / `0.875rem`,标签与统计标签使用 `0.75rem`,避免在详情页使用随视口放大的独立大字号。
|
||||
|
||||
## 3. 数据真相源
|
||||
|
||||
### 3.1 RPG 作品
|
||||
|
||||
1. `custom_world_profile` 增加 `play_count`、`remix_count`、`like_count`。
|
||||
2. `custom_world_gallery_entry` 同步这三项统计,作为公开详情和首页卡片读模型。
|
||||
3. `record_custom_world_profile_play` 负责在公开作品启动前递增 `play_count`,只更新已发布且未删除作品。
|
||||
4. `record_custom_world_profile_like` 负责记录当前用户对公开作品的点赞;同一用户对同一公开作品只计入一次,首次点赞时递增 `like_count` 并同步刷新 `custom_world_gallery_entry`。
|
||||
5. `remix_custom_world_profile` 在同一事务内:
|
||||
- 校验源作品已发布、未删除。
|
||||
- 递增源作品 `remix_count` 并刷新源作品 gallery。
|
||||
- 复制源 profile payload 为当前用户草稿,清空公开编号、发布时间与统计。
|
||||
- 返回新草稿 profile,供前端进入草稿详情页。
|
||||
|
||||
### 3.2 拼图作品
|
||||
|
||||
1. `puzzle_work_profile` 保留既有 `play_count`,新增 `remix_count`、`like_count`。
|
||||
2. `start_puzzle_run` 继续作为游玩次数递增入口。
|
||||
3. `record_puzzle_work_like` 负责记录当前用户对公开拼图作品的点赞;同一用户对同一公开作品只计入一次,首次点赞时递增 `like_count`。
|
||||
4. `remix_puzzle_work` 在同一事务内:
|
||||
- 校验源 profile 为已发布作品。
|
||||
- 递增源作品 `remix_count`。
|
||||
- 新建当前用户拼图 Agent session,并把源作品锚点、封面、简介复制为草稿。
|
||||
- 新建当前用户草稿 profile,统计归零,返回新草稿 session 与 profile。
|
||||
4. API facade 解析拼图 `item_json` / `items_json` 时必须兼容历史公开作品缺失 `play_count`、`remix_count`、`like_count` 的 JSON,缺失值统一按 `0` 处理;新写入数据仍必须写全统计字段。
|
||||
|
||||
### 3.3 大鱼吃小鱼作品
|
||||
|
||||
1. `big_fish_creation_session` 现有 `play_count` 继续作为游玩统计,新增 `remix_count`、`like_count`、`published_at`。
|
||||
2. `publish_big_fish_game` 写入 `published_at` 与 `updated_at`,公开列表和详情优先用 `updated_at` 展示最近更新。
|
||||
3. `record_big_fish_play` 继续作为游玩次数递增入口。
|
||||
4. `record_big_fish_like` 负责记录当前用户对公开大鱼作品的点赞;同一用户对同一公开作品只计入一次,首次点赞时递增 `like_count`。
|
||||
5. `remix_big_fish_work` 在同一事务内:
|
||||
- 校验源 session 为已发布作品。
|
||||
- 递增源作品 `remix_count`。
|
||||
- 新建当前用户创作 session,复制锚点、草稿和资源槽,阶段回到可编辑草稿态。
|
||||
- 新 session 的统计归零,返回新草稿 session。
|
||||
|
||||
## 4. API 与前端接入
|
||||
|
||||
1. 三类公开作品摘要统一返回:`playCount`、`remixCount`、`likeCount`、`publishedAt`、`updatedAt`。
|
||||
- 作者头像不固化到作品读模型;详情页按 `authorPublicUserCode` 或 `ownerUserId` 读取公开用户摘要中的 `avatarUrl`,确保头像跟随账号资料更新。
|
||||
2. Remix API:
|
||||
- RPG:`POST /api/runtime/custom-world-gallery/{owner_user_id}/{profile_id}/remix`
|
||||
- 拼图:`POST /api/runtime/puzzle/gallery/{profile_id}/remix`
|
||||
- 大鱼:`POST /api/runtime/big-fish/gallery/{session_id}/remix`
|
||||
3. 点赞 API:
|
||||
- RPG:`POST /api/runtime/custom-world-gallery/{owner_user_id}/{profile_id}/like`
|
||||
- 拼图:`POST /api/runtime/puzzle/gallery/{profile_id}/like`
|
||||
- 大鱼:`POST /api/runtime/big-fish/gallery/{session_id}/like`
|
||||
- 三个接口都必须走登录态鉴权,后端使用当前登录用户身份写入点赞关系;重复点击返回当前最新读模型,不重复增加 `likeCount`。
|
||||
4. 前端统一详情页只消费读模型字段,不自行派生统计。
|
||||
5. 首页卡片点击只设置统一详情状态;启动、点赞与 Remix 只能在详情页触发。
|
||||
6. Remix 成功后的跳转:
|
||||
- RPG:进入复制出的草稿详情。
|
||||
- 拼图:进入复制出的拼图结果页草稿。
|
||||
- 大鱼:进入复制出的大鱼结果页草稿。
|
||||
7. 拼图作品详情页启动时复用当前详情页已经展示的公开作品读模型,直接调用 `POST /api/runtime/puzzle/runs` 记录游玩并进入运行态;不得在启动前额外依赖 `GET /api/runtime/puzzle/gallery/{profile_id}`,避免开发代理或详情读取短断点阻塞启动链路。
|
||||
8. 本地开发时 `localhost:3000` 是 Vite 前端端口,`/api/**` 默认代理到 Rust `api-server:3100`;若 3100 未监听,点击启动、点赞或作品改造会在浏览器显示 `/api/... 500`,此时真实断点是 Rust 后端未启动,不允许用前端假数据替代后端事务。
|
||||
|
||||
## 5. 验收点
|
||||
|
||||
1. 三类作品从首页点击均先进入统一作品详情页。
|
||||
2. 详情页无评价、论坛 Tab,无开发者的话模块。
|
||||
3. 四项统计在前端、共享契约、API facade、SpacetimeDB 表之间字段一致。
|
||||
4. Remix 后原作品改造次数增加,新草稿归当前用户所有,且不会继承源作品统计。
|
||||
5. 点赞公开作品会走对应后端记录入口,首次点赞后刷新仍能看到递增后的点赞次数,重复点赞不会继续增加。
|
||||
6. 启动公开作品会走对应后端记录入口,刷新后仍能看到递增后的游玩次数。
|
||||
7. 未登录进入作品详情页后,点击“作品改造”和“启动”只打开登录入口面板;登录成功后恢复对应动作,未登录期间不会创建 Remix 草稿、开始拼图 run、记录 RPG 游玩或启动大鱼本地运行态。
|
||||
8. 移动端首页“推荐”和“今日游戏”列表滚动时,仅中心卡片自动轮播多封面;旧中心卡离开后回到首张封面,新的中心卡接续轮播。
|
||||
9. 修改后运行编码检查、SpacetimeDB 绑定生成、Rust 检查和必要前端测试。
|
||||
@@ -29,6 +29,14 @@
|
||||
|
||||
网格规模仍可作为运行时内部状态存在,但不默认写在 UI 顶栏中。
|
||||
|
||||
### 1.1 2026-04-30 顶栏与底部工具补充
|
||||
|
||||
1. 顶栏作者信息不再只显示一行作者名,必须展示为作者头像与昵称组合;当前运行态只提供昵称时,用昵称首字生成圆形占位头像。
|
||||
2. 倒计时组件提升为顶栏中的强信息,字号、内边距和图标尺寸都需要明显大于作者昵称与关卡序号。
|
||||
3. 底部只保留 `提示 / 原图 / 冻结` 三个功能按钮,并整体居中展示;三个按钮触控面积和图标字号都需要放大。
|
||||
4. 底部不再展示“等待下一关候选”这类状态占位。通关后在三个道具按钮上方固定展示“下一关”按钮,展示条件只依赖当前关卡已通关,不依赖 `recommendedNextProfileId` 是否已有值。
|
||||
5. 点击底部“下一关”按钮继续调用运行时壳层已有 `onAdvanceNextLevel` 事件;正式 run 由后端 `next-level` 选择候选,本地 run 由 `local-next-level` 生成或接续下一关,前端不在按钮层自行决定下一关来源。
|
||||
|
||||
### 2. 拼图块显示规则
|
||||
|
||||
运行时单块右下角编号全部移除。
|
||||
|
||||
@@ -4,12 +4,14 @@
|
||||
|
||||
## 文档列表
|
||||
|
||||
- [CUSTOM_WORLD_CREATOR_INPUT_AND_AI_BOUNDARY_DESIGN_2026-04-06.md](./CUSTOM_WORLD_CREATOR_INPUT_AND_AI_BOUNDARY_DESIGN_2026-04-06.md):自定义世界里创作者输入与 AI 分工边界设计。
|
||||
- [CUSTOM_WORLD_CREATOR_INPUT_AND_AI_BOUNDARY_DESIGN_2026-04-06.md](./CUSTOM_WORLD_CREATOR_INPUT_AND_AI_BOUNDARY_DESIGN_2026-04-06.md):自定义世界里百梦主输入与 AI 分工边界设计。
|
||||
- [CUSTOM_WORLD_CREATOR_MANUAL_AI_SYSTEM_BALANCE_DESIGN_2026-04-12.md](./CUSTOM_WORLD_CREATOR_MANUAL_AI_SYSTEM_BALANCE_DESIGN_2026-04-12.md):自定义世界创作里“手填锚点 / AI 可改初稿 / 系统托管层”的平衡设计。
|
||||
- [CUSTOM_WORLD_CREATOR_PURE_AGENT_COMPARISON_AND_CONVERSION_DESIGN_2026-04-12.md](./CUSTOM_WORLD_CREATOR_PURE_AGENT_COMPARISON_AND_CONVERSION_DESIGN_2026-04-12.md):纯 Agent 式创作工具与结构化工作台方案的优缺点对比,以及转型设计。
|
||||
- [CUSTOM_WORLD_TEMPLATE_DECOUPLING_AND_CROSS_GENRE_GENERALIZATION_DESIGN_2026-04-08.md](./CUSTOM_WORLD_TEMPLATE_DECOUPLING_AND_CROSS_GENRE_GENERALIZATION_DESIGN_2026-04-08.md):把自定义世界从武侠/仙侠模板依赖迁到跨题材通用设定层的优化设计。
|
||||
- [CUSTOM_WORLD_SELF_OWNED_SETTING_LAYER_OPTIMIZATION_2026-04-08.md](./CUSTOM_WORLD_SELF_OWNED_SETTING_LAYER_OPTIMIZATION_2026-04-08.md):把模板依赖逐步迁成自定义世界自有设定层,并保证不破坏当前生成流程的优化方案。
|
||||
- [MOBILE_CREATION_NEW_WORK_COMPACT_LAYOUT_2026-04-24.md](./MOBILE_CREATION_NEW_WORK_COMPACT_LAYOUT_2026-04-24.md):移动端创作页新建作品模块最多占用首屏约 1/3 高度的紧凑布局设计。
|
||||
- [MOBILE_CREATION_WORK_LIST_TWO_COLUMN_LAYOUT_2026-04-29.md](./MOBILE_CREATION_WORK_LIST_TWO_COLUMN_LAYOUT_2026-04-29.md):移动端创作页作品列表至少 2 列的紧凑布局设计。
|
||||
- [PLATFORM_HOME_MOBILE_FEED_CARD_REDESIGN_2026-04-28.md](./PLATFORM_HOME_MOBILE_FEED_CARD_REDESIGN_2026-04-28.md):平台首页移动端参考图式信息流、双端公开作品卡 16:9 封面结构与点赞数读模型设计。
|
||||
- [PLATFORM_CATEGORY_AND_CREATE_TAB_DESIGN_2026-04-24.md](./PLATFORM_CATEGORY_AND_CREATE_TAB_DESIGN_2026-04-24.md):平台入口新增分类 Tab、登录态导航裁剪与创作 Tab 视觉强化设计。
|
||||
- [PLATFORM_BIG_FISH_ENTRY_HIDE_2026-04-28.md](./PLATFORM_BIG_FISH_ENTRY_HIDE_2026-04-28.md):平台入口暂时隐藏大鱼吃小鱼创作卡片,但保留现有玩法链路。
|
||||
- [UNIFIED_MODAL_WINDOW_DESIGN_2026-04-25.md](./UNIFIED_MODAL_WINDOW_DESIGN_2026-04-25.md):统一平台风与 RPG 像素风模态窗口外壳、交互边界和迁移顺序。
|
||||
@@ -27,8 +29,8 @@
|
||||
|
||||
- 做物品、Build、锻造相关需求时,先看前两份。
|
||||
- 做 RPG 全剧情规划、主支线矩阵、角色线、场景章节与剧情交付模板时,先看新增的全剧情策划流程。
|
||||
- 做自定义世界创作工作台、创作者输入边界、AI 分工设计时,先看第一份。
|
||||
- 做“哪些内容必须让创作者手填、哪些适合 AI 先生成再改、哪些必须系统托管”这类分层设计时,优先看新增的输入平衡设计稿。
|
||||
- 做自定义世界创作工作台、百梦主输入边界、AI 分工设计时,先看第一份。
|
||||
- 做“哪些内容必须让百梦主手填、哪些适合 AI 先生成再改、哪些必须系统托管”这类分层设计时,优先看新增的输入平衡设计稿。
|
||||
- 做“是否应该转成纯 Agent 式创作工具、转了之后前后台各该怎么收口”这类产品方向评估时,优先看新增的纯 Agent 对比与转型设计稿。
|
||||
- 做自定义世界去模板依赖、跨题材泛化、兼容迁移设计时,优先看新增的去模板化优化设计稿。
|
||||
- 做“模板依赖如何真正变成自定义世界自有设定层”的具体迁移方案时,优先看新增的自有设定层优化方案。
|
||||
|
||||
+20
-13
@@ -11,14 +11,17 @@
|
||||
1. 负好感或敌对 NPC 进入聊天后,不再设置固定 5 回合上限。
|
||||
2. 负好感或敌对 NPC 每轮回复后,模型必须判断本轮是否结束聊天。
|
||||
3. 敌对 NPC 判定时应偏向随时结束聊天并进入对峙,但必须结合玩家刚说的话、NPC 性格、当前剧情压力和对话历史。
|
||||
4. 好感度大于等于 0 且非敌对 NPC 不启用模型终止判定,玩家可一直聊天。
|
||||
5. 模型判定终止后,聊天面板不再继续提供聊天输入,只显示“继续”按钮,点击后沿用原流程继续生成冒险选项。
|
||||
6. 点击“退出聊天”不再直接收起聊天页,也不立即进入剧情推理;它会发送一条结束聊天的玩家输入,对方回复后同样只显示“继续”按钮。
|
||||
7. 正向 NPC 的退出聊天只是玩家主动收束,不代表模型强制中止,也不展示战斗/逃跑选项。
|
||||
8. 对负好感或敌对 NPC,在聊天终止后的后续流程仍沿用敌对出口:继续推进后展示一个“战斗”选项,以及按相邻场景和当前场景起点展开的多个逃跑选项。
|
||||
9. 聊天候选中允许混入当前 NPC 可执行 function,例如交易、送礼、请求帮助、招募、接任务、交任务、开战、离开等。
|
||||
10. Function 候选进入聊天上下文时只作为可触发动作,不在 UI 中展示说明类文本。
|
||||
11. “换一换”在聊天态可用,用于在不推进对话的情况下改排/轮换当前候选;它不调用后端,不改变聊天历史。
|
||||
4. 敌对 NPC 感知到玩家负面发言时,例如挑衅、威胁、羞辱、逼问、拒绝退让、直接宣战或强行越界,应倾向立即 `shouldEndChat=true`。
|
||||
5. 敌对 NPC 已聊天轮次超过 4 轮后,应倾向立即 `shouldEndChat=true`,避免敌对关系被拖成长时间闲聊。
|
||||
6. 敌对 NPC 最后一轮回复必须像战斗、驱逐或正面对峙前的狠话:短促、带压迫感、明确把局势推向行动前一刻,但不在对白中直接结算战斗。
|
||||
7. 好感度大于等于 0 且非敌对 NPC 不启用模型终止判定,玩家可一直聊天。
|
||||
8. 模型判定终止后,聊天面板不再继续提供聊天输入,只显示“继续”按钮,点击后沿用原流程继续生成冒险选项。
|
||||
9. 点击“退出聊天”不再直接收起聊天页,也不立即进入剧情推理;它会发送一条结束聊天的玩家输入,对方回复后同样只显示“继续”按钮。
|
||||
10. 正向 NPC 的退出聊天只是玩家主动收束,不代表模型强制中止,也不展示战斗/逃跑选项。
|
||||
11. 对负好感或敌对 NPC,在聊天终止后的后续流程仍沿用敌对出口:继续推进后展示一个“战斗”选项,以及按相邻场景和当前场景起点展开的多个逃跑选项。
|
||||
12. 聊天候选中允许混入当前 NPC 可执行 function,例如交易、送礼、请求帮助、招募、接任务、交任务、开战、离开等。
|
||||
13. Function 候选进入聊天上下文时只作为可触发动作,不在 UI 中展示说明类文本。
|
||||
14. “换一换”在聊天态可用,用于在不推进对话的情况下改排/轮换当前候选;它不调用后端,不改变聊天历史。
|
||||
|
||||
## 3. 后端契约
|
||||
|
||||
@@ -43,12 +46,14 @@
|
||||
1. 敌对聊天可随时中止,NPC 更偏好结束谈判转入战斗或驱逐。
|
||||
2. 终止不等于在回复正文里直接执行战斗,只需要用台词把对话收束到对峙、威胁、驱逐、最后通牒或行动前一刻。
|
||||
3. 玩家主动退出聊天时,NPC 回复要对这次收束作出回应,并留下自然的后续入口。
|
||||
4. 若玩家本轮发言明显负面,或敌对聊天已进入第 5 轮及之后,回复 prompt 要提示 NPC 直接给出战斗前、驱逐前或正面对峙前的狠话。
|
||||
|
||||
建议 prompt 需要明确:
|
||||
|
||||
1. 常规聊天候选继续生成玩家台词。
|
||||
2. Function 候选要根据提供的 function 列表,改写成玩家可直接点击的动作文本。
|
||||
3. 不输出规则说明,不把 functionId 暴露给玩家。
|
||||
4. 敌对聊天判断 `shouldEndChat` 时,负面发言和已聊天轮次超过 4 轮都应作为强收束信号;如果返回 `shouldEndChat=true`,`terminationReason` 使用 `hostile_breakoff`。
|
||||
|
||||
## 5. 前端流程
|
||||
|
||||
@@ -81,8 +86,10 @@
|
||||
1. 负好感主 NPC 不再出现固定 `turnLimit: 5`。
|
||||
2. 敌对 NPC 每轮请求会向后端传 `terminationMode: hostile_model`。
|
||||
3. 模型返回 `forceExit: true` 后,聊天输入消失,只显示继续按钮。
|
||||
4. 好感度大于等于 0 的 NPC 聊天不传敌对中止模式。
|
||||
5. 点击退出聊天会新增玩家结束聊天气泡与 NPC 回复,而不是直接切走面板。
|
||||
6. 聊天态可看到并点击 function 候选,且“换一换”可改变候选顺序。
|
||||
7. 选项文字前出现中文 function 标签,且标签不改变原 actionText。
|
||||
8. 聊天结束后的“继续冒险”直接进入下一幕;最后一幕则展示多个相邻场景方向入口。
|
||||
4. 玩家对敌对 NPC 说出挑衅、威胁、羞辱、逼问、拒绝退让、直接宣战或强行越界类发言时,模型应倾向返回 `shouldEndChat=true`,NPC 最后一轮回复带战斗前狠话。
|
||||
5. 敌对 NPC 已聊天轮次超过 4 轮后,模型应倾向返回 `shouldEndChat=true`,NPC 最后一轮回复带战斗前狠话。
|
||||
6. 好感度大于等于 0 的 NPC 聊天不传敌对中止模式。
|
||||
7. 点击退出聊天会新增玩家结束聊天气泡与 NPC 回复,而不是直接切走面板。
|
||||
8. 聊天态可看到并点击 function 候选,且“换一换”可改变候选顺序。
|
||||
9. 选项文字前出现中文 function 标签,且标签不改变原 actionText。
|
||||
10. 聊天结束后的“继续冒险”直接进入下一幕;最后一幕则展示多个相邻场景方向入口。
|
||||
|
||||
@@ -207,4 +207,12 @@
|
||||
|
||||
---
|
||||
|
||||
## 18. 2026-04-30 资料兑换码弹窗响应式修正
|
||||
|
||||
- `RpgEntryHomeView.tsx` 的兑换码弹窗现在抽成同一份 `rewardCodeModal`,桌面与移动端分支都挂载,避免竖屏点击头像右侧“兑换码”后只更新状态但不显示窗口。
|
||||
- `src/index.css` 已补齐 `platform-modal-backdrop`、`platform-recharge-modal`、`platform-profile-input`、`platform-primary-button`、`platform-modal-close` 与兑换结果提示样式;后续资料类轻量弹窗可以复用这组类接入平台主题背景。
|
||||
- 兑换码窗口仍只保留输入框、兑换按钮和后端返回提示,不新增规则说明文案。
|
||||
|
||||
---
|
||||
|
||||
_文档目的:交接给下一个 Agent 时,优先读本文件 + `UI_CODING_STANDARD.md`,再改 `uiAssets.ts` / `App.tsx` / `index.css`。_
|
||||
|
||||
@@ -29,7 +29,7 @@
|
||||
|
||||
结论:
|
||||
- 独立编辑器入口如果没有继续接入主流程,应及时物理删除,不要长期保留兼容壳
|
||||
- 页签命名要贴近创作者语言,而不是内部实现命名
|
||||
- 页签命名要贴近百梦主语言,而不是内部实现命名
|
||||
|
||||
### 2.2 NPC 视觉模块并入 NPC 编辑
|
||||
|
||||
@@ -144,7 +144,7 @@
|
||||
|
||||
经验:
|
||||
|
||||
- 创作者并不关心 “function” 这个技术词,更关心“这个选项会发生什么”
|
||||
- 百梦主并不关心 “function” 这个技术词,更关心“这个选项会发生什么”
|
||||
- 同类编辑器如果只给字段表单而没有模板起稿能力,复用效率会很低
|
||||
|
||||
### 2.8 选项行为预览升级到实机回放
|
||||
@@ -217,7 +217,7 @@
|
||||
|
||||
- 预览面板要么都显示“实时状态”
|
||||
- 要么都显示“同一个阶段的快照”
|
||||
- 混用实时值和预测值会让创作者误判
|
||||
- 混用实时值和预测值会让百梦主误判
|
||||
|
||||
## 4. 这类项目里沉淀下来的方法论
|
||||
|
||||
@@ -245,7 +245,7 @@
|
||||
|
||||
- 不是所有字段都应该在所有行为类型下开放
|
||||
- 如果某类行为最终不会直接读取某个字段,就应该禁用或弱化它
|
||||
- 否则创作者会错误地以为改动无效是 bug
|
||||
- 否则百梦主会错误地以为改动无效是 bug
|
||||
|
||||
### 4.4 模板比空白表单更重要
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@
|
||||
|
||||
3. 历史已发布作品必须能自动补齐 gallery 投影。
|
||||
- 公开列表读取 `list_custom_world_gallery_entries` 前,会扫描 `custom_world_profile` 中已发布且未删除的 profile。
|
||||
- 若已发布 profile 缺少 `custom_world_gallery_entry`,或缺少公开作品码 / 作者叙世号,会先补齐公开字段并同步 gallery 投影。
|
||||
- 若已发布 profile 缺少 `custom_world_gallery_entry`,或缺少公开作品码 / 作者百梦号,会先补齐公开字段并同步 gallery 投影。
|
||||
- 这样旧版本发布成功但未落入广场读模型的作品,在下一次首页 / 分类页读取公开列表时会自动出现。
|
||||
|
||||
## 经验
|
||||
|
||||
@@ -394,7 +394,7 @@ MVP 阶段不需要单独设置密码。
|
||||
|
||||
落地规则:
|
||||
|
||||
- 入参只允许 `phone` 和 `password`,不支持邮箱、用户名或叙世号。
|
||||
- 入参只允许 `phone` 和 `password`,不支持邮箱、用户名或百梦号。
|
||||
- 手机号不存在时,不创建账号,返回统一的登录失败。
|
||||
- 手机号存在但账号未设置过密码时,不允许密码登录。
|
||||
- 首次设置密码只能在已登录账号中心内完成;用户必须先通过手机号验证码或已绑定手机号的微信账号进入已登录态。
|
||||
@@ -734,7 +734,7 @@ MVP 阶段建议至少提供一个轻量账号中心,包含:
|
||||
|
||||
约束:
|
||||
|
||||
- 不支持邮箱、用户名或叙世号。
|
||||
- 不支持邮箱、用户名或百梦号。
|
||||
- 不承担注册能力。
|
||||
- 只有已存在、已验证手机号、且 `passwordLoginEnabled=true` 的账号可以登录。
|
||||
|
||||
|
||||
@@ -0,0 +1,169 @@
|
||||
# 后台管理独立前端工程 PRD
|
||||
|
||||
日期:`2026-04-30`
|
||||
|
||||
## 1. 目标
|
||||
|
||||
本 PRD 定义当前项目的后台管理独立前端工程 v1。目标不是重做一套后端,也不是把玩家端前端改造成后台,而是在 monorepo 内新增一个独立管理端应用,正式承接已经从 `api-server` 内嵌页面移出的后台 UI。
|
||||
|
||||
首版目标:
|
||||
|
||||
1. 后台 UI 独立落在 `apps/admin-web`,不再写入 Rust 源码字符串。
|
||||
2. 管理数据、业务规则、权限校验和写操作继续统一走 `server-rs/crates/api-server`。
|
||||
3. v1 只接管已有管理能力:管理员登录、当前管理员信息、服务/数据库概览、受控 API 调试、兑换码管理、注册邀请码管理。
|
||||
4. 保持管理端清爽、可扫读、移动端可用,不在界面堆大段规则说明。
|
||||
5. 发布包内由 Web 网关把独立后台前端挂到同域 `/admin/`;Rust `api-server` 自身仍不恢复旧的 `GET /admin` 内嵌页面。
|
||||
|
||||
## 2. 用户与使用场景
|
||||
|
||||
### 2.1 目标用户
|
||||
|
||||
1. 项目开发者:用于本地或测试环境快速查看 `api-server` 与 SpacetimeDB 连接状态。
|
||||
2. 运维/运营人员:用于创建、更新、停用兑换码,预置注册邀请码,以及确认后台接口是否可用。
|
||||
3. 后续后台功能开发者:以本工程作为后续用户、作品、资产、审核等管理模块的承载壳。
|
||||
|
||||
### 2.2 首版高频场景
|
||||
|
||||
1. 管理员打开后台登录页,输入环境变量配置的管理员用户名和密码。
|
||||
2. 登录后进入总览页,确认当前服务监听、JWT issuer、SpacetimeDB server/database、schema 表数量和关键表统计。
|
||||
3. 在 API 调试页对当前 `api-server` 的同源相对路径发起受控请求,排查接口状态。
|
||||
4. 在兑换码管理页创建或更新公共码、唯一码、私有码,并在需要时停用兑换码。
|
||||
5. 在邀请码管理页创建或更新注册链路使用的邀请码与 metadata。
|
||||
|
||||
## 3. 功能范围
|
||||
|
||||
### 3.1 包含
|
||||
|
||||
1. 独立前端工程骨架:`apps/admin-web`。
|
||||
2. 登录页:
|
||||
- 调用 `POST /admin/api/login`。
|
||||
- 登录成功后保存管理员 Bearer token。
|
||||
- 登录失败直接展示后端返回的错误消息。
|
||||
3. 管理端 Shell:
|
||||
- 顶部显示当前管理员、登录状态和退出按钮。
|
||||
- 侧边或底部导航包含“总览”“API 调试”“兑换码”“邀请码”。
|
||||
- 移动端导航改为底部或顶部紧凑标签。
|
||||
4. 总览页:
|
||||
- 调用 `GET /admin/api/me` 恢复管理员会话。
|
||||
- 调用 `GET /admin/api/overview` 展示服务和数据库概览。
|
||||
- 表统计允许部分失败,并直接展示失败项。
|
||||
5. API 调试页:
|
||||
- 调用 `POST /admin/api/debug/http`。
|
||||
- 只允许填写同源相对路径,不提供绝对 URL 输入暗示。
|
||||
- 调试结果在独立结果面板展示状态码、响应头、响应文本和 JSON 预览。
|
||||
6. 兑换码管理页:
|
||||
- 调用 `POST /admin/api/profile/redeem-codes` 创建/更新兑换码。
|
||||
- 调用 `POST /admin/api/profile/redeem-codes/disable` 停用兑换码。
|
||||
- 支持 `public`、`unique`、`private` 三种模式。
|
||||
- 私有码支持输入内部 `userId` 和公开百梦号,提交给后端统一解析。
|
||||
7. 邀请码管理页:
|
||||
- 调用 `POST /admin/api/profile/invite-codes` 创建/更新注册邀请码。
|
||||
- 支持输入 JSON 对象 metadata,提交前做基础 JSON 对象校验,最终校验以服务端为准。
|
||||
|
||||
### 3.2 不包含
|
||||
|
||||
1. 不新建后台专用后端服务、BFF、Express 服务或 PostgreSQL 数据面。
|
||||
2. 不让管理端直接连接 SpacetimeDB TypeScript SDK。
|
||||
3. 不新增 SpacetimeDB 表结构。
|
||||
4. 不实现完整用户管理、作品审核、资产审核、充值订单后台。
|
||||
5. 不实现多角色权限体系、管理员 refresh session、多端会话管理。
|
||||
6. 不保留 Rust `api-server` 的 `GET /admin` 同源内嵌页面作为正式后台入口;部署态 `/admin/` 只允许由独立后台前端静态产物承接。
|
||||
|
||||
## 4. 页面与交互要求
|
||||
|
||||
### 4.1 登录页
|
||||
|
||||
登录页只保留必要输入和状态反馈:
|
||||
|
||||
1. 用户名输入框。
|
||||
2. 密码输入框。
|
||||
3. 登录按钮。
|
||||
4. 登录失败状态。
|
||||
5. 后台未启用状态。
|
||||
|
||||
后台未启用时,前端根据 `POST /admin/api/login` 的 `503` 响应展示不可登录状态,不额外引导用户在页面配置环境变量。
|
||||
|
||||
### 4.2 总览页
|
||||
|
||||
总览页必须能快速扫读:
|
||||
|
||||
1. 服务状态:监听地址、端口、JWT issuer。
|
||||
2. SpacetimeDB 配置:server URL、database。
|
||||
3. 数据库元信息:database identity、owner identity、host type。
|
||||
4. 表清单与表统计:展示成功计数和失败原因。
|
||||
|
||||
总览页不展示任意 SQL 输入框。
|
||||
|
||||
### 4.3 API 调试页
|
||||
|
||||
API 调试页是受控接口调试台,不是通用代理工具:
|
||||
|
||||
1. method 使用选择控件。
|
||||
2. path 只接受 `/xxx` 形式。
|
||||
3. headers 使用结构化键值编辑。
|
||||
4. body 使用文本框。
|
||||
5. 结果展示在固定结果面板,不在按钮下方临时插入内容。
|
||||
|
||||
### 4.4 兑换码管理页
|
||||
|
||||
兑换码管理页首版采用一个创建/更新表单和一个停用表单:
|
||||
|
||||
1. code:提交前可在前端 trim,但最终标准化以服务端为准。
|
||||
2. mode:`public`、`unique`、`private`。
|
||||
3. rewardPoints:必须为正整数,最终校验以服务端为准。
|
||||
4. maxUses:必须为正整数,最终校验以服务端为准。
|
||||
5. enabled:创建/更新时可切换。
|
||||
6. allowedUserIds:私有码允许的内部用户 ID 列表。
|
||||
7. allowedPublicUserCodes:私有码允许的公开百梦号列表。
|
||||
|
||||
提交成功后展示后端返回的兑换码记录;失败时展示后端错误消息。
|
||||
|
||||
### 4.5 邀请码管理页
|
||||
|
||||
邀请码管理页首版采用一个创建/更新表单和一个结果面板:
|
||||
|
||||
1. inviteCode:提交前可在前端 trim,最终标准化以服务端为准。
|
||||
2. metadata:必须是 JSON 对象;空值按 `{}` 提交。
|
||||
3. 提交成功后展示后端返回的 userId、inviteCode、createdAt、updatedAt 和 metadata。
|
||||
4. 失败时展示后端错误消息。
|
||||
|
||||
## 5. 数据与权限边界
|
||||
|
||||
1. 管理端所有请求必须经过 `/admin/api/*`。
|
||||
2. 管理端持有的管理员 token 只用于后台接口,不复用玩家登录 token。
|
||||
3. 普通玩家 token 访问管理接口应被后端拒绝。
|
||||
4. 管理端不持久化密码。
|
||||
5. token 首版可保存在 localStorage;退出登录时立即清除。
|
||||
6. SpacetimeDB 表、reducer、procedure、迁移和权限判断均不由管理端直接处理。
|
||||
|
||||
## 6. 验收标准
|
||||
|
||||
1. `apps/admin-web` 可以独立启动和构建。
|
||||
2. 登录页可完成管理员登录,错误和未启用状态展示清楚。
|
||||
3. 登录后刷新页面可通过 `GET /admin/api/me` 恢复会话。
|
||||
4. 总览页可展示 `GET /admin/api/overview` 的服务与数据库数据。
|
||||
5. API 调试页可通过后端调试接口访问 `/healthz`。
|
||||
6. 兑换码管理页可创建/更新、停用兑换码,并展示返回记录。
|
||||
7. 邀请码管理页可创建/更新注册邀请码,并展示返回记录。
|
||||
8. 直连 Rust `api-server` 时 `GET /admin` 保持 404,不恢复旧内嵌页面;通过发布包 Web 网关访问 `/admin/` 时返回独立后台前端。
|
||||
9. `npm run check:encoding` 通过。
|
||||
|
||||
## 7. 首版任务拆解
|
||||
|
||||
首版编码按以下模块收口,避免独立后台工程继续扩散成未定义功能:
|
||||
|
||||
1. 工程骨架:创建 `apps/admin-web`,补齐 Vite、TypeScript、React 入口和独立构建脚本。
|
||||
2. API client:只封装 `/admin/api/*`,统一处理 Bearer token、统一 envelope 和后端错误消息。
|
||||
3. 登录与会话:实现登录、启动恢复、`401` 清理、退出登录四个状态流。
|
||||
4. 页面 Shell:实现桌面侧栏/顶部栏与移动端紧凑导航,不在未登录状态渲染后台导航。
|
||||
5. 总览页:展示 `service`、`database`、`tableStats`、`fetchErrors`,部分失败不阻断整页。
|
||||
6. API 调试页:实现 method、path、headers、body 输入和独立结果面板。
|
||||
7. 兑换码页:实现创建/更新、停用、三种 mode 切换和私有码用户列表输入。
|
||||
8. 邀请码页:实现注册邀请码创建/更新、metadata JSON 对象输入和最近记录展示。
|
||||
9. 验证:完成后台工程 typecheck/build、根工程编码检查,以及 `/admin` 仍为 404 的后端验证。
|
||||
|
||||
## 8. 交互修正记录
|
||||
|
||||
### 8.1 兑换码记录页签保持
|
||||
|
||||
兑换码管理页的“记录”面板展示最近一次创建、更新或停用接口返回的兑换码记录。该记录在管理端会话内切换“总览”“API 调试”“兑换码”页签时必须保留,避免运营人员切页核对信息后丢失刚返回的结果。退出登录、登录新会话或刷新浏览器页面时可以清空该前端会话态;持久化查询能力后续由新的后端查询接口承接,不在首版用前端伪造历史列表。
|
||||
+12
-12
@@ -31,7 +31,7 @@
|
||||
|
||||
大鱼吃小鱼玩法是一个 `Agent-First` 的轻量实时成长玩法创作链:
|
||||
|
||||
**创作者先与 Agent 共创“进化母题、等级阶梯、生态风格与场地气质”,系统再自动编译出一个竖屏全屏、摇杆移动、吞噬收编、三合一进化、持续刷怪、升到最高级即通关的可运行玩法作品。**
|
||||
**百梦主先与 Agent 共创“进化母题、等级阶梯、生态风格与场地气质”,系统再自动编译出一个竖屏全屏、摇杆移动、吞噬收编、三合一进化、持续刷怪、升到最高级即通关的可运行玩法作品。**
|
||||
|
||||
---
|
||||
|
||||
@@ -115,26 +115,26 @@
|
||||
|
||||
`Agent-First 大鱼吃小鱼玩法创作工具`
|
||||
|
||||
玩法运行态对外展示名可由创作者自定义,不强绑平台内部域名。
|
||||
玩法运行态对外展示名可由百梦主自定义,不强绑平台内部域名。
|
||||
|
||||
## 5.2 目标用户
|
||||
|
||||
目标用户主要是 3 类:
|
||||
|
||||
1. 轻创作者
|
||||
1. 轻百梦主
|
||||
- 想快速做一个可玩的成长吞噬小游戏,但不懂完整关卡编辑器
|
||||
|
||||
2. 视觉驱动型创作者
|
||||
2. 视觉驱动型百梦主
|
||||
- 更关心“每级长什么样、动作怎么样、背景氛围如何”
|
||||
|
||||
3. 玩法原型创作者
|
||||
3. 玩法原型百梦主
|
||||
- 想快速验证一套吞噬成长节奏、等级曲线和场地压迫感
|
||||
|
||||
## 5.3 成功标准
|
||||
|
||||
本期上线后,至少要满足下面这些结果:
|
||||
|
||||
1. 创作者可在 `5~12` 分钟内通过 Agent 聊天形成一版可用锚点草稿。
|
||||
1. 百梦主可在 `5~12` 分钟内通过 Agent 聊天形成一版可用锚点草稿。
|
||||
2. 系统默认能编译出 `8` 级实体阶梯的初版玩法草稿。
|
||||
3. 每一级实体都能在结果页单独生成和重生成主图。
|
||||
4. 每一级实体都能在结果页单独生成和重生成动作。
|
||||
@@ -179,9 +179,9 @@
|
||||
|
||||
Agent 在这一玩法里不负责实时玩法裁决,它只负责 3 件事:
|
||||
|
||||
1. 帮创作者明确高杠杆锚点
|
||||
2. 帮创作者把模糊灵感总结成可编译结构
|
||||
3. 帮创作者收束出第一版等级阶梯与视觉方向
|
||||
1. 帮百梦主明确高杠杆锚点
|
||||
2. 帮百梦主把模糊灵感总结成可编译结构
|
||||
3. 帮百梦主收束出第一版等级阶梯与视觉方向
|
||||
|
||||
## 7.2 前台交互原则
|
||||
|
||||
@@ -222,7 +222,7 @@ Agent 在这一玩法里不负责实时玩法裁决,它只负责 3 件事:
|
||||
3. `成长阶梯`
|
||||
- 这一玩法一共大致有几级,以及每一级如何逐步升级、变大、变强、变异
|
||||
- 最高级终局形态也并入这一锚点统一确定
|
||||
- 若创作者没有明确总层数,本期默认按 `8` 级编译,可配置范围固定为 `6~12` 级
|
||||
- 若百梦主没有明确总层数,本期默认按 `8` 级编译,可配置范围固定为 `6~12` 级
|
||||
|
||||
4. `风险节奏`
|
||||
- 玩家周围应该更偏压迫、平衡还是偏爽快
|
||||
@@ -235,7 +235,7 @@ Agent 在这一玩法里不负责实时玩法裁决,它只负责 3 件事:
|
||||
2. `等级总层数` 并入 `成长阶梯`
|
||||
3. `升级轮廓` 并入 `成长阶梯`
|
||||
4. `终局形态` 并入 `成长阶梯`
|
||||
5. `开局成长方式` 改为系统固定规则,不再作为创作者锚点
|
||||
5. `开局成长方式` 改为系统固定规则,不再作为百梦主锚点
|
||||
|
||||
后续 Agent 追问时,不再把这些内容拆成独立必答题。
|
||||
|
||||
@@ -302,7 +302,7 @@ Agent 在这一玩法里不负责实时玩法裁决,它只负责 3 件事:
|
||||
|
||||
## 9.1 默认草稿规模
|
||||
|
||||
当创作者没有特别指定时,第一版玩法草稿必须默认编译为:
|
||||
当百梦主没有特别指定时,第一版玩法草稿必须默认编译为:
|
||||
|
||||
1. `8` 级实体阶梯
|
||||
2. `1` 张活动区域背景图
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user