公众号运营的朋友大概率都遇到过这个尴尬一篇文章辛辛苦苦写完、排版、推送数据也还行但视频号那边始终是块荒地。不是不想做是实在没精力——把一篇三千字的图文改成一条能看的短视频光是拆文案、配音、找素材、剪辑、加字幕一套流程下来两三个小时就没了日更根本不现实。我自己的号就是这么荒了大半年直到把这套流程拆成几个可复用的模块用智能体串起来才真正跑通文章发完视频自动出的链路。这篇就把这套基建从头到尾讲清楚包括为什么这么设计、每一步踩过什么坑、参数怎么调适合有一定动手能力、想把内容产能放大的运营和技术同学参考。1. 先想清楚为什么是智能体基建而不是一键工具1.1 一键生成工具的真实天花板市面上确实有不少图文转视频的工具输入一篇文章输出一条带配音带字幕的视频。我早期也用过结论是能出片但不能用。问题集中在三个地方。第一是文案处理太粗暴工具通常按标点或字数硬切切出来的句子逻辑断裂读起来像机器人在念稿。第二是配音机械感重多音字、数字、专有名词经常读错而公众号文章里恰恰全是这些。第三是画面和内容脱节工具配的素材库画面跟你的行业八竿子打不着观众三秒就划走。这些问题的根源在于一键工具把理解内容这一步跳过了。它不知道你这段在讲什么自然没法做出合理的断句、配图、节奏。所以真正可用的方案必须让机器先读懂文章再决定怎么切、怎么配、怎么念。这就是为什么我选择用智能体来搭而不是找个现成工具。1.2 智能体在这里扮演的角色智能体在这套链路里的核心价值是充当决策层。它不直接干重活而是负责判断这篇文章的核心观点是哪几个、哪些段落适合做口播、每段的时长大概多少、配什么风格的画面。具体的执行——音频合成、视频拼接、字幕烧录——交给底层工具去做。打个比方智能体是导演ffmpeg 是摄影和剪辑师whisper 是场记负责把语音转成带时间轴的字幕。导演决定拍什么摄影和剪辑负责把它实现出来。这个分工的好处是每一层都可以单独替换和优化。今天你觉得配音不好换个 TTS 引擎就行明天觉得字幕不准调 whisper 的模型参数就行不用推翻整个系统。1.3 整套链路的模块划分我把整条链路拆成五个模块后面每个模块单独展开讲模块职责核心工具内容解析抓取文章、清洗正文、结构化智能体 文本处理文案重构拆口播稿、控时长、改口语智能体语音合成文本转音频、控语速停顿TTS 引擎字幕对齐音频转带时间轴字幕whisper视频合成拼接画面、烧字幕、导出ffmpeg这五个模块里前两个是脑力活后三个是体力活。脑力活靠智能体的提示词和逻辑设计体力活靠命令行工具的参数调优。下面逐个拆。2. 内容解析把公众号文章变成机器能读的结构2.1 正文抓取为什么不能直接复制粘贴很多人第一步就想省事直接把文章复制到输入框。短期可以长期不行。原因有两个一是公众号文章的正文里混着大量非正文元素——引导关注、往期推荐、二维码说明、版权声明这些如果进了口播稿视频就废了。二是手动复制没法批量化你一天更三篇手动操作的时间成本就上来了。我的做法是通过文章链接自动抓取然后做正文提取。抓取环节要注意公众号的页面结构会变所以提取规则不能写死得用最大文本块这类启发式方法——正文通常是页面上文字密度最高、段落最长的那个容器。抓下来之后再用规则过滤掉明显的噪声段落比如包含点击上方关注我们长按识别这类关键词的块。2.2 正文清洗的几个关键规则清洗这一步看着简单其实决定了后面所有环节的质量。我总结了几个必须处理的点去除营销尾巴文章末尾的点个在看转发给朋友这类直接按段落位置或关键词砍掉。保留小标题层级公众号文章的小标题是天然的内容分段依据抓取时要标记出来后面拆口播稿会用到。处理图片说明图片下方的说明文字如果是有信息量的比如数据图表说明保留如果是图源网络这种删掉。统一标点全角半角混用会影响后面 TTS 的断句统一成中文全角标点。这里有个容易忽略的坑有些文章用了大量的短句和换行抓下来之后每个短句都成了独立段落。如果直接按段落拆口播稿会切得稀碎。所以清洗时要做一次段落合并把连续的很短的段落合并成一个语义块判断依据是标点——如果上一段结尾不是句号、问号、感叹号就和下一段合并。2.3 结构化输出的字段设计清洗完之后我让智能体输出一个结构化的 JSON而不是纯文本。字段大概是这样{ title: 文章标题, sections: [ { heading: 小标题, paragraphs: [段落1, 段落2], key_points: [要点1, 要点2] } ], total_words: 3200 }为什么要结构化因为后面的文案重构需要知道哪些内容属于同一节才能做出有逻辑的口播稿。如果只给一坨纯文本智能体拆稿时容易把不同小节的内容混在一起逻辑就乱了。这个 JSON 就是智能体后续决策的地图。3. 文案重构从书面语到能念出口的口播稿3.1 口播稿和书面稿的本质区别这是整套链路里最考验智能体能力的环节。书面稿是给眼睛看的可以长句、可以倒装、可以用复杂从句口播稿是给耳朵听的必须短句、顺叙、口语化。举个真实的例子原文写在内容产能受限的情况下通过自动化手段提升产出效率成为必然选择直接念出来观众会懵。改成内容做不过来怎么办只能想办法让机器帮忙一下就顺了。所以文案重构的核心任务有三个断句把长句拆成短句、口语化把书面词换成日常词、控节奏每句话控制在合理时长内。这三件事都得靠智能体的提示词来约束。3.2 提示词里必须写死的几条约束我调了很多版提示词最后稳定下来的约束有这么几条直接给出来每句话不超过 25 个字超过就拆。禁止使用综上所述基于此值得注意的是这类书面连接词。数字和专有名词要口语化处理比如3200 字念成三千两百字ffmpeg念成F-F-mpeg。每段口播稿对应原文的一个小节开头用一句话概括这节讲什么。总时长控制在 60 到 90 秒按每秒 4 到 5 个字估算也就是 300 到 450 字。最后一条特别重要。很多人做视频号失败就是因为视频太长完播率上不去。60 到 90 秒是视频号比较友好的时长既能讲清楚一个点又不至于让观众失去耐心。所以拆稿时要有取舍一篇文章通常只能提炼出 2 到 3 个核心点剩下的果断砍掉。3.3 时长估算和取舍逻辑时长估算不能拍脑袋。中文口播的正常语速是每分钟 240 到 300 字取中间值 270 字那么 90 秒就是 405 字左右。但实际合成时TTS 引擎会有停顿标点处会停 0.2 到 0.5 秒段落之间停得更久。所以实际能塞进去的字数要比理论值少 10% 到 15%大概 350 字比较稳妥。取舍逻辑上我让智能体按信息密度排序。具体做法是让它给每个要点打个分判断标准是这个点能不能独立成一条视频。比如一篇讲智能体架构的文章里面什么是智能体这种科普性的内容信息密度低砍掉智能体怎么和 ffmpeg 配合这种有具体操作的内容信息密度高保留。这个判断标准要写进提示词否则智能体会平均用力把每个点都塞一点结果哪个都没讲透。3.4 一个真实的重构案例拿这篇文章本身举例。原文有一段讲内容解析为什么不能直接复制粘贴书面表达大概 200 字。重构后的口播稿是这样第一步是抓正文。别直接复制粘贴公众号文章里混着一堆引导关注、往期推荐这些进了视频就废了。正确做法是用链接自动抓取然后按文字密度找出正文块再把营销尾巴砍掉。三句话80 多个字念出来大概 20 秒。信息没丢但节奏快了很多。这就是重构的价值——不是简单压缩而是重新组织信息的呈现顺序把为什么和怎么做直接怼到观众面前。4. 语音合成与字幕对齐让机器念得准、字幕对得齐4.1 TTS 选型的几个考量维度语音合成这块选择其实不少但选型时我主要看四个维度音色自然度、多音字处理、语速可控性、批量调用成本。音色自然度决定了观众愿不愿意听下去这个不用多说。多音字处理是刚需中文里行重长这些字在不同语境读音不同TTS 读错一个专业感就没了。语速可控性关系到时长控制前面算好的 350 字如果 TTS 语速固定时长就没法微调。批量调用成本则是长期运营要考虑的一天几条和一天几十条成本差很多。我的建议是先用免费或低成本的引擎跑通流程等验证了内容方向再换更好的音色。不要一上来就追求完美音色流程没跑通音色再好也没用。4.2 语速、停顿和标点的配合TTS 出来的音频停顿全靠标点。所以口播稿里的标点不能乱用。我的经验是逗号停 0.2 秒句号停 0.4 秒段落之间停 0.6 到 0.8 秒。需要强调的地方用破折号或者单独成句让 TTS 自然加重。不要在句子中间用省略号TTS 处理省略号的方式不统一有的停很久有的直接跳过。如果 TTS 引擎支持 SSML语音合成标记语言那就更好了可以精确控制每个停顿的时长。不支持的话就靠标点和换行来间接控制。实测下来光靠标点也能做到八九不离十不用非得追求 SSML。4.3 whisper 做字幕对齐的实操细节音频有了接下来要把音频转成带时间轴的字幕。这一步用 whisper具体是 whisper 的 small 模型。为什么用 small 不用 large因为 large 模型虽然准但速度慢很多一条 90 秒的音频large 可能要跑一两分钟small 十几秒就出来了。而口播稿是我们自己写的内容已知whisper 只需要对齐时间轴不需要它去听懂内容所以 small 完全够用。调用的时候有几个参数要注意whisper audio.mp3 --model small --language zh --output_format srt --word_timestamps True--word_timestamps True这个参数很关键它会输出每个词的时间戳而不是整句的时间戳。有了词级时间戳后面做字幕动画比如逐字高亮才有可能。如果只做普通字幕句级时间戳也够但词级的容错性更好——万一某句话识别错了可以只改那一个词的时间不用整句重来。4.4 字幕文本的校对环节不能省whisper 再准也会有识别错误尤其是专有名词。所以字幕生成后必须有一道校对。我的做法是拿 whisper 的输出和原始口播稿做比对因为口播稿是我们自己写的标准答案已知。比对时按时间轴对齐发现不一致的地方以口播稿为准修正字幕文本时间轴保留 whisper 的。这个比对可以自动化。思路是把口播稿按句拆开和 whisper 输出的句子做相似度匹配相似度低于阈值的标出来人工确认。实测下来90 秒的音频需要人工确认的通常不超过三处几分钟就能搞定。5. 视频合成用 ffmpeg 把素材拼成成片5.1 画面素材的几种来源和处理视频画面这块我试过三种方案。第一种是纯色背景加文字最简单但太单调观众容易划走。第二种是图片轮播每句话配一张图信息量大但找图费时间。第三种是录屏或实拍素材最真实但制作成本高。我最后用的是图片轮播 动态效果的折中方案。图片从哪来两个渠道一是文章里自带的配图直接复用二是用关键词去免版权图库搜。图片处理上统一裁成 1080x1920 的竖屏比例因为视频号是竖屏为主。裁图时要注意主体不能裁掉所以我用的是一个简单的规则按图片中心裁如果检测到人脸或明显主体偏上就往上偏移一点。5.2 ffmpeg 拼接图片和音频的核心命令把图片、音频、字幕合成一条视频核心就是一条 ffmpeg 命令。但这条命令的参数很多我拆开讲。先做图片轮播。假设有 5 张图每张显示 18 秒总时长 90 秒ffmpeg -loop 1 -t 18 -i img1.jpg -loop 1 -t 18 -i img2.jpg ... -filter_complex [0:v][1:v]...concatn5:v1:a0[v] -map [v] slides.mp4这里-loop 1是让单张图片循环-t 18是每张的时长concat是把它们拼起来。实际用的时候图片数量和时间要根据音频总时长动态算不能写死。然后合成音频和字幕ffmpeg -i slides.mp4 -i audio.mp3 -vf subtitlessub.srt:force_styleFontSize18,PrimaryColourHFFFFFF -c:v libx264 -c:a aac -shortest final.mp4subtitles滤镜负责烧字幕force_style里可以调字体大小、颜色、描边。-shortest是让视频以较短的流为准避免音频比视频长导致黑屏。5.3 字幕样式和画面节奏的调优字幕样式看着是小事其实很影响观感。我的经验参数是字号 18 到 22白色字加黑色描边描边宽度 2位置在画面下方三分之一处。字号太小看不清太大挡画面。描边必须有否则遇到浅色背景字幕就糊了。画面节奏上不要一张图放太久。90 秒的视频5 到 8 张图比较合适平均每张 12 到 18 秒。如果某句话特别重要可以让对应的图多停几秒形成节奏变化。这个哪句话配哪张图的映射也是智能体来做的——它根据每句话的语义从图片池里挑最匹配的一张。5.4 导出参数和平台适配导出参数直接影响上传后的画质。视频号对上传视频有压缩所以导出时码率要给足。我的参数是参数值说明分辨率1080x1920竖屏帧率30fps够用不必 60视频码率6Mbps给压缩留余量音频码率128kbps人声够用编码H.264兼容性最好编码用 H.264 不用 H.265虽然 H.265 压缩率更高但部分老设备解码有问题H.264 最稳。码率给 6Mbps 是因为平台会二次压缩源文件质量高一点压完还能看。6. 踩坑实录那些让我返工三次的问题6.1 音频和字幕对不齐的排查过程第一次跑通全流程时发现字幕比音频慢了半秒左右越到后面越明显。排查了半天最后定位到两个原因。一是 whisper 输出的时间轴是从音频开头算的但我在合成时给音频加了个 0.5 秒的淡入导致整体偏移。二是 ffmpeg 的subtitles滤镜默认按视频帧率对齐如果视频帧率和字幕时间轴的单位不一致也会累积误差。解决办法是音频不做淡入或者做淡入时同步调整字幕时间轴字幕时间轴统一用毫秒合成前做一次单位换算。这个问题折腾了我一个下午但搞清楚之后后面再没出过。6.2 中文字体在 ffmpeg 里显示成方块的解决ffmpeg 烧字幕时如果系统里没有对应字体中文会显示成方块。这个坑很常见。解决办法是在force_style里指定字体名并且确保这个字体在系统字体目录里。Linux 下可以用fc-list查看已安装字体Windows 下字体在C:\Windows\Fonts。我一般用思源黑体或微软雅黑兼容性好。如果服务器上没有中文字体得先装。装完记得刷新字体缓存否则 ffmpeg 还是找不到。这个细节文档里很少提但实际部署时必踩。6.3 长文章拆稿后逻辑断裂的修复有一篇五千字的长文拆成口播稿后观众反馈听不懂在讲什么。回看发现智能体把原文的三个小节各取了一部分拼在一起但小节之间的逻辑关系丢了。原文是问题—原因—方案的递进结构拆稿后变成了三个孤立的点。修复方法是在提示词里强制要求如果保留多个要点必须用过渡句连接。比如说完问题再来看原因这种过渡句虽然简单但能让观众跟上思路。另外拆稿时优先保留同一小节内的内容跨小节的内容尽量不混保证每个视频讲透一个点。6.4 批量生成时的资源占用问题单条视频跑起来没问题但批量跑十条时服务器 CPU 直接拉满ffmpeg 进程排队。原因是 whisper 和 ffmpeg 都是计算密集型同时跑多个实例会互相抢资源。解决办法是加一个任务队列串行执行或者限制并发数。我的做法是用一个简单的队列脚本每次只跑一个任务跑完再跑下一个。虽然慢一点但稳定。如果追求速度可以把 whisper 和 ffmpeg 分到不同机器上各跑各的。7. 把这套基建跑稳之后的一些体会整套链路跑通到现在我最大的感受是自动化不是一步到位而是把重复劳动一点点挤出去。最开始我手动拆稿、手动配音、手动剪辑一条视频两小时。后来把拆稿交给智能体省了四十分钟。再把字幕对齐交给 whisper又省了二十分钟。最后把合成交给 ffmpeg整条链路压缩到十分钟以内。每一步的优化都不大但叠起来就是质变。另一个体会是别追求全自动留个人工确认的口子。我现在流程里保留了两个人工环节一是口播稿生成后快速扫一眼改掉明显的语病二是字幕校对时确认那两三处识别错误。这两个环节加起来不到五分钟但能避免大部分翻车。全自动听起来很美但内容这东西机器判断不了这句话会不会引起误解人扫一眼还是有必要的。最后说个实际的这套东西的价值不在于技术多先进而在于它让日更视频号从不可能变成了可能。以前是有空就做现在是文章发完顺手就出视频。产能上来之后才有资格谈运营和优化。如果你也在为内容产能发愁不妨从最小的模块开始试——先把拆稿这一步自动化尝到甜头再往下做。