自有媒体流水线：
从提示词到音画同步的成片工程

一、产线的四层结构

流水线并非一堆 API 的堆叠，而是一个四层的分层系统——每层只信任下一层的输出格式，而不关心它的来源：

二、三个模型的工程性格

2.1 文生图：Qwen-Image-2.1 的「对齐纪律」

服务端要求尺寸为 32 的整数倍，插件自动向下对齐；默认 1664×928（16:9 宽幅）、steps=40，实测约 75–90 秒/张。预设（square/portrait/cinema/clip）实为分辨率模板，显式 width/height 会覆盖预设。种子（seed）一旦落盘即可复现——这对本刊意义重大：每一期封面都是一条可审计的记录，而非一次性的巧合。

2.2 文生音乐：以 Token 计量的时间

MiniMax-Music3 的标定关系朴素得迷人：约 25 tokens 换 1 秒音频，上限 9000 tokens≈360 秒整曲。歌词结构标签（[Verse]/[Chorus]…）必须独占一行，否则该行歌词被模型静默丢弃——一个典型的「格式即语义」陷阱。插件按目标时长自动换算 tokens，并在歌词不足以唱满时主动收敛时长：宁可短，不留一段静默。本篇所在专题的两首配乐（40 秒）正是这一逻辑的产物。

2.3 参考生视频：H3 的素材物理学

MiniMax-H3 Ref2VA 接受图/音/视频参考，用占位符（<Picture 1>/<Audio 1>）在提示词中引用素材。这里埋着本项目踩过的最深的一个坑：网关不读客户端本地路径，multipart 直传返回 500；可行解是把素材降采样后转成 base64 data URI 内嵌 JSON。音画同步靠「音频流强度」参数（audio_flow_shift）调节，默认 3.0——数值越高，镜头运动越服从节拍。

三、断点续跑：把「 Render 」变成状态机

电影级生成动辄数十个镜头，云端串行队列一跑数小时，任何网络抖动都可能毁掉整晚。编排层的解法是把一次生成变成可恢复的状态机：每次运行落盘一个工程目录 output/runs/<runId>/manifest.json，本地步骤（出图/作曲）即时完成，云端任务分批提交（默认批大小 2，防过载），wzw_media_run action=resume 可反复轮询、下载已完成片段，全部就绪后自动拼接成片——中途崩溃，从断点继续即可。

# 断点续跑的最小闭环
wzw_media_pipeline mode=movie brief="…" lyrics="…"   # → runId
wzw_media_run action=status  run_id=ep01v2           # 查看片段 27/27
wzw_media_run action=resume  run_id=ep01v2           # 续跑 + 下载 + 自动拼片
# → output/runs/ep01v2/work/joined_*.mp4

本刊《山海经·星门》第一集（27 个 H3 片段）即以此方式完成：分批提交、断点续跑、尾部统一混入配乐——工程上它是一次渲染，概念上它是一台可以暂停的制片厂。

四、合成层的音画同步公式

ffmpeg 合成层把「图 + 乐」拼成 MV 的手法并不神秘，但值得记下这个默认配方，因为它是一套可复算的美学参数：

• Ken Burns 缓推：每张图按音乐时长均分，图像以缓慢缩放/平移制造呼吸感；
• 淡入淡出 0.8s：默认交叉溶解时长，硬切只在节拍点上人为指定；
• 混音守恒：mux 的 mix 模式下，配乐音量默认 0.55、原音轨 1.0——音乐永远做底，不做抢戏者；
• 字卡即静帧：片头字卡用 still 模式生成，与成片统一规格，无「素材感」落差。

五、自有意味着什么

「自有媒体插件」的自负之处不在免费，而在主权：素材不过第三方手、参数由编辑部自持、失败可回溯、风格可沉淀。对一个以「智人如何重写自己」为题的刊物而言，这不是成本问题，而是立场问题——用自己的引擎讲黄昏的故事，是黄昏叙事的第一性。