学日语时，查一个词并不难。难的是对方说话不按教材停顿：一句刚听懂，下一句已经来了；更难的是轮到我回应时，脑子里有意思，却没有一条能马上说出口的日语。面试把这种时间压力变得很具体。我想要一块放在电脑上的屏幕，让我先抓住对方在说什么，也留下声音，之后能回头弄清自己到底漏了哪句。
所以第一版先做日中同传加录音。今天把代码收进仓库时，应用已经能同时采集 Mac 里播放的声音与麦克风，显示一列滚动字幕，把会话录下来，停下后回放和导出。混音是因为线上面试可能从电脑里出声，而我从麦克风说话；只听其中一路，一场对话就缺一半。这里的「能用」仍很早：目前只有 11 项自动测试通过，不能据此说它已经适合重要面试。
问题：翻译结果不能替代可复查的原声#
把一段录音上传、等完整翻译回来，质量可以很高，却错过了正在发生的对话；只把实时识别的每个碎片立刻显示，又会让我读到尚未说完的半句话。我要先解决的是有人说话时可以看，没看懂时还能回听。因此第一版把实时字幕和本地录音绑在同一次会话里：实时链路负责眼前，录音负责事后核对。屏幕上一行字也必须分清原文和译文，不能让译文看起来像对方真的说了中文。
这不是要让 App 替我参加面试。它至多帮我把耳朵来不及处理的东西变成可读文字；对方问了什么、我愿不愿意这样回答，责任仍在我。如果它连声音都没收全、字幕都对不上，增加回答按钮只会放大错误。
第一版怎么验收#
我把验收拆成三件事：电脑里播放的对方声音有没有收进来；麦克风里的自己有没有收进来；结束后能否从历史记录打开原声。只看见一列字幕，不能证明整场对话被完整记录。首个提交的 11 项自动测试通过，说明采集和状态逻辑有基础保障；它们没有测过一场真实面试从头到尾的延迟、漏字和回放体验。后续我需要保留可公开的测试会话，分别量音频覆盖、首行字幕时间和回放结果。
成本从第一天就是产品问题#
自己做工具，也要自己承担模型调用和长会话的账。实时音频按持续时长计费，安静的时候也可能保持连接；如果再开一路原文转写，费用不是“翻译一次”的价格。相反，录音可以先存本地，等需要时再做文件转写。目前我还没有一张足够准确的分路账单，不能把“自己开发就更便宜”当结论。至少要先把每场会话用了多久、何时值得开实时链路量出来。
对我来说，今天这版最重要的不是它用了哪个模型，而是它先留下一个真实使用场景：我在日本学习日语，有必须听懂和回应的时刻。先把声音接对、字幕放到眼前、录音留得下来，才有资格讨论“更准”“更快”和“能不能帮我开口”。
证据出处：项目首个提交 eb01e9d（2026-06-06）的功能与测试记录。成本是此时的产品顾虑，还没有会话分路计费界面。