AI编程 擎天说

让文章成片工作台真正生成一条带中文旁白的本地 MP4

这篇写了什么

让文章成片工作台真正生成一条带中文旁白的本地 MP4 我最先确认的不是界面是否完整,而是它能不能把一篇文章真正送进播放器。 这次里程碑里,工作台使用本机的 Microsoft Huihui Desktop 合成中文旁白,完成了三个场景的竖屏视频。最终文件是 1080×1920、30 fps 的 H.

让文章成片工作台真正生成一条带中文旁白的本地 MP4

我最先确认的不是界面是否完整,而是它能不能把一篇文章真正送进播放器。

这次里程碑里,工作台使用本机的 Microsoft Huihui Desktop 合成中文旁白,完成了三个场景的竖屏视频。最终文件是 1080×1920、30 fps 的 H.264/yuv420p 视频,音频为 AAC/48 kHz,时长 21.674 秒。它不是一段模拟音频,也不是只生成到某个中间目录的半成品,而是通过了完整媒体读取校验的 MP4。

我借助 AI 开发工具推进这件事时,重点没有放在让它替我写完更多代码,而是先把“文章转视频”拆成几个必须能单独判断对错的环节,再逐项检查实际产物。

先把“能生成视频”拆成六个可检查的阶段

文章转视频很容易被描述成一个大功能:读取文章、生成场景、配音、渲染、导出。这样的描述适合介绍产品,却不适合排查问题。

我把核心流程拆成 ASSETS、TTS、TIMELINE、RENDER、COMPOSE、VERIFY 六个阶段。每个阶段都要留下可判断的结果,最后再由 VERIFY 检查视频和音频是否真的可读取。

这个拆分改变了验收方式。遇到问题时,不需要笼统地问“为什么没有成片”,而是先看失败发生在素材、语音、时间线、渲染、合成还是校验阶段。三场景真实旁白烟测中,六个阶段全部成功,说明这条主流程已经从演示路径推进到了可重复检查的工作路径。

AI 开发工具在这里更像一个拆解和复核助手:它可以根据目标整理任务边界、提示遗漏的输入输出,再把检查项转成可以执行的测试和命令。最终是否成立,仍然由生成出来的媒体文件和测试结果决定,而不是由代码看起来是否完整决定。

系统语音先做基础引擎,不把它包装成高质量音色

语音方案是这次最需要做取舍的地方。

目标是在不下载模型、不替用户接受第三方许可证的前提下,立即生成真实中文旁白。于是我选择 Windows System.Speech 作为当前基础引擎,并新增了一个本地回环服务。服务随机绑定 127.0.0.1 端口,通过随机会话令牌建立调用关系,Electron 环境页提供一键启用系统语音的入口。

这个选择有明确边界:系统语音适合快速可用和回归验证,但不能冒充已经通过门禁的高质量 AI 音色。CosyVoice2 和 IndexTTS2 仍然保留为后续候选,在安装之前还需要确认兼容性、音质和许可证。

最终烟测使用 Microsoft Huihui Desktop 完成中文旁白生成,总耗时 40.557 秒。这个结果证明当前环境下确实能完成从文本到本地音频再到视频的贯通,但没有证明系统语音的自然度已经满足最终内容生产要求。

隐私要求必须落实到进程边界

“数据留在本机”不能只写在产品简介里,还要落实到调用方式上。

合成文本只通过子进程的标准输入传递,不放进命令行参数,也不写入日志。服务关闭时会清理临时音频。会话令牌由主进程持有,不返回给 renderer;本地服务也只绑定回环地址,而不是对外暴露端口。

这些限制让语音合成具备了比较清楚的边界:桌面界面负责发起操作,主进程管理令牌和调用,语音服务处理标准输入,临时文件在服务结束后清理。这里没有把安全性简化成一个开关,而是检查文本、令牌、端口和临时文件分别经过了什么路径。

这也是我让 AI 工具参与检查时反复强调的部分。它可以帮助列出“文本是否进入参数”“令牌是否被 renderer 拿到”“服务是否绑定外网地址”等问题,但这些问题必须回到实际进程和调用代码中核对,不能只看界面上有没有一个“本地模式”选项。

真实 WAV 进入时间线后,边界问题才会出现

使用占位音频时,字幕和画面时间线通常不会暴露太多问题。换成真实 WAV 后,拼接过程出现了亚毫秒级的舍入差异。这个问题不一定会让视频立即失败,却可能让音频、字幕和场景尾部出现细小错位。

处理方式不是把所有片段粗暴地统一取整,而是把误差安全地吸收到最后一个字幕句段。这样可以保持前面各段的时间关系,同时让整条时间线在末尾完成对齐。

这个判断体现了“局部修正”比“全局重算”更适合这类流水线。文章转视频的场景、旁白和字幕都有各自的中间结果,时间线出现微小误差时,应该尽量缩小修正范围,避免牵动已经正确的部分。

用成片和自动验证结束验收

这次验收没有停在测试数量上,也没有只看截图。实际生成的三场景 MP4 通过了分辨率、帧率、编码格式、音频采样率和可读取时长校验。截图中的字幕、标题、要点与安全区也已经进入最终 H.264/AAC 成片,而不是只存在于编辑界面。

同时,25 个测试文件共 72 项测试通过,桌面生产构建、Electron IPC 烟测以及桌面和移动 UI 烟测也通过。它们分别覆盖了逻辑、构建、进程通信和界面入口,和最终媒体校验放在一起,才足以说明这条路径目前可以使用。

但验收范围仍然有边界。真实 Halo 内容与用户 LLM 的完整内容质量,还需要在桌面版中按实际文章继续检查;更高质量的旁白候选,也要在用户确认许可证后再安装和试听。

所以,这个里程碑的结果不是“所有视频质量问题都解决了”,而是工作台已经有了一条真实可播放、可验证、数据留在本机的基础成片路径。后续工作可以围绕具体文章质量和音色选择继续推进,而不必再从模拟音频或未完成的导出流程开始。