一顆小按鍵的官方 App 太重了，有人在選單列重寫了一個

先從一個很小的地方看起。ulanzi VibeKey 是一顆掛在螢幕上方或桌緣的小裝置，機身只有一顆按鍵和一個旋鈕，本體做的事很單純：按一下、轉一下、再按一下。硬體的介面語言用三個動作就說完了。可是當使用者把它接上 Mac，打開官方 App 之後，畫面的份量和那顆按鍵完全不成比例。App 體積偏大，功能塞得多，而且不支援跳轉到其他應用程式。這是近日 V2EX 上一則分享帖的起點：一位網友 szxczyc 嫌官方 App 不好用，於是自己動手，讓 Claude 幫他寫了一個替代品，命名為 Open VibeKey，放上 Homebrew 供同好安裝。

這件事值得從設計的角度拆開來看，因為它觸及一個老問題：硬體越小，軟體應該長成什麼樣子。

三個動作，對上一整個視窗

VibeKey 的輸入面積大概只有一枚硬幣大。按鍵可按、旋鈕可左轉右轉也可按下，攏共五種左右的觸發方式。對應到軟體端，最合理的介面形態應該也差不多這麼小。Open VibeKey 選的形態是 macOS 的選單列常駐：一個圖示掛在螢幕頂端，點開是一份清單，清單裡能做的事包括為按鍵與旋鈕綁定快捷鍵或媒體控制、把按鍵設定成打開或切換指定 App、儲存多套配置並快速切換、調整燈光與麥克風設定、切換 Mac 的音訊輸入來源，以及查看連線狀態、電量與韌體資訊。

把這份清單和官方 App 擺在一起比，差別就在「容器」的選擇。官方 App 走的是視窗路線，意味著使用者每次調整都要呼叫一個完整視窗出來；選單列版本把同樣的功能收進一個下拉面板，調整本身被設計成一次點擊內完成的動作。對一顆以「順手」為賣點的桌面小硬體來說，後者的介面重量和硬體重量是相稱的。

這裡的取捨邏輯，和 reMarkable 那類以「少」為賣點的裝置正好形成對照。先前我們看過一臺標榜只能拿來寫字的機器被裝進整個安卓的改造，那次是往「多」的方向加東西，這次則是往回減。方向相反，判斷標準卻是同一個：軟體的複雜度應該跟著硬體承諾的使用情境走。VibeKey 承諾的是桌前的快速操作，官方 App 給的卻像一套設定中心，落差就在這裡。

介面被搬到了使用發生的地方

Open VibeKey 有一個細節做得相當聰明：把 Mac 音訊輸入裝置的切換也放進選單列，還能鎖定常用輸入。這一步等於把一項原本藏在系統設定深處的功能，搬到使用者手指已經停駐的位置。VibeKey 本身帶麥克風，使用者在裝置之間切換輸入源的頻率不低，官方 App 沒有跳轉能力，於是這個斷點就被留下了。

重新設計的價值常常不在發明新功能，而在重排功能的位階。多套配置加選單列快速切換，也是同樣的手法：它假設使用者的情境會變，會議、直播、剪輯各需要一組綁定，而切換這個動作應該比打開任何 App 都快。功能清單本身沒有一項是官方 App 做不到的，差別全在排版與動線。

順帶一提，這個專案也是典型的個人側專案樣貌。開發者在補充說明裡提到，早上發現一個 bug，得晚上回家修，第一次發 App 沒經驗。這句話和產品本身一樣誠實。用 AI 協助寫出來的程式碼能不能長期維護，是我們先前在vibe coding 專案的維護觀察裡碰過的課題，Open VibeKey 這種單一目的、功能邊界清楚的小工具，恰好是這類開發模式最不容易出事的一端。

小硬體的生態位，最終由軟體決定

ulanzi 做出了好看的小硬體，這一點沒有爭議。但一顆可程式化的按鍵，買回家之後的體驗有一大半住在軟體裡。官方 App 的問題不是醜，而是沒有替「順手」這個硬體承諾設計對應的軟體形態。Open VibeKey 用一個選單列圖示示範了另一種答案：介面的尺寸，應該和使用者與它互動的時間長度成正比。

至於這個重寫版本能不能活下去，取決於後續維護，也取決於官方會不會把選單列常駐這件事學走。但至少它已經把問題講清楚了：一顆三動作的小裝置，配不上一個需要打開視窗才能用的設定中心。這個判斷，比任何一份功能清單都值得硬體廠商抄回去。