企业官网建设流程全解析

公众号运营者最头疼的事，往往不是写不出文章，而是文章发出去之后，视频号那边还空着。图文和短视频是两套完全不同的生产逻辑，重新剪辑、配音、加字幕，一条三分钟的视频能吃掉半天时间。我做了两年多的内容自动化，踩过的坑足够写一本小册子，今天就把"公众号文章自动转视频号短视频"这条链路完整拆开讲一遍。核心思路是用智能体把整条流水线串起来：抓取文章正文、用大模型做脚本改写和分镜拆解、调用语音合成生成配音、用 ffmpeg 做画面合成与字幕烧录、最后通过浏览器自动化把成品推到视频号后台。整套方案涉及智能体编排、wechat-video-creator 这类自动化工具、ffmpeg 音视频处理、whisper 语音识别以及 CDP 浏览器控制几个关键技术点，适合有一定 Python 基础、想把内容生产规模化的运营和技术同学参考。下面我从整体架构开始，一层一层往下拆。

1. 为什么公众号转视频号不能靠"录屏+念稿"

1.1 图文和短视频的底层逻辑差异

很多人第一反应是：把公众号文章打开，录个屏，配个 AI 朗读，不就完事了？我最早也是这么干的，结果发出去播放量惨不忍睹。问题出在两种媒介的信息密度和节奏完全不同。公众号文章是"扫读"逻辑，读者可以跳读、回看、停顿，一段话可以承载三四个信息点；而短视频是"线性流"逻辑，观众只能顺着往下看，每 3 到 5 秒必须有一个新的刺激点，否则手指就划走了。

这意味着直接把文章文字转成语音，会得到一条语速均匀、信息平铺、没有任何视觉变化的"催眠视频"。真正可用的转换，必须经过一次"再创作"：把长段落拆成短句、把书面语改成口语、把抽象论述换成具体例子、把静态描述转成可以配画面的分镜。这一步是整条链路里最值钱的环节，也是大模型最能发挥价值的地方。

1.2 智能体在这条链路里到底扮演什么角色

所谓"智能体基建"，说白了就是把原来需要人一步步操作的环节，交给一个能自主决策、能调用工具、能处理异常的程序去跑。在这条公众号转视频的链路里，智能体要干的事包括：判断文章类型（是干货教程还是观点评论）、决定视频时长和分镜数量、生成每一段的解说词和画面提示、调用 TTS 接口、调用 ffmpeg 合成、最后处理上传。它不是一个单点工具，而是整条流水线的调度中枢。

我用的架构是"主智能体 + 工具函数"的模式，主智能体负责规划和决策，具体的抓取、合成、上传都封装成独立函数由它调用。这样做的好处是每个环节可以单独测试、单独替换，不会牵一发动全身。下面这张表是我对比过的几种方案，供你选型参考。

1.3 整条流水线的五个关键节点

把复杂流程拆开看，其实就五步：内容获取、脚本重构、语音合成、视频合成、自动发布。内容获取是从公众号文章里提取干净的正文；脚本重构是把正文变成分镜脚本；语音合成是把脚本变成音频；视频合成是把音频、画面、字幕拼成成品；自动发布是通过浏览器自动化把成品传到视频号。这五步里，第三步和第四步是技术含量最高、也最容易出问题的，后面会重点展开。

2. 内容获取与脚本重构：智能体的"大脑"环节

2.1 从公众号文章里提取干净正文

公众号文章的正文提取有个坑：页面里混着大量样式标签、广告位、推荐阅读模块，直接抓 HTML 会得到一堆垃圾。我的做法是用无头浏览器加载页面，等正文区域渲染完成后，定位到#js_content这个容器（公众号正文的标准 id），把里面的文本节点抽出来。这里要注意，公众号对图片做了防盗链，正文里的图片 URL 带有时效性参数，抓下来之后要立刻下载到本地，否则过几个小时就失效了。

提取出来的文本还要做清洗：去掉多余空行、统一标点、把全角空格转半角。我写了一个简单的清洗函数，核心逻辑是用正则把连续空白替换成单个换行，再过滤掉长度小于 5 的短行（通常是残留的按钮文字）。这一步看起来不起眼，但直接影响后面大模型的理解质量——喂给模型的文本越干净，生成的分镜越靠谱。

2.2 用大模型把文章改写成口播脚本

这是整个链路的核心。我的提示词设计遵循三个原则：限定输出结构、限定语言风格、限定长度。输出结构上，我要求模型返回 JSON 数组，每个元素包含narration（解说词）、visual（画面描述）、duration（预估时长）三个字段。语言风格上，明确要求"口语化、短句为主、每句不超过 25 字、避免书面连接词"。长度上，根据目标视频时长反推，一般 60 秒视频对应 180 到 220 字解说词。

这里有个经验：不要一次性让模型处理整篇长文，效果会很差。我的做法是先让模型做一次"大纲提取"，把文章拆成 3 到 5 个核心观点，然后针对每个观点单独生成分镜。这样既保证了逻辑清晰，又避免了模型在长上下文里"跑偏"。另外，模型生成的duration往往不准，我一般按"每秒 4 个字"的语速重新估算，比模型自己猜的靠谱得多。

2.3 分镜脚本的字段设计与校验

分镜脚本是整个流水线的"施工图"，字段设计要考虑到下游所有环节的需求。除了上面说的三个字段，我还会加一个keywords字段，用来做字幕高亮和画面素材检索。脚本生成后必须做校验：解说词总字数是否在合理区间、分镜数量是否过多或过少、有没有空字段。校验不通过就带着错误信息重新请求模型，最多重试三次。

提示：模型偶尔会返回带 markdown 代码块标记的 JSON，解析前记得先剥掉json 和这两层包裹，否则json.loads会直接报错。这个坑我踩过不止一次。

3. 语音合成与 whisper 的配合使用

3.1 TTS 选型与参数调优

语音合成这块，市面上的选择很多，我主要用两类：一类是云服务的 TTS 接口，音质好、情感自然，但按量计费；另一类是本地部署的开源方案，成本低但音质参差。选型时重点看三个指标：自然度、响应速度、是否支持 SSML。SSML 很重要，它允许你在文本里插入停顿、重音、语速变化标记，能让机械的朗读变得有节奏感。

参数调优上，语速我一般设在 1.0 到 1.1 倍之间，太快听不清，太慢显得拖沓。音调保持默认，除非是特定人设需要调整。这里有个细节：不同 TTS 引擎对同一段文本的断句逻辑不同，有的会在逗号处停很久，有的几乎不停。我的做法是先用一小段文本测试，听一遍断句效果，再决定要不要在文本里手动加停顿标记。

3.2 本地部署 whisper 做字幕时间轴

视频字幕的时间轴对齐是个麻烦事。如果靠人工听打，一条三分钟的视频能耗掉半小时。我的方案是用 whisper 做自动对齐：先把 TTS 生成的音频喂给 whisper，让它输出带时间戳的文本，再和原始脚本做模糊匹配，就能得到每句话的精确起止时间。whisper 本地部署推荐用faster-whisper这个实现，比原版快好几倍，显存占用也低。

部署命令大致是这样：

pip install faster-whisper

调用时选择base或small模型就够了，字幕对齐不需要太高的识别精度，反而模型越大越慢。这里要注意，whisper 识别出来的文本可能和原始脚本有出入（同音字、漏字），所以匹配时要用编辑距离做模糊匹配，不能要求完全一致。我一般设置相似度阈值 0.7，低于这个值就认为对齐失败，回退到按字数平均分配时间。

3.3 音频与字幕的合并策略

拿到音频和带时间戳的字幕后，要把它们合并成一个带字幕轨的视频。这里有两种做法：一种是生成独立的.srt字幕文件，播放器加载；另一种是把字幕直接烧录进画面。视频号场景下我推荐烧录，因为用户大多在手机端观看，独立字幕轨兼容性不稳定。烧录用 ffmpeg 的subtitles滤镜就能搞定，具体命令后面会讲。

4. ffmpeg 视频合成：从素材到成品的完整命令拆解

4.1 画面素材的准备与规格统一

视频画面我一般用两种来源：一是纯色背景加文字动画，二是从免费素材库下载的相关片段。不管哪种，都要先统一规格：分辨率 1080x1920（竖屏）、帧率 30fps、像素格式 yuv420p。规格不统一是 ffmpeg 合成失败的头号原因，我见过太多人卡在"输入流参数不一致"的报错上。

统一规格的命令：

ffmpeg -i input.mp4 -vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2,setsar=1" -r 30 -pix_fmt yuv420p output.mp4

这条命令里的force_original_aspect_ratio=decrease保证画面不变形，pad把不足的部分用黑边补齐，setsar=1统一采样宽高比。这几个参数缺一不可，尤其是setsar，不加的话合成时经常报 SAR 不匹配的错。

4.2 字幕烧录与文字动画

字幕烧录用subtitles滤镜，配合force_style参数控制字体、大小、颜色、描边。竖屏视频的字号建议在 48 到 60 之间，太小了手机上看不清。描边一定要加，否则浅色画面上白字会糊成一片。

ffmpeg -i video.mp4 -vf "subtitles=sub.srt:force_style='FontSize=54,OutlineColour=&H00000000,Outline=3,Alignment=2,MarginV=120'" -c:a copy output.mp4

Alignment=2表示底部居中，MarginV=120是距底部的像素距离，这个值要避开视频号底部的交互按钮区域，不然字幕会被挡住。

4.3 音视频合并与常见报错处理

把配音音频和画面合并，最稳的方式是用-shortest参数，让输出时长以较短的流为准。如果音频比画面长，画面会定格在最后一帧；如果画面比音频长，音频结束后会静音。我一般让画面比音频长 0.5 秒，避免结尾太突兀。

ffmpeg -i video.mp4 -i audio.mp3 -c:v copy -c:a aac -shortest output.mp4

常见的报错里，"Codec time base not set" 通常是因为输入流的时间基不一致，加-vsync cfr强制恒定帧率能解决大部分情况。"Non-monotonous DTS" 是时间戳乱序，加-fflags +genpts重新生成时间戳即可。这些报错看着吓人，其实都是参数问题，理解了原理就不难处理。

5. 自动发布：CDP 控制浏览器上传视频号

5.1 为什么选 CDP 而不是模拟点击

自动发布这块，很多人用 Selenium 或 Playwright 做模拟点击，但视频号后台的页面结构经常变，选择器一失效整个流程就断了。我改用 CDP（Chrome DevTools Protocol）直接控制浏览器，好处是可以监听网络请求、拦截响应、注入脚本，对页面变化的容忍度更高。CDP 通过 WebSocket 和浏览器通信，Python 里用websockets库就能直接对接，不需要额外的驱动。

启动浏览器时要开调试端口：

chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-profile

user-data-dir指定一个独立的用户目录，这样登录状态可以持久化，不用每次重新扫码。第一次手动登录一次，之后智能体就能复用这个会话。

5.2 上传流程的关键步骤与等待策略

上传视频号的流程大致是：打开上传页、选择文件、等待上传完成、填写标题和描述、选择封面、点击发布。每一步都要有明确的等待条件，不能靠固定sleep。我的做法是监听 CDP 的网络事件，等上传接口返回成功后再进行下一步。上传大文件时进度条会走很久，这时候要设置足够长的超时，我一般给 5 分钟。

填写标题和描述时要注意，视频号的标题有字数限制，描述里不能带某些敏感词。我的做法是在智能体里内置一个简单的校验函数，提交前先检查一遍，避免因为文案问题导致发布失败。

5.3 发布失败的排查与重试机制

自动发布最怕的是"静默失败"——脚本以为成功了，其实没发出去。我的做法是发布后主动查询一次作品列表接口，确认新视频确实存在。如果不存在，就截图保存当前页面状态，方便事后排查。重试机制上，我设置最多重试两次，两次都失败就发通知，不再无脑重试，避免触发平台的风控。

注意：自动发布涉及平台账号操作，频率一定要控制。我一般一天不超过 3 条，且发布间隔在 2 小时以上，模拟正常人工节奏。频率过高容易触发风控，得不偿失。

6. 智能体编排与容错：让整条流水线稳定跑起来

6.1 主智能体的任务规划逻辑

主智能体不直接干活，它负责"想"和"调度"。收到一篇文章后，它先判断文章类型和长度，决定视频时长和分镜数量，然后依次调用各个工具函数。每个工具函数的返回结果都会反馈给智能体，由它决定下一步是继续、重试还是终止。这种设计的好处是，任何一个环节出问题，智能体都能感知到并做出反应，而不是整条链路直接崩掉。

我用的是"状态机 + 大模型决策"的混合模式。状态机负责管理流程的确定性部分（比如必须先有脚本才能合成音频），大模型负责处理不确定性部分（比如脚本生成失败时怎么调整提示词重试）。两者结合，既保证了流程的稳定，又保留了灵活性。

6.2 各环节的异常捕获与降级方案

每个环节都要有降级方案。脚本生成失败，降级到用文章原文按段落切分；TTS 失败，降级到用备用引擎；ffmpeg 合成失败，降级到用更简单的合成参数；上传失败，降级到保存到本地待人工处理。降级不是失败，而是保证"至少能产出点东西"，这对批量生产很重要。

异常捕获要细，不能一个try-except包住整个流程。我的做法是每个工具函数内部自己处理异常，返回统一的结果对象，包含success、data、error三个字段。主智能体根据success判断是否继续，根据error决定重试策略。

6.3 日志与可观测性建设

批量跑的时候，出问题是必然的，关键是能不能快速定位。我的做法是每个环节都打结构化日志，记录时间戳、环节名、输入摘要、输出摘要、耗时、是否成功。日志用 JSON 格式写文件，方便后续用脚本分析。另外，关键节点（比如上传成功）会发一条通知到工作群，这样即使不盯着也能知道进度。

可观测性这块，我还会记录每个环节的耗时分布。跑一段时间后就能看出瓶颈在哪——通常是 TTS 和 ffmpeg 合成最慢。知道瓶颈后就能针对性优化，比如把 TTS 改成并发调用，或者把 ffmpeg 的 preset 从slow改成medium换取速度。

7. 实操中的几个关键取舍

7.1 视频时长控制在多少合适

我的经验是 45 到 90 秒最合适。太短信息量不够，太长完播率断崖式下跌。一篇文章通常能拆出 2 到 3 条视频，每条聚焦一个核心观点，而不是硬塞进一条。拆分的时候要注意，每条视频要有独立的开头和结尾，不能是简单的"上集下集"，否则单条观看的体验很差。

7.2 画面风格是统一还是多变

统一风格有利于建立账号辨识度，但每条视频完全一样又容易审美疲劳。我的做法是保持"版式统一、素材多变"：字幕位置、字体、配色固定，但背景素材根据内容更换。这样既有辨识度，又不至于千篇一律。素材来源上，我优先用和内容相关的实拍片段，实在找不到就用渐变色背景加文字动画，效果也不差。

7.3 人工介入的边界在哪里

全自动不等于完全不管。我的做法是在两个节点保留人工确认：脚本生成后和发布前。脚本确认是为了保证内容质量，发布前确认是为了避免文案问题。这两个确认点可以做成简单的命令行交互，也可以做成网页表单。批量生产时，人工确认会成为瓶颈，所以我的策略是"抽检"——每 10 条抽 1 条人工看，其余自动放行，出问题再回溯。

这套流水线我跑了半年多，从最初每条视频要折腾一小时，到现在全自动跑完只要几分钟，中间踩的坑基本都在这篇文章里了。最后分享一个小技巧：ffmpeg 合成时加上-threads 0让它自动使用所有 CPU 核心，合成速度能快将近一倍，这个参数在批量处理时特别有用。另外，如果你的机器有独立显卡，可以试试用硬件加速编码，h264_nvenc比软件编码快得多，画质损失也在可接受范围内。