01-overview

总体设计

article-slide-video 是文章口播幻灯片视频工作流的调度 Skill。它本身不编辑文本、不请求 TTS、不渲染 HTML、不合成视频,也不生成字幕或封面;这些能力分别交给独立原子 Skill 完成。

它的职责是:

  • 创建统一输出目录。
  • 调用上游和下游 Skill。
  • 确保中间产物按契约落盘。
  • 校验 slide_id 在各阶段一致。
  • 只在失败阶段重跑,不无差别推倒重来。
  • 最终汇总交付物路径和 QA 状态。

设计目标

1. 把内容生产和工程交付拆开

文章转视频同时包含写作、视觉设计、语音合成、浏览器渲染、FFmpeg 合成和人工视觉检查。如果都放在一个 Skill 里,边界会迅速失控。

当前设计把流程拆为几个明确阶段:

  • voiceover-editor:只产出冻结口播稿。
  • slide-narration-planner:只做分页和讲述规划。
  • frontend-slides 或其他生成器:只产出视频可渲染的 HTML deck。
  • bytedance-tts:只产出音频和音频时间线。
  • slide-video-delivery:只负责最终视频、字幕、封面和 QA。

article-slide-video 只管编排和验收。

2. 用文件契约连接阶段

阶段之间不共享内存状态,也不依赖对话上下文里的临时描述,而是通过固定文件传递:

  • voiceover.md
  • narration-plan.json
  • deck.html
  • deck-manifest.json
  • voiceover.wav
  • tts-manifest.json
  • delivery-report.json

这样做的好处是中断后可恢复、失败后可定位、交付物可审计,也方便替换某个阶段的实现。

3. 用稳定 slide_id 防止错页

视频生成最容易出问题的地方是“第几页”和“哪段音频”的映射漂移。当前设计要求从 narration-plan.json 开始生成稳定 slide_id,例如 slide-01、slide-02。

后续阶段必须复用这些 ID:

  • HTML 页面使用同一组 slide_id。
  • deck-manifest.json 记录同一组 slide_id。
  • TTS manifest 记录同一组 slide_id。
  • QA 帧按 slide_id 回溯视觉状态。

调度器校验三份数据中的 slide_id 集合完全一致,避免按页面数量或顺序猜测映射。

4. 允许替换幻灯片生成器

frontend-slides 是默认 HTML 幻灯片生成器,但不是系统边界。只要其他生成器能输出同样的 deck-manifest.json,并在 HTML 中实现 window.__SLIDE_VIDEO__,就可以接入同一条视频交付链路。

因此视频交付阶段不得读取 .slide、.active、特定路由或生成器名称;它只能通过标准 manifest 和浏览器桥接操作页面。

Comments

Popular posts from this blog

How to turn off Sass warning prompts in Nuxt.js projects

Configuring SSH Access to a Docker Container via an Alternative Port

Quickly Set Up a Cloud Database Using MongoDB Atlas