主世界层直接写正文，转述与旁观改读用户展示输出。
去掉裁决包主路径，让无转述时可直出终稿、有转述时再改写镶壳。 Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Cursor
@@ -234,7 +234,7 @@ value, rev, updatedAt, source # source: user | worker:<id> | system
|
||||
|
||||
### 5.4 维护 worker
|
||||
|
||||
读：正文/裁决、维护规则、当前表 → 写：字段更新。
|
||||
读：本轮正文、维护规则、当前表 → 写：字段更新。
|
||||
可不写用户终稿；可与展示链解耦、**延后**跑。
|
||||
|
||||
### 5.5 副作用（含大纲、人设、事件）
|
||||
@@ -479,7 +479,7 @@ phase:core（核心体验 + 交互）
|
||||
| 意图 | 典型停点 |
|
||||
|------|----------|
|
||||
| 自主长篇 | 大纲 / 主题 worker → `review`；正文链多段 → `continue`，直到用户叫停或大纲段落再 `review` |
|
||||
| 交互 / RP | 产出用户可见终稿的转述（如 narrator）→ `review`；世界裁决等中间层 → `continue` |
|
||||
| 交互 / RP | 产出用户可见终稿的槽（无转述＝主世界层；有转述＝narrator）→ `review`；有转述时主世界草稿 → `continue` |
|
||||
|
||||
创作期按 **§7.2 创作单位** 分块验收（worker 与固定上下文同级），与上表正交。
|
||||
design-flow / design-step / 创作调度必须为 **每个** run worker 写出 `acceptance`；缺省时不得假设「全都不用验收」——面向用户的可读输出默认倾向 `review`，纯中间层倾向 `continue`，吃不准就 ask_user。
|
||||
|
||||
+14
-39
@@ -7,69 +7,44 @@
|
||||
|
||||
| 称呼 | 槽 | 干什么 | 不干什么 |
|
||||
|------|-----|--------|----------|
|
||||
| **主世界层（DM）** | gm | 读设定与当前状态，对本轮玩家行动做**裁决**；可提议改变量 | 不负责长文文风；不靠「再想一遍」修表 |
|
||||
| **旁观维护（副 LLM）** | auditor | **查漏补缺**：表缺字段、该不该按生成规则补一条实例；多数轮**空操作** | 不当作者写正文；不替代裁决 |
|
||||
| **主世界层（DM）** | gm | 读设定与当前状态，推进场面，直接写**故事正文（Markdown）** | 不交 JSON 裁决包；不靠结构化包改表 |
|
||||
| **旁观维护（副 LLM）** | auditor | **查漏补缺**：读本轮正文推断表变更、该不该按生成规则补实例；多数轮**空操作** | 不当作者写正文；不替代主世界叙事 |
|
||||
|
||||
转述只吃裁决包写用户可见文字——与「俩人怎么配合」无关。
|
||||
转述（若启用）读主世界正文：提取场面、按文风改写、按壳镶前端；可补残稿，不改剧情。
|
||||
|
||||
## 2. 你提到的两种做法
|
||||
|
||||
**做法甲：DM 先提要求 → 副 LLM 交作业 → DM 再过一遍**
|
||||
|
||||
```text
|
||||
DM：「按怪物规则补 1 个」→ 旁观生成 → DM 再裁决一次
|
||||
DM：「按怪物规则补 1 个」→ 旁观生成 → DM 再写一遍
|
||||
```
|
||||
|
||||
- 优点：DM 始终握笔。
|
||||
- 缺点：同一回合容易 **3 次模型调用**，贵、慢；旁观一不小心变成「小作者」。
|
||||
|
||||
**做法乙：DM 先交齐裁决 → 把结果和要求交给副 LLM → 副 LLM 用工具改表**
|
||||
**做法乙：DM 先交齐正文 → 副 LLM 根据正文改表**
|
||||
|
||||
```text
|
||||
DM 出裁决包（含变量变更）→ 旁观只动表/触发生成 → 程序合并，不再开一轮 DM
|
||||
DM 写故事正文 →（可选转述润色）→ 旁观只动表/触发生成 → 程序合并，不再开一轮 DM
|
||||
```
|
||||
|
||||
- 优点：叙事权威仍在 DM；旁观像**库管/校对**，适合工具改表。
|
||||
- 缺点：若裁决里已经写错事实，旁观「修表」救不了叙事，只能修状态。
|
||||
- 优点：叙事权威仍在 DM；旁观像**库管/校对**。
|
||||
- 缺点：若正文写错事实，旁观「修表」救不了叙事，只能修状态。
|
||||
|
||||
## 3. 本仓库采用的（推荐）
|
||||
|
||||
**采用做法乙：主世界层先拍板 → 转述 → 旁观在回合末改表（合并结果供下一轮主世界层读取）。**
|
||||
**采用做法乙：主世界层先写正文 →（可选）转述 → 旁观在回合末改表（合并结果供下一轮主世界层读取）。**
|
||||
|
||||
```text
|
||||
每轮：
|
||||
1. 主世界层：读上一轮合并后的 变量.当前 + 设定 + 历史 + 用户输入
|
||||
→ 出 settlement 裁决包（可含 variable_changes；可经 harness 调机遇工具）
|
||||
2. 程序：合并裁决中的 variable_changes → 变量.当前（边沿副作用照常）
|
||||
3. 叙事转述（若启用）：只读裁决包写用户可见正文
|
||||
4. 旁观维护：读本轮裁决 + 合同 + 表
|
||||
→ 直接写 Markdown 故事正文（输出.用户展示；可经 harness 调机遇工具）
|
||||
2. 叙事转述（若启用）：读主世界正文 → 提取/改写/镶壳 → 覆盖 输出.用户展示
|
||||
3. 旁观维护：读本轮正文 + 合同 + 表
|
||||
→ 多数轮：空 maintain
|
||||
→ 少数轮：table_ops / need_generate
|
||||
5. 程序：合并旁观 table_ops → 变量.当前（**下一轮**主世界层才读到）
|
||||
4. 程序：合并旁观 table_ops → 变量.当前（**下一轮**主世界层才读到）
|
||||
```
|
||||
|
||||
要点：
|
||||
|
||||
1. **不要**默认「旁观先扫再让 DM 裁决」（旧顺序已废弃）。
|
||||
2. **不要**默认「DM 写完再让旁观润色全文」（贵，且旁观会抢笔）。
|
||||
3. **不要**默认「旁观先写一大段设定再交给 DM」（旁观变作者）。
|
||||
4. 生成规则给旁观：只要**合同**（有哪些 rule、格式、何时该生成），不要整本描写范文。
|
||||
5. 真要「按规则生成实例」：旁观点 `need_generate.rule_id`，由**程序/既定生成通路**落表，而不是旁观写小说。
|
||||
|
||||
## 4. 和「生成规则要不要给副 LLM」的关系
|
||||
|
||||
问题本质不是「塞不塞那一份文档」，而是：
|
||||
|
||||
- 旁观要不要能说「该按某条规则补东西」？→ **要**，就得看见规则目录/格式。
|
||||
- 旁观要不要会写角色描写？→ **不要**，所以描写长文不必进旁观上下文。
|
||||
|
||||
## 5. 上下文与思考流（UI 对接）
|
||||
|
||||
主世界层游玩期走 **gm harness**（tool loop）：与普通 worker 相同，经 `onThinkingDelta` / `onOutputDelta` 把推理与正文增量推到前端；机遇工具往返也在同一气泡时间线内展示，不另开隐藏通道。
|
||||
|
||||
转述、旁观仍各是一次 worker 调用，各自独立流式输出；**不要**把旁观维护当成 gm 的 tool。
|
||||
|
||||
## 6. 一句话
|
||||
|
||||
**主世界层断事；转述说话；旁观在回合末对表，改表给下一轮。**
|
||||
交互上优先「一次裁决 + 延后轻维护」，不优先「来回多轮 LLM 传话」。
|
||||
无转述时：主世界正文即用户终稿，往往已够用。
|
||||
|
||||
@@ -93,8 +93,8 @@
|
||||
|
||||
设计.监控栏 → 回复呈现清单（看什么）
|
||||
设计.正文组成 → 壳 + 美化（怎么展示）
|
||||
运行.本轮.裁决 → body 事实；suggested_actions → 行动区
|
||||
输出.用户展示 → present.v1 或纯 Markdown（→ body）
|
||||
输出.用户展示（主世界正文）→ 转述提取/改写后的 body；suggested_actions → 行动区
|
||||
输出.用户展示（终稿）→ present.v1 或纯 Markdown（→ body）
|
||||
```
|
||||
|
||||
## 5. 游玩灌数契约
|
||||
|
||||
@@ -94,10 +94,10 @@ Progressive 投影 本轮主世界层只看见「当前档」；未
|
||||
|
||||
```text
|
||||
用户输入
|
||||
→ 主世界层（世界推演）：读变量 + 已投影 data，交事件/改真值（按规则）；可经 harness 批量调 chance 工具
|
||||
→ 主世界层（世界推演）：读变量 + 已投影 data，写本轮故事正文（Markdown）；可经 harness 批量调 chance 工具
|
||||
→（可选）角色视角：强信息隔离时出反应建议（默认关，插在主世界层之后）
|
||||
→（可选）叙事转述：把裁决写成用户可见正文
|
||||
→ 旁观维护（副 LLM）：合同+表+本轮裁决；默认空操作（maintain.v1）；改表供下一轮主世界层读取
|
||||
→（可选）叙事转述：读主世界正文，提取/改写/镶壳为用户终稿（可补残稿，不改剧情）
|
||||
→ 旁观维护（副 LLM）：合同+表+本轮正文；默认空操作（maintain.v1）；改表供下一轮主世界层读取
|
||||
```
|
||||
|
||||
| 内容 | 给谁 | 不要做成 |
|
||||
@@ -111,13 +111,13 @@ Progressive 投影 本轮主世界层只看见「当前档」；未
|
||||
|
||||
用户可见名：`ui-glossary.md`（主世界层、旁观维护、叙事转述…）。作者文档可称 **主世界层 / 旁观维护**，与酒馆「主 GM + auditor」同构；**不要**对用户改称整套系统为「GM 框架」而废弃「执行单元」。
|
||||
|
||||
**维护路径（不是 gm 的 chance toolcall）**：主世界层输出 settlement.v1 → Runtime 合并 `variable_changes` 进 `变量.当前` → `side_effects` 换投影；旁观维护输出 maintain.v1 → Runtime 按需合并 `table_ops` / `need_generate` 程序抽样。gm harness 的 `chance` 只负责本回合裁决前的骰子/抽签。
|
||||
**维护路径（不是 gm 的 chance toolcall）**：主世界层写正文 → 旁观维护输出 maintain.v1 → Runtime 按需合并 `table_ops` / `need_generate` 程序抽样 → `side_effects` 换投影。可选正文隐藏段维护语句。遗留 settlement.v1 仍可合并（旧存档）。gm harness 的 `chance` 只负责本回合的骰子/抽签。
|
||||
|
||||
## 6. 世界模拟器技能落点
|
||||
|
||||
| 技能 | 钉什么 |
|
||||
|------|--------|
|
||||
| **变量设计与更新规则** | 真值；**维护语句**形状（settlement / 隐藏段）；**Data 映射索引**（指向生成规则+具体实例）；`side_effects` |
|
||||
| **变量设计与更新规则** | 真值；**维护语句**形状（旁观 maintain / 隐藏段）；**Data 映射索引**（指向生成规则+具体实例）；`side_effects` |
|
||||
| **变量控制上下文** | 各槽视野；**旁观汇总**（当前档摘要，非整表）；剧透边界 |
|
||||
| **生成规则 / 具体实例** | 分档表 schema 与行数据（如好感→性格）；生成后由变量设计索引 |
|
||||
| **正文组成** | 隐藏段定界（供解析维护语句）；用户可见块序 |
|
||||
|
||||
Reference in New Issue
Block a user