把彈幕「打包」帶走，解鎖高清版視頻的吐槽自由

編注：本期內容為少數派 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/

/產品推薦/