会议录音不能上云时，怎样把听写服务留在局域网：LymeScribe 的主机与客户端拆分
语音转文字常被误当成一个“选模型”的问题：挑一个识别率更高的云 API，再把音频传过去。但在客户访谈、内部复盘、招聘面试或含代码讨论的会议里，真正先需要回答的问题往往是：音频是否可以离开办公室？谁保留原始录音和转写文本？网络断开后流程是否仍可用？
LymeStack 推出的 LymeScribe 选择了另一条路线。它把 Whisper 系列模型放在用户拥有的 Mac 或 Windows 机器上运行；桌面客户端负责听写与查看结果，另一台你控制的机器也可以充当局域网里的转写主机。官网将两种托管规模分开：一台电脑可服务少量可信设备；面向办公室的 Server 则运行在自有 Windows/NVIDIA 或 Apple Silicon 硬件上。这里的关键不是“有一个本地模型”，而是把音频、推理和文本存储一起留在可管理的网络边界里。
先区分三个角色，而不是急着把它装到所有电脑
部署前可把需求拆成三个角色：说话的人、发起转写的客户端，以及承担模型推理的主机。个人使用时，三者可以是同一台笔记本；小团队更合理的做法是让一台性能较好的机器做主机，其他同事只用客户端连接它。这样既避免每台设备重复下载模型，也更容易统一升级与保存策略。
LymeScribe 的免费桌面应用可以连接服务端；将自己的电脑作为小规模主机属于其付费 hosting unlock。产品页还说明，办公室 Server 面向较多并发用户，采用 GPU 加速；不要把这两个层级混为一谈，更不要仅凭“本地运行”就假定旧电脑可承担多人实时请求。官方对长录音与说话人标注给出了明确边界：Mac 建议使用 M2 或更高、16 GB 以上内存；Windows 上，纯转写可在 64 位 PC 上运行，但说话人标签需要 NVIDIA GPU，CPU-only 处理一小时录音可能花数小时。
最小可用部署：先验证本机闭环，再扩展到局域网
不要先把它当作公司基础设施。先在一台测试机器完成“录音进入、文字落盘、可搜索和可导出”的闭环，再考虑让其他设备接入。官网当前提供的安装包链接可直接下载；下载完成后先交给系统的签名与安全机制检查，不要为绕过警告关闭整机安全策略：
curl -L -o LymeScribe-3.6.3.dmg \ "https://iadev.net/lymescribe/LymeScribe-3.6.3.dmg" Invoke-WebRequest \ -Uri "https://iadev.net/lymescribe/LymeScribeClient-3.6.3.msi" \ -OutFile "LymeScribeClient-3.6.3.msi"
安装后用一段无敏感信息的短音频做验收。第一步测试按住快捷键说话，确认文字能进入当前光标所在的应用；产品页说明它可通过键盘输入或剪贴板粘贴将结果送入应用，且可按应用配置。第二步拖入一段短会议录音，确认批处理结果保存在本机，并且导出文件可被常用编辑器打开。第三步故意断开外网后重复一次测试：若你的目标是本地边界，验收标准不应只是“联网时能识别”。
这一步还会暴露一个常见误区：转写文本本身仍是敏感数据。即使音频没有上传，如果用户把结果自动粘贴进云端工单、在线笔记或聊天窗口，数据边界依然被后续操作打穿。因此快捷键和“自动粘贴”应只在已批准的应用里启用；对未知窗口，更稳妥的默认是只复制到剪贴板，随后由人决定粘贴位置。
批处理、说话人标注与术语纠正：哪些能力值得纳入流程
产品页把实时听写之外的会议录音处理也放在本地路径中：可将音频文件作为批任务处理，并在支持的硬件上进行说话人标注（diarization）。其结果不是简单的一大段文字，而是按说话人归属的脚本；用户可以试听声音片段后把“Speaker 1”改为真实姓名。它还提供本地的纠正词典，用于一次性教会系统专有名词、人名和缩写。
实践中，建议将这三项能力按风险排序使用。术语词典适合放入团队项目名、产品名和常见缩写，但不要把密码、客户密钥或完整内部架构名称当成“方便识别的词”写入。说话人姓名应在征得会议参与者同意后再替换；录音内容也要遵循原有的保留期限。批处理适合会后生成初稿，不适合直接作为人事结论、合同承诺或事故复盘的唯一依据——错误转写、同名说话人和背景噪声都需要人工回听确认。
从单机扩展到局域网时，真正要补的不是提示词
当一台主机开始给多人服务时，风险从模型质量转向运维边界。至少应补齐四件事：
- 网络范围：只允许受信任的办公网段访问主机；不要为了远程使用直接暴露端口到公网。需要异地访问时，应先使用组织已有的 VPN 或受管网络方案。
- 主机容量：记录并发人数、模型大小、GPU/内存占用和长录音排队时间。实时听写与批量会议转写抢同一块硬件时，应设定优先级或错峰。
- 数据保留：明确原始音频、转写文本、导出副本和说话人标签各自保留多久，谁能删除，以及离职或设备报废时如何清理。
- 故障降级：主机不可用时，客户端应告诉用户“稍后转写”还是改为本机处理；不要静默把音频切换到未经批准的云端服务。
LymeScribe 的价值并不在于承诺零风险，而在于提供一个可以自己定义边界的起点：模型在哪里跑、文件在哪里留、局域网内由哪台机器服务，都能由部署者决定。对确实不能把会议音频交给外部 API 的团队，这比“云端服务承诺会保护隐私”更容易落到可检查的工程控制上。
验收时要留下哪些证据
本地部署也需要可复查的验收记录。建议为每次试运行保留一张简短清单：测试音频的来源与敏感级别、使用的客户端和主机版本、是否断网测试、转写文件的实际保存位置、删除测试文件的结果，以及批处理耗时。它们不是为了把桌面应用变成重型平台，而是为了在使用范围从个人扩展到小组时，能回答“这段录音经过了哪些机器”。
对于说话人标注，验收还应单独抽取几段重叠发言、简称和数字密集的片段人工回听。将人名修正、术语词典与原始音频的访问权分开管理：可以需要纠正词典的同事，不一定也应该能查看所有会议录音。若团队没有能力维护这些最基本的权限与保留规则，就应把范围收回到个人本机听写，而不是先开放成共享服务。
当然，它并不是通用的语音基础设施。需要浏览器协作、跨地域大规模队列、集中合规检索或面向公众的转写 API 时，仍需独立评估认证、审计、加密、容量与接口能力；不能从一个桌面产品的本地特性推断出这些企业能力已经具备。最稳妥的起点仍是：用无敏感的样本证明本机闭环，再用受限局域网验证小规模共享，最后才决定是否值得投入专用主机。