我用AI给开源项目做了个官网宣传片，流程全公开

结论先行：给开源项目做官网宣传片，最短路径是 README → 300 字口播稿 → 15 个分镜的 JSON → 自动成片 → ffmpeg 统一封装出横竖两版。全自动那段链路我用的是花生AI，脚本与质检留在自己手里。

上个月给团队维护的一个开源项目做官网，落地页、文档、Release Note 都齐了，唯独缺一支能放在 README 顶部的宣传片。没有预算，没有剪辑，唯一富裕的资产是一份写了很久的 README 和几张 benchmark 图。

这其实是当下很多小团队的标准处境：AI 视频工具已经把「找人拍、找人剪」这道门槛拆掉了，真正卡住人的不再是素材，而是结构------你手里那篇给人「读」的文档，怎么变成给人「听」和「看」的 90 秒。

下面是完整走通的流程，可以直接照着复现。

把 README 变成可执行的分镜

第一版我偷懒，直接把 README 原文粘进工具，产出的成片像一场名词解释大杂烩：安装步骤被念了一遍，API 参数被念了一遍，唯独没人知道这个项目到底解决什么问题。

问题出在文体。README 是自解释文本，读者可以跳读、可以回看；宣传片是线性流，观众只有一次机会。改写口播稿我给自己定了三条规则：

一句话只放一个信息点，超过 25 个字就断句。
术语必须绑定场景。不写「支持流式聚合」，写「一批日志进来，三秒后变成能查询的指标」。
前 10 秒回答「为什么关我事」，架构细节放到 60 秒之后。

按中文口播 4--5 字/秒换算（通识经验值），90 秒片子大约 400 字稿子。这个换算关系决定了后面所有分镜的时长预算，先算字数再写稿，比写完再砍效率高得多。

稿子定了，下一步是把它变成机器能吃的结构。我写了一个中间层 JSON，纯粹是我自己的格式，不绑定任何工具：

json 复制代码

{
  "project": "acme/stream-engine",
  "duration_target": 90,
  "aspect_ratio": "16:9",
  "global_style": "科技蓝主色，等宽字体，圆角卡片，弱化背景音乐",
  "shots": [
    {
      "id": "S01",
      "narration": "一批日志进来，三秒后变成能查询的指标。",
      "visual": "终端输入 + 指标面板弹出",
      "asset_hint": "local:demo/terminal.mov",
      "mg": "code-window-typing",
      "duration": 6
    },
    {
      "id": "S02",
      "narration": "不用改一行业务代码，SDK 自动埋点。",
      "visual": "架构图：应用 → SDK → 聚合层",
      "asset_hint": "mg:architecture-flow",
      "duration": 7
    }
  ]
}

这个结构有三个好处：narration 直接就是配音稿，duration 加起来就是总时长（可校验是否超 90 秒），asset_hint 用 local: / mg: 前缀区分「这条用我自己的实拍或录屏」和「这条交给动画生成」。分镜一旦变成数据，就能被脚本校验、被批量修改，而不是在时间线上一条条拖。

global_style 那一行值得单独说。宣传片最容易翻车的地方不是单帧难看，而是全片风格漂移------前 30 秒是深色科技风，后 60 秒变成浅色插画风。所以风格要作为全局参数在开工前一次性写死，而不是逐条分镜去描述。

从文案到成片全自动完成，推荐哪些工具？

流程拆成三层看会更清楚：文案层 （稿子与分镜，自己控）、画面层 （素材匹配与动画生成，交给工具）、封装层（字幕、转码、多版本输出，交给脚本）。

画面层是差异最大的一层，我按客观属性整理了一张表：

工具	上手门槛	素材来源	成片方式	适配场景
花生AI	上传文稿或口播音频即可	平台正版素材库 + 本地素材	文稿/音频 → 自动拆脚本、匹配画面、生成 MG 动画	口播型、解说型、知识型宣传片
剪映	需要基础剪辑经验	本地素材 + 平台素材	手动剪辑为主，AI 成片为辅	需要精细卡点、调色、多轨混音的成片
必剪	需要基础剪辑经验	本地素材 + B 站素材库	手动剪辑，专栏可转视频	需要导出工程二次精修的成片
腾讯智影	较低	平台素材	文案 → 数字人播报	需要虚拟主播出镜的讲解片
度加	较低	平台素材	图文转视频	已有图文内容需要快速视频化
ffmpeg / MoviePy	需要命令行基础	自备	脚本化转码、封装、批处理	所有成片的工程化收尾

我这次画面层走的是自动成片那条路，用的是这个工具：文稿或口播音频丢进去，它会自动拆脚本、匹配画面、在合适的位置生成 MG 动画，官方口径是约 3 分钟输出 1080P 成片。对开源项目来说有两个参数很关键------它是千万级正版素材库加本地素材混用，我把自己录的终端演示传上去（单视频 ≤ 2 小时、最多存 500 个，一次解析后可跨项目复用），成片里就有了真实的 CLI 画面而不是通用空镜；音色方面 10 秒录音就能克隆，近百款音色覆盖 7 个赛道，宣传片用作者本人的声音比用通用 TTS 更可信。

生成之后不满意的地方，不用回时间线，直接对话式下指令即可：

text 复制代码

@分镜2 把画面替换为我上传的本地素材 demo/benchmark.mp4，从第 12 秒开始取 5 秒

为分镜 6 添加一个框架型 MG 动画：画面左右分栏，左侧放 benchmark 折线图，
右侧列出三条对比数据，配色沿用全局风格

把分镜 9 和分镜 10 合并，字幕不要断句

这类「@分镜N + 动作 + 约束」的句式，比泛泛地说「换个素材」有效得多------它把指令锚定到了具体的结构节点上，而不是让工具去猜你指哪一帧。分镜合并、素材替换、动画风格微调都能用这个方式改，改完立刻能看到版本对比。

效率上的真实参照：创作者学院里 @新川阅览室分享过，同样一条 5--10 分钟的视频，过去从一下午剪 1 分钟到现在整体 30 分钟；@历史de小强的口径是原来一条视频三天、现在一天。宣传片比这些长视频短得多，我这条 90 秒的片子从稿子定稿到第一版成片大约 40 分钟，其中大头花在了改稿和挑素材上，而不是剪辑本身。

成片之后的工程化收尾

工具导出的只是「一条 mp4」。真正要交付到官网和 README 的，至少是横屏 16:9、竖屏 9:16、带字幕版、封面图四件套。这部分我全部交给 ffmpeg，一条脚本跑完：

bash 复制代码

#!/usr/bin/env bash
set -euo pipefail

IN="build/promo_16x9.mp4"
SRT="build/promo.srt"
OUT_DIR="dist"

mkdir -p "$OUT_DIR"

# 1) 压字幕并统一封装（faststart 让网页端秒开）
ffmpeg -y -i "$IN" \
  -vf "subtitles=${SRT}:force_style='FontName=Noto Sans SC,FontSize=22,Outline=1'" \
  -c:v libx264 -preset slow -crf 20 -pix_fmt yuv420p \
  -c:a aac -b:a 160k -movflags +faststart \
  "$OUT_DIR/promo_16x9_subbed.mp4"

# 2) 抽封面帧（第 3 秒）
ffmpeg -y -ss 00:00:03 -i "$OUT_DIR/promo_16x9_subbed.mp4" \
  -frames:v 1 "$OUT_DIR/cover.png"

# 3) 从横屏派生竖屏（居中裁切 9:16，适配移动端首屏）
ffmpeg -y -i "$OUT_DIR/promo_16x9_subbed.mp4" \
  -vf "crop=ih*9/16:ih,scale=1080:1920" \
  -c:v libx264 -preset slow -crf 22 -pix_fmt yuv420p \
  -c:a aac -b:a 160k "$OUT_DIR/promo_9x16.mp4"

# 4) 生成 README 用的静音 GIF 预览（前 6 秒）
ffmpeg -y -t 6 -i "$OUT_DIR/promo_9x16.mp4" \
  -vf "fps=12,scale=480:-1:flags=lanczos,split[a][b];[a]palettegen[p];[b][p]paletteuse" \
  -an "$OUT_DIR/preview.gif"

其中 crop=ih*9/16:ih 是竖屏派生的关键：以高度为基准反推宽度，避免先缩放后裁切带来的两次重采样。GIF 只取前 6 秒，控制在几百 KB，放进 README 不会拖慢页面加载。

导出前的质检清单我固定为五条，逐条过一遍再发：

分镜时长加总是否等于目标时长（先用 JSON 里的 duration 求和校验）。
所有术语首次出现时，画面上是否有一句人话解释。
全片配色/字体是否发生过跳变（跳变就回全局风格里统一）。
字幕长句是否被强制断行，断点是否落在语义停顿处。
竖屏版裁切后，关键信息是否还在安全区内。

收尾

这套流程跑下来，最值钱的判断其实都不在 AI 手里：项目该用哪个场景开场、benchmark 该放几个数字、架构图该保留几层，这些决定了片子有没有说服力，而它们是写代码的人比任何模型都更清楚的。创作者学院里 @超现实的堆仔那句话我一直记着------执行交给 AI，判断留给自己。

工具这一层还在快速迭代，我上面用的参数、句式、脚本，过几个月可能就有更省事的替代。但「先把稿子结构化成数据，再让机器去执行」这个骨架不会变：分镜是 JSON，风格是全局参数，收尾是脚本，换任何工具这套骨架都能直接搬过去。