1
This commit is contained in:
@@ -16,6 +16,14 @@
|
||||
|
||||
---
|
||||
|
||||
## 2026-05-14 抓大鹅物品素材 sheet 改用 APIMart nanobanana
|
||||
|
||||
- 背景:抓大鹅 2D 五视角物品素材仍沿用 5x5 sheet、绿幕去背、切图、OSS 转存和 `generatedItemAssets` 持久化,但用户要求物品素材图片生成步骤改用 APIMart 已接好的 nanobanana / Gemini 图片模型。
|
||||
- 决策:抓大鹅物品素材 sheet 生图固定走 APIMart `POST {APIMART_BASE_URL}/images/generations`,模型为 `gemini-3.1-flash-image-preview`,`size = 1:1`,`resolution = 1K`,`official_fallback = true`;响应优先读图片 URL 或 base64,缺图片时按 `task_id` 轮询 `/tasks/{task_id}`。封面、9:16 纯背景图、1:1 容器 UI 图、音频、切图、OSS、扣费和运行态消费链路保持不变。
|
||||
- 影响范围:`server-rs/crates/api-server/src/match3d.rs`、`server-rs/crates/api-server/src/config.rs`、`deploy/env/api-server.env.example`、抓大鹅素材生成技术文档。
|
||||
- 验证方式:执行 `cargo test -p api-server match3d_material_sheet --manifest-path server-rs\Cargo.toml`、`cargo test -p api-server from_env_reads_non_public_models_and_urls --manifest-path server-rs\Cargo.toml`、`cargo check -p api-server --manifest-path server-rs\Cargo.toml`、`npm run check:encoding`。
|
||||
- 关联文档:`docs/technical/MATCH3D_DRAFT_ASSET_GENERATION_PIPELINE_2026-05-10.md`。
|
||||
|
||||
## 2026-05-13 认证运行期同步直接导入正式认证表
|
||||
|
||||
- 背景:`auth_store_snapshot` 是 Stage 1 整包快照过渡表,主键固定 `default`,会让所有用户状态集中在一条 `snapshot_json` 中;Stage 2/3 已有 `user_account/auth_identity/refresh_session` 正式认证表,继续刷新 `default` 容易让运行时真相和表拆分目标混在一起。
|
||||
@@ -27,7 +35,7 @@
|
||||
## 2026-05-13 微信小程序支付以后端通知为唯一入账事实
|
||||
|
||||
- 背景:“我的”账户充值需要接入微信小程序支付,同时保留本地 / H5 mock 支付联调能力。
|
||||
- 决策:`paymentChannel = "mock"` 继续创建即 paid 订单并立即入账;`paymentChannel = "wechat_mp"` 先在 `profile_recharge_order` 写入 `pending` 订单,再由 `api-server` 调微信支付 JSAPI 下单并返回小程序 `wx.requestPayment` 参数。小程序或 H5 的支付成功回调只触发刷新,不直接发放光点或会员;最终入账只由 `/api/profile/recharge/wechat/notify` 验签、解密并确认 `trade_state = SUCCESS` 后完成。`provider_transaction_id` 保存微信支付平台交易号,用于对账、查单、退款和客服排障。
|
||||
- 决策:`paymentChannel = "mock"` 继续创建即 paid 订单并立即入账;`paymentChannel = "wechat_mp"` 先在 `profile_recharge_order` 写入 `pending` 订单,再由 `api-server` 调微信支付 JSAPI 下单并返回小程序 `wx.requestPayment` 参数。小程序或 H5 的支付成功回调只触发刷新,不直接发放泥点或会员;最终入账只由 `/api/profile/recharge/wechat/notify` 验签、解密并确认 `trade_state = SUCCESS` 后完成。`provider_transaction_id` 保存微信支付平台交易号,用于对账、查单、退款和客服排障。
|
||||
- 影响范围:`profile_recharge_order` 表、SpacetimeDB 充值 procedure、`api-server` 微信支付客户端、小程序 native 支付页、H5 充值弹窗与共享 contract。
|
||||
- 验证方式:执行 `npm run typecheck`、`npm run test -- src/components/rpg-entry/RpgEntryHomeView.recharge.test.tsx`、`cargo test -p module-runtime recharge --manifest-path server-rs/Cargo.toml`、`cargo test -p api-server wechat_pay --manifest-path server-rs/Cargo.toml`,后端联调仍用 `npm run api-server` 和 `/healthz`。
|
||||
- 关联文档:`docs/technical/MY_TAB_ACCOUNT_RECHARGE_IMPLEMENTATION_2026-04-25.md`、`docs/technical/SPACETIMEDB_TABLE_CATALOG.md`。
|
||||
@@ -59,7 +67,7 @@
|
||||
## 2026-05-12 拼图与抓大鹅草稿背景音乐按纯音乐自动生成
|
||||
|
||||
- 背景:拼图和抓大鹅需要在草稿生成阶段直接产出可试听、可重生成、可进入运行态循环播放的背景音乐。
|
||||
- 决策:复用通用 VectorEngine Suno 创作音频链路,不新增 SpacetimeDB 表;拼图音乐保存到首关 `PuzzleDraftLevel.backgroundMusic`,运行态通过 `PuzzleRuntimeLevelSnapshot.backgroundMusic` 下发;抓大鹅音乐保存到首个 `generatedItemAssets[].backgroundMusic`。两者草稿生成都使用 `title` 驱动、`prompt = ""`、`make_instrumental = true`,失败只降级记录 warning,结果页允许重新生成。
|
||||
- 决策:复用通用 VectorEngine Suno 创作音频链路,不新增 SpacetimeDB 表;拼图音乐保存到首关 `PuzzleDraftLevel.backgroundMusic`,运行态通过 `PuzzleRuntimeLevelSnapshot.backgroundMusic` 下发;抓大鹅音乐保存到首个 `generatedItemAssets[].backgroundMusic`。两者草稿生成都使用 `title` 驱动、`prompt = ""`、`make_instrumental = true`;自动草稿阶段必须拿到可播放 `audioSrc` 才能返回成功,失败时停留在生成页并允许重试同一 session/profile。结果页内的手动重新生成继续作为已有草稿的补救入口。
|
||||
- 影响范围:`api-server` 音频生成、拼图草稿编译、抓大鹅草稿编译、Puzzle/Match3D 结果页和运行态音频播放。
|
||||
- 验证方式:检查草稿 response / work detail 中的 `backgroundMusic.audioSrc`,运行态开局后隐藏 audio 循环播放;执行音频相关后端 check、前端 typecheck 和编码检查。
|
||||
- 关联文档:`docs/technical/PUZZLE_MATCH3D_RESULT_AUDIO_TAB_2026-05-11.md`、`docs/technical/MATCH3D_DRAFT_ASSET_GENERATION_PIPELINE_2026-05-10.md`。
|
||||
@@ -67,7 +75,7 @@
|
||||
## 2026-05-12 拼图 UI 背景图复用 levels_json 持久化
|
||||
|
||||
- 背景:拼图草稿结果页需要像抓大鹅一样支持 UI 背景生成,但首版只需要作品级/首关背景,不应为图片生成结果新增 SpacetimeDB 表结构。
|
||||
- 决策:拼图 UI 背景字段存入首关 `levels_json`,字段为 `uiBackgroundPrompt`、`uiBackgroundImageSrc`、`uiBackgroundImageObjectKey`;`compile_puzzle_draft` 草稿编译阶段在首图和背景音乐后自动生成首关 UI 背景,失败只记录 warning 并允许结果页重试;结果页新增 `UI` Tab,可编辑提示词并触发 `generate_puzzle_ui_background`。`api-server` 读取 `public/ui-previews/puzzle-image-compact-ui-2026-05-08.png` 作为非拼图 UI 参考图,调用 VectorEngine `gpt-image-2-all` 生成 9:16 背景并要求中央正方形拼图区与外部 UI 背景边界清晰。SpacetimeDB 只保存结果,不做外部 I/O。
|
||||
- 决策:拼图 UI 背景字段存入首关 `levels_json`,字段为 `uiBackgroundPrompt`、`uiBackgroundImageSrc`、`uiBackgroundImageObjectKey`;`compile_puzzle_draft` 草稿编译阶段在首图完成后自动生成首关 UI 背景,自动草稿阶段必须拿到 `uiBackgroundImageSrc` 或 `uiBackgroundImageObjectKey` 才能返回成功;结果页新增 `UI` Tab,可编辑提示词并触发 `generate_puzzle_ui_background`,手动生成失败只展示在当前面板。`api-server` 读取 `public/ui-previews/puzzle-image-compact-ui-2026-05-08.png` 作为非拼图 UI 参考图,调用 VectorEngine `gpt-image-2-all` 生成 9:16 背景并要求中央正方形拼图区与外部 UI 背景边界清晰。SpacetimeDB 只保存结果,不做外部 I/O。
|
||||
- 影响范围:拼图结果页、拼图运行态背景渲染、拼图 agent action、`module-puzzle` / `spacetime-module` / `spacetime-client` 的拼图关卡 JSON 映射、拼图流程技术文档。
|
||||
- 验证方式:执行 `npm run test -- src/components/puzzle-result/PuzzleResultView.test.tsx`、`cargo test -p api-server puzzle_ui_background --manifest-path server-rs/Cargo.toml`、`cargo check -p api-server --manifest-path server-rs/Cargo.toml`、`npm run typecheck`、`npm run check:encoding`。
|
||||
- 关联文档:`docs/technical/PUZZLE_FORM_CREATION_FLOW_2026-04-29.md`。
|
||||
@@ -210,10 +218,10 @@
|
||||
- 验证方式:未登录首次访问应展示新手引导;生成后只进入 1 关本地拼图;通关后登录保存应在当前用户拼图作品架出现草稿作品;不应产生 SpacetimeDB schema 变更。
|
||||
- 关联文档:`docs/prd/FIRST_LAUNCH_PUZZLE_ONBOARDING_PRD_2026-05-05.md`。
|
||||
|
||||
## 2026-05-05 text-game 作为百梦幕间文字游戏模板接入
|
||||
## 2026-05-05 text-game 作为陶泥儿幕间文字游戏模板接入
|
||||
|
||||
- 背景:团队希望参考 MOKU / 幕间类 AI 文游,设计可在百梦内落地的 AI 文字游戏模板,但不能把外部平台社区、支付、榜单、论坛、账号或私有存档迁入 Genarrative。
|
||||
- 决策:新增 `text-game` 作为百梦 AI 原生文字游戏模板口径,展示名可用“幕间”或“幕间文字”;它与 `visual-novel` 分离,重点是 AI GM、自由行动、状态后果、长期记忆、章节目标和轻量剧本模拟器;入口、作品、发布、资产、钱包、埋点、存档和广场全部复用百梦平台接口;禁止新增 replay、外部社区、外部支付、外部榜单和私有存档系统。
|
||||
- 背景:团队希望参考 MOKU / 幕间类 AI 文游,设计可在陶泥儿内落地的 AI 文字游戏模板,但不能把外部平台社区、支付、榜单、论坛、账号或私有存档迁入 Genarrative。
|
||||
- 决策:新增 `text-game` 作为陶泥儿 AI 原生文字游戏模板口径,展示名可用“幕间”或“幕间文字”;它与 `visual-novel` 分离,重点是 AI GM、自由行动、状态后果、长期记忆、章节目标和轻量剧本模拟器;入口、作品、发布、资产、钱包、埋点、存档和广场全部复用陶泥儿平台接口;禁止新增 replay、外部社区、外部支付、外部榜单和私有存档系统。
|
||||
- 影响范围:后续 `text-game` shared contracts、`module-text-game`、SpacetimeDB 表、`api-server` 路由、前端入口 / workspace / result / runtime、平台作品架和发现聚合。
|
||||
- 验证方式:后续落地时确认路由使用 `/api/creation/text-game/*` 与 `/api/runtime/text-game/*`;确认正式业务真相在 Rust / SpacetimeDB 后端;确认没有 `replay` 能力和外部平台功能误入;确认 `text-game` 不复用 `visual-novel` step 契约作为运行态真相。
|
||||
- 关联文档:`docs/prd/AI_NATIVE_TEXT_GAME_TEMPLATE_MOKU_REFERENCE_PRD_2026-05-05.md`。
|
||||
|
||||
@@ -67,6 +67,8 @@
|
||||
- 验证:`npm run test -- src/services/apiClient.test.ts` 覆盖 `details.reason`;`cargo test -p api-server state --manifest-path server-rs/Cargo.toml` 覆盖半配置 OSS 不阻断启动;`npm run api-server` 后按实际 `GENARRATIVE_API_PORT` 请求 `/healthz`,不要默认打 `3100`。
|
||||
- 关联:`packages/shared/src/http.ts`、`server-rs/crates/api-server/src/state.rs`、`docs/technical/API_SERVER_EXTERNAL_SERVICE_ENV_CONFIG_2026-05-07.md`、`docs/technical/AUTH_SNAPSHOT_AND_MATCH3D_LOCAL_DEV_FIX_2026-05-01.md`。
|
||||
|
||||
2026-05-14 补充:抓大鹅“物品素材 sheet”已改用 APIMart `gemini-3.1-flash-image-preview`,真实生成还需要 `APIMART_BASE_URL`、`APIMART_API_KEY` 和 `APIMART_IMAGE_REQUEST_TIMEOUT_MS`;封面、背景图和容器 UI 仍继续使用 VectorEngine。排查时先按失败阶段区分缺 APIMart、VectorEngine 还是 OSS,不能把物品素材缺 APIMart 误判成 VectorEngine 缺配置。
|
||||
|
||||
## `.hermes` 只放共享内容,不放个人 Hermes 配置
|
||||
|
||||
- 现象:团队成员误把个人 Hermes 配置、会话或密钥复制进仓库。
|
||||
@@ -164,6 +166,14 @@
|
||||
- 验证:`npm run test -- src/components/puzzle-result/PuzzleResultView.test.tsx`,以及自动试玩入口测试 `npm run test -- src/components/rpg-entry/RpgEntryFlowShell.agent.interaction.test.tsx -t "puzzle draft generation auto starts trial"`。
|
||||
- 关联:`src/components/puzzle-result/PuzzleResultView.tsx`、`src/components/rpg-entry/RpgEntryFlowShell.agent.interaction.test.tsx`、`docs/technical/PUZZLE_MATCH3D_RESULT_AUDIO_TAB_2026-05-11.md`。
|
||||
|
||||
## 自动草稿成功但缺音乐或 UI 先查后端吞错
|
||||
|
||||
- 现象:拼图或抓大鹅生成页提示完成,但草稿页仍显示“暂无音乐”,拼图 UI 仍是默认预览,试玩局内也没有生成音乐或 UI 背景。
|
||||
- 原因:自动草稿阶段如果把 VectorEngine / Suno / OSS / 资产绑定错误记录为 warning 后继续返回成功,前端只能拿到缺关键资产的成功 draft,随后保存和试玩都会消费这份空资产状态。
|
||||
- 处理:自动草稿必须把必需生成资产当作后端完成条件:拼图首关需同时具备 `levels[0].backgroundMusic.audioSrc` 和 `levels[0].uiBackgroundImageSrc/uiBackgroundImageObjectKey`;抓大鹅需在 `generatedItemAssets[]` 中具备非空 `backgroundMusic.audioSrc`。缺失或上游失败时返回错误并停留在生成页,结果页手动重新生成只作为已有草稿补救入口。
|
||||
- 验证:`cargo test -p api-server puzzle_initial_draft_assets_must_include_music_and_ui_background match3d_background_music_ready_requires_audio_src match3d_background_music_title_is_required_for_auto_draft --manifest-path server-rs\Cargo.toml`,并重启 `npm run api-server` 后检查 `/healthz`。
|
||||
- 关联:`server-rs/crates/api-server/src/puzzle.rs`、`server-rs/crates/api-server/src/match3d.rs`、`docs/technical/PUZZLE_FORM_CREATION_FLOW_2026-04-29.md`、`docs/technical/MATCH3D_DRAFT_ASSET_GENERATION_PIPELINE_2026-05-10.md`。
|
||||
|
||||
## 拼图草稿生成 180 秒后 502/504 先查 VectorEngine 超时与前端重试
|
||||
|
||||
- 现象:点击“生成拼图游戏草稿”后,`POST /api/runtime/puzzle/agent/sessions/{sessionId}/actions` 等待约 180 秒返回 `502 Bad Gateway` 或 `504 Gateway Timeout`;钱包流水里同一 session 可能出现连续两组 `puzzle_initial_image` 扣费后退款。
|
||||
@@ -528,9 +538,9 @@
|
||||
## 拼图发布 409 不一定是接口故障
|
||||
|
||||
- 现象:拼图结果页点击发布后,控制台出现 `POST /api/runtime/puzzle/agent/sessions/{sessionId}/actions 409 (Conflict)`,用户只看到发布失败。
|
||||
- 原因:`publish_puzzle_work` 是资产操作发布入口,发布前会预扣 `1` 枚光点;余额不足时后端按业务冲突返回 `409 CONFLICT`,`details.message` 为 `光点余额不足`。
|
||||
- 原因:`publish_puzzle_work` 是资产操作发布入口,发布前会预扣 `1` 枚泥点;余额不足时后端按业务冲突返回 `409 CONFLICT`,`details.message` 为 `泥点余额不足`。
|
||||
- 处理:前端发布弹窗在用户点击发布后必须保留并展示后端业务错误,不能只把错误写到弹窗背后的页面 banner。
|
||||
- 验证:`PuzzleResultView` 单测覆盖发布弹窗内展示 `光点余额不足`。
|
||||
- 验证:`PuzzleResultView` 单测覆盖发布弹窗内展示 `泥点余额不足`。
|
||||
- 关联:`src/components/puzzle-result/PuzzleResultView.tsx`、`docs/technical/PUZZLE_RESULT_AUTOSAVE_AND_TAG_GATE_FIX_2026-04-28.md`、`docs/technical/ASSET_GENERATION_POINTS_CONSUMPTION_2026-04-27.md`。
|
||||
|
||||
## WebGL 画布在高 DPR 移动端放大溢出
|
||||
|
||||
@@ -104,10 +104,10 @@ Rust 加密摘要依赖口径:新代码不再引入 `sha1`;OSS V4 签名、
|
||||
|
||||
以 `docs/technical/PRODUCT_NAMING_BAIMENG_RENAME_2026-05-01.md` 为准:
|
||||
|
||||
- 产品展示名:百梦
|
||||
- 消费单位:光点
|
||||
- 公开账号标识:百梦号
|
||||
- 创作侧称谓:百梦主
|
||||
- 产品展示名:陶泥儿
|
||||
- 消费单位:泥点
|
||||
- 公开账号标识:陶泥号
|
||||
- 创作侧称谓:陶泥儿主
|
||||
|
||||
个人任务与埋点系统首版边界:
|
||||
|
||||
@@ -117,7 +117,7 @@ Rust 加密摘要依赖口径:新代码不再引入 `sha1`;OSS V4 签名、
|
||||
- 任务进度写入 `profile_task_progress`
|
||||
- 领奖记录写入 `profile_task_reward_claim`
|
||||
- 钱包流水写入 `profile_wallet_ledger`
|
||||
- “星光”奖励复用现有“光点”钱包,不新增第二种货币
|
||||
- “星光”奖励复用现有“泥点”钱包,不新增第二种货币
|
||||
- 个人任务 scope 首版仅支持 `user`
|
||||
|
||||
## 关键文档入口
|
||||
|
||||
@@ -1,23 +1,23 @@
|
||||
---
|
||||
name: genarrative-admin-backoffice
|
||||
short_description: 在 Genarrative/百梦后台新增或修改管理页、后台只读/写接口、导出能力时使用。
|
||||
description: 在 Genarrative/百梦后台新增或修改管理页、后台 BFF 接口、shared-contracts/admin DTO、admin-web 路由导航、Excel/表格导出与验证发布时使用。
|
||||
short_description: 在 Genarrative/陶泥儿后台新增或修改管理页、后台只读/写接口、导出能力时使用。
|
||||
description: 在 Genarrative/陶泥儿后台新增或修改管理页、后台 BFF 接口、shared-contracts/admin DTO、admin-web 路由导航、Excel/表格导出与验证发布时使用。
|
||||
version: 1.0.0
|
||||
author: Hermes Agent
|
||||
license: MIT
|
||||
metadata:
|
||||
hermes:
|
||||
tags: [Genarrative, 百梦后台, admin-web, 后台接口, Excel导出, Rust, Axum, SpacetimeDB]
|
||||
tags: [Genarrative, 陶泥儿后台, admin-web, 后台接口, Excel导出, Rust, Axum, SpacetimeDB]
|
||||
related_skills: [genarrative-play-type-integration]
|
||||
---
|
||||
|
||||
# Genarrative / 百梦后台管理功能接入流程
|
||||
# Genarrative / 陶泥儿后台管理功能接入流程
|
||||
|
||||
用于在 Genarrative 项目中新增或修改百梦后台管理端能力,包括后台页面、后台 API、管理端 DTO、导航路由、表格明细、导出、鉴权与验证。
|
||||
用于在 Genarrative 项目中新增或修改陶泥儿后台管理端能力,包括后台页面、后台 API、管理端 DTO、导航路由、表格明细、导出、鉴权与验证。
|
||||
|
||||
## 适用场景
|
||||
|
||||
- 新增百梦后台页面或导航项,例如“埋点数据”“任务配置”“邀请码”。
|
||||
- 新增陶泥儿后台页面或导航项,例如“埋点数据”“任务配置”“邀请码”。
|
||||
- 新增 `/admin/api/*` 接口。
|
||||
- 修改 `apps/admin-web` 的后台页面、API client、路由、Shell 导航。
|
||||
- 在后台展示 SpacetimeDB 表明细或统计数据。
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
|
||||
## 背景
|
||||
|
||||
本次在 Genarrative/百梦后台新增“埋点数据”页:
|
||||
本次在 Genarrative/陶泥儿后台新增“埋点数据”页:
|
||||
|
||||
- 后端新增 `GET /admin/api/tracking/events`。
|
||||
- shared-contracts 新增 admin tracking query/list/entry DTO。
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>百梦后台</title>
|
||||
<title>陶泥儿后台</title>
|
||||
</head>
|
||||
<body>
|
||||
<div id="root"></div>
|
||||
|
||||
@@ -50,7 +50,7 @@ export function AdminShell({
|
||||
<ShieldCheck size={20} aria-hidden="true" />
|
||||
</div>
|
||||
<div>
|
||||
<strong>百梦后台</strong>
|
||||
<strong>陶泥儿后台</strong>
|
||||
<span>Admin</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -86,7 +86,7 @@ export const adminTrackingEventDefinitions: AdminTrackingEventDefinition[] = [
|
||||
key: 'wallet_ledger_view',
|
||||
title: '钱包流水查看',
|
||||
scopeKind: 'user',
|
||||
remark: '读取光点钱包流水成功后记录。',
|
||||
remark: '读取泥点钱包流水成功后记录。',
|
||||
},
|
||||
{
|
||||
key: 'recharge_center_view',
|
||||
|
||||
@@ -742,9 +742,9 @@ const databaseTableColumnLabelMap: Record<string, string> = {
|
||||
theme_tags_json: '主题标签JSON',
|
||||
cover_image_src: '封面图',
|
||||
cover_asset_id: '封面资产ID',
|
||||
public_user_code: '百梦号',
|
||||
public_user_code: '陶泥号',
|
||||
public_work_code: '公开作品号',
|
||||
author_public_user_code: '作者百梦号',
|
||||
author_public_user_code: '作者陶泥号',
|
||||
author_display_name: '作者昵称',
|
||||
display_name: '显示名',
|
||||
avatar_url: '头像地址',
|
||||
@@ -874,9 +874,9 @@ const databaseTableColumnDescriptionMap: Record<string, string> = {
|
||||
theme_tags_json: '主题标签列表 JSON',
|
||||
cover_image_src: '封面图片地址或平台资产引用',
|
||||
cover_asset_id: '封面对应的平台资产 ID',
|
||||
public_user_code: '用户对外展示的百梦号',
|
||||
public_user_code: '用户对外展示的陶泥号',
|
||||
public_work_code: '作品公开后对外展示的作品号',
|
||||
author_public_user_code: '作者对外展示的百梦号',
|
||||
author_public_user_code: '作者对外展示的陶泥号',
|
||||
author_display_name: '作者展示昵称',
|
||||
display_name: '用户展示名称',
|
||||
avatar_url: '用户头像地址',
|
||||
|
||||
@@ -39,7 +39,7 @@ export function AdminLoginPage({notice, onLogin}: AdminLoginPageProps) {
|
||||
<ShieldCheck size={26} aria-hidden="true" />
|
||||
</div>
|
||||
<div>
|
||||
<h1>百梦后台</h1>
|
||||
<h1>陶泥儿后台</h1>
|
||||
<span>Admin Console</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
@@ -253,7 +253,7 @@ export function AdminRedeemCodePage({
|
||||
/>
|
||||
</label>
|
||||
<label className="admin-field">
|
||||
<span>公开百梦号</span>
|
||||
<span>公开陶泥号</span>
|
||||
<textarea
|
||||
rows={6}
|
||||
value={allowedPublicUserCodes}
|
||||
|
||||
@@ -373,7 +373,7 @@ export function AdminTaskConfigPage({
|
||||
/>
|
||||
</label>
|
||||
<label className="admin-field">
|
||||
<span>奖励光点</span>
|
||||
<span>奖励泥点</span>
|
||||
<input
|
||||
min={1}
|
||||
step={1}
|
||||
|
||||
+1
-1
@@ -13,7 +13,7 @@
|
||||
重点补充:RPG 创作与运行时脚本职责地图见 [RPG_CREATION_AND_RUNTIME_SCRIPT_RESPONSIBILITY_MAP_2026-04-28.md](./reference/RPG_CREATION_AND_RUNTIME_SCRIPT_RESPONSIBILITY_MAP_2026-04-28.md)。
|
||||
- [埋点查询](./tracking/README.md):埋点原始事件与聚合投影的本地 SQL 查询。
|
||||
- [运营查询](./operations/README.md):任务、领奖、钱包对账等后台核查查询。
|
||||
- [PRD](./prd/README.md):产品需求与阶段计划;参考 MOKU / 幕间类 AI 文游的百梦 `text-game` 模板口径见 [AI_NATIVE_TEXT_GAME_TEMPLATE_MOKU_REFERENCE_PRD_2026-05-05.md](./prd/AI_NATIVE_TEXT_GAME_TEMPLATE_MOKU_REFERENCE_PRD_2026-05-05.md),视觉小说模板 TXT 玩法平台化接入口径见 [AI_NATIVE_VISUAL_NOVEL_TEMPLATE_PRD_2026-05-05.md](./prd/AI_NATIVE_VISUAL_NOVEL_TEMPLATE_PRD_2026-05-05.md),创意互动内容 Agent Phase 1 的 LangChain-Rust PoC、拼图闭环和并行任务拆分见 [CREATIVE_INTERACTIVE_AGENT_PHASE1_LANGCHAIN_RUST_PUZZLE_LOOP_PRD_2026-05-05.md](./prd/CREATIVE_INTERACTIVE_AGENT_PHASE1_LANGCHAIN_RUST_PUZZLE_LOOP_PRD_2026-05-05.md),幸存者类模板闭环见 [AI_NATIVE_SURVIVOR_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-05-05.md](./prd/AI_NATIVE_SURVIVOR_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-05-05.md),后台管理独立前端工程见 [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),方洞挑战创作、发布与试玩闭环见 [AI_NATIVE_SQUARE_HOLE_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-05-04.md](./prd/AI_NATIVE_SQUARE_HOLE_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-05-04.md)。
|
||||
- [PRD](./prd/README.md):产品需求与阶段计划;参考 MOKU / 幕间类 AI 文游的陶泥儿 `text-game` 模板口径见 [AI_NATIVE_TEXT_GAME_TEMPLATE_MOKU_REFERENCE_PRD_2026-05-05.md](./prd/AI_NATIVE_TEXT_GAME_TEMPLATE_MOKU_REFERENCE_PRD_2026-05-05.md),视觉小说模板 TXT 玩法平台化接入口径见 [AI_NATIVE_VISUAL_NOVEL_TEMPLATE_PRD_2026-05-05.md](./prd/AI_NATIVE_VISUAL_NOVEL_TEMPLATE_PRD_2026-05-05.md),创意互动内容 Agent Phase 1 的 LangChain-Rust PoC、拼图闭环和并行任务拆分见 [CREATIVE_INTERACTIVE_AGENT_PHASE1_LANGCHAIN_RUST_PUZZLE_LOOP_PRD_2026-05-05.md](./prd/CREATIVE_INTERACTIVE_AGENT_PHASE1_LANGCHAIN_RUST_PUZZLE_LOOP_PRD_2026-05-05.md),幸存者类模板闭环见 [AI_NATIVE_SURVIVOR_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-05-05.md](./prd/AI_NATIVE_SURVIVOR_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-05-05.md),后台管理独立前端工程见 [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),方洞挑战创作、发布与试玩闭环见 [AI_NATIVE_SQUARE_HOLE_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-05-04.md](./prd/AI_NATIVE_SQUARE_HOLE_CREATOR_AND_GAMEPLAY_SYSTEM_PRD_2026-05-04.md)。
|
||||
|
||||
生产部署切换到 systemd + Nginx + SpacetimeDB 自托管的总方案见 [PRODUCTION_DEPLOYMENT_PLAN_2026-05-02.md](./technical/PRODUCTION_DEPLOYMENT_PLAN_2026-05-02.md),该文档也是当前生产 Jenkinsfile 的唯一入口。SpacetimeDB 表结构变更、自动迁移边界和保留旧数据的分阶段迁移流程见 [SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md](./technical/SPACETIMEDB_SCHEMA_CHANGE_CONSTRAINTS.md);private 表迁移 JSON 导入导出、HTTP 413 分片导入和旧数据库迁移流水线经验见 [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)。
|
||||
|
||||
|
||||
@@ -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,15 +1,15 @@
|
||||
# 百梦线下展会易拉宝设计记录 2026-05-07
|
||||
# 陶泥儿线下展会易拉宝设计记录 2026-05-07
|
||||
|
||||
## 1. 目标
|
||||
|
||||
为百梦线下展会制作一张纵向易拉宝广告展板,用于在展位现场快速传达:
|
||||
为陶泥儿线下展会制作一张纵向易拉宝广告展板,用于在展位现场快速传达:
|
||||
|
||||
1. 产品名称:百梦。
|
||||
2. 产品愿景:百梦AI团队致力于打造AI互动内容UGC平台。
|
||||
1. 产品名称:陶泥儿。
|
||||
2. 产品愿景:陶泥儿AI团队致力于打造AI互动内容UGC平台。
|
||||
3. 产品slogan:不用代码,不用美术,10分钟把脑洞变成有趣的体验。
|
||||
4. 产品特点:低门槛创作、高完成度作品、玩过后可改造并发布。
|
||||
5. 关键技术:Harness Engineering、多Agent调度、AI创作工具、AI原生游戏框架。
|
||||
6. 产品心智:想玩但找不到、玩到不满意、平台外体验不满意时,都可以来百梦做成自己满意的。
|
||||
6. 产品心智:想玩但找不到、玩到不满意、平台外体验不满意时,都可以来陶泥儿做成自己满意的。
|
||||
|
||||
## 2. 视觉方向
|
||||
|
||||
@@ -27,7 +27,7 @@
|
||||
第一层:品牌识别
|
||||
|
||||
```text
|
||||
百梦
|
||||
陶泥儿
|
||||
10分钟做自己的互动内容
|
||||
```
|
||||
|
||||
@@ -57,10 +57,10 @@
|
||||
第四层:产品心智与关键技术
|
||||
|
||||
```text
|
||||
当用户找不到想玩的游戏 -> 来百梦做给自己玩
|
||||
当用户找不到想玩的游戏 -> 来陶泥儿做给自己玩
|
||||
当用户玩到了不好玩的游戏 -> 快速改成自己喜欢玩的
|
||||
当用户在平台外玩到了不满意的游戏 -> 来百梦做成自己满意的
|
||||
什么游戏最好玩? -> 来百梦玩自己做的游戏最好玩
|
||||
当用户在平台外玩到了不满意的游戏 -> 来陶泥儿做成自己满意的
|
||||
什么游戏最好玩? -> 来陶泥儿玩自己做的游戏最好玩
|
||||
```
|
||||
|
||||
关键技术压缩为:
|
||||
@@ -82,7 +82,7 @@ AI原生游戏框架:
|
||||
```text
|
||||
model: gpt-image-2
|
||||
size: 1536x3840
|
||||
reference image: 百梦气泡共创logo方向图
|
||||
reference image: 陶泥儿气泡共创logo方向图
|
||||
output: output/imagegen/baimeng-expo-rollup/baimeng-rollup-background-gpt-image-2.png
|
||||
```
|
||||
|
||||
@@ -119,17 +119,17 @@ output/imagegen/baimeng-expo-rollup/baimeng-rollup-final-cn-preview.png
|
||||
北京亓盒网络科技有限公司
|
||||
岗位名称:AI 原生游戏产品/内容实习生
|
||||
行业方向:AI 原生游戏 × UGC 内容创作 × 互动叙事
|
||||
产品:百梦 AI互动内容创作平台
|
||||
产品:陶泥儿 AI互动内容创作平台
|
||||
```
|
||||
|
||||
新版保留百梦气泡色彩、轻盈白底和创作流动感,但新增校园实验室、AI 游戏创作、作品卡、产品测试与内容设计氛围。版面结构调整为:
|
||||
新版保留陶泥儿气泡色彩、轻盈白底和创作流动感,但新增校园实验室、AI 游戏创作、作品卡、产品测试与内容设计氛围。版面结构调整为:
|
||||
|
||||
1. 顶部:公司名、岗位名、行业方向与招聘主标题。
|
||||
2. 中上:百梦产品主张与三枚产品能力标签。
|
||||
2. 中上:陶泥儿产品主张与三枚产品能力标签。
|
||||
3. 中部:按 `游玩 -> 改造 -> 创作` 顺序展示产品体验闭环。
|
||||
4. 中下:介绍“我们正在做的事「百梦」”。
|
||||
4. 中下:介绍“我们正在做的事「陶泥儿」”。
|
||||
5. 下部:实习生参与内容、加分项、团队背景和联系方式。
|
||||
6. 底部:预留两个方形二维码占位,收尾文案为 `百梦 | 让每个人都能做自己的游戏`。
|
||||
6. 底部:预留两个方形二维码占位,收尾文案为 `陶泥儿 | 让每个人都能做自己的游戏`。
|
||||
|
||||
新版使用当前仓库 `VectorEngine gpt-image-2-all` 路径生成底图:
|
||||
|
||||
@@ -137,7 +137,7 @@ output/imagegen/baimeng-expo-rollup/baimeng-rollup-final-cn-preview.png
|
||||
model: gpt-image-2-all
|
||||
size: 1536x3840
|
||||
reference image 1: 用户提供的上一版海报截图
|
||||
reference image 2: 百梦气泡共创logo方向图
|
||||
reference image 2: 陶泥儿气泡共创logo方向图
|
||||
output: output/imagegen/baimeng-recruitment-rollup/baimeng-recruitment-rollup-background-gpt-image-2-all.png
|
||||
```
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# 百梦 logo gpt-image-2 概念方案 2026-05-05
|
||||
# 陶泥儿 logo gpt-image-2 概念方案 2026-05-05
|
||||
|
||||
## 1. 产品气质提炼
|
||||
|
||||
当前产品对外名为“百梦”,核心不是单一 RPG 玩法,而是面向互动叙事、世界生成和运行时演出的 AI 原生创作平台。
|
||||
当前产品对外名为“陶泥儿”,核心不是单一 RPG 玩法,而是面向互动叙事、世界生成和运行时演出的 AI 原生创作平台。
|
||||
|
||||
本次 logo 概念围绕以下关键词设计:
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
|
||||
视觉方向:
|
||||
|
||||
- 用一个打开的门 / 星门作为主体,门内有多条细线向外延展,代表百梦主从一个灵感入口进入多个世界。
|
||||
- 用一个打开的门 / 星门作为主体,门内有多条细线向外延展,代表陶泥儿主从一个灵感入口进入多个世界。
|
||||
- 负形中弱化出“百”的结构,不强行写字,方便后续做 App icon、favicon 和小尺寸导航标。
|
||||
- 色彩以暖白、珊瑚粉、少量紫蓝和深墨色组成,贴近平台亮色主题,同时保留梦境和 AI 的科技感。
|
||||
|
||||
@@ -28,7 +28,7 @@
|
||||
|
||||
设计含义:
|
||||
|
||||
“梦门”代表创作入口,“星轨”代表剧情线程、角色关系和世界分支。它强调百梦是让创作者开启世界的工具,而不是只播放固定剧情的游戏。
|
||||
“梦门”代表创作入口,“星轨”代表剧情线程、角色关系和世界分支。它强调陶泥儿是让创作者开启世界的工具,而不是只播放固定剧情的游戏。
|
||||
|
||||
## 3. 方案 B:叙事图谱
|
||||
|
||||
@@ -36,7 +36,7 @@
|
||||
|
||||
- 用节点、弧线和轻微书页轮廓组成一个稳定的圆形标志。
|
||||
- 图谱整体形成近似“百”的秩序感,避免复杂到小尺寸失真。
|
||||
- 色彩以深墨、湖青、光点金和珊瑚色组合,体现规则边界与创作活力并存。
|
||||
- 色彩以深墨、湖青、泥点金和珊瑚色组合,体现规则边界与创作活力并存。
|
||||
|
||||
适合场景:
|
||||
|
||||
@@ -48,13 +48,13 @@
|
||||
|
||||
这个方向更强调“世界不是一段文本,而是一张可控的叙事图谱”。节点是角色、地点、物件和任务,弧线是关系、暗线与回响。
|
||||
|
||||
## 4. 方案 C:光点梦织
|
||||
## 4. 方案 C:泥点梦织
|
||||
|
||||
视觉方向:
|
||||
|
||||
- 多个光点汇聚成柔和的“B / 百”抽象符号,中心像一枚被点亮的种子。
|
||||
- 多个泥点汇聚成柔和的“B / 百”抽象符号,中心像一枚被点亮的种子。
|
||||
- 线条更轻,图形更偏平台化和消费级,不做重游戏徽章。
|
||||
- 色彩采用珊瑚粉、暖金、浅青和深色细线,表达“光点”消费单位与灵感生长。
|
||||
- 色彩采用珊瑚粉、暖金、浅青和深色细线,表达“泥点”消费单位与灵感生长。
|
||||
|
||||
适合场景:
|
||||
|
||||
@@ -64,7 +64,7 @@
|
||||
|
||||
设计含义:
|
||||
|
||||
每个光点都是一次生成、一次灵感、一次世界推进。多点汇聚成梦,呼应“百梦”里从许多小创意生长出完整作品的路径。
|
||||
每个泥点都是一次生成、一次灵感、一次世界推进。多点汇聚成梦,呼应“陶泥儿”里从许多小创意生长出完整作品的路径。
|
||||
|
||||
## 5. 方案 D:像素剧场
|
||||
|
||||
@@ -82,11 +82,11 @@
|
||||
|
||||
设计含义:
|
||||
|
||||
舞台代表演出,卷轴代表叙事,星形光标代表 AI 与玩家选择。它让百梦看起来仍然属于游戏和互动内容,而不是泛 AI 工具。
|
||||
舞台代表演出,卷轴代表叙事,星形光标代表 AI 与玩家选择。它让陶泥儿看起来仍然属于游戏和互动内容,而不是泛 AI 工具。
|
||||
|
||||
## 6. 生成说明
|
||||
|
||||
本次推荐先用 `gpt-image-2` 生成 4 张 `1024x1024` 方形草案。由于图片模型对中文文字的稳定性有限,首轮应优先验证“图形标识”而不是直接把“百梦”两个字烘焙进图片。最终产品落地时,建议使用真实前端字体或 SVG 字形承载“百梦”字标,把生成图作为图形标志参考。
|
||||
本次推荐先用 `gpt-image-2` 生成 4 张 `1024x1024` 方形草案。由于图片模型对中文文字的稳定性有限,首轮应优先验证“图形标识”而不是直接把“陶泥儿”两个字烘焙进图片。最终产品落地时,建议使用真实前端字体或 SVG 字形承载“陶泥儿”字标,把生成图作为图形标志参考。
|
||||
|
||||
## 7. 女性友好与全年龄潮流版补充
|
||||
|
||||
@@ -96,8 +96,8 @@
|
||||
|
||||
- 字形更圆润,减少尖锐笔锋、黑底压迫感和玄幻气质。
|
||||
- 色彩从黑白、金色、深墨切换到奶油白、莓果粉、薰衣草紫、薄荷青。
|
||||
- 允许轻量梦泡、云朵、柔软光点等符号,但不堆叠插画。
|
||||
- 保留“百梦”中文字标作为主识别,图标可作为 App icon 或社交头像补充。
|
||||
- 允许轻量梦泡、云朵、柔软泥点等符号,但不堆叠插画。
|
||||
- 保留“陶泥儿”中文字标作为主识别,图标可作为 App icon 或社交头像补充。
|
||||
|
||||
本轮生成 prompt:
|
||||
|
||||
|
||||
@@ -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 等级锚点
|
||||
|
||||
|
||||
@@ -31,8 +31,9 @@
|
||||
3. 用户每次进入创作页时,前端读取上一次进入该页面缓存的公开指标快照;当已发布作品卡片滑动进入视口后,数字从缓存值增长到本次接口返回的最新值。
|
||||
4. 若最新值高于缓存值,动画完成后在对应指标右下角展示红色向上箭头和本次上涨的具体数值,字号低于主数字,避免抢占主信息层级。
|
||||
5. 若没有缓存值、缓存值不低于最新值或作品仍是草稿,则直接显示最新值,不展示上涨标记。
|
||||
6. 每张作品卡片继续使用作品封面作为整卡背景,封面需要有透明度和渐变遮罩,确保标题、描述和指标在亮色与暗色主题下都清晰可读。
|
||||
6. 每张作品卡片继续使用作品封面作为整卡背景,封面保持主视觉可见;遮罩只用于保证标题、描述和指标可读,不能把封面洗成普通面板底色。
|
||||
7. 作品列表按 `updatedAt` 倒序排列;前端排序需要兼容 ISO 时间和 Rust 后端常用的 `seconds.microsZ` 时间文本。
|
||||
8. 若玩法摘要缺少 `coverImageSrc`,允许从同一作品的正式关卡图、背景图或素材图里取第一张可用图片作为卡片背景兜底。
|
||||
|
||||
## 移动端布局规则
|
||||
|
||||
|
||||
@@ -96,7 +96,7 @@
|
||||
- 同时开放短信与密码登录时,面板顶部展示两个居中的文字页签,当前页签使用深色字重和短下划线强调。
|
||||
- 只渲染当前页签对应的输入区;切换页签不弹出新面板,不展示二维码入口。
|
||||
- `短信登录` 页签包含手机号、验证码、获取验证码和主按钮。
|
||||
- `密码登录` 页签只包含手机号、密码、主按钮和忘记密码入口;不支持邮箱、用户名或百梦号。
|
||||
- `密码登录` 页签只包含手机号、密码、主按钮和忘记密码入口;不支持邮箱、用户名或陶泥号。
|
||||
- 密码登录只是手机号验证码登录的补充方式:只有已登录并设置过密码的手机号账号才能使用,不能在密码页签创建账号。
|
||||
- `密码登录` 主按钮固定为 `登录`,不得使用 `注册/登录`。
|
||||
- 未开放某个登录方式时不展示对应页签,避免用户进入不可用表单。
|
||||
|
||||
@@ -69,7 +69,7 @@
|
||||
- 入口、删除、分享、领取拼图激励等行为全部复用现有 `CustomWorldCreationHub` 的作品卡逻辑。
|
||||
- 一级底部 Tab 文案为“草稿”,内部仍可按草稿与已发布筛选。
|
||||
- 作品列表必须按最后修改时间倒序排列;排序使用后端 `updatedAt`,前端需要兼容 ISO 字符串和 `seconds.microsZ` 两种时间文本。
|
||||
- 每张作品卡以作品封面图铺满整卡背景,并叠加遮罩保证标题和描述可读;缺封面时才使用现有兜底底图。
|
||||
- 每张作品卡以作品封面图铺满整卡背景,并叠加遮罩保证标题和描述可读;遮罩不能把封面洗成普通面板底色。缺 `coverImageSrc` 但同一作品已有正式关卡图、背景图或素材图时,优先用这些真实作品图兜底,再使用现有兜底底图。
|
||||
- 草稿页卡片不展示“最后修改时间”“更新于”或原始 `updatedAt` 文本,时间只参与排序。
|
||||
|
||||
## 6. 我的页玩过列表
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user