Agent/examples/process_pipeline/script/procedure-dsl/spec/format/procedure-table.md

工序表 (procedure-table) 规范

可视化页面是一个单文件 HTML, 含 inline <style> + <table class="proc"> + <script> 交互。下面给出结构规范 — 按此命名 + 交互填表即可。

模板与数据分离 (重要)

可视化是 共享模板 + per-case 数据:

文件	角色	内容
spec/tools/renderer.py	共享模板 (renderer)	CSS / JS / 渲染 helpers / 字典树 / build_html(case_data) 主入口
spec/tools/render-case.py	渲染 + 校验 CLI	接 workflow.json (--workflow), 内存组装 case_data + 跑 JSON Schema 校验, 调 renderer.build_html, 输出 HTML
tests/case-{N}/workflow.json	per-case 数据	按 spec/templates/workflow.template.json 填; 顶层 {source, procedures:[]}, 每个 procedure 含 declarations / type_registry / steps / return_row. page_title 由 --page-title 提供
tests/case-{N}/case-{N}-<slug>.html	生成产物	跑 python spec/tools/render-case.py --workflow tests/case-{N}/workflow.json --source-input input/case-{N}-raw.json --page-title "..." --case-id {N} --out ... 输出

case_data 结构 (build_html 输入契约 — renderer 由 workflow.json + --source-input + --page-title + --case-id 在内存组装):

{
    'page_title':    str,                   # 页面 <title> + h1 (来自 --page-title)
    'case_id':       int | str | None,
    'source':        {platform, author, date, url, title, excerpt},   # case 级原文 (折叠块), 跨所有 procedures 共享
    'procedures':    [                                                 # 1 ~ N 个独立工序; 单工序也用长度-1 数组
        {
            'id':            str,                                       # 'p1' / 'p2' ...
            'name': str, 'purpose': str, 'category': str, 'platform': str, 'author': str,   # 工序头部
            'declarations':  {                                          # declare 块
                'inputs':    [{type, name, default?, desc?}, ...],
                'resources': [{type, name, desc?}, ...],
                'returns':   {type, note?},
            },
            'type_registry': {<typename>: {...}},                       # 本工序 case-specific, 与 STDLIB_TYPE_REGISTRY 合并
            'steps':         [{id, kind, effect, via, action, instruction, feature, inputs[], outputs[], intent, focus, group?}],
            'return_row':    {arrow, text},                             # 该工序表底返回行
        },
        # ... 多工序再加 procedure
    ],
}

新增 case 流程: 复制 spec/templates/workflow.template.json → tests/case-{N}/workflow.json → 替换 <填:...> 占位符 (各 phase in-place Edit) → 跑 python spec/tools/render-case.py --workflow tests/case-{N}/workflow.json --source-input input/case-{N}-raw.json --page-title "Case {N} · <主题>" --case-id {N} --out tests/case-{N}/case-{N}-<slug>.html. 渲染主模板 spec/tools/renderer.py 由 render-case.py 内部 import, Agent 不要 Read 它. 唯一 canonical 模板是 spec/templates/workflow.template.json, 不要 Read 其他 tests/case-*/ 下文件 — 那些是 case-specific 产物, 不是模板. 输入契约见 spec/format/case-data.schema.json.

页面结构 (从上到下)

<header class="page-header">     · 页面标题
<details class="declarations">    · 工序头部 + declare 块 (折叠, 默认 open)
<details class="source-block">    · 原文 (折叠, 默认 closed)
<div class="legend">              · 列控制器 (4 个组的 toggle 按钮)
<div class="table-wrap">          · 横向滚动容器
  <table class="proc">            · 23 列工序表
<aside class="drawer">            · 详情侧拉抽屉 (chip / 字典树点击)

整体布局

23 列 table, 2 行 thead, 4 个 group (需求 colspan=3 / 输入 colspan=6 / 实现 colspan=8 / 输出 colspan=6). 行 1 是 group 头, 行 2 是 sub 列细分.

[需求/灰 ───►]   [输入/黄 ────────►]                    [实现/绿 ────────────────►]                          [输出/蓝 ────────►]
# / 目的 / 作用 / 实质 / 形式 / 类型 / 变量名 / 值 / 来源 / 外部工具 / 动作 / 指令 / 配置 / 运行 / 备注 / 逻辑控制 / 特性 / 实质 / 形式 / 类型 / 变量名 / 值 / 去处

列从左到右近似一个自然语言句: 「第 N 步 · 为了 X(目的) · 起 Y(作用) · 给定 Z(数据流·输入) · 由 W(外部工具) 做 K(动作) 用 D(指令) 控制 F(特性) · 得到 V(数据流·输出)」。需求面/数据流 vs 工具组的分割: 需求面 + 数据流 (实质/形式/类型/值/...) 描述"内容生产意图与素材", 工具组 (via/action/指令/特性) 描述"用工具怎么做"; prompt 必须按这条边界拆 — 内容描述部分进数据流的"值"列, 写给工具的 directive (e.g. "严格反推不要发挥") 与工具运行参数 (采样步数 / cfg / LoRA / aspect / 时长) 进工具组的"指令"列。

列分组与模式归属:

分组	列	内容性质	模式切换	底色
摘要句 (caller why)	目的	selector + summarizer 摘要句 — 每行选最有信号的 2-3 维度组一句易懂话, 被选中的维度在本行内高亮	结构化模式整列隐藏	灰组
结构化标签 (caller meta)	作用	纯文本 (无 tag chip 装饰, 保留 data-prefix/value 供 drawer); 取值受字典树 §A.1 规范	自然语言模式整列隐藏	灰组
数据流·输入 (始终)	输入·实质 / 输入·形式 / 输入·类型 / 输入·变量名 / 输入·值 / 输入·来源	实质/形式 路径 (从外部 JSON 词表取) / type chip / name / flow + 字面量值 / 锚链或容器索引	实质·形式 列在自然语言模式整列隐藏, 类型 始终显示	黄组
工具实体	外部工具	L1 canonical 名 (e.g. seedream_4_5) 或占位 <llm> / -	不参与模式切换	绿组
工具动作 kind	动作	纯标签值 (字典树 §A.2 叶子路径); 控制类 控制/X 已分流到 逻辑控制列	自然语言模式整列隐藏	绿组
工具指令	指令	字面 prompt 文本 — 真正喂给工具的 prompt 字符串 (祈使句; 不是步骤说明)	始终显示, 内部 .natural 子段可隐	绿组
工具配置	配置	工具运行参数 (采样步数 / cfg / LoRA / 模型权重 / aspect / 时长 / 帧率)	同上	绿组
调用修饰	运行	caller-side decorator (@采样 / @重试 / @缓存 / @限流 等)	同上	绿组
备注	备注 (memo)	其他结构化字段没能包含的实现方法信息: 经验性招法 (如 "去 BGM" 双重保险) / 替代 variant 说明 / 工具选型理由 / 适用条件 / 已知坑. 数据端用单一 kind ('memo', txt)	同上	绿组
逻辑控制	逻辑控制 (control)	本步的控制流类型: 并行 / 遍历 / 分支 / 请求 / 等待; 普通 step 留 -. 可在 intent 引用 ({control:并行})	同上	绿组
工具特性 (纯执行特征)	特性	执行特征 (随机 / 幂等 / 写外部 / 读外部 / 人工 / 本地); 不含控制流 (那归 逻辑控制列). intent 中不允许引用 ({feature:X} ❌)	自然语言模式整列隐藏	绿组
数据流·输出 (始终)	输出·实质 / 输出·形式 / 输出·类型 / 输出·变量名 / 输出·值 / 输出·去处	同输入侧, 去处 表达下游引用与容器索引	实质·形式 列在自然语言模式整列隐藏, 类型 始终显示	蓝组

目的列是 selector + summarizer: 不复读其他列的全部信息, 而是 selector 选这一行最差异化的 2-3 个维度 (默认信号: 主动作 / 实质或形式的关键变化 / 控制流特性), 用它们组一句易懂话; 被选中的格在它们各自列里加 .row-focus 加深底色高亮 (不用方框)。每行的"高亮形状"不同, 一眼能看出"这一步的关键在哪几格"。

目的列内容规则 (重要):

1. 形式: 简短自然语言句 (≤ 25 字), 读出来像一句话。严禁 任何 dataflow / 伪代码痕迹: 不许出现 → / : 这类符号化连接, 不许 "X: Y → Z" 公式结构。
2. 以结构化元素为骨架: 直接使用其他列已有的结构化值 作为 {kind:value} token, 自动获得对应底色; 允许动词 / 连接词等少量自然胶水 ("用 / 把 / 给 / 到 / 和 / 形成 / 得到 / 为参考 / 当前 / 上一张" 等) 串成连贯句; 严禁 case-specific 简写或 jargon (如 "锚 / 链 / 抽卡 / 喂" 这种没在其他列出现的概念词)。
3. 同行有多个相同列的值时, 各自做独立 token, 不用胶水词聚合: 例如 s1 有两个输出 正向提示词 (type=提示词) + 负向提示词 (type=负向提示词), 不要写 "得到正负 {type:提示词}" (合并 + 加"正负"胶水), 应该写 "得到 {type:提示词} 和 {type:负向提示词}" (两个 type token 独立, 类型名本身已含"负向"语义)。
4. 合法 kind (色底完全对应所引用的列, 输入用黄, 输出用蓝, 实现用绿, 需求用灰):

| kind | 引用列 | 底色 / 形状 | |------|------|------| | {effect:XX} | 作用 (需求组) | 灰 矩形 | | {via:XX} | 外部工具 (实现组) | 浅绿 矩形 + 等宽字体 | | {act:XX} | 动作 (实现组) | 绿 矩形 | | {control:XX} | 逻辑控制 (实现组) — 并行/遍历/分支/请求/等待 | 浅青 矩形 | | {in-type:XX} | 输入·类型 | 黄圆胶囊 chip | | {out-type:XX} | 输出·类型 | 蓝圆胶囊 chip | | {in-sub:XX} | 输入·实质 (叶子短名) | 黄矩形 tag | | {out-sub:XX} | 输出·实质 (叶子短名) | 蓝矩形 tag | | {in-form:XX} | 输入·形式 (叶子短名) | 黄矩形 tag 斜体 | | {out-form:XX} | 输出·形式 (叶子短名) | 蓝矩形 tag 斜体 |

type/sub/form 必须带 in- / out- 前缀, 因为这些列在输入和输出组都有, 引用方向决定颜色 (同一个值如 提示词 作输入时黄, 作输出时蓝).

{feature:XX} 不允许在 intent 中出现: 特性 (随机/幂等/人工/读写外部/本地) 是步骤内部执行属性, 不是用户面向的描述要素; 写到 intent 中等于污染. 若必须表达"人工", 改用胶水词 "手写"/"人工" 或 {via:human} token.

1. 严禁变量名 token — {in:参考视频} / {out:正向提示词} ❌, 改用 {type:参考视频} / {type:提示词}。
2. token 内容必须能在该行实际 cell 中找到来源, 不允许新造。

示例:

• ✓ "用 {via:manus} {act:反推} {in-type:参考视频}, 得到 {out-type:提示词} 和 {out-type:负向提示词}"
• ✓ "把 {in-type:提示词} 按动作/人物/运镜 {control:并行} {act:添加} 到 {out-type:提示词库}"
• ✓ "以 {in-type:参考图} 和上一张 {in-type:分镜图} 为参考, {act:元素生成} 当前 {out-type:分镜图}"
• ✗ "{act:反推}: {in-form:景别角度} → {out-form:纪实记录}" (dataflow 公式)
• ✗ "{in-type:提示词} → {out-type:提示词库}" (用 → 符号化, 应改"到")
• ✗ "锚+链 {act:元素生成} 累积 {out-type:分镜图}" (case-specific 简写"锚 / 链 / 累积"读不懂, 应用真实结构化值)
• ✗ "得到正负 {out-type:提示词}" (用胶水词合并 2 个变量, 应拆成独立 token)
• ✗ "{feature:人工} 手写..." (feature 不能在 intent 引用; 改为胶水词 "手写" 或 {via:human})

作用/动作/特性 列只放标签值: 无 <span class="tag"> 灰底 chip 装饰, 无 xxx: 前缀。保留 data-prefix / data-value 属性以触发 taxonomy drawer。

动作列纯标签值: 只放 动作: kind 值 (e.g. 提取/化学提取/反推 / 生成/元素生成 / 控制/并行)。块头的 ▼ 折叠箭头放 # 列, 动作列不挤。

指令列内容范围: (1) directive 文本片段 — 给工具的指令性 prompt 段落, 如"严格遵循源结构反推, 不要发挥"、"维持人物特征一致"; (2) 工具运行参数 — 采样步数 / cfg / LoRA / 模型权重 / aspect ratio / 时长 / 帧率 / @采样(n=4, pick=人工) 等。case-specific 字面量挂 .natural 类。

数据流 IO 6 子列: 输入侧 实质/形式/类型/变量名/值/来源; 输出侧 实质/形式/类型/变量名/值/去处. 每 step 多 IO 项时, 同列内 vertical 堆叠 (跨列位置对应)。

<thead> (2 行, 行 1 是 4 个 group 头 colspan=3/6/8/6, 行 2 是 23 个 sub 列):

<thead>
  <tr>
    <th colspan="3" class="col-group-demand">需求</th>
    <th colspan="6" class="col-group-input">输入</th>
    <th colspan="8" class="col-group-impl">实现</th>
    <th colspan="6" class="col-group-output">输出</th>
  </tr>
  <tr>
    <th class="col-idx">#</th>
    <th class="col-intent">目的</th>
    <th class="col-effect">作用</th>
    <th class="col-in-substance">实质</th>
    <th class="col-in-form">形式</th>
    <th class="col-in-type">类型</th>
    <th class="col-in-name">变量名</th>
    <th class="col-in-value">值</th>
    <th class="col-in-anchor">来源</th>
    <th class="col-via">外部工具</th>
    <th class="col-action">动作</th>
    <th class="col-directive">指令</th>
    <th class="col-config">配置</th>
    <th class="col-decorator">运行</th>
    <th class="col-memo">备注</th>
    <th class="col-control">逻辑控制</th>
    <th class="col-feature">特性</th>
    <th class="col-out-substance">实质</th>
    <th class="col-out-form">形式</th>
    <th class="col-out-type">类型</th>
    <th class="col-out-name">变量名</th>
    <th class="col-out-value">值</th>
    <th class="col-out-anchor">去处</th>
  </tr>
</thead>

数据流 vs 工具组视觉分割: col-effect 右边界、col-in-anchor/col-via 之间、col-feature/col-out-substance 之间各加一条粗竖线 (border-right: 3px solid #94a3b8) 划分需求面 / 数据流·输入 / 工具组 / 数据流·输出 四段。

每个 step 一个 <tr> (示例骨架)

输入组 6 列: 实质·形式·类型·变量名·值·来源. 输出组 6 列: 实质·形式·类型·变量名·值·去处. 实现组 8 列: 外部工具 · 动作 · 指令 · 配置 · 运行 · 备注 · 逻辑控制 · 特性 (备注 = 其他列没能包含的工艺信息; 逻辑控制 = 并行/遍历/分支; 特性 = 仅执行特征如随机/幂等/人工).

<tr class="step step-main" data-step="s1" data-focus="action,out-form-0,out-form-1">
  <td class="idx">1</td>
  <td class="intent">
    <div class="intent-text">用 manus 反推参考视频, 得到 9 维 {type:提示词}</div>
  </td>
  <td class="effect" data-prefix="作用" data-value="预处理">预处理</td>
  <td class="in-substance" data-prefix="实质" data-value="/表象/视觉/视频">/表象/视觉/视频</td>
  <td class="in-form" data-prefix="形式" data-value="/呈现/视觉">/呈现/视觉</td>
  <td class="in-type"><span class="chip" data-type="参考视频">参考视频</span></td>
  <td class="in-name"><span class="name" data-var="参考视频">参考视频</span></td>
  <td class="in-value"><span class="natural">&lt;10s 床上女性参考视频&gt;</span></td>
  <td class="in-anchor"><span class="flow">← 工序输入</span></td>
  <td class="via">manus</td>
  <td class="action row-focus" data-prefix="动作" data-value="提取/化学提取/反推">提取/化学提取/反推</td>
  <td class="instruction"><span class="natural">"严格反推视频的人物/场景/动作/运镜/光照/色调/风格, 不要发挥"</span></td>
  <td class="feature" data-prefix="特性" data-value="随机">随机</td>
  <td class="out-substance" data-prefix="实质" data-value="/理念/知识/具体内容">/理念/知识/具体内容</td>
  <td class="out-form" data-prefix="形式" data-value="/架构/叙事">/架构/叙事</td>
  <td class="out-type"><span class="chip" data-type="提示词">提示词</span></td>
  <td class="out-name row-focus"><span class="name" data-var="正向提示词">正向提示词</span></td>
  <td class="out-value"></td>
  <td class="out-anchor"><span class="flow">→ s2 / s3</span></td>
</tr>

输入侧 来源 / 输出侧 去处 列: 表达数据流的"上游引用 / 下游引用 + 容器索引". 输入: ← 工序输入 / ← sN.varname / ← s6.分镜图列表[i] / ← 分镜序列[i]. 输出: → sN / → 视频片段列表.追加 / → 返回 短剧.

实质/形式 取值: 路径字符串 (e.g. /表象/视觉/人物, /呈现/视觉/特写), 来自外部 JSON 词表 (分类库导出_实质.json / 分类库导出_形式.json). 详见 syntax §2.1 (实质/形式).

推断补全可视化 (详见 上方 "推断补全标记" 章节): IO 级推断在 item 上标 inferred: True, inferred_reason: "...", 整行 6 个 cell 自动加橙色虚线下划线 + 「推」角标 + tooltip; field 级在 step.inferred_marks dict 标. legend "高亮推断" 一键凸显所有推断 cell.

复合 step (块头) — 列对齐

块头 (并行 / 遍历) 的 ▼ 折叠箭头放 # 列, 控制流 kind 已分流到 逻辑控制 列, 动作列展示父动作 (如 修改/增/添加) 或留空:

<tr class="block-header" data-target="step-3">
  <td class="idx"><span class="arrow">▼</span> 3</td>
  <td class="intent">...</td>
  <td class="effect" data-prefix="作用" data-value="工艺规约">工艺规约</td>
  <td class="in-substance">...</td>
  <td class="in-form">...</td>
  <td class="in-type">...</td>
  <td class="in-name">...</td>
  <td class="in-value">...</td>
  <td class="in-anchor">...</td>
  <td class="via">-</td>
  <td class="action" data-prefix="动作" data-value="修改/增/添加">修改/增/添加</td>
  <td class="instruction">-</td>
  <td class="feature" data-prefix="特性" data-value="控制/并行">控制/并行</td>
  <td class="out-substance">...</td>
  <td class="out-form">...</td>
  <td class="out-type">...</td>
  <td class="out-name">...</td>
  <td class="out-value">...</td>
  <td class="out-anchor">...</td>
</tr>
<tr class="nested step" data-group="step-3">...</tr>

返回行

<tr class="return-row">
  <td class="idx">↩</td>
  <td colspan="24"><span class="kw">返回</span> <span class="chip" data-type="视频成品">视频成品</span> 短剧</td>
</tr>
<!-- colspan=22: 总 23 列减去 idx 列 -->

Type chip 设计 (点击看字典树位置 + extends 桥接)

chip 写法:

<span class="chip" data-type="分镜图">分镜图</span>           <!-- stdlib 叶子 -->
<span class="chip" data-type="主角图">主角图</span>           <!-- case-specific (extends 参考图), drawer 显示桥接 -->

data-type 是真实 type 名。chip 统一色不分类: 表格 类型 列内 chip 用列色 (输入黄 / 输出蓝), declaration / drawer / 返回行的 chip 用中性灰底。点击 chip → drawer 显示该 type 在字典树里的位置 + 分类说明 + extends 信息。

作用 / 动作 / 特性 / 实质 / 形式 列内无 chip 装饰 — 纯文本展示 (无 class="tag" 灰底, 无 xxx: 前缀), 但 span 保留 data-prefix / data-value 属性触发 taxonomy drawer。点击 作用 cell → drawer 显示 §A.1 作用字典树 (当前值高亮); 点击 动作 cell → drawer 显示 §A.2 动作字典树; 点击 实质 / 形式 cell → drawer 显示对应外部 JSON 词表的子树 (按当前值的路径展开)。

紫色 (#6d28d9) 专属逻辑控制流关键字: 工序 / 输入 / 资源 / 返回 / 并行 / 遍历, CSS class .kw / .block-kw — 与 .chip 颜色互不冲突。

CSS / JS 实施 (移到代码层)

CSS 类目录 + 列宽 + 列组着色 + 显示模式切换 — 全部代码在 spec/tools/styles.css, 以那里为 ground truth, 本规范不再列 CSS 代码细节.

JS 交互行为 (drawer 点 chip 弹字典树 / hash 锚跳 / atom 展开 / 列控制器 toggle / 模式切换 / 跨页跳转 / placeholder 替换) — 全部代码在 spec/tools/script.js, 同上.

JS 启动时通过 placeholder 注入两个数据对象:

• typeRegistry — case-specific 类型表 (workflow.json 各 procedure 的 type_registry 合并; stdlib 叶子的 in_tree 由 type.json $leaves 标记)
• taxonomy — 字典树 (effect / action / type / feature 各自 _load_drawer_tree() 产出)

drawer / chip / scroll 等用户交互视觉规范 (颜色 / 显示模式 / row-focus 高亮) 见上一节"Type chip 设计" + 下面 IO td 段; 实施靠 CSS/JS 自己保证, 本规范只说应该长啥样, 不说怎么实现.

输入/输出 td 结构补充

• 输入组 6 列 (in-substance / in-form / in-type / in-name / in-value / in-anchor) 紧贴, 输出组 6 列 (out-substance / out-form / out-type / out-name / out-value / out-anchor) 紧贴, 顺序固定 — 数据流"内容性质"列 (实质·形式) 在前, 物理标识 (类型·变量·值·锚链) 在后
• 多 IO 项时, 每 step 用 N 个 tr 表示, N = max(输入项数, 输出项数), 用 native table rowspan 让数据流列横向严格对齐:
  • tr.step-main: 主行, 包含全部 23 列; 需求组 3 列 (idx/intent/effect) + 实现组 8 列 (via/action/directive/config/decorator/memo/control/feature) 都挂 rowspan="N" 跨整个 step
  • tr.step-sub: 子行 N-1 个, 只含 IO 12 列 (输入 6 + 输出 6)
  • 所有同 step 的 tr 共享 data-step="step-N" 属性, 供 JS 折叠 / hover 高亮分组
  • 视觉: step 之间用 1.5px solid 粗分隔线 (tr.step-main > td { border-top: ... }), 子行内部用 1px dashed 细分隔
• 块头 (并行/遍历) 和 nested step 同样适用多子行规则; 折叠 click 通过 tr.nested[data-step="X"] 选所有 nested 行 (含子行)
• 实质·形式 取值 = 外部 JSON 词表的路径字符串 (e.g. /表象/视觉/人物/特写); 详见 syntax §2.1 (实质/形式); 不要写 "全维" / 实质·人物 等单标签 (旧格式)
• 变量名 (<span class="name">) 可点击触发 prompt 抽屉; 类型 chip 可点击触发 type 抽屉; 实质/形式/作用/动作/特性 文本可点击触发 taxonomy drawer
• caller-side decorator (@采样 等) 归位到 指令 列 — DSL 文本里 @采样(n=4, pick=人工) { 生成图像(...) } 是 caller-side 调用修饰, 落到工具组的 指令 列, 与工具运行参数 (采样步数 / cfg / LoRA / aspect / 时长) 并列: html <td class="via">seedream_4_5</td> <td class="action">生成/元素生成</td> <td class="instruction"> <span class="natural">{ 2K · 1:1 · 4 张 }</span> <span class="natural">@采样(n=4, pick=人工)</span> </td> 好处: 动作 列只放 kind 标签值, 不混入 caller decorator; "这次 step 工具怎么跑的运行参数" (config + sampling + directive) 集中在 指令 一处看. 工序的"数据流输入"列只保留真正的内容素材 (参考视频 / 参考图 / prompt 文本等) - prompt 文本拆为 数据 vs 指令两部分: - 描述内容的部分 (e.g. "卧室床上, 年轻亚洲女性, 湿长发") → 数据流的 in-value 列 (变量 = 参考提示词 / 分镜提示词 等) - 写给工具的 directive 文本 (e.g. "严格反推视频结构, 不要发挥" / "维持人物特征一致" / "去掉 BGM") → 工具组的 instruction 列 - 同一来源 prompt 也要按这条边界拆 (即同一段 prompt 文本里有 directive 句也有内容句的, 拆到两列) - 目的文本要简短 — 每个 step 的 intent-text 一行话, 内嵌 1-3 个 {kind:text} token (kind ∈ in/out/act/via/effect/feature), token 取自该行实际 cell 内容, 不允许新造 - <配置> 已不作为 in-type chip — 工具运行参数挪到 指令 列; 数据流的 in-type 只承载真正的内容素材类型 (来自字典树 §A.3, 如 参考视频 / 提示词 / 参考图) - via 列只放 L1 工具的 canonical name (e.g. seedream_4_5, 不是 ByteDance-Seedream-4.5), 不带 config / 参数 hint - 动作 列只放标签值 (e.g. 提取/化学提取/反推 / 生成/元素生成), 不放动作名 / 函数调用 / 参数值 / 自然语言描述; 控制类 (并行 / 遍历 / 分支) 已分流到 特性 列 --- ### 容易踩的坑 - ❌ 只读文本不读图 — 文章配图里的 prompt 原文、工具配置、UI 参数往往是关键信息 - ❌ 凭印象写 prompt — 必须从图里逐字回填, 截断了就标 note, 不要自补 - ❌ #输入 / #输出 写"全维" — 偷懒, 改成具体子项列举 (实质·人物 + 实质·场景 + 形式·光照 + ...) - ❌ L1 写成抽象动作 — external manus(...) 是具体工具 (L1), 动作 反推提示词(...) 是抽象 (L2), 两层别混 - ❌ tag 与 type 重复 — 领域语义已在 type 名里, tag 不再标 - ❌ 变体写在动作名里 — 不写 生成分镜提示词_按视频拆解, 写 生成分镜提示词.按视频拆解 走 impl A.variant via B - ❌ config 一刀切 — 同一工序内不同 step 的 config 可能不同 (e.g. 两段视频 16:9/12s vs 4:3/5s), 按 step 独立绑定 - ❌ config 串到 via 或动作列文本里 — <配置> 是普通输入参数, 跟 prompt / image 一样挂在 io-in, 不写到 via 的工具名后面也不内联在动作函数调用括号里 (那是 L3/L4 混层) - ❌ via 写工具的人写品牌名 — via 是 L1 引用, 用 canonical seedream_4_5 不写 ByteDance-Seedream-4.5; 人写形式留在 L1 external 定义的注释里就好 --- ### 与 dedup / 训练的衔接 (未来) DSL 既是描述, 也是数据归一化载体。多 case 累积后: - dedup — 同一 prompt block content (除空白差异) 跨 case 出现 → 抽到 stdlib prompt_fragment;同一 step 序列模式跨 case 出现 → 抽到 stdlib procedure_template - 训练 — case 文本 (L3 模板) 作为代码 LM 训练语料;L4 实例的 extracted_values 作为 grounding;#目的 / #输入 / #输出 作为弱监督信号 - 检索 — 跨 case 的 #目的 / 动作 / #输入 / #输出 组合作为检索键 (e.g. "找所有 动作:生成/合成 + #输出 含 实质·动作 的 step") 这些不在当前阶段做, 但 DSL 的归一化倾向就是为它们留口子。 ---