要点速览
一段跑好几个小时的录音，转出来的文字稿没有人会从头读到尾，所以真正的目标不是一份干净的文档，而是一份你能搜索、并且能随时跳回音频对应位置的文档。分段要按讲次或话题来切，不要切成等长的几块；时间戳一定要保留；随着现场情况变化，识别质量会有起伏，这很正常；另外，在撞上一个你根本不知道存在的上传体积上限之前，先把视频里的音频单独提取出来。
大多数关于转文字的建议，默认你手上是一段通勤路上就能听完的文件——二十分钟，顶多四十分钟。这类建议本身没什么问题，直到你面对的是一整天八小时的会议录音、一整个系列被拼进同一个文件里的讲道，或者一场谁都不想结束的访谈。到了这个长度，问题并不只是“原来的麻烦放大了几倍”。它们是另一类问题，而通行的建议常常意识不到这一点。
人的第一反应是问：怎么才能把整段东西都转成文字。更值得问的是：转出来之后，你打算拿它做什么。因为没有人会把一份四万字的文档从头读到尾。这么长的内容真正需要的并不是“完整”，而是“能重新找回去”的能力。
长度到底会压垮什么
短录音会替自己掩盖限制。上传体积上限、核对文字稿要花的精力、成品文档最后长成什么样——在五分钟的素材上，这些都无关紧要。把同一段录音拉长到五个小时，这些限制会一起冒出来。
- 短文件永远碰不到的上传体积上限
- 核对文字稿所需要的注意力——面对的是几个小时的音频，而不是几分钟
- 一份长到没有人愿意从头读到尾的成品文档，包括你自己
这个临界点并不是一个固定的分钟数——它取决于录音本身、麦克风的情况，以及你对里面的内容已经了解多少——但方向对所有人都一样：超过某个长度之后，输出的组织方式开始和准确率一样重要。这并不是说长录音没法转写，而是说目标必须改变。短录音追求的是一份干净的文字稿；长录音追求的是一份能导航的文字稿——可以搜索，分成有意义的段落，把你以后真正会用到的地方标出来，方便再找回去。如果想在投入一整个下午之前，先大致知道这种体量的文件要处理多久，转写时长计算器可以先给你一个粗略的估计。
时间戳才是让长录音撑得下来的东西
光靠搜索，你只能拿到文字，拿不回音频。在短录音上这几乎无所谓——两分钟就能把整段扫一遍，搜索不灵的话靠耳朵也能找到那一刻。可是在八个小时的录音里，在文本里找到一句话，几乎说明不了你该在播放器的哪个位置点下去，除非文字稿带着和音频对得上的时间戳。
时间戳把文字稿从“用来读的文档”变成“用来使用的文档”。有了它，你可以把文本当作录音的索引，而不是录音的替代品：找到那句话，记下时间，把播放器跳过去，在上下文里听一遍——这一层信息，光看文字是给不全的。没有时间戳，长文字稿只能被搜索，却回不去：你知道那句话就在里面某个地方，却没有高效的办法回到它被说出口的那一刻。在这种体量的文件上，这不是一点小小的不便，而是“一份帮你省时间的文字稿”和“一份只是把麻烦挪了个地方的文字稿”之间的区别。
如果你已经预感到这件事会反复做——从几个小时的素材里挑出特定片段，用来写报告、整理笔记，或者只是帮自己记住——那就值得早点养成习惯。关于如何在长录音里找到某个瞬间的那篇指南，写的正是这类活儿。
按内容切，不要按体积切
让长文件变得好处理，最直觉的做法是把它切成等长的几段——比如一小时一段，或者上传工具喜欢多大就切多大。这个念头要压住。等长切分做起来容易，导航起来几乎没用，因为第三段和第四段之间的那条界线，和当时在讲什么毫无关系。它只是时钟刚好走到了那里。
换个切法，按真正发生变化的地方切：
- 按讲次切，如果这一天是由若干场彼此独立的演讲组成的
- 按讲道切，如果这是一个系列被录进了同一个文件
- 按话题或发言人切，如果这是一场长访谈或者圆桌讨论
这些分界线就是你的目录。当以后有人问起第三场演讲讲了什么，或者系列里第二篇讲道说了些什么，你需要的是一条对应这个问题的界线，而不是一条对应“六十分钟过去了”的界线。这样分段还有一个好处：它们经得起时间考验，哪怕几个月后你带着完全不同的问题回来翻这段录音，它们依然管用。无论是在转写之前标记这些位置，还是在检查输出时顺手标上，多花的那几分钟，在你第一次急着找东西的时候就赚回来了。
几个小时里质量会漂移，校对也该跟着走
跑上几个小时的录音，很少能从头到尾保持一致。有人中途挪了麦克风。房间里人越来越多，声学环境跟着变。讲话的人转身去指幻灯片，那一段的声音就比一分钟前对着麦克风说的话薄了不少。这些都不是转写本身的毛病——它们是录音的事实，而文字稿会相应地在不同段落之间参差不齐：有些地方清楚，有些地方粗糙，有时候在同一段里就能看出差别。这种不均匀值得事先预料，而不是事后惊讶——它会告诉你，手上有限的核对时间该花在哪儿，而不是把整段录音当成同样可信，或者同样可疑。
只修重要的地方，不是修所有地方
把一份长文字稿从头到尾读一遍来纠错，通常并不值得花那么多时间。这么长的录音，实际上几乎不可能被均匀地核对——你会反复啃某些段落，另一些则再也不会看第二眼。所以，不要按顺序逐字读下去找错。找出你真正会引用、会拿去作依据、会据此做决定的那些段落，把这些具体片段对着音频核一遍。其余部分就留着，当作一份粗糙但可搜索的记录。如果你更希望一份文档“处处正确”，而不是“大体正确、马上能用”，这个取舍会让人不太舒服。但把每一句话都看得同样值得核对，正是一份八小时录音的校对能吃掉你一整天、换来的精度提升你大部分永远用不上的原因。
在文字稿之前，文件本身就是个问题
长录音会撞上一个多数人想不到、直到被卡住才发现的限制：文件体积。整整一天会议的视频是个大文件，而大多数上传通道都有一个上限，哪怕它没有写在什么显眼的地方。同一段录音如果只保留音频——把画面剥掉——体积会小得多，往往小到足以通过一个视频版本根本没机会通过的门槛。
如果你要的只是文字，那就在上传任何东西之前，先把音频提取出来。你失去的是画面，而只要本来就没人打算回看这段录音，这几乎没有代价；换来的是一个真的进得去门的文件。很多时候，“长录音顺利转成文字”和“上传到一半失败、原因和转写本身毫无关系”之间的全部差别，就在这一步。音频转文字这条路正是围绕这一点设计的：喂给它音频而不是视频，体积问题往往就自己解决了。要把下一个长文件从头到尾处理完——说话人标注、摘要和文字稿放在一起——可以直接下载 iOS、Android 和 macOS 版本。
摘要替你做不了的事
长录音的摘要确实有用，但它回答的是和文字稿不一样的问题。摘要告诉你大致发生了什么——有意思的段落在哪儿，主要脉络是什么。它没法告诉你某个说法的确切措辞、两件事实际的先后顺序，也没法确认你隐约记得的一句话是不是真的在里面。这些要靠文字稿，一份带时间戳、分好段落的文字稿，而不是拿一段描述来顶替原物。
把摘要当地图，把文字稿当地形。如果这段录音你不熟悉，先读摘要——它会指给你值得花时间的部分。然后针对那些具体片段去看文字稿，而不是要么把全文读完，要么指望摘要已经把你以后需要的东西全都收进去了。它通常没有，这不是因为摘要做得差，而是因为八个小时的内容压成摘要，必然只剩下所讲内容的一小部分，而你最后需要的那点东西，很有可能就住在被略掉的那一块里。这不是在批评摘要——摘要本来就是干这个用的，指望它顺便把文字稿的活儿也干了，才是失望的来源。
