Add capability-probed structured outputs and a prototype/instance creation graph.
Probe API profiles for json_schema/tools, flatten worker artifacts onto a strict schema, and let users spawn or revise graph nodes instead of a one-shot DAG. Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Cursor
@@ -37,13 +37,14 @@ feeds: gm,auditor
|
||||
|
||||
```opening
|
||||
先认定本轮规则写哪一类内容：
|
||||
- 若【规划产物】已有对象，以此为起点；要改对象就在本步改。
|
||||
- 若【本步对象】/【原型建议】已有对象提示，以此为起点；要改对象就在本步改。
|
||||
- 若规划为空，先钉对象族，再谈规则。
|
||||
|
||||
然后谈：
|
||||
1. 若不做专门规则、只靠世界设定临场写，最怕出现什么不可接受的结果？
|
||||
2. 更需要：开局先钉一批、游玩中再随机补，还是只在游玩期动态生成？
|
||||
3. 哪些产物字段需要「池」？（池挂在 JSON 字段上，如气质标签池→`气质`；可多个；没有就说没有）
|
||||
3. 这类实例彼此有没有必须同场钉死的关系（如互为亲属、对立、同场搭档）？有 → 一次同批生成；彼此独立 → 一次一条。
|
||||
4. 哪些产物字段需要「池」？（池挂在 JSON 字段上，如气质标签池→`气质`；可多个；没有就说没有）
|
||||
|
||||
想到什么写什么；完整规则在正式产物里钉。
|
||||
```
|
||||
@@ -59,7 +60,7 @@ feeds: gm,auditor
|
||||
3. **池**（可选）：每个池挂在产物格式里的某个字段（变量）上，供该字段抽取/组装/枚举；
|
||||
一条规则可多个池；无则 `池: []`。
|
||||
|
||||
本步是〔先验产物〕：先定本轮对象族，再写规则。读【规划产物】当起点；规划可空。禁止顺手扩到其它族。
|
||||
本步是〔先验产物〕：先定本轮对象族，再写规则。读【本步对象】与【原型建议】；在本步钉「写什么」。禁止顺手扩到其它族。
|
||||
|
||||
执行顺序：
|
||||
1. 认定对象族：规划有 `target` 则采用（用户要改则以最新为准）；规划为空则先钉对象。不要停下来让编排器补参。
|
||||
@@ -68,14 +69,17 @@ feeds: gm,auditor
|
||||
- `runtime_only`：仅游玩期动态生成；不要求「具体实例」。
|
||||
- `seed_only`：由「具体实例」预生成；规则用完可丢。
|
||||
- `seed_and_runtime`：先种子实例；规则与实例都保留，游玩期仍可按同规则生成。
|
||||
4. 写满规则三块：生成与描写（可较长）+ 产物格式（**单层 JSON**：每条产物是一层键值，无嵌套对象）+ 池（需要才填；绑顶层字段）。
|
||||
5. 逐字段过筛：每个属性都要能回答「对本对象族是否必要」。冗余字段删掉（如女主规则里的「性别」）；对象族必需字段不得漏（如 D&D 怪物的等级、攻击骰）。
|
||||
6. `rule_id`：规划已给则用；否则稳定 kebab-case。已有产物按 rule_id 增量。
|
||||
4. 钉「数量」与「一次生成」（两件不同的事）：
|
||||
- **数量**：这类对象总共要有几条（fixed / range / contextual）。
|
||||
- **一次生成**：点一次「具体实例」交几条。彼此有必须同场对齐的关系 → `同批`（一次交出并对齐关系）；彼此独立 → `单条`（一次只交 1 条，要更多就再点原型）。产物形状始终是 `records[]`，不因单条改成单对象。
|
||||
5. 写满规则三块：生成与描写（可较长）+ 产物格式（**单层 JSON**：每条产物是一层键值，无嵌套对象）+ 池（需要才填；绑顶层字段）。
|
||||
6. 逐字段过筛：每个属性都要能回答「对本对象族是否必要」。冗余字段删掉（如女主规则里的「性别」）；对象族必需字段不得漏（如 D&D 怪物的等级、攻击骰）。
|
||||
7. `rule_id`：规划已给则用；否则稳定 kebab-case。已有产物按 rule_id 增量。
|
||||
若本步对象与规划不一致，以最新对象为准并重钉对应英文 rule_id，禁止沿用旧 id。
|
||||
7. 按自评三维打分并填追问；输出 JSON。禁止夹带最终实例 records。
|
||||
8. 按自评三维打分并填追问；输出 JSON。禁止夹带最终实例 records。
|
||||
|
||||
若程序已发默认问题：禁止重复开场；在首答上补洞。
|
||||
summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生成并动态}`；跳过 → `生成规则 · {对象} · 无需专门规则`。
|
||||
summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生成并动态} · {单条|同批}`；跳过 → `生成规则 · {对象} · 无需专门规则`。
|
||||
```
|
||||
|
||||
## principles
|
||||
@@ -90,7 +94,8 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
|
||||
类型/必填/枚举/上下界必须可校验；禁止只给示例让下游猜类型。
|
||||
6. 池绑顶层字段名（如 `气质`、`攻击花招`）；一条规则可多池。池条目是该字段材料，不是整条 record。
|
||||
7. 生命周期先行；未定前不假装可执行「具体实例」。
|
||||
8. 不写变量更新公式、不写剧情推进、不填最终实例。
|
||||
8. **一次生成**看关系，不看「想不想一次多写」：有必须同场钉死的关系（亲属、对立、同场搭档等）→ `同批`；彼此独立 → `单条`。`同批` 至少 2 条，否则改 `单条`。不要把「总共要几个」（数量）和「这一次交几条」（一次生成）混成一件事。
|
||||
9. 不写变量更新公式、不写剧情推进、不填最终实例。
|
||||
```
|
||||
|
||||
## probe
|
||||
@@ -98,7 +103,7 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
|
||||
```probe
|
||||
每轮 1～2 点。规划已钉且用户未改对象时，禁止重问 target / rule_id。规划为空或用户要换对象时，先问本轮生成什么。
|
||||
|
||||
优先：整条规则是否必要；某字段该不该进表（冗余 vs 漏接口）；单层格式类型/枚举/边界；哪些字段要池。
|
||||
优先：整条规则是否必要；实例彼此有无必须同场对齐的关系（一次生成：同批 vs 单条）；某字段该不该进表（冗余 vs 漏接口）；单层格式类型/枚举/边界；哪些字段要池。
|
||||
若双门槛不成立 → 建议跳过，停追问字段与格式。
|
||||
不追问：最终实例正文、变量增减公式、其它对象族、完整世界百科。
|
||||
```
|
||||
@@ -141,6 +146,10 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
|
||||
"最大": 1,
|
||||
"决定规则": "contextual 时必填，可较长"
|
||||
},
|
||||
"一次生成": {
|
||||
"模式": "单条|同批",
|
||||
"关系": "同批必填：本批记录之间必须一起钉的联系；单条写「彼此独立」"
|
||||
},
|
||||
"生成与描写": {
|
||||
"依据": ["可较长；引用上游产物或用户要求"],
|
||||
"方法": ["可较长：生成顺序、如何组装、描写口径、语气/切面、如何用池"],
|
||||
@@ -236,7 +245,7 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
|
||||
1. 合法 JSON；必含 `schema` / `技能` / `brief` / `正文` / `自评` / `追问`（题目可 `[]`）。
|
||||
2. **公共三段**：正文＝规则主体；自评＝必要性/属性妥当/格式准确（**分数 0–10 十分制**）；追问＝导语+建议选项。
|
||||
3. **正文键固定**：本步参数、必要性判断、rules、增量说明。
|
||||
4. **每条 rule 必含**：生成与描写、产物格式；**池可空数组**。有池时 `绑定字段` 必须是单层 schema 的顶层键。
|
||||
4. **每条 rule 必含**：生成与描写、产物格式、数量、一次生成；**池可空数组**。有池时 `绑定字段` 必须是单层 schema 的顶层键。`一次生成.模式` 为同批时 `关系` 必填且本批至少 2 条；为单条时一次只交 1 条。
|
||||
5. **产物格式强制单层**：`schema` 的 `type` 不得为 `object`；`array` 的 `items` 不得为 object。禁止 `外貌.发色` 这类嵌套路径。
|
||||
6. 结论为「无需专门规则」时：`rules` 必须 `[]`。上下文策略布尔须与生命周期一致。
|
||||
7. 池条目≠最终实例；禁止输出具体实例 `records`、变量更新规则、执行单元列表。
|
||||
@@ -248,7 +257,7 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
|
||||
- [ ] 含 schema / brief / 正文 / 自评 / 追问？
|
||||
- [ ] 自评为必要性 / 属性妥当 / 格式准确？
|
||||
- [ ] 整条规则必要性有举证？不成立时 rules=[]？
|
||||
- [ ] 建立时：逐字段无冗余无漏接口？产物为单层 JSON 且类型可校验？
|
||||
- [ ] 建立时：逐字段无冗余无漏接口？产物为单层 JSON 且类型可校验？数量与一次生成已分清（总共几个 vs 这一次交几条）？同批有关系、单条写彼此独立？
|
||||
- [ ] 池：无则 []；有则绑顶层字段、未写成最终实例表？
|
||||
- [ ] 未夹带最终实例、变量公式、其它对象族、百科？
|
||||
```
|
||||
@@ -259,11 +268,15 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
|
||||
好：
|
||||
- D&D 怪物：单层含 名称/等级/攻击骰/……；池可绑 `气质`；自评属性妥当高（未漏战斗接口）。
|
||||
- 女主规则：不设「性别」字段；关系切面进表；池可空。
|
||||
- 互为仇敌的两名开局 NPC：一次生成=同批，关系写清对立如何对齐；数量=2。
|
||||
- 可互换的酒馆路人：一次生成=单条，关系写「彼此独立」；要 5 个就点 5 次。
|
||||
- 事件钩子：池绑顶层 `钩子`；方法写抽 1～2 条写入该字段。
|
||||
- 普通古董 → 无需专门规则（必要性维度说明跳过理由）。
|
||||
|
||||
坏：
|
||||
- 产物写成 `{ "外貌": { "发色": "…" } }` → 非单层，前端表格/投影难对接。
|
||||
- 女主规则塞「性别」；或怪物规则只有「名字+性格」没有等级/攻击骰。
|
||||
- 有亲属关系的三人却标成单条，分三次各写一条，关系对不上。
|
||||
- 把「总共要 5 个」写成一次生成=同批，但彼此并无必须同场的关系。
|
||||
- 把写好的 NPC 整份塞进池当最终实例。
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user