我寫了一個軟體，幫你找回在Zune上的美好回憶……

編注：我們會不定期挑選 Matrix 的優質文章，展示來自用戶的最真實的體驗和觀點。文章代表作者個人觀點，少數派僅對標題和排版略作修改。

贊助商廣告

這是一個我和 NovaDNG 老師探討了很久的話題。打過好久嘴炮，有過很多幻想。而就在幾個月前，我決定將腦子裡那些天馬行空的想法化作現實。 Rune ，一款利用現代技術棧重新實現 Zune 神韻的開發項目就此展開。

事實上我已不止一次嘗試開發一款播放器，但限於敝人孱弱的技術水平和極其矯情的技術品味，嘗試了倉庫開了兩三個，最後全都變成了棄案。然而隨著 GPT、Claude 這類開發能力很強的模型不斷湧現，造一個火箭不再是一個遙不可及的事情。如果你之前讀過 Alice Run! 的開發報告，那應當能領教這類大語言模型解決開發問題的能力有多驚人。

借著這股「東風」，我開始了幾個月近乎瘋狂的開發之旅。

開始這篇文章之前，我想先請你點開下面的影片，看看 Rune 播放器現在的樣子。這個項目也群友被發到了 Hacker News 上，如果你感興趣的話也可以看看大家的討論（順便點個 Upvote）。

▍Why we do that

趕著科技發展如火箭般躍遷的時代，相信你我都曾對很多產品有過感動。有人第一次上手 iPhone 時，反覆開關「飛行模式」，只為了欣賞從螢幕右側飛進來的那個小飛機；有人對著 iOS 系統更新時齒輪轉動的動畫看得入神發呆；有人把窗口拖來拖去，看著 Vista 新出現的毛玻璃無比興奮；也有人看到「量子紙」的概念影片，感嘆新的設計時代已經來臨。

我曾是首批在 Web 上實現 Material Ripple 的開發者，也是首個在 Web 平台上實現高兼容性、高性能 Fluent Reveal Highlight 的開發者。

在那個黃金年代，總有一群較真的人聚在一起探討著一些在今天看來非常荒謬的問題。你或許還能記得我們曾經對 iPhone 的注塑天線口誅筆伐，對 Android 將三大金剛鍵收入螢幕感到詫異，對著一加手機那不到兩毫米的攝像頭突起惋惜「它看起來有點太凸了」。

贊助商廣告

這一盛況是從什麼時候開始衰敗的呢？每個人對這個時間點的定義可能都不同，但在我看來可能是 iOS 7 的發布。

iOS 7 will probably be really awesome when they do the visual design. Tom Coates

「在設計上胡搞也無所謂，只要你足夠大牌，它就會變得合理」，人們似乎從教宗那得到了某種啟示，自此對設計的較真勁就越來越少了。

時至今日大多數「科技大廠」只有「美工」而沒有「設計」，做得出「炫炮」的視覺並不意味著設計水平有多高，能否以充滿秩序的方式承載內容才是一個平台的首要設計價值。可惜沒人在乎，不然新版 iOS 那醜陋的圖標調色功能也不至於通過了公司內部的設計評審，堂而皇之地出現在用戶的面前。

蘋果在「設計自由奔放」上向微軟看齊，谷歌在「設計文檔稀爛」上向微軟看齊，微軟在「寡淡保守無趣」上向蘋果看齊。人們都說「好的設計是趨同的」，而把話反過來說「稀爛的設計也在趨同」。

用著手上那按什麼地方都卡一下的 Windows，我不禁發問，微軟那些手持優雅 Mac、日日讚美蘋果的設計師們，究竟是否用過自己設計出來的這坨穢物。而當年粉碎了 Material Design 的始作俑者 Luke Wroblewski 又是否靜下心來好好用過 Android。

Windows 上一款名為 Zune 的播放器，其上下文菜單的實現

越是因萬物蓬勃發展而感到興奮的人，在看到軟體工程和硬體設計質量集體墮落時，越是感到懊惱。

面對著這場狂歡，我曾彷徨無措甚是挫敗，最後一氣之下把手機換成了海信 A9 和 Jelly 2 這兩款鼓勵你「遠離手機」的設備。不再愛便不會再受到傷害，自此我找回了內心當中的安寧。

「批評會招致仇恨，抱怨不能解決問題」我還在高三時班主任曾如此勸誡過我，而直到三十歲我才領悟了其中的意涵。

抽象的評價沒有意義，我需要做些具體的事情。無論結果是好的還是壞的，我至少要實際地證明自己的想法。而這，就是當下我們交出來的答卷。

▍How we do that

贊助商廣告

如果要評選出獨立開發者五大白月光項目，GTD 系列（TODO、記賬、時間管理、日記、日曆）、編輯器系列（筆記軟體、寫作軟體、Markdown 編輯器）、CMS 及 OA 系列（博客、各類管理面板）、音樂播放器一定能擠進前四。

你打開 GitHub 簡單搜搜，就會發現大量寫了一半沒人管的倉庫。各大軟體博客介紹的新軟體里，這類軟體也必然是每期必現的常客。似乎「如何更高效地提高效率」變成了熱門話題。「告別效率，回歸工具」成為了某種潮流。

這類項目的不停湧現是因為兩個重要的特徵：技術門檻低、需求涵射範圍廣。前者意味著任何一個人，只要有想法就可以立刻下手做出一個「像模像樣」的東西。後者決定了開發者必須花費更多精力來給項目劃定明確的邊界，即定義清楚它的內涵概念和外延概念究竟是什麼，哪些東西要做，哪些東西不要做。否則，這個工程就會變成一個永遠做不完的無底黑洞，此等項目必然不得善終。

想清楚這兩件事看似困難，其核心只有一個問題：我要做的這個企劃究竟在解決什麼問題？這又被稱作是 Goal of success。

Goal of success 是一個很重要的概念。若是完滿地解決了當初提出的問題，我們就可以說這款產品達到了「功能完備」之狀態。此時開發者既可以選擇設立新的目標，也可以選擇暫時停下，將其視作是一款完備的產品，轉而追求其他的目標。

我們很少看到有開發者宣稱自己的作品達到了「Goal of success」，這確是一件憾事。我曾在《當代學生生存手冊》一書中詳細討論過此話題，若各位讀者感興趣，我可擇日以免費試讀的形式將其開放給你，故在此不再贅述。

我們這次建立新倉庫的初衷是，通過現代技術重現 Zune 之神韻，擷取歷代微軟產品設計的亮眼之處，以合理的方式編織到一個產品當中。這是一個設計實驗，我們希望重新梳理微軟設計的時序，假定歷代設計都以一種不那麼跳躍的方式演化，最後它們會以何種方式收束到 Fluent Design 2 之上。

贊助商廣告

讓我進一步澄清一下：這是一次關於產品和用戶體驗設計的實驗。

如上論述已是一個高度可操作的課題，接下來我們將其解構為數個子目標，這既是作為團隊奠基者我個人意志的投射，也可以被視作是整個項目的價值體系：

回答「2024 年的 Zune 播放器，應該長成什麼樣子」這一問題；
探究現代化的聆聽體驗的一種可能性；
如果精力允許，進一步回答：倘若微軟的 Multi-platform Vision 依舊在延續，這個設計在電腦、手機、乃至智能手錶和手環上，可能是什麼樣子。

基於此，我們給項目起名為 Rune，寄託了 Zune Revived 這一隱喻和期望。

▍What we did

目前，這個企劃已經執行到了中期階段。我們對前兩個問題做出了某種程度的解答、而對第三個問題的解答也已初具雛形。

保守的視覺

在做界面設計時，我幾乎每天都拽著 NovaDNG 討論界面設計。我們有一個共識，微軟最有辨識度的設計便是 Zune 的視覺要素和 Windows 8 的 Metro Design（磁貼設計）。

我非常能夠理解很多人討厭磁貼，因為它看起來並不精緻，且與你曾經所看過的設計差異懸殊。但我對這種設計風格抱有極大的好感，因為它是一次大膽的嘗試。Metro Design 以一種合理的方式延續了 Zune 的視覺要素，但沒有喪失基本的秩序感，甚至具備極佳的辨識度，這對一個產品和品牌來講是至關重要的。

基於這樣的共識，我們搭建起了一些基本的框架和邏輯：

媒體庫首頁和專輯列表

贊助商廣告

曲目列表

而在一些細部元素的處理上，我們參考了 Windows 10 Mobile 的視覺風格，多了一點不是很誇張的圓角，以和 Fluent Design 2 的設計標準相匹配。

媒體庫設置和媒體控制按鈕設置

談起微軟設計歷史上最濃墨重彩的一筆，不得不提 Reveal Highlight 光效。為了向其致敬，我們刻意花了一點時間給封面牆界面加入了跟隨鼠標運動的光照動畫。雖然其中的大部分實現都參考自網上已有的公開代碼，但細部的色彩調整還是花了不少時間。就結果而言，這流光溢彩光景讓我多熬的那幾個大夜顯得非常值當。甚至有幾日睡前，我打開了自己最喜歡的幾首曲子，對著螢幕上如火焰版擺動的頻譜，笨拙地站在出租屋內起舞。

我已經有好些日子不曾打內心當中感到快樂了。而那幾分鐘當中的感受，那種自心底萌生出來的喜悅，甚至讓我幻想自己臨終前是否也要以此為伴的念頭。這想法的確荒謬，但確是我當時的想法。

贊助商廣告

亮色和暗色模式的封面牆

我們對最終呈現出來的視覺風格是滿意的，拿給一些微軟開發者社區的朋友看，大家也對此抱有積極的態度。

在開發過程中，一切工作都進展地相當平順，我們並沒有遇到什麼特別難纏的工程問題。如果非要說，導航欄上下級切換時的 FLIP 動效和換頁動效（根據路由關係決定頁面淡出方向）倒是吞掉了數個夜晚。但跟之前與一些以「標新立異尋求優越感」的末流設計師合作經驗來看，這完全在可接受的範圍之內。畢竟最佳工程實踐和概念都已完備，我不必像落入浴缸的貓咪一樣瘋狂地四處撲騰，一切都有跡可循。

愚鈍的功能

在 2024 年，人們似乎更加在乎 AI，無所不用其極地將 AI 塞進每一個產品。若 AI 意味著聰明，不加入 AI 的產品無疑是「愚鈍」的。但在我看來這並不是壞事，畢竟 AI 只是一個噱頭，而它背後要解決的問題才是核心。

AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI AI 你猜我說了幾次 AI？

智能、AI 的產品往往意味著和私有化的雲服務（Some computers in other people's home）強綁定，其對應的商業模型對追求盈利的公司們有利，但不一定對你有利。

我討厭這個勢頭，並希望擺出自己的姿態作出對抗。

對於目前版本，甚至沒有任何一個功能需要聯網，整個程序甚至連遙測都沒有加。是的，我對你的個人數據不感興趣，那是屬於你的東西，我沒有想要掠奪它。

以此為產品價值取向，我們開始了對功能的規劃。

讓我們來審視一下當代人音樂消費的習慣發生了什麼樣的變化。在音樂還有物理載體的年代（像是磁帶和 CD），人們以「專輯」為單位欣賞音樂。而「MP3」的出現極大地改變了這種模式，以「播放列表」和「單曲」為單位的消費行為成為了主流。

我知道現在依然有很多人堅持尊重音樂家的創作意圖，堅持從頭到尾聽完一個專輯，並對這種零碎的聆聽方式嗤之以鼻。我尊重你高雅的品味，但我也想將更加廣泛存在的需求處理好。

贊助商廣告

推薦算法

提到推薦算法，很多讀者能想到的第一件事，可能就是根據大量用戶的聆聽習慣做聚類，這種根據真實消費行為做出來的推薦一定是最符合心理預期的。但一款離線音樂播放產品，並沒有這樣的「王之寶庫」，我們要怎麼做？

古老的技術總有它獨特的魅力。我們參考了 Sony 的 SenseMe，以及其背後的 12 Tone Analysis 算法。儘管算法本身並沒有開源，但是它的名字昭示了一切，背後的實現一望即知——Chroma Spectrum。

通過分析一首曲子在十二個半音上的能量強度，我們便可以大致了解整首作品的形態特徵。加上一些時域、頻域和主觀聽感上的特徵，構成了一個包含 61 個維度的數據空間。在這個話語體系下，「推薦一首相似的音樂」變成了「尋找在這個空間內最近的點」。聽起來挺酷炫的，但實際上就是調庫。

音頻特徵抽取方面，我們用 Rust 重新實現了一遍 Meyda ，推薦算法方面，我們則是使用了 Arroy 。不要自己造輪子，有現成的東西就拿來用是高速推進項目的重要原則，我受用至今。

基於這個資料庫，我們開發了一個類似「心情電台」的功能，沿著高維空間的對角線，取九個百分位數，以這九個點為核心畫一個圈，就組成了風格的九個播放列表。

我得承認，敝人的心理學專業背景並不足以支持更加複雜的算法研發，沿著對角線取點只是一種我能想到的權宜之計，基於此推薦出來的曲目風格可能不夠多元。或許會有更好的尋找種子點的方法，但是它完全在我的能力範圍之外。若正在閱讀此文的你有這方面的知識，還請賜教。

掌控感

我理解，對於很多用戶來講，將一切交給算法，會帶來很大的不安全感。但一首一首將音樂加入播放列表又相當麻煩。因此我一直在構想一種更加便利、友好且受控的播放列表構建範式。

我能找到的參考範本只有 iTunes 的 Smart Playlist。現在市面上能找到的「動態播放列表構建器」也都參考自這個設計。但這無疑一種相當糟糕的答案，它就像是一個 SQL 編輯器的 GUI，如果你對「數據結構」不夠了解，不能精準地拼出專輯和作曲家的名字，那這個功能根本不是為你準備的。

贊助商廣告

但我們不能期待用戶是一名數據專家和專業樂評人，這樣的設計無疑是一種轉嫁設計責任的行為，將不必要的複雜度一股腦地塞給了懵懂的用戶。就像 iOS 全新推出的圖標調色和暗色圖標功能一樣。

iTunes 的「智能播放列表」

對於這個問題，Rune 給出了不同的答案：Mix。我們將整理播放列表的過程分成了兩個步驟，「將想要的條件納入」和「把不想要的東西濾掉」，就像用榨汁機製作混合果汁一樣。你可以一次將所有符合條件的歌曲放進來。不必清晰地記住所有資訊細節，每個輸入框都配有搜索功能，輸入一個大概的資訊就會列出所有備選，而右面會實時地告訴你這個播放列表都包含什麼樣的曲目。

Rune 的 Mix

你也可以做到這些看起來很魔法的事情：「進入這個播放列表就自動進入隨機播放」「我喜歡這些專輯和作曲者，請向我推薦和它們相似的曲子」「按照我聽完整首歌的次數排序，我要反覆聽這些我喜歡的曲子」。

他不像 SQL 編輯器一樣全能，我們有意識地裁掉了「邏輯關係編輯」這類令人困惑的概念，希望最後呈現出來的產品樣態更加貼近你的直覺和日常使用習慣。

這個功能背後由一組查詢語法驅動，表現簡潔有力。唯一的遺憾是其背後的工程實現，無論是複雜度還是性能都很不理想。希望我的後端工程能力能夠早日提升到能夠優雅處理這一問題的水平，但目前為止，這已是我盡力而為的結果。

偏執的管理

接下來，我想和你聊聊開源。

Rune 是一款開源軟體，基於相對寬鬆的 MPL 協議。

MPL 允許在其授權下的源代碼與其他授權的文件進行混合，包括私有許可證。但在 MPL 授權下的代碼文件必須保持 MPL 授權，並且保持開源。這樣的條款讓 MPL 既不像 MIT 和 BSD 那樣允許派生作品完全轉化為私有，也不像 GPL 那樣要求所有的派生作品，包括新的組件在內，全部必須保持 GPL。 Wikipedia

對於個人開發者來講，將軟體開源是一個非常危險的行為，因為你會面臨被人 Fork、換牌、貼廣告、付費上架的危險。業界甚至還出過這樣的人間慘劇：Fork 的人忘記換關於頁面的聯繫資訊，導致一大堆抨擊廣告的負面評論大批大批地灌進了原始倉庫。

我充分地理解這件事情，就像我當初出版《當代學生生存手冊》時，充分理解被盜版的風險，依然選擇上架 Booth 一樣。

贊助商廣告

生物是由目的驅動的有機物集合，人類也不例外。我們做一件事情其背後必然對應著某種動機。我的動機是討好自己，而非商業利益。若是能有更多金錢灌注進來協助我改善生活，那便是好上加好，但沒有好像也沒差。我不會因此而感到憤世嫉俗或顧影自憐，我坦然地接受這些行為帶來的一切結果。

在這樣的動機之下，開源是對我個人和 Rune 最好的決策，我並不會因為這個行為失去什麼，但各位讀者將有機會更加深入地了解這款風格獨特的軟體，並有機會將我們共同在乎的價值投射在這款獨特的作品上。

在完成基礎架構設計後，我便開始為每個開發周期編製版本號，每個周期實現一些小功能，修復一些小臭蟲。這種獨自掌控整個項目的走向非常美妙，每天晚上填寫開發日誌的過程帶來了源源不斷的多巴胺噴發。我似乎構造了一個屬於自己的迷你世界，而我就是這個世界的創世神明。

掌控感是很重要的。敝人拙見，一切主觀動機背後的根源掌控感。無論是開源項目還是閉源項目，公益項目還是商業項目，其背後的核心目的都是對周遭和內部環境的塑造，其最終產物都是對特定事物的話語權。這種話語權可能是對外部事物的改變，也有可能是穩定內心世界的力量。

而終歸，那些做到一半便被拋棄的作品們，其走向末路的原因都是對主導者來講，決定核心價值的因素已經無法被自己所控制。這既有可能是因為未能滿足模糊的預期而感到失望，也有可能是對自身邊界的錯誤評估，被過大的責任和工作量壓垮。

在清楚地意識到自身管理能力和項目性質的基礎上，我選擇了一種溫和獨裁且偏執的開源社區治理策略：

目前僅支持英文：能夠以某種形式（包括大語言模型）使用英語，是一名合格開發者的基本資質。開源世界幾乎所有主流產品，其源代碼和文檔的默認語言都是英語。而無法善用這些資源，或使用這種「事實標準」進行溝通的成員應當被排除在社區之外。
贊助商廣告
不接受草率的功能請求：對於絕大多數的開源項目而言，發起者都是那個可憐的 CPU 0，這是一件極度消耗熱情的事。特別是遇到不成熟的「參與者」以一種不負責任的方式提出不切實際的需求時，以「高度社會化」的方式回應會消耗大量時間。因此我沒有打算當那個 CPU 0，只打算做自己關心的功能。當然如果開發者想要自己添加一些新功能，或者通過「完成某些工作量」來和我做一個「和需求有關的交易」，我都樂意接受。