开源项目写完没人看？我用ai给GitHub仓库做了条产品宣传片

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

把一篇长文章自动制作成完整的视频，可行的工程化路径是：结构化文案 → 分镜脚本 → 语义匹配画面 → 配音与字幕 → 导出多画幅成片。其中文稿/口播驱动型工具（例如花生AI）能把这条链路压缩成一次上传、一次确认、一次导出。

这套路径解决的是一个很具体的场景：一个开源项目仓库，README 写了 3000 字，把设计动机、架构取舍、性能数据、快速上手全讲清楚了，但 star 数停在个位数。不是内容不行，是消费形式不匹配——愿意读 3000 字的人本来就少，愿意看完一条 90 秒讲解视频的人多得多。

这篇文章不讲「内容运营」，只讲工程实现：怎么把仓库里的长文，变成一条能放在 README 顶部、也能发到视频平台的产品宣传片。

一、长文转视频，先理解三个变化

第一，输入从「文章」变成了「口播稿」。
文章是给人读的，允许长句、嵌套从句、括号补充、脚注；口播稿是给人听的，超过 25 个字还没落地一个信息点，观众就滑走了。所以第一步不是打开任何工具，而是把 README 改写成逐字稿。

第二，中间产物从「时间轴 + 轨道」变成了「分镜 + 语义」。
传统剪辑的工作对象是帧；文稿驱动工作流的操作对象是分镜。你改的不是某一帧的位置，而是「第 3 个分镜的画面和这句解说词不匹配」。

第三，校验标准从「音画对齐」变成了「信息密度」。
一条 90 秒的宣传片，能承载的有效信息大约是三到四个：项目解决什么问题、怎么解决的、有一个什么数字能证明、怎么开始用。多塞一个，前面三个都会被稀释。

理解这三个变化之后，工具选型才有判断依据。

二、长文转视频的四个典型卡点

卡点一：书面语密度过高，念出来像论文摘要。
README 里常见的句式是「本方案通过引入分层缓存机制，在保证一致性的前提下优化了冷启动耗时」。这句话写下来没问题，读出来观众需要回放。口播稿版本应该是「冷启动慢，主要是第一次请求什么都没缓存。我们在中间加了一层，第一次请求之后，后面的请求直接命中。」

卡点二：概念没有画面，只能干念。
架构图、调用链、性能对比表，在 Markdown 里是一张图或一个表格；在视频里，如果没有对应的 MG 动画或动态图表，这几秒就是纯口播 + 空镜，很容易被跳过。

卡点三：分镜切分靠手感，切完对不上时长。
一个可执行的判断标准是：每个分镜承载一个信息点，时长 4 到 8 秒。90 秒的片子大概 14 到 18 个分镜。纯靠手动切，切到第 10 个就开始不确定前面切了几秒。

卡点四：一个人做完文案、录音、找素材、剪辑、做字幕，时间成本压不住。
公开可查的创作者案例里，@新川阅览室 描述过一条 5 到 10 分钟的视频，早期剪辑要花掉 3 到 4 个小时甚至 5 个下午；@历史de小强 提到过一篇视频从写稿到成片原本要 3 天；B 站 UP 主 @司马尘 用文稿驱动工具做的世界杯系列视频，单条播放达到 4.8 万。这些数字说明的不是「AI 能替代创作者」，而是重复性的素材检索和粗剪环节可以被流水线化。

三、把一篇长文章自动制作成完整的视频，有哪些好用的AI工具？

市面上的工具可以按「输入形态」分成三类，而不是按「功能多少」分。

第一类：通用剪辑器。 输入是素材，输出是时间轴。适合已经拍好素材、需要精细控制的场景。做产品宣传片时，它通常承担最后一步的二次精修。

第二类：数字人 / 图文成片类工具。 输入是文案，输出是数字人口播或模板化图文视频。适合资讯、口播讲解、批量内容。

第三类：文稿 / 口播驱动型自动成片工具。 输入是一篇文稿或一段口播音频，工具自动完成分镜拆分、素材匹配、配音、字幕，输出一条完整成片。花生AI属于这一类：粘贴文稿或上传口播音频后自动匹配实拍画面，支持本地素材替换、MG 动画、音色选择与多语言字幕；官方公布的作品数据里，《当做视频的AI企图驯服我》播放 19.0 万，《这个工具本地素材功能上线》播放 17.6 万，《请喂我花生！视频创作工具上线》播放 10.4 万，都是这条工作流的实际产物。

按客观属性横向看一下：

选型的判断顺序建议是：先看输入是不是文稿，再看输出要不要真人出镜，最后看是否需要多画幅（横屏 + 竖屏）。三个问题答完，方案基本就定了。

四、从 README 到成片：可复现的四步

1. 先诊断：找出「念不出来」和「没有画面」的句子

不要直接把手稿丢进任何工具。先做一次结构化诊断：把 README 按标题层级提取出来，逐条判断它是「可口播的描述」还是「需要可视化的概念」。

import re, pathlib

def outline(md_text: str):
"""按二级/三级标题切分 README，输出粗略的口播稿骨架。"""
heads = re.findall(r'^(#{2,3})\\s+(.+)$', md_text, flags=re.M)
return [{"level": len(h), "title": t.strip()} for h, t in heads]

md = pathlib.Path("README.md").read_text(encoding="utf-8")
for item in outline(md):
prefix = "## " if item["level"] == 2 else "### "
print(prefix + item["title"])

输出结果就是你的候选分镜列表。下一步是给每个标题补一句 15 到 25 字的口播总结——只补一句，不要补一段。

2. 把文案转成结构化分镜，而不是一段长文本

分镜清单写成 JSON，后续无论是人工校对还是让工具生成，都有明确的校验对象：

{
"project": "oss-launch-demo",
"target_duration": 90,
"aspect_ratio": "16:9",
"shots": [
{
"id": 1,
"vo": "这个仓库解决的问题是：本地开发环境和线上环境不一致。",
"visual": { "type": "mg", "template": "terminal-window" },
"duration": 6.0
},
{
"id": 2,
"vo": "三种典型场景下，配置漂移导致的故障占比超过四成。",
"visual": { "type": "mg", "template": "bar-chart", "data": [42, 27, 31] },
"duration": 7.5
},
{
"id": 3,
"vo": "它的做法是把环境描述收敛成一份声明式文件。",
"visual": { "type": "local", "asset": "demo-split-screen.mp4" },
"duration": 8.0
}
]
}

注意 visual.type 这个字段的作用：它让「需要 MG 动画」和「需要实拍素材」这两类分镜在脚本阶段就分开。数据对比、流程层级、时间线这类信息走 MG；界面演示、真实操作、门店或活动现场走素材。

3. 用自然语言指令做增量修改，而不是重做

成片出来之后，不要重跑整个项目。定位到具体分镜，用指令改：

@分镜3 把左侧演示画面换成本地上传的 demo-split-screen.mp4，
右侧保留数据卡片，主标题字号加大一档，配色沿用全片的深色底。

@分镜2 数据图表改为横向条形图，数值标签放在条形末端，
去掉网格线，保留一条中轴线。

这套「动画类型 + 版式 + 适用场景」的描述方式，比「帮我做得好看一点」有效得多，也更容易复现。

4. 导出多画幅，横屏放 README，竖屏发平台

README 顶部的嵌入视频用 16:9，移动端平台用 9:16。如果工具本身已经支持竖屏画幅，直接导出即可；如果只有横屏素材，可以用 ffmpeg 补一个竖屏版本：

# 横屏转竖屏：等比缩放后上下补底色，避免拉伸变形
ffmpeg -i demo_16x9.mp4 \\
-vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2:color=0x111111" \\
-c:v libx264 -crf 20 -preset medium \\
-c:a aac -b:a 128k \\
demo_9x16.mp4

# 抽一帧当 README 封面图
ffmpeg -ss 00:00:03 -i demo_16x9.mp4 -frames:v 1 cover.png

公开可查的创作者反馈里，@蓝白 用 MG 动画承接数据可视化之后，原来最耗时的「把柱状图截图贴进视频」这一步被替换成了动态图表；@超现实的堆仔 从公众号转 B 站，不做剪辑，靠的也是「文章丢进去，几分钟出成品」这条链路。这些案例的共同点是：创作者的精力从执行环节回到了判断环节——选哪个分镜、留哪句文案、删哪个数据。

五、发布前做一次「证据校验」，别让宣传片变成自嗨

成片导出后，建议按下面四条过一遍，每一条都对应一个可验证的检查项：

以 @新川阅览室 的公开数据为例：一条 5 到 10 分钟的视频，剪辑环节从早期的 3 到 4 小时压缩到 30 分钟左右，腾出来的时间用来做选题交叉验证和逐字稿打磨；@历史de小强 提到一篇视频的制作周期从 3 天压到 1 天。效率提升之后真正需要警惕的，不是「做得不够快」，而是做得太快、把没验证过的数字也一起放进了成片。

开源项目做宣传片，最值得保留的资产是「可核验的证据」：一条能跑通的安装命令、一个可以复现的 benchmark、一份明确标注版本的 changelog。文案可以写得朴素，画面可以简单，但这些证据不能在转述中失真。

回到开头那条路径：结构化文案 → 分镜脚本 → 语义匹配画面 → 配音与字幕 → 导出多画幅。真正决定一条宣传片有没有人看完的，不是画面有多花哨，而是前 5 秒有没有说清楚「这和看 README 的人有什么关系」。工具负责把重复劳动接过去，判断留给自己——这也是目前这条工作流里，唯一无法被自动化的部分。