Hello！大家好！我是 Ne0W0r1d！CN 地区的 Linux 兼容性文档《Can We Tux》 的首席 Maintainer，也是这次第三方 Q 音客户端的“产品经理”。

本次内容基本上都是来自我博客的转载：项目开始 和 Quaver 1.0 发布

前言

Linux 的 Q 音客户端……烂透了，Electron 8 + X11 Only + 不完整的 MPRIS + 会员听不了高阶音质。让我一个开着自动续费 Q 音 SVIP 的普通用户气笑了。然后就动用当时孙割限免的 BAI 和🐧亲儿子 WorkBuddy 整了一个第三方 Q 音客户端。

名字来源

Quaver，英语代表“八分音符”，𝅘𝅥𝅮，既是可以代表音乐的完美符号，又能关联到 QQ 音乐。这就是选择做 Quaver 为名字的原因。

但 Quaver 本来就是一个 Rhythm Game，所以为了避嫌，就叫作 Quaver Music 了。

当然，虽然目前只有 Q 音，但我也正在考虑接近 SPlayer 的设计，支持 NAS 内和本地音乐 + 搜刮，但不代表未来不会从 MoeKoe 偷来 KM 支持（因为我不太喜欢那种类 GTK 设计）。

仓库： Team Quaver - Quaver Music

契机

这个契机十分的……有趣？我一直是 QQ 音乐的用户，也用过 NCM 的第三方客户端（SPlayer Next 等），Spotify，Apple Music。

然而 QQ 音乐一直没有什么好用的第三方客户端，而同 TME 系的有 MoeKoe ，而转机是在一个基于 GPUI 的上。

一个挺好用的 Rust Q 音第三方客户端，但可惜 Rust 太重了，而且我 Rust 是真的菜。（是的，原作者实现的 CSD 确实比我自己想的上面扩展 CSD 好很多）

所以使用 Electron，对接入 NodeJS 的 API 而言也很方便，开发也很快，也可以避免我孱弱的 Rust 开发，与此同时，后端我也能玩 C++ 这一个我更熟悉的编程语言。

只不过整出来，我像瘫在椅子上看到爆炸一般，Electron + AI 的迭代真的太快了。

为什么使用 Electron

答案很简单，出效果快，各大桌面也能用，而且也不会考虑 Rust 带来的影响。

先说说我率先过掉的开发技术栈：

• GTK：跨平台弱，性能弱，且本人对 GNOME 基金会存在一定偏见
• Tauri：我用 WebKitGTK 就是坐牢的，且 Rust 相关知识还是比较薄弱，直接不考虑
• iced：还是发展初期，且 Rust 相关知识还是比较薄弱。
• GPUI：有类似物了

然后在这两个纠结：

• Qt：还可以，但是 QML 出效果比较慢，但胜在轻量，只不过我之前开发 Qt 都是 Widget，QML 没怎么摸过。
• Electron：对接入 NodeJS 的 API 而言很方便，开发迭代很快，也很适合 Vibe Coding，同时可以避免我孱弱的 Rust 开发，且后端我也能玩 C++ 等，不过最初想法是用 Astro 的，但想想看，还是更为标准的 Vite 吧。

一些想说的

这目前是个完全的 Vibe Coding 项目，加上自己的设计，我个人很喜欢部分 Mac 的设计，所以味道有点重很正常。

希望这个项目不被 DMCA，也希望能成为多数 Linux QQ 音乐用户的首选软件。

为了不被 DMCA，该项目将做到

• 会执行跨平台，但会针对 Win + Mac 用户警告回到官方客户端
• 该应用不允许下载音乐
• 该应用不允许越权听取无资格内容（由 Q 音自己服务器鉴权 + 下放音质/音频流）
• 该应用不会尝试支持 DTS: X 和杜比全景声解码

正式版之路

因为我在 Prototype 的时候就打了一个很好的底子，借鉴了 Spotify 和 Apple Music。

也借鉴了 QQ 音乐官方客户端，NCM 官方客户端。

我个人认为，主界面应该是三段式的，播放器应该固定在底下，这样的设计对 Quaver Music 带来了比较强的实用风格，且毛玻璃实现起来，比液体玻璃来说更雅观。

至于主页，这个功能来自 @LMFuture 为 Quaver Music 实现的 Verse 风格。在经过了社区投票后，Verse 风格已经决定不再合并，但我觉得主页布局还行，就叫 AI 帮我移植了。

与此同时，我也在做“竞品分析”，我分析的竞品，包括 SPlayer-Next 和 MoeKoe Music。

这也是我在未来会支持 Sparkle 愚者面具系统（即插件系统），坚定设计风格的决定，且短时间 Rust 不会成为 Quaver 技术栈的原因。

然后在实现功能的时候，现在的 ds4.1f 和 GLM5.3f 都会为其实现 Smoke Test，而我做的，只是作为 QA，实现功能完善的情况，并继续学习 TypeScript 和 Python，完善一些代码。

而播放后端使用 MPV，单纯只是因为接入简单，也很方便实现一些高级选项，因为技术能力在这，没法做到像 SPlayer 那样用 Rust 实现一套 FFmpeg 控制器。

文档完善，善用飞书

在线文档

我建立了属于挂在我域名下的一个在线文档，使用了我之前 Vibed 的 VitePress 主题 Vivian。

现在是已经打了个基础的稿，未来再慢慢填充内容。

• 简介
• 免责
• 基础框架

欢迎大伙去 Quaver Music 官网 查阅。

问卷

我的问卷系统，从 Can We Tux 到 友链，再到 Quaver Music，一切都是使用了飞书。

我认为，重大的，依赖社区的问题，一定要快速，及时的触及。这就是使用飞书问卷的理由。

飞书的多维表格在这方面快速筛选内容来说，可以让我快速决策。

开发看板

同理，我用的也是飞书多维表格， 用多视图 + 分组实现了分门别类。让我清晰的做到每个版本该开发啥，存在什么问题，一目了然。

AI 的局限性，对我的影响

我真正怒 Vibe，是在今年上了几个月班的时候，配了 Hermes + MiMo Token Plan 。

而如今，是因为 Workbuddy。

我真觉得 Codebuddy/Workbuddy 的体验确实还行，我现在这一套也是用 WorkBuddy 的 Hy3、DeepSeek v4.1 Flash、GLM 5.3 Flash 实现的，打样的时候用的是孙割的 b.ai 的 Qwen 3.8 Flash

对于前端工作相关，4.1f 和 5.3f Vibe Coding 的迭代速度，让我真的吓到了，而后端的 Python，也能帮我拆分完，实现了 Electron 加密存储区等功能。

但快速的打样很快，但真的维护很麻烦，我觉得这点 Linus Torvalds 说的没错，前期接触一门语言还算是个好选择，一旦维护起来，就非常头疼。

尤其是我这个至今还在学 TypeScript / Python / QML，同时还在重新学习 Qt 和 C++ 的人。

但是怎么说呢，目前来说我应该开发会和 AI 一起参与吧，所有 AI 产生的补丁我可能都需要检查一下了。与此同时，我也要加快 TypeScript + Python 的学习进度，以尽量在中后期使用人工优化代码质量。

就是不知道 Sol、Astra、GLM5.3、Kimi K3 这类吓人的真·LLM 能给我多少“惊吓”了。

现在/未来的规划

1.x Ellen

Prototype 代号取自《无畏契约》角色霓虹，该角色为瓦里面机动性最强，的角色，以此为代号代表“快”，正好对快速迭代维护，而正式版代号取自《绝区零》角色艾莲·乔，没有什么意味，随便选的，鲨鱼妹正好符合我 XP 而已，取代号只是为了方便建分支，没啥意义。

1.0 Chisa（维护分支）

Chisa 代号取自《鸣潮》角色朽叶千咲

• 在未来的维护版本中，实现主菜单栏和播放列表的可拉伸
• 将会禁止用户拖拽预期外的超链接内容
• 执行新操作的时候允许打断旧操作
• 优化 MPV 在注销的逻辑（Hyprland + Greed 出现注销后继续播放的情况）
• 优化播放进度条的容器限制
• 优化搜索页双击逻辑

1.1 Cyrene（正在进行的功能分支）

Cyrene 代号取自《崩坏：星穹铁道》角色昔涟

• 内存占用优化
• 播放页 - 更多选项
• QRC 解码，并上线默认样式
• Sparkle 插件系统
• 播放页：画廊模式
• 优化音质获取能力

1.2 Phoebe（已确定的未来分支）

Phoebe 代号取自《鸣潮》角色菲比

• 全局快捷键
• 通过日期种子生成的随机播放
• Sparkle 愚者面具 - Cover Flow
• MPRIS 音量控制
• Logind 直连 Inhibit 兜底机制
• Sparkle 愚者面具 - AMLL For Quaver
• 歌单管理

1.3 Evanescia（开发看板中的未来版本，但确定了叫这个代号，但确定上线内容待定）

Evanescia 代号取自《崩坏：星穹铁道》角色绯英

• 优化音质获取能力
  • 因为发现现在获取音质的时候，明明有更高音质，总是会降级
• 主菜单支持右键快速删除歌单
• 为 macOS ARM，Windows AMD64/ARM64 进行跨平台打包
  • 龙芯亟须贡献者负责（Electron 和 Python 的问题）
  • 我们会考虑在 Linux 其他平台进行打包，如如意玲珑和 Amber PM，至于 AUR，个人认为有 AppImage 存在，没啥必要，而 Flatpak，由于执行代码存在 AI 生成内容。故不考虑为 Flatpak 打包。
• Sparkle 愚者面具 - Material Design 3 界面插件（为 Sparkle 提供主题设计模板）
• Sparkle 愚者面具 - Cover Flow
• Sparkle 愚者面具 - 对 K 记的支持
• Sparkle - 与 LX Music 的插件兼容性
• 本地音乐支持且支持刮削
• NAS 音乐库支持且支持刮削
• 桌面歌词
• MPRIS 汇报歌词为歌曲标题
• 自动更新

2.0 Jett（待定）

2.0 我们不会那么开始，我们需要评估一切，如果遇到后端或者前端开发技术栈不满足我们需求后，我们计划会使用 QML 或 Flutter 实现。

若能满足，短时间内不会考虑 Jett 分支的开发。

但我们会长期评估现在的开发平台能否继续完善，若不能，我们也会提前开启 Project Jett / Quaver v2。

后话

感觉这次没啥后面说的，真的只能说是椅瘫核，看到了如此完善的音乐流媒体软件在我用 Flash 级别的模型拷打下出来。

又要由我一个菜逼开始慢慢接手，慢慢维护😭。

与此同时，正式版发布了，但我也想说。

TME 你别拿 DMCA 干我，我是真没招了，你的 Linux QQ 音乐客户端真难用。😭