一、先看整条流水线口播视频的生产本质上是把一个重复劳动流程自动化五个环节各用一件工具全部开源或低成本环节工具解决的问题① 文案提取faster-whisperOpenAI Whisper 的加速版把别人的爆款视频扒成文字做二创起点② 文案润色DeepSeek API去洗稿痕迹、口语化、控时长③ 声音克隆IndexTTS-2B 站开源5~15 秒参考音频克隆音色文本转语音④ 对口型InfiniteTalk开源图片或视频 音频 → 会说会动的数字人⑤ 一键发布Playwright自动登录态下批量上传到各平台下面逐个环节给代码。二、环境准备硬件门槛先说清楚免得白折腾要么就用云端环节显存需求说明Whisper2~6 GBCPU 也能跑int8 量化慢但不影响DeepSeek0走 API不占本地显存IndexTTS-28 GB 起官方建议 RTX 3060 以上InfiniteTalk24 GB 起是整条链路的瓶颈建议单独一张卡关键经验这几件事不要挤在一张卡上跑。TTS 和口型驱动同时抢显存两边都会 OOM。工程上建议拆开——一张小卡专跑 TTS一张大卡专跑口型。三、① Whisper把爆款视频扒成文案用faster-whisper比原版 Whisper 快得多工程里没有理由不用它三个必踩的坑1. 一定开vad_filterTrue。静音段是 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-25 秒音频克隆音色IndexTTS-2 是 B 站 IndexTeam 开源的零样本 TTS2025 年 9 月发布改动最大的一点是把音色和情感拆开了——音色来自参考音频情感可以单独控制。对做口播工具来说这个特性非常有用。三个实战经验1. 参考音频质量决定上限这一段没有补救空间。手机在安静房间录 10 秒效果远好于从嘈杂会场录音里剪 1 分钟。做产品的话客户端里应该直接内置一段参考音频录制指引别指望用户自己懂。2. 长文本必须切句。一次塞 2000 字合成质量和稳定性都会掉。按标点切成 20~40 字的短句逐句合成再拼接。3. 语速不要指望模型放到后期调。用 1.0x 正常合成最后在 FFmpeg 里整体变速atempo1.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 请求里同步等。九、做成产品中间必须加一层服务端如果只是自己用上面这套跑起来就够了。但要给别人用客户端直连推理服务会踩三个坑算力白送。接口一暴露谁都能拿你的 GPU 跑自己的任务。排队不可控。并发一上来所有请求一起超时用户看到的是软件坏了。授权没处做。卡密核销、额度控制、代理归属总得有个中间层。结构很简单FastAPI 接请求 → Redis 排队 → worker 串行消费。worker 侧最关键的是失败退款——任务挂了必须把卡密还回去一次不退带来的信任损失比这一次算力成本贵得多。十、部署清单或者云端组件部署方式备注faster-whisperPython 进程CPU int8 也能跑有卡更快DeepSeek调 API不占本地资源IndexTTS-2独立服务建议独占 8G 显卡避免和数字人抢显存InfiniteTalk独立服务 / ComfyUI显存需求最高建议独立 24G 卡FastAPI Redis常规 Linux 部署队列、卡密、任务状态都在这层Playwright同机部署需要持久化浏览器目录别放容器临时盘一句话建议先用按量付费的云算力把链路跑通再决定要不要自建。测试阶段一条视频的云成本不到两块钱比先买卡试错便宜太多。十一、常见坑汇总#坑解法1Whisper 输出整段幻觉文字必开vad_filterTrue2改写后和原文太像temperature提到 1.2~1.53TTS 把提示词念出来了系统提示词里明确只输出正文4IndexTTS 长文本音质崩按标点切 20~40 字短句再合成5数字人推理同步接口超时必须改成提交任务 轮询异步模式6多模型抢显存 OOM按模型拆卡别都堆一张7自动发布导致账号被限流做成自动填表 人工点发布的半自动8全自动发布整批中断每个平台独立 try/except十二、结语这套流程的技术栈全部是开源或低成本的Whisper 解决看别人怎么讲DeepSeek 解决讲成自己的话IndexTTS-2 解决用我的声音讲InfiniteTalk 解决我不用出镜Playwright 解决发出去。真正难的不是模型调用是把这五段拼成一条能长时间稳定跑的生产线——队列、算力调度、异常兜底、授权控制这些才是工程价值所在。有在搭类似流水线的同行欢迎评论区交流你更想深入哪一段——音色克隆还是长视频对口型的稳定性下一篇写投票多的那个。
一、先看整条流水线口播视频的生产本质上是把一个重复劳动流程自动化五个环节各用一件工具全部开源或低成本环节工具解决的问题① 文案提取faster-whisperOpenAI Whisper 的加速版把别人的爆款视频扒成文字做二创起点② 文案润色DeepSeek API去洗稿痕迹、口语化、控时长③ 声音克隆IndexTTS-2B 站开源5~15 秒参考音频克隆音色文本转语音④ 对口型InfiniteTalk开源图片或视频 音频 → 会说会动的数字人⑤ 一键发布Playwright自动登录态下批量上传到各平台下面逐个环节给代码。二、环境准备硬件门槛先说清楚免得白折腾要么就用云端环节显存需求说明Whisper2~6 GBCPU 也能跑int8 量化慢但不影响DeepSeek0走 API不占本地显存IndexTTS-28 GB 起官方建议 RTX 3060 以上InfiniteTalk24 GB 起是整条链路的瓶颈建议单独一张卡关键经验这几件事不要挤在一张卡上跑。TTS 和口型驱动同时抢显存两边都会 OOM。工程上建议拆开——一张小卡专跑 TTS一张大卡专跑口型。三、① Whisper把爆款视频扒成文案用faster-whisper比原版 Whisper 快得多工程里没有理由不用它三个必踩的坑1. 一定开vad_filterTrue。静音段是 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-25 秒音频克隆音色IndexTTS-2 是 B 站 IndexTeam 开源的零样本 TTS2025 年 9 月发布改动最大的一点是把音色和情感拆开了——音色来自参考音频情感可以单独控制。对做口播工具来说这个特性非常有用。三个实战经验1. 参考音频质量决定上限这一段没有补救空间。手机在安静房间录 10 秒效果远好于从嘈杂会场录音里剪 1 分钟。做产品的话客户端里应该直接内置一段参考音频录制指引别指望用户自己懂。2. 长文本必须切句。一次塞 2000 字合成质量和稳定性都会掉。按标点切成 20~40 字的短句逐句合成再拼接。3. 语速不要指望模型放到后期调。用 1.0x 正常合成最后在 FFmpeg 里整体变速atempo1.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 请求里同步等。九、做成产品中间必须加一层服务端如果只是自己用上面这套跑起来就够了。但要给别人用客户端直连推理服务会踩三个坑算力白送。接口一暴露谁都能拿你的 GPU 跑自己的任务。排队不可控。并发一上来所有请求一起超时用户看到的是软件坏了。授权没处做。卡密核销、额度控制、代理归属总得有个中间层。结构很简单FastAPI 接请求 → Redis 排队 → worker 串行消费。worker 侧最关键的是失败退款——任务挂了必须把卡密还回去一次不退带来的信任损失比这一次算力成本贵得多。十、部署清单或者云端组件部署方式备注faster-whisperPython 进程CPU int8 也能跑有卡更快DeepSeek调 API不占本地资源IndexTTS-2独立服务建议独占 8G 显卡避免和数字人抢显存InfiniteTalk独立服务 / ComfyUI显存需求最高建议独立 24G 卡FastAPI Redis常规 Linux 部署队列、卡密、任务状态都在这层Playwright同机部署需要持久化浏览器目录别放容器临时盘一句话建议先用按量付费的云算力把链路跑通再决定要不要自建。测试阶段一条视频的云成本不到两块钱比先买卡试错便宜太多。十一、常见坑汇总#坑解法1Whisper 输出整段幻觉文字必开vad_filterTrue2改写后和原文太像temperature提到 1.2~1.53TTS 把提示词念出来了系统提示词里明确只输出正文4IndexTTS 长文本音质崩按标点切 20~40 字短句再合成5数字人推理同步接口超时必须改成提交任务 轮询异步模式6多模型抢显存 OOM按模型拆卡别都堆一张7自动发布导致账号被限流做成自动填表 人工点发布的半自动8全自动发布整批中断每个平台独立 try/except十二、结语这套流程的技术栈全部是开源或低成本的Whisper 解决看别人怎么讲DeepSeek 解决讲成自己的话IndexTTS-2 解决用我的声音讲InfiniteTalk 解决我不用出镜Playwright 解决发出去。真正难的不是模型调用是把这五段拼成一条能长时间稳定跑的生产线——队列、算力调度、异常兜底、授权控制这些才是工程价值所在。有在搭类似流水线的同行欢迎评论区交流你更想深入哪一段——音色克隆还是长视频对口型的稳定性下一篇写投票多的那个。
