0.1 一条片子的分解

0.1 一条片子的分解

本节摘要：本节做全书的第一次拆解。拿来一条 60 秒的原创知识短片《六十秒看懂：彩虹为什么是弧形》，逐秒还原它是怎么被生产出来的，把「一条片子」拆成脚本、分镜、素材、生成、剪辑、音轨、字幕七段加工，并标出每段的输入、输出与责任边界。随后对照「单模型直出」与「流水线组装」两条路线：同样一条 60 秒短片，直出路线改一个镜头要整条重生成，流水线路线只重跑受影响的镜头——质量差距是表象，可控性差距才是本质。最后给出经 GitHub 接口核实的生态热度图景（事实基准日 2026-10-16，stars 为社区口径、增速需甄别），并说明怎么读这些数字才不会被带偏。

学习目标

• 把一条 60 秒短片逐段归位到七段加工，说出每段的输入与输出。
• 解释单模型直出的三处天花板：时长、镜头语言、一致性。
• 用「改第 3 秒」的思想实验判断一条生产路线的可控性。
• 复述本书点名的开源项目清单及其定位，并说明 stars 口径的读法。

一、拿来拆的片子：60 秒知识短片

示例是一条完全原创的知识短片《六十秒看懂：彩虹为什么是弧形》，总长 60 秒、竖屏 1080 by 1920、30 帧。它的镜头表如下（时间码为示意，讲解逻辑自洽即可）：

这张镜头表此刻还是「人读的表」，流水线里它会变成「机器读的表」。提前看一眼它将来的样子（schema 在第 1.2 节正式定义，此处只求混个眼熟）：

# storyboard_preview.json —— 彩虹片镜头表前两行的机器形态（示意）
{
  "shots": [
    {"shot_id": 101, "duration": 5.0, "camera": "固定",
     "visual": "雨后天空转晴的空镜，片名字卡淡入",
     "line": "雨停了，阳光回来，天边挂出一道弧", "transition": "切"},
    {"shot_id": 102, "duration": 10.0, "camera": "推",
     "visual": "一束阳光射向一颗水滴的动画",
     "line": "你看到的弧，起点是一亿五千万公里外的阳光"}
  ]
}
​

现在不必逐字段抠细节，只记一件事：镜头表里的每一行，将来都是一个带镜头号的 JSON 对象——这个号码是它此后在素材、生成、剪辑三段里被指名道姓的唯一凭据，「只重跑第 3 个镜头」说的就是它。

这条片子没有明星、没有实拍团队、没有版权素材，全部内容要么来自生成模型，要么来自程序绘制的图形——这正是它能被一条流水线完整生产的原因。下面把它拆回七段。

二、七段加工逐段拆解

 脚本 ──▶ 分镜 ──▶ 素材 ──▶ 生成 ──▶ 剪辑 ──▶ 音轨 ──▶ 字幕 ──▶ 导出
  │        │        │        │        │        │        │        │
 剧本JSON  分镜JSON  素材清单   片段mp4   时间线JSON 音频轨    SRT      成片
​

第一段，脚本。输入是一句想法（「讲清楚彩虹为什么是弧形，60 秒，科普口吻」），输出是剧本 JSON：三场戏、每场的动作与台词。责任方是大模型加结构化输出约束，第 2.1 节展开。

第二段，分镜。输入是剧本 JSON，输出是分镜 JSON：把每场戏切成带镜头号、时长、画面描述、台词、运镜、转场的镜头列表——上表六行就是分镜的雏形。这一段是全书最重要的人审节点，第 2.3 节展开。

第三段，素材。输入是分镜 JSON，输出是素材包与生成任务清单：哪些镜头走文生图转图生视频、哪些走纯文生视频、哪些用程序图形直接绘制（本片的三段动画其实最适合矢量图形或 HTML 渲染，第 5.3 节会回到这一点）。第 3、4 章展开。

第四段，生成。输入是生成任务清单，输出是「每镜一条片段 mp4」。注意产物形态：不是一条成片，而是一堆几秒钟的镜头片段，带着镜头号落盘。第 3 章展开。

第五段，剪辑。输入是片段集合与分镜 JSON，输出是时间线 JSON 与拼接后的视频轨。第 5 章展开。

第六段，音轨。输入是台词文本，输出是配音、音效与混音。原理见 ai-engineering-from-scratch 第 7 章《语音与音频》，工程实做在后半本第 6 章。

第七段，字幕。输入是音轨与台词，输出是对齐到帧的字幕文件。后半本第 7 章展开。

七段连起来有一个共同点：段与段之间传递的都是文件——JSON 清单、图片、片段、音轨、字幕——而不是内存里的隐含状态。这个特点让任何一段都可以单独重跑，是第 1 章的总论主题。

把七段的接口收进一张总表，它可以当作全书的地图用——后面每章展开一段时，回来对一眼输入输出即可：

读这张表还有一个附加收获：它就是 1.3 节目录模板的来历——build 下的七个子目录与七个加工段一一对应，目录结构即流水线形状。

三、单模型直出与流水线组装的对照

「一句话直出成片」的路线在 2026 年已经相当能打：给一句提示词，模型直接吐出几秒到几十秒的视频。它的天花板也稳定：

一个思想实验把差别钉死：客户看完样片说「00:30 那句旁白后面的动画，把 42 度改成带刻度的扇形」。直出路线的答案是把提示词改一改、整条重生成，然后祈祷其他五段没有变样；流水线路线的答案是改分镜 JSON 里那一个镜头的画面描述，重跑一个镜头的生成与剪辑，其余五个镜头原样复用。生产的竞争力不在第一次出片多快，而在第十次修改还剩多少可控性。

还要说清反面：流水线不是免费的。它要求你维护契约、目录与重跑逻辑，前期工程量明显更大。日更一条的个人创作者用直出加手工微调可能就够了；要做栏目化、多客户、批量交付，「第十次修改」迟早来，流水线的投入从那时开始回本。

四、生态热度与甄别方法

以下项目在事实基准日 2026-10-16 经 GitHub 接口逐一核实过存在性与官方描述，stars 为社区口径，只表达热度量级，增速需甄别，不构成选型结论：

怎么读这张表：第一，2026 年 GitHub star 通胀是公认现象，玩梗仓库也能冲到十万级，六位数不等于六位数质量，看增速曲线与 issue 活跃度比看绝对值可靠；第二，项目定位以官方仓库描述为准，二手转述常把「录制工具」说成「生成模型」；第三，这些项目覆盖了流水线的不同段——OpenMontage 与 huobao-drama 是整线整合，hyperframes 是渲染段的新路线，video-use 与 filmcraft 是剪辑段，LTX-2 是生成段的本地选项——本书各章会按段取用它们的思路，而不绑定任何一家。

五、常见问题与排查

第一次用七段视角看片子，疑问常集中在四处。

问：七段必须严格串行执行吗？ 段间依赖决定大顺序：脚本在分镜前、分镜在生成前、剪辑在音轨字幕前，这条主链不能乱。但段内任务可以并行——最典型的是生成段，一批镜头任务同时挂起（第 3.1 节的并发控制）；素材段的找图与选曲也可以与脚本段并行起步，只要在生成段开工前把任务清单填齐。

问：口播类、实拍类内容也适用这七段吗？ 适用，只是个别段会「退化」。实拍内容的生成段换成拍摄素材入库，素材段多一项整理母版的工作；纯口播内容的分镜可能只有两三条镜头。七段是加工抽象，不绑定生成模型——只要产物仍是文件加清单，目录、契约、重跑逻辑全部照用。

问：每段产物为什么必须落盘成文件？一个长脚本从头跑到尾不行吗？ 进程内存里的状态无法单独重跑、无法人审、无法交接，进程一崩全部蒸发。文件是断点、是证据、也是协作界面——第 1 章的执行器与完成标记全部建立在「产物即文件」之上。

问：直出路线以后会不会支持只改一个镜头？ 部分产品确实在朝局部编辑演进，但截至事实基准日，主流直出路线的修改单位仍是整条重生成；即便局部能力普及，「分镜级契约」的可控性仍高于「提示词级祈祷」——可控性来自结构，不来自某一家产品的功能承诺。

问：想拿自己的片子练手拆解，从哪下手？ 找一条自己拍过或剪过的 60 秒内容，先只做前四段的归位——每个镜头标出它的画面描述与台词，再对照本节镜头表的格式补全时间码；后三段等读完第 5 到 7 章再回来补。拆三条之后，七段会从概念变成手感。

本节要点回顾

• 一条片子可拆成七段加工：脚本、分镜、素材、生成、剪辑、音轨、字幕，段间以文件为契约。
• 直出与流水线的本质差异是修改成本：前者整条重生成，后者只重跑受影响段。
• 流水线的代价是前期工程投入，栏目化与批量交付场景才划算。
• stars 是社区口径的热度量级，增速需甄别，选型看定位匹配与活跃度。

拆解是纸面功夫，下一节把它变成能跑的东西——三十余行代码，两段文字进，五秒成片出。