重构世界模拟器为模块化配方架构，完善创作编排、会话运行时与 Web UI，并清理过时技能。
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
511
docs/design-orchestrator-guide.md
Normal file
511
docs/design-orchestrator-guide.md
Normal file
@@ -0,0 +1,511 @@
|
||||
# 创作设计指导（总管 / 分步 design skills）
|
||||
|
||||
> **文档层级：剧本 / 创作方法（非系统架构）。**
|
||||
> 运行内核边界见 [`architecture.md`](./architecture.md)；本文不定义相位机、持久化或 Context Compiler。
|
||||
|
||||
权威说明：如何从用户意图收成 **实例规格（`设计.worker集` JSON）**，并指导 play 期声明调度。
|
||||
非固定创作流水线；`world-simulator` 等只是可选能力 ref，不是默认总形态。
|
||||
|
||||
相关：`context-assembly.md`（拼装）、`preset-format.md`（全局预设）、`tag-blackboard.md`（黑板）、`run-snapshot.md`（快照）。
|
||||
|
||||
包内落地：
|
||||
|
||||
| 文件 | 角色 |
|
||||
|------|------|
|
||||
| `orchestrator.md` | 总管调度 |
|
||||
| `design-common.md` | 创作共同开头（注入各 design-*） |
|
||||
| `workers/design-core/` | A 核心（开放，不拆 A1→A2→A3 管道） |
|
||||
| `workers/design-worker/` | 一次一个 worker |
|
||||
| `workers/design-fixed/` | 一次一块固定上下文 |
|
||||
| `workers/design-refine/` | C 细化 / 终稿 |
|
||||
|
||||
**运行时以各 SKILL + design-common 为准**；本文是方法长文，改方法时与 skill 切片一起改。
|
||||
|
||||
---
|
||||
|
||||
## 0. 总原则
|
||||
|
||||
```text
|
||||
三大步（每步含自检，可反复，无强制题材工序）
|
||||
A 核心 → 站位 + 系统扮演/输出/交互 + 体验检验
|
||||
B 细节交互 → Worker/常驻上下文能否撑起世界与交互；冲突请用户选
|
||||
C 细化 → 钉死不能瞎发挥的关键前提；表/数据拓扑/副作用；用户是否满意
|
||||
|
||||
全程正推：需要 [体验] → 用 [常驻上下文 | 表 | worker | 程序 | 预设 | tool] 维持/产出
|
||||
每增必问：能否缩减？常驻上下文能否替代？能否合并？黑板够不够/是否多余？
|
||||
```
|
||||
|
||||
**禁止**
|
||||
|
||||
- 题材 → 固定 worker 清单；否定式路由；完整历史喂 LLM 再筛给另一 LLM
|
||||
- 格式/排版专用 worker；临时生成 tool；默认 input 整理 worker
|
||||
- 把「世界模拟」当成开场默认答案
|
||||
- 固定 instantiate 管道（world-blueprint 等）
|
||||
|
||||
**预设**：凡 LLM 请求（总管 / agent / worker）均插入用户预设。
|
||||
**进 play**：用户手动满意后进入（程序不强制开局锁定）。
|
||||
**Play 回合**：用户新输入 = 认可上一轮最终展示；否则重 roll / 编辑后重 roll。表维护可延后。
|
||||
|
||||
**规格格式**：`设计.worker集` 为 **JSON**（权威存储）；解析层可兼容旧 YAML 草稿，新产出必须 JSON。
|
||||
|
||||
---
|
||||
|
||||
## 1. 交互流程（先定「怎么和人轮转」）
|
||||
|
||||
输出本质可以都是「系统给出一截用户可见结果」，但 **轮转形态**不同，规格必须写明：
|
||||
|
||||
| 形态 | 典型 | 规格要点 |
|
||||
|------|------|----------|
|
||||
| 对话回合 | 最终展示一轮 ↔ 用户一轮 | 终稿 tag；无每轮验收 |
|
||||
| 助手分段 | 先大纲/细纲，用户填表再继续 | 表可编辑；阶段门控；大纲可走表副作用 |
|
||||
| 其它 | 旁观多角、写手统筹… | 站位 + 系统扮演共同决定 |
|
||||
|
||||
用户可 **编辑表（精确到字段格）** → 必须有 **字段级版本**（见 §5）。
|
||||
|
||||
---
|
||||
|
||||
## 2. 三大步
|
||||
|
||||
### A. 核心
|
||||
|
||||
#### A1. 用户站位（扮演什么）
|
||||
|
||||
单角代入 / 代理操控 / 旁观·实验 / 写手统筹 / 多角切换…
|
||||
→ 谁决策、输入如何解释、结构骨架。
|
||||
|
||||
#### A2. 系统扮演什么（play agent 整体）
|
||||
|
||||
指整个 **play agent 系统** 要：
|
||||
|
||||
- **扮演什么**（世界执行者？对白对手？写作助手？陈述实验？）
|
||||
- **输出什么**（叙事、摘要、选项、表、大纲块…）
|
||||
- **怎么输出**（单段终稿 / 程序拼状态栏+正文 / 多面板）
|
||||
- **怎么与用户交互**（回合对话、填表驱动、先大纲后正文…）
|
||||
|
||||
由此才谈：要不要转述、程序拼格式、表是否上屏等。
|
||||
|
||||
#### A3. 核心体验检验（首要评分，自检必做）
|
||||
|
||||
对当前理解与「现有 worker/上下文草案」打分或文字判定。
|
||||
|
||||
**对内**：可只在思维链里过一遍。
|
||||
**对外**（总管 `ask_user.assessment`，或关键分叉复述）：写成用户可读的完备度评价，再据此出题。
|
||||
|
||||
**首要（必须检）**
|
||||
|
||||
| 维 | 含义 |
|
||||
|----|------|
|
||||
| 核心体验 / 满足来源 | 用户最想反复感到什么；爽点从哪来（权力、求生、关系、解谜…）——**一切评价与追问以此为轴** |
|
||||
| 用户–`<user>` 关系 | 用户与代入角色/叙述对象的关系是否清楚 |
|
||||
| 焦点位置 | 注意力与镜头落在哪 |
|
||||
|
||||
**可选（有缺口才写，不必凑齐）**
|
||||
|
||||
| 维 | 含义 |
|
||||
|----|------|
|
||||
| 内容维度 | 情节/日常/战斗/推理…比重与情绪质感 |
|
||||
| 人物与关系 | 核心关系动态 |
|
||||
| 身体与感官 | 物质、亲密、暴力等描写边界 |
|
||||
| 背景与规则 | 世界架与规则用途 |
|
||||
| 意义与主题 | 快感 / 代价 / 终点 |
|
||||
|
||||
`assessment` 建议结构（按需删维）：
|
||||
|
||||
```text
|
||||
# 内容维度
|
||||
核心感觉: 完备度 40%
|
||||
已知: …
|
||||
待探: 用户期望的【情绪质感】是【方向A】？【方向B】？还是组合？
|
||||
|
||||
人物与关系: 完备度 50%
|
||||
已知: …
|
||||
待探: …
|
||||
```
|
||||
|
||||
`questions`：只针对「待探」里必须用户拍板的点；一次 1～2 题。
|
||||
- `prompt`：明确题干（「你更倾向于哪种…」）
|
||||
- `options`：**建议示范**（可含短场景钩子 + 点题句），用户可改写后采用；禁止空泛是/否
|
||||
|
||||
自问：缺口是常驻上下文、表、worker，还是必须问用户？能推断就别问。
|
||||
|
||||
变造世界提示：用户常给「基础架 + 变种设定」；核心体验往往来自变种——从设定读内核，但 **不要**写成固定工序，也不要题材锁死体验。
|
||||
|
||||
#### A 步通用自检
|
||||
|
||||
见 §3。
|
||||
|
||||
---
|
||||
|
||||
### B. 细节交互
|
||||
|
||||
对照 A 的结论，检查草案：
|
||||
|
||||
1. **现有 worker（+ 常驻上下文）能否满足需求？**
|
||||
2. **能否支撑起整个世界/助手流程？**
|
||||
3. **有无冲突必须用户选择？**（两套互斥满足来源、互斥交互形态等 → `ask_user`）
|
||||
|
||||
仍用正推补洞；能固定上下文则不上 worker（§6：示例话题可问用户，不是填空表）。
|
||||
**顺序软规则**：纲领类固定上下文（风格/叙事/美学）宜先于大量 worker——同一份 tag 挂多个 worker，而不是先列 worker 再填上下文。
|
||||
然后 §3 自检。
|
||||
|
||||
---
|
||||
|
||||
### C. 细化
|
||||
|
||||
原则：只钉 **不能交给 AI 自由发挥、又对体验关键** 的东西。
|
||||
变造世界已能推出的（已知现代 → 不问常规科技树）默认不问，除非用户提过。
|
||||
|
||||
常钉类（按需）：规则与 **核心实现前提**、状态、**表结构**、**整体叙事指南**（≠ 文风：管世界态度与体验边界）、输入协议。
|
||||
|
||||
本步更盯 **数据**：
|
||||
|
||||
- 什么要 **拓扑化**（依赖、阶段边、触发边）？
|
||||
- 什么要 **数据化/进表**？
|
||||
- 表字段、显隐（折叠防剧透，非防用户）、维护规则、副作用是否清楚？
|
||||
- **用户是否满意** 这些钉死项？
|
||||
|
||||
大纲：**不必**单独「大纲管道」。需要时用 **表 + 副作用**——例如表字段 `当前章=第一章` → 边沿触发插入「第一章细纲」上下文（与好感改人设同一套机制，见 §5）。
|
||||
|
||||
然后 §3 自检。
|
||||
|
||||
---
|
||||
|
||||
## 3. 每一步自检清单（三大步与每一小步共用）
|
||||
|
||||
每完成一截推理或改草案，强制过一遍：
|
||||
|
||||
| # | 问 |
|
||||
|---|-----|
|
||||
| 1 | **能否缩减？** 这条能力/字段/worker 删了是否仍成立？ |
|
||||
| 2 | **增加的必要性？** 删掉会丢掉哪段体验？ |
|
||||
| 3 | **上文是否足够** 辅助主 LLM 完成其 duty？不足补常驻/表/黑板，而非盲目加工人 |
|
||||
| 4 | **写入黑板的内容** 够不够？是否多余？ |
|
||||
| 5 | **能否与其它 worker 合并？** 或 **常驻上下文替代？** |
|
||||
| 6 | **上下文插入是否按「变动/重要度」顺序？**（稳定块与易变块分层；参考 ST 注入位思路） |
|
||||
| 7 | （C 步加重）数据传播、表、副作用、字段版本是否自洽？有无「持续为真每轮触发」？ |
|
||||
|
||||
复述给用户时：说明有什么、**为何没有** 某重型件。
|
||||
|
||||
---
|
||||
|
||||
## 4. 短板加装（表见 §5）
|
||||
|
||||
| 短板 | 做法 |
|
||||
|------|------|
|
||||
| 可见文本质量 | 转述 worker **或** 常驻文风；能轻则轻 |
|
||||
| 记忆 / 长线 / 大纲 / 随机分支 / 人设阶段 | **统一用表**（§5）：维护 + 显隐 + 副作用插换上下文 |
|
||||
| 信息差玩法 | 分角 worker；极贵，慎用 |
|
||||
| 格式 | 程序拼 |
|
||||
| 真随机 / 骰子卡组计算 | 用户触发或填入，或表；已有 tool 手动调；不临时造 tool |
|
||||
| 用户不应知道的信息 | 程序固定注入，不进可见区；非 input 整理 worker |
|
||||
| 输入协议 | 常驻上下文（`()` 元要求、`""` 对白、无包裹=事实等） |
|
||||
|
||||
长线记忆：**不上**则靠模型；**要上**则 RAG（固定少设计）或表；禁止历史互喂筛选。
|
||||
|
||||
---
|
||||
|
||||
## 5. 表（结构 · 版本 · 维护 · 副作用 · 大纲）
|
||||
|
||||
### 5.1 用途
|
||||
|
||||
状态与物品、显隐信息、阶段/章节、随机与事件权重、人设态度段、**大纲/细纲挂载**、驱动常驻上下文插入或替换。
|
||||
|
||||
### 5.2 结构与显隐
|
||||
|
||||
- 扁平、利于二维表 UI；schema 写在 Worker 集
|
||||
- **显形 / 隐藏（可折叠）**：防剧透、分层观看，不是防用户
|
||||
- 维护规则可执行，并带触发语义（默认 once + edge）
|
||||
|
||||
### 5.3 字段格版本（防互相覆盖）
|
||||
|
||||
每一 **字段格**（非仅整表）含至少：
|
||||
|
||||
```text
|
||||
value, rev, updatedAt, source # source: user | worker:<id> | system
|
||||
```
|
||||
|
||||
合并规则：
|
||||
|
||||
- 用户编辑升 `rev`，`source=user`
|
||||
- Worker 写回须带 **读时的 rev**；若当前 rev 已变 → **不覆盖**，跳过或 ask_user
|
||||
- 禁止无条件用维护结果盖掉用户格
|
||||
|
||||
### 5.4 维护 worker
|
||||
|
||||
读：正文/裁决、维护规则、当前表 → 写：字段更新。
|
||||
可不写用户终稿；可与展示链解耦、**延后**跑。
|
||||
|
||||
### 5.5 副作用（含大纲、人设、事件）
|
||||
|
||||
表值变化满足条件 → 触发声明内专用逻辑（改写态度段、插入第 N 章细纲、替换某常驻块等）。
|
||||
|
||||
优先：查表换段；跨阶段再跑改写 LLM。
|
||||
|
||||
**防无限触发（程序约定，写入规格）：**
|
||||
|
||||
1. **边沿**：`prev` 不满足且 `now` 满足才触发
|
||||
2. **阶段字段**：规则绑「进入 stage」，不绑「处于 stage」
|
||||
3. **`fired` / ruleId**：once 规则触发后标记，不再入队
|
||||
4. 可重复须显式（`mode: every_edge`）+ 冷却/边沿
|
||||
5. 同 round 同 ruleId 最多一次；对本轮维护用快照算边沿，限制连锁爆炸
|
||||
|
||||
例：`好感>=60→恋爱` 不得每轮触发；`当前章=第一章`→插入细纲须 edge 或章字段变更 once。
|
||||
|
||||
**规格字段（`tables.side_effects[]`）：**
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "affinity-romance",
|
||||
"field": "好感",
|
||||
"op": "gte",
|
||||
"value": 60,
|
||||
"mode": "once",
|
||||
"action": {
|
||||
"type": "write_tag",
|
||||
"tag": "上下文.角色态度",
|
||||
"content": "恋爱模式：……"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
| 字段 | 含义 |
|
||||
|------|------|
|
||||
| `op` | `eq` / `neq` / `gte` / `lte` / `gt` / `lt` / `truthy` / `changed` |
|
||||
| `mode` | `once`（边沿 + 记 fired）\| `every_edge`（可反复跨边沿） |
|
||||
| `action.type` | `write_tag` / `replace_tag` / `queue_worker` |
|
||||
|
||||
实现：`src/blackboard/table-side-effects.ts`；写 `变量.当前` / `运行.初始变量` 后由 runtime 求值；fired 存 `运行.表副作用.fired`。
|
||||
|
||||
### 5.6 与交互流程
|
||||
|
||||
助手流：生成大纲/细纲 → **用户写入/改表** → 副作用或调度读表继续；始终尊重字段 `rev`。
|
||||
|
||||
---
|
||||
|
||||
## 6. 固定上下文族与预设
|
||||
|
||||
**「固定上下文」是概称**：不必单独开 worker、由程序按契约插入 prompt 的内容。
|
||||
**不上 worker ≠ 不重要**——谈清楚并写进规格的纲领/范式，往往比某个中间 worker 更决定体验。
|
||||
|
||||
### 6.0 Tag 的真正用途（纠正）
|
||||
|
||||
固定上下文用稳定 **tag / 单位 id** 命名（如美学纲领、叙事指南），便于：
|
||||
|
||||
1. **同一份正文挂到多个 worker**（`mount` / `contextSegments` / 声明映射）——这是主收益
|
||||
2. **创作单位分块验收**——扯皮过程可折叠，定稿切片进「创作.已验收内容」（已做）
|
||||
|
||||
**不是**「只报 tag 名就能省掉创作期依赖正文」。写 B 块时若依赖 A 的内容，仍要把 A 的定稿喂给写 B 的 LLM；tag 不能替代依赖传递。
|
||||
|
||||
```text
|
||||
能省：反复扯皮直到定稿之前的过程（验收折叠）
|
||||
不能省：写下游时对上游定稿正文的依赖
|
||||
主收益：跨 worker 复用同一份固定上下文，而不是为每个 worker 各写一份
|
||||
```
|
||||
|
||||
### 6.1 用法（重要：不是填空）
|
||||
|
||||
§6.2 里的名称 **只是示例话题**：告诉 design / 总管——**可以向用户询问类似内容**，再收成固定上下文。
|
||||
|
||||
```text
|
||||
不是：按表逐项填空、默认必谈、谈完才算过关
|
||||
而是：对话中若体验需要钉死某类边界/呈现/协议 → 可以按这类话题问用户 → 写入规格并注入
|
||||
```
|
||||
|
||||
正推仍成立：需要维持 [体验/边界/呈现] 且宜稳定注入 → 固定上下文；会变 → 表；本轮推理 → worker。
|
||||
问什么、问几句、要不要问，由当前体验缺口决定——**禁止把示例表当成问卷。**
|
||||
|
||||
### 6.2 示例话题（可问用户的方向）
|
||||
|
||||
| 话题（示例） | 大致在问什么 | 若收成规格，常见落点 |
|
||||
|--------------|--------------|----------------------|
|
||||
| 交互怎么转 | 站位、系统扮演、输出、怎么一轮一轮交手 | `interaction`（多由 `phase:core` 收） |
|
||||
| 叙事指南 | 世界/助手态度与体验边界（≠ 文风） | `narrative_guide` |
|
||||
| 美学纲领 | 呈现给用户的可读终稿气质 | `presentation` / 常驻美学块 |
|
||||
| 输入协议 | `()` / `""` / 无包裹等约定 | `input_protocol` |
|
||||
| 核心前提 | 不能瞎发挥又关键的硬前提 | `core_premises` |
|
||||
| 其它常驻片段 | 只给部分 worker 的稳定句（态度段、轻规则…） | `resident_context[]` |
|
||||
|
||||
落点 id（`fixed:*` / `resident:*`）仅在 **已经写出内容、要当创作单位验收** 时使用；没有内容就不要当成待填格子。
|
||||
实现里的 `FIXED_CONTEXT_CATALOG` 同样是提示目录，不是 UI 填空项。
|
||||
|
||||
### 6.3 创作顺序（软）
|
||||
|
||||
```text
|
||||
phase:core（核心体验 + 交互）
|
||||
→ 纲领类固定上下文（风格 / 叙事 / 美学…）——宜先于大量 worker
|
||||
→ 一次一个 worker（声明挂载哪些已有 tag，勿复制纲领）
|
||||
→ 杂项常驻 / 表 / 副作用 → 终稿
|
||||
```
|
||||
|
||||
**禁止默认**「先写完 worker 列表，再为每个 worker 填写上下文」。
|
||||
Worker 规格应回答：职责是什么、读哪些已有 tag、写哪些 tag——而不是顺带发明一份私有美学。
|
||||
|
||||
**UI**：检查器把固定上下文做成 **独立卡片区**（非 Worker 子项），每张卡展示 **塞进哪些 Worker**；见 `worker-set-view.ts` 的 `contextTags`。
|
||||
|
||||
### 6.4 常驻条目与预设
|
||||
|
||||
杂项常驻（`resident_context[]`）形状示例：
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "tone",
|
||||
"position": "static",
|
||||
"importance": 2,
|
||||
"content": "文风克制、偏冷",
|
||||
"mount": ["narrator"]
|
||||
}
|
||||
```
|
||||
|
||||
- 默认黑板 tag `上下文.常驻.{id}`；可显式 `tag`
|
||||
- `mount` 空 = 全部 worker；否则仅列出的 ref
|
||||
- 能常驻则不上 worker；叙事指南 / 美学 / 交互等 **若已谈清**，用对应规格字段，不要全塞进含糊 `tone`
|
||||
- 越稳、越决定体验边界 → 插入位越靠上
|
||||
|
||||
预设 = 全局；固定上下文 = 实例/worker 级。
|
||||
用户不可见、模型必须知 → **程序固定拼装**，不是整理用户输入的 worker。
|
||||
实现：`src/skills/resident-context.ts`。
|
||||
|
||||
---
|
||||
|
||||
## 7. 产出与验收
|
||||
|
||||
产出：`设计.worker集` JSON，建议包含：
|
||||
|
||||
- `interaction`：站位、系统扮演、输出形态、与用户轮转方式
|
||||
- `experience_check`：首要三维（及可选维）摘要
|
||||
- `workers[]`：`ref` / `duty` / `rationale` / **`acceptance`（run 验收点，见 §7.3）**
|
||||
- `resident_context[]`：位置、内容摘要、挂载哪些 worker
|
||||
- `tables`：schema、显隐、维护规则、副作用（含 edge/once/stage）
|
||||
- `narrative_guide` / `core_premises`：叙事指南与核心实现前提
|
||||
- `input_protocol`：若需要
|
||||
- `design_end`：可选开局 · 开场白等备忘（非强制管道）
|
||||
|
||||
验收复述须含：站位；系统扮演/输出/交互；体验首要三维；有何 worker/表/副作用；**run 在哪些 worker 后停下来给人看**；为何没有某件；进 play 由用户决定。
|
||||
|
||||
交稿自检：题材词可替换仍成立；§3 清单通过；无持续为真每轮触发；格式程序化；字段级 rev 已设计；每个面向用户的可读终稿点有明确 `acceptance`。
|
||||
|
||||
---
|
||||
|
||||
## 7.1 强用户可读（前端约定）
|
||||
|
||||
创作期检查器须让用户看懂：
|
||||
|
||||
| 面板 | 内容 |
|
||||
|------|------|
|
||||
| **设计** | Worker 集卡片（含 run 验收点标注）、设计进度 |
|
||||
| **验收** | 当前产物结构化预览 + 接受/不接受（主确认点） |
|
||||
| **上下文** | 终产物 tag、活跃 tag、定稿摘要、已归档过程计数 |
|
||||
| **历史** | 调度时间线（可折叠） |
|
||||
|
||||
主 feed：隐藏过程调度；验收中的全文进验收 Tab；**创作对话 messages 全量保留供浏览**；拼给下一 design worker 的「创作.对话」才裁 AI（见 §7.2）。
|
||||
|
||||
---
|
||||
|
||||
## 7.2 创作与 Run：两套上下文（勿混）
|
||||
|
||||
| | 创作 `design` | Run / play |
|
||||
|--|---------------|------------|
|
||||
| 单位 | **创作单位**：一个 worker，或固定上下文族中的一块（交互范式 / 叙事指南 / 美学纲领 / …），同级 | 声明内的 run worker |
|
||||
| 会话 | 用户 ↔ 设计讨论进 **session `messages`（全量，用户可回看）**；**隐藏 AI 历史只作用于拼给模型的 transcript** | Worker **按契约从黑板重装**（`contextSegments` / `inputTags`） |
|
||||
| 验收后折叠 | **不删 messages**；产物在黑板/规格；同步「创作.对话」供下一单位 | 过程 tag 归档 + `上下文.定稿摘要`（`compress-after-worker.ts`） |
|
||||
| 禁止 | 一次收齐整份 worker 集 + 全部固定上下文；把纲领当成「顺便写的备注」 | 把创作闲聊塞进 worker prompt |
|
||||
|
||||
### 创作单位（粒度）
|
||||
|
||||
「固定上下文」= **族名**。族内某块 **只有谈出来并写入规格后** 才成为创作单位；§6.1 示例话题不是待填格子。
|
||||
|
||||
典型推进（非强制工序）：
|
||||
|
||||
1. `phase:core`：站位 + 交互 + 核心体验
|
||||
2. 需要时：风格 / 叙事 / 美学等 **纲领类** 固定上下文先验收（`design-fixed`）
|
||||
3. 各 `worker:{ref}`：挂载已有 tag，勿复制纲领
|
||||
4. 其它 `resident:*` → 表 / 副作用 → 终稿 `设计.worker集`
|
||||
|
||||
单位跑只写 `设计.worker集.草稿`；终稿才写 `设计.worker集`（才 `designInstanceReady`）。
|
||||
|
||||
### 创作会话（简单）
|
||||
|
||||
```text
|
||||
本单位进行中：问答、复述、草稿讨论 → 照常 append 到 messages（用户浏览全量）
|
||||
拼给 AI：写入黑板 tag「创作.对话」= 用户全量 + 仅最后一次 AI 输出（含未完成提问）
|
||||
不需要：步内 policy、创作专用拼装栈改写 messages
|
||||
```
|
||||
|
||||
### 创作折叠（简单）
|
||||
|
||||
```text
|
||||
用户接受本单位产物
|
||||
→ session.messages 不删（用户可继续浏览历史）
|
||||
→ 产物本身在黑板/规格里；已验收内容写入「创作.已验收内容」
|
||||
→ 同步「创作.对话」transcript（仍按：用户全量 + AI 只留最后一次）
|
||||
→ 下一单位从「已定稿产物 + 新对话」继续
|
||||
```
|
||||
|
||||
不在创作期做「定稿摘要再注入下一 design LLM」的复杂链；产物本身在黑板/规格里，够用。
|
||||
「隐藏 AI 历史」= 仅 transcript 裁剪，**绝不**从主 feed 删掉或折叠创作过程消息。
|
||||
|
||||
### Run 压缩（与创作正交）
|
||||
|
||||
```text
|
||||
用户在 run 验收点接受产物
|
||||
→ 终产物 tag 标记 final
|
||||
→ 过程 tag（worker 答复、*.草稿 等）归档
|
||||
→ 写入 上下文.定稿摘要
|
||||
→ 下一 worker 按契约重装时带上摘要与终产物
|
||||
```
|
||||
|
||||
实现：`src/runtime/compress-after-worker.ts`。
|
||||
禁止把完整过程讨论继续喂给下一 **run** worker。
|
||||
|
||||
---
|
||||
|
||||
## 7.3 Run 验收点（创作时必须设计进 Worker 集）
|
||||
|
||||
**不是**「整条 run 有没有验收」的二选一，也不是创作阶段的特例。
|
||||
|
||||
**是：** 规定 **跑完哪个 worker 之后必须停下来让用户阅读/验收**；其余可连续调度。
|
||||
|
||||
| `workers[].acceptance` | 含义 |
|
||||
|------------------------|------|
|
||||
| `review` | 本 worker 完成后进入用户验收；接受后才压缩并允许续跑 |
|
||||
| `continue` | 完成后可接着调下一个，不打断用户 |
|
||||
|
||||
**正推示例（写入 rationale / 复述给人听）：**
|
||||
|
||||
| 意图 | 典型停点 |
|
||||
|------|----------|
|
||||
| 自主长篇 | 大纲 / 主题 worker → `review`；正文链多段 → `continue`，直到用户叫停或大纲段落再 `review` |
|
||||
| 交互 / RP | 产出用户可见终稿的转述（如 narrator）→ `review`；世界裁决等中间层 → `continue` |
|
||||
|
||||
创作期按 **§7.2 创作单位** 分块验收（worker 与固定上下文同级），与上表正交。
|
||||
design-intake / 创作调度必须为 **每个** run worker 写出 `acceptance`；缺省时不得假设「全都不用验收」——面向用户的可读输出默认倾向 `review`，纯中间层倾向 `continue`，吃不准就 ask_user。
|
||||
|
||||
---
|
||||
|
||||
## 7.4 开局 · 开场白（opening-generator）
|
||||
|
||||
创作末尾、Worker 集已 accept 之后。此时 **世界设定、故事设定、表结构通常已经很详细**。
|
||||
|
||||
**主产物是开场白**（玩家迈进世界的第一段可读文本），不是填表。
|
||||
|
||||
```text
|
||||
结合前面的世界 + 故事 + 表结构 → 写开场白
|
||||
初值表 = 与开场同一真相的状态快照（辅）
|
||||
能从已有设定/用户话推出的字段 → 直接填并对齐开场，别问卷
|
||||
只有开场必须成立却推不出的点 → 轻量 ask_user
|
||||
```
|
||||
|
||||
例：已有校园末日设定 + 用户「普通大学生」→ 开场写宿舍/校园第一拍；表里年龄/资产/身份自然对齐；**不要**先发一张年龄资产问卷。
|
||||
|
||||
产出：`输出.开场白`（主）+ `运行.初始变量` / `变量.当前`（辅，字段格）。
|
||||
须用户验收。实现：`workers/opening-generator/SKILL.md`。
|
||||
|
||||
---
|
||||
|
||||
## 8. Play / Run 边界（给总管；运行时按声明执行）
|
||||
|
||||
- 只 `run_worker` 声明内的 ref
|
||||
- 遇 `acceptance: review` → 停、给人看、接受后压缩再继续
|
||||
- 遇 `acceptance: continue` → 可在 burst 内续调下一 worker（受 burst 上限约束）
|
||||
- 表维护 / 副作用可在终稿展示之后延后；写表须尊重字段 `rev` / `source=user`
|
||||
- 开局类 skill 仅创作末尾可选，禁止当 run 每轮技能
|
||||
Reference in New Issue
Block a user