录音不想反复听：用 Buzz 做一份可校对的逐字稿

Buzz 的核心价值：文字、时间、音频三位一体

“不是周四，是周五。”录音已经变成文字，这句话却还得回去听一次：到底是正式改期，还是说话人随口举了个例子？

这次拆的开源项目叫 Buzz。它值得看的地方，是把转写文字、时间位置和录音播放器放在同一个窗口里。找到可疑的一段，再回到那几秒原音，校对就有了落脚点。

先看实际结果：这份练习稿里，更改日期的一段从 00:17.040 开始。播放录音时点中这一行，进度跳到了这段附近；把第一句里的错字改掉，关掉结果窗口再打开，改动还在。最后导出两份文件：一份方便继续编辑的 TXT，一份带时间轴的 SRT。

安装与准备：选对版本，用好小样本

不过，准备这篇文章时也遇到了一个不能略过的问题：本机 Buzz 1.4.5 能转写，打开结果查看器却反复崩溃。对照测试官方 1.2.0 后，回放、编辑、重开和导出才跑通。下面的完整操作主线按实际跑通的 1.2.0 写；1.4.5 的失败放到后面说明，不混用两个版本的按钮和结果。

项目入口是 chidiwilliams/buzz。GitHub 在这里相当于项目的官方资料站，零基础读者不需要先读源码，也不用点那个绿色的 Code 按钮下载一堆代码。

从仓库进入 Releases，找到 Buzz 1.2.0 发布页。本次电脑是 Apple Silicon Mac，使用的安装文件为 Buzz-1.2.0-mac-arm64.dmg。打开 DMG 后，把里面的 Buzz 应用复制到本机，再从复制后的应用启动。Intel Mac 和 Windows 的安装包不同，请对照自己的系统选择；本文没有在这些平台重复测试。

这里使用旧版是一次具体的兼容性选择，不是“旧版一定更好”的建议。已经在用其他版本的人，先保留自己的历史记录和输出，不要为了跟这篇文章把旧程序直接覆盖到现有环境。本次旧版读取新版数据库时，曾因多出的字段拒绝迁移；测试保留了新版数据库，在单独的测试数据状态下重新导入音频。新装应用的读者不需要进行这种迁移操作。

Buzz 是 MIT 许可的开源软件。本篇选的是本地识别路径，不要求购买语音 API，也不需要填写 API 密钥。安装包和首次使用的模型仍需下载，模型会占磁盘空间；运行还会使用电脑算力。不要把“源码免费”理解成没有这些成本。

配套材料里有两段音频：buzz-short.wav 约 28.5 秒，先用来确认流程；sample.mp3 约 2 分 15 秒，用来做完整校对练习。它们是本地 Qwen 生成的原创教学录音，内容是一次模拟分享会安排，不是真人会议。

第一次用自己的录音，也先截一小段：有正常说话声、句子完整，最好带一个你熟悉的人名或数字。先用播放器确认文件能打开、有声音，再交给 Buzz。不要一开始就把一小时录音放进去，出了问题却不知道是文件、模型还是设置造成的。

首次转写：只选对这四项关键设置

打开 Buzz 主窗口，点左上角的 “＋”新增文件，在文件选择框里找到 buzz-short.wav，选中后点 Open。文件选中不等于任务已经开始，接下来会出现一个以文件名为标题的设置窗口。

先看模型区域。第一行选 Whisper.cpp，第二行选 Base。前者是本次使用的识别后端，可以理解为负责运行识别工作的那套程序；后者是模型规格。Buzz 把这些选择放在界面里，让你不用自己拼接命令。

这里用 Base 是为了先跑通小样本，不是因为它已经足够准确。本次结果里，同音词和人名都有错误。也不要把 Base 和 Base.En 混为一谈：当前练习是中文，按图中的 Base 选即可。

“任务”选 Transcribe，也就是转写，把说出来的话写成文字；不要选 Translate 翻译。我们要保留原话，不能让输出在第一步就换成另一种语言。“语言”选 Chinese。本机这个版本有些标签是中文，有些选项保留英文，截图就是实际显示的样子。

本次先不勾“逐词识别”。这里的目标是按片段校对，不需要先处理每个词的时间。高级设置也先保持原样。这里还专门试过加入“以下是普通话录音的简体中文逐字稿。”作为初始提示，但本次仍输出了繁体字，所以没有把它当作可靠的繁简开关。底部同时勾选 TXT、SRT，再点“开始执行”。如果模型还没有缓存，先等模型下载完成；下载模型与识别录音是两件事，不要看到等待就连续新增同一个任务。

任务完成后，主列表会出现文件名和完成状态。点选这一行，再点工具栏的“打开识别结果”图标，就能看到带“开始、结束、文本”三列的结果窗口。第一次成功的标准很具体：文件没有报错，文字确实来自这段录音，播放器能加载相同的原音。

本机旧版列表曾把短片段耗时显示为“0s”，完整录音显示为“3s”；完整任务从加入到输出文件落盘实际约 14 秒。这些计时口径并不相同，不能据此写成“几秒转完所有录音”。你的电脑、模型缓存和音频内容也会影响等待时间。

机器初稿不可直接交稿：四类关键信息必须校对

短片段的第一句就很能说明问题。源稿是“用来练习录音转写和逐字稿校对”，实际输出里的错误，换成简体引用是“用来练习录音转写和逐字搞交对”。第二句里的“人名”，又变成了“人民”。

繁体字本身不是听错；同音字改变了意思，才是这里需要处理的问题。为了让演示方便阅读，本篇在 Buzz 编辑器里逐段统一了简体，保留原始稿作为对照。操作就是双击右侧文字、输入简体内容，再点别的行提交；没有替换模型输出的原始证据。先把全文转成简体，并不能自动修复“人民”与“人名”。把输出排得整齐，也不能让它变得更可靠。

Buzz 在这里负责把几个环节接起来：读取音频，交给识别后端，把带起止时间的文字片段放进查看器，再提供编辑和导出。真正“听声音、猜文字”的工作由模型完成。界面好用，和模型每个字都听对，是两回事。

为了确认这条路径，本次阅读了 1.2.0 的 Whisper.cpp 调用代码：文件先加载成音频数据，再调用 Whisper.cpp，读取每个片段的文字与起止时间，转换为毫秒。这里说的是本次选中的后端，不代表 Buzz 的所有模型都用同一套实现。

时间戳像书签，作用是让你回来得更快。它不证明句子准确，也不保证每个片段恰好对应一个完整句子。完整样本中，“签到安排”和“会议室地点”就被放在同一段里；如果只截取其中几个字来理解，很容易丢掉前后关系。

校对四类关键信息：人名缩写、日期数量、否定条件、说话人更正

短片段跑通后，再用相同设置导入 buzz-full.mp3，也就是完整练习音频。本次 1.2.0 输出 25 段，从开头的模拟说明一直覆盖到结尾；源文件长约 134.67 秒，最后一段结束时间写到 134.92 秒。时间边界有轻微偏差，因此这里采用“能定位的转写初稿”，不把它叫作精确到每个音节的成品。

下面的对照来自实际输出与合成源稿。源稿能告诉我们原本准备表达什么，但不能替代对生成音频的听审；配套纠错表也保留了这个区别。

第一类是人名和缩写。 在 00:31.800 开始的一段里，源稿写“陈澄，耳东陈，清澈的澄”，识别结果却是“陈成、耳东陈、清澈的成”。连解释姓名用字的提示都写出来了，最后那个字仍然可能错。遇到真实人名，要回听，也要对照名单或本人确认，不要只凭哪个名字更常见来选择。

00:55.360 那一段，资料页数“12 页”保留下来了，文件格式却写成 PDIF。本例源稿用中文注音表示 PDF，这正好提醒我们：缩写的声音、识别出来的字母和实际文件格式，需要分别核对。修正文稿时写 PDF 可以，但纠错表里应说明依据。

第二类是日期、数量和金额。 本次“9 月 11 日下午 3 点”“18 人”“20 份资料”和“1200 元”都能在原稿中找到。不过数字出现了，不等于关系就已经核对完。18 是参加人数，20 是资料份数，多出的 2 份是备用；把它们整理成“共 20 人”就改了意思。

金额也是一样。原话说打印和茶水的合计预算上限是 1200 元，不是每个人 1200 元。实际识别把“打印”写成了“答应”，但“不是每个人”仍保留着。校对时既要修正错词，也要保留预算适用的范围。

第三类是否定和条件。 “不要直接去三楼”“不要只靠加快语速”“不要把所有材料只放在一个需要联网的链接里”，每一句都包含实际限制。逐字稿里少一个“不”，可能比多一个逗号严重得多。先查会影响执行的词，再处理标点和繁简统一。

第四类是说话人自己更正的地方。 日期段落保留了“原来暂定周四，后来改了，不是周四，是周五”。通知截止时间也保留了“不是上午 10 点，是中午 12 点”。如果目标是逐字稿，就应该留下这种更正关系；如果下一步要写通知，可以另做一份摘要，只写最终有效的时间。

机器初稿、校对稿、摘要，最好分成三个文件。初稿保留机器当时写了什么；校对稿尽量忠于声音；摘要再做归纳。这样以后有人问起“这句话怎么来的”，还能找到原音和修改依据。

操作闭环：选中→回放→修改→重开→导出

回到完整录音的结果窗口。左边两列是开始和结束时间，右边是文字，底部是播放器。在本次跑通的 1.2.0 里，先点播放，再点选要核对的那一行。 只在暂停状态下点选文字，不要直接当成已经完成了定位。

本次先开始播放，再点日期更正那一段，进度从前面跳到了约 17 秒处，随后在这段范围内循环播放。测试截图截在约 20 秒的位置。对应的查看器代码确实只在播放状态下设置段落范围；播放器代码会定位到范围起点，播过终点再回到起点。

这个动作的用处很朴素：不用为了核对一个名字，每次都从头再听一遍。需要前后文时，可以拖动播放条离开当前循环范围，听相邻部分；不要把软件给出的分段当成语义的绝对边界。

要改文字，先暂停，双击右侧需要修正的文本单元格。这里演示第一句：把“逐字搞交对”修正为“逐字稿校对”，并把这一句统一为简体和中文标点。编辑结束后，点一下别的行，离开输入框，让这次修改提交。

接着做一个很小、但值得养成习惯的检查：关闭结果窗口，回主列表再次打开同一条记录，看修改后的句子还在不在。本次重开后，修正仍然保留。不是看到光标离开输入框就算保存成功，也不要直到关掉电脑后才第一次检查。

配套材料保留了最初的 buzz-full-one-line-corrected 单句修正示例。按简体演示要求，随后在 Buzz 里把完整稿的 25 段逐段统一为简体；第二段视频接着把“人民”改回“人名”，关闭重开后导出 buzz-full-two-lines-corrected。这份文件演示了前两句的文字修正，其余段落只统一字形，仍保留识别错误，方便继续练习；它不是一份已经逐秒听完的校对成品。

导出：TXT 用于编辑，SRT 用于时间轴复用

在结果窗口上方点“导出”，可以看到 TXT、SRT、VTT。先选 TXT，在保存框里改一个与原稿不同的文件名，再点 Save。接着重复一次，选择 SRT。简体演示最终保存的是 buzz-full-two-lines-corrected.txt 和同名 .srt，原始自动输出文件继续保留。

TXT 适合复制到文档里继续编辑。SRT 是字幕文件，里面除了文字，还保存每一段的起止位置。它并不复杂，开头一段长这样：

1
00:00:00,000 --> 00:00:05,360
这是一段模拟工作说明，用来练习录音转写和逐字稿校对。

第一行是编号，第二行是开始和结束时间，第三行是这段文字，空一行后进入下一段。逗号后面的三位表示毫秒。你不用手工重写这些时间戳，正常导出就会带上。

导出后用文本编辑器重新打开文件。至少看三处：开头是不是刚才改过的句子，中间的数字与更正关系是否还在，结尾是否出现“这段模拟说明到这里结束”。本次两个导出文件都保留了第一句的修改，SRT 的段落编号和时间顺序也通过检查。

练习包里同时放了源录音、合成源稿、机器原稿、单句留档、简体修正示例和关键字段纠错表。使用时先听音频、看原稿，自己尝试修改，再参考纠错表；不要先把源稿直接贴成“识别结果”。有原音、有原稿、有修改记录，稿子才方便复核。

故障排查：分清是模型、文件、界面还是网络层问题

如果卡在模型下载，先看下载是否还在进行、磁盘是否有空间，以及网络能否访问模型来源。换一份录音不会修复模型没有下载完成的问题。等下载结束，再用短片段检查一次。

如果任务报错或播放器不能加载，先确认原文件在普通播放器里能打开，再用短 WAV 或 MP3 做对照。不同格式的读取路径可能不同，不要只把扩展名改成 .wav 就当成转换了格式。

如果有文字但错得多，先回到那几秒原音，检查说话声是否清楚、有没有重叠说话，再考虑换模型比较同一片段。每次只改变一个条件，保留模型名称、输入文件和输出，才知道变化来自哪里。本篇没有测试多人会议、嘈杂环境和方言，不能把合成单人样本的表现推广过去。

还有这次实际遇到的界面问题：在本机 macOS 26.6.2 上，1.4.5 的转写可以完成，但结果查看器反复触发 Qt 辅助功能相关崩溃；重启和切换输入法没有解决。官方 1.2.0 的独立副本在重新导入样本后跑通了查看器。本篇没有证明所有 Mac 都会遇到这个问题，也没有把降级写成万能修复。遇到同样现象，先保留已导出的 TXT/SRT 和日志，再考虑用独立环境对照，避免丢掉已有记录。

“本地识别”也只说明本篇选中的语音处理路径。模型下载、更新检查以及其他可选功能可能联网；本次没有完成断网或网络抓包验收，因此不作“整个应用完全不联网”的承诺。

下一份录音的操作清单

Buzz 帮你省掉的是一部分从头寻找位置、手工打字和整理时间轴的操作。最终那一句是否准确，仍然要回到声音和可核实的材料。

下一次可以沿用这条顺序：保留原音，先跑一小段；设置确认后转完整录音；优先查人名、缩写、日期、数字、否定和更正；把可疑处放回前后文；修改后重开，再导出独立文件。

听不清的地方先写“待核”。一份诚实保留疑问、能回到原音的稿子，比一份读起来很顺却找不到依据的稿子更好用。

JOTO 企业落地观察

• 企业部署语音转写工具时，需明确区分“自动化能力”与“人工校验责任”——Buzz 提供的可回放时间戳是校验锚点，而非准确率担保，这对建立可审计的智能体工程交付流程至关重要。
• 当企业知识库需接入会议纪要类非结构化语音数据时，Buzz 这类本地化、可校对的 RAG 前置处理链路，比纯云端 API 更利于满足敏感数据不出域与修改留痕的治理要求。
• 版本兼容性问题（如 1.4.5 查看器崩溃）暴露了开源工具在企业环境中面临的现实挑战：FDE 驻场共创需提前验证 GUI 组件稳定性，而非仅关注模型精度指标。
• 文中强调的“机器初稿、校对稿、摘要三分离”原则，可直接映射为企业 AI 安全治理中的“输入-过程-输出”三层审计要求，确保每处修改均可追溯至原始音频证据。