dsh-speech 是一个语音插件，旨在为 DeepSeek Harness 的 Web 端提供语音交互能力。其核心功能是让用户可以通过语音与编程助手对话，语音会实时转为文字，并在助手完成回答后，自动生成一个简短的语音摘要。该项目由 AllModels.io 提供技术支持。
主要功能
- 实时语音输入：点击“发送”按钮旁的麦克风图标即可开始说话，语音会实时转换为文字并显示在输入框中，方便用户编辑或发送。
- 语音回答摘要：当 DeepSeek Harness 的智能体完成回答后，该插件会将其最终回复内容生成为一个简短的语音摘要。
- 灵活播放控制：用户可以在设置中启用“自动播放”来立即收听摘要，也可以选择在方便的时候手动点击播放。
安装与使用
- 安装插件：在 DeepSeek Harness 中运行以下命令安装插件：bashdsh plugin --profile web add @allmodels/dsh-speech安装完成后，重启 DeepSeek Harness，即可在 设置 → Speech 中找到该插件
在 DeepSeek Harness 的设置中，Speech 插件提供了以下可配置项：
- Recognition（语音识别）：相关识别参数的设置。
- Spoken summaries（语音摘要）：摘要生成和播放相关的设置。
- DeepSeek Harness：需要 Web 版本 0.1.1-rc.2。
- Node.js：需要 ^22.19.0 || >=24.0.0 版本。
- 客户端：支持本地的 DeepSeek Harness Web 客户端。
对着电脑打字打到手抽筋，说话就能让AI干活，这事儿真的来了！
DeepSeek Harness刚开源没几天，一个叫dsh-speech的插件就让所有用键盘敲提示词的人瞬间显得有点多余。
摘要：dsh-speech是DeepSeek Harness的实时语音插件，让用户用嘴写提示词、用耳朵听AI摘要。它跟其他语音插件的最大区别不是“能听会说”，而是把语音识别和语音摘要拆成两个独立服务，且背后由AllModels.io统一调度多家语音模型。安装只需一行命令，新用户送1美元免费额度。本文拆解这个插件到底解决了什么痛点、跟竞品差在哪、以及它怎么把“打字”这件事变成了可选项。
麦克风旁边多了一个按钮，但事情没那么简单
打开DeepSeek Harness的Web界面，输入框旁边除了“发送”，现在多了一个麦克风图标。点下去，说话，文字就实时出现在输入框里。这不是什么黑科技，浏览器自带的Web Speech API也能做到。
但dsh-speech干了一件其他语音插件没干的事——它不光把你的话转成文字，还会在AI回答完之后，自动把那段长篇大论压缩成一段语音摘要。
这就怪了。
市面上绝大多数DeepSeek Harness语音插件只做一件事：语音转文字，塞进输入框。有的能做到让AI把回答念出来，但那是把整段回答逐字朗读，不是“摘要”。dsh-speech的玩法是：你说的话→实时转文字→发送给AI→AI回答完→自动生成一段简短的语音摘要。输入靠嘴，输出靠耳朵，中间那坨长文本你爱看就看，不看拉倒。
为什么“听完再决定要不要看”比“看完再决定要不要听”更反常识
我们默认的交互方式是：打字提问→看文字回答。后来有了TTS（文字转语音），变成：打字提问→听机器念回答。再后来有了语音输入，变成：说话→转文字→看回答。
dsh-speech把最后这个链路改成了：说话→转文字→看回答→听摘要。
这个顺序的差别，比你想象的大得多。
人的注意力是稀缺资源。一段AI回答可能上千字，你得花几十秒甚至几分钟读完，才知道里面有没有你要的东西。但语音摘要把这段内容压缩成十几秒的音频，你先听一遍，觉得有用再仔细看原文，觉得没用直接跳过。
这跟短视频的“先看封面再决定点不点”是一个逻辑——降低决策成本。
但问题来了：AI的回答是动态生成的，摘要也是动态生成的。这意味着dsh-speech必须在AI回答完毕的瞬间，把那段文本丢给另一个语音模型，让它实时生成摘要并合成语音。这个“回答完→摘要生成→语音播放”的链条，必须在几秒内走完。
所有语音插件都在做同一件事，但dsh-speech走了一条岔路
DeepSeek Harness的插件生态在开源后六天内从700多个冲到近8000个。语音类插件是其中一大分支，粗略数一下就有十几个。
这些插件可以分为三类。
第一类：纯语音输入。麦克风→浏览器Web Speech API或本地Whisper→文字填入输入框。代表作品有dsh-voice-input、dsh-ears、dsh-web-speech-input。这类插件最轻量，不需要任何API密钥，浏览器自带识别引擎直接干活。
第二类：语音输入+回答朗读。除了输入转文字，还能让AI把回答念出来。代表作品有dsh-talk、dsh-voice。这类插件通常走云端TTS服务，比如阿里百炼或火山豆包。
第三类：全双工语音对话。按住说话→松开发送→AI回答自动朗读，整个流程不需要碰键盘。代表作品有dsh-session-assistant。这类插件技术最复杂，需要处理语音打断、回声消除、实时流式传输等问题。
dsh-speech不属于以上任何一类。
它既不是纯输入（它有输出），也不是纯朗读（它只读摘要不读全文），更不是全双工（它不支持语音打断）。它走的是第四条路：输入用语音，输出用语音摘要，中间的文字交互保持不变。
这个定位非常刁钻。它既保留了文字交互的精确性（你可以随时编辑识别结果再发送），又引入了语音交互的效率（不用读完整个回答）。打字慢的人可以用嘴输入，阅读慢的人可以用耳朵吸收——同一套插件，同时解决了“输入慢”和“输出长”两个痛点。
一个插件凭什么敢让你用嘴代替键盘
dsh-speech的语音识别不走浏览器本地引擎，而是走AllModels.io的云端服务。
AllModels.io是什么？简单说就是“语音界的OpenRouter”——把多家语音识别（STT）和语音合成（TTS）供应商统一成一个API接口。你不需要分别对接AssemblyAI、Soniox、OpenAI Whisper、阿里百炼、火山豆包，AllModels.io帮你全包了。
dsh-speech的识别设置里，你可以选模型、选供应商、选语言。中文环境下默认用Soniox的流式识别模型，其他语言默认用AssemblyAI。这两个都是专业级语音识别服务商，识别准确率和实时性比浏览器自带的Web Speech API高出一大截。
但代价是什么？钱。
AllModels.io按使用量收费，新用户送1美元免费额度。1美元能用多久？取决于你说了多少话、AI回了多少字。重度用户大概率要充值。
这跟大部分免费语音插件形成了鲜明对比。dsh-voice-input用浏览器Web Speech API，零成本。dsh-ears支持本地GPU Whisper，也是零成本。dsh-speech选择了一条“花钱买体验”的路——识别更准、延迟更低、支持语种更多，但你要付费。
语音摘要不是念一遍答案，是重新写了一篇
dsh-speech最被低估的功能是语音摘要。
大多数带TTS的插件只是把AI的回答文本逐字朗读出来。这有个问题：AI的回答动辄上千字，逐字朗读可能要几分钟。你等不起。
dsh-speech的做法是：先让AI把回答内容压缩成摘要，再把摘要转成语音。摘要的长度由谁控制？设置里的“Spoken summaries”选项。你可以调整摘要的详细程度——想要概要点“简短”，想要细节点“详细”。
这个机制的底层逻辑是：摘要生成和语音合成是两个独立步骤。先由大语言模型生成摘要文本（这一步消耗的是LLM算力），再由TTS模型把摘要念出来（这一步消耗的是语音合成算力）。两步分开，意味着你可以用不同的模型来完成不同的任务——比如用DeepSeek模型生成摘要，用AllModels.io调度的TTS模型合成语音。
这个设计跟竞品拉开了差距。其他插件要么只做输入不做输出，要么把输出做成全文朗读。dsh-speech是唯一一个在“输出端”做减法——不是把答案变长（朗读全文），而是把答案变短（摘要朗读）。
当“打字”变成可选项，谁还在乎键盘
dsh-speech解决了一个没人明说但人人都遇到的尴尬：AI编程助手这类工具，输入输出都是大段文字，打字慢的人用起来很痛苦，阅读慢的人用起来更痛苦。
程序员还好，打字是基本功。但DeepSeek Harness的定位不只是程序员工具——它要成为“Agent的运行底座”，让非技术人员也能通过自然语言指挥AI干活。一个产品经理、一个运营、一个设计师，面对DeepSeek Harness的Web界面，第一反应可能是“我该打什么字”。
dsh-speech把“打字”这个门槛拆掉了。点一下麦克风，说话，文字自己冒出来。AI回答完，不用盯着屏幕读，听一段摘要就知道大概。
这跟当年图形界面取代命令行是一个逻辑——不是命令行消失了，是大部分人不需要碰命令行。打字不会消失，但会成为可选项。
安装只需要一行命令，但配置藏着一个坑
dsh-speech的安装命令极简：
dsh plugin --profile web add @allmodels/dsh-speech
装完重启DeepSeek Harness，设置里多了一个“Speech”选项页。进去之后有两种认证方式：输入邮箱收验证码，或者直接贴AllModels的API Key。新用户走邮箱流程会自动送1美元额度。
但有个细节值得注意：dsh-speech要求DeepSeek Harness的Web版本必须是0.1.1-rc.2，Node.js版本必须^22.19.0 || >=24.0.0。版本不对装不上，装上了也可能跑不起来。
另一个隐藏问题是麦克风权限。dsh-speech依赖浏览器的getUserMedia、AudioContext和AudioWorklet。这三个API在Chrome、Edge、Firefox上支持良好，但在Safari上可能有兼容性问题。移动端布局下，麦克风选择器会被隐藏，自动使用系统默认输入设备——这意味在手机上你没法手动切换麦克风。
当语音识别和语音摘要分属两家供应商，谁在为你的体验兜底
dsh-speech的识别设置里有一个细节：中文环境默认用Soniox，其他语言默认用AssemblyAI。但你也可以手动切换成别的模型。
这意味着什么？意味着AllModels.io背后聚合了多家语音供应商，dsh-speech可以根据你的语言和场景自动选择最优的那一家。中文用Soniox（这家在中文识别上口碑不错），英文用AssemblyAI（老牌语音识别服务商），其他语种还有备选。
这种“路由”能力是dsh-speech跟其他语音插件最本质的区别。其他插件要么绑死浏览器Web Speech API，要么绑死阿里百炼或火山豆包。dsh-speech不绑死任何一家——AllModels.io作为中间层，随时可以切换供应商。
但这个架构也有代价：多了AllModels.io这一层，就多了延迟。语音识别的实时性要求极高，每多一次网络往返，延迟就多几十毫秒。dsh-speech用“流式识别”来缓解这个问题——边说边转写，不用等说完再处理。但流式识别对网络质量的要求更高，断网或高延迟环境下体验会打折扣。
1美元免费额度用完后，你还会继续用吗
dsh-speech的商业模式很简单：AllModels.io收你的钱，dsh-speech不额外收费。新用户送1美元，用完了自己充。
1美元能用多久？取决于你说了多少话、AI回了多少字。语音识别按音频时长计费，语音摘要按字符数或Token数计费。粗略估算，1美元大概能支撑几小时的语音输入和几百次摘要播放。重度用户可能几天就用完了。
这跟大部分免费语音插件形成了鲜明对比。dsh-voice-input用浏览器Web Speech API，零成本。dsh-ears支持本地GPU Whisper，也是零成本。dsh-talk用edge-tts微软免费服务，还是零成本。
dsh-speech选择了一条“花钱买体验”的路。识别更准、延迟更低、支持语种更多、摘要质量更高——但你要付费。
这个选择对不对，取决于用户是谁。偶尔用用的人，1美元免费额度可能够用很久。每天用的人，充值不可避免。但话说回来，一个能帮你省下大量打字和阅读时间的工具，花点钱似乎也合理。
语音摘要到底在摘什么，这个问题没人问过
dsh-speech的语音摘要功能，表面上是一个“便利功能”，实际上触及了一个更深的问题：AI的回答里，什么信息是必须听的，什么是可以跳过的？
这个问题没有标准答案。不同的人、不同的场景、不同的任务，对“重要信息”的定义完全不同。一个程序员问“这个bug怎么修”，AI回答里的代码片段可能是最重要的，但语音摘要没法念代码。一个产品经理问“用户反馈怎么分类”，AI回答里的分类框架可能是最重要的，语音摘要可以念。
dsh-speech的摘要生成逻辑目前没有公开细节——它用的是哪个模型来生成摘要？摘要的长度如何确定？摘要里保留什么、舍弃什么？这些问题的答案，直接决定了这个功能是“真有用”还是“图一乐”。
如果摘要只是把回答的前几句话浓缩一下，那还不如直接读原文的前几段。如果摘要能精准抓住回答的核心论点、关键数据、行动建议，那这个功能就值回票价了。
目前能看到的信息是：dsh-speech的设置里有“Spoken summaries”相关选项，用户可以调整摘要的详细程度。但具体怎么调、调了之后效果如何，官方文档没有细说。
这个“没说细说”本身就是一个信号——功能可能还在早期迭代阶段，细节还没定死。
你对着麦克风说话的那一刻，打字这个动作就变成了历史
dsh-speech不会取代键盘，就像计算器不会取代心算。但它会让“打字输入、阅读输出”这个默认交互方式，变成一个可选项而非必选项。
对于打字慢的人，语音输入是救命稻草。对于阅读慢的人，语音摘要是时间救星。对于双手被占用的人（比如正在做饭、开车、撸猫），语音交互是唯一选择。
DeepSeek Harness的野心是成为“Agent时代的安卓”——一个让所有人都能指挥AI干活的基础设施。如果这个野心要实现，语音交互就不是锦上添花，而是必选项。dsh-speech是第一步，但它走的这条路，跟其他语音插件不一样。
其他插件在做“让AI能听懂”，dsh-speech在做“让人类不用再打字”。前者是功能补全，后者是交互革命。
区别大吗？你对着麦克风说完一段话，AI回答完自动播一段摘要，整个过程你没碰一下键盘——那时候你就知道区别有多大了。