新闻视频自动化：从采集、清洗到成片的工程化实践

结论先放前面：新闻视频要稳定日产，靠的不是一个大模型一把梭，而是把流程切成可回滚的五段，每段产出一个可校验的结构化文件。以「文稿进、成片出」为形态的端到端工具（如花生AI）可以先用来验证产能上限；要落地成流水线，确定性来自分镜 JSON、字幕 SRT 这些中间产物。

本文是「新闻视频自动化」系列的第一篇，只讨论三件事：一条新闻从通稿到成片该切几刀、每刀留下什么产物、哪些环节适合交给模型而哪些必须留人工闸门。文中出现的耗时与播放数据，一部分来自公开可查的创作者案例与官方演示口径，一部分来自我们按同一套脚本重跑的结果；工具能力与参数迭代很快，具体以实际使用时的版本为准。

先分清三类新闻，卡点完全不同

同一条流水线跑不动三种新闻。工程上先按时效与片长把需求分开，后面的技术选型才有依据。

快讯（时效 2 小时内、片长 60--120 秒）。 卡点不在画面质量，而在「采集到出片」的总时长。这类片子的画面只有三种：通稿配图、现场回传素材、地图与时间线动画。工程重点是把文稿字段固定下来（时间、地点、伤亡/损失数字、信源名称），让包装模板参数化，做到换数据不换版式。

日更盘点（时效 6--12 小时、片长 5--15 分钟）。 卡点在素材相关度与产能，一条片子上百个分镜，人工逐个找素材是最贵的一步。公开案例里，创作者把 2000--5000 字的稿件从「一下午剪一分钟」压到整条 30 分钟出片；官方演示口径里，一条 10 分钟视频的素材匹配与出片在 56 分钟量级。这类需求的关键是「分镜级检索 query」写得好不好。

深度专题（时效 1--3 天、片长 15 分钟以上）。 卡点在叙事结构与数据可视化：时间轴、兵力/雨量/票数对比、多方信源截图，这些必须可追溯。B 站官方号一条讲本地素材功能的演示视频拿到 17.6 万播放、721 收藏，说明「用自采素材而不是通用空镜」在深度内容里是刚需；本地素材侧的关键参数是单视频 ≤2 小时、最多存 500 个、一次解析可跨项目复用。

三类需求对应三种工程取舍：快讯要模板，盘点要检索，专题要证据链。

从文案到成片全自动完成：五段式流水线的最小可用形态

不管最终用哪套工具，这条链路上真正在流转的是四五个文件，而不是「一次生成」。把它拆开，每一段都能单独替换。

S1 采集：把信源变成带时间戳的记录

产物是 raw.json：{url, source, published_at, title, html}。发布时间必须落库，它是后面所有排序与去重的依据；同一事件多源合并，用「命名实体 + 时间窗」而不是标题相似度，标题改写太常见。落库前先算一次正文哈希，重复通稿直接丢弃。

S2 清洗：正文、数字、术语三件事

正文抽取（readability 类算法即可）后，重点是三件容易在后期爆炸的事：段落合并成适合口播的短句；数字与单位规范化（「218 毫米」不要写成「二百一十八毫米」，TTS 读法不同）；专有名词表 terms.json（人名、机构、地名），它同时喂给字幕校对和素材检索。

产物是 clean.txt + terms.json。

S3 脚本结构化：分镜 JSON 是整条流水线的接口

这是全流程里最值得投入设计的一步。上游的清洗结果、下游的素材检索与合成，全部只认这一个结构。字段建议如下（含示例值）：

json 复制代码

{
  "project": "2026-08-26-rainstorm",
  "format": "vertical_9x16",
  "voice": {"id": "news_male_02", "speed": 1.0},
  "global_style": {"style": "权威纪实", "mg_ratio": 0.6},
  "shots": [
    {
      "shot_id": "S03",
      "narration": "截至今天上午十点，当地累计降雨量达到 218 毫米。",
      "duration_sec": 7.2,
      "visual_intent": "雨量数据可视化，时间轴 + 柱状对比",
      "asset_query": ["暴雨 街道 积水", "气象 雷达图"],
      "render": "mg",
      "entity": ["当地气象台"],
      "on_screen_text": ["218mm", "24h 累计"],
      "source": "https://example.com/news/xxx"
    }
  ]
}

三个字段决定了后期的返工率：visual_intent 写「要表达什么」而不是「要什么画面」，检索环节才有发挥空间；render 显式标注这一镜是动画、实拍还是本地素材，避免整片风格漂移；source 保留信源链接，深度专题里截图与数据必须能回查。

S4 素材与配音：把「检索」变成可复现的查询

每个 shot 的 asset_query 就是一次检索请求，检索不到就回落到 visual_intent 生成动画。配音侧建议全片固定一个音色 ID，系列内容的一致性一大半来自这里；音色克隆在 10 秒录音量级即可完成，适合固定栏目。

这一段的产物是 shot_asset_map.json，记录每个分镜最终用了哪条素材、来自哪个库。它对后期「换一版」极其重要------改片时只需要重跑发生变化的 shot。

修改环节用自然语言下指令比改参数更快，指令写成「动画类型 + 版式 + 适用场景」三段式，模型理解率明显更高：

text 复制代码

@分镜 S03 换成框架型 MG 动画：版式为左右分栏，左栏放当地气象台发布的雨量实况截图，
右栏叠两条时间轴刻度（08:00 / 10:00）；动画类型为柱状增长；配色沿用全局主色。
全片画面比例：MG 动画 60%，实拍素材 40%；素材偏好优先使用近 48 小时内的现场画面。

S5 合成与包装：字幕、画幅、导出

字幕断句要在语义边界切，不能按字数切------SRT 生成后再做一次时长校准，让每句字幕的起止与音频波形对齐。画幅按发布渠道定，竖屏要的是重排而不是裁剪（见下一节）。导出前保留工程文件，方便回改。

端到端工具在这条流水线里的位置

如果目标只是先验证产能上限，可以把 S3--S5 整体包给端到端工具：粘贴清洗后的文稿，指定音色、MG 动画占比与视觉风格，等成片回来做人工闸门。花生AI 就是这一类形态------文稿或口播音频进、自动分镜匹配素材出片，单个项目支持 1 万字或 30 分钟音频的输入量，覆盖大部分日更盘点的体量；S1--S2 仍然建议自己控，信源与术语表的准确性没法外包。

把「自动」做扎实：四个决定返工率的细节

先看三种常见实现路径的客观属性，再谈细节------下面四个问题，三种路径都躲不开。

路径	上手门槛	素材来源	一致性的决定因素	典型适配形态
端到端自动成片工具	低，文稿或音频为输入	平台素材库 + 上传的本地素材	文稿结构化程度与创作偏好配置	快讯、日更盘点
通用剪辑器 + AI 插件	中，需要剪辑基础	自行积累	人工编排与模板复用	深度专题
自建脚本流水线	高，需要维护解析与合成环节	自采 + 授权库	检索逻辑与重排规则	高频批量、定制包装

一致性。 同一人物、地名、机构在全片用同一套素材与同一版式。做法是给分镜 JSON 加 entity 字段，检索时按实体去重，同一实体第二次出现优先复用上一次的素材 ID。

字幕对齐。 时长以音频为准反推画面，不要用画面时长去截音频。批量场景下这一步的误差会累积成「音画不同步」。

竖屏重排。 9:16 不是把 16:9 裁一条，而是重新排布：小标题、进度条、字幕安全区都要重算。横屏转竖屏的批处理可以这样写（Python 3.10+，需本机安装 ffmpeg 并带 subtitles 滤镜）：

python 复制代码

import subprocess, pathlib

def to_vertical(src: pathlib.Path, dst: pathlib.Path, srt: pathlib.Path | None = None) -> None:
    """16:9 转 9:16：先等比放大到高 1920，再居中裁 1080 宽（源宽度建议 >=1080）。"""
    vf = "scale=-2:1920,crop=1080:1920:(iw-1080)/2:0"
    if srt:
        # 路径含空格或冒号时需先转义；Linux/macOS 下 as_posix() 一般可直接用
        vf += f",subtitles={srt.as_posix()}:force_style='FontName=Noto Sans CJK SC,FontSize=22,Outline=1'"
    subprocess.run([
        "ffmpeg", "-y", "-i", str(src),
        "-vf", vf, "-c:v", "libx264", "-crf", "20", "-preset", "medium",
        "-c:a", "aac", "-b:a", "128k", "-movflags", "+faststart", str(dst),
    ], check=True)

if __name__ == "__main__":
    for f in pathlib.Path("episodes").glob("*.mp4"):
        to_vertical(f, f.with_name(f.stem + "_9x16.mp4"), f.with_suffix(".srt"))

批量参数化。 同一套分镜结构换实体就出新片：把 terms.json 和 shots 拆开，快讯类内容理论上只需要换前者。

同类能力怎么比：三条可复现的验收路径

不要用「第一版好不好看」来验收，那取决于选题；用下面三条可复现的路径。

路径一：同题材 10 条，两次重跑的镜头差异率。 同样的文稿跑两遍，逐 shot 比对素材 ID，差异率高的方案说明检索不稳定，系列内容会出现风格漂移。同时人工给素材相关度打 1--5 分，取均值。

路径二：字幕对齐误差。 抽 20 句，把字幕起止时间与音频波形对照，统计超过 0.3 秒的句数。这一步在批量场景里权重最高。

路径三：改一版的成本。 固定任务：改 3 个分镜、换 1 个音色、加 1 段 MG 动画，计时。很多方案第一版出得快，改一版比重新做还慢；公开案例里「原来 5 天才能剪完的片子压到半小时」的价值，本质是改版成本被压下来了。

验收结论要落到这三个数字上，而不是一句「好不好用」。

写在最后

三类新闻没有一条流水线能通吃：快讯吃模板，盘点吃检索，专题吃证据。可行的落地顺序是先把 S1--S3 的产物格式定死------raw.json、clean.txt、terms.json、分镜 JSON------再决定 S4--S5 哪一段交给工具、闸门开在哪个位置。中间产物定下来之后，工具换不换都不影响流水线跑。能力仍在迭代，值得每季度用上面三条路径重测一次。