編注：本期內容為少數派 Matrix 社區應用自薦文章合集。文章代表作者個人觀點，作者與文中產品有直接的利益相關（開發者、自家產品等），少數派僅對標題和排版略作修改。
本期目錄1️⃣ 彈彈play：把彈幕打包帶走3️⃣ Tutti：一個聲音，響遍全場3️⃣ DeskBox：你的桌面，終於可以井井有條
彈彈play
Belcheck | iOS / macOS / Android / PC / Web | 下載地址
彈幕大概是少數幾種會讓人留念 B 站的東西。
有些影片，我更願意在原作者的 YouTube 頻道或自己的高清媒體庫里觀看：畫面更清楚，壓縮更少，也可能保留了更完整的內容。但少了 B 站同一時間點飄過的一句吐槽，觀看體驗似乎也跟著少了一塊。
有時候，真正讓我笑出來的並不完全是影片本身，而是畫面和彈幕共同完成的：某句似曾相識的台詞、一個固定出場的道具，或者創作者剛挖完坑，觀眾已經提前在螢幕上報出了答案。
畫面可以換一個地方看，這種共同觀看的感覺卻很難一起帶走。
於是我做了「彈來彈去」：粘貼一個 B 站，它只獲取彈幕，不下載、也不播放影片，再通過一層透明置頂窗口，把彈幕覆蓋到 YouTube、Infuse、IINA、QuickTime 等播放器上。
現在它已經支持 macOS 和 Windows，並在 GitHub 開源。
▍畫質和彈幕，為什麼非要二選一？
從數據上看，影片和彈幕本來就是兩套相對獨立的內容。
影片負責畫面與聲音；彈幕只需要知道兩件事：應該顯示什麼，以及應該在第幾秒出現。既然如此，彈幕並不一定非得被鎖在某個網頁或某個播放器里。
只要在影片窗口上方放置一層透明、置頂的彈幕窗口，底下播放的是瀏覽器里的 YouTube、Infuse 中的個人媒體庫，還是 IINA、QuickTime 里的本地文件，在窗口化播放場景里都沒有本質區別。
我最初以為，這是一個應該早就被解決的問題。
後來搜索才發現，類似方案並非沒有：彈彈play 在 Windows 上支持把彈幕覆蓋到 PotPlayer、mpv、MPC 等指定播放器；Danmaku Anywhere 可以給網頁影片加載彈幕；IINA 和 mpv 也有各自的彈幕插件。
但我的需求剛好落在這些方案之間：
不想為了看彈幕更換自己習慣的播放器；
不希望工具接管或重新播放影片；
既要覆蓋瀏覽器，也要覆蓋 Infuse、QuickTime 等原生應用；
既然現成方案沒有完全落在這個交集裡，我決定自己做一個。
▍一個只負責彈幕的 App
「彈來彈去」的使用流程只有四步：
粘貼 B 站，支持 BV、av、分 P 和 b23.tv 短鏈；
獲取對應影片的彈幕；
打開透明彈幕層，並把它放到影片畫面上方；
在任意播放器中打開對應的影片，完成一次時間同步。
它不讀取影片內容，也不知道彈幕窗口下面正在播放什麼。你可以用 Infuse 播放自己的媒體庫，在 IINA 里打開本地文件，也可以直接在瀏覽器里觀看 YouTube。只要兩邊是內容和時間軸大致對應的同一段影片，就能把它們組合起來。
這種設計的好處是通用：我不需要為每個播放器分別實現一套影片加載邏輯，更不會碰到畫質、字幕、HDR、音軌、網盤協議或播放權限等問題。
它只做彈幕，其餘事情繼續交給用戶已經選擇好的播放器。
但這種通用性也帶來了整個項目最麻煩的問題。
▍它怎麼知道影片播放到哪裡了？
答案是：它不知道。
因為「彈來彈去」不讀取下方播放器的狀態，所以無法自動知道影片正在播放、暫停，或者已經快進到了第幾秒。
最理想的體驗當然是自動同步：播放器暫停，彈幕也暫停；播放器跳轉，彈幕跟著跳轉；播放速度改變，兩條時間軸始終保持一致。
但如果要實現這種體驗，就需要分別適配瀏覽器、Infuse、IINA、QuickTime 以及其他播放器。有些可以通過腳本或輔助功能獲取狀態，有些只能間接猜測，還有些系統級全螢幕場景根本不允許外部窗口覆蓋。
對於一個只為了解決個人觀看需求的小工具來說，這很容易變成一項永遠做不完的工程。
我最後選擇了一個更樸素的辦法：讓彈幕使用自己的時間軸，再通過一次手動操作和影片完成同步。
加載彈幕後，點擊「5 秒後從 0 同步」，彈幕層中央會出現倒計時。我只需要把滑鼠放到播放器的播放按鈕上，在倒計時歸零時開始播放影片即可，這一個設計可以讓用戶在使用時不用受忙腳亂地去對齊進度。
如果兩邊相差一點，還可以使用 ±1 秒、±5 秒按鈕或直接輸入精確偏移進行微調。在我自己的使用中，只要兩個版本沒有明顯的片頭或剪輯差異，通常十秒左右就能對齊。
完成同步後，App 會保存這個影片的播放位置和時間偏移。下次從歷史記錄打開時，可以直接從上次的位置繼續，不需要重新從頭校準。
它沒有自動同步那麼優雅，但足夠簡單，也足夠可靠。
當然，這個方案也有明確邊界：如果兩個版本的片頭不同，可以用偏移解決；如果中間存在刪減或重新剪輯，後半段仍可能再次錯位。通用性並不是免費的，它只是把 「適配每個播放器」 的複雜度，換成了用戶偶爾進行一次手動校準。
▍真正好用的工具，應該儘量 「消失」
彈幕層位於播放器上方，但平時不應該妨礙播放器操作。
因此我加入了「滑鼠穿透」：開啟後，點擊、拖動進度條、切換全螢幕等操作都會直接落到下面的播放器上；需要調整彈幕層的位置和尺寸時，再暫時關閉穿透，窗口邊緣會出現提示邊框，可以直接拖動和縮放。
主窗口也被壓縮成兩個主要步驟：第一頁選擇彈幕來源，可以粘貼鏈接或從歷史記錄繼續觀看；第二頁只保留播放、暫停、進度、同步和微調。倍速、清屏、滑鼠穿透和導入導出等低頻操作，都收進二級菜單。
觀影時，我通常不會再切回主窗口，而是使用全局快捷鍵控制彈幕：
播放或暫停彈幕；
前後微調 1 秒或 5 秒；
從當前時刻重新同步；
顯示或隱藏彈幕層。
這看起來只是一些很小的功能，卻直接決定了一個 App 是只能演示一次，還是願意在下次看影片時重新打開。
▍從「能運行」到「願意一直用」
最早的版本只完成了四件事：解析鏈接、獲取彈幕、渲染彈幕，以及讓彈幕開始或暫停。
剩下的功能，幾乎都來自實際使用中的不滿。
拖動進度條時，時間數字沒有同步變化；主窗口資訊太多；開啟滑鼠穿透後，很難再把控制窗口找回來；長時間觀看後，兩邊的時間軸可能產生輕微偏差。
這些問題單獨看都不嚴重，但它們決定了一個「能運行的 Demo」 能否變成真正願意反覆打開的工具。
因此，我補上了播放狀態、歷史記錄、進度保存、全局快捷鍵、偏移微調、窗口位置記憶、顯示區域、密度控制和過濾功能。時間軸與窗口狀態也做了自動測試，避免修復一個問題時又破壞另一個使用場景。
工具類產品最容易忽略的，往往不是核心功能，而是核心功能前後的十幾個小動作。
▍macOS 的 Liquid Glass，以及後來的 Windows 版
macOS 版採用原生 AppKit 開發，並使用了 macOS 26 Tahoe 的 Liquid Glass 界面。主控制窗口使用玻璃材質卡片和按鈕，深色模式下則選擇了偏粉色的強調色，希望它看起來像一個系統工具，而不是套著網頁外殼的播放器。
使用新系統 API 的代價也很直接：目前 macOS 版要求 macOS 26 或更高版本。為了兼容更舊的系統重新實現整套界面，會讓這個個人項目多出不少維護成本，因此第一階段我選擇先把體驗做好。
後來我又做了 Windows 10/11 x64 原生版本。它採用 .NET 8 和 WPF，同樣包含透明置頂彈幕層、滑鼠穿透、分 P、時間軸同步、過濾、歷史記錄和全局快捷鍵。安裝包是自包含版本，用戶不需要額外安裝 .NET Runtime。
兩個版本沒有追求界面上的完全一致，但核心工作方式相同：影片由原來的播放器負責，彈幕由一層獨立窗口負責。
▍彈幕也可以不擋住畫面
一位朋友試用後，向我提到了另一個起初沒有想到的使用場景。
看經典電影，或者攝影、作畫特別出色的動畫時，人會更想好好欣賞完整的構圖、光影和細節。彈幕依然有趣，但讓文字從人物面前和精心設計的畫面上不斷飄過，有時也會破壞觀看體驗。
在站內播放器里，彈幕終究與影片共用同一塊畫面。即使可以調整透明度和顯示區域，想在關鍵鏡頭完全不受遮擋，往往還是需要手動打開和關閉彈幕。
但「彈來彈去」的彈幕層本身就是一個可以自由移動、縮放的獨立窗口，你想調整成任何比例，放在任何位置都可以，因此彈幕並不一定要蓋在影片上。
只有一塊螢幕時，可以把影片窗口放在螢幕上半部分，把彈幕層放在下半部分：上面只保留完整畫面，下面繼續顯示觀眾在同一時間點留下的反應，兩邊互不遮擋。
如果有兩塊顯示器，還可以把影片放在主屏，把彈幕層單獨放到副螢幕。主屏用來專心看電影，副螢幕則像一條與影片同步的觀眾席 —— 想看時轉一下視線，不想看時也不會干擾畫面。
這也是獨立窗口帶來的另一個價值：它不只是把 B 站彈幕帶到其他播放器，也讓畫面和彈幕可以在空間上彼此分離。彈幕既可以覆蓋在影片上，也可以退到畫面之外，成為一條獨立的觀看層。
像播客類的節目，本身畫面就不重要，你甚至可以一邊開著彈幕一邊查閱其他資料，比如這樣：
▍下載、限制與邊界
「彈來彈去」目前已經在 GitHub 開源，採用 GPL-3.0 許可證：
查看源代碼與完整使用說明
目前有幾項限制需要提前說明：
macOS 版要求 macOS 26 Tahoe 或更高版本；Windows 版支持 Windows 10/11 x64；
工具僅使用無需登錄即可訪問的公開接口，不攜帶 Cookie，因此獲取到的是當前公開彈幕池，不一定包含全部歷史彈幕；
當前支持 BV、av、分 P 和 b23.tv 短鏈，暫不支持番劇 ep/ss 鏈接與互動影片；
工具不下載影片，也不會繞過影片平台的播放權限；
獨立彈幕層在系統原生獨占全螢幕下可能無法顯示，可改用窗口最大化，或導出 ASS 字幕作為兜底；
影片版本存在中途刪減或重新剪輯時，彈幕可能需要再次校準。
這是一個獨立第三方開源工具，與嗶哩嗶哩沒有關聯、授權或合作關係。彈幕內容的權利歸原發送用戶及平台所有，請僅用於個人觀看輔助，不要用於批量抓取或商業用途。
▍還想繼續做什麼
現在的版本已經解決了我最初的問題：在 Infuse 中播放自己的高清媒體庫，或者在 YouTube 上觀看創作者發布的版本時，仍然能夠保留 B 站彈幕。
但還有一些方向值得繼續嘗試。
比如把彈幕密度顯示成時間軸熱力圖。彈幕數量往往能反映影片的情緒高點，即使不讀取具體內容，也可以提前知道接下來哪裡可能發生有趣的事情。
我也考慮過製作一個瀏覽器擴展，用來讀取 YouTube 等網頁播放器的當前進度，再與桌面 App 通過本地連接自動同步。它會讓網頁觀看體驗更加完整，不過也意味著需要針對不同網站持續適配。
至少在現在，我仍然更願意先保持這個工具的簡單：
影片歸播放器管，彈幕歸「彈來彈去」管。
我們早已習慣把影片、字幕和音軌自由組合。也許彈幕同樣不應該永遠被鎖在某一個網站裡。
有些影片值得用最好的畫質觀看，而有些梗，確實需要大家一起笑才完整。
彈彈play ： https://www.dandanplay.com/
Tutti
Barrybarrywu | iOS / macOS | 下載地址
從一個聽起來很簡單的需求開始
我用 Mac 的時候，習慣常年在桌面上接一台顯示器，有時還會連上藍牙喇叭。但是有個問題一直困擾我，它們明明都能發出聲音，但 macOS 默只能選擇其中一個作為聲音的輸出。
於是我就想：既然面前已經有兩三個揚聲器，為什麼不能讓它們同時播放？聲場效果不是更好嗎？
系統其實做得到，只是做完以後更難用了
於是我上網找了一圈，發現很多人也有和我一樣的困惑，然後看到有人推薦，使用 macOS 自帶的 「音頻 MIDI 設置」，可以創建多輸出設備。把幾個輸出勾選進去之後，同一個聲音確實能從多個設備里一起出來。
但創建多輸出設備後，平音量鍵不再像原來那樣工作；想調整聲音大小，你要一個個調，它沒有一個總音量可以同時調整所有的設備。臨時切換設備或重新組合時，也要再回到 「音頻 MIDI 設置」 里操作，這個就很方便了。
更明顯的問題是延遲。顯示器、Mac 內置揚聲器和藍牙喇叭處理聲音的速度並不相同。只要其中一台慢了一點，就會感覺到聲音對不齊，聽起來像在 KTV 里幾個人搶著唱同一句。
MacOS 系統已經提供了 「讓它們一起響」 的底層能力，卻沒有把它變成一套適合每天使用的控制體驗。原本只是想多開一個喇叭，最後卻要面對音量、同步和切換三個問題。
MIDI 設置
我先找了一圈現成方案
MIDI 這條路走不通，於是我在想是不是已經有其他更好的 APP 解決，可以解決這個問題？
我先後看了 FineTune、SoundSource 和 Loopback 等工具。它們各有不同的重心：有的主要解決按 App 調整音量，有的提供更完整、更專業的音頻路由能力。
這些產品也讓我逐漸確認，我真正想解決的並不是 「給 APP 再加一個音量滑塊」，而是把多個實體輸出設備當作一組來管理：快速選擇設備、統一控制總音量、保留各自的音量大小，並補償不同設備之間的延遲。
我尤其在意最後一點。桌上的藍牙喇叭總是比 Mac 自帶揚聲器慢一點，而我沒有找到一套完全符合自己操作習慣的解決方式。那我就想，既然沒有合適的，我就自己做一個好了，反正現在 AI 編程這麼強了。這才成為我開始做 Tutti 的理由。
把多輸出設備重新放回菜單欄
現在的 Tutti，是一個常駐菜單欄的原生 Mac 應用。打開面板後，可以像選擇普通輸出一樣勾選多個設備，讓 Mac 內置揚聲器、顯示器、藍牙喇叭、耳機或 USB 音頻設備同時播放。對了，它也可以實現類似 iPhone 上接入兩個 AirPods 的同步功能。我不懂為什麼蘋果在 iOS 上做了這個功能，但是在 MacOS 上卻沒有把它帶進來。
以我桌上的顯示器和藍牙喇叭為例，我可以先調整各自的響度，再用一個總音量統一控制整組設備。下次使用時，把這套組合存成預設，不必再回到 「音頻 MIDI 設置」重新創建。
如果兩個設備沒有同時發聲，還可以單獨增加某台設備的延遲。Tutti 不能讓較慢的藍牙設備憑空變快，它做的是把更快的設備稍微往後推，儘量讓兩邊重新對齊。
另一個場景是按 App 控制聲音。在 macOS 14.4 及以上，可以分別調整不同 App 的音量、EQ 和輸出位置。例如把音樂送到顯示器，把瀏覽器送到另一台揚聲器，減少來回切換系統輸出的次數。
我還做了個 Tutti Theater 功能，可以把把一隻喇叭設為左聲道，另一隻設為右聲道。相當於把獨立的喇叭組成一套立體聲系統，讓左右聲道分別從不同設備播放，而不是所有設備播放相同的混音。之前你在耳機裡面才能聽到的左右聲道，現在在桌面上也可以聽到了。
我甚至還做了一個 iPhone 的遙控 APP，使用 iPhone 就可以控制 Mac 上的各個設備的音量、APP 的音量，以及查看現在播放的資訊。
這些功能看起來分散，其實都圍繞同一個目標：把多設備播放從一次性的系統設置，變成菜單欄上的一個小工具。
為什麼我堅持不安裝虛擬音頻驅動
開發 Tutti 時，我給自己定了一條邊界：儘量使用 macOS 已經提供的 Core Audio 能力，不額外安裝虛擬音頻驅動、核心擴展或系統擴展。
當用戶選擇多個輸出時，Tutti 會在系統能力範圍內臨時組織這些設備；退出應用後，再恢復此前的系統音頻輸出。我希望它像一個隨時可以關掉的菜單欄工具，而不是接管整套音頻環境的基礎設施。
這並不是說虛擬音頻驅動不好。對於錄音、直播或複雜混音，它們能提供更完整的路由能力。只是 Tutti 面向的是日常播放和設備控制，我更願意用較輕的實現，換取更簡單的安裝、退出和恢復過程。
這個選擇也意味著 Tutti 有明確邊界。它不能代替專業音頻工作站，也不會覆蓋所有路由需求；我更關心的是，讓普通用戶在連接顯示器、喇叭和耳機時，不必先理解一整套專業音頻概念。
從能運行的 Demo 到願意長期維護的產品
這是我第一次真正把一個 App 從想法、代碼和測試，一直做到官網、寫幫助文檔、接入支付與售後系統。第一版很快就能用了，但我後來才發現，「能運行」 和 「可以交給別人長期使用」 之間，還有很長一段距離。
真正耗費時間的，是各種不在 Demo 里的事情：不同品牌設備的行為、藍牙重新連接、系統版本變化、異常退出後的恢復，以及某些 App 特有的兼容問題。
最初我的腦袋裡有很多想做的功能，但是我也不知道功能優先級應該怎樣排列，更不知道這個需求是否只屬於我自己。後來我找了一些用戶測試，根據他們連接的設備、實際使用方式和遇到的問題，持續疊代了一個多月，才決定正式發布。
用戶反饋
這段經歷也改變了我對 Vibe coding 的看法。藉助現有 AI Agent 做出一個能跑的原型 Demo 並不難，難的是理解每一處行為，並願意繼續處理反饋、兼容性和邊緣問題。一個產品真正的工作，往往從 Demo 能運行之後才開始。
我從一開始就不想讓 Tutti 停留在免費 Demo。基礎功能可以免費使用，高級功能採用一次買斷，用戶第一次下載就提供 Pro 的高級功能七天試用。我希望商業化帶來的不是更激進的功能限制，而是讓我有理由繼續維護這個小工具，並對用戶遇到的問題負責。
它現在適合誰，又不適合誰
如果你的 Mac 經常連接顯示器、藍牙喇叭、USB DAC 或多副耳機，或者你希望分別控制不同 App 的聲音，Tutti 會比較接近它最初想解決的場景。
應用本體支持 macOS 13 及以上；按 App 調整音量、EQ 和輸出需要 macOS 14.4 及以上。如果使用較早的系統，仍然可以使用多設備輸出和設備控制，但不會出現應用級功能。
它目前也有一些明確限制。AirPlay 設備不能加入 Tutti 的多輸出組合，因為蘋果並沒有開放這部分的 API。但是呢，我嘗試自己使用其他的方法，讓 iPad 跟 iPhone、還有其他 Mac 也可以加入到輸出設備里，預計會在下一個大版本裡面更新；部分 App 或 macOS 測試版可能出現 Core Audio 兼容問題。如果你的核心需求是 HomePod、AirPlay 多房間播放或專業錄音路由，Tutti 並不適合替代對應的專業方案。
我寧願把這些邊界提前寫清楚。音頻工具和每個人手上的硬體關係很大，同一個功能在顯示器、藍牙喇叭和 USB 聲卡上的體驗可能並不完全相同。
與同類對比
我還想知道大家音響系統是怎麼樣的？
Tutti 最早來自我自己的桌面，但發布以後，我發現大家的音響設備比我想像得複雜得多。有人連接兩台顯示器，有人需要連接聲卡，也有人同時處理會議、音樂和瀏覽器聲音。
所以我現在最想知道兩件事：你平時會給一台 Mac 同時連接哪些音頻設備？在統一音量、設備同步和按 App 分配輸出之間，哪一個問題最影響你的日常使用？
如果你願意嘗試，也歡迎把 macOS 版本、設備型號和具體問題告訴我。即使 Tutti 目前不能解決，這些真實場景也會幫助我判斷下一步應該先做什麼。
Tutti 官網下載 ： https://tutti.barrybarrywu.com/
GitHub 版本記錄： https://github.com/BarryBarrywu/tutti
更多心得： https://b23.tv/UwGlKqb
產品演示： https://b23.tv/UebCv99
DeskBox
大雨實驗室 | Windows | 下載地址
關聯聲明：DeskBox 是我使用 AI Vibe Coding 獨立開發的項目，目前在 Github 免費開源，本文不含付費推廣，本文部分內容使用了 AI 進行輔助創作。
這是我第一次在少數派寫文章，想先聊一個大多數人每天都會面對的問題：Windows 桌面為什麼總是很容易變亂？
截圖、壓縮包、微信接收的文件、臨時導出的表格、過幾天還要處理的資料，全都很自然地落到桌面上。剛開始只有幾個，後來慢慢鋪滿整個螢幕。偶爾整理一次，通常也只是把它們塞進一個叫作 「新建文件夾」 的地方。
這不完全是因為懶。
桌面本來就是電腦上最順手的臨時空間，但 Windows 給它的組織方式一直比較單一：文件、文件夾，以及擺放位置。我們可以把文件放進文件夾，卻很難在不離開桌面的情況下，看清文件夾里有什麼，也很難同時保留「隨手放」和「有秩序」 這兩件事。
我試過把桌面徹底清空，也試過啟動器、快捷方式和一些桌面美化工具。它們各有用處，但我真正想要的並不是另一個啟動器，也不是把桌面替換成一套全新的工作檯。
我只是想給原來的 Windows 桌面，多加一層簡單的整理能力。
所以我做了 DeskBox。
它簡潔，輕量，克制，免費開源，且完全遵循 windows 設計規範，能完美與 windows 的設置，個性化聯動。包括明暗模式，主題色，材質，圓角組件等。
▍格子不是桌面上的裝飾
DeskBox 最基礎的東西，是一個個可以獨立擺放和調整大小的文件格子。
其中一種叫「收納格子」。它背後對應一個真實文件夾，把文件拖進去，就會移動到對應目錄。你在資源管理器里仍然能看到這些文件，也可以正常複製、重命名、刪除和打開。DeskBox 不會把文件塞進自己的資料庫，更不會把它們變成只有軟體自己認識的格式。
另一種是「文件夾映射」。如果已經有整理好的項目目錄、下載目錄或素材文件夾，可以直接把它映射成格子。它只提供桌面上的查看和操作入口，不改變原文件的位置。
這兩種方式看起來很像，解決的卻是不同的問題。
收納格子適合接住桌面上不斷出現的臨時文件；文件夾映射適合把經常打開的目錄帶到桌面上。一個負責「把東西放進去」，一個負責「讓我隨時看得到」。
我很在意這一點，因為文件整理工具最不應該做的事情，就是把用戶的文件困在工具里。
哪天不想用 DeskBox 了，文件依然是原來的文件，文件夾也依然是原來的文件夾。
當然，如果你是第一次使用，也不用擔心，DeskBox 裡面有完整的新手指導，幾步就能理解並快速上手。
▍桌面上需要的，不只是文件
真正使用一段時間後，我發現桌面上讓人分心的並不只有文件。
有時是一件今天必須完成的小事，有時是一段稍後還要複製的文字，有時只是想看一眼天氣，或者切到下一首歌。
如果每次都要打開一個完整應用，處理成本反而有點高。所以 DeskBox 後來增加了待辦、隨記、天氣和音樂幾類功能格子。
但我並不想把它們做成對應專業軟體的縮小版。
待辦不是另一個複雜的項目管理系統。它適合快速記下一件事，在桌面上看見它，需要時再進入詳情設置截止日期、提醒和重複。
隨記也不是知識庫。它更像一張臨時放在桌面上的紙，可以寫文字、放圖片、固定常用內容，再用不同紙張稍微區分一下用途。
音樂格子只連接 Windows 的系統媒體會話，用來顯示封面、歌名和常用播放控制；天氣格子則根據尺寸自動改變資訊密度，小尺寸看當前天氣，拉大後再展示逐小時和多日預報。
這些格子的共同點是，它們都應該在需要時離手邊很近，不需要時又足夠安靜。
▍不一直置頂，也不徹底消失
桌面格子有一個很麻煩的問題：窗口層級。
如果始終置頂，它們會擋住瀏覽器、文檔和聊天窗口；如果固定在桌面底層，真正需要的時候，又得先最小化一堆窗口才能找到。
DeskBox 默認採用動態層級。通過托盤或快捷鍵喚起時，所有格子會回到前台；之後不再強行霸占最上層，而是把窗口關係重新交給 Windows 管理。
你點擊其他應用，其他應用就會自然蓋在格子上面；再次點擊某個格子，它只會回到當前窗口之前。點擊格子標題時，則可以一次喚起全部格子。
這套邏輯聽起來不算複雜，實際卻花了我很長時間。多顯示器、Win+D、快捷鍵、托盤、全螢幕窗口和不同的點擊順序，都會改變最終結果。
它也是桌面工具和普通應用很不一樣的地方：很多體驗沒有一個可以直接套用的標準答案，只能真的把它放在桌面上，每天去用。
▍我喜歡那些不太顯眼的反饋
DeskBox 基於 WinUI 3 和 Windows App SDK 開發。我會優先使用 Windows 原生組件、系統材質和窗口能力，只有原生方案無法滿足時，才自己繪製。
我不希望它看起來像一個蓋在 Windows 上面的網頁，也不希望每個操作都配上很誇張的動畫。
比如調整格子大小時，邊緣靠近其他格子或螢幕邊界，會出現輔助參考線。參考線有一點很輕的呼吸效果，不是為了炫技，而是讓對齊這件事更容易被感知。
文件拖到格子上方時也會有反饋，但我特意把它做得很弱。它只需要告訴你 「這裡可以放」，不應該一直搶注意力。
我比較喜歡這種設計：功能確實存在，但平時不大聲提醒你它的存在。
▍做得更多，不一定更好用
獨立做產品很容易陷入一個節奏：有人提了一個想法，就想趕緊做上去；看到別的軟體有一個功能，也會擔心自己是不是缺了什麼。
我前一段時間就有點著急。
結果是功能增長得很快，但有些地方只是 「先做出來了」。之前的待辦和隨記就是這樣，入口很多，資訊層級卻不夠清楚，視覺和交互也沒有真正整理好。說實話，那時候連我自己都不太想用。
後來我停下來，把這兩個格子從布局、字號、間距、選中狀態，到詳情編輯、拖動排序和批量操作重新梳理了一遍。
這個過程讓我重新確認了一件事：只有我自己長期使用起來舒服的東西，才適合交給其他人。
用戶反饋當然重要，但把每條反饋都立即變成功能，不一定是在尊重用戶。產品需要有邊界，也需要克制。有些建議我會儘量實現，有些和整體方向確實衝突的，只能抱歉地放下。
我希望 DeskBox 最後是一個簡單、好用的工具，而不是一個什麼都能做、但每件事都做得不夠舒服的工具。
▍輕量不是少幾個按鈕
一個長期放在桌面上的應用，性能本身就是功能。
早期把所有功能格子打開後，我的電腦上內存占用大約在 140MB。音樂格子還出現過連續播放和切歌后，內存不斷增長的問題。反覆切換語言、明暗模式、材質和透明度，也會留下沒有及時釋放的資源。
後面我重新整理了窗口生命周期、定時器、圖片解碼、圖標緩存、主題刷新和事件訂閱。現在在相同的日常測試環境裡，所有功能格子同時打開，內存基本穩定在 50MB 左右。
不同電腦、不同圖片和文件數量下的結果肯定不完全一樣，但我的目標很明確：當用戶沒有操作 DeskBox 時，它應該知道安靜下來。
輕量不等於界面簡陋，也不等於少用新的系統能力。它更應該意味著，不做無意義的持續刷新，不留下不再使用的資源，也不為了一個小效果引入很重的東西。
▍它適合誰，也不適合誰
DeskBox 目前主要面向 Windows 11，我也把 Windows 11 作為主要測試環境。
它比較適合習慣把臨時文件放在桌面、希望常用文件夾隨手可見，或者想在桌面保留輕量待辦和隨記的人。
它不適合需要雲同步、多人協作、複雜項目管理或完整知識庫的用戶。待辦、隨記、天氣和音樂都刻意保留了邊界，它們不會替代專業應用。
另外需要特別說明：把文件拖入「收納格子」 時，文件會真實移動到對應收納目錄；如果只想查看現有目錄而不改變位置，應該使用 「文件夾映射」。
DeskBox 仍然是一個由我獨立維護的早期產品，不同顯示器、系統縮放和桌面習慣下，也可能還有我沒有覆蓋到的問題。
▍寫在最後
Windows 給了我們一張桌面，卻沒有真正教我們怎樣整理它。
我做 DeskBox，不是想替換桌面，也不是想重新發明一套文件系統。我只是希望在已經用了很多年的 Windows 桌面上，補一點秩序。
文件有地方放，臨時內容有地方記，待辦能看見，天氣和音樂可以順手處理。需要的時候把格子叫出來，處理完之後，再把注意力交還給正在做的事情。
一點點就夠了。
DeskBox 已經開源，GitHub 提供免費安裝包。無廣告免費使用。
GitHub：https://github.com/Tianyu199509/DeskBox
官網：https://deskbox.fun/
/產品推薦/
