算法越做越强，用户反而跑回命令行听歌！
音乐软件塞满推荐、社交、短视频，但有一拨人正在用纯黑屏终端听自己的歌！
一个只能打字的音乐播放器，凭什么让几万首歌的管理比手机App还快。答案不在界面上，在数据归谁手里。rmp是一个基于OpenSubsonic协议的终端音乐播放器，用模糊搜索代替专辑封面浏览，用键盘指令代替滑动操作，把音乐库管理、搜索、播放全部塞进命令行。当你还在纠结“每日推荐”为什么总推同一首歌时，有人已经用三个字母搜出二十年前的冷门曲目。音乐软件的方向，可能走反了。
推荐算法越懂你，你越不知道自己在听什么
Spotify的Discovery Mode被集体诉讼指控为“现代版Payola”，用户声称平台所谓的个性化推荐其实是唱片公司花钱买来的位置。一个你每月付11.99美元的服务，推荐列表里塞满了付费推广，你还以为算法真的懂你。
推荐系统解决了一个问题：用户不知道自己想听什么。但它制造了另一个问题：用户越来越难知道自己到底在听什么。
当平台替你选歌，你的播放列表其实是平台的商业决策。算法分析你的播放记录、收藏行为、停留时间，然后预测你的下一首。这套逻辑对“随便听听”的人管用，但对另一群人完全失效。
那群人知道自己喜欢什么。他们知道自己要听哪首歌、哪个版本、哪场现场。他们的问题不是“推荐给我点新鲜的”，而是“我要的那首歌在哪儿”。
几百首歌的时候，封面浏览很直观。几万首歌的时候，浏览变成体力活。你需要的是搜索引擎，不是推荐引擎。
rmp走的就是这条路。用户输入关键词，播放器快速定位。这更像数据库查询，而不是内容推荐。音乐软件到底应该帮用户发现，还是帮用户执行？这是两个完全不同的方向。
OpenSubsonic把音乐数据从平台手里抢回来
传统音乐平台把一切都绑在自己的服务器上。你的收藏、播放列表、听歌记录，全存在平台账号里。换个平台，一切归零。
OpenSubsonic换了个玩法。
音乐服务器负责存文件和管数据库，客户端只管连接、搜索、播放。rmp只是其中一个入口。你的数据始终在你的音乐库里，不在任何平台的服务器上。
这个协议最早来自Subsonic——一个2005年诞生的个人媒体流服务器。Subsonic的创始人Sindre Mehus写了一个Java程序，让用户能从任何地方听自己电脑里的歌。后来Subsonic闭源了，但它的API活了下来，演变成OpenSubsonic。
现在支持OpenSubsonic的服务器一堆：Navidrome用Go写的，轻量到能在树莓派上跑；Gonic是另一个开源实现；还有Suboxide用Rust写的。客户端更多——手机上有Symfonium、DSub，桌面上有Supersonic、Feishin，终端里有rmp、ostui。
这套架构和NAS、家庭服务器属于同一个方向：数据在你手里，工具你随便换。
但自托管有个硬门槛。你得自己维护服务器、管理存储、配置网络。不是所有人都愿意周末泡在终端里配环境。商业平台卖的是省事，自托管卖的是控制权。两种模式满足两种人。
事情就有意思了：一个需要自己折腾的系统，反而在2025年越来越多人用。Navidrome在GitHub上攒了超过两万星。用户报告说用这套方案管理超过三万六千个文件毫无压力。 Spotify每次播放给艺人的钱是0.003到0.005美元。一张15美元的专辑，艺人到手大概1.5美元，相当于三百到五百次播放的收入。与其把钱交给平台再让平台替你选歌，不如直接买歌、自己管、自己听。
终端界面不是简陋，是去掉多余信息
很多人觉得终端软件是程序员用的东西。没封面墙、没动画、没漂亮的专辑卡片，黑底白字看着像上世纪的东西。
但rmp的价值恰恰来自这种“简陋”。
图形界面适合展示少量信息。专辑封面一排排摆开，好看，但只能看十几张。滚动、翻页、再滚动。当数据规模到几万首，人眼浏览的效率断崖式下跌。搜索输入反而成了最快路径。
Vim、Git、ripgrep都有类似逻辑。这些工具不模拟视觉世界，它们让用户直接表达需求。用户输入；系统匹配；结果执行。中间没有视觉导航。
rmp延续了这个设计。它的操作逻辑是：按几个键，打出歌名，回车，音乐响起。中间不需要滑动、不需要点开层层菜单、不需要等待封面加载。
软件效率不来自更多按钮，而来自减少用户和目标之间的距离。
rmp用Go写的，MIT协议开源。它依赖ffmpeg处理音频，在Linux上跑得最顺，OpenBSD也能用。配置写在一个文件里：服务器地址、用户名、密码。没了。
这和一个程序解决一个明确问题的Unix哲学是一个路数。但功能少就是功能少。没有推荐系统、没有社交、没有视觉化浏览。它不试图讨好所有人，它只服务一种人：知道自己要听什么的人。
简单不代表全面，代表一种明确的取舍。
功能越堆越多，边界越来越模糊
现代软件有个毛病——功能膨胀。
播放器加社交、加短视频、加社区互动、加商业推荐。最后播放器不再是播放器，成了内容平台。你打开一个音乐App，一半时间是算法喂给你的东西，另一半时间是广告。
rmp守住了边界。它只做几件事：管理音乐库、搜索歌曲、播放音乐。
这个选择在今天看起来像个异类。当所有人都在往App里塞功能时，有人选择把功能砍到只剩骨架。
但这也意味着它不适合大多数人。没有推荐系统，习惯了“随便听听”的人用不了。没有社交体验，喜欢分享歌单的人用不了。没有视觉界面，习惯看图选歌的人用不了。
可是那些抱怨“推荐越来越不准”“想找的歌找不到”“App越更新越卡”的人呢？他们可能正是rmp的目标用户。
软件行业的竞赛正在变成一个悖论：功能越多的产品，用户反而越难完成最简单的任务。打开一个播放器要等三秒加载推荐内容，但搜一首歌要翻三层菜单。这合理吗？
算法替你选，还是等你选
人工智能正在强化一个趋势：软件越来越主动预测用户。系统会告诉你：你可能喜欢什么、你下一步应该做什么、什么内容更适合你。
这种模式提高了“随便听听”的效率，但减少了用户主动表达需求的机会。
rmp展现的是另一种关系。软件不预测用户，它等用户给指令。用户拥有音乐库，用户决定播什么，软件负责准确执行。
这个区别比你想象的大。
一个总想替你做决定的系统，会越来越复杂。它要收集更多数据、训练更大模型、推送更多内容。一个只执行你决定的系统，会越来越可靠。它不需要猜你，只需要听你。
未来的软件竞争，可能不是比谁更聪明，而是比谁更清楚自己和用户之间的边界。
缓存越用越多，数据到底该放哪儿
rmp有个本地缓存机制。服务器第一次提供歌曲，本地保存一份，之后再播就不用反复从服务器拉数据。这和浏览器缓存、CDN节点是同一个思路。
第一次播要等网络，第二次播几乎秒开。在网络波动的时候，这套机制能保证连续播放不中断。
但缓存也带来了新问题。音乐文件不断往库里加，本地存储压力跟着涨。一首FLAC几十MB，一万首就是几百GB。缓存命中率高了体验好，但硬盘空间在燃烧。
一个测试场景显示，连续播放大量远程歌曲时，缓存命中率明显影响体验。但同一套机制在网络差的时候又能救命。
这就留下了一个没完全解决的问题：个人音乐库持续扩大，数据应该越来越集中在本地，还是越来越依赖远程服务器？
把数据全放本地，响应最快，但存储成本线性增长，设备迁移麻烦。把数据全放远程，存储压力转移给服务器，但每次播放都依赖网络，断网就抓瞎。
rmp的缓存策略踩在中间——热数据本地留一份，冷数据远程取。但这个平衡点怎么找，什么算热什么算冷，缓存多大合适，满了怎么淘汰？
这套实验还没跑完。答案可能因人而异：有人硬盘大、网络差，倾向全量缓存；有人网络好、存储紧，倾向即播即弃。没有一个正确答案，只有适合你场景的取舍。
而取舍这件事，正是rmp和整个自托管音乐运动的核心命题。