引入上下文片段、固定槽与投影排序，并完善机遇裁定与游玩期 UI。
把创作产物收敛为可挂载片段与 play_slots/context_order，同步修订世界模拟器模块与运行时拼装。 Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
@@ -1,7 +1,8 @@
|
||||
# 美学纲领与交互范式
|
||||
|
||||
> 能力标准形范例。程序只切割下方 **fence 块**（`meta` / `opening` / `task` / …）；`##` 标题仅供人读。
|
||||
> 写法说明：`docs/world-simulator-modules.md`。
|
||||
> **技能标准形范例**（其它中段技能对齐本结构）。
|
||||
> 程序只切割下方 **fence 块**（`meta` / `opening` / `task` / …）；`##` 标题仅供人读。
|
||||
> 写法：`docs/world-simulator-modules.md`；产物公共头：`docs/context-fragment-design.md`。
|
||||
|
||||
## meta
|
||||
|
||||
@@ -14,15 +15,16 @@ declaration: >
|
||||
询问相近故合为一步，勿拆成「交互」「美学」两步
|
||||
when: |
|
||||
可玩/可沉浸体验，但站位、呈现、核心感觉或轮转边界仍不清时；
|
||||
世界模拟类导演通常作为剧本第一步（无上游依赖）。
|
||||
世界模拟类配方通常作为工作流计划第一步（无上游依赖）。
|
||||
已有等价定稿且用户未要求重谈 → 不要重复排入。
|
||||
when_not: |
|
||||
只改实现细节且体验契约已验收；纯工具/排版；与「给玩家什么体验」无关。
|
||||
boundary: |
|
||||
本能力：体验是什么、怎么发生在用户身上、轮转怎么停。
|
||||
叙事指南：世界/助手态度口径（契约已写清的勿重复问卷）。
|
||||
世界蓝图 / 具体实例 / 生成规则：世界内容与可执行规则——本步不定。
|
||||
实现机制 / 拓扑 / 变量* / 状态栏 / 回复格式 / Worker 规格：落到可运行结构——本步不定。
|
||||
本技能：体验是什么、怎么发生在用户身上、轮转怎么停；产出 context-fragment.v1。
|
||||
叙事指南与故事推进：把感觉落成遣词/笔墨/禁忌与推进——本步只钉感觉与轮转。
|
||||
舞台骨架 / 具体实例 / 生成规则：舞台与可执行规则——本步不定。
|
||||
实现机制 / 变量* / 监控栏 / 正文组成 / 游玩拓扑 / 上下文投影排序 / 细化终稿：落到可运行结构——本步不定。
|
||||
feeds: design_only
|
||||
```
|
||||
|
||||
## opening
|
||||
@@ -48,7 +50,8 @@ boundary: |
|
||||
```task
|
||||
与用户一起钉清一份「体验契约」：给玩家什么感受、如何参与、正文如何呈现、何时等待用户。
|
||||
|
||||
写入产物 tag（通常为 设计.美学纲领与交互范式）。
|
||||
产物必须是 **context-fragment.v1** JSON，写入 tag「设计.美学纲领与交互范式」。
|
||||
业务字段全部放在「正文」内；须含 schema / 技能 / brief；建议填 mount 与稳变（本步不写数字 order）。
|
||||
|
||||
一次 design-step、一场对话、一次验收。参与方式与美学内容在同一步内交叉追问，不要先交「半份交互」再开「半份美学」。
|
||||
|
||||
@@ -65,6 +68,7 @@ boundary: |
|
||||
5. 用户常说不清想要什么 → 展示优于提问、大胆优于保守、去道德化/常态化、具体化；负面信号同样有效。
|
||||
6. 变造世界：先抓「原型 + 变在哪里」；核心体验往往来自变种，不要写成设定百科。
|
||||
7. 同一设定不同用户要的东西可以完全不同（角斗士：荣耀 / 自由 / 血与酒）——找到核心与禁忌，不是补全世界观。
|
||||
8. 本步是上下文片段，不是执行单元清单；禁止输出 Worker 列表或最终插入 order。
|
||||
```
|
||||
|
||||
## probe
|
||||
@@ -96,68 +100,136 @@ boundary: |
|
||||
|
||||
```output
|
||||
{
|
||||
"brief": "一句话：用户要的核心体验",
|
||||
"变造": {
|
||||
"原型": "…",
|
||||
"变点": "…"
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "美学纲领与交互范式",
|
||||
"brief": "一句话点题：用户最想反复感受到什么",
|
||||
"mount": ["world-simulator", "narrator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"设定逻辑": {
|
||||
"变造": { "原型": "…", "变点": "…" },
|
||||
"参与方式": {
|
||||
"用户与user关系": { "结论": "…", "完备度": "…%", "依据": "…" },
|
||||
"焦点位置": { "结论": "…", "完备度": "…%", "依据": "…" },
|
||||
"满足来源": { "结论": "…", "完备度": "…%", "依据": "…" }
|
||||
},
|
||||
"内容维度": {
|
||||
"核心感觉": { "完备度": "…%", "已知": "…", "待探": "无|…" },
|
||||
"人物与关系": { "完备度": "…%", "已知": "…", "待探": "无|…" },
|
||||
"身体与感官": { "完备度": "…%", "已知": "…", "待探": "无|…" },
|
||||
"背景与规则": { "完备度": "…%", "已知": "…", "待探": "无|…" },
|
||||
"意义与主题": { "完备度": "…%", "已知": "…", "待探": "无|…" }
|
||||
},
|
||||
"特殊概念": "无|短列",
|
||||
"区域化诊断": {
|
||||
"是否需要": false,
|
||||
"判断依据": "…",
|
||||
"区域识别": [],
|
||||
"边界类型": "无|空间|阶段|…",
|
||||
"转换机制": "…"
|
||||
},
|
||||
"复杂性识别": {
|
||||
"内容复杂性": "简单|可结构化复杂|…",
|
||||
"体验者位置复杂性": "简单|…",
|
||||
"判断依据": "…"
|
||||
},
|
||||
"完备度判断": {
|
||||
"核心状态": "核心明确|仍混沌|…",
|
||||
"判断依据": "…",
|
||||
"薄弱点": "…"
|
||||
}
|
||||
},
|
||||
"交互范式": {
|
||||
"前置配置": {
|
||||
"用户与user关系": "…",
|
||||
"人称": "第二人称称「你」|…",
|
||||
"元叙事": "不得跳出故事直接问卷；决策用情节呈现|…"
|
||||
},
|
||||
"叙事视角": {
|
||||
"主要视角": "…",
|
||||
"视角切换": "禁止|例外…",
|
||||
"可写内心": "仅 user|…",
|
||||
"不呈现的信息": "…"
|
||||
},
|
||||
"描写权限": {
|
||||
"思考与抉择": "何时可写 / 何时必须停等用户",
|
||||
"言语": "…",
|
||||
"主动行动": "…",
|
||||
"情绪与身体反应": "…",
|
||||
"习惯与既有技能": "…",
|
||||
"外在状态": "…",
|
||||
"用户输入后": "只确认 / 补细节 / 连带后果…"
|
||||
},
|
||||
"后果与叙事控制": {
|
||||
"行为后果判定": "…",
|
||||
"世界对user的影响": "…",
|
||||
"时间与场景": "…",
|
||||
"引入新内容": "…",
|
||||
"设计困境": "…"
|
||||
},
|
||||
"区域差异": "无|按区域写权限差异（与设定逻辑.区域化诊断对齐）"
|
||||
},
|
||||
"美学纲领": {
|
||||
"体验内核": "给用户读的纲领正文（可多段；写清要反复感到什么、权力/关系如何成立）",
|
||||
"呈现要点": {
|
||||
"氛围基调": "…",
|
||||
"边界与尺度": "色情/暴力/血腥等：服务体验的用法与禁忌",
|
||||
"其它要点": ["权力日常化|反差|…"]
|
||||
}
|
||||
}
|
||||
},
|
||||
"参与": {
|
||||
"站位": "…",
|
||||
"代入": "完全|部分|操控|旁观|…",
|
||||
"用户与user": "情感距离 / 控制期待 / 多角色",
|
||||
"输入解释": "主视角行动 vs 世界行动等",
|
||||
"焦点": "主焦点；次要（若有）",
|
||||
"满足来源": "…"
|
||||
"自评": {
|
||||
"维度": [
|
||||
{ "名": "交互范式", "分数": 0, "说明": "权限边界是否锁住核心体验" },
|
||||
{ "名": "美学纲领", "分数": 0, "说明": "体验内核是否点题、有质感" },
|
||||
{ "名": "整体协调", "分数": 0, "说明": "范式是否在保护纲领" }
|
||||
],
|
||||
"薄弱点": "一句话"
|
||||
},
|
||||
"呈现": {
|
||||
"正文人称或体裁": "…",
|
||||
"系统扮演": "世界执行者 / …",
|
||||
"输出形态": "单段叙事 / …"
|
||||
"追问": {
|
||||
"导语": "为贴近你要的质感，还需确认：",
|
||||
"题目": [
|
||||
{
|
||||
"问": "…",
|
||||
"建议选项": ["选项A（可带短场景）", "选项B", "其它（请写明）"],
|
||||
"示例": "可选：一句示范句或短钩子"
|
||||
}
|
||||
]
|
||||
},
|
||||
"体验": {
|
||||
"内核": "最想反复感受到的…",
|
||||
"形状": "过程|张力|层次|构成|循环|…",
|
||||
"呈现要点": ["…"],
|
||||
"边界禁忌": ["…"]
|
||||
},
|
||||
"内容摘要": {
|
||||
"核心感觉": "…",
|
||||
"人物与关系": "…",
|
||||
"身体与感官": "…",
|
||||
"背景与规则": "…",
|
||||
"意义与主题": "…"
|
||||
},
|
||||
"轮转": {
|
||||
"思考与抉择": "何时等、怎么等、例外、输入后怎么补",
|
||||
"言语": "…"
|
||||
}
|
||||
"开放问题": []
|
||||
}
|
||||
```
|
||||
|
||||
未知字段省略或写「未定」，禁止编造。summary：`美学纲领与交互范式 · …`（点题核心体验）。
|
||||
硬规则（公共三段 + 本技正文）：
|
||||
1. 合法 JSON；必含 `schema` / `技能` / `brief` / `正文` / `自评` / `追问`（题目可 `[]`）。
|
||||
2. **公共三段**：`正文`＝产物主体；`自评`＝完备度打分；`追问`＝导语+题目（建议选项/示例）。禁止用散文代替这三段。
|
||||
3. **本技正文三块**：`设定逻辑`（参与/内容维度/区域/复杂性/完备度）+ `交互范式` + `美学纲领`。未知省略或「未定」，禁止编造百科。
|
||||
4. `mount` 建议挂主世界层+转述；**禁止**写数字 `order`。`稳变` 定稿后多为 `stable`。
|
||||
5. `追问.题目` 一次宜 1～3 题；有建议选项；允许「其它」。已答清的不要再问。
|
||||
6. summary：`美学纲领与交互范式 · {brief 缩略}`。
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 变造：原型与变点是否清楚（或已标未定）？
|
||||
- [ ] 代入与否 / 站位是否清楚？
|
||||
- [ ] 最想反复感受到的核心是否一句话能说清？
|
||||
- [ ] 体验内核 + 呈现要点 + 边界禁忌是否成套（可短，不可互相矛盾）？
|
||||
- [ ] 重大抉择与言语的等待边界是否够下游引用？
|
||||
- [ ] 有没有为「完整」强行填充的设定百科？
|
||||
- [ ] 有没有完善着偏离用户原话里的核心？
|
||||
- [ ] 是否误写成 Worker 列表？
|
||||
- [ ] 含 schema / brief / 正文 / 自评 / 追问 三段外壳？
|
||||
- [ ] 正文含设定逻辑 + 交互范式 + 美学纲领？自评有交互/美学/协调维度？
|
||||
- [ ] 未写 order、未输出执行单元列表？
|
||||
- [ ] brief 能点题核心体验？变造/代入/满足来源清楚或已标未定？
|
||||
- [ ] 交互范式权限与美学纲领互相保护、不矛盾？
|
||||
- [ ] 追问只打薄弱点，带建议选项？
|
||||
- [ ] 有没有为「完整」强行填充百科或偏离用户核心？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：
|
||||
- 「丧尸世界，变点是只有我不会被感染；完全代入；最想感到特权下的求生紧张与道德压力。」
|
||||
- 用户要艰苦角斗 → 禁忌写「轻松连胜」；选项带短场景。
|
||||
- brief 点题「垄断生存资源的绝对掌控感」；正文三块齐（设定逻辑含完备度/待探、交互范式锁权限、美学纲领写体验内核）；自评打分；追问带建议选项打薄弱点。
|
||||
- 内容质感可参考「权力孤岛」类长描写，但必须落在上述 JSON 键里，不要输出 XML/自定义标签壳。
|
||||
|
||||
坏：
|
||||
- 「现代都市，有公司有地铁…」（百科，无变点、无核心感受）
|
||||
- 用户要爽文角斗，仍按真实艰苦写满受苦
|
||||
- 「你想要什么体验？」抽象难答；或一张表全勾选
|
||||
- 只有散文纲领，无 JSON / 无自评 / 无追问结构
|
||||
- 百科式背景堆砌，无满足来源与权限边界
|
||||
- 输出 workers[] 或 order 表
|
||||
- 追问空洞「你想要什么体验？」无选项
|
||||
```
|
||||
|
||||
@@ -29,19 +29,18 @@ modules:
|
||||
|
||||
# —— 世界与内容 ——
|
||||
- id: world-blueprint
|
||||
name: 世界蓝图与人文地理
|
||||
name: 舞台骨架
|
||||
declaration: >-
|
||||
当体验需要可引用的「舞台背景」时使用：钉舞台尺度、熟悉基底与变造、
|
||||
关键格局与人文地理；只细化舞台上会出现的部分，不做设定百科或纸面地图
|
||||
artifact: 设计.世界蓝图与人文地理
|
||||
体验需要可引用舞台时：钉尺度、基底与变造、关键舞台区，以及社会结构与世界状况；
|
||||
只细化会上台部分，不做地图百科
|
||||
artifact: 设计.舞台骨架
|
||||
|
||||
- id: generation-rules
|
||||
name: 生成规则
|
||||
repeatable: true
|
||||
declaration: >-
|
||||
仅当某类内容既对游玩重要、又无法凭世界基底稳定生成时使用：
|
||||
定义严格 schema、生成约束与仅动态/仅预生成/预生成并动态三种生命周期；
|
||||
可按生成对象反复调用
|
||||
仅当某类内容既重要又无法凭基底稳定生成时：写出规则
|
||||
（怎么描写/生成 + 产物格式 + 可选多池，池绑 JSON 字段）；可按对象反复调用
|
||||
artifact: 设计.生成规则
|
||||
params:
|
||||
- key: target
|
||||
@@ -61,8 +60,7 @@ modules:
|
||||
name: 具体实例
|
||||
repeatable: true
|
||||
declaration: >-
|
||||
执行一条要求预生成的生成规则，直接产出符合其 schema 与约束的具体实例；
|
||||
仅动态规则不调用，可按 rule_id 或批次反复调用
|
||||
按预生成规则原样产出实际产物；不设计、不改合同；可按 rule_id/批次反复调用
|
||||
artifact: 设计.具体实例
|
||||
params:
|
||||
- key: rule_id
|
||||
@@ -79,16 +77,18 @@ modules:
|
||||
hint: 数字或「按规则」；contextual 时写清规模依据
|
||||
|
||||
- id: narrative
|
||||
name: 叙事指南
|
||||
declaration: 世界/助手态度与体验边界（不等于文风；契约已写清的态度勿重复问卷）
|
||||
artifact: 设计.叙事指南
|
||||
name: 叙事指南与故事推进
|
||||
declaration: >-
|
||||
钉转述写法与故事推进：纲领、遣词造句、笔墨焦点、禁忌/不偏好、示范与备用、
|
||||
推进决策（可含变量钩子）；美学写感觉，本步写怎么写、往哪推
|
||||
artifact: 设计.叙事指南与故事推进
|
||||
|
||||
# —— 机制与数据 ——
|
||||
- id: mechanism
|
||||
name: 实现机制
|
||||
declaration: >-
|
||||
当核心体验已经明确，需要识别由哪些角色、世界、关系、规则或情境切面支撑，
|
||||
并把体验落成可供后续设定工作的核心支点时使用
|
||||
核心体验已明时：识别承重切面（如何支撑 / 缺失后果），产出可挂主世界层的上下文片段；
|
||||
不重定体验、不写百科或执行单元
|
||||
artifact: 设计.实现机制
|
||||
|
||||
- id: topology
|
||||
@@ -98,33 +98,60 @@ modules:
|
||||
|
||||
- id: variable-design
|
||||
name: 变量设计与更新规则
|
||||
declaration: 钉变量字段、初值与更新时机/规则；与表副作用对齐
|
||||
declaration: >-
|
||||
钉真值字段、写入源（执行单元/用户/程序）、更新规则，以及按真值门控的
|
||||
side_effects（Progressive 投影）；与运行规格 tables 对齐
|
||||
artifact: 设计.变量设计与更新规则
|
||||
|
||||
- id: variable-context
|
||||
name: 变量控制上下文
|
||||
declaration: 钉哪些变量如何挂进常驻上下文 / 控制生成口径（可见性与措辞）
|
||||
declaration: >-
|
||||
钉真值与投影如何挂进主世界层等上下文：可见性、措辞、未解锁不注入
|
||||
artifact: 设计.变量控制上下文
|
||||
|
||||
# —— 呈现 ——
|
||||
- id: status-bar
|
||||
name: 设计状态栏
|
||||
declaration: 钉用户可见状态栏：字段、刷新时机、与正文如何拼装
|
||||
artifact: 设计.状态栏
|
||||
name: 设计监控栏
|
||||
declaration: >-
|
||||
钉用户可见监控栏字段：只留会变、影响决策或沉浸的信息
|
||||
（主角/攻略目标/场景交互物等）；旧称设计状态栏
|
||||
artifact: 设计.监控栏
|
||||
|
||||
- id: reply-format
|
||||
name: 设计回复格式
|
||||
declaration: 钉单轮可见输出的结构（正文块、面板、拼接顺序），服务体验契约
|
||||
artifact: 设计.回复格式
|
||||
name: 正文组成
|
||||
declaration: >-
|
||||
钉用户可见的一轮回复由哪些块、何顺序组成（含监控栏位置、隐藏变量段、前端拆分）；
|
||||
不是程序报文格式；旧称设计回复格式
|
||||
artifact: 设计.正文组成
|
||||
|
||||
# —— 开局（创作偏晚） ——
|
||||
- id: opening-setup
|
||||
name: 开场白与开场变量
|
||||
declaration: >-
|
||||
写出遵循正文组成/叙事等契约的开场一小段，并钉同真相的开场变量初值；
|
||||
开场为主、填表为辅；可与 opening-generator 落库
|
||||
artifact: 设计.开场白与开场变量
|
||||
|
||||
# —— 收成 / 钉声明（共用；世界模拟器按需） ——
|
||||
- id: worker-spec
|
||||
name: Worker 规格
|
||||
repeatable: true
|
||||
declaration: 钉一个游玩期执行单元（职责、读写、挂载）；多演员时可多次调用
|
||||
name: 游玩拓扑
|
||||
repeatable: false
|
||||
declaration: >-
|
||||
勾选固定游玩槽位（主世界层/叙事转述/可选角色视角/可选机遇裁定，或写手大纲+章节）；
|
||||
禁止自由发明执行单元
|
||||
artifact: 设计.worker规格
|
||||
|
||||
- id: context-order
|
||||
name: 上下文投影排序
|
||||
repeatable: false
|
||||
declaration: >-
|
||||
根据各上游上下文概括，为启用槽写出扁平投影序（含对话.历史与 projection）；
|
||||
挂谁已定、排第几在本步；不发明执行单元、不重写长文
|
||||
artifact: 设计.上下文投影排序
|
||||
|
||||
- id: refine
|
||||
name: 细化终稿
|
||||
declaration: 钉死关键前提、表与副作用，收成可进游玩的规格
|
||||
declaration: >-
|
||||
按已勾选固定槽与投影排序表收成运行规格（play_slots、常驻、表副作用）；
|
||||
不发明新执行单元
|
||||
artifact: 设计.worker集
|
||||
|
||||
@@ -1,7 +1,8 @@
|
||||
# 具体实例
|
||||
|
||||
> 能力文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 写法说明：`docs/world-simulator-modules.md`；范例：`aesthetics-interaction`。
|
||||
> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 产物外壳：`docs/context-fragment-design.md`。
|
||||
> 本步极简：严格按已验收的「生成规则」执行，交出实际产物。
|
||||
|
||||
## meta
|
||||
|
||||
@@ -10,100 +11,114 @@ name: 具体实例
|
||||
id: concrete-instances
|
||||
artifact: 设计.具体实例
|
||||
declaration: >
|
||||
执行一条要求预生成的生成规则，直接产出符合该规则的具体实例；
|
||||
可按 rule_id 或批次反复调用
|
||||
按一条预生成规则原样产出实际产物（单层 JSON records）；可按 rule_id/批次反复调用；
|
||||
本步不设计、不改合同
|
||||
when: |
|
||||
「设计.生成规则」中已有生命周期为 `seed_only` 或 `seed_and_runtime` 的规则，
|
||||
现在需要按该规则生成实际内容。
|
||||
「设计.生成规则」中已有 `seed_only` 或 `seed_and_runtime` 的规则，需要生成实际内容。
|
||||
when_not: |
|
||||
规则生命周期为 `runtime_only` → 留到实际游玩中生成，本步不预生成。
|
||||
没有对应生成规则，或规则缺少执行所需信息 → 返回「生成规则」补齐。
|
||||
想修改 schema、约束或生命周期 → 返回「生成规则」，本步不改合同。
|
||||
`runtime_only` → 游玩期再生成。
|
||||
无规则 / 规则不完整 / 想改格式或方法 → 回「生成规则」。
|
||||
boundary: |
|
||||
本能力只做一件事：读取指定生成规则，按规则规定的数量、schema、生成步骤与约束，
|
||||
生成可直接使用的实例。它不重新论证规则、不修改规则，也不扩写其它设计。
|
||||
本技能只做一件事：按指定规则生成 records。规则说怎么写、什么格式、如何用池，就照做。
|
||||
生成规则：合同制定方——本步不重论证、不修改。
|
||||
feeds: gm
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
规则已由【本步参数】rule_id 钉死。有批次目标或数量偏好可一句带过；否则直接「按规则生成」。
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
你正在执行剧本中的「具体实例」步骤。产物写入「设计.具体实例」。
|
||||
你正在执行「具体实例」。产物必须是 **context-fragment.v1** JSON，写入「设计.具体实例」。
|
||||
|
||||
本步只是「生成规则」的执行器：根据规则生成具体实例，不做第二轮设计。
|
||||
要执行的 `rule_id` 已在【本步参数】；禁止再问用户要生成什么或重新讨论规则。
|
||||
本步 = 规则执行器。禁止重议对象族、生命周期、schema 或描写方法。
|
||||
|
||||
执行顺序：
|
||||
1. 从「设计.生成规则」找到 `params.rule_id` 对应规则。不存在、不是预生成生命周期或缺少执行所需信息时，停止并准确指出缺口。
|
||||
2. 确定本批数量：`params.count` 有明确数字时采用；否则完全按规则的「数量」决定。`params.batch_goal` 若有，只作为不违反规则的本批筛选条件。
|
||||
3. 按规则的「生成依据」和「生成步骤」生成实例。`records` 只使用规则 schema 声明的字段，填满所有必填字段，并遵守类型、枚举、边界、嵌套结构、硬约束、字段间约束、变化维度、禁止项和去重规则。
|
||||
4. 逐条按规则的「校验」检查；不合格的实例直接重生成，不把错误项或设计过程写进产物。
|
||||
5. 若已有「设计.具体实例」，按 `rule_id` 追加新批次；除非用户明确要求替换，不改动旧批次。
|
||||
6. 输出符合 output 的 JSON。
|
||||
1. 取出 `params.rule_id` 对应规则；非预生成生命周期或缺信息 → 停止并指出缺口。
|
||||
2. 数量：`params.count` 有数字用数字，否则用规则「数量」；`batch_goal` 只作不违反规则的筛选。
|
||||
3. 完全按规则的「生成与描写」+「产物格式」+「池」生成 `records`（单层 JSON；键=schema 顶层字段）。
|
||||
4. 按规则自检；不合格内部重做。已有产物则追加批次（除非用户要求替换）。
|
||||
5. 输出 JSON；追问通常 `[]`。
|
||||
|
||||
若程序已发出默认问题：用户首答在「用户.worker答复」。禁止重复同一开场。
|
||||
|
||||
summary：`具体实例 · {生成对象} · {本批数量}条`
|
||||
summary：`具体实例 · {对象} · {n}条`
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 规则说什么就生成什么：不补字段、不改边界、不新增规则。
|
||||
2. 只交实例：`records` 放最终可用数据，不放 schema、解释、草稿或占位符。
|
||||
3. 先生成后自检：不合格项内部重做，只交通过规则校验的结果。
|
||||
4. 保持差异：在规则允许的变化维度内避免重复，不用变化破坏共同约束。
|
||||
1. 只按规则来：方法、格式、池、数量、约束——规则有什么用什么；没有的不发明。
|
||||
2. 只交 records：单层 JSON；不交解释、草稿、schema 副本、整池粘贴。
|
||||
3. 要改合同 → 回「生成规则」，本步不加字段、不改枚举。
|
||||
```
|
||||
|
||||
## probe
|
||||
|
||||
```probe
|
||||
通常不追问，直接按规则生成。
|
||||
仅当规则使用 contextual 数量而现有参数和依赖无法算出数量时，询问缺失的地区、阶段或规模。
|
||||
若用户要求 schema 外内容，提示返回「生成规则」修改合同；不要在本步临时加字段。
|
||||
通常不追问。仅当 contextual 数量算不出时问一句规模依据。
|
||||
用户要 schema 外内容 → 提示回「生成规则」。
|
||||
```
|
||||
|
||||
## output
|
||||
|
||||
```output
|
||||
{
|
||||
"batches": [
|
||||
{
|
||||
"batch_id": "稳定的英文 kebab-case id",
|
||||
"rule_id": "来源生成规则 id",
|
||||
"对象": "本批生成的内容类型",
|
||||
"数量": 3,
|
||||
"批次条件": ["本批额外筛选条件；没有则为空"],
|
||||
"records": [
|
||||
{
|
||||
"这里直接使用来源规则的实际字段": "不得使用通用人物/地点/物件名片代替"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"增量说明": "本次新增或替换了哪个 batch_id"
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "具体实例",
|
||||
"brief": "rule_id + 本批条数",
|
||||
"mount": ["world-simulator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"rule_id": "与 params 一致",
|
||||
"本批数量": 3,
|
||||
"批次条件": ["params.batch_goal 等；无则 []"],
|
||||
"batch_id": "英文 kebab-case",
|
||||
"records": [
|
||||
{
|
||||
"键来自规则产物格式 schema": "值"
|
||||
}
|
||||
],
|
||||
"增量说明": "新建|追加|替换某 batch_id"
|
||||
},
|
||||
"自评": {
|
||||
"维度": [
|
||||
{
|
||||
"名": "合规模",
|
||||
"分数": 0,
|
||||
"说明": "是否严格按该规则的方法、单层格式、池与约束生成"
|
||||
}
|
||||
],
|
||||
"薄弱点": "一句话；无则空字符串"
|
||||
},
|
||||
"追问": {
|
||||
"导语": "",
|
||||
"题目": []
|
||||
},
|
||||
"开放问题": []
|
||||
}
|
||||
|
||||
`records` 的示意键必须被实际规则 schema 完整替换。不得把 schema 定义复制进 `records`。
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. 合法 JSON；含 `schema` / `技能` / `brief` / `正文` / `自评` / `追问`。
|
||||
2. 正文键固定：`rule_id` / `本批数量` / `批次条件` / `batch_id` / `records` / `增量说明`。
|
||||
3. `records` 每条必须是规则约定的单层 JSON；`本批数量 === records.length`。
|
||||
4. 自评仅「合规模」一维。禁止改规则、写 `order`、输出执行单元列表。
|
||||
5. summary：`具体实例 · {对象} · {n}条`。
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 是否执行了 params.rule_id 指向的预生成规则？
|
||||
- [ ] 数量是否来自 params.count 或规则本身？
|
||||
- [ ] records 是否完整符合 schema 及全部约束？
|
||||
- [ ] 是否只输出最终实例，没有混入规则解释或校验过程？
|
||||
- [ ] 是否保留未要求替换的已有批次？
|
||||
- [ ] 按 params.rule_id 的预生成规则执行？
|
||||
- [ ] records 单层、键值符合产物格式与全部约束？
|
||||
- [ ] 自评为合规模？未改合同？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：
|
||||
- `heroine-design` 要求 1 条：直接生成 1 条完整女主记录，字段和值全部服从规则。
|
||||
- `major-npc` 要求 5 条：直接生成 5 名互不重复、满足阵营与地区约束的重要 NPC。
|
||||
|
||||
坏：
|
||||
- 无视 schema，给实例补上“背景故事”等未声明字段。
|
||||
- 输出一段生成思路和校验报告，却没有直接给可用实例。
|
||||
好：规则要 3 条怪物 → 交出 3 条单层 record，字段与池用法全服从规则。
|
||||
坏：加规则没有的字段；输出一段「我是怎么想的」却没有 records；本步改 schema。
|
||||
```
|
||||
|
||||
129
skills/dialogue/world-simulator/modules/context-order/prompt.md
Normal file
129
skills/dialogue/world-simulator/modules/context-order/prompt.md
Normal file
@@ -0,0 +1,129 @@
|
||||
# 上下文投影排序
|
||||
|
||||
> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> **本步只排出扁平投影序，不发明执行单元，不重写设定长文。**
|
||||
> 「对话.历史」也是可投影标签（改 projection 裁剪长度）；见 `docs/context-fragment-design.md`。
|
||||
|
||||
## meta
|
||||
|
||||
```meta
|
||||
name: 上下文投影排序
|
||||
id: context-order
|
||||
artifact: 设计.上下文投影排序
|
||||
declaration: >
|
||||
根据各上游上下文的概括，为每个启用槽写出扁平投影序
|
||||
（含对话.历史标签与 projection）；不发明槽、不重写正文
|
||||
when: |
|
||||
游玩槽已确认（或可按默认），且主要上下文块已有可摘要产物，
|
||||
需要决定插入顺序与投影级别、再收成运行规格时。
|
||||
when_not: |
|
||||
体验/站位仍混沌 → 先美学纲领与交互范式。
|
||||
槽位未定且用户拒绝默认 → 先游玩拓扑。
|
||||
上游上下文仍大量空洞、无法判断稳/变 → 先补缺口，勿空排。
|
||||
只需勾选槽 → 游玩拓扑；只需合并终稿 → 细化终稿。
|
||||
boundary: |
|
||||
本技能：读各块概括 → 产出每槽 inserts[]（order / ref / projection / 可选 note）；须含对话.历史。
|
||||
无「历史前/后」硬分区；对话.历史本身是可排序的一项。
|
||||
游玩拓扑：槽位权威；本步不增白名单外 ref（含按需 chance 不进每轮序）。
|
||||
中段技能：可带 mount 与稳/变信号，最终 order 以本步为准。
|
||||
细化终稿：把本步排序表收进运行规格 context_order；本步不输出完整 设计.worker集。
|
||||
feeds: design_only
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
准备排出各游玩槽的扁平投影序（只排序，不改设定正文）。
|
||||
|
||||
请确认或补充：
|
||||
1. 启用槽是否仍是默认？（世界模拟：主世界层 + 叙事转述；角色视角默认关）
|
||||
2. 「对话.历史」希望夹在哪、投影多狠？（默认 summary）
|
||||
3. 有没有「几乎永不改」或「每轮必变」的块要特别强调？
|
||||
|
||||
若前面产物够用，可直接回复「按已有概括排序」。
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
你正在执行「上下文投影排序」。产物写入「设计.上下文投影排序」。
|
||||
|
||||
输入：已启用槽；各上游上下文的短摘要（及 mount / 稳变信号，若有）。
|
||||
输出：按槽分组的格式化排序表——Runtime/终稿据此把投影插到固定位置。
|
||||
|
||||
规则：
|
||||
1. 禁止发明执行单元或白名单外 ref。
|
||||
2. 禁止重写上游长文；只写 order、ref、projection 与一句 note（勿再写硬锚点分区）。
|
||||
3. 每槽扁平数字序：order 0＝该槽固定人设；其后按「稳→对话.历史→易变」软排。
|
||||
4. 必须包含一项 ref=`对话.历史`（默认 projection=summary）；历史由程序维护，本步只决定夹在哪、投影多狠。
|
||||
5. 常见块名用新 artifact：设计.舞台骨架 / 设计.叙事指南与故事推进 / 设计.正文组成 / 设计.监控栏 等。
|
||||
6. 越稳越靠前；本轮输入/真值/裁决通常在历史之后。
|
||||
7. 同一内容可挂多槽；chance 为按需槽，不必排进每轮 inserts。
|
||||
8. summary：如 `投影排序 · 主世界层 N 条 · 含历史`。
|
||||
|
||||
若程序已发默认问题：禁止重复同一开场；在首答上产出表。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 晚排序：此时才能区分常变与重要；勿回退去发明新槽。
|
||||
2. 概括驱动：凭摘要与稳变信号排序，不把百科全文再读一遍当创作。
|
||||
3. 历史是标签：用投影裁剪，不要假装「整段历史永远在中间锚点」。
|
||||
4. 缓存优先：少变块靠前；高频变块靠后。
|
||||
5. 投影分级：full / summary / fields / fixed——历史默认 summary。
|
||||
6. 可修订已有排序表；用户改稳变判断时只改序，不改上游产物 id。
|
||||
```
|
||||
|
||||
## probe
|
||||
|
||||
```probe
|
||||
一次 askUser 1～2 点，优先 options：
|
||||
- 某块稳/变判断冲突时，问用户更偏「少改利缓存」还是「每轮必须看见」。
|
||||
- 角色视角若开启，问哪些块禁止进主世界层。
|
||||
已齐则直接产出，勿为凑问题而问。
|
||||
```
|
||||
|
||||
## output
|
||||
|
||||
```output
|
||||
{
|
||||
"schema": "context-order.v1",
|
||||
"brief": "一句话：本局扁平投影序（含对话.历史）",
|
||||
"play_slots": { "gm": true, "narrator": true, "perspective": false },
|
||||
"slots": [
|
||||
{
|
||||
"ref": "world-simulator",
|
||||
"label": "主世界层",
|
||||
"inserts": [
|
||||
{ "order": 0, "ref": "worker.persona", "projection": "fixed", "note": "槽位人设" },
|
||||
{ "order": 1, "ref": "设计.实现机制", "projection": "summary", "note": "承重规则摘要" },
|
||||
{ "order": 2, "ref": "对话.历史", "projection": "summary", "note": "按投影裁剪" },
|
||||
{ "order": 3, "ref": "变量.当前", "projection": "fields", "note": "真值" },
|
||||
{ "order": 4, "ref": "用户.最新输入", "projection": "full", "note": "本轮" }
|
||||
]
|
||||
},
|
||||
{
|
||||
"ref": "narrator",
|
||||
"label": "叙事转述",
|
||||
"inserts": [
|
||||
{ "order": 0, "ref": "worker.persona", "projection": "fixed", "note": "转述人设" },
|
||||
{ "order": 1, "ref": "设计.叙事指南与故事推进", "projection": "summary" },
|
||||
{ "order": 2, "ref": "对话.历史", "projection": "summary" },
|
||||
{ "order": 3, "ref": "运行.本轮.裁决", "projection": "full", "note": "settlement" }
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 未发明白名单外执行单元
|
||||
- [ ] 未重写上游长文，只有排序/投影
|
||||
- [ ] 每启用槽有 order 0 人设位
|
||||
- [ ] 每槽含「对话.历史」且有合理 projection
|
||||
- [ ] 少变块整体靠前、本轮/真值靠后（软规则）
|
||||
- [ ] 与游玩拓扑勾选一致
|
||||
```
|
||||
@@ -1,7 +1,8 @@
|
||||
# 生成规则
|
||||
|
||||
> 能力文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 写法说明：`docs/world-simulator-modules.md`；范例：`aesthetics-interaction`。
|
||||
> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 产物外壳：`docs/context-fragment-design.md`；范例：`aesthetics-interaction` / `mechanism`。
|
||||
> 正文高度自定义（描写文案、schema 字段、池条目随对象族而变）；外壳与规则键必须严。
|
||||
|
||||
## meta
|
||||
|
||||
@@ -10,183 +11,254 @@ name: 生成规则
|
||||
id: generation-rules
|
||||
artifact: 设计.生成规则
|
||||
declaration: >
|
||||
仅为重要且模型无法仅凭世界基底稳定生成的同类内容，定义可执行的生成规则、
|
||||
严格数据格式与生命周期；可按生成对象反复调用
|
||||
仅当某类内容既重要又无法凭基底稳定生成时：为该对象族写出一条可执行规则
|
||||
（怎么描写/生成 + 产物格式 + 可选多池，池绑 JSON 字段）；可按对象反复调用；本步不填最终实例
|
||||
when: |
|
||||
上游体验、机制与世界基底已足以判断某类内容：
|
||||
1. 它对实际游玩非常重要；并且
|
||||
2. 模型仅凭现有上下文无法稳定产出符合期待、彼此一致且可供下游使用的结果。
|
||||
两项同时成立时，才为该类对象建立专门生成规则。
|
||||
上游体验与世界基底已足以判断某类内容同时满足：
|
||||
1. 对游玩重要；2. 仅凭现有上下文无法稳定产出合格、一致、可供下游使用的结果。
|
||||
when_not: |
|
||||
内容虽重要，但凭世界基底与常识即可稳定生成 → 不调用。
|
||||
内容难生成，但只是装饰、偶尔出现或删掉不影响核心体验 → 不调用。
|
||||
只想预先写一个普通人/地/物，且不需要先建立专门格式与生成约束 → 不调用。
|
||||
只需定义变量在游玩中如何更新 → 变量设计与更新规则。
|
||||
只需定义剧情、章节或世界如何推进 → 交给对应 Worker 或其它推进能力，不借本步泛化。
|
||||
重要但常识/世界基底已够 → 不建规则。
|
||||
难生成但不影响核心体验 → 不建规则。
|
||||
只要预写最终记录、且不需专门规则 → 通常不必本步。
|
||||
变量如何增减 → 「变量设计与更新规则」。
|
||||
剧情如何推进 → 不借本步泛化。
|
||||
boundary: |
|
||||
本能力：为“一类格式相近的内容”定义生成合同，包括生成依据、字段 schema、
|
||||
枚举值、数值上下界、约束、随机维度、校验方式与规则生命周期。
|
||||
生成对象不限于人物，也可为怪物、装备、任务、职业、组织、事件等。
|
||||
具体实例：执行本步中要求预生成的规则，产出符合合同的实际记录；本步不填实例数据。
|
||||
世界蓝图与人文地理：提供可直接依赖的世界基底；本步不重写世界百科。
|
||||
实现机制：说明某类内容为何支撑体验；本步先验证其必要性，再定义怎么生成。
|
||||
变量设计与更新规则：定义游玩期状态如何变化；本步只约束实例生成时的数据类型与初始合法范围。
|
||||
Worker 规格 / 细化终稿：决定谁在游玩期执行、哪些产物进入常驻上下文；本步只声明所需生命周期。
|
||||
本技能产出的是「规则」本身，一条规则包含：
|
||||
（1）应该怎么描写、生成；（2）产物格式——单层 JSON（对接表格/旁观者/投影）；
|
||||
（3）可选多「池」——各挂一个顶层字段，供抽取/组装/枚举。
|
||||
具体实例：按规则填最终 records；本步不写最终实例（池条目≠实例）。
|
||||
舞台骨架 / 实现机制：可引用，不重写百科、不重做移除检验。
|
||||
变量*：游玩期状态更新——本步只约束生成时的类型与合法初值范围。
|
||||
feeds: gm
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
本轮生成对象已由编排参数钉死（见【本步参数】target）。请直接谈该类内容：
|
||||
|
||||
1. 若不做专门规则、只靠世界设定临场写，最怕出现什么不可接受的结果？
|
||||
2. 更需要：开局先钉一批、游玩中再随机补，还是只在游玩期动态生成？
|
||||
3. 哪些产物字段需要「池」？（池挂在 JSON 字段上，如气质标签池→`气质`；可多个；没有就说没有）
|
||||
|
||||
想到什么写什么；完整规则在正式产物里钉。
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
你正在执行剧本中的「生成规则」步骤。产物写入「设计.生成规则」。
|
||||
你正在执行「生成规则」。产物必须是 **context-fragment.v1** JSON，写入「设计.生成规则」。
|
||||
|
||||
本步不是泛用写作建议，也不是“凡是重要就做一张表”。调用目标已由编排期写入【本步参数】（至少含 target）；禁止再问「这一步生成什么」。
|
||||
本步写出的最终物是**规则**，不是实例。一条规则必须说清两件事，并可附第三件：
|
||||
1. **生成与描写**：应该怎么写、怎么生成（步骤、依据、语气/切面、约束）。
|
||||
2. **产物格式**：生成结果必须遵循的可校验格式（schema）。
|
||||
3. **池**（可选）：每个池挂在产物格式里的某个字段（变量）上，供该字段抽取/组装/枚举；
|
||||
一条规则可多个池；无则 `池: []`。
|
||||
|
||||
对象族已由【本步参数】`target` 钉死；禁止再问「这一步生成什么」，禁止顺手扩到其它族。
|
||||
|
||||
执行顺序：
|
||||
1. 读取【本步参数】与依赖产物。`target` 决定本轮唯一生成对象族；不要顺手扩展到其它类别。若缺必填参数，停止产出并提示返回 design-flow 补参。
|
||||
2. 执行双门槛判断：
|
||||
- 重要性门槛：没有专门生成合同，核心玩法、关键关系、长期一致性或必要数据接口是否会明显受损？
|
||||
- 不可替代门槛：模型是否无法依靠世界基底、常识和普通提示稳定生成合格结果？
|
||||
两项有任一不成立，输出“无需专门规则”的判断与理由，不为了完成步骤硬造 schema。
|
||||
3. 两项均成立时，从三种生命周期中选且只选一种（若 params.lifecycle_intent 已给且合理，优先采用；不合理则说明并 askUser）：
|
||||
- `runtime_only`：仅游玩期动态生成。规则进入后续上下文，不要求「具体实例」预生成。
|
||||
- `seed_only`：下一步由「具体实例」按规则生成；实例进入后续上下文，规则在完成生成与校验后丢弃。
|
||||
- `seed_and_runtime`：下一步先生成种子实例；实例与规则都进入后续上下文，游玩期仍可按同一规则继续生成。
|
||||
4. 建立真正可执行的数据合同：
|
||||
- 明确顶层 JSON 形状、单批数量或数量决定方式、每个字段是否必填。
|
||||
- 每个字段固定类型。至少区分 `string`、`number`、`integer`、`boolean`、`enum`、`array`、`object`；不得只给示例值让下游猜类型。
|
||||
- `enum` 必须同时给出允许值及各值含义；`number/integer` 必须给上下界，并说明边界含义或单位；`array` 必须定义元素类型与数量范围；`object` 必须继续定义子字段。
|
||||
- 写清字段间约束、与世界基底的引用关系、禁止项、去重规则和一致性校验。
|
||||
5. 只有确实需要不可预测性时才定义随机维度；区分“允许变化的字段”和“不能随机破坏的约束”。随机不是省略设计。
|
||||
6. 若 params.rule_id 已给，优先用作本规则 id；否则生成稳定 kebab-case `rule_id`。若已有「设计.生成规则」，按 `rule_id` 增量更新或追加；不得无故重写其它对象的规则。
|
||||
7. 输出符合 output 的 JSON。规则本身不得夹带实际实例。
|
||||
1. 读 params 与依赖。缺 `target` → 停止并提示补参。
|
||||
2. 双门槛：重要性 + 基础上下文不足。任一项不成立 → 结论「无需专门规则」，`rules: []`。
|
||||
3. 两项成立时，生命周期三选一（params.lifecycle_intent 合理则采用）：
|
||||
- `runtime_only`：仅游玩期动态生成；不要求「具体实例」。
|
||||
- `seed_only`：由「具体实例」预生成；规则用完可丢。
|
||||
- `seed_and_runtime`：先种子实例；规则与实例都保留，游玩期仍可按同规则生成。
|
||||
4. 写满规则三块：生成与描写（可较长）+ 产物格式（**单层 JSON**：每条产物是一层键值，无嵌套对象）+ 池（需要才填；绑顶层字段）。
|
||||
5. 逐字段过筛：每个属性都要能回答「对本对象族是否必要」。冗余字段删掉（如女主规则里的「性别」）；对象族必需字段不得漏（如 D&D 怪物的等级、攻击骰）。
|
||||
6. `rule_id`：params 已给则用；否则稳定 kebab-case。已有产物按 rule_id 增量。
|
||||
7. 按自评三维打分并填追问；输出 JSON。禁止夹带最终实例 records。
|
||||
|
||||
若程序已发出默认问题：用户首答在「用户.worker答复」。禁止重复同一开场。只追问会改变必要性、生命周期或 schema 的信息。
|
||||
|
||||
summary：
|
||||
- 建立规则：`生成规则 · {生成对象} · {仅动态|仅预生成|预生成并动态}`
|
||||
- 不建立规则：`生成规则 · {生成对象} · 无需专门规则`
|
||||
若程序已发默认问题：禁止重复开场；在首答上补洞。
|
||||
summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生成并动态}`；跳过 → `生成规则 · {对象} · 无需专门规则`。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 双门槛：必须“对游玩重要”且“基础上下文不足以稳定生成”同时成立。
|
||||
2. 反表格冲动：核心玩法是古董拍卖，不代表纯现代背景中的普通古董必须有专门规则；常识足够时直接生成。
|
||||
3. 一规则一对象族：怪物与装备若 schema、约束和用途不同，分次调用；不要做万能内容生成器。
|
||||
4. 格式也是规则：字段名、类型、枚举、上下界、嵌套结构与必填性都必须可校验。
|
||||
5. 生命周期先行：是否预生成、规则最终是否保留，必须在生成实例前决定。
|
||||
6. 规则服务差异：只固定影响体验和接口的字段；不要把所有可描写细节都结构化。
|
||||
7. 可追溯：每项关键约束应能指向世界基底、实现机制、体验禁忌或用户明确要求。
|
||||
8. 不混淆状态更新：好感度可在实例 schema 中规定为有界数字；何时增减、如何结算属于变量设计。
|
||||
1. 整条规则先问必要性：是否值得单独用「生成规则」承接？双门槛不成立则跳过，勿硬造表。
|
||||
2. 一调用一对象族；格式或用途不同则分次编排。
|
||||
3. 规则 = 描写/生成方法 + 产物格式；池是可选附属（可多池），不是必填第三设计。
|
||||
4. 属性逐个过筛：每个字段必须对本对象族有意义；禁塞通用名片字段，也禁漏掉玩法接口字段。
|
||||
5. 产物格式 = **单层 JSON**：一条产物是一层扁平对象；值仅为标量或「标量数组」。
|
||||
禁止嵌套 object、禁止 object 数组。此格式要对齐动态表格列、旁观者→主世界层生成、以及投影取字段。
|
||||
类型/必填/枚举/上下界必须可校验；禁止只给示例让下游猜类型。
|
||||
6. 池绑顶层字段名（如 `气质`、`攻击花招`）；一条规则可多池。池条目是该字段材料，不是整条 record。
|
||||
7. 生命周期先行；未定前不假装可执行「具体实例」。
|
||||
8. 不写变量更新公式、不写剧情推进、不填最终实例。
|
||||
```
|
||||
|
||||
## probe
|
||||
|
||||
```probe
|
||||
一轮 askUser 1～2 点；优先问会改变结论的分叉。禁止重问【本步参数】已钉的 target / rule_id。
|
||||
每轮 1～2 点。禁止重问 params 已钉的 target / rule_id。
|
||||
|
||||
必要性不明：如果不做专门规则、只让模型按世界设定直接生成，最可能出现的不可接受结果是什么？
|
||||
生命周期不明且 params 未给：这些实例需要每局变化、固定为开局设定，还是固定一批后仍要继续随机补充？
|
||||
枚举不明：这个字段只能从哪些世界内类别中选择？是否允许“其它”？
|
||||
数值不明：上下界分别代表什么，生成时是否允许取到边界？
|
||||
数量不明：需要固定数量，还是由场景/规模决定？允许范围是多少？
|
||||
|
||||
若用户的答案证明双门槛不成立，直接建议跳过，不再追问 schema。
|
||||
优先：整条规则是否必要；某字段该不该进表（冗余 vs 漏接口）；单层格式类型/枚举/边界；哪些字段要池。
|
||||
若双门槛不成立 → 建议跳过，停追问字段与格式。
|
||||
不追问：最终实例正文、变量增减公式、其它对象族、完整世界百科。
|
||||
```
|
||||
|
||||
## output
|
||||
|
||||
```output
|
||||
{
|
||||
"brief": "一句话：本轮判断与其服务的核心体验",
|
||||
"必要性判断": {
|
||||
"生成对象": "例：重要 NPC / 怪物 / 装备 / 任务 / 职业体系",
|
||||
"对游玩的重要性": "没有专门规则会具体损失什么",
|
||||
"基础生成的不足": "现有世界基底为何不足以稳定产出合格结果",
|
||||
"结论": "建立专门规则|无需专门规则"
|
||||
},
|
||||
"rules": [
|
||||
{
|
||||
"rule_id": "稳定的英文 kebab-case id",
|
||||
"对象": "该规则生成什么",
|
||||
"生命周期": "runtime_only|seed_only|seed_and_runtime",
|
||||
"上下文策略": {
|
||||
"预生成实例": true,
|
||||
"保留规则到游玩期": false,
|
||||
"保留实例到游玩期": true
|
||||
},
|
||||
"生成依据": ["引用的上游产物、世界事实或用户要求"],
|
||||
"数量": {
|
||||
"模式": "fixed|range|contextual",
|
||||
"值": 1,
|
||||
"最小": 1,
|
||||
"最大": 1,
|
||||
"决定规则": "contextual 时必填"
|
||||
},
|
||||
"输出合同": {
|
||||
"格式": "JSON",
|
||||
"顶层": "array",
|
||||
"schema": {
|
||||
"字段名": {
|
||||
"type": "string|number|integer|boolean|enum|array|object",
|
||||
"required": true,
|
||||
"description": "字段语义",
|
||||
"allowed_values": [
|
||||
{ "value": "枚举值", "meaning": "含义与适用边界" }
|
||||
],
|
||||
"minimum": 0,
|
||||
"maximum": 100,
|
||||
"items": { "type": "string" },
|
||||
"min_items": 1,
|
||||
"max_items": 3,
|
||||
"properties": {}
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "生成规则",
|
||||
"brief": "一句话：对象族 + 建立规则|无需专门规则 + 生命周期（若建立）+ 有池|无池",
|
||||
"mount": ["world-simulator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"本步参数": {
|
||||
"target": "与 params 一致",
|
||||
"rule_id": "已钉或本步拟定；跳过时可空字符串",
|
||||
"lifecycle_intent": "params 原值或空"
|
||||
},
|
||||
"必要性判断": {
|
||||
"生成对象": "本轮对象族",
|
||||
"对游玩的重要性": "没有专门规则会损失什么",
|
||||
"基础生成的不足": "现有上下文为何不够；若足够则写清",
|
||||
"结论": "建立专门规则|无需专门规则"
|
||||
},
|
||||
"rules": [
|
||||
{
|
||||
"rule_id": "英文 kebab-case",
|
||||
"对象": "该规则生成什么",
|
||||
"生命周期": "runtime_only|seed_only|seed_and_runtime",
|
||||
"上下文策略": {
|
||||
"预生成实例": true,
|
||||
"保留规则到游玩期": false,
|
||||
"保留实例到游玩期": true
|
||||
},
|
||||
"数量": {
|
||||
"模式": "fixed|range|contextual",
|
||||
"值": 1,
|
||||
"最小": 1,
|
||||
"最大": 1,
|
||||
"决定规则": "contextual 时必填，可较长"
|
||||
},
|
||||
"生成与描写": {
|
||||
"依据": ["可较长；引用上游产物或用户要求"],
|
||||
"方法": ["可较长：生成顺序、如何组装、描写口径、语气/切面、如何用池"],
|
||||
"硬约束": ["任何产物不得违反"],
|
||||
"字段间约束": ["例：阵营=A 时权限≥3"],
|
||||
"变化维度": ["允许随机或变化的部分；无则 []"],
|
||||
"禁止项": ["不得出现的组合或内容"],
|
||||
"去重规则": ["同批/跨批"],
|
||||
"校验": ["类型、枚举、边界、世界与体验一致性；以及是否按方法生成"]
|
||||
},
|
||||
"产物格式": {
|
||||
"格式": "单层JSON",
|
||||
"批量时": "array of flat object（每条记录单层）|单条则一个 flat object",
|
||||
"schema": {
|
||||
"字段名": {
|
||||
"type": "string|number|integer|boolean|enum|array",
|
||||
"required": true,
|
||||
"description": "语义 + 为何本对象族需要此字段；可较长",
|
||||
"allowed_values": [
|
||||
{ "value": "枚举值", "meaning": "含义" }
|
||||
],
|
||||
"minimum": 0,
|
||||
"maximum": 100,
|
||||
"items": { "type": "string|number|integer|boolean|enum" },
|
||||
"min_items": 1,
|
||||
"max_items": 3
|
||||
}
|
||||
},
|
||||
"示例形状": {
|
||||
"名称": "……",
|
||||
"等级": 3,
|
||||
"攻击骰": "2d6+2",
|
||||
"气质": "阴郁"
|
||||
}
|
||||
}
|
||||
},
|
||||
"池": [
|
||||
{
|
||||
"pool_id": "英文 kebab-case；同规则内唯一",
|
||||
"名称": "人话名",
|
||||
"绑定字段": "单层 schema 的顶层字段名，例：气质 / 攻击花招",
|
||||
"用途": "灵感组装|随机抽取|枚举生成|其它",
|
||||
"说明": "该字段如何用本池；与「生成与描写.方法」如何配合；可较长",
|
||||
"条目": [
|
||||
{
|
||||
"id": "可选稳定 id",
|
||||
"内容": "材料正文或短标签；结构随池自定义，但同池宜一致",
|
||||
"权重": 1,
|
||||
"标签": ["可选分类标签"]
|
||||
}
|
||||
],
|
||||
"抽取或组装规则": "可较长；无特殊则写「均匀随机」或「按方法写入绑定字段」"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"增量说明": "相对已有规则新增或修改了什么；首条可写「新建」"
|
||||
},
|
||||
"自评": {
|
||||
"维度": [
|
||||
{
|
||||
"名": "必要性",
|
||||
"分数": 0,
|
||||
"说明": "整条规则：是否有必要单独用「生成规则」承接该类内容；跳过时理由是否充分"
|
||||
},
|
||||
"生成步骤": ["按什么顺序决定字段，如何利用上游依据"],
|
||||
"硬约束": ["任何实例都不得违反的条件"],
|
||||
"字段间约束": ["例：阵营=A 时，权限等级不得低于 3"],
|
||||
"变化维度": ["允许随机或变化的部分；不需要随机则为空"],
|
||||
"禁止项": ["即使随机抽到也不得出现的组合或内容"],
|
||||
"去重规则": ["同批及跨批如何避免同质化或重复"],
|
||||
"校验": ["类型、枚举、边界、世界一致性与体验一致性检查"]
|
||||
}
|
||||
],
|
||||
"增量说明": "相对已有规则新增或修改了什么",
|
||||
"开放问题": ["仅保留会阻止规则执行的问题"]
|
||||
{
|
||||
"名": "属性妥当",
|
||||
"分数": 0,
|
||||
"说明": "逐字段：有无冗余（如女主规则的性别）或缺失（如 D&D 怪物缺等级/攻击骰）；跳过时写 N/A"
|
||||
},
|
||||
{
|
||||
"名": "格式准确",
|
||||
"分数": 0,
|
||||
"说明": "是否严格单层 JSON、类型/必填/枚举/边界可对接动态表格·旁观者生成·投影；跳过时写 N/A"
|
||||
}
|
||||
],
|
||||
"薄弱点": "一句话"
|
||||
},
|
||||
"追问": {
|
||||
"导语": "为钉准生成规则，还需确认：",
|
||||
"题目": [
|
||||
{
|
||||
"问": "…",
|
||||
"建议选项": ["选项A", "选项B", "其它（请写明）"],
|
||||
"示例": "可选"
|
||||
}
|
||||
]
|
||||
},
|
||||
"开放问题": []
|
||||
}
|
||||
|
||||
当结论为「无需专门规则」时，省略 `rules`，并在 `brief` 中说明应直接依赖哪些现有世界基底生成。
|
||||
schema 中只保留实际字段适用的类型属性：例如非枚举字段不写 `allowed_values`，非数字字段不写 `minimum/maximum`。
|
||||
```
|
||||
|
||||
硬规则（公共三段 + 本技正文）：
|
||||
1. 合法 JSON；必含 `schema` / `技能` / `brief` / `正文` / `自评` / `追问`（题目可 `[]`）。
|
||||
2. **公共三段**：正文＝规则主体；自评＝必要性/属性妥当/格式准确；追问＝导语+建议选项。
|
||||
3. **正文键固定**：本步参数、必要性判断、rules、增量说明。
|
||||
4. **每条 rule 必含**：生成与描写、产物格式；**池可空数组**。有池时 `绑定字段` 必须是单层 schema 的顶层键。
|
||||
5. **产物格式强制单层**：`schema` 的 `type` 不得为 `object`；`array` 的 `items` 不得为 object。禁止 `外貌.发色` 这类嵌套路径。
|
||||
6. 结论为「无需专门规则」时：`rules` 必须 `[]`。上下文策略布尔须与生命周期一致。
|
||||
7. 池条目≠最终实例；禁止输出具体实例 `records`、变量更新规则、执行单元列表。
|
||||
8. `mount` 默认主世界层；**禁止**写 `order`。summary 见 task。
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 重要性与基础生成不足是否分别举证，且两项都成立？
|
||||
- [ ] 是否因为“玩法重要”就误给常识足够的内容建表？
|
||||
- [ ] 生命周期是否在三种模式中明确唯一，布尔策略与之相符？
|
||||
- [ ] 每个字段是否有明确类型、必填性和语义？
|
||||
- [ ] enum 是否给全允许值与含义，数字是否给上下界，嵌套类型是否定义完整？
|
||||
- [ ] 是否写清字段间约束、禁止项、去重与校验？
|
||||
- [ ] 是否把实际实例、变量更新规则、剧情推进规则或 Worker 规格混入本步？
|
||||
- [ ] 是否只覆盖本轮对象族，并保留其它已有 rule_id？
|
||||
- [ ] 含 schema / brief / 正文 / 自评 / 追问？
|
||||
- [ ] 自评为必要性 / 属性妥当 / 格式准确？
|
||||
- [ ] 整条规则必要性有举证？不成立时 rules=[]？
|
||||
- [ ] 建立时：逐字段无冗余无漏接口？产物为单层 JSON 且类型可校验？
|
||||
- [ ] 池：无则 []；有则绑顶层字段、未写成最终实例表？
|
||||
- [ ] 未夹带最终实例、变量公式、其它对象族、百科？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
应建立：
|
||||
- 怪物是核心战斗资源，需要每局变化，且世界有独特生态与战斗接口；使用 `runtime_only`，固定属性 schema、生态枚举、数值边界与组合禁忌。
|
||||
- 单女主必须承载特定关系体验，直接写人设容易遗漏关键切面；使用 `seed_only`，下一步生成女主后丢弃规则。
|
||||
- 重要 NPC 需要开局已有一批，后续也会随地区开放继续出现；使用 `seed_and_runtime`。
|
||||
|
||||
不应建立：
|
||||
- 纯现代都市拍卖玩法中的普通古董；即使古董很重要，只要现实常识与世界基底足以直接生成，就不值得专门维护规则。
|
||||
- 只在背景里出现一次的路边摊菜单；即使模型可能写得普通，也不影响核心体验。
|
||||
好：
|
||||
- D&D 怪物：单层含 名称/等级/攻击骰/……；池可绑 `气质`；自评属性妥当高（未漏战斗接口）。
|
||||
- 女主规则：不设「性别」字段；关系切面进表；池可空。
|
||||
- 事件钩子：池绑顶层 `钩子`；方法写抽 1～2 条写入该字段。
|
||||
- 普通古董 → 无需专门规则（必要性维度说明跳过理由）。
|
||||
|
||||
坏：
|
||||
- 只写“人物要立体、装备要有趣”，没有 JSON schema 与可校验约束。
|
||||
- 枚举字段写“阵营：字符串”，却不生成允许的阵营项。
|
||||
- 好感度写“0～100”，又在本步编写每轮加减公式，侵入变量更新能力。
|
||||
- 产物写成 `{ "外貌": { "发色": "…" } }` → 非单层，前端表格/投影难对接。
|
||||
- 女主规则塞「性别」；或怪物规则只有「名字+性格」没有等级/攻击骰。
|
||||
- 把写好的 NPC 整份塞进池当最终实例。
|
||||
```
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# 实现机制
|
||||
|
||||
> 能力文档。程序只切割下方 **fence 块**（`meta` / `opening` / `task` / …）；`##` 标题仅供人读。
|
||||
> 写法说明：`docs/world-simulator-modules.md`；泛用规范：`docs/briefs/capability-authoring-brief.md`。
|
||||
> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 产物外壳对齐：`docs/context-fragment-design.md`；范例：`aesthetics-interaction`。
|
||||
|
||||
## meta
|
||||
|
||||
@@ -11,25 +11,22 @@ id: mechanism
|
||||
artifact: 设计.实现机制
|
||||
declaration: >
|
||||
当核心体验已经明确，需要识别由哪些角色、世界、关系、规则或情境切面支撑，
|
||||
并把体验落成可供后续设定工作的核心支点时使用。
|
||||
并把体验落成可供后续设定工作的核心支点时使用
|
||||
when: |
|
||||
已有「美学纲领与交互范式」或等价的体验声明，但还不能回答：
|
||||
“这个体验具体靠什么存在？”
|
||||
“拿掉哪些东西后，核心感觉就会明显变质？”
|
||||
“哪些设定切面必须被后续世界、角色与规则设计继承？”
|
||||
when_not: |
|
||||
核心体验尚未明确时，不用本能力代替「美学纲领与交互范式」决定想要什么体验。
|
||||
只需要补写完整世界、地点、组织、人物生平或具体事件时，交给「世界蓝图与人文地理」或「具体实例」。
|
||||
需要定义内容如何持续生成、演化或响应时，交给「生成规则」。
|
||||
需要定义变量、状态及更新条件时，交给「变量设计与更新规则」。
|
||||
需要决定文本如何叙述、取舍和呈现时，交给「叙事指南」。
|
||||
核心体验尚未明确 → 先「美学纲领与交互范式」。
|
||||
只需补舞台骨架/实例 → 「舞台骨架」或「具体实例」。
|
||||
需持续生成规则 → 「生成规则」；需真值门控 → 「变量设计与更新规则」。
|
||||
只需叙述呈现与推进口径 → 「叙事指南与故事推进」。
|
||||
boundary: |
|
||||
本能力：识别支撑核心体验的关键元素及其支撑切面，说明该切面是什么、如何支撑体验，以及缺失后会损失什么。
|
||||
美学纲领与交互范式：决定用户要什么体验、以什么交互关系接近该体验；本能力不重定体验目标，也不重定谁能做什么。
|
||||
世界蓝图与人文地理：把已确认的世界支点展开成完整环境、社会和人文结构；本能力只钉住其中承担体验功能的切面。
|
||||
具体实例：把机制实例化为具体人物、地点、组织或事件；本能力不补齐实例的全部设定。
|
||||
生成规则：定义内容在游玩中如何产生、变化和延续；本能力只指出需要被规则维护的支撑条件。
|
||||
叙事指南：决定如何写出这些体验；本能力不规定文风、镜头、节奏或信息揭示方式。
|
||||
本技能：识别支撑核心体验的关键切面（如何支撑 / 缺失后果）；产出 context-fragment.v1。
|
||||
美学纲领与交互范式：体验目标与轮转——本步不重定。
|
||||
舞台骨架 / 具体实例 / 生成规则 / 变量* / 叙事指南与故事推进：展开环境、实例、生成、真值、写法——本步只钉承重切面。
|
||||
feeds: gm
|
||||
```
|
||||
|
||||
## opening
|
||||
@@ -40,35 +37,28 @@ boundary: |
|
||||
## task
|
||||
|
||||
```task
|
||||
你正在执行剧本中的「实现机制」步骤。本步产物写入「设计.实现机制」。
|
||||
你正在执行「实现机制」。产物必须是 **context-fragment.v1** JSON，写入「设计.实现机制」。
|
||||
|
||||
这里的「机制」不是一套必须解释到底的科学原理，也不等于程序规则。它更接近科幻小说中可以直接成立的初始设定：后续内容都依赖它，但本步不必为它补写起源史或完整理论。
|
||||
这里的「机制」不是必须解释到底的科学原理，也不等于程序规则。它更接近可直接成立的初始设定：后续内容依赖它，本步不必补起源史或完整理论。
|
||||
|
||||
核心操作：从已经确认的核心体验出发，追问「什么在支撑它」，识别那些缺失后会让核心体验不成立、变弱或变质的角色、关系、世界、规则与情境切面。
|
||||
核心操作：从已确认的核心体验出发，追问「什么在支撑它」，识别缺失后会让体验不成立、变弱或变质的角色、关系、世界、规则与情境切面。
|
||||
|
||||
执行顺序：
|
||||
1. 读取依赖产物和用户表述，提取已经确认的核心体验。只做忠实复述，不重新设计美学纲领或交互范式。
|
||||
2. 在思考阶段判断本叙事空间继承了怎样的可能性范围，以此检查候选支撑点是否可能存在。这个「基准世界」只用于推理和校验，不写入产物。
|
||||
3. 分别检查体验如何产生、如何增强、如何维持，以及多个支撑点如何共同成立。
|
||||
4. 对每个候选点做移除检验：「如果删掉或替换这个切面，核心体验会损失什么？」
|
||||
5. 只保留有明确支撑关系的主要支点。常识、装饰、完整人物设定和应由后续能力展开的内容不纳入。
|
||||
6. 描述每个支点所属的元素、承担支撑作用的切面、切面的必要结构，以及它与核心体验的关系。
|
||||
7. 若支点之间存在重要的前提、对照、制衡、循环或共同支撑关系，再单独说明；关系简单时不要强行建图。
|
||||
8. 输出符合 output 契约的 JSON，供用户验收。
|
||||
1. 读依赖产物与用户表述，忠实提取核心体验；不重做美学/交互。
|
||||
2. 思考阶段判断基准世界可能性范围（只校验，不写入产物）。
|
||||
3. 检查体验如何产生、增强、维持，及多支点如何共同成立。
|
||||
4. 对每个候选做移除检验。
|
||||
5. 只保留有明确支撑关系的主要支点；常识、装饰、完整人物卡、后续技能展开对象不纳入。
|
||||
6. 写入正文：依据体验、支撑点（含切面形态）、支撑点关系、覆盖判断。
|
||||
7. 填自评与追问（薄弱点才问；题目可空数组）。
|
||||
8. 输出符合 output 契约的 JSON。
|
||||
|
||||
工作姿态——「识别已经在那里之物」：
|
||||
- 不凭空另造一套体验。
|
||||
- 不把无关设定做成菜单让用户挑选。
|
||||
- 不因为某类题材常见某套设定，就直接套用固定机制。
|
||||
- 可以把用户已经表达但尚未命名的支撑关系整理成清晰语言。
|
||||
- 可以提出基于现有体验的暂定识别，交给用户修正。
|
||||
- 如果两种不同理解会导向不同的核心支点，先用一个针对性问题辨明，不要同时堆出多套方案。
|
||||
工作姿态——「识别已经在那里之物」：不另造体验；不设设定菜单；不题材套件；可整理未命名关系；可暂定请用户修正；二选一支点先问清再写。
|
||||
|
||||
若依赖产物内部仍有含混或矛盾，不要越权重做上一步。只询问会改变本步支撑识别的关键差异；无法在本步解决的内容写入「开放问题」。
|
||||
依赖含混时不越权重做上一步。无法在本步解决的写入开放问题或追问。
|
||||
|
||||
若程序已发出默认问题：用户首答在「用户.worker答复」。禁止重复同一开场；在首答与依赖产物上补洞。
|
||||
|
||||
summary：`实现机制 · …`（点题主要支撑，非题材标签）。
|
||||
若程序已发默认问题：禁止重复开场；在首答与依赖上补洞。
|
||||
summary：`实现机制 · …`（点题主要支撑）。
|
||||
```
|
||||
|
||||
## principles
|
||||
@@ -170,141 +160,124 @@ summary：`实现机制 · …`（点题主要支撑，非题材标签）。
|
||||
## output
|
||||
|
||||
```output
|
||||
最终只输出一个合法 JSON 对象，不加代码块外说明，不使用注释，不夹带未定义的英文 id。
|
||||
|
||||
{
|
||||
"依据的核心体验": [
|
||||
"从依赖产物中忠实提取的体验锚点，不在这里重新设计"
|
||||
],
|
||||
"支撑点": [
|
||||
{
|
||||
"名称": "简短、稳定、对人可读的支撑点名称",
|
||||
"归属元素": "这个切面属于哪个角色、关系、群体、世界条件、规则或情境",
|
||||
"支撑切面": "只指出该元素中与核心体验有关的那个面向",
|
||||
"切面形态": {
|
||||
"结构": "一句话｜过程｜张力｜层次｜构成｜循环｜关系网",
|
||||
"概述": "用最短的充分描述说清这个切面是什么样的",
|
||||
"展开": [
|
||||
{
|
||||
"部分": "仅在确有内部结构时填写",
|
||||
"描述": "该部分在结构中的位置或作用"
|
||||
}
|
||||
]
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "实现机制",
|
||||
"brief": "一句话：主要靠什么撑住核心体验",
|
||||
"mount": ["world-simulator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"依据的核心体验": [
|
||||
"从依赖产物忠实提取的体验锚点；此处不重做美学纲领"
|
||||
],
|
||||
"支撑点": [
|
||||
{
|
||||
"名称": "简短、稳定、对人可读",
|
||||
"归属元素": "角色 / 关系 / 群体 / 世界条件 / 规则 / 情境…",
|
||||
"支撑切面": "该元素中真正相关的那一面",
|
||||
"切面形态": {
|
||||
"结构": "一句话|过程|张力|层次|构成|循环|关系网",
|
||||
"概述": "最短充分描述",
|
||||
"展开": [{ "部分": "仅必要时", "描述": "…" }]
|
||||
},
|
||||
"对应体验": ["直接服务的体验锚点"],
|
||||
"如何支撑": "条件 / 限制 / 对照 / 张力如何让体验成立",
|
||||
"缺失后果": "拿掉或改弱后具体损失什么（禁止只写「变差」）",
|
||||
"完备度": "…%"
|
||||
}
|
||||
],
|
||||
"支撑点关系": [
|
||||
{
|
||||
"涉及": ["支撑点名称"],
|
||||
"关系": "前提|共同支撑|反衬|制衡|递进|循环|…",
|
||||
"体验作用": "为何必须保留这段关系"
|
||||
}
|
||||
],
|
||||
"覆盖检验": {
|
||||
"主要支撑是否覆盖核心体验": "是|否|部分",
|
||||
"说明": "还有哪块体验没有支点、或支点过密",
|
||||
"宁少勿多说明": "为何到此停止"
|
||||
}
|
||||
},
|
||||
"自评": {
|
||||
"维度": [
|
||||
{
|
||||
"名": "覆盖度",
|
||||
"分数": 0,
|
||||
"说明": "能否完全覆盖用户已表达的规则/前提/硬条件（未漏掉用户点名的承重约束）"
|
||||
},
|
||||
"对应体验": [
|
||||
"该支撑点直接服务的体验锚点"
|
||||
],
|
||||
"如何支撑": "说明它通过什么条件、限制、对照或张力让体验成立",
|
||||
"缺失后果": "说明拿掉或改弱这个切面后，体验会失去什么"
|
||||
}
|
||||
],
|
||||
"支撑点关系": [
|
||||
{
|
||||
"涉及": ["支撑点名称"],
|
||||
"关系": "前提、共同支撑、反衬、制衡、递进、循环或其它自然语言关系",
|
||||
"体验作用": "这项关系为何需要被保留"
|
||||
}
|
||||
],
|
||||
"开放问题": [
|
||||
{
|
||||
"问题": "尚不能可靠确定、且会影响本步结论的问题",
|
||||
"影响": "不确定性会改变哪些支撑点或支撑关系",
|
||||
"当前暂定": "若已有最可能的理解，用可撤销的方式写明；没有则留空字符串"
|
||||
}
|
||||
]
|
||||
{
|
||||
"名": "充分度",
|
||||
"分数": 0,
|
||||
"说明": "支撑点合起来能否充分展示用户想要的核心体验（缺了是否撑不住感觉）"
|
||||
},
|
||||
{
|
||||
"名": "克制度",
|
||||
"分数": 0,
|
||||
"说明": "是否精确到支撑切面；无多余百科、人物卡、起源史或题材默认拓展"
|
||||
}
|
||||
],
|
||||
"薄弱点": "一句话"
|
||||
},
|
||||
"追问": {
|
||||
"导语": "为钉准支撑切面，还需确认：",
|
||||
"题目": [
|
||||
{
|
||||
"问": "移除检验或短场景落地题…",
|
||||
"建议选项": ["选项A（可带短场景）", "选项B", "其它（请写明）"],
|
||||
"示例": "可选示范句"
|
||||
}
|
||||
]
|
||||
},
|
||||
"开放问题": []
|
||||
}
|
||||
|
||||
填写规则：
|
||||
- 「依据的核心体验」只建可追溯关系，不得扩写成新的美学纲领。
|
||||
- 每个「支撑点」必须同时写清归属元素、支撑切面和支撑关系（如何支撑 + 缺失后果）。
|
||||
- 简单支点「结构」填「一句话」，「展开」填空数组。
|
||||
- 只有一句话不足以保留关键结构时才用其它结构类型。
|
||||
- 「缺失后果」不能只写「体验变差」，必须指出具体损失。
|
||||
- 「支撑点关系」只记对体验有实际影响的关系；没有则空数组。
|
||||
- 基准世界、推理过程、候选菜单和被淘汰支点不得写入产物。
|
||||
- 没有开放问题时填空数组，不要制造问题。
|
||||
- 不要输出完整角色卡、世界观百科、剧情大纲、叙事规则、变量表或演员规格。
|
||||
|
||||
本步完成的定义：
|
||||
- 核心体验的主要支撑已经被覆盖；
|
||||
- 每个支撑点都通过了「如何支撑／缺了会怎样」的检验；
|
||||
- 每个元素只保留了承担支撑作用的切面；
|
||||
- 所有支点在当前叙事空间中都可能成立，没有暗中引入未经确认的变造；
|
||||
- 剩余内容属于常识、具体实例或后续能力的展开范围。
|
||||
```
|
||||
|
||||
硬规则（公共三段 + 本技正文）：
|
||||
1. 合法 JSON；必含 `schema` / `技能` / `brief` / `正文` / `自评` / `追问`（题目可 `[]`）。
|
||||
2. **公共三段**：`正文`＝产物主体；`自评`＝打分；`追问`＝导语+建议选项。禁止整份散文壳。
|
||||
3. **本技正文**：`依据的核心体验` + `支撑点[]` + `支撑点关系[]` + `覆盖检验`。基准世界/推理过程/淘汰候选不得写入。
|
||||
4. 每个支撑点须有归属元素、支撑切面、如何支撑、缺失后果；简单支点结构＝「一句话」、展开＝`[]`。
|
||||
5. `mount` 默认主世界层（`world-simulator`）；**禁止**写 `order`。承重规则进 GM，不进转述全文。
|
||||
6. `稳变` 多为 `stable`（支点定稿后少改）；若用户明确机制会阶段性改换可标 `semi`。
|
||||
7. 不要输出角色卡、世界百科、剧情大纲、叙事文风、变量表、执行单元列表。
|
||||
8. summary：`实现机制 · {brief 缩略}`。
|
||||
|
||||
本步完成：主要支撑已覆盖；每点过「如何支撑／缺了怎样」；无暗中变造；剩余归常识或下游技能。
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 「依据的核心体验」是否忠实来自依赖产物，而非本步新设计？
|
||||
- [ ] 每个支撑点是否都有：归属元素、支撑切面、如何支撑、缺失后果？
|
||||
- [ ] 简单支点是否避免了不必要的「展开」？
|
||||
- [ ] 是否误写成设定菜单、完整人物卡、起源史或叙事文风指南？
|
||||
- [ ] 是否暗中引入了用户未确认的变造？
|
||||
- [ ] 宁少勿多：主要支撑已覆盖后是否停住？
|
||||
- [ ] 「支撑点关系」是否只含对体验有实际影响的项（或空数组）？
|
||||
- [ ] 开放问题是否都真正影响本步结论（无则空）？
|
||||
- [ ] 含 schema / brief / 正文 / 自评 / 追问？
|
||||
- [ ] 依据的核心体验忠实来自上游，非本步新设计？
|
||||
- [ ] 每个支撑点有归属元素、切面、如何支撑、缺失后果？
|
||||
- [ ] 自评含覆盖度 / 充分度 / 克制度？
|
||||
- [ ] 未写成设定菜单、人物卡、起源史、叙事指南与故事推进、order 表？
|
||||
- [ ] 宁少勿多；支撑点关系仅保留有体验作用的项（可空）？
|
||||
- [ ] 追问只打会改变支点的缺口，带建议选项？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
示例一：简单支撑点
|
||||
好：
|
||||
- brief「秘密靠丈夫认知过滤与证据逼近维持」；正文有依据体验 + 支撑点（认知切面过移除检验）+ 覆盖检验；自评三维（覆盖/充分/克制）；追问用短场景打待探。
|
||||
- 循环支点「力量与自我侵蚀同步」：展开诱因/收益/代价/反馈；与「身边人延迟识别」写进支撑点关系。
|
||||
- 整份落在 context-fragment.v1；支撑点切片示例：
|
||||
|
||||
核心体验：「秘密长期存在，但每次接近暴露时都令人紧张。」
|
||||
|
||||
合格：
|
||||
{
|
||||
"名称": "丈夫的认知过滤",
|
||||
"归属元素": "丈夫",
|
||||
"支撑切面": "面对威胁完美家庭信念的证据时，会无意识地优先采用无害解释",
|
||||
"切面形态": {
|
||||
"结构": "一句话",
|
||||
"概述": "他的信任不是单纯迟钝，而是一种维护既有信念的认知过滤。",
|
||||
"展开": []
|
||||
},
|
||||
"对应体验": ["秘密能够长期存在", "证据接近暴露时的紧张"],
|
||||
"如何支撑": "认知过滤让可疑证据能够出现而不立刻终结秘密，使暴露风险可以反复逼近。",
|
||||
"缺失后果": "如果他能稳定、直接地识别证据，秘密会迅速结束；如果完全没有证据出现，濒临暴露的紧张也会消失。"
|
||||
}
|
||||
只描述认知切面，不补职业、外貌、成长史。
|
||||
|
||||
示例二：具有内部结构的支撑点
|
||||
|
||||
核心体验：「每次获得力量都伴随自我逐渐陌生化的诱惑与恐惧。」
|
||||
|
||||
合格：
|
||||
{
|
||||
"名称": "力量与自我侵蚀的同步增长",
|
||||
"归属元素": "超常力量",
|
||||
"支撑切面": "力量的每次增长都会永久改变使用者的一项感知、欲望或判断方式",
|
||||
"切面形态": {
|
||||
"结构": "循环",
|
||||
"概述": "危机促使角色使用力量，力量解决危机并造成侵蚀，侵蚀又让下一次使用更容易发生。",
|
||||
"展开": [
|
||||
{ "部分": "诱因", "描述": "现实危机让使用力量成为最有效的解决方式。" },
|
||||
{ "部分": "收益", "描述": "力量立即兑现效果，使继续使用具有真实吸引力。" },
|
||||
{ "部分": "代价", "描述": "每次使用都会留下不可完全逆转的自我改变。" },
|
||||
{ "部分": "反馈", "描述": "改变后的角色更容易接受下一次使用，循环因此加深。" }
|
||||
]
|
||||
},
|
||||
"对应体验": ["力量带来的诱惑", "逐渐失去自我的恐惧"],
|
||||
"如何支撑": "收益与侵蚀来自同一次行动，角色不能只取其一，因此诱惑和恐惧能够持续共存。",
|
||||
"缺失后果": "如果侵蚀可以轻易撤销，恐惧会退化成短期成本；如果力量没有即时收益，诱惑则无法成立。"
|
||||
}
|
||||
不解释力量由谁创造、完整物理理论或全部侵蚀实例。
|
||||
|
||||
示例三：支撑点之间的关系
|
||||
|
||||
{
|
||||
"涉及": ["力量与自我侵蚀的同步增长", "身边人对变化的延迟识别"],
|
||||
"关系": "共同支撑并形成时间差",
|
||||
"体验作用": "侵蚀让角色真实改变，延迟识别则给变化留下累积空间；两者共同维持「尚能隐藏但终将无法隐藏」的过程感。"
|
||||
"支撑切面": "面对威胁完美家庭信念的证据时，优先采用无害解释",
|
||||
"切面形态": { "结构": "一句话", "概述": "维护既有信念的认知过滤，而非单纯迟钝。", "展开": [] },
|
||||
"对应体验": ["秘密长期存在", "濒临暴露的紧张"],
|
||||
"如何支撑": "可疑证据可出现而不立刻终结秘密。",
|
||||
"缺失后果": "若能直接识别证据则秘密速终；若永无证据则紧张消失。",
|
||||
"完备度": "90%"
|
||||
}
|
||||
|
||||
不合格：
|
||||
- 「可以选择诅咒、寄生物、人格分裂、外星科技或邪神污染…」→ 脱离体验的设定菜单。
|
||||
- 「丈夫四十二岁，是律师，外表温和，童年…」→ 把认知切面扩成完整人物设定。
|
||||
- 「为了营造压抑美感，叙述应采用近距离视角…」→ 叙事呈现，不是支撑设定。
|
||||
- 「这种力量源于三千年前的实验事故…」→ 为可直接成立的初始设定补不必要起源史。
|
||||
坏：
|
||||
- 设定菜单：「可选诅咒/寄生物/邪神…」
|
||||
- 人物卡膨胀；叙事文风；无必要起源史
|
||||
- 只有散文支点、无 schema / 自评 / 追问
|
||||
```
|
||||
|
||||
@@ -1,109 +1,279 @@
|
||||
# 叙事指南
|
||||
# 叙事指南与故事推进
|
||||
|
||||
> 能力文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 写法说明：`docs/world-simulator-modules.md`；范例：`aesthetics-interaction`。
|
||||
> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 产物外壳：`docs/context-fragment-design.md`；对照：`aesthetics-interaction`（感觉）↔ 本技（怎么写 / 往哪推）。
|
||||
> 默认服务**叙事转述**；「推进与决策」同时给主世界层用。
|
||||
> 旧称：叙事指南（流程 name / artifact 兼容见 creation-flow）。
|
||||
|
||||
## meta
|
||||
|
||||
```meta
|
||||
name: 叙事指南
|
||||
name: 叙事指南与故事推进
|
||||
id: narrative
|
||||
artifact: 设计.叙事指南
|
||||
artifact: 设计.叙事指南与故事推进
|
||||
declaration: >
|
||||
世界/助手态度与体验边界（不等于文风；契约已写清的态度勿重复问卷）
|
||||
钉转述「怎么写」与主世界「怎么推」：叙事纲领、遣词造句与笔墨焦点、绝对禁忌/不偏好、
|
||||
示范与情境备用，以及推进/决策（可含变量门控）；不重做美学感觉问卷
|
||||
when: |
|
||||
需要单独钉清「世界/助手如何说话、如何取舍信息、如何对待用户情绪」时；
|
||||
或美学纲领与交互范式里态度仍过粗、下游演员会飘时。
|
||||
已有（或等价）美学纲领，需要把「要的感觉」落成可执行的写法与推进时；
|
||||
或转述缺遣词/示范/笔墨重心（如男频写女、女频写男、末日绝望 vs 日常小确幸）；
|
||||
或缺少情境切换语料、或主世界层缺推进框架（可含好感/日期/冷却钩子）时。
|
||||
when_not: |
|
||||
美学纲领与交互范式已写清态度/禁忌，用户未要求加细 → 不要重复问卷。
|
||||
用户只要文风辞藻样本、不要态度边界 → 可放入常驻上下文短句，不必强开本步。
|
||||
排版/回复块结构 → 设计回复格式。
|
||||
美学未钉、还在谈「要什么感觉」→ 先「美学纲领与交互范式」。
|
||||
契约已细到可直接转述、用户明确不要本步 → 可不排。
|
||||
用户可见块序/监控栏版式 → 「正文组成」/「设计监控栏」。
|
||||
事件池 schema / 预生成 → 「生成规则」/「具体实例」。
|
||||
真值与 side_effects → 「变量设计与更新规则」。
|
||||
boundary: |
|
||||
本能力：态度、信息取舍、体验边界、焦点偏好（给转述/写手演员的稳定口径）。
|
||||
不等于文风词典：少堆形容词；多写「遇到 X 时怎么处理」。
|
||||
美学纲领与交互范式：站位、呈现、核心体验、轮转——已写清的勿重问。
|
||||
生成规则：可执行推进规则；本步不定章结构算法。
|
||||
设计回复格式：块结构与拼接顺序。
|
||||
本技能：叙事宪法 + 遣词造句/笔墨焦点 + 禁忌与不偏好 + 示范/备用 + 推进与决策 + 内容表达；
|
||||
产出 context-fragment.v1。美学写「感觉」，本步写「花笔墨在哪、怎么遣词、故事怎么推」。
|
||||
美学纲领与交互范式：体验与轮转——已写清的感觉勿重问。
|
||||
生成规则 / 变量*：合同与副作用规格——本步只给推进钩子与写法，不建表。
|
||||
设计回复格式：块结构——本步不定。
|
||||
feeds: narrator
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
用几句话说明「系统说话时该像什么人」（想到什么写什么）：
|
||||
美学纲领里的「感觉」已有方向时，请谈叙事「怎么写、往哪推」（想到什么写什么）：
|
||||
|
||||
1. 态度：冷静如实 / 偏袒主角 / 狠心推进 / 温柔留余地 / 其它？
|
||||
2. 信息：用户不知道的世界内情，默认藏多少？可以剧透结构吗？
|
||||
3. 边界：什么绝对不写或不怎么写？（已有禁忌可写「同体验契约」）
|
||||
1. 正文应该像什么？遣词大概什么味道？
|
||||
例：第三人称网文、偏爽文、简明带张力；句短、少文艺腔……
|
||||
|
||||
若上游契约已够用，可回复「按美学纲领，只补……」。
|
||||
2. 笔墨该花在谁/什么上？有什么绝对不能写、或不想多写？
|
||||
例：男频爱情 → 多写女角色美丽与反应；女频相反；
|
||||
末日 → 生存绝望，禁止轻松解决一切；日常 → 小确幸，禁止突然飞来横祸……
|
||||
|
||||
3. 故事怎么往前推？要不要跟变量挂钩？有没有情境要换一套语料？
|
||||
例：好感够了才插入倒追；NSFW 改官能笔法；丛林三两句带过 vs 荒野逐步细写……
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
你正在执行剧本中的「叙事指南」步骤。产物写入「设计.叙事指南」。
|
||||
你正在执行「叙事指南与故事推进」。产物必须是 **context-fragment.v1** JSON，写入「设计.叙事指南与故事推进」。
|
||||
|
||||
先读「设计.美学纲领与交互范式」：已写清的态度/禁忌直接继承，只补缺口。
|
||||
美学钉感觉；本步钉：**怎么遣词造句、笔墨花在哪里、绝对禁忌与不偏好、示范长什么样、故事如何推进**。
|
||||
|
||||
执行顺序：
|
||||
1. 复述已确认的体验内核与呈现；不重定站位。
|
||||
2. 钉态度、信息策略、焦点、边界；写成下游可挂载的短规则，而非散文赏析。
|
||||
3. 与体验禁忌冲突时以体验禁忌为准，并在产物里点明。
|
||||
4. 输出符合 output 的 JSON。
|
||||
1. 读美学纲领（及可选机制/舞台）：继承体验内核与禁忌；改写成创作导向句，不重复问卷。
|
||||
2. 写「叙事纲领」：核心定位 + 叙事使命 + 叙事追求（浓缩）。
|
||||
3. 写「风格与遣词」：叙述者人格、整体基调、**遣词造句**（用什么词/句式/节奏、避免什么）、修辞；附至少 1 段示范。
|
||||
4. 写「笔墨焦点」：观众/代入取向下应详写谁、略写谁（例：男用户向爱情线详女角色；女用户向详男角色）；与体验类型对齐的场景重心。
|
||||
5. 写「禁忌与不偏好」：绝对禁忌（硬禁）与不偏好（能避则避、出现须极克制）——含题材气质禁令（末日禁轻松通关、日常禁无端灾难等）。
|
||||
6. 需要时写「情境备用」多套语料；写「推进与决策」（驱动力、速度/详略、成败、困境、节奏、可选变量钩子）。
|
||||
7. 写「内容与表达」：视角执行、场景详略、信息组织。
|
||||
8. 自评 + 追问；输出 JSON。
|
||||
|
||||
若程序已发出默认问题：禁止重复同一开场。
|
||||
|
||||
summary：`叙事指南 · …`（点题态度，非「文学性」空话）。
|
||||
mount：默认挂叙事转述 + 主世界层。禁止写最终 `order`。
|
||||
summary：`叙事指南与故事推进 · …`（点题体裁/笔墨重心 + 推进有无）。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 态度是行为规则，不是形容词堆砌。
|
||||
2. 不重复问卷：契约已有的字段引用即可。
|
||||
3. 服务体验：狠心或温柔都必须能指向核心感受。
|
||||
4. 写手模式：可写「助手如何给大纲意见 / 如何改稿语气」，仍避免空泛文风课。
|
||||
5. 缩减：三条管用口径优于一页风格指南。
|
||||
1. 感觉 vs 做法
|
||||
美学：装逼的爽感。本步：第三人称爽文、遣词短促有力、笔墨落在哪、示范段落、推进是否心想事成……
|
||||
禁止复读体验口号。
|
||||
|
||||
2. 遣词造句必须可执行
|
||||
不只写「要有张力」：写句长、用词场、可否网感/文言、感官词偏好、情绪直给 vs show。
|
||||
每条倾向尽量带「做法 → 目的」。
|
||||
|
||||
3. 笔墨焦点跟体验与观众站位走
|
||||
爱情线：男用户向通常详写女角色外貌/气质/反应；女用户向详写男角色——写清本局取向，勿默认「男女均衡」。
|
||||
末日天灾：详写匮乏、威胁、代价与绝望感；禁止轻松解决一切、轻松段子冲淡生存压。
|
||||
日常小确幸：详写细微暖意与节奏；禁止无铺垫的突发致命危险或崩坏（除非用户明确要）。
|
||||
其它类型同理：问「读者眼神会停在哪」。
|
||||
|
||||
4. 绝对禁忌 ≠ 不偏好
|
||||
绝对禁忌：出现即破坏体验，硬禁。
|
||||
不偏好：能避则避；偶尔出现须克制、不抢主戏。
|
||||
两者都要写，并说明与美学的关系。
|
||||
|
||||
5. 示范与情境备用
|
||||
至少一段默认示范；NSFW/战斗/日常等用「情境备用」换遣词与禁忌增量。
|
||||
|
||||
6. 推进与写法同框，推进可轻可无
|
||||
变量门控只写钩子；表规格交给变量/生成规则。
|
||||
|
||||
7. 继承优先；与美学硬禁忌冲突时以体验禁忌为准并点明。
|
||||
```
|
||||
|
||||
## probe
|
||||
|
||||
```probe
|
||||
一轮 1～2 点。
|
||||
每轮 1～2 点。已在美学写清的感觉禁止重问。
|
||||
|
||||
缺态度：失败时系统更像「如实报损」还是「帮用户找补救」？
|
||||
缺信息：用户是否允许「角色知道但用户暂不知」的悬置？
|
||||
与禁忌冲突：用户既要无虐又要残酷真实——以哪边为先？
|
||||
优先：体裁与遣词味道；笔墨焦点（详谁/略谁）；绝对禁忌 vs 不偏好；末日/日常等气质禁令；推进门控与详略成败；是否要情境备用。
|
||||
不追问：回复块排版、事件池 schema、side_effects 细节、舞台百科。
|
||||
```
|
||||
|
||||
## output
|
||||
|
||||
```output
|
||||
{
|
||||
"brief": "一句话：叙事口径服务什么体验",
|
||||
"态度": "…",
|
||||
"信息策略": "…",
|
||||
"焦点": "…",
|
||||
"边界": ["…"],
|
||||
"遇到冲突时": "优先保全…",
|
||||
"继承自体验契约": ["已直接采用的字段"],
|
||||
"开放问题": ["…"]
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "叙事指南与故事推进",
|
||||
"brief": "一句话：体裁遣词 + 笔墨重心 + 推进有无",
|
||||
"mount": ["narrator", "world-simulator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"依据的体验": [
|
||||
"从美学纲领忠实转化；可点名禁忌继承"
|
||||
],
|
||||
"叙事纲领": {
|
||||
"核心定位": "一句话：叙事本质/灵魂",
|
||||
"叙事使命": "1～2 句：要让用户体验到什么",
|
||||
"叙事追求": [
|
||||
"关键词 - 简短解释"
|
||||
]
|
||||
},
|
||||
"风格与遣词": {
|
||||
"叙述者人格": "形象化一句话：这个声音是谁",
|
||||
"整体基调": "温度/节奏/质感/距离的整体描述",
|
||||
"遣词造句": [
|
||||
"原则 - 具体做法（用词/句式/段落节奏） → 目的"
|
||||
],
|
||||
"核心修辞": [
|
||||
"修辞名 - 示例 → 作用"
|
||||
],
|
||||
"示范": [
|
||||
{
|
||||
"情境": "常态/开场/高潮…",
|
||||
"段落": "一段可朗读的示范（体现遣词与张力）"
|
||||
}
|
||||
]
|
||||
},
|
||||
"笔墨焦点": {
|
||||
"观众与代入取向": "男用户向|女用户向|中性/双关|未定；可附一句站位",
|
||||
"详写优先": [
|
||||
"应花笔墨的对象或维度（例：女角色外貌与反应；生存压迫与资源匮乏；微表情与小确幸）"
|
||||
],
|
||||
"可略写": [
|
||||
"可三两句带过或背景化的部分"
|
||||
],
|
||||
"说明": "与体验类型如何对齐（男频/女频/末日/日常…）"
|
||||
},
|
||||
"禁忌与不偏好": {
|
||||
"绝对禁忌": [
|
||||
"禁止… → 原因（硬禁；破坏体验）"
|
||||
],
|
||||
"不偏好": [
|
||||
"尽量避免… → 若出现则如何克制"
|
||||
]
|
||||
},
|
||||
"情境备用": [
|
||||
{
|
||||
"触发": "例：NSFW / 战斗 / 日常过场",
|
||||
"改用风格": "例：官能小说笔法",
|
||||
"遣词与禁忌增量": ["相对默认改什么"],
|
||||
"笔墨增量": "该情境笔墨是否偏移；无则空字符串",
|
||||
"示范": "可选示范段"
|
||||
}
|
||||
],
|
||||
"推进与决策": {
|
||||
"有无专门推进": "有|无（沿用常识与体验即可）",
|
||||
"驱动力来源": "故事主要由什么推动",
|
||||
"叙事速度与详略": "何种过程可带过，何种必须细写",
|
||||
"成败与难度": "心想事成 / 允许受挫 / 其它；与体验关系",
|
||||
"变量门控钩子": [
|
||||
{
|
||||
"变量或信号": "好感|日期|冷却|进度|seed|其它",
|
||||
"条件意图": "例：好感≥某档；冷却归零；纯随机",
|
||||
"插入或推进什么": "例：倒追线；诡异遭遇",
|
||||
"实现指向": "投影/动态表|生成规则事件池|主世界层临场判断",
|
||||
"说明": "可较长；本步不写 side_effects"
|
||||
}
|
||||
],
|
||||
"困境应对": [
|
||||
"困境简述 → 应对方向(关键词)"
|
||||
],
|
||||
"节奏意识": [
|
||||
"情境 → 应对"
|
||||
]
|
||||
},
|
||||
"内容与表达": {
|
||||
"视角执行": {
|
||||
"主次原则": "主信息源占比/辅助源条件",
|
||||
"切换时机": ["情境 → 应对"],
|
||||
"切换方式": "如何平滑切换"
|
||||
},
|
||||
"场景详略映射": [
|
||||
"场景类型: 聚焦… | 详写条件 → 原因（与笔墨焦点对齐）"
|
||||
],
|
||||
"信息组织模式": [
|
||||
"模式名: 结构 → 适用情境"
|
||||
]
|
||||
}
|
||||
},
|
||||
"自评": {
|
||||
"维度": [
|
||||
{
|
||||
"名": "写法可执行",
|
||||
"分数": 0,
|
||||
"说明": "遣词+笔墨焦点+禁忌/不偏好+示范是否够转述落地"
|
||||
},
|
||||
{
|
||||
"名": "推进可执行",
|
||||
"分数": 0,
|
||||
"说明": "主世界层是否知道如何推进；变量钩子清楚或明确无需"
|
||||
},
|
||||
{
|
||||
"名": "与美学对齐",
|
||||
"分数": 0,
|
||||
"说明": "是否把感觉落成做法；笔墨与禁忌服务体验而非跑偏"
|
||||
}
|
||||
],
|
||||
"薄弱点": "一句话"
|
||||
},
|
||||
"追问": {
|
||||
"导语": "为钉准写法与推进，还需确认：",
|
||||
"题目": [
|
||||
{
|
||||
"问": "…",
|
||||
"建议选项": ["选项A", "选项B", "其它（请写明）"],
|
||||
"示例": "可选短示范句"
|
||||
}
|
||||
]
|
||||
},
|
||||
"开放问题": []
|
||||
}
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. 合法 JSON；含 `schema` / `技能` / `brief` / `正文` / `自评` / `追问`。
|
||||
2. 正文键固定：依据的体验、叙事纲领、**风格与遣词**、**笔墨焦点**、**禁忌与不偏好**、情境备用、推进与决策、内容与表达。
|
||||
3. `风格与遣词.示范` 至少 1 条；`遣词造句` 不得空数组（建立本步时）。`情境备用` 可 `[]`。
|
||||
4. `绝对禁忌` 与 `不偏好` 均须出现（可短，但不可整段省略）；须能对上体验类型（如末日/日常/频向）。
|
||||
5. 自评：写法可执行 / 推进可执行 / 与美学对齐。禁止 `order`。
|
||||
6. 不要输出事件池 schema、side_effects、回复块结构、执行单元列表。
|
||||
7. summary：`叙事指南与故事推进 · {brief 缩略}`。
|
||||
8. 兼容：若下游仍读旧 tag「设计.叙事指南」，细化终稿可将本产物同步或改挂新 tag（本步只写新 artifact）。
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 与美学纲领与交互范式不重复盘问、不矛盾？
|
||||
- [ ] 是否可被演员当规则执行（非纯文风赏析）？
|
||||
- [ ] 是否误写成回复块结构或生成规则？
|
||||
- [ ] 含 schema / brief / 正文 / 自评 / 追问？
|
||||
- [ ] 自评为写法可执行 / 推进可执行 / 与美学对齐？
|
||||
- [ ] 遣词造句具体？有示范？笔墨焦点写清详谁略谁？
|
||||
- [ ] 绝对禁忌与不偏好都有，且贴合体裁（男频/女频/末日/日常等）？
|
||||
- [ ] 推进钩子清楚或明确无需？未越权写生成规则/变量规格？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：
|
||||
- 「如实推进代价；不替用户道德排雷；悬念可藏事实不可藏规则。」
|
||||
- 男频爱情爽文：遣词网文短句；笔墨详女角色美丽与心动反应；略写男主外貌流水账；禁忌：禁止把女主写成无魅力背景板。
|
||||
- 女频：笔墨详男角色气质/行动力；不偏好过度描写女主外貌抢戏。
|
||||
- 末日：详写寒冷/饥饿/信任崩裂；绝对禁忌「轻松解决危机」；推进允许失败与代价。
|
||||
- 日常小确幸：详写琐碎暖意；绝对禁忌无铺垫的突发灾难；推进忌强行高潮。
|
||||
- NSFW 备用：触发后改官能遣词；笔墨可临时偏移身体感官。
|
||||
|
||||
坏：
|
||||
- 「要有诗意、电影感、高级感……」无可执行口径
|
||||
- 只写「要有沉浸感」无遣词、无笔墨焦点。
|
||||
- 默认「男女都要均衡描写」却无视本局男/女用户向。
|
||||
- 末日指南里鼓励轻松打闹通关。
|
||||
```
|
||||
|
||||
173
skills/dialogue/world-simulator/modules/opening-setup/prompt.md
Normal file
173
skills/dialogue/world-simulator/modules/opening-setup/prompt.md
Normal file
@@ -0,0 +1,173 @@
|
||||
# 开场白与开场变量
|
||||
|
||||
> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 产物外壳：`docs/context-fragment-design.md`。
|
||||
> 创作偏晚：规格与呈现契约已齐，写「迈进世界的第一拍」并钉开场真值。
|
||||
> 磁盘 worker `opening-generator` 可执行/落库本产物到 `输出.开场白` 与 `运行.初始变量`。
|
||||
|
||||
## meta
|
||||
|
||||
```meta
|
||||
name: 开场白与开场变量
|
||||
id: opening-setup
|
||||
artifact: 设计.开场白与开场变量
|
||||
declaration: >
|
||||
写出遵循正文组成/叙事/监控栏等契约的开场一小段，并钉与之同真相的开场变量初值；
|
||||
开场为主、填表为辅
|
||||
when: |
|
||||
体验、舞台、叙事、变量（若有）、正文组成等已大致可引用，
|
||||
需要可开玩的第一段剧情与初始真值快照时；通常在细化终稿前后、进游玩前。
|
||||
when_not: |
|
||||
体验/呈现仍混沌 → 先美学与正文组成等。
|
||||
只要改文风不要开场 → 叙事指南。
|
||||
只要改真值规则不要开场文 → 变量设计。
|
||||
boundary: |
|
||||
本技能：开场正文（按正文组成块序拼出用户可见第一屏）+ 开场变量初值 + 可选监控栏初值示意。
|
||||
必须遵守已验收的叙事指南、正文组成、监控栏、变量设计；不重做这些契约。
|
||||
具体实例：开场可引用已有实例名片，不在本步新造百科。
|
||||
opening-generator：可将本产物写入 输出.开场白 / 运行.初始变量 / 变量.当前。
|
||||
feeds: narrator
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
设定已齐时，用几句话定开场第一拍：
|
||||
|
||||
1. 玩家睁眼/进场时在哪、正发生什么？
|
||||
2. 开场结束时，TA 显然可以做什么？
|
||||
3. 此时各真值大概是多少？（能推断的直接说；推不出的标「要问」）
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
你正在执行「开场白与开场变量」。产物必须是 **context-fragment.v1** JSON，写入「设计.开场白与开场变量」。
|
||||
|
||||
主产物是**开场一小段剧情**（用户第一屏），不是填表工具。
|
||||
必须遵循：叙事指南与故事推进、正文组成（可见块序、隐藏段若开场就要写）、监控栏字段（若启用）、变量真值名单。
|
||||
|
||||
执行顺序：
|
||||
1. 读依赖：worker 集/美学/叙事/正文组成/监控栏/变量设计/舞台与实例。
|
||||
2. 按正文组成的可见块写出开场各块内容（至少正文块）；隐藏段仅当开场即需声明初值变更时使用（通常初值走「开场变量」字段，隐藏段可空）。
|
||||
3. 钉开场变量：与开场事实同一真相；能从设定推断的填上；冲突则以开场叙述为准并改表。
|
||||
4. 若有监控栏：给出开场时监控栏展示快照（短）。
|
||||
5. 自评 + 追问；输出 JSON。
|
||||
|
||||
禁止：先问卷填表再糊开场；禁止开场与初值打架；禁止重写 Worker 集。
|
||||
|
||||
summary：`开场白与开场变量 · …`（点题场景）。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 开场为主，表为配套：表服务「这一刻世界是什么样」。
|
||||
2. 遵守版式：用户看见的结构按正文组成；文风按叙事指南；笔墨焦点同样适用。
|
||||
3. 同真相：开场写身无分文 → 资产真值不得很富。
|
||||
4. 可行动：第一拍结束要有「接下来能做什么」的空间，非说明书。
|
||||
5. 短：可读完、愿意进游玩；不是第一章全文。
|
||||
6. 隐藏真值/未解锁映射档不得剧透进可见开场。
|
||||
```
|
||||
|
||||
## probe
|
||||
|
||||
```probe
|
||||
开场地点/冲突不清；某真值开场值推不出；版式块是否都要在开场出现（有的块首轮可空）。一次 1～2 点。
|
||||
```
|
||||
|
||||
## output
|
||||
|
||||
```output
|
||||
{
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "开场白与开场变量",
|
||||
"brief": "一句话：开场场景 + 关键初值",
|
||||
"mount": ["narrator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"依据契约": [
|
||||
"正文组成 / 叙事指南 / 监控栏 / 变量设计 等已遵循要点"
|
||||
],
|
||||
"开场可见块": [
|
||||
{
|
||||
"块id": "与正文组成.visible块一致",
|
||||
"内容": "该块开场文本；可空块写空字符串并说明为何首轮空"
|
||||
}
|
||||
],
|
||||
"开场白全文": "按块序拼好的用户可见开场（主阅读件）",
|
||||
"开场变量": [
|
||||
{
|
||||
"名": "与变量设计真值名一致",
|
||||
"值": "初值",
|
||||
"依据": "开场事实/设定推断"
|
||||
}
|
||||
],
|
||||
"监控栏开场快照": [
|
||||
{
|
||||
"名": "监控栏字段名",
|
||||
"显示": "短展示"
|
||||
}
|
||||
],
|
||||
"隐藏段开场": "通常空；若有定界内容则写出",
|
||||
"落库提示": {
|
||||
"输出.开场白": "开场白全文",
|
||||
"运行.初始变量": "开场变量 → 表格式",
|
||||
"变量.当前": "与初始变量对齐"
|
||||
},
|
||||
"用户可行动空间": "开场结束后玩家显然能尝试什么"
|
||||
},
|
||||
"自评": {
|
||||
"维度": [
|
||||
{
|
||||
"名": "契约符合",
|
||||
"分数": 0,
|
||||
"说明": "是否遵循正文组成/叙事/监控栏"
|
||||
},
|
||||
{
|
||||
"名": "同真相",
|
||||
"分数": 0,
|
||||
"说明": "开场叙述与开场变量是否一致"
|
||||
},
|
||||
{
|
||||
"名": "可开玩",
|
||||
"分数": 0,
|
||||
"说明": "是否短、可感、有下一步行动空间"
|
||||
}
|
||||
],
|
||||
"薄弱点": "一句话"
|
||||
},
|
||||
"追问": {
|
||||
"导语": "为钉准开场，还需确认：",
|
||||
"题目": [
|
||||
{
|
||||
"问": "…",
|
||||
"建议选项": ["选项A", "选项B", "其它（请写明）"],
|
||||
"示例": "可选"
|
||||
}
|
||||
]
|
||||
},
|
||||
"开放问题": []
|
||||
}
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. context-fragment.v1；自评契约符合/同真相/可开玩。
|
||||
2. `开场白全文` 与 `开场变量` 必填；监控栏快照无监控栏则为 `[]`。
|
||||
3. 不输出完整 worker 集；不发明新真值名（须来自变量设计，若无变量设计则可极少数字段并标明临时）。
|
||||
4. summary：`开场白与开场变量 · {brief 缩略}`。
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 开场遵循正文组成块序与叙事口径？
|
||||
- [ ] 变量与开场同真相？可行动空间清楚？
|
||||
- [ ] 未剧透隐藏档？未写成第一章全文？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：末日醒来缺水——开场正文写干渴与门外声响；口粮=1、威胁=邻层异响；监控栏短显示；无姓名性别栏。
|
||||
坏：先填完 20 个表字段再写两句「你醒了」；开场说破产表里却有百万资产。
|
||||
```
|
||||
@@ -1,8 +1,8 @@
|
||||
# 细化终稿
|
||||
|
||||
> 能力文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 写法说明：`docs/world-simulator-modules.md`；规格字段见 `docs/skill-design-guide.md`。
|
||||
> 本步产物 tag 为 **`设计.worker集`**（可进游玩的实例规格）。
|
||||
> 产物 tag：**`设计.worker集`**（JSON）。
|
||||
> **禁止自由发明 workers。** 按上游「游玩拓扑」的 `play_slots` / `writing_slots` 展开。
|
||||
|
||||
## meta
|
||||
|
||||
@@ -11,20 +11,22 @@ name: 细化终稿
|
||||
id: refine
|
||||
artifact: 设计.worker集
|
||||
declaration: >
|
||||
钉死关键前提、表与副作用，收成可进游玩的规格
|
||||
按已勾选固定槽与「上下文投影排序」表收成可进游玩的规格：
|
||||
play_slots、投影插入序、常驻上下文、表与副作用；不发明新执行单元
|
||||
when: |
|
||||
前面能力已大致谈清（至少有体验契约，且演员职责可说清），
|
||||
需要收成可进游玩的「设计.worker集」JSON 时；
|
||||
编排应将本局流程 status 导向 closed。
|
||||
前面技能已大致谈清（至少有体验契约；槽已勾选或可按默认；
|
||||
若已有多块上下文则宜先有投影排序表），需要输出「设计.worker集」JSON 时；
|
||||
编排应将流程 status 导向 closed。
|
||||
when_not: |
|
||||
体验站位未定、或关键演员仍完全空白时，不要用本步代替上游。
|
||||
用户只想改某一个演员细节 → 可先 Worker 规格，再本步合并。
|
||||
体验站位未定 → 先上游。
|
||||
拓扑未勾选且用户拒绝默认槽 → 先「游玩拓扑」。
|
||||
上下文块已多且稳/变未排序 → 先「上下文投影排序」。
|
||||
boundary: |
|
||||
本能力：合并上游产物，钉死不能瞎发挥的前提，输出完整「设计.worker集」JSON（含 interaction、workers、resident_context、tables 等）。
|
||||
进 play 由用户手动决定；本步不自动切游玩。
|
||||
Worker 规格：分步钉演员；本步负责合并与终稿一致性。
|
||||
美学纲领与交互范式等：只读引用，不重做问卷（矛盾处才问）。
|
||||
开局·开场白：可选后续步骤，本步可用 design_end.opening 标记是否建议。
|
||||
本能力：合并上游 → 完整运行规格 JSON（interaction、play_slots、context_order/inserts、
|
||||
workers 由槽展开、resident_context、tables）。
|
||||
游玩拓扑：槽位权威；上下文投影排序：插入序与投影位权威；本步不新增白名单外的 ref。
|
||||
变量设计：side_effects / 真值吸入 tables；不创建 variable-update 执行单元。
|
||||
进 play 由用户手动决定。
|
||||
```
|
||||
|
||||
## opening
|
||||
@@ -32,9 +34,10 @@ boundary: |
|
||||
```opening
|
||||
准备收成可进游玩的规格。请确认或补充：
|
||||
|
||||
1. 还有没有「绝不能瞎发挥」的前提要钉死？（一句一条）
|
||||
2. 游玩时最少需要哪些演员上场？（用中文名即可）
|
||||
3. 要不要表/状态栏？（不要就写「不要」）
|
||||
1. 还有没有「绝不能瞎发挥」的前提？（一句一条）
|
||||
2. 槽位是否按上游拓扑？（世界模拟默认：主世界层+转述；写手默认：大纲+章节）有无要改的勾选？
|
||||
3. 若已有「上下文投影排序」，是否按该表收成？（不要在本步重排）
|
||||
4. 要不要表/状态门控？（不要就写「不要」）
|
||||
|
||||
若前面产物已经够用，可直接回复「按已有产物收成」。
|
||||
```
|
||||
@@ -42,50 +45,51 @@ boundary: |
|
||||
## task
|
||||
|
||||
```task
|
||||
你正在执行剧本中的「细化终稿」步骤。产物必须写入 **设计.worker集**，且为 **JSON**（不要 YAML）。
|
||||
你正在执行「细化终稿」。产物必须写入 **设计.worker集**，且为 **JSON**。
|
||||
|
||||
本步是收成，不是再开一场题材发明。优先合并：
|
||||
- 设计.美学纲领与交互范式 → interaction / experience_check / 呈现
|
||||
- 设计.worker规格 → workers[]
|
||||
- 设计.叙事指南 / 生成规则 / 具体实例 / 世界蓝图 / 实现机制等 → resident_context 挂载或 core_premises
|
||||
- 设计.变量* / 状态栏 / 拓扑 → tables / 显隐说明（有则写，无则省略）
|
||||
本步是收成，不是发明新执行单元。优先合并：
|
||||
- 设计.美学纲领与交互范式 → interaction / experience_check
|
||||
- 设计.worker规格（游玩拓扑）→ play_slots 或 writing_slots
|
||||
- 设计.上下文投影排序 → 写入规格的 context_order（每槽 inserts：order/anchor/ref/projection）；无表且上下文很少时可按默认 static/dynamic 退化
|
||||
- 设计.叙事指南与故事推进（旧称 设计.叙事指南）/ 世界 / 机制 / 生成规则等 → resident_context（挂载以排序表与 mount 为准，本步不重排数字序）
|
||||
- 设计.变量设计与更新规则 → tables.side_effects（及 schemas 摘要）
|
||||
- 设计.变量控制上下文 → 核对挂载与剧透，写入 notes 或 resident 短句
|
||||
|
||||
执行顺序：
|
||||
1. 忠实复述已确认的站位、体验内核、禁忌；矛盾处 askUser 1 点，勿静默覆盖。
|
||||
2. 组装 workers[]：每个含 ref、name（中文）、duty、rationale、acceptance；缺省 context/outputs 可标示留给模板合并，但 acceptance 必须写出。
|
||||
3. resident_context：把稳定长文（叙事态度、关键规则摘要、禁忌）挂到需要的 workers；不要把全过程聊天塞进去。
|
||||
4. tables：仅钉体验真正依赖的字段与副作用；无则 `tables` 省略或空 schemas。
|
||||
5. core_premises：不能瞎发挥的短列表。
|
||||
6. design_end：如 `{ "opening": "optional" }` 表示可随后跑开场白。
|
||||
7. 输出完整 JSON；summary：`细化终稿 · Worker集 · N 演员 · …`
|
||||
1. 复述站位、体验内核、禁忌；矛盾处 askUser 1 点。
|
||||
2. 写入 `play_slots`（世界模拟）或等价写手槽；**workers 只含白名单 ref**：
|
||||
- world_sim 每轮：world-simulator / narrator / role-decide（仅 perspective 开时）
|
||||
- world_sim 按需：chance（仅 chance 开时；`invocation: on_demand`）
|
||||
- writing：outline / chapter-writer
|
||||
- 程序也会按 play_slots 展开；你仍应写出与槽一致的 workers[]（含 acceptance），便于人读验收。
|
||||
3. **禁止**自造 ref、禁止添加 variable-update / lore-keeper / 自造骰子 LLM 等。
|
||||
4. resident_context：稳定句挂到 gm 或 narrator（或 outline/chapter-writer）；勿塞聊天过程。
|
||||
5. tables：吸入变量设计的 side_effects；无则空数组或省略。
|
||||
6. core_premises、design_end.opening 按需。
|
||||
7. summary：`细化终稿 · 槽 gm+转述 · …` 或 `细化终稿 · 大纲+章节 · …`
|
||||
|
||||
若程序已发出默认问题：禁止重复同一开场。
|
||||
|
||||
进游玩不在本步完成；用户验收本产物后，由用户手动进入游玩。
|
||||
进游玩不在本步完成。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 合并优于重写：上游已验收内容优先进入规格，禁止无故改写体验内核。
|
||||
2. 每个面向用户的可读终稿点必须有 acceptance（review）；中间层 continue。
|
||||
3. 正推缩减：能不建表就不建；能常驻一段话解决的不要新演员。
|
||||
4. 写手路径最小可运行：outline + chapter-writer（或用户只要分段写手）；扮演路径按已钉演员。
|
||||
5. 键名稳定：workers[].ref 英文 kebab；name 中文给人看。
|
||||
6. 禁止题材固定套件；禁止在本步发明新 tool。
|
||||
7. 未决进 open_questions，不要假完备。
|
||||
1. 合并优于重写；槽位优于发明演员。
|
||||
2. 面向用户的终稿点 acceptance=review（通常是 narrator 或 chapter-writer）；gm/outline 常用 continue。
|
||||
3. 真值变更写在 gm 的 outputs（运行.本轮.变量变更 / 裁决包内 variable_changes），不靠第三变量 Worker。
|
||||
4. 裁决包约定：运行.本轮.裁决 使用 settlement.v1（见 progressive-data-design / 模板）。
|
||||
5. 键名稳定；未决进 open_questions。
|
||||
```
|
||||
|
||||
## probe
|
||||
|
||||
```probe
|
||||
一轮 1～2 点，只问会挡住收成的矛盾：
|
||||
只问挡住收成的矛盾：
|
||||
|
||||
- 上游演员列表与用户本轮说法冲突时，以谁为准？
|
||||
- 终稿演员是「每轮世界+叙事」还是「先纲后章」？
|
||||
- 有表需求但字段未定：先不要表，还是先钉 1～2 个关键字段？
|
||||
- 拓扑与用户本轮说法冲突时以谁为准？
|
||||
- 有表需求但副作用未定：先不要表，还是只钉 1～2 条 side_effects？
|
||||
|
||||
能按已有产物收成则不要为「完美」继续盘问。
|
||||
不要问「还要加哪个 Worker」。
|
||||
```
|
||||
|
||||
## output
|
||||
@@ -93,6 +97,7 @@ boundary: |
|
||||
```output
|
||||
{
|
||||
"version": 1,
|
||||
"form_summary": "一句话体验",
|
||||
"interaction": {
|
||||
"user_stance": "…",
|
||||
"system_role": "…",
|
||||
@@ -104,27 +109,35 @@ boundary: |
|
||||
"focus": "…",
|
||||
"satisfaction_source": "…"
|
||||
},
|
||||
"play_slots": {
|
||||
"gm": true,
|
||||
"narrator": true,
|
||||
"perspective": false
|
||||
},
|
||||
"workers": [
|
||||
{
|
||||
"name": "章节正文",
|
||||
"ref": "chapter-writer",
|
||||
"duty": "…",
|
||||
"when": "…",
|
||||
"rationale": "删掉则…",
|
||||
"acceptance": "review",
|
||||
"context": {
|
||||
"static": ["设计.worker集", "大纲.当前"],
|
||||
"dynamic": ["用户.最新输入"]
|
||||
},
|
||||
"outputs": ["正文.当前段", "正文.已完成"]
|
||||
"name": "主世界层",
|
||||
"ref": "world-simulator",
|
||||
"duty": "读投影与真值，输出 settlement.v1 裁决包；可提议变量变更",
|
||||
"when": "每轮用户输入后",
|
||||
"rationale": "删掉则无程序化裁决与真值更新",
|
||||
"acceptance": "continue"
|
||||
},
|
||||
{
|
||||
"name": "叙事转述",
|
||||
"ref": "narrator",
|
||||
"duty": "只读裁决包，写用户可见正文",
|
||||
"when": "裁决包就绪后",
|
||||
"rationale": "删掉则无独立文风呈现（或需 gm 兼写，须用户明确）",
|
||||
"acceptance": "review"
|
||||
}
|
||||
],
|
||||
"resident_context": [
|
||||
{
|
||||
"id": "experience-contract",
|
||||
"position": "static",
|
||||
"content": "从上游压缩的稳定句（体验/禁忌/态度）",
|
||||
"mount": ["chapter-writer"]
|
||||
"content": "体验/禁忌压缩句",
|
||||
"mount": ["world-simulator", "narrator"]
|
||||
}
|
||||
],
|
||||
"tables": {
|
||||
@@ -132,7 +145,6 @@ boundary: |
|
||||
"side_effects": []
|
||||
},
|
||||
"core_premises": ["…"],
|
||||
"narrative_guide": "可选短摘要；长文优先走 resident_context",
|
||||
"input_protocol": {
|
||||
"parens": "() 元要求",
|
||||
"quotes": "\"\" 角色对白",
|
||||
@@ -141,33 +153,33 @@ boundary: |
|
||||
"design_end": {
|
||||
"opening": "optional"
|
||||
},
|
||||
"open_questions": ["…"]
|
||||
"open_questions": []
|
||||
}
|
||||
```
|
||||
|
||||
必须是可解析 JSON。无表可省略 tables 或留空数组。每个 workers[] 元素必须有 acceptance。
|
||||
写手路径示例：不要 `play_slots`，workers 仅 `outline` + `chapter-writer`（acceptance 按是否验大纲）。
|
||||
|
||||
必须是可解析 JSON。每个 workers[] 元素必须有 acceptance，且 ref ∈ 白名单。
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 是否 JSON 且可解析为设计.worker集？
|
||||
- [ ] interaction 站位/轮转是否与美学纲领一致？
|
||||
- [ ] 每个 worker 是否有 name、ref、duty、rationale、acceptance？
|
||||
- [ ] 删掉任一 worker 的 rationale 是否说得清？
|
||||
- [ ] 有没有把聊天过程塞进常驻上下文？
|
||||
- [ ] 有没有题材默认灌入用户未要的演员/表？
|
||||
- [ ] 验收复述能否一句话说清：站位、体验核心、演员、为何没有某件？
|
||||
- [ ] 是否含 play_slots（世界模拟）或仅白名单写手 workers？
|
||||
- [ ] 有无白名单外的 ref？
|
||||
- [ ] interaction 是否与美学纲领一致？
|
||||
- [ ] side_effects 是否来自变量设计（或明确不要表）？
|
||||
- [ ] 有无把变量管理做成额外 worker？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：
|
||||
- 扩写：interaction.turn_shape=助手分段；workers=outline(continue/review)+chapter-writer(review)；resident 挂爽点与禁忌。
|
||||
- 扮演：world-simulator(continue)+narrator(review)；core_premises 含变造点。
|
||||
- play_slots gm+narrator；workers 两条与槽一致；side_effects 从变量设计拷入。
|
||||
- 扩写：outline continue + chapter-writer review；无自造 ref。
|
||||
|
||||
坏：
|
||||
- 输出 YAML 或半散文
|
||||
- workers 无 acceptance
|
||||
- 无视上游，按「标准世界模拟套件」重写
|
||||
- 自由发明 affinity-agent、world-lore-worker。
|
||||
- 无 play_slots 却塞了 6 个自定义 workers。
|
||||
- YAML 或半散文
|
||||
```
|
||||
|
||||
@@ -1,60 +1,231 @@
|
||||
# 设计回复格式
|
||||
# 正文组成
|
||||
|
||||
> **状态：待完善** — 块格式见 `docs/world-simulator-modules.md`；范例见 `aesthetics-interaction`。
|
||||
> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 产物外壳：`docs/context-fragment-design.md`。
|
||||
> **不是**程序 API/JSON schema 格式；钉的是用户最后看见的「一封信怎么拼起来」。
|
||||
> 旧称：设计回复格式。
|
||||
|
||||
## meta
|
||||
|
||||
```meta
|
||||
name: 设计回复格式
|
||||
name: 正文组成
|
||||
id: reply-format
|
||||
artifact: 设计.回复格式
|
||||
declaration: 钉单轮可见输出的结构（正文块、面板、拼接顺序），服务体验契约
|
||||
when: 需要钉单轮「用户看见什么、什么顺序」时（含多块拼接）
|
||||
when_not: 美学纲领与交互范式里呈现已足够且无多块结构时
|
||||
artifact: 设计.正文组成
|
||||
declaration: >
|
||||
钉用户可见的一轮回复由哪些块、何顺序组成（抬头/日期/正文/监控栏/文末吐槽等），
|
||||
含对 LLM 隐藏的变量维护段与前端拆分/美化提示；不等于程序报文格式
|
||||
when: |
|
||||
用户看见的不该只是「一整段散文」，需要版式块（抬头、监控栏、文末小块等）；
|
||||
或需要约定隐藏变量段供模型维护表格；或需要前端分区渲染时。
|
||||
when_not: |
|
||||
纯单段叙事、明确不要分块版式 → 可不排（转述直接出一段即可）。
|
||||
只谈文风遣词 → 「叙事指南与故事推进」。
|
||||
只钉监控栏字段清单、版式已定 → 「设计监控栏」。
|
||||
块结构未定时不要先空谈 CSS 细节。
|
||||
boundary: |
|
||||
本能力：单轮可见结构与拼接。
|
||||
设计状态栏：状态栏块的字段细则。
|
||||
美学纲领与交互范式：人称、系统扮演、体验边界——本步不重谈。
|
||||
本技能：用户可见组成（块清单、顺序、可见/隐藏、前端拆分意图）；产出 context-fragment.v1。
|
||||
不是 OpenAI/函数调用报文，也不是结算包 schema。
|
||||
设计监控栏：监控栏内有哪些可变字段——可本步给骨架，细则可交监控栏技能。
|
||||
叙事指南与故事推进：怎么写正文——本步定「正文」块在版式里的位置与职责，不重写文风。
|
||||
变量设计：真值如何变——本步只约定隐藏段如何承载变更声明，不写 side_effects。
|
||||
feeds: narrator
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
用户每一轮「看见的东西」希望像什么？（想到什么写什么）
|
||||
|
||||
1. 由哪些部分组成？什么顺序？
|
||||
例：抬头 + 日期/地点 + 正文；或正文 + 监控栏；或文末再加小吐槽/模拟书评……
|
||||
|
||||
2. 有没有要「藏起来给模型/程序看、用户界面默认不展示」的段？
|
||||
例：用特殊标记包住的变量变更，方便拆解维护表格。
|
||||
|
||||
3. 前端要不要拆成多个区域美化？（监控栏固定顶栏、正文滚动、文末折叠……）没有就说没有。
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
钉清单轮可见回复格式（块、顺序、可选面板），写入 设计.回复格式。对齐已验收的呈现契约。
|
||||
（待作者细写）
|
||||
你正在执行「正文组成」。产物必须是 **context-fragment.v1** JSON，写入「设计.正文组成」。
|
||||
|
||||
本步设计的是**用户最后看见的内容版式**——像一封信由收信人、正文、日期、发信人组成；
|
||||
也可以是抬头、日期、地点、正文、监控栏、文末吐槽、小故事、模拟书评等。
|
||||
**不是**程序接口格式。
|
||||
|
||||
执行顺序：
|
||||
1. 读美学呈现与叙事指南：继承人称/终稿由谁写；不重开文风问卷。
|
||||
2. 列出「可见块」：每块职责、顺序、是否可空、由谁填充（转述/程序拼装/监控栏技能）。
|
||||
3. 若有监控栏：写清它在版式中的位置与职责；字段级细则可引用或留给「设计监控栏」（只留会变、要盯的信息）。
|
||||
4. 若有隐藏段：写清标记约定（如正则/定界符）、内容用途（变量变更声明）、用户侧默认隐藏、模型须输出以便拆表。
|
||||
5. 写「前端拆分与美化」意图（区域、可否折叠、是否 HTML 片段）；无则说明纯 Markdown/纯文本。
|
||||
6. 自评 + 追问；输出 JSON。禁止写最终 context `order`。
|
||||
|
||||
summary：`正文组成 · …`（点题主要块序）。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
结构服务体验；块要少；与状态栏/终稿 tag 约定一致。
|
||||
1. 用户看见的版式，不是程序报文
|
||||
用「信/报纸/游戏 HUD」类比思考块；禁止把本步写成 API 字段说明书。
|
||||
|
||||
2. 块要少、每块有职责
|
||||
宁缺毋滥；装饰块必须服务体验（吐槽/书评若只是玩梗也要写清触发与长度）。
|
||||
|
||||
3. 监控栏 ≠ 名片卡
|
||||
监控的是会变、影响决策或沉浸的信息（好感、体力、场景可交互对象、攻略目标状态…）。
|
||||
主角「姓名」「性别」等几乎不变的内容默认不要进监控栏（绝大多数局）。
|
||||
|
||||
4. 隐藏段服务维护，不污染阅读
|
||||
变量变更等可用定界符包住，供 LLM 输出、程序/旁路拆解入表；用户 UI 默认不渲染或折叠。
|
||||
|
||||
5. 前端意图只写「拆哪里、干什么」
|
||||
可提：顶栏监控 / 正文区 / 文末折叠 / 简易 HTML 片段。不写完整 CSS 工程。
|
||||
|
||||
6. 与转述、变量分工
|
||||
正文块文风归叙事指南；真值规则归变量设计；本步定拼装契约。
|
||||
```
|
||||
|
||||
## probe
|
||||
|
||||
```probe
|
||||
（待作者细写）
|
||||
每轮 1～2 点。
|
||||
|
||||
优先：必须有哪些可见块；监控栏要不要、盯什么类型信息；隐藏变量段要不要及标记长什么样；前端要不要分区。
|
||||
不追问：完整 CSS、事件池 schema、文风遣词细节（除非块职责不清）。
|
||||
```
|
||||
|
||||
## output
|
||||
|
||||
```output
|
||||
{
|
||||
"块顺序": ["状态栏", "正文", "…"],
|
||||
"正文约定": "…",
|
||||
"可选面板": [],
|
||||
"终稿tag或拼装说明": "…"
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "正文组成",
|
||||
"brief": "一句话：用户看见的主要块序",
|
||||
"mount": ["narrator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"依据的体验与呈现": [
|
||||
"从美学/叙事继承的呈现要点"
|
||||
],
|
||||
"版式隐喻": "例：一封信 / 网文章节页 / 游戏回合面板 / 无（纯散文）",
|
||||
"可见块": [
|
||||
{
|
||||
"块id": "英文 kebab 或中文短名，同局稳定",
|
||||
"显示名": "用户可理解的标题；可无标题则空",
|
||||
"职责": "这块给用户什么信息",
|
||||
"顺序": 1,
|
||||
"可空": true,
|
||||
"填充方": "叙事转述|程序拼装|监控栏|其它",
|
||||
"内容形态": "散文|短列表|键值行|HTML片段|其它",
|
||||
"示例": "可选一句/三行示意"
|
||||
}
|
||||
],
|
||||
"监控栏锚点": {
|
||||
"本局是否启用": "是|否",
|
||||
"在可见块中的块id": "若启用则指向可见块之一",
|
||||
"职责摘要": "盯哪些类信息（详表见设计.监控栏或本步字段草稿）",
|
||||
"字段草稿": [
|
||||
{
|
||||
"名": "会变且值得盯的字段",
|
||||
"为何监控": "决策/沉浸理由",
|
||||
"来源意图": "真值|投影|临场生成"
|
||||
}
|
||||
]
|
||||
},
|
||||
"隐藏段": [
|
||||
{
|
||||
"段id": "variable-delta",
|
||||
"用途": "变量维护语句（与「变量设计.维护语句约定」同构），供程序拆进变量.当前",
|
||||
"定界或正则约定": "例：<<<VARS>>>...<<<END>>>；形状细节以变量设计为准",
|
||||
"用户界面": "默认隐藏|折叠可见|调试可见",
|
||||
"模型必须输出": true,
|
||||
"内容形状": "短键值/JSON行；非 chance toolcall",
|
||||
"示例": "可选"
|
||||
}
|
||||
],
|
||||
"前端拆分与美化": {
|
||||
"需要前端分区": "是|否",
|
||||
"区域": [
|
||||
{
|
||||
"区域id": "monitor|body|footer|…",
|
||||
"对应块id": ["…"],
|
||||
"意图": "固定顶栏|主滚动|折叠文末|…",
|
||||
"渲染提示": "纯文本|Markdown|受限HTML；勿写完整工程"
|
||||
}
|
||||
],
|
||||
"说明": "无分区则写「单流渲染」"
|
||||
},
|
||||
"拼装与终稿": {
|
||||
"终稿tag": "通常 输出.用户展示",
|
||||
"拼装方": "叙事转述一次写出各块|程序按块拼接|混合",
|
||||
"与裁决包关系": "转述读 settlement 再填各块；隐藏段可含 variable_changes 镜像"
|
||||
}
|
||||
},
|
||||
"自评": {
|
||||
"维度": [
|
||||
{
|
||||
"名": "可见完备",
|
||||
"分数": 0,
|
||||
"说明": "用户该看见的块是否齐、顺序是否服务体验"
|
||||
},
|
||||
{
|
||||
"名": "监控克制",
|
||||
"分数": 0,
|
||||
"说明": "监控栏是否只盯会变信息；无姓名性别等死字段堆砌（若无监控栏可 N/A）"
|
||||
},
|
||||
{
|
||||
"名": "可实现",
|
||||
"分数": 0,
|
||||
"说明": "隐藏段约定与前端拆分是否清楚到可交给转述/程序/前端"
|
||||
}
|
||||
],
|
||||
"薄弱点": "一句话"
|
||||
},
|
||||
"追问": {
|
||||
"导语": "为钉准用户看见的版式，还需确认：",
|
||||
"题目": [
|
||||
{
|
||||
"问": "…",
|
||||
"建议选项": ["选项A", "选项B", "其它（请写明）"],
|
||||
"示例": "可选"
|
||||
}
|
||||
]
|
||||
},
|
||||
"开放问题": []
|
||||
}
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. 合法 JSON；含公共三段外壳。
|
||||
2. 正文键固定：依据的体验与呈现、版式隐喻、可见块、监控栏锚点、隐藏段、前端拆分与美化、拼装与终稿。
|
||||
3. `可见块` 至少 1 条（通常含正文）；`隐藏段`/`字段草稿` 可 `[]`。
|
||||
4. 禁止把本步写成程序 API schema；禁止 `order`（上下文投影序）。
|
||||
5. 自评：可见完备 / 监控克制 / 可实现。
|
||||
6. summary：`正文组成 · {brief 缩略}`。
|
||||
7. 兼容旧称产物 tag「设计.回复格式」：细化终稿可读新 tag，旧局可仍挂旧名。
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 是否与美学纲领的呈现/轮转一致？
|
||||
- [ ] 状态栏块是否指向 设计.状态栏（若有）？
|
||||
- [ ] 明确是用户可见版式，而非程序报文？
|
||||
- [ ] 可见块有顺序与职责？监控栏未塞不变名片字段？
|
||||
- [ ] 隐藏段（若有）定界与用途清楚？前端拆分有或明确单流？
|
||||
- [ ] 自评三维？未越权重写文风或 side_effects？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：
|
||||
- 块序：监控栏 → 正文 → 文末吐槽；隐藏段 <<<VARS>>> 维护好感变更。
|
||||
- 书信局：抬头/日期/正文/落款；无监控栏。
|
||||
- 监控栏只盯：体力、攻略目标好感、场景可交互对象——不写主角姓名性别。
|
||||
|
||||
坏：
|
||||
- 把 settlement.v1 字段表当「回复格式」。
|
||||
- 监控栏列出姓名、性别、种族等死设定。
|
||||
- 只写「要好看的 UI」无块清单。
|
||||
```
|
||||
|
||||
@@ -1,59 +1,189 @@
|
||||
# 设计状态栏
|
||||
# 设计监控栏
|
||||
|
||||
> **状态：待完善** — 块格式见 `docs/world-simulator-modules.md`；范例见 `aesthetics-interaction`。
|
||||
> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 产物外壳：`docs/context-fragment-design.md`；字段筛选气质对齐「生成规则」属性妥当。
|
||||
> 旧称：设计状态栏。更名因：这里盯的是**会变、要监控的信息**，不是名片式「状态展览」。
|
||||
|
||||
## meta
|
||||
|
||||
```meta
|
||||
name: 设计状态栏
|
||||
name: 设计监控栏
|
||||
id: status-bar
|
||||
artifact: 设计.状态栏
|
||||
declaration: 钉用户可见状态栏：字段、刷新时机、与正文如何拼装
|
||||
when: 体验需要程序拼状态栏+正文，或用户要持续可见关键状态时
|
||||
when_not: 纯单段叙事、明确不要 HUD/状态条时
|
||||
artifact: 设计.监控栏
|
||||
declaration: >
|
||||
钉用户可见监控栏字段：只留会变、影响决策或沉浸的信息
|
||||
（主角状态/攻略目标/场景可交互对象等）；不进姓名性别等死字段
|
||||
when: |
|
||||
「正文组成」已启用监控栏，或体验需要持续可见的监控信息时；
|
||||
需要逐字段筛「该不该监控」时。
|
||||
when_not: |
|
||||
明确不要 HUD/监控条 → 不排。
|
||||
版式块序未定、连有没有监控栏都不清 → 先「正文组成」。
|
||||
真值如何增减 → 「变量设计与更新规则」（本步只选展示哪些）。
|
||||
boundary: |
|
||||
本能力：可见状态栏字段与刷新/拼装。
|
||||
变量设计与更新规则：背后变量如何变。
|
||||
设计回复格式：整轮输出结构（状态栏可为其一块）。
|
||||
本技能：监控栏字段清单、来源意图、刷新与可见条件；产出 context-fragment.v1。
|
||||
正文组成：监控栏在整轮版式中的位置——本步不重排其它块。
|
||||
变量设计：真值与 side_effects——本步可引用字段名，不写更新公式。
|
||||
生成规则：内容表 schema——监控栏不是生成实例表，但同样忌冗余字段。
|
||||
feeds: narrator
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
这一局监控栏要让用户盯住什么？（想到什么写什么）
|
||||
|
||||
1. 监控对象是谁/哪一层？
|
||||
例：主角生存资源；攻略目标态度；当前场景可交互对象；任务进度……
|
||||
|
||||
2. 哪些数字或短状态会变、且变了会影响你下一步？
|
||||
不要列几乎不变的名片（姓名、性别等——绝大多数局都不需要）。
|
||||
|
||||
3. 刷新节奏？每轮都刷，还是事件后才变？
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
钉清用户可见状态栏：字段、来源、刷新时机、与正文拼装方式。写入 设计.状态栏。
|
||||
（待作者细写）
|
||||
你正在执行「设计监控栏」。产物必须是 **context-fragment.v1** JSON，写入「设计.监控栏」。
|
||||
|
||||
监控栏 = 用户可见的**监控**区：只放有用、会变的信息。
|
||||
可含：主角资源/状态、攻略目标状态、当前场景可交互对象等——按体验需要选，不默认堆满。
|
||||
|
||||
执行顺序：
|
||||
1. 读正文组成（若有）与变量设计：继承栏位位置与已有真值名。
|
||||
2. 逐字段过筛（同生成规则「属性妥当」）：对本局是否值得监控？不变的名片字段删除。
|
||||
3. 写清每字段：名、为何监控、来源意图、可见条件、展示形态（短文本/数值/列表）。
|
||||
4. 写刷新时机与空态（无目标/无交互物时显示什么）。
|
||||
5. 自评 + 追问；输出 JSON。
|
||||
|
||||
summary：`设计监控栏 · …`（点题监控对象）。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
只展示影响决策或沉浸的字段；与变量设计对齐。
|
||||
1. 监控 ≠ 角色卡
|
||||
姓名、性别、种族等几乎不变内容默认排除（除非玩法就是改性别/改名且必须盯）。
|
||||
|
||||
2. 只留有用消息
|
||||
能回答：变了以后用户会不会改决策或沉浸感？不能则删。
|
||||
|
||||
3. 对象可以多层
|
||||
不限于「主角状态」：攻略目标、场景可交互列表、世界危机进度等都可进栏——但每层字段仍要克制。
|
||||
|
||||
4. 来源可追溯
|
||||
字段应能指向真值、投影或临场短生成；禁止无来源的装饰假数。
|
||||
|
||||
5. 展示短
|
||||
监控栏不是正文；长描写放叙事，栏内短标签/数字/一行列表。
|
||||
```
|
||||
|
||||
## probe
|
||||
|
||||
```probe
|
||||
（待作者细写）
|
||||
每轮 1～2 点：缺哪类监控对象；某字段是否死字段该删；刷新过频还是过稀。
|
||||
不追问：整页 CSS、文风、完整变量更新公式。
|
||||
```
|
||||
|
||||
## output
|
||||
|
||||
```output
|
||||
{
|
||||
"字段": [{ "名": "…", "来源": "…", "可见条件": "…" }],
|
||||
"刷新": "每轮|事件|…",
|
||||
"拼装": "状态栏在正文前|后|旁|…"
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "设计监控栏",
|
||||
"brief": "一句话：监控谁/什么",
|
||||
"mount": ["narrator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"依据": ["正文组成锚点 / 变量设计字段 / 体验需要"],
|
||||
"监控对象": [
|
||||
{
|
||||
"对象id": "pc|target|scene|world|…",
|
||||
"名称": "主角|攻略目标|当前场景|…",
|
||||
"为何出现在栏内": "…"
|
||||
}
|
||||
],
|
||||
"字段": [
|
||||
{
|
||||
"名": "短名，用户可见",
|
||||
"对象id": "归属上述对象",
|
||||
"为何监控": "变了如何影响决策或沉浸",
|
||||
"来源意图": "真值键名|投影tag|临场",
|
||||
"类型示意": "number|string|short_list|enum",
|
||||
"可见条件": "始终|某阶段|有目标时…",
|
||||
"展示形态": "例：❤ 37；或一行「可交互：门、柜」",
|
||||
"禁止原因若曾候选": "例：性别——不变，已剔除；无则空"
|
||||
}
|
||||
],
|
||||
"刻意不监控": [
|
||||
"姓名、性别…及原因"
|
||||
],
|
||||
"刷新": {
|
||||
"时机": "每轮|事件后|变量边沿|手动",
|
||||
"空态": "无数据时显示什么"
|
||||
},
|
||||
"与版式关系": "在正文组成中的块位置；若尚无正文组成则写建议位置"
|
||||
},
|
||||
"自评": {
|
||||
"维度": [
|
||||
{
|
||||
"名": "属性妥当",
|
||||
"分数": 0,
|
||||
"说明": "逐字段：无死名片；该盯的生存/关系/场景信息未漏"
|
||||
},
|
||||
{
|
||||
"名": "克制度",
|
||||
"分数": 0,
|
||||
"说明": "字段是否够少、展示是否够短"
|
||||
},
|
||||
{
|
||||
"名": "可接线",
|
||||
"分数": 0,
|
||||
"说明": "来源意图是否接得上变量/投影/正文组成"
|
||||
}
|
||||
],
|
||||
"薄弱点": "一句话"
|
||||
},
|
||||
"追问": {
|
||||
"导语": "为钉准监控栏，还需确认：",
|
||||
"题目": [
|
||||
{
|
||||
"问": "…",
|
||||
"建议选项": ["选项A", "选项B", "其它（请写明）"],
|
||||
"示例": "可选"
|
||||
}
|
||||
]
|
||||
},
|
||||
"开放问题": []
|
||||
}
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. 合法 JSON；公共三段外壳。
|
||||
2. 正文键固定：依据、监控对象、字段、刻意不监控、刷新、与版式关系。
|
||||
3. 自评：属性妥当 / 克制度 / 可接线。
|
||||
4. 字段不得无故包含姓名/性别等死设定（列入「刻意不监控」并说明）。
|
||||
5. summary：`设计监控栏 · {brief 缩略}`。
|
||||
6. 兼容旧 artifact「设计.状态栏」。
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 每个字段是否有变量/表来源？
|
||||
- [ ] 是否与回复格式拼装不冲突？
|
||||
- [ ] 字段均为会变且有用？死名片进了「刻意不监控」？
|
||||
- [ ] 可含攻略目标/场景交互物等非主角对象？
|
||||
- [ ] 来源意图清楚？未写成长文正文？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：
|
||||
- 末日：体力、口粮、威胁等级；刻意不监控姓名性别。
|
||||
- 恋爱：攻略目标好感/心情；场景可交互：公园长椅、便利店。
|
||||
- 字段 3～7 个，短展示。
|
||||
|
||||
坏：
|
||||
- 监控栏 = 完整人物卡（名/性/龄/身高/籍贯…）。
|
||||
- 把叙事指南整段塞进栏内。
|
||||
```
|
||||
|
||||
@@ -13,7 +13,7 @@ when: 实现机制大致清楚，需要钉依赖边、触发边与数据流向
|
||||
when_not: 尚未决定有哪些执行单元就先画复杂图
|
||||
boundary: |
|
||||
本能力：依赖/触发/读写流向。
|
||||
Worker 规格：单个单元契约。
|
||||
游玩拓扑：固定槽勾选；本步若仍需要，只画已启用槽之间的数据流。
|
||||
实现机制：总览「要哪些件」，本步钉件与件的边。
|
||||
```
|
||||
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
# 变量控制上下文
|
||||
|
||||
> **状态：待完善** — 块格式见 `docs/world-simulator-modules.md`；范例见 `aesthetics-interaction`。
|
||||
> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 上游：`variable-design`；方法：`docs/progressive-data-design.md`。
|
||||
|
||||
## meta
|
||||
|
||||
@@ -8,50 +9,145 @@
|
||||
name: 变量控制上下文
|
||||
id: variable-context
|
||||
artifact: 设计.变量控制上下文
|
||||
declaration: 钉哪些变量如何挂进常驻上下文 / 控制生成口径（可见性与措辞）
|
||||
when: 变量已大致设计，需要规定它们如何进入 worker 上下文与措辞时
|
||||
when_not: 尚无变量，或变量仅程序内部、从不进提示词时
|
||||
declaration: >
|
||||
钉真值/投影/Data 摘要如何挂进主世界层、叙事转述与旁观：
|
||||
可见性、措辞、未解锁不注入；汇总映射当前档供旁观 agent
|
||||
when: |
|
||||
变量设计已有真值或 Data 映射索引，需要规定谁看见什么、旁观看哪份摘要时。
|
||||
when_not: |
|
||||
尚无变量且无投影。
|
||||
仅内部记账永不进提示词 → 可跳过，在变量设计备注即可。
|
||||
只改字段与更新规则 → 变量设计与更新规则。
|
||||
boundary: |
|
||||
本能力：变量 → 上下文挂载与生成口径。
|
||||
变量设计与更新规则：字段与改值规则本身。
|
||||
本技能：挂载表、剧透边界、旁观汇总视野、与维护语句/投影 tag 对齐。
|
||||
变量设计：字段、映射索引、维护语句形状、side_effects。
|
||||
具体实例：表行正文——本步不重生成，只声明「旁观读当前档/哪几个摘要键」。
|
||||
设计监控栏 / 正文组成：用户可见层；本步管提示词视野。
|
||||
feeds: gm
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
有没有「玩家不该看见、但主世界层/旁观要知道」或「到了某档才允许提起」的状态？
|
||||
旁观需要看「当前好感档性格要点」这类汇总吗？有则简述；没有就「没有信息差」。
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
钉清变量如何挂进常驻上下文、控制哪些生成口径。写入 设计.变量控制上下文。
|
||||
（待作者细写）
|
||||
你正在执行「变量控制上下文」。产物必须是 **context-fragment.v1** JSON，写入「设计.变量控制上下文」。
|
||||
|
||||
在已有真值 / Data 映射索引 / side_effects 上钉：
|
||||
1. 主世界层每轮见哪些真值键与投影 tag
|
||||
2. 叙事转述见哪些玩家安全切片
|
||||
3. **旁观汇总**：从映射索引+投影拼出的只读摘要（给旁观 agent，不写 canon）
|
||||
4. 未达阈值不注入；禁止泄露列表
|
||||
|
||||
不重开变量清单；不重写具体实例整表。
|
||||
|
||||
summary：`变量控制上下文 · …`。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
只挂影响生成的变量；措辞服务体验，不泄露不该剧透的内部态（除非体验需要）。
|
||||
1. 只挂影响生成的状态；整张 Data 不进 static。
|
||||
2. 旁观要「当前档汇总」，材料来自映射索引的摘要键 + 已投影 tag；不是第二份实例库。
|
||||
3. Progressive：未解锁档正文不进上下文。
|
||||
4. 维护语句由主世界层按变量设计输出；本步只保证挂载后能读到合并后的真值/投影。
|
||||
5. 默认拓扑：主世界层 + 可选转述 + 可选旁观挂载；不为挂载再拆执行单元。
|
||||
```
|
||||
|
||||
## probe
|
||||
|
||||
```probe
|
||||
（待作者细写）
|
||||
主世界层要不要隐藏真值？旁观汇总要哪些摘要键？转述是否禁止好感数字？一次 1～2 点。
|
||||
```
|
||||
|
||||
## output
|
||||
|
||||
```output
|
||||
{
|
||||
"挂载": [{ "变量": "…", "挂到": "常驻|某worker|…", "措辞要点": "…" }],
|
||||
"禁止泄露": ["…"]
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "变量控制上下文",
|
||||
"brief": "一句话：各槽看见什么状态",
|
||||
"mount": ["world-simulator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"挂载": [
|
||||
{
|
||||
"对象": "主世界层|叙事转述|旁观|常驻",
|
||||
"ref或mount": "world-simulator|narrator|…",
|
||||
"真值键": ["好感"],
|
||||
"投影tag": ["上下文.角色态度"],
|
||||
"映射摘要": ["从映射id取当前档的哪些键；无则 []"],
|
||||
"措辞要点": "…",
|
||||
"未达阈值": "对应投影不注入"
|
||||
}
|
||||
],
|
||||
"旁观汇总": {
|
||||
"启用": "是|否",
|
||||
"tag": "上下文.旁观.状态摘要",
|
||||
"组成": [
|
||||
"真值：好感数字（仅旁观）",
|
||||
"映射 affinity-personality：当前档态度要点+禁触",
|
||||
"已触发 once 门列表"
|
||||
],
|
||||
"更新时机": "真值变更后 / 与 side_effects 同时",
|
||||
"禁止": ["整表粘贴", "写回 canon"]
|
||||
},
|
||||
"禁止泄露": [
|
||||
{
|
||||
"内容": "…",
|
||||
"对谁禁": "叙事转述|用户展示|…",
|
||||
"原因": "…"
|
||||
}
|
||||
],
|
||||
"与side_effects对齐": ["上下文.角色态度 ← affinity-romance"],
|
||||
"与维护语句对齐": "主世界层读合并后真值；维护语句形状见变量设计，本步不改"
|
||||
},
|
||||
"自评": {
|
||||
"维度": [
|
||||
{
|
||||
"名": "视野正确",
|
||||
"分数": 0,
|
||||
"说明": "各槽该见/不该见是否清楚"
|
||||
},
|
||||
{
|
||||
"名": "旁观可用",
|
||||
"分数": 0,
|
||||
"说明": "旁观汇总是否够用且未整表；不需要旁观则 N/A"
|
||||
},
|
||||
{
|
||||
"名": "防剧透",
|
||||
"分数": 0,
|
||||
"说明": "未解锁与禁止泄露是否落实"
|
||||
}
|
||||
],
|
||||
"薄弱点": "一句话"
|
||||
},
|
||||
"追问": {
|
||||
"导语": "为钉准状态视野，还需确认：",
|
||||
"题目": []
|
||||
},
|
||||
"开放问题": []
|
||||
}
|
||||
```
|
||||
|
||||
硬规则：公共三段；旁观汇总可「启用=否」；禁止发明变量执行单元；summary 见 task。
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 挂载是否与变量设计名单一致？
|
||||
- [ ] 剧透边界是否与体验禁忌一致？
|
||||
- [ ] 挂载与变量设计名单一致？
|
||||
- [ ] 旁观汇总用摘要键而非整表？
|
||||
- [ ] 投影 tag 与 side_effects 一致？剧透边界清楚？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：旁观 tag 只含「当前档态度要点 + 好感」；转述只见投影态度不见数字。
|
||||
坏：把具体实例整份分档 JSON 挂进旁观 static。
|
||||
```
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# 变量设计与更新规则
|
||||
|
||||
> **状态：待完善** — 块格式见 `docs/world-simulator-modules.md`；范例见 `aesthetics-interaction`。
|
||||
> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 方法：`docs/progressive-data-design.md`；外壳：`docs/context-fragment-design.md`。
|
||||
> 与「正文组成」隐藏段、生成规则/具体实例的 Data 表、旁观汇总对齐。
|
||||
|
||||
## meta
|
||||
|
||||
@@ -8,58 +10,217 @@
|
||||
name: 变量设计与更新规则
|
||||
id: variable-design
|
||||
artifact: 设计.变量设计与更新规则
|
||||
declaration: 钉变量字段、初值与更新时机/规则；与表副作用对齐
|
||||
when: 需要可追踪状态（进度、关系、资源等）且要写清谁何时改时
|
||||
when_not: 无状态纯对话、或状态仅散文描述从不程序化时
|
||||
declaration: >
|
||||
钉真值、谁可写、如何变；起草 side_effects；约定维护语句形状；
|
||||
汇总 Data 映射索引（分档/实例来自生成规则与具体实例）供投影与旁观
|
||||
when: |
|
||||
体验需要可追踪状态，且下游要可靠查询、门控、防重复或按值换文案时。
|
||||
when_not: |
|
||||
无状态纯对话，或状态只临场描写、从不程序化。
|
||||
只要大段设定不要门控 → 舞台骨架 / 生成规则。
|
||||
只规定挂进谁的提示词 → 「变量控制上下文」。
|
||||
只规定用户看见哪些监控字段 → 「设计监控栏」。
|
||||
boundary: |
|
||||
本能力：字段、初值、更新规则、与副作用。
|
||||
变量控制上下文：这些变量如何进入提示词口径。
|
||||
设计状态栏：哪些对用户可见。
|
||||
本技能：真值清单、更新规则、维护语句约定、Data 映射索引、side_effects 草案。
|
||||
分档长文/性格切片正文：由生成规则定格式、具体实例填表；本步做索引与门控，不重写整表。
|
||||
正文组成：隐藏段定界符——本步钉「维护语句写什么」；定界样式与之对齐。
|
||||
机遇裁定 chance：真随机 toolcall，不是变量表维护手段。
|
||||
变量控制上下文：挂载对象与旁观汇总视野。
|
||||
细化终稿：收成 tables.side_effects。
|
||||
feeds: gm
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
先说「玩的时候必须记住、否则体验会糊」的东西：
|
||||
|
||||
1. 数字/阶段？（好感、章节、资源…）一次性门？
|
||||
2. 有没有「到了某值换一套态度/大纲」的表？（表正文可已在具体实例里）
|
||||
3. 每轮模型用什么方式声明变量变了？（裁决包字段 / 隐藏段键值 / 两者）
|
||||
4. 旁观或主世界层是否需要一份「当前映射摘要」（如好感档→性格要点）？
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
钉清变量字段、初值与更新规则，写入 设计.变量设计与更新规则。与表/副作用命名对齐。
|
||||
（待作者细写）
|
||||
你正在执行「变量设计与更新规则」。产物必须是 **context-fragment.v1** JSON，写入「设计.变量设计与更新规则」。
|
||||
|
||||
三分：
|
||||
- **真值**：跨轮必须记住的少数字段（好感、章节…）
|
||||
- **Data 映射**：阈值→切片大表（性格档、章纲、事件池）——格式归生成规则，行归具体实例；本步建索引并指向实例/规则 id
|
||||
- **Progressive**：side_effects 按真值边沿投影当前切片；旁观/主世界层读投影或汇总，不整表常驻
|
||||
|
||||
**维护语句**：规定模型每轮如何声明变更（供程序拆进 `变量.当前` / 裁决包 `variable_changes`）。
|
||||
这不是 chance toolcall；toolcall 只做骰子/抽签。隐藏段定界与「正文组成」对齐。
|
||||
|
||||
执行顺序：
|
||||
1. 读美学/机制/生成规则/具体实例/正文组成；不重开体验。
|
||||
2. 立真值（承重才建）；写写入源与更新规则。
|
||||
3. 建 Data 映射索引：每张表写清键依哪个真值、材料来自哪条 rule_id/batch、给旁观/投影用的摘要字段。
|
||||
4. 写维护语句约定：形状、必填键、与隐藏段/settlement 的关系、示例一句。
|
||||
5. 写 side_effects（once/every_edge → replace_tag 等）。
|
||||
6. 自评 + 追问；输出 JSON。
|
||||
|
||||
summary：`变量设计 · …`（点题主真值 + 有无映射表）。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
字段要少；更新规则可检查；禁止隐式改值。
|
||||
1. 承重才立真值；派生性格不落第二可写格。
|
||||
2. 映射内容：具体实例生成 → 本步索引汇总 → side_effects/变量控制上下文供给旁观与主世界层。
|
||||
3. 维护靠「声明 + 程序合并」，不靠模型直接改库：
|
||||
- 主路径：裁决包 variable_changes 和/或正文隐藏段（正则/定界）→ Runtime 合并进 变量.当前
|
||||
- 边沿：side_effects 换投影 tag
|
||||
- 用户手改；chance 只出随机数，不替代维护语句
|
||||
4. 维护语句必须可生成、可校验：固定键名、短值、禁止散文糊弄。
|
||||
5. 旁观要看的是「当前档摘要」，不是整份实例库；汇总句或投影 tag 即可。
|
||||
6. 宁少勿多；与监控栏字段可交集但职责不同（监控=用户看见；真值=程序真相）。
|
||||
```
|
||||
|
||||
## probe
|
||||
|
||||
```probe
|
||||
（待作者细写）
|
||||
每轮 1～2 点：主真值；连续数字还是阶段枚举；维护走裁决包还是隐藏段还是两者；映射表是否已有具体实例可索引；旁观要不要当前档摘要。
|
||||
```
|
||||
|
||||
## output
|
||||
|
||||
```output
|
||||
{
|
||||
"变量": [
|
||||
{
|
||||
"名": "…",
|
||||
"类型": "…",
|
||||
"初值": "…",
|
||||
"更新": "谁、何时、怎么变"
|
||||
}
|
||||
],
|
||||
"副作用备注": "…"
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "变量设计与更新规则",
|
||||
"brief": "一句话：主真值 + 映射/维护方式",
|
||||
"mount": ["world-simulator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"依据的体验": ["从机制/美学提取的状态化点"],
|
||||
"真值": [
|
||||
{
|
||||
"名": "好感",
|
||||
"类型": "number|enum|boolean|string|set",
|
||||
"初值": 0,
|
||||
"对用户可见": true,
|
||||
"对主世界层可见": true,
|
||||
"写入源": ["llm", "用户"],
|
||||
"更新": {
|
||||
"时机": "…",
|
||||
"方式": "delta|绝对值|枚举切换",
|
||||
"钳制": "0..100|未定",
|
||||
"执行单元": "world-simulator"
|
||||
},
|
||||
"备注": ""
|
||||
}
|
||||
],
|
||||
"Data映射索引": [
|
||||
{
|
||||
"映射id": "affinity-personality",
|
||||
"用途": "好感分档性格|章大纲|场景包|事件池|…",
|
||||
"键依真值": "好感",
|
||||
"键规则": "例：区间 [0,30)/[30,60)/[60,100]",
|
||||
"结构摘要": "阈值 → 态度/行为切片字段…",
|
||||
"生成规则rule_id": "来自设计.生成规则；无则待补",
|
||||
"具体实例batch_id": "来自设计.具体实例；无则待补",
|
||||
"旁观与投影要用的摘要键": ["档名", "态度要点", "禁触"],
|
||||
"说明": "长文在实例表；本索引只为查表与汇总"
|
||||
}
|
||||
],
|
||||
"维护语句约定": {
|
||||
"通道": ["settlement.variable_changes", "隐藏段", "二者都要"],
|
||||
"与正文组成对齐": "隐藏段段id / 定界约定；无隐藏段则写「仅用裁决包」",
|
||||
"语句形状": {
|
||||
"格式": "JSON行|键值列表|与 settlement 字段同构",
|
||||
"必填键": ["key", "delta|to"],
|
||||
"禁止": ["无键散文", "改未立真值"]
|
||||
},
|
||||
"生成要求": "主世界层每轮须输出可解析维护语句（哪怕本轮无变更也给空列表）",
|
||||
"示例": [
|
||||
{ "key": "好感", "delta": 8, "reason": "送礼成功" }
|
||||
],
|
||||
"程序侧": "Runtime 合并进 变量.当前；再跑 side_effects；非 chance toolcall"
|
||||
},
|
||||
"side_effects": [
|
||||
{
|
||||
"id": "affinity-romance",
|
||||
"field": "好感",
|
||||
"op": "gte",
|
||||
"value": 60,
|
||||
"mode": "once",
|
||||
"action": {
|
||||
"type": "replace_tag",
|
||||
"tag": "上下文.角色态度",
|
||||
"content": "恋爱档要点或「按映射id查当前档摘要」"
|
||||
}
|
||||
}
|
||||
],
|
||||
"旁观汇总意图": {
|
||||
"需要": "是|否",
|
||||
"汇总什么": "例：当前好感档性格要点 + 已触发 once 门",
|
||||
"建议tag": "上下文.旁观.状态摘要",
|
||||
"材料来自": ["Data映射索引", "投影tag", "真值字段"]
|
||||
},
|
||||
"不立变量的理由": ["…"]
|
||||
},
|
||||
"自评": {
|
||||
"维度": [
|
||||
{
|
||||
"名": "承重度",
|
||||
"分数": 0,
|
||||
"说明": "真值是否只覆盖必须跨轮记住的状态"
|
||||
},
|
||||
{
|
||||
"名": "可维护",
|
||||
"分数": 0,
|
||||
"说明": "维护语句是否可解析；映射索引是否接得上实例/规则"
|
||||
},
|
||||
{
|
||||
"名": "克制度",
|
||||
"分数": 0,
|
||||
"说明": "无派生可写格膨胀；无用 chance 冒充改表"
|
||||
}
|
||||
],
|
||||
"薄弱点": "一句话"
|
||||
},
|
||||
"追问": {
|
||||
"导语": "为钉准变量与维护，还需确认：",
|
||||
"题目": [
|
||||
{
|
||||
"问": "…",
|
||||
"建议选项": ["选项A", "选项B", "其它（请写明）"],
|
||||
"示例": "可选"
|
||||
}
|
||||
]
|
||||
},
|
||||
"开放问题": []
|
||||
}
|
||||
```
|
||||
|
||||
硬规则：
|
||||
1. context-fragment.v1 外壳；自评承重度/可维护/克制度。
|
||||
2. Data 映射索引可指向尚未生成的实例（标待补），但键与用途必须清。
|
||||
3. 维护语句约定必填；须声明通道与示例。
|
||||
4. side_effects 可 `[]`。禁止输出完整 workers[]。
|
||||
5. summary：`变量设计 · {brief 缩略}`。
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 每个变量是否有明确更新者与时机？
|
||||
- [ ] 是否与拓扑/表设计一致？
|
||||
- [ ] 真值有写入源与更新时机？
|
||||
- [ ] 映射索引指向规则/实例或标待补？旁观摘要键清楚？
|
||||
- [ ] 维护语句可解析且与正文组成/settlement 对齐？
|
||||
- [ ] 未把分档长文做成可写真值？未用 chance 当改表？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：
|
||||
- 好感真值 + 映射索引指向 concrete batch「分档性格」+ side_effect 投影态度 + 维护语句走 variable_changes。
|
||||
- 旁观汇总意图：只挂当前档「态度要点」，不挂整表。
|
||||
|
||||
坏：
|
||||
- 每轮让模型重写「当前性格」长字符串当真值。
|
||||
- 只写「好感会变」无维护语句形状。
|
||||
- 用 run_worker chance 来改好感。
|
||||
```
|
||||
|
||||
@@ -1,135 +1,147 @@
|
||||
# Worker 规格
|
||||
# 游玩拓扑
|
||||
|
||||
> 能力文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 写法说明：`docs/world-simulator-modules.md`；范例：`aesthetics-interaction`。
|
||||
> 可选默认契约见 `worker-templates/`（缺省合并用，非本步全文）。
|
||||
> **禁止自由发明执行单元。** 只从固定槽勾选；程序按 `play_slots` 展开 workers。
|
||||
> 方法：`docs/progressive-data-design.md`；模板：`worker-templates/`。
|
||||
|
||||
## meta
|
||||
|
||||
```meta
|
||||
name: Worker 规格
|
||||
name: 游玩拓扑
|
||||
id: worker-spec
|
||||
artifact: 设计.worker规格
|
||||
declaration: >
|
||||
钉一个游玩期执行单元（职责、读写、挂载）；多演员时可多次调用
|
||||
勾选固定游玩槽位（主世界层 / 叙事转述 / 可选角色视角 / 可选机遇裁定；写手路径为大纲+章节），
|
||||
禁止自由发明新的执行单元 ref
|
||||
when: |
|
||||
已能说出「游玩时谁上场做什么」，需要把某一个演员钉成可调度契约时；
|
||||
或多演员需分次钉清时（本能力可反复）。
|
||||
体验契约已大致清楚，需要决定游玩期启用哪些固定槽时；
|
||||
或要修订已勾选槽位（开/关 perspective、chance 等）时。
|
||||
when_not: |
|
||||
体验/机制仍混沌，还说不清删掉谁会坏体验时 → 先上游能力。
|
||||
已在收成「细化终稿」且只需合并已有规格时 → 交给细化终稿，勿重复问卷。
|
||||
体验/站位仍混沌 → 先美学纲领与交互范式。
|
||||
只需收成完整运行规格 → 交给细化终稿（本步只交槽位勾选）。
|
||||
不要用本步「发明」世界观/性格/变量专用执行单元。
|
||||
boundary: |
|
||||
本能力：一次（或本步焦点内）钉清一个游玩期执行单元：中文名、ref、职责、何时上场、读写 tag、验收点、为何需要。
|
||||
产物写入「设计.worker规格」（可含累积列表）；最终合并进「设计.worker集」由「细化终稿」完成。
|
||||
细化终稿：收成完整 Worker 集、表、常驻上下文；本步不假装交终稿。
|
||||
拓扑图谱：多演员依赖与数据流总图；本步可写本单元读写，不画全图。
|
||||
生成规则 / 叙事指南：规则与态度正文；本步只声明挂载哪些 tag，不重写全文。
|
||||
本能力：输出 play_slots（及写手路径的 writing_slots），可选覆盖挂载说明；不写完整 设计.worker集。
|
||||
细化终稿：按本步勾选展开 workers、合并常驻与 tables。
|
||||
变量设计 / 变量控制上下文：真值与投影，不是推理槽。
|
||||
机遇裁定（chance）：按需程序工具槽，不进每轮管线。
|
||||
叙事指南与故事推进：挂到转述槽（推进可兼挂主世界层）；世界/机制：挂到主世界层——本步只点名槽。
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
先点名「下一个要钉的演员」（一个即可）：
|
||||
游玩时用哪些固定槽？（只勾选，不要发明新角色名当「新系统」）
|
||||
|
||||
1. 中文称呼：TA 在游玩里叫什么？（例：世界推进、叙事转述、大纲、章节正文）
|
||||
2. 职责一句话：删掉 TA 会丢掉哪段体验？
|
||||
3. 何时上场：每轮？用户点名写章时？某条件触发？
|
||||
世界模拟类常见：
|
||||
1. 主世界层（裁决，几乎总要）——要 / 不要
|
||||
2. 叙事转述（写你看见的正文，几乎总要）——要 / 不要
|
||||
3. 角色视角（仅当有强秘密、不能进主世界层时）——要 / 不要（默认不要）
|
||||
4. 机遇裁定（骰子/抽签/比点等真随机，按需调用、不进每轮）——要 / 不要（默认不要；有战斗检定、抽签事件时建议开）
|
||||
|
||||
若你已有多个演员想法，先写最核心的一个；其余可再跑本能力。
|
||||
写手/扩写类常见：大纲/细纲 + 章节正文（固定两槽，同上只勾选）。
|
||||
|
||||
变量、性格分档、世界观：不是槽，后面用变量/世界等技能收进上下文。
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
你正在执行剧本中的「Worker 规格」步骤。产物写入「设计.worker规格」。
|
||||
你正在执行「游玩拓扑」。产物写入「设计.worker规格」。
|
||||
|
||||
一次 design-step 以钉清**一个**游玩期执行单元为主；若用户一次抛出多个且关系简单，可写入 `actors` 数组但须逐个写清 rationale，并在 summary 标明本步焦点。
|
||||
核心操作：让用户勾选固定槽，写成 `play_slots`（世界模拟）或 `writing_slots`（扩写）。**禁止**新建未在固定列表中的 ref。
|
||||
|
||||
固定 ref 白名单：
|
||||
- 世界模拟每轮：`world-simulator`（gm）、`narrator`、`role-decide`（perspective，默认关）
|
||||
- 世界模拟按需：`chance`（机遇裁定，默认关；invocation=on_demand）
|
||||
- 扩写：`outline`、`chapter-writer`
|
||||
- 禁止：`variable-update`、自造 kebab、为世界观/性格再拆槽
|
||||
|
||||
执行顺序：
|
||||
1. 读依赖产物与体验契约；正推「需要谁」——禁止题材默认演员套餐。
|
||||
2. 若已有「设计.worker规格」，增量：同 ref 更新；新 ref 追加；不要无故删除用户已验收条目（除非用户要求改）。
|
||||
3. 为该单元填写：name（中文）、ref（英文 kebab，可与 worker-templates 对齐）、duty、when、rationale、acceptance、context/outputs 建议。
|
||||
4. acceptance：面向用户的可读终稿倾向 `review`；纯中间裁决/整理倾向 `continue`；吃不准就 ask_user。
|
||||
5. ref 可参考包内模板（如 narrator、world-simulator、outline、chapter-writer），但必须以本局体验为准，勿强行两端都上。
|
||||
6. 输出符合 output 的 JSON。
|
||||
1. 读配方与体验契约，判断路径：世界模拟 vs 写手分段。
|
||||
2. 默认世界模拟：`gm: true, narrator: true, perspective: false, chance: false`；
|
||||
仅信息隔离才开 perspective；需要骰子/抽签/比点等真随机时开 chance。
|
||||
3. 写手路径：`outline` + `chapter-writer` 默认都开；用户明确只要正文则可关 outline。
|
||||
4. 可写简短 `mount_notes`（哪类上游产物挂哪槽），不粘贴长文。
|
||||
5. 输出 JSON。summary：`游玩拓扑 · gm+转述` 或 `游玩拓扑 · gm+转述+机遇` 等。
|
||||
|
||||
若程序已发出默认问题：禁止重复同一开场。
|
||||
|
||||
summary：`Worker 规格 · {中文名} · …`
|
||||
若程序已发默认问题：禁止重复同一开场；在首答上补洞。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 删掉检验：说不清「丢掉哪段体验」的演员不要。
|
||||
2. 正推：体验 → 手段 → 演员；禁止「世界模拟就一定要 world-simulator + narrator」。
|
||||
3. 写手/分段常见最小集：大纲/细纲（outline）+ 章节正文（chapter-writer）；按需加减。
|
||||
4. 扮演/世界推进常见：世界裁决 + 叙事转述；能合并则问用户是否合并。
|
||||
5. name 给人看，ref 给机器；二者成对出现。
|
||||
6. 本步不写完整表 schema、不写整份 Worker 集终稿。
|
||||
7. 常驻上下文挂载只点名「需要挂哪些已有产物 tag」，不在本步粘贴长文。
|
||||
1. 只勾选，不发明：ref 必须在白名单内。
|
||||
2. 默认少槽：世界模拟 = 主世界层 + 转述；perspective 默认关。
|
||||
3. 变量 / Data / Progressive 不是执行单元。
|
||||
4. 删掉检验仍适用：关某个槽要说得清损失什么。
|
||||
5. 本步不输出完整 Worker 集、不写 tables 全文（交给细化终稿 / 变量设计）。
|
||||
6. 可修订已有勾选，不要为「更聪明」加槽。
|
||||
```
|
||||
|
||||
## probe
|
||||
|
||||
```probe
|
||||
一轮 1～2 点。
|
||||
一次 1～2 点：
|
||||
|
||||
缺验收点：本演员产出是「给用户读的一段」还是「给下一演员的中间结果」？
|
||||
缺 ref：更接近包内哪个模板职责？（给中文选项，勿逼用户记英文）
|
||||
多演员纠结：能否合并成一个？合并会损失什么？
|
||||
写手路径：是否需要「先大纲后正文」两个演员，还是只要分段写手？
|
||||
- 正文是否必须由独立转述写？（不要则 gm 兼呈现，narrator=false——需用户明确）
|
||||
- 是否有「主世界层不该知道的角色秘密」？（有才 perspective=true）
|
||||
- 扩写：要不要先验大纲再写章？
|
||||
|
||||
不要问「还想加什么 Worker」。
|
||||
```
|
||||
|
||||
## output
|
||||
|
||||
```output
|
||||
{
|
||||
"brief": "一句话：本步钉的演员如何服务体验",
|
||||
"actors": [
|
||||
{
|
||||
"name": "叙事转述",
|
||||
"ref": "narrator",
|
||||
"duty": "…",
|
||||
"when": "…",
|
||||
"rationale": "删掉则…",
|
||||
"acceptance": "review",
|
||||
"context": {
|
||||
"static": ["设计.worker集"],
|
||||
"dynamic": ["用户.最新输入"]
|
||||
},
|
||||
"outputs": ["输出.用户展示"],
|
||||
"presentation": {
|
||||
"tone": "可选；转述类可填"
|
||||
}
|
||||
}
|
||||
"brief": "一句话：本局启用哪些固定槽",
|
||||
"path": "world_sim|writing",
|
||||
"play_slots": {
|
||||
"gm": true,
|
||||
"narrator": true,
|
||||
"perspective": false,
|
||||
"chance": false
|
||||
},
|
||||
"writing_slots": {
|
||||
"outline": true,
|
||||
"chapter_writer": true
|
||||
},
|
||||
"mount_notes": [
|
||||
"叙事指南与故事推进 → narrator（推进兼 gm）",
|
||||
"世界/机制/变量规则 → gm",
|
||||
"真随机检定 → chance（按需）",
|
||||
"真值与 side_effects → 细化终稿 tables"
|
||||
],
|
||||
"增量说明": "相对旧稿新增/改了哪个 ref",
|
||||
"开放问题": ["…"]
|
||||
"开放问题": []
|
||||
}
|
||||
```
|
||||
|
||||
`acceptance` 只能是 `review` 或 `continue`。未知字段省略。
|
||||
填写规则：
|
||||
- `path=world_sim` 时必须有 `play_slots`；`writing_slots` 可省略。
|
||||
- `path=writing` 时必须有 `writing_slots`；`play_slots` 可省略。
|
||||
- `chance` 缺省视为 false；为 true 时不进每轮序，仅可按需调度。
|
||||
- 不要输出自造 `actors[]` / 自由 `workers[]`。
|
||||
- 旧产物若含 `actors[]`：本步应改写为槽位勾选，不再追加自定义 ref。
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 每个演员能否通过删掉检验？
|
||||
- [ ] name/ref 是否成对？acceptance 是否写出？
|
||||
- [ ] 是否误交完整 设计.worker集 或表结构？
|
||||
- [ ] 是否题材默认套演员？
|
||||
- [ ] 增量是否误删已有条目？
|
||||
- [ ] 是否只有白名单槽，无自造 ref？
|
||||
- [ ] perspective / chance / 只要正文等非常规选择是否有理由？
|
||||
- [ ] 是否误把变量管理做成槽？是否误把 chance 当成每轮 LLM？
|
||||
- [ ] 是否误交完整 设计.worker集？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好：
|
||||
- 扩写：先钉「大纲/细纲」outline（continue 或 review 按用户是否要验大纲），再另一步钉「章节正文」chapter-writer（review）。
|
||||
- 扮演：世界推进 continue + 叙事转述 review。
|
||||
- play_slots: gm+narrator，perspective/chance false；mount_notes 一行。
|
||||
- 有凶手真名不能进 GM：perspective true，并说明只出反应建议。
|
||||
- 需要检定/抽签：chance true（按需程序工具）。
|
||||
|
||||
坏：
|
||||
- 一次甩出 8 个演员且无 rationale
|
||||
- 只写英文 id 给用户看
|
||||
- 本步直接输出整份 version:1 Worker 集冒充终稿
|
||||
- actors 里发明 affinity-manager、lore-keeper、dice-master（LLM）。
|
||||
- 为性格分档再拆一个执行单元。
|
||||
```
|
||||
|
||||
@@ -1,36 +1,35 @@
|
||||
# 世界蓝图与人文地理
|
||||
# 舞台骨架
|
||||
|
||||
> 能力文档。程序只切割下方 **fence 块**（`meta` / `opening` / `task` / …）；`##` 标题仅供人读。
|
||||
> 写法说明：`docs/world-simulator-modules.md`；泛用规范：`docs/briefs/capability-authoring-brief.md`。
|
||||
> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 产物外壳：`docs/context-fragment-design.md`；范例：`aesthetics-interaction` / `mechanism`。
|
||||
|
||||
## meta
|
||||
|
||||
```meta
|
||||
name: 世界蓝图与人文地理
|
||||
name: 舞台骨架
|
||||
id: world-blueprint
|
||||
artifact: 设计.世界蓝图与人文地理
|
||||
artifact: 设计.舞台骨架
|
||||
declaration: >
|
||||
当体验需要可引用的「舞台背景」时使用：钉舞台尺度、熟悉基底与变造、
|
||||
关键格局与人文地理；只细化舞台上会出现的部分，不做设定百科或纸面地图
|
||||
体验需要可引用的舞台背景时：钉尺度、基底与变造、关键舞台区，以及社会结构与世界状况；
|
||||
只细化会上台的部分，不做地图或设定百科
|
||||
when: |
|
||||
体验契约（及可选的实现机制）已大致清楚，但仍不能回答：
|
||||
“这局故事发生在多大的舞台上？”
|
||||
“背景世界以什么大家熟悉的基底成立，又变在哪里？”
|
||||
“下游开局与生成需要引用哪些格局、势力或人文条件？”
|
||||
“这局发生在多大的舞台上？以什么基底成立、变在哪里？”
|
||||
“台上是谁在互动？世界以何种状况运转故事？”
|
||||
“下游要引用哪些舞台区、社会格局或世界状况？”
|
||||
when_not: |
|
||||
核心体验尚未钉清时，不用本能力代替「美学纲领与交互范式」发明想要什么感觉。
|
||||
只需识别体验支撑切面、不必展开环境与社会时，交给「实现机制」。
|
||||
需要可点名的人/地/物名片时，交给「具体实例」。
|
||||
需要内容如何持续生成或推进时，交给「生成规则」。
|
||||
用户只要轻设定回合、明确拒绝世界骨架时，不要排入。
|
||||
核心体验未钉清 → 先「美学纲领与交互范式」。
|
||||
只需识别体验支撑切面、不必展开环境与社会 → 「实现机制」。
|
||||
需要可点名的人/地/物名片 → 「具体实例」。
|
||||
需要内容如何持续生成 → 「生成规则」。
|
||||
用户只要轻设定、明确拒绝世界骨架 → 不要排入。
|
||||
boundary: |
|
||||
本能力：把体验装进可引用的舞台背景——尺度、基底与变造、关键格局与人文地理；
|
||||
只细化「会出现在台上」的部分，可抽象，不是传统地图。
|
||||
美学纲领与交互范式：体验是什么、用户怎么参与；本步不重定体验目标。
|
||||
实现机制：体验靠哪些切面成立；本步把其中世界侧支点展开成骨架，不重做支撑检验。
|
||||
具体实例：可点名的人/地/物条目；本步不定逐条名片与生平。
|
||||
生成规则：内容如何生成/推进；本步不定触发与节奏规则。
|
||||
叙事指南：怎么写、世界态度；本步不定文风与镜头。
|
||||
本技能：可引用舞台骨架——尺度、基底+变造、关键舞台区、社会结构、世界状况；产出 context-fragment.v1。
|
||||
不是地理志：凡影响核心运转且会上台的（生灵种类、势力、灾变、通道、习俗等）都落在社会结构或世界状况里。
|
||||
美学纲领与交互范式：体验与轮转——本步不重定。
|
||||
实现机制：承重切面——本步展开世界侧骨架，不重做移除检验。
|
||||
具体实例 / 生成规则 / 叙事指南与故事推进：名片、生成节奏、遣词与推进——本步不定。
|
||||
feeds: gm
|
||||
```
|
||||
|
||||
## opening
|
||||
@@ -38,13 +37,12 @@ boundary: |
|
||||
```opening
|
||||
先用几句话框住「这局会出现的背景舞台」（想到什么写什么）：
|
||||
|
||||
1. 舞台有多大？
|
||||
例：整个地球与大国博弈；一座城市；一所学校的几个系；
|
||||
也可以很抽象——「魔族与人族对峙割据的前线」，不必是真地图。
|
||||
1. 舞台有多大？熟悉基底是什么？变在哪里？
|
||||
例：一座城 / 一所学校几个系 / 「魔族与人族对峙的前线」（可抽象，不必真地图）。
|
||||
|
||||
2. 熟悉的基底是什么？变在哪里？
|
||||
例：现代都市，但没有国别之分；现代都市，但中美关系两极化；
|
||||
西方魔幻常见格局，但魔法极度稀缺……也可以只说基底，变点稍后补。
|
||||
2. 社会结构与世界状况里，什么在撑故事？
|
||||
例：人类与丧尸如何相处；每年寒灾；南极通往怪物世界的出口；村中活人祭祀……
|
||||
只点会影响核心运转、会反复碰到的，不写物种大全或民俗全书。
|
||||
|
||||
3. 真正会反复出现的舞台区是哪里？
|
||||
一句话即可——只点「会上台」的部分，其余可留黑。
|
||||
@@ -53,71 +51,61 @@ boundary: |
|
||||
## task
|
||||
|
||||
```task
|
||||
你正在执行剧本中的「世界蓝图与人文地理」步骤。本步产物写入「设计.世界蓝图与人文地理」。
|
||||
你正在执行「舞台骨架」。产物必须是 **context-fragment.v1** JSON，写入「设计.舞台骨架」。
|
||||
|
||||
这里的「蓝图」不是纸面地图，也不是设定集百科。它是**会出现在台上的背景内容**：空间可大可小、可具体可抽象，尺度完全由本局要展示的体验决定。
|
||||
钉的是**会出现在台上、影响故事核心运转的背景**——不只是地理：
|
||||
空间格局、谁在台上互动（社会结构）、世界如何运转（世界状况：灾变、通道、习俗、禁忌、命脉等）都属本步。
|
||||
不是纸面地图，也不是设定集百科。尺度由本局体验决定。
|
||||
|
||||
同一「现代都市」基底下：
|
||||
- 「体验作为韩国顶级财阀」→ 舞台往往是地球级势力、国家与资本网络；
|
||||
- 「体验普通大学生活」→ 舞台可能只是一座城，甚至一所学校的几个系。
|
||||
西方魔幻也可以只钉「魔族与人族对峙割据」这类格局，作为舞台布景，而不画完整大陆。
|
||||
|
||||
核心操作：在已确认的体验（及可选机制支点）之上，用「熟悉基底 + 变造」钉出可引用骨架，并只细化关键舞台区。
|
||||
核心操作：在已确认体验（及可选机制支点）之上，用「熟悉基底 + 变造」钉出可引用骨架；写清社会结构与世界状况；只细化关键舞台区。
|
||||
|
||||
执行顺序：
|
||||
1. 读取依赖产物与用户表述，提取已确认的核心体验、变造暗示、以及实现机制里属于世界侧的支点。只忠实继承，不重做美学或机制。
|
||||
2. 判定舞台尺度：本局背景需要「装得下」多大范围——以体验会碰到的边界为准，不是以题材惯例为准。
|
||||
3. 选定文化/世界基底（大家有印象的原型），再写清变点；变点优先服务体验与关键舞台，不为完整而扩写。
|
||||
4. 只展开关键舞台区的格局、势力/社群、人文地理要点；舞台外用「刻意留黑 / 继承常识」交代即可。
|
||||
5. 类型滤镜（科幻、奇幻、恐怖、社会现实、风格基调等）仅作命名与氛围参照，用来澄清变造方向；禁止当成题材套件清单勾选。
|
||||
6. 输出符合 output 契约的 JSON，供用户验收。
|
||||
1. 读依赖与用户表述，忠实继承体验与世界侧机制支点；不重做美学/机制。
|
||||
2. 判定舞台尺度：以体验会碰到的边界为准。
|
||||
3. 选定熟悉基底，写清变点。
|
||||
4. 钉「社会结构」：台上有哪些种类/势力/阶层在互动（种类级与格局级，非名片）。
|
||||
5. 钉「世界状况」：灾变、通道、祭祀、资源命脉、禁忌等——须能回答如何影响核心运转；软性日常条件也归此。
|
||||
6. 只展开关键舞台区；舞台外「刻意留黑」。
|
||||
7. 类型滤镜仅作体裁/氛围参照；禁止题材套件勾选。
|
||||
8. 填齐正文 + 自评 + 追问，输出 JSON。
|
||||
|
||||
工作姿态——「搭舞台，不写百科」：
|
||||
- 不问「这个世界完整长什么样」，问「玩家会反复看见/碰到什么背景」。
|
||||
- 能继承常识与基底默认的，不追问（已知现代 → 不问常规科技树，除非体验依赖变造）。
|
||||
- 可以把用户已表达但尚未整理的尺度与变造写成清晰骨架，请用户校正。
|
||||
- 两种舞台尺度会显著改变后续设定时，先辨明再展开，不要并行堆两套地图。
|
||||
工作姿态——「搭舞台，不写百科」：不问世界完整长什么样，问玩家会反复看见/碰到什么背景与运转部件。
|
||||
|
||||
若依赖产物内部仍有含混或矛盾，不要越权重做上一步。只询问会改变尺度、基底变造或关键舞台区的差异；无法在本步解决的写入「开放问题」。
|
||||
|
||||
若程序已发出默认问题：用户首答在「用户.worker答复」，开场白在「创作.能力开场白」。禁止重复同一开场；在首答与依赖产物上补洞。
|
||||
|
||||
summary：`世界蓝图与人文地理 · …`（点题尺度 + 基底变造，非题材标签）。
|
||||
若程序已发默认问题：禁止重复开场；在首答与依赖上补洞。
|
||||
summary：`舞台骨架 · …`（点题尺度 / 社会结构或世界状况）。
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
1. 舞台服务于体验
|
||||
尺度、格局、人文条件都必须能回答：它让哪段已确认体验得以发生或被感觉到？
|
||||
尺度、格局、社会结构、世界状况都必须能回答：它让哪段已确认体验得以发生或被感觉到？
|
||||
不能从题材标签反推「这类故事通常有完整大陆/完整国别」。
|
||||
|
||||
2. 蓝图 ≠ 地图 ≠ 百科
|
||||
可以是抽象格局（对峙、割据、阶层天井、一条街的生态）。
|
||||
不要求接壤关系、比例尺、全史年表、全物种志。
|
||||
下游需要点名条目时交给「具体实例」；本步给骨架与引用钩子即可。
|
||||
2. 骨架 ≠ 地图 ≠ 百科；社会与状况同等重要
|
||||
地理只是一类钩子。社会结构（谁在台上、如何分层互动）与世界状况（寒灾、异界出口、活人祭祀、命脉资源等）
|
||||
往往比「哪条河接哪座山」更能决定故事如何运转——必须写，但不能写成物种志/民俗全书。
|
||||
可以是抽象格局（对峙、割据、阶层天井）。不要求接壤比例尺、全史年表。
|
||||
下游需要点名条目时交给「具体实例」；本步给格局级与状况级引用钩子。
|
||||
|
||||
3. 变造基底，再按舞台细化
|
||||
优先路径：大家都有印象的基底世界 → 点明变在哪里 → 只细化关键舞台区。
|
||||
例：「现代都市，但没有国别之分」「现代都市，中美关系两极化」。
|
||||
优先路径：大家都有印象的基底世界 → 点明变在哪里 → 只细化关键舞台区与会撑故事的社会/状况条目。
|
||||
细化粒度跟舞台走：财阀博弈可写到国家/财团层；校园日常写到系馆与社团层即可。
|
||||
|
||||
4. 类型滤镜是叠加在基底上的体裁/氛围参照，不是必选题单
|
||||
可用于澄清「故事以何种体裁被讲述」，从而影响冲突模式与背景气质，例如：
|
||||
- 科幻/未来：硬科幻、太空歌剧、社会科幻、赛博/蒸汽/柴油/原子/生物/太阳朋克、卡带未来、钟表朋克…
|
||||
- 奇幻/超自然：高奇幻、剑与魔法、低魔、武侠/仙侠、都市奇幻、魔法现实主义、神话童话…
|
||||
- 恐怖/悬疑：哥特、宇宙恐怖、心理/肉体/生存恐怖、悬疑惊悚、灵异…
|
||||
- 社会/现实：历史、犯罪、黑色电影、西部、战争、谍战、冒险、日常、成长、言情、竞技…
|
||||
- 风格/基调：喜剧讽刺、乌托邦/反乌托邦、后末日、超级英雄、歌舞、剥削/Cult 等
|
||||
用法：用户已有印象或体验需要某一体裁气质时，用滤镜命名变造方向；
|
||||
可用于澄清「故事以何种体裁被讲述」，从而影响冲突模式与背景气质。
|
||||
禁止：列出大菜单请用户勾选；禁止因选了滤镜就自动塞满该类型常见地理与势力。
|
||||
|
||||
5. 与实现机制的分工
|
||||
机制已钉「世界侧支撑切面」时：本步展开其环境/社会骨架，不重做「如何支撑／缺了会怎样」。
|
||||
机制已钉「世界侧支撑切面」时：本步展开其环境/社会/状况骨架，不重做「如何支撑／缺了会怎样」。
|
||||
机制未排入时：仍可从体验直接推断最小舞台；不要假装已经做过支撑检验。
|
||||
|
||||
6. 宁少勿多，舞台外留黑
|
||||
关键舞台区写清即可停止。舞台外、体验碰不到的大洲/朝代/组织，默认不写。
|
||||
关键舞台区 + 撑故事的社会与状况写清即可停止。舞台外、体验碰不到的部分默认不写。
|
||||
「未展开范围」写明刻意省略，避免下游把留黑当成缺口去补百科。
|
||||
|
||||
7. 正推，禁止否定式路由
|
||||
@@ -126,161 +114,167 @@ summary：`世界蓝图与人文地理 · …`（点题尺度 + 基底变造，
|
||||
|
||||
8. 继承优先于发明
|
||||
基底已蕴含的常识默认成立；只在变点与体验依赖处显式改写。
|
||||
不要为显得严谨而补起源史、伪科学或全套神话谱系，除非它们本身就是舞台上会出现的背景。
|
||||
不要为显得严谨而补起源史、伪科学或全套神话谱系，除非它们本身会上台。
|
||||
```
|
||||
|
||||
## probe
|
||||
|
||||
```probe
|
||||
只追问会改变舞台尺度、基底变造、关键舞台区或人文格局的缺口。每轮 1～2 点。依赖产物或用户已答清的禁止重问。
|
||||
只追问会改变尺度、变造、社会结构、世界状况或台上格局的缺口。每轮 1～2 点。已答清的禁止重问。
|
||||
|
||||
【默认问题已覆盖】舞台大小、基底+变点、会反复出现的舞台区。首答后按缺口补，勿重问已答清的。
|
||||
【默认问题已覆盖】尺度、基底+变点、社会结构/世界状况、会反复出现的舞台区。首答后按缺口补。
|
||||
|
||||
优先方式：
|
||||
|
||||
1. 尺度对照
|
||||
用同一基底的两种舞台问差异。
|
||||
例：「同是现代都市——更接近『全国财阀与国家势力都在台上』，还是『基本不出这座城/这所学校』？」
|
||||
|
||||
2. 变造落句
|
||||
把模糊变点收成可引用短句，请用户改一个词即可采用。
|
||||
例：「是否可以写成：现代都市基底，但国家边界弱化到几乎无国别，冲突主要在公司与城市场景里发生？」
|
||||
|
||||
3. 关键舞台区边界
|
||||
问「会反复上台」的部分，而不是「世界还有什么」。
|
||||
例：「真正会反复出现的，是总部—宴会—监管听证这几类场合，还是还要经常切到海外子公司现场？」
|
||||
3. 社会与状况核对
|
||||
例：「台上互动方是否就是『人类 + 无攻击欲的丧尸』？还有没有别的智能方会影响你的掌控？」
|
||||
例：「『每年寒灾』是全局运转的硬时钟，还是只在边陲传说？祭祀是真要死人，还是可被你改写的习俗？」
|
||||
|
||||
4. 滤镜澄清（可选）
|
||||
仅当体裁气质会改变背景冲突模式时才问；给 2～3 个完整句，不给类型树勾选。
|
||||
例：「背景更偏赛博朋克式的巨企夜城，还是偏社会科幻式的制度压迫（科技外表不重要）？」
|
||||
4. 关键舞台区边界
|
||||
例：「真正会反复出现的，是总部—宴会—监管听证，还是还要经常切到海外子公司现场？」
|
||||
|
||||
5. 机制支点落地
|
||||
若上游机制点了世界侧切面，问它在舞台上长什么样。
|
||||
例：「『信息被巨企垄断』在台上主要体现为哪几个可见势力/场所，而不是再解释一遍为何垄断支撑体验。」
|
||||
5. 滤镜澄清 / 机制落地（可选）
|
||||
体裁气质会改变冲突模式时才问滤镜；机制已点世界侧切面时，问它在台上长什么样，不重做支撑检验。
|
||||
|
||||
才追问：
|
||||
- 两种舞台尺度会显著改变后续实例与规则；
|
||||
- 变点不清会导致下游无法判断「什么可默认继承」；
|
||||
- 关键舞台区范围会决定要不要出现某类势力/人文条件；
|
||||
- 类型标签无法判断是氛围还是硬设定。
|
||||
才追问：两种尺度会显著改变后续；变点/社会/状况不清会改核心运转；关键舞台区范围决定要否某类势力；类型标签分不清氛围与硬设定。
|
||||
|
||||
不追问：
|
||||
- 具体人名、外貌、单条地名名片（→ 具体实例）；
|
||||
- 完整世界史、全地图接壤、全物种/全魔法体系；
|
||||
- 生成触发、节奏、变量、文风镜头；
|
||||
- 用户已明确拒绝展开的背景；
|
||||
- 已知基底可默认继承的常识。
|
||||
不追问：具体名片（→ 具体实例）；完整物种志/民俗志/世界史/全地图；生成/变量/文风；用户已拒绝展开的背景；基底可默认继承的常识。
|
||||
```
|
||||
|
||||
## output
|
||||
|
||||
```output
|
||||
最终只输出一个合法 JSON 对象，不加代码块外说明，不使用注释，不夹带未定义的英文 id。
|
||||
|
||||
{
|
||||
"依据的体验": [
|
||||
"从依赖产物忠实提取的体验锚点；可附带与舞台相关的机制支点名称"
|
||||
],
|
||||
"舞台尺度": {
|
||||
"范围": "一句话：地球级 / 国家 / 城市 / 机构内部 / 抽象割据带 / …",
|
||||
"为何如此": "与核心体验的关系：为什么需要这么大或这么小",
|
||||
"玩家常活动边界": "体验中反复碰到的空间/社会边界（可抽象）"
|
||||
},
|
||||
"基底与变造": {
|
||||
"基底": "大家都有印象的原型世界或文化骨架（如现代都市、西方高奇幻常见格局、近未来地球…）",
|
||||
"变点": [
|
||||
"相对基底改了什么；每条宜短、可引用"
|
||||
"schema": "context-fragment.v1",
|
||||
"技能": "舞台骨架",
|
||||
"brief": "一句话：舞台多大 + 社会/状况如何撑故事",
|
||||
"mount": ["world-simulator"],
|
||||
"稳变": "stable",
|
||||
"正文": {
|
||||
"依据的体验": [
|
||||
"从依赖产物忠实提取；可附带与舞台相关的机制支点名"
|
||||
],
|
||||
"类型滤镜": "可选：体裁/氛围参照名；无则空字符串。说明其如何影响背景气质，勿展开类型百科",
|
||||
"默认可继承": "基底下可默认成立、本步不写的常识范围（一句话）"
|
||||
"舞台尺度": {
|
||||
"范围": "地球级 / 国家 / 城市 / 机构内部 / 抽象割据带 / …",
|
||||
"为何如此": "与核心体验的关系",
|
||||
"玩家常活动边界": "反复碰到的空间或社会边界（可抽象）"
|
||||
},
|
||||
"基底与变造": {
|
||||
"基底": "大家都有印象的原型（现代都市、西方高奇幻常见格局…）",
|
||||
"变点": ["相对基底改了什么；每条宜短、可引用"],
|
||||
"类型滤镜": "可选体裁/氛围参照名；无则空字符串",
|
||||
"默认可继承": "基底下可默认成立、本步不写的常识范围（一句话）"
|
||||
},
|
||||
"社会结构": [
|
||||
{
|
||||
"名称": "种类/势力/阶层/阵营等格局级称呼——不是具体名片",
|
||||
"性质": "智慧生灵种类|国家/财团|院系|帮派|阵营|阶层|其它",
|
||||
"在舞台上的位置": "玩家如何碰到；相对权力/危险/依赖/互动方式",
|
||||
"服务体验": "它让什么感觉或规则成立",
|
||||
"细化程度": "点到为止|需要下游实例化|本步已够用"
|
||||
}
|
||||
],
|
||||
"世界状况": [
|
||||
{
|
||||
"名称": "影响核心运转或台上氛围的状况条目",
|
||||
"性质": "周期性灾变|异界/通道|祭祀习俗|资源命脉|禁忌律法|日常节奏|话语禁忌|其它",
|
||||
"是什么": "最短可引用描述（例：每年寒灾；南极通往怪物世界的出口；村中活人祭祀）",
|
||||
"如何影响运转": "它怎样推动、限制或框住故事与体验；软条件也可写「塑造氛围/日常感」",
|
||||
"节奏或触发": "年周期 / 可往返 / 日常默认…；不明则「未定」",
|
||||
"作用范围": "全局|仅某舞台区",
|
||||
"服务体验": "对应哪段体验或机制支点"
|
||||
}
|
||||
],
|
||||
"关键舞台区": [
|
||||
{
|
||||
"名称": "会反复上台的区/层/格局名",
|
||||
"是什么": "空间、社会层或抽象舞台的最短描述",
|
||||
"为何需要": "服务哪段体验或哪个机制支点",
|
||||
"格局要点": ["与社会结构/世界状况如何交汇——只写台上用得上的"]
|
||||
}
|
||||
],
|
||||
"未展开范围": [
|
||||
"刻意留黑或仅继承常识；禁止下游当缺口补百科"
|
||||
],
|
||||
"覆盖检验": {
|
||||
"关键骨架是否够用": "是|否|部分",
|
||||
"说明": "玩家会反复碰到的社会与状况是否已有钩子",
|
||||
"宁少勿多说明": "为何到此停止"
|
||||
}
|
||||
},
|
||||
"关键舞台区": [
|
||||
{
|
||||
"名称": "会反复上台的区/层/格局名",
|
||||
"是什么": "空间、社会层或抽象舞台的最短描述",
|
||||
"为何需要": "服务哪段体验或哪个机制支点",
|
||||
"格局要点": [
|
||||
"势力、场所类型、流通关系、可见冲突等——只写台上用得上的"
|
||||
]
|
||||
}
|
||||
],
|
||||
"势力与社群": [
|
||||
{
|
||||
"名称": "…",
|
||||
"性质": "国家/财团/院系/帮派/种族阵营/阶层…",
|
||||
"在舞台上的作用": "玩家会如何感到它的存在",
|
||||
"细化程度": "点到为止｜需要下游实例化｜本步已够用"
|
||||
}
|
||||
],
|
||||
"人文地理要点": [
|
||||
{
|
||||
"要点": "习俗、阶层、话语、禁忌、日常节奏、资源分布等可引用条件",
|
||||
"服务体验": "它让什么感觉成立",
|
||||
"作用范围": "仅关键舞台区｜全局默认"
|
||||
}
|
||||
],
|
||||
"未展开范围": [
|
||||
"刻意留黑或仅继承常识、禁止下游当缺口补百科的部分"
|
||||
],
|
||||
"开放问题": [
|
||||
{
|
||||
"问题": "尚不能可靠确定、且会影响尺度/变造/关键舞台的问题",
|
||||
"影响": "不确定性会改变什么",
|
||||
"当前暂定": "可撤销的暂定理解；没有则空字符串"
|
||||
}
|
||||
]
|
||||
"自评": {
|
||||
"维度": [
|
||||
{
|
||||
"名": "覆盖度",
|
||||
"分数": 0,
|
||||
"说明": "能否覆盖用户已表达的舞台/社会/状况/变造硬要求"
|
||||
},
|
||||
{
|
||||
"名": "充分度",
|
||||
"分数": 0,
|
||||
"说明": "骨架是否够下游引用，并撑起用户想要的体验发生与运转"
|
||||
},
|
||||
{
|
||||
"名": "克制度",
|
||||
"分数": 0,
|
||||
"说明": "是否只写会上台部分；无地图百科、物种志、民俗全书膨胀"
|
||||
}
|
||||
],
|
||||
"薄弱点": "一句话"
|
||||
},
|
||||
"追问": {
|
||||
"导语": "为钉准舞台骨架，还需确认：",
|
||||
"题目": [
|
||||
{
|
||||
"问": "…",
|
||||
"建议选项": ["选项A（可带短场景）", "选项B", "其它（请写明）"],
|
||||
"示例": "可选示范句"
|
||||
}
|
||||
]
|
||||
},
|
||||
"开放问题": []
|
||||
}
|
||||
|
||||
填写规则：
|
||||
- 「依据的体验」只建追溯，不得扩写成新的美学纲领或机制表。
|
||||
- 「舞台尺度」必须能用体验解释；禁止「这类题材一般都这样」。
|
||||
- 「变点」为空数组仅当用户明确只要纯基底且无变造；否则至少标「未定」于开放问题。
|
||||
- 「关键舞台区」只含会上台的部分；不要为对称补齐未上场区域。
|
||||
- 「势力与社群」「人文地理要点」无则空数组；有则每条写清舞台作用，禁止百科句。
|
||||
- 「类型滤镜」不得连带输出该类型常见元素清单。
|
||||
- 「未展开范围」建议填写，防止下游过度补全。
|
||||
- 不要输出具体实例名片、生成规则、变量表、叙事文风或演员规格。
|
||||
|
||||
本步完成的定义：
|
||||
- 舞台尺度已能被体验解释；
|
||||
- 基底与变造可被下游引用（或明确未定）；
|
||||
- 关键舞台区已覆盖玩家会反复碰到的背景；
|
||||
- 舞台外留黑已交代；
|
||||
- 剩余点名条目属于「具体实例」，生成方式属于「生成规则」。
|
||||
```
|
||||
|
||||
硬规则（公共三段 + 本技正文）：
|
||||
1. 合法 JSON；必含 `schema` / `技能` / `brief` / `正文` / `自评` / `追问`（题目可 `[]`）。
|
||||
2. **公共三段**：正文＝舞台主体；自评＝覆盖度/充分度/克制度；追问＝导语+建议选项。
|
||||
3. **本技正文**须含：依据体验、舞台尺度、基底与变造、**社会结构**、**世界状况**、关键舞台区、未展开范围、覆盖检验。
|
||||
4. 社会结构＝谁在台上互动（种类/势力/阶层，格局级）；世界状况＝世界如何运转（灾变/通道/习俗等硬部件 + 日常软条件）。无则空数组，但须在覆盖检验说明「为何无需」。
|
||||
5. `mount` 默认主世界层；**禁止**写 `order`。`稳变` 多为 `stable`。
|
||||
6. 不要输出具体实例名片、物种大全、民俗全书、生成规则、变量表、执行单元列表。
|
||||
7. summary：`舞台骨架 · {brief 缩略}`。
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 尺度是否由体验决定（而非题材默认地图）？
|
||||
- [ ] 是否采用「基底 + 变造」，且变点可引用？
|
||||
- [ ] 是否只细化关键舞台区，舞台外有「未展开范围」？
|
||||
- [ ] 有无写成设定百科、接壤全图或完整世界史？
|
||||
- [ ] 类型滤镜若出现，是否只作氛围/体裁参照而非套件勾选？
|
||||
- [ ] 与美学／机制是否矛盾或越权重做？
|
||||
- [ ] 是否误写成具体实例名单或生成规则？
|
||||
- [ ] 开放问题是否都真正影响本步结论（无则空）？
|
||||
- [ ] 含 schema / brief / 正文 / 自评 / 追问？
|
||||
- [ ] 自评为覆盖度 / 充分度 / 克制度？
|
||||
- [ ] 尺度由体验决定？基底+变造可引用？
|
||||
- [ ] 社会结构与世界状况已写（或空数组且说明无需）？硬状况能说清如何影响运转？
|
||||
- [ ] 只细化关键舞台区，且有未展开范围？
|
||||
- [ ] 未写成地图百科、物种志、民俗全书、类型勾选菜单、具体名片？
|
||||
- [ ] 追问只打尺度/社会/状况/变造缺口，带建议选项？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
好 · 尺度随体验收缩：
|
||||
- 体验「普通大学生活」→ 舞台＝一所大学的几个系与周边街区；基底＝现代都市校园；变点可无或很轻；未展开＝国家政治与国际局势。
|
||||
- 体验「作为韩国顶级财阀」→ 同属现代都市基底，但舞台升到财阀—国家—跨国资本；关键舞台区＝董事会、政商宴、舆论与监管场合。
|
||||
|
||||
好 · 抽象舞台：
|
||||
- 「魔族与人族对峙割据」作为关键舞台区名称；格局要点写前线、禁忌地带、两边话语；不画大陆全图。
|
||||
|
||||
好 · 变造落句：
|
||||
- 基底「现代都市」；变点「几乎无国别之分，冲突在城市与公司层发生」；或「中美关系两极化渗入日常消费与舆论」。
|
||||
|
||||
好 · 滤镜作参照：
|
||||
- 类型滤镜＝「赛博朋克气质」；说明＝巨企与霓虹夜城压迫感；不自动追加义体市场、全部帮派地图。
|
||||
好：
|
||||
- 体验「普通大学生活」→ 舞台＝校园几系；社会结构＝师生/社团层；世界状况可轻；未展开＝国家政治。
|
||||
- 体验「垄断粮食的末日支配」→ 社会结构＝人类 + 无攻击欲丧尸 + 楼内依赖关系；世界状况＝外出采集命脉；舞台区＝楼内安全区 / 楼外采集区。
|
||||
- 世界状况示例：每年寒灾；南极通往怪物世界的出口；村中活人祭祀。
|
||||
- 抽象：「魔族与人族对峙割据」——社会结构两种阵营；不画大陆全图。
|
||||
|
||||
坏：
|
||||
- 「先写完整七大国、货币史、三万年神话…」→ 百科，无舞台优先。
|
||||
- 「选一个类型：硬科幻/太空歌剧/赛博朋克/…（全表）」→ 题材套件菜单。
|
||||
- 「因为是日常所以不要任何社会结构」→ 否定式路由；日常也可以有系馆权力与阶层天井。
|
||||
- 「地点1：XX咖啡馆，店主叫…」→ 具体实例，不是蓝图骨架。
|
||||
- 只写山脉河流，不写祭祀/灾变/异界口等用户已点名的运转部件。
|
||||
- 「先写完整七大国、五十种魔族生态、三万年神话…」→ 百科。
|
||||
- 「地点1：XX咖啡馆，店主叫…」→ 具体实例，不是骨架。
|
||||
- 整份只有散文无三段外壳。
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user