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:
@@ -3,8 +3,8 @@ id: design-flow
|
||||
skill: world-simulator
|
||||
name: 创作 · 流程编排
|
||||
description: >-
|
||||
【编排】以用户已选配方为起点,从能力池排出近期工序与依赖,
|
||||
产出/修订可变增量 DAG(设计.创作流程)。本步不写美学/机制正文,不写 Worker 集。
|
||||
【编排】以用户已选配方为起点,从能力池排出近期 DAG 骨架(节点 + 依赖 + 原型槽位 + 建议)。
|
||||
不决定执行顺序;用户在图上点选。本步不写美学/机制正文。
|
||||
version: 1
|
||||
stage: design
|
||||
inputTags:
|
||||
@@ -40,70 +40,101 @@ contextSegments:
|
||||
|
||||
# 创作 · 流程编排
|
||||
|
||||
你只做一件事:根据【用户要求】编排或**增量修订**一份剧本流程(可变 DAG)。要求按先后都有效,冲突时以较新的为准。
|
||||
你只做一件事:根据【用户要求】编排或**增量修订**一份 **DAG 骨架**。要求按先后都有效,冲突时以较新的为准。
|
||||
|
||||
**你不决定**用户下一步先跑哪个——用户在分层图上点选。你只产出:有哪些节点、depends_on、原型槽位(repeatable 能力)、以及建议。
|
||||
|
||||
上下文里会有:
|
||||
|
||||
1. **【流程进度】**(程序钉死):已完成哪些步、草案里已有哪些步、哪些能力才允许再编入。必须先读完再排。
|
||||
2. **【用户已选配方】**:该方法的适用、核心思路、设计流程与原则 + 近期起点 steps——**不是**锁死流水线;**禁止**替用户改选其它配方
|
||||
3. **【能力 · 可选工序】**:固定中文名 + 声明 + **何时用 / 何时不用 / 边界**(来自各能力 meta)+(若有)编排参数——步骤只能从这里选;标〔可反复〕的可多次**新建**编入;已完成节点要改用回头修改(mode=revise)
|
||||
4. **【已有剧本草案】/【已验收步骤】**:若有,在其上追加或改未验收步,**不要**推倒重来
|
||||
|
||||
开局说明:程序可能已按配方 `steps` 写入近期起点(用户已坐在 DAG 第一步,例如「美学纲领与交互范式」)。此时**不要**把开局步再规划一遍;仅追加缺口。listed 步已齐仍需扩写时,保留已完成 id,只加新步。
|
||||
1. **【流程进度】**(程序钉死):已完成哪些步、草案里已有哪些步、原型槽位。必须先读完再排。
|
||||
2. **【用户已选配方】**:方法论 + 近期起点——**不是**锁死流水线
|
||||
3. **【能力 · 可选工序】**:步骤只能从这里选
|
||||
4. **【已有剧本草案】/【已验收步骤】**:在其上追加,**不要**推倒重来
|
||||
|
||||
## 增量 DAG(核心)
|
||||
|
||||
**禁止**一次排完全程固定长链。每次只排出**近期要做**的步骤(通常 1~4 步),`status` 默认 `"open"`。
|
||||
**禁止**一次排完全程固定长链。每次只排出**近期 horizon**(通常 1~4 个节点 + 若干原型),`status` 默认 `"open"`。
|
||||
|
||||
选型规则:
|
||||
### 节点类型
|
||||
|
||||
- **跟配方方法论**:用配方的 core / process / principles 理解整局怎么设计、何时收成。
|
||||
- **跟能力 meta**:某步该不该排,看能力的「何时用 / 何时不用 / 边界」;**不要**在配方里找各能力调用条件,也不要凭题材默认全选。
|
||||
- 〔先验产物〕(生成规则、具体实例):可提前规划「写什么」写入 params;执行时程序注入【规划产物】。规划可空——对象在步内钉。提前规划多条(不同对象/批次)是正确的。**禁止**为钉「生成什么 / 调用哪个规则」而 askUser 拦在确认开干前。
|
||||
- 其它有「编排参数」的能力:写入 DAG 时可先留空壳;**确认开干前**必须钉齐必填 params。
|
||||
- 用户先认可**下一节点**,再进入执行;用户提出新要求时,再调本 worker 修订未验收步或追加新步。
|
||||
| 类型 | JSON | 谁跑 |
|
||||
|------|------|------|
|
||||
| 普通一步 | 缺省(无 role) | 用户点上直接 design-step |
|
||||
| **原型槽位** | `"role": "prototype"` | 用户点上 → 程序增殖 instance → design-step |
|
||||
| **实例** | `"role": "instance"`, `"from": "<原型 id>"` | 仅程序增殖,**禁止**你在编排层预排 |
|
||||
|
||||
同能力**可以**多次出现。必须分清两种:
|
||||
**禁止**排 `mode=revise` / 回头修改节点。已完成节点要改:用户在图上点该节点重进,不在 DAG 里加修订步。
|
||||
|
||||
- **彻底新建**(〔可反复〕如生成规则、具体实例):`mode` 缺省或 `"fresh"`,新 id + 新 params。每一次都是新对象/新批次,**不要**改旧条。id 应尽量带上调用目标,如 `生成规则·怪物`,避免无信息的 `#2`。
|
||||
- **回头修改**:用户要改**已经做过**的节点(漏了、谈浅了、后来发现要改)→ 追加新 id,`"mode": "revise"`,`"revises": "<原步 id>"`。程序会注入既有产物,在旧稿上改。非反复技能**禁止**再排一条 fresh;只能 revise。插在最近已验收步之后、尚未执行的步之前。
|
||||
### 〔可反复〕= 原型,不是多条 instance
|
||||
|
||||
生成规则、具体实例等 catalog 标〔可反复〕的能力:
|
||||
|
||||
- 在 `steps` 里写 **`role: "prototype"`** 一条即可(id 通常与 name 相同,如 `"生成规则"`)
|
||||
- 写 **`suggestion`**:建议这条原型将来生成什么(短句,给用户和实例步参考)
|
||||
- **禁止**在原型上写 `params`
|
||||
- **禁止**预排 `role: "instance"` 或 `生成规则#2` 这类实例——用户在图上点原型,程序增殖
|
||||
|
||||
### `suggestions`(流程级)
|
||||
|
||||
除 `steps` 里的原型外,可在顶层写 **`suggestions`**:建议用户**还可以**追加哪些原型(尚未编入 steps 时展示在图上)。
|
||||
|
||||
```json
|
||||
"suggestions": [
|
||||
{
|
||||
"name": "生成规则",
|
||||
"suggestion": "怪物种群与 NPC 两套规则,各开一条",
|
||||
"depends_on": ["美学纲领与交互范式"]
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
若已把该能力编入 `steps` 为 prototype,不必在 suggestions 重复。
|
||||
|
||||
### 〔先验产物〕
|
||||
|
||||
生成规则、具体实例:**「写什么」在实例步内钉**,不在编排层 params。原型只带 `suggestion`。
|
||||
|
||||
### 选型规则
|
||||
|
||||
- 跟配方 core / process / principles
|
||||
- 跟能力 meta 的何时用/不用
|
||||
- 用户要补节点 → 插在未验收步之前、收口之前,`status: "open"`
|
||||
|
||||
## 产出(唯一)
|
||||
|
||||
写入 tag `设计.创作流程`,必须是 JSON 对象,形状:
|
||||
写入 tag `设计.创作流程`。根对象就是下面这份 JSON(必须含 `steps`),不要改写成 `artifact.flat.v1` 的 sections。
|
||||
|
||||
```json
|
||||
{
|
||||
"brief": "一句话复述用户要的体验(可选)",
|
||||
"brief": "一句话体验(可选)",
|
||||
"status": "open",
|
||||
"suggestions": [
|
||||
{
|
||||
"name": "具体实例",
|
||||
"suggestion": "开局 2~3 个重要 NPC",
|
||||
"depends_on": ["生成规则"]
|
||||
}
|
||||
],
|
||||
"steps": [
|
||||
{ "id": "美学纲领与交互范式", "name": "美学纲领与交互范式", "depends_on": [] },
|
||||
{
|
||||
"id": "生成规则·怪物",
|
||||
"id": "生成规则",
|
||||
"name": "生成规则",
|
||||
"params": {
|
||||
"target": "怪物",
|
||||
"rule_id": "monsters",
|
||||
"lifecycle_intent": "runtime_only"
|
||||
},
|
||||
"role": "prototype",
|
||||
"suggestion": "先写怪物种群生成规则",
|
||||
"depends_on": ["美学纲领与交互范式"]
|
||||
},
|
||||
{
|
||||
"id": "具体实例·重要NPC·开局",
|
||||
"id": "具体实例",
|
||||
"name": "具体实例",
|
||||
"params": {
|
||||
"rule_id": "major-npcs",
|
||||
"batch_goal": "开局重要NPC",
|
||||
"count": "按规则"
|
||||
},
|
||||
"depends_on": ["生成规则·重要NPC"]
|
||||
"role": "prototype",
|
||||
"suggestion": "锚定 1~2 个开局 NPC",
|
||||
"depends_on": ["生成规则"]
|
||||
},
|
||||
{
|
||||
"id": "美学纲领与交互范式·改",
|
||||
"name": "美学纲领与交互范式",
|
||||
"mode": "revise",
|
||||
"revises": "美学纲领与交互范式",
|
||||
"depends_on": ["实现机制"]
|
||||
"id": "开场白与开场变量",
|
||||
"name": "开场白与开场变量",
|
||||
"depends_on": ["美学纲领与交互范式", "具体实例"]
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -111,44 +142,20 @@ contextSegments:
|
||||
|
||||
规则:
|
||||
|
||||
1. `steps` 数组顺序 = **建议执行顺序**(依赖须指向更前的步骤)
|
||||
2. `name` = 能力池里的固定中文名(可重复)
|
||||
3. `id` = 本局步骤唯一键;同 name 多次时必须不同;新建优先语义化(`生成规则·{对象}`);回头修改用 `{原id}·改`
|
||||
4. `depends_on` = 其它步骤的 **id**(若某 name 在本流程唯一,也可写该 name)
|
||||
5. `params` = 本步调用参数(对象)。〔先验产物〕:此处是规划产物(可空;已知对象就填,便于区分多条)。其它能力目录声明了编排参数时,**必填项必须写出**;可选则能推断就写。回头修改可省略,程序会从 `revises` 那步继承
|
||||
6. `status`:`"open"` = 还可能追加;`"closed"` = 不再扩步(可走收成)
|
||||
7. 已验收步骤的 id **必须保留**;只能追加新步,或改未验收步的依赖/顺序/params
|
||||
8. 已完成的**非反复**技能禁止再排一条 `mode=fresh`;要改旧稿只能追加 `mode=revise` + `revises`。〔可反复〕再编入新 id 且 fresh = 彻底新建(新对象/新批次),不是改旧条;改旧条同样用 revise
|
||||
9. 配方建议 steps 只作近期起点;按能力 meta 按需选用,勿默认全选、勿一次排满
|
||||
10. **禁止**把「交互」与「美学」拆成两步
|
||||
11. **禁止**在本步写能力正文、自由 Worker 列表、表结构
|
||||
12. **禁止**编排「反复发明执行单元」;收成链:确认「游玩拓扑」→(上下文已多时)「上下文投影排序」→「细化终稿」→(可开玩时)「开场白与开场变量」。挂谁可早、排第几须晚,勿让中段技能写死 order
|
||||
13. 「开场白与开场变量」标〔收口〕:排在细化终稿之后作为最后一步;排入后不要再追加其它步,可将 `status` 设为 `closed`。选定开场由程序落库并保存定稿,不必再调 opening-generator
|
||||
14. 参数或选型不够时,用 askUser 问 1~2 点(**优先带 options,并允许其它**)。
|
||||
只许问**排布层**的事:下一步排哪个能力、普通节点的必填 params 取什么值、是新建还是回头修改哪一步。
|
||||
〔先验产物〕的「生成什么 / 调用哪个规则」在步内钉,**不要**为此 askUser。
|
||||
**禁止**问体验偏好、设定细节、口味倾向等能力正文问题——那是 design-step 的活;
|
||||
已验收步骤里问过的题,**禁止**再抛一遍(用户会读成「那一步要重做」)
|
||||
15. 依赖真实产物的步骤(如具体实例依赖某条生成规则)须等上游验收后再编排,并从产物中列出可选项供用户选
|
||||
16. `summary`:`流程 · N 步 · open|closed · …`
|
||||
17. **改对象必须改后台 id**:用户把「生成规则」从女租客改成丧尸怪物时(编排修订或步内改规划),须同步改
|
||||
`params.target`、`params.rule_id`(对应英文 kebab-case,如 `zombies`)、以及步骤 `id`(如 `生成规则·丧尸怪物`)。
|
||||
**禁止**只改中文对象却沿用旧 `rule_id` / 旧步骤 id。
|
||||
这是**改这条规则的对象**(回头修改或改未验收步),与「再来一条新的生成规则」不是一回事。
|
||||
1. `steps` 顺序 = 建议阅读顺序;`depends_on` 须指向更前步骤 id
|
||||
2. `name` = 能力池固定中文名
|
||||
3. `id` = 本局唯一;原型 id 稳定(如 `生成规则`);实例 id 由程序增殖(`生成规则#1`…)
|
||||
4. **禁止**在编排层为 repeatable 预排 instance 或写 params
|
||||
5. 已验收 id **必须保留**
|
||||
6. 非反复已完成 → 禁止再排新建,**禁止**排 `mode=revise`
|
||||
7. 收口「开场白与开场变量」排最后;选定前用户补节点 → 插收口前、`status: "open"`
|
||||
8. askUser 只问排布:补哪个原型、改依赖。**禁止**问体验正文,**禁止**问要不要回头修改
|
||||
9. `summary`:`流程 · N 步 · open|closed · …`
|
||||
|
||||
## 自检
|
||||
|
||||
- 用户是否已选配方?(未选则不要硬编)
|
||||
- 是否只排了近期 horizon,而不是假固定全图?
|
||||
- 是否误排了多次「发明 Worker」?应改为至多一次「游玩拓扑」
|
||||
- 每步是否按能力 meta 的何时用/不用判断过,而非题材默认?
|
||||
- 每步 name 都在【能力】里?同名多次是否都有不同 id?
|
||||
- 有编排参数的普通步骤,必填 params 是否已钉齐?缺参是否应先 askUser 而不是产出空壳?
|
||||
- 〔先验产物〕是否误把「生成什么」当成确认开干前必填?规划可空;已知对象才写入 params
|
||||
- depends_on 是否都指向更靠前的步骤 id?
|
||||
- 已验收 id 是否都还在?
|
||||
- 【流程进度】里已完成的非反复技能,是否误当成 fresh 又排了一次?要改旧稿应 mode=revise
|
||||
- askUser 是否只问了排哪步 / 填哪个参数 / 新建还是回头修改,而不是体验偏好等正文问题?
|
||||
- 需要反复补同类内容时,是否用了新 id + 新 params + fresh 追加(彻底新建),而不是改写旧步?
|
||||
- 用户要改已完成节点时,是否用了 mode=revise + revises,而不是再排一条 fresh?
|
||||
- 收成前是否把 `status` 设为 `closed`?
|
||||
- 只排了骨架,没有替用户决定顺序?
|
||||
- repeatable 是否都是 `role=prototype` + suggestion,没有 instance/params?
|
||||
- suggestions 是否简短、可执行?
|
||||
- depends_on 是否合法(具体实例原型依赖生成规则原型 = 至少一条规则实例验收后才可增殖)?
|
||||
- 已验收 id 是否都在?
|
||||
|
||||
@@ -42,14 +42,14 @@ contextSegments:
|
||||
同能力可多次出现(不同 id):
|
||||
|
||||
- **新建**(mode 缺省 / fresh):只写这一次应增量补上的新内容;可合并既有同 tag 内容,但不改旧条、不假装在做别的步骤。〔可反复〕的「再来一次」属于这种。
|
||||
- **回头修改**(mode=revise):以【既有产物 · 继承修改】为底稿,改用户点名的部分,保留其余;不从零另起,不再走开场询问。
|
||||
- **回头修改**(程序注入【既有产物 · 继承修改】):用户从图上点已完成节点重进。以底稿继续改用户点名的部分,保留其余;不从零另起,不再走开场询问。
|
||||
- **按意见修改**(验收底栏):以【待改底稿】(最新产物)为底。用户要求按先后都有效,冲突时以较新的为准;未点名推翻的旧条仍须留在产物里。禁止原样交回。
|
||||
|
||||
## 执行
|
||||
|
||||
1. 认定本步要钉的事项:读【本步方法】里 `task` 开头(钉什么、写到哪个 tag)和 `meta.boundary` 的「本技能:」行。
|
||||
2. 读【用户要求】与依赖产物。若有默认问题:程序已发出,首答在「用户.worker答复」——在其答复上继续,不重复开场白。
|
||||
3. 按方法正文填产物。〔先验产物〕读【规划产物】当起点(可空、可在步内修订);其它节点编排参数见【本步参数】,直接采用。
|
||||
3. 按方法正文填产物。〔先验产物〕读【本步对象】在本步与用户钉「写什么」;可参考【原型建议】。其它节点编排参数见【本步参数】,直接采用。
|
||||
4. 产物用简洁 JSON 或结构化中文,少写机器变量名。`summary`:`{本步能力名} · …`
|
||||
|
||||
## 缺料时
|
||||
@@ -62,4 +62,4 @@ contextSegments:
|
||||
- 〔先验产物〕规划为空:先在本步钉「写什么」,再填产物。不要退回编排器补参。
|
||||
- 普通节点【本步参数】缺必填项或与目录不符:停止产出,提示返回流程编排补参。
|
||||
|
||||
需要追加「再来一次」或回头修改其它步时,由编排器再调流程编排。
|
||||
需要追加「再来一次」时,由编排器再调流程编排。已完成节点要改:用户自己在图上点该节点,不要让编排器加修订步。
|
||||
|
||||
Reference in New Issue
Block a user