企业官网建设流程全解析

1. 从 OpenMontage 说起：一个把 AI 编程助手和视频渲染引擎缝在一起的思路

第一次看到 OpenMontage 这个名字，我脑子里蹦出来的不是某个具体产品，而是一类正在冒头的东西：把 agentic 的 AI coding assistant 和 Remotion 这种"用代码写视频"的框架拼起来，让模型直接产出可渲染的视频工程。这个方向最近热度确实上来了，尤其是 Veo 这类视频生成模型把"生成一段画面"的门槛打下来之后，很多人开始琢磨——画面能生成了，那剪辑、合成、字幕、节奏、转场这些活儿，能不能也交给 agent 去干？

OpenMontage 要解决的就是这个缝。它不是一个单纯的视频生成工具，也不是一个单纯的代码助手，而是试图让 AI coding assistant 在一个 Remotion 工程里自主完成"写组件、调参数、渲染成片"的闭环。适合谁来参考？三类人：一是做内容自动化、批量出片的技术团队；二是想把 AI 编程能力接进视频生产流水线的工程师；三是单纯好奇 Remotion 这套"React 写视频"范式、想看看 agent 能把它推到什么程度的开发者。哪怕你只是做短视频批量生产，理解这套组合拳的逻辑，也能帮你判断哪些环节值得自动化、哪些环节还得人来兜底。

我下面会按"整体设计思路 → 核心细节 → 实操落地 → 踩坑排查"这条线来拆，尽量把每个选择背后的理由讲清楚，而不是甩一堆概念。文中涉及的具体参数和步骤，有一部分是基于 Remotion 官方文档和 agentic coding 的常见实践补全的，我会标注清楚哪些是通用做法、哪些是我自己的取舍。

2. 整体设计与思路拆解：为什么是 Remotion + Agent，而不是别的组合

2.1 视频生成和视频合成，是两件完全不同的事

很多人一上来就把 OpenMontage 理解成"AI 生成视频"，这个理解偏了。Veo 这类模型干的是生成素材——给它一段文字，它吐出一段几秒的画面。但一条完整的视频，尤其是带品牌调性、带固定版式、带字幕和数据可视化的视频，光有素材远远不够。你需要把素材按时间轴摆好、加转场、叠字幕、配音乐、控制节奏，这些是合成的活儿。

合成这件事，传统上靠 Premiere、After Effects 这类 GUI 工具，或者靠 FFmpeg 命令行硬拼。前者对 agent 不友好（GUI 操作难以程序化），后者表达力有限（复杂动效很难写）。Remotion 的价值就在这儿：它让你用 React 组件描述视频，每一帧就是一个 React 渲染结果，时间轴就是帧号。这意味着视频工程变成了纯代码工程，而纯代码工程恰好是 AI coding assistant 最擅长的领域。

所以 OpenMontage 选择 Remotion 作为底座，逻辑是通的：agent 不需要去"操作软件"，它只需要"写代码"，而写代码是它的主场。这个选型背后其实是一个判断——能被代码完整描述的东西，才容易被 agent 稳定接管。GUI 工具再强，agent 也只能靠模拟点击，脆弱且不可复现；Remotion 工程则是确定性的，同样的代码永远渲染出同样的结果。

2.2 Agentic 的关键：不是"生成一次"，而是"能迭代"

普通的 AI 视频工具是"一次性"的：你给提示词，它出结果，不满意就重来。OpenMontage 这类 agentic 方案的核心差异在于闭环迭代。一个合格的 agentic coding assistant 在 Remotion 工程里应该能做到：读现有工程结构 → 理解需求 → 修改或新增组件 → 本地渲染预览 → 检查输出 → 根据问题再改。

这个闭环里，"渲染预览"和"检查输出"是最容易被忽略但最关键的环节。因为视频不像文本，文本生成完你读一眼就知道对不对，视频你得渲染出来看。agent 如果没有能力触发渲染、读取渲染结果（哪怕是抽帧成图片让它"看"），那它就只是个盲写的代码生成器，改十遍也未必对。

我实测下来的体会是：agent 的迭代能力，取决于它能不能拿到高质量的反馈信号。在 Remotion 场景里，这个反馈信号可以是渲染日志（报错信息）、可以是抽帧图片（视觉检查）、也可以是渲染耗时（性能问题）。OpenMontage 这类项目如果做得好，一定是在"给 agent 喂反馈"这件事上下了功夫，而不是单纯堆提示词。

2.3 和 Codex CLI + Remotion 这条线的异同

最近 "codex cli remotion" 这个组合被讨论得挺多，本质上是同一类思路的另一种实现：用命令行形态的 coding agent 去驱动 Remotion 工程。区别在于，Codex CLI 更偏"通用 coding agent 接一个具体框架"，而 OpenMontage 更像是"为视频合成这个场景专门设计的 agent 工作流"。

通用 agent 的好处是灵活，什么都能干；坏处是它不懂视频的"领域知识"——比如它不知道 30fps 下 1 秒是 30 帧、不知道useCurrentFrame()和interpolate()怎么配合做动画、不知道音频和视频轨怎么对齐。专用工作流则可以把这些领域知识固化进去，减少 agent 犯低级错误的概率。

我的判断是：短期内通用 agent + 好的工程脚手架（比如一份详尽的 Remotion 项目规范文档）能覆盖大部分需求；长期看，像 OpenMontage 这种带领域约束的方案在稳定性和可复现性上会更有优势。选哪个取决于你的场景——如果只是偶尔出片，通用方案够了；如果要批量、要稳定、要团队协作，专用工作流更靠谱。

3. 核心细节解析与实操要点：Remotion 工程的几个命门

3.1 帧、时间轴与插值：理解 Remotion 的心智模型

Remotion 最反直觉的地方是：它没有"时间"这个概念，只有"帧"。你写的组件会被渲染器在每一帧调用一次，组件内部通过useCurrentFrame()拿到当前帧号，然后决定这一帧长什么样。所谓动画，就是你根据帧号算出某个属性的值。

举个最朴素的例子，让一个方块从左移到右：

import { useCurrentFrame, interpolate } from 'remotion'; const MovingBox = () => { const frame = useCurrentFrame(); const x = interpolate(frame, [0, 60], [0, 500], { extrapolateRight: 'clamp', }); return <div style={{ transform: `translateX(${x}px)` }}>Box</div>; };

这段代码的意思是：第 0 帧 x=0，第 60 帧 x=500，中间线性插值。extrapolateRight: 'clamp'保证超过 60 帧后不再继续移动。如果你不写这个 clamp，方块会一直往右飞出画面——这是新手最常踩的坑之一。

为什么这个心智模型重要？因为 agent 在改代码时，如果它不理解"帧驱动"这件事，它很可能会写出基于setTimeout或 CSS animation 的代码，那在 Remotion 里是完全错误的。Remotion 的渲染是逐帧、可暂停、可跳转的，任何依赖真实时间的动画都会导致渲染结果不确定。所以给 agent 的工程规范里，第一条就该写死：所有动画必须由帧号驱动，禁止使用真实时间相关的 API。

3.2 组合（Composition）与参数化：让 agent 有"可改的把手"

Remotion 里每个视频是一个 Composition，注册在Root.tsx里，带一组默认 props。这个设计对 agent 极其友好，因为 props 就是天然的"参数接口"。你想让 agent 改标题文字、改配色、改时长，不需要它去读组件内部实现，只要告诉它改哪个 prop 就行。

<Composition id="Promo" component={Promo} durationInFrames={300} fps={30} width={1920} height={1080} defaultProps={{ title: '默认标题', primaryColor: '#1a73e8', duration: 10, }} />

我建议在给 agent 的规范里，把"可调参数"集中定义成一个 schema，比如用 Zod 定义 props 类型，这样 agent 改参数时有类型约束，不容易改错。实测下来，有类型约束的工程，agent 一次改对的概率明显更高，因为它能在编译期就发现错误，而不是等到渲染时才炸。

这里有个经验：不要把太多逻辑塞进 props。props 应该是"数据"，不是"行为"。如果你发现某个 prop 传进去后组件内部要做一堆分支判断，那说明这个设计对 agent 不友好——它得理解你的分支逻辑才能正确改。更好的做法是把不同变体拆成不同 Composition，让 agent 在"选哪个组件"这一层做决策，而不是在"传什么参数"这一层做决策。

3.3 素材管理：静态资源、动态生成与 Veo 的接入点

视频工程离不开素材。Remotion 里素材分两类：静态资源（staticFile()引用的图片、音频、视频）和动态生成的内容（用代码画出来的图形、文字、图表）。OpenMontage 这类方案里，Veo 生成的视频片段通常作为静态资源落盘，然后被 Remotion 引用。

这里有个实操要点：素材路径一定要用staticFile()包一层，不要直接写相对路径。因为 Remotion 渲染时的工作目录和开发时可能不同，直接写路径在本地能跑、一渲染就找不到文件，这个坑我踩过不止一次。

import { staticFile, Video } from 'remotion'; <Video src={staticFile('clips/veo-output-01.mp4')} />

另外，Veo 生成的片段时长往往和你的时间轴对不齐。比如你规划了 5 秒的镜头，Veo 给你 4.2 秒。这时候要么用playbackRate微调速度，要么用trimBefore/trimAfter裁切，要么在前后补黑场或转场。我的建议是在 agent 的工作流里加一步"素材时长校验"：渲染前先探测每个片段的实际时长，和规划时长比对，超出阈值就报警或自动调整。这一步能省掉大量"渲染完才发现对不齐"的返工。

3.4 音频对齐：最容易被 agent 忽略的细节

视觉部分 agent 往往能处理得不错，但音频是重灾区。常见问题有三个：音频比视频长导致结尾被截、音频比视频短导致结尾静音、多个音频轨叠加时音量爆掉。

Remotion 里音频用<Audio>组件，配合<Sequence>控制起止。关键参数是startFrom（从音频的第几帧开始播）和endAt（播到第几帧）。如果你要让音频和某个视觉事件对齐，最稳的做法是先确定视觉事件在第几帧，再反推音频的 startFrom，而不是凭感觉调。

<Sequence from={30} durationInFrames={120}> <Audio src={staticFile('audio/bgm.mp3')} startFrom={0} endAt={120} /> </Sequence>

音量控制上，多个音轨叠加时建议给每个轨设volume，总和别超过 1.0，否则会削波失真。BGM 一般压到 0.2~0.3，人声或音效保持 0.8~1.0。这些数值不是死的，但作为 agent 的默认值很合适——它至少不会一上来就把音量拉满。

4. 实操过程与核心环节实现：从零搭一个能被 agent 接管的 Remotion 工程

4.1 工程初始化与目录约定

第一步是搭骨架。用npx create-video@latest起一个 Remotion 项目，然后按下面的结构整理目录。这个结构不是官方强制的，但它是"对 agent 友好"的——每个目录职责单一，agent 找文件、改文件都不容易迷路。

my-video/ ├── src/ │ ├── Root.tsx # Composition 注册中心 │ ├── compositions/ # 各个视频组件 │ │ ├── Promo.tsx │ │ └── Tutorial.tsx │ ├── components/ # 可复用的小组件 │ │ ├── Title.tsx │ │ └── LowerThird.tsx │ ├── schemas/ # props 类型定义（Zod） │ │ └── promo.ts │ └── utils/ # 工具函数 │ └── timing.ts ├── public/ # 静态资源 │ ├── clips/ │ ├── audio/ │ └── images/ ├── remotion.config.ts └── package.json

为什么要把compositions和components分开？因为 agent 改代码时，如果所有东西都堆在一个文件里，它很容易改错地方。分开之后，"改某个视频"和"改某个通用组件"是两个明确的动作，agent 的改动范围可控，回归风险也小。

schemas目录是我强烈建议加的。用 Zod 定义每个 Composition 的 props 类型，既能在开发时做校验，又能作为 agent 的"接口文档"。agent 读一遍 schema 就知道这个视频能调哪些参数、每个参数什么类型、有没有默认值，比让它去读组件实现高效得多。

4.2 用 Zod 定义 props schema 的具体写法

import { z } from 'zod'; export const promoPropsSchema = z.object({ title: z.string().default('默认标题'), subtitle: z.string().optional(), primaryColor: z.string().default('#1a73e8'), durationInSeconds: z.number().min(3).max(60).default(10), showLogo: z.boolean().default(true), }); export type PromoProps = z.infer<typeof promoPropsSchema>;

然后在 Composition 里用schema属性挂上去，Remotion 会自动做校验，还会在 Studio 里生成一个可视化编辑面板。这个面板对 agent 也有用——agent 可以通过修改 props 来快速试不同配置，不用改代码。

这里有个细节：durationInSeconds和 Composition 的durationInFrames是两个东西。前者是业务参数（用户想多长），后者是技术参数（实际渲染多少帧）。你需要在组件里做换算：durationInFrames = durationInSeconds * fps。这个换算逻辑最好放在一个工具函数里，别散落在各处，否则 agent 改的时候容易漏改。

4.3 渲染命令与 agent 的调用方式

Remotion 的渲染命令是npx remotion render，基本用法：

npx remotion render Promo out/promo.mp4 --props='{"title":"新标题"}'

给 agent 用的渲染命令，我建议封装成一个 npm script，把常用参数固化进去：

{ "scripts": { "render:promo": "remotion render Promo out/promo.mp4", "render:preview": "remotion render Promo out/preview.mp4 --scale=0.5", "still": "remotion still Promo out/frame.png --frame=30" } }

render:preview用--scale=0.5渲染半分辨率，速度快很多，适合 agent 迭代时快速看效果。still命令抽单帧成图片，是 agent "视觉检查"的关键——它可以把抽出来的帧图片拿去分析，判断布局有没有问题。这两个命令是我在实际工作流里用得最多的，比全量渲染高效太多。

提示：agent 迭代阶段一律用 preview 或 still，只有最终确认后才跑全量渲染。全量渲染 1080p 一条 30 秒视频可能要几分钟，迭代时跑全量纯属浪费时间。

4.4 一个完整的 agent 工作流示例

假设需求是"把 Promo 视频的标题改成'春季新品发布'，主色改成橙色，时长压到 8 秒"。一个设计良好的 agent 工作流应该是这样的：

1. 读schemas/promo.ts，确认有title、primaryColor、durationInSeconds三个参数。
2. 读Root.tsx，确认 Promo 这个 Composition 的注册信息。
3. 修改defaultProps或渲染时传 props，把三个值改掉。
4. 跑npm run still，抽第 30 帧看标题和配色。
5. 如果视觉没问题，跑npm run render:preview看整体节奏。
6. 确认后跑npm run render:promo出成片。

这个流程里，第 1、2 步是"读"，第 3 步是"写"，第 4、5 步是"验证"，第 6 步是"交付"。读-写-验证-交付这个循环，是 agentic 工作流的基本骨架。任何一环缺失，agent 的可靠性都会大打折扣。尤其是"验证"这一环，很多方案为了省事直接跳过，结果就是 agent 改完不知道对不对，只能靠人肉检查，自动化程度大打折扣。

5. 常见问题与排查技巧实录：那些渲染时才暴露的坑

5.1 渲染报错排查速查表

这张表是我从实际项目里攒出来的，基本覆盖了八成以上的渲染报错。agent 遇到报错时，如果能拿到这张表做映射，定位速度会快很多。建议把它作为工程文档的一部分，让 agent 能读到。

5.2 字体加载：本地能跑、渲染就变默认字体

这是 Remotion 新手最经典的坑。你在 CSS 里写了font-family: 'MyFont'，本地 Studio 里显示正常，一渲染就变成系统默认字体。原因是渲染时的环境没有你系统里装的那个字体。

解决办法是用@remotion/google-fonts或者@remotion/fonts显式加载：

import { loadFont } from '@remotion/google-fonts/Inter'; const { fontFamily } = loadFont();

然后在样式里用这个fontFamily。这样字体是随工程打包的，渲染环境一定能拿到。任何依赖系统字体的写法，在 agent 工作流里都是定时炸弹，因为 agent 没法感知"这个字体在渲染机上存不存在"。统一用打包字体，一劳永逸。

5.3 时长对不齐：一个自动校验的小脚本

前面提过素材时长的问题，这里给一个具体的校验思路。用ffprobe探测每个片段的实际时长，和规划时长比对：

ffprobe -v error -show_entries format=duration -of csv=p=0 public/clips/clip-01.mp4

输出是一个秒数，比如4.2。你可以在 agent 工作流里加一步：把所有片段的实际时长读出来，和schemas里规划的时长做差，超过 0.3 秒就标记出来让 agent 处理。处理方式无非三种：裁切、变速、补转场。让 agent 根据差值大小自动选，比人肉一个个调快得多。

注意：变速会改变音频音调，如果片段带人声，慎用变速，优先考虑裁切或补转场。

5.4 性能优化：渲染慢的四个常见原因

渲染慢是另一个高频问题。按我的经验，原因通常在这四个地方，按排查优先级排：

1. 分辨率过高。1080p 渲染慢就先用 720p 或--scale=0.5验证逻辑，最后再出高清。
2. 并发设置不当。默认并发是按 CPU 核数来的，但如果你内存不够，高并发反而会拖慢甚至 OOM。内存紧张时加--concurrency=2试试。
3. 单帧计算太重。比如在组件里做了大量数组遍历、复杂计算。这类计算应该用useMemo缓存，或者提前算好存成常量。
4. 素材太大。4K 素材塞进 1080p 工程纯属浪费，提前压到目标分辨率。

我一般会先跑一个 10 帧的短渲染测速，算出单帧耗时，再乘以总帧数估算全片时间。如果估算时间离谱，就先优化再全量渲染，别傻等。

5.5 给 agent 的工程规范文档该写什么

最后分享一个我觉得最有价值的经验：给 agent 准备一份工程规范文档，比调提示词有用得多。这份文档应该包含：

• 目录结构说明，每个目录放什么。
• 动画必须帧驱动，禁止真实时间 API。
• 素材必须用staticFile()，字体必须打包加载。
• 渲染命令清单，迭代用 preview/still，交付用全量。
• 常见报错速查表。
• props schema 的位置和修改方式。

这份文档放在工程根目录，agent 每次开工先读一遍。实测下来，有这份文档的工程，agent 犯低级错误的概率能降一大半。它本质上是在把"老手的经验"固化下来，让 agent 不用每次从零摸索。这件事一次投入、长期受益，我觉得是 OpenMontage 这类方案能不能真正落地的关键所在。

6. 我对这套组合的一些个人判断

折腾了一段时间 Remotion + agent 这套东西，我最大的感受是：视频合成的自动化，瓶颈不在生成能力，而在验证能力。模型写代码越来越强，但"写完怎么知道对不对"这个问题，目前还得靠抽帧、预览、日志这些手段拼凑。谁能把验证这一环做得更顺滑，谁就能让 agent 真正跑起来，而不是停在"生成一堆代码等人检查"的阶段。

另一个体会是，领域知识固化的价值被低估了。通用 agent 什么都能写，但在视频这个场景里，它不知道的细节太多了——帧率、插值、音频对齐、字体加载，每一个都是坑。把这些知识写进工程规范，比指望 agent 自己悟出来靠谱得多。OpenMontage 这类方案如果能把领域约束做扎实，在稳定性上会比纯通用方案有明显优势。

至于 Veo 这类生成模型的接入，我的看法是把它当成"素材供应商"就好，别指望它直接出成片。生成归生成，合成归合成，中间用 Remotion 这层代码化的胶水粘起来，各司其职，整个流水线才稳。这个分工想清楚了，后面扩展起来也顺——换生成模型不影响合成层，换合成框架也不影响生成层，解耦带来的灵活性，在快速迭代的场景里很值钱。