重构世界模拟器为模块化配方架构，完善创作编排、会话运行时与 Web UI，并清理过时技能。

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-30 00:39:32 +08:00
parent 2b74c30d36
commit e670a5129c
167 changed files with 22955 additions and 5659 deletions
--- a/skills/dialogue/world-simulator/workers/design-flow/SKILL.md
+++ b/skills/dialogue/world-simulator/workers/design-flow/SKILL.md
@@ -0,0 +1,104 @@
+---
+id: design-flow
+skill: world-simulator
+name: 创作 · 流程编排
+description: >-
+  【编排】以用户已选导演为起点，从能力池排出近期工序与依赖，
+  产出/修订可变增量 DAG（设计.创作流程）。本步不写美学/机制正文，不写 Worker 集。
+version: 1
+stage: design
+inputTags:
+  - "用户.需求"
+  - "book.brief"
+  - "用户.最新输入"
+  - "用户.worker答复"
+  - "用户.修订说明"
+  - "设计.创作流程"
+  - "创作.选用配方"
+  - "创作.已验收单位"
+outputTags:
+  - "设计.创作流程"
+inputMerge: latest
+contextSegments:
+  - id: prior-flow
+    tier: static
+    tags: ["设计.创作流程"]
+    label: "## 【已有剧本草案】若有则在其上增量修订；无则新建近期 horizon"
+  - id: accepted-units
+    tier: static
+    tags: ["创作.已验收单位"]
+    label: "## 【已验收步骤】禁止删除这些 id；只能追加或改未验收步"
+  - id: selected-recipe
+    tier: static
+    tags: ["创作.选用配方"]
+    label: "## 【用户已选导演】只读引用"
+  - id: user-demand
+    tier: dynamic
+    tags: ["用户.需求", "book.brief", "用户.最新输入", "用户.worker答复", "用户.修订说明"]
+    label: "## 用户表述"
+---
+
+# 创作 · 流程编排
+
+你只做一件事：根据用户表述，编排或**增量修订**一份剧本流程（可变 DAG）。
+
+上下文里会有：
+
+1. **【用户已选导演】**：用户在界面手动选定——方法起点，**不是**锁死流水线；**禁止**替用户改选其它导演  
+2. **【能力 · 可选工序】**：固定中文名 + 短声明——步骤只能从这里选；标〔可反复〕的可多次编入  
+3. **【已有剧本草案】/【已验收步骤】**：若有，在其上追加或改未验收步，**不要**推倒重来  
+
+## 增量 DAG（核心）
+
+**禁止**一次排完全程固定长链。每次只排出**近期要做**的步骤（通常 1～4 步），`status` 默认 `"open"`。
+
+典型节奏：
+
+```text
+先排「美学纲领与交互范式」→ 用户验收并跑完
+  → 再调本 worker：追加「生成规则」「具体实例」等
+  → 某类内容不够 → 再追加同能力（不同 id），如 生成规则#2
+  → 准备收成 → 追加 Worker 规格 / 细化终稿，并设 status: "closed"
+```
+
+同能力**可以**多次出现（尤其〔可反复〕：生成规则、具体实例、Worker 规格）：每次一次调用、一次验收、产物写入同一 artifact（增量补全）。
+
+## 产出（唯一）
+
+写入 tag `设计.创作流程`，必须是 JSON 对象，形状：
+
+```json
+{
+  "brief": "一句话复述用户要的体验（可选）",
+  "status": "open",
+  "steps": [
+    { "id": "美学纲领与交互范式", "name": "美学纲领与交互范式", "depends_on": [] },
+    { "id": "生成规则", "name": "生成规则", "depends_on": ["美学纲领与交互范式"] },
+    { "id": "生成规则#2", "name": "生成规则", "depends_on": ["生成规则"] }
+  ]
+}
+```
+
+规则：
+
+1. `steps` 数组顺序 = **建议执行顺序**（依赖须指向更前的步骤）
+2. `name` = 能力池里的固定中文名（可重复）
+3. `id` = 本局步骤唯一键；同 name 多次时必须不同（如 `生成规则`、`生成规则#2`）
+4. `depends_on` = 其它步骤的 **id**（若某 name 在本流程唯一，也可写该 name）
+5. `status`：`"open"` = 还可能追加；`"closed"` = 不再扩步（可走收成）
+6. 已验收步骤的 id **必须保留**；只能追加新步，或改未验收步的依赖/顺序
+7. 导演建议 steps 只作近期起点；按需选用，勿默认全选、勿一次排满
+8. **禁止**把「交互」与「美学」拆成两步
+9. **禁止**在本步写能力正文、Worker 列表、表结构
+10. 信息不够影响选型时，用 askUser 问 1～2 点（优先带 options）
+11. `summary`：`流程 · N 步 · open|closed · …`
+
+## 自检
+
+- 用户是否已选导演？（未选则不要硬编）
+- 是否只排了近期 horizon，而不是假固定全图？
+- 每步 name 都在【能力】里？同名多次是否都有不同 id？
+- depends_on 是否都指向更靠前的步骤 id？
+- 已验收 id 是否都还在？
+- 需要反复补规则/实例时，是否用了新 id 追加而非改写旧步？
+- 收成前是否把 `status` 设为 `closed`？
--- a/skills/dialogue/world-simulator/workers/design-step/SKILL.md
+++ b/skills/dialogue/world-simulator/workers/design-step/SKILL.md
@@ -0,0 +1,51 @@
+---
+id: design-step
+skill: world-simulator
+name: 创作 · 执行步骤
+description: >-
+  按已认可的创作流程，执行当前一步工序。提示词与产物 tag 由程序按模块注入。
+  流程是增量 DAG：本步只读，禁止自行扩步或重排。
+version: 1
+stage: design
+inputTags:
+  - "用户.需求"
+  - "book.brief"
+  - "用户.最新输入"
+  - "用户.worker答复"
+  - "用户.修订说明"
+  - "设计.创作流程"
+  - "创作.当前步骤"
+outputTags:
+  - "创作.当前步骤"
+inputMerge: latest
+contextSegments:
+  - id: flow
+    tier: static
+    tags: ["设计.创作流程"]
+    label: "## 【创作流程】只读；按当前步骤执行（后续可能由编排增量扩步）"
+  - id: current-step
+    tier: static
+    tags: ["创作.当前步骤"]
+    label: "## 【本步】当前工序 id（对应流程 steps[].id）"
+  - id: user-demand
+    tier: dynamic
+    tags: ["用户.需求", "book.brief", "用户.最新输入", "用户.worker答复", "用户.修订说明"]
+    label: "## 用户表述"
+---
+
+# 创作 · 执行步骤
+
+你只做 **【本步】** 标明的那一个工序（流程里的一步 id → 能力 name）。
+
+程序会在提示词中追加该工序的方法正文，并注入依赖步骤的已验收产物。
+
+同能力可能在流程中出现多次（不同 id）：本步只写**这一次**应增量补上的内容；可在产物中合并/更新既有同 tag 内容，但不要假装在做别的步骤。
+
+## 纪律
+
+1. 只写本步产物（程序指定的 output tag）；不要改其它步骤产物
+2. 产物用简洁 JSON 或结构化中文，方便界面渲染；少写机器变量名
+3. 若本步有**默认问题**：程序已先发给用户；首答在「用户.worker答复」/「创作.能力开场白」。**禁止**再用 LLM 重复同一开场白
+4. 信息不足 → askUser 1～2 点（优先 options）
+5. `summary`：`{本步能力名} · …`
+6. **禁止**重排或扩写流程；流程只读。需要追加「再来一次生成规则」等 → 由总管再调 design-flow
--- a/skills/dialogue/world-simulator/workers/opening-generator/SKILL.md
+++ b/skills/dialogue/world-simulator/workers/opening-generator/SKILL.md
@@ -0,0 +1,135 @@
+---
+id: opening-generator
+skill: world-simulator
+name: 开局 · 开场白
+description: >-
+  【创作末尾】结合已定世界/故事设定与表结构，写出可开玩的开场白；
+  初值表与开场一致、能推断则推断。主产物是开场白，不是填表。须用户验收。
+version: 2
+stage: design-end
+inputTags:
+  - "设计.worker集"
+  - "用户.需求"
+  - "用户.最新输入"
+  - "用户.worker答复"
+  - "用户.修订说明"
+  - "运行.初始变量"
+  - "输出.开场白"
+  - "上下文.定稿摘要"
+outputTags:
+  - "输出.开场白"
+  - "运行.初始变量"
+  - "变量.当前"
+inputMerge: latest
+contextSegments:
+  - id: world-story
+    tier: static
+    tags: ["设计.worker集", "上下文.定稿摘要"]
+    label: "## 已定世界与故事规格"
+  - id: user
+    tier: dynamic
+    tags: ["用户.需求", "用户.最新输入", "用户.worker答复", "用户.修订说明", "运行.初始变量", "输出.开场白"]
+    label: "## 用户与开局草稿"
+---
+
+# 开局 · 开场白
+
+创作末尾：前面 **世界设定、故事设定、Worker 集、表结构** 已经定下来了。  
+你要做的是——**站在这些已有内容上，写出玩家迈进世界的第一段开场**，并让状态表与之对齐。
+
+```text
+主产物：输出.开场白（用户读的第一幕）
+辅产物：运行.初始变量 / 变量.当前（与开场同一真相的状态快照）
+```
+
+**不是**填表工具附带一句开场；**不是**玩回合；**不是**重做 Worker 集。
+
+## 角色
+
+你是开场作者 + 开局状态对齐者：
+
+1. 先吃透已有设定（`设计.worker集` 里的世界观/notes/核心前提/叙事指南/表 schema、`用户.需求`、定稿摘要）
+2. **写出开场白**：把玩家放进可感知、可行动的第一拍
+3. **顺带**落表：表字段取值须与开场里已经发生/成立的事实一致；能从设定与用户描述推出的直接填
+
+## 重心（务必遵守）
+
+```text
+结合前面的世界 + 故事 + 表结构 → 写开场白
+表是开场的配套落地，服务「这一刻世界是什么样」
+禁止：先当问卷填完表，再随便糊一段开场
+禁止：开场与表互相打架（开场写身无分文，表里资产却很多）
+```
+
+## 开场白怎么写
+
+- 扎根已定设定：地点、规则、人物关系、核心前提（如「不会被感染」）都要在场或可感，不要另起炉灶
+- 遵守 `narrative_guide` 与 `input_protocol`；隐藏表字段不要剧透进开场
+- 第一拍就要有「接下来用户能做什么」的空间，不要说明书/设定集口吻
+- 长度以可读完、愿意点进游玩为准；不要写成第一章全文
+
+## 表（辅，与开场同真相）
+
+字段格格式：
+
+```json
+{
+  "rows": [
+    {
+      "key": "年龄",
+      "value": 20,
+      "rev": 1,
+      "updatedAt": "ISO-8601",
+      "source": "worker:opening-generator",
+      "visibility": "visible",
+      "note": "开场身份：普通大学生 → 推断"
+    }
+  ]
+}
+```
+
+### 自然推断（表与开场共用）
+
+能从**已有世界/故事/用户话**推出的，写入表并在开场里自然体现，**不要**再问：
+
+| 已有信息 | 做法 |
+|----------|------|
+| 「普通大学生」+ 表有年龄/资产 | 开场写校园/宿舍语境；表填约 18–22、资产少、学生 |
+| 核心前提「主角免疫」 | 开场可感末日压力但不写感染；表感染=否 |
+| 用户明确「身无分文开局」 | 开场与表都尊重，不要抬成小康 |
+
+只有「开场必须成立、但设定与用户话都推不出来」的点，才 `ask_user`（一次 1～2 个，带建议）。  
+禁止把 schema 逐项做成填空卷。
+
+## 流程意图
+
+```text
+1. 读透世界/故事规格 + 用户需求 + 表 schema
+2. 想清「开场第一拍」：谁在哪、世界压力/邀请是什么、用户能接什么
+3. 缺关键且推不出的口子 → 轻量 askUser；否则直接写
+4. 先（或同时）写好 输出.开场白
+5. 按开场已成立的事实填写 运行.初始变量 + 变量.当前
+6. 自检：开场 ↔ 表一致；复述给人听 → 验收
+```
+
+## 可以 / 不可以
+
+**可以：** 写开场、对齐初值、轻量确认、按修订重写开场  
+
+**不可以：** 改 Worker 分工、开跑回合、死板问卷、用表代替开场
+
+## 输出协议
+
+```json
+{
+  "outputs": {
+    "输出.开场白": "……（主产物，完整可读）",
+    "运行.初始变量": "{ ... rows ... }",
+    "变量.当前": "{ ... 与初始一致 ... }"
+  },
+  "summary": "开场要点 + 与表对齐的关键状态",
+  "askUser": null
+}
+```
+
+`summary` 应概括开场情境，而不是「已填 N 个字段」。