ArtCraft 管出图工作流、视频环节单独留一份参数，两边改动别互相带

改完出图那部分，视频那部分的输出也跟着变了，通常是两条线读了同一份参数：同一个工作流文件里的全局变量、同一段默认值继承，或者某个节点被两边同时引用。判断方法不复杂——先把图像环节和视频环节在结构上分开编号，各自抄一份当前参数当基线，然后只改图像侧跑一次，看视频侧输出是否变化；共用部分如果摘不干净，就单独冻结或分离。顺序不要颠倒，先分结构再动参数，否则改完连「原来是什么」都找不回来。

图像段和视频段互相带，多数不是模型本身的问题，而是两段读了同一份参数。适用场景：一个工作流里同时有出图节点和视频节点，且视频段会复用图像段的中间产物。操作动作：拆段编号、各抄一份基线、单侧改动做一次交叉验证、共享参数冻结或分离。验证方式：只动图像侧，比对视频侧输出文件与节点日志里的实际入参。风险边界：参数可以分开，但视频段依赖图像段产物（首帧、结构图）时，产物依赖仍然存在，需要单独确认。

把当前工作流按图像环节和视频环节拆成两段并分别编号

这一步只改结构认知，不改任何数值。把工作流里所有节点按「主要服务于谁」归到 IMG 段或 VID 段，两边都读的放进 shared 段。编号的作用是给后续操作一个稳定称呼，避免说「改了那个节点」时两边理解不一致。

# segments.yaml —— 只登记结构，不写具体参数值
img_segment: IMG-01
  nodes:
    - img-01.model_loader
    - img-02.prompt_encode
    - img-03.sampler
    - img-04.decode
vid_segment: VID-01
  nodes:
    - vid-01.frame_input
    - vid-02.motion_params
    - vid-03.interpolate
    - vid-04.encode
shared:
  - common.seed_policy
  - common.output_dir
  - common.resolution_base

共用部分要标注到「谁在读它」这一层。例如 vid-01.frame_input 读的是 img-04.decode 的输出文件，这是产物依赖，不是参数共用，两者必须分开记：产物依赖通常没法靠冻结参数解决，只能靠固定产物版本。先把这份节点清单落在工作流目录里，后续所有改动都按 IMG-01、VID-01 指认。

分别抄录两条线当前使用的参数各一份

基线要在动手改之前抄。抄录的对象是界面上或配置文件中真实生效的值，不是默认值推测出来的值；能导出运行日志的，优先以日志里打印的入参为准。

# baseline_IMG-01.yaml
segment: IMG-01
source: 当前工作流导出
nodes:
  img-01.model_loader: 模型名:<填>, 精度:<填>
  img-03.sampler: steps:<填>, cfg:<填>, 采样器:<填>, seed:<填>
  img-04.decode: vae:<填>

# baseline_VID-01.yaml
segment: VID-01
source: 当前工作流导出
nodes:
  vid-01.frame_input: 来源:<填>, 帧率:<填>
  vid-02.motion_params: 时长:<填>, 运动强度:<填>
  vid-03.interpolate: 倍率:<填>, 插帧模型:<填>
  vid-04.encode: 编码:<填>, 码率:<填>

共用参数单独列一份 common.yaml，每个键后面写一句依赖说明，例如 resolution_base 被 img-03 与 vid-04 同时读取。这一步不要顺手把共用参数复制成两份，先留痕，复制留到冻结或分离时再做，否则基线本身就失真了。

只改图像侧参数跑一次，观察视频侧输出是否变化

改动项只取一个，建议选 img-03.sampler 的 steps 或 cfg，取当前值附近的一个档位，不要同时改三项。跑一次完整流程后收集三样东西：视频侧输出文件、视频侧节点日志里的实际入参、以及流程中是否出现多余的重新编码或重新采样。

sha256sum out/vid_*.mp4 > vid_hash_after.txt
grep -nE "vid-0[1-4]" run.log | grep -Ei "param|seed|resolution|source"

结果判断：视频侧输出校验值与基线记录一致，且日志里 VID 段入参没有读到 IMG 段的值，说明两条线在参数层面基本独立。校验值变了、或 VID 节点日志里出现了 IMG 段的取值，说明存在连带，进入下一节处理。

需要注意一个边界：视频编码环节本身可能带非确定性（时间戳、容器元数据），文件哈希在两次运行间本来就可能不同。这种情况下改比对首帧图像和日志入参，不要只认哈希值，否则会把正常的编码抖动误判成连带污染。

对共享的参数单独做一次冻结或分离处理

先列出被两边同时读取的键，逐个确认是不是真的需要共享。分辨率、seed 策略、输出目录这类通常只是习惯上放在公共位置，并不要求两段取同值；只有真正需要两端一致的键才留下。

# common_base.yaml —— 唯一的共享基线，只放确实需要两端一致的值
resolution_base: <填>
seed_policy: <填>

# img_params.yaml
image_params:
  extends: common_base.yaml
  resolution_base: 1024x1024   # 覆盖，不改基线

# vid_params.yaml
video_params:
  extends: common_base.yaml
  resolution_base: 768x768     # 覆盖，不改基线

分离写法是把共享键复制进各自段配置，并在原共享文件里删掉或标记废弃，防止被隐式读取。冻结写法是保留 common_base.yaml 作为只读基线，任何一段要改共享值都写进自己的覆盖项，不回写基线。两种写法选一种，不要混用。

验证方式分两步：临时改一次 common_base.yaml 里的值，确认两段入参都跟着变，说明基线仍然是活的；再把基线改回去，只改 img_params.yaml 的覆盖项，确认 VID 段入参不变。两步都过了，共享部分才算处理干净。

把两份最终参数存档并写下还原步骤

存档命名建议统一成 workflow_<工作流名>_<段编号>_<YYYYMMDD>_<变更摘要>.yaml，例如 workflow_artcraft_IMG-01_<YYYYMMDD>_steps.yaml。同一批改动产生的共享基线也留一份同名加 _common 后缀的副本，三份放同一目录，避免只存了段配置、还原时找不到对应的基线版本。

还原顺序是先还原共享基线，再还原目标段，最后做一次对照运行。先落基线是因为共享值会影响两段，最后还原它容易把中间步骤的覆盖项冲掉；目标段放在基线之后，覆盖关系才成立。

还原后的检查点看三处：目标段日志入参与你存档文件的键值逐项对得上；另一段输出与存档时的记录一致；视频段若依赖图像段产物，确认产物文件是对应版本的那一份，而不是最近一次运行的残留。三处都过了，任意一条线都可以单独还原，而不会把另一边带回旧状态。