SyncTrans 1.0.0 在八月中旬发布。最终打的标签（build 13，8月19日）在下载按钮提供的构建之上只包含最后一处改动，而且属于簿记整理而非新功能：应审核要求，Mac App Store 构建不再提供商店本身已包含的应用内更新。自那以后，我们没有发布任何更新的版本。如果你想知道某个特定构建包含什么，版本说明始终是唯一算数的页面。
然而，代码仓库并没有闲着。打标签后的一周内，有两条工作线合并进了开发分支。这篇文章如实向大家介绍它们，这也就意味着首先要附上免责声明：以下所有内容均处于开发中，尚未发布，也不对任何发布日期作出承诺。我们之所以写出来，是因为另一种选择是更新日志式的沉默，而那容易被误读为停滞不前。
混合引擎：三个插槽代替单一方案
在 1.0.0 中，引擎模式是单一的选择：本机、托管云端或自定义服务，而且这一选择同时适用于识别、翻译和语音合成。对于首个发布版本来说这是合适的形式，但对于我们实际收到的需求而言又显得过于粗粒度——比如有人想要云端翻译的质量但希望识别留在本机，或者想要本机翻译但搭配更好的云端托管音色。
开发中的工作将单一方案替换为三个独立的插槽——识别、翻译、语音——各自从其允许的来源中填充。这项设计在写代码之前先在纸面上推演：初稿经过评审，因一系列阻塞项被否决，随后不断修改直至评审人员达成共识。在这一过程中沉淀下来的规则，充分说明了 1.0.0 曾经存在的棱角：
- 不搞静默降级。如果某个插槽在会话中途失败，该轮对话会在时间线中明确显示失败，并标明出错的插槽。会话会等待下一句话，而不是悄悄切换到另一个来源——在多次失败后，横幅会建议更改该插槽，而切换始终是用户明确的选择。
- 方案在会话启动时冻结。在对话中途修改设置不会改变正在运行的会话；下一次启动才会应用新设置。这就消除了一整类处于半应用状态的中间状态。
- 计费不能对单次调用重复扣费。当涉及云端插槽时，每个逻辑操作都带有稳定的幂等性密钥，服务器据此去重，因此重试的请求会直接从首次尝试的记录中返回结果，而不会再次计费。
- 语言支持基于组合而非单一方案校验。一场会话能够支持哪些语言对，是通过计算所选三个来源各自支持能力的交集得出的，并在会话开始前完成验证——这样一来，混合配置就不会承诺只有三个阶段中两个阶段才支持的语言。
这一切都不会改变已经发布的内容：1.0.0 的三种引擎模式依然保持原样，混合配置是一项新增功能，而非替代品。
本机模式加固
第二条工作线规模更小、更偏战术性：针对端侧体验的三项修复，在一个加固分支上共同开发。
模型下载现在会从中断处继续，而不是重新开始；下载失败会在模型卡片上显示错误，而不是直接消失。取消操作也得到了同样的处理——停止下载会传达给每一个传输中的分片，被取消的下载会明确标注为已取消，而不是看起来像出错。第三项修复关乎界面的诚实：应用现在会提前说明在哪些情况下你实际获得的是 macOS 系统音色（GGUF 模型套件不附带语音包，因此它们使用系统音色），而系统音色无法朗读的语言——印尼语就是具体的例子——会在你围绕它们构建配置之前予以明确标注。
这些改进属于那种平时只困扰你一次、随后每次都会注意到的细节。它们已经在内部合并，但尚未进入任何公开发布版本。
我们特意没有提及的内容
以上所有内容都没有附带版本号和日期，因为两者目前都还不存在。特别是混合引擎，是对应用中同时处理费用与隐私的核心部分的重大改造，只有当它达到自身设定的标准时才会发布，而不是按既定时间表仓促上线。当其中任何一项正式发布时，它都会出现在附带版本号的新功能页面中——该页面而非本博客，才是确认构建版本的最终权威来源。
如果这些方向中有你关心的——或者你有其他不同的期望——反馈看板会切实影响哪些内容被优先完成。