Appearance
旧笔记本跑 Whisper：我把一周会议录音转文字的真实流水账
公司内网政策写得很清楚：客户相关会议录音不得上传公有云转写。以前我们靠人工记要点，或者我私下用付费转写再删账号——心里一直不踏实。三月某周五个会连轴转，我索性把吃灰的 2019 款笔记本翻出来，装开源 Whisper，整周录音只在本地磁盘上转。
这篇是按天记的流水账，不是安装手册。装环境那晚上踩的坑只写结论：Windows 上先用官方 Python 环境，ffmpeg 路径写进 PATH，medium 模型在 CPU 上约等于 1:3 到 1:5 的实时比。细节网上很多，我不重复。你要看的是：转出来的字能不能当纪要用、哪天的结果是废纸。
先交代为什么不用公司买的某云会议自带转写：Admin 关掉了存储到境外 region 的选项，而本地部署的 enterprise 方案排期在 Q3。等不起，只能 DIY。DIY 的代价就是这篇流水账里的风扇声和周二那 45 分钟回听。
设备：i5-8250U，16GB RAM，无独显，512GB SATA 盘。录音来源：手机 Voice Memos 导出 m4a，采样率 44.1kHz，单声道混音。
周一：产品对齐会，32 分钟
操作：Whisper medium，语言指定 en（会里中英夹杂，但主干英文）。
耗时：上传准备 negligible；转写约 98 分钟。我在会上就料到会久，笔记本风扇拉满，同事笑话像起飞。
结果质量：英文段落可用率大约八成。专有名词挂了：把客户产品名 Codexa 听成 Codex，把内部项目名听成两个词。中文插话部分变成拼音碎片或乱码，不如直接标 [CN segment unclear] 后自己补。
当日决策：专有名词表单独建 txt，下次转写前粘贴进 initial prompt（Whisper 不支持真 prompt，我用的是 faster-whisper 的 hotwords 实验脚本，效果有限但比没有强一点）。
是否可当纪要：修 20 分钟后能发给组内。不能对外。
周一晚上我试着把 txt 丢进对话模型要「三条 action items」。模型从错误听写的 Codex 里编了一条「联系 Codex 团队」——二次幻觉。现在规定：转写 txt 可以进 AI，但 AI 输出必须逐条对回 timestamp 回听，和 把 PDF 丢给 AI 问问题 里写的「硬信息要核对」是同一纪律。
周二：客户故障复盘，58 分钟——几乎翻车
操作：同上，但会议室回声大，手机放桌上录。
问题：Whisper 把一半句子断错行，多人抢话时 说话人全混成一个。更糟的是，有一段把 background 里的「maybe we rollback」听成「maybe we roll back the contract」，我差点把错误结论写进纪要。
耗时：转写 2 小时 40 分；人工听回关键 8 分钟又花 45 分。
教训：
- 回声环境 不值得信 first pass，必须对数字、rollback、日期类词人工回听。
- 故障会 必须戴指向麦或电脑直连录音，手机外录降级一档。
这篇流水账里，周二是唯一一天我写了「转写结果作废，仅保留时间轴」的。
周二深夜我差点把转写 txt 直接贴 Slack。幸好预览时看到 contract 那句——Slack 一旦出去就收不回。后来我在 Obsidian 模板里加了一行红字：故障会转写：发送前 8 分钟回听 mandatory。流程丑，但比道歉邮件省事。
周三：1:1，17 分钟
操作：model 降到 base 试速度。
耗时：转写 22 分钟。
质量：口语、单人、近距离，错误率明显下降。但 base 把两个技术术语听糊，我又用 medium 只重跑术语出现的 3 分钟片段（手动 ffmpeg 切条）。
发现：短会 + 单人 → base 够；长会 + 多人 → medium 起步。切条重跑比整段重跑省时间，是我这周摸索出的最实用技巧。
周四：跨部门评审，41 分钟，含屏幕共享
操作：medium；录音里夹杂 Zoom 系统声的 ding。
Whisper 行为：把 ding 标成括号噪音还好，偶尔把 ding 后面的半句吞掉。屏幕共享时有人指「看左边图表」，转写只有 look at the chart，left 丢了——对纪要影响不大。
耗时：转写 1 小时 55 分；编辑 35 分。
产出：按时间戳分三段：决策 / 开放问题 / 行动项。行动项必须人工标 owner——Whisper 不会告诉你谁接话了，除非你会里点名。
和 用 AI 做会议纪要 不同：那篇是流程设计；这里是 离线 Whisper 的粗糙输出长什么样。
周五：站会合集，5 段共 23 分钟
操作：batch 脚本 overnight 跑 small（想省时间，错误增多）。
结果：站会快、信息密度低，small 勉强够。有一句「blocked on API quota」听成 blocked on AP I quota，不影响理解。
overnight 的意义：周五下班开转写，周一早上收文本。旧笔记本合盖插电，Windows 睡眠策略改成从不。
一周汇总（给自己看的表）
| 日 | 录音时长 | 模型 | 转写耗时约 | 可直接用？ | 人工补时 |
|---|---|---|---|---|---|
| 一 | 32 min | medium | 98 min | 修后内部可 | 20 min |
| 二 | 58 min | medium | 160 min | 否，关键段回听 | 45 min |
| 三 | 17 min | base+片段 medium | 22+8 min | 是 | 10 min |
| 四 | 41 min | medium | 115 min | 修后可 | 35 min |
| 五 | 23 min | small | 40 min | 站会够 | 5 min |
总录音 ~171 分钟；总机器转写时间 ~7 小时（含周二）；总人工 ~115 分钟。
若你期待「一键完美纪要」，这组数字会劝退你。若你接受 机器出草稿、人做核对，旧硬件也能闭环。
我固定下来的流程（第五天才稳定）
- 会中：手机仅作备份；重要客户会改用 笔电本地录（Audacity 或 OBS 只录音频轨）。
- 会后 10 分钟内：文件命名
YYYYMMDD-topic.m4a，丢进 inbox 文件夹。 - 每晚：batch 脚本 medium，输出 txt + srt；srt 只为跳转，不对外。
- 编辑时：先标 action items 和日期数字，再润色句子；never 先润色再找数字。
- 敏感词：客户名、金额出现处 100% 回听，不信任 first pass。
- 存档：音频 90 天后删，txt 留 Obsidian，链接到项目页。
没有上说话人分离模型——试过 pyannote，CPU 上太慢，且对我们这种 3–5 人小会收益不成比例。
周末：我是否还会用这套
周六把笔记本清灰，换硅脂，转写速度体感提升一截，大概 10%，不是魔法。周日重听周二那 8 分钟，确认 rollback 那句是幻听，把 wiki 里的 mandatory 回听保留。
周一开始第二周：我会继续 batch，但 客户会一律笔电录 + medium，站会用 small 无所谓。若项目结束、合规放开，我可能仍会保留本地链路处理最敏感的那一类录音——习惯已经养成了，且 Tuesday 那种错够我记很久。
和云端转写比，我得到了什么、失去了什么
得到：数据不出本机；无订阅；长录音不担心按分钟计费；能反复用不同 model 重跑片段。
失去：实时字幕；说话人标签；手机 App 一键分享；英文口音多样性下的鲁棒性（云端大模型有时更稳）。
我们合规要求选本地。若你可以上云，未必需要复刻这条苦路；若你不能，Whisper 仍是 可接受的草稿机，不是书记员。
硬件诚实建议（基于这台 i5，不是 benchmark 文）
- medium：质量与速度平衡点；长会就挂着别指望实时。
- large：在本机未试——RAM 和耗时都不友好。
- GPU：有独显会质变；我没有，所以不装 CUDA 教程忽悠你。
- 磁盘：medium 模型约 1.5GB；一周 txt 几 MB；音频才是大户，记得删。
周二那次 rollback 听错，后来怎么写进纪要
最终纪要里写的是：Team discussed rollback as one option; decision deferred pending API vendor ticket #7842。没有写 roll back the contract。那一句是 Whisper 加戏，人是靠回听拦住的。
我写进团队 wiki 的提醒是：任何涉及 legal / contract / rollback 的词，转写稿只能当索引，不能当证据。证据仍是录音本身或官方 Slack 记录。
若你只想知道「值不值得折腾」
- 一周 3 以下短会、且无合规限制 → 云端可能更省命。
- 一周 5+ 场、含客户、且不能上传 → Whisper 值得，但要配 人工核对预算。
- 期望零编辑 → 别装，会继续失望。
我下周仍用同一台笔记本。可能加一块外置 SSD 专放音频，别拖慢系统盘。说话人分离暂时放弃，等换带 GPU 的机器再说。
后记：没有最佳模型，只有最匹配的会
Whisper 不是 AI 助手那种「聊一下就好」的产品。它像一台 脏活机器：吃时间、吃电、吃你的耐心，吐出带刺的 plaintext。把这周流水账记下来，是为了下次有人问我「本地转写行不行」，我可以直接甩周二——行，但有一天你会几乎翻车。
若你也有一台旧笔记本和一堆不能上云的 m4a，希望这组数字比「准确率 95%」的营销话更帮得上忙。数字不好看，但诚实。
可复制：我的 batch 脚本在做什么（概念级，非代码教程）
脚本逻辑只有四行人话：扫描 inbox 里未处理的 m4a → 调 faster-whisper medium → 输出同名 txt 和 srt → 把原文件挪到 processed 并写一行 log（时长、耗时、模型）。失败就写 error.log，不 silent fail。我不用 GUI 工具，不是鄙视 GUI，是 需要 overnight 无人值守。你若只偶尔转一条，Whisper Desktop 类程序可能更省心——路径不同，纪律相同：数字和 rollback 仍要回听。
问同事时他们常问的两句
「准确率多少？」 我会说：产品对齐会八成可用，故障复盘会零信任。不是一个数字。
「要不要买 Mac Mini 专门转写？」 我说：先算你一周几小时录音、是否 GPU。我暂时用旧本 + 时间换钱；若每周 10 小时以上客户会，再算硬件账。
两句答完，对方要么放弃，要么回去清灰。这两种都是诚实结果。