打字不是与 Agent 对话的唯一方式。移动端用户、写代码写到一半不想打断手的人、无障碍场景——语音输入是「低点赞、高真实使用」的那类需求。
需求信号
- #5049 与 #4164：两个独立的「原生语音输入」请求。
- #2431：提议官方把 ASR/TTS 做成能力接缝（capability seam）。
- #6552：一个安卓端语音输入的 bug 报告——反向证据：已经有人在手机上用语音输入了。
缺口在哪
索引数据（2026-09-16 快照）里 voice/audio 主题有 248 个仓库，没有一个达到 100★，最高的 dsh-omi-voice 74★ 还只做朗读不做输入。这是我们整个索引分析中「需求词仓库多、高星供给为零」落差最大的一类。
建议形态
Client UI 为主：composer 加麦克风按钮（按住说话/松开发送），可选 host service 做本地 whisper 或云 ASR 转发；朗读侧用 Speech Synthesis 起步。
实现要点
- 浏览器侧 Web Speech API / getUserMedia 即可起步，不要一上来就自建音频管线。
- 音频属于敏感输入：默认本地处理或明示云端转发，权限声明写清楚——这类插件在收录审核里会被重点看。
- composer 的扩展点参考官方 slots.md 与 web-client.md。
最小可行版本
桌面 Chrome 的按住说话转文字进 composer。朗读留到 v2。
风险与边界
诚实地讲：Discussion 里这类帖子的点赞数不高。它的逻辑不是「声量大」而是「供给为零」——第一个做得稳的语音插件大概率直接吃下这个品类，但要接受增长可能很慢。
FAQ
为什么 248 个仓库没一个做起来？
多数是 demo 级实现或捆绑在大而全的插件包里。单品类、打磨过交互（按住/松手、误触、权限引导）的没有。