Hyperframes 字幕叠加之道：drop / rail / embed 三层模型与“字幕是叠加层而非保留带”法则

Hyperframes 仓库中的 captions-overlay 技能文档定义了一套完整的字幕排版教义（overlay doctrine）：它解决的不是“字幕怎么加”，而是“字幕加在哪里、加多少、以什么姿态加”——即 drop / rail / embed 三层字幕模型（每句口播词只可能是三者之一，且 embed 是稀缺的高光而非默认），以及一条“叠加层法则”（字幕行是合成在成片之上的覆盖层，不是从布局里预留出来的保留区）。读完本篇，你将掌握在为 talking-head 或产品发布视频添加字幕时，如何决定一个短语该被丢弃、走逐字字幕轨，还是被提升为一次性的内嵌高潮词；以及为什么构图应该锚定在画布的真实垂直中心、内容可以延伸到画布底边，而不是为字幕“让位”。

该文档位于仓库的 .claude/skills/captions-overlay/SKILL.md，它明确声明自己是上游 embedded-captions 技能的补充层（supplement）：“Applies ON TOP of it; do not expect it folded into the upstream skill”——也就是说它不替代上游技能，而是在其上叠加两条规则。理解这套教义，需要先理解它所依附的两条流水线：

• embedded-captions 流水线（上游）：skills/embedded-captions/SKILL.md 描述了一个端到端本地工作流——hyperframes init → bash scripts/prepare.sh <project>（matte ∥ transcribe ∥ audio-envelope 并行，随后生成 safe-zones）→ 编写创作 JSON → scripts/preview-frames.cjs 视觉 QA → scripts/render-and-composite.sh 过门控输出 final.mp4。它的核心承诺是“原始视频原样交付”——字幕是唯一被添加的东西，matte（人物抠像，基于 hyperframes 的 remove-background，u2net_human_seg 模型）只让主体能够遮挡（occlude）内嵌字幕层，绝不重新调色或给镜头加特效。
• product-launch-video 流水线（约束来源）：captions-overlay 文档中“叠加层法则”逐字引用了该发布视频场景智能体的 constraint #13——字幕启用时，finalize 阶段会把一条小而极简的逐词字幕行作为覆盖层合成在整个影片之上（单行文字，底部居中，大约占画布高度的 5–8%）。发布视频的字幕构建逻辑见 skills/product-launch-video/scripts/captions.mjs（含字幕分组启发式：帧边界、句末标点、静默间隙、密度感知词数上限），其测试为 skills/product-launch-video/scripts/captions.test.mjs。

两条流水线共享同一个底层事实：影片本身不因为字幕的存在而被改动——字幕是“加上去的层”，不是“留出来的区”。captions-overlay 教义就是把这个事实上升为两条可执行的规则。

字幕模型：每个口播词都是 drop、rail 或 embed 三者之一

captions-overlay 文档给出的模型与上游 embedded-captions 的 § Caption model 完全一致（文档注明 “verbatim from embedded-captions”），原文对照见 skills/embedded-captions/SKILL.md：

层级	是什么	如何呈现
drop	填充词——um/uh、口吃、自我纠正	不显示
rail	默认档——普通口播内容（逐字）	干净的 lower-third 字幕，位于画面前方、可读性好。重音词（punch word）可以获得行内 emphasis 高亮（强调色 / 当前词弹跳）——但它仍留在 rail 上
embed	被提升的高光——标题级重拍	一个大词被合成到主体身后（matte 遮挡），有专门设计的入场与退场

这个模型的要点可以概括为三句话：

1. rail 承载绝大部分文字。逐字口播内容默认都走 rail——一条位于画面前方、可读性优先的下三分之一字幕带。rail 的完整规格（它是一条“薄”规则集）单独成文于 skills/embedded-captions/references/rail.md。
2. embed 是稀缺的、被“挣得”的高光。稀缺性是按拍/按块（per beat/block）计的，不是按整条片子计的：每个句子/beat 至多 1 个 embed，绝不允许两个相邻或同屏可见，两个 embed 窗口之间要留有至少一个 beat 的间隔（上游编译器在间隔小于 0.6s 时会告警）。短片子通常只有 1 个（或 1–2 个）embed；长讲解片大约每节一个。文档点名了最常见的错误：“Embedding every word is the common mistake”——把整段转写都嵌进画面，是默认的错误方向。
3. climax ≠ 全片唯一爆点。在多个高光词中，作者标注的最大一个是 APEX（独享完整 lockup 内嵌 + 宽度适配抬升），其余较小的是 MINOR peaks（以超大强调行的形式挂在栏内，前景、弱动效）。climax 的含义是“每个 beat 的峰值”，而不是“整条片子唯一的 payoff”。

Standard 与 Cinematic：同一模型、两种形态

captions-overlay 文档特别区分了该模型在两种模式下的形态（与 skills/embedded-captions/SKILL.md 的引擎划分一致）：

• Standard（默认）：rail = 逐字 lower-third 字幕；embed = 合成在主体身后的收尾高潮。绝大多数 explainer / voiceover 内容走这一档。
• Cinematic：丢弃 rail，一切字幕都以 embed 形态呈现（英雄字体、累积排版、遮挡即特效）。文档划了一条明确的适用边界——只用于纯电影感诉求，绝不用在必须“读得出词”的 explainer / voiceover 场景。上游 SKILL.md 的表述同样明确：column-flow 类身份（丢 rail、全 embed）“recommend them only for mood-over-verbatim asks, never for explainer / voiceover where the words must read”。

两条承重规则（原文引用的上游“不可协商”项）

captions-overlay 从 embedded-captions 的 non-negotiables 中逐字引用了其中两条，它们是这套模型的承重墙（对应上游 skills/embedded-captions/SKILL.md “Non-negotiables” 一节）：

• Rail-first（talking-head / explainer 场景）：不要嵌入整段转写——大部分文字属于 rail，只有峰值词才 embed。“Embedding everything is the default mistake.”
• Embed 稀缺且拉开间隔：每句/每 beat 至多 1 个 embed，绝不允许两个相邻或同屏可见，间隔至少一个 beat，至多一个 apex。

这两条规则与模型的表格是自洽的：既然 rail 在前、embed 在后的分层关系成立，那么“全部 embed”就必然破坏节奏——因为稀缺性正是 embed 之所以是“事件”的原因（上游原话：“which is exactly what keeps the apex an event”）。

叠加层法则：字幕不是预留带，内容锚定真实垂直中心

这是 captions-overlay 文档的第二部分，也是它相对于上游最核心的增量。它针对的是生成式发布视频（generated launch composition）的字幕排版问题，逐字引用了 product-launch-video 场景智能体的 constraint #13：当字幕启用时，finalize 会在整部影片之上合成一条“小而极简的逐词字幕行”作为覆盖层——单行文字、底部居中、大约占画布高度的 5–8%。

由此推出四条执行规则：

1. 构图锚定真实垂直中心 y = H / 2（横屏 540，竖屏 960）。不要把内容上移去“给字幕腾地方”；文档直言：“a composition centered at 0.42 × H with a dead lower band is the bug, not the fix”——把构图放在 0.42×H 并留下一条死掉的底部带，是 bug 本身，而不是解决方案。
2. 内容可以延伸到画布底边。全出血（full-bleed）的主体、rail、背景都欢迎——因为字幕是叠在上面的覆盖层，不需要在布局中“开洞”。
3. 唯一的一条柔性礼貌规则：避免把关键的小号可读文字（一行 URL、法务行、副字幕）恰好停在字幕行所在的底部居中约 80px 区间内——覆盖层会与之打架。但大号图像 / 卡片 / 环境内容位于字幕之下完全没问题：字幕皮肤（caption skin）的设计目标就是能在内容之上保持可读。
4. 不存在机器 keep-out 门控。文档明确写道：“There is no machine keep-out gate (the old captions.mjs keepout check is retired). Finalize snapshot QA judges caption-over-content legibility visually.”——旧的 captions.mjs keepout 检查已经退役，改为在 finalize 快照上视觉判断“字幕压在内容上”的可读性。

字幕禁用时呢？ 自由度完全相同——叠加层只是不存在而已。这一句很重要：它说明“内容延伸到画布底边”的自由度不依赖字幕开关状态，排版规则因此可以在字幕开/关两种情况下保持稳定。

与旧版 keep-out 设计的对照

从仓库其他位置可以拼出这套规则演化的另一半证据链，帮助理解“为什么退役”：

• skills/product-launch-video/references/visual-design.md 仍保留着旧式“Caption-band keep-out (plan side)”一节的痕迹：底部约 17% 画布为字幕胶囊预留，每帧内容需规划进顶部约 83%。
• skills/product-launch-video/scripts/captions.mjs 头部注释中仍可见 keep-out band 的语义词汇：品牌 token 注入时包含 --cap-band-top / --cap-band-height (the keep-out band)。

从源码结构看，当前仓库处于新旧两套排版哲学的并存状态：captions-overlay 教义（.claude 技能层）声明 keep-out 检查已退役、可读性改由视觉 QA 判定，而 product-launch-video 技能内的参考文档与脚本注释还保留着 band 时代的词汇与 83% 规划线。这恰好印证了教义文档的定位——它是叠在上游之上的增量层：上游的旧约束不会被自动改写（“do not expect it folded into the upstream skill”），新法则由 captions-overlay 在决策时刻接管。

为什么这两条规则其实是同一条教义

captions-overlay 文档的最后一节把两条规则收拢为一个论断：模型说 rail 骑在前面、embed 是合成在主体身后的稀有词——两者都是加在“原样交付的镜头”上的层；叠加层法则说字幕行是合成在整部影片之上的层，不是从布局里挖出的带子。所以在 embedded-captions 与 launch-video 两条管线里，字幕都是你加上去的层，不是你预留出来的区：

• 保留完整画布；锚定真实中心；让内容跑向边缘；
• 让 rail（或那条小小的覆盖层字幕行）承载逐字文字；
• 只在真正的峰值把某个词提升为 embed——稀缺、拉开间隔、绝不同屏两个；
• 什么都不预留；“字幕压内容”的可读性用眼睛判，不靠 keep-out 门控。

实操要点速查

把教义落回日常操作，可以浓缩成一份决策清单（均出自 .claude/skills/captions-overlay/SKILL.md 及其引用的上游文件）：

• 判断一个短语的归宿：填充词/口吃/自我纠正 → drop；普通逐字内容 → rail（重音词可加行内 emphasis，但仍留在 rail）；标题级重拍 → embed（且满足“每 beat ≤1、不邻接、间隔 ≥1 beat、至多一个 apex”）。
• 决定模式：explainer / voiceover / 必须读得出词 → Standard（rail + 峰值 embed）；纯电影感诉求 → Cinematic（全 embed、丢 rail）。
• 布局构图：主体与构图锚定 y = H/2（横屏 540 / 竖屏 960），内容可全出血到底边；唯一要避开的是底部居中约 80px 区间内的关键小号文字（URL 行、法务行、副字幕）。
• 验证方式：不再有机器 keep-out 门控；在 finalize 快照上做视觉可读性判断（embedded-captions 侧对应 scripts/preview-frames.cjs 的预览帧 + references/reference-bar.md 的正面检查清单；发布视频侧由 finalize snapshot QA 承担）。
• 相关文档入口：上游完整规则见 skills/embedded-captions/SKILL.md（决策门、5 步管线、Non-negotiables 全文），rail 规格见 skills/embedded-captions/references/rail.md，embed 排版权威手册见 skills/embedded-captions/references/composition-craft.md，35 个视觉身份的单一事实源见 skills/embedded-captions/CATALOG.md，发布视频字幕构建见 skills/product-launch-video/scripts/captions.mjs。