企业官网建设流程全解析

每天一睁眼，手机上躺着一条“新鲜出炉”的技术新闻视频，标题、字幕、配音、封面全齐，感觉像有个勤快实习生替我值完了夜班。这活儿不是我的幻觉，是我用蓝耘元生代 + Remotion 搭起来的一条全自动流水线：每天固定时间抓取技术新闻，交给云上算力整理成稿，再让视频模板自己“长”出成片，全程不需要我手动打开剪辑软件，一条命令就能出片。

这套组合解决的是内容生产者最头疼的重复劳动问题。以前我日更技术新闻视频，从找素材、写稿、录音、剪字幕到压制成片，每天至少搭进去两小时，而且越做越像流水线工人。现在我把“分析新闻”“写摘要”“配音”“渲染画面”这些环节全部脚本化，本地只负责下发任务和接收成品。如果你也是做内容更新、想稳定日更技术频道的开发者或自媒体人，这篇实操记录应该能让你少踩很多坑。

1. 一条命令背后，我到底在“打工”什么

标题叫“我给AI打工”，其实是反讽。表面上我是那个坐在电脑前的人，但真正干活的是蓝耘元生代上的云端算力，和 Remotion 这个代码化视频渲染框架。我只是那个把自己“工作流程”拆成标准作业程序，然后交给机器执行的人。

1.1 把每日视频拆成一条可复用的流水线

在我动手写任何代码之前，先干了这么一件事：把“做一条技术新闻视频”这件事，拆成几个可以被程序独立处理的环节。这个拆解过程，比选工具本身更重要。

我拆出来的环节大概是这样的：采集新闻源、内容去重与筛选、生成新闻摘要和口播稿、语音合成、背景视觉生成、字幕排版、视频剪辑拼接、最后导出成片。你仔细看就会发现，这里面每一步都有现成工具能做。难的是把它们串起来，并且在某一步失败时，整个流程不会直接崩掉。

拆完流程后，我给自己定了个标准：所有中间产物必须是标准文件。新闻稿存成 JSON，音频统一用 WAV，字幕文本和配音时长一一对应。只有中间产物格式统一，后续的 Remotion 模板才能用同一套数据接口渲染出不同日期的视频。这个习惯帮了我大忙，后面讲缓存和重试的时候你就能体会到。

1.2 为什么是蓝耘元生代 + Remotion 这个组合

先说蓝耘元生代。我的需求很具体：每天要跑大模型摘要、文本润色、语音合成，偶尔还要生成配图。这些任务本地显卡不是不能跑，但问题是我不能为了跑一个三分钟的任务，把显卡锁死在电脑里，更不能承担模型环境冲突带来的折腾。蓝耘元生代这类云端算力平台解决的是“按需调用”的问题，我通过 API 把任务提交上去，它会分配计算资源跑完，再把结果返回给我。简单说，我把这里当成一个“算力外卖”，按量付费，不用管机器维护。

再说 Remotion。它不是普通剪辑软件，而是一个用代码来写视频的开源框架。你写一个 React 组件，组件里的每帧画面都可以由 JavaScript 计算出来，最后通过命令行渲染成 MP4。这个思路对自动化来说简直是天作之合：新闻列表是数组，我往模板里塞几个条目，它就能自动生成对应时长的视频段落，不用我一帧帧去对时间轴。

选这套组合，本质上是在选“可编程性”。Premiere 和剪映再强大，它们的自动化能力也是封闭的；Remotion 的自动化能力是开放的，配合云算力的 API，我能把整条流水线写进一个脚本文件里，甚至挂上定时任务，让它像闹钟一样每天自动开工。

2. 分工与串联：流水线的每一站都干了什么

一条自动化视频流水线，很像一家迷你工厂。每个环节都要产出下一环节能用的原料，同时要留出出错后的回退余地。下面我把每站的细节摊开讲。

2.1 第一站：技术新闻的采集与清洗

新闻采集是所有后续工作的燃料。我每天抓的是技术社区的热榜、开源项目的发布动态、几个固定技术媒体的 RSS。采集本身不难，难在清洗。

我踩过的第一个坑是编码问题。有些源返回的内容里带着 HTML 标签、混乱的空白字符，甚至还有 emoji 混合在标题里，直接拿来喂给大模型写摘要，容易把模型带偏。所以我在采集脚本里做了一层清洗：去掉标签、压缩空白、过滤掉非技术类的杂讯，比如把“某某公司融资”这种泛商业新闻和“某某框架发布新版本”这种纯技术动态区分开。

清洗之后还要做去重。每日新闻重复率其实很高，同一个框架的版本更新，会出现在好几个源里。我的做法很简单：以标题的归一化文本做指纹，再用发布时间排序，只保留最早出现的那条。这套朴素方法应付绝大多数情况已经足够。

2.2 第二站：云上算力生成文稿

清洗完成后的新闻条目，被整理成一个 JSON 数组。接下来我要为每个条目生成三样东西：一句吸引人的导语、一段 60 字左右的摘要、一条适合口播的简短文案。这些全部交给蓝耘元生代上的大模型来处理。

我在调用时设置了一个固定 Prompt 模板，重点强调三件事：输出仅限 JSON、每条摘要不超过指定字数、口播文案的断句必须自然。为什么要强调 JSON？因为后续脚本要直接解析模型输出，格式稍有偏差就会让整条流水线卡住。

还有一点值得提醒：只在“摘要生成”这一步调用大模型是不够的。我试过让模型直接把整段新闻稿一口气写完，结果节奏拖沓，口播出来非常不自然。后来我给每个条目单独生成文案，最后再拼接成一个整体的新闻串烧稿，更接近短视频的观看节奏。

2.3 第三站：配音与配图

配音环节我用的是本地部署的开源语音合成模型，再结合一个简单的停顿规则：每条摘要之间至少留 500 毫秒静音，让听感不显得赶。为了控制总时长，我会先合成单个条目的音频，再用工具读出时长，最后汇总成整个视频的配乐时间轴。

配图方面，风格统一比画质更重要。我不追求每张图都惊艳，而是保证同一期节目里的视觉语言一致。我让模型按统一风格参数生成背景图，输出 PNG。如果当天生成失败，就回退到固定的纯色渐变背景，保证视频不会因为缺图而卡壳。

3. Remotion 模板怎么写，视频才能“长出来”

如果说流水线的前几站是在准备“原材料”，Remotion 模板就是把原材料变成成品的车间。这一步最关键，也最容易让人一头雾水。

3.1 用数据驱动视频，而不是一帧帧剪

我第一次接触 Remotion 时，最大的认知转变是：不要把它当成剪辑软件，而是当成一个“渲染函数”。你输入一份数据（比如新闻条目数组），输出一段视频。视频里每一帧画面的坐标、透明度、文字内容，全部都可以由数据计算出来。

这个思路直接决定了模板的设计。我把整期视频定义成一个主组件，组件接收items（新闻条目数组）和date（日期）作为 props。渲染时，每个新闻条目对应一个片段，片段的时长由配音音频的长度决定。这样每天的新闻数量不同，视频总时长也会自动伸缩，完全不需要手动调整。

3.2 一个新闻条目的模板长什么样

这里我给出一个极简的模板骨架，它足够说明核心思路。

import { AbsoluteFill, Sequence, Audio, useCurrentFrame } from "remotion"; export const NewsCard: React.FC<{ item: NewsItem }> = ({ item }) => { return ( <AbsoluteFill style={{ justifyContent: "center", alignItems: "center", backgroundColor: "#1a1a2e", }} > <div style={{ fontSize: "3.6rem", fontWeight: 700, color: "#fff", textAlign: "center", padding: "0 80px", }} > {item.title} </div> <div style={{ fontSize: "2rem", color: "#9ca3af", marginTop: 28, }} > {item.summary} </div> </AbsoluteFill> ); };

这只是一个静态画面，真正的时间轴控制由外层组件完成：

export const NewsVideo: React.FC<{ items: NewsItem[] }> = ({ items }) => { let currentFrame = 0; return ( <> {items.map((item, index) => { const startFrame = currentFrame; currentFrame += item.audioDurationInFrames; return ( <Sequence key={index} from={startFrame} durationInFrames={item.audioDurationInFrames}> <Audio src={item.audioPath} /> <NewsCard item={item} /> </Sequence> ); })} </> ); };

每个Sequence就像时间轴上独立的一段，from决定它从第几帧开始，durationInFrames决定它持续多久。音频多长，画面就停多久，音画同步的问题从根源上被解决。

3.3 渲染参数与并发调优

模板写好后，真正渲染时还要调几个参数。我第一次渲染一条五分钟的视频，默认设置下跑了将近二十分钟，后来发现几个关键点。

渲染命令里最值得关注的是--concurrency，它控制同时渲染多少帧。机器核心多的话，把并发数调上去会快很多。我自己的机器用--concurrency=4比较稳，太高会导致内存爆掉。另一个参数是--props，它允许你在命令行传入 JSON 作为模板的 props，这样我前几站生成的新闻数据就能直接喂给模板。

如果某一天的渲染因为中途报错失败，Remotion 还支持按帧范围渲染。我可以只渲染失败的那一段，而不是从头再来。分段渲染对长视频尤其友好，这也是我选择它的重要原因之一。

4. 一条命令的实现：脚本串联的前前后后

前几节讲的是“每一站怎么干活”，这一节讲怎么把这些站点拧成一根绳，真正做到“一条命令出成片”。

4.1 入口脚本的骨架

我的入口是一个 Bash 脚本，加上几个 Python 脚本分工协作。整体流程用下面这段伪代码就能讲清楚：

#!/usr/bin/env bash set -euo pipefail DATE="${1:-$(date +%Y-%m-%d)}" echo "start pipeline for ${DATE}" # 1. 抓取并清洗新闻 python fetch_news.py --date "$DATE" --output news.json # 2. 提交到蓝耘元生代生成摘要与口播稿 python generate_scripts.py --input news.json --output scripts.json # 3. 合成语音并统计音频时长 python generate_tts.py --input scripts.json --output audio/ # 4. 调用模型生成封面背景图 python generate_covers.py --input scripts.json --output covers/ # 5. 用 Remotion 渲染成片 npx remotion render src/index.tsx \ "output/news_${DATE}.mp4" \ --props="$(python build_props.py --date "$DATE")" \ --concurrency=4 echo "done: output/news_${DATE}.mp4"

这串代码本身不复杂，复杂的是每一步都要做好异常处理。我在脚本开头加了set -euo pipefail，意思是任何一条命令失败就立刻退出，避免带着半成品继续往下跑。

4.2 缓存、重试与可重入：自动化跑久了的命门

这一小节才是整套自动化能跑多久的关键。一开始我的脚本是“裸奔”的，某次新闻源超时导致整条流水线中断，重新跑一遍又得重新生成语音，白花了不少算力费用。后来我加了两层保护措施。

第一层是“落盘缓存”。每完成一步，就把结果写入本地文件。比如scripts.json生成后，再次运行时先检查这个文件是否存在且日期匹配，如果存在就直接跳过重新生成。这样即使中途失败，重跑时也能从断点继续。

第二层是“重试与退避”。蓝耘元生代 API 调用偶尔会超时，我的调用封装里加了三次重试机制，第一次失败等 5 秒，第二次等 20 秒，第三次等 60 秒。如果三次都失败，脚本不会硬撑，而是把这条新闻标记为失败，在视频里自动跳过，保证整体流程还能走完。

我还保留了一个“手动救援通道”：如果当天某条新闻特别重要，生成摘要失败，我会用手写文案替代它。具体实现是允许scripts.json里混入手工编辑的条目，脚本判断到字段不全时就原样使用已有内容，不再做二次生成。

5. 我踩过的坑：自动化视频生产的“事故现场”

说实话，这套系统第一次跑通并没有花太久，但真正让它稳定日更，是在解决了一堆“既不复杂但又很烦”的问题之后。这些问题如果不记录下来，后来的人很可能还要再踩一遍。

5.1 音画不同步排查

最让我头疼的是音画不同步。症状表现为：画面切换时配音还没结束，或者配音已经结束但画面还在停留。排查时我发现问题不在 Remotion，而在我的时长计算。我一度用“文本字数除以平均语速”来估算音频时长，结果差之毫厘谬以千里。

后来我改成“先合成音频，再读取真实音频时长，最后把时长写入 props”。读取音频时长用ffprobe就能完成。一切以真实文件时长为准，音画同步问题就再也没出现过。

5.2 API 偶发超时与素材字体问题

第二个高频事故是上游 API 超时。这不是某一个服务商的问题，而是所有在线调用都可能遇到的通病。我的应对策略上面已经提过，重试 + 缓存 + 跳过。这里补充一个细节：缓存文件要带日期，否则第二天跑的时候会因为命中旧缓存而出错。

第三个事故是字体。Remotion 默认字体对中文支持不完整，我第一次渲染出来的字幕全是方框。解决方式很直接：在模板里显式加载中文字体文件，并且把字体文件放在本地项目目录，而不是依赖网络资源。网络资源在渲染机上有加载延迟，第一次渲染时很容易出现“第一帧没有字体”的现象。

5.3 问题速查表：自动化视频常见故障一览

我把这段时间遭遇的问题整理成一份速查表，方便你直接对照排查。

上面这张表基本覆盖了我经历过的大部分故障场景。自动化流程有一个不变的规律：出问题的地方永远是边界条件，而边界条件需要靠时间喂出来。跑得越久，你会越理解这句话。

最后再讲一点个人体会。刚开始我把这套系统当成“偷懒工具”，后来发现它真正改变的是我的工作方式：以前我坐在剪辑软件前，是被迫的；现在我写脚本、调模板、优化 Prompt，是主动的。每天早上的那条视频，成了我检查流水线是否健康的信号。如果你也想照着搭一套，我的建议是从最小闭环开始：先手动跑通一遍再谈全自动，等所有环节都稳定了，再把定时的最后一步接上。这样即使出问题，你也知道该去哪一环节排查。