浏览器书签脚本：一键复制文本到GLM-TTS生成语音-开发者社区

浏览器书签脚本：一键复制文本到GLM-TTS生成语音

在内容创作、在线阅读和辅助技术日益智能化的今天，我们对“信息获取方式”的期待早已不再局限于视觉呈现。越来越多的人希望以更自然、更高效的方式消费文字——比如，让网页上的文章自动用你喜欢的声音“读”出来。但现实是，大多数TTS（文本转语音）工具仍停留在“打开界面 → 粘贴文本 → 调参合成”的繁琐流程中。

有没有可能，只用一次点击，就把当前页面上选中的段落，直接变成你熟悉音色说出的话语？答案是肯定的。借助一个小小的浏览器书签脚本，配合本地运行的GLM-TTS模型，我们可以实现真正的“所见即所说”。

这不仅是一个自动化技巧，更是一种思维转变：把大模型从孤立的应用程序，变成可编程的信息处理节点，无缝嵌入我们的日常交互流。

为什么选择 GLM-TTS？

市面上的TTS方案不少，但真正能在中文场景下做到高保真、低门槛、支持情感表达的并不多。GLM-TTS 正是其中的佼佼者。它基于智谱AI的GLM架构演化而来，由社区开发者“科哥”封装成易于部署的Web UI版本，具备几项令人眼前一亮的能力：

首先是零样本语音克隆。你只需要提供一段3到10秒的参考音频——哪怕只是随口念几句普通话——系统就能提取出说话人的声学特征，生成高度相似的音色。不需要重新训练，也不需要微调参数，整个过程完全是提示驱动的（Prompt Learning），堪称“即插即播”。

其次是情感迁移能力。传统TTS往往语气单一，而GLM-TTS能从参考音频中捕捉语调起伏、节奏快慢甚至情绪色彩。如果你上传了一段愤怒或温柔语气的录音，生成的语音也会自然带上相应的情感倾向。这对于虚拟主播、有声书朗读等场景意义重大。

再者是精细化控制机制。通过自定义G2P词典（configs/G2P_replace_dict.jsonl），你可以修正多音字、专业术语的发音错误。比如，“重”可以强制读作“chóng”，“行”可根据上下文设定为“xíng”或“háng”。这种级别的干预自由度，在开源TTS中实属罕见。

最后是性能优化方面的硬核设计：KV Cache 缓存注意力键值对，显著减少长文本推理时的重复计算；支持流式输出，最低延迟可达40ms，已接近实时对话的要求。

相比传统TTS动辄需要数千句训练数据、固定音色、缺乏情感变化的特点，GLM-TTS 在数据需求、音色保真度、多语言混合支持等方面都实现了代际跨越。主观评测MOS分超过4.2，意味着普通人几乎难以分辨其与真实人声的区别。

对比维度	传统TTS	GLM-TTS
数据需求	需数千句训练数据	仅需3–10秒参考音频（零样本）
音色相似度	中等	高（主观评测MOS > 4.2）
多语言支持	通常单一语言	中英混合良好
情感控制	固定或无	可通过参考音频自然迁移
推理速度（24kHz）	快	中等偏快（依赖GPU）
显存占用	<6GB	8–12GB（取决于采样率）

当然，这一切的前提是你有一块性能足够的GPU（建议显存≥10GB）。毕竟，高质量语音合成本质上是一场密集的矩阵运算游戏。

如何打通“网页 → TTS”最后一公里？

即便模型再强大，如果每次使用都要手动复制粘贴，效率依然受限。真正的生产力提升，来自于工作流的简化。于是我们引入了一个极简却高效的工具：浏览器书签脚本。

别被名字迷惑——这不是普通的收藏链接，而是一段存储在书签栏里的JavaScript代码。当你点击它时，它会在当前页面上下文中执行，访问DOM、获取选中文本、发起网络请求……就像一个微型自动化代理。

我们的目标很明确：用户在任意网页中选中一段文字后，点击书签，脚本立即捕获该文本，并将其POST到本地运行的GLM-TTS服务接口，触发语音合成并自动播放结果。

整个流程如下：

用户选中文本（如一篇知乎回答、小说章节或PDF片段）；
点击浏览器书签栏中的“TTS朗读”按钮；
脚本调用window.getSelection()获取纯文本内容；
构造符合Gradio API规范的JSON payload；
发送至http://localhost:7860/run/predict；
接收返回的音频URL，创建<audio>元素并播放。

全程无需跳转页面，不打断阅读节奏，响应时间主要取决于TTS模型的推理速度，而非脚本本身——后者执行通常在50毫秒以内。

下面是核心实现代码：

javascript:(function() { const selectedText = window.getSelection().toString().trim(); if (!selectedText) { alert("请先选中一段文本！"); return; } const ttsEndpoint = "http://localhost:7860/run/predict"; const payload = { "data": [ null, // prompt_audio: 使用上次上传的音频 "", // prompt_text: 参考文本（可空） selectedText, // input_text: 待合成文本 24000, // sample_rate: 24kHz 42, // seed: 固定随机种子便于复现 true, // enable_cache: 启用KV Cache加速 "ras" // sampling_method: 采样方法 ] }; fetch(ttsEndpoint, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(payload) }) .then(response => response.json()) .then(data => { if (data.success) { const audioUrl = data.data[0]; const audio = new Audio(audioUrl); audio.play().catch(e => console.error("播放失败:", e)); alert("语音已开始播放！"); } else { alert("合成失败，请检查GLM-TTS服务是否正常运行。"); } }) .catch(error => { console.error("请求错误:", error); alert("无法连接到GLM-TTS服务，请确认服务已在本地启动。"); }); })();

这段代码有几个关键点值得注意：

使用立即执行函数包裹逻辑，避免污染全局变量；
payload.data数组顺序必须严格匹配前端组件结构，可通过浏览器开发者工具抓包/run/predict请求确认；
成功响应后解析data.data[0]获取音频URL（Gradio标准格式）；
错误处理覆盖了服务未启动、网络异常、CORS限制等多种情况；
自动播放功能依赖于现代浏览器的AudioAPI，部分环境可能因策略限制需用户主动触发。

⚠️注意事项：
- 必须提前在GLM-TTS界面上传参考音频，否则prompt_audio为空会导致合成失败；
- 浏览器同源策略要求服务运行在localhost或配置CORS白名单；
- 若浏览HTTPS网站，本地服务也应启用HTTPS，否则可能被拦截；
- 建议关闭该脚本在银行、支付类敏感站点的使用，以防误触泄露信息。

实际应用场景与工程实践

这套组合拳的价值，体现在多个高频使用场景中：

内容创作者：写作即预演

写文案、做脚本时，光看文字很难判断口语表达是否流畅。现在你可以边写边试听：选中刚写的段落，一点书签，立刻听到“自己声音”说出来的感觉。调整语序、删减冗余变得直观得多。

视障辅助：个性化播报

通用朗读工具音色机械、缺乏亲和力。而GLM-TTS允许你用家人或朋友的声音作为播报音色，极大提升听觉舒适度。对于长期依赖屏幕阅读器的用户来说，这是一种情感层面的升级。

语言学习：沉浸式跟读

外语学习者可以用喜欢的播客主持人音色来朗读英文材料，增强代入感。结合音素控制功能，还能重点纠正某些发音难点，比如英语中的 /θ/ 和 /ð/。

开发者原型验证

智能硬件团队在开发带语音输出的产品时，常需快速测试不同文本的播报效果。此方案可作为低成本原型验证工具，集成进开发流程，无需等待完整SDK上线。

从系统架构上看，这是一个典型的三层联动模型：

+------------------+ +-----------------------+ | Web Browser | <-> | Bookmark Script (JS) | +------------------+ +-----------+-----------+ | v +----------------------------+ | Local GLM-TTS Web Service | | Host: http://localhost | | Port: 7860 | +-------------+--------------+ | v +------------------------+ | GPU-accelerated TTS | | Model (PyTorch + CUDA) | +------------------------+

前端负责内容展示，中间层脚本充当“粘合剂”，后端服务承载模型推理。所有数据流转均发生在本地，安全可控。

为了确保稳定运行，推荐以下最佳实践：