在自动化脚本中调用语音合成（文本转声音）

自动化脚本里加语音播报，这件事本身不复杂，但容易做偏。很多人第一反应是去找一个“功能丰富”的 TTS 服务，申请 Key、调 HTTP 接口、处理音频流、再想办法让设备播放出来。这条路径在移动端自动化场景里会引入一连串不必要的变量：网络延迟、鉴权失效、音频格式兼容、播放器状态管理。冰狐的 tts 对象选择了另一条路——把这些问题全部收走，只暴露两个方法。

官方文档的描述很克制，只有 play 和 stop 两个入口，play 接受一个字符串，stop 不接受任何参数。没有音色选择，没有语速调节，没有 SSML，也没有异步回调。表面上看是功能少，实际上是在自动化脚本这个特定语境下做出的合理裁剪：状态播报、异常告警、进度提示这类需求，核心诉求是“让设备在人不在旁边的时候把话说出来”，而不是做语音产品。功能越少，脚本里的确定性就越高。

理解这一点，后续的用法才不容易走偏。

两个方法背后的行为约定

tts.play(text) 最关键的行为不是“把文本变成声音”，而是它的中断语义：连续调用时，后一次播放会自动中断前一次尚未完成的语音，不需要手动调用 stop 来清理。这条规则直接决定了脚本里语音调用的编排方式。

它同时也意味着 tts.play 不是阻塞的。传入文本后，方法立即返回，语音在底层异步播放。如果紧接着执行 sleep(2000)，这两秒里语音可能还在播，也可能已经结束，取决于文本长度和设备 TTS 引擎的合成速度。脚本逻辑不能假设 tts.play 之后语音会“说完再往下走”。

tts.stop() 则是一个无副作用的终止指令，没有语音在播的时候调用它不会报错，所以可以放在 finally 块或者异常处理的统一清理路径里，不必先判断当前是否有播放在进行。

另一个容易被忽略的细节是运行环境：冰狐的 TTS 完全在本地完成，不经过网络请求，没有调用频率限制。这听起来像是锦上添花，但在自动化脚本里意义很大——离线设备、弱网环境、或者需要高频触发播报的循环任务，都不会因为 TTS 而增加新的失败点。

在脚本里编排语音：从“能播”到“播得对”

最直接的用法是在脚本的关键节点各插一句：

function main() {
tts.play('脚本启动，开始执行登录流程');
// … 登录操作 …
tts.play('登录完成，进入数据采集');
// … 采集操作 …
tts.play('采集结束，共处理 12 条记录');
}

这样写在 demo 里没有问题，放到真实脚本里却会遇到一个很实际的问题：如果两个 tts.play 之间的操作耗时较短，第一句还没播完，第二句就会把它切掉。用户听到的可能是半截“登录完成”紧接着“采集结束”，信息反而变得碎片化。

解决方式不是让 tts.play 变成阻塞的——它做不到——而是在调用侧加一层时序控制。一个务实的做法是给播报点之间留出与语音时长匹配的间隔，或者更稳妥地，用一个简单的播报队列来串行化：

function speakSafely(text, waitMs) {
tts.play(text);
if (waitMs && waitMs > 0) {
sleep(waitMs);
}
}

function main() {
speakSafely('开始执行批量签到', 2200);
// … 签到循环 …
speakSafely('签到完成，共处理 8 个账号', 2600);
speakSafely('接下来执行数据导出', 2200);
// … 导出操作 …
speakSafely('全部任务结束', 1800);
}

waitMs 的取值不需要精确。中文 TTS 的语速大致在每秒四到五个字左右，一句十个字左右的短提示，两千毫秒是一个合理的保守估计。如果文本更长，相应上调。这个参数的本质是用时间换确定性，代价是脚本整体时长会略微增加，换来的是播报内容的完整度。

如果脚本的某个分支需要用户立刻听到警示，而不是等前一句播完，那么 tts.stop() 就应该被显式调用：

function alertCritical(message) {
tts.stop();
tts.play(message);
}

function main() {
tts.play('正在执行常规巡检，请稍候');
// … 巡检过程中检测到异常 …
if (batteryLevel < 10) {
alertCritical('电量过低，请立即连接充电器');
}
}

这里 tts.stop() 的作用不是“优雅地停止”，而是“清空当前播报队列，让最高优先级的消息立刻占据语音通道”。在异常告警场景下，这个行为比等待前一句播完再播下一句更符合使用者的预期。

和 toast、console.log 的分工

冰狐脚本里同时存在视觉和语音两种反馈通道，它们不应该互相替代，也不应该重复同一句话。一个稳定的分工方式是：

• tts.play 负责“人在忙别的事情时需要被通知到的信息”：任务开始、关键节点完成、异常发生。

• toast 负责“人正在看屏幕时可以快速扫一眼的短状态”：当前点击了什么、第几步执行中。

• console.log 负责“事后排查时需要还原的上下文”：具体参数、返回值、耗时。

三者各司其职，脚本的可观测性会明显好于全部堆在语音里或者全部只写日志。尤其需要注意的是，不要把调试信息也塞进 tts.play——语音通道是稀缺的注意力资源，频繁的无关播报会让人很快对语音提示脱敏。

文本内容的一些实际约束

虽然冰狐 TTS 在接口层面接受任意字符串，但实际播放效果仍然受设备本地 TTS 引擎的影响。标点符号的处理、中英文混读的流畅度、数字和单位的读法，在不同 Android 设备上并不完全一致。这不是冰狐的问题，而是“调用本地引擎”这一设计路径的固有属性。

在脚本里能做的是尽量让传入的文本对本地引擎友好：避免 emoji 和生僻的控制字符，英文单词之间保留空格，数字和单位之间不要粘连。长文本的实践阈值大致在几百字以内，再长的话，即使引擎能合成，tts.play 之后的脚本时序也会变得难以预估。如果确实需要播报一段较长的内容，拆成多个短句、用队列间隔串行播放，比一次性传入一个大字符串更可控。

还有一个容易被忽略的边界：空字符串。tts.play('') 不会报错，也不会有任何效果，但它会参与中断语义——如果前一句正在播，一个空的 play('') 调用同样会把它切断。所以在拼接动态文本时，如果变量可能为空，最好在调用前做一次非空判断，避免无意中“静默地”掐掉正在播报的内容。

一个带保护的播报封装

把上面讨论的几个点收在一起，可以在脚本里加一个轻量的封装，让业务代码不必每次手动处理中断和间隔：

var _lastSpeakEnd = 0;

function speak(text, opts) {
if (!text || text.trim() === '') {
return;
}

var minGap = (opts && opts.minGap) || 0;
var now = new Date().getTime();
var elapsed = now – _lastSpeakEnd;

if (minGap > 0 && elapsed < minGap) {
sleep(minGap – elapsed);
}

tts.play(text);
_lastSpeakEnd = new Date().getTime();
}

function speakUrgent(text) {
if (!text || text.trim() === '') {
return;
}
tts.stop();
tts.play(text);
}

function main() {
speak('自动化脚本已启动', { minGap: 2200 });
// … 业务操作 …
speak('第一阶段处理完成', { minGap: 2200 });

try {
// … 可能失败的操作 …
} catch (e) {
speakUrgent('执行异常，脚本即将终止');
console.error(e);
return;
}

speak('全部流程正常结束', { minGap: 1800 });
}

speak 处理常规播报，用 minGap 在两次调用之间插入必要的间隔，_lastSpeakEnd 记录上一次实际调用的时间点，避免在紧凑循环里反复触发中断。speakUrgent 只做一件事：清空当前播报，让紧急消息立刻被听到。两个函数都过滤空文本，防止边界情况下的意外中断。

这套封装没有试图把 tts 变成更“强大”的东西，只是在两个原始方法之上补充了自动化脚本真正需要的时序确定性。冰狐 TTS 的设计取向也正在于此：它不提供丰富的合成参数，不构建音频流水线，而是把“让设备说出当前状态”这件事压缩成一个几乎不会失败的本地调用，把复杂度留给脚本作者去用最少的代码控制节奏。对于状态播报、异常告警、无障碍辅助这些自动化场景而言，这种克制比功能堆叠更实用。