在我担任 InfoWorld 首席博主期间，我对软件操作过程的旁白视频产生了浓厚兴趣。当时已有工具可以实现这种叙事方式，但后来被称为 screencasting（屏幕录制）的这种形式的解释力尚未被广泛认可。尽管这种媒介后来成为演示软件的标准方式，我也在多年间制作和编辑了许多 screencast，但现有工具从未按照我希望的方式工作：简单且精确的逐帧预览，以及注释、剪切、暂停和旁白的执行。当人们要求制作 screencast 来演示如何使用 Bram 时，我尝试使用常规工具，沮丧地放弃了，然后一时兴起决定看看能否用 Bram 来创建我一直想要的编辑器。

几天之内我就做出了 Bram Studio 的第一个版本；又经过几天的迭代，Bram 的首个 screencast 诞生了。该工具从 Bram Studio 的 GitHub 仓库的本地克隆运行，你在那里启动 Bram，然后打开它所谓的目标应用。

它对我来说运行良好，但这种设置感觉有点奇怪。谁会想要克隆一个仓库，然后安装 Bram，再用 Bram 来启动 Bram Studio 呢？为什么不直接把 Bram Studio 打包成一个像 Bram 本身那样易于下载和安装的单一二进制文件呢？

Bram Studio 是一个用户创新工具包

我产品开发的北极星目标最好用 Eric von Hippel 的《Democratizing Innovation》来描述。他主张，不要仅仅交付一个预设产品来满足预期需求。相反，让产品具有可塑性，由领先用户根据他们的实际需求来塑造它。书中的例子包括但不限于软件产品。我最喜欢的例子是滑雪板。公司出货的滑雪板允许客户进行改装，观察改装的发生，将最重要和最通用的改装纳入出货产品，然后迭代这个良性循环。

在开发 Bram Studio 的过程中，我意识到我用 Bram 来指挥的智能体——主要是 Claude Code，有时是 Codex——正在以强大的方式运用 FFmpeg。在一篇关于其创造者 Fabrice Bellard 多才多艺成就的文章中，John Carmack 写道：

如今 FFmpeg 是互联网的无形引擎。YouTube 使用它。Netflix 使用它。VLC 使用它。Chrome 和 Firefox 使用了它的部分功能。每一部 Android 手机、每一部 iPhone、每一台智能电视、每一个你接触过的视频编辑工具，底层都在某处运行着 FFmpeg。如果你在过去 20 年里在屏幕上观看过视频，那就是 Fabrice 的代码在处理它。

Claude 对它在 Bram Studio 中使用 FFmpeg 的方式之一的解释。

你在某个场景的一部分上配音，你的声音恰好在那段时间内替换了该场景的声音。画面保持不变。这需要四次 ffmpeg 处理：清理人声。从播放开始的那一刻起，将录音剪切到实际说出的内容，然后进行降噪、高通和压缩：anlmdn → highpass=f=80 → acompressor (NARRATE_AF)。测量它。在仅测量的处理中运行 loudnorm=print_format=json。它只报告整体响度；不会改变音频。如果结果低于 –45 LUFS，则拒绝该次录制，提示“no speech was heard”。否则，将需要达到 –16 LUFS 的增益作为单个 volume=…dB 应用，然后使用 alimiter。将被替换的音频（atrim）保存在 media/.narrated/ 中，这样即使在其他编辑之后，旁白也可以稍后被移除。用一个 filter_complex 将其拼接进去：原始音频到开始处（atrim，然后 10 毫秒 afade out），新声音填充或裁剪以精确填满该段（apad=whole_dur，atrim=duration），然后从结束处开始的原始音频（10 毫秒 afade in），用 concat=v=0:a=1 连接。

这些 FFmpeg 的用法被固化在 Bram Studio 中，位于一个 Python 框架里，可以作为独立二进制文件的一部分交付。如果我走那条路，我会放弃 Python——它是一个部署难题——转而使用像 Go 或 Rust 这样适合单一二进制部署的语言。Bram 本身也发生过类似的事情。它最初使用 Python 来编写在智能体工具调用前后运行的钩子。这让可能没有安装 Python 的 Windows 用户的生活变得复杂。我心想，将这些钩子移植到 Rust——Bram 使用的主要语言（因为它基于 Tauri 框架）——会有多难？几个小时就完成了，Bram 摆脱了对 Python 的依赖。编程语言现在是可以互换的；大语言模型能看透代码的深层结构；它们能轻松可靠地在表面表示之间进行转换。

但单一二进制版本的 Bram Studio 不会是一个用户创新工具包；它将是一个预设应用，固化了关于如何使用 FFmpeg 的假设。当你使用 Bram 从其本地仓库运行 Bram Studio 时，你可以使用其预设的目标应用，但你也可以与智能体讨论你项目独有的音频片段。如果固化的调整不合适，你可以指示智能体测量电平，试验滤波器和限制器，并交付最优结果。

虽然这一切尚未发生，因为 Bram Studio 才诞生一周，但你也可以指示智能体提出 GitHub issue 来报告 bug 或建议改进。就像那些领头的单板滑雪者一样，你的修改可以推动核心产品的演进。

一个成为现实的自动化梦想

我一直想象有一天，一个工具能够读取原始屏幕录制、识别场景，并生成带有实用注释的精简剪辑录屏。今天就是那一天。我需要最后过一遍 Bram 的首个录屏来调整音频。为了测试自动化想法，我打开了屏幕录制，并在 Bram Studio 中一边操作一边讲解，同时摄像头也在运行。

然后，仍在 Bram Studio 中，我让 Claude 起草一个录屏。它可以使用的工具包括我电脑上的一切：当然是 FFmpeg，还有 Apple 内置的 Vision 框架和 Swift 编译器（我从未用过），以及 Bram 详尽的结构化日志，其中包含每一轮对话的时间戳。

尝试了几次，但结果令人惊叹：一个精简剪辑的两分钟视频，隔离并注释了那次最终音频调整过程中每一次 FFmpeg 的使用。

我需要为 Bram 制作一整套演示，而且由于它发展得如此之快，这曾是一个令人生畏的前景。现在这变得可行了，我迫不及待想要投入其中。当我以某种想要展示的方式使用 Bram 时，我可以打开屏幕录制并捕捉发生的一切。大多数录制都会是废片，这没关系。当我捕捉到值得展示的内容时，我会使用 Bram Studio 的对话模式自动创建初稿。然后我会切换到预制应用进行最终的注释、剪辑、停顿和旁白。而且由于我是 Bram Studio 的第一位也是最好的领头用户，我在此过程中学到的东西将推动一个良性改进循环。

这一切并不特定于 Bram 或 Bram Studio。它们只是恰好向我展示了，当明智地使用智能体将产品转变为用户创新工具包时，会是什么样子。每个软件产品都应该这样运作，我希望很快会有更多产品做到这一点。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：InfoWorld

原创地址：https://www.infoworld.com/article/4232736/screencasting-in-the-ai-era.html