同传做出来后，我有过一个很自然的念头：既然已经在听、在转写，为什么还要单独放“录音”？回看历史时，答案变得很具体：实时字幕可能中断或出错，原声却是事后核对唯一能回到现场的材料。
同传的价值在眼前：对方刚说完，我要立刻知道大意。录音的价值在以后：某个词当时没听清，或者我想复盘一场练习、核对面试里自己有没有答到点上。这时候我宁可多等一会儿，也不想拿一份错得很快的字幕当唯一证据。原声是底稿，转写和翻译是可以重做的解释。
问题：字幕故障曾把录音一起停掉#
早期实时连接连续重试失败，应用会把整场同传也停掉。重连退避可能持续几十秒，期间音频跟着断了；但现场的对话不会因为我的网络故障暂停。8 月 10 日我把两件事拆开：字幕中断时明确提示“录音在继续”，麦克风仍把声音存到本机；网络恢复再追字幕，结束时在这场记录里留下中断提示。这样回头看到一段空白，我知道是产品漏了字幕，而不是误以为当时没人说话。
“录到了”也不等于“存住了”。同一天之前我修过一个更尴尬的错误：录音文件确实写在磁盘上，会话结束却没有把它正确写进历史索引，用户看到的是一个空壳。这和字幕错了不是同一种损失。字幕可以从音频补，音频丢了不能从字幕里还原。于是索引要备份，部分损坏时不能继续盲写覆盖，孤儿音频要能被找回来；长会话结束还要确认多个分片确实拼成完整文件。我用 300 个分片的自动用例去防“文件能播放，但后半小时被悄悄截掉”这种问题。自动用例验证了拼接逻辑，不能代替每台机器上的长时间现场录制。
解决：把录音保存和字幕连接拆开#
这次改动不是简单地在断网后再试一次。录音写本机文件，字幕走网络连接，两者有各自的状态；连接重试时，界面直接告诉我“录音在继续”。结束会话还要把音频文件与历史索引一起核对。断线恢复后可以继续出字幕，但缺字区间不能被悄悄填成“没有人说话”。
验收也分两层：自动用例重放连续 300 个音频分片，检查拼接后没有缺尾；在产品里主动制造网络中断，确认录音计时仍走、会话结束可回放、历史能指出字幕缺口。前者是已经完成的代码验证，后者仍需要每次重要系统变更后做现场回归。
事后处理可以选择慢一点#
录音模式不需要持续把每一秒都送去实时模型。先把声音安全地放在本机，停下后再文件转写、翻译和总结，可以让模型拿到较完整的句子；如果结果不好，还能回听和补处理。相反，同传要在句子还没结束时出字，愿意接受临时结果稍后被校正。这也是我不想把两种模式合成一个按钮的原因：用户要知道自己此刻买的是速度，还是一份可复查的记录。
成本也迫使我把两条路径分开。实时翻译与实时原文识别按音频分钟分别计费；长会话或双声道采集时，光看“一场会花了多少”很容易算错。8 月 10 日我才把会话中的用量和价格展示出来，而且价格要能由使用者自己填。它仍是估算，不是服务商账单。录音模式把“持续连接多久”改成“什么时候需要处理哪一段”，让成本选择可以摆在眼前，而不是结束后猜。
现在我会把这两个入口说得很直白：急着看对方在说什么，开同传；想留一份能回放、能复盘的内容，开录音。无论选哪一个，原声都不能因为字幕链出错而悄悄消失。
证据出处：8 月 9 日历史索引与录音落盘修复；8 月 10 日断网继续录音提交 e585c26、会话用量提交 c0e7db0；当前 docs/ARCHITECTURE.md 的四模式说明。图中的断点为机制示意，不对应一次完整的现场录音。