用 AI 做视频时，最容易失控的地方往往不在剪辑本身，而在项目一开始就混用了渲染框架、画幅、内容类型和素材标准。
一条稳定的视频生产流程，应当先完成路由，再进入制作：
框架 → 画幅 → 内容类型 → 项目契约 → 共享生产契约 → 预览 → 渲染 → QA这正是 video-production 技能解决的问题。
一、先确定生产框架
所有新项目和重大修改，统一使用 HyperFrames。
HyperFrames 的 HTML composition 和 source builder 是生产源文件，负责：
- 画面布局
- 素材时序
- 字幕
- 动效
- 音频
生成的 index.html 只是产物，不能作为主要编辑对象。修改应当回到源 builder，再重新生成。
Remotion 只保留为历史兼容材料：
- 不用 Remotion 开始新项目
- 不向旧 Remotion 项目继续添加新场景
- 旧项目需要重大修改时，先迁移到 HyperFrames
历史上的 Pillow、Python 或 FFmpeg 素材可以继续保留，但它们不再承担新项目的生产框架角色。
完成框架选择后，只读取 HyperFrames 的入口技能。核心、渲染、字幕、音频、关键帧和动画等子技能，根据具体路线按需加载。
二、画幅决定构图
画幅应当根据交付规格选择，不能只根据发布平台决定。
竖屏
适用于 9:16 交付，默认尺寸为 1080×1920。
重点关注：
- 竖屏安全区
- 更大的字幕
- 单一视觉重点
- 适合手机观看的主体比例
横屏
适用于 16:9 交付，默认尺寸为 1920×1080。
重点关注：
- 更宽的证据布局
- 页面、截图和视频的横向呈现
- 横屏字幕避让
- 更大的信息组织空间
画幅会改变构图和 QA 标准，但不会改变内容的真实性要求。
三、内容类型决定制作路线
比如「Bilibili」「TikTok」只是发行平台，不能直接决定制作方式。应当先判断视频属于哪一种编辑类型。
| 类型 | 适合内容 | 对应路线 | | --- | --- | --- | | Explainer 解释型 | 概念、机制、技术或文化对象的讲解 | HyperFrames 解释型流程；任意文本可使用 faceless-explainer，较长的自定义构图可使用 general-video | | Investigation 调查型 | 通过数据、实验、原始资料或冻结证据回答问题 | HyperFrames 调查路线 | | Documentary 纪录型 | 实拍、采访、现场素材或 Bilibili 长叙事 | 先进行纪录片研究和编辑规划，再结合 HyperFrames | | Motion 动效型 | 由动画承担主要信息，旁白很少或没有 | motion-graphics | | Promo 宣传型 | 产品、项目、网站或功能展示 | general-video 或 website-to-hyperframes |
general-video 是没有更合适专业路线时的 HyperFrames 后备方案，不能替代前面的类型判断。
四、编辑前先读取项目契约
确定框架、画幅和类型后，才进入具体项目。
编辑前需要读取：
- 项目级
AGENTS.md - 项目
README.md - 内容 source of truth
- 素材来源记录
- 最近一次 QA 结果
同时需要先读取共享生产契约。它覆盖：
- 研究
- 文案
- 音频
- 字幕
- 素材
- 动效
- 渲染
- QA
- 工作区边界
类型路线可以增加更严格的要求，但不能削弱共享生产契约。每次只加载当前路线需要的技能，不把所有视频技能一次性混在一起。
五、五条贯穿全流程的生产原则
1. TTS 节奏是生产门槛
旁白需要在 1 倍速下实际试听，并测量句子时长。
如果声音拖沓，处理顺序应当是：
- 先缩短句子
- 再小幅调整 TTS 语速
- 重新生成旁白
- 重新生成字幕和场景时序
- 重新渲染并完成 QA
不能在保留慢速音轨的情况下单独重排字幕，也不能依靠音乐掩盖过长停顿。
2. 默认一场景一个视觉核心
每个场景应当只有一个清晰、居中、占主导地位的视觉核心。
只有在叙事明确需要比较、对照或映射多个对象时，才使用：
- 分栏布局
- 多面板布局
- 并列素材
3. 每个场景都要能说清视觉核心
每个场景都应当有一句话说明：
这一幕最重要的画面是什么？
如果答案不清楚，就应当删除：
- 次级字幕
- 解释性段落
- 装饰标签
- 重复说明
- 多余的角标
解释交给旁白，画面负责让观众看到正在被解释的对象。
4. 解释对象时，直接标记对象
当画面中有多个可能目标时，应当使用一个明确的视觉锚点：
- 箭头
- 括号
- 轮廓
- 遮罩
- 高亮
旁白应当同步谈论这个被标记的目标，避免让观众自行猜测重点。
5. 把画面当成视频，而不是幻灯片
画面中不应长期保留类似演示文稿的 UI 装饰，例如：
- 左上角的章节编号
- 右上角的文件名
- 持续存在的进度条
- 与当前叙事无关的角落信息
素材来源和证据链应当保存在项目记录中。只有在确实有助于验证时，才在画面中加入简短来源说明。
六、HyperFrames 的视觉语法
让真实素材占据画面
真实视频默认全屏呈现。
历史页面、截图和解释性图形可以作为信息层使用，但不要把当前证据长期缩成漂浮卡片，也不要把整个视频做成持续存在的 PPT 框架。
每个镜头都要根据当前旁白和字幕进行语义检查。如果画面与句子不一致，应当更换镜头，装饰性文字无法弥补语义错误。
素材要有代表性
优先使用真实、标志性和易识别的素材。
不要为了填满时长重复使用同一张图片或同一段视频。每次重复都应当有明确目的，并记录在 shot plan 中。
静态图片不应无理由长时间停留。可以使用：
- 有意义的切换
- 短暂揭示
- 稳定的镜头推进
- 受控的镜头移动
面对长网页时，应固定页面宽度，像真实浏览一样缓慢滚动。不要用快速匀速滚动单纯消耗画面时长。
长页面通常应裁切到最具代表性的 16:9 区域。只有当页面本身具有特殊历史意义时，才保留完整长页面移动。
自制图形不能伪装成历史证据
自制图形适合组织、标注和解释真实材料。
当真实素材无法解释某个机制时，才使用自制图形。自制图形不能伪装成历史网页、真实截图或未经证实的界面。
章节卡保持简单
章节卡只需要：
- 一个较大的时间节点
- 一行简短副标题
不需要进度条、角落填充物或重复时间线。
章节卡应当紧接在相关历史资料或平台素材之前。
动效服务于证据变化
主要转场语言应当保持克制：
- 硬切
- 有目的的推近
- 匹配剪辑
动效应当表示证据、时间或叙事阶段发生了变化，而不是持续制造装饰性运动。
七、声音、字幕与音乐
旁白与时序来自同一份清单
旁白、字幕和场景时序应当从同一份 manifest 生成，避免三个系统各自维护时间。
对于已经建立的中文解释型生产线，默认使用：
EdgeTTS zh-CN-XiaoxiaoNeural除非项目 brief 另有要求。
字幕保持短而连贯
字幕应拆分为连接自然的短语。
建议：
- 避免句末标点
- 避免装饰符号
- 可以用逗号连接两个短分句
- 保留版本号、代码名和产品标识中的必要标点
例如：
Forge 1.0.0
Minecraft 1.20.2这些标识中的点号属于信息本身，不应随意删除。
字体应在项目内保持一致。Minecraft 风格的生产线默认使用 Fusion Pixel Font，覆盖字幕、标题、标签和解释性图形。
音乐从可听见的段落开始
BGM 应从第一个明确可听见的音乐段落开始，而不是从一段几乎没有内容的低音量前奏开始。
每个主要章节可以拥有自己的音乐段落，并使用短淡入淡出。音乐应当压在旁白下方，结尾的情绪高潮要与最终观点的出现同步。
游戏音效适合用于：
- 素材出现
- 场景切换
- 章节提示
音效应当短促、清晰、彼此有区分。大型章节提示使用短音符或短 accent 即可，避免长时间、高存在感的传送门音效。
八、证据记录与交付 QA
所有真实素材都应记录在项目 provenance 文件中，包括：
- 图片
- 网页
- 视频
- Logo
- 字体
- 音乐
- 用户提供的素材
真实截图应保留为截图，不要重新绘制成看似真实的界面。
public/ 和项目内素材目录都应当被视为明确的输入来源。用户提供的素材需要：
- 有清晰文件名
- 连接到对应旁白
- 在时间线上实际使用
- 经过使用检查
预览前，应当从 source builder 重新生成 index.html。
预览时使用稳定端口，优先使用 3000，并通过完整 URL 验证 HTTP 端点。只提供一个 index 文件路径，不足以证明预览服务正常。
渲染前至少完成：
- HyperFrames build
- 完整检查
- 全时间线视觉语义检查
- 字幕对齐检查
- 1 倍速音频试听
确认预览通过后，再进行正式渲染。
最终 QA 不能只检查语法，还应检查：
- 画面是否重复
- 静态素材是否停留过久
- 视频窗口裁切是否正确
- 章节卡时机是否合适
- 字幕是否清晰
- BGM 是否可听且不压旁白
- 音效是否存在且不过量
- 结尾是否形成完整的情绪和观点落点
九、当前可用的路线矩阵
HyperFrames / horizontal / investigation
VCT 数据样本与当前数据调查路线
HyperFrames / horizontal / explainer
Minecraft Java Mod 历史与其他机制解释型视频
HyperFrames / vertical or horizontal / motion
短动效、片头和 motion-first 单元
HyperFrames / horizontal / documentary
未来的 Bilibili 长篇纪录型项目
HyperFrames / horizontal / promo
项目、网站和功能展示路线目录不应提前创建空目录，也不应为尚未使用的组合制作占位技能。
只有当真实项目需要新路线时，才添加终端路线，并同步：
- 记录到
route-matrix.md - 使用真实项目验证
- 完成真实渲染
结语：先路由，再制作
一条可靠的视频生产流程，可以浓缩成五个问题：
- 使用什么框架？
- 交付什么画幅？
- 视频属于什么编辑类型？
- 项目的真实来源和验收状态是什么？
- 当前镜头是否准确服务于正在说的话？
HyperFrames 负责生产源文件，画幅负责构图边界，内容类型负责编辑方法，项目契约负责证据和工作区，QA 负责最终交付。
当这些选择在制作开始前被固定下来，视频才会从“素材堆积”进入真正可控的生产流程。