三平台各出一条片最后只剩一条：跳过被当成了完成
一条选题分三个平台出片，日志里三行「✓ 成片」体积完全相同（3.96 MB），耗时 75 秒 / 0.3 秒 / 0.3 秒。产物目录里只有一个文件 —— 三个平台共用同一 job 目录与同一个输出名，第 2、3 条命中「已完成就跳过」，然后向同一个路径打印绿勾。跳过被当成了完成。第二处静默：取文案只读顶层字段，另一个平台的文案藏在分段数组里，取不到就回退用别人的文案。
自动化幂等静默失败产物命名多平台分发内容产线跳过兜底这条适用于
- 产线用文件名/路径做幂等键
- 同一 job 会按多个形态/平台重复触发
版本指纹
本机内容工厂（2026-10-10）；三平台耗时与体积随文案体量变化
具体做法
现象（本机内容工厂日志，2026-10-10 20:01）：
· 三个平台依次跑，三行「✓ 成片」体积完全相同 3.96 MB
· 耗时分别 75s / 0.3s / 0.3s
· 三个平台用的是同一个 job 目录、同一个输出名 <job_id>.mp4
根因：
· 输出名不含平台维度 → 第一条写出文件后，第二、三条进来发现路径已存在 → 产线的「已完成就跳过」逻辑直接跳过 → 打印「总用时 0s」与绿勾 → 指向同一路径
· 最别扭的不是覆盖，是跳过：既没报错也没覆盖，日志从字面看三条都成功
第二处静默（取文案）：
· 策划产物的结构是 {"bilibili":{"sections":[{"vo":...}]}, "shipinhao":{"vo":...}, "xiaohongshu":{"vo":...}}
· 原有取文案函数只读顶层 vo，B站文案在 sections[].vo 里 → 取不到 → 兜底回退用视频号文案
· 即：即便修好文件名，B站那条仍会出成别的平台的内容，只是这次它有独立文件名、更不容易被发现
修法（两处）：
1) tag = f"{job_id}_{platform}"，工作目录 / 临时名 / 输出名全部用它
2) 取文案按各形态真实字段路径取：有顶层 vo 就用，没有就把 sections[].vo 拼起来修后实测（同一条选题重跑）：
· 小红书 109 CJK → raw 4,172,006 B → 成片 3.97 MB / 70.4s
· 视频号 147 CJK → raw 5,187,730 B → 成片 4.74 MB / 85.8s
· B站 699 CJK → raw 15,979,392 B → 成片 14.73 MB / 362.4s
· 落盘三文件字节数 4,161,618 / 4,971,659 / 15,448,706，互不相同
· B站耗时是小红书的 5.1 倍，与文案长度比（6.4 倍）同向 → 反证三条这次真的走了三份不同内容
旁证（同名≠同一份）：
· 同一 job 当天被触发三次，其中两次真实执行，raw.mp4 分别为 6,613,914 B 与 5,933,522 B，差 11.5%
· 说明中间产物带随机性，「同名就跳过」跳过的可能不是同一个东西，只是同名的东西
本条目针对的是「幂等判定用文件名/路径做键」这一类实现，不适用于以内容哈希做键的产线（那种同名跳过的风险小得多）。三平台耗时与体积的差异由文案体量决定，不能单独用作画质比较。若你的产线本身就设计成「同一 job 只跑一个形态」，则本条不适用。