口播智能体，AI短视频智能体开发流程（已开源）

一、先看整条流水线

口播视频的生产，本质上是把一个重复劳动流程自动化：

五个环节各用一件工具，全部开源或低成本：

下面逐个环节给代码。

二、环境准备

硬件门槛先说清楚，免得白折腾（要么就用云端）：

关键经验：这几件事不要挤在一张卡上跑。TTS 和口型驱动同时抢显存，两边都会 OOM。工程上建议拆开——一张小卡专跑 TTS，一张大卡专跑口型。

三、① Whisper：把爆款视频扒成文案

用faster-whisper，比原版 Whisper 快得多，工程里没有理由不用它

三个必踩的坑：

1. 一定开vad_filter=True。静音段是 Whisper 幻觉的重灾区。不开 VAD，遇到一段没有人声的画面，模型会自己"编"出一整段字幕来，而且编得很像真的。做批量任务时不加这个参数，你会得到一堆莫名其妙的内容。

2. 长视频要分片。超过 10 分钟的素材切成 3~5 分钟一段再喂进去，否则显存容易堆爆。faster-whisper内部虽然有滑窗，但外层再切一刀更稳。

3. 传initial_prompt能显著改善中文标点。不传的话，输出经常是一整段没有标点的文字，后面的切句、润色都会受影响。

四、② DeepSeek：把扒来的稿子变成"自己的"

直接抄别人的文案发出去，一是平台判重，二是没有自己的语气。这一步用 DeepSeek 做改写。

工程上要注意：

1.temperature是改写场景的关键参数。默认 1.0 出来的稿子经常和原文高度相似。调到 1.2~1.5，句子结构会有明显变化，但要点还在。

2. "只输出正文"这句必须写在提示词里。否则模型很容易回一句"好的，以下是为您改写的文案："——这行字配上 TTS 就会直接念出来。

3. 用数字控制时长，别用字数控制。口播的实际语速约 45 字/秒。要做 60 秒的视频，就让模型写 260300 字，这个换算关系比"写得简洁点"这种模糊指令管用得多。

五、③ IndexTTS-2：5 秒音频克隆音色

IndexTTS-2 是 B 站 IndexTeam 开源的零样本 TTS，2025 年 9 月发布，改动最大的一点是把音色和情感拆开了——音色来自参考音频，情感可以单独控制。对做口播工具来说，这个特性非常有用。

三个实战经验：

1. 参考音频质量决定上限，这一段没有补救空间。手机在安静房间录 10 秒，效果远好于从嘈杂会场录音里剪 1 分钟。做产品的话，客户端里应该直接内置一段"参考音频录制指引"，别指望用户自己懂。

2. 长文本必须切句。一次塞 2000 字，合成质量和稳定性都会掉。按标点切成 20~40 字的短句，逐句合成再拼接。

3. 语速不要指望模型，放到后期调。用 1.0x 正常合成，最后在 FFmpeg 里整体变速（atempo=1.1），比让 TTS 模型变语速要可控得多，也不会影响音质。

六、④ InfiniteTalk：图片/视频 + 音频 = 会说会动的数字人

InfiniteTalk 是音频驱动的数字人生成模型，和传统只修嘴型的方案最大的区别是：它同时驱动嘴型、表情、头部转向和身体姿态，而且是流式分块生成，理论上不限时长。

• 项目地址：https://github.com/MeiGen-AI/InfiniteTalk

• 基座模型：Wan2.1-I2V-14B，推荐 24GB+ 显存

• 许可证：Apache 2.0，商用友好

• 支持 Image-to-Video（一张人像图 + 音频）和 Video-to-Video（原视频 + 新音频重配音）

直接调它的推理脚本：

部署要点（这几个坑踩过才知道）：

1. 显存不够，加机器比调参划算。这是最重要的结论。24G 卡跑 1080p 长视频会非常勉强，把分辨率、步数一路调低之后，产物质量会掉到不可用。与其纠结参数，不如直接上更大的卡，或者分成多张卡跑。

2. 长视频必须靠分块，不能一次性喂。InfiniteTalk 内部是按块处理的（每块约 81 帧，带 25 帧重叠过渡），这个机制保证了长视频不崩。但超过 1 分钟的视频可能出现色偏，工程上是靠 Prompt 保持和分块重叠来压制的——如果你的项目对色准要求高，这一步之后要加一道调色兜底。

3. 480p 是性价比最优解。对于口播这种主体固定、动作幅度小的场景，480p 生成后再用超分放大，比直接跑 720p 又快又省显存，肉眼几乎看不出差别。

4. 想省事可以走 ComfyUI。InfiniteTalk 有 ComfyUI 节点封装。如果你的团队已经在用 ComfyUI 做 AIGC 管线，直接接进去比自己写封装更快，也方便做可视化调试。

七、⑤ 一键发布：Playwright 多平台自动上传

先说结论，避免走弯路：抖音、视频号、小红书这些平台，没有面向个人开发者的公开发布 API。

• 抖音开放平台的发布能力需要企业开发者资质和审核；

• B 站开放平台主要面向企业；

• 视频号和小红书基本没有对外开放的上传接口。

所以工程上能落地的方案只有一个：浏览器自动化 + 持久化登录态。

这段代码的四个设计决定，都是踩坑换来的：

1. 用launch_persistent_context而不是launch。普通launch每次都是全新的无痕环境，每次都要重新扫码登录。持久化 context 把 Cookie 存在本地目录，登录一次能用很久。

2. 表单要在上传完成之后再填。各家平台的标题输入框都是上传开始后才渲染的。上传前就去找元素，必然拿到空。

3. 刻意不自动点最后的"发布"按钮。这是工程上故意的保守设计：自动填好表单，最后一步留人工确认。原因是各平台的风控对"全自动发布"非常敏感，账号被限流得不偿失。半自动比全自动更耐用。

4. 单个平台失败不影响其他平台。每个适配器独立 try/except，一个挂了不影响后面的。批量任务里，一个异常中断整批是最常见的事故。

八、串起来：一条命令跑完全流程

把五步拼成一个 pipeline：

整条链路的时间成本参考：25 秒的口播成片，脚本处理部分（①②）约 10 秒，配音（③）约 20 秒，数字人生成（④）是绝对瓶颈，在单卡上要几分钟。所以做产品时，④ 必须做成异步任务队列，不能放在 HTTP 请求里同步等。

九、做成产品，中间必须加一层服务端

如果只是自己用，上面这套跑起来就够了。但要给别人用，客户端直连推理服务会踩三个坑：

1. 算力白送。接口一暴露，谁都能拿你的 GPU 跑自己的任务。

1. 排队不可控。并发一上来所有请求一起超时，用户看到的是"软件坏了"。

1. 授权没处做。卡密核销、额度控制、代理归属，总得有个中间层。

结构很简单：FastAPI 接请求 → Redis 排队 → worker 串行消费。

worker 侧最关键的是失败退款——任务挂了必须把卡密还回去，一次不退带来的信任损失，比这一次算力成本贵得多。

十、部署清单（或者云端）

一句话建议：先用按量付费的云算力把链路跑通，再决定要不要自建。测试阶段一条视频的云成本不到两块钱，比先买卡试错便宜太多。

十一、常见坑汇总

十二、结语

这套流程的技术栈全部是开源或低成本的：Whisper 解决"看别人怎么讲"，DeepSeek 解决"讲成自己的话"，IndexTTS-2 解决"用我的声音讲"，InfiniteTalk 解决"我不用出镜"，Playwright 解决"发出去"。

真正难的不是模型调用，是把这五段拼成一条能长时间稳定跑的生产线——队列、算力调度、异常兜底、授权控制，这些才是工程价值所在。

有在搭类似流水线的同行，欢迎评论区交流：你更想深入哪一段——音色克隆，还是长视频对口型的稳定性？下一篇写投票多的那个。