改写回合推演技能合同，并接上画面工作流库。
旧产物名仍能读到，避免改名后上下文对不上。 Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Cursor
@@ -0,0 +1,11 @@
|
||||
# 壳生图
|
||||
|
||||
> 状态：以后再说。记录：2026-10-11。
|
||||
> 不在每层配图的第一版里做。
|
||||
|
||||
呈现壳的美化图（背景、角色立绘等）以后可以走 ComfyUI。和游玩每层配图分开：
|
||||
|
||||
- 每层配图跟着回合，挂在对应楼层上，主世界层不读。
|
||||
- 壳上的图换得更慢，多半在开场或人物、地点稳定之后才出，由前端填进壳里预留的图位。
|
||||
|
||||
提示词仍归旁观副 LLM。主世界层不写图片地址，图也不进正文呈现和下一轮上下文。
|
||||
@@ -125,6 +125,7 @@
|
||||
| Intake | **需求描述** | 启动填空 | — |
|
||||
| Burst | **本轮调度** | — | 少对用户说 burst。 |
|
||||
| Questions card | **询问卡** | Questions | 详见 `ui-design.md` §8。 |
|
||||
| Direct chat / `direct-chat` | **直聊** | — | 与作品「对话」并列的轻量多轮 LLM 面；两层（上下文壳 → 会话）。见 `direct-chat.md`。 |
|
||||
|
||||
---
|
||||
|
||||
@@ -206,6 +207,7 @@
|
||||
| `interaction` | 交互范式（旧；已并入上一行） |
|
||||
| `narrative_guide` | 叙事指南与故事推进 |
|
||||
| `narrative-guide` | 叙事指南（对话落盘） |
|
||||
| `image-prompt` | 画面与生图（对话落盘） |
|
||||
| `story-progression` | 故事推进（对话落盘） |
|
||||
| `user-requirements` | 用户需求（偏好库选用） |
|
||||
| `input_protocol` | 输入协议 |
|
||||
|
||||
@@ -173,12 +173,13 @@ recipes/world-simulator|expand-assistant/recipe.yaml
|
||||
|------|-----|------|
|
||||
| 美学纲领与交互范式 | `aesthetics-interaction` | **范例已写**；前端 mosaic 视图 |
|
||||
| 主角设定 | `protagonist` | **已写**：代入名片（名字/背景/特殊设定）；挂在当前选用的用户角色卡下；关掉这局就不加载 |
|
||||
| 实现机制 | `mechanism` | **已写**：`context-fragment.v1`（支撑点正文 + 自评 + 追问）；`feeds: gm`；**专用卡已接** |
|
||||
| 世界法则 | `mechanism` | **已写**：`context-fragment.v1`（法则 + 连锁）；旧称实现机制，产物旧 tag `设计.实现机制` 仍可读；`feeds: gm`；**专用卡已接** |
|
||||
| 舞台骨架 | `world-blueprint` | **已写**：`context-fragment.v1`；社会结构 + 世界状况；**专用卡已接** |
|
||||
| 生成规则 | `generation-rules` | **已写**：`context-fragment.v1`；方向池优先、元素池仅封闭集合；可反复；**〔先验产物〕**；规划字段 `target`；挂 gm+auditor；**专用卡已接** |
|
||||
| 具体实例 | `concrete-instances` | **已写**：`context-fragment.v1`；只按规则执行；可反复；**〔先验产物〕**；规划字段 `rule_id` |
|
||||
| 叙事指南与故事推进 | `narrative` | **工序编排**：一份全文双挂；结构化卡。对话落盘不排本步 |
|
||||
| 叙事指南 | `narrative-guide` | **对话落盘**：遣词/笔墨/禁忌/写法档；`intake: dictate` |
|
||||
| 画面与生图 | `image-prompt` | **对话落盘**：从工作流库选一种并写提示词合同；只挂旁观；`intake: dictate` |
|
||||
| 故事推进 | `story-progression` | **对话落盘**：推进方式 + 用户输入用法；`intake: dictate` |
|
||||
| 拓扑图谱 | `topology` | 必须生成且不适合走生成规则→实例时，用拓扑结构写出（升级路径、地图、人物关系等） |
|
||||
| 回复呈现 | `status-bar` | **已写**：每轮终稿看什么（正文/字数/日期/变量）；旧称设计监控栏 |
|
||||
|
||||
@@ -1,23 +1,26 @@
|
||||
# 美学纲领与交互范式
|
||||
# 美学纲领
|
||||
|
||||
## meta
|
||||
|
||||
```meta
|
||||
name: 美学纲领与交互范式
|
||||
name: 美学纲领
|
||||
id: aesthetics-interaction
|
||||
artifact: 设计.美学纲领与交互范式
|
||||
artifact: 设计.美学纲领
|
||||
declaration: >
|
||||
提取用户最想反复获得的核心体验与让它成立的承重内核，写成给后续能力读的美学纲领；
|
||||
同时钉清交互范式：人称视角、模型可代写什么、用户保留什么、后果由谁裁定、何时停笔。
|
||||
提取用户最想反复获得的核心体验和让它成立的承重内核。
|
||||
体验锚定只留三句短锚：站位、核心感觉、轮转停点。描写权限、后果裁定和停笔做法与推进合同一起写在故事推进与交互范式。
|
||||
when: |
|
||||
用户要的是叙事、角色扮演或持续互动，但还不能明确说出：最想反复获得什么体验、自己站在什么位置、轮转到哪必须停等用户。
|
||||
用户主动改变核心体验、代入站位或关键权限时也应重写。
|
||||
用户要的是叙事、角色扮演或持续互动，但还不能明确说出最想反复获得什么体验时使用。
|
||||
用户主动改变核心体验时也应重写。站位与轮转停点若已有短句，只补体验，不在本步展开权限。
|
||||
when_not: |
|
||||
本局不依赖体验契约的纯转换、资料整理或机械格式任务，可不使用。
|
||||
只改遣词和具体写法 → 叙事指南；只改推进与输入用法 → 故事推进；只改舞台详情或硬法则 → 对应能力。
|
||||
只改谁代写、谁裁定、何时停笔、输入用法或篇幅 → 故事推进与交互范式。
|
||||
只改遣词和具体写法 → 叙事指南。只改舞台或硬法则 → 对应能力。
|
||||
boundary: |
|
||||
本能力只交三块：美学纲领（体验是什么、怎样发生、呈现尺度）、背景与规则的承重内核、交互范式（视角、描写权限、后果控制、停笔）。
|
||||
背景与规则只提取承重内核，不扩写百科；舞台细节归舞台骨架，可执行硬法则归实现机制；具体遣词句式归叙事指南。
|
||||
本步只交美学纲领、背景与规则的承重内核，以及体验锚定三句。
|
||||
体验写在 `体验内核` 一处；同义的发生方式、角色人文、描写焦点省略。
|
||||
背景内核写成后续可引用的短句。场所归舞台骨架，因果归世界法则，遣词归叙事指南。
|
||||
交互权限与推进合同归故事推进与交互范式，本步不写描写权限表。
|
||||
feeds: design_only
|
||||
```
|
||||
|
||||
@@ -42,27 +45,24 @@ feeds: design_only
|
||||
## task
|
||||
|
||||
```task
|
||||
从用户材料中提取一份体验契约，写入 `设计.美学纲领与交互范式`。它是后续所有能力取舍的依据，也会挂给主世界层与转述层直接阅读。产物回答三件事：
|
||||
从用户材料提取体验契约，写入 `设计.美学纲领`。它给后续能力做取舍，不进游玩投影。产物回答两件事，并留下三句短锚：
|
||||
|
||||
1. 美学纲领：用户最想反复获得什么体验，它通过什么关系、处境、感官或选择反复发生，呈现时的氛围与尺度。
|
||||
2. 背景与规则：删掉就会让这份体验不成立的最小承重前提，以及它如何约束人物、选择与后果。
|
||||
3. 交互范式：用户与所扮演角色的关系、人称与视角、模型对 user 每类行为能代写到哪一步、世界后果由谁裁定、何时必须停笔等用户。
|
||||
1. 美学纲领：用户最想反复获得什么体验，它靠什么关系或处境反复发生，呈现时的尺度。体验本身只写在 `体验内核`。
|
||||
2. 背景与规则：删掉就会让这份体验不成立的最小前提，写成后续能原句引用的短句。
|
||||
3. `体验锚定`：站位、核心感觉、轮转停点各一句。完整的谁代写、谁裁定、怎么停笔，留给故事推进与交互范式。
|
||||
|
||||
保留用户自己的重点、用词和尺度。材料不足时少写或写「未定」，把真正影响体验或权限的缺口交给 `self_score.gap`；产物正文不放评分、诊断、追问或开放问题。
|
||||
保留用户自己的重点、用词和尺度。材料不足时少写或写「未定」，真正影响体验的缺口进 `self_score.gap`。正文不含评分、诊断或追问。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 核心是用户想要的体验；其余字段都是为了让它稳定地反复发生。完善设定时回头核对原本的核心体验，不让它被设定冲淡。
|
||||
2. 核心体验不是题材、剧情简介或情绪标签：写用户如何参与、体验怎样反复发生。同一设定不同用户要的可以完全不同（角斗士：荣耀 / 自由 / 血与酒），找到这个人要的那一个，而不是补全世界观。
|
||||
3. 变造世界先抓「原型 + 变在哪里」；核心体验往往来自变点。背景与规则只写承重内核：关键关系、社会前提、世界规则或作用机制。
|
||||
4. 用户常说不清想要什么：展示优于提问，大胆优于保守；用两种站位或两种感觉的短场景让用户选或改；负面信号同样有效。用户可以说不，随时准备整份改写。
|
||||
5. 用户要的内容去道德化、常态化处理：按用户给的尺度写进「边界与尺度」，写清服务体验的用法与真正的禁忌，不替用户加或减尺度。
|
||||
6. 交互范式写可执行权限，不写口号。描写权限按行为类别逐项写：哪些模型可直接代写、哪些只写到起势就停、哪些必须留给用户；「用户输入后」写模型对一句输入是只确认、补细节还是连带推出后果。
|
||||
7. 交互范式要保护美学纲领：权限、视角和停笔点的设置要让核心体验更容易发生，两者矛盾时以美学纲领为准改范式。
|
||||
8. 本步不扩写世界百科，不制定完整硬机制，不细化遣词句式，不决定故事推进方法，不输出执行单元列表或插入 order。
|
||||
9. 用户改口导致体验内核改变时整份重写，不在旧契约后追加互相冲突的补丁。
|
||||
1. 核心是用户想反复获得的体验。其余字段只为让它稳定发生。设定变长时，先核对体验句还在不在。
|
||||
2. 体验不是题材、剧情简介或情绪标签。写用户怎么参与、它怎样反复发生。同一设定可以要荣耀、自由或血与酒，只写这个人要的那一个。
|
||||
3. 先抓「原型 + 变在哪里」。`核心内核` 只留删掉体验就不成立的那一句关系、社会前提或规则。场所、因果链、价目不在这里展开。
|
||||
4. 用户说不清时，用两种站位或两种感觉的短场景让用户选；问在回复里，不写进产物。用户改口导致内核变了，整份重写，不在旧契约后打补丁。
|
||||
5. 尺度按用户给的写进 `边界与尺度`：服务体验的用法，以及真正的禁忌。不替用户加码或减码。
|
||||
6. `发生方式`、`角色人文`、`作用方式`、`描写焦点` 与体验内核或核心内核同义时整项省略。描写焦点只点注意力放在哪类瞬间，不写遣词，不写示范段，不写权限表。
|
||||
```
|
||||
|
||||
## probe
|
||||
@@ -72,7 +72,7 @@ feeds: design_only
|
||||
|
||||
用户首句、默认问题首答或黑板「用户.需求」里已有的直接采纳，已答清的不重问。
|
||||
|
||||
缺其中一件：回复里只问这一件，给 2～3 个带短场景的建议选项，不问开放式「你还想要什么」。三件已清：再挑一个最影响体验的薄弱点（视角、某类描写权限、尺度）给选项；都够用就不再追问。
|
||||
缺其中一件：回复里只问这一件，给 2～3 个带短场景的建议选项，不问开放式「你还想要什么」。三件已清：再挑尺度或描写焦点里最影响体验的一点给选项；权限和停笔做法留给故事推进与交互范式，本步不再追问。
|
||||
|
||||
用户讲到人物、舞台、规则细节：只抽取能改变体验、站位或权限的那一句写进正文，其余留给对应能力，本步不追问细节。
|
||||
```
|
||||
@@ -82,112 +82,87 @@ feeds: design_only
|
||||
```output
|
||||
{
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "美学纲领与交互范式",
|
||||
"brief": "一句话点出用户最想反复获得的核心体验",
|
||||
"技能": "美学纲领",
|
||||
"brief": "一句话：用户最想反复获得的核心体验",
|
||||
"体验锚定": {
|
||||
"站位": "用户与所扮演角色/作品的关系：代入、部分代入、旁观或操控",
|
||||
"站位": "代入、部分代入、旁观或操控",
|
||||
"核心感觉": "最想反复获得的体验",
|
||||
"轮转停点": "何时必须停笔等待用户"
|
||||
},
|
||||
"mount": ["world-simulator", "narrator"],
|
||||
"mount": [],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"美学纲领": {
|
||||
"体验内核": "给后续能力和游玩层读的纲领正文，可多段：用户要反复感到什么、它靠什么关系或处境成立、从哪一刻开始、怎样被反复兑现",
|
||||
"发生方式": "体验通过哪些关系、处境、感官或选择反复发生",
|
||||
"角色人文": "关键人物关系中的权力、尊严、亲疏或人性张力；无则省略",
|
||||
"体验内核": "一段：反复感到什么，靠什么关系或处境成立，怎样被反复兑现",
|
||||
"发生方式": "可选；内核没写到的反复条件",
|
||||
"角色人文": "可选；内核没写到的权力、尊严或亲疏",
|
||||
"呈现要点": {
|
||||
"氛围基调": "整体质感与情绪温度",
|
||||
"描写焦点": "注意力放在哪里：哪些瞬间、反应、细节值得放慢写；具体遣词交给叙事指南",
|
||||
"边界与尺度": "色情/暴力/血腥等按用户给的尺度：服务体验的用法与真正的禁忌",
|
||||
"其它要点": ["反差、日常化、节奏偏好等短条；无则省略"]
|
||||
"氛围基调": "整体质感",
|
||||
"描写焦点": "注意力放在哪类瞬间；不写遣词",
|
||||
"边界与尺度": "按用户尺度：服务体验的用法与真正的禁忌",
|
||||
"其它要点": ["可选短条"]
|
||||
}
|
||||
},
|
||||
"背景与规则": {
|
||||
"原型与变点": "熟悉的原型世界，以及变在哪里；无变造则省略",
|
||||
"核心内核": "让体验成立的最小承重前提",
|
||||
"作用方式": "它如何约束人物、选择与后果，怎样持续制造该体验",
|
||||
"非必要设定": "明确本步不展开的装饰信息；无则省略"
|
||||
},
|
||||
"交互范式": {
|
||||
"前置配置": {
|
||||
"用户与user关系": "完全代入 / 部分代入 / 旁观 / 操控，及其含义",
|
||||
"人称": "如：第二人称称「你」",
|
||||
"元叙事": "如：不跳出故事直接问卷，决策用情节呈现"
|
||||
},
|
||||
"叙事视角": {
|
||||
"主要视角": "镜头跟谁、看什么",
|
||||
"视角切换": "禁止，或允许的例外",
|
||||
"可写内心": "可以写谁的内心；如仅 user 或仅 NPC 外显",
|
||||
"不呈现的信息": "user 不该知道、正文不能透露的内容"
|
||||
},
|
||||
"描写权限": {
|
||||
"思考与抉择": "关键决定是否只能由用户做，模型写到哪里停",
|
||||
"言语": "模型能否替 user 说话、说到什么程度",
|
||||
"主动行动": "模型能否替 user 发起行动",
|
||||
"情绪与身体反应": "模型可补写的生理与情绪反应",
|
||||
"习惯与既有技能": "模型可按既有设定自动执行的部分",
|
||||
"外在状态": "外貌、伤势、衣着等可否直接描写",
|
||||
"用户输入后": "对用户一句输入：只确认 / 补细节 / 连带推出后果"
|
||||
},
|
||||
"后果与叙事控制": {
|
||||
"行为后果判定": "谁裁定 user 行为的成败与代价",
|
||||
"世界对user的影响": "NPC 与世界如何主动作用于 user",
|
||||
"时间与场景": "模型可否推进时间、切换场景，跨度多大",
|
||||
"引入新内容": "模型可否主动引入新人物、事件、威胁",
|
||||
"设计困境": "是否主动给 user 制造两难；怎样的两难服务体验"
|
||||
},
|
||||
"停笔时机": "必须等用户输入的明确时机"
|
||||
"原型与变点": "原型世界，以及变在哪里；无变造则省略",
|
||||
"核心内核": "后续可引用的一句承重前提",
|
||||
"作用方式": "可选；这句前提约束哪类选择或后果",
|
||||
"非必要设定": "可选；本步不展开的范围"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. 输出合法 JSON。`体验锚定` 三项必填短句：开场白写入前程序按它判定体验是否已锚定，缺项会拒绝写入开场白。
|
||||
2. `正文` 只含 `美学纲领`、`背景与规则`、`交互范式` 三块，每块是对象，不写成一段散文。未知字段写「未定」或省略，不编造百科。
|
||||
3. 不在产物里写 `自评`、`追问`、`开放问题`、完备度、评分依据或用户回复；缺口交给 `self_score.gap`。
|
||||
4. `mount` 固定包含 `world-simulator` 与 `narrator`；不写数字 `order`，不输出执行单元列表。
|
||||
1. 合法 JSON。`体验锚定` 三项必填短句。`mount` 固定 `[]`。
|
||||
2. `正文` 只含 `美学纲领`、`背景与规则`。不写 `交互范式`。键名不用「核心体验」「参与边界」「描写信号」。
|
||||
3. `体验内核` 与 `核心内核` 各只写一次。同义的可选槽整项省略。
|
||||
4. 未知写「未定」或省略。正文不含评分、追问、权限表、舞台清单、法则全文或推进方案。
|
||||
|
||||
## score
|
||||
|
||||
```score
|
||||
美学纲领：
|
||||
- 5：准确提取用户最想反复获得的体验，写清它怎样反复发生、从哪一刻成立，呈现焦点与尺度贴合用户原话；后续能力可据此取舍。
|
||||
- 3：大方向正确，但仍偏题材或情绪概括，或体验如何反复发生、尺度如何把握尚不明确。
|
||||
- 1：误读用户重点，只有剧情简介、设定标签或泛化氛围。
|
||||
- 5：体验内核写清反复感到什么、怎样兑现；可选槽没有把这句话再写一遍；尺度贴用户原话。
|
||||
- 3：方向对，但仍是题材或情绪标签，或发生方式在复读内核。
|
||||
- 1：只有剧情简介或设定堆砌。
|
||||
|
||||
交互范式：
|
||||
- 5：站位、人称视角、逐类描写权限、后果裁定与停笔时机都可执行，且在保护核心体验。
|
||||
- 3：有站位与停笔，但描写权限笼统，或某类行为（言语、行动、反应）谁来写仍不清。
|
||||
- 1：只有口号式描述，或权限设置与核心体验矛盾。
|
||||
体验锚定：
|
||||
- 5：站位、核心感觉、轮转停点各是一句可核对的短锚，没有展开成权限表。
|
||||
- 3：三件都有，但某一件是空话或和体验内核无关。
|
||||
- 1：缺件，或把描写权限、停笔做法写进本产物。
|
||||
|
||||
背景与规则：
|
||||
- 5：找到让核心体验成立的最小内核——关键关系、背景前提或作用规则，并说明它怎样持续制造该体验。
|
||||
- 3：找到相关前提，但内核过宽、因果不清，或混有较多装饰设定。
|
||||
- 1：没找到承重内核；只有百科堆砌，或规则与核心体验无关。
|
||||
- 5：核心内核是一句删掉体验就不成立的前提，后续能引用。
|
||||
- 3：找到前提，但过宽，或作用方式在复读内核。
|
||||
- 1：百科，或与体验无关。
|
||||
```
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] `体验锚定` 三项（站位、核心感觉、轮转停点）都已写出？
|
||||
- [ ] 美学纲领写的是用户反复获得什么、怎样发生，而非题材或剧情简介？体验内核能直接给游玩层读？
|
||||
- [ ] 背景与规则是删掉就会破坏体验的最小内核？
|
||||
- [ ] 交互范式逐类写清描写权限、后果裁定和停笔时机，并且在保护美学纲领？
|
||||
- [ ] 未扩写舞台百科、硬机制、具体文风或推进方案？
|
||||
- [ ] 产物正文不含评分、诊断、追问和开放问题？
|
||||
- [ ] `体验锚定` 三项都已写出？
|
||||
- [ ] 体验只在 `体验内核` 写清，同义槽已省略？
|
||||
- [ ] `核心内核` 是后续能引用的短句，不是舞台或法则全文？
|
||||
- [ ] 体验锚定是三句短锚，没有描写权限表？
|
||||
- [ ] 正文无评分、诊断、追问？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：
|
||||
- brief 点题「垄断生存资源的绝对掌控感」；美学纲领的体验内核写清掌控感从哪一刻成立、靠什么反复兑现，边界与尺度照用户原话；交互范式写明 user 的抉择只由用户做、模型可补身体反应与习惯动作、NPC 的屈服与反抗由模型裁定、每次 NPC 给出回应后停笔。
|
||||
- 体验内核：「反复感到垄断生存资源的掌控；对方因资源断供而让步或反抗时兑现。」发生方式与这句话同义，省略。
|
||||
- 核心内核：「物资只从用户控制的仓库流出。」作用方式一句：「拒绝供货会在下一顿改变对方的选择。」不写仓库在哪条街。
|
||||
- 体验锚定：站位「完全代入」；核心感觉「断供时的掌控」；轮转停点「对方让步或反抗后等用户决定供不供」。
|
||||
|
||||
坏：
|
||||
- 只有一段散文纲领，三块没有拆成对象。
|
||||
- 百科式背景堆砌，看不出体验靠哪条前提成立。
|
||||
- 交互范式只写「尊重玩家选择」，没说言语、行动、反应各由谁写。
|
||||
- 在正文里写评分、追问或「待确认」清单。
|
||||
缺料时：
|
||||
- 站位、核心感觉、轮转停点缺一件 → 回复里只问这一件，产物里该项写「未定」或先不落盘。
|
||||
- 用户只给了题材词 → 不编体验，gap 问他要反复感到的那一种。
|
||||
|
||||
偏了就改回：
|
||||
- 体验内核、发生方式、角色人文、描写焦点四段同一句掌控感 → 留体验内核，其余省略。
|
||||
- 核心内核写成古武阶梯、五阶段链或十阶价目 → 收成一句前提。阶梯和价目留给拓扑图谱，因果留给世界法则。
|
||||
- 描写焦点写成一段感官范文 → 改成「注意力放在让步或反抗的那一刻」。
|
||||
- 用「核心体验 / 描写信号」当键，或在本步写描写权限表 → 体验留在本产物，权限改写入故事推进与交互范式。
|
||||
```
|
||||
|
||||
@@ -21,7 +21,7 @@
|
||||
# （declaration / when / when_not / boundary）注入 design-flow。
|
||||
# when/when_not 必须是规划对照用户话与已有产物就能判定的信号；调用条件写在技能 meta，不要写进配方 process。
|
||||
#
|
||||
# 标准范例：aesthetics-interaction（美学纲领与交互范式）
|
||||
# 标准范例：aesthetics-interaction（美学纲领）
|
||||
# 后来写能力：同结构 prompt.md（含默认问题）+ 本表一行索引
|
||||
#
|
||||
# 世界模拟器常用能力见下「体验→世界→机制→呈现→收成」；编排按需选用，勿默认全选。
|
||||
@@ -43,13 +43,13 @@ modules:
|
||||
|
||||
# —— 体验契约 ——
|
||||
- id: aesthetics-interaction
|
||||
name: 美学纲领与交互范式
|
||||
name: 美学纲领
|
||||
layer: final
|
||||
mount: [world-simulator, narrator]
|
||||
declaration: >-
|
||||
钉清用户会在意的体验承诺：站位、反复感到什么、轮转何时停。
|
||||
询问相近故合为一步。
|
||||
artifact: 设计.美学纲领与交互范式
|
||||
artifact: 设计.美学纲领
|
||||
|
||||
- id: protagonist
|
||||
name: 主角设定
|
||||
@@ -119,7 +119,7 @@ modules:
|
||||
libraries: [style-packs]
|
||||
declaration: >-
|
||||
美学已有方向时：把感觉落成可执行的遣词、笔墨落点、禁忌与推进方式；
|
||||
不重做体验问卷。工序编排用本步；对话落盘拆成「叙事指南」「故事推进」
|
||||
不重做体验问卷。工序编排用本步；对话落盘拆成「叙事指南」「故事推进与交互范式」
|
||||
artifact: 设计.叙事指南与故事推进
|
||||
|
||||
- id: narrative-guide
|
||||
@@ -129,12 +129,12 @@ modules:
|
||||
layer: final
|
||||
mount: [narrator, world-simulator]
|
||||
declaration: >-
|
||||
从文风库选取本局写法（默认 1～2，确需可到 3），
|
||||
落成风格推荐与要求、笔墨落点、少量禁忌与可选写法档；不钉推进
|
||||
从文风库写成遣词、视角执行、段落形态、笔墨落点和少量禁忌；
|
||||
体验句留在美学纲领，不钉推进
|
||||
artifact: 设计.叙事指南
|
||||
|
||||
- id: story-progression
|
||||
name: 故事推进
|
||||
name: 故事推进与交互范式
|
||||
intake: dictate
|
||||
libraries: [preferences]
|
||||
layer: final
|
||||
@@ -142,17 +142,28 @@ modules:
|
||||
declaration: >-
|
||||
从偏好库选取约束，只选定一种用户输入用法，
|
||||
并写清每一轮里扩写（演本轮材料）与续写（材料后往下写）的定义、比例与 OOC 处理；不写遣词
|
||||
artifact: 设计.故事推进
|
||||
artifact: 设计.故事推进与交互范式
|
||||
|
||||
- id: image-prompt
|
||||
name: 画面与生图
|
||||
intake: dictate
|
||||
libraries: [image-workflows]
|
||||
layer: final
|
||||
mount: [auditor]
|
||||
declaration: >-
|
||||
从工作流库选定一种画面工作流，并写成旁观每轮可执行的生图提示词合同；
|
||||
游玩时不再改选。只挂旁观
|
||||
artifact: 设计.画面与生图
|
||||
|
||||
# —— 机制与数据 ——
|
||||
- id: mechanism
|
||||
name: 实现机制
|
||||
name: 世界法则
|
||||
layer: final
|
||||
mount: [world-simulator]
|
||||
declaration: >-
|
||||
保存世界中稳定成立的因果法则，供主世界层推演事件后果、
|
||||
剧情变化和人物反应；一次可写多条共同作用的机制
|
||||
artifact: 设计.实现机制
|
||||
写出世界相对熟悉基底的根本变造及其连锁（制度、权力、日常），
|
||||
以及金手指与玩法系统的固定规则；不预定人物对玩家的反应
|
||||
artifact: 设计.世界法则
|
||||
|
||||
- id: topology
|
||||
name: 拓扑图谱
|
||||
@@ -161,8 +172,8 @@ modules:
|
||||
mount: [world-simulator, auditor]
|
||||
repeatable: true
|
||||
declaration: >-
|
||||
为一个独有但结构复杂的对象定义节点、连接、初始图与开场后的维护规则；
|
||||
一份产物一张图，可按地图、关系链、升级树等对象反复
|
||||
为一张图定义节点、连接、初始图与开场后的维护规则。
|
||||
地图、关系链、升级树，以及社会阶梯、价目、兑换等级等有序标尺，都在这里；一份产物一张图
|
||||
artifact: 设计.拓扑图谱
|
||||
|
||||
- id: variable-design
|
||||
@@ -171,8 +182,8 @@ modules:
|
||||
layer: final
|
||||
mount: [world-simulator, auditor]
|
||||
declaration: >-
|
||||
定义必须跨轮保存的最少真值、合法更新条件、权限与派生映射，
|
||||
供程序选择简单状态工具或复杂维护副 Worker
|
||||
定义必须跨轮保存的最少真值、合法更新条件、权限与派生映射；
|
||||
默认值只留短事实，人物档案留在具体实例；有真值即旁观填表
|
||||
artifact: 设计.变量设计与更新规则
|
||||
|
||||
- id: variable-context
|
||||
@@ -190,7 +201,7 @@ modules:
|
||||
mount: [world-simulator, narrator]
|
||||
declaration: >-
|
||||
定义普通楼层每轮实际启用的语义区域、出现条件、权威来源与内容要求；
|
||||
可含隐藏更新语义区，不决定前端排版和渲染
|
||||
默认含文字选项；字数区间与占比照写故事推进与交互范式，不决定前端排版
|
||||
artifact: 设计.监控栏
|
||||
|
||||
- id: zero-layer-status
|
||||
|
||||
@@ -17,8 +17,9 @@ when_not: |
|
||||
一张有节点和连接的结构图 → 拓扑图谱。
|
||||
规则写明创作期不预填、只在游玩期生成 → 本步不写记录。
|
||||
boundary: |
|
||||
本能力只交一条记录。有规则则严格按字段、池或提示、填写工作流填写；无规则则只写用户给出的少量简单字段。
|
||||
不重议合同，不写世界百科，不改变量公式。一次写入多条时，程序按记录拆成多份产物。
|
||||
本步只交一条按合同填好的记录。有规则则按字段、池或提示、地板和工作流填写，填到地板即停。
|
||||
不重议合同，不把规则里的提示、分级表象或反例抄成正文，不预写尚未发生的场面。
|
||||
世界格局与硬法则留在舞台骨架和世界法则，本步只写这一条自己的事实。
|
||||
feeds: gm
|
||||
```
|
||||
|
||||
@@ -31,28 +32,27 @@ feeds: gm
|
||||
## task
|
||||
|
||||
```task
|
||||
写出一条具体实例，写入 `设计.具体实例#中文名`。一份产物只含一条记录。用户一次给出多条时，每条各写一份；若交来的是记录数组，程序会按条拆开。
|
||||
写出一条具体实例，写入 `设计.具体实例#中文名`。一份产物只含一条记录。用户一次给出多条时，每条各写一份；交来的是记录数组时，程序按条拆开。
|
||||
|
||||
有生成规则时：认定规则的中文名，按规则的字段、池或提示、填写工作流生成这一条；用户已写明的专名与结果只扩写不改写，未写字段从已有材料往下补满。无规则且只是一条字段很少的具名内容时：直接写用户给出的字段。
|
||||
有生成规则时：认定规则的中文名，按字段、池或提示、地板和填写工作流填这一条。用户已写明的专名与结果保持原样。未写字段从已有材料补到该字段的地板：地板是最低要看见或碰到的事实，补完即停。无规则且只是一条字段很少的具名内容时：只写用户给出的字段。
|
||||
|
||||
规则的一次生成为同批时：一次 insert 写齐本批，`记录` 写成数组，每项一条记录并带上规则里的姓名或名称字段，程序按条拆成多份。先定各条如何互指、对立、同场，再填各条字段。
|
||||
规则为同批时：一次写齐本批，`记录` 写成数组，每项一条并带上姓名或名称，程序按条拆成多份。先定各条如何互指、对立、同场，再填字段。
|
||||
|
||||
材料足够便直接成稿。缺的是合同本身时，先回到生成规则，不在这里补合同。产物正文不放评分、诊断、追问或开放问题。
|
||||
材料够就成稿。缺的是合同本身时，回到生成规则，不在这里补合同。规则里的硬门槛（年龄、禁止项、档位）对不上材料时，不把这条写成违规内容，缺口进 `self_score.gap`。正文只含记录 JSON，不含评分、诊断或追问。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 有规则：字段名、取值方式、工作流阶段与依赖都以规则为准；不增删字段，不改池。
|
||||
2. 池选取按合理度选择，不是程序抽签；提示约束按那句话的范围写开。
|
||||
3. 按填写工作流推进：先骨架后血肉；阶段依赖与自检能核对的，生成后要能过。
|
||||
4. 一份产物一条记录。单条规则一次写一条；多条各自成稿，用中文名称区分。
|
||||
5. 同批规则一次写齐本批：先对齐关系，再填字段；各条里互指的专名与关系必须一致（甲记乙为仇敌，乙也记甲，且说的是同一件事）。有关系的人在同一次里写完，不拆到不同轮。
|
||||
6. 句子级字段写到规则 `地板` 规定的可感知程度；词条、档位、数字可以短。句子级字段只丢一个词不算填完。
|
||||
7. 分级字段只填档位短值（如「金丹」）；表象留在规则的分级表现里，不复制进每条记录。
|
||||
8. 无规则只写用户点名的那一条，字段保持很少；不借机发明完整人设合同。
|
||||
9. 用户已写明的专名、关系、结果保持原样，只做厚度扩写；未写字段从这些材料延伸。
|
||||
10. 给人读的键和专名用中文。材料里的英文名音译成中文，不把英文原名留在字段值里。外壳的 schema、brief、mount 保持既有键。
|
||||
1. 有规则：字段名、取值方式、工作流与依赖以规则为准。不增删字段，不改池。
|
||||
2. 池选取按合理度选。提示是范围，按范围写这一条的事实，不把提示里的方向句原样贴进记录。
|
||||
3. 按工作流：先定会约束后面的项，再填其余。填完要能过规则的自检。
|
||||
4. 一份产物一条记录。同批一次写齐：先对齐关系，再填字段。互指的专名与事由必须一致，同一次写完。
|
||||
5. 句子级字段写到地板规定的可感知事实即停。词条、档位、数字保持短值。只丢一个词、低于地板，不算填完；写成一场戏、一段台词或「以后会怎样沦陷」，算写过了，收回到事实。
|
||||
6. 命门、突破口、限制类字段写失效条件：什么事实一发生，这项依仗就变了。不写征服过程。外貌写能认出的年龄感、衣服和一处外形，不写尚未发生的身体反应。
|
||||
7. 分级字段只填档位短值。表象留在规则的分级表现里，不抄进记录。舞台、机制、美学里已有的句子不在记录里再写一遍。
|
||||
8. 无规则只写用户点名的那一条，字段保持很少。
|
||||
9. 给人读的键和专名用中文。英文专名音译，不把英文原名留在字段值里。外壳的 schema、brief、mount 保持既有键。
|
||||
```
|
||||
|
||||
## output
|
||||
@@ -68,46 +68,56 @@ feeds: gm
|
||||
"规则": "所依生成规则的中文名；无规则时省略",
|
||||
"名称": "这条记录的中文名",
|
||||
"记录": {
|
||||
"字段名": "按规则字段或极简内容填写的值"
|
||||
"字段名": "按规则填到地板的事实；档位与数字保持短值"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. 输出合法 JSON。`记录` 是单个对象；规则为同批时写成至少 2 项的对象数组，每项带姓名或名称。`名称` 用中文，并与这条记录的主名称一致。
|
||||
1. 合法 JSON。`记录` 是单个对象；同批时写成至少 2 项的对象数组，每项带姓名或名称。`名称` 用中文，并与这条记录的主名称一致。`mount` 固定 `["world-simulator"]`。
|
||||
2. 有规则时 `记录` 的键必须来自该规则字段，不得增删。
|
||||
3. 无规则时省略 `规则`，`记录` 只含用户给出的少量简单字段。
|
||||
4. 字段名和专名用中文；英文专名音译为中文。
|
||||
5. 不在产物正文写自评、追问、开放问题或合同草稿。
|
||||
6. `mount` 固定为 `["world-simulator"]`。
|
||||
3. 每个句子级字段停在地板：可核对的事实，不附场面、台词或预告。分级只填短值。
|
||||
4. 无规则时省略 `规则`，`记录` 只含用户给出的少量简单字段。
|
||||
5. 字段名和专名用中文；英文专名音译。正文不含自评、追问、合同草稿或规则条文。
|
||||
|
||||
## score
|
||||
|
||||
```score
|
||||
工作流符合度：
|
||||
- 5：严格按规则填写工作流推进；字段、池选取、依赖与自检都落实；句子级字段达到地板；同批各条互指一致；无规则路径则字段简单够用且不越权发明合同。
|
||||
- 3：大体按工作流，但有一处阶段跳跃、依赖未咬合，或某句子级字段明显低于地板。
|
||||
- 1：忽略工作流；乱增字段；句子级只填一个词；同批互指对不上；或把用户已定内容改掉。
|
||||
- 5：按规则字段与工作流填写；句子级达到地板并停在事实；同批互指一致；用户已定内容未改。
|
||||
- 3：大体按工作流，但有一处低于地板，或有一句在预写场面。
|
||||
- 1：乱增字段、忽略地板写成整场戏、同批对不上，或改掉用户已定内容。
|
||||
```
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 有规则则按字段与填写工作流执行；无规则则只是一条字段很少的具名内容？
|
||||
- [ ] 一份产物只有一条记录，名称是中文？
|
||||
- [ ] 同批规则已一次写齐，各条互指的专名与关系一致？
|
||||
- [ ] 句子级字段达到地板？分级字段只填档位短值？
|
||||
- [ ] 记录键值合法，用户已定专名未改写，英文专名已音译？
|
||||
- [ ] 未改合同？
|
||||
- [ ] 产物正文不含评分、诊断、追问？
|
||||
- [ ] 有规则则键与工作流一致；无规则则只是一条字段很少的内容？
|
||||
- [ ] 一份产物一条记录，名称是中文？
|
||||
- [ ] 同批已一次写齐，互指的专名与事由一致？
|
||||
- [ ] 句子级字段达到地板且停在事实，没有场面或预告？
|
||||
- [ ] 分级只填短值；硬门槛对不上时已进 gap 而不是写违规记录？
|
||||
- [ ] 用户已定专名未改，英文专名已音译？
|
||||
- [ ] 正文无评分、诊断、追问？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：规则一次生成=同批、关系=开局仇敌二人 → 一次写齐 2 条，甲的仇敌字段写乙与夺位之事，乙的写甲与同一件事，两条对得上。
|
||||
坏：记录里加了规则没有的字段（规则无「性别」却写进去）。
|
||||
坏：规则要求句子级的「气质」只填「阴郁」，没达到地板。
|
||||
坏：同批的仇敌二人分两轮各写各的，互指的名字和事由对不上。
|
||||
好：
|
||||
- 同批仇敌二人：一次写齐。甲的关系写乙与夺位之事，乙写甲与同一件事。
|
||||
- 外貌地板是年龄感、一套衣服、一处外形：写「三十四岁，黑套裙，金丝眼镜，坐在桌沿按着档案」。不写被制服后的神态。
|
||||
- 命门：写「三份签章权被公开或被上层改掉，高位当天失效；失效前她加价，失效后改口说补件是自愿」。不写一场惩戒。
|
||||
- 阶层填「T2·豪门顶流」。不把分级表现里的表象再抄进记录。
|
||||
|
||||
缺料时：
|
||||
- 没有可依的规则，又不止一条简单具名内容 → 先写生成规则。
|
||||
- 材料过不了规则的年龄或禁止项 → 不填成违规记录，进 `self_score.gap`。
|
||||
|
||||
偏了就改回：
|
||||
- 命门写成完整征服过程 → 收成「什么事实让这项依仗失效」。
|
||||
- 外貌后半段写成身体反应 → 删到能认出的外形为止。
|
||||
- 把规则提示里的方向句原样贴进字段 → 改成这一条自己的事实，仍落在该范围内。
|
||||
- 记录里重写「古武核威慑」→ 删掉，留在世界法则；「五阶段崩解」这类全员反应链不写，这一条怎么破防由她的性格与命门推出。
|
||||
```
|
||||
|
||||
@@ -49,7 +49,7 @@ feeds: design_only
|
||||
2. 禁止重写上游长文；只写顺序与投影。
|
||||
3. 每轮槽：order 0＝该槽固定人设；其后按「稳→对话.历史→易变」软排。
|
||||
4. 主世界层必须含 ref=`对话.历史`（默认 projection=summary）；转述与旁观维护默认不含历史。
|
||||
5. 主世界层应挂「设计.叙事指南」「设计.故事推进」（工序编排则为「设计.叙事指南与故事推进」）等 mount 到 gm 的块；有「设计.随机范围整理」则挂 gm（summary 即可）；转述只读本轮正文（输出.用户展示）+ 文风/壳。
|
||||
5. 主世界层应挂「设计.叙事指南」「设计.故事推进与交互范式」（旧档仍挂「设计.故事推进」；工序编排则为「设计.叙事指南与故事推进」）等 mount 到 gm 的块；有「设计.随机范围整理」则挂 gm（summary 即可）；转述只读本轮正文（输出.用户展示）+ 文风/壳。
|
||||
6. 旁观维护在回合末：须含「输出.用户展示」与变量合同，不含历史。
|
||||
7. 越稳越靠前；本轮输入/真值/正文通常在历史之后。
|
||||
8. 同一内容可挂多槽。
|
||||
@@ -96,7 +96,7 @@ feeds: design_only
|
||||
"inserts": [
|
||||
{ "order": 0, "ref": "worker.persona", "projection": "fixed" },
|
||||
{ "order": 1, "ref": "设计.舞台骨架", "projection": "summary" },
|
||||
{ "order": 2, "ref": "设计.实现机制", "projection": "summary" },
|
||||
{ "order": 2, "ref": "设计.世界法则", "projection": "summary" },
|
||||
{ "order": 3, "ref": "设计.变量设计与更新规则", "projection": "summary" },
|
||||
{ "order": 4, "ref": "设计.生成规则", "projection": "summary" },
|
||||
{ "order": 5, "ref": "设计.叙事指南与故事推进", "projection": "summary" },
|
||||
|
||||
@@ -7,52 +7,49 @@ name: 生成规则
|
||||
id: generation-rules
|
||||
artifact: 设计.生成规则
|
||||
declaration: >
|
||||
为需要统一生成的一类对象写出合同：名称、用途、字段、池或提示约束、填写工作流；不填最终实例；可按对象反复。
|
||||
为一类要统一生成的对象写填写合同：名称、用途、字段、池或提示、填写工作流。不填最终实例。每个产物一条规则。
|
||||
when: |
|
||||
要落两份或以上同类对象时使用。
|
||||
只落一份，但字段多、结构重要，或需要先审字段和填写工作流时也使用。
|
||||
不因开场后是否继续按同一合同生成而改道。每个产物只写一条规则。
|
||||
不因开场后是否继续按同一合同生成而改道。
|
||||
when_not: |
|
||||
只有一条、字段很少、也不承载玩法的具名内容，才不建规则。这种内容通常也不必落具体实例。
|
||||
一张有节点和连接的结构（地图、升级路径、关系网）→ 拓扑图谱。
|
||||
跨轮真值 → 变量设计；舞台格局与硬法则 → 舞台骨架 / 实现机制。
|
||||
只有一条、字段很少、也不承载玩法的具名内容 → 不建规则，通常也不落具体实例。
|
||||
一张有节点和连接的结构 → 拓扑图谱。
|
||||
跨轮真值 → 变量设计。舞台格局与硬法则 → 舞台骨架 / 世界法则；本步只短引用。
|
||||
boundary: |
|
||||
本能力只交生成合同：名称、用途、字段、池或提示、填写工作流。
|
||||
不填最终 records，不重写世界百科，不改变量公式与剧情推进。
|
||||
本步交生成合同，供具体实例与游玩期按同一字段填写。
|
||||
同一条约束只放一个槽：填充要求、提示、地板、分级表现不换壳复述。
|
||||
地板写最低要让人看见或碰到什么，不写可照抄的场面。价目、境界全文、台上格局已在别处时，本步引用名称，不重抄表。
|
||||
feeds: gm,auditor
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
先说这套规则生成什么、用在什么场合。只有一条字段很少的具名内容，通常不必建规则，也不必落具体实例。
|
||||
先说这套规则生成什么、用在什么场合。只有一条字段很少的具名内容，通常不必建规则。
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
为单一对象族写出一份生成合同，写入 `设计.生成规则#中文规则名`。先写名称与用途，再按用途推出字段与每项填充要求；描写类字段写明地板，标签看不懂的分级另写分级表现；需要封闭选取的字段绑池，更适合一句话约束的字段写提示；最后写填写工作流（含依赖、自检、反模式），供具体实例与游玩期动态生成共用。
|
||||
为单一对象族写一份生成合同，写入 `设计.生成规则#中文规则名`。先写名称与用途，再按用途推出字段：每项用 `填充要求` 写清填什么、为何需要。取值默认用提示约束；能数完且必须全员一致的封闭集合才建池。描写类字段另给一句 `地板`（最低可感知到什么）。标签本身看不懂的分级才写 `分级表现`。最后写填写工作流，只保留真正改变填写顺序的阶段。
|
||||
|
||||
每个产物只含一条规则。材料足够便直接成稿；真正会改合同的缺口（生命周期、必填字段、单条/同批关系）交给 `self_score.gap`。产物正文不放评分、诊断、追问或开放问题。
|
||||
同一事实只写一次。`提示` 只在填充要求没写清范围时补范围；`地板` 不重复填充要求，也不写示范句。舞台骨架、世界法则或拓扑图谱里已有的格局、法则、阶梯和价目，在用途或相关填充要求里点名引用。
|
||||
|
||||
每个产物一条规则。材料够就成稿。会改合同的缺口（生命周期、必填字段、单条还是同批）进 `self_score.gap`。正文只含合同 JSON，不含评分、诊断、追问或最终记录。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 用途决定字段：每个字段都要能回答「对这个用途是否必要」；女 NPC 不写性别；药水要写清效果参数，不要只写外观；怪物这类要接战斗的，等级、攻击骰等玩法接口不能漏。
|
||||
2. 字段不多不少、互不重叠：资产与存款这类同义字段只留一个。
|
||||
3. 取值分三类：自由生成；从池中选取（填写方按合理度选，不是伪随机程序）；提示约束（如「现代都市中正常的职业」）。默认优先提示约束；只有能数完、必须全员一致的封闭集合（阶层、强度档、武器种类）或分阶段选型时才建池。
|
||||
4. 姓名、绰号、能力概念、外貌、气质写不完：用自由或提示约束，不建池，也不在填充要求或提示里列一串可选值冒充穷举。要反复生成又怕雷同时，`提示` 可写 2～6 个「方向名：一句概括」划多样的范围；方向不挂作品名、不堆例句。
|
||||
5. 描写类字段（外貌、能力现象、限制、互动手感等）写 `地板`：最低要写到读者能看见、听见或碰到什么，对手能抓住什么空隙。词条、档位、数字、骰子可以短，不写地板。规则里出现的示例必须达到地板，不用「气质：阴郁」「能力：时空斩」这种单标签当示例。
|
||||
6. 标签本身看不懂的分级（境界、品阶、强度档、好感档）另写 `分级表现`：每档一句概括 + 一段可感知表象，相邻档必须能分清。实例字段只填档位短值，叙事按此表展开。
|
||||
7. 外貌、服装、仪式等几面拼成一格的字段，在该字段 `填充要求` 里写配方：用哪几面、每面写什么、怎么拼成一段。字段仍是一个扁平值，不拆嵌套对象，也不为每一面各建池。
|
||||
8. 填写工作流按重要性推进：先锚定会约束后续的选项，再填血肉；阶段、依赖、自检、反模式都服务于「怎么填对」，写短写准。会反复生成的规则，自检清单要含去重：与已有记录不撞名、不撞核心特征。
|
||||
9. 生命周期三选一：`仅游玩期`（创作期不预填）、`只预生成`（预填完即可丢掉规则）、`预生成并游玩期`（既写种子，开场后仍可再生成）。选哪一档不改变「要不要先写这份合同」。
|
||||
10. `只预生成` 为中间层；另两类为最终层，挂主世界层与旁观。
|
||||
11. `数量` 与 `一次生成` 是两件事：`数量` 是总共几条；`一次生成` 看记录之间有没有必须一起钉死的关系（互指、对立、同场），不看总数。有 → 同批，`关系` 只写谁对谁；彼此独立 → 单条。「总共 5 个」不等于同批。
|
||||
12. 多张名片共享的台上格局、世界状况、既成法则归舞台骨架或实现机制：已有则在 `用途` 或 `填充要求` 里短引用；没有则只写填写时必须守的最短条款，缺口交 `self_score.gap`。不在规则里重抄「共通前提」长文，也不借 `关系` 写前史与社会律。
|
||||
13. 不输出最终实例记录。
|
||||
14. 给人读的键和专名用中文。材料里的英文名音译成中文。外壳的 schema、brief、mount 保持既有键。
|
||||
1. 用途决定字段。每个字段都要能回答「这个用途是否必要」。女 NPC 不写性别；药水写效果参数；要接战斗的写等级、攻击骰等接口。同义字段只留一个。
|
||||
2. 取值三类：自由；池选取（填写方按合理度选）；提示约束。默认提示约束。姓名、绰号、能力概念、外貌、气质不建池，也不在提示里列一串冒充穷举。怕生成雷同且会反复生成时，`提示` 写 2～6 个「方向名：一句概括」，不挂作品名、不堆例句。
|
||||
3. 描写类字段的 `地板` 是最低栏：写到能看见、听见或碰到什么，或对手能抓住什么空隙。一句话。词条、档位、数字、骰子不写地板。地板不是小场景，不写「下一句怎么说」「手怎么放」。
|
||||
4. 标签看不懂、且还没有拓扑标尺的分级，才写 `分级表现`：每档一句概括，加一句能与相邻档分开的表象。实例只填档位短值。社会阶梯、境界、价目、兑换等级已在拓扑图谱时，填充要求点图名，不另造一套数，也不把全表抄进 `分级表现`。
|
||||
5. 几面拼成一格时，配方写在该字段的 `填充要求`：哪几面、每面写什么。字段值仍是一段扁平文字。
|
||||
6. 工作流按填写顺序写短：先定会约束后面的项，再填其余。用不到的阶段不写。会反复生成时，自检含去重（不撞名、不撞核心特征）。`反模式` 写错在哪；需要时加半句反例，不写一场戏。
|
||||
7. 生命周期三选一：`仅游玩期`、`只预生成`、`预生成并游玩期`。`数量` 是总共几条；`一次生成` 看记录是否必须互指、对立或同场。有则同批，关系只写谁对谁；彼此独立则单条。总共 5 个且互不改写，仍是单条。
|
||||
8. 共享的台上格局与既成法则已有则短引用；没有则只写填写时必须守的最短条款，缺口进 `self_score.gap`。给人读的键和专名用中文；英文专名音译。外壳的 schema、brief、mount 保持既有键。
|
||||
```
|
||||
|
||||
## output
|
||||
@@ -65,69 +62,58 @@ feeds: gm,auditor
|
||||
"mount": ["world-simulator", "auditor"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"名称": "人话规则名，如「末世可征服 NPC」",
|
||||
"用途": "这套规则在本局用来生成什么、服务哪类游玩反馈",
|
||||
"规则名": "中文短名，与名称对应且稳定",
|
||||
"名称": "人话规则名",
|
||||
"用途": "生成什么、服务哪类反馈；已有舞台或机制则点名",
|
||||
"规则名": "中文短名，与名称对应",
|
||||
"生命周期": "仅游玩期|只预生成|预生成并游玩期",
|
||||
"数量": {
|
||||
"模式": "固定|区间|看情况",
|
||||
"值": 1,
|
||||
"最小": 1,
|
||||
"最大": 1,
|
||||
"决定规则": "contextual 时说明如何决定条数"
|
||||
"决定规则": "看情况时说明如何决定条数"
|
||||
},
|
||||
"一次生成": {
|
||||
"模式": "单条|同批",
|
||||
"关系": "同批必填：本批必须一起钉死的互指；单条写彼此独立"
|
||||
"关系": "同批：谁对谁必须一起钉死；单条：彼此独立"
|
||||
},
|
||||
"字段": [
|
||||
{
|
||||
"名": "顶层字段名",
|
||||
"填充要求": "填什么、填到多厚、为何本用途需要它；几面拼一格的写配方（哪几面、各写什么）",
|
||||
"填充要求": "填什么、为何需要；几面拼一格时写配方",
|
||||
"取值方式": "自由|池选取|提示约束",
|
||||
"绑定池": "池选取时填写池名称；其它省略",
|
||||
"提示": "提示约束时写可执行的一句范围，或 2～6 个「方向名：一句概括」；其它省略",
|
||||
"地板": "描写类字段写：最低填到什么可感知程度；词条、档位、数字省略"
|
||||
"绑定池": "仅池选取时写池名称",
|
||||
"提示": "仅提示约束且填充要求未写清范围时：一句范围，或 2～6 个「方向名：一句概括」",
|
||||
"地板": "仅描写类：一句最低可感知标准"
|
||||
}
|
||||
],
|
||||
"池": [
|
||||
{
|
||||
"名称": "与字段绑定的人话名",
|
||||
"说明": "何时从中选取、选取口径",
|
||||
"条目": ["封闭可选项；只列必须一致的有限集合"]
|
||||
"说明": "何时选取、按什么合理度",
|
||||
"条目": ["封闭可选项"]
|
||||
}
|
||||
],
|
||||
"分级表现": [
|
||||
{
|
||||
"字段": "标签看不懂的分级字段名；无此类分级则省略整个键",
|
||||
"字段": "标签看不懂的分级字段名；无则省略整个键",
|
||||
"档位": [
|
||||
{
|
||||
"值": "档位短值，与实例所填一致",
|
||||
"概括": "一句：这档能做到什么量级",
|
||||
"表象": "看见、听见、碰到什么；须能和上下档分清"
|
||||
"值": "与实例所填一致的短值",
|
||||
"概括": "一句：这档的量级",
|
||||
"表象": "一句：与相邻档可分开的可见差别"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"填写工作流": {
|
||||
"工作流": {
|
||||
"阶段1 骨架锚定": "先选哪些池/字段、定下什么内核",
|
||||
"阶段2 灵魂注入": "下一步推什么，如何与上一阶段咬合",
|
||||
"阶段3 血肉填充": "姓名、外貌等如何服务已定内核",
|
||||
"阶段4 立场定调": "可选；最后定关系或立场类字段"
|
||||
"阶段1": "先定什么"
|
||||
},
|
||||
"依赖关系": [
|
||||
"字段A → 字段B：约束说明"
|
||||
],
|
||||
"自检清单": [
|
||||
"填完后必须能回答的关键问题"
|
||||
],
|
||||
"依赖关系": ["字段A → 字段B：约束"],
|
||||
"自检清单": ["填完必须能核对的一点"],
|
||||
"反模式": [
|
||||
{
|
||||
"名": "短名",
|
||||
"说明": "为什么错",
|
||||
"反例": "可选一句"
|
||||
}
|
||||
{ "名": "短名", "说明": "错在哪", "反例": "可选半句" }
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -135,65 +121,62 @@ feeds: gm,auditor
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. 输出合法 JSON；每个产物只描述一条规则，禁止 `rules` 数组堆多条。
|
||||
2. `字段` 由用途推出；可省略的字段不写；重叠字段合并。
|
||||
3. `池` 可 `[]`；池选取字段必须能对应到某个池；提示约束字段必须有 `提示`。姓名、绰号、能力概念、外貌、气质不绑池。
|
||||
4. `填写工作流` 必含 `工作流`；`依赖关系` / `自检清单` / `反模式` 为子字段，无则 `[]`，不要拆成正文顶层并列大段。
|
||||
5. `一次生成` 为同批时关系必填且本批至少 2 条；为单条时一次只交 1 条。
|
||||
6. 字段值为扁平可填内容；不要嵌套对象当字段值契约。几面拼一格的配方写在 `填充要求`。
|
||||
7. 描写类字段必须有 `地板`；规则里任何示例都要达到地板。标签看不懂的分级必须在 `分级表现` 写齐每档；没有此类分级则省略 `分级表现`。
|
||||
8. 不在产物正文写自评、追问、开放问题或最终记录。
|
||||
9. `只预生成` 时程序记为中间层；`仅游玩期` / `预生成并游玩期` 记为最终层。
|
||||
10. 字段名和专名用中文；英文专名音译为中文。
|
||||
1. 合法 JSON；每个产物一条规则，不写 `rules` 数组。`mount` 固定 `["world-simulator", "auditor"]`。
|
||||
2. 字段由用途推出；重叠合并；可省略的键不写。池选取必须对应到某个池；无池则 `池` 为 `[]`。姓名、绰号、能力概念、外貌、气质不绑池。
|
||||
3. 同一约束只出现在一个槽。`提示` 与 `填充要求` 同义则省略 `提示`。`地板` 与填充要求同义、或写成场面/台词，则改成一句可感知标准或省略。
|
||||
4. `填写工作流` 必含 `工作流`；依赖、自检、反模式无则 `[]`。阶段按实际顺序命名，不凑满四段。
|
||||
5. 同批时关系必填且本批至少 2 条；单条一次只交 1 条。字段值是扁平文字，配方写在 `填充要求`。
|
||||
6. 没有难懂分级则省略 `分级表现`。不在正文写最终记录、价目全表、百科、评分或追问。`只预生成` 为中间层；另两类为最终层。字段名与专名用中文。
|
||||
|
||||
## score
|
||||
|
||||
```score
|
||||
字段妥当：
|
||||
- 5：字段由用途推出，不多不少、不重叠；该有的玩法/效果接口齐全，该省略的已省略；描写类字段有达到可感知的地板，难懂分级有分级表现。
|
||||
- 3：大体可用，但有 1 个冗余、重叠或明显缺失字段，或个别描写字段地板含糊、某档分级只有阶名。
|
||||
- 1：通用名片乱塞，或关键效果/接口字段缺失；描写字段与示例都是单标签。
|
||||
- 5：字段由用途推出，不多不少；描写地板是一句可感知标准；难懂分级能与邻档分开。
|
||||
- 3：大体可用，但有一处冗余、缺失，或地板/提示在复读填充要求。
|
||||
- 1：关键接口缺失，或地板、提示、反例写成场面。
|
||||
|
||||
池与提示：
|
||||
- 5：只有封闭集合用池，不可穷举项用提示或自由；提示具体可执行，方向式提示以「方向名：一句概括」为主、不挂作品名。
|
||||
- 3：大体合理，但个别字段误用/漏用池，或池过泛、提示含糊。
|
||||
- 1：为姓名、气质、能力等建词池，大段假穷举，或本该一句话提示却做成巨型词表。
|
||||
- 5：封闭集合用池，其余用提示或自由；提示是范围或方向名，不堆例句。
|
||||
- 3：个别字段误用池，或提示含糊。
|
||||
- 1：为姓名、气质、能力建词池，或提示变成例句库。
|
||||
|
||||
填写工作流：
|
||||
- 5：阶段简洁有力，依赖与自检/反模式能引导按重要性推进，反复生成时含去重，不臃肿。
|
||||
- 3：有阶段但顺序或依赖不清，或清单偏长却抓不住关键咬合。
|
||||
- 1：无工作流，或与字段脱节，无法指导动态生成。
|
||||
- 5：阶段只含会改变顺序的步骤，自检抓得住，反复生成时含去重。
|
||||
- 3：有阶段但依赖不清，或清单偏长。
|
||||
- 1：无工作流，或与字段脱节。
|
||||
```
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 名称与用途已写清？
|
||||
- [ ] 字段由用途推出，无冗余重叠、无关键缺失？
|
||||
- [ ] 池与提示分工正确？姓名、绰号、能力、外貌、气质没有建池？
|
||||
- [ ] 描写类字段有地板，示例不是单标签？难懂分级有分级表现？
|
||||
- [ ] 几面拼一格的字段在填充要求里写了配方？
|
||||
- [ ] 填写工作流含子字段：工作流 / 依赖关系 / 自检清单 / 反模式？反复生成时自检含去重？
|
||||
- [ ] 生命周期已钉？一次生成按关系定，而非按总数？
|
||||
- [ ] 共享格局只引用舞台骨架，没有重抄共通前提？
|
||||
- [ ] 未输出最终实例、百科长文、评分或追问？
|
||||
- [ ] 名称、用途、生命周期已写清，且只含一条规则？
|
||||
- [ ] 字段由用途推出，无同义字段？
|
||||
- [ ] 填充要求、提示、地板没有同一句写两遍？
|
||||
- [ ] 地板是一句可感知标准，不是场面或台词？
|
||||
- [ ] 池只绑封闭集合；难懂分级才有分级表现，且未另造一套已有标尺？
|
||||
- [ ] 工作流阶段没有凑数；同批/单条按关系而非总数？
|
||||
- [ ] 格局与法则是短引用，没有重抄舞台或机制？
|
||||
- [ ] 正文无最终实例、评分或追问？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：
|
||||
- 武功典籍：字段为名字 / 效果 / 阶层。阶层池选取封闭档位，另写 `分级表现`，每阶一句概括 + 可感知表象；名字与效果用提示约束。
|
||||
- 女主规则：不设「性别」；池为 `[]`；内在冲突自由写，地板是「能在一场戏里演出来的两难」。
|
||||
- D&D 怪物：名称、等级、攻击骰齐全；气质用提示约束，地板写到一个可观察的习性。
|
||||
- 外貌：`填充要求` 写配方「轮廓一句 + 质感一句 + 一个旁人会记住的细节」，拼成扁平的一段「外貌」。
|
||||
- 互为仇敌的两名开局 NPC → 一次生成=同批，关系写谁夺了谁的什么；可互换的酒馆路人 → 单条；总共要 5 个但彼此无关 → 数量 5、一次生成单条。
|
||||
- 武功典籍：字段为名字、效果、阶层。阶层走封闭池，分级表现每档一句概括加一句与邻档不同的可见差别。名字与效果用提示，不建池。
|
||||
- 外貌：填充要求写配方「轮廓一句 + 质感一句 + 一个旁人会记住的细节」。地板一句：「能认出年龄感、一套衣服、一处身体曲线。」不写被征服时的神态。
|
||||
- 实权：填充要求写「相对主角有没有二十四小时内生效的赏罚；没有则写无实权落差」。提示与地板不把这句话再写一遍。
|
||||
- 已有 10 阶价目拓扑：填充要求写「强度取该图的阶名，价格按该档已写基价」。不在本规则重列全表。
|
||||
- 互为仇敌的两名开局 NPC：一次生成同批，关系写谁夺了谁的什么。彼此无关的五个路人：数量 5，一次生成单条。
|
||||
|
||||
坏：
|
||||
- 为气质、绰号、能力各建一个 8～20 词的池，填出来全是标签。
|
||||
- 提示里的方向每条挂作品名或例句，变成假选项库。
|
||||
- 示例写「气质：阴郁」「能力：时空斩」，地板被示例教坏。
|
||||
- 阶层只写「A」「金丹」，没有分级表现，叙事时无从下笔。
|
||||
- 把社会格局、前史写成「共通前提」长文塞进规则，而不是引用舞台骨架。
|
||||
- 女主规则塞「性别」；怪物规则只有名字和性格，没有等级、攻击骰。
|
||||
缺料时：
|
||||
- 生命周期或同批关系定不下来 → `self_score.gap`。
|
||||
- 台上格局还没有 → 填充要求只写必须守的最短条款，并 gap 指明缺舞台或机制。
|
||||
|
||||
偏了就改回：
|
||||
- 填充要求、提示、地板三份都在讲「二十四小时内失去什么」→ 留在填充要求，另两槽删掉或只补真正的缺口。
|
||||
- 地板写成「她会哭着改口、手按在锁骨上」→ 改成「写出哪份文件作废」。
|
||||
- 分级表象写成一段调教 → 改成一句与邻档不同的可见差别。
|
||||
- 反例写成完整小剧场 → 留半句错法，或只留说明。
|
||||
```
|
||||
|
||||
@@ -0,0 +1,115 @@
|
||||
# 画面与生图
|
||||
|
||||
## meta
|
||||
|
||||
```meta
|
||||
name: 画面与生图
|
||||
id: image-prompt
|
||||
artifact: 设计.画面与生图
|
||||
declaration: >
|
||||
从工作流库选定一种画面工作流，并写成旁观每轮可执行的生图提示词合同。
|
||||
游玩时不再改选工作流。
|
||||
when: |
|
||||
用户要给游玩配图，或点名某种画面风格（西幻、写实、东方玄幻等）。
|
||||
when_not: |
|
||||
用户没提配图、插图或画面风格。
|
||||
只改遣词 → 叙事指南。只改真值 → 变量设计与更新规则。
|
||||
壳上的背景、立绘先不做。
|
||||
boundary: |
|
||||
本步只交：选中的工作流 id，以及这一局的画面提示词怎么写。
|
||||
不写 ComfyUI 节点图，不写某一轮的成品提示词，不写真值与填表规则。
|
||||
产物只挂旁观。主世界层不读。
|
||||
feeds: auditor
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
这局游玩要不要配图？要的话，画面更接近库里的哪一种？人物或场面里有什么必须反复画出来？
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
为这本书选定一种画面工作流，并写下旁观每轮写生图提示词时要遵守的合同，写入 `设计.画面与生图`。
|
||||
|
||||
先看工作流库目录。用户点了名、或和本局世界明显同一种画面时，用 `read_library_entry` 读取那一条（只读 1 条）。把该条目的 id 原样写入 `工作流`。`画什么`、`始终带上`、`不画`、`写法` 按本局来写：工作流已经带上模型和画风，写法里说明提示词写场面与可见人物，不另起一套画风形容词。
|
||||
|
||||
库是空的，或没有对得上的条目：不要编一个 id。`工作流` 留空字符串，并在 `self_score.gap` 写明库里还没有可用工作流。
|
||||
|
||||
材料够就成稿。产物正文不含评分、诊断或某一轮的成品提示词。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 工作流只选库里已有的一个 id。游玩期间定死，不在合同里留备选。
|
||||
2. `画什么` 写每轮从正文取哪些可见内容（场所、在场的人、刚发生的动作），一句。
|
||||
3. `始终带上` 只留本局必须反复出现的外貌或标志，每条一句。没有就空数组。
|
||||
4. `不画` 只留不该进画面的东西，例如界面、选项、系统字。没有就空数组。
|
||||
5. `写法` 写提示词的语言、粗细，以及要不要重复画风词。不写一场示范提示词。
|
||||
6. 节点图、采样器、模型文件名不写入产物。
|
||||
7. `mount` 只有 `auditor`。
|
||||
```
|
||||
|
||||
## output
|
||||
|
||||
```output
|
||||
{
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "画面与生图",
|
||||
"brief": "一句话：用哪份工作流，提示词写什么",
|
||||
"mount": ["auditor"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"工作流": "工作流库条目 id；库空则空字符串",
|
||||
"画什么": "每轮从正文取哪些可见内容，一句",
|
||||
"始终带上": ["必须反复出现的外貌或标志，一句一条"],
|
||||
"不画": ["不该进画面的东西"],
|
||||
"写法": "语言、粗细、是否重复画风词"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. 输出合法 JSON。`工作流` 是库里的一个 id，或库空时的空字符串。
|
||||
2. `mount` 只有 `auditor`。
|
||||
3. 不写节点图，不写某一轮的成品提示词，不写真值。
|
||||
4. 产物正文不写自评和追问。
|
||||
|
||||
## score
|
||||
|
||||
```score
|
||||
工作流：
|
||||
- 5：id 来自库，且和本局画面一致。
|
||||
- 3：id 在库里，但和用户说的风格偏了。
|
||||
- 1：库里没有却编了一个 id。
|
||||
|
||||
提示词合同：
|
||||
- 5：画什么、始终带上、写法都能让旁观直接写下一轮提示词。
|
||||
- 3：方向有了，但写法仍是氛围词，或写成了一段示范提示词。
|
||||
- 1：只有风格标签，没有可执行的取景说明。
|
||||
```
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 工作流 id 来自库，或库空时明确留空？
|
||||
- [ ] 只选了一种，没有备选？
|
||||
- [ ] 写法没有示范提示词，也没有节点图？
|
||||
- [ ] mount 只有 auditor？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：
|
||||
- 库有 `eastern-fantasy`，用户要仙侠 → `工作流` 写该 id。`画什么`：「这一轮正文里看得到的场所、在场的人和正在做的动作」。`写法`：「中文短句；模型已是东方玄幻，提示词不另堆画风词」。
|
||||
|
||||
缺料时：
|
||||
- 工作流库没有任何条目 → `工作流` 为 ""，gap 写明还没有可用工作流。
|
||||
|
||||
偏了就改回：
|
||||
- 把某一场的完整提示词写进 `写法` → 改成语言和粗细。
|
||||
- `mount` 写了 world-simulator → 改成只有 auditor。
|
||||
```
|
||||
@@ -1,53 +1,63 @@
|
||||
# 实现机制
|
||||
# 世界法则
|
||||
|
||||
## meta
|
||||
|
||||
```meta
|
||||
name: 实现机制
|
||||
name: 世界法则
|
||||
id: mechanism
|
||||
artifact: 设计.实现机制
|
||||
artifact: 设计.世界法则
|
||||
declaration: >
|
||||
保存世界中稳定成立的因果法则，供主世界层推演事件后果、剧情变化和人物反应；一次可写多条共同作用的机制。
|
||||
写出这个世界相对熟悉基底的根本变造及其连锁后果，以及金手指、玩法系统的固定规则；
|
||||
供主世界层判断「在这个世界里，这件事意味着什么、会引来什么」。
|
||||
when: |
|
||||
本局存在拿掉后会改变故事骨架的既成法则，且后续需要据此推演环境变化、事件后果或人物反应时使用。
|
||||
用户给出了与现实或原作不同的世界前提（超常力量、社会常态、禁忌、缺失之物），且它会持续改变人们怎样看待、处理玩家要做的事时使用。
|
||||
本局有金手指或玩法系统，需要固定的触发条件与总则时使用。档位全表、价目、社会阶梯归拓扑图谱。
|
||||
when_not: |
|
||||
只有熟悉常识，没有特殊因果法则 → 不使用。 「特殊」只是身份或开场处境、能被舞台骨架、具体实例或开场白覆盖（如现实世界里模拟一名普通大学生）→ 不使用。 地点、势力与社会格局 → 舞台骨架；多份人物或要先审字段的名片 → 生成规则，单条字段很少的具名内容才归具体实例；字段合同 → 生成规则。
|
||||
世界与熟悉基底无差别，也没有需要固定规则的能力或系统 → 不使用。
|
||||
只是身份或开场处境 → 主角设定 / 开场白。
|
||||
地点、势力分布与主要场所 → 舞台骨架。
|
||||
社会阶梯、境界、价目、兑换等级的全表 → 拓扑图谱；本步只点图名。
|
||||
某人或某类人对玩家的态度、好感、屈服阶段 → 具体实例 / 生成规则 / 变量设计。
|
||||
怎么写、写多细 → 叙事指南。
|
||||
boundary: |
|
||||
本能力交稳定因果，不预写唯一剧情，也不把所有人物钉成同一种反应。
|
||||
不解释起源，不扩写世界百科，不制定推进节奏、变量表或检定公式。
|
||||
本步只写对整个世界客观成立的规则：变造本身，它在制度、权力、日常里的连锁，触碰它的代价与边界；能力与系统的触发和总则。档表不写在这里。
|
||||
规则不预定任何人对玩家的反应或结局；人物如何反应由其性格、利益与当前变量推出。
|
||||
舞台骨架的「必要变造」只留一句台上结果，完整连锁写在本步。
|
||||
feeds: gm
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
说说这个世界有哪些已经成立、会持续改变事件后果的法则。重点是它如何起作用，以及不同处境和人物会因此面对什么；多条机制可以一起写清。
|
||||
说说这个世界和熟悉的现实（或原作）哪里不一样，这些不同让社会、权力和日常变成了什么样。如果有金手指或玩法系统，说说它的触发条件和总则；整张档表交给拓扑图谱。
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
把本局承重的既成因果法则整理为实现机制，写入 `设计.实现机制`。一个产物可以包含多条共同作用的机制；分别写清法则内容、生效方式、因果影响和推演口径，再说明机制之间如何共同作用。
|
||||
把材料整理为 `设计.世界法则`：这个世界对玩家要做的事持什么态度，由哪些规则决定。
|
||||
|
||||
先在内部对每条候选做移除检验：拿掉后故事骨架是否改变。`缺失后果`只用于筛选，不得写进实际产物。机制应让主世界层能够推演事件怎样发展、不同人物可能怎样反应，但不得指定唯一剧情或统一人物反应。
|
||||
先从美学纲领找出玩家反复要做的那件事（讲黄段子、越级修炼、复制能力、扳倒高位者……），再问：在这个世界里，这件事是什么地位——稀缺、禁忌、违法、被垄断、有代价，还是寻常？给出这个地位的世界前提，就是要写的法则。每条写：
|
||||
1. `法则`：世界里成立什么，何时对谁生效。一到两句，主语是世界或某类人，不是玩家。
|
||||
2. `连锁`：因此世界长成什么样。往下推到制度、权力分布、风俗日常、普通人的常见看法，每条一句，1～4 条。
|
||||
3. `代价与边界`：有人去做相关的事会撞上什么（处罚、排斥、追捕、反噬、争夺），法则在哪里失效。无则省略。
|
||||
4. 法则依赖社会阶梯、境界、价目或兑换等级时，在法则或连锁里点拓扑图名，不抄档表。
|
||||
|
||||
材料足够便直接成稿；真正会改变法则内容的缺口交给 `self_score.gap`。产物正文不放评分、诊断、追问或开放问题。
|
||||
写完核对两件事：删掉所有提到玩家的句子，每条法则仍成立；没有一句替某类人预定了对玩家的态度或结局。
|
||||
|
||||
材料够就成稿；会改变法则或连锁方向的缺口进 `self_score.gap`。产物正文只含机制 JSON，不含评分、诊断或追问。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 机制是稳定因果：写世界承认什么、何时生效、会带来什么后果。
|
||||
2. 法则可以是超常前提、约束性公理，也可以是社会性或规范性的既成事实，如“这个世界没有花里胡哨的魔法，只有繁衍到极致的斗气”“这个西幻世界里男尊女卑是常态”“这里以三国杀高手为尊”。同一设定有很多面向，只写后续推演必须承认的那一面。
|
||||
3. 身份特殊、开场处境特殊不是法则：能由舞台骨架、具体实例或开场白承担的（如现实世界里的普通大学生），不写成机制。
|
||||
4. 内部使用移除检验筛选承重法则；只能回答“更丰富”或“以后也许有用”的候选不纳入。缺失后果不输出。
|
||||
5. 内部按基准世界做最小充分继承，校验过程不写入产物：现实地球沿用现实物理、心理与社会规律；变造地球只在用户已表达或体验依赖处承认变造；具体作品世界优先最近一层作品设定，原作未定义处再参考其底层世界；类型世界只继承与当前体验有关的类型约定；从头创造以显式设定为准，未定义处用最少常识；混合或二创只处理与当前法则有关的继承与变造。
|
||||
候选法则超出基准世界已知可能性时，只有用户材料已明示或体验确实依赖才写入，不暗中变造；拿不准是否在用户设想中，就不写进产物，把这处变造交给 `self_score.gap`。
|
||||
6. 因果影响写行动可能性、代价、资源与关系怎样改变；推演口径写推演情节和人物反应时必须考虑什么。
|
||||
7. 人物反应保持开放：同一机制下，人物可因认知、利益、身份和性格不同而隐藏、合作、利用、抵抗或误判。
|
||||
8. 多条机制可一次生成。分别写清后，再说明它们是前提、叠加、制衡还是反馈循环；没有关系则不硬连。
|
||||
9. 机制不等于题材标签。“灵气复苏”“全民直播求生”必须拆成可推演的生效方式与因果链；题材标签也不能代替“这条法则缺了故事会换”。能指明它支撑美学纲领里哪段体验时，写进 `服务体验`。
|
||||
10. 一句话够用便停止；不补起源史、体系百科、人物卡、剧情大纲或推进节奏。
|
||||
1. 世界给体验以分量，不替体验兑现结果。用户要的感觉（爽、禁忌、反差）归美学纲领；本步写让这种感觉成立的地形：这件事为什么难、为什么稀罕、为什么冒险。写成「某类人都喜欢 / 都会屈服 / 绝不反抗」，就是把愿望写成了法则；改回世界前提，人物反应交给实例与变量。
|
||||
2. 两类来源，按序写：世界变造（与基底不同的物理、超常力量、社会常态、禁忌或缺失）优先且写全；其次是特殊力量规则（金手指、功法、血统：触发、效果、限制）。社会阶梯、境界、价目、兑换等级的全表归拓扑图谱。
|
||||
3. 用户描述世界时给出的每一处变造，都要落到某条法则或连锁里，与主角无关的也一样。只写主角身上的力量、漏掉世界本身的不同，是本步最常见的偏法。
|
||||
4. 连锁按常识与人性往下推：谁受益、谁吃亏、制度怎样适应、普通人信什么。可以补出用户没说的合理后果，不得与用户已说的冲突；推不准且会改方向的进 gap。
|
||||
5. 用户否定过的方向本身就是法则（如「古武加入不意味着能单凭武力颠覆一切」），写进去，其它条服从它。
|
||||
6. 同一事实只出现一次。场所写进舞台骨架，体验句留在美学纲领，遣词与「重点描写什么」归叙事指南。
|
||||
7. 一条说清就停，不为凑数拆条。
|
||||
```
|
||||
|
||||
## output
|
||||
@@ -55,100 +65,81 @@ feeds: gm
|
||||
```output
|
||||
{
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "实现机制",
|
||||
"brief": "一句话说明哪些稳定因果在改变本局世界",
|
||||
"技能": "世界法则",
|
||||
"brief": "一句话：这个世界哪些根本不同，让玩家要做的事有了什么分量",
|
||||
"mount": ["world-simulator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"既成机制": [
|
||||
{
|
||||
"名称": "简短稳定的人话名",
|
||||
"法则内容": "世界中稳定成立什么；可以是超常前提、公理，也可以是社会常态或规范",
|
||||
"服务体验": "一句话说明它支撑美学纲领里的哪段体验；无明确对应则省略",
|
||||
"生效方式": [
|
||||
"对谁、在什么条件下、以什么方式起作用"
|
||||
],
|
||||
"因果影响": [
|
||||
"它怎样改变行动可能性、代价、资源、关系或事件后果"
|
||||
],
|
||||
"推演口径": [
|
||||
"推演剧情发展和人物反应时必须结合哪些认知、利益、身份或处境"
|
||||
],
|
||||
"边界或例外": [
|
||||
"确有必要才写；无则省略"
|
||||
]
|
||||
"法则": "世界里成立什么；何时对谁生效",
|
||||
"连锁": ["因此世界在制度、权力、日常或普遍看法上变成什么样"],
|
||||
"代价与边界": ["可选；触碰时撞上什么，法则在哪里失效"]
|
||||
}
|
||||
],
|
||||
"共同作用": [
|
||||
{
|
||||
"涉及机制": ["机制 A", "机制 B"],
|
||||
"关系": "前提|叠加|制衡|反馈循环",
|
||||
"推演影响": "共同作用时会怎样改变事件与人物选择空间"
|
||||
}
|
||||
]
|
||||
"共同作用": []
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. 输出合法 JSON；`既成机制` 可含多条承重机制。
|
||||
2. `缺失后果`、移除检验和被淘汰候选只用于内部推理，不得进入正文。
|
||||
3. 每条机制必须写 `法则内容 / 生效方式 / 因果影响 / 推演口径`；`服务体验` 与 `边界或例外` 可选。
|
||||
4. `共同作用` 只写真实存在的机制关系；无则 `[]`。
|
||||
5. 推演口径提供因果依据，不指定唯一剧情，也不规定所有人物作同一种反应。
|
||||
6. 不在产物正文写自评、追问、开放问题、起源百科或检定公式。
|
||||
7. `mount` 固定为 `["world-simulator"]`。
|
||||
1. 合法 JSON；`既成机制` 可多条；`mount` 固定 `["world-simulator"]`。
|
||||
2. 每条必填 `名称`、`法则`、`连锁`；`代价与边界` 无则整项省略。不写档表、价目全表。
|
||||
3. 正文不出现某人或某类人对玩家的态度、好感、屈服阶段或必然结局；不出现「详写」「重点刻画」一类写法指令。
|
||||
4. `共同作用` 每项一句，只写两条法则相互放大或制约后的世界后果；无则 `[]`。
|
||||
5. 正文不含评分、诊断、追问或历史百科。
|
||||
|
||||
## score
|
||||
|
||||
```score
|
||||
骨架必要度：
|
||||
- 5：每条都是拿掉后会改变故事骨架的承重法则，没有常识、装饰或下游细节。
|
||||
- 3：主体承重，但夹有一条作用较弱或可交给其它能力的内容。
|
||||
- 1：只有题材标签或装饰设定，或把身份、开场处境、暗中加入的变造写成法则。
|
||||
世界客观度：
|
||||
- 5：每条对整个世界成立，删去玩家仍成立；无人物态度或结局预设。
|
||||
- 3：主体客观，夹一句「某类人会配合 / 屈服」或一条写法指令。
|
||||
- 1：法则主要在描述人物如何回应玩家，或在教如何攻略。
|
||||
|
||||
因果清晰度：
|
||||
- 5：生效条件与影响链清楚，能据此推演环境、事件和关系怎样变化。
|
||||
- 3：法则方向正确，但生效方式或一段关键因果仍需猜测。
|
||||
- 1：只说“存在某设定”，无法推出后果。
|
||||
连锁充分度：
|
||||
- 5：用户给出的变造全部落下，且推到制度、权力或日常；主世界层能据此回答「在这个世界里做某事会怎样」。
|
||||
- 3：变造齐了但连锁只有一层，或漏了一处与主角无关的变造。
|
||||
- 1：只有题材标签，或只写了主角的力量。
|
||||
|
||||
推演开放度：
|
||||
- 5：能支持人物按不同认知、利益、身份和性格作出多种合理反应，而不失去法则约束。
|
||||
- 3：提供了反应依据，但部分表述暗含单一路线。
|
||||
- 1：直接预写唯一剧情，或把所有人物规定成同一种反应。
|
||||
承重克制度：
|
||||
- 5：每条拿掉都会改变世界反馈；无场所、名片、文风内容；同一事实只出现一次。
|
||||
- 3：夹一条该交给其它能力的内容，或两条互相复读。
|
||||
- 1：凑数、百科化，或把场所、人物、体验句挤进来。
|
||||
```
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 每条候选已在内部通过移除检验，且缺失后果未写入产物？
|
||||
- [ ] 法则内容、生效方式、因果影响与推演口径均可执行？
|
||||
- [ ] 多条机制的共同作用已写清，或明确无须关联？
|
||||
- [ ] 能支持不同人物作出不同但合理的反应？
|
||||
- [ ] 未把身份或开场处境写成法则？超出基准世界的变造都来自用户材料或体验依赖？
|
||||
- [ ] 未写成题材标签、世界百科、剧情大纲或裁定表？
|
||||
- [ ] 产物正文不含评分、诊断、追问？
|
||||
- [ ] 用户给出的每一处世界变造都落到了法则或连锁里？
|
||||
- [ ] 删掉提到玩家的句子，每条仍成立？
|
||||
- [ ] 没有预定某类人对玩家的态度、屈服阶段或结局？
|
||||
- [ ] 连锁推到了制度、权力或日常层？
|
||||
- [ ] 阶梯、价目、兑换等级只点了拓扑图名，没有抄进本产物？
|
||||
- [ ] 无写法指令、场所、人物名片；正文无评分、诊断、追问？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
灵气复苏：
|
||||
- 灵气重新进入环境，生物可吸收并强化、异变；浓度、接触方式与修炼方法影响变化速度和可控程度。
|
||||
- 因果上会改变资源价值和既有力量关系；推演人物时结合其认知、资源、身份得失与控制能力，不能默认人人都追求修炼。
|
||||
没有黄段子的世界：
|
||||
- 好：法则「这个世界的语言与文化里没有性玩笑；性只在医疗与法律语境里被提起」。连锁「公开谈论性视同猥亵，可被举报处罚」「人们没有接这种话的经验，第一反应多是困惑或惊骇」「极少数地下圈子私下流传，被抓即身败名裂」。代价与边界「说出口的人承担社会性死亡与治安风险；医生、律师在职业语境内例外」。
|
||||
- 偏：「玩家很爱讲黄段子」「某某很爱听」。前者是体验，归美学纲领；谁会好奇、谁会举报，由各人性格推出。
|
||||
|
||||
全民直播求生：
|
||||
- 可拆为“强制进入求生场”“关键行为公开直播”“观众反馈可进入场内（若本局采用）”等多条机制。
|
||||
- 公开评价与即时生存会共同改变选择代价；人物是否表演、隐藏或利用镜头，应由其是否在乎声誉、是否相信能返回现实等条件推出。
|
||||
- 观众若只能观看，就不能推演出打赏资源；边界会直接改变因果链。
|
||||
世界变造写全：
|
||||
- 「阴气偏重，女性习武天然占优」→ 连锁「古武世家上层多为女性」「表世界招聘与言论默认偏向女性，女权乃至种姓式言论常见」「男性高手稀少，罕见的男性天才格外扎眼」。只写主角禁功的突破与反噬、漏掉这条，就是偏了。
|
||||
- 「古武者能绕开任何安保近身刺杀，但扛不住重武器」→ 连锁「真正掌权的是古武世家或受其庇护者」「古武者不公开对抗国家机器，靠隐秘施压」「市井当古武是传言」。
|
||||
- 「超级英雄是合法职业，接替了旧时代偶像的商业位置」→ 连锁「经纪公司与广告左右英雄的曝光与资源」「守序多因利益，被逼急可以转做反派，名声不是绝对枷锁」。
|
||||
- 「灵气重回环境」→ 连锁「生物可经接触与修炼强化或异变」「浓度与方法决定速度和可控度」「资源价值与既有力量关系被改写」。
|
||||
|
||||
好：
|
||||
- 社会常态类法则“这个西幻世界里男尊女卑是常态”：生效方式写继承、婚配、对外交涉由谁做主；因果影响写女性角色行动的额外代价与绕行渠道；推演口径写人物可能顺从、利用或反抗，不规定人人同一态度。
|
||||
- “这个世界没有花里胡哨的魔法，只有繁衍到极致的斗气”：只写斗气是唯一超常力量、怎样决定地位与胜负，不展开境界百科。
|
||||
- 公理“黑暗森林”：一句话钉“暴露坐标即招来打击，文明默认隐藏”；后续情节不能靠对外广播求援收场，不写宇宙社会学论文。
|
||||
特殊力量与系统：
|
||||
- 复制金手指：法则写触发与总则（对方无感、不被削弱；装备、金钱、智力、寄生体不可复制）。五档效果写成拓扑图谱的一条链；主角设定只点图名。
|
||||
- 跨世界对数等级与价目 → 全表是一张 `path` 拓扑；本步只写「强度与价格按那张图」。生成规则和变量只填阶名。
|
||||
|
||||
坏：
|
||||
- 现实世界模拟普通大学生，把“主角是普通大学生”写成机制：这是身份与开场处境，交给具体实例或开场白；没有特殊法则就不使用本能力。
|
||||
- 二创里暗中加入原作没有的力量体系（如在无超能力的原作里写入“觉醒异能”）：用户未设想的变造不写入，拿不准时交给 `self_score.gap`。
|
||||
- 只写“灵气复苏”“末世”等题材标签，没有生效方式与因果链：主世界层无法据此推演任何后果。
|
||||
偏了就改回：
|
||||
- 「恶女必经五阶段：自负→惊恐→……→顺从」→ 删。各人怎么破防写在实例性格，进度交给变量。
|
||||
- 「养母绝不会对主角动手，只会包容」→ 删。这是人物关系，写在实例与变量。
|
||||
- 「主角出手必然形成绝对压制」→ 删；用户说过武力不能颠覆一切时，改写成法则「权与钱仍是表世界主轴，武力不能直接换来合法地位与资产」。
|
||||
- 「推演时详写其神态与身体反差」→ 删，写法归叙事指南。
|
||||
```
|
||||
|
||||
@@ -7,18 +7,20 @@ name: 叙事指南
|
||||
id: narrative-guide
|
||||
artifact: 设计.叙事指南
|
||||
declaration: >
|
||||
继承美学纲领与交互范式，从文风库选取本局写法，落成可执行的遣词要求、视角执行、段落形态、笔墨落点、少量禁忌与可选写法档；不钉故事怎么往前。
|
||||
从文风库写成遣词、视角执行、段落形态、笔墨落点和少量禁忌。
|
||||
体验句留在美学纲领，人称与描写权限留在故事推进与交互范式。
|
||||
when: |
|
||||
已有美学纲领（或等价），但游玩正文仍不知道怎么写：遣词什么要求、视角怎么落笔、笔墨落谁身上、场合是否要换写法档、有哪些绝对不能写。
|
||||
已有美学纲领，但游玩正文还不知道怎么落笔：遣词、视角执行、笔墨落谁身上、场合是否换写法档、绝对不能写什么。
|
||||
用户主动谈文风、措辞、叙述声音、写法档时也使用。
|
||||
when_not: |
|
||||
本技能只给对话落盘。工序编排不排本步（编排池是「叙事指南与故事推进」）。
|
||||
美学未钉 → 先「美学纲领与交互范式」。
|
||||
美学未钉 → 先「美学纲领」。
|
||||
用户明确说本局不用文风细则，且美学里已有可执行遣词方向 → 可不使用。
|
||||
只谈推进、输入用法 → 「故事推进」。单轮字数与篇幅 → 「故事推进」；可见区域 → 「回复呈现」。版式 → 「正文组成」。
|
||||
只谈推进、输入用法、单轮字数 → 「故事推进与交互范式」。可见区域 → 「回复呈现」。版式 → 「正文组成」。
|
||||
boundary: |
|
||||
本能力只交怎么写：选用文风、遣词要求（含叙述声音、视角执行、段落形态）、笔墨落点与代入取向、少量绝对禁忌、可选写法档。
|
||||
推进、输入用法、单轮字数与篇幅归故事推进；体验契约、人称与叙事视角的定义归美学纲领与交互范式。
|
||||
本步只交怎么落笔：选用文风、遣词（叙述声音、视角执行、段落形态）、笔墨落点、少量绝对禁忌、有切换才写的写法档。
|
||||
体验内核、描写焦点、边界与尺度留在美学纲领，本步点名引用，不改写成第二份体验。
|
||||
人称、可写内心、输入用法、单轮字数归故事推进与交互范式。
|
||||
feeds: narrator,gm
|
||||
```
|
||||
|
||||
@@ -31,26 +33,26 @@ feeds: narrator,gm
|
||||
## task
|
||||
|
||||
```task
|
||||
把本局写法整理为叙事指南，写入 `设计.叙事指南`。先继承上游「美学纲领与交互范式」：把 `美学纲领.体验内核`、`呈现要点.描写焦点` 与 `呈现要点.边界与尺度` 改写成做法向句子；`交互范式` 已定的人称与叙事视角不重定义，只在 `遣词.视角` 写怎么执行。再用 `read_library_entry` 从绑定的文风库读取最相关条目（默认 1～2；确需第三种时须写 reason 并标明适用场合），按本局体验本局化，写成可执行的风格推荐与要求。
|
||||
把本局落笔方法整理为叙事指南，写入 `设计.叙事指南`。先读美学的 `体验内核` 和 `描写焦点`，只把焦点里的对象或瞬间点进 `笔墨焦点.详写`；体验句本身不搬过来，也不换说法再写一遍。人称、可写内心以故事推进与交互范式的 `交互范式` 为准，本步在 `遣词.视角` 只写镜头距离和如何不漂人称。
|
||||
|
||||
产物回答：选了哪些文风、各自用在什么场合；遣词、视角执行、段落形态与笔墨要怎么做；叙述声音与代入取向（推得出才写）；只有少数绝对禁忌。除禁忌外，少写“不要怎样”，多写“要怎样”。不写示范段落，不写推进、输入用法或单轮字数。
|
||||
再用 `read_library_entry` 从文风库读取最相关条目（默认 1～2；确需第三种时须写 reason 并标明适用场合）。`风格推荐` 和 `本局要求` 只写节奏、用词层级、句段形态、对话与叙述怎么配。写成台词、角色正在做的场面，或把某类人物当例子演一遍，就改回做法。
|
||||
|
||||
材料足够便直接成稿；真正会改写法的缺口交给 `self_score.gap`。产物正文不放评分、诊断、追问或开放问题。
|
||||
材料够就成稿。会改落笔的缺口进 `self_score.gap`。产物正文不含评分、诊断或追问。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 美学写要什么感受，本步写怎么遣词、笔墨落哪。已在美学写清的感受不重问，直接改写成做法：体验内核与描写焦点落成详写对象和写法要求；边界与尺度按美学给的用法写进写法要求或写法档，只把其中真正碰不得的收进禁忌。
|
||||
2. 文风库是参考，不是照抄：读取后改成本局可执行要求，并记下适用场合与微调。
|
||||
3. 优先 1～2 种文风；确需第三种时，每种都必须有清晰切换场合，禁止无差别堆叠。
|
||||
4. 写法用“风格推荐 + 要求”表达：对象、节奏、注意力落点、句段形态都写成要做什么。示范段落不写。
|
||||
5. 段落形态默认值：用户未提段落形态时，`遣词.写法要求` 写入「完整长自然段叙述，不要单句成段」；用户另定则按用户写。段落形态归本步，单轮字数与篇幅归故事推进。
|
||||
6. 视角只写执行：人称、主要视角、可写内心、不呈现的信息以交互范式为准，本步写落笔做法——镜头距离（贴身 / 中景 / 远观，何时拉近）；内心写到哪（只写交互范式允许写内心的一方，其余人物用外显言行与身体反应表现）；如何不漂人称（全文固定一种称呼，回忆、转述与内心独白也不换人称）。交互范式未定视角时按美学站位取最贴的写法，并在 gap 写明。
|
||||
7. `叙述者` 写叙述声音：冷眼旁观、调侃、贴身低语等，以及它对人物的态度。`代入取向` 写笔墨替谁看、读者站在谁那边。两项都从美学站位与体验推出；推不出或与视角执行重复时省略。
|
||||
8. 绝对禁忌只留真正碰不得的少数几条；其余偏好都改成正向做法。
|
||||
9. 写法档是多文风/多调性容器：有切换才写，无切换整项省略。场合名要能指导何时切入，不是具体剧情桥段清单。用户报出「当众折辱」「独处一室」这类具体场合时，判断它要哪种写法，升一档写进对应写法档的适用场合与写法要求（感官密度、节奏、对话长短、详略），场合本身不单列；每档写清切入与切回。
|
||||
10. 不写故事推进、输入用法、单轮字数与篇幅（归故事推进）或版式壳。
|
||||
1. 美学已经写了要什么感受。本步写怎么落笔。`详写` 点名对象或瞬间；一句若是体验内核的同义改写，删掉。`边界与尺度` 里真正碰不得的收成禁忌短句，用法本身留在美学，不整段抄来。
|
||||
2. 文风库是参考：读完改成本局可执行的节奏和句段，记下适用场合。不搬库里的范文。
|
||||
3. 优先 1～2 种文风。确需第三种时，每种都要有切换场合。
|
||||
4. `风格推荐` 与 `写法要求` 写对象、节奏、注意力落点、句段形态。不写示范段，不写台词，不用「某类角色被怎样」代替做法。
|
||||
5. 用户未提段落形态时，`遣词.写法要求` 写入「完整长自然段叙述，不要单句成段」；用户另定则按用户写。单轮字数归故事推进与交互范式。
|
||||
6. `遣词.视角` 只写执行：镜头距离（贴身 / 中景 / 远观，何时拉近）；内心写到哪（只写交互范式允许写内心的一方，其余用外显言行）；如何不漂人称。交互范式未定视角时按美学站位取最贴的写法，并在 gap 写明。
|
||||
7. `叙述者`、`代入取向` 能从站位推出、且和视角执行不是同一句时才写；否则省略。
|
||||
8. 禁忌只留少数绝对不能写的短句。其余写成正向做法。
|
||||
9. 写法档只在有切换时写。用户报的具体场合（如当众折辱、独处）升进某一档的适用场合与写法要求，不单列成桥段清单。
|
||||
10. 推进、输入用法、单轮字数、版式不在本步写。
|
||||
```
|
||||
|
||||
## output
|
||||
@@ -59,7 +61,7 @@ feeds: narrator,gm
|
||||
{
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "叙事指南",
|
||||
"brief": "一句话：本局正文怎么写",
|
||||
"brief": "一句话：本局正文怎么落笔",
|
||||
"mount": ["narrator", "world-simulator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
@@ -67,39 +69,34 @@ feeds: narrator,gm
|
||||
{
|
||||
"库条目": "style-packs 中的 id 或名称",
|
||||
"适用场合": "默认全文 / 亲密场面 / 战斗反转 等",
|
||||
"本局要求": "从该条目提炼并改写后的可执行写法要求"
|
||||
"本局要求": "节奏、用词、句段；不写台词和场面"
|
||||
}
|
||||
],
|
||||
"遣词": {
|
||||
"整体取向": "本局叙述应呈现的风格方向",
|
||||
"叙述者": "可选：叙述声音，如冷眼旁观 / 调侃 / 贴身低语，及它对人物的态度；无则省略",
|
||||
"风格推荐": ["优先采用的节奏、用词层级、句段形态"],
|
||||
"整体取向": "本局叙述的风格方向，一句",
|
||||
"叙述者": "可选；与视角执行不同才写",
|
||||
"风格推荐": ["节奏、用词层级、句段形态；不写台词"],
|
||||
"写法要求": [
|
||||
"完整长自然段叙述，不要单句成段（用户另定段落形态则改写）",
|
||||
"要写到什么密度、如何处理对话与叙述、注意力放哪"
|
||||
"密度、对话与叙述怎么配、注意力落在哪类瞬间"
|
||||
],
|
||||
"视角": {
|
||||
"镜头距离": "如：贴身跟随 user，冲突时拉近到手与眼神，转场时拉远一句带过",
|
||||
"内心": "如：只写 user 的内心；NPC 只写外显言行与身体反应",
|
||||
"人称": "如：全文第二人称「你」，回忆与内心独白不换人称"
|
||||
"镜头距离": "贴身 / 中景 / 远观，以及何时拉近",
|
||||
"内心": "只写交互范式允许的一方；其余用外显",
|
||||
"人称": "全文固定一种称呼，回忆与独白也不换"
|
||||
}
|
||||
},
|
||||
"笔墨焦点": {
|
||||
"代入取向": "可选：笔墨替谁看、读者站在谁那边；无则省略",
|
||||
"详写": ["应花笔墨的对象与感受"],
|
||||
"代入取向": "可选；与视角执行不同才写",
|
||||
"详写": ["点名对象或瞬间；不复述体验内核"],
|
||||
"可略": ["可一带而过的部分"]
|
||||
},
|
||||
"禁忌": ["仅少数绝对不能写的内容；无则省略"],
|
||||
"禁忌": ["仅少数绝对不能写的短句；无则省略"],
|
||||
"写法档": [
|
||||
{
|
||||
"名字": "展示情色",
|
||||
"适用场合": "切到身体与权力交换时；用户报的「独处一室」这类场合升到这一档",
|
||||
"适用场合": "切到身体与权力交换时",
|
||||
"写法要求": "感官词加重、节奏放慢、对话变短；切回日常则收"
|
||||
},
|
||||
{
|
||||
"名字": "网文爽文",
|
||||
"适用场合": "打脸、反转时；用户报的「当众折辱」之后的反击升到这一档",
|
||||
"写法要求": "可复述对方原话、结果写满、过程可略；反转落定后切回默认文风"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -107,56 +104,65 @@ feeds: narrator,gm
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. 输出合法 JSON；`选用文风` 默认 1～2 项，最多 3 项，每项必须有适用场合与本局要求。
|
||||
2. 不写示范段落、示例正文或仿写样章。
|
||||
3. 除 `禁忌` 外，正文以正向要求为主；空话氛围词改成可执行做法。
|
||||
4. 用户未定段落形态时，`遣词.写法要求` 必含「完整长自然段叙述，不要单句成段」。
|
||||
5. `遣词.视角` 只写交互范式人称与视角的执行，不改人称、不扩大可写内心的范围。`叙述者`、`代入取向` 可选，无则省略。
|
||||
6. `写法档` 无切换时整项省略；有则每档写清场合与写法要求；具体场合升档写入，不单列桥段。
|
||||
7. 不在产物正文写自评、追问、开放问题，或推进、输入用法、单轮字数。
|
||||
1. 输出合法 JSON。`选用文风` 默认 1～2 项，最多 3 项，每项有适用场合与本局要求。
|
||||
2. `风格推荐`、`本局要求`、`写法要求`、`详写` 不写台词、不写角色正在做的场面、不把体验内核换个说法再写一遍。
|
||||
3. 除 `禁忌` 外，正文以正向要求为主。
|
||||
4. 用户未定段落形态时，`遣词.写法要求` 含「完整长自然段叙述，不要单句成段」。
|
||||
5. `遣词.视角` 只执行交互范式里的人称与可写内心，不改范围。
|
||||
6. `写法档` 无切换则整项省略。有则每档写场合与写法要求。
|
||||
7. 产物正文不写自评、追问、推进、输入用法、单轮字数。
|
||||
8. `mount` 固定包含 `narrator` 与 `world-simulator`。
|
||||
|
||||
## score
|
||||
|
||||
```score
|
||||
遣词可执行：
|
||||
- 5：风格推荐与要求具体到能直接落笔，无需再猜味道；视角执行与段落形态写清。
|
||||
- 3：大方向清楚，但仍有几处停留在氛围概括，或视角执行含糊。
|
||||
- 1：只有题材或情绪标签，无法指导遣词。
|
||||
- 5：风格推荐与写法要求具体到节奏和句段，能直接落笔；视角执行写清。
|
||||
- 3：方向清楚，但仍有几处是氛围词，或视角含糊。
|
||||
- 1：只有题材或情绪标签。
|
||||
|
||||
笔墨与禁忌：
|
||||
- 5：详略落点清楚，贴合美学的描写焦点与边界尺度；绝对禁忌少而可执行；其余多为正向要求。
|
||||
- 3：落点大体有，但禁忌偏多或详略仍含糊。
|
||||
- 1：几乎不谈笔墨，或堆满否定句却无正向做法。
|
||||
- 5：详写点名对象或瞬间，没有把体验内核再写一遍；禁忌少而可执行。
|
||||
- 3：落点大体有，但详写在复述感受，或禁忌偏多。
|
||||
- 1：几乎不谈笔墨，或堆满否定句。
|
||||
|
||||
文风选用：
|
||||
- 5：1～2（偶发 3）条贴合本局；多档时切换场合清楚，具体场合已升档写入，无重复堆叠。
|
||||
- 3：选用相关，但场合区分弱，或有一条不够贴。
|
||||
- 5：1～2（偶发 3）条贴合本局；多档时切换场合清楚。
|
||||
- 3：选用相关，但场合区分弱。
|
||||
- 1：未读库硬编，或多种文风无差别并列。
|
||||
|
||||
本局化：
|
||||
- 5：库内容与美学感受已改成本局说法与要求，能看出针对本局体验的取舍。
|
||||
- 3：有微调，但仍有整段近乎原文搬用，或重问了美学已写清的感受。
|
||||
- 1：基本照抄库条目，或与本局体验脱节。
|
||||
- 5：库条目收成可执行的节奏和句段；体验句仍只在美学。
|
||||
- 3：有微调，但仍有整段近乎库原文，或详写在改写体验内核。
|
||||
- 1：照抄库条目，或本局要求写成台词和场面。
|
||||
```
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 已继承美学的体验、描写焦点与边界尺度，改写成做法？
|
||||
- [ ] 已按需读取文风库并本局化？
|
||||
- [ ] 详写只点名对象或瞬间，没有改写体验内核？
|
||||
- [ ] 已读取文风库，本局要求是节奏和句段？
|
||||
- [ ] 选用文风 1～2（最多 3），各有适用场合？
|
||||
- [ ] 遣词是风格推荐与要求，不是示范段落？用户未定段落形态时已写长自然段默认？
|
||||
- [ ] 风格推荐里没有台词、场面或角色举例？
|
||||
- [ ] 视角只写执行，未改交互范式的人称与可写内心？
|
||||
- [ ] 具体场合已升档写入写法档，未单列桥段？
|
||||
- [ ] 除少数禁忌外，多为“要怎样”？
|
||||
- [ ] 用户未定段落形态时已写长自然段默认？
|
||||
- [ ] 未写入推进、输入用法、单轮字数或版式？
|
||||
- [ ] 产物正文不含评分、诊断、追问？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：美学的「掌控感」落成详写对方的迟疑与屈从、user 的动作从容简短；视角写「第二人称贴身镜头，只写你的内心，NPC 只写外显」；写法要求含长自然段默认；用户提的「当众折辱」升进「网文爽文」档，写清切入与切回。
|
||||
坏：重新定义人称或扩大可写内心；把「当众折辱」「独处一室」列成桥段清单；写示范段落；在本步写单轮字数或推进方式。
|
||||
好：
|
||||
- 描写焦点已是「让步或反抗的那一刻」→ 详写只写「让步与反抗」，不把体验内核再写一遍。
|
||||
- 风格推荐：「短句、少形容词、对话压成一句」。本局要求同样只写节奏和句段。
|
||||
- 视角：「第二人称贴身；只写你的内心；NPC 只写外显」。
|
||||
|
||||
缺料时：
|
||||
- 文风库没有贴合条目 → gap 问一个方向，不编第三种文风充数。
|
||||
- 交互范式未定人称 → 按美学站位先写一种执行，gap 标明。
|
||||
|
||||
偏了就改回：
|
||||
- 风格推荐写成某角色的台词，或「骄横千金被按住后改口」→ 改成节奏、用词、句段。
|
||||
- 详写把「反复感到掌控」再写一遍 → 删掉，只留焦点里的对象或瞬间。
|
||||
- 禁忌把美学的边界与尺度整段抄来 → 只留真正碰不得的短句。
|
||||
```
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 产物外壳：`docs/context-fragment-design.md`；对照美学：感觉 → 本步「怎么写、故事怎么往前」。
|
||||
> **一份产物、一次询问**；转述与主世界层都挂同一份（不必为省 token 拆成两套投影）。
|
||||
> **工序编排用本步。** 对话落盘拆成「叙事指南」与「故事推进」，不要在落盘池排本步。
|
||||
> **工序编排用本步。** 对话落盘拆成「叙事指南」与「故事推进与交互范式」，不要在落盘池排本步。
|
||||
> 旧称：叙事指南。
|
||||
|
||||
## meta
|
||||
@@ -18,8 +18,8 @@ when: |
|
||||
已有美学纲领（或等价），但转述/主世界层仍会不知道这四件：遣词什么味道、笔墨落谁身上、绝对不能写什么、故事靠场面自己推还是等用户。
|
||||
用户主动谈文风、措辞禁忌、写法档（官能/爽文/恐怖/情色等）也排。
|
||||
when_not: |
|
||||
本技能只给工序编排。对话落盘不排本步（落盘池是「叙事指南」与「故事推进」）。
|
||||
美学未钉 → 先「美学纲领与交互范式」。
|
||||
本技能只给工序编排。对话落盘不排本步（落盘池是「叙事指南」与「故事推进与交互范式」）。
|
||||
美学未钉 → 先「美学纲领」。
|
||||
用户只要感觉/站位、不要文风细则 → 不排，沿用美学。
|
||||
版式/壳 → 「正文组成」；每轮看什么（字数/变量/日期）→ 「回复呈现」。
|
||||
事件池 schema、真值增减 → 「生成规则」/「变量设计与更新规则」。
|
||||
@@ -86,7 +86,7 @@ summary：`叙事指南与故事推进 · …`
|
||||
- **续写**（旧称扮演停笔）：行为与对话作拓写起点；装载上列准则；主角设定偏好同大纲扩写。
|
||||
- **自动写入**：短 meta/极简扮演→长续写；允许按主角设定代写用户角色；倾向详钉性格。
|
||||
4. 情境备用是写法档：名字用「官能小说」「网文爽文」「展示恐怖」「展示情色」同级；用法写该档遣词与何时切入。无切换则空数组。
|
||||
5. 工序编排保持本步一份产物；对话落盘拆成「叙事指南」与「故事推进」，不要在本步执行时再拆技能。
|
||||
5. 工序编排保持本步一份产物；对话落盘拆成「叙事指南」与「故事推进与交互范式」，不要在本步执行时再拆技能。
|
||||
6. 字数区间归「回复呈现」；本步管怎么写与怎么推，不重钉字数。
|
||||
```
|
||||
|
||||
|
||||
@@ -13,9 +13,9 @@ when: |
|
||||
LLM 获得较多推进权，而现有材料不足以稳定代演该角色时也使用。
|
||||
when_not: |
|
||||
旁观、无固定主角或纯作者视角时不使用。刻意无名的自我投射不因缺名字而强制使用。
|
||||
NPC 有多份或需要统一字段时归生成规则，要留下的单条再写具体实例；世界硬法则归实现机制；第一幕归开场白。
|
||||
NPC 有多份或需要统一字段时归生成规则，要留下的单条再写具体实例；世界硬法则归世界法则；第一幕归开场白。
|
||||
boundary: |
|
||||
本能力只交用户角色名片和必要行为依据。体验与权限来自美学纲领，输入及推进方式来自故事推进，本步据此控制详略。
|
||||
本能力只交用户角色名片和必要行为依据。体验与权限来自美学纲领，输入及推进方式来自故事推进与交互范式，本步据此控制详略。
|
||||
feeds: gm
|
||||
```
|
||||
|
||||
@@ -28,9 +28,9 @@ feeds: gm
|
||||
## task
|
||||
|
||||
```task
|
||||
把用户材料整理为本局用户角色名片，写入 `设计.主角设定`。先保留承载核心体验的身份、能力、关系与限制，再按 LLM 获得的推进权决定是否需要行为依据。
|
||||
把用户材料整理为本局用户角色名片，写入 `设计.主角设定`。先保留承载体验的身份、关系和此人能做的那一件，再按故事推进与交互范式里的代写权限决定要不要行为依据。
|
||||
|
||||
用户自己扮演或提供详细大纲时，身份背景够用即可，不替用户设计人格与选择。LLM 代演越多，性格、处事倾向和默认反应越需要具体可执行。产物正文不放评分、追问或诊断。
|
||||
`特殊设定` 只写这张名片上的能力或身份。拓扑图谱或世界法则里已有的档位、百分比、价目和阶段链不抄进来，作用里点图名或机制名即可。用户自己扮演时，身份背景够用即可，不替用户设计人格与选择。产物正文不放评分、追问或诊断。
|
||||
```
|
||||
|
||||
## principles
|
||||
@@ -39,7 +39,7 @@ feeds: gm
|
||||
1. 只设计用户已明确给出、核心体验依赖或运行确实需要的内容。
|
||||
2. 一张脸测试：逐句问「删掉这句，玩家还知道自己是谁吗？」删了仍知道的句子不落盘。
|
||||
3. “首富之子”“唯我独法”等若是核心体验成立条件，属于必要设定，不算过度设计。
|
||||
4. 特殊能力写“能做什么 + 限制”；世界为何如此由实现机制处理。
|
||||
4. 特殊设定写此人能做什么，限制写做不到什么。档位、百分比、价目、阶段链已在拓扑图谱或世界法则里时，作用只点图名或机制名。作用与设定是同一句时省略作用。
|
||||
5. `称呼` 可写固定名字，也可写 `@玩家` 表示刻意留白；不要因无名阻塞成卡。
|
||||
6. 身份与背景一两句；用户没给就写「未定」或省略，不代编来历。
|
||||
7. 行为依据随推进权增减：用户控制越多越简；LLM 代演越多越具体。
|
||||
@@ -62,7 +62,7 @@ feeds: gm
|
||||
"特殊设定": [
|
||||
{
|
||||
"设定": "身份、能力、关系或随身之物",
|
||||
"作用": "它怎样承载核心体验或影响世界反应",
|
||||
"作用": "可选；此人因此能做什么。与设定同义，或只是机制公式的复述时省略",
|
||||
"限制": "无则省略"
|
||||
}
|
||||
],
|
||||
@@ -80,6 +80,7 @@ feeds: gm
|
||||
2. 不写产物内自评、追问、开放问题或完备度。
|
||||
3. 不把核心体验所依赖的身份、能力或关系误删为“过度设计”。
|
||||
4. 不替用户补未授权的人格、目标、情绪和关键决定。
|
||||
5. `特殊设定` 不复制拓扑图谱或世界法则里的档位表、百分比、价目和阶段链。
|
||||
|
||||
## score
|
||||
|
||||
@@ -102,14 +103,17 @@ feeds: gm
|
||||
- [ ] 非必要、未经确认的性格与行为设计已删除？
|
||||
- [ ] 行为依据的详细度与 LLM 推进权匹配？
|
||||
- [ ] 称呼允许固定名字或 `@玩家` 留白？
|
||||
- [ ] 未写 NPC、世界百科、文风或开场事件？
|
||||
- [ ] 特殊设定没有抄机制里的档位、百分比或价目？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
- 好：称呼「林晚」；身份与背景一句穿来当日的处境；特殊设定「能看见别人对她的好感数字」，限制「别人看不见」。
|
||||
- 坏：把侯府地理、朝堂势力写进背景。
|
||||
- 坏：把开场羞辱戏全文写进名片。
|
||||
- 坏：为宿舍开场和天台开场各写一张 `设计.主角设定#短码`；各开场不同的处境应写进对应开场白的 `meta.用户角色`。
|
||||
- 好：复制能力的作用只写「接触后可复制对方一项能力」，五档百分比留在拓扑图谱，这里点图名。
|
||||
|
||||
偏了就改回：
|
||||
- 作用写成 1%–100% 的五档表 → 删表，作用留一句能做什么，或与设定同义则省略。
|
||||
- 把侯府地理、朝堂势力写进背景 → 收到舞台或开场白。
|
||||
- 为宿舍开场和天台开场各写一张 `设计.主角设定#短码` → 各开场不同的处境写进对应开场白的 `meta.用户角色`。
|
||||
```
|
||||
|
||||
@@ -13,7 +13,7 @@ when: |
|
||||
机制、变量或生成规则已出现必须用随机数才能裁定的点时使用。
|
||||
when_not: |
|
||||
全程不靠随机推进 → 不使用。
|
||||
公式本身还没钉死 → 先实现机制、生成规则或变量设计。
|
||||
公式本身还没钉死 → 先世界法则、生成规则或变量设计。
|
||||
按合理度从池里选，而不是抽签 → 不列入。
|
||||
boundary: |
|
||||
不新建表，不发骰面。数字是普通隐藏变量，默认玩家看不见。
|
||||
@@ -30,7 +30,7 @@ feeds: gm
|
||||
## task
|
||||
|
||||
```task
|
||||
先扫实现机制、生成规则、变量设计、叙事与故事推进、美学，列出所有需要随机数才能裁定的点，再写入 `设计.随机范围整理`。每项是 `变量.当前` 的一行，行名写成「名称.随机数」，玩家默认不可见。值是剩余数字组成的数组，下一个可用的是第一个。
|
||||
先扫世界法则、生成规则、变量设计、叙事与故事推进、美学，列出所有需要随机数才能裁定的点，再写入 `设计.随机范围整理`。每项是 `变量.当前` 的一行，行名写成「名称.随机数」，玩家默认不可见。值是剩余数字组成的数组，下一个可用的是第一个。
|
||||
|
||||
用掉第一个后，程序改写这一行，去掉那个数。改完后如果只剩 1 个，就按范围补到预备个数，不要等这一行空了。模型不自己编数字。
|
||||
|
||||
|
||||
@@ -40,10 +40,10 @@ boundary: |
|
||||
你正在执行「细化终稿」。产物必须写入 **设计.worker集**，且为 **JSON**。
|
||||
|
||||
本步是收成，不是发明新执行单元。优先合并：
|
||||
- 设计.美学纲领与交互范式 → interaction / experience_check
|
||||
- 设计.美学纲领（旧档仍认 设计.美学纲领与交互范式）→ interaction / experience_check
|
||||
- 设计.worker规格（游玩拓扑）→ play_slots 或 writing_slots
|
||||
- 设计.上下文投影排序 → 写入规格的 context_order（每槽 inserts：order/anchor/ref/projection）；无表且上下文很少时可按默认 static/dynamic 退化
|
||||
- 设计.叙事指南 / 设计.故事推进（工序编排：设计.叙事指南与故事推进）/ 世界 / 机制 / 生成规则等 → resident_context（挂载以排序表与 mount 为准，本步不重排数字序）
|
||||
- 设计.叙事指南 / 设计.故事推进与交互范式（旧档 设计.故事推进；工序编排：设计.叙事指南与故事推进）/ 世界 / 机制 / 生成规则等 → resident_context（挂载以排序表与 mount 为准，本步不重排数字序）
|
||||
- 设计.变量设计与更新规则 → tables.side_effects（及 schemas 摘要）
|
||||
- 设计.变量控制上下文 → 核对挂载与剧透，写入 notes 或 resident 短句
|
||||
|
||||
|
||||
@@ -21,7 +21,9 @@ boundary: |
|
||||
隐藏维护区不进 DOM；表由旁观副 LLM 维护，主回复不建填表通道。
|
||||
随机数是变量表隐藏行，也与本能力无关。
|
||||
壳参考库只提供布局与交互方法参考，不是必须照抄的固定产品模板。
|
||||
feeds: gm,narrator
|
||||
创作时一次写好 frontend 并由程序持有；游玩不把 html/css/js 塞进模型上下文。
|
||||
程序按数据契约要求模型只交 present.v1 各 block（如正文、标题、选项），再灌进已固定的壳。
|
||||
feeds: program
|
||||
```
|
||||
|
||||
## opening
|
||||
@@ -75,7 +77,7 @@ feeds: gm,narrator
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "正文组成",
|
||||
"brief": "一句话说明普通消息的阅读结构与特殊渲染",
|
||||
"mount": ["world-simulator", "narrator"],
|
||||
"mount": [],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"参考壳": [
|
||||
@@ -148,7 +150,7 @@ feeds: gm,narrator
|
||||
6. `示例灌数` 是非正史预览，schema 固定 `present.v1`，只含用户可见 blocks。
|
||||
7. 不重定义语义区域、篇幅、文风、变量规则、随机数或 0 层槽位更新。
|
||||
8. 产物正文不含自评、追问或开放问题。
|
||||
9. `mount` 固定为 `["world-simulator", "narrator"]`；兼容旧称 tag `设计.回复格式`。
|
||||
9. `mount` 固定为 `[]`：壳不进游玩投影；程序持有 frontend，只向模型注入数据契约。兼容旧称 tag `设计.回复格式`。
|
||||
|
||||
## score
|
||||
|
||||
|
||||
@@ -9,14 +9,16 @@ artifact: 设计.监控栏
|
||||
declaration: >
|
||||
定义普通楼层每轮回复实际启用的语义区域、出现条件、权威来源与内容要求；不决定前端排版和渲染。
|
||||
when: |
|
||||
已有故事推进及本局需要展示的变量、拓扑或其它内容后使用；排在正文组成与开场白之前。
|
||||
本局会游玩、每轮有一条助手回复时就使用。默认声明正文区和文字选项；用户明确不要选项时关掉选项区。回复里还有抬头、状态、小故事或数据卡时，也在本步声明。
|
||||
排在故事推进与交互范式之后、正文组成之前。用户谈到选项、状态栏、每轮除正文外还看什么时也使用。
|
||||
when_not: |
|
||||
每轮只需普通正文且语义合同已由上游明确、无需额外区域时可使用最小正文区域，不扩展其它块。
|
||||
只讨论 HTML、CSS、Tab、分区或具体渲染 → 正文组成。
|
||||
本局没有游玩回复（纯转换、资料整理、一次性成稿）→ 不使用。
|
||||
持久 0 层卡、不增加普通楼层 → 0层回复呈现。
|
||||
语义区已经钉死，只讨论 HTML、CSS、Tab 或分区 → 正文组成。语义区还没有时，仍先本步。
|
||||
boundary: |
|
||||
本能力决定回复由哪些可见或隐藏语义区域组成、何时出现、内容来自哪里、怎样才算填对。
|
||||
正文组成负责把这些区域放到前端的具体位置并实现 HTML/CSS/JS、Tab 和特殊渲染。
|
||||
故事推进是单轮字数及扩写/续写预算的唯一来源；本能力不重复定义篇幅。
|
||||
字数区间与扩写/续写占比以故事推进与交互范式已写的为准，本步照写进正文内容要求，不另起一套数字。
|
||||
变量设计与拓扑图谱定义权威数据和更新规则；本能力只决定回复是否包含其展示区或隐藏更新区。
|
||||
feeds: gm,narrator
|
||||
```
|
||||
@@ -24,7 +26,7 @@ feeds: gm,narrator
|
||||
## opening
|
||||
|
||||
```opening
|
||||
每轮回复除正文外，还需要哪些语义内容？逐项说明它何时出现、由模型生成还是由程序投影，以及用户是否可见。若有地图或状态展示，请指出权威数据来源；若维护策略要求结构化隐藏更新，也把它列为隐藏区域。
|
||||
每轮回复除正文外，还需要哪些可见内容？逐项说明它何时出现、由模型生成还是由程序投影，以及用户是否可见。有地图或状态时，指出要投影的字段。
|
||||
```
|
||||
|
||||
## task
|
||||
@@ -39,7 +41,7 @@ feeds: gm,narrator
|
||||
- 对应的上游引用与正向内容要求。
|
||||
- 没有内容时是省略、给空态，还是仍须输出。
|
||||
|
||||
正文区域只引用 `设计.故事推进` 的单轮篇幅与扩写/续写预算，不复制数值。状态、地图等权威内容使用程序投影，正文模型不重复生成。选项若启用，写清数量、各项的差异维度（如冒险/稳重）和每项的组成规则，让选项彼此不同；不声明点击交互。
|
||||
正文区的 `内容要求` 照写 `设计.故事推进与交互范式` 里已经定下的目标字数或区间、扩写占比、续写占比。数字与上游一致，不另起一套。状态、地图等权威内容使用程序投影，正文模型不重复生成。文字选项默认启用：`内容约束` 写 4 条，每条约束选项该满足什么，不写成品行动句。用户明确不要选项时，省略该区。
|
||||
|
||||
表维护由旁观副 LLM 固定承担；本步**不**建立主回复里的隐藏变量更新区（无 `state_ops` / maintenance_channel）。可见区只投影权威数据。
|
||||
|
||||
@@ -52,10 +54,10 @@ feeds: gm,narrator
|
||||
1. 语义区域回答“回复里有什么”，正文组成回答“在前端哪里、怎么显示”。
|
||||
2. 只写实际启用区域。固定每轮出现用 `every_turn`；条件出现须给可判定条件。
|
||||
3. 模型生成区写内容要求；程序投影区写权威 ref 与字段选择。程序已有的数据不让模型复述一份。
|
||||
4. 正文篇幅、扩写和续写预算只引用故事推进；文风只引用叙事指南。
|
||||
4. 正文内容要求照写故事推进与交互范式里的字数区间和扩写/续写占比，数字保持一致。文风只引用叙事指南，不抄遣词全文。
|
||||
5. 状态与拓扑的真相来自运行数据。可见区域只选择投影字段，不在这里修改变量或拓扑。
|
||||
6. 不在主回复建隐藏填表区；表由旁观副 LLM 维护。
|
||||
7. 选项是文本建议。是否有交互、点击后做什么，只有正文组成和宿主前端真正实现时才声明。
|
||||
7. 文字选项默认每轮都有，用户明确不要时整区省略。选项是文本建议；是否可点击，只有正文组成和宿主前端真正实现时才声明。
|
||||
8. 区域要求使用正向规格；没有特殊要求便保持短，不为完整感堆区域。
|
||||
9. 每个可见区属于一种：抬头、正文、小故事、数据卡、结构、文字选项。抬头是页首一行短内容；小故事是旁支短文，不推进主线，也不复述正文；条目一多或当前值一长则改用数据卡。数据卡和结构要写出露出的列或字段。
|
||||
```
|
||||
@@ -90,11 +92,12 @@ feeds: gm,narrator
|
||||
"区域种类": "正文",
|
||||
"来源": {
|
||||
"方式": "model_generated",
|
||||
"ref": "设计.故事推进"
|
||||
"ref": "设计.故事推进与交互范式"
|
||||
},
|
||||
"内容要求": [
|
||||
"遵守故事推进中的单轮篇幅与扩写/续写预算",
|
||||
"遵守叙事指南；在本轮自然停笔点结束"
|
||||
"目标字数或区间：照写故事推进与交互范式",
|
||||
"扩写占比与续写占比：照写故事推进与交互范式，两者一致",
|
||||
"遵守叙事指南"
|
||||
],
|
||||
"空值处理": "error"
|
||||
},
|
||||
@@ -107,13 +110,12 @@ feeds: gm,narrator
|
||||
"方式": "every_turn|conditional",
|
||||
"条件": "conditional 时写程序或模型可判断的条件"
|
||||
},
|
||||
"内容类型": "text|markdown|kv|list|table|topology|state_ops",
|
||||
"区域种类": "小故事|数据卡|结构|文字选项",
|
||||
"内容类型": "text|markdown|kv|list|table|topology",
|
||||
"区域种类": "抬头|小故事|数据卡|结构|文字选项",
|
||||
"来源": {
|
||||
"方式": "model_generated|program_projection|maintenance_channel",
|
||||
"方式": "model_generated|program_projection",
|
||||
"ref": "上游产物、运行状态或维护策略的稳定引用",
|
||||
"字段": ["程序投影时只选择实际需要的字段"],
|
||||
"投递": "仅维护区使用：runtime_selects_tool_or_structured"
|
||||
"字段": ["程序投影时只选择实际需要的字段"]
|
||||
},
|
||||
"内容要求": [
|
||||
"正向说明该区域应该提供什么"
|
||||
@@ -133,17 +135,19 @@ feeds: gm,narrator
|
||||
"区域种类": "文字选项",
|
||||
"来源": {
|
||||
"方式": "model_generated",
|
||||
"ref": "设计.故事推进"
|
||||
"ref": "设计.故事推进与交互范式"
|
||||
},
|
||||
"选项": {
|
||||
"数量": 2,
|
||||
"各项": [
|
||||
{ "差异维度": "冒险", "组成": "一句推进风险或探索的具体行动" },
|
||||
{ "差异维度": "稳重", "组成": "一句观察、保守或缓和局面的具体行动" }
|
||||
"数量": "本局每轮几条",
|
||||
"内容约束": [
|
||||
"选项必须满足的条件",
|
||||
"第二条约束，仍不是成品行动",
|
||||
"第三条约束",
|
||||
"第四条约束"
|
||||
]
|
||||
},
|
||||
"内容要求": [
|
||||
"每项是用户角色此刻能直接采取的一句行动，按各自差异维度写，彼此不重复"
|
||||
"按四条内容约束生成；每条是约束，不是成品行动"
|
||||
],
|
||||
"空值处理": "omit"
|
||||
}
|
||||
@@ -154,11 +158,11 @@ feeds: gm,narrator
|
||||
|
||||
硬规则：
|
||||
1. 输出合法 JSON；`语义区域` 只含实际启用项，不写 `启用:false` 或未启用清单。
|
||||
2. 普通楼层至少含 `body`；正文只引用故事推进，不复制目标字数、占比或字数预算。
|
||||
2. 普通楼层至少含 `body`，默认再含文字选项。正文 `内容要求` 照写故事推进与交互范式的字数区间和扩写/续写占比，不另起数字。
|
||||
3. 每个区域必须声明出现方式、内容类型、区域种类、来源、内容要求和空值处理。可见区的区域种类只能是抬头、正文、小故事、数据卡、结构、文字选项。
|
||||
4. `program_projection` 必须给稳定 ref；状态和拓扑数据不得标为临场或要求模型重新生成。
|
||||
5. 不建立主回复隐藏填表区（无 `state_ops` / `maintenance_channel`）；表由旁观副 LLM 维护。
|
||||
6. 文字选项须含 `选项`：数量，以及每项的差异维度和组成；不写可点击、按钮动作或回传协议。
|
||||
6. 文字选项默认写入。`内容约束` 恰好 4 条，每条是对选项的约束，不是成品行动。不写可点击、按钮动作或回传协议。用户明确不要选项时省略该区。
|
||||
7. 不选壳，不写布局、HTML、CSS、JS、Tab、SVG 或槽位替换；这些属于正文组成。
|
||||
8. 产物正文不含自评、追问或开放问题。
|
||||
9. `mount` 固定为 `["world-simulator", "narrator"]`；artifact tag 暂时保留 `设计.监控栏`。
|
||||
@@ -187,9 +191,9 @@ feeds: gm,narrator
|
||||
- 1：正文外长期堆积大量无关信息。
|
||||
|
||||
职责边界：
|
||||
- 5：只定义语义内容，并把渲染、维护真相和篇幅分别交给正确节点。
|
||||
- 3：主体边界正确，但夹有少量排版或重复篇幅要求。
|
||||
- 1：在本步写 HTML、变量公式或重新定义推进篇幅。
|
||||
- 5：只定义语义内容；字数区间和占比与故事推进与交互范式一致，渲染和变量真相交给对应节点。
|
||||
- 3：主体边界正确，但夹有少量排版，或占比和上游不一致。
|
||||
- 1：在本步写 HTML、变量公式，或另起一套字数。
|
||||
```
|
||||
|
||||
## checklist
|
||||
@@ -198,18 +202,27 @@ feeds: gm,narrator
|
||||
- [ ] 只列实际启用区域，普通楼层含正文？
|
||||
- [ ] 每个区域的出现条件、来源、要求与空值处理完整？
|
||||
- [ ] 状态、地图等权威数据均由程序投影，模型没有重复生成？
|
||||
- [ ] 内联维护的隐藏 state_ops 已声明运行期选路，副 Worker 路径未建立该区？
|
||||
- [ ] 正文只引用故事推进，没有重复字数和比例？
|
||||
- [ ] 没有建立主回复里的隐藏填表区？
|
||||
- [ ] 正文内容要求写了字数区间和扩写/续写占比，且与故事推进与交互范式一致？
|
||||
- [ ] 默认有文字选项；内容约束恰好 4 条，每条是约束而不是成品行动？
|
||||
- [ ] 用户明确不要选项时，该区已省略？
|
||||
- [ ] 未写布局、HTML/CSS/JS、Tab、SVG 或交互动作？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
- 只有正文：只列 body，并引用故事推进和叙事指南。
|
||||
- 展示状态：新增 kv 区域，来源指向变量当前值及明确字段；内容由程序投影。
|
||||
- 展示地图：新增 topology 区域，说明用户应看到哪些节点、连接或当前位置；具体 SVG、表格或 Tab 留给正文组成。
|
||||
- 简单变量内联维护：新增用户不可见的 state_ops 语义区域；运行期优先投递为 tool call，工具不可用时进入结构化整包。
|
||||
- 文字选项：写数量、彼此差异和应提供的行动方向；不声明点击行为。
|
||||
- 坏：只写「要选项」，不定数量、各项差异维度与组成，结果每轮几条选项大同小异。
|
||||
好：
|
||||
- 正文内容要求照写上游已定的「800–2500 字，扩写 60%，续写 40%」，不改成另一套区间。
|
||||
- 文字选项默认在。内容约束四条，例如「一句此刻能做的行动」「彼此风险不同」「不写旁白」「不重复上轮原句」。
|
||||
- 展示状态：新增 kv 区，来源指向变量当前值及要露出的字段，由程序投影。
|
||||
|
||||
缺料时：
|
||||
- 故事推进还没写字数区间 → 正文内容要求该项写「未定」，gap 指向那一份，不在本步另定数字。
|
||||
- 用户说不要选项 → 省略文字选项区，其余照写。
|
||||
|
||||
偏了就改回：
|
||||
- 内容约束写成四条成品行动（「推门进去」「先观察」）→ 改成四条必须满足的约束。
|
||||
- 本步把 800–2500 改成 2000–4000 → 改回故事推进与交互范式里的数字。
|
||||
- 为了完整感再加隐藏填表区 → 删掉；表由旁观副 LLM 维护。
|
||||
```
|
||||
|
||||
@@ -1,43 +1,45 @@
|
||||
# 故事推进
|
||||
# 故事推进与交互范式
|
||||
|
||||
## meta
|
||||
|
||||
```meta
|
||||
name: 故事推进
|
||||
name: 故事推进与交互范式
|
||||
id: story-progression
|
||||
artifact: 设计.故事推进
|
||||
artifact: 设计.故事推进与交互范式
|
||||
declaration: >
|
||||
继承交互范式的描写权限与停笔时机，从偏好库选取本局约束，钉推进方式（可无专门推进），只选定一种用户输入用法；每一轮正文分成扩写（演本轮材料）与续写（材料后往下写），写清定义、字数分配与 OOC 处理；不写遣词。
|
||||
把交互权限和推进合同写成同一份：谁能代写、谁裁定、何时停笔，以及唯一输入用法、扩写/续写和单轮篇幅。不写遣词。
|
||||
when: |
|
||||
已有美学纲领（或等价），但尚未钉死唯一的用户输入用法，或扩写/续写边界与比例仍不清，或还不知道故事靠场面自推、等用户决策还是无专门推进。
|
||||
用户主动谈推进、节奏、停笔、大纲扩写、续写、自动写入、单轮字数时也使用。
|
||||
已有美学体验（或等价短锚），但还没把权限和推进钉成一份合同：谁代写、何时停、输入是大纲还是扮演、扩写和续写各做什么、单轮多长。
|
||||
用户主动谈权限、停笔、推进、大纲扩写、续写、自动写入、单轮字数时也使用。
|
||||
when_not: |
|
||||
本技能只给对话落盘。工序编排不排本步（编排池是「叙事指南与故事推进」）。
|
||||
美学未钉 → 先「美学纲领与交互范式」。
|
||||
只改遣词、笔墨、写法档、段落形态 → 「叙事指南」。可见区域 → 「回复呈现」。
|
||||
好感公式、进度表、事件池等表规格 → 「变量设计与更新规则」/「生成规则」。
|
||||
固定输入标记（裸写 / `#行动#` / 引号）由程序解析，不在本步重定义或按局反转。
|
||||
体验内核还没有 → 先「美学纲领」。本步引用那三句短锚，不改写体验正文。
|
||||
只改遣词、笔墨、写法档、段落形态 → 「叙事指南」。
|
||||
每轮回复里有哪些区域、选项怎么列 → 「回复呈现」。
|
||||
好感公式、进度表、事件池 → 「变量设计与更新规则」/「生成规则」。
|
||||
固定输入标记（裸写 / `#行动#` / 引号）由程序解析，不在本步重定义。
|
||||
boundary: |
|
||||
本能力只交推进合同：推进方式及可选的驱动力、成败与难度、变量钩子；唯一输入用法、单轮目标字数、扩写要求、续写要求、篇幅分配、OOC 处理策略。
|
||||
单轮字数与篇幅只在本步定义；段落形态（长段不碎行）归叙事指南，可见区域归回复呈现。
|
||||
叙事指南管怎么写；变量与生成规则管表与合同，本步只写钩子；主角详略只写偏好钩子。
|
||||
本步交两块，写在同一份产物里：`交互范式`（权限与停笔）和推进合同（用法、扩写、续写、篇幅）。
|
||||
停笔只写在 `交互范式.停笔时机`；续写要求只写怎样走到这个停点，不把停笔条件再写一遍。
|
||||
单轮字数只在本步定义。选项、抬头、状态等可见区域归回复呈现。段落形态归叙事指南。
|
||||
变量与生成规则管表，本步只写钩子。
|
||||
feeds: gm,narrator
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
先选定这局唯一的输入用法：大纲扩写、续写，或自动写入。再说清楚单轮大约写多长；扩写（主路径不动，在用户已给的节拍之间补连接小动作，把场面写顺）和续写（从材料结束后往下写他人与世界反应）各做什么、各占多少。上帝视角/OOC 指令准备怎么处理。故事要不要专门往前推、用户会不会失败，也可以一并说；没想过就按体验先定。
|
||||
先钉谁能替你写、写到哪必须停。再选定唯一输入用法：大纲扩写、续写，或自动写入。然后说单轮大约多长，扩写和续写各做什么、各占多少。
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
把本局推进合同写入 `设计.故事推进`。先继承上游「美学纲领与交互范式」：把 `交互范式.描写权限`（思考与抉择、言语、主动行动、用户输入后）、`后果与叙事控制` 与 `停笔时机` 改写成推进做法；交互范式已写过停笔权限，也要落进本步的用法与续写要求，不因已有而省略。再用 `read_library_entry` 从绑定的偏好库读取最相关 1～2 条并本局化，然后钉推进方式（不明则写「无专门推进」），只选定一种用户输入用法。
|
||||
把交互权限和推进合同一起写入 `设计.故事推进与交互范式`。先读美学的体验锚定三句，按它写 `交互范式`：人称与视角、逐类描写权限、后果由谁裁定、停笔时机。权限要让那句体验发生得了。再用 `read_library_entry` 从偏好库取最相关 1～2 条并本局化，钉推进方式（不明则「无专门推进」），只选一种用户输入用法。
|
||||
|
||||
扩写与续写是每一轮正文里的两段工作，不是两种输入用法。按所选用法写清单轮目标字数、扩写做什么、续写做什么、两者各自篇幅预算，以及裸写（上帝视角/OOC）指令如何处理。
|
||||
扩写与续写是每一轮正文里的两段工作，不是两种输入用法。按所选用法写清扩写做什么、续写怎样走到已写的停笔时机、两者的字数预算，以及裸写指令如何处理。停笔条件不在续写要求里再抄一遍。
|
||||
|
||||
禁止混用两种用法或写成半套规则。固定标记怎么识别交给程序；本步只写识别之后怎么服从与落笔。不写遣词、段落形态、示范段落或版式。
|
||||
不混用两种用法。固定标记怎么识别交给程序；本步只写识别之后怎么服从。不写遣词、段落形态、选项清单或版式。
|
||||
|
||||
材料足够便直接成稿；多种用法都像、必须用户点选时，把缺口交给 `self_score.gap`。产物正文不放评分、诊断、追问或开放问题。
|
||||
```
|
||||
@@ -53,7 +55,7 @@ feeds: gm,narrator
|
||||
3. 续写：从用户材料结束后往下写。写其他角色与世界如何反应、把场面推到下一个停笔点。默认不可再写用户角色的实际行动、说话或带倾向抉择；最多被动占位（望去、让开）。整轮停在其他角色等用户角色行动抉择之刻。
|
||||
- 用法为「大纲扩写」或「续写」时：禁止替用户角色做决定，不引入材料外的新剧情事实。
|
||||
- 用法为「自动写入」时：可按主角设定代演用户角色言行，把续写写长；关键抉择仍按交互范式的权限处理。
|
||||
4. 三种输入用法互斥，按体验与交互范式选一种，写入时只保留一个完整合同。差别在输入是什么、扩写/续写谁长谁短、续写能不能代演用户角色：
|
||||
4. 三种输入用法互斥，按刚写的交互范式选一种。差别在输入是什么、扩写/续写谁长谁短、续写能不能代演用户角色：
|
||||
- 大纲扩写：用户是写手、要大纲成稿，输入多为剧情节拍时选它。扩写充分、续写短。
|
||||
- 续写（旧称扮演停笔）：代入扮演、轮转等用户决策时选它（交互范式规定关键抉择或言语只由用户做、停笔时机是等用户回应）。输入往往较短；扩写只跟已声明内容，续写多于大纲扩写、短于自动写入。
|
||||
- 自动写入：用户只给短 meta 指令或极简扮演、希望 AI 代演用户角色，且交互范式允许模型代写 user 言行（旁观、操控站位常见）时选它。扩写少、续写宜长。
|
||||
@@ -66,7 +68,7 @@ feeds: gm,narrator
|
||||
8. OOC/上帝视角内容由程序从裸写识别；本步写处理策略：服从到什么程度、是否打断当前场面、如何与既定扩写/续写比例兼容。
|
||||
9. 偏好库是参考：读取后改成本局可执行要求，不照抄。
|
||||
10. 单轮篇幅在这里一次钉死：给目标字数或窄区间，并把扩写、续写的占比与字数预算对应起来；其它节点直接消费，不重复定义。段落形态归叙事指南，本步不写。
|
||||
11. 不写遣词、写法档、段落形态、版式或事件池公式。
|
||||
11. 不写遣词、写法档、段落形态、版式、选项文案或事件池公式。可见区域交给回复呈现。
|
||||
```
|
||||
|
||||
## output
|
||||
@@ -74,11 +76,41 @@ feeds: gm,narrator
|
||||
```output
|
||||
{
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "故事推进",
|
||||
"技能": "故事推进与交互范式",
|
||||
"brief": "一句话：唯一输入用法 + 单轮篇幅与扩写/续写分配",
|
||||
"mount": ["world-simulator", "narrator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"交互范式": {
|
||||
"前置配置": {
|
||||
"用户与user关系": "完全代入 / 部分代入 / 旁观 / 操控",
|
||||
"人称": "如：第二人称称「你」",
|
||||
"元叙事": "决策是否用情节呈现"
|
||||
},
|
||||
"叙事视角": {
|
||||
"主要视角": "镜头跟谁、看什么",
|
||||
"视角切换": "不允许，或允许的例外",
|
||||
"可写内心": "可以写谁的内心",
|
||||
"不呈现的信息": "正文不能透露的内容"
|
||||
},
|
||||
"描写权限": {
|
||||
"思考与抉择": "关键决定写到哪里停",
|
||||
"言语": "能否替 user 说话、说到什么程度",
|
||||
"主动行动": "能否替 user 发起行动",
|
||||
"情绪与身体反应": "可补写的范围",
|
||||
"习惯与既有技能": "可按既有设定自动执行的部分",
|
||||
"外在状态": "外貌、伤势、衣着可否直接写",
|
||||
"用户输入后": "只确认 / 补细节 / 连带推出后果"
|
||||
},
|
||||
"后果与叙事控制": {
|
||||
"行为后果判定": "谁裁定成败与代价",
|
||||
"世界对user的影响": "NPC 与世界如何作用于 user",
|
||||
"时间与场景": "可否推进时间、切换场景，跨度多大",
|
||||
"引入新内容": "可否引入新人物、事件、威胁",
|
||||
"设计困境": "是否制造两难；怎样的两难服务体验"
|
||||
},
|
||||
"停笔时机": "必须等用户的时机；续写停在这里，不另写一套"
|
||||
},
|
||||
"选用偏好": [
|
||||
{
|
||||
"库条目": "preferences 中的 id",
|
||||
@@ -113,7 +145,7 @@ feeds: gm,narrator
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. 输出合法 JSON；`用户输入用法` 只能是三者之一，不得并列或混装半套。
|
||||
1. 输出合法 JSON。`交互范式` 与推进合同在同一份正文里。`用户输入用法` 只能是三者之一。`停笔时机` 是唯一停笔定义；`续写要求` 只写如何走到该停点。不写选项清单。
|
||||
2. `扩写要求` 只写「把本轮材料演成场面」怎么做；`续写要求` 只写「材料结束后往下写」怎么做。不要把另一种输入用法的规则抄进这两项。两项占比合计 100%，字数预算与目标字数对应。
|
||||
3. `推进方式` 是单个字符串；`驱动力`、`成败与难度`、`变量钩子` 可选，`变量钩子` 不写公式或数值。
|
||||
4. `选用偏好` 默认 1～2 项；无合适条目时可 `[]`，但仍须钉死唯一用法。
|
||||
@@ -143,7 +175,7 @@ feeds: gm,narrator
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 已继承交互范式的描写权限与停笔时机并落进本步？
|
||||
- [ ] `交互范式` 已写清逐类权限、裁定和唯一停笔时机，并与输入用法一致？
|
||||
- [ ] 推进方式已写（不明则「无专门推进」），未发明公式、进度表或事件池？
|
||||
- [ ] 只选定一种用户输入用法，且符合它的适用场景？
|
||||
- [ ] 扩写与续写已按两段工作分别写清（扩写=演本轮材料，续写=材料后往下写），且与所选用法相符？
|
||||
|
||||
@@ -7,15 +7,20 @@ name: 拓扑图谱
|
||||
id: topology
|
||||
artifact: 设计.拓扑图谱
|
||||
declaration: >
|
||||
为一个独有但结构复杂的对象定义节点、连接、初始图与开场后的维护规则；可用于地图、关系链、升级树等可变备忘录。
|
||||
为一个独有但结构复杂的对象定义节点、连接、初始图与开场后的维护规则。
|
||||
地图、关系链、升级树，以及社会阶梯、境界、价目、兑换等级这类有序标尺，都在这里；一份产物一张图。
|
||||
when: |
|
||||
单个对象要用节点和连接才能写清时使用，例如地图、升级路径、关系网。
|
||||
要保存的结构是树、图或链时使用：节点之间有上下、相邻或交叉关系，拿掉连接就说不清。
|
||||
树：升级路径、分支前提、从属。
|
||||
图：地图、关系网，节点可多向相连。
|
||||
链：社会阶梯、境界、价目、兑换等级，每一档只和相邻档比较。
|
||||
一张图一份产物。不因开场后会不会再长节点而改用别的能力。
|
||||
when_not: |
|
||||
没有节点和连接，只是同类对象的多份记录，或一份要先审字段的合同 → 生成规则，再按需填具体实例。
|
||||
只有一条字段很少的具名内容，且用户明确要留下 → 具体实例。
|
||||
只有地点、势力或社会格局的叙述，没有可定义的连接 → 舞台骨架。
|
||||
只需保存少量数值或枚举 → 变量设计。
|
||||
世界里成立的因果、触碰的代价 → 世界法则；那里只点本图的图名，不抄档表。
|
||||
只需保存少量数值或枚举（当前点数、当前落在哪一档）→ 变量设计。
|
||||
boundary: |
|
||||
本能力定义一张图的结构真相与维护合同，不负责界面、SVG、排版或是否展示。
|
||||
「正文组成」决定是否渲染以及显示入口；维护合同编译工具负责把本产物的更新要求交给运行期维护者。
|
||||
@@ -26,7 +31,7 @@ feeds: gm,auditor
|
||||
## opening
|
||||
|
||||
```opening
|
||||
说说要保存的这张图是什么、游玩时用它记住什么，以及开场后它应保持固定、只记录状态，还是允许继续长出节点和连接。
|
||||
说说要保存的这张图是什么。地图、关系、升级树，或是一套有序标尺（社会阶梯、境界、价目、兑换等级）都可以。再补一句：开场后它保持固定、只记录状态，还是允许继续长出节点和连接。
|
||||
```
|
||||
|
||||
## task
|
||||
@@ -34,6 +39,8 @@ feeds: gm,auditor
|
||||
```task
|
||||
为一个独有的结构对象设计拓扑图谱，写入 `设计.拓扑图谱#图名`。每份产物只定义一张图：先写名称与用途，再定义节点字段、连接字段和初始图，最后写开场后的动态模式与维护规则。
|
||||
|
||||
有序标尺写成一条链，类型用 `path`：一档一个节点，连接只连相邻档。节点写这一档是谁、能做什么，或这一档的基价与强度；连接写跨过这一档要什么、和下一档差多少。档位在开场前已由用户定死时用 `static`。人物、物品、变量只填档名，不在别处重抄整表。
|
||||
|
||||
动态模式只选一种：
|
||||
- `static`：节点、连接和状态均固定。
|
||||
- `record`：节点与连接固定，但可记录发现、备注或节点/连接状态。
|
||||
@@ -47,7 +54,7 @@ feeds: gm,auditor
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 一产物一张图。不同地图、关系网或升级树分别调用本能力，不能塞进同一 `拓扑` 数组。
|
||||
1. 一产物一张图。不同地图、关系网、升级树或标尺分别调用本能力，不能塞进同一 `拓扑` 数组。社会阶梯和价目是两张图。
|
||||
2. 用途决定字段。节点与连接只保留识别、推演和维护所需信息；字段不重叠，不把节点写成完整名片。
|
||||
3. 节点 id 稳定且唯一；连接只能引用已存在节点，并明确方向、关系和必要属性。
|
||||
4. 动态模式决定维护权限：`static` 无运行写入；`record` 只改允许的状态字段；`expand` 才能改变图结构。
|
||||
@@ -157,9 +164,9 @@ feeds: gm,auditor
|
||||
|
||||
```score
|
||||
对象适配：
|
||||
- 5：确实是一张独有的关系结构，普通实例或扁平变量不足以表达。
|
||||
- 5：确实是一张独有的关系结构或有序标尺，普通实例或扁平变量不足以表达。
|
||||
- 3：存在真实连接，但部分内容可移交舞台、实例或变量。
|
||||
- 1：只是清单、名片或背景散文，没有拓扑必要性。
|
||||
- 1：只是互不相连的清单、名片或背景散文。
|
||||
|
||||
字段合同：
|
||||
- 5：节点与连接字段由用途推出，数量恰当、互不重叠，更新权限明确。
|
||||
@@ -199,6 +206,8 @@ feeds: gm,auditor
|
||||
- 固定空间：节点与通路固定；若只需记录“已发现/封锁”，使用 record，不因探索重新生成建筑结构。
|
||||
- 关系网络：人物节点固定或可扩展，关系边可记录类型、强度与公开状态；关系变化必须由正文中的已成立事实触发。
|
||||
- 升级树：阶段和前置连接固定时用 static；若允许游玩中发现新分支才用 expand，并写清新增分支必须满足的前置关系。
|
||||
- 社会阶梯：节点 t0 到 t5。t0 写「冠号大宗师里的顶尖，不动用核武器无法威胁」；t5 写「普通人，暗面对他们是都市传说」。连接只连相邻档，字段写跨档要什么（个人武力、开宗立派、表世界权位）。`static`。实例只填「t2」。
|
||||
- 价目或兑换等级：一档一个节点，字段写强度范围和基价；连接写相邻档的价差。物品规则和变量只填档名与当前点数。
|
||||
- 不合适：把若干互不相连的人物简介装进节点；应改用生成规则，需要留下的单条再写具体实例。
|
||||
- 不合适：在本产物中指定 SVG 坐标、颜色和 Tab；展示应由正文组成决定。
|
||||
```
|
||||
|
||||
@@ -12,7 +12,7 @@ when: |
|
||||
某项状态若不持久保存，就会导致数值、阶段、资源、门控或已发生事实跨轮漂移时使用。
|
||||
when_not: |
|
||||
状态只需从最近正文理解、无需查询或门控 → 不使用。
|
||||
节点与连接构成的地图、关系或路径 → 拓扑图谱。
|
||||
节点与连接构成的地图、关系、路径，以及社会阶梯、价目、兑换等级的全表 → 拓扑图谱。本步只存当前点数或当前档位。
|
||||
大段设定或同类对象合同 → 舞台骨架 / 生成规则。
|
||||
boundary: |
|
||||
本能力定义什么是真值、什么事实允许它改变，以及改变后的约束。
|
||||
@@ -30,7 +30,9 @@ feeds: gm,auditor
|
||||
## task
|
||||
|
||||
```task
|
||||
为本局定义跨轮真值及其更新规则，写入 `设计.变量设计与更新规则`。先做必要性检验，再为每个真值写稳定 id、类型、初始化要求、公开性、允许写入者、允许操作、范围和基于事实的更新规则。
|
||||
为本局定义跨轮真值及其更新规则，写入 `设计.变量设计与更新规则`。先做必要性检验，再为每个真值写稳定 id、类型、初始化、公开性、允许写入者、允许操作、范围和基于事实的更新规则。
|
||||
|
||||
`初始化.默认值` 只放开局就要有、且具体实例里没有的那一条已发生事实：数字、枚举、布尔或空集合。人物是谁、关系、外貌和命门留在具体实例；变量要指向人时只存 id 或名字。
|
||||
|
||||
区分两类判断：
|
||||
- `deterministic`：程序能从明确指令、公式或工具结果直接计算。
|
||||
@@ -52,8 +54,9 @@ feeds: gm,auditor
|
||||
4. 类型决定操作：number/integer 可 `set|delta`；enum/string/boolean 可 `set`；set 可 `add|remove`。不用散文值绕过类型。
|
||||
5. 公开性只区分用户可见与隐藏；更细的主世界层、转述、旁观投影交给变量控制上下文。
|
||||
6. 阈值映射只保存引用和选取条件；长文内容仍在生成规则/具体实例中。
|
||||
7. 「维护复杂度」只写给旁观看的难点备注（交叉依赖、叙事推断证据），不决定开不开旁观；有真值即旁观填表。
|
||||
8. 不在正文中设计隐藏标签、正则或维护 JSON；主世界不承担隐藏填表通道。
|
||||
7. 默认值匹配类型，且短。人物档案、关系长文、外貌和命门不写进默认值；实例里已有的事实不在默认值再写一遍。
|
||||
8. 「维护复杂度」只写给旁观看的难点备注（交叉依赖、叙事推断证据），不决定开不开旁观；有真值即旁观填表。
|
||||
9. 不在正文中设计隐藏标签、正则或维护 JSON；主世界不承担隐藏填表通道。
|
||||
```
|
||||
|
||||
## probe
|
||||
@@ -79,7 +82,7 @@ feeds: gm,auditor
|
||||
"用途": "不保存它会造成什么跨轮错误",
|
||||
"类型": "number|integer|enum|string|boolean|set",
|
||||
"初始化": {
|
||||
"默认值": 0,
|
||||
"默认值": "数字、枚举、布尔或空集合；不写人物档案",
|
||||
"开场确定规则": "开场可覆盖默认值时写条件；否则写固定"
|
||||
},
|
||||
"公开性": "public|hidden",
|
||||
@@ -147,7 +150,7 @@ feeds: gm,auditor
|
||||
|
||||
硬规则：
|
||||
1. 输出合法 JSON；每个真值必须有稳定 `id`、用途、类型、初始化、权限、操作、约束和更新规则。
|
||||
2. 类型与允许操作必须相容；number/integer 的边界、enum 的枚举值必须明确；不适用的约束字段省略。
|
||||
2. 类型与允许操作必须相容；number/integer 的边界、enum 的枚举值必须明确；不适用的约束字段省略。`默认值` 与类型一致，且不是人物档案或关系长文。
|
||||
3. `narrative_inference` 必须写证据要求；正文没有该证据时不更新。
|
||||
4. 派生映射与触发规则可为空；存在时必须引用已声明变量，且派生结果不得成为第二个可写真值。
|
||||
5. `维护复杂度` 可选；有则写备注与依据给旁观，勿再写 `建议: inline_*` 指望关旁观。有真值时程序固定 `play_slots.auditor=true`。勿手写 `play_slots`。
|
||||
@@ -164,9 +167,9 @@ feeds: gm,auditor
|
||||
- 1：把人物感受、场景描述或大段设定全部变量化。
|
||||
|
||||
字段妥当性：
|
||||
- 5：类型、初值、操作和约束彼此一致，字段数量恰当且不重叠。
|
||||
- 5：类型、初值、操作和约束彼此一致，字段数量恰当且不重叠。默认值是短值，人物事实在具体实例。
|
||||
- 3：基本可用，但有边界、枚举或初始化要求不够明确。
|
||||
- 1：类型与操作冲突，或存在余额/存款一类重复真值。
|
||||
- 1：类型与操作冲突，存在余额/存款一类重复真值，或默认值是一段人物关系。
|
||||
|
||||
更新可执行性：
|
||||
- 5：每条规则都有已发生事实、判断方式、证据、操作、值规则和时机。
|
||||
@@ -188,7 +191,7 @@ feeds: gm,auditor
|
||||
|
||||
```checklist
|
||||
- [ ] 每个真值都通过“不保存会出错”的必要性检验？
|
||||
- [ ] 类型、初值、允许操作、约束和写入者互相一致？
|
||||
- [ ] 默认值是短值，没有把人物关系或实例里已有的事实再写一遍？
|
||||
- [ ] 每条更新规则都有事实证据和可执行的值规则？
|
||||
- [ ] 派生映射未被重复建成可写真值？
|
||||
- [ ] 维护复杂度若写了，是旁观备注而非开槽开关？
|
||||
@@ -198,8 +201,11 @@ feeds: gm,auditor
|
||||
## examples
|
||||
|
||||
```examples
|
||||
- 单个数值真值或关系矩阵：都写清更新规则；有真值即由旁观副 LLM 填表，主世界只写正文。
|
||||
- 单个数值真值或关系矩阵：都写清更新规则；有真值即由旁观副 LLM 填表，主世界只写正文。关系矩阵的默认值是空集合或少量 id，不是每人一段小传。
|
||||
- 多个真值需结合正文共同判断：在维护复杂度.备注里点出推断难点与证据，供旁观读。
|
||||
- 当前态度由好感区间映射得到：只保存好感，态度作为派生映射，不建立第二个可写“当前态度”。
|
||||
- 不合适：每轮重写一段“当前性格”长字符串，或只写“随剧情变化”而没有证据与操作。
|
||||
|
||||
偏了就改回：
|
||||
- 默认值写成十几个角色的关系、外貌或命门 → 档案留在具体实例，这里改成数字、枚举或 id 列表。
|
||||
- 每轮重写一段“当前性格”长字符串，或只写“随剧情变化”而没有证据与操作 → 改成有证据的 set/delta，或取消该真值。
|
||||
```
|
||||
|
||||
@@ -7,42 +7,48 @@ name: 舞台骨架
|
||||
id: world-blueprint
|
||||
artifact: 设计.舞台骨架
|
||||
declaration: >
|
||||
保存会在游玩中反复影响世界反馈的外部舞台：熟悉基底、必要变造、核心运转和主要活动场所。
|
||||
保存会反复影响世界反馈的外部舞台：熟悉基底、必要变造、核心运转和主要活动场所。
|
||||
推进时据此知道该推哪些地方，以及玩家行为在哪个尺度上产生回馈。
|
||||
when: |
|
||||
核心体验依赖外部环境、社会力量或世界状况持续作出一致反馈，而现有材料还不足以支撑这些反馈时使用。
|
||||
是否换区不是判断标准：跨越多地可以需要舞台骨架；一室之内的朝堂、审讯或家庭关系同样可以需要。
|
||||
when_not: |
|
||||
熟悉现实基底已经够用，地点和外部格局不会改变核心体验或世界反馈时不使用。 既成硬法则归实现机制；多份人物或要先审字段的名片归生成规则，单条字段很少的具名内容才归具体实例；重点在节点与连接本身时归拓扑图谱。
|
||||
熟悉现实基底已经够用，地点和外部格局不会改变核心体验或世界反馈时不使用。
|
||||
既成硬法则归世界法则；本步最多引用其台上结果。
|
||||
多份人物或要先审字段的名片归生成规则；单条字段很少的具名内容归具体实例。
|
||||
重点在节点与连接本身时归拓扑图谱。
|
||||
boundary: |
|
||||
本能力只交会上台并反复有用的外部事实，其余沿用熟悉常识或明确留白。
|
||||
不重写核心体验，不解释硬法则起源，不制作人物名片、完整地图、历史或百科。
|
||||
本步交四块会上台并反复有用的外部事实：熟悉基底、必要变造、核心运转、主要活动场所。
|
||||
在这四块上再写清推进落点与回馈尺度：该推哪些地方，玩家行为在哪一层产生回馈。
|
||||
熟悉常识默认继承；体验碰不到的范围写进留白。硬法则正文、人物名片、完整地图、历史与百科交给对应能力。
|
||||
feeds: gm
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
说说这局里会反复影响你的外部舞台：它以什么熟悉世界为基底，哪里不同，哪些场所、关系或世界状况会持续参与反馈。只写真正会上台的部分即可。
|
||||
说说这局里会反复影响你的外部舞台：以什么熟悉世界为基底，哪里不同，哪些运转和场所会持续参与反馈。再补一句：推进时该推哪些地方，你的行为会在哪一层尺度上回馈。
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
把用户材料整理为一份可供主世界层稳定反馈的舞台骨架，写入 `设计.舞台骨架`。先确定最短的熟悉基底与必要变造，再提取会反复影响玩家的社会关系、环境条件和主要场所；体验碰不到的范围明确留白。
|
||||
把材料整理为 `设计.舞台骨架`。先写最短的 `熟悉基底` 和回馈 `尺度`，再列会改变台上反馈的 `必要变造`，然后写 `核心运转` 和会反复上台的 `主要舞台`；碰不到的范围进 `留白边界`。
|
||||
|
||||
材料足够便直接成稿。若两种舞台尺度或运转条件会导致明显不同的世界反馈，把这一处缺口交给 `self_score.gap`；产物正文不放评分、诊断、追问或开放问题。
|
||||
四块写完后，核对推进能不能用：`主要舞台` 是该推的地方；`尺度`（或某一舞台自有的一层）是玩家行为产生回馈的层级。`核心运转` 写力量或状况怎样持续影响玩家；`玩家如何接触` 写这一处怎么进场、碰到什么、回馈落在哪。两处说同一句时，删舞台侧的因果复读，场所与回馈层留下。
|
||||
|
||||
材料够就成稿。两种尺度或运转会导致明显不同反馈、又无法从材料判定时，缺口进 `self_score.gap`。产物正文只含舞台 JSON，不含评分、诊断或追问。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 舞台以世界怎样回应玩家为准，不以是否换区、地图大小或题材类型为准。
|
||||
2. 尺度由核心体验会碰到的边界决定。同是“现代都市”基底：体验作为韩国顶级财阀，尺度升到地球级势力、国家与资本网络，主要舞台写到财团、宴会、听证层；体验普通大学生活，尺度是一座城或一所学校，主要舞台写到系馆与社团层。按体验正推，写“需要跨国资本压迫感 → 升到国家层”，不写“因为是校园文所以不要国际政治”。
|
||||
3. 熟悉常识默认继承，只写相对基底的必要变造，以及会反复参与体验的外部事实。
|
||||
4. 核心运转可以是社会力量、阶层关系、周期事件、资源条件、禁忌或日常秩序；只说明它如何作用于玩家和主要舞台。用户已点名的灾变、祭祀、异界出口等世界状况必须写进核心运转。
|
||||
5. 主要舞台可以是空间、机构、社会层或一间房；写到能稳定反馈为止：玩家在这里做什么、会碰到谁或什么、得到什么反馈，不只点名。
|
||||
6. 既成硬法则只引用其结果，规则本身交给实现机制；多份或要先审字段的具名人物交给生成规则，单条字段很少的具名内容才交给具体实例。多张名片共享的台上格局与世界状况写在本能力，生成规则只引用，不在规则里重抄。
|
||||
7. 用户未触及的地区、历史、物种、民俗和势力不补全，在留白边界中说明即可。类型（西幻、修仙、末日等）只作体裁与氛围参照，不是必选题单：不因题材自动塞入该类型常见的地理与势力；不为显得严谨补起源史、伪科学或神话谱系，除非它们本身会上台。
|
||||
1. 舞台以世界怎样回应玩家为准，不以换区数量、地图大小或题材类型为准。
|
||||
2. `尺度` 由体验会碰到的边界正推，也是行为回馈的层级。同是「现代都市」：财阀压迫收到国家与资本网；大学生活收到一座城或一所学校。某一舞台的回馈层与全局不同时，写在该舞台上。
|
||||
3. 熟悉常识默认继承。`必要变造` 只列相对基底、且会改变世界反馈的差异（一句一条）。差异本质是因果法则时，法则进世界法则；本步写台上看得见的结果。
|
||||
4. `核心运转` 是社会力量、阶层关系、周期事件、资源、禁忌、日常秩序，以及用户点名的灾变、祭祀、异界出口。写它怎样持续影响玩家和主要舞台。
|
||||
5. `主要舞台` 是会反复上台的空间、机构、社会层或一间房，也是推进时要推的地方。写玩家在这里做什么、会碰到谁或什么、回馈落在哪一层，写到能稳定反馈为止。玩法标签不代替场所。
|
||||
6. 硬法则只引用台上结果；多张名片共享的台上格局写在本步，生成规则只引用。用户未触及的地区、历史、势力不补全，进留白。类型名只作氛围参照，不自动塞该类型常见地理与谱系。
|
||||
```
|
||||
|
||||
## output
|
||||
@@ -51,13 +57,13 @@ feeds: gm
|
||||
{
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "舞台骨架",
|
||||
"brief": "一句话说明什么外部舞台在支撑核心体验",
|
||||
"brief": "一句话：什么外部舞台在支撑反馈，推进该推哪，回馈落在哪一层",
|
||||
"mount": ["world-simulator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"舞台基底": {
|
||||
"熟悉基底": "现实或常见类型中可直接继承的最短描述",
|
||||
"尺度": "体验会碰到的边界，如国家与资本网络、一座城、一所学校、一间殿；熟悉基底已说明时省略",
|
||||
"尺度": "体验边界，也是行为回馈的层级；与熟悉基底同一句时可并入基底",
|
||||
"必要变造": ["只列会改变世界反馈的差异；无则省略"]
|
||||
},
|
||||
"核心运转": [
|
||||
@@ -70,8 +76,8 @@ feeds: gm
|
||||
"主要舞台": [
|
||||
{
|
||||
"名称": "会反复上台的空间、机构或社会层",
|
||||
"玩家如何接触": "玩家在这里做什么、会碰到谁或什么、受到什么反馈；写到能稳定反馈的具体程度，不只点名",
|
||||
"关键运转": ["仅引用与此处直接相关的核心运转"]
|
||||
"玩家如何接触": "在这里做什么、碰到谁或什么、回馈落在哪一层",
|
||||
"关键运转": ["仅引用与此处直接相关的核心运转名称"]
|
||||
}
|
||||
],
|
||||
"留白边界": ["本局不会上台、只继承常识或刻意不展开的范围"]
|
||||
@@ -80,48 +86,52 @@ feeds: gm
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. 输出合法 JSON；未知或无内容的可选字段直接省略，不写“未定”占位。
|
||||
2. `核心运转` 统一容纳必要的社会结构与世界状况，不为分类而补内容。
|
||||
3. `主要舞台` 只写会反复上台且需要稳定反馈的部分；单一房间也可成为完整舞台。
|
||||
4. 不在产物正文写自评、追问、开放问题、覆盖检验或设定诊断。
|
||||
5. `mount` 固定为 `["world-simulator"]`。
|
||||
1. 合法 JSON；无内容的可选字段整项省略；`mount` 固定 `["world-simulator"]`。
|
||||
2. 四块都写：熟悉基底、必要变造（无则省略该项）、核心运转、主要舞台。`主要舞台` 是推进落点，不因与运转相关就删掉。
|
||||
3. `玩家如何接触` 不复述对应运转的 `如何作用`；复读删因果句，场所与回馈层留下。`关键运转` 只写名称。
|
||||
4. `必要变造` 不写法则全文、价目或检定。正文不含评分、诊断、追问、百科或人物名片。
|
||||
|
||||
## score
|
||||
|
||||
```score
|
||||
支撑度：
|
||||
- 5：核心体验依赖的舞台、关系和运转条件均足以支持稳定世界反馈。
|
||||
- 3：方向正确，但缺少一项会反复影响体验的环境或社会条件，或其作用尚不明确。
|
||||
- 1：只有题材或地点标签，无法据此判断世界如何回应玩家。
|
||||
- 5：熟悉基底、变造、运转和主要场所足以稳定反馈；并能指出该推哪些地方、行为在哪一层回馈。
|
||||
- 3：四块方向对，但缺一项会反复影响体验的条件，或回馈层不清。
|
||||
- 1：只有题材或地点标签，世界如何回应、推进该推哪都无从判断。
|
||||
|
||||
克制度：
|
||||
- 5：只写会上台且反复有用的内容，熟悉常识默认继承，其余明确留白。
|
||||
- 3：夹带少量暂时不会影响游玩的地图、历史或设定。
|
||||
- 1：写成完整世界百科，或因题材自动塞满该类型常见地理与势力，核心舞台反而不突出。
|
||||
- 5：只写会上台且反复有用的内容；常识继承；其余留白；运转与舞台无同义复读。
|
||||
- 3：夹带少量暂不影响游玩的设定，或有一处舞台在复读运转。
|
||||
- 1：写成世界百科，或把变造、舞台写成硬法则与玩法标签。
|
||||
```
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 舞台内容足以让主世界层稳定回应玩家？
|
||||
- [ ] 判断依据是外部反馈，而不是换区数量或地图大小？
|
||||
- [ ] 核心运转只含会反复作用的关系与状况？
|
||||
- [ ] 主要舞台详细度够用即止，未触及范围已留白？
|
||||
- [ ] 未重写体验、硬法则、人物名片、完整历史或百科？
|
||||
- [ ] 尺度由体验正推？多张名片共享的格局已写在本步？
|
||||
- [ ] 产物正文不含评分、诊断、追问和开放问题？
|
||||
- [ ] 熟悉基底、必要变造、核心运转、主要舞台四块都在（无变造则该项省略）？
|
||||
- [ ] 推进时能从主要舞台选出该推的地方？
|
||||
- [ ] 行为回馈的尺度已写明？
|
||||
- [ ] 舞台未把运转因果换壳重写，也未写成玩法标签？
|
||||
- [ ] 未触及范围已留白；共享格局写在本步；硬法则未展开？
|
||||
- [ ] 正文无评分、诊断、追问？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：
|
||||
- 体验普通大学生活：熟悉基底为现代都市，尺度是一所学校；主要舞台写到系馆、宿舍、社团，各写玩家在那里做什么、受到什么反馈；国家政治列入留白边界。
|
||||
- 核心运转写世界状况：“每年寒灾”“南极通往怪物世界的出口”“村中活人祭祀”各写如何作用，如寒灾按年逼近、决定储粮与迁徙的代价；祭祀每年要交出活人，决定村里谁有话语权。
|
||||
- 一室朝堂：主要舞台只有一座殿，核心运转是皇权、派系与言官的相互牵制，如何作用写清每次奏对会被谁记账、牵动哪一方。
|
||||
- 普通大学生活：熟悉基底是现代都市，尺度是一所学校（冲突回馈落在系馆与宿舍，不落到国家）。必要变造若无则省略。主要舞台写系馆、宿舍、社团：玩家在那里做什么、碰到谁、回馈落在校园这一层。国家政治进留白。
|
||||
- 财阀压迫：同一都市基底，尺度升到国家与资本网。核心运转写资本与名声怎样持续施压；主要舞台写财团、宴会、听证，并写明一次出手的回馈落在资本与名声层。
|
||||
- 一室朝堂：主要舞台只有一座殿。核心运转写皇权与派系怎样在奏对里记账；接触栏写入殿后对面是谁、当场回馈是被谁记账。
|
||||
- 必要变造短写：「市井当古武是传言，权贵圈才兑现」；刺杀阈值等因果进世界法则。
|
||||
|
||||
坏：
|
||||
- 只写山脉河流，不写用户已点名的祭祀、灾变、异界出口：世界怎样回应玩家仍无从判断。
|
||||
- “地点1：XX咖啡馆，店主叫…”：这是具体实例的活；本能力只写这类场所在舞台上怎样作用于玩家。
|
||||
- 把多张名片共享的台上格局丢给生成规则写“共通前提”：格局写在本能力，生成规则只引用。
|
||||
缺料时：
|
||||
- 两种尺度都会改反馈且材料未钉 → `self_score.gap`。
|
||||
- 只有咖啡馆店主姓名、无台上作用 → 留给具体实例，不写进本步。
|
||||
|
||||
偏了就改回：
|
||||
- 用「该推哪里、回馈哪一层」替换掉基底、变造、运转、场所 → 四块补回，落点与尺度写在尺度和主要舞台上。
|
||||
- 接触栏只是把「如何作用」换壳 → 删复读，留下进场、在场对象和这一处的回馈层。
|
||||
- 必要变造写成核威慑长因果 → 因果进机制，变造改成台上可见的圈层差异。
|
||||
- 接触栏写成「正义堕落、战败调教」→ 改成该场所谁进出、玩家以何身份入场、回馈落在哪一层。
|
||||
```
|
||||
|
||||
@@ -16,7 +16,9 @@ when_not: |
|
||||
boundary: |
|
||||
0层回复呈现决定槽位内容和更新语义；本能力决定固定外壳、位置、渲染与更新应用。
|
||||
权威状态由程序投影；本能力只消费数据，不让正文模型重复生成。
|
||||
feeds: gm,narrator
|
||||
创作时一次写好 frontend 并由程序持有；游玩不把 html/css/js 塞进模型上下文。
|
||||
程序按数据契约要求模型只交槽位更新结构化内容，再灌进已固定的壳。
|
||||
feeds: program
|
||||
```
|
||||
|
||||
## opening
|
||||
@@ -73,7 +75,7 @@ HTML、CSS、JS 合计不超过 60 KB。材料足够便直接成稿；会改变
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "0层正文组成",
|
||||
"brief": "一句话说明持久卡的主工作面、辅助导航与更新方式",
|
||||
"mount": ["world-simulator", "narrator"],
|
||||
"mount": [],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"参考壳": [
|
||||
@@ -162,7 +164,7 @@ HTML、CSS、JS 合计不超过 60 KB。材料足够便直接成稿；会改变
|
||||
7. topology 读取结构化节点与连接绘制 SVG，并提供列表降级。
|
||||
8. 预览是非正史验收数据，不写成开场。
|
||||
9. 产物正文不含自评、追问或开放问题。
|
||||
10. `mount` 固定为 `["world-simulator", "narrator"]`。
|
||||
10. `mount` 固定为 `[]`：壳不进游玩投影；程序持有 frontend，只向模型注入数据契约。
|
||||
|
||||
## score
|
||||
|
||||
|
||||
@@ -90,7 +90,7 @@ feeds: gm,narrator
|
||||
},
|
||||
"来源": {
|
||||
"方式": "model_generated",
|
||||
"ref": "设计.故事推进"
|
||||
"ref": "设计.故事推进与交互范式"
|
||||
},
|
||||
"内容要求": [
|
||||
"遵守故事推进与叙事指南",
|
||||
|
||||
@@ -11,7 +11,7 @@ core: >-
|
||||
世界舞台与状态机仅在体验真需要时才引入，默认不做世界模拟全套。
|
||||
|
||||
process:
|
||||
- 开始通常先做「美学纲领与交互范式」。
|
||||
- 开始通常先做「美学纲领」。
|
||||
- 对照【能力 · 可选工序】的「何时用 / 何时不用」选型；调用条件以技能 meta 为准。
|
||||
- 收成时由程序根据已确认需求整理「游玩执行方式」，再用「运行配置组装」生成可执行规格并 closed。
|
||||
- 舞台、机制、变量、监控栏等：仅当对应技能「何时用」成立时再选，勿套世界模拟全套。
|
||||
@@ -27,6 +27,6 @@ principles:
|
||||
brief: 扩写/写手类：先定站位与轮转，再落到大纲→分段写文规格
|
||||
|
||||
steps:
|
||||
- id: 美学纲领与交互范式
|
||||
name: 美学纲领与交互范式
|
||||
- id: 美学纲领
|
||||
name: 美学纲领
|
||||
depends_on: []
|
||||
|
||||
@@ -12,7 +12,7 @@ core: >-
|
||||
再由「运行配置组装」生成可执行规格。执行单元只用固定槽（主世界层必开 / 叙事转述默认关 / 可选角色视角；旁观按变量需要），不为表/百科再拆槽，不开机遇裁定槽。
|
||||
|
||||
process:
|
||||
- 开始通常先做「美学纲领与交互范式」。
|
||||
- 开始通常先做「美学纲领」。
|
||||
- 读美学卡上用户会在意的部分，对照【能力 · 可选工序】的何时用 / 何时不用，把兑现那些承诺所需的节点写进 steps（需要几步排几步）。各技能调用条件以 meta 为准，本表不重复。
|
||||
- 世界模拟默认槽：仅主世界层（转述关、旁观关、视角关）。「游玩执行方式」由程序从独立文风层、变量维护和秘密隔离需求中整理。
|
||||
- 中段按承诺写上下文；每块只标挂谁（mount）与稳/变，具体顺序留给自动「上下文排序」。挂载归属：世界/机制/生成/叙事指南 → 主世界层（无转述时叙事也挂主世界层）；开了转述则叙事指南可挂转述；美学进常驻。
|
||||
@@ -29,12 +29,12 @@ principles:
|
||||
- 真值 / Data / Progressive 三分；派生性格与章细纲不落可写真值。
|
||||
- 有编排参数的步骤：进执行前钉齐 params（askUser 选项+其它）；缺参时先问再进 design-step。
|
||||
- 〔可反复〕可再追加（彻底新建）；已验收 id 留在 steps。
|
||||
- 舞台骨架通常都排（备案，只分详细度）；代入后几乎不移动、只在一处待着则不排。实现机制对照其 meta。
|
||||
- 舞台骨架通常都排（备案，只分详细度）；代入后几乎不移动、只在一处待着则不排。世界法则对照其 meta。
|
||||
- 百科与查表归主世界层；可见正文默认由主世界层直接写；显式开转述时转述在主世界正文上改写/镶壳。
|
||||
|
||||
brief: 回合推演：美学卡上在意的部分→挂槽写上下文→晚排序投影→收成运行规格
|
||||
|
||||
steps:
|
||||
- id: 美学纲领与交互范式
|
||||
name: 美学纲领与交互范式
|
||||
- id: 美学纲领
|
||||
name: 美学纲领
|
||||
depends_on: []
|
||||
|
||||
@@ -11,6 +11,7 @@ suggested_context:
|
||||
- 设计.变量设计与更新规则
|
||||
- 设计.生成规则
|
||||
- 设计.变量控制上下文
|
||||
- 设计.画面与生图
|
||||
dynamic:
|
||||
- 输出.用户展示
|
||||
- 用户.最新输入
|
||||
@@ -34,3 +35,4 @@ prompt_excerpt: |
|
||||
need_generate 仅在确需按某条 rule_id 补实例时写成 { "rule_id", "reason" }。
|
||||
程序只会抽该规则里的元素池；方向池由主世界层按规则自创，不要指望抽签出标签。
|
||||
禁止编造长对话续写；禁止输出用户可见正文；禁止修改未点名的无关字段。
|
||||
上下文里若有「设计.画面与生图」，填表时不使用它；table_ops 只按变量合同。画面提示词不写进 notes。
|
||||
|
||||
@@ -10,6 +10,7 @@ suggested_context:
|
||||
- 设计.叙事指南与故事推进
|
||||
- 设计.叙事指南
|
||||
- 设计.故事推进
|
||||
- 设计.故事推进与交互范式
|
||||
- 设计.正文组成
|
||||
- 设计.监控栏
|
||||
dynamic:
|
||||
@@ -41,7 +42,7 @@ prompt_excerpt: |
|
||||
monitor 用短键值（芯片），勿写长文。只填该壳已有区域。
|
||||
用户主读正文（body）默认 1000～2000 字（汉字）；以「设计.监控栏」回复呈现已钉字数为准。
|
||||
采用完整长自然段叙述，不要单句成段；不要几句短信就结束。
|
||||
用户输入用法以「设计.故事推进」或「设计.叙事指南与故事推进」为准：
|
||||
用户输入用法以「设计.故事推进与交互范式」（旧档「设计.故事推进」）或「设计.叙事指南与故事推进」为准：
|
||||
- 大纲扩写：把主世界正文当事实底稿写终稿。底稿里节拍之间的具体动作原样保留；文风只改遣词与节奏，不要把这些动作收成形容词。不另补底稿没有的动作，不改底稿已有的人、事、话、结果。续写短；用户角色实操仅保留底稿已有，续写不加代控。
|
||||
- 续写：仅当故事推进（或合并技能）明确钉了此用法时——终稿停在其他角色等用户角色回应之刻；不可写用户角色未给出的其它行为/对话。
|
||||
- 自动写入：续写宜长；可按主角设定保留/补全用户角色言行（与底稿、人设一致）。
|
||||
|
||||
@@ -13,6 +13,7 @@ suggested_context:
|
||||
- 设计.叙事指南与故事推进
|
||||
- 设计.叙事指南
|
||||
- 设计.故事推进
|
||||
- 设计.故事推进与交互范式
|
||||
- 设计.正文组成
|
||||
- 设计.监控栏
|
||||
dynamic:
|
||||
@@ -30,7 +31,7 @@ prompt_excerpt: |
|
||||
无独立转述时：你写的正文就是用户终稿。
|
||||
若本局启用了叙事转述：你仍写完整（或尽量完整）的场面正文；文风润色、残稿补全、前端壳由转述处理。不要改成「只交事实包」。
|
||||
真值/表字段变更不靠你交结构化包：有旁观维护时由副 LLM 根据本轮正文改表；若正文组成钉了隐藏段维护语句，可按约定写短键值，否则不要为维护打断叙述。
|
||||
用户输入用法以「设计.故事推进」或「设计.叙事指南与故事推进」为准：
|
||||
用户输入用法以「设计.故事推进与交互范式」（旧档「设计.故事推进」）或「设计.叙事指南与故事推进」为准：
|
||||
- 钉了「大纲扩写」：本轮输入是待演成场面的大纲，不是终稿句子。已写明的人、事、话、结果保持不变，每个节拍都要演到。节拍之间补具体动作、物件和当场的小纠正，把场合里已有的处境演出来；大纲没写这些动作也要写。例：「我去相亲、坐了下来」——坐下前可以写先跟服务员要一杯咖啡，话出口又急忙改成两杯，用来显出局促；后面她提出的要求和拒绝的结果不动。只加形容词、比喻或气氛、不增加动作，不算拓写。另起大纲没有的冲突、新目标，或改掉已定结果，才算出界。设计文若写「不发明未涉及的剧情」，指的是这一种出界，不是禁止节拍之间的具体动作。续写段宜短且不可代写用户角色行动/说话；演绎后停在抉择点（配方另钉一次收束则从其配方）。
|
||||
- 钉了「续写」：拓写跟用户已声明行为/对话；续写可推进场面但用户角色仅被动占位；禁止替用户角色做决定；停在需用户回应之刻。
|
||||
- 钉了「自动写入」：短需求驱动；续写宜长；可按主角设定代写用户角色言行。
|
||||
|
||||
@@ -13,7 +13,8 @@ inputTags:
|
||||
- "用户.最新输入"
|
||||
- "用户.worker答复"
|
||||
- "用户.修订说明"
|
||||
- "设计.美学纲领与交互范式"
|
||||
- "设计.美学纲领"
|
||||
- "设计.美学纲领"
|
||||
- "设计.创作流程"
|
||||
- "创作.选用配方"
|
||||
- "创作.已验收单位"
|
||||
@@ -23,7 +24,7 @@ inputMerge: latest
|
||||
contextSegments:
|
||||
- id: opening-aesthetics
|
||||
tier: static
|
||||
tags: ["设计.美学纲领与交互范式"]
|
||||
tags: ["设计.美学纲领", "设计.美学纲领"]
|
||||
label: "## 【开头节点 · 美学纲领】用户会在意这张卡的哪几处？用那些承诺选节点（无则先排本步）"
|
||||
- id: accepted-units
|
||||
tier: static
|
||||
@@ -65,7 +66,7 @@ contextSegments:
|
||||
|
||||
题材名（丧尸、都市、宫廷）本身不决定套件。用户会反复感到的那几处才决定。
|
||||
|
||||
无美学卡：体验尚未钉清，先排「美学纲领与交互范式」；其余只排此刻能从【用户要求】看出用户在意什么。美学已验收之后，按这些承诺把该排的节点写进 `steps`——需要几步排几步。
|
||||
无美学卡：体验尚未钉清，先排「美学纲领」；其余只排此刻能从【用户要求】看出用户在意什么。美学已验收之后，按这些承诺把该排的节点写进 `steps`——需要几步排几步。
|
||||
|
||||
选定节点时对照【能力 · 可选工序】的何时用 / 何时不用 / 边界：这份承诺该由哪个技能兑现。配方 `core` / `process` / `principles` 给方法顺序（默认槽、收成链），不代替「用户在意什么」。含糊或可跳过则不排。已在草案里的 `name` 保留，一次性技能不写第二份。能力池里兑不了那处承诺：不发明新 `name`，askUser 问用户改体验还是放弃那一处。
|
||||
|
||||
@@ -107,23 +108,23 @@ askUser 只问排布（补哪个原型、改依赖）。用户谈到体验正文
|
||||
}
|
||||
],
|
||||
"steps": [
|
||||
{ "id": "美学纲领与交互范式", "name": "美学纲领与交互范式", "depends_on": [] },
|
||||
{ "id": "美学纲领", "name": "美学纲领", "depends_on": [] },
|
||||
{
|
||||
"id": "生成规则",
|
||||
"name": "生成规则",
|
||||
"role": "prototype",
|
||||
"suggestion": "异能觉醒与升级合同",
|
||||
"depends_on": ["美学纲领与交互范式"]
|
||||
"depends_on": ["美学纲领"]
|
||||
},
|
||||
{
|
||||
"id": "变量设计与更新规则",
|
||||
"name": "变量设计与更新规则",
|
||||
"depends_on": ["美学纲领与交互范式"]
|
||||
"depends_on": ["美学纲领"]
|
||||
},
|
||||
{
|
||||
"id": "叙事指南与故事推进",
|
||||
"name": "叙事指南与故事推进",
|
||||
"depends_on": ["美学纲领与交互范式"]
|
||||
"depends_on": ["美学纲领"]
|
||||
},
|
||||
{
|
||||
"id": "细化终稿",
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
/**
|
||||
* 工作流库 → 创作提示里的短目录。不含 ComfyUI 节点图。
|
||||
*/
|
||||
|
||||
import { listImageWorkflows, type ImageWorkflowEntry } from "./store.js";
|
||||
|
||||
export function formatImageWorkflowCatalogForPrompt(
|
||||
entries?: ImageWorkflowEntry[],
|
||||
): string {
|
||||
const workflows = entries ?? listImageWorkflows();
|
||||
if (!workflows.length) return "";
|
||||
|
||||
const lines = workflows.map(
|
||||
(entry) => `- ${entry.id}｜${entry.name}｜${entry.summary}`,
|
||||
);
|
||||
|
||||
return `## 【工作流库 · 可选用】
|
||||
|
||||
本机已导出的画面工作流。选定一个 id 写入本步产物。这里只有短名和一句画面说明。
|
||||
|
||||
${lines.join("\n")}`;
|
||||
}
|
||||
@@ -0,0 +1,7 @@
|
||||
export {
|
||||
getImageWorkflow,
|
||||
getImageWorkflowsDir,
|
||||
listImageWorkflows,
|
||||
type ImageWorkflowEntry,
|
||||
} from "./store.js";
|
||||
export { formatImageWorkflowCatalogForPrompt } from "./catalog.js";
|
||||
@@ -0,0 +1,102 @@
|
||||
/**
|
||||
* 本机 ComfyUI 工作流库。
|
||||
* 目录：{用户数据}/image-workflows/<id>/
|
||||
* meta.json 短名、一句画面说明、提示词节点
|
||||
* workflow.json ComfyUI「API 格式」导出的节点图
|
||||
* 创作模型只看短目录；节点图留在磁盘，提交生图时才读。
|
||||
*/
|
||||
|
||||
import { existsSync, readdirSync, readFileSync, statSync } from "node:fs";
|
||||
import path from "node:path";
|
||||
import { getUserDataDir } from "../config/user-data-dir.js";
|
||||
|
||||
export type ImageWorkflowEntry = {
|
||||
id: string;
|
||||
name: string;
|
||||
/** 给创作模型看的一句画面说明 */
|
||||
summary: string;
|
||||
/** ComfyUI API JSON 里的节点 id */
|
||||
promptNode: string;
|
||||
/** 该节点上要覆盖的字段，CLIP 文本一般为 text */
|
||||
promptField: string;
|
||||
/** 可选：这种风格的提示词习惯，仍不是节点图 */
|
||||
promptNotes?: string;
|
||||
};
|
||||
|
||||
const DIR_NAME = "image-workflows";
|
||||
|
||||
export function getImageWorkflowsDir(): string {
|
||||
return path.join(getUserDataDir(), DIR_NAME);
|
||||
}
|
||||
|
||||
function asString(v: unknown): string | undefined {
|
||||
if (typeof v !== "string") return undefined;
|
||||
const t = v.trim();
|
||||
return t || undefined;
|
||||
}
|
||||
|
||||
function readJson(file: string): unknown | null {
|
||||
try {
|
||||
return JSON.parse(readFileSync(file, "utf8")) as unknown;
|
||||
} catch {
|
||||
return null;
|
||||
}
|
||||
}
|
||||
|
||||
function parseEntry(folderName: string, dir: string): ImageWorkflowEntry | null {
|
||||
const metaPath = path.join(dir, "meta.json");
|
||||
const workflowPath = path.join(dir, "workflow.json");
|
||||
if (!existsSync(metaPath) || !existsSync(workflowPath)) return null;
|
||||
const meta = readJson(metaPath);
|
||||
const workflow = readJson(workflowPath);
|
||||
if (!meta || typeof meta !== "object" || Array.isArray(meta)) return null;
|
||||
if (!workflow || typeof workflow !== "object" || Array.isArray(workflow)) return null;
|
||||
const row = meta as Record<string, unknown>;
|
||||
const id = asString(row.id) ?? folderName.trim();
|
||||
const name = asString(row.name);
|
||||
const summary = asString(row.summary);
|
||||
const promptNode = asString(row.prompt_node) ?? asString(row.promptNode);
|
||||
const promptField = asString(row.prompt_field) ?? asString(row.promptField);
|
||||
if (!id || !name || !summary || !promptNode || !promptField) return null;
|
||||
const promptNotes = asString(row.prompt_notes) ?? asString(row.promptNotes);
|
||||
return {
|
||||
id,
|
||||
name,
|
||||
summary,
|
||||
promptNode,
|
||||
promptField,
|
||||
...(promptNotes ? { promptNotes } : {}),
|
||||
};
|
||||
}
|
||||
|
||||
/** 扫描目录。缺文件或字段不全的文件夹跳过。 */
|
||||
export function listImageWorkflows(): ImageWorkflowEntry[] {
|
||||
const root = getImageWorkflowsDir();
|
||||
if (!existsSync(root)) return [];
|
||||
const out: ImageWorkflowEntry[] = [];
|
||||
let names: string[] = [];
|
||||
try {
|
||||
names = readdirSync(root);
|
||||
} catch {
|
||||
return [];
|
||||
}
|
||||
for (const name of names) {
|
||||
if (!name || name.startsWith(".")) continue;
|
||||
const dir = path.join(root, name);
|
||||
try {
|
||||
if (!statSync(dir).isDirectory()) continue;
|
||||
} catch {
|
||||
continue;
|
||||
}
|
||||
const entry = parseEntry(name, dir);
|
||||
if (entry) out.push(entry);
|
||||
}
|
||||
out.sort((a, b) => a.name.localeCompare(b.name, "zh"));
|
||||
return out;
|
||||
}
|
||||
|
||||
export function getImageWorkflow(id: string): ImageWorkflowEntry | null {
|
||||
const key = id.trim();
|
||||
if (!key) return null;
|
||||
return listImageWorkflows().find((entry) => entry.id === key) ?? null;
|
||||
}
|
||||
@@ -3,6 +3,7 @@
|
||||
* 新库：实现 formatForPrompt，在本文件 register。
|
||||
*/
|
||||
|
||||
import { formatImageWorkflowCatalogForPrompt } from "../image-workflow/catalog.js";
|
||||
import { formatPreferenceCatalogForPrompt } from "../preference/catalog.js";
|
||||
import { formatStylePackCatalogForPrompt } from "../style-pack/catalog.js";
|
||||
|
||||
@@ -74,6 +75,12 @@ registerLibrary({
|
||||
formatForPrompt: formatPreferenceCatalogForPrompt,
|
||||
});
|
||||
|
||||
registerLibrary({
|
||||
id: "image-workflows",
|
||||
label: "工作流库",
|
||||
formatForPrompt: formatImageWorkflowCatalogForPrompt,
|
||||
});
|
||||
|
||||
/**
|
||||
* 从模块列表收集绑定的库 id（去重、保序）。
|
||||
* 对话落盘：通常传入 intake≠recipe 的模块。
|
||||
|
||||
@@ -91,6 +91,8 @@ import {
|
||||
isInstanceStep,
|
||||
findStepByRef,
|
||||
findModuleByName,
|
||||
legacyTagsRetiredByWrite,
|
||||
readModuleArtifactContent,
|
||||
hasAcceptedCloserStep,
|
||||
parseCreationFlow,
|
||||
DESIGN_FLOW_WORKER_ID,
|
||||
@@ -1127,15 +1129,18 @@ export class PhaseRuntime {
|
||||
const other = findStepByRef(flow, item);
|
||||
return other?.name === step.name;
|
||||
}).length;
|
||||
const tag = findModuleByName(catalog, step.name)?.artifact?.trim();
|
||||
if (tag) {
|
||||
const stored = readModuleArtifactContent(
|
||||
findModuleByName(catalog, step.name),
|
||||
(tag) => this.blackboard.getContentByTag(tag),
|
||||
);
|
||||
if (stored?.content) {
|
||||
const pruned = pruneRepeatableArtifactContent({
|
||||
raw: this.blackboard.getContentByTag(tag) ?? "",
|
||||
raw: stored.content,
|
||||
step,
|
||||
remainingSameModule,
|
||||
});
|
||||
this.blackboard.write({
|
||||
tag,
|
||||
tag: stored.tag,
|
||||
content: pruned,
|
||||
source: "runtime",
|
||||
});
|
||||
@@ -1710,11 +1715,12 @@ export class PhaseRuntime {
|
||||
}
|
||||
|
||||
const pendingModule = findModuleByName(catalog, step.name);
|
||||
const storedArtifact = readModuleArtifactContent(pendingModule, (tag) =>
|
||||
this.blackboard.getContentByTag(tag),
|
||||
);
|
||||
if (reenter) {
|
||||
const artTag = pendingModule?.artifact?.trim();
|
||||
const hasArt = Boolean(
|
||||
artTag && this.blackboard.getContentByTag(artTag)?.trim(),
|
||||
);
|
||||
const artTag = storedArtifact?.tag;
|
||||
const hasArt = Boolean(storedArtifact?.content);
|
||||
if (
|
||||
!isStepAccepted(step, accepted) &&
|
||||
!hasArt &&
|
||||
@@ -1764,7 +1770,7 @@ export class PhaseRuntime {
|
||||
if (reenter) {
|
||||
const existing = this.ensureReenterArtifact(
|
||||
pinned.id,
|
||||
pendingModule?.artifact,
|
||||
storedArtifact?.tag ?? pendingModule?.artifact,
|
||||
);
|
||||
if (existing) {
|
||||
this.reopenArtifactForRevision(existing, pinned);
|
||||
@@ -2719,6 +2725,11 @@ export class PhaseRuntime {
|
||||
content: toWrite,
|
||||
source: workerId,
|
||||
});
|
||||
if (toWrite.trim()) {
|
||||
for (const oldTag of legacyTagsRetiredByWrite(tag)) {
|
||||
this.blackboard.deleteByTag(oldTag);
|
||||
}
|
||||
}
|
||||
if (
|
||||
inferLifecycleStage(this.session) === "play" &&
|
||||
(tag === "输出.用户展示" || tag === "输出.开场白")
|
||||
|
||||
@@ -36,11 +36,12 @@ const WORKER_LABELS: Record<string, string> = {
|
||||
};
|
||||
|
||||
const FIXED_TOPIC_LABELS: Record<string, string> = {
|
||||
"aesthetics-interaction": "美学纲领与交互范式",
|
||||
"aesthetics-interaction": "美学纲领",
|
||||
interaction: "交互范式",
|
||||
narrative_guide: "叙事指南与故事推进",
|
||||
"narrative-guide": "叙事指南",
|
||||
"story-progression": "故事推进",
|
||||
"image-prompt": "画面与生图",
|
||||
"story-progression": "故事推进与交互范式",
|
||||
input_protocol: "输入协议",
|
||||
core_premise: "核心前提",
|
||||
aesthetics: "美学纲领",
|
||||
@@ -58,6 +59,11 @@ const CREATION_MODE_LABELS: Record<string, string> = {
|
||||
listen_serial: "听书连载",
|
||||
};
|
||||
|
||||
/** 顶栏产品面（与作品对话并列） */
|
||||
const PRODUCT_SURFACE_LABELS: Record<string, string> = {
|
||||
"direct-chat": "直聊",
|
||||
};
|
||||
|
||||
const SKILL_PACK_LABELS: Record<string, string> = {
|
||||
"world-simulator": "回合推演",
|
||||
"expand-assistant": "扩写助手",
|
||||
@@ -74,6 +80,12 @@ export function displayStageLabel(id: string | undefined | null): string {
|
||||
return STAGE_LABELS[id] ?? id;
|
||||
}
|
||||
|
||||
/** 顶栏产品面展示名 */
|
||||
export function displayProductSurfaceLabel(id: string | undefined | null): string {
|
||||
if (!id) return "";
|
||||
return PRODUCT_SURFACE_LABELS[id] ?? id;
|
||||
}
|
||||
|
||||
/** 进料方式展示名（新建对话框 / 工作面 kicker） */
|
||||
export function displayCreationModeLabel(id: string | undefined | null): string {
|
||||
if (!id) return "";
|
||||
|
||||
@@ -496,6 +496,7 @@ const SYNTH_FALLBACK_CONTEXT: Record<
|
||||
"设计.变量设计与更新规则",
|
||||
"设计.生成规则",
|
||||
"设计.变量控制上下文",
|
||||
"设计.画面与生图",
|
||||
],
|
||||
dynamic: [
|
||||
"输出.用户展示",
|
||||
@@ -508,13 +509,14 @@ const SYNTH_FALLBACK_CONTEXT: Record<
|
||||
"world-simulator": {
|
||||
static: [
|
||||
"设计.舞台骨架",
|
||||
"设计.世界法则",
|
||||
"设计.实现机制",
|
||||
"设计.变量设计与更新规则",
|
||||
"设计.生成规则",
|
||||
"设计.叙事指南与故事推进",
|
||||
"设计.叙事指南",
|
||||
"设计.故事推进",
|
||||
"设计.正文组成",
|
||||
"设计.故事推进与交互范式",
|
||||
"设计.监控栏",
|
||||
],
|
||||
dynamic: [
|
||||
@@ -529,7 +531,7 @@ const SYNTH_FALLBACK_CONTEXT: Record<
|
||||
"设计.叙事指南与故事推进",
|
||||
"设计.叙事指南",
|
||||
"设计.故事推进",
|
||||
"设计.正文组成",
|
||||
"设计.故事推进与交互范式",
|
||||
"设计.监控栏",
|
||||
],
|
||||
dynamic: ["输出.用户展示"],
|
||||
|
||||
@@ -12,6 +12,7 @@ import {
|
||||
formatAcceptedUnitsForPrompt,
|
||||
} from "./creation-units.js";
|
||||
import { projectFragmentContent } from "./context-fragment.js";
|
||||
import { tagReadFallbacks } from "./creation-flow.js";
|
||||
import {
|
||||
buildHistoryFallback,
|
||||
isDialogueHistoryRef,
|
||||
@@ -79,6 +80,21 @@ function readTagContent(
|
||||
inputs: Record<string, string>,
|
||||
blackboard: Blackboard,
|
||||
inputMerge: BlackboardInputMerge,
|
||||
): string {
|
||||
const direct = readOneTag(tag, inputs, blackboard, inputMerge);
|
||||
if (direct) return direct;
|
||||
for (const alt of tagReadFallbacks(tag)) {
|
||||
const found = readOneTag(alt, inputs, blackboard, inputMerge);
|
||||
if (found) return found;
|
||||
}
|
||||
return "";
|
||||
}
|
||||
|
||||
function readOneTag(
|
||||
tag: string,
|
||||
inputs: Record<string, string>,
|
||||
blackboard: Blackboard,
|
||||
inputMerge: BlackboardInputMerge,
|
||||
): string {
|
||||
if (inputs[tag]?.trim()) return inputs[tag]!.trim();
|
||||
const items = blackboard.queryByPatterns([tag], inputMerge);
|
||||
|
||||
+101
-13
@@ -1309,16 +1309,95 @@ export function creationFlowFromRecipeSeed(
|
||||
};
|
||||
}
|
||||
|
||||
/**
|
||||
* 改名后，旧步骤名和旧产物 tag 仍对上同一能力。
|
||||
* 新写入用目录里的现名和现 tag；读取时两边都认。
|
||||
*/
|
||||
const MODULE_LEGACY: Record<
|
||||
string,
|
||||
{ names: string[]; artifacts: string[]; current: string }
|
||||
> = {
|
||||
mechanism: {
|
||||
names: ["实现机制"],
|
||||
artifacts: ["设计.实现机制"],
|
||||
current: "设计.世界法则",
|
||||
},
|
||||
};
|
||||
|
||||
/** 读上下文时，现用 tag 与旧 tag 互为兜底。 */
|
||||
export function tagReadFallbacks(tag: string): string[] {
|
||||
const t = tag.trim();
|
||||
for (const legacy of Object.values(MODULE_LEGACY)) {
|
||||
if (t === legacy.current) return [...legacy.artifacts];
|
||||
if (legacy.artifacts.includes(t)) return [legacy.current];
|
||||
}
|
||||
return [];
|
||||
}
|
||||
|
||||
/** 写成现用 tag 后，旧 tag 应清掉，避免两份法则同时进上下文。 */
|
||||
export function legacyTagsRetiredByWrite(tag: string): string[] {
|
||||
const t = tag.trim();
|
||||
for (const legacy of Object.values(MODULE_LEGACY)) {
|
||||
if (t === legacy.current) return [...legacy.artifacts];
|
||||
}
|
||||
return [];
|
||||
}
|
||||
|
||||
/** 现用产物 tag 在前，旧 tag 在后。 */
|
||||
export function moduleArtifactTags(
|
||||
mod: Pick<ModuleCatalogEntry, "id" | "artifact">,
|
||||
): string[] {
|
||||
const current = mod.artifact?.trim();
|
||||
const legacy = MODULE_LEGACY[mod.id]?.artifacts ?? [];
|
||||
return [...new Set([...(current ? [current] : []), ...legacy])];
|
||||
}
|
||||
|
||||
export function moduleOwnsArtifactTag(
|
||||
mod: Pick<ModuleCatalogEntry, "id" | "artifact">,
|
||||
tag: string,
|
||||
): boolean {
|
||||
const bare = tag.trim();
|
||||
if (!bare) return false;
|
||||
return moduleArtifactTags(mod).some(
|
||||
(artifact) => bare === artifact || bare.startsWith(`${artifact}#`),
|
||||
);
|
||||
}
|
||||
|
||||
function filledOwnsModule(
|
||||
filled: ReadonlySet<string>,
|
||||
mod: Pick<ModuleCatalogEntry, "id" | "artifact">,
|
||||
): boolean {
|
||||
return moduleArtifactTags(mod).some((tag) => filled.has(tag));
|
||||
}
|
||||
|
||||
/** 黑板里已有内容的那条 tag；都空时返回现用 tag。 */
|
||||
export function readModuleArtifactContent(
|
||||
mod: Pick<ModuleCatalogEntry, "id" | "artifact"> | null | undefined,
|
||||
read: (tag: string) => string | undefined,
|
||||
): { tag: string; content: string } | null {
|
||||
if (!mod) return null;
|
||||
const tags = moduleArtifactTags(mod);
|
||||
for (const tag of tags) {
|
||||
const content = read(tag)?.trim() || "";
|
||||
if (content) return { tag, content };
|
||||
}
|
||||
const current = tags[0];
|
||||
return current ? { tag: current, content: "" } : null;
|
||||
}
|
||||
|
||||
/** 无 id 时的兜底（目录仍应显式写 id） */
|
||||
function slugFromName(name: string): string {
|
||||
const map: Record<string, string> = {
|
||||
美学纲领与交互范式: "aesthetics-interaction",
|
||||
交互范式: "interaction",
|
||||
美学纲领: "aesthetics",
|
||||
美学纲领: "aesthetics-interaction",
|
||||
故事推进与交互范式: "story-progression",
|
||||
叙事指南: "narrative-guide",
|
||||
画面与生图: "image-prompt",
|
||||
叙事指南与故事推进: "narrative",
|
||||
故事推进: "story-progression",
|
||||
实现机制: "mechanism",
|
||||
世界法则: "mechanism",
|
||||
实现机制: "mechanism", // 旧称
|
||||
舞台骨架: "world-blueprint",
|
||||
世界蓝图与人文地理: "world-blueprint", // 旧称
|
||||
世界蓝图: "world-blueprint", // 旧简称
|
||||
@@ -1958,8 +2037,8 @@ export function formatFlowProgressForAgent(params: {
|
||||
for (const step of flow.steps) {
|
||||
if (isPrototypeStep(step)) continue;
|
||||
const acceptedHere = isStepAccepted(step, accepted);
|
||||
const art = catalog ? artifactTagForStep(step.name, catalog) : null;
|
||||
const hasArtifact = Boolean(art && filled.has(art));
|
||||
const modForArt = catalog ? findModuleByName(catalog, step.name) : null;
|
||||
const hasArtifact = Boolean(modForArt && filledOwnsModule(filled, modForArt));
|
||||
const repeatable = repeatableNames.has(step.name);
|
||||
if (acceptedHere || (!repeatable && hasArtifact)) {
|
||||
markDone(
|
||||
@@ -1981,7 +2060,7 @@ export function formatFlowProgressForAgent(params: {
|
||||
if (catalog) {
|
||||
for (const mod of catalogModulesForIntake(catalog, "recipe")) {
|
||||
if (mod.repeatable === true) continue;
|
||||
if (!mod.artifact || !filled.has(mod.artifact)) continue;
|
||||
if (!filledOwnsModule(filled, mod)) continue;
|
||||
if (doneNames.has(mod.name)) continue;
|
||||
markDone(mod.name, undefined, "产物已在黑板", false);
|
||||
}
|
||||
@@ -2032,7 +2111,7 @@ export function formatFlowProgressForAgent(params: {
|
||||
catalog && flow
|
||||
? flow.steps.filter((step) => {
|
||||
if (isPrototypeStep(step)) return false;
|
||||
const mod = catalog.modules.find((m) => m.name === step.name);
|
||||
const mod = findModuleByName(catalog, step.name);
|
||||
return Boolean(mod?.closer) && !isStepAccepted(step, accepted);
|
||||
})
|
||||
: [];
|
||||
@@ -2131,7 +2210,10 @@ export function validateCreationFlow(
|
||||
const seenIds = new Set<string>();
|
||||
const allowed = catalog
|
||||
? new Set(
|
||||
catalogModulesForIntake(catalog, "recipe").map((m) => m.name),
|
||||
catalogModulesForIntake(catalog, "recipe").flatMap((m) => [
|
||||
m.name,
|
||||
...(MODULE_LEGACY[m.id]?.names ?? []),
|
||||
]),
|
||||
)
|
||||
: null;
|
||||
const reportedFreshDup = new Set<string>();
|
||||
@@ -2147,7 +2229,7 @@ export function validateCreationFlow(
|
||||
errors.push(`「${step.name}」不在模块目录中`);
|
||||
}
|
||||
|
||||
const mod = catalog?.modules.find((m) => m.name === step.name);
|
||||
const mod = catalog ? findModuleByName(catalog, step.name) : null;
|
||||
if (isReviseStep(step)) {
|
||||
const ref = step.revises?.trim() ?? "";
|
||||
if (!ref) {
|
||||
@@ -2220,7 +2302,7 @@ export function validateStepReadyToRun(
|
||||
step: CreationFlowStep,
|
||||
catalog: ModuleCatalog | null,
|
||||
): CreationFlowValidation {
|
||||
const mod = catalog?.modules.find((m) => m.name === step.name);
|
||||
const mod = findModuleByName(catalog, step.name);
|
||||
if (!mod?.params?.length) return { ok: true, errors: [] };
|
||||
const missing = missingRequiredStepParams(step, mod);
|
||||
if (missing.length === 0) return { ok: true, errors: [] };
|
||||
@@ -2260,7 +2342,7 @@ export function artifactTagForStep(
|
||||
name: string,
|
||||
catalog: ModuleCatalog | null,
|
||||
): string | null {
|
||||
return catalog?.modules.find((m) => m.name === name)?.artifact ?? null;
|
||||
return findModuleByName(catalog, name)?.artifact ?? null;
|
||||
}
|
||||
|
||||
/**
|
||||
@@ -2458,7 +2540,7 @@ export function listCallableCatalogModules(params: {
|
||||
for (const mod of catalogModulesForIntake(catalog, "recipe")) {
|
||||
if (scheduled.has(mod.name)) continue;
|
||||
if (!mod.repeatable) {
|
||||
if (mod.artifact && filled.has(mod.artifact)) continue;
|
||||
if (filledOwnsModule(filled, mod)) continue;
|
||||
if (accepted.has(mod.name)) continue;
|
||||
}
|
||||
out.push({
|
||||
@@ -2566,7 +2648,7 @@ export function formatCreationFlowForUser(
|
||||
...(blockedBy?.length ? { blockedBy } : {}),
|
||||
runState,
|
||||
...(mod?.artifact ? { artifactTag: mod.artifact } : {}),
|
||||
...(mod?.artifact && filled.has(mod.artifact) ? { hasArtifact: true } : {}),
|
||||
...(mod && filledOwnsModule(filled, mod) ? { hasArtifact: true } : {}),
|
||||
...(!proto && s.params ? { params: s.params } : {}),
|
||||
...(paramsMissing.length > 0 ? { paramsMissing } : {}),
|
||||
};
|
||||
@@ -2579,7 +2661,13 @@ export function findModuleByName(
|
||||
name: string,
|
||||
): ModuleCatalogEntry | null {
|
||||
if (!catalog) return null;
|
||||
return catalog.modules.find((m) => m.name === name) ?? null;
|
||||
const exact = catalog.modules.find((m) => m.name === name);
|
||||
if (exact) return exact;
|
||||
const legacyId = Object.entries(MODULE_LEGACY).find(([, legacy]) =>
|
||||
legacy.names.includes(name),
|
||||
)?.[0];
|
||||
if (!legacyId) return null;
|
||||
return catalog.modules.find((m) => m.id === legacyId) ?? null;
|
||||
}
|
||||
|
||||
/** 已验收步骤名列表（JSON 数组或换行文本） */
|
||||
|
||||
@@ -240,7 +240,7 @@ const DEFAULT_WORKER_CONTRACTS: Record<
|
||||
"设计.叙事指南与故事推进",
|
||||
"设计.叙事指南",
|
||||
"设计.故事推进",
|
||||
"设计.正文组成",
|
||||
"设计.故事推进与交互范式",
|
||||
"设计.监控栏",
|
||||
],
|
||||
dynamic: [
|
||||
@@ -268,7 +268,7 @@ const DEFAULT_WORKER_CONTRACTS: Record<
|
||||
"设计.叙事指南与故事推进",
|
||||
"设计.叙事指南",
|
||||
"设计.故事推进",
|
||||
"设计.正文组成",
|
||||
"设计.故事推进与交互范式",
|
||||
"设计.监控栏",
|
||||
],
|
||||
dynamic: ["输出.用户展示", "用户.最新输入", "变量.当前"],
|
||||
|
||||
+55
-43
@@ -5,6 +5,7 @@ import { describe, expect, it } from "vitest";
|
||||
import {
|
||||
artifactTagForStep,
|
||||
extractModuleOpening,
|
||||
findModuleByName,
|
||||
formatCreationFlowForUser,
|
||||
deriveFlowStepTitle,
|
||||
titleFromSuggestion,
|
||||
@@ -444,11 +445,11 @@ describe("creation-flow", () => {
|
||||
it("loads world-simulator catalog and formats for agent", async () => {
|
||||
const catalog = await loadModuleCatalog("dialogue/world-simulator");
|
||||
expect(catalog?.modules.some((m) => m.name === "美学纲领与交互范式")).toBe(
|
||||
true,
|
||||
false,
|
||||
);
|
||||
expect(catalog?.modules.some((m) => m.name === "主角设定")).toBe(true);
|
||||
expect(catalog?.modules.some((m) => m.name === "交互范式")).toBe(false);
|
||||
expect(catalog?.modules.some((m) => m.name === "美学纲领")).toBe(false);
|
||||
expect(catalog?.modules.some((m) => m.name === "美学纲领")).toBe(true);
|
||||
expect(
|
||||
catalog?.modules.find((m) => m.name === "生成规则")?.repeatable,
|
||||
).toBe(true);
|
||||
@@ -476,7 +477,7 @@ describe("creation-flow", () => {
|
||||
expect(gen?.boundary).toBeTruthy();
|
||||
const block = formatModuleCatalogForAgent(catalog!);
|
||||
expect(block).toContain("【能力");
|
||||
expect(block).toContain("美学纲领与交互范式：");
|
||||
expect(block).toContain("美学纲领：");
|
||||
expect(block).toContain("生成规则〔可反复〕〔先验产物〕");
|
||||
expect(block).toContain("上下文排序〔程序步〕");
|
||||
expect(block).toContain("何时用");
|
||||
@@ -489,7 +490,7 @@ describe("creation-flow", () => {
|
||||
expect(block).not.toMatch(/^- 故事推进：/m);
|
||||
const dictateBlock = formatModuleCatalogForDictate(catalog!);
|
||||
expect(dictateBlock).toMatch(/^- 叙事指南：/m);
|
||||
expect(dictateBlock).toMatch(/^- 故事推进：/m);
|
||||
expect(dictateBlock).toMatch(/^- 故事推进与交互范式：/m);
|
||||
expect(dictateBlock).toContain("开场白与开场变量〔可反复〕〔收口〕");
|
||||
expect(dictateBlock).toContain("信息可见范围〔落档程序〕");
|
||||
expect(dictateBlock).not.toMatch(/^- 叙事指南与故事推进/m);
|
||||
@@ -499,12 +500,12 @@ describe("creation-flow", () => {
|
||||
expect(catalog?.modules.find((m) => m.name === "叙事指南")?.intake).toBe(
|
||||
"dictate",
|
||||
);
|
||||
expect(catalog?.modules.find((m) => m.name === "故事推进")?.intake).toBe(
|
||||
"dictate",
|
||||
);
|
||||
expect(catalog?.modules.find((m) => m.name === "故事推进")?.libraries).toEqual([
|
||||
"preferences",
|
||||
]);
|
||||
expect(
|
||||
catalog?.modules.find((m) => m.name === "故事推进与交互范式")?.intake,
|
||||
).toBe("dictate");
|
||||
expect(
|
||||
catalog?.modules.find((m) => m.name === "故事推进与交互范式")?.libraries,
|
||||
).toEqual(["preferences"]);
|
||||
expect(catalog?.modules.some((m) => m.id === "user-requirements")).toBe(false);
|
||||
expect(
|
||||
catalog?.modules.find((m) => m.name === "叙事指南")?.libraries,
|
||||
@@ -527,7 +528,7 @@ describe("creation-flow", () => {
|
||||
const leftover = listCallableCatalogModules({ catalog: catalog! });
|
||||
expect(leftover.some((m) => m.name === "叙事指南与故事推进")).toBe(true);
|
||||
expect(leftover.some((m) => m.name === "叙事指南")).toBe(false);
|
||||
expect(leftover.some((m) => m.name === "故事推进")).toBe(false);
|
||||
expect(leftover.some((m) => m.name === "故事推进与交互范式")).toBe(false);
|
||||
|
||||
const splitFlow = parseCreationFlow(`{
|
||||
"steps": [{ "name": "叙事指南", "depends_on": [] }]
|
||||
@@ -552,7 +553,7 @@ describe("creation-flow", () => {
|
||||
expect(ws?.process).toBeTruthy();
|
||||
expect(ws?.principles).toBeTruthy();
|
||||
expect(
|
||||
ws?.seed?.steps.some((s) => s.name === "美学纲领与交互范式"),
|
||||
ws?.seed?.steps.some((s) => s.name === "美学纲领"),
|
||||
).toBe(true);
|
||||
expect(ws?.seed?.status).toBe("open");
|
||||
const formatted = formatSelectedRecipeForAgent(ws!);
|
||||
@@ -724,7 +725,7 @@ recipes:
|
||||
expect(selected.promptBody).toContain("【用户已选配方 · 回合推演】");
|
||||
expect(selected.promptBody).toContain("回合推演");
|
||||
expect(selected.promptBody).toContain("【能力");
|
||||
expect(selected.promptBody).toContain("美学纲领与交互范式");
|
||||
expect(selected.promptBody).toContain("美学纲领：");
|
||||
expect(selected.promptBody).toContain("核心思路");
|
||||
expect(selected.promptBody).toContain("何时用");
|
||||
expect(selected.promptBody).toContain("开局 steps");
|
||||
@@ -827,7 +828,7 @@ modules:
|
||||
|
||||
it("injects aesthetics-interaction module prompt into design-step", async () => {
|
||||
const flowRaw = JSON.stringify({
|
||||
steps: [{ name: "美学纲领与交互范式", depends_on: [] }],
|
||||
steps: [{ name: "美学纲领", depends_on: [] }],
|
||||
});
|
||||
const loaded = await loadWorkerSkillWithContext(
|
||||
"world-simulator",
|
||||
@@ -835,14 +836,14 @@ modules:
|
||||
undefined,
|
||||
{
|
||||
flowRaw,
|
||||
currentStepName: "美学纲领与交互范式",
|
||||
currentStepName: "美学纲领",
|
||||
acceptedStepNames: [],
|
||||
},
|
||||
);
|
||||
expect(loaded.worker.outputTags).toContain("设计.美学纲领与交互范式");
|
||||
expect(loaded.worker.outputTags).toContain("设计.美学纲领");
|
||||
expect(loaded.worker.outputTags).not.toContain("创作.当前步骤");
|
||||
expect(loaded.worker.inputTags).toContain("创作.当前步骤");
|
||||
expect(loaded.promptBody).toContain("美学纲领与交互范式");
|
||||
expect(loaded.promptBody).toContain("【本步方法 · 美学纲领】");
|
||||
expect(loaded.promptBody).toContain("体验契约");
|
||||
expect(loaded.promptBody).toContain("程序开场");
|
||||
expect(loaded.promptBody).toContain("【本步参数】");
|
||||
@@ -890,9 +891,9 @@ modules:
|
||||
const binding = await resolveDesignStepBinding({
|
||||
skillPackRoot: "dialogue/world-simulator",
|
||||
flowRaw: JSON.stringify({
|
||||
steps: [{ name: "美学纲领与交互范式", depends_on: [] }],
|
||||
steps: [{ name: "美学纲领", depends_on: [] }],
|
||||
}),
|
||||
currentStepName: "美学纲领与交互范式",
|
||||
currentStepName: "美学纲领",
|
||||
});
|
||||
expect(binding?.opening).toContain("反复获得什么体验");
|
||||
expect(binding?.modulePrompt).toContain("```task");
|
||||
@@ -913,7 +914,7 @@ modules:
|
||||
"../src/skills/creation-flow.js"
|
||||
);
|
||||
const sections = parseModulePromptSections(prompt!);
|
||||
expect(sections.blocks.task).toContain("稳定反馈");
|
||||
expect(sections.blocks.task).toContain("回馈");
|
||||
expect(sections.blocks.output).toContain('"核心运转"');
|
||||
expect(sections.blocks.output).not.toContain('"自评"');
|
||||
expect(sections.blocks.output).not.toContain('"追问"');
|
||||
@@ -1018,7 +1019,7 @@ modules:
|
||||
"../src/skills/creation-flow.js"
|
||||
);
|
||||
const sections = parseModulePromptSections(prompt!);
|
||||
expect(sections.blocks.task).toContain("只选定一种");
|
||||
expect(sections.blocks.task).toContain("只选一种");
|
||||
expect(sections.blocks.task).toContain("read_library_entry");
|
||||
expect(sections.blocks.output).toContain('"用户输入用法"');
|
||||
expect(sections.blocks.output).toContain('"扩写要求"');
|
||||
@@ -1037,8 +1038,16 @@ modules:
|
||||
it("loads the migrated mechanism contract", async () => {
|
||||
const catalog = await loadModuleCatalog("dialogue/world-simulator");
|
||||
const module = catalog?.modules.find((item) => item.id === "mechanism");
|
||||
expect(module?.name).toBe("世界法则");
|
||||
expect(module?.artifact).toBe("设计.世界法则");
|
||||
expect(module?.layer).toBe("final");
|
||||
expect(module?.mount).toEqual(["world-simulator"]);
|
||||
expect(findModuleByName(catalog, "实现机制")?.id).toBe("mechanism");
|
||||
expect(artifactTagForStep("实现机制", catalog)).toBe("设计.世界法则");
|
||||
const legacyFlow = parseCreationFlow(
|
||||
`{"steps":[{"name":"实现机制","depends_on":[]}]}`,
|
||||
)!;
|
||||
expect(validateCreationFlow(legacyFlow, catalog).ok).toBe(true);
|
||||
|
||||
const prompt = await loadModulePrompt(
|
||||
"dialogue/world-simulator",
|
||||
@@ -1048,19 +1057,21 @@ modules:
|
||||
"../src/skills/creation-flow.js"
|
||||
);
|
||||
const sections = parseModulePromptSections(prompt!);
|
||||
expect(sections.blocks.task).toContain("多条共同作用");
|
||||
expect(sections.blocks.task).toContain("缺失后果");
|
||||
expect(sections.blocks.task).toContain("连锁");
|
||||
expect(sections.blocks.task).toContain("删掉所有提到玩家的句子");
|
||||
expect(sections.blocks.output).toContain('"既成机制"');
|
||||
expect(sections.blocks.output).toContain('"因果影响"');
|
||||
expect(sections.blocks.output).toContain('"推演口径"');
|
||||
expect(sections.blocks.output).toContain('"法则"');
|
||||
expect(sections.blocks.output).toContain('"连锁"');
|
||||
expect(sections.blocks.task).toContain("拓扑图名");
|
||||
expect(sections.blocks.output).not.toContain('"标尺"');
|
||||
expect(sections.blocks.output).toContain('"共同作用"');
|
||||
expect(sections.blocks.output).not.toContain('"缺失后果"');
|
||||
expect(sections.blocks.output).not.toContain('"推演口径"');
|
||||
expect(sections.blocks.output).not.toContain('"自评"');
|
||||
expect(sections.blocks.score).toContain("骨架必要度");
|
||||
expect(sections.blocks.score).toContain("因果清晰度");
|
||||
expect(sections.blocks.score).toContain("推演开放度");
|
||||
expect(sections.blocks.examples).toContain("灵气复苏");
|
||||
expect(sections.blocks.examples).toContain("全民直播求生");
|
||||
expect(sections.blocks.score).toContain("世界客观度");
|
||||
expect(sections.blocks.score).toContain("连锁充分度");
|
||||
expect(sections.blocks.score).toContain("承重克制度");
|
||||
expect(sections.blocks.examples).toContain("没有黄段子");
|
||||
expect(sections.blocks.examples).toContain("灵气重回");
|
||||
});
|
||||
|
||||
it("loads the migrated topology contract", async () => {
|
||||
@@ -1078,6 +1089,7 @@ modules:
|
||||
"../src/skills/creation-flow.js"
|
||||
);
|
||||
const sections = parseModulePromptSections(prompt!);
|
||||
expect(sections.blocks.task).toContain("有序标尺");
|
||||
expect(sections.blocks.task).toContain("一张图");
|
||||
expect(sections.blocks.task).toContain("static");
|
||||
expect(sections.blocks.task).toContain("record");
|
||||
@@ -1111,8 +1123,8 @@ modules:
|
||||
const sections = parseModulePromptSections(prompt!);
|
||||
expect(sections.blocks.task).toContain("deterministic");
|
||||
expect(sections.blocks.task).toContain("narrative_inference");
|
||||
expect(sections.blocks.task).toContain("inline_tool");
|
||||
expect(sections.blocks.task).toContain("auditor_bundle");
|
||||
expect(sections.blocks.task).toContain("旁观填表");
|
||||
expect(sections.blocks.task).toContain("play_slots");
|
||||
expect(sections.blocks.output).toContain('"允许写入者"');
|
||||
expect(sections.blocks.output).toContain('"更新规则"');
|
||||
expect(sections.blocks.output).toContain('"派生映射"');
|
||||
@@ -1143,11 +1155,11 @@ modules:
|
||||
);
|
||||
const sections = parseModulePromptSections(prompt!);
|
||||
expect(sections.blocks.task).toContain("语义区域");
|
||||
expect(sections.blocks.task).toContain("inline");
|
||||
expect(sections.blocks.task).toContain("旁观副 LLM");
|
||||
expect(sections.blocks.output).toContain('"语义区域"');
|
||||
expect(sections.blocks.output).toContain("program_projection");
|
||||
expect(sections.blocks.output).toContain("maintenance_channel");
|
||||
expect(sections.blocks.output).toContain("state_ops");
|
||||
expect(sections.blocks.output).not.toContain("maintenance_channel");
|
||||
expect(sections.blocks.output).not.toContain("state_ops");
|
||||
expect(sections.blocks.output).not.toContain('"启用"');
|
||||
expect(sections.blocks.output).not.toContain("1000～2000");
|
||||
expect(sections.blocks.output).not.toContain('"自评"');
|
||||
@@ -1658,18 +1670,18 @@ modules:
|
||||
const flowRaw = JSON.stringify({
|
||||
status: "open",
|
||||
steps: [
|
||||
{ id: "美学纲领与交互范式", name: "美学纲领与交互范式", depends_on: [] },
|
||||
{ id: "美学纲领", name: "美学纲领", depends_on: [] },
|
||||
],
|
||||
});
|
||||
const binding = await resolveDesignStepBinding({
|
||||
skillPackRoot: "dialogue/world-simulator",
|
||||
flowRaw,
|
||||
currentStepName: "美学纲领与交互范式",
|
||||
acceptedStepNames: ["美学纲领与交互范式"],
|
||||
currentStepName: "美学纲领",
|
||||
acceptedStepNames: ["美学纲领"],
|
||||
inheritExisting: true,
|
||||
});
|
||||
expect(binding?.opening).toBeNull();
|
||||
expect(binding?.inheritTag).toBe("设计.美学纲领与交互范式");
|
||||
expect(binding?.inheritTag).toBe("设计.美学纲领");
|
||||
|
||||
const loaded = await loadWorkerSkillWithContext(
|
||||
"world-simulator",
|
||||
@@ -1677,15 +1689,15 @@ modules:
|
||||
undefined,
|
||||
{
|
||||
flowRaw,
|
||||
currentStepName: "美学纲领与交互范式",
|
||||
acceptedStepNames: ["美学纲领与交互范式"],
|
||||
currentStepName: "美学纲领",
|
||||
acceptedStepNames: ["美学纲领"],
|
||||
inheritExisting: true,
|
||||
},
|
||||
);
|
||||
expect(loaded.promptBody).toContain("【回头修改】");
|
||||
expect(loaded.promptBody).not.toContain("程序开场");
|
||||
expect(loaded.worker.name).toContain("回头修改");
|
||||
expect(loaded.worker.inputTags).toContain("设计.美学纲领与交互范式");
|
||||
expect(loaded.worker.inputTags).toContain("设计.美学纲领");
|
||||
});
|
||||
|
||||
it("layers follow longest dependency path", () => {
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
import { mkdirSync, mkdtempSync, writeFileSync } from "node:fs";
|
||||
import { tmpdir } from "node:os";
|
||||
import path from "node:path";
|
||||
import { beforeEach, describe, expect, it } from "vitest";
|
||||
|
||||
describe("image workflow library", () => {
|
||||
beforeEach(() => {
|
||||
process.env.WRITING_AGENT_DATA_DIR = mkdtempSync(
|
||||
path.join(tmpdir(), "wa-img-"),
|
||||
);
|
||||
});
|
||||
|
||||
it("lists a folder only when meta and workflow are both valid", async () => {
|
||||
const { getImageWorkflowsDir, listImageWorkflows, getImageWorkflow } =
|
||||
await import("../src/image-workflow/store.js");
|
||||
const { formatImageWorkflowCatalogForPrompt } = await import(
|
||||
"../src/image-workflow/catalog.js"
|
||||
);
|
||||
const root = getImageWorkflowsDir();
|
||||
const ready = path.join(root, "western-fantasy");
|
||||
const broken = path.join(root, "broken");
|
||||
mkdirSync(ready, { recursive: true });
|
||||
mkdirSync(broken, { recursive: true });
|
||||
writeFileSync(
|
||||
path.join(ready, "meta.json"),
|
||||
JSON.stringify({
|
||||
id: "western-fantasy",
|
||||
name: "西幻",
|
||||
summary: "铠甲、城堡、油画光",
|
||||
prompt_node: "6",
|
||||
prompt_field: "text",
|
||||
prompt_notes: "提示词写场面，不堆画风词",
|
||||
}),
|
||||
);
|
||||
writeFileSync(
|
||||
path.join(ready, "workflow.json"),
|
||||
JSON.stringify({ "6": { class_type: "CLIPTextEncode", inputs: { text: "" } } }),
|
||||
);
|
||||
writeFileSync(path.join(broken, "meta.json"), JSON.stringify({ name: "缺图" }));
|
||||
|
||||
const listed = listImageWorkflows();
|
||||
expect(listed.map((entry) => entry.id)).toEqual(["western-fantasy"]);
|
||||
expect(getImageWorkflow("western-fantasy")?.promptNode).toBe("6");
|
||||
const catalog = formatImageWorkflowCatalogForPrompt();
|
||||
expect(catalog).toContain("【工作流库 · 可选用】");
|
||||
expect(catalog).toContain("western-fantasy｜西幻｜铠甲、城堡、油画光");
|
||||
expect(catalog).not.toContain("CLIPTextEncode");
|
||||
});
|
||||
});
|
||||
+11
-2
@@ -34,11 +34,12 @@ const WORKER_LABELS = {
|
||||
};
|
||||
|
||||
const FIXED_TOPIC_LABELS = {
|
||||
"aesthetics-interaction": "美学纲领与交互范式",
|
||||
"aesthetics-interaction": "美学纲领",
|
||||
interaction: "交互范式",
|
||||
narrative_guide: "叙事指南与故事推进",
|
||||
"narrative-guide": "叙事指南",
|
||||
"story-progression": "故事推进",
|
||||
"image-prompt": "画面与生图",
|
||||
"story-progression": "故事推进与交互范式",
|
||||
input_protocol: "输入协议",
|
||||
core_premise: "核心前提",
|
||||
aesthetics: "美学纲领",
|
||||
@@ -55,6 +56,14 @@ export function displayStageLabel(id) {
|
||||
return STAGE_LABELS[id] ?? id;
|
||||
}
|
||||
|
||||
export function displayProductSurfaceLabel(id) {
|
||||
if (!id) return "";
|
||||
const map = {
|
||||
"direct-chat": "直聊",
|
||||
};
|
||||
return map[id] ?? id;
|
||||
}
|
||||
|
||||
export function displayCreationModeLabel(id) {
|
||||
if (!id) return "";
|
||||
const map = {
|
||||
|
||||
Reference in New Issue
Block a user