3.2 KiB
3.2 KiB
主世界层 与 旁观维护：怎么配合
用白话说明「DM」和「副 LLM（旁观）」谁先谁后、谁干什么。
实现上当前管线是：旁观 →（可选角色视角）→ 主世界层 → 转述。
1. 先说清楚两个角色
| 称呼 | 槽 | 干什么 | 不干什么 |
|---|---|---|---|
| 主世界层（DM） | gm | 读设定与当前状态，对本轮玩家行动做裁决；可提议改变量 | 不负责长文文风；不靠「再想一遍」修表 |
| 旁观维护（副 LLM） | auditor | 查漏补缺：表缺字段、该不该按生成规则补一条实例；多数轮空操作 | 不当作者写正文；不替代裁决 |
转述只吃裁决包写用户可见文字——与「俩人怎么配合」无关。
2. 你提到的两种做法
做法甲：DM 先提要求 → 副 LLM 交作业 → DM 再过一遍
DM：「按怪物规则补 1 个」→ 旁观生成 → DM 再裁决一次
- 优点：DM 始终握笔。
- 缺点：同一回合容易 3 次模型调用，贵、慢；旁观一不小心变成「小作者」。
做法乙：DM 先交齐裁决 → 把结果和要求交给副 LLM → 副 LLM 用工具改表
DM 出裁决包（含变量变更）→ 旁观只动表/触发生成 → 程序合并，不再开一轮 DM
- 优点：叙事权威仍在 DM；旁观像库管/校对，适合工具改表。
- 缺点：若裁决里已经写错事实，旁观「修表」救不了叙事，只能修状态。
3. 本仓库采用的（推荐）
既不是甲也不是乙的「整段返工」，而是：旁观轻扫 → DM 拍板 →（程序合并旁观的改表）→ 转述。
每轮：
1. 旁观：看规则合同 + 当前表 + 玩家输入
→ 多数轮：什么都不改（空 maintain）
→ 少数轮：写 table_ops / need_generate（补字段或点名 rule_id）
2. 主世界层：出 settlement 裁决包（可含变量变更）
3. 程序：合并旁观改表 + DM 变量变更（边沿副作用照常）
4. 转述：只根据裁决包写正文
要点：
- 不要默认「DM 写完再让旁观润色全文」（贵，且旁观会抢笔）。
- 不要默认「旁观先写一大段设定再交给 DM」（旁观变作者）。
- 生成规则给旁观：只要合同（有哪些 rule、格式、何时该生成），不要整本描写范文。
- 真要「按规则生成实例」：旁观点
need_generate.rule_id，由程序/既定生成通路落表，而不是旁观写小说。
若以后要改成「乙」：把旁观挪到 DM 之后、只保留工具改表、禁止旁观输出正文——可以再开一刀改调度序；当前以已落地的「旁观在前、轻维护」为准。
4. 和「生成规则要不要给副 LLM」的关系
问题本质不是「塞不塞那一份文档」，而是：
- 旁观要不要能说「该按某条规则补东西」？→ 要，就得看见规则目录/格式。
- 旁观要不要会写角色描写？→ 不要，所以描写长文不必进旁观上下文。
5. 一句话
旁观看门与补表；DM 断事；转述说话。
交互上优先「轻维护 + 一次裁决」，不优先「来回多轮 LLM 传话」。