完善配方驱动的创作编排
为可重复技能补充参数校验与展示，统一配方、编排器和执行单元术语。 Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
moran
@@ -1,6 +1,7 @@
|
||||
# 生成规则
|
||||
|
||||
> **状态：待完善** — 块格式见 `docs/world-simulator-modules.md`；范例见 `aesthetics-interaction`。
|
||||
> 能力文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。
|
||||
> 写法说明：`docs/world-simulator-modules.md`；范例：`aesthetics-interaction`。
|
||||
|
||||
## meta
|
||||
|
||||
@@ -8,53 +9,184 @@
|
||||
name: 生成规则
|
||||
id: generation-rules
|
||||
artifact: 设计.生成规则
|
||||
declaration: 钉内容如何生成/推进的可执行规则（触发、约束、节奏），非散文设定
|
||||
when: 需要把「世界怎么动、内容怎么长出来」写成可执行约束时
|
||||
when_not: 仍在谈体验感受、尚未需要可执行规则时
|
||||
declaration: >
|
||||
仅为重要且模型无法仅凭世界基底稳定生成的同类内容，定义可执行的生成规则、
|
||||
严格数据格式与生命周期；可按生成对象反复调用
|
||||
when: |
|
||||
上游体验、机制与世界基底已足以判断某类内容：
|
||||
1. 它对实际游玩非常重要；并且
|
||||
2. 模型仅凭现有上下文无法稳定产出符合期待、彼此一致且可供下游使用的结果。
|
||||
两项同时成立时，才为该类对象建立专门生成规则。
|
||||
when_not: |
|
||||
内容虽重要，但凭世界基底与常识即可稳定生成 → 不调用。
|
||||
内容难生成，但只是装饰、偶尔出现或删掉不影响核心体验 → 不调用。
|
||||
只想预先写一个普通人/地/物，且不需要先建立专门格式与生成约束 → 不调用。
|
||||
只需定义变量在游玩中如何更新 → 变量设计与更新规则。
|
||||
只需定义剧情、章节或世界如何推进 → 交给对应 Worker 或其它推进能力，不借本步泛化。
|
||||
boundary: |
|
||||
本能力：触发、约束、节奏、可否随机等可执行规则。
|
||||
变量设计与更新规则：字段与何时改值。
|
||||
实现机制：落到哪些 worker/表来执行这些规则。
|
||||
```
|
||||
|
||||
## opening
|
||||
|
||||
```opening
|
||||
本能力：为“一类格式相近的内容”定义生成合同，包括生成依据、字段 schema、
|
||||
枚举值、数值上下界、约束、随机维度、校验方式与规则生命周期。
|
||||
生成对象不限于人物，也可为怪物、装备、任务、职业、组织、事件等。
|
||||
具体实例：执行本步中要求预生成的规则，产出符合合同的实际记录；本步不填实例数据。
|
||||
世界蓝图与人文地理：提供可直接依赖的世界基底；本步不重写世界百科。
|
||||
实现机制：说明某类内容为何支撑体验；本步先验证其必要性，再定义怎么生成。
|
||||
变量设计与更新规则：定义游玩期状态如何变化；本步只约束实例生成时的数据类型与初始合法范围。
|
||||
Worker 规格 / 细化终稿：决定谁在游玩期执行、哪些产物进入常驻上下文；本步只声明所需生命周期。
|
||||
```
|
||||
|
||||
## task
|
||||
|
||||
```task
|
||||
钉清生成与推进规则，写入 设计.生成规则。须可被下游 worker/程序引用，禁止只写散文氛围。
|
||||
（待作者细写）
|
||||
你正在执行剧本中的「生成规则」步骤。产物写入「设计.生成规则」。
|
||||
|
||||
本步不是泛用写作建议，也不是“凡是重要就做一张表”。调用目标已由编排期写入【本步参数】（至少含 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。规则本身不得夹带实际实例。
|
||||
|
||||
若程序已发出默认问题：用户首答在「用户.worker答复」。禁止重复同一开场。只追问会改变必要性、生命周期或 schema 的信息。
|
||||
|
||||
summary：
|
||||
- 建立规则：`生成规则 · {生成对象} · {仅动态|仅预生成|预生成并动态}`
|
||||
- 不建立规则：`生成规则 · {生成对象} · 无需专门规则`
|
||||
```
|
||||
|
||||
## principles
|
||||
|
||||
```principles
|
||||
可执行优于文采；与体验禁忌对齐。
|
||||
1. 双门槛：必须“对游玩重要”且“基础上下文不足以稳定生成”同时成立。
|
||||
2. 反表格冲动：核心玩法是古董拍卖，不代表纯现代背景中的普通古董必须有专门规则；常识足够时直接生成。
|
||||
3. 一规则一对象族：怪物与装备若 schema、约束和用途不同，分次调用；不要做万能内容生成器。
|
||||
4. 格式也是规则：字段名、类型、枚举、上下界、嵌套结构与必填性都必须可校验。
|
||||
5. 生命周期先行：是否预生成、规则最终是否保留，必须在生成实例前决定。
|
||||
6. 规则服务差异：只固定影响体验和接口的字段；不要把所有可描写细节都结构化。
|
||||
7. 可追溯：每项关键约束应能指向世界基底、实现机制、体验禁忌或用户明确要求。
|
||||
8. 不混淆状态更新：好感度可在实例 schema 中规定为有界数字；何时增减、如何结算属于变量设计。
|
||||
```
|
||||
|
||||
## probe
|
||||
|
||||
```probe
|
||||
（待作者细写）
|
||||
一轮 askUser 1～2 点；优先问会改变结论的分叉。禁止重问【本步参数】已钉的 target / rule_id。
|
||||
|
||||
必要性不明：如果不做专门规则、只让模型按世界设定直接生成，最可能出现的不可接受结果是什么？
|
||||
生命周期不明且 params 未给：这些实例需要每局变化、固定为开局设定，还是固定一批后仍要继续随机补充？
|
||||
枚举不明：这个字段只能从哪些世界内类别中选择？是否允许“其它”？
|
||||
数值不明：上下界分别代表什么，生成时是否允许取到边界？
|
||||
数量不明：需要固定数量，还是由场景/规模决定？允许范围是多少？
|
||||
|
||||
若用户的答案证明双门槛不成立，直接建议跳过，不再追问 schema。
|
||||
```
|
||||
|
||||
## 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": {}
|
||||
}
|
||||
}
|
||||
},
|
||||
"生成步骤": ["按什么顺序决定字段，如何利用上游依据"],
|
||||
"硬约束": ["任何实例都不得违反的条件"],
|
||||
"字段间约束": ["例：阵营=A 时，权限等级不得低于 3"],
|
||||
"变化维度": ["允许随机或变化的部分；不需要随机则为空"],
|
||||
"禁止项": ["即使随机抽到也不得出现的组合或内容"],
|
||||
"去重规则": ["同批及跨批如何避免同质化或重复"],
|
||||
"校验": ["类型、枚举、边界、世界一致性与体验一致性检查"]
|
||||
}
|
||||
],
|
||||
"增量说明": "相对已有规则新增或修改了什么",
|
||||
"开放问题": ["仅保留会阻止规则执行的问题"]
|
||||
}
|
||||
|
||||
当结论为「无需专门规则」时，省略 `rules`，并在 `brief` 中说明应直接依赖哪些现有世界基底生成。
|
||||
schema 中只保留实际字段适用的类型属性：例如非枚举字段不写 `allowed_values`，非数字字段不写 `minimum/maximum`。
|
||||
```
|
||||
|
||||
## checklist
|
||||
|
||||
```checklist
|
||||
- [ ] 规则是否可被执行/检查，而非纯描写？
|
||||
- [ ] 是否与体验边界禁忌冲突？
|
||||
- [ ] 重要性与基础生成不足是否分别举证，且两项都成立？
|
||||
- [ ] 是否因为“玩法重要”就误给常识足够的内容建表？
|
||||
- [ ] 生命周期是否在三种模式中明确唯一，布尔策略与之相符？
|
||||
- [ ] 每个字段是否有明确类型、必填性和语义？
|
||||
- [ ] enum 是否给全允许值与含义，数字是否给上下界，嵌套类型是否定义完整？
|
||||
- [ ] 是否写清字段间约束、禁止项、去重与校验？
|
||||
- [ ] 是否把实际实例、变量更新规则、剧情推进规则或 Worker 规格混入本步？
|
||||
- [ ] 是否只覆盖本轮对象族，并保留其它已有 rule_id？
|
||||
```
|
||||
|
||||
## examples
|
||||
|
||||
```examples
|
||||
应建立：
|
||||
- 怪物是核心战斗资源，需要每局变化，且世界有独特生态与战斗接口；使用 `runtime_only`，固定属性 schema、生态枚举、数值边界与组合禁忌。
|
||||
- 单女主必须承载特定关系体验，直接写人设容易遗漏关键切面；使用 `seed_only`，下一步生成女主后丢弃规则。
|
||||
- 重要 NPC 需要开局已有一批，后续也会随地区开放继续出现；使用 `seed_and_runtime`。
|
||||
|
||||
不应建立：
|
||||
- 纯现代都市拍卖玩法中的普通古董；即使古董很重要，只要现实常识与世界基底足以直接生成，就不值得专门维护规则。
|
||||
- 只在背景里出现一次的路边摊菜单；即使模型可能写得普通，也不影响核心体验。
|
||||
|
||||
坏：
|
||||
- 只写“人物要立体、装备要有趣”，没有 JSON schema 与可校验约束。
|
||||
- 枚举字段写“阵营：字符串”，却不生成允许的阵营项。
|
||||
- 好感度写“0～100”，又在本步编写每轮加减公式，侵入变量更新能力。
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user