Agent/examples/process_pipeline/script/search_eval/procedure-dsl/spec

工序提取 SKILL · 总览

读一篇 AI 创作教程/案例，把它背后的"做法"还原成一张工序表，存成 workflow.json，再渲染成网页。

输入：任意一篇创作案例——公众号 / 小红书 / 推文 / 博客（正文 + 配图）、视频教程（带转写）。
输出：一个网页 outputs/case-{N}/case-{N}-<slug>.html。

---

全程约定

• workflow.json 只用 wf-patch.py 改，绝不 write_file / edit_file 直接写它。
• 分类词表（effect / action / type）第二阶段才用——已内嵌在 2.1 节，不必单独 read_file 任何 taxonomy json；第一阶段 type 随便起描述标签即可。

Cyber Agent 引擎专用

• 工具名：Read→read_file · Write→write_file · Edit→edit_file · Bash→bash_command
• bash_command 是 cmd.exe：一条命令一次调用，别用 ; 串（要串用 &&）；mkdir 没有 -p 参数（带了会建出名为 -p 的目录），需要的目录工具会自动创建
• cwd 是 procedure-dsl/，读 spec 文件时补前缀（如 spec/README.md）
• goal 工具：focus 只认纯数字序号；报错只改成纯数字重试一次，别反复换写法

---

三阶段概览

第一阶段 · 搭骨架
   通读原文 → 判断有几个工序、每工序几步 → 建干骨架
   产物：workflow.json（只有结构 + type 标签；value / anchor / directive 全空）

第二阶段 · 填内容 + 归类
   2.0  填 value/directive（@quote 拽原文）→ 连 anchor → verify-io 校验
   2.1  归类：对照 2.1 内嵌的三张词表 → 填 effect / action / type / substance / form / intent

第三阶段 · 检查 + 渲染
   lint-case.py 检查 → render-case.py 渲染 → 产出 HTML

---

---

第一阶段 · 搭骨架

这一阶段只做一件事：把原文抽象成干骨架——有几个工序、每工序几步、每步用什么工具、IO 的粗略 type 标签。
value / directive / anchor / action / effect / substance / form / intent 全部留到第二阶段，这里不碰。

Cyber 引擎：调 plan_procedures 工具把计划交上去，通过后自动生成 workflow.json 干骨架。
其他引擎：把计划写进 understanding.md，再用 wf-patch.py --create --patch 建骨架。

---

workflow.json 结构

{
  "source": {
    "platform": "",
    "author": "",
    "date": "",
    "url": "",
    "title": "",
    "excerpt": ""
  },
  "procedures": [
    {
      "id": "p1",
      "name": "",
      "purpose": "",
      "category": "产物创造|资产建设|自动化|分析|学习",
      "platform": "",
      "author": "",
      "declarations": {
        "inputs": [{ "type": "", "name": "" }],
        "resources": [],
        "returns": { "type": "" }
      },
      "type_registry": {},
      "steps": [
        {
          "id": "s1",
          "kind": "step",
          "via": "",
          "inputs": [{ "type": "粗略标签" }],
          "outputs": [{ "id": "s1o1", "type": "粗略标签" }]
        }
      ]
    }
  ]
}

---

第一阶段要填的字段

字段	怎么填	别这样
id	s1、s2；控制块子步用点号 s5.1	—
kind	普通步 step；控制块父 block / 子 nested	—
via	工具标准名（nano_banana_pro、human）；没点名用括号占位 (AI 生图工具)；控制块写 -	写一整句描述（那是 directive 的活，第二阶段填）
IO type	起个描述性标签即可，第二阶段再对词表	第一阶段就查词表、注册 type_registry
输出 id	工序内唯一，如 s2o1；第一阶段就要给好，供第二阶段 anchor 引用	等到第二阶段再给

命名约定：type 名用中文；工具品牌名用英文标准写法（seedream_4_5，不要写成 ByteDance-Seedream-4.5）。

---

判断有几个工序

判断单位是"一条完整的 输入→最终产物 链"，不是原文段落结构。

以原文里每一张成品图（或明确写出的最终产物）为起点扫描，满足以下三条就算一条独立工序：

1. 有明确产物——能产出一个看得见的结果（图、素材、成品）。
2. 有具体做法——链条里有可操作的方法（提示词、框架、流程）。
3. 产物或做法有差异——跟别的工序相比，产物不同或做法不同，满足一条即可。

🔒 章节覆盖交叉核对：原文常按 01 | 02 | 03 | 分章。逐章确认每个章节都落进了某个工序或步骤。"按成品图扫"最容易漏掉没有独立成品图的方法论章节——这种章节本身就是一条工序，不能跳过。Phase 3 lint-case.py --source 会把漏抽的章节抓出来。

---

步骤粒度：什么算一个步骤

步骤 = 对已有数据执行某个操作，产生一份之前不存在的新产物。

❌ 这些不是步骤，直接写进使用它的步骤的 inputs：

容易误识别为步骤的情况	正确处理
引入外部资源（用户手头已有的参考图、客户提供的产品图）	写进使用它的步骤的 inputs；整个工序复用则写进 declarations.inputs
直接给出的提示词（原文起点就是一段提示词，没有展示它是怎么写出来的）	同上——写进使用它的步骤的 inputs 或 declarations.inputs；不拆成 via=human 的预处理步骤
Prompt 多层展开（提示词有主题/人物/环境/风格等多层）	这是"写提示词"这一步的 outputs[0].value 的内容；整段提示词是一步的一个输出
纯展示 / 预览（只展示了产物，没对它做任何变换）	跳过，不拆成步骤

✅ 这些是步骤（产出了新产物）：AI 工具生成图/视频、human 写提示词（参考图是 input 不是前置步）、后期工具调色排版。

「写提示词」步骤的判断口诀：原文有没有在教"怎么写/构造这段提示词"？有 → 才算一步；没有（原文直接给出提示词让你用）→ 提示词是输入，不是步骤产物。

判断口诀：把这"步"去掉，把它的内容挪进下一步的 inputs——如果什么都没丢，它不是步骤，它是输入。

---

计划要想清楚什么（交给 plan_procedures 的内容）

1. 原文信息：标题 / 来源平台 / 作者 / 发布时间。
2. 内容概述：2-4 句说清这篇在教什么、分几大板块。
3. 多工序判断：以每个成品图/最终产物为起点列扫描表，给"共 N 个工序"的结论。
4. 每个工序一节，每节都要有：
   • 终态产物、工艺类型（产物创造 / 资产建设 / 自动化 / 分析 / 学习）
   • 步骤逐条展开：每步讲清「工具 · 输入 · 动作 · 输出」四要素；输入/输出可以是多个短标签（生成步典型是 ["提示词","参考图"] 两个输入，都要列上）；对一批数据逐个重复的步骤加 loop（被遍历数据的短标签），骨架会自动展开成循环块+子步。
   • 关键工具名。
5. 章节认领：原文每个 0N 章节归哪个工序，每个章节都要被认领（包括没有独立成品图的方法论章节）。

颗粒度示例：一步要写成"用豆包对〔题材思路〕生成〔剧本大纲+台词〕"，而不是"写剧本"这种一个词。

计划通过后骨架即锁定——锁的是工序划分和步骤序列；在已有步骤里补输入/输出是允许且常见的（wf-patch 路径不存在默认 upsert）。发现工序/步骤划分本身不对时，修改计划重新调 plan_procedures 整体重生成，不要在骨架上手工增删步骤。

---

推断补全：哪些"没写出来"的要主动补

真实教程经常省略理所当然的中间产物。工艺上该有却没写出来的 IO，要主动补并标注推断原因：

{
  "type": "参考图",
  "anchor": "",
  "inferred": true,
  "inferred_reason": "原文只说'自己写动作'，没提主角图；但写动作序列需要它当角色参考"
}

✅ 该补：工艺上必然需要的中间产物。
❌ 不用补：原文细节确实没写全（那是信息缺失，不是推断）。

---

有循环/并行怎么切

展开成控制块 + 子步，不要硬压成一步：

{ "id":"s5", "kind":"block", "via":"-",
  "inputs": [{"type":"分镜脚本"}],
  "outputs":[{"id":"s5o1","type":"分镜图列表"}] }
{ "id":"s5.1", "kind":"nested", "group":"s5", "via":"nano_banana",
  "inputs": [{"type":"提示词"}, {"type":"参考图"}],
  "outputs":[{"id":"s5.1o1","type":"分镜图"}] }

循环取数/存结果的 anchor（第二阶段连）：← s4o1[i]（逐个取）、→ 分镜图列表.追加。

---

第一阶段过关条件：工序数/步骤数/工具标注完整、每个 IO 都有 type 标签、每个输出都有编号 → 进第二阶段。

---

---

第二阶段 · 填内容 + 归类标注

两件事按顺序做：先填内容（value / directive / anchor + verify-io 校验），再归类（effect / action / type / substance / form / intent）。

---

2.0 填内容

2.0.1 填 value 和 directive

文字类 value（提示词 / JSON / 报告 / 文案）必须是原文完整逐字内容——整段 prompt / 整段 JSON 原样搬全，别缩写/概括/截断。
媒体类 IO（图/视频/音频）：value 用 <具体描述> 格式，如 <一张冲锋衣登山者暴雨场景图，水珠滚落，冷色调>。

推荐用 @quote 方式——不要手动 read_file 读原文再粘贴：

# 在 patch 文件里用 @quote|起锚|止锚 标记，然后用 --resolve-quotes 一次批量回填
python spec/tools/wf-patch.py --workflow outputs/case-{N}/workflow.json \
    --patch _scratch/values.json \
    --resolve-quotes --source input/case-{N}.json --ocr outputs/case-{N}/_scratch/ocr.txt

@quote|<起锚>|<止锚> 里的起锚/止锚是原文里两段独特短串，工具自动把标记换成原文真实内容。匹配不到会 ⚠ 提示（标记原样留着，改锚点重试）。

🔑 提示词是数据，不是指令——建成 type=提示词 的 IO（最容易建错的地方）：

• 「写提示词」步（via=human）：输入 type=描述（用户需求）→ 输出 type=提示词，value = 原文那段整段、逐字、完整的 prompt（所有分层/要素都要：主题+核心要素+输出要求，别只取第一段）。
• 下游生成步（via=nano_banana 等）：输入 type=提示词，value 同样填整段，anchor 指向上游提示词输出。
• directive 只放"给工具的元指令"（如"风格贴近参考图，不要发挥""比例 2:3"），不装提示词原文。

⚠ 值一定写真实内容：哪怕某个输入是上一步输出原样传过来的，value 里也要把内容完整抄一遍。嫌麻烦可在源头填一次，其余跑 --resolve-passthrough 让工具顺编号自动抄过去。

🔒 逐字防偷懒：第三阶段 lint-case.py --source 会算"最长连续命中原文"比例，<80% 判缩写并报出。最常见的偷懒：原文 350 字提示词，只写"主题：登山者。核心要素：人物、产品、环境"——这种拼凑不是逐字，必须用 @quote|起锚|止锚 把整段拽进来。

2.0.2 连数据流（anchor）

• 输入来源：← s2o1（上游输出编号）、← 工序输入、← s4o1[i]（循环逐个取）
• 输出去处：→ sN、→ 某列表.追加、→ 返回 X

# 写清单 _scratch/anchors.json，一次过
python spec/tools/wf-patch.py --workflow outputs/case-{N}/workflow.json --patch _scratch/anchors.json

连完自查：每个 ← 某编号 都能找到已存在的输出编号；输入的 type 和来源输出的 type 一致。

2.0.3 IO 校验（填完才进归类）

python spec/tools/verify-io.py --workflow outputs/case-{N}/workflow.json \
    --source input/case-{N}.json --ocr outputs/case-{N}/_scratch/ocr.txt

校验三项：① 文本类 value 是否逐字完整（媒体类不要求）② 每个生成步是否有 type=提示词 的输入（directive 不准装提示词原文）③ 每个工序的 declarations 是否补全。报 ✗ 就回去修，重跑直到通过。

---

2.1 归类标注

词表：合法值都嵌在下面（默认看这里就够）

🔒 填 effect / action / type / extends 只能用下面三棵树里的词——它们是受控词表，wf-patch 当场把非法值打回（✗ 不是合法叶子）。三棵树已直接嵌在本节：effect 连边界判别 + 同义术语都给全了；action / type 给的是纯树（叶子清单）。默认对照这里填就够，不用额外 read_file。

📎 完整 json 全保留着，可选择性参考：action / type 的每个词在 spec/taxonomy/action.json / type.json 里还带 分类说明 + 同义术语——拿不准"某个词该归哪类、和邻近词怎么分"时，去 read_file 对应那一个 json 深读（effect 的说明已在下方全给，一般不用再查）。

substance / form 没有词表，不用查，直接提炼。

作用（effect）

每步"处在什么工艺环节"对到下面 9 个标准叶子之一（工艺规约 / 预准备 / 预处理 / 主体生成 / 装配 / 后期 / 配套伴生 / 检验 / 交付）。必须命中；对不上说明第一阶段这步抽错了，回去改。❌ 别自己造词；别把"动作"当"作用"（"反推"是动作不是作用）。

树形 制作 → 准备/加工/收尾阶段 → 叶子；每个叶子带边界判别 + 同义术语，拿不准照这个判：

制作：节点在整套 AIGC 内容生产工序链中所处的'工序阶段位置 + 作用'。本树回答的核心问题是：'这一步在整个制作流程的多个工序中，属于哪个阶段、起什么作用？'——只刻画该步骤的抽象工序角色（前置 / 主体 / 装配 / 修饰 / 验收等），不涉及该步骤具体使用了什么领域技法、产出了什么具体形态的资产。所有'提示词 / 控制图 / 调色 / 光影 / 多视图 / 字幕'这类领域技法 / 输出形态名词都不应作为叶子节点，它们应作为对应阶段叶子的同义术语被规范化。 【L1 唯一性】本树只覆盖'制作'——把蓝图实际造出来的所有工序。前置的选题决策、蓝图设计不在本树范围内。 【L2 切分维度】按工序在产线上的'阶段位置'切分，作为'目录'帮助快速定位：准备阶段（在主体生产之前的准备性活动）/ 加工阶段（生产主体并对主体做加工与组合）/ 收尾阶段（主体已成型之后的整饰、伴生、验收、交付）。L2 本身只承担目录定位，不作为 roles[] 取值。 【L3 切分维度】每个 L2 内按'抽象工序阶段'切分。L3 节点直接作为 roles[] 字段的规范取值——名称必须是抽象工序角色（如'预处理 / 主体生成 / 装配 / 后期'），不允许携带领域技法词（如'调色 / 光影 / 提示词 / 多视图'）。领域技法 / 具体输出形态名词全部下放到 L3 的'同义术语'段做规范化。

准备阶段

目录定位：主体生产之前的所有准备性活动——尚未产出本批主干件，只是为主干件的产出建立长效规则、备齐原料、把原料加工成工具能用的输入。判别口诀：把这一步抽掉，影响的是'下一步缺规则 / 缺原料 / 缺可用输入'，不是'下一步缺主干件'。

• 工艺规约：它是什么阶段：meta-工序——不在每批生产中重复发生，但贯穿后续所有批次。 它的作用：建立一组可被反复套用的长效生产规约——其产物的服务对象是'未来的多次生产'，而不是'本次一份具体作品'。 与相邻阶段的边界：与'预准备 / 预处理'的边界——工艺规约的产物长效复用（跨批次），预准备 / 预处理的产物一次性消费（per-batch）。 同义术语（写 roles[] 时统一规范为「工艺规约」）：工作流编排 / pipeline 建立 / 流水线设计 / 节点图设计 / Agent 编排 / 规则建立 / SOP 建立 / 规约制定 / 标准制定 / 参数约定 / 质量门槛建立 / 模板沉淀 / 模板范式建立 / 提示词模板沉淀 / 剪辑模板沉淀 / 版式沉淀 / 知识库构建 / 素材库搭建 / 提示词库搭建 / 知识沉淀 / LoRA 训练沉淀 / Embedding 沉淀 / 语料库建立。
• 预准备：它是什么阶段：本批生产开始前的'物料备齐'阶段。 它的作用：为本批生产把所需要的原材料 / 参照样本'拿到手'——只'取'，不加工。产物在本批生产中被一次性消费或被参照。 与相邻阶段的边界：与'工艺规约'的边界——预准备是 per-batch 一次性（本批用完即止），工艺规约是 meta- 长效（跨批复用）。与'预处理'的边界——预准备是'去拿料'（来料原样），预处理是'把料加工成工具能直接吃的输入'（料 → 加工后输入）。 同义术语（写 roles[] 时统一规范为「预准备」）：素材采集 / 原料采集 / 素材抓取 / 素材准备（原料侧）/ 拍摄 / 录像 / 录音 / 录屏（自己的）/ 参考收集 / 参考整理 / ref 收集 / 风格参考采集 / 参考准备 / 物料备制。
• 预处理：它是什么阶段：本批生产开始前的'输入加工'阶段——介于预准备与主体生成之间的转换步骤。 它的作用：把已拿到的原材料加工成生产工具能直接消费的输入——产物是一份'工具直接吃'的输入包，不是主干件。 与相邻阶段的边界：与'预准备'的边界——预处理对已有原料做加工产出工具可用输入，预准备只是去取原料。与'主体生成'的边界——预处理产出的是输入侧（被消费），主体生成消费这些输入后产出主干件（产出侧）。 同义术语（写 roles[] 时统一规范为「预处理」）：输入构造 / 输入准备 / 输入加工 / 提示词构造 / prompt 编写 / prompt 拼写 / 从图片提取 prompt（action 选 反推）/ caption 提取（用于输入）/ 控制图准备 / mask 准备 / 蒙版准备 / 骨架图准备 / 输入预处理。

加工阶段

目录定位：本批主干件的成型与组合活动——从输入产出本批主干件、把多件主干件组合成复合件。判别口诀：本阶段是产线的核心环节，本批作品的实体形态在这里被造出来或被结构性组合。注：对单件主干做内容层局部修整（增 / 删 / 替换 / 重述 等动作）由动作树的'修改'L1 承担，不作为本树独立的阶段角色——它可以在主体生成与装配之间反复发生 0~N 次，但不构成独立的阶段位置。

• 主体生成：它是什么阶段：产线核心生产工序——本批作品主干件的诞生时刻。 它的作用：从输入产出本批作品的核心主干件（从 0 到 1）——这一份主干件是后续装配 / 后期 / 验收 / 交付的对象。 与相邻阶段的边界：与'预处理'的边界——主体生成消费输入产出主干件（产出侧），预处理产出供给主体生成的输入（输入侧）。与'装配'的边界——主体生成是产出单件主干（输入 → 一件单件），装配是组合多件已就绪的零件（多件 → 一件复合件）。 与动作树'修改'的边界：主体生成产出新主干（从 0 到 1，输入是引导信息），动作.修改 是在已有主干上做局部内容改动（从 1 到 1，输入是已有对象）；当一步是'在主体生成后对单件主干做局部修整'时，它在动作维度归 修改.增/删/变，但在本树（作用维度）依然属于'主体生成'阶段的延续，不构成独立阶段。 同义术语（写 roles[] 时统一规范为「主体生成」）：主体成型 / 成品生成 / 底图构建 / 底图生成 / 锚图构建 / 主图生成 / 主资产生成 / 主体构建 / 草图构建 / 线稿生成 / 粗稿生成 / 雏形构建 / 结构搭建（视觉主干）/ 布局搭建 / 构图搭建 / 分镜图构建 / 分镜图生成 / 分镜图构建发展 / 镜头画面生成 / 文本撰写 / 文案撰写 / 正文撰写 / 脚本编写 / 台本撰写 / 口播稿撰写 / 对白设计 / 主音频生成 / 主 BGM 生成。
• 装配：它是什么阶段：把多个已就绪的对等零件组合成一个复合件的工序——本批最终产物的'拼成'阶段。 它的作用：把多个独立的对等零件按时间 / 空间 / 层级关系组合成一个不可拆的复合件（多件 → 一件）。 与相邻阶段的边界：与'主体生成'的边界——装配的输入是已就绪的多个零件（前置已完成产出），主体生成是从输入产出零件本身（单件 → 一件）。与'后期'的边界——装配是结构性组合（改产物组成），后期是呈现层调节（不改组成）。 与动作树'修改'的边界：装配是把多个已有件组合成新的复合件（结构组合，多 → 一），动作.修改 是在单件上做局部增删变（不改对象身份）；二者不冲突——一步既可能是'装配'（阶段角色）又可能含 修改 动作（如剪辑中对单镜做剪除）。 同义术语（写 roles[] 时统一规范为「装配」）：装配集成 / 组装合成 / 集成 / 复合产出 / 合成剪辑 / 视频剪辑 / 剪辑组装 / 镜头组装 / 时间轴组装 / 成片剪辑 / 串联（多镜头）/ 排版 / 图文排版 / 落版 / 版式集成 / 拼图（格子化）/ 信息图组装 / 图层合成 / 多图融合 / 图像合成 / 多图层合成 / 抠图合成 / 双重曝光合成 / 音视频合成 / AV 合成 / 配音挂载 / BGM 挂载 / 音效挂载 / 字幕烧录 / 混音 / 跨轨合成。

收尾阶段

目录定位：本批主体已成型 / 已装配之后的整饰、伴生、验收、交付活动——产物不再被结构性改造，只对其呈现层做整饰、为其配套伴生信息、对其做最终审查、把其推向终态对外交付。判别口诀：把这一步抽掉，影响的不是'是否有主体 / 是否成型'，而是'主体是否已'整饰到位 + 配套到位 + 验收到位 + 推到终态'。

• 后期：它是什么阶段：主体 / 复合件成型后的整体呈现层整饰工序——只调产物的'看上去 / 听上去'层，不改产物的内容 / 元素 / 结构。 它的作用：对已成型的产物做整体呈现层的调节——产物的内容主体不变，但整体调性 / 氛围 / 光感 / 色调 / 风格被整饰。整图 / 整片统一作用，不锁定具体元素。 判别口诀——把这一步前后两个产物并排对比： - 没有任何具体内容变化（画面里没有'多 / 少 / 改'掉哪个具体的东西），只是整体调子 / 风格 / 氛围 / 光线变了 → 归后期 - 多了 / 少了 / 改了具体的语义元素（人 / 物 / 段 / 镜 / 水印 / logo）→ 不归后期，归动作.修改（增 / 删 / 替换 等）；在本作用树里这种情形继续算作'主体生成'阶段的延续，不构成独立阶段 特殊边界： - '整体清晰度提升 / 超分 / 整体降噪 / 整体锐化'——虽然全图作用，但属于呈现质量增强（不增减语义内容）→ 后期 - '加雾 / 加粒子 / 朦胧化'——属于氛围呈现层（无具体语义对象）→ 后期 - '加水印 / 加 logo / 加配饰'——增加了具体语义元素 → 不归后期（在本树归主体生成延续；在动作树归 修改.增.叠加） - '换色'有歧义——指定某元素改颜色（局部内容改）→ 不归后期；整图换色调 → 后期.调色 与其它相邻阶段的边界： - 与'装配'：后期是同一件的呈现层调优（不改组成），装配是多件 → 一件的组合（改组成）。 - 与'交付'：后期是中段整饰（产物还可继续配套 / 验收），交付是把产物推向终态对外。 - 与动作树'修改'：后期改呈现层（整体调性），动作.修改 改内容层（具体元素）；二者是同一根'改什么'轴的两端，本树只保留呈现层这一端作为阶段角色。 同义术语（写 roles[] 时统一规范为「后期」）：表面修饰 / 表面处理 / 风格化 / 风格调优 / 风格化处理 / 风格统一 / 风格迁移（制作侧）/ LoRA 套用 / 滤镜套用 / 调色 / 调色统一 / 色彩统一 / 色调对齐 / LUT 套用 / 色彩校正 / 校色 / 整体调色 / 整体色温调整 / 氛围渲染 / 氛围增强 / 氛围特效 / 情绪渲染 / 加雾 / 加粒子 / 朦胧化 / 光影修饰 / 光影调节 / 重打光 / 阴影修整 / 高光强化 / 加体积光 / 对比度调节 / 整体清晰度提升 / 超分 / 整体降噪 / 整体锐化。
• 配套伴生：它是什么阶段：主体成品已就绪后，为其生成依附性伴生信息的工序——产物本身不是独立资产，而是依附于主体成品存在的元信息 / 说明性内容。 它的作用：为已生成的主体成品配套生成伴生信息（说明性 / 描述性 / 元信息性），用于对外展示 / 检索 / 发布时附带在主体旁。 与相邻阶段的边界：与'主体生成'的边界——配套伴生的产物依附于已有主体成品（无主体则无意义），主体生成的产物本身就是主体（独立资产）。与'交付'的边界——配套伴生产出'附在主体旁的伴生信息'，交付负责把'主体 + 伴生信息'一起推向终态。 同义术语（写 roles[] 时统一规范为「配套伴生」）：文本伴生 / 描述伴生 / caption 生成 / 描述生成 / 配文生成 / 文案配套 / 发布文案配套 / 标题配套 / 短描述配套 / alt text 生成 / 标签生成 / 元数据生成 / 视频简介生成。
• 检验：它是什么阶段：终态对外交付前的审查工序——产物不再被改造，但要被验证其质量 / 合规 / 完整性。 它的作用：对已就绪的主体 + 伴生信息做质量审查 / 合规校验 / 完整性确认——产物是审查结论（通过 / 待修 / 不通过），不是新增的实体资产。 与相邻阶段的边界：与'后期 / 配套伴生'的边界——检验不改变产物（只做评估），后期 / 配套伴生会改变产物（改外观 / 加伴生信息）。与'交付'的边界——检验产出审查结论（评估），交付产出最终对外的成品（实物）。 同义术语（写 roles[] 时统一规范为「检验」）：质量检验 / 成品校验 / 终审 / 质量评估 / 合规校验 / 品质审查 / 过程审核 / 人工校稿 / 阶段化展示（用于审查目的）/ 试发布 / 小样测试。
• 交付：它是什么阶段：产线的最末工序——把已就绪 + 已伴生 + 已审查的产物推向终态对外的工序。 它的作用：产出最终对外的交付物——主体 + 伴生信息按发布规格 / 终态格式被一并输出 / 发布 / 归档。 与相邻阶段的边界：与前面所有阶段的边界——前面所有阶段处于工序中段（产物可继续被改造 / 整饰 / 审查），交付处于工序末端（产物即终态对外）。 同义术语（写 roles[] 时统一规范为「交付」）：成品输出 / 成品定稿 / 定稿输出 / 终稿交付 / 最终导出 / 出片 / 出图（终态）/ 终稿出文 / 多视图展示（作为终态交付物形态）/ 多角度展示 / 成品多视图 / 阶段化展示（作为终态交付物形态）/ 成品阶段化展示 / 成品输出阶段化展示 / 发布。

动作（action）

对到下面这棵树的某节点（填叶子名或 根/…/叶 全路径，如 解构 或 提取/化学提取/解构）。❌ 别自己造动词。拿不准某词归哪类，查 spec/taxonomy/action.json 的 分类说明。

⚠ 反推 vs 解构：从文字/教程里提炼框架、步骤、要点 → 解构（信息在原文里显式可见）；从图片推回生成它所用的 prompt、或推断其隐含结构（depth map / 风格参数等）→ 反推（信息在原图里不可直接看到）。"梳理教程结构""分析原文框架""提取风格要素"几乎都是 解构，不是 反推。

获取
  搜索
    检索
    下载
  查询
    调取
  录入
    上传
    拍摄
    录音
    键入
  引用
    选取
提取
  物理提取
    裁切
    抠取
    抽帧
  化学提取
    识别
    反推
    解构
生成
  元素生成
  关系生成
    数组生成
    结构生成
修改
  增
    添加
    叠加
  删
    抹除
    剪除
  变
    重述
    风格化
    转换
    替换
    调整
    增强
存储
  暂存
    缓存
  沉淀
    入库
  归档
    存档

类型（type）——漏斗式，别跳步

1. 先列候选：根据这份数据的内容，列 3-5 个候选类型词（覆盖不同抽象层）。
2. 匹配下面这棵树（命中即停）：候选里有直接命中标准叶子的 → 用它；都没命中则挑最近的叶子做挂靠，在本工序的 type_registry 里登记："主角图": {"extends": "参考图", "desc": "本案例的女主肖像"}。

3. 自查：每个类型要么是标准叶子、要么在 type_registry 里有挂靠 + 说明。不允许写个自造词却不登记（lint-case.py 会抓出来）。

   程序控制类型
   指令
   提示词
   负向提示词
   描述
   参数
   生成参数
   规格参数
   模型权重
   评估
   评分
   评语
   流程
   工作流
   批处理
   数据复用类型
   原子
   数字人
   版式
   序列
   模板
   内容类型
   素材
   化学变化
     参考图
     参考视频
     参考音频
     对标内容
     分镜图
     转场
     蒙版
     控制图
     运动轨迹
     滤镜
     构图布局
   物理变化
     截图
     视频片段
     转场片段
     关键帧
     音效
     特效
   半成品
   序列
     大纲
     脚本
     分镜脚本
     剪辑脚本
     配音文案
   原子
     底图
     样图
     分镜视频
   组合
     图层组合
     拼图
   准成品
   歌词
   配音
   BGM
   字幕
   标题
   正文
   成品
   成品图
   视频成品
   合成图
   知识类型
   知识库
   

实质 / 形式（substance / form）

这两个字段只描述最终产物画面内容的视觉维度，与步骤处理的是什么类型的数据无关。从核心要回答这个方法，未来可以用在哪些内容领域。

实质（substance）：画面里有什么——这步的方法或产物所针对的视觉内容主体。如：美女、草原等。

• ❌ 不填分析维度：风格、视觉风格、氛围 描述的是"长什么样"，不是"有什么"，属于形式而非实质
• ❌ 不填数据类型：提示词、描述、框架 是步骤处理的信息类型，不是画面主体
• ⚠ 即使这步产出的是文字（提示词、描述、框架），也要填这步所面向/描述的画面主体——不能因为产出是文字就填 null

形式（form）：画面长什么样——视觉风格与审美调性。填风格词，如 超现实主义、古风、氛围感。

• ❌ 不填数据格式：JSON、表格、列表 是技术格式，不是视觉风格
• ⚠ 即使这步产出的是文字（提示词、描述），只要步骤面向特定风格，就填该风格——不能因为产出是文字就填 null
• 步骤对风格没有任何限定（方法适用于任意风格）→ 才填 null

没有特别涉及的直接设 null——不要为了填而填。多个主体/风格都重要时用顿号并列：小孩、围巾。

---

起手先判断作者意图：这篇讲的是可复用的通用方法，还是记录一次操作的具体案例？

• 通用方法文（核心是教一套可以套用到其他地方的做法）→ 实质填方法的作用对象，尽量具体：专讲人物的填 人物，专讲产品的填 产品，专讲风景的填 风景；方法确实没有题材限制时，填比 图片 更具体的大类，如 实拍图、、信息排版图 等。形式：方法有明确风格倾向则填，否则 null。
• 具体案例文（核心是复盘某次创作，没有推广意图）→ 实质填案例里实际出现的视觉主体（如 人物、场景），形式填案例的具体视觉风格（如 超现实主义）。

判断依据：文章有无"这个方法可以用于……""换个题材也能套""任何图片都能跑"这类泛化表述？有 → 通用方法；没有 → 具体案例。判断不清时偏具体案例方向。

常见错误速查

错误填法	为什么错	正确填法
substance=风格	风格描述"长什么样"，是形式不是实质	form=超现实主义，substance=实际主体或 null
substance=提示词 / 描述 / 框架	这是数据类型，不是画面主体	substance=null
form=JSON结构	技术格式不是视觉风格	form=null

null 的设置方式：--set 'p1.s1.form=__null__'

目的列（intent）

每步一句话概括，≤25 字，跨步骤一起看（为了让每行各有侧重）。

写法：

1. 像句人话，读出来通顺。别写成公式（不要出现 →、: 这种符号串）。
2. 关键词用 {类别:值} 标出来。能用的类别只有 5 个：{effect:}、{via:}、{act:}、{in-type:}、{out-type:}。类型必须带 in-/out- 前缀。
3. 同类的几个值各标各的，别揉成一个。

例子：

• ✅ {via:human} {act:解构} {in-type:教程原文}，得到 {out-type:提示词框架}
• ✅ 以 {in-type:参考图} 和上一张 {in-type:分镜图} 为参考，{via:manus} {act:元素生成} 当前 {out-type:分镜图}
• ✅ {via:manus} {act:反推} {in-type:参考图}，得到 {out-type:提示词}（从图推回 prompt 才是反推）
• ❌ {act:反推}: {in-type:视频} → {out-type:提示词}（写成了公式）

归类落盘命令

🔒 词表已内嵌在上方，直接对照填即可，不需要额外 read_file 任何 taxonomy json。

python spec/tools/wf-patch.py --workflow outputs/case-N/workflow.json \
    --set 'p1.s1.effect=主体生成' \
    --set 'p1.s1.action=生成/元素生成' \
    --set 'p1.s1.inputs[0].type=参考图' \
    --set 'p1.s1.substance=图片' \
    --set 'p1.s1.form=__null__' \
    --set 'p1.s1.intent=用 {via:豆包} {act:元素生成} {in-type:提示词}，得到 {out-type:生成图}' \
    --set 'p1.type_registry.主角图.extends=参考图' \
    --set 'p1.type_registry.主角图.desc=本案例的女主肖像'

第二阶段过关条件：每步的作用/动作都命中标准词、每个类型要么命中词表要么登记了挂靠、每步的 substance/form 都已处理（填值或显式设 null）、每步都有 intent → 进第三阶段。

---

---

第三阶段 · 检查 + 渲染

# lint 带 --source 才会跑「章节覆盖」+「value 逐字」两条强制
python spec/tools/lint-case.py --workflow outputs/case-N/workflow.json --case-id N \
    --source input/case-N.json --ocr outputs/case-N/_scratch/ocr.txt

python spec/tools/render-case.py --workflow outputs/case-N/workflow.json \
    --source-input input/case-N-raw.json --page-title "Case N · 主题" --case-id N \
    --out outputs/case-N/case-N-<slug>.html

收尾检查清单

检查	规则	反面例子
输出编号唯一	每个输出都有编号，工序内不重复	两个输出都叫 s2o1
数据流连得上	每个 ← 某编号 都能找到已存在的输出编号	引用了 ← s2o9 但根本没有这个编号
类型对得上	输入的 type 和来源输出的 type 一致	输入写 分镜图 但来源输出是 参考图
"值"写真内容	文字写全文；图片视频用 <整段描述>；不写 ← sN 引用	值 = ← s1o1
作用/动作命中词表	作用是 9 个标准词之一；动作是动作词表里的路径	作用写成"开端"（词表里没有）
类型命中词表或挂靠	类型是词表里的词，或自造但在 type_registry 里写了"算作"哪个标准词	类型写"小品"却没说挂靠 视频成品
自造类型登记齐全	lint-case.py 提示"类型完整性 N 个问题"说明有自造类型没登记 → 补	type='主角图' 但没在 type_registry 登记
章节全覆盖	原文每个 0N 章节都对应到某工序/步骤；lint 报漏抽 → 回 Phase 1 补工序	原文"02 结构化框架"整章没抽
文本 value 逐字	文本类 value 是原文一整段连续文本；lint 报"疑似缩写" → 回 Phase 2 用 @quote 重填	350 字提示词被写成"主题:…。核心要素:人物、产品"
目的列规范	≤25 字一句话；5 个合法标记类别；别写成公式	{act:反推}: {in-type:视频} → {out-type:提示词}