THE SLOW LIFE GAZETTE如何把录音沉淀为知识资产

很多人所谓的录音文件"知识管理"，只是把声音换了个地方吃灰。

录音最大的问题不是存不下来，是用不起来。

它只能从头放，想找个点得来回拖进度条，更别说改、引用、或者丢给 AI 整理。一节课里讲到一个有用的方法，一次分享里冒出几个值得展开的观点，一场会议里留下一串决定和待办——它们都还在声音里，要用，得先找出来。

所以我把录音变成资料的第一步，永远是先转成文字。文字稿准备好以后，内容才方便搜索、提炼和引用，也方便让 AI 帮我整理方法、归纳观点、生成文章素材。

转写本身有不同路径。我会先看录音有多大、内容适不适合上传、转出来以后准备怎么用。条件不同，工具选择也不同。

下面三条，基本覆盖我遇到的所有情况。

短录音，先上云端工具

如果是课程片段、临时会议，或者随便一段访谈，这个时候开一个网页版 AI 特别方便。省去装模型和配环境的麻烦，先拿到一份文字稿，后面再决定怎么整理。

网页版 AI 这边，可以把音频交给支持音频输入的多模态大模型（除了读文字，也能处理图片、音频、视频）。豆包、Kimi、Gemini 都可以试，前提是用的入口支持对应音频文件。

任务最好说清楚——比如直接告诉它：先把音频完整转写，再提取三个重点，把人名、数字和专业名词单独标出来。也可以让它整理成会议待办，或者改成一份文章素材。这种方式适合快速拿结果，但涉及引用、数字和专业名词时，仍然需要回听原始音频。模型能省掉大量重复播放的时间，不能替你确认每个字都准确。

如果只是想要一份干净的逐字稿，飞书妙记是另一种选择。录音小于 20 分钟的，我一般走飞书 CLI 调用（就是用命令行批量调，比网页端一个个传快；不想敲命令，直接用飞书妙记网页版也一样）——把音频丢进去，等它生成文字记录，再导出来继续校正。

文件接近 100MB，先切分再转

录音接近 100MB 时，网页入口、豆包或 Kimi 可能卡在文件大小、录音时长或上传权限上。这种时候，就需要先把文件切小。

先保留原始录音。再在电脑上把它切成若干段，每段控制在 20 分钟以内。文件名按顺序标好——第一段、第二段、第三段。

切分时尽量只做分段，不要反复压缩原音频，后面回听和核对时间会方便一些。

切好以后，把片段分批交给飞书妙记（同样走 CLI）。每段生成文字记录，按原来顺序导出，最后合并成一份完整逐字稿。原始录音、分段文件和文字稿最好分开保存，之后某一段有问题，还能单独回查。

如果录音里有多人说话，分段后还要留意说话人编号。第一段里的 Speaker 1 和第二段里的 Speaker 1，可能对应不同的人。合并时要结合上下文和原始音频重新校准，不能只按编号拼接。

觉得麻烦，也可以把这套流程交给 Agent（一类能调用文件和工具、替你执行一串步骤的 AI 助手）。只要它接入了本地文件处理和相关音频工具，我可以直接告诉它：保留原始录音，把文件切成每段不超过 20 分钟，按顺序命名和上传，导出文字后合并，并检查说话人编号。

这样做的好处，是不用自己记每一个操作细节。Agent 能连飞书妙记或其他工具时，还能继续帮你完成批量上传和结果整理。但最后的事实核对，仍然要我自己来。

敏感内容或长期处理，上本地模型

录音里有不方便上传的内容，或者以后会反复处理大量音频时，这时候可以考虑本地转写。音频和模型都在自己电脑上跑，文件不传到远程服务。

本地转写，要先选语音模型。Whisper 有 tiny、base、small 等不同版本，速度、占用资源和识别效果各有取舍。Qwen3-ASR-0.6B 是围绕语音转文字做的轻量模型，中文友好，也适合塞进具体本地工作流。

Buzz 这类桌面工具，把音频导入、模型选择、转写和导出放进一个界面。适合不想一开始就碰命令行和运行环境的人。我用它处理过电脑系统声音，最后拿到一批能直接打开和搜索的文字稿。

愿意自己配环境，也可以直接部署 Whisper 或 Qwen3-ASR。

这套方案也有自己的局限——对设备硬件要求相对较高。模型要下载，电脑得有存储和算力，长录音搁普通 CPU 或者 GPU 上跑，可能等很久。好处是文件不会泄露，不用担心隐私问题。

总结

前面三条路径，浓缩成一张表：

转写完，文字稿还要再过一遍

自动转写出来的文字稿，还需要检查一遍。

人名容易听岔，专业词常变成同音字，数字和单位也得重新核一遍。多人对话里的说话人标签能帮阅读，不能直接当正式记录。这种时候可以考虑使用大模型来整理。

我会保留原始录音和原始转写稿，再另外写一份整理稿。原始稿是档案，整理稿才是资产。 整理稿负责让你的下一次阅读更方便——课程整理成课程笔记，会议整理成决定和后续动作。我习惯在整理稿文件名里加标签，比如「2026-访谈-产品方法论-待写稿」，以后 AI 搜文件名就能把几年前的观点捞出来用。

最后

我现在处理录音，会先按场景分配路径：短录音先用云端入口，文件大了先切分，内容敏感或长期处理再考虑本地模型。转写结束以后，重要信息回到原始音频核对，文字稿才有机会变成能搜索、能引用、能继续使用的知识资产。

越这么做越觉得，语音转写这活，天生该交给垂直小模型。

转写、翻译、字幕、输入法，每个环节都有专门的小模型去做，做得更稳。再由一个大模型把它们串起来——理解上下文、提炼重点、整理文章，把一整个任务跑完。大模型管编排，小模型管干活，这样搭配性价比最高。

随着小模型越来越聪明，这种垂直领域的小模型，往后会越来越重要。未来的样子大概是这样：一个大模型，带着几个小模型干活。