[{"data":1,"prerenderedAt":242},["ShallowReactive",2],{"Content:\u002Farticle\u002Ftech\u002F2026-09-21-tamaasr":3},{"id":4,"title":5,"body":6,"categories":231,"date":233,"description":222,"extension":234,"home":235,"important":236,"meta":237,"navigation":235,"path":238,"seo":239,"stem":240,"__hash__":241},"article\u002Farticle\u002Ftech\u002F2026-09-21-tamaasr.md","让Linux也用上语音输入",{"type":7,"value":8,"toc":221},"minimark",[9,16,23,28,31,39,48,51,54,65,74,77,80,84,93,99,102,111,114,119,130,134,137,140,143,146,150,153,156,159,162,167,170,198,201,209,214],[10,11,12],"blockquote",{},[13,14,15],"p",{},"在Linux下，我们也能愉快地畅骂AI了......",[13,17,18],{},[19,20],"img",{"alt":21,"src":22},"title","https:\u002F\u002Fs41.ax1x.com\u002F2026\u002F09\u002F22\u002FpnQRNDI.png",[24,25,27],"h2",{"id":26},"语音输入法真香","语音输入法，真香",[13,29,30],{},"原本我对语音输入的态度一直都是拒绝的，即便手机上的讯飞在我小学时就已经支持了这个功能，\n我也从来没用过。",[13,32,33,34,38],{},"但是，自从用上了vibe coding以后，我发现，面对时不时整出逆天操作的ai时，还是用语音输入畅快地骂出来",[35,36,37],"strong",{},"比较有利于身心健康","。",[40,41,43],"div",{"align":42},"center",[19,44],{"src":45,"alt":46,"width":47},"https:\u002F\u002Fs41.ax1x.com\u002F2026\u002F09\u002F22\u002FpnQR2bq.jpg","真香",200,[13,49,50],{},"但众所周知呢，我又是一名常年的桌面Linux用户，至少一半的开发工作都是在Linux下进行的。在Windows下语音输入法确实很多也很完善，像用得最多的微信输入法，还有一些新兴的千问输入法等。但在Linux下，几乎就是一片空白了。",[13,52,53],{},"Linux下目前的方案主要聚焦于本地模型或云端api调用。",[13,55,56,57,64],{},"本地模型派的代表是",[58,59,63],"a",{"href":60,"rel":61},"https:\u002F\u002Fgithub.com\u002FLeonardNJU\u002FVocoType-linux",[62],"nofollow","VoCoType-linux","，它使用优化后的FunASR，可以在CPU上离线运行，但本地模型的最大问题就是：缺乏商业级输入法的实时AI润色能力。",[13,66,67,68,73],{},"还有一些对接云端ASR api的方案，比如",[58,69,72],{"href":70,"rel":71},"https:\u002F\u002Fgithub.com\u002Fflyhunterl\u002FLexiSharp-Linux",[62],"LexiSharp","。这些实现的最大问题是：调用api要钱。我本来用AI都花钱了，骂AI再花钱那不是成冤大头了。",[13,75,76],{},"以及部分商业输入法在UOS\u002FKylin下提供语音输入，但显然，打死我都不会用那些信创发行版的。",[13,78,79],{},"那还有什么解决方案呢？",[24,81,83],{"id":82},"喜报您的输入法为您引入了一个新的chromium浏览器","喜报：您的输入法为您引入了一个新的chromium浏览器！",[13,85,86,87,92],{},"打开各种AI网页对话助手，比如",[58,88,91],{"href":89,"rel":90},"https:\u002F\u002Fwww.doubao.com",[62],"豆包","，我们可以惊喜地看到，在输入框的右侧，有一个语音识别的按钮。而且这种语音识别能力是跨平台的，即便在Linux下也能使用。",[13,94,95],{},[19,96],{"alt":97,"src":98},"豆包对话界面","https:\u002F\u002Fs41.ax1x.com\u002F2026\u002F09\u002F21\u002FpnQRpBq.png",[13,100,101],{},"诶，那为什么不能靠这个功能来做个语音输入法呢？实现方案也很明晰，要么逆向对应的网页的语音识别接口链路，要么直接内置一个浏览器去从前端控制转发。",[13,103,104,105,110],{},"你现在看到的这个项目，",[58,106,109],{"href":107,"rel":108},"https:\u002F\u002Fgithub.com\u002FMelorise\u002FTamaASR",[62],"TamaASR","，便是第二种方案下的产物。",[13,112,113],{},"选二不选一的主要原因一是逆向的接口不稳定，时不时得重新适配，而前端元素改动的可能性却是非常低。而我是一个懒人，没多少精力去维护这么个业余项目。二是现在的大模型网安道德水平都高得要死，逆向请求这类操作轻易不会让你做的，想做还得搞破甲或者手搓。三是现在的设备带个electron应用基本上问题都不大，我个人是没什么electron洁癖的，多装个chromium就多装个。",[10,115,116],{},[13,117,118],{},"至于为什么不用Tauri，我在项目仓库里也写明了，其实主要就是我的一台主力设备不兼容，使用webkit2gtk打开这些AI助手的网页是根本没法进行语音输入的。",[10,120,121],{},[13,122,123,124,129],{},"事实上，后来我发现已经有了类似思路但是走逆向请求的项目，如",[58,125,128],{"href":126,"rel":127},"https:\u002F\u002Fgithub.com\u002Flilong7676\u002Fdoubao-murmur",[62],"Doubao Murmur","，如果不喜欢内嵌一个chromium并且常驻500-700mb的内存的话，也可以看看这个项目哦。",[24,131,133],{"id":132},"x11-wayland-没事我们有fcitx5","X11? Wayland? 没事，我们有fcitx5",[13,135,136],{},"我和AI讨论这个方案时，AI就提醒我，需要注意X11和Wayland的兼容性问题。",[13,138,139],{},"尤其是Wayland，不得不说，可是让人又恨又爱啊。它是比X11现代化了，But at what cost？为了避免堆成屎山，Wayland选择尽可能少的协议约束，但是做桌面又不能没有那些功能，于是各家桌面环境就推出了各种碎片化的第三方协议，对于输入法这样的涉及原生事件的软件来说简直是一场灾难。",[13,141,142],{},"但是！输入法毕竟是桌面使用的刚需，总得有人去做的，于是我们就等来了一位“白马王子”，CJK输入法使用最广泛的框架，fcitx5。诶，那我们直接去适配fcitx5，不就能解决Wayland下的兼容问题了吗？",[13,144,145],{},"于是，最难啃的部分也解决了，现在，让我们为Linux桌面带来接近微信输入法体验的高精度语音输入法吧！",[24,147,149],{"id":148},"选择什么后端豆包元宝千问chatgpt","选择什么后端？豆包？元宝？千问？ChatGPT？",[13,151,152],{},"嗯，遇到这个问题，大部分人应该还是首选豆包吧，毕竟是国内大模型多模态做的最好的。",[13,154,155],{},"但是！豆包的网页版存在一个严重问题：它是直接识别完后把识别内容作为对话请求发出去，这就意味着，单靠纯前端控制元素很难达成目标了，因为前端不会显示输入的中间态，在发送请求前也不会存在可抓取的前端DOM。如果坚持使用豆包就会导致实现很不优雅，首先得拦截最终的发送请求（你也不想让对话记录里一堆乱七八糟的识别内容被发给豆包吧？），其次中间态也得想办法拦截，不然最后只是整段地呈现的话，说的话一多就很难受。",[13,157,158],{},"于是只好转向国内的其它几家啦。国内的AI助手网页端总共也就那么几家，智谱和deepseek是没有网页端语音识别的，最后敲定使用千问和元宝。千问是最先适配的，但实测元宝会更好用点，元宝会有一个最终的AI精修的动作，而千问基本上是边说边修，结束输入就不再改动了。",[13,160,161],{},"至于ChatGPT，openai的whisper在业内一直都很出名，但我毕竟要做的是一个日用而且中文友好的，一个需要时刻使用魔法，中文识别也谈不上顶尖的选择就暂时不考虑了。",[10,163,164],{},[13,165,166],{},"后来发现讯飞星火和百度文心也有符合要求的网页版语音识别，但因为元宝和千问够用了，所以一直没适配，前面说了，我懒。",[24,168,169],{"id":169},"适配时遇到的一些问题",[171,172,173,180,186,192],"ul",{},[174,175,176,179],"li",{},[35,177,178],{},"Wayland",": 没错，还是万恶的Wayland。因为我们需要用悬浮球显示输入状态，而在Wayland下，悬浮球一出现就会打断输入焦点，导致输入被中断。最后强制指定了x11，在Wayland下靠XWayland运行。",[174,181,182,185],{},[35,183,184],{},"状态不统一",": 因为是靠的前端DOM进行判断和操作，所以总会因为各种莫名其妙的边界条件导致状态不统一，比如取消并再次输入太快了就会导致多次点击网页后端的输入按钮，造成网页后端维持在输入态而前台已经退出输入。",[174,187,188,191],{},[35,189,190],{},"electron43的托盘图标",": 很难想象这么大个项目还能整出这种篓子，electron43早期的一些版本（但已经是正式版而非测试版了）的托盘图标会不显示，而我们很依赖托盘图标进入后台，最后全部指定为42。",[174,193,194,197],{},[35,195,196],{},"对Tauri的迷信",": 毫无疑问，这种要常驻后台的Web应用，人们的第一反应肯定是Tauri。我其实也尝试过至少两版Tauri移植。但实际上，对于这个应用的很多DOM操作，Tauri其实是并没有提供对应的api的，如果想移植到Tauri，必须还得自行实现一套DOM操作和DOM状态判断的API，甚至于和移植到QtWebEngine都无异了。继续移植下去肯定也能做，但我之前也说了，我有台设备根本用不了Tauri版，而也能使用Tauri的其它设备性能要强得多，后台多挂个electron应用根本没啥影响，对我而言开发Tauri版的收益就很低了，也许以后学习Rust时会再次尝试吧。所以说，选择Tauri还是Electron，有时也不能光看刻板印象。",[24,199,200],{"id":200},"解放双手以后",[13,202,203,204,208],{},"历经波折",[205,206,207],"del",{},"明明是烧了很多token吧","，也是在Linux下用上语音输入了。不得不说还是语音输入开骂舒服啊。",[13,210,211],{},[19,212],{"alt":109,"src":213},"https:\u002F\u002Fs41.ax1x.com\u002F2026\u002F09\u002F22\u002FpnQWro6.png",[13,215,216,220],{},[58,217,219],{"href":107,"rel":218},[62],"项目也已经以MPL2许可证开源","，欢迎各位来提出宝贵的建议，或者开发更好的方案，比如使用逆向请求或者移植到Tauri。",{"title":222,"searchDepth":223,"depth":223,"links":224},"",2,[225,226,227,228,229,230],{"id":26,"depth":223,"text":27},{"id":82,"depth":223,"text":83},{"id":132,"depth":223,"text":133},{"id":148,"depth":223,"text":149},{"id":169,"depth":223,"text":169},{"id":200,"depth":223,"text":200},[232],"tech","2026-09-21","md",true,false,{},"\u002Farticle\u002Ftech\u002F2026-09-21-tamaasr",{"title":5,"description":222},"article\u002Ftech\u002F2026-09-21-tamaasr","3DwbyivmbnE9goEg5Dtp9cFS8T17rLZuTWxs2keh0Bw",1790509163629]