添加 TTS 或 ASR 引擎¶

VoiceStudio 内置了大量引擎。这种广度只有在其中每一个引擎都仍能在每个平台上正常工作时才是一种资产——否则它只会变成一堆支持工单，而项目真正的承诺（首次运行即可用）才是为它买单的东西。

所以新引擎是为了一份工作而聘用的，而不是被添加到一个列表中。

任务地图¶

代码树中的每个引擎至少拥有一项任务。一项任务有且只有一个持有者。

提案必须要么从现任持有者手中接管一项任务（附带数据），要么认领一项没有任何引擎覆盖的任务。“它基准测试表现不错”不是一项任务。

门槛¶

只有当以下所有条件都成立时，新引擎才会被接受。漏掉一条，答案就是拒绝——这是门槛本身的属性，而不是对贡献者的评判。

1. 一项明确的职责。 它接管或新增了上表中的哪一行，以及现有引擎为什么无法覆盖它。延迟、语言、硬件范围或质量档次——用户会为了某个理由而选择它。
2. 每个组件的权利记录。 分别记录代码、模型权重、分词器及其他所需资产，包括它们的许可证、来源/版本、商业许可以及所需署名。未知或相互冲突的条款不能算作商业许可。受限引擎只有在获得所有者的明确批准，并有一个在首次使用时披露其条款的接受步骤的情况下，才可被免费应用接受。Pro 必须拒绝后端中的非商业或未获授权的资产，除非已获得必要权利。应用程序许可证不授予模型或输出权利。现有集成同样需要这项审计；相关控制措施仍在 #2587 中跟踪。此前批准的 audiocpp / Breeze-TTS-2 例外仍然受限，并由 @debpalash 负责管理。
3. 每个平台，或明确选择加入（opt-in）。 macOS（Apple Silicon 和 Intel）、Windows、Linux。必须有 CPU 路径——只在某一种加速器上运行的引擎可以接受，但它必须降级而不是崩溃；仅限单一平台的引擎必须放在选择加入之后（参见 CLAUDE.md 的一致性规则）。
4. 适配现有适配器。 使用 TTSBackend / SubprocessBackend，且不改动核心流水线。与我们的依赖配置冲突的依赖档案意味着需要采用 sidecar（SubprocessBackend），这是一种已有解决方案的形态——参见 docs/engines/omnivoice-subprocess.md。
5. 同一个 PR 中有 CI 冒烟测试。 不需要 GPU：对 sidecar 打桩，并断言适配器契约。没有测试的集成，就是那种坏了也没人会注意到的集成。
6. 一位明确的维护负责人。 提案人承诺在 12 个月内作为该引擎问题的联系人。没有负责人，就不合并——这就是广度与技术债之间的区别。
7. 需求证据。 一个真实的请求、一个真实的工作流、一个真实的用户。理想情况下，是某个已经在其缺失状态下变通工作的人。

弃用¶

广度只有在其仍然活跃时才值得背负。当一个引擎连续两个版本都没有维护负责人且没有通过冒烟测试时，它就会被归档。归档同样不是一种评判——这正是其余引擎保持可信赖的方式。

如果未能通过门槛¶

适配器接口是公开的。引擎可以存在于代码树之外，并行安装，并通过 id 被选中——你不需要我们合并就能使用你的引擎，我们宁愿链接一个好的外部引擎，也不愿背负一个半维护状态的内部引擎。