播客式视频生成规划方案+生产现况-v02

本文是《播客式分镜周报视频生成规划方案｜2026年02月22日》的 v02 版本。原文解决的是方向判断：长音频如何视频化、SeedDance 是否应该全程使用、播客演播室模板是否值得建立。经过后续几轮实际生产测试后，当前方案已经从“规划”进入“可运行产品线”的阶段，因此需要把目录结构、通用组件、镜头池逻辑、标题卡策略、生产现况和下一步迁移计划统一记录下来。

v02 的核心变化是：不再把“播客式视频”理解成某一条周报的特殊实验，而是拆成 `podcast-core / podcast-article / podcast-weekly` 三层产品结构。周报、普通文章、史话文章、年度回顾文章都可以共享同一套底层播客视频能力，但在输入、增强规则和输出目录上保持清晰边界。

一、从 90 秒 MVP 到完整播客视频管线

原规划文章提出的判断依然成立：长音频视频化的核心矛盾，是音频很长，而 AI 视频模型更适合生成 5 秒到 10 秒级片段。因此，当前生产方案没有走“每句话都生成 AI 视频”的路线，而是采用混合结构：

播客演播室镜头作为主视觉底座；
说话人时间轴驱动 A/B 角色镜头切换；
章节标题卡和文章插图作为信息层；
opening / body / outro 分段合成；
最终统一重编码，保证帧率、分辨率、音频规格一致。

这个路线已经完成了从 MVP 到完整成片的验证。早期 Week22/Week23 的测试更偏“实验脚本”，后续 Week26 和单篇文章测试则开始进入产品化路径。当前已经能生成十几分钟级别的完整 1920×1080、24fps、带字幕、带音频的播客式视频。

二、当前三层产品结构

三层产品结构：podcast-core、podcast-article 与 podcast-weekly

现在推荐把 storyboardworld.com 的播客式视频拆成三层：

1. `podcast-core`：共享底层能力

`podcast-core` 不直接代表某一种内容产品，而是共享能力层。它负责沉淀可以被周报和普通文章共同使用的底层组件，例如：

通用播客 opening 生成；
通用 podcast outro；
opening + body + outro 的最终合成；
基于说话人时间轴的正文镜头池调度；
章节标题卡 overlay；
通用视觉 preset；
通用镜头池配置。

当前核心配置包括：

configs/podcast-core/overlay_preset_v06.json
configs/podcast-core/shot_pool.json
scripts/podcast-core/make_podcast_opening.py
scripts/podcast-core/compose_podcast_body_shotpool_fontplus.py
scripts/podcast-core/compose_podcast_full_opening_body_outro.py
scripts/podcast-core/apply_podcast_heading_overlays.py

其中 `overlay_preset_v06.json` 已经锁定一条重要原则：章节卡是 overlay，不是插入片段。也就是说，标题卡只叠在正文镜头上，不切断播客音频，不改变整片时长。

2. `podcast-article`：任意单篇文章播客视频

`podcast-article` 是面向“任意文章”的入口。它不局限于周报，也可以处理史话文章、年度回顾、普通技术方案、项目复盘等内容。

当前结构为：

input/podcast-article/{episode_slug}/
content/podcast-article/{episode_slug}-podcast-api/
outputs/podcast-article/{episode_slug}/
scripts/podcast-article/run_podcast_article.py
configs/podcast-article/default.json

它的职责是把一篇文章标准化成播客视频输入：抓取 WordPress 正文、保存 Markdown、提取正文图片、准备 episode manifest、调用豆包播客音频接口、调用 `podcast-core` 完成 body 和 final 合成。

最近用原规划文章完成了一轮完整测试：文章没有特色图和正文图，因此系统自动生成了无标题的 fallback 背景用于 opening；正文根据文章 H2 生成了 12 个半透明 bokeh 章节卡；最终成片保持原始播客时间轴，不切音频、不插入额外时长。

3. `podcast-weekly`：周报增强播客产品线

`podcast-weekly` 是周报专用入口。它使用与 `podcast-article` 相同的底层播客能力，但保留周报特有增强：

周报 opening / outro 的周次表达；
周报正文结构映射；
周报章节卡；
周报图片回顾或日报回顾片尾；
后续可能加入“本周高光新闻 B-roll”。

当前 Week26 已经使用新目录结构生成过完整成片，输出进入：

outputs/podcast-weekly/{week_slug}/

这意味着 weekly 不再是散落脚本里的单次实验，而是明确成为一条独立产品线。

三、镜头池逻辑：从 weekly 命名到 podcast 通用命名

原始规划文章中，播客演播室镜头的价值在于复用。实际生产后，这个判断进一步被验证：长音频视频化最稳定、最省成本的方式，就是建立固定的“播客演播室镜头池”。

早期镜头池路径带有 `weekly-podcast-shot-pool` 命名，容易让人误解为只能服务周报。现在已经通用化为：

sites/_shared/seedance-asset-library/shot-pools/storyboard_studio_classic_v01/podcast-shot-pool

当前通用镜头池按角色和镜头类型组织：

podcast-shot-pool/
  beta/
    beta_full-shot_v*.mp4
    beta_close-up_v*.mp4
    beta_reverse-shot_raymo-listening_v*.mp4
    beta_extreme-close-up_*_v*.mp4
  raymo/
    raymo_full-shot_v*.mp4
    raymo_close-up_v*.mp4
    raymo_reverse-shot_beta-listening_v*.mp4
    raymo_extreme-close-up_*_v*.mp4
  establishing-shot/
  archive-source/

这里有几个关键规则：

`beta` 和 `raymo` 是播客画面角色，而不是某一期内容的临时变量；
`full-shot`、`close-up`、`reverse-shot`、`extreme-close-up` 是可调度的逻辑镜头槽位；
`v01 / v02 / v12` 不是优先级，而是同一槽位的等价候选；
调度时会随机等权选择，并避免相邻镜头立即重复；
`reverse-shot` 表示当前说话人仍在说话，但画面切到对方聆听反应；
`extreme-close-up` 用于长话轮里的局部细节插入，例如手写屏、讲稿、桌面动作。

这套逻辑解决了长音频中最容易出现的“画面单调”和“角色错位”问题。它不是简单循环几个视频，而是由 speaker timeline 决定镜头归属，再由 shot type 规则决定视觉节奏。

四、正文结构：音频时间轴驱动，而不是自然段驱动

当前正文视频不按 Markdown 自然段直接切，而是优先使用播客音频接口返回的 speaker timeline。每个发言片段包含：

start time；
end time；
speaker；
text；
speaker name。

合成脚本会把连续的同一说话人片段合并成 visual run，并按时长决定镜头策略：

很短的发言：使用 full-shot 或 close-up，避免频繁碎切；
中短发言：优先 close-up；
长发言：close-up 开场，再切 full-shot、reverse-shot、extreme-close-up；
尾部过短的片段会吸收到前一个镜头，避免低于最小时长的闪切。

这种逻辑比“每段文字对应一个画面”更适合播客视频。因为播客的连续性来自声音，画面负责提供节奏、角色关系和信息辅助，而不是逐句还原文字。

五、章节标题卡：从插入式卡片改为 overlay

Week26 和单篇文章测试后，章节卡的规则已经明确：标题卡不能作为独立片段插入正文，否则会改变时间轴，也容易切断说话节奏。

当前 v06 规则是：

每个 H2 生成一个 5 秒章节卡；
章节卡叠在正文镜头上；
不切音频；
不改变总时长；
使用半透明 floating bokeh card；
只保留 soft halo，不使用右下角硬边阴影；
下划线位于标题块下方，避免压字。

这一点对 `podcast-article` 特别重要。因为普通文章的 H2 天然就是章节结构，系统可以直接根据 Markdown H2 生成章节 overlay。最近的测试文章识别出 12 个 H2，并成功生成 12 个 overlay 章节卡，验证了这个逻辑可以从 weekly 移植到 article。

六、特色图、正文图和 fallback 背景的边界

当前生产中已经踩过一个典型问题：如果文章没有特色图，系统会生成 fallback opening 背景；但 fallback 背景不应该自带标题，否则 opening 组件再叠一次标题，就会出现“双标题”。

现在的边界应当是：

featured image：用于 opening 背景；
fallback background：只提供视觉氛围，不写标题；
opening overlay：唯一负责标题、日期、副标题；
body images：只使用 Markdown/WP 正文里真实出现的图片；
featured image 不重复作为正文图插入。

这条规则能避免两个问题：一是 opening 标题重复；二是没有正文图时强行把特色图塞进 body，造成内容误导。

如果文章没有特色图，也没有正文图，系统可以使用 podcast-core 的 bokeh 背景完成 opening，但正文不应伪造图片素材。后续如果要增强普通文章的正文视觉，应通过“根据章节生成插图”或“人工提供插图”进入，而不是复用 opening 封面图冒充正文插图。

七、当前已验证的生产现况

截至 v02，已经验证过的能力包括：

`podcast-weekly` 新目录结构可以生成完整周报播客视频；
`podcast-article` 新入口可以从 WordPress URL 抓取文章并生成完整播客视频；
豆包播客音频接口可以生成双人对谈音频和 speaker timeline；
`podcast-core` 可以提供通用 body、opening、outro、final composition；
通用 `podcast-shot-pool` 已替代 weekly 命名的镜头池路径；
章节标题卡已经从 weekly 移植到 article，并验证为非插入式 overlay；
无特色图文章可以通过 fallback 背景生成 opening，且不再重复标题；
最终输出可以稳定保持 1920×1080、24fps、H.264 + AAC。

最近一次 `podcast-article` 测试输出约 1085 秒，包含 13 秒 opening、约 1063 秒正文和约 9 秒 outro。正文由 76 轮对谈拆成 308 个镜头片段，说明这套镜头池调度已经可以承载十几分钟级别的内容。

八、仍在 legacy 状态的部分

当前仍保留 `podcast-dialogue`，但它已经不应作为新用户入口。它的定位是 legacy/reference，原因是历史年度回顾、史话文章和若干已完成成片仍引用旧路径。

暂时不能直接删除 `podcast-dialogue`，因为里面仍有：

旧年度回顾 runner；
历史 input；
历史 output；
旧 podcast opening / outro；
若干文档和验证产物；
某些 legacy config 仍指向旧 `weekly-podcast-shot-pool`。

正确做法不是直接删除，而是分阶段迁移：

把仍有价值的脚本能力迁入 `podcast-core`；
把年度回顾入口改成 `podcast-article` preset；
把历史产物归档到 archive 或迁入新目录；
grep 确认无活动引用；
最后再删除或冻结 `podcast-dialogue`。

九、v02 推荐的标准生产流程

新的标准流程可以概括为：

文章 / 周报 Markdown / WordPress URL
  ↓
标准化输入：article.md + episode.json + body images
  ↓
豆包播客音频：mp3 + speaker-timeline.json
  ↓
正文 body：speaker timeline → podcast-shot-pool 镜头调度 → 字幕烧录
  ↓
opening：featured image / fallback background + 标题 overlay
  ↓
outro：通用 podcast outro 或周报专用 outro
  ↓
final：opening + body + outro 统一重编码
  ↓
增强层：H2 heading overlay / article image overlay / weekly recap
  ↓
最终 mp4 + plan + validation

在这个流程里，`article.md` 是语义输入，`speaker-timeline.json` 是时间轴输入，`podcast-shot-pool` 是视觉底座，`overlay_preset_v06.json` 是视觉增强约束。

这比原规划文章中的“先做 90 秒 MVP”更进一步：MVP 已经证明方向可行，现在进入的是可维护、可复用、可扩展的生产管线阶段。

十、下一阶段改进建议

1. 固化 `podcast-article` 默认 v03 逻辑

后续 `run_podcast_article.py –generate` 应默认输出包含：

无重复标题 opening；
H2 heading overlay；
正文真实图片 overlay；
统一 validation；
plan 文件记录每个增强层时间点。

2. 完成 `podcast-dialogue` legacy 迁移

`podcast-dialogue` 不应继续承担新入口。需要把年度回顾和史话文章统一迁到 `podcast-article`，把共用组件沉淀到 `podcast-core`。

3. 强化镜头池资产管理

`podcast-shot-pool` 后续应继续扩展：

增加 establishing shot；
增加更多 beta / raymo 的 close-up 变体；
增加桌面、屏幕、手写屏、讲稿等 detail shots；
为每个镜头补 metadata，包括时长、角色、构图、可用场景和禁用原因。

4. 增加章节插图生成策略

对于没有正文图的文章，可以选择按 H2 生成插图，但要作为“生成插图”明确进入素材层，而不是复用特色图。插图可以用于正文 overlay、Ken Burns 动画或章节解释卡。

5. 建立发布前验证清单

每次成片前应检查：

opening 是否重复标题；
特色图是否被错误重复到 body；
章节卡是否改变总时长；
是否有音频；
字幕是否烧录；
fps 是否统一为 24；
输出目录是否属于正确产品线；
是否还有 legacy `podcast-dialogue` 路径泄漏。

十一、阶段性结论

原规划文章的方向判断是正确的：播客式视频不应全程依赖 SeedDance，也不应逐句影视化。真正可持续的路线，是播客演播室镜头池 + 音频时间轴 + 章节信息层 + 少量 AI 高光素材。

v02 的新增结论是：这条路线已经不只是方案，而是形成了初步产品结构。

`podcast-core` 负责共享能力；
`podcast-article` 负责任意单篇文章；
`podcast-weekly` 负责周报增强；
`podcast-shot-pool` 成为通用演播室镜头池；
`podcast-dialogue` 退为 legacy/reference。

下一步重点不是继续增加一次性脚本，而是把已经验证通过的逻辑正式固化到默认 runner，并清理旧路径，使播客式视频生成成为 storyboardworld.com 可长期复用的内容生产能力。