在真正动手写这套方案前，我先调研并付费试用了几款市面产品，包括 DuRT、Bob、Be My Ears - 实时字幕翻译。结果很一致：要么是音频接入链路不适合我的会议环境，要么不够适配 Teams 这类“边开会边理解”的实时翻译场景；在内容识别和会中可用性上，都没达到我能长期依赖的标准。
所以最后我没有继续“找工具凑合”，而是决定自己动手做一个真正贴合我日常会议节奏的 macOS 实时翻译器。
这周我又遇到一次典型场景：
和印度同事开需求评审，节奏很快、口音很重，Teams 里英文字幕在飞。我能“看见”每一句，但很难“跟上”每一句，更别说马上接问题、当场拍板。
公司当前是 Teams 标准版，会议里有字幕，但没有翻译。这在跨语言协作里是个很真实的断层。
一句话结论：字幕解决的是“可见性”，翻译解决的是“可理解性”。两者不是一回事。
如果你只有 30 秒，先看这 3 句：
- Teams 标准会议里“有字幕无翻译”并不罕见，这是许可层和会议配置层共同造成的。
- 我做的 Voice Real-time Translation（应用名 VoiceTranslation），不改 Teams，不等公司采购，直接在 macOS 本机补“实时翻译层”。
- 技术上核心是“系统音频捕获 + 语音识别 + 流式翻译 + 低延迟展示”，目标不是炫技，是减少会中理解损耗。
一、先把规则说清楚：为什么你看到字幕，却看不到翻译
截至 2026 年 2 月 24 日，Microsoft 官方支持文档给了一个非常关键的分层：
- Teams 会议默认可用实时字幕（live captions）
- 翻译字幕（translated captions）涉及额外许可与会议开关
简单说，你能不能翻译，不只取决于你自己，还取决于组织者和租户配置。
| 能力层 | 常见表现 | 你在会议里的体感 |
|---|---|---|
| 实时字幕 | 英文发言显示英文字幕 | 看得到，但理解压力依然很高 |
| 翻译字幕 | 英文发言显示中文（或其他语言）字幕 | 理解门槛显著下降 |
Microsoft 官方页面里关于翻译字幕的说明很直白：组织者若没有相应许可，参会者要想用翻译字幕，需要各自有 Teams Premium 或 Microsoft 365 Copilot 许可。
这也是为什么很多企业内部会出现同一种体验：“字幕有，翻译没有。”
二、我做了什么：在 macOS 本机补一层实时翻译
项目叫 Voice Real-time Translation（macOS 应用名是 VoiceTranslation）。目标很朴素：
不碰公司 IT 权限，不改 Teams 配置，在我自己的 Mac 上，把会议声音实时翻成我能快速理解的中文。
下面这张是我在真实会议场景下的运行界面（来自我今天的一张截图），不是示意图：
2.1 技术链路（核心）
我在代码里做的是一条实时数据链路，不是离线转录再翻译：
- 采集层：支持麦克风与系统音频两种输入源
- 转写层：接入 macOS Speech Recognition 做实时识别
- 调度层：句子级检测 + 防抖触发 + FIFO 翻译队列
- 翻译层：OpenAI Chat Completions 流式输出
- 展示层：会中持续刷新原文与译文，降低“等一整段”的延迟感
2.2 为什么我强调“系统音频模式”
会议场景下，系统音频模式比麦克风模式稳定得多：
- 少一层环境噪声干扰
- 不依赖外放音量和麦克风拾音距离
- 在 macOS 14.2+ 上可走 Core Audio Tap 的 pre-mixer 捕获链路
这点非常关键。因为我的真实目标不是“能翻一次”，而是“90 分钟会议里稳定可用”。
2.3 已覆盖的音源与真实案例
当前版本我已经把音源兼容做到了比较彻底：支持 macOS 所有输入与输出音源路径，包括蓝牙设备、内置扬声器、外接音箱、USB 音频设备等。
这不是“参数支持”，而是我在真实会议/日常沟通里反复跑过的场景：
| 场景 | 输入/输出组合 | 实际效果 |
|---|---|---|
| 日常 Teams 评审（办公位） | MacBook 内置扬声器输出 + 系统音频捕获 | 最稳，开箱即用 |
| 蓝牙耳机会议 | AirPods/Bluetooth 耳机输入输出 | 口音会议里可持续跟上节奏 |
| 外接显示器/音箱场景 | HDMI/Type-C 外接音箱输出 + 系统音频路径 | 不改会议软件，翻译照常工作 |
| 会议室临时接入 | USB 麦克风/USB 声卡 + 系统输出 | 快速切换设备后即可翻译 |
| 嘈杂环境兜底 | 麦克风模式 + 语音识别实时转写 | 可用，但优先级低于系统音频模式 |
你可以把它理解成：不管你的声音从哪里进、从哪里出，Voice Real-time Translation（VoiceTranslation）都能在 macOS 音频链路里接住并翻译。
2.4 半年演进：两次重构后，才进入稳定期
这个项目不是一周冲出来的 demo。
我查了 git 记录，首个提交是 2025-08-11，到今天 2026-02-24，刚好是“做了半年”。
这半年里，主线其实很清楚：先做出可用，再把不稳定点一层层剥掉。
中间经历了两次关键重构：
-
第一次重构（2025-09-27）：重构 API Provider 管理
目标是把“单一 API 调用”升级成“可配置的 Provider 架构”，让后续能力扩展和设置管理不再互相牵制。 -
第二次重构（2025-12-10 起）：重构权限处理与音频质量监控
目标是把最容易翻车的权限链路和系统音频稳定性做成可诊断、可恢复的工程化流程，后续在 2026-01 又补齐了 Core Audio Tap、翻译队列等关键能力。
所以你现在看到的版本，和最早能跑起来的版本不是一个概念：
前者是“能用”，现在是“可持续稳定用”。
三、实操：5 分钟把它跑起来（可复现）
我的建议顺序（别跳步骤）：
- 打开应用后先配置 API Key（未配置时翻译不会触发）
- 语言方向先固定为
English → 中文（会议里最常用） - 一次性走完三项权限：麦克风、语音识别、屏幕录制
- 会议场景把输入源切到“系统音频”
- 先用 1 分钟英文视频做预热测试，再进正式会
最容易踩的坑有两个：
- 屏幕录制权限“勾上但未生效”（需要完全退出应用后重启）
- 把输入源留在麦克风，导致把环境声也喂进识别链路
四、对我这种场景，实际价值到底在哪
我最关心的不是“翻译有多华丽”，而是会中三件事有没有改善：
- 能不能更快抓住问题核心
- 能不能更快接住追问
- 能不能减少会后反复补录音/补笔记
坦白说，它不是同传系统，也不会 100% 准确。
但在“印度同事快语速 + 技术术语密集 + 需要即时决策”的场景里，它把我的理解延迟明显压下来了。
这就够了。
五、为什么我现在就做，而不是等公司升级许可
因为这个工具已经在我的跨语言会议里跑通并稳定可用，我更希望先把它介绍出来，帮助同样有“有字幕无翻译”痛点的人。当前阶段我会先持续打磨体验和效果，暂时还未开源。
我更愿意先用工程办法把问题压下来：
- 能本地解决的，先本地解决
- 能快速验证的，先快速验证
- 能稳定复用的，再逐步产品化
这篇文章本质上就是在公开介绍这个工具，也希望和有类似场景的团队交流真实反馈，继续把它打磨成可长期使用的解决方案：
字幕是输入层，翻译是理解层；没有理解层，跨语言会议很难真正提效。
如果你也有类似场景，想试用或交流落地方式，欢迎直接联系我。
参考资料（官网/官方文档）
- Microsoft Support - Use live captions in Microsoft Teams meetings
https://support.microsoft.com/en-us/office/use-live-captions-in-microsoft-teams-meetings - Microsoft Learn - Translate captions in Microsoft Teams
https://learn.microsoft.com/en-us/microsoftteams/translate-captions - Apple WWDC22 - Meet ScreenCaptureKit
https://developer.apple.com/videos/play/wwdc2022/10156/ - Apple WWDC24 - Capture audio output from all applications with Core Audio taps
https://developer.apple.com/videos/play/wwdc2024/10153/ - Apple Developer Documentation - Speech framework
https://developer.apple.com/documentation/speech/recognizing-speech-in-live-audio
