公众号运营的朋友大概率都遇到过这个尴尬一篇文章写完了排版也调好了但视频号那边还空着。重新剪一条短视频从找素材、配音、加字幕到导出没两个小时下不来。更别提日更的账号每天光这一项就能把人拖垮。我自己的号做了大半年前三个月基本靠手动剪后来实在扛不住就开始琢磨能不能把文章转视频这件事拆成一条自动化流水线——用智能体把文案提取、语音合成、画面匹配、字幕烧录、视频合成这几个环节串起来一键出片。这套东西我前后迭代了四版踩过的坑从ffmpeg参数写错到whisper模型选型翻车再到CDP抓取页面时被反爬拦下来基本都经历了一遍。下面就把这套公众号文章自动生成视频号短视频的智能体基建方案完整拆开讲从整体架构到每个模块的落地细节再到实测中那些文档里不会写的坑尽量说透。适合有一定Python基础、想给自己账号做内容自动化的运营者也适合正在搭智能体工作流、想找一个完整实战案例的开发者。1. 先想清楚文章转视频到底难在哪很多人一上来就想找个一键转换的工具结果发现要么模板丑得没法看要么配音机械得像机器人要么字幕和语音对不上。问题的根源在于这件事本质上不是一个动作而是一条包含多个异构环节的流水线每个环节的技术栈都不一样。1.1 拆解流水线五个环节各自的技术选型我把整条链路拆成五步每一步都有明确的输入输出和候选方案环节输入输出候选方案我的选择文案提取公众号文章URL纯文本段落结构手动复制 / CDP抓取 / 开放接口CDP抓取语音合成文本音频文件时间戳云TTS / 本地TTS / 录音云TTS画面生成段落文本背景视频/图片素材库 / AI生图 / 纯色背景素材库AI生图字幕对齐音频文本SRT字幕whisper / 强制对齐 / 手动whisper视频合成音频画面字幕成片ffmpeg / 剪映 / 专业软件ffmpeg这张表看着简单但每个选择背后都有取舍。比如文案提取为什么不用手动复制因为日更账号一天可能转3-5篇手动复制粘贴加上清理格式一篇就要5分钟一个月就是两个多小时纯浪费。为什么不用开放接口因为不是所有账号都有权限而且接口返回的HTML结构经常变维护成本不比CDP低。1.2 为什么选CDP而不是直接请求接口CDPChrome DevTools Protocol这个词在热词里和SDP、DCP一起出现很多人分不清。简单说CDP是浏览器暴露出来的一套调试协议你可以通过它控制一个真实的浏览器实例——打开页面、点击元素、读取DOM、执行JS。SDP是会话描述协议用在WebRTC里协商媒体流DCP是Digital Cinema Package数字电影打包格式跟这个场景没关系。选CDP的核心原因是它操作的是真实浏览器页面渲染出来的DOM就是最终形态不用去猜接口返回的数据结构。公众号文章的正文在页面里是渲染好的用CDP直接读document.querySelector拿到的就是干净的内容。而且CDP可以复用登录态不用处理cookie和token的过期问题。注意CDP控制浏览器时建议用独立的用户数据目录不要和你日常用的浏览器混在一起否则登录态冲突会导致抓取失败。1.3 智能体在这里扮演什么角色智能体这个词现在被用得很泛我这里说的智能体是指一个能自主编排上述五个环节、根据中间结果做决策的执行体。比如whisper识别出来的文本和原文对不上时智能体要决定是重新识别还是手动修正比如某段文案太长智能体要决定是拆成两屏还是一屏放完。用平台搭建的智能体和用Python搭建的智能体有什么不一样平台智能体比如扣子、dify这类优势是可视化编排、上手快但涉及ffmpeg这种底层命令调用、whisper这种本地模型推理时平台的能力边界就出来了。我的方案是混合用Python写核心处理逻辑用智能体框架做任务调度和异常决策。这样既有灵活性又能享受智能体的编排能力。2. 文案提取用CDP把公众号文章读下来这一步的目标很明确给一个文章URL拿到结构化的正文内容——标题、段落、小标题、图片位置。听起来简单但公众号页面的DOM结构有不少坑。2.1 CDP环境搭建与浏览器接管先装依赖。Python这边用websocket-client或者pychrome来跟CDP通信但我更推荐直接用playwright它底层就是CDP但封装了连接管理、等待、选择器等常用能力省得自己处理WebSocket心跳。pip install playwright playwright install chromium启动浏览器时关键参数是--remote-debugging-port指定一个端口让CDP能连上from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch( headlessFalse, args[--remote-debugging-port9222] ) context browser.new_context( user_data_dir./user_data # 独立数据目录保留登录态 ) page context.new_page() page.goto(https://mp.weixin.qq.com/s/xxxxx)headlessFalse是有意为之。公众号对无头浏览器有一定识别用有头模式加上真实的用户数据目录被抓取的概率低很多。实测下来headless模式大概十次有三四次会触发验证有头模式基本稳定。2.2 正文DOM的定位与清洗公众号文章的正文容器id是js_content这个相对稳定。但里面的结构不统一有的段落是p有的是section小标题可能是h2也可能是加粗的span。我的做法是先拿整个容器的innerText再按换行切分然后做规则清洗。content page.eval_on_selector(#js_content, el el.innerText) paragraphs [p.strip() for p in content.split(\n) if p.strip()]清洗规则包括去掉点击上方蓝字关注我们这类固定话术、去掉图片占位符、合并被错误换行拆开的句子。这里有个经验公众号编辑器里手动换行和自动换行在DOM里表现不一样手动换行会产生br自动换行只是文本折行。用innerText拿到的结果里手动换行会变成\n自动换行不会。所以按\n切分基本能还原作者的段落意图。2.3 图片提取与后续使用文章里的图片要单独提取出来因为视频里可以用作画面素材。图片的src通常在img标签的>images page.eval_on_selector_all( #js_content img, els els.map(el el.getAttribute(data-src) || el.src) )拿到图片URL后下载到本地注意公众号图片有防盗链请求时要带上Referer: https://mp.weixin.qq.com/。这一步的图片后面会用在画面生成环节作为该段落的配图。提示如果文章图片很多建议只取前5-8张视频号短视频时长有限画面切换太频繁反而影响观感。3. 语音合成与whisper字幕对齐文案拿到手之后下一步是把它变成音频同时拿到每个字的时间戳这样才能做字幕对齐。这里有两个技术点TTS选型和whisper的模型选择。3.1 TTS选型为什么不用本地模型TTS方案我试过三种本地开源模型如VITS、云服务TTS、以及录音。录音直接排除日更不可能天天自己念。本地模型的问题是音质和自然度跟云服务差距明显尤其是中文的韵律处理本地模型经常在逗号处停顿不自然。云TTS按量付费一篇2000字的文章大概几分钱成本可以忽略。选云TTS时要注意两点一是要支持返回时间戳有些TTS只返回音频不返回每个字的时长那样就没法做精确字幕二是要支持SSML标记可以在文本里插入停顿、重音让配音更自然。# 伪代码示意具体SDK按所选服务调整 result tts_client.synthesize( textarticle_text, voicezh-CN-female, speed1.0, return_timestampsTrue ) audio_bytes result.audio word_timestamps result.timestamps # [(word, start_ms, end_ms), ...]3.2 whisper模型选择small还是medium热词里出现了potplayer whisper small 模型和whisper jax说明大家对whisper的模型规格很关注。whisper有tiny、base、small、medium、large五个规格。我的实测结论是中文短视频字幕场景small是性价比最高的选择。模型参数量中文准确率推理速度CPU显存占用GPUtiny39M较差极快极低base74M一般快低small244M良好中等约2GBmedium769M优秀慢约5GBlarge1550M最佳很慢约10GBsmall在中文上的准确率已经够用尤其是配合TTS返回的时间戳做交叉验证时错误率可以压得很低。medium和large虽然更准但推理时间成倍增加日更场景下不划算。如果你有GPUsmall基本是秒级出结果纯CPU的话2000字音频大概需要30-60秒也能接受。3.3 时间戳对齐的两种策略策略一直接用TTS返回的时间戳。优点是精确缺点是有些TTS的时间戳粒度是词级别不是字级别做逐字字幕时会有偏差。策略二用whisper重新识别音频拿到字级别时间戳。优点是粒度细缺点是whisper本身有识别错误可能把智能体识别成智能题。我的做法是两者结合以TTS时间戳为主用whisper的结果做校验。如果某个词的时间戳和whisper识别的边界差异超过200ms就以whisper为准因为whisper是基于实际音频波形分析的更能反映真实发音位置。def align_timestamps(tts_ts, whisper_ts, threshold_ms200): aligned [] for word, start, end in tts_ts: # 在whisper结果里找对应词 match find_closest(whisper_ts, word, start) if match and abs(match.start - start) threshold_ms: aligned.append((word, match.start, match.end)) else: aligned.append((word, start, end)) return aligned4. 画面生成让视频不只是一张静态图如果整条视频就是一张背景图加字幕那跟PPT没区别。视频号短视频要有点动的感觉画面至少要有变化。我的方案是每个段落配一张图或一段短视频段落切换时画面跟着切。4.1 素材来源的优先级素材来源按优先级排文章自带图片 本地素材库 AI生图 纯色/渐变背景。文章自带图片最相关直接用本地素材库是平时积累的按标签检索AI生图适合文章没有配图的情况但生成速度慢一篇文可能要多等几分钟纯色背景是兜底方案至少保证视频能出来。AI生图这块我用的是文生图模型prompt的构造有个技巧不要直接拿段落原文去生成那样出来的图很抽象。要把段落提炼成3-5个关键词再加上风格限定词。比如智能体开发这段prompt写成futuristic AI agent workflow, blue tone, clean tech style, no text。4.2 画面与音频的时长匹配这是最容易出问题的地方。音频总时长是固定的比如3分20秒你有8个段落每个段落的音频时长不一样画面要跟着音频走不能平均分配。# 根据每个段落的音频时长计算画面切换点 segments [] current_time 0 for para, audio_duration in zip(paragraphs, durations): segments.append({ text: para, start: current_time, end: current_time audio_duration, image: get_image_for(para) }) current_time audio_duration如果某个段落特别长比如超过30秒建议拆成两个画面中间加一个转场避免观众视觉疲劳。转场用ffmpeg的xfade滤镜0.5秒的淡入淡出就够了太长会显得拖沓。4.3 竖屏适配1080x1920的构图要点视频号是竖屏分辨率1080x1920。文章配图通常是横屏直接放进去会有大片黑边。处理方式有两种一是模糊背景填充把原图放大模糊后作为背景原图居中二是裁剪但会损失内容。我推荐模糊背景填充ffmpeg命令大概是这样ffmpeg -i input.jpg -filter_complex [0:v]scale1080:1920:force_original_aspect_ratioincrease, crop1080:1920,boxblur20:5[bg]; [0:v]scale1080:-1[fg]; [bg][fg]overlay(W-w)/2:(H-h)/2 output.jpg这段命令先把图片放大裁切到1080x1920做背景并模糊再把原图按宽度缩放后居中叠加。出来的效果就是上下模糊、中间清晰视觉上比黑边舒服很多。5. ffmpeg合成参数、性能与那些坑所有素材准备好之后最后一步是用ffmpeg把它们合成一条完整的视频。这一步是整条流水线里最容易出问题的参数写错一个字符可能就要重跑。5.1 基础合成命令拆解一条典型的合成命令包含视频输入图片序列或视频片段、音频输入、字幕文件、输出参数。ffmpeg -y \ -f concat -safe 0 -i images.txt \ -i audio.mp3 \ -vf subtitlessubtitle.srt:force_styleFontSize18,PrimaryColourHFFFFFF,OutlineColourH000000,Outline2 \ -c:v libx264 -preset medium -crf 23 \ -c:a aac -b:a 128k \ -pix_fmt yuv420p \ -r 30 -s 1080x1920 \ -shortest \ output.mp4逐个参数说-f concat是拼接多个图片/视频片段images.txt里列出每个片段的路径和时长-vf subtitles是烧录字幕force_style控制字体大小、颜色、描边-c:v libx264是H.264编码兼容性最好-crf 23是质量参数18-28之间23是平衡点-pix_fmt yuv420p是像素格式不指定的话某些播放器会花屏-shortest是音频结束后自动停止避免视频比音频长。5.2 字幕烧录的字体与样式坑字幕烧录最常见的坑是字体。ffmpeg的subtitles滤镜依赖libasslibass需要系统里有对应字体。如果你在服务器上跑服务器可能没装中文字体烧出来的字幕全是方块。解决办法是在force_style里指定字体名并确保系统里有这个字体force_styleFontNameNoto Sans CJK SC,FontSize18,...Linux上装字体apt install fonts-noto-cjk。Windows上一般有微软雅黑用FontNameMicrosoft YaHei。另一个坑是字幕位置。竖屏视频字幕默认在底部但视频号底部有交互按钮字幕会被挡住。建议把字幕往上移用MarginV参数控制force_style...,MarginV200200的意思是距底部200像素具体数值根据你的画面构图调。5.3 性能优化为什么你的合成那么慢ffmpeg合成慢通常是三个原因编码器没选对、preset太慢、或者用了CPU软编。编码器优先用硬件编码。NVIDIA显卡用h264_nvencIntel核显用h264_qsvMac用h264_videotoolbox。硬件编码比软编快3-5倍画质差距在短视频场景下基本看不出来。# NVIDIA硬件编码 -c:v h264_nvenc -preset p4 -cq 23preset从快到慢有p1到p7p4是平衡点。软编的preset从ultrafast到veryslowmedium是平衡点但如果你赶时间用fast也能接受。还有一个容易忽略的点图片序列合成时如果每张图都是1080x1920的大图ffmpeg要反复解码很慢。建议提前把图片统一缩放到目标分辨率合成时就不用再缩放。注意热词里提到ffmpeg推流到srs存在延迟那是直播推流场景的问题跟本文的本地合成不是一回事。推流延迟主要跟GOP大小、缓冲策略有关本地合成不涉及。5.4 GPL和LGPL的区别对项目的影响热词里有ffmpeg gpl和lgpl有什么区别这个问题在商业项目里很关键。ffmpeg默认编译是LGPL协议但如果你启用了--enable-gpl就会引入GPL组件比如x264、x265整个ffmpeg就变成GPL。GPL要求你的项目也开源LGPL则允许闭源调用。如果你只是自己用或者开源项目GPL没问题。如果是商业闭源产品要么用LGPL版本但功能受限比如没有x264要么用硬件编码器nvenc是LGPL兼容的要么通过命令行调用ffmpeg可执行文件而不是链接库这样通常被认为是聚合而非衍生可以规避GPL传染。6. 智能体编排把五个环节串成一条流水线前面五章讲的是每个环节怎么做这一章讲怎么把它们串起来以及智能体在其中的决策逻辑。6.1 任务状态机设计整条流水线是一个状态机每个环节是一个状态状态之间有条件跳转。[开始] - [抓取文章] - [提取文案] - [TTS合成] - [whisper对齐] | v [结束] - [ffmpeg合成] - [画面生成] - [字幕生成]每个状态有成功、失败、重试三种出口。失败时智能体要根据错误类型决定是重试、跳过、还是终止。比如TTS服务超时重试两次还失败就降级到备用TTS比如whisper识别置信度低于阈值就标记该段落需要人工复核但不阻塞整体流程。6.2 异常决策的几条规则规则一任何环节连续失败3次终止流程并告警。避免无限重试浪费资源。规则二非关键环节失败可降级。画面生成失败可以用纯色背景兜底字幕对齐失败可以用TTS时间戳兜底但音频合成失败必须终止因为没有音频就没有视频。规则三中间产物全部落盘。每个环节的输出都存到本地这样失败重跑时不用从头开始。比如TTS已经合成好了whisper失败了重跑时直接读音频文件不用重新TTS。def run_pipeline(article_url): state load_state(article_url) # 读取已有进度 if not state.get(article_text): state[article_text] fetch_article(article_url) save_state(state) if not state.get(audio_path): state[audio_path] tts_synthesize(state[article_text]) save_state(state) # ... 后续环节同理6.3 用Python智能体还是平台智能体回到热词里那个问题利用平台构建的智能体与用python构建的智能体有什么不一样我的实际体会是平台智能体扣子、dify等适合做编排层——定义流程、配置条件分支、接入API。它的优势是可视化、改起来快、不用写调度代码。但它的劣势是执行环境受限你没法在平台里直接跑ffmpeg命令也没法加载whisper模型。Python智能体适合做执行层——实际调用ffmpeg、跑whisper推理、处理文件IO。它的优势是灵活、可控、能调底层。劣势是调度逻辑要自己写异常处理要自己兜。我的方案是两者结合平台智能体负责接收任务、编排流程、记录状态Python服务负责执行具体环节通过HTTP接口被平台调用。这样既享受了平台的可视化编排又保留了底层的执行能力。7. 实测中的那些坑与经验这一章不讲理论只讲我实际踩过的坑以及怎么解决的。7.1 whisper识别中文标点丢失whisper识别中文时标点符号经常丢失或者错乱。比如你好世界可能识别成你好世界。这会导致字幕没有停顿感。解决办法是在whisper输出后用原文的标点做校正。因为原文是我们自己提供的标点是准确的。把whisper识别的文本和原文做对齐标点以原文为准。import difflib def restore_punctuation(whisper_text, original_text): # 用原文的标点替换whisper结果中的对应位置 matcher difflib.SequenceMatcher(None, whisper_text, original_text) result list(whisper_text) for tag, i1, i2, j1, j2 in matcher.get_opcodes(): if tag equal: for k in range(i2 - i1): if original_text[j1 k] in 。: result[i1 k] original_text[j1 k] return .join(result)7.2 ffmpeg concat拼接时的时长精度问题用concat拼接图片时每张图的时长是写在images.txt里的比如file img1.jpg下一行duration 5.2。但ffmpeg对duration的精度处理有问题5.2可能被当成5.199或者5.201累积下来会导致音画不同步。解决办法是用高精度的时间值并且最后加一个duration为0的收尾项。或者干脆不用concat用-loop 1 -t 5.2 -i img1.jpg的方式逐个输入用concat滤镜拼接。后者更精确但命令更长。ffmpeg \ -loop 1 -t 5.2 -i img1.jpg \ -loop 1 -t 3.8 -i img2.jpg \ -filter_complex [0:v][1:v]concatn2:v1:a0[v] \ -map [v] ...7.3 CDP抓取时的登录态失效CDP复用浏览器登录态时如果公众号登录过期了抓取会拿到登录页而不是文章页。智能体要能识别这种情况检查页面标题是否包含登录或者正文容器是否存在。if page.query_selector(#js_content) is None: raise LoginExpiredError(公众号登录态已失效请重新登录)处理方式是弹出一个有头浏览器让用户手动扫码登录后再继续。这个环节没法完全自动化因为扫码需要人参与。但可以做成登录一次管用很久因为公众号的登录态有效期比较长。7.4 视频号上传的格式要求最后一步是把生成的mp4上传到视频号。视频号对格式有要求MP4容器、H.264编码、AAC音频、分辨率建议1080x1920、码率建议4-8Mbps、文件大小不超过1GB。ffmpeg的默认输出基本满足但码率要控制一下。-b:v 6M -maxrate 8M -bufsize 12M-b:v 6M是目标码率6Mbps-maxrate 8M是最大码率-bufsize 12M是缓冲区大小。这样出来的文件大小可控画质也够。7.5 整条流水线的时间成本实测数据一篇2000字的文章从抓取到出片全流程大概需要3-5分钟。其中TTS合成约30秒whisper对齐约40秒GPU或90秒CPU画面生成约60秒含AI生图ffmpeg合成约40秒。如果跳过AI生图用本地素材总时间可以压到2分钟以内。对比手动剪辑同样一篇文章手动找素材、配音、加字幕、导出熟练工也要40-60分钟。自动化之后效率提升20倍以上而且可以批量跑——晚上挂机跑10篇第二天直接上传。8. 后续可以扩展的方向这套流水线跑通之后我陆续加了一些扩展功能这里简单提几个方向给想继续深挖的朋友参考。第一个方向是批量处理。把文章URL列表丢进去智能体排队处理每篇之间加个间隔避免触发风控。这个改动不大主要是状态管理要支持多任务。第二个方向是多平台适配。视频号是竖屏1080x1920但抖音、快手、B站的规格不一样。可以在ffmpeg合成环节加一个参数根据目标平台切换分辨率和码率。第三个方向是封面自动生成。视频号需要封面图可以从文章里选一张图加上标题文字用ffmpeg或者PIL合成。标题文字的字体、颜色、位置可以做成模板。第四个方向是数据回流。视频发布后把播放量、完播率、点赞数抓回来和文章类型、视频时长、画面风格做关联分析找出什么样的文章适合转视频、什么样的画面风格完播率高。这个需要额外的数据采集和分析模块但价值很大。这套东西我从零搭到现在最大的体会是不要追求一步到位。先把最核心的文章-音频-字幕-视频跑通哪怕画面就是纯色背景先让流程能出片。然后再逐步优化每个环节——换更好的TTS、加画面、加转场、加封面。每优化一个环节视频质量就提升一点但流程始终是通的。最怕的是一开始就想做完美结果卡在某个环节上整条流水线跑不起来。
