Feimore AI
开始使用

Logo 和字幕不该只交给生成模型：五条可控的视频制作路线

一道题，难倒了大多数视频模型

2026 年 10 月 1 日，arXiv 上出现了一个新基准 VTR-Bench，专门测视频生成模型能否把字“写对”。它用 300 条提示词、五类场景（广告、科学、界面、文化、日常），评测了 11 个当下最先进的模型，指标是字错率（WER）：把画面里出现的文字与要求出现的文字逐词比对，错得越多，数值越高。 结果并不乐观。成绩最好的 Wan 3.0 平均 WER 为 0.250。WER 是包含替换、插入和删除的编辑距离指标，不能简单理解为恰好四分之一的词错误；11 个模型中只有两个低于 0.5（另一个是 Minimax H3，0.447）；9 个超过 0.6，其中 5 个在 0.96 以上，几乎等于逐字皆错，Kling v3.0 为 0.979，几款开源模型接近 1。Seedance 2.5 为 0.641。论文还统计，23.31% 的目标文字被评估器判定为无法辨认。 需要说明两点。第一，这个基准考的是“提示词要求出现的文字”，不是“给模型一张 Logo 参考图，让它照着用”，后者的表现可能更好，但目前没有同等规模的公开数据。第二，它测的是整段生成，并不意味着每支视频都会出错。 另一项 2026 年 5 月的研究换了个角度：用带多个文字组件的设计动画做测试。这里的数字来自特定设计布局基准中的 LLM 评估指标，而不是通用的文字块正确率：在完整版式下，Veo 3.1 的 Hard AR 约为 42%，Sora-2 约为 67%，参考设计约为 94%。作者的结论是，当前的生成模型常常无法在多组件版式中准确保留所需文字。 厂商文档的态度也值得留意。Google 的 Veo 3.1 接口文档把参考图称为“风格与内容参考”，最多三张，并称模型会保留主体的外观，但没有对文字与 Logo 的逐像素保真作出承诺。这里能得出的结论是“文档未作保证”，不能进一步推断模型在理论上无法保留文字。 营销视频里，有些东西不能“差不多”：Logo、产品界面、价格、品牌色、字幕。所以问题不再是“怎样让模型画得更准”，而是换一个问法。

先换一个问法：每个像素从哪里来

视频里的每个像素，来源只有几类：

像素来源 做法 谁保证 Logo 与界面不变 典型缺陷
生成 模型根据提示词和参考图重新画一遍 没有人，靠概率 文字乱码、Logo 漂移
渲染 程序读取源文件（SVG、字体、截图），按规则算出每一帧 源文件本身 缺少真实世界的质感，擅长图形与排版
采集 真实运行软件，把画面录下来 软件本身 录制质量、环境与脚本的稳定性
合成 把以上几类分层叠加 各层各自负责 接缝处的对齐与光影

下文的五条路线，是这几种来源的不同组合：浏览器逐帧渲染、非浏览器的程序化引擎、真实采集加后期、模板填槽、以及生成与合成的混合。它们有一个共同点：由文本大模型负责“导演”（写分镜、选组件、填参数），把“不许错”的像素交给确定性的程序。

路线一：把视频当作网页来渲染

电影的本质是一格一格的静止画面。浏览器渲染视频的思路与之相同：每一帧都是“当前时刻”的纯函数，程序依次跳到第 n 帧，把画面截下来，再交给 ffmpeg 拼成视频。

原理

要让这件事可重复，需要几条纪律。以 HeyGen 开源的 HyperFrames 文档为例：

  • 时间只看帧号，不看钟表：“time = floor(frame) / fps”，整数运算。
  • 动画只“跳转”，不“播放”：“All GSAP timelines are paused and seeked, never played.”
  • 抓取画面由浏览器一次性完成：Chrome 的 HeadlessExperimental.beginFrame 在一次原子操作里取得像素。
  • 禁用一切不确定因素：Date.now()、requestAnimationFrame、系统计时器，以及未设种子的 Math.random()。 Remotion 走的是另一条路：每帧调用浏览器的截屏接口，靠“画面只能由帧号决定”这一写法约定来保证一致。 Logo 与文字为什么更容易保持一致？因为它们来自源文件：SVG、PNG、字体文件由 Chrome 栅格化，在固定浏览器、字体和渲染环境下可以保持一致；这不等于最终压缩视频在所有播放器中都逐像素相同。输出 4K 时，HTML 文字和矢量图形会按更高分辨率重新栅格化，而位图只能被放大。

代表方案

  • Remotion：用 React 编写，2020 年起开源。3 人及以下的团队免费；更大的公司按“写 Remotion 代码的人”每人每月 25 美元，或按每次成功渲染 0.01 美元计费（最低 100 美元/月）。官方提供面向 AI 编程代理的 Agent Skills。官方给出的 AWS Lambda 成本示例：1 分钟视频约 0.017 至 0.021 美元（仅算力，不含存储、流量与授权费）。
  • HyperFrames：HeyGen 的开源项目，仓库创建于 2026 年 3 月 10 日，Apache-2.0 许可，以 HTML 加 GSAP 等可跳转的动画库为核心，提供面向代理的技能包。当前仍是 0.x 版本，动画适配器接口标注为实验性，发版频繁。
  • Revideo、Motion Canvas：MIT 许可，更偏编辑器与库的形态；Motion Canvas 最新稳定版发布于 2024 年 12 月。

容易踩的坑

  • 视频素材：HeyGen 明确写道，“Letting a browser play video at render time does not work.”它的做法是渲染前用 FFmpeg 把每段视频按目标帧率拆成编号图片，再替换进页面。
  • 平台限制：HeyGen 的说明是，这套最强的确定性抓帧路径在 Linux 的 chrome-headless-shell 上成立；在 macOS 与 Windows 上主要使用截图捕获，确定性能力和并行方式与 Linux 路径不同。
  • 字体与中文：HyperFrames 文档承认，本机渲染“可能在不同机器间差一个像素”，因此提供 Docker 模式，固定 Chromium 版本、字体集与编码器。字体是否可重复取决于是否明确嵌入并锁定编译环境；当前文档已包含部分 CJK 预置字体，也支持编译时嵌入或获取字体，不能笼统写成“只有拉丁子集”。Remotion 的仓库里则有 issue 反映，加载中日韩字体子集时会报错（#7258，已关闭，本文未能确认修复方式）。
  • 色彩：Remotion 4.x 文档将默认色彩空间描述为等同于 BT.601；5.0 仍应写成规划版本，不能当作当前版本行为。HyperFrames 则在抓帧滤镜里显式转换到 BT.709 并写入标签。品牌色在手机上是否一致，取决于这一步。
  • 授权与稳定性：Remotion 5.0 的授权草案（PR #3750，截至 2026 年 10 月 17 日未见合并）拟把外包人员计入团队规模，并禁止运营“允许终端用户上传自己的 Remotion 代码”的渲染服务。对于由大模型生成场景代码的平台，这需要法务确认。

效果与边界

图形、文字、界面动效，是这条路线最稳的部分，而且大模型写 HTML 与 CSS 的能力强，HeyGen 的原话是“LLMs are great at writing code specifically HTML”。它不擅长的是真三维、复杂光影与物理运动。速度方面，本文没有找到独立的性能基准，公开数字都来自厂商。

路线二：不用浏览器的程序化引擎

去掉浏览器这一层，直接用滤镜、图形库或三维引擎出帧。这条路线是一个家族：

  • FFmpeg 滤镜图：当前最新为 9.0.2。可用 drawtext 与 libass 做文字和字幕，用 overlay 叠图，用 perspective 做透视变形，还能做逐帧的动画叠加与 GL 转场；8.1 起新增 drawvg，可用 Cairo 在滤镜里画矢量图形。它不是浏览器级的排版引擎，drawtext 也不提供浏览器式的自动布局与换行；现代构建可以使用 HarfBuzz 做文字 shaping，并支持多行和对齐，复杂版式仍应由上层计算。
  • 二维图形引擎：skia-canvas 4.0（MIT，2026 年 10 月 12 日发布）是不依赖浏览器的 Canvas 实现；Satori 加 resvg 可把 CSS 子集渲染成图片，适合卡片式版面，但 Satori 自己声明输出不保证与浏览器一致。动效方面，ThorVG 是仍在维护的 Lottie 与 SVG 渲染器，rlottie 已被弃用，Rive 没有文档化的 Linux 无头导出路径。Manim 适合图解与数学类讲解视频，中日韩字体需要显式指定。
  • 三维引擎：Blender 是唯一成熟、可脚本化的真三维产品镜头方案，具备物理光照与运动模糊，输出归使用者所有；其 Python 接口 bpy 为 GPL-3.0。没有显卡的服务器上，Cycles 的 CPU 渲染是可行路径，EEVEE 在无头环境下的表现，各来源说法不一，本文未能验证。把 Logo 或界面截图作为贴图贴到三维设备模型上，是这类方案的典型用法。Godot 的 Movie Maker 模式按非实时方式逐帧渲染，官方称输出与硬件无关，但无显卡环境能否运行，尚无文档说明。
  • After Effects 模板自动化：品牌与动效设计的保真度最高，设计师工作流成熟。但 AE 只能运行在 Windows 与 macOS 上，无人值守的服务器授权没有定论：nexrender 的说明称渲染节点无需 AE 授权，Adobe 社区的回帖则持相反看法，本文未能读到 Adobe 官方页面。这是一个需要向 Adobe 书面确认的法律风险，使用托管服务是规避方式之一。 与浏览器路线相比，这个家族的优势在于真三维与物理光照、更高的吞吐和更简单的运维（以普通进程运行，无需 Chromium 和逐帧截图），以及离线渲染的确定性。劣势同样明显：还原 HTML 与 CSS 界面不是它们的强项，网页字体、emoji、中日韩回落不能开箱即用，大模型在这些工具上的训练语料也远少于 HTML。本文没有找到任何一项非浏览器渲染器与无头 Chromium 的横向性能对比。

路线三：把真实的软件录下来

相机架在三脚架上的工作室场景 图：真实采集的逻辑与拍摄一致，画面来自被拍摄的对象本身。 想让界面一笔不差，最稳的办法是使用真的界面。关键是录屏的同时记录事件：点击位置、光标轨迹、按键，之后再用确定性的后期叠加缩放、光标、标注与字幕。Screen Studio 的官方文档写明，自动缩放由点击位置生成，并作为可编辑的区块出现在时间线上，也就是说，“哪里该放大”来自事件记录，而不是从像素里猜。

网页界面

Playwright 1.64（2026 年 10 月 7 日发布）新增 VP9、fps、缓动合成光标与操作装饰；章节卡和 HTML 叠加层属于较早的 screencast API 能力。它仍是实时的屏幕流，画面尺寸受限于 CSS 视口，默认输出为 800×450。Puppeteer 当前提供实验性的 page.record()；Chrome 153 与 ffmpeg 的限制需要和旧的 page.screencast() 文档区分开。 调研时做了一次小实验：同一个含中英文小字的静态界面页，与原生截图对比，默认 800×450 的 PSNR 为 35.4 dB，1080p 的 VP9 为 40.4 dB，Chrome 153 原生录制为 41.6 dB。这是单页、单次的结果，仅供参考；文章没有公开脚本、素材、编码参数和帧对齐方式，不能据此得出跨编码器的普遍结论。在这次实验里，输出分辨率的影响看起来大于编码器，但仍需更多可复现实验验证。要保证品牌色、细线图标与中英文小字，逐帧无损截图，或直接取自 DOM，是更稳妥的来源。

移动端、终端与 DOM

  • 移动端：iOS 模拟器的 xcrun simctl io recordVideo 与 Android 的 adb screenrecord（单段上限 3 分钟）都直接采集真实帧缓冲；Maestro 是仍在活跃维护的脚本化流程工具；设备外框可用 Rotato 的命令行把屏幕素材在渲染时换进去。
  • 终端：Charm 的 VHS 可以用脚本确定性地录制终端；本文查到的官方 release 页面列出的版本为 0.12.0，具体版本应随部署锁定。
  • DOM 回放：rrweb 重放转视频的 rrvideo，本质上是对重放页面的 Playwright 录屏，受同样的画质限制；Browserbase 已弃用 rrweb 回放接口，改用屏幕流视频，原因是 DOM 回放“subtly wrong”。交互式演示工具中，Navattic 与 Storylane 提供 DOM 级的捕获，Arcade 以截图与录屏为主；它们导出的视频多是幻灯片式的步骤演示（步数有上限），而非真实界面的连续画面。
  • 截图转代码：没有任何公开的像素级保真度度量，不宜用于要求界面一笔不差的场景。

让 AI 代理来操作软件

Playwright MCP（v0.0.83）已经暴露了录像、章节卡与操作叠加的工具，Stagehand 会缓存成功的操作，以便不经大模型重放。但相关厂商自己也承认，完全自主的探索并不可靠。更合理的分工是：由代理编写或修复一次脚本，之后由脚本确定性地重放，产出素材。

效果与边界

界面保真度最高，但需要可运行的软件与稳定的演示数据：固定视口、种子数据、模拟的时间与网络。竖屏成片要做重新取景，敏感信息要做模糊。

路线四：模板加数据填槽

排字工人在铅字排版机前工作的黑白照片 图：铅字排版的逻辑与模板相同，字模一旦铸好，每次印出的都一样，变化的只是排进去的内容。 设计师一次性搭好模板（版式、品牌字体、Logo 图层），每条视频只提交变量。大模型要做的，只是填写这些变量。几家代表产品的做法：

  • Creatomate：视频以 JSON 描述；修改项以元素名为键。它的“dynamic”标记只是组织与界面层面的约定，文档明确说明，无论是否标记，任何属性都可以通过接口修改。
  • Shotstack：用双花括号占位符做合并，模板有独立编号。
  • Canva：自动填充接口先返回模板里声明的可填字段；图片字段只接受已在素材库中的 asset ID，“External image URLs are currently not supported”。
  • Plainly：基于 After Effects，把 AE 图层映射为接口参数；不会自动改画幅，每种画幅需要独立的根合成与模板。 这里有一个容易被忽略的事实：在本文查阅的文档中，Creatomate、Bannerbear、Placid 都没有提供“锁定”标志，接口可以改任意属性。品牌安全因此取决于开发者暴露了多少字段，而不是厂商替你锁住了什么。较稳妥的做法是只给大模型一份很小的、带类型的字段表，由确定性的适配层映射到允许修改的键。 计费口径差异很大：Creatomate 按宽、高、帧率与时长折算积分，官方的说法是 1 积分约等于 1 亿像素，按此估算，一条 30 秒、1080p、30 帧的视频约 18.7 积分；Shotstack 按分钟计费，官方定价页上从每分钟 0.20 美元（按量付费）到 0.05 美元（最高档套餐）不等。在本文查阅的公开文档里，几家托管厂商都未说明中日韩字体的控制方式、色彩标注与渲染器版本的固定机制，这意味着可重复性需要自己验证。 适合的场景是批量个性化与版式固定的系列内容；不适合需要大量版式变化的创意。

路线五：混合，让 AI 只负责“允许变化”的部分

把画面分层：背景、人物、环境、镜头运动这类允许变化的，交给生成模型；Logo、界面、字幕、价格这类不许错的，用确定性的手段在后期叠加上去。

先固定关键帧，再生成

VTR-Bench 的作者做了一个“关键帧引导的代理框架”，以 Minimax H3 为例，字错率从 0.4468 降到 0.3015，相对降低 32.5%。这说明先固定起始画面再生成确实有帮助，但远没有降到零，多篇实践指南给出的建议也一致：精确的字幕、产品声明、价格与行动号召，应在剪辑环节加，不要指望模型一次生成对。

屏幕替换

最典型的场景，是 AI 生成的“手持手机”镜头里，屏幕必须是真实的软件界面。做法是跟踪屏幕的四个角点，用透视变换（单应性）把真实截图贴上去：OpenCV 的 findHomography 与 warpPerspective，或 ffmpeg 的 perspective 滤镜，也可以用 Blender 的 Plane Track Deform。分割与跟踪可以用 SAM 3，手遮挡屏幕时需要 MatAnyone 2 这类抠像模型生成 alpha 遮罩。 每个环节都有现成工具，但本文没有找到把它们自动串起来，并给出可靠率数据的公开方案。AI 生成的手机边框未必是刚体，四个角点也未必稳定，这一步目前仍然是工程活。

其他做法

  • 把需要精确的内容预渲染成带透明通道的图层，用 ffmpeg 的 overlay 合成到生成的底板上，这是常见做法。
  • 平面素材上的缓慢镜头与二点五维视差，可以不改变文字本身，因为素材就是图片。DepthFlow 1.0.1（2026 年 8 月 25 日）是活跃的开源方案，但采用 AGPL-3.0 许可，若作为网络服务提供，需要法务评估。
  • 如果 Logo 与界面是确定性插入的，验收就退化为几何与光度检查：四边形是否有效且稳定、叠层是否被遮挡、最终导出画面的文字识别结果是否等于目标文案。目前没有公开的 Logo 验收通过率与单条成本数据，上线前应当用一批真实生成做试点来估算。

让文本大模型当导演，而不是画师

无论选哪条路线，大模型的角色都是写分镜、选组件、填参数。公开证据都指向同一个方向：先规划，再写代码，渲染之后再检查。

  • 先规划：Code2Video（arXiv 2510.01174）把教学视频拆成规划、编码、评审三个角色。以 GPT-4.1 为底座，直接让模型写代码，美学分 34.2、知识测验分 37.0；完整流程为 79.0 和 82.0；去掉规划器，两项分别下降 40.9 与 41.5，是各组件里降幅最大的一项。代价是耗时约 7 倍、token 约 26 倍。这些分数部分由大模型给出，领域是教学动画，不能直接外推到营销视频。
  • 能运行不等于正确：OmniManim（arXiv 2605.15585）指出，重叠、错位、动画不连贯这类缺陷“无法仅凭代码可靠检出，要在执行之后才显现”，因此需要对渲染结果做结构化诊断，再做局部修复。
  • 让代码来量，不靠模型目测：Remotion 官方给大模型的系统提示明确禁用 Math.random()，要求使用带种子的随机函数；组件属性可用 zod 做类型校验；文字用 measureText、fitText 一类工具由代码测量。HyperFrames 则提供一条 check 命令，一次覆盖语法检查、运行时错误、版面、动效意图与 WCAG 对比度，并输出带标注的截图。
  • 品牌资产按引用，不要让模型重画：Remotion 官方的 AI 模板在用户附上图片时，会让助手“尝试用代码复刻”它，这恰恰是 Logo 失真的来源。更稳妥的做法是把 Logo 作为文件，按编号或路径引用。 需要坦率说明：本文没有找到直接比较“带类型的 JSON 加固定组件库”与“让模型写代码”在品牌保真度上的公开研究。上述做法是对多处证据的综合，而不是某个经过完整验证的架构。 音画同步也值得一提：以音频为时钟，先合成语音、取得时间戳，再据此推算镜头时长，比让模型估计时长可靠。ElevenLabs 的接口会随音频返回逐字符的起止时间；Remotion 的字幕接口按空格切词，中文需要自行分词。

工程细节：“可预期”是如何落地的

  • 目标是同镜像、同输出，而不是跨机器逐字节一致。Playwright 文档说明，截图会因浏览器和平台而异，基线应在同一环境生成；HyperFrames 也承认本机渲染可能差一个像素。
  • 固定浏览器版本。Remotion 每个版本固定一个 Chrome Headless Shell（4.0.534 起为 Chrome 157），并提示改用完整 Chrome 可能“不那么确定”。
  • 固定软件渲染。HyperFrames 的分布式渲染拒绝硬件 GL，理由是硬件 GL 在分块边界上不确定，并固定使用 SwiftShader。
  • 抓帧格式影响文字边缘。有损的 JPEG 帧会在 Logo 边缘和小字周围引入压缩噪点，Remotion 的文档建议用 png 帧以获得准确的颜色，代价是更慢。
  • 编码器要选可重复的。老资料（2007 年、2015 年的邮件列表）显示，x264 在线程数固定、不启用 VBV 时才可重复；硬件编码（VideoToolbox、NVENC）没有公开的逐位一致说明；HyperFrames 对分段输出拒绝 GPU 编码，理由是 GPU 编码器忽略强制关键帧。
  • 中文字形要明确。同一个汉字码位在不同语言的字体里字形不同；社区资料（如 Arch Linux 文档）记录，不带语言标记时 Noto CJK 在部分环境会回落到日文字形。应当嵌入明确的字体文件并设置语言，再放一个黄金测试：渲染几个中日写法不同的汉字，与存档图片比对。
  • 验收优先用确定性检查。版式由程序掌握时，Logo 的位置是已知的：裁剪出该区域，与源文件按同一尺度比对，比模板匹配更可靠，后者需要为每个 Logo 单独校准阈值；最终导出的画面再做文字识别，与目标文案比对（中文可用 PaddleOCR，需要在自己的画面上评测）；ffmpeg 自带黑帧、静帧、静音检测。视觉大模型评审放在最后一道，只作参考，不做自动打回。

五条路线怎么选

路线 像素来源 Logo 与界面保真 可重复性 擅长 主要风险与代价
一、浏览器逐帧渲染 渲染 高，源文件原样栅格化 高，同环境可回归 图形、文字、界面动效，大模型写 HTML 友好 字体、色彩与视频素材的细节；Remotion 授权；不适合真三维
二、非浏览器引擎 渲染 高，取决于素材 高，离线渲染 三维产品镜头、高吞吐、滤镜合成 没有排版引擎；AE 授权不明；大模型语料少
三、真实采集加后期 采集 高，源画面来自真界面；最终画质仍受录制与编码影响 取决于脚本与演示数据 软件与 App 演示 录制分辨率与压缩；需要可运行环境；全自动探索不可靠
四、模板加数据填槽 渲染（托管） 高，来自模板中的 Logo 图层 取决于厂商是否固定渲染器 批量个性化、系列内容 版式僵硬；字体、色彩与版本不透明
五、生成加合成的混合 生成加渲染或采集 取决于合成环节 中，底板每次不同 真实人物与场景 对齐与光影；缺少可靠率数据；成本

按场景的粗略建议

  • 软件或 App 功能演示：以路线三为主，路线一负责片头片尾、字幕与缩放标注。
  • 品牌片头、数据卡片、字幕动效、多语言版本：路线一。
  • 三维产品展示、开箱类镜头：路线二，以 Blender 为主。
  • 成百上千条个性化视频：路线四，或自建路线一的模板。
  • 需要真实人物与场景，同时屏幕上必须是真界面：路线五。

总的原则可以浓缩成一句话：让模型负责允许变化的，让程序负责需要验收的。生成式模型在 2026 年仍在快速进步，文字渲染的差距也在缩小，但只要 Logo 与界面不能错一笔，把它们放进确定性的那一层，仍是最可预期的做法。

说明与参考

数据截至 2026 年 10 月 17 日。文中的论文多为预印本，部分评分由大模型完成；价格与许可条款以各官方页面为准。引用的主要来源：