Load present shells from a skill-pack catalog and list leftover creation modules.
Design-flow now sees leftover catalog skills and aesthetics-card commitments; reply-format injects present-shells/, and world-simulator prompts add random-range plus a tighter module set. Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Cursor
@@ -249,11 +249,11 @@ Context Trace 是排查泄漏的主工具（契约已定，实现渐进）。
|
||||
| 运行内核 | `runtime-state-machine.md`、`tool-contracts.md`、`context-assembly.md`、`tag-blackboard.md` |
|
||||
| 持久化 | `book-storage.md`、`run-snapshot.md` |
|
||||
| UI | `ui-design.md`、`ui-glossary.md` |
|
||||
| 实现顺序 | `implementation-guide.md` |
|
||||
| 写代码规则 / 文档地图 | `implementation-guide.md` |
|
||||
| **产品体验路线** | **`px-roadmap.md`**（PX0–PX5 交付与 DoD） |
|
||||
| **日常场景 → P0** | **`daily-use-p0.md`**（场景、功能表、P0 工作包） |
|
||||
| 外部参考 | `references.md` |
|
||||
| **工作流计划 / 创作方法（非系统架构）** | `design-orchestrator-guide.md`、`creation-playbook.md`、`world-simulator-modules.md` |
|
||||
| **工作流计划 / 创作方法（非系统架构）** | `design-orchestrator-guide.md`、`creation-playbook.md`、`world-simulator-modules.md`、`progressive-data-design.md`、`context-fragment-design.md`、`play-presentation-shells.md`、`play-dm-auditor.md` |
|
||||
| **Skill 包格式（非系统架构）** | `skill-format.md`、`orchestrator-skill-format.md`、`worker-skill-format.md`、`skill-design-guide.md`、`preset-format.md` |
|
||||
| **技能撰写交接** | `briefs/capability-authoring-brief.md` |
|
||||
|
||||
|
||||
@@ -191,13 +191,13 @@ catalog 登记（短声明给编排看；可选 repeatable）
|
||||
| 交付物 | 路径 | 给谁看 |
|
||||
|--------|------|--------|
|
||||
| 目录行 | `modules/catalog.yaml` 一行 | 索引、`repeatable`、编排 `params` |
|
||||
| 方法全文 | `modules/{id}/prompt.md` | 执行该步的 LLM + 程序切割；**编排读 `meta` 的 when/when_not/boundary** |
|
||||
| 方法全文 | `modules/{id}/prompt.md` | **规划**读 `meta`（declaration / when / when_not / boundary）；**执行**读切割后的 task/opening/output |
|
||||
|
||||
编排时注入能力 **meta 选型字段**（非全文 prompt）；执行时才注入切割后的方法块。
|
||||
|
||||
## 3.4 能力之间如何相处
|
||||
|
||||
- **正推**：需要 [体验/产物] → 才纳入某技能；勿默认全选池内能力。
|
||||
- **正推**：需要 [体验/产物] → 才纳入某技能；勿默认全选池内能力。调用条件写在该技能 `when` / `when_not`，不要写进规划 SKILL 或配方 process。
|
||||
- **边界**：每个能力在 `meta.boundary` 写清「本步定什么 / 不定什么 / 交给谁」。
|
||||
- **依赖**：由工作流计划 `depends_on` 声明；执行期程序注入对应产物。
|
||||
- **合并**：询问主题高度重叠 → 合成一个能力（如美学+交互）。
|
||||
@@ -206,7 +206,7 @@ catalog 登记（短声明给编排看；可选 repeatable）
|
||||
## 3.5 方法层硬禁止（写任何能力都适用）
|
||||
|
||||
- 题材 → 固定执行单元清单。
|
||||
- 否定式路由（「因为是 X 所以不需要 Y」）；应写「需要 A 体验 → 用 B 手段」。
|
||||
- 否定式路由（「因为是丧尸题材所以不需要舞台骨架」）；应写「需要 A 体验 → 用 B 手段」。技能 `when_not` 指向另一个技能或「不排」不算否定式路由。
|
||||
- 把「世界模拟」当成一切开场的默认答案。
|
||||
- 为排版/格式单独发明执行单元；能程序拼则程序拼。
|
||||
- 临时发明 tool。
|
||||
@@ -305,14 +305,34 @@ boundary: |
|
||||
|
||||
## 4.3 `meta` 字段
|
||||
|
||||
| 字段 | 含义 |
|
||||
|------|------|
|
||||
| `name` | 固定中文名（= 流程 `steps[].name`） |
|
||||
| `id` | 英文 id（= 目录名） |
|
||||
| `artifact` | 本步写入的黑板 tag |
|
||||
| `declaration` | 给编排看的短声明（不是全文） |
|
||||
| `when` / `when_not` | 何时该/不该入选工作流计划 |
|
||||
| `boundary` | 与邻接能力的分工 |
|
||||
`meta` 是 **规划 LLM** 选型用的短文；执行 LLM 看不到这段当任务说明书（它读 `task` / `opening` / `output`）。
|
||||
|
||||
| 字段 | 含义 | 怎么写 |
|
||||
|------|------|--------|
|
||||
| `name` | 固定中文名（= 流程 `steps[].name`） | 与 catalog 完全一致 |
|
||||
| `id` | 英文 id（= 目录名） | kebab-case |
|
||||
| `artifact` | 本步写入的黑板 tag | |
|
||||
| `declaration` | 规划扫描池时的第一眼 | 解决什么缺口；不要写产物 JSON 形状 |
|
||||
| `when` | **现在**要不要进近期 DAG | 对照用户话、已验收步骤、已有产物就能判定的信号。例：还不能回答哪三句；已有哪份产物仍缺什么 |
|
||||
| `when_not` | 不该进图 | 每条指向另一个技能或「不排」。缺替代去向的「不要」规划用不上 |
|
||||
| `boundary` | 与邻接能力的分工 | 本步定什么 / 不定什么 / 交给谁 |
|
||||
|
||||
**错（规划无法判定，几乎任何局都会排）：**
|
||||
|
||||
```text
|
||||
when: 已有美学纲领，需要把感觉落成可执行的写法与推进时。
|
||||
```
|
||||
|
||||
**对：**
|
||||
|
||||
```text
|
||||
when: |
|
||||
已有美学纲领，但转述仍会不知道遣词/笔墨落点/绝对禁忌/故事靠场面还是等用户时才排。
|
||||
when_not: |
|
||||
用户只要感觉不要文风细则 → 不排，沿用美学。
|
||||
```
|
||||
|
||||
不要把 `task` 的执行顺序写进 `when`。配方 `process` 不要再抄一份调用条件。
|
||||
|
||||
## 4.4 `catalog.yaml` 一行
|
||||
|
||||
@@ -418,7 +438,7 @@ task 必须写：禁止重复同一开场；在首答上补洞。
|
||||
|
||||
# 第五部分：撰写任一能力时的工作步骤
|
||||
|
||||
1. **定身份**：中文名、id、artifact；写清 when / when_not / boundary。
|
||||
1. **定身份**：中文名、id、artifact；按规划视角写 when / when_not / boundary（可判定信号，不是执行细则）。
|
||||
2. **看邻接**：上/下游能力各定什么；禁止重叠问卷。
|
||||
3. **定产物形状**：先定 `output` JSON（中段须含 §4.9 公共头），再写 task/probe 如何填满它。
|
||||
4. **定 opening**：需要程序先问再 LLM → 写 opening；否则留空。
|
||||
|
||||
@@ -0,0 +1,900 @@
|
||||
# design-flow 提示词人工审查
|
||||
|
||||
规划 LLM（`design-flow`）一次请求里会拼上：**本 worker 的 SKILL 正文** + **程序注入的固定句** + **已选配方** + **全部技能 meta**。
|
||||
本文把这些静态提示词收齐，供你逐段审查。改源文件后请同步改本文，或重新生成。
|
||||
|
||||
用法：每条把 `☐ 未审查` 改成 `☑ 已审查`（可在后面加日期/一句批注）。
|
||||
不含：`design-step` 执行全文、`opening`/`task`/`output`、游玩模板、编排器 `orchestrator.md`（那是另一颗 LLM）。
|
||||
|
||||
权威路径以各节「源文件」为准。`feeds` 写在 meta 里，但 **不会** 注入 design-flow。
|
||||
|
||||
---
|
||||
|
||||
## 总表
|
||||
|
||||
| # | 条目 | 源文件 | 人工审查 |
|
||||
|---|------|--------|----------|
|
||||
| 1 | design-flow SKILL 正文 | `skills/dialogue/world-simulator/workers/design-flow/SKILL.md` | ☑ 已审查 2026-09-06：用户会在意美学卡哪几处 → 节点与 suggestion；同一题材换核换图 |
|
||||
| 2 | 上下文块标题（contextSegments.label） | `skills/dialogue/world-simulator/workers/design-flow/SKILL.md` frontmatter | ☑ 已审查 2026-09-06：【开头节点】按用户会在意的部分选节点；已验收=id 清单 |
|
||||
| 3 | 【流程进度】固定句 | `src/skills/creation-flow.ts` → `formatFlowProgressForAgent` | ☑ 已审查 2026-09-06：改成清单怎么用；禁止句改成要干嘛；与 SKILL 对齐 |
|
||||
| 4 | 【用户已选配方】外壳 | `src/skills/creation-flow.ts` → `formatSelectedRecipeForAgent` | ☑ 已审查 2026-09-06：去掉只排近期；对照美学卡承诺增删；换配方改成要干嘛 |
|
||||
| 5 | 未选配方时的三句 | （已删）`src/skills/creation-flow.ts` → `formatDesignFlowContentBlocks` | ☑ 已删除 2026-09-06：开局必选配方，不再注入问选用兜底 |
|
||||
| 6 | 【能力 · 可选工序】外壳 | `src/skills/creation-flow.ts` → `formatModuleCatalogForAgent` | ☑ 已审查 2026-09-06：只收集各节点 meta；调用条件不在外壳 |
|
||||
| 7 | 配方目录短声明 | `skills/dialogue/world-simulator/recipes/catalog.yaml` | ⏭ 跳过：人工手选列表，不进规划提示词 |
|
||||
| 8 | 配方 · 世界模拟器 | `skills/dialogue/world-simulator/recipes/world-simulator/recipe.yaml` | ☑ 已审查 2026-09-06：怎么排跟 SKILL；去掉 1～4；禁止句改成要干嘛 |
|
||||
| 9 | 配方 · 扩写助手 | `skills/dialogue/world-simulator/recipes/expand-assistant/recipe.yaml` | ⏭ 跳过 |
|
||||
| 10 | 技能 meta · 美学纲领与交互范式 | `skills/dialogue/world-simulator/modules/aesthetics-interaction/prompt.md`（meta） | ☑ 已审查 2026-09-06：声明改成体验承诺；when 去掉近期/可玩套话 |
|
||||
| 11 | 技能 meta · 实现机制 | `skills/dialogue/world-simulator/modules/mechanism/prompt.md`（meta） | ☑ 已审查 2026-09-06：第一初设定；无特殊变造才不排 |
|
||||
| 12 | 技能 meta · 舞台骨架 | `skills/dialogue/world-simulator/modules/world-blueprint/prompt.md`（meta） | ☑ 已审查 2026-09-06：会换区才备案；代入后几乎不移动（网聊/门卫室）不排 |
|
||||
| 13 | 技能 meta · 生成规则 | `skills/dialogue/world-simulator/modules/generation-rules/prompt.md`（meta） | ☑ 已审查 2026-09-06：时机 a 精准格式或时机 b 原创会雾且还要生成，满足一条就排 |
|
||||
| 14 | 技能 meta · 具体实例 | `skills/dialogue/world-simulator/modules/concrete-instances/prompt.md`（meta） | ☑ 已审查 2026-09-06：用户确认基本没问题；已有预生成规则才排，不改合同 |
|
||||
| 15 | 技能 meta · 叙事指南与故事推进 | `skills/dialogue/world-simulator/modules/narrative/prompt.md`（meta） | ☑ 已审查 2026-09-06：用户确认基本可以 |
|
||||
| 16 | 技能 meta · 拓扑图谱 | `skills/dialogue/world-simulator/modules/topology/prompt.md`（meta） | ☑ 已审查 2026-09-06：必须生成且不适合走生成规则→实例；用拓扑结构描述 |
|
||||
| 17 | 技能 meta · 变量设计与更新规则 | `skills/dialogue/world-simulator/modules/variable-design/prompt.md`（meta） | ☑ 已审查 2026-09-06：用户确认完成 |
|
||||
| 18 | 技能 meta · 变量控制上下文 | `skills/dialogue/world-simulator/modules/variable-context/prompt.md`（meta） | ☑ 已审查 2026-09-06：用户确认完成 |
|
||||
| 19 | 技能 meta · 正文组成 | `skills/dialogue/world-simulator/modules/reply-format/prompt.md`（meta） | ☑ 已审查 2026-09-06：展示回复呈现清单；选壳+美化，可写 CSS/HTML/JS |
|
||||
| 20 | 技能 meta · 回复呈现 | `skills/dialogue/world-simulator/modules/status-bar/prompt.md`（meta） | ☑ 已审查 2026-09-06：必选/可选区域 + 各区简单内容规则（含选项组成） |
|
||||
| 21 | 技能 meta · 游玩拓扑 | `skills/dialogue/world-simulator/modules/worker-spec/prompt.md`（meta） | ☑ 已审查 2026-09-07：主世界必要；有变量开旁观；取消机遇槽→随机范围整理 |
|
||||
| 22 | 技能 meta · 上下文投影排序 | `skills/dialogue/world-simulator/modules/context-order/prompt.md`（meta） | ☑ 已审查 2026-09-07：用户确认；已去机遇槽残留 |
|
||||
| 23 | 技能 meta · 细化终稿 | `skills/dialogue/world-simulator/modules/refine/prompt.md`（meta） | ☐ 未审查 |
|
||||
| 24 | 技能 meta · 开场白与开场变量 | `skills/dialogue/world-simulator/modules/opening-setup/prompt.md`（meta） | ☐ 未审查 |
|
||||
| 25 | 技能 meta · 随机范围整理 | `skills/dialogue/world-simulator/modules/random-range/prompt.md`（meta） | ☑ 已写入 2026-09-07：正文组成前汇总随机项与范围；待你过目可再改 |
|
||||
|
||||
---
|
||||
|
||||
## 一、design-flow worker
|
||||
|
||||
### 1. SKILL 全文
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：怎么排=用户会在意美学卡哪几处 → 哪些节点/suggestion 兑现；同一题材换核换图
|
||||
|
||||
源：`skills/dialogue/world-simulator/workers/design-flow/SKILL.md`
|
||||
|
||||
~~~~
|
||||
---
|
||||
id: design-flow
|
||||
skill: world-simulator
|
||||
name: 创作 · 流程编排
|
||||
description: >-
|
||||
【编排】从美学卡上用户会在意的部分推出要哪些节点、节点建议写什么；对照已完成 id。
|
||||
产出工作流计划 DAG。用户在图上点选执行顺序。本步不写各技能正文。
|
||||
version: 1
|
||||
stage: design
|
||||
inputTags:
|
||||
- "用户.需求"
|
||||
- "book.brief"
|
||||
- "用户.最新输入"
|
||||
- "用户.worker答复"
|
||||
- "用户.修订说明"
|
||||
- "设计.美学纲领与交互范式"
|
||||
- "设计.创作流程"
|
||||
- "创作.选用配方"
|
||||
- "创作.已验收单位"
|
||||
outputTags:
|
||||
- "设计.创作流程"
|
||||
inputMerge: latest
|
||||
contextSegments:
|
||||
- id: opening-aesthetics
|
||||
tier: static
|
||||
tags: ["设计.美学纲领与交互范式"]
|
||||
label: "## 【开头节点 · 美学纲领】用户会在意这张卡的哪几处？用那些承诺选节点（无则先排本步）"
|
||||
- id: accepted-units
|
||||
tier: static
|
||||
tags: ["创作.已验收单位"]
|
||||
label: "## 【已验收步骤】已完成节点的 id 清单（只作覆盖标记，不是各步正文）"
|
||||
- id: prior-flow
|
||||
tier: static
|
||||
tags: ["设计.创作流程"]
|
||||
label: "## 【已有工作流计划】在其上修订；无则新建"
|
||||
- id: selected-recipe
|
||||
tier: static
|
||||
tags: ["创作.选用配方"]
|
||||
label: "## 【用户已选配方】只读引用"
|
||||
- id: user-demand
|
||||
tier: dynamic
|
||||
tags: ["用户.需求", "book.brief", "用户.worker答复"]
|
||||
label: "## 用户表述"
|
||||
---
|
||||
|
||||
|
||||
|
||||
# 创作 · 流程编排
|
||||
|
||||
读【开头节点 · 美学纲领】里**用户会在意的部分**，推出要哪些节点、节点建议写什么；对照【已验收步骤】标记，从【能力 · 可选工序】排出一份 **工作流计划 DAG**，写入 tag `设计.创作流程`。无美学卡时用【用户要求】当种子。
|
||||
|
||||
产出：节点 + `depends_on` +（〔可反复〕）原型槽位与 `suggestion` + 可选顶层 `suggestions`。用户在图上点选下一步；你给出依赖与建议阅读序。
|
||||
|
||||
先读【流程进度】（已完成 / 草案已有 / 尚未编入）、【用户已选配方】、【能力 · 可选工序】，再排。要求按先后都有效，冲突时以较新的为准。
|
||||
|
||||
## 怎么排
|
||||
|
||||
先当用户看这张美学卡：**我会在意哪几处？** 那几处是本局要兑现的承诺。再问：兑现每一处，要哪些技能节点、节点里建议写什么？已完成 id 表示那一处已经有槽。
|
||||
|
||||
同一题材，卡上在意的东西不同，图和 suggestion 就不同。例如都是丧尸末日：
|
||||
|
||||
- 核是异能觉醒、升级、对抗（网文）→ 生成规则写异能/等级合同，变量盯等级与觉醒，叙事管打脸与对抗节奏
|
||||
- 核是人与人背刺（美式）→ 具体实例锚定开局几个人，叙事管背叛与信任，变量控制管信任度和资源缺口；舞台可以很薄
|
||||
- 核是砍砍砍（B 级片）→ 生成规则写可砍的尸群，叙事管血腥动作笔墨；等级、背刺、复杂社会可以不排，反倒是武器生成规则需要仔细斟酌
|
||||
|
||||
题材名（丧尸、都市、宫廷）本身不决定套件。用户会反复感到的那几处才决定。
|
||||
|
||||
无美学卡：体验尚未钉清，先排「美学纲领与交互范式」；其余只排此刻能从【用户要求】看出用户在意什么。美学已验收之后，按这些承诺把该排的节点写进 `steps`——需要几步排几步。
|
||||
|
||||
选定节点时对照【能力 · 可选工序】的何时用 / 何时不用 / 边界：这份承诺该由哪个技能兑现。配方 `core` / `process` / `principles` 给方法顺序（默认槽、收成链），不代替「用户在意什么」。含糊或可跳过则不排。已在草案里的 `name` 保留，一次性技能不写第二份。能力池里兑不了那处承诺：不发明新 `name`，askUser 问用户改体验还是放弃那一处。
|
||||
|
||||
用户要补节点：插在未验收步之前、收口之前，`status: "open"`。新 `name` 只从【流程进度】「尚未编入、仍可调用」里选。
|
||||
|
||||
〔可反复〕的 `suggestion` 必须点名这局在意的对象（异能合同 / 开局背刺对象 / 可砍尸群），不要写成空泛的「NPC 与物资」。本局还可能用到、但暂时不写进 `steps` 的：写入顶层 `suggestions`。已在 `steps` 里的不重复。暂时不必则省略。
|
||||
|
||||
## 节点怎么写
|
||||
|
||||
|
||||
| 类型 | JSON | 进入执行 |
|
||||
| ---- | ----------------------------------------- | ---------------------------------- |
|
||||
| 普通一步 | 无 role | 用户点上 → design-step |
|
||||
| 原型槽位 | `"role": "prototype"` + `suggestion` | 用户点上 → 程序增殖 instance → design-step |
|
||||
| 实例 | `"role": "instance"`, `"from": "<原型 id>"` | 仅程序增殖 |
|
||||
|
||||
|
||||
〔可反复〕（生成规则、具体实例等）：`steps` 里写一条原型即可（id 通常与 name 相同，如 `"生成规则"`），并写 `suggestion`（建议这条原型将来生成什么）。原型只带 `suggestion`；「写什么」在用户点原型后的实例步内钉。
|
||||
|
||||
已完成节点要改：用户在图上点该节点重进。编排只追加未验收步、改未验收依赖；已验收 id 原样留在 `steps`。
|
||||
|
||||
〔收口〕「开场白与开场变量」排在 `steps` 最后。选定开场前若要补前序节点，插在收口之前，保持收口为最后一步，`status` 仍为 `"open"`。
|
||||
|
||||
askUser 只问排布（补哪个原型、改依赖）。用户谈到体验正文：当作编排线索；体验细节留到对应技能步。排布已能写清则直接产出。
|
||||
|
||||
## 产出
|
||||
|
||||
根对象就是下面这份 JSON（必须含 `steps`）。
|
||||
|
||||
```json
|
||||
{
|
||||
"brief": "代入觉醒者，反复感到升级碾压与对抗",
|
||||
"status": "open",
|
||||
"suggestions": [
|
||||
{
|
||||
"name": "具体实例",
|
||||
"suggestion": "开局 1 个对照用的未觉醒同伴",
|
||||
"depends_on": ["生成规则"]
|
||||
}
|
||||
],
|
||||
"steps": [
|
||||
{ "id": "美学纲领与交互范式", "name": "美学纲领与交互范式", "depends_on": [] },
|
||||
{
|
||||
"id": "生成规则",
|
||||
"name": "生成规则",
|
||||
"role": "prototype",
|
||||
"suggestion": "异能觉醒与升级合同",
|
||||
"depends_on": ["美学纲领与交互范式"]
|
||||
},
|
||||
{
|
||||
"id": "变量设计与更新规则",
|
||||
"name": "变量设计与更新规则",
|
||||
"depends_on": ["美学纲领与交互范式"]
|
||||
},
|
||||
{
|
||||
"id": "叙事指南与故事推进",
|
||||
"name": "叙事指南与故事推进",
|
||||
"depends_on": ["美学纲领与交互范式"]
|
||||
},
|
||||
{
|
||||
"id": "细化终稿",
|
||||
"name": "细化终稿",
|
||||
"depends_on": ["生成规则", "变量设计与更新规则", "叙事指南与故事推进"]
|
||||
},
|
||||
{
|
||||
"id": "开场白与开场变量",
|
||||
"name": "开场白与开场变量",
|
||||
"depends_on": ["细化终稿"]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
1. `steps` 顺序 = 建议阅读顺序；`depends_on` 指向更前步骤 id
|
||||
2. `name` = 能力池固定中文名
|
||||
3. `id` 本局唯一；原型 id 稳定（如 `生成规则`）；实例 id 由程序增殖（`生成规则#1`…）
|
||||
4. 具体实例原型依赖生成规则原型（至少一条规则实例验收后才可增殖）
|
||||
5. `summary`：`流程 · N 步 · open|closed · …`
|
||||
|
||||
|
||||
|
||||
## 自检
|
||||
|
||||
- 节点和 `suggestion` 是否兑现卡上用户会在意的那几处（同一题材换核会换图），而不是题材默认套件？
|
||||
- 已验收 id 是否都在 `steps` 里？
|
||||
- 〔可反复〕是否都是 `role=prototype` + suggestion？
|
||||
- 尚未编入里本局还可能用到的〔可反复〕是否进了 `suggestions`？
|
||||
- 收口是否在最后？`depends_on` 是否合法？
|
||||
~~~~
|
||||
|
||||
### 2. 上下文块标题
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：【开头节点】按用户会在意的部分选节点；已验收=id 清单；工作流计划
|
||||
|
||||
拼进 prompt 的 Markdown 标题（frontmatter `contextSegments.label`）。后面跟黑板 tag 正文，不在此审查。
|
||||
|
||||
~~~~
|
||||
## 【开头节点 · 美学纲领】用户会在意这张卡的哪几处？用那些承诺选节点（无则先排本步）
|
||||
## 【已验收步骤】已完成节点的 id 清单（只作覆盖标记，不是各步正文）
|
||||
## 【已有工作流计划】在其上修订；无则新建
|
||||
## 【用户已选配方】只读引用
|
||||
## 用户表述
|
||||
~~~~
|
||||
|
||||
---
|
||||
|
||||
## 二、程序注入（固定句）
|
||||
|
||||
源：`src/skills/creation-flow.ts`。带 `{…}` 的是按现场填的，审查时看固定句。
|
||||
|
||||
### 3. 【流程进度】
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：清单怎么用；禁止句改成要干嘛；与 SKILL 对齐
|
||||
|
||||
~~~~
|
||||
【流程进度】程序按现场列出：已完成、草案已有、原型槽位、尚未编入。编排以这份清单为准。
|
||||
已完成 = 覆盖标记（原 id 留在 steps）；草案已有 = 保留原 id，在其上追加或改未验收依赖；尚未编入 = 新 name 只从这里选。
|
||||
〔可反复〕在 steps 里写一条 role=prototype，带 suggestion（点名这局在意的对象）。「写什么」在用户点原型后的实例步里钉。
|
||||
一次性技能已覆盖的那一面：要改则用户点该节点重进。要改已有实例：用户点该实例重进。点原型增殖 = 全新 instance（role=instance，from=原型 id）。
|
||||
|
||||
（以下段落按现场拼装，审查固定句即可）
|
||||
草案已有〔收口〕「…」但尚未选定。用户要补节点时：把新步插在收口之前，保持收口为最后一步，并将 status 改回 open。收口已排入仍可在它前面加步。
|
||||
|
||||
已完成：尚无已验收步骤。草案里的开局步是配方预置起点，保留原 id。
|
||||
已完成：
|
||||
- {name}（id: …） · 已验收|产物已在黑板 〔可反复：… / 一次性：这一面已覆盖；要改则用户点该节点重进〕
|
||||
|
||||
草案已有、尚未验收（保留原 id）：
|
||||
- {name}（id: …） · 已在草案，保留原 id
|
||||
|
||||
原型槽位（保留；用户点增殖）：
|
||||
- {name}（id: …，role=prototype） · 建议：… · 保留；用户点此槽增殖 instance
|
||||
|
||||
建议追加的原型（可编入 steps 为 role=prototype）：
|
||||
- {name} · {suggestion} · 依赖 …
|
||||
|
||||
尚未编入、仍可调用（新 name 只从这里选）：
|
||||
- {name}〔可反复〕〔收口〕：{declaration}
|
||||
尚未编入、仍可调用：无。用户只能点图上已有节点，或对〔可反复〕原型增殖。
|
||||
|
||||
目录〔可反复〕：生成规则、具体实例（排骨架时用 role=prototype）
|
||||
目录〔可反复〕：以能力目录为准。
|
||||
~~~~
|
||||
|
||||
### 4. 【用户已选配方】外壳
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：去掉只排近期；对照美学卡承诺增删；换配方改成要干嘛
|
||||
|
||||
配方 `when` / `core` / `process` / `principles` / `steps` 插在此后，见第 8、9 条。
|
||||
|
||||
~~~~
|
||||
【用户已选配方 · {name}】
|
||||
这是用户手动选定的设计方法。步骤名从【能力】选。
|
||||
对照美学卡上用户会在意的部分与配方方法论，增删改未验收步骤与依赖；已验收步保留。
|
||||
能力「何时用 / 何时不用」以【能力 · 可选工序】为准；本配方不重复罗列各能力调用条件。
|
||||
用户要换配方：等用户在界面重新选定后再编排。
|
||||
简介：…
|
||||
适用：…
|
||||
核心思路：
|
||||
…
|
||||
设计流程：
|
||||
- …
|
||||
原则：
|
||||
- …
|
||||
开局 steps（配方预置起点，可按美学卡上的承诺增删）：
|
||||
```json
|
||||
{ brief, status, steps }
|
||||
```
|
||||
~~~~
|
||||
|
||||
### 5. 未选配方
|
||||
|
||||
人工审查：☑ 已删除 2026-09-06：开局必选配方，这段不再注入。
|
||||
|
||||
（原三句「用户尚未手动选择 / 禁止自行猜测 / 请 askUser 选配方」已从 `formatDesignFlowContentBlocks` 去掉。无已选配方时只不注入第 4 条外壳，不再让规划 LLM 问选用。）
|
||||
|
||||
### 6. 【能力 · 可选工序】外壳
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：只收集各节点 meta；调用条件不在外壳。固定句暂留（标记怎么读）。
|
||||
|
||||
~~~~
|
||||
【能力 · 可选工序】
|
||||
按需选用，勿默认全选；步骤名只能从这里选；标〔可反复〕的可多次编入；标〔收口〕的是终节点：排在细化终稿之后作最后一步；尚未选定开场前，用户要补前序节点（如 NPC）时插在收口之前，勿以「收口已排入」拒绝追加；选定后才结束创作并保存；标〔程序步〕的确认编排后直接执行（不抛默认问题、不经同意并开始），产物仍验收。
|
||||
标〔先验产物〕（生成规则、具体实例）：编排层只排 role=prototype 槽位 + suggestion；禁止在原型写 params、禁止预排 instance。「写什么」在用户点原型增殖后的实例步内钉。
|
||||
其它有「编排参数」的步骤：确认开干前写齐必填 params；缺参时用 askUser 选项+其它。
|
||||
选型依据是下方「何时用 / 何时不用 / 边界」（来自各能力 meta）。对照用户表述与已验收产物判定：该排才排；可跳过或条件含糊则不排。不要用执行细则补脑。
|
||||
〔可反复〕再编入新 id = 彻底新建一条。已完成节点要改：禁止排 mode=revise 新步；用户会在图上点该节点重进。禁止把改旧稿写成又一条 fresh。
|
||||
不要把能力执行全文塞进本步；执行由 design-step 注入。
|
||||
|
||||
（下方逐条拼接各技能 declaration / when / when_not / boundary / params；全文见第三节）
|
||||
~~~~
|
||||
|
||||
---
|
||||
|
||||
## 三、配方
|
||||
|
||||
### 7. 配方目录
|
||||
|
||||
人工审查：⏭ 跳过：人工手选列表，不进规划提示词
|
||||
|
||||
源：`skills/dialogue/world-simulator/recipes/catalog.yaml`
|
||||
（用户选型列表；选定后才注入第 4 条外壳 + 对应 recipe.yaml。）
|
||||
|
||||
~~~~
|
||||
# 导演选项目录（用户在新建作品时手动选择；对用户称「导演」/「配方」）
|
||||
# id = recipes/{id}/ 文件夹
|
||||
# name = 固定中文名（下拉展示）
|
||||
# declaration = 给人看的短说明
|
||||
# 内部仍叫 recipe；勿对用户再说「配方」作第二层选项
|
||||
# recipe.yaml 写方法论：when / core / process / principles + 近期 steps
|
||||
# 步骤 name 必须 ∈ modules/catalog.yaml（【能力】）
|
||||
# 选定后写入黑板 tag 创作.选用配方
|
||||
|
||||
recipes:
|
||||
- id: world-simulator
|
||||
name: 世界模拟器
|
||||
declaration: 回合互动、世界推进、角色扮演类体验的设计方法
|
||||
|
||||
- id: expand-assistant
|
||||
name: 扩写助手
|
||||
declaration: 大纲/分段写作、写手统筹、成稿向助手类体验的设计方法
|
||||
~~~~
|
||||
|
||||
### 8. 世界模拟器
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：怎么排跟 SKILL；去掉 1～4；禁止句改成要干嘛
|
||||
|
||||
源：`skills/dialogue/world-simulator/recipes/world-simulator/recipe.yaml`
|
||||
|
||||
~~~~
|
||||
# 世界模拟器 · 配方
|
||||
# 写方法论：适用、核心思路、设计流程、原则。
|
||||
# 各技能何时用 / 不用 → 读技能 meta（编排器会注入），勿在此重复。
|
||||
# steps = 开局起点；选中本配方时程序写入「设计.创作流程」，开局即坐在第一步。
|
||||
|
||||
when: 回合互动、世界推进、角色扮演、沉浸推演类体验
|
||||
|
||||
core: >-
|
||||
先钉清用户如何参与、正文如何呈现、核心体验与禁忌（美学卡上用户会在意的部分）；
|
||||
再按那些承诺选出要兑现的上下文技能，并标明挂哪些固定槽（默认：主世界层裁决 + 叙事转述）；
|
||||
挂载归属可早定，插入顺序必须晚定——收成前用「上下文投影排序」按各块概括排出数字序与双锚点投影；
|
||||
再细化终稿收成运行规格。执行单元只用固定槽（主世界层 / 叙事转述 / 可选角色视角 / 可选机遇裁定），不为表/百科再拆槽。
|
||||
|
||||
process:
|
||||
- 开始通常先做「美学纲领与交互范式」。
|
||||
- 读美学卡上用户会在意的部分，对照【能力 · 可选工序】的何时用 / 何时不用，把兑现那些承诺所需的节点写进 steps（需要几步排几步）。各技能调用条件以 meta 为准，本表不重复。
|
||||
- 世界模拟默认槽：旁观维护 + 主世界层 + 叙事转述（视角关、机遇关）。能吃默认则不必排「游玩拓扑」。
|
||||
- 中段按承诺写上下文；每块只标挂谁（mount）与稳/变，order 留给「上下文投影排序」。挂载归属：世界/机制/生成 → 主世界层；叙事指南 → 叙事转述（推进兼挂主世界层）；美学进常驻。
|
||||
- 「回复呈现」几乎都排：先钉每轮看什么；「正文组成」在其后把清单展示出来（选壳、美化，可写 CSS/HTML/JS），开场白之前。
|
||||
- 收成链顺序固定：上游上下文大致齐 →「回复呈现」→「正文组成」→「上下文投影排序」→「细化终稿」→ 需要开场则「开场白与开场变量」（〔收口〕）。选定开场后结束创作并保存。
|
||||
|
||||
principles:
|
||||
- 正推：美学卡上用户会在意的部分 → 缺口 → 技能。同一题材换核就换图，不按题材套世界模拟全套。
|
||||
- 技能选型以技能 meta 为准；本配方不代替各技能写调用条件。
|
||||
- 执行单元只用固定槽（主世界层 / 叙事转述 / 可选角色视角 / 可选机遇裁定）。
|
||||
- 默认少槽：主世界层 + 叙事转述；仅强信息隔离才开角色视角；骰子/抽签/比点开机遇裁定（按需程序工具，不进每轮）。
|
||||
- 挂谁可早、排第几须晚：插入序与投影位只由「上下文投影排序」产出；中段技能写 mount 与稳/变。
|
||||
- 投影序扁平：「对话.历史」按 projection 动态裁剪；少变靠前、易变靠后是软规则，不是硬分区。
|
||||
- 真值 / Data / Progressive 三分；派生性格与章细纲不落可写真值。
|
||||
- 有编排参数的步骤：进执行前钉齐 params（askUser 选项+其它）；缺参时先问再进 design-step。
|
||||
- 〔可反复〕可再追加（彻底新建）；已验收 id 留在 steps。
|
||||
- 舞台骨架通常都排（备案，只分详细度）；代入后几乎不移动、只在一处待着则不排。实现机制对照其 meta。
|
||||
- 百科与查表归主世界层；裁决归主世界层、可见正文归叙事转述。
|
||||
|
||||
brief: 世界模拟类：美学卡上在意的部分→挂槽写上下文→晚排序投影→收成运行规格
|
||||
|
||||
steps:
|
||||
- id: 美学纲领与交互范式
|
||||
name: 美学纲领与交互范式
|
||||
depends_on: []
|
||||
~~~~
|
||||
|
||||
### 9. 扩写助手
|
||||
|
||||
人工审查：⏭ 跳过（本轮先不改）
|
||||
|
||||
源：`skills/dialogue/world-simulator/recipes/expand-assistant/recipe.yaml`
|
||||
|
||||
~~~~
|
||||
# 扩写助手 · 配方
|
||||
# 写方法论：适用、核心思路、设计流程、原则。
|
||||
# 各能力何时用 / 不用 → 读能力 meta（编排器会注入），勿在此重复。
|
||||
# steps = 近期起点；选中本配方时程序写入「设计.创作流程」，开局即坐在第一步（不是固定全程 DAG）。
|
||||
|
||||
when: 大纲/分段扩写、写手统筹、先纲后章、成稿向助手、长文/爽文类体验
|
||||
|
||||
core: >-
|
||||
先钉清写手/统筹站位、分段轮转、爽点与禁忌；
|
||||
再落到「谁写大纲、谁写正文」的可执行规格；
|
||||
世界舞台与状态机仅在体验真需要时才引入，默认不做世界模拟全套。
|
||||
|
||||
process:
|
||||
- 开始通常先做「美学纲领与交互范式」。
|
||||
- 对照【能力 · 可选工序】的「何时用 / 何时不用」选型；调用条件以技能 meta 为准。
|
||||
- 收成前若不能吃写手默认槽（大纲+章节），再排「游玩拓扑」勾选 →「细化终稿」并 closed。
|
||||
- 舞台、机制、变量、监控栏等：仅当对应技能「何时用」成立时再选，勿套世界模拟全套。
|
||||
|
||||
principles:
|
||||
- 正推写手体验，勿默认套「世界模拟」全套能力。
|
||||
- 能力选型以能力 meta 为准；本配方不代替各能力写调用条件。
|
||||
- 禁止自由发明执行单元；写手路径只用 outline + chapter-writer 固定槽。
|
||||
- 有编排参数的步骤须在进执行前钉齐 params；禁止空壳进 design-step。
|
||||
- 同能力可反复编入；已验收步骤不得删除。
|
||||
- 收成前 status: closed，产物进运行规格而非散文说明书。
|
||||
|
||||
brief: 扩写/写手类：先定站位与轮转，再落到大纲→分段写文规格
|
||||
|
||||
steps:
|
||||
- id: 美学纲领与交互范式
|
||||
name: 美学纲领与交互范式
|
||||
depends_on: []
|
||||
~~~~
|
||||
|
||||
---
|
||||
|
||||
## 四、技能 meta（注入【能力 · 可选工序】）
|
||||
|
||||
规划只看见 `declaration` / `when` / `when_not` / `boundary` 和 catalog 标记（〔可反复〕〔收口〕〔程序步〕〔先验产物〕）及 params。
|
||||
`feeds` 与执行块不进 design-flow。
|
||||
|
||||
### 10. 美学纲领与交互范式（`aesthetics-interaction`）
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：声明改成体验承诺；when 去掉近期/可玩套话
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/aesthetics-interaction/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 美学纲领与交互范式
|
||||
id: aesthetics-interaction
|
||||
artifact: 设计.美学纲领与交互范式
|
||||
declaration: >
|
||||
钉清用户会在意的体验承诺：站位、反复感到什么、轮转何时停。询问相近故合为一步。
|
||||
when: |
|
||||
还不能回答这三件：代入还是旁观？最想反复感到什么？轮转到哪必须停等用户？
|
||||
无上游，通常作第一步。
|
||||
when_not: |
|
||||
这三件已有等价定稿、用户未要求重谈 → 不重复排入。
|
||||
只改文风 → 「叙事指南与故事推进」；只改版式/监控 → 「正文组成」/「设计监控栏」。
|
||||
只改舞台、规则、真值、槽位 → 对应下游技能。与「给玩家什么体验」无关 → 不排。
|
||||
boundary: |
|
||||
本技能：体验是什么、怎么发生在用户身上、轮转怎么停。产出供后续编排阅读的开头节点。
|
||||
叙事指南与故事推进：把感觉落成遣词/笔墨/禁忌与推进——本步只钉感觉与轮转。
|
||||
舞台骨架 / 具体实例 / 生成规则：舞台与可执行规则——本步不定。
|
||||
实现机制 / 变量* / 监控栏 / 正文组成 / 游玩拓扑 / 上下文投影排序 / 细化终稿：落到可运行结构——本步不定。
|
||||
feeds: design_only
|
||||
~~~~
|
||||
|
||||
### 11. 实现机制（`mechanism`）
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：第一初设定；无特殊变造才不排
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/mechanism/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 实现机制
|
||||
id: mechanism
|
||||
artifact: 设计.实现机制
|
||||
declaration: >
|
||||
整体感觉已钉，故事里有必须当作既成事实的变造法则（科幻意义上的第一初设定）时：点出它们如何约束故事，不解释为何存在
|
||||
when: |
|
||||
已有「美学纲领与交互范式」或等价整体感觉，且用户表述或美学卡里有必须当作既成事实的变造法则。
|
||||
例：现代都市但已繁荣一统、存在修炼体系；三体黑暗森林；机器人三定律。
|
||||
特征：故事不必纠结它为什么存在，拿掉则故事骨架会换。
|
||||
when_not: |
|
||||
整体感觉未钉 → 先「美学纲领与交互范式」。
|
||||
没有特殊变造，或「特殊」只是身份/开场处境、能被「舞台骨架」「具体实例」「开场白与开场变量」覆盖（如现实世界模拟普通大学生）→ 不排。
|
||||
boundary: |
|
||||
本技能：点名故事当作既成事实的变造法则，写清如何约束后续；不补起源、不写舞台百科、不写人物名片。
|
||||
美学纲领与交互范式：体验与轮转——本步不重定。
|
||||
舞台骨架：环境与社会格局。具体实例 / 开场白与开场变量：名片与第一屏（身份特殊走它们）。
|
||||
生成规则 / 变量* / 叙事指南与故事推进：持续生成、跨轮真值、遣词推进——本步只钉前提法则。
|
||||
feeds: gm
|
||||
~~~~
|
||||
|
||||
### 12. 舞台骨架（`world-blueprint`）
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：会换区才备案；代入后几乎不移动（网聊/门卫室）不排
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/world-blueprint/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 舞台骨架
|
||||
id: world-blueprint
|
||||
artifact: 设计.舞台骨架
|
||||
declaration: >
|
||||
本局舞台备案：划出玩家实际游玩会换区活动的主要区域并写细；尺度与详细度随体验变。代入后几乎不移动、只在一处待着则不排
|
||||
when: |
|
||||
已有「美学纲领与交互范式」或等价整体感觉，且玩家实际游玩会在划分的活动区域上发生（会换区、会移动）。
|
||||
变造世界与现实世界都要排：只是详细度有所不同。
|
||||
玩家实际游玩过程中的主要活动区域必须写细，但如果本身世界变造不多、或特殊设定较少（如西幻就足以概括的世界），就不需要多写。
|
||||
when_not: |
|
||||
整体感觉未钉 → 先「美学纲领与交互范式」。
|
||||
代入后几乎不移动：玩家只会在一处待着体验，不会走到别的活动区域（如网聊、门卫室）→ 不排。
|
||||
可点名名片 → 「具体实例」另排。持续生成合同 → 「生成规则」。
|
||||
boundary: |
|
||||
本技能：舞台备案——范围、基底+变造、主要活动区域（写细）、社会结构、世界状况。
|
||||
美学纲领与交互范式：体验与轮转——本步不重定。
|
||||
实现机制：既成变造法则——本步把法则落到活动区域上长什么样，不重钉法则来源。
|
||||
具体实例 / 生成规则 / 叙事指南与故事推进：名片、生成节奏、遣词与推进——本步不定。
|
||||
feeds: gm
|
||||
~~~~
|
||||
|
||||
### 13. 生成规则（`generation-rules`）
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：时机 a 精准格式或时机 b 原创会雾且还要生成，满足一条就排
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/generation-rules/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 生成规则
|
||||
id: generation-rules
|
||||
artifact: 设计.生成规则
|
||||
declaration: >
|
||||
要精准格式，或本局原创听了会雾且故事里还要生成时：写出该对象族怎么生成（描写/格式/可选池）；不填最终实例；可按对象反复
|
||||
when: |
|
||||
已有「美学纲领与交互范式」或等价整体感觉，且下面两条满足一条就排（可按对象族反复）：
|
||||
a. 生成物必须有精准格式。例：武功典籍要有名字、效果、阶层。
|
||||
b. 本局原创、听了会一头雾水的东西，故事里还要随机/反复生成。例：人人能绽放的「心之彩」；当成本局原创的斩魄刀。
|
||||
when_not: |
|
||||
整体感觉未钉 → 先「美学纲领与交互范式」。
|
||||
常识能推、也不需要精准格式（现实名车、西幻常见种族）→ 不排。
|
||||
只要几张具名名片、不必按规则生成 → 不排；已有规则再要名片 → 「具体实例」。
|
||||
跨轮记住什么 → 「变量设计与更新规则」。故事怎么往前写 → 「叙事指南与故事推进」。
|
||||
boundary: |
|
||||
本技能：一条规则＝怎么描写/生成 + 单层 JSON 产物格式 + 可选多池（各绑一个顶层字段）。
|
||||
具体实例：按规则填最终 records；本步不写最终实例（池条目≠实例）。
|
||||
舞台骨架 / 实现机制：可引用，不重写百科、不重钉既成法则。
|
||||
变量*：游玩期状态更新——本步只约束生成时的类型与合法初值范围。
|
||||
旁观维护：可读合同（rule_id、产物格式、何时可 need_generate）；不依赖整份描写长文。
|
||||
feeds: gm,auditor
|
||||
~~~~
|
||||
|
||||
### 14. 具体实例（`concrete-instances`）
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：用户确认基本没问题；已有预生成规则才排，不改合同
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/concrete-instances/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 具体实例
|
||||
id: concrete-instances
|
||||
artifact: 设计.具体实例
|
||||
declaration: >
|
||||
已有预生成规则时：按该规则原样交出 records；不设计、不改合同；可按规则/批次反复
|
||||
when: |
|
||||
「设计.生成规则」里已有 `seed_only` 或 `seed_and_runtime` 的规则，且现在需要实际名片/记录（开局 NPC、种子事件等）。
|
||||
when_not: |
|
||||
尚无规则或规则不完整 → 先「生成规则」。想改格式/方法/池 → 回「生成规则」，本步不改合同。
|
||||
规则是 `runtime_only` → 不排，游玩期再生成。
|
||||
只要规则不要预写实例 → 不排。
|
||||
boundary: |
|
||||
本技能只做一件事：按指定规则生成 records。规则说怎么写、什么格式、如何用池，就照做。
|
||||
生成规则：合同制定方——本步不重论证、不修改。
|
||||
feeds: gm
|
||||
~~~~
|
||||
|
||||
### 15. 叙事指南与故事推进（`narrative`）
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：用户确认基本可以
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/narrative/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 叙事指南与故事推进
|
||||
id: narrative
|
||||
artifact: 设计.叙事指南与故事推进
|
||||
declaration: >
|
||||
美学已有方向时：把感觉落成可执行的遣词、笔墨落点、禁忌与推进方式；不重做体验问卷
|
||||
when: |
|
||||
已有美学纲领（或等价），但转述/主世界层仍会不知道这四件：遣词什么味道、笔墨落谁身上、绝对不能写什么、故事靠场面自己推还是等用户。
|
||||
用户主动谈文风、措辞禁忌、写法档（官能/爽文/恐怖/情色等）也排。
|
||||
when_not: |
|
||||
美学未钉 → 先「美学纲领与交互范式」。
|
||||
用户只要感觉/站位、不要文风细则 → 不排，沿用美学。
|
||||
版式/壳/监控栏 → 「正文组成」/「设计监控栏」。
|
||||
事件池 schema、真值增减 → 「生成规则」/「变量设计与更新规则」。
|
||||
boundary: |
|
||||
本技能：一份 context-fragment，写清怎么写 + 怎么推；不必拆技能、也不必为省 token 做精细双投影。
|
||||
美学：感觉与轮转。生成规则/变量*：合同与表。
|
||||
feeds: narrator,gm
|
||||
~~~~
|
||||
|
||||
### 16. 拓扑图谱（`topology`）
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：必须生成且不适合走生成规则→实例；用拓扑结构描述
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/topology/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 拓扑图谱
|
||||
id: topology
|
||||
artifact: 设计.拓扑图谱
|
||||
declaration: >
|
||||
有些东西必须生成，但不需要或不适合走「生成规则→具体实例」时：用拓扑结构写出来（升级路径、地图、人物关系等）
|
||||
when: |
|
||||
已有「美学纲领与交互范式」或等价整体感觉，且同时满足：
|
||||
这些东西必须生成；不需要或不适合走「生成规则→具体实例」；能用拓扑结构描述。
|
||||
很泛：升级路径、地图、人物关系等等都可以。
|
||||
when_not: |
|
||||
整体感觉未钉 → 先「美学纲领与交互范式」。
|
||||
需要精准格式，或本局原创听了会雾且还要按规则生成 → 「生成规则」；已有规则再要名片 → 「具体实例」。
|
||||
只是活动区域写细、没有拓扑可描述 → 「舞台骨架」。
|
||||
跨轮真值 → 「变量设计与更新规则」。执行单元勾选 → 「游玩拓扑」。
|
||||
没有必须生成的拓扑结构 → 不排。
|
||||
boundary: |
|
||||
本技能：用拓扑结构写出必须存在、又不走生成规则合同的内容（节点、连接、方向/层级）。
|
||||
生成规则 / 具体实例：复杂合同与 records——本步不写生成格式、不填名片表。
|
||||
舞台骨架：活动区域写细——本步不重写舞台百科。
|
||||
游玩拓扑：固定槽勾选——本步不描述执行单元谁读谁写。
|
||||
变量*：跨轮状态——本步不设计变量表。
|
||||
feeds: gm
|
||||
~~~~
|
||||
|
||||
### 17. 变量设计与更新规则（`variable-design`）
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：用户确认完成
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/variable-design/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 变量设计与更新规则
|
||||
id: variable-design
|
||||
artifact: 设计.变量设计与更新规则
|
||||
declaration: >
|
||||
体验必须跨轮记住少数状态时：钉真值、谁可写、如何变、维护语句，以及按值换文案的映射索引
|
||||
when: |
|
||||
体验需要跨轮记住少数状态，否则会糊：必须可查询、门控、防重复，或到某值换一套态度/文案/章纲。
|
||||
用户点名要好感/资源/阶段数字、分档换性格、进度门控时排。
|
||||
when_not: |
|
||||
无状态纯对话，或状态只临场描写、从不程序化 → 不排。
|
||||
只要大段设定不要门控 → 「舞台骨架」/「生成规则」。
|
||||
只规定谁的提示词看见什么 → 「变量控制上下文」。
|
||||
只规定用户看见哪些监控字段 → 「设计监控栏」。
|
||||
boundary: |
|
||||
本技能：真值清单、更新规则、维护语句约定、Data 映射索引、side_effects 草案。
|
||||
分档长文/性格切片正文：由生成规则定格式、具体实例填表；本步做索引与门控，不重写整表。
|
||||
正文组成：隐藏段定界符——本步钉「维护语句写什么」；定界样式与之对齐。
|
||||
机遇裁定 chance：真随机 toolcall，不是变量表维护手段。
|
||||
变量控制上下文：挂载对象与旁观汇总视野。
|
||||
细化终稿：收成 tables.side_effects。
|
||||
feeds: gm
|
||||
~~~~
|
||||
|
||||
### 18. 变量控制上下文（`variable-context`）
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：用户确认完成
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/variable-context/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 变量控制上下文
|
||||
id: variable-context
|
||||
artifact: 设计.变量控制上下文
|
||||
declaration: >
|
||||
已有真值或映射时：钉谁看见什么（主世界层/转述/旁观）、未解锁不注入；无信息差则可不排
|
||||
when: |
|
||||
变量设计已有真值或 Data 映射，且存在信息差：玩家不该看见但主世界层/旁观要知道，或到某档才允许提起，或旁观需要「当前档摘要」。
|
||||
when_not: |
|
||||
尚无变量且无投影 → 不排。
|
||||
仅内部记账、永不进任何提示词 → 跳过，在变量设计备注即可。
|
||||
只改字段与更新规则 → 「变量设计与更新规则」。
|
||||
真值对所有槽同样可见、无剧透边界 → 可不排。
|
||||
boundary: |
|
||||
本技能：挂载表、剧透边界、旁观汇总视野、与维护语句/投影 tag 对齐。
|
||||
变量设计：字段、映射索引、维护语句形状、side_effects。
|
||||
具体实例：表行正文——本步不重生成，只声明「旁观读当前档/哪几个摘要键」。
|
||||
设计监控栏 / 正文组成：用户可见层；本步管提示词视野。
|
||||
feeds: gm,auditor
|
||||
~~~~
|
||||
|
||||
### 19. 正文组成（`reply-format`）
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：展示回复呈现清单；选壳+美化，可写 CSS/HTML/JS
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/reply-format/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 正文组成
|
||||
id: reply-format
|
||||
artifact: 设计.正文组成
|
||||
declaration: >
|
||||
把「回复呈现」已钉的内容展示给用户：选壳、美化排版，可写 CSS/HTML/JS；排在回复呈现之后、开场白之前
|
||||
when: |
|
||||
已有「回复呈现」（或等价：每轮终稿看什么已钉）后排。几乎每局都要。
|
||||
必须在「开场白与开场变量」之前。
|
||||
when_not: |
|
||||
还不知道每轮给用户看什么 → 先「回复呈现」。
|
||||
不要排在开场白之后。几乎不跳过。
|
||||
只谈文风遣词 → 「叙事指南与故事推进」。只改呈现清单（字数/变量/日期）→ 「回复呈现」。
|
||||
boundary: |
|
||||
本技能：前端展示——从【可选呈现壳】选壳、把回复呈现的各项落到区域、美化排版（可含 CSS/HTML/JS）。
|
||||
回复呈现：看什么、正文多少字、展示哪些变量——本步不重议清单，只负责怎么显示。
|
||||
叙事指南：文风。变量设计：真值规则。开场白：第一屏——本步先定展示。
|
||||
feeds: narrator
|
||||
~~~~
|
||||
|
||||
### 20. 回复呈现（`status-bar`）
|
||||
|
||||
人工审查：☑ 已审查 2026-09-06：必选/可选区域 + 各区简单内容规则（含选项组成）
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/status-bar/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 回复呈现
|
||||
id: status-bar
|
||||
artifact: 设计.监控栏
|
||||
declaration: >
|
||||
几乎每局都要：钉每轮终稿的必选/可选区域，以及各区域的简单内容规则（字数、段落、选项怎么组成等）；不排版
|
||||
when: |
|
||||
舞台/世界/变量等上游大致齐后排。几乎每局都要。
|
||||
排在「正文组成」之前：先钉有什么区域、各区怎么写，再交给正文组成去展示。
|
||||
when_not: |
|
||||
上游还没齐 → 先那些。
|
||||
只谈怎么排版、选壳、CSS/HTML/JS → 「正文组成」。
|
||||
只谈文风遣词 → 「叙事指南与故事推进」。
|
||||
变量如何增减 → 「变量设计与更新规则」（本步只定展示哪些、展示规则）。
|
||||
boundary: >
|
||||
本技能：区域清单（必选/可选）+ 各区域简单内容规则（字数、自然段、选项槽位与提示口径等）。
|
||||
正文组成：如何把这些区域展示给用户（壳、美化、CSS/HTML/JS）——本步不定版式。
|
||||
变量设计：真值与更新——本步可点名要展示的键与监控规则，不写增减公式。
|
||||
feeds: narrator
|
||||
~~~~
|
||||
|
||||
### 21. 游玩拓扑（`worker-spec`）
|
||||
|
||||
人工审查：☑ 已审查 2026-09-07：主世界必要；有变量开旁观；取消机遇槽→随机范围整理
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/worker-spec/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 游玩拓扑
|
||||
id: worker-spec
|
||||
artifact: 设计.worker规格
|
||||
declaration: >
|
||||
不能吃默认槽时才勾选：主世界层必开；有变量/表维护才开旁观；转述默认开；强秘密才开视角；写手则大纲+章节；禁止发明执行单元与机遇槽
|
||||
when: |
|
||||
体验契约已大致清楚，且不能吃默认槽：要关旁观、关转述、开角色视角（强秘密不能进主世界层），或走写手大纲+章节。
|
||||
或要修订已勾选槽（开/关 auditor、perspective、narrator 等）。
|
||||
when_not: |
|
||||
体验/站位仍混沌 → 先「美学纲领与交互范式」。
|
||||
世界模拟可吃默认（主世界层+转述+旁观；视角关）→ 可不排，「细化终稿」按默认收成。
|
||||
只需输出完整运行规格 → 「细化终稿」（本步只交槽位勾选）。
|
||||
检定/掷骰范围汇总 → 「随机范围整理」；不要为本步加「机遇裁定」槽。
|
||||
不要用本步发明世界观/性格/变量专用执行单元。
|
||||
boundary: |
|
||||
本能力：输出 play_slots（及写手路径的 writing_slots），可选覆盖挂载说明；不写完整 设计.worker集。
|
||||
主世界层（gm）几乎总要。旁观维护：有变量/表/规则要程序化盯时才开。转述默认开。
|
||||
不再设机遇裁定（chance）槽：真随机走「随机范围整理」+ 程序插入上下文备用数。
|
||||
细化终稿：按本步勾选展开 workers、合并常驻与 tables。
|
||||
变量设计 / 变量控制上下文：真值与投影，不是推理槽。
|
||||
叙事指南与故事推进：挂到转述槽（推进可兼挂主世界层）；世界/机制：挂到主世界层——本步只点名槽。
|
||||
~~~~
|
||||
|
||||
### 21b. 随机范围整理（`random-range`）
|
||||
|
||||
人工审查：☑ 已写入 2026-09-07：正文组成前汇总；待你过目可再改
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/random-range/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 随机范围整理
|
||||
id: random-range
|
||||
artifact: 设计.随机范围整理
|
||||
declaration: >
|
||||
上游已有检定/对抗/掷骰需求时：汇总全部要用的随机项与取值范围（含表达式），供程序每轮插入备用随机数；排在正文组成之前
|
||||
when: |
|
||||
机制/生成规则/变量/叙事等上游已出现需要随机数的内容（对抗、检定、抽签、伤害区间等），且尚未收成一份范围表。
|
||||
排在「正文组成」之前（通常紧挨其前；回复呈现可并行或略前）。
|
||||
when_not: |
|
||||
全程不靠随机数推进 → 不排。
|
||||
还在定「怎么裁定 / 公式本身」→ 先「实现机制」「生成规则」或「变量设计与更新规则」；本步只汇总已定需求。
|
||||
只谈前端怎么藏、选壳美化 → 「正文组成」。
|
||||
只谈每轮可见区域与字数 → 「回复呈现」。
|
||||
boundary: |
|
||||
本技能：一份清单——每项随机用途、范围或表达式（如力量*5～*10、敏捷检定 1～100）、本轮建议备用条数。
|
||||
不写新裁定法则、不写骰子剧情；法则来自上游，此处只整理成程序可读范围。
|
||||
游玩拓扑：不再开「机遇裁定」槽；真随机靠本表 + 程序插入上下文。
|
||||
正文组成：负责把隐藏备用区接到壳/消息里——本步只交「要插什么数」。
|
||||
feeds: gm,narrator
|
||||
~~~~
|
||||
|
||||
### 22. 上下文投影排序（`context-order`）
|
||||
|
||||
人工审查：☑ 已审查 2026-09-07：用户确认；已去机遇槽残留
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/context-order/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 上下文投影排序
|
||||
id: context-order
|
||||
artifact: 设计.上下文投影排序
|
||||
declaration: >
|
||||
收成前给已启用槽排扁平投影序（含对话.历史）；不发明槽、不重写长文、不演情节选择题
|
||||
when: |
|
||||
游玩槽已确认（或可按默认），且主要上下文块已有可摘要产物，需要决定各执行单元看见什么、以何顺序插入。
|
||||
本步为〔程序步〕：上下文已多、即将收成时排入。
|
||||
when_not: |
|
||||
体验/站位仍混沌 → 先「美学纲领与交互范式」。
|
||||
槽位未定且用户拒绝默认 → 先「游玩拓扑」。
|
||||
上游上下文仍大量空洞、无法判断稳/变 → 先补缺口，勿空排。
|
||||
只需勾选槽 → 「游玩拓扑」；上下文很少、只需合并终稿 → 「细化终稿」可按默认序退化。
|
||||
boundary: |
|
||||
本技能：抄名册 → 凭各块 brief/挂载/稳变 给每槽 inserts[]。
|
||||
名册权威在程序（及已勾选的游玩拓扑）；本步不增白名单外 id。
|
||||
中段技能可带 mount 与稳/变；最终 order 以本步为准。
|
||||
细化终稿：把本步排序表收进运行规格 context_order；本步不输出完整 设计.worker集。
|
||||
禁止把依赖产物里的游玩示例（迎上去/推开/反客为主 等）当成当前要问的题。
|
||||
feeds: design_only
|
||||
~~~~
|
||||
|
||||
### 23. 细化终稿（`refine`）
|
||||
|
||||
人工审查：☐ 未审查
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/refine/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 细化终稿
|
||||
id: refine
|
||||
artifact: 设计.worker集
|
||||
declaration: >
|
||||
按已勾选槽（或默认槽）与投影排序表收成运行规格；不发明新执行单元
|
||||
when: |
|
||||
至少体验契约可引用；槽已勾选或可按默认；若上下文块已多则宜先有投影排序表。
|
||||
需要输出「设计.worker集」才能进游玩时排；编排应将流程导向 closed。
|
||||
when_not: |
|
||||
体验站位未定 → 先「美学纲领与交互范式」。
|
||||
不能吃默认槽且尚未勾选 → 先「游玩拓扑」。
|
||||
上下文块已多且稳/变未排序 → 先「上下文投影排序」。
|
||||
只要改某一块设定长文 → 回头修改对应上游节点，不要用本步重写。
|
||||
boundary: |
|
||||
本能力：合并上游 → 完整运行规格 JSON（interaction、play_slots、context_order/inserts、
|
||||
workers 由槽展开、resident_context、tables）。
|
||||
游玩拓扑：槽位权威；上下文投影排序：插入序与投影位权威；本步不新增白名单外的 ref。
|
||||
变量设计：side_effects / 真值吸入 tables；不创建 variable-update 执行单元。
|
||||
进 play 由用户手动决定。
|
||||
~~~~
|
||||
|
||||
### 24. 开场白与开场变量（`opening-setup`）
|
||||
|
||||
人工审查：☐ 未审查
|
||||
|
||||
源：`skills/dialogue/world-simulator/modules/opening-setup/prompt.md`
|
||||
|
||||
~~~~
|
||||
name: 开场白与开场变量
|
||||
id: opening-setup
|
||||
artifact: 设计.开场白与开场变量
|
||||
declaration: >
|
||||
创作终节点：写出 1～多条开场白并钉同真相初值；选定后落库、结束创作并保存定稿
|
||||
when: |
|
||||
收成链已齐（至少体验契约可引用，且「细化终稿」已产出或可立即收成运行规格），需要可开玩的第一段剧情与同真相初值。
|
||||
排在收成之后作最后一步。用户要进游玩但还没有第一屏 → 排。
|
||||
when_not: |
|
||||
体验/呈现仍混沌 → 先「美学纲领与交互范式」与「正文组成」等。
|
||||
只要改文风不要开场 → 「叙事指南与故事推进」。
|
||||
只要改真值规则不要开场文 → 「变量设计与更新规则」。
|
||||
运行规格未齐 → 先「细化终稿」。尚未选定开场前若要补前序节点（如 NPC）→ 插在本步之前，勿以「收口已排入」拒绝追加。
|
||||
boundary: |
|
||||
本技能是创作终节点：1～多条开场正文（按正文组成块序）+ 开场变量初值 + 可选监控栏初值示意。
|
||||
必须遵守已验收的叙事指南、正文组成、监控栏、变量设计；不重做这些契约。
|
||||
具体实例：开场可引用已有实例名片，不在本步新造百科。
|
||||
选定后由程序写入 输出.开场白 / 运行.初始变量 / 变量.当前，关闭 DAG 并保存定稿；不要在本步之后再排其它能力。
|
||||
feeds: narrator
|
||||
~~~~
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 不在本文
|
||||
|
||||
| 提示词 | 原因 |
|
||||
|--------|------|
|
||||
| `skills/dialogue/world-simulator/workers/design-step/SKILL.md` 与各技能 `task`/`opening`/`output` | 执行 LLM，规划看不见 |
|
||||
| `skills/dialogue/world-simulator/workers/opening-generator/SKILL.md` | 创作末尾兜底，不是 design-flow |
|
||||
| `skills/dialogue/world-simulator/orchestrator.md` / `uiPrompt` | 总管 LLM |
|
||||
| `skills/dialogue/world-simulator/worker-templates/*.yaml` `prompt_excerpt` | 游玩人设 |
|
||||
|
||||
执行全文审查可另开文档；选型口径见 `docs/briefs/prompt-revision-inventory.md`。
|
||||
@@ -1,57 +1,52 @@
|
||||
# 提示词 / 能力文档修订清单（待你改）
|
||||
# 提示词修订清单
|
||||
|
||||
> 程序侧已落地：`play_slots`、`settlement.v1`、模板默认契约、前端友好渲染雏形。
|
||||
> **本清单只整理「可能需要你改的提示词/能力文」——此处不改正文，等你确认后再动。**
|
||||
|
||||
权威方法：`docs/progressive-data-design.md`、`docs/ui-glossary.md` §5.1。
|
||||
> 规划 LLM **不**靠加长 `design-flow` SKILL 学会选型。
|
||||
> 选型权威在各技能 `prompt.md` 的 **`meta.when` / `when_not` / `boundary` / `declaration`**。
|
||||
> 写法：`docs/world-simulator-modules.md`（写给规划，不是写给执行）、`docs/briefs/capability-authoring-brief.md` §4.3。
|
||||
> **人工审查工作簿（含 SKILL / 注入固定句 / 配方 / 全部 meta 全文）**：**`docs/briefs/design-flow-prompt-review.md`**。
|
||||
|
||||
---
|
||||
|
||||
## 优先级 P0（与固定槽 + 裁决包强相关）
|
||||
## 已改（规划选型）
|
||||
|
||||
| 文件 | 状态 |
|
||||
全部 15 个技能的 `meta` 已按「对照用户话 + 已有产物就能判定」重写；`catalog.yaml` 声明已对齐；两份配方 `process` 不再抄各技能调用条件。
|
||||
|
||||
规划注入见 `formatModuleCatalogForAgent`：含糊或可跳过则不排。
|
||||
|
||||
| 技能 | 选型要点 |
|
||||
|------|----------|
|
||||
| 美学纲领与交互范式 | 三件还不能回答才排；已定稿不重复；产出供后续编排读的开头节点 |
|
||||
| 实现机制 | 整体感觉已钉且有既成变造法则才排；无特殊设定或仅身份/开场可覆盖则不排 |
|
||||
| 舞台骨架 | 会换区才备案；代入后几乎不移动、只在一处待着（网聊/门卫室）不排 |
|
||||
| 生成规则 | 时机 a 精准格式或时机 b 原创会雾且还要生成，满足一条就排 |
|
||||
| 具体实例 | 已有 seed 类规则才排；`runtime_only` 不排；本步不改合同（已审查，基本不动） |
|
||||
| 叙事指南与故事推进 | 转述仍不知遣词/禁忌/推进才排；默认：长自然段；用户输入＝大纲扩写不越界 |
|
||||
| 拓扑图谱 | 必须生成且不适合走生成规则→实例；用拓扑结构描述（升级路径、地图、人物关系等） |
|
||||
| 变量设计与更新规则 | 必须跨轮记住否则会糊才排（已审查，用户确认完成） |
|
||||
| 变量控制上下文 | 有信息差才排；全员同可见则可不排（已审查，用户确认完成） |
|
||||
| 回复呈现 | 几乎都排；必选/可选区域 + 规则；正文默认 1000～2000 字、长自然段 |
|
||||
| 随机范围整理 | 有检定/对抗/掷骰才排；正文组成前汇总范围/表达式；替代机遇槽 |
|
||||
| 正文组成 | 把回复呈现清单展示出来；选壳+美化；可接隐藏备用随机区；开场白之前 |
|
||||
| 游玩拓扑 | **不能吃默认槽**才排；主世界必要；有变量开旁观；禁机遇槽 |
|
||||
| 上下文投影排序 | 上下文已多、即将收成时排（程序步）；名册无机遇；随机范围挂 gm |
|
||||
| 细化终稿 | 要输出运行规格才排 |
|
||||
| 开场白与开场变量 | 收成后、需要第一屏才排（收口） |
|
||||
|
||||
---
|
||||
|
||||
## 尚未细调（执行全文）
|
||||
|
||||
`task` / `opening` / `probe` / `output` 仍是初稿。规划看不见这些；要改产物质量再逐份动。
|
||||
|
||||
| 文件 | 备注 |
|
||||
|------|------|
|
||||
| `modules/worker-spec/prompt.md` | **已改** → 游玩拓扑，只勾选固定槽 |
|
||||
| `modules/refine/prompt.md` | **已改** → 按 `play_slots` 收成，禁发明 ref |
|
||||
| `modules/catalog.yaml` / 配方 / `design-flow` | **已改**（配方含：挂谁可早、排第几须晚） |
|
||||
| `modules/context-order/prompt.md` | **骨架已写**（`context-order.v1`） |
|
||||
| `docs/context-fragment-design.md` | **已写**；范例技能已对齐 `context-fragment.v1` |
|
||||
| 程序：片段解析 / 扁平投影序 / `对话.历史` 可投影 | **已落地**（非硬双锚） |
|
||||
| `orchestrator.md` | **已改**：play 调度 gm → perspective? → narrator → auditor |
|
||||
| 其余 `modules/*/prompt.md` 执行块 | 结构齐，未逐句打磨 |
|
||||
| `workers/design-flow/SKILL.md` | 怎么排（美学正文 + 已完成 id → 缺口）+ DAG 写法；**不要**把各技能调用条件搬进来 |
|
||||
| `worker-templates/*.yaml` `prompt_excerpt` | 游玩人设，与创作选型无关 |
|
||||
|
||||
## 优先级 P1（能力归属 feeds）
|
||||
---
|
||||
|
||||
| 文件 | 建议补什么 |
|
||||
|------|------------|
|
||||
| `modules/*/prompt.md` 的 `meta` | 统一加 `feeds: gm \| narrator \| runtime \| design_only \| perspective`（约定字段，程序以后可读） |
|
||||
| `aesthetics-interaction` | `feeds: design_only`（再压缩进常驻）；呈现要点可摘要给 narrator |
|
||||
| `mechanism` | **已改** output→`context-fragment.v1`；`feeds: gm` |
|
||||
| `world-blueprint` | **已改**→「舞台骨架」+ `context-fragment.v1`；`feeds: gm` |
|
||||
| `generation-rules` / `concrete-instances` | **已改** fragment；生成规则 **mount/feeds 含 auditor（合同级）** |
|
||||
| `narrative` | **已改**：一步两块（风格与写法｜推进与决策）+ 双挂；专用 mosaic |
|
||||
| `variable-design` | **已写** |
|
||||
| `variable-context` | **已改**：mount 含 auditor + 旁观汇总 |
|
||||
| `reply-format` / `status-bar` | 已有正文；见 artifact-card-coverage |
|
||||
| `topology` | 骨架；等你定「小循环」选项后再写 |
|
||||
| `worker-templates/*.yaml` | gm/narrator/auditor 已齐 |
|
||||
|
||||
## 优先级 P2（文档口径）
|
||||
|
||||
| 文件 | 建议 |
|
||||
|------|------|
|
||||
| `docs/design-orchestrator-guide.md` | § 三大步 / Worker 创造：改为固定槽 + 创作上下文映射；保留表副作用 |
|
||||
| `docs/world-simulator-modules.md` | 清单状态：worker-spec→拓扑；链到本清单 |
|
||||
| `docs/tag-blackboard.md` | 强调 `运行.本轮.裁决` = settlement.v1；转述少读 `变量.当前` |
|
||||
| `docs/skill-design-guide.md` | 若仍教「创造 worker」，加世界模拟例外 |
|
||||
| `ui-glossary.md` | §5.1 已有主世界层；可补「游玩槽位」用户可见词（可选） |
|
||||
|
||||
## 明确不必改成「第三 Worker」的
|
||||
|
||||
- **变量管理**：保持 `variable-design` / `variable-context` + Runtime `side_effects`，不要新 `variable-update` 必选槽。
|
||||
- **世界观**：常驻挂 GM，不要世界观执行单元。
|
||||
- **性格分档**：Data + Progressive tag，不要性格 agent。
|
||||
|
||||
## 程序已做、提示词需跟上的契约
|
||||
## 程序契约（提示词需继续遵守）
|
||||
|
||||
```json
|
||||
// 设计.worker集（世界模拟）
|
||||
@@ -62,35 +57,4 @@
|
||||
}
|
||||
```
|
||||
|
||||
```json
|
||||
// 运行.本轮.裁决
|
||||
{
|
||||
"schema": "settlement.v1",
|
||||
"player_action": "…",
|
||||
"resolved": ["…"],
|
||||
"visible_now": "…",
|
||||
"npc_moves": [{ "who": "…", "move": "…" }],
|
||||
"variable_changes": [{ "key": "好感", "delta": 8 }],
|
||||
"do_not_say": ["好感数字"],
|
||||
"tone_hint": "…"
|
||||
}
|
||||
```
|
||||
|
||||
```json
|
||||
// 运行.本轮.旁观（多数轮空）
|
||||
{
|
||||
"schema": "maintain.v1",
|
||||
"need_generate": false,
|
||||
"table_ops": [],
|
||||
"notes": []
|
||||
}
|
||||
```
|
||||
|
||||
## 建议你改的顺序
|
||||
|
||||
1. `refine` + `worker-spec`（或新拓扑技能）对齐 `play_slots`
|
||||
2. `world-simulator` 配方 + `orchestrator` 调度顺序
|
||||
3. 各能力 meta 补 `feeds`
|
||||
4. 骨架能力（status-bar / reply-format / topology）按需细写或降级
|
||||
|
||||
改完后告诉我，我可以按你的口径改提示词并加解析 `feeds`（若要程序注入）。
|
||||
明确不必改成「第三 Worker」的：变量管理、世界观、性格分档——见旧口径，仍有效。
|
||||
|
||||
@@ -61,8 +61,8 @@
|
||||
生成规则正文：必要性判断 + `rules[]`（生成与描写 + **单层**产物格式 + 可选多池绑顶层字段 + **数量**与**一次生成**（单条|同批，同批须钉记录间关系））；自评＝必要性/属性妥当/格式准确。
|
||||
美学纲领自评仍为：交互范式 / 美学纲领 / 整体协调（勿与生成规则三维混用）。
|
||||
叙事指南与故事推进正文：一份全文（纲领/遣词/笔墨/禁忌/推进等）；**整份**双挂转述与主世界层，不为省 token 拆两套投影。artifact=`设计.叙事指南与故事推进`。
|
||||
正文组成：**基于固定呈现壳适配微调**（选 `shell_id` + 微调轴；块只挂壳已有区域）；正文含 **`示例`**（`present.v1` 灌数，验收壳与美化；非正史，文笔不重要）；artifact=`设计.正文组成`。见 `docs/play-presentation-shells.md`。
|
||||
设计监控栏：只监控会变字段（可含攻略目标/场景交互物）；artifact=`设计.监控栏`（旧称状态栏）。
|
||||
回复呈现：每轮终稿给用户看什么（正文/字数/日期/变量）；artifact=`设计.监控栏`（旧称设计监控栏/状态栏）。
|
||||
正文组成：把回复呈现清单展示给用户（选壳、美化，可写 CSS/HTML/JS）；artifact=`设计.正文组成`。见 `docs/play-presentation-shells.md`。
|
||||
变量设计：真值 + **维护语句** + **Data映射索引**（指向具体实例）+ side_effects。
|
||||
变量控制上下文：各槽视野 + **旁观汇总**；mount 含主世界层与旁观维护。
|
||||
生成规则：合同挂主世界层 + 旁观（旁观读 rule_id/格式/必要性，描写长文可 summary）。
|
||||
|
||||
+11
-327
@@ -5,7 +5,7 @@
|
||||
```text
|
||||
1. 先读文档，再写对应文件。
|
||||
2. 一次只写一个文件（或一组强绑定的 types + 实现）。
|
||||
3. 每写完一个文件，对照本文档的「文件职责」自检。
|
||||
3. 每写完一个文件，对照对应规格文档自检。
|
||||
4. 文件行为与文档冲突时，先改文档，再改代码。
|
||||
5. 不要跳步实现：下游文件不能先于上游文件。
|
||||
```
|
||||
@@ -28,21 +28,29 @@
|
||||
| UI | `ui-design.md` | 工作台布局、检查器、composer |
|
||||
| UI | **`ui-glossary.md`** | 用户可见中文口径；禁止裸露内部 id |
|
||||
| 外部参考 | `references.md` | 按层借鉴的 GitHub 仓库 |
|
||||
| 本文件 | `implementation-guide.md` | 文件顺序与职责；在现有内核上补齐 |
|
||||
| 本文件 | `implementation-guide.md` | 写代码规则与文档地图 |
|
||||
| **产品体验路线** | **`px-roadmap.md`** | PX0–PX5 交付、DoD、明确不做 |
|
||||
| **日常 → P0** | **`daily-use-p0.md`** | 日常场景、功能映射、P0 详细工作包 |
|
||||
| **剧本 / 方法（非系统架构）** | `design-orchestrator-guide.md` | 创作三大步、表/副作用、自检 |
|
||||
| **剧本 / 方法（非系统架构）** | `creation-playbook.md` | 创作流程概念（指向指导） |
|
||||
| **剧本 / 方法（非系统架构）** | `world-simulator-modules.md` | 编排器/能力清单与现行包布局 |
|
||||
| **剧本 / 方法（非系统架构）** | `progressive-data-design.md` | 真值 / Data / Progressive |
|
||||
| **剧本 / 方法（非系统架构）** | `context-fragment-design.md` | 上下文片段、固定槽、投影排序 |
|
||||
| **剧本 / 方法（非系统架构）** | `play-presentation-shells.md` | 游玩呈现壳 |
|
||||
| **剧本 / 方法（非系统架构）** | `play-dm-auditor.md` | 主世界层与旁观维护 |
|
||||
| **Skill 格式（非系统架构）** | `orchestrator-skill-format.md` | manifest 写法（非编排表） |
|
||||
| **Skill 格式（非系统架构）** | `worker-skill-format.md` | SKILL.md、contextSegments |
|
||||
| **Skill 格式（非系统架构）** | `skill-format.md` | 包存储、registry（示例以 world-simulator 为准） |
|
||||
| **Skill 格式（非系统架构）** | `skill-format.md` | 包存储、registry |
|
||||
| **Skill 格式（非系统架构）** | `skill-design-guide.md` | 包格式薄层 |
|
||||
| **Skill 格式（非系统架构）** | `preset-format.md` | 预设导入 |
|
||||
| **能力撰写** | `briefs/capability-authoring-brief.md` | 外部 AI 写 modules 交接 |
|
||||
|
||||
许可证占位：仓库根 `THIRD_PARTY_NOTICES.md`。
|
||||
|
||||
工作簿（非规格）：`briefs/prompt-revision-inventory.md`、`briefs/design-flow-prompt-review.md`、`briefs/artifact-card-coverage.md`。
|
||||
|
||||
现行唯一落地包：`skills/dialogue/world-simulator/`（见该包 README）。
|
||||
|
||||
---
|
||||
|
||||
## 3. 在现有内核上补齐（当前优先）
|
||||
@@ -61,327 +69,3 @@
|
||||
| PX4 | 长文加深（P0 已含最小闭环） | — |
|
||||
| PX5 | 隔离 + 调试；必要时新配方包 | — |
|
||||
| 延后 | SQLite / 事件溯源 / Mastra·Next | — |
|
||||
|
||||
历史分期 A0–E 见下节（**多数已 done，仅作文件职责索引**；进度与验收以 [`px-roadmap.md`](./px-roadmap.md) 为准，勿再按 §9「未开始」判断现状）。
|
||||
|
||||
> §3b / §9 中仍可能出现 `design-intake`、`skills/novel/`、缺失文件路径等**历史表述**；磁盘真相见 `skills/dialogue/world-simulator/README.md`。
|
||||
|
||||
---
|
||||
|
||||
## 3b. 历史实现分期（索引）
|
||||
|
||||
### Phase A0 — 可运行阶段机
|
||||
|
||||
目标：**不依赖 LLM**，阶段机整体可运行、可手动驱动、可脚本跑通最小闭环。
|
||||
|
||||
| # | 文件 | 状态 | 干嘛的 |
|
||||
|---|---|---|---|
|
||||
| A06 | `src/types/runtime.ts` | done | 5 相位、事件、会话类型 |
|
||||
| A09 | `src/runtime/phase-machine.ts` | done | 纯函数：`applyEvent`，不调 LLM |
|
||||
| A20 | `src/runtime/phase-runtime.ts` | done | 运行层：处理 effects，stub worker |
|
||||
| A21 | `src/cli/phase-demo.ts` | done | 交互式演示 CLI，手动发事件 |
|
||||
| A22 | `tests/phase-runtime.test.ts` | done | 闭环 + worker 中途提问测试 |
|
||||
|
||||
**运行方式：**
|
||||
```bash
|
||||
npm run phase-script # 非交互，自动跑最小闭环
|
||||
npm run phase-demo # 交互，手动 /decide /approve /worker-ask
|
||||
npm run phase-demo -- --auto # worker 自动占位完成
|
||||
```
|
||||
|
||||
### Phase A1 — 编排器 LLM 接入（阶段机之上）
|
||||
|
||||
目标：在 PhaseRuntime 之上接 Main Agent，不改动 phase-machine 规则。
|
||||
|
||||
| # | 文件 | 状态 | 干嘛的 |
|
||||
|---|---|---|---|
|
||||
| A11–A19 | blackboard、llm、main-agent、orchestrator、run.ts | done | 带 Mock/真实 LLM 的完整栈 |
|
||||
| A15 | `src/main-agent/prompts.ts` | todo | prompt 拆分 |
|
||||
|
||||
### Phase A2 — Skill 层（创作指南）
|
||||
|
||||
目标：`skills/` 批量存储 SKILL.md；启动第一个询问是选 skill；编排器读 activeSkill。
|
||||
|
||||
| # | 文件 | 状态 | 干嘛的 |
|
||||
|---|---|---|---|
|
||||
| S00 | `skills/registry.yaml` | done | skill 索引 |
|
||||
| S01 | `skills/novel-standard/SKILL.md` | done | 小说指南（含启动询问） |
|
||||
| S02 | `skills/theater-roleplay/SKILL.md` | done | 剧场指南（含启动询问） |
|
||||
| S03 | `src/skills/types.ts` | todo | ParsedSkill、SkillIndexEntry |
|
||||
| S04 | `src/skills/loader.ts` | todo | 解析 SKILL.md |
|
||||
| S05 | `src/skills/registry.ts` | todo | listSkills() |
|
||||
| S06 | `src/skills/resolver.ts` | todo | 推断当前 stage |
|
||||
| S07 | `src/main-agent/skill-context.ts` | todo | 注入编排器 prompt |
|
||||
| S08 | `src/runtime/phase-machine.ts` | todo | 增加 skill_selection / skill_selected |
|
||||
| S09 | `src/cli/phase-demo.ts` | todo | 启动时 /select-skill |
|
||||
|
||||
详见 `docs/skill-format.md` §5。
|
||||
|
||||
### Phase B — Tool Call 化
|
||||
|
||||
目标：编排器 / worker 从 JSON 决策改为 tool call；Runtime 做 tool 校验与事件转换。
|
||||
|
||||
### Phase C — 真实 Worker
|
||||
|
||||
目标：outline / drafting 等固定 worker 接真实 LLM；worker 可中途 ask_user。
|
||||
|
||||
### Phase D — 持久化
|
||||
|
||||
目标：book 存储；preset 导入。
|
||||
|
||||
### Phase E — 标签黑板迁移（当前文档已完成，代码待做）
|
||||
|
||||
目标：代码与 `tag-blackboard.md` 对齐。
|
||||
|
||||
| # | 文件 | 状态 | 干嘛的 |
|
||||
|---|---|---|---|
|
||||
| E01 | `src/types/blackboard.ts` | done | `BlackboardItem`、按 tag 查询 |
|
||||
| E02 | `src/blackboard/blackboard.ts` | done | listTagIndex、前缀匹配 |
|
||||
| E03 | `src/skills/types.ts` + `loader.ts` | done | 解析 inputTags / outputTags（兼容 outputKeys） |
|
||||
| E04 | `src/worker/executor.ts` | done | 按 tag 取 context，校验 outputTags |
|
||||
| E05 | `src/types/runtime.ts` + `main-agent.ts` + `phase-runtime` | done | 决策去掉 keys；runtime 按 Worker Skill 执行 |
|
||||
| E06 | `skills/novel/weird-rules-short/` | todo | tag 化 skill 样板 + inputTags frontmatter |
|
||||
| E07 | `skills/novel/quick-write/` | todo | 简易全量 LLM skill |
|
||||
|
||||
编排写在各包 `orchestrator.md`，不单独维护 execution-flow YAML。
|
||||
|
||||
---
|
||||
|
||||
## 4. Phase A 文件顺序
|
||||
|
||||
按序号逐个实现。状态列：`done` = 已有初版，`todo` = 未写或未按文档对齐。
|
||||
|
||||
### 4.1 项目配置
|
||||
|
||||
| # | 文件 | 状态 | 干嘛的 |
|
||||
|---|---|---|---|
|
||||
| A01 | `package.json` | done | 项目元数据、npm scripts（dev / test / demo） |
|
||||
| A02 | `tsconfig.json` | done | TypeScript 编译选项 |
|
||||
| A03 | `vitest.config.ts` | done | 测试入口配置 |
|
||||
| A04 | `.env.example` | done | LLM API 环境变量模板，不含真实 key |
|
||||
| A05 | `.gitignore` | done | 忽略 node_modules、dist、.env |
|
||||
|
||||
**A01 职责：** 声明依赖（typescript、tsx、vitest）和三条命令。不含业务逻辑。
|
||||
|
||||
---
|
||||
|
||||
### 4.2 类型层（只放数据结构，不含逻辑）
|
||||
|
||||
| # | 文件 | 状态 | 干嘛的 | 对应文档 |
|
||||
|---|---|---|---|---|
|
||||
| A06 | `src/types/runtime.ts` | done | 相位、事件、会话、产物、ResumeContext | `runtime-state-machine.md` §2–5 |
|
||||
| A07 | `src/types/blackboard.ts` | done | BlackboardItem、TagIndex | `tag-blackboard.md` §2 |
|
||||
| A08 | `src/types/tools.ts` | todo | 编排器 tool、worker tool 的参数与结果类型 | `tool-contracts.md` |
|
||||
|
||||
**A06 职责：**
|
||||
- 定义 `RuntimePhase`（5 种）
|
||||
- 定义 `WaitingReason`（waiting_user 的子原因）
|
||||
- 定义 `RuntimeEvent`（唯一改变相位的输入）
|
||||
- 定义 `RuntimeSession`（运行时快照）
|
||||
- 定义 `PhaseEffect`（阶段机产生的副作用，如 invoke_main_agent）
|
||||
|
||||
**A07 职责（Phase E 迁移后）：**
|
||||
- 定义 `BlackboardItem`（id、tag、content、source、metadata）
|
||||
- 定义 `BlackboardTagIndex`（给编排器：tag + source，无 content）
|
||||
- 定义 `BlackboardWrite`（worker 写回）
|
||||
|
||||
**A08 职责（Phase B 再写）：**
|
||||
- `MainAgentToolName`、`WorkerToolName`
|
||||
- 每个 tool 的 params / result 类型
|
||||
- tool → event 映射表（类型级注释）
|
||||
|
||||
---
|
||||
|
||||
### 4.3 阶段机（纯函数，不调用 LLM）
|
||||
|
||||
| # | 文件 | 状态 | 干嘛的 | 对应文档 |
|
||||
|---|---|---|---|---|
|
||||
| A09 | `src/runtime/phase-machine.ts` | done | 5 相位阶段机：`applyEvent`、`canApplyEvent` | `runtime-state-machine.md` §6–8 |
|
||||
| A10 | `src/runtime/state-machine.ts` | done | 废弃别名，re-export phase-machine | — |
|
||||
|
||||
**A09 职责：**
|
||||
- `createSession()` — 创建 idle 会话
|
||||
- `getAllowedEvents()` — 当前相位允许哪些事件
|
||||
- `canApplyEvent()` — 事件是否合法（含 waitingReason 校验）
|
||||
- `applyEvent()` — 纯函数：session + event → 新 session + effects
|
||||
- `createArtifact()` — 创建产物记录
|
||||
|
||||
**约束：**
|
||||
- 不 import llm、blackboard、main-agent
|
||||
- 不做 IO
|
||||
- 所有相位转移必须写进 history
|
||||
|
||||
**A10 职责：** 兼容旧 import 路径，后续可删。
|
||||
|
||||
---
|
||||
|
||||
### 4.4 黑板
|
||||
|
||||
| # | 文件 | 状态 | 干嘛的 | 对应文档 |
|
||||
|---|---|---|---|---|
|
||||
| A11 | `src/blackboard/blackboard.ts` | done | listTagIndex、queryByPatterns、write | `tag-blackboard.md` §2 |
|
||||
|
||||
**A11 职责：**
|
||||
- `listTagIndex()` — 给编排器
|
||||
- `queryByPatterns()` — 给 worker 注入
|
||||
- `write()` — 按 tag 写回
|
||||
- `getContentByTag()` / `getLatestByTag()`
|
||||
|
||||
---
|
||||
|
||||
### 4.5 配置与 LLM
|
||||
|
||||
| # | 文件 | 状态 | 干嘛的 | 对应文档 |
|
||||
|---|---|---|---|---|
|
||||
| A12 | `src/config/env.ts` | done | 从环境变量读 baseUrl、apiKey、model | `architecture.md` §2 config |
|
||||
| A13 | `src/llm/client.ts` | done | OpenAI 兼容 API + MockLlmProvider | — |
|
||||
|
||||
**A12 职责：**
|
||||
- `loadLlmConfig()` — 必须有 key，否则抛错
|
||||
- `loadLlmConfigOptional()` — 无 key 返回 null，CLI 切 mock
|
||||
|
||||
**A13 职责：**
|
||||
- `LlmProvider` 接口：`complete(messages) → string`
|
||||
- `OpenAiCompatibleProvider` — 真实 API 调用
|
||||
- `MockLlmProvider` — 测试 / demo 用预设响应
|
||||
- apiKey 不出现在 session 或项目文件里
|
||||
|
||||
---
|
||||
|
||||
### 4.6 编排器 LLM
|
||||
|
||||
| # | 文件 | 状态 | 干嘛的 | 对应文档 |
|
||||
|---|---|---|---|---|
|
||||
| A14 | `src/main-agent/main-agent.ts` | done | 编排器：只选 worker，读 tag 索引 | `tag-blackboard.md` §6 |
|
||||
| A15 | `src/main-agent/prompts.ts` | todo | 编排器 prompt 拆分 | `tag-blackboard.md` §6 |
|
||||
|
||||
**A14 职责：**
|
||||
- `MainAgent.decide(context)` — 调 LLM，返回 `MainAgentDecision`
|
||||
- `parseMainAgentDecision(raw)` — 解析 JSON（Phase B 改为 parse tool calls）
|
||||
- `buildMainAgentUserPrompt(context)` — 拼 user prompt
|
||||
- `DEFAULT_WORKERS` — 第一版可用 worker 列表
|
||||
|
||||
**约束：**
|
||||
- 编排器不读黑板 value
|
||||
- 编排器不直接改 phase
|
||||
- 不含 question-worker（提问是 worker 能力）
|
||||
|
||||
**A15 职责（可选拆分）：** 把 prompt 从 main-agent.ts 抽出来，方便迭代。
|
||||
|
||||
---
|
||||
|
||||
### 4.7 编排层
|
||||
|
||||
| # | 文件 | 状态 | 干嘛的 | 对应文档 |
|
||||
|---|---|---|---|---|
|
||||
| A16 | `src/runtime/orchestrator.ts` | deprecated | 旧入口；用 phase-runtime | `architecture.md` |
|
||||
|
||||
**A16 职责：**
|
||||
- `RuntimeOrchestrator` — 对外 API：start、submitUserInput、approve、accept 等
|
||||
- `dispatch(event)` — 调 `applyEvent`，处理 `PhaseEffect`
|
||||
- `runMainAgent()` — phase=running 时调编排器
|
||||
- `runStubWorker()` — 第一版占位 worker（Phase C 替换）
|
||||
- `resumeStubWorker()` — worker 中途提问后恢复
|
||||
|
||||
**约束：**
|
||||
- 唯一调用阶段机和编排器的地方
|
||||
- user 事件（approve / accept）只从 CLI / API 进入，不从 LLM 进入
|
||||
|
||||
---
|
||||
|
||||
### 4.8 入口与测试
|
||||
|
||||
| # | 文件 | 状态 | 干嘛的 |
|
||||
|---|---|---|---|
|
||||
| A17 | `src/cli/run.ts` | done | 交互式 CLI：输入、/approve、/accept、/status |
|
||||
| A18 | `tests/phase-machine.test.ts` | done | 阶段机单元测试 |
|
||||
| A19 | `tests/orchestrator.test.ts` | done | 编排层 + Mock LLM 集成测试 |
|
||||
|
||||
**A17 职责：**
|
||||
- 读 stdin，转成 orchestrator 方法调用
|
||||
- 打印 `phase` + `waitingReason`
|
||||
- `--mock` 或无 API key 时用 MockLlmProvider
|
||||
|
||||
---
|
||||
|
||||
## 5. Phase B 文件顺序（下一步）
|
||||
|
||||
| # | 文件 | 干嘛的 |
|
||||
|---|---|---|
|
||||
| B01 | `src/types/tools.ts` | tool 类型定义 |
|
||||
| B02 | `src/runtime/tool-registry.ts` | 注册 tool、校验参数、tool → event |
|
||||
| B03 | `src/main-agent/main-agent.ts` | 改为 tool calling 模式 |
|
||||
| B04 | `src/runtime/tool-handlers/main-agent.ts` | 编排器 tool 处理器 |
|
||||
| B05 | `src/runtime/tool-handlers/worker.ts` | worker tool 处理器（ask_user / submit） |
|
||||
|
||||
**B02 职责：**
|
||||
- 白名单：当前 phase + waitingReason 下允许哪些 tool
|
||||
- LLM 调了不允许的 tool → 拒绝，不转事件
|
||||
|
||||
---
|
||||
|
||||
## 6. Phase C 文件顺序
|
||||
|
||||
| # | 文件 | 干嘛的 |
|
||||
|---|---|---|
|
||||
| C01 | `src/workers/types.ts` | WorkerDefinition、WorkerRunOutcome |
|
||||
| C02 | `src/workers/base-worker.ts` | prompt 拼接、tool 执行循环 |
|
||||
| C03 | `src/workers/outline-worker.ts` | 大纲 worker |
|
||||
| C04 | `src/workers/drafting-worker.ts` | 正文 worker |
|
||||
| C05 | `src/runtime/worker-runner.ts` | 替代 orchestrator 里的 stub |
|
||||
|
||||
**WorkerRunOutcome（Phase C 核心）：**
|
||||
|
||||
```ts
|
||||
type WorkerRunOutcome =
|
||||
| { kind: "complete"; writes: BlackboardWrite[]; summary: string }
|
||||
| { kind: "suspend"; questions: string[]; partialWrites?: BlackboardWrite[] }
|
||||
| { kind: "fail"; reason: string };
|
||||
```
|
||||
|
||||
- `complete` → `worker_completed` 事件
|
||||
- `suspend` → `worker_needs_input` 事件
|
||||
- `fail` → `runtime_failed` 事件
|
||||
|
||||
---
|
||||
|
||||
## 7. Phase D 文件顺序
|
||||
|
||||
| # | 文件 | 干嘛的 |
|
||||
|---|---|---|
|
||||
| D01 | `src/flows/types.ts` | ExecutionFlow、ExecutionStep |
|
||||
| D02 | `src/flows/ghostwriting-flow.ts` | 代笔 flow 配置 |
|
||||
| D03 | `src/book-storage/store.ts` | Book 持久化 |
|
||||
| D04 | `src/preset/importer.ts` | SillyTavern 预设导入 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 单文件完成检查清单
|
||||
|
||||
每写完一个文件，确认：
|
||||
|
||||
```text
|
||||
[ ] 文件顶部的职责是否只对应文档里的一节
|
||||
[ ] 是否 import 了不该 import 的上层模块（阶段机不应 import LLM）
|
||||
[ ] 是否有对应测试（内核文件必须有）
|
||||
[ ] 是否更新了本表的状态列（done / todo）
|
||||
[ ] 是否在 PR / 提交说明里写「这个文件干嘛的」一句话
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. 当前进度
|
||||
|
||||
```text
|
||||
Phase A0（可运行阶段机） ✅ 完成
|
||||
phase-machine + phase-runtime + phase-demo + 测试
|
||||
|
||||
Phase A1（编排器 LLM） ✅ 有初版（orchestrator + run.ts）
|
||||
下一步：orchestrator 应基于 PhaseRuntime 重构
|
||||
|
||||
Phase B（tool call） 未开始
|
||||
Phase C（真实 worker） 未开始
|
||||
Phase D（flow / 存储） 未开始
|
||||
```
|
||||
|
||||
**下一个应写文件：** 让 `orchestrator.ts` 内部组合 `PhaseRuntime`，而不是重复阶段机逻辑。写之前会先说明该文件职责。
|
||||
|
||||
@@ -2,18 +2,19 @@
|
||||
|
||||
> **阶段**：P1 = 定类与契约；**P2** = 程序/样式适配与灌数。
|
||||
> 上游：游玩管线 `gm → perspective? → narrator → auditor`。
|
||||
> 创作挂钩：`设计.正文组成` / `设计.监控栏`；终稿 tag 通常 `输出.用户展示`。
|
||||
> **创作定位：基于固定壳做适配微调，不是从零设计前端。**
|
||||
> 创作挂钩：`设计.正文组成`（怎么展示）/ `设计.监控栏`（每轮看什么，技能名「回复呈现」）；终稿 tag 通常 `输出.用户展示`。
|
||||
> 各壳介绍与规格：`skills/dialogue/world-simulator/present-shells/`（正文组成执行时动态注入）。
|
||||
> **创作定位：按回复呈现清单选壳并美化，可写 CSS/HTML/JS。**
|
||||
> 预览：`/shells.html`
|
||||
|
||||
## 1. 创作怎么做（权威口径）
|
||||
|
||||
```text
|
||||
固定壳（本仓库预置，七种）
|
||||
→ 按「要同时看见什么」选 shell_id（不是按好看）
|
||||
呈现壳（仓库 present-shells/，动态装载）
|
||||
→ 按「要同时看见什么」对照各壳介绍选 shell_id
|
||||
→ 只改允许的微调轴
|
||||
→ 禁止改分区骨架、禁止发明第八种布局
|
||||
游玩期：往壳区域灌数；正文随 500～2000 字撑高滚动
|
||||
→ 禁止改分区骨架、禁止自造目录没有的壳
|
||||
游玩期：往壳区域灌数；正文随 1000～2000 字撑高滚动
|
||||
```
|
||||
|
||||
选壳依据（同时可见关系）：
|
||||
@@ -36,7 +37,7 @@
|
||||
|
||||
| 优先级 | 区域 | 视觉待遇 |
|
||||
|--------|------|----------|
|
||||
| **P0** | `body` | 阅读主轴；**随字数撑高**（单轮按 500～2000 字设计），由页面/消息区滚动 |
|
||||
| **P0** | `body` | 阅读主轴；**随字数撑高**（单轮按 1000～2000 字设计），由页面/消息区滚动 |
|
||||
| **P1** | 建议行动 | 要决策时醒目；`choice_dock` 坞 **sticky 贴底** |
|
||||
| **P2** | `monitor` | 芯片密排，高度固定矮 |
|
||||
| **P3** | `header` / `footer` / `aside` | 辅助；双栏 **aside sticky**，长文仍可对照 |
|
||||
@@ -84,13 +85,14 @@
|
||||
## 4. 与创作产物的映射
|
||||
|
||||
```text
|
||||
设计.正文组成
|
||||
正文.呈现壳.shell_id → 七选一
|
||||
设计.正文组成
|
||||
正文.呈现壳.shell_id → 【可选呈现壳】中的 id
|
||||
正文.呈现壳.微调 → 只填允许轴
|
||||
正文.可见块[] → 挂到壳已有区域
|
||||
正文.示例.灌数 → present.v1 形状预览（非正史；专供验收壳/美化）
|
||||
|
||||
设计.监控栏 → monitor 字段表
|
||||
设计.监控栏 → 回复呈现清单（看什么）
|
||||
设计.正文组成 → 壳 + 美化（怎么展示）
|
||||
运行.本轮.裁决 → body 事实；suggested_actions → 行动区
|
||||
输出.用户展示 → present.v1 或纯 Markdown（→ body）
|
||||
```
|
||||
@@ -114,7 +116,7 @@
|
||||
|
||||
## 6. 创作期只做适配
|
||||
|
||||
1. **选壳**：按「主面积给谁」（§2）七选一。
|
||||
1. **选壳**：按「主面积给谁」从已装载壳里选。
|
||||
2. **微调**：字段、显示名、行动开关、tone、空态。
|
||||
3. **不要**：重画分区、发明区域 id、写 CSS。
|
||||
|
||||
@@ -131,4 +133,4 @@
|
||||
|
||||
---
|
||||
|
||||
修订：2026-08-22 · 七壳；终稿阅读柱；单轮正文 500～2000 字。
|
||||
修订：2026-09-06 · 七壳；终稿阅读柱；单轮正文默认 1000～2000 字。
|
||||
|
||||
+61
-429
@@ -2,447 +2,131 @@
|
||||
|
||||
> **文档层级：Skill 包格式（非系统架构）。**
|
||||
> 系统级模块与调度边界见 [`architecture.md`](./architecture.md)。
|
||||
>
|
||||
> **现行唯一落地包**：`skills/dialogue/world-simulator/`（见该包 README、`world-simulator-modules.md`）。
|
||||
> 下文部分示例仍保留历史 `novel/` / `weird-rules-short` 树形说明，**仓库内已不存在**；写新内容请以 world-simulator 为准。
|
||||
> 创作流水线现行名：`design-flow` + `design-step`（旧称 `design-intake` 已废弃）。
|
||||
> 创作流水线：`design-flow` + `design-step`。
|
||||
|
||||
## 1. 定位：两层 Skill
|
||||
本文只写**包怎么落盘、registry、启动时怎么绑包**。manifest 正文见 `orchestrator-skill-format.md`；磁盘 Worker 见 `worker-skill-format.md`；建包步骤见 `skill-design-guide.md`。
|
||||
|
||||
本项目有 **两种 Skill 文档**，不要混在一个文件里：
|
||||
---
|
||||
|
||||
## 1. 两层 Skill
|
||||
|
||||
| 类型 | 路径 | 消费者 | 写什么 |
|
||||
|------|------|--------|--------|
|
||||
| **编排器 Skill** | `skills/{bookKind}/{name}/orchestrator.md` | Main Agent | **何时**调哪个 worker、验收方式、启动询问 |
|
||||
| **编排器 Skill** | `skills/{bookKind}/{name}/orchestrator.md` | Main Agent | **何时**调哪个 worker、验收方式、启动引导 |
|
||||
| **Worker Skill** | `workers/{workerId}/SKILL.md` | Worker Agent | **inputTags/outputTags**、怎么做 |
|
||||
|
||||
```text
|
||||
选 weird-rules-short（编排器 Skill）
|
||||
→ 编排器：brief 齐了 → run ruleset-worker，input=[project.brief]
|
||||
→ Worker：读 workers/ruleset-worker/SKILL.md → 写 core / rules / commentary
|
||||
→ 编排器：rules accepted → run review-worker
|
||||
→ Worker：读 workers/review-worker/SKILL.md → 评估怎么做
|
||||
```
|
||||
|
||||
**何时评估** = 编排器 Skill 的 Worker 编排表。
|
||||
**如何评估** = review-worker 的 Worker Skill。
|
||||
|
||||
详细规范：
|
||||
|
||||
- 编排器 Skill → `docs/orchestrator-skill-format.md`
|
||||
- Worker Skill → `docs/worker-skill-format.md`
|
||||
|
||||
旧称「Skill = 创作说明书」仍成立，但说明书 **拆成编排（编排器）与执行（worker）两份**。
|
||||
|
||||
```text
|
||||
会话开始
|
||||
→ 询问 1：选哪个编排器 Skill（skills/{bookKind}/{name}/orchestrator.md）
|
||||
→ 加载编排器 Skill
|
||||
→ 询问 2：读编排器 Skill「## 启动询问」
|
||||
→ 之后编排器按「Worker 编排」调度；Worker 读本 skill 包内 workers/{id}/SKILL.md
|
||||
→ 自动绑定默认编排器包（world-simulator）
|
||||
→ UI 选配方（recipes/，不是再选 skill 包）
|
||||
→ 编排器按 tool loop 调度；Worker 读本包 workers/{id}/SKILL.md
|
||||
```
|
||||
|
||||
**何时评估** = 编排器 Skill。
|
||||
**如何评估** = 对应 Worker Skill（或运行规格里的声明）。
|
||||
|
||||
---
|
||||
|
||||
## 2. 存储位置
|
||||
|
||||
Skill 以 **Skill 包（skill pack）** 为单位：一个编排器 + 其专属 workers，**同包绑定，不跨包复用 worker**。
|
||||
Skill 以 **Skill 包** 为单位：一个编排器 + 其专属 workers，**同包绑定，不跨包复用 worker**。
|
||||
|
||||
```text
|
||||
skills/
|
||||
├── registry.yaml
|
||||
├── novel/ # Book 形态
|
||||
│ ├── basic/
|
||||
│ │ └── orchestrator.md # 编排器 Skill
|
||||
│ ├── weird-rules-short/
|
||||
│ │ ├── orchestrator.md # 编排器：何时调谁、黑板 key
|
||||
│ │ └── workers/ # 本编排器专属，不与其他 skill 共享
|
||||
│ │ ├── write-rules/
|
||||
│ │ │ └── SKILL.md # 规则怪谈：怎么写规则+解析
|
||||
│ │ └── review/
|
||||
│ │ └── SKILL.md # 规则怪谈：怎么检查
|
||||
│ └── novel-standard/
|
||||
│ ├── orchestrator.md
|
||||
│ └── workers/
|
||||
│ ├── outline/SKILL.md
|
||||
│ └── drafting/SKILL.md
|
||||
└── dialogue/
|
||||
└── theater-roleplay/
|
||||
└── world-simulator/
|
||||
├── orchestrator.md
|
||||
├── recipes/
|
||||
├── modules/
|
||||
├── worker-templates/
|
||||
└── workers/
|
||||
└── turn/SKILL.md
|
||||
├── design-flow/SKILL.md
|
||||
├── design-step/SKILL.md
|
||||
└── opening-generator/SKILL.md
|
||||
```
|
||||
|
||||
规则：
|
||||
|
||||
```text
|
||||
第一层文件夹 = bookKind（novel | dialogue），决定 Book 存储结构
|
||||
第二层文件夹 = 一个 skill 包，名与 frontmatter.name 一致
|
||||
orchestrator.md 编排器 Skill（编排、启动询问、验收）
|
||||
workers/{id}/ 本包专属 worker；id 在包内唯一即可
|
||||
Worker 不复用：novel-standard 的 outline worker ≠ weird-rules-short 的任何 worker
|
||||
registry.yaml 的 path 指向 orchestrator.md，如 novel/weird-rules-short/orchestrator.md
|
||||
orchestrator.md 编排器 Skill
|
||||
workers/{id}/ 本包专属 worker；id 在包内唯一
|
||||
```
|
||||
|
||||
**为何不复用 worker：** 同一「产出形状」（如规则表）在不同编排器下的写法、Rubric、自检完全不同；共享 worker 会把体裁细节塞进编排器或搞混上下文。需要相似流程时 **复制 worker 包再改**，而不是引用全局 worker。
|
||||
loader 仍扫描 `skills/novel/` 与 `skills/dialogue/`（平铺 `.md` 或 `{name}/orchestrator.md`）。仓库里目前只有 `dialogue/world-simulator`。
|
||||
|
||||
与 Cursor skill 的区别：
|
||||
|
||||
| | Cursor Skill | 本项目 Skill |
|
||||
|---|---|---|
|
||||
| 位置 | `.cursor/skills/` | `skills/` |
|
||||
| 触发 | Agent 自动或显式引用 | **会话开始必须选一个** |
|
||||
| 内容 | 通用任务指南 | **创作流程 + 思维链 + 询问策略** |
|
||||
| 消费者 | Cursor Agent | 编排器 LLM |
|
||||
**为何不复用 worker：** 同一产出形状在不同编排器下的写法、验收完全不同；需要相似流程时复制后再改。
|
||||
|
||||
---
|
||||
|
||||
## 3. SKILL.md 结构
|
||||
## 3. Frontmatter（编排器）
|
||||
|
||||
### 3.0 两层分类（重要）
|
||||
|
||||
Skill 分类分**两层**，不要混为一层：
|
||||
|
||||
```text
|
||||
第一层：Book 形态（category / bookKind，选定后不可换）
|
||||
novel 类小说存储：卷、章、大纲、正文（含各类小说子类型）
|
||||
dialogue 多轮多角色对话：回合、角色、场景（roleplay / 剧场）
|
||||
|
||||
第二层：具体 Skill 包（name，用户启动时选）
|
||||
每个包 = orchestrator.md + workers/，不是 category 下的平铺 .md 枚举。
|
||||
```
|
||||
|
||||
示例：
|
||||
|
||||
```text
|
||||
category: novel ← 第一层：Book 怎么存
|
||||
name: novel-standard ← 第二层：标准长篇流程
|
||||
name: weird-rules-short ← 第二层：规则怪谈短篇（仍是 novel Book）
|
||||
name: basic ← 第二层：最小演示
|
||||
|
||||
category: dialogue
|
||||
name: theater-roleplay ← 第二层：剧场式多角色互动
|
||||
```
|
||||
|
||||
**不要把「规则怪谈」做成与 novel 平级的 category。**
|
||||
规则怪谈是 **novel 形态下的专精 skill**，用 `name` + `tags` 区分：
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: weird-rules-short
|
||||
description: 短篇规则怪谈：从隐含核心反推护命规则，再成章撰写。
|
||||
category: novel
|
||||
bookKind: novel
|
||||
tags: [novel, weird_rules, short, horror]
|
||||
---
|
||||
```
|
||||
|
||||
| 层级 | 字段 | 谁选 | 例子 |
|
||||
|---|---|---|---|
|
||||
| Book 形态 | `category` / `bookKind` | 选 skill 时确定，之后不变 | `novel` / `dialogue` |
|
||||
| 具体流程 | `name` | 启动询问 1：选哪个 SKILL.md | `weird-rules-short` |
|
||||
| 体裁标签 | `tags` | 可选，供匹配与过滤 | `weird_rules`, `standard` |
|
||||
|
||||
启动 UI 可以按 `category` 分组展示，组内列出多个 `name`（如「小说」下：标准长篇、规则怪谈短篇、…）。
|
||||
|
||||
参考 Cursor `SKILL.md`：YAML frontmatter + Markdown 正文。
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: novel-standard
|
||||
description: >-
|
||||
标准长篇小说创作：先简报、再大网、事件细化、正文。
|
||||
适用于用户要写小说、章节、大纲时使用。
|
||||
category: novel
|
||||
version: 1
|
||||
defaultFlowId: ghostwriting-flow
|
||||
tags: [novel, outline, draft]
|
||||
---
|
||||
|
||||
# 标准小说创作
|
||||
|
||||
## 启动询问
|
||||
|
||||
（流程 2：选 skill 后向用户展示什么、必收集项、写入 book.brief）
|
||||
|
||||
## 创作总纲
|
||||
|
||||
（给编排器：这类内容是什么、总体顺序、禁忌）
|
||||
|
||||
## 编排器思维链
|
||||
|
||||
（每轮决策前先检查什么、如何选 worker）
|
||||
|
||||
## 推荐阶段
|
||||
|
||||
（brief → outline → plotline → style → draft）
|
||||
|
||||
## 询问策略
|
||||
|
||||
### 编排器应先问
|
||||
### 交给 Worker 问
|
||||
|
||||
## 推荐 Worker
|
||||
|
||||
## 示例
|
||||
```
|
||||
|
||||
### 3.1 Frontmatter 字段
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: novel-standard # 必需，唯一 id，[a-z0-9-]
|
||||
description: > # 必需，供启动时向用户展示、供编排器匹配
|
||||
第三人称描述 WHAT + WHEN。
|
||||
category: novel # 必需：Book 形态，见 §3.0
|
||||
bookKind: novel # 建议与 category 对齐；选定后 Book 结构固定
|
||||
version: 1
|
||||
defaultFlowId: ghostwriting-flow # 可选，绑定 execution flow
|
||||
defaultPresetId: writing-default # 可选
|
||||
tags: [novel, standard] # 体裁/子类型标签，如 weird_rules、short
|
||||
suggestedWorkers: # 可选，本 skill 常用 worker
|
||||
- outline-worker
|
||||
- plotline-worker
|
||||
- drafting-worker
|
||||
---
|
||||
```
|
||||
loader（`src/skills/loader.ts`）从 `orchestrator.md` 解析的字段：
|
||||
|
||||
| 字段 | 必需 | 用途 |
|
||||
|---|---|---|
|
||||
| `name` | ✅ | skill id；通常与文件名一致（不含 .md） |
|
||||
| `description` | ✅ | 启动选择列表展示；编排器判断用户描述是否匹配 |
|
||||
| `name` | ✅ | skill id |
|
||||
| `description` | ✅ | 列表展示、匹配 |
|
||||
| `category` | ✅ | 与 `bookKind` 一致：`novel` \| `dialogue` |
|
||||
| `bookKind` | 建议 | 选定后 Book 结构固定；缺省时由所在文件夹推断 |
|
||||
| `tags` | | 体裁细分：`weird_rules`、`standard` 等 |
|
||||
| `path` | registry | 相对路径，如 `novel/weird-rules-short.md` |
|
||||
| `defaultFlowId` | | 选中后默认 execution flow |
|
||||
| `suggestedWorkers` | | 编排器选 worker 时的白名单提示 |
|
||||
| `bookKind` | 建议 | 缺省时由所在文件夹推断 |
|
||||
| `workers` | 建议 | 本包可调度的 design worker id（亦认 `suggestedWorkers`） |
|
||||
| `demandTag` | | 启动写入目标；缺省 `book.brief` |
|
||||
| `startupMode` | | `agent-first`（默认）或 `intake`（legacy） |
|
||||
| `uiPrompt` | | agent-first 首屏引导 |
|
||||
| `tags` | | 体裁细分 |
|
||||
| `version` | | 数字 |
|
||||
|
||||
### 3.2 撰写标准：写作生命周期（推荐）
|
||||
|
||||
Skill 文件本质上是**给 LLM 与 Runtime 读的字符串规格**。下面这套「触发 → 写前 → 写中 → 写后 → 质量维度」与现有阶段机、验收模式对齐，**应作为所有 skill `.md` 的撰写标准**。
|
||||
|
||||
```text
|
||||
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
|
||||
│ 触发条件 │ → │ 写作前 │ → │ 写作中 │ → │ 写作后 │ → │ 质量维度 │
|
||||
│ 何时激活 │ │ 需求分析 │ │ 分步引导 │ │ 自检润色 │ │ 可量化 Rubric│
|
||||
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
|
||||
frontmatter 启动询问 推荐阶段 自检清单 质量评估标准
|
||||
+ tags + 创作总纲 + 示例/约束 + 验收策略 + 接受度(预留)
|
||||
+ 询问策略 + 禁用行为
|
||||
```
|
||||
|
||||
#### 与正文章节的对应关系
|
||||
|
||||
| 生命周期 | 对应章节 | 写什么 |
|
||||
|---|---|---|
|
||||
| **触发条件** | frontmatter `description` + `tags` | 何时应选本 skill；用户说什么话时应匹配（如「规则怪谈」「短篇怪谈」） |
|
||||
| **写作前 · 需求分析** | `## 启动询问` + `## 创作总纲` | 对象、受众、语气、目标、禁忌；**禁止直接动笔**；写入哪个 key |
|
||||
| **写作中 · 分步引导** | `## 推荐阶段` + `## 示例` + `## 禁用行为` | 阶段链、每步约束、好/坏示例；对应 worker 与产出 key |
|
||||
| **写作后 · 自检润色** | `## 自检清单` + `## 验收策略` | 产出前检查点；LLM 自审 vs 人工 vs 程序验收 |
|
||||
| **质量评估** | `## 质量评估标准` | 可量化维度 + 各 stage 的 acceptanceMode |
|
||||
| **编排** | `## 编排器思维链` + `## 询问策略` + `## 推荐 Worker` | 编排器如何调度；谁向用户提问 |
|
||||
|
||||
不必每个 skill 都写独立 `# 写作前` 大标题；**用统一章节名即可**，内容覆盖上表即可。
|
||||
|
||||
#### `## 质量评估标准`（必需）
|
||||
|
||||
避免只写「写得更好」。每个 skill 应列出 **可检查的质量维度**，格式建议：
|
||||
|
||||
```markdown
|
||||
## 质量评估标准
|
||||
|
||||
| 维度 | 说明 | 检查方式 |
|
||||
|---|---|---|
|
||||
| 完整性 | 是否满足启动询问中的必收集项 | programmatic / 人工 |
|
||||
| 体裁符合 | 是否符合创作总纲（如规则怪谈：规则可反推危险） | LLM 自审 + 人工 |
|
||||
| 一致性 | 与已 accepted 上游产物是否矛盾 | programmatic |
|
||||
| **接受度** | 用户/系统是否接受该产物（预留） | user_confirmed → 记录 accept/reject |
|
||||
|
||||
各 stage 默认 acceptanceMode 见「验收策略」。
|
||||
```
|
||||
|
||||
**「接受度」维度（预留）：**
|
||||
|
||||
- 第一版：**不强制数值打分**；用阶段机的 `user_accepted_artifact` / `reject` 记录二元结果即可。
|
||||
- 后续可在 Book / Session 元数据写入 `acceptanceScore` 或 `acceptanceNotes`（字符串或 1–5 分），与 Skill Rubric 对齐。
|
||||
- Skill 里写清楚：**接受度由验收事件沉淀，不由 LLM 自报分数代替人工。**
|
||||
|
||||
#### `## 自检清单`（必需）
|
||||
|
||||
写作后、提交验收前，worker 或编排器应过的检查点（字符串列表即可）：
|
||||
|
||||
```markdown
|
||||
## 自检清单
|
||||
|
||||
### rules.draft 提交前
|
||||
- [ ] 每条规则能否对应非玄学的危险动机？
|
||||
- [ ] 是否未直接写出 core.danger？
|
||||
- [ ] 是否无「违反即抹杀」空规则？
|
||||
|
||||
### content.chapter.* 提交前
|
||||
- [ ] 是否遵守 rules.draft 已 accepted 版本？
|
||||
- [ ] …
|
||||
```
|
||||
|
||||
与 `programmatic_review` 的关系：自检清单 = LLM/人读的规范；程序验收 = 可机械执行的子集。
|
||||
|
||||
#### 模板骨架（`skills/{bookKind}/{name}.md`）
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: …
|
||||
description: … # 触发条件（WHEN）
|
||||
tags: …
|
||||
category / bookKind: …
|
||||
suggestedWorkers: …
|
||||
---
|
||||
|
||||
# 标题
|
||||
|
||||
## 启动询问 # 写作前 · 需求分析
|
||||
## 创作总纲
|
||||
## 编排器思维链
|
||||
## 推荐阶段 # 写作中 · 分步引导
|
||||
## 询问策略
|
||||
## 推荐 Worker
|
||||
## 示例 # 写作中 · 约束与范例
|
||||
## 禁用行为
|
||||
## 自检清单 # 写作后
|
||||
## 验收策略 # 写作后 · 与 acceptanceMode 绑定
|
||||
## 质量评估标准 # Rubric + 接受度（预留）
|
||||
## Book 结构 # 可选，novel / dialogue 形态说明
|
||||
```
|
||||
|
||||
代码当前**结构化解析**的仍主要是 `## 启动询问`；其余章节整段注入编排器 prompt（待 `buildSkillContext`）。**全部是 Markdown 字符串，不矛盾。**
|
||||
|
||||
### 3.3 正文必需章节（检查清单）
|
||||
|
||||
| 章节 | 生命周期 | 内容 |
|
||||
|---|---|---|
|
||||
| frontmatter | 触发 | name、description、tags、bookKind |
|
||||
| **启动询问** | 写前 | 必收集项、写入 key |
|
||||
| **创作总纲** | 写前 | 顺序、边界、体裁原则 |
|
||||
| **推荐阶段** | 写中 | 阶段链、worker、产出 key、prerequisites |
|
||||
| **示例** | 写中 | 好/坏对照或完整流程范例 |
|
||||
| **禁用行为** | 写中 | 绝对不要做的事 |
|
||||
| **自检清单** | 写后 | 提交验收前的检查点 |
|
||||
| **验收策略** | 写后 | 各 stage 的 acceptanceMode |
|
||||
| **质量评估标准** | 质量 | 可量化维度 + **接受度（预留）** |
|
||||
| **编排器思维链** | 编排 | 每轮决策检查 |
|
||||
| **询问策略** | 编排 | 编排器问 vs worker 问 |
|
||||
| **推荐 Worker** | 编排 | 与 suggestedWorkers 一致 |
|
||||
|
||||
可选：`## Book 结构`、`examples.md` 外链。
|
||||
正文章节、验收与禁用行为见 `orchestrator-skill-format.md`。不要再写「推荐阶段 / 质量评估标准 / 推荐 Worker」那套旧 SKILL 骨架。
|
||||
|
||||
---
|
||||
|
||||
## 4. registry.yaml（可选）
|
||||
## 4. registry.yaml
|
||||
|
||||
启动时列举可用 skill，不必扫描目录：
|
||||
启动时列举可用 skill，不必全靠扫盘：
|
||||
|
||||
```yaml
|
||||
skills:
|
||||
- name: novel-standard
|
||||
description: 标准长篇小说：大纲 → 事件 → 正文
|
||||
category: novel
|
||||
- name: weird-rules-short
|
||||
description: 短篇规则怪谈：隐含核心 → 护命规则 → 成章
|
||||
category: novel
|
||||
- name: theater-roleplay
|
||||
description: 剧场式角色扮演：角色 → 场景 → 回合互动
|
||||
- name: world-simulator
|
||||
description: 默认包：选配方 → 编排工作流计划 → 执行单元上场
|
||||
category: dialogue
|
||||
- name: forum-thread
|
||||
description: 论坛体连载：楼主身份 → 回帖风格 → 楼层
|
||||
category: novel
|
||||
bookKind: dialogue
|
||||
path: dialogue/world-simulator/orchestrator.md
|
||||
```
|
||||
|
||||
若无 `registry.yaml`，Runtime 扫描 `skills/novel/*.md` 与 `skills/dialogue/*.md`。
|
||||
**registry 列举的是第二层 skill（name），不是 category。**
|
||||
无 `registry.yaml` 时，Runtime 扫描 `skills/novel/` 与 `skills/dialogue/`。
|
||||
registry 列举的是第二层 skill（`name`），不是 category。
|
||||
|
||||
---
|
||||
|
||||
## 5. 会话启动：描述需求，而非选包
|
||||
## 5. 会话启动
|
||||
|
||||
新建作品 **不再** 让用户输入 skill name 或列表编号。Runtime 自动加载默认 orchestrator（`world-simulator`，见 `src/config/default-orchestrator.ts`），直接进入 intake。
|
||||
|
||||
### 5.1 启动转移
|
||||
新建作品 **不** 让用户输入 skill name。Runtime 加载默认编排器（`world-simulator`，见 `src/config/default-orchestrator.ts`），用户只选**配方**。
|
||||
|
||||
```text
|
||||
idle
|
||||
session_started { initialSkill }
|
||||
→ waiting_user(intake)
|
||||
→ waiting_user(intake) # 展示 uiPrompt；用户描述需求
|
||||
```
|
||||
|
||||
`session_started` 携带 `initialSkill` 时跳过 `skill_selection`。
|
||||
registry 中其它包仅供 `startWithOrchestrator` / 旧作品读档兼容。
|
||||
registry 中其它包仅供 `startWithOrchestrator` / 旧作品读档。
|
||||
|
||||
**Legacy（旧会话恢复）：**
|
||||
无 `initialSkill` 的旧快照才可能出现 `waiting_user(skill_selection)`。
|
||||
|
||||
```text
|
||||
session_started（无 initialSkill）
|
||||
→ waiting_user(skill_selection) # 仅旧快照可能出现
|
||||
```
|
||||
|
||||
```ts
|
||||
| { kind: "skill_selection"; availableSkills: SkillIndexEntry[] } // legacy
|
||||
| { kind: "intake"; prompt: string }
|
||||
```
|
||||
|
||||
### 5.2 向用户展示
|
||||
|
||||
来自 orchestrator `## 启动询问`，例如 world-simulator：
|
||||
|
||||
```text
|
||||
请用你自己的话描述想做什么，例如：
|
||||
|
||||
- 西幻升级、长篇 AI 交互、世界推着走
|
||||
- 部分代入：() 是指令，"" 是角色话，【】 是行动
|
||||
- 或：仿写/扩写、规则怪谈、快节奏爽文……
|
||||
|
||||
Agent 会根据你的描述推理需要哪些 Worker，并产出 Worker 集。
|
||||
```
|
||||
|
||||
### 5.3 用户回答方式
|
||||
|
||||
```text
|
||||
直接描述创作目标（一句话即可）
|
||||
```
|
||||
|
||||
Runtime 写入 `用户.需求`（或 skill 指定的 startupTargetKey），确认后进入 design stage。
|
||||
|
||||
### 5.4 两阶段启动（现行）
|
||||
|
||||
```text
|
||||
阶段 1（系统） 自动绑定默认 orchestrator
|
||||
阶段 2（intake） 启动询问 → 用户描述需求 → confirm → agent burst
|
||||
```
|
||||
|
||||
**Agent 根据需求编排能力并收成 worker 集**（`design-flow` → `design-step`），不再让用户在 registry 里四选一。
|
||||
用户回答写入 `demandTag`（现行包为 `用户.需求`），之后 `design-flow` → `design-step` 编排并收成 worker 集。
|
||||
|
||||
---
|
||||
|
||||
## 6. 编排器如何使用已选 Skill
|
||||
## 6. 解析与加载
|
||||
|
||||
`session.slots.activeSkill` 加载后，编排器 prompt 注入：
|
||||
| 文件 | 干嘛的 |
|
||||
|---|---|
|
||||
| `src/skills/types.ts` | SkillIndexEntry、ParsedSkill、ParsedWorkerSkill |
|
||||
| `src/skills/loader.ts` | 读 registry 或扫盘；解析 orchestrator.md 与 workers/*/SKILL.md |
|
||||
| `src/config/default-orchestrator.ts` | 默认包 id、uiPrompt 兜底 |
|
||||
|
||||
```text
|
||||
当前 skill: novel-standard
|
||||
category: novel
|
||||
创作总纲: （SKILL.md 摘要或全文）
|
||||
当前推荐阶段: outline（由 resolver 根据黑板推断）
|
||||
询问策略: 编排器应先问 brief；outline 细节交给 worker
|
||||
建议 worker: outline-worker, drafting-worker
|
||||
defaultFlowId: ghostwriting-flow
|
||||
```
|
||||
|
||||
编排器决策仍通过 tool / JSON 决策，**不**直接改 phase。
|
||||
|
||||
---
|
||||
|
||||
## 7. 示例
|
||||
|
||||
完整示例见仓库内真实文件（不要只在文档里维护一份）：
|
||||
完整示例以仓库内真实文件为准：
|
||||
|
||||
```text
|
||||
skills/dialogue/world-simulator/orchestrator.md
|
||||
@@ -451,62 +135,10 @@ skills/dialogue/world-simulator/modules/catalog.yaml
|
||||
skills/dialogue/world-simulator/recipes/catalog.yaml
|
||||
```
|
||||
|
||||
（历史示例 `skills/novel/weird-rules-short`、`theater-roleplay` 已不在仓库。）
|
||||
|
||||
---
|
||||
|
||||
## 8. 解析与加载（将来代码）
|
||||
## 7. 与其它文档
|
||||
|
||||
| 文件 | 干嘛的 |
|
||||
|---|---|
|
||||
| `src/skills/types.ts` | SkillIndexEntry、ParsedSkill 类型 |
|
||||
| `src/skills/loader.ts` | 扫描 skills/、解析 frontmatter + 正文 |
|
||||
| `src/skills/registry.ts` | 读 registry.yaml 或目录扫描 |
|
||||
| `src/skills/resolver.ts` | 根据黑板 index 推断当前 stage |
|
||||
|
||||
加载流程：
|
||||
|
||||
```text
|
||||
listSkills() → SkillIndexEntry[]
|
||||
loadSkill(skillId) → ParsedSkill（含 startupInquiry 解析自 ## 启动询问）
|
||||
selectSkill(session, skillId) → session.slots.activeSkill
|
||||
getStartupPrompt(activeSkill) → 流程 2 展示文案
|
||||
buildSkillContext(activeSkill, blackboardIndex) → 编排器 prompt 片段
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 10. 与 creation-playbook.md 的关系
|
||||
|
||||
`creation-playbook.md` 描述**概念与数据结构**（Playbook、Stage、InquiryPolicy）。
|
||||
|
||||
**本文件**描述**落盘格式**（SKILL.md 怎么写、放哪、启动时怎么选）。
|
||||
|
||||
关系：
|
||||
|
||||
```text
|
||||
Creation Playbook（概念）
|
||||
= SKILL.md（存储）+ stages.yaml（可选结构化）
|
||||
+ session.slots.activeSkill（运行时）
|
||||
```
|
||||
|
||||
`creation-playbook.md` 中的 TS 类型，实现时可从 SKILL.md 解析或从 stages.yaml 读取。
|
||||
|
||||
---
|
||||
|
||||
## 11. 第一版范围
|
||||
|
||||
```text
|
||||
skills/ 目录 + 示例 orchestrator 包
|
||||
启动 → 自动绑定默认 orchestrator → intake（描述需求）
|
||||
编排器 prompt 注入 skill 摘要
|
||||
registry.yaml 可选（legacy 包 / 读档兼容）
|
||||
```
|
||||
|
||||
不做：
|
||||
|
||||
```text
|
||||
skill 可视化编辑器
|
||||
运行时 LLM 自动生成 skill
|
||||
与 Cursor .cursor/skills 混用（路径独立）
|
||||
```
|
||||
`creation-playbook.md` 描述创作/游玩流程概念。
|
||||
本文件描述包怎么存、启动时怎么绑。
|
||||
方法正文见 `design-orchestrator-guide.md`。
|
||||
|
||||
+1
-1
@@ -452,5 +452,5 @@ flowchart TB
|
||||
| `runtime-state-machine.md` | `waitingReason` 定义 |
|
||||
| `worker-skill-format.md` | `ask_user` / 提问侧契约 |
|
||||
| `run-snapshot.md` | 快照与分支；左轨/检查器入口 |
|
||||
| `implementation-guide.md` | `web/*` 文件职责 |
|
||||
| `implementation-guide.md` | 写代码规则与文档地图 |
|
||||
| `book-storage.md` | 作品、存档、资产形态 |
|
||||
|
||||
+1
-1
@@ -183,7 +183,7 @@
|
||||
| `input` | 补充说明 | 发送 / 补充并发送 |
|
||||
| `worker_questions` | 答题 | 补充并发送；已进技能步时旁挂「返回节点」 |
|
||||
| `approve_step` | 确认 | 同意并开始；重进已完成节点时文案为「回头修改 · {技能名}」；次要为「返回节点」 |
|
||||
| `pick_creation_step` | 选节点 | 点可进入的节点即开始；要改排在底栏写意见再发 |
|
||||
| `pick_creation_step` | 选节点 | 点图上可进入的节点即开始；要看技能池点上方「技能」；要改排在底栏写意见再发 |
|
||||
| `review_artifact` | 视产物（勿一律「验收」） | **流程编排** → 确认编排；技能步 → 接受；开场 → 选定此开场。旁挂「按意见改编排 / 按意见修改」 |
|
||||
| `next_intent` | 说话 | 继续（可留空） |
|
||||
| `revision` | 说话 | 按意见修改 |
|
||||
|
||||
@@ -8,6 +8,7 @@
|
||||
> **游玩呈现壳**：**`docs/play-presentation-shells.md`**（预览页 `/shells.html`）。
|
||||
> **主世界层↔旁观怎么配合**：**`docs/play-dm-auditor.md`**。
|
||||
> **提示词待改清单**：**`docs/briefs/prompt-revision-inventory.md`**。
|
||||
> **design-flow 提示词人工审查**：**`docs/briefs/design-flow-prompt-review.md`**。
|
||||
> **给外部 AI 的完整泛用规范**：**`docs/briefs/capability-authoring-brief.md`**（含 `context-fragment.v1`）。
|
||||
|
||||
## 两层
|
||||
@@ -44,7 +45,10 @@
|
||||
name: …
|
||||
id: …
|
||||
artifact: 设计.…
|
||||
declaration: …
|
||||
declaration: … # 规划第一眼：解决什么缺口
|
||||
when: … # 对照现场能判定才排
|
||||
when_not: … # 每条指向另一技能或「不排」
|
||||
boundary: …
|
||||
```
|
||||
|
||||
## opening
|
||||
@@ -93,7 +97,18 @@ declaration: …
|
||||
| `params` | 可选；普通节点=编排期 `steps[].params` 声明（必填项须在进执行前钉齐）。〔先验产物〕=规划产物字段（可提前填，空则步内钉） |
|
||||
| `opening` | 可选覆盖；一般只写在 prompt 的 `opening` 块 |
|
||||
|
||||
编排器注入【能力 · 可选工序】时，会读取各能力 `prompt.md` 的 `meta`（`declaration` / `when` / `when_not` / `boundary`），**不是**只看 catalog 短声明。执行全文仍只在 design-step 注入。
|
||||
编排器注入【能力 · 可选工序】时，会读取各能力 `prompt.md` 的 `meta`（`declaration` / `when` / `when_not` / `boundary`），**不是**只看 catalog 短声明。执行全文（`task` / `opening` / `output` 等）仍只在 design-step 注入。
|
||||
|
||||
**写给规划，不是写给执行：**
|
||||
|
||||
| 字段 | 规划用来做什么 | 怎么写 |
|
||||
|------|----------------|--------|
|
||||
| `declaration` | 扫描池时的第一眼 | 解决什么缺口；不要写产物 JSON 长什么样 |
|
||||
| `when` | **现在**要不要进近期 DAG | 对照用户话、已验收步骤、已有产物就能判定的信号（还不能回答哪句 / 已有哪份产物） |
|
||||
| `when_not` | 缺口其实该交给谁，或明确跳过 | 每条指向另一个技能或「不排」；不要只写禁止 |
|
||||
| `boundary` | 别和邻居排重 | 本步定什么 / 不定什么 / 交给谁 |
|
||||
|
||||
`when` 里不要搬 `task` 的执行细则。配方 `process` 只写方法顺序（如收成链、默认槽），**不要再抄各技能调用条件**。
|
||||
|
||||
### 配方 `recipe.yaml`
|
||||
|
||||
@@ -161,9 +176,10 @@ recipes/world-simulator|expand-assistant/recipe.yaml
|
||||
| 生成规则 | `generation-rules` | **已写**：`context-fragment.v1`；宽原则 + 严合同键；可反复；**〔先验产物〕**；规划字段 `target`；挂 gm+auditor；**专用卡已接** |
|
||||
| 具体实例 | `concrete-instances` | **已写**：`context-fragment.v1`；只按规则执行；可反复；**〔先验产物〕**；规划字段 `rule_id` |
|
||||
| 叙事指南与故事推进 | `narrative` | **已写**：一份全文双挂；**不**为省 token 拆投影；结构化卡 |
|
||||
| 拓扑图谱 | `topology` | 骨架，待细写（拟改为选项小循环或降级） |
|
||||
| 设计监控栏 | `status-bar` | **已写**：只盯会变信息；通用 fragment 卡 |
|
||||
| 正文组成 | `reply-format` | **已写**：壳适配 + 正文.`示例`（present.v1 预览，看美化）；P2 present 渲染已接 |
|
||||
| 拓扑图谱 | `topology` | 必须生成且不适合走生成规则→实例时，用拓扑结构写出（升级路径、地图、人物关系等） |
|
||||
| 回复呈现 | `status-bar` | **已写**：每轮终稿看什么（正文/字数/日期/变量）；旧称设计监控栏 |
|
||||
| 随机范围整理 | `random-range` | **已写**：汇总检定/对抗等随机项与范围；正文组成之前；替代机遇裁定槽 |
|
||||
| 正文组成 | `reply-format` | **已写**：把回复呈现清单展示出来；选壳+美化，可写 CSS/HTML/JS；可接隐藏备用随机区 |
|
||||
| 变量设计与更新规则 | `variable-design` | **已写**；专用/结构化卡 |
|
||||
| 变量控制上下文 | `variable-context` | **已写**：旁观汇总；mount 含 auditor；通用 fragment 卡 |
|
||||
| 开场白与开场变量 | `opening-setup` | **已写**：开场守版式+同真相初值；**〔收口〕**选定后落库并保存定稿 |
|
||||
@@ -172,13 +188,13 @@ recipes/world-simulator|expand-assistant/recipe.yaml
|
||||
|
||||
| 能力 | id | 状态 |
|
||||
|------|-----|------|
|
||||
| 游玩拓扑 | `worker-spec` | **已写**：勾选固定槽（含旁观维护 auditor）；禁自由发明 worker |
|
||||
| 游玩拓扑 | `worker-spec` | **已写**：不能吃默认槽才勾选；主世界必要；有变量开旁观；禁机遇槽与自由发明 worker |
|
||||
| 上下文投影排序 | `context-order` | **已写**：扁平投影序（含对话.历史；旁观维护默认无历史）；收成进 `context_order`；Runtime 已拼装 |
|
||||
| 细化终稿 | `refine` | **已写**：按 `play_slots`（及排序表）收成 `设计.worker集` |
|
||||
|
||||
| 编排器 | 状态 |
|
||||
|------|------|
|
||||
| 世界模拟器 | 创作链路已写；**play**：`gm → perspective? → narrator → auditor`；gm harness 批量 chance；settlement/maintain 合并变量已接 |
|
||||
| 世界模拟器 | 创作链路已写；**play**：`gm → perspective? → narrator → auditor`；真随机改走随机范围表+程序插数（机遇槽弃用）；settlement/maintain 合并变量已接 |
|
||||
| 扩写助手 | 方法论已写；起点：美学纲领与交互范式；勿默认套世界模拟全套 |
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user