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.mdnarration-plan.jsondeck.htmldeck-manifest.jsonvoiceover.wavtts-manifest.jsondelivery-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
Post a Comment