去掉裁决包主路径,让无转述时可直出终稿、有转述时再改写镶壳。 Co-authored-by: Cursor <cursoragent@cursor.com>
51 lines
2.3 KiB
Markdown
51 lines
2.3 KiB
Markdown
# 主世界层 与 旁观维护:怎么配合
|
||
|
||
> 用白话说明「DM」和「副 LLM(旁观)」谁先谁后、谁干什么。
|
||
> 实现上当前管线是:`主世界层 →(可选角色视角)→ 转述 → 旁观维护`。
|
||
|
||
## 1. 先说清楚两个角色
|
||
|
||
| 称呼 | 槽 | 干什么 | 不干什么 |
|
||
|------|-----|--------|----------|
|
||
| **主世界层(DM)** | gm | 读设定与当前状态,推进场面,直接写**故事正文(Markdown)** | 不交 JSON 裁决包;不靠结构化包改表 |
|
||
| **旁观维护(副 LLM)** | auditor | **查漏补缺**:读本轮正文推断表变更、该不该按生成规则补实例;多数轮**空操作** | 不当作者写正文;不替代主世界叙事 |
|
||
|
||
转述(若启用)读主世界正文:提取场面、按文风改写、按壳镶前端;可补残稿,不改剧情。
|
||
|
||
## 2. 你提到的两种做法
|
||
|
||
**做法甲:DM 先提要求 → 副 LLM 交作业 → DM 再过一遍**
|
||
|
||
```text
|
||
DM:「按怪物规则补 1 个」→ 旁观生成 → DM 再写一遍
|
||
```
|
||
|
||
- 优点:DM 始终握笔。
|
||
- 缺点:同一回合容易 **3 次模型调用**,贵、慢;旁观一不小心变成「小作者」。
|
||
|
||
**做法乙:DM 先交齐正文 → 副 LLM 根据正文改表**
|
||
|
||
```text
|
||
DM 写故事正文 →(可选转述润色)→ 旁观只动表/触发生成 → 程序合并,不再开一轮 DM
|
||
```
|
||
|
||
- 优点:叙事权威仍在 DM;旁观像**库管/校对**。
|
||
- 缺点:若正文写错事实,旁观「修表」救不了叙事,只能修状态。
|
||
|
||
## 3. 本仓库采用的(推荐)
|
||
|
||
**采用做法乙:主世界层先写正文 →(可选)转述 → 旁观在回合末改表(合并结果供下一轮主世界层读取)。**
|
||
|
||
```text
|
||
每轮:
|
||
1. 主世界层:读上一轮合并后的 变量.当前 + 设定 + 历史 + 用户输入
|
||
→ 直接写 Markdown 故事正文(输出.用户展示;可经 harness 调机遇工具)
|
||
2. 叙事转述(若启用):读主世界正文 → 提取/改写/镶壳 → 覆盖 输出.用户展示
|
||
3. 旁观维护:读本轮正文 + 合同 + 表
|
||
→ 多数轮:空 maintain
|
||
→ 少数轮:table_ops / need_generate
|
||
4. 程序:合并旁观 table_ops → 变量.当前(**下一轮**主世界层才读到)
|
||
```
|
||
|
||
无转述时:主世界正文即用户终稿,往往已够用。
|