Obsidian 插件 Qiaomu Reader 和 Qiaomu AI RSS 新增 TTS 语音朗读支持

2026 年 10 月 13 日 7:04（帖内显示 7:04 AM），作者向阳乔木在 X 上发布帖文，称 Obsidian 插件 Qiaomu Reader 和 Qiaomu AI RSS 现在都已支持语音 TTS 朗读。这是本次功能更新的唯一信息来源，帖文本身属于作者自述的产品更新，而非官方公告或第三方评测。

帖文同时提到，前一天给 Reader 增加了 txt、html、markdown 渲染阅读支持。作者把 TTS 的定位概括为“如果懒得看文字，听是一个好的选择”，即把阅读场景延伸到听觉场景。

需要区分的是：上述功能描述均为作者本人的说法，属于 source_claim 级别；帖文未附版本号、发布时间线或功能演示，因此“已支持”这一状态目前只有作者单方陈述。

按帖文描述，TTS 朗读同时提供云端与本地两条路径。云端侧新增豆包语音和 Edge TTS 两个模型，用于朗读文章和电子书；本地侧则支持本地小语音模型进行实时朗读。

这一组合的意图可以合理推断为兼顾质量与可用性：云端模型通常依赖网络，本地模型则可能在断网时顶替。但帖文并未说明云端 TTS 的调用方式、配额与费用，也未说明本地小语音模型的具体名称、体积与运行要求。

评论区中，用户 0x小师妹 直接追问“本地模型蹲一个具体名字”，并称手头老机器跑 Edge 云端虽然稳，但断网还是想用本地的顶一下。这说明本地模型的具体身份是读者关心的信息缺口，而帖文没有给出答案。

作者称两个插件都已经上架到 Obsidian 官方插件库，并给出下载安装地址。但帖文中两处地址均被截断为 community.obsidian.md/plugins/qiaomu…，无法确认完整链接，也无法据此独立核实上架状态。

因此，“已上架官方插件库”目前只能作为作者自述处理。两款插件是否确实通过 Obsidian 官方审核并上架，缺乏第一方或第三方独立来源佐证。

帖文互动数据为：7,276 次浏览、19 次转发、1 次引用、22 次点赞、11 次收藏。这些数字反映的是帖文传播量，而非插件安装量或功能验证结果。

评论区提供了两个具体使用场景。用户 Pixel｜AI实用笔记 提出把口播稿作为文本导入 Reader，选一段听，手动圈出一口气塞了三四个信息的长句再拆短；该用户同时提醒，TTS 能念顺不等于真人能说顺，仍需自己读一遍检查停顿和重音。

另一位用户 Allen Chow 认为，把 Obsidian 知识库与 AI RSS 变成可听内容，可在通勤、跑步时持续学习。这两个用法均来自评论者，属于 source_claim，帖文作者并未表示采纳或官方支持。

这些讨论的价值在于提示 TTS 的实际用途可能超出“朗读文章”，延伸到写作检查与碎片时间消费；但它们不构成对功能本身的技术验证。

综合帖文与评论，目前明确缺失的信息包括：TTS 支持的具体语言、音色数量、离线可用范围；云端豆包语音与 Edge TTS 的调用方式、配额与费用；本地小语音模型的名称、体积与运行要求；新增功能的具体版本号或发布时间线。

此外，Reader 新增的 txt、html、markdown 渲染支持是否与 TTS 功能同步发布，帖文也未说明。作者只提到“昨天”增加了渲染支持，与 TTS 上线的先后关系无法确认。

这些缺口意味着，读者若要在自己的 Obsidian 环境中评估可用性，仍需以插件实际安装后的表现为准，而不能仅凭帖文描述下结论。

从可核实的信息看，这是一次由作者单方发布的产品功能更新：两款 Obsidian 插件加入 TTS 朗读，覆盖云端与本地模型，并称已上架官方插件库。帖文发布于 2026 年 10 月 13 日，互动量有限，未见独立来源跟进。

对潜在用户而言，关键判断点不在“是否支持 TTS”，而在云端与本地两条路径的实际可用性：本地模型名称未知，云端费用与配额未知，上架状态仅有作者自述。在这些问题得到澄清前，把该更新视为“已宣布、待验证”更为稳妥。