writing-agent/skills/dialogue/world-simulator/modules/generation-rules/prompt.md

生成规则

能力文档。程序只切割下方 fence 块；## 标题仅供人读。
写法说明：docs/world-simulator-modules.md；范例：aesthetics-interaction。

meta

name: 生成规则
id: generation-rules
artifact: 设计.生成规则
declaration: >
  仅为重要且模型无法仅凭世界基底稳定生成的同类内容，定义可执行的生成规则、
  严格数据格式与生命周期；可按生成对象反复调用
when: |
  上游体验、机制与世界基底已足以判断某类内容：
  1. 它对实际游玩非常重要；并且
  2. 模型仅凭现有上下文无法稳定产出符合期待、彼此一致且可供下游使用的结果。
  两项同时成立时，才为该类对象建立专门生成规则。
when_not: |
  内容虽重要，但凭世界基底与常识即可稳定生成 → 不调用。
  内容难生成，但只是装饰、偶尔出现或删掉不影响核心体验 → 不调用。
  只想预先写一个普通人/地/物，且不需要先建立专门格式与生成约束 → 不调用。
  只需定义变量在游玩中如何更新 → 变量设计与更新规则。
  只需定义剧情、章节或世界如何推进 → 交给对应 Worker 或其它推进能力，不借本步泛化。
boundary: |
  本能力：为“一类格式相近的内容”定义生成合同，包括生成依据、字段 schema、
  枚举值、数值上下界、约束、随机维度、校验方式与规则生命周期。
  生成对象不限于人物，也可为怪物、装备、任务、职业、组织、事件等。
  具体实例：执行本步中要求预生成的规则，产出符合合同的实际记录；本步不填实例数据。
  世界蓝图与人文地理：提供可直接依赖的世界基底；本步不重写世界百科。
  实现机制：说明某类内容为何支撑体验；本步先验证其必要性，再定义怎么生成。
  变量设计与更新规则：定义游玩期状态如何变化；本步只约束实例生成时的数据类型与初始合法范围。
  Worker 规格 / 细化终稿：决定谁在游玩期执行、哪些产物进入常驻上下文；本步只声明所需生命周期。

task

你正在执行剧本中的「生成规则」步骤。产物写入「设计.生成规则」。

本步不是泛用写作建议，也不是“凡是重要就做一张表”。调用目标已由编排期写入【本步参数】（至少含 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

1. 双门槛：必须“对游玩重要”且“基础上下文不足以稳定生成”同时成立。
2. 反表格冲动：核心玩法是古董拍卖，不代表纯现代背景中的普通古董必须有专门规则；常识足够时直接生成。
3. 一规则一对象族：怪物与装备若 schema、约束和用途不同，分次调用；不要做万能内容生成器。
4. 格式也是规则：字段名、类型、枚举、上下界、嵌套结构与必填性都必须可校验。
5. 生命周期先行：是否预生成、规则最终是否保留，必须在生成实例前决定。
6. 规则服务差异：只固定影响体验和接口的字段；不要把所有可描写细节都结构化。
7. 可追溯：每项关键约束应能指向世界基底、实现机制、体验禁忌或用户明确要求。
8. 不混淆状态更新：好感度可在实例 schema 中规定为有界数字；何时增减、如何结算属于变量设计。

probe

一轮 askUser 1～2 点；优先问会改变结论的分叉。禁止重问【本步参数】已钉的 target / rule_id。

必要性不明：如果不做专门规则、只让模型按世界设定直接生成，最可能出现的不可接受结果是什么？
生命周期不明且 params 未给：这些实例需要每局变化、固定为开局设定，还是固定一批后仍要继续随机补充？
枚举不明：这个字段只能从哪些世界内类别中选择？是否允许“其它”？
数值不明：上下界分别代表什么，生成时是否允许取到边界？
数量不明：需要固定数量，还是由场景/规模决定？允许范围是多少？

若用户的答案证明双门槛不成立，直接建议跳过，不再追问 schema。

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

- [ ] 重要性与基础生成不足是否分别举证，且两项都成立？
- [ ] 是否因为“玩法重要”就误给常识足够的内容建表？
- [ ] 生命周期是否在三种模式中明确唯一，布尔策略与之相符？
- [ ] 每个字段是否有明确类型、必填性和语义？
- [ ] enum 是否给全允许值与含义，数字是否给上下界，嵌套类型是否定义完整？
- [ ] 是否写清字段间约束、禁止项、去重与校验？
- [ ] 是否把实际实例、变量更新规则、剧情推进规则或 Worker 规格混入本步？
- [ ] 是否只覆盖本轮对象族，并保留其它已有 rule_id？

examples

应建立：
- 怪物是核心战斗资源，需要每局变化，且世界有独特生态与战斗接口；使用 `runtime_only`，固定属性 schema、生态枚举、数值边界与组合禁忌。
- 单女主必须承载特定关系体验，直接写人设容易遗漏关键切面；使用 `seed_only`，下一步生成女主后丢弃规则。
- 重要 NPC 需要开局已有一批，后续也会随地区开放继续出现；使用 `seed_and_runtime`。

不应建立：
- 纯现代都市拍卖玩法中的普通古董；即使古董很重要，只要现实常识与世界基底足以直接生成，就不值得专门维护规则。
- 只在背景里出现一次的路边摊菜单；即使模型可能写得普通，也不影响核心体验。

坏：
- 只写“人物要立体、装备要有趣”，没有 JSON schema 与可校验约束。
- 枚举字段写“阵营：字符串”，却不生成允许的阵营项。
- 好感度写“0～100”，又在本步编写每轮加减公式，侵入变量更新能力。