voc-sop-pipeline.md 19 KB

VOC-SOP 五阶段流水线(产线B 口播/商业短视频)

提炼自 kb-raw/04-SOP工作流/: SOP-视频脚本生成工作流/(SOP 正文 + flow/ 六个流程模板 + scripts/)与 SOP-变装视频生成工作流/。

这是产线B(口播 / 商业短视频)的执行骨架。产线A(音乐 MV)走的是 references/pipeline-a-song-mv.md。


一、核心原则

人不做初稿,AI 不做终稿。

原则 含义
漏斗式生成 对标 → 仿写 → 分镜 → 素材。不跳步
人不做初稿 AI 负责快速生成草稿和逻辑梳理
AI 不做终稿 人类负责经验判断、策略把控、业务修正
分段作业 不一次生成全稿;每阶段单独会话输出,人工确认后再进下一阶段

迭代节奏:初稿目标 65 分 → 修正后 75–80 分 → 终稿。 先做好 1 个案例的格式和逻辑,验证通过后套用到其他案例。


二、五阶段总览

阶段0 准备资料(人工)
   ↓  对标视频链接 + 语音转写文案 + 产品信息 + 品牌调性
阶段1 文案获取(AI辅助 → 人工确认)
   ↓  抖音文案.md + video.mp4
阶段2 脚本仿写(AI初稿 → 人工确认)
   ↓  文案-仿写版.md(10 个版本)
阶段3 分镜生成(AI初稿 → 人工确认)
   ↓  分镜{序号}-{篇章名}.md
阶段4 素材生成(AI生成 → 人工确认)
   ↓  output/images/photo1..N.png + output/videos/视频1..N.mp4
阶段4.5 素材修正(AI辅助 → 人工确认)

各阶段命令映射(本技能仓)

阶段 SOP 原本做法 本技能仓对应
0 准备 人工找对标视频 人工;fmode-mv talk --script <口播稿> 可跳过 1–2
1 文案获取 yt-dlp 下载 + Whisper 转写 仓外环节(需外部工具,本仓不含下载/转写)
2 脚本仿写 flow/2-文案仿写prompt.md templates/copywriting-prompt.md + fmode-mv talk(内置 chatJSON)
3 分镜生成 flow/3-分镜prompt1.1.md templates/storyboard-prompt.md + fmode-mv storyboard
4a 照片生成 scripts/2-generate-photos.js fmode-mv scene --scene-only / fmode-mv keyframe
4b 视频生成 scripts/3-generate-videos.js fmode-mv video(即梦,含 method=3 降级)
4.5 素材修正 scripts/regenerate.js 重跑对应工序并加 --shot <id> --force
— 人物一致性 无(靠 prompt) fmode-mv character-sheet(本技能新增,补最大缺口)

三、阶段 0 · 准备资料(人工主导)

资料类型 具体内容 格式要求
对标视频 参考爆款视频链接或文件 抖音分享链接 / 本地视频文件
视频文案 对标视频的语音转写文本 txt / md
产品信息 卖点、买点、目标人群 —
品牌调性 语气、禁语、视觉风格 —

人工确认点

  • 对标视频是否为目标爆款?
  • 视频文案是否完整转写?
  • 产品信息是否准确?品牌调性是否清晰?案例主题是否明确?

四、阶段 1 · 文案获取(AI辅助 → 人工确认)

输出物:{项目目录}/抖音文案.md、{项目目录}/video.mp4

AI 作业要点:一键下载 + 转写;支持抖音分享链接和本地视频;自动提取并保留原始分段结构。

⚠️ 本技能仓不含下载/转写(依赖 yt-dlp / TikHub API / Whisper 等外部工具, 属仓外环境依赖)。KB 的做法见 kb-raw/04-SOP工作流/…/flow/1-抖音文案获取流程.md。 没有对标视频时,可直接用 fmode-mv talk "主题" 从零撰写(跳过本阶段)。

人工确认点

  • 视频是否成功下载?文案转写是否完整?
  • 分段结构是否保留?是否有遗漏的关键词或数据?

五、阶段 2 · 脚本仿写(AI初稿 → 人工确认)

输出物:{项目目录}/文案-仿写版.md(10 个版本)

必须做到(缺一不可):

  1. 必须使用救猫咪 15 节拍表设计结构(见 references/narrative-playbook.md 第一节)
  2. 必须选择 10 种爆款故事类型之一
  3. 必须设计人物弧光(A 状态 → B 状态)
  4. 必须使用嘴替式开场
  5. 必须使用 VOC 词汇(去专业化)
  6. 每条文案单独输出,标注序号;时长控制 60–120 秒

输出格式

## 文案X:{篇章名称}

**标题**:「爆款标题」

**正文**:

{完整口播文案}

---
**素材要点**:
- 人物弧光:{描述}
- 故事类型:{类型}
- 核心冲突:{冲突}

人工确认点(逐条打勾)

  • 标题是否去专业化?普通老板能看懂吗?
  • 开头 3 秒是否有抓手?(不能有自我介绍)
  • 是否有明显的认知反差或痛点?
  • 讲故事时是否自然植入产品?
  • 是否避免了 B 端黑话?(见第九节黑名单)
  • 是否避免了 AI 味句式?
  • 结尾是否有金句强化记忆?
  • 整体是否有对话感,像在跟朋友聊天?
  • 内容是否从用户买点出发,而不是产品卖点?
  • 是否有具体数字 / 案例支撑?
  • 是否已完成脱敏处理?
  • 15 节拍完整吗?人物有弧光吗?选对故事类型了吗?
  • 有清晰的前提吗?(性格 + 行动 = 后果)
  • 口播文案总时长与视频总时长匹配?(语速约 4–5 字/秒)

关键纠偏

  • 选题大于技巧 —— 好选题本身就是流量
  • 讲买点不讲卖点 —— 讲用户完成后的价值
  • 痛点共鸣 —— 「不会卖不出去」比「才能选对」更有力
  • 故事先行 —— 用案例讲故事,产品自然植入

语速与字数换算(决定文案长度,必用)

  • 每 10 秒视频最多 50 个中文字符,语速 ≤ 4 字/秒
  • 字数 > 35 → 至少 10s 镜头;> 25 → 至少 8s 镜头;第一段至少 10s
  • 优先用 5 / 8 / 10 秒的镜头时长(与即梦 frames 约束对齐)

六、阶段 3 · 分镜生成(AI初稿 → 人工确认)

输出物:{项目目录}/分镜{序号}-{篇章名}.md

命名规则:序号对应文案中的第几个版本(1–10);篇章名从文案标题提取关键词。

分镜结构选择(按内容类型)

结构 适用
救猫咪 15 节拍 90 秒 + 故事型
黄金三秒钩子 30–60 秒快节奏
嘴替式情感共鸣 60–90 秒信任型
10 种爆款故事类型 按类型匹配

必须包含的四块

# {作品标题}

**话题标签**:#话题1 #话题2 #话题3
**总时长**:约90秒
**风格**:{风格描述}

---

#### 场景逻辑描述

```
照片1 → 视频生成 → 照片2 → 视频生成 → ...
```

#### 照片生成表格

| 分镜序号 | Prompt(英文) | 场景说明 |
| ---- | ---- | ---- |

#### 视频生成表格

| 视频段号 | 时长 | 生成方式 | 运镜 | prompt(中文) | 旁白/字幕 | 用到的分镜序号 |
| ---- | -- | ---- | ---- | ---- | ---- | ---- |

#### 口播台词(按时间轴)

| 时间 | 画面 | 口播台词 |
| ---- | ---- | ---- |
| 0:00-0:10 | {画面描述} | {口播台词} |

末尾附完整口播文案(纯文本),方便复制。

硬性要求

  1. 首帧必须是楼外 / 空旷外部场景(有利于图生视频)。
  2. 第一段视频用推镜(从室外推入室内)。
  3. 末帧必须与首帧有视觉呼应(闭环)。
  4. 所有画面比例统一 16:9(竖版项目统一 9:16)。
  5. 每镜时长落在 5/6/7/8/9/10 秒(即梦图生视频硬约束,见下)。
  6. 人物必须使用中国人形象;避免两个镜头出现同一个人物(除非有 character-sheet 参考图)。
  7. 相邻照片保持色调连续性。

人工确认点

  • 首帧是楼外/空旷外部场景吗?第一段视频是推镜入室内吗?
  • 人物有视觉弧光(服装/表情/环境变化)吗?
  • 三层冲突都有画面表现吗?
  • 景别变化丰富(大远→中→近→特写)吗?
  • 节奏有张弛(每 10–15 秒一个小高潮)吗?
  • 转场有设计(匹配/动势/淡入淡出)吗?
  • 末帧与首帧有视觉呼应吗?
  • AI 提示词足够具体(画面细节、风格、光影)吗?
  • 口播台词时间轴与视频时长匹配?
  • 照片 → 视频映射完整?(每张照片都有对应视频段)

七、阶段 4 · 素材生成(AI生成 → 人工确认)

7.1 照片生成

  • 首张照片必须为楼外 / 空旷外部场景
  • 人物必须使用中国人形象
  • 比例 16:9(竖版 9:16);画质 2K 起

即梦尺寸约束(实测,必须遵守)

端点 面积 推荐尺寸
text2imgV3(场景图) [512², 2048²] 1K 1664×936(16:9) / 2K 2560×1440
getImgV4(关键帧/人物) [1024², 4096²] 2K 2560×1440 / 4K 5404×3040

给 getImgV4 传 1280×720 会在轮询阶段才报 height or width invalid。 本技能仓已用 assertValidSize() 在本地拦下。

7.2 图片压缩(视频生成前预处理)

视频 API 的 base64 输入限制约 4–5MB(字符串长度),大 PNG 直接转 base64 会超限。

const sharp = require('sharp');
// 2560×1440 PNG (~5.6MB) → 1280×720 JPEG q80 (~200KB),base64 从 ~750 万字符降到 ~28 万字符
await sharp(inputPath).resize(1280, 720).jpeg({ quality: 80 }).toFile(outputPath);

本技能的等价实现:lib/jimeng.mjs 的 prepareImageUrl() 用 ffmpeg 做同样的压缩(零 npm 依赖,不引入 sharp),再上传七牛拿公网 URL。

7.3 素材映射预检(视频生成前必做)

photo1 → 视频1(首帧), 视频1(尾帧)
photo3 → 视频2(首帧)
photo4 → 视频3(首帧)
...
  • 每张照片(photo1..N)在分镜中都有对应的视频段?
  • 视频脚本里的首帧路径都指向存在的文件?
  • method=3 的两张图都存在?
  • 映射关系与分镜文档一致?

踩坑记录:元气森林项目中 photo1(楼外场景)生成了但没有对应视频,后期才发现需要补生成。

7.4 视频生成

frames = 24 × 秒数 + 1        (5秒=121,6秒=145,7秒=169,8秒=193,9秒=217,10秒=241)

实测硬约束(比 KB 记载更严)

  • frames 范围 [121, 241],且 frames % 24 === 1 → 合法值只有 121/145/169/193/217/241
  • 也就是说:单镜只能是 5~10 秒的整数秒
  • 分辨率统一 720p(省钱;¥0.28/秒)
  • 每个 prompt 必须包含背景音效描述(如「温暖氛围音乐」「励志管弦乐」「科技感电子音」)
  • 首段用 method=3(首尾帧,config.image_urls = [首帧, 尾帧] 数组);其余用 method=2(首帧,单张)

method=3 降级逻辑(必须内置)

method=3 比 method=2 更容易失败(两张图数据量翻倍 + 首尾帧一致性要求更高)。

async function generateVideo(data) {
  if (data.method === '3') {
    const result = await submitVideo({ ...data, method: '3' });
    if (result.data?.workId) return pollAndDownload(result.data.workId);
    console.log('method=3 失败,降级为 method=2');
  }
  return submitVideo({ ...data, method: '2' });   // 降级:只传首帧
}

场景跨度大时禁用 method=3(硬规则): 室内→室外、人物→空镜这类差异过大的两帧会崩坏。 method=3 只用于:同场景连续动作、相似场景过渡、数据/状态渐变。

本技能的 jimeng.img2video() 已内置该降级,并在返回值里用 degraded: true 留痕 (绝不悄悄降级)。

7.5 人工确认点

  • 照片按分镜序号生成了吗?人物形象符合要求吗?
  • 场景与分镜描述一致吗?色调连贯吗?
  • 视频生成成功吗?时长符合要求吗?运镜方式正确吗?
  • 照片 → 视频映射完整?
  • base64 大小未超限?(压缩后 < 50 万字符)
  • 首段视频降级策略已准备?每张照片都有对应视频?

八、阶段 4.5 · 素材修正(AI辅助 → 人工确认)

触发场景:某张照片效果不符预期 / 某张照片没对应视频 / 某段视频运镜不理想 / 素材间视觉一致性需微调。

作业流程

人工检查素材 → 指出需修正项 → 重跑对应工序 → 验证修正结果

本技能仓的修正方式(比重写脚本更简单):

# 单镜重做:只重跑第 3 镜,覆盖旧产物
fmode-mv scene  --from work/storyboard.json --shot 3 --force
fmode-mv video  --from work/storyboard.json --shot 3 --force

# 整个人物形象不满意 → 换描述重跑
fmode-mv character-sheet --desc "新的设定…" --force

# 素材全跳过只想重拼 → 直接重跑剪辑(零 API 费用)
fmode-mv assemble --from work/storyboard.json

人工确认点

  • 修正后的素材与分镜描述一致?
  • 修正后的素材与相邻素材色调连贯?
  • 原有映射关系未破坏?

九、合规与表达边界

9.1 词汇黑名单(B 端黑话 → 人话)

禁止词 替代词
赋能 帮助、让…能做到
解决方案 方法、路、招
闭环 做完还能接着做
打法 做法、玩法
赛道 领域、市场
生态 体系、系统
矩阵 一套、组合
操盘 运作、运营
颗粒度 具体程度
链路 流程、步骤
认知 想法、认识
心智 印象、想法
壁垒 优势、护城河
精准 准、到位

9.2 脱敏处理规则(五条,逐条过)

  1. 真实品牌名 → 泛指代称(某品牌、某竞品)
  2. 具体人名 → 「某总」、「某人」、「创始人」
  3. 真实地名 → 「某地」、「某某城市」
  4. 具体数字 → 模糊化(如「数十亿」而非「23 亿」)
  5. 可识别特征 → 抽象化描述

9.3 其他红线

  • 开头 3 秒不得自我介绍(详见 references/narrative-playbook.md 2.3)
  • 禁用「值得注意的是…」这类 AI 报告腔
  • 讲买点不讲卖点
  • 不得伪造数据、案例、客户评价

十、质量检测清单(发布前总检查)

10.1 文案(阶段2)

  • 标题去专业化 / 开头 3 秒有抓手 / 有认知反差或痛点
  • 故事自然植入产品 / 避免 B 端黑话 / 避免 AI 味句式
  • 结尾有金句 / 有对话感 / 从用户买点出发 / 有具体数字案例
  • 完成脱敏处理 / 15 节拍完整 / 人物有弧光 / 选对故事类型

10.2 分镜(阶段3)

  • 首帧是楼外场景 / 第一段是推镜 / 人物有视觉弧光
  • 三层冲突有画面 / 景别变化丰富 / 节奏有张弛 / 转场有设计
  • 末帧与首帧呼应 / AI 提示词具体 / 比例统一
  • 口播台词时间轴与视频时长匹配
  • 每镜时长 ∈ {5,6,7,8,9,10} 秒

10.3 素材(阶段4)

  • 照片按序号生成 / 人物是中国形象 / 场景与分镜一致 / 色调连贯
  • 视频生成成功 / 时长符合要求 / 运镜正确
  • 照片→视频映射完整
  • base64 未超限
  • 首段视频降级策略已准备
  • 人物一致性有 character-sheet 参考图锁定

10.4 修正(阶段4.5)

  • 修正后素材与分镜描述一致 / 与相邻素材色调连贯 / 原有映射未破坏

十一、版本迭代节奏

11.1 单案例迭代

版本 目标 说明
v1–v2 探索期 AI 自由探索,发现方向
v3–v4 收敛期 结合人工反馈逐步修正,收敛方向
v5–v6 定型期 格式标准化,内容基本确定
v7–v8 精修期 细节打磨,合规确认

11.2 跨案例标准化

  1. 先完成 1 个案例的完整流程,验证模板可行性
  2. 提取通用模板和 SOP
  3. 套用到其他案例,按品类差异做局部调整
  4. 最终形成标准化的智能体流程

十二、常见问题(Q&A)

Q1:binary_data_base64 超限怎么办? 现象:Image Decode Error: invalid binary data file size。 原因:API 对 base64 大小有限制,约 4–5MB(对应 ~3–4MB 原始图片)。 解决:压缩为 1280×720 JPEG quality 80 后再提交。本技能用 prepareImageUrl() 自动做。

Q2:method=3 首尾帧模式请求失败怎么办? 原因:两张图数据量翻倍,更容易超限;首尾帧对画面一致性要求更高。 解决:① 降级 method=2 重试;② 把 method=2 的 prompt 改成描述「从首帧到预期的过渡效果」; ③ 必须用首尾帧时,把两张图压到更小尺寸。场景跨度大时改用 method=2。

Q3:照片没有对应视频怎么办? 解决:跑素材映射预检;发现缺失时补视频段或调整分镜。

Q4:视频生成结果和照片视觉效果不一致怎么办? 解决:进入阶段 4.5,对照片重新压缩后再生成对应视频,并更新分镜文档中的 prompt。

Q5:人物在不同镜头换脸怎么办?(KB 未解,本技能新增解法) 先用 fmode-mv character-sheet 产出人物多视图, 再用 fmode-mv scene --character out/character/4-多视图.png 生成关键帧。 一致性从「靠提示词猜」变成「有像素级锚点」。


十三、变装视频工作流(另一套 SOP)

kb-raw/04-SOP工作流/…/SOP-变装视频生成工作流/ 是一套独立场景的流水线(电商服装), 流程为六步,与本 SOP 共用底层即梦通道:

步 产出 flow 文档
1 产品照片白底图 1-产品照片白底生成.md
2 衣架挂衣照片 2-衣架挂衣照片生成.md
3 模特上身效果 3-模特上身效果生成.md
4 3×3 细节网格 4-3x3细节网格生成.md
5 单张细节照片提取 5-单张细节照片提取.md
6 视频生成 6-视频生成.md

对应端点:getImgV4_goods(商品提取)、getClothesV2(虚拟换装)、getActorV2(动作模仿,¥0.4/秒)。 成本:换装跳舞视频 8–12 秒约 ¥15–24/条(人工 ¥10 + 照片 ¥2 + 视频 ¥3.2–5)。


十四、参考文件索引

本仓内

  • references/narrative-playbook.md —— 脚本层方法论(15 节拍 / 爆款类型 / 弧光 / 分镜)
  • templates/copywriting-prompt.md —— 文案仿写模板
  • templates/storyboard-prompt.md —— 分镜生成模板
  • templates/video-prompt.md —— 视频生成模板
  • references/jimeng-api.md —— 即梦通道全部端点与参数
  • references/production-evolution.md —— 版本 1~6 演进与踩坑清单

知识源(kb-raw,仓内保留)

  • kb-raw/04-SOP工作流/…/SOP-视频脚本生成工作流.md(含第九章合规边界)
  • kb-raw/04-SOP工作流/…/flow/(1 获取 / 2 仿写 / 3 分镜 / 4 素材 / 4 封面)
  • kb-raw/04-SOP工作流/…/SOP-变装视频生成工作流/