开源项目 AI-TRANSLATOR 发布 MVP，支持语音文本同步翻译并多路输出

AI Voice Translator 是一款同步语音和文本翻译器，可将翻译结果并行分发到任意输出端。AI-TRANSLATOR 监听语音（或接收文本），获取目标语言的翻译，并将结果同时发送到任意数量的独立输出端——文本输出端（字幕、屏幕显示、文件）和语音输出端（将翻译后的语音路由到虚拟音频设备、网络音频流）。该项目的核心特性在于：翻译核心并不知道其结果会被送往何处。核心产生的是翻译事件流；分发由可单独启用或禁用的隔离输出模块执行。同一份翻译可以同时送往舞台屏幕、广播字幕和语音频道。

第 1 阶段（MVP）已实现并有测试覆盖：事件总线、输出子系统、控制台、WebSocket、转录和 Telegram 输出端、监督器、同步翻译提供方上的音频源、离线文本和脚本源，以及命令行界面。在 1.0 发布之前，接口仍可能发生变化。

Linux 是主要平台：Nix flake 提供开发 shell，transono 驱动 PipeWire 和 ALSA，虚拟音频设备通过其 PipeWire 模块创建。macOS 支持构建和运行：项目使用 Xcode Command Line Tools 和 rustup 工具链构建，无需 Nix；音频采集和播放通过 cpal 经由 CoreAudio 进行，transono 的 PipeWire 模块完全不会被编译。语音输出端在该平台上不可用——虚拟音频设备是用户自行安装的第三方驱动——麦克风权限会从终端请求。Linux、macOS 和 Windows 在每次推送时都由 CI 构建和测试。发布包仅针对 Apple Silicon 制作：媒体引擎没有面向 Intel Mac 的构建，而不含语音聊天输出端的包不会发布。

Windows x86_64 支持构建和运行：音频采集和播放通过 cpal 经由 WASAPI 进行，语音聊天输出端的媒体引擎存在 x86_64-pc-windows-msvc 版本，发布形式为包含 ai-translator.exe 和 ntgcalls.dll 的可移植 ZIP 包。该平台上的虚拟音频设备是第三方驱动（VB-Cable、VoiceMeeter），因此 virtual_sink 会被配置检查拒绝，而不是假装可用。Windows arm64 没有媒体引擎，也不会发布。

核心与输出端之间交换的单元是规范化的不可变事件：is_final 标记一个短语的结束：更新单条记录的输出端（屏幕、字幕行）用它来释放当前记录并开始下一条。seq 是严格递增的计数器，供需要它的协议使用。同步翻译协议没有表示「短语已完整」的事件——它只发送增量。因此短语边界由增量之间的停顿合成（默认 700 ms），并且即使没有新的增量到达，定时器也会关闭最后一个短语。

配置中声明并为后续阶段保留的内容：

未就绪的输出端会如实报告，而不是静默吞掉翻译：被禁用的输出端永远不会启动，无法投递的输出端会报告错误，监督器会记录并据此采取行动。失败的输出端会以有限次数重启，且不影响其他输出端。

在 macOS 和 Windows 上，虚拟音频设备不是系统音频栈的一部分，而是用户自行安装的第三方驱动（macOS 上为 BlackHole 或 Loopback，Windows 上为 VB-Cable 或 VoiceMeeter）；应用程序本身从不安装驱动。virtual_sink 在所有平台上仍是占位实现，因此配置检查会拒绝已启用的它并给出说明，而不是让监督器反复重启它——参见 docs/decisions.md，ADR-002。

翻译后的语音直接来自 AI 提供方，作为产生翻译文本的同一会话的一部分。语音合成（TTS）是可选的额外音频来源，仅在提供方或来源本身不产生语音时使用。

群组可以在其语音聊天中以实时音频形式承载翻译。该路径不走 Bot API：机器人根本无法加入语音聊天，因此广播以用户账号运行，需要 api_id、api_hash 和已保存的会话。

[[sink.voice]] type = "telegram_call" chat_id = "-1001234567890" api_id_env = "TELEGRAM_API_ID" api_hash_env = "TELEGRAM_API_HASH" session_file = "~/.local/state/ai-translator/telegram-user.session" create_if_missing = true

该账号通过 ai-translator telegram-login 登录一次；会话文件是完整的访问凭据，被视为机密。语音从与文本输出端相同的流水线逐帧送入通话，因此群组能实时听到正在说出的翻译。

传输层是原生媒体引擎（libntgcalls，即 pytgcalls 背后的引擎），因此该输出端是一个构建特性：telegram-call。每个包都带此特性构建：Linux x86_64、Apple Silicon 上的 macOS 和 Windows x86_64 都在二进制文件旁携带该引擎，且没有可在不带它的情况下构建的开关。普通的 cargo build 会关闭该特性，因此程序无需下载引擎即可编译；这样的构建仍会解析该输出端，并在其被启用时给出原因予以拒绝，而不是静默丢弃。

一个 TOML 文件描述核心和所有输出端。每个输出端都有一个 type 和一个 enabled 标志；机密通过环境变量引用，绝不存储在文件中。每个字段都有默认值，因此配置可以只写出与默认值不同的部分：

[core] target_lang = "ru"

该文件将内容翻译为俄语，识别源语言，使用系统输入和输出设备，并在终端中打印结果。空文件同样有效，含义相同，但目标语言为英语。默认值为：provider = "openai/translation"，source_lang = "auto"，target_lang = "en"，input_device = "default"，output_device = "default"，没有 [sink] 段意味着使用控制台输出端，屏幕监听 127.0.0.1:8642，没有路径的转录则

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）