DevHub：Mac 離線開發者工具箱，68 個工具收進一個原生 App

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

日常開發裡最零碎的工作，把貼來的 JSON 排整齊、解一個 JWT、算時間戳、生一組密碼、轉一段 Base64，多數人的做法是開一排網頁工具站，把東西貼上去換個結果。DevHub 想把這一排分頁收進一個 App：Mac 上的離線開發者工具箱，從 App Store 免費下載，收錄 68 個開發小工具，標榜處理都在本機、資料不經過任何工具網站的伺服器。這個定位打得很準，需求是真的；原生 App 的安裝檔不到 6 MB，跟那些開起來就要吃幾百 MB 記憶體的 Electron 工具相比，走的是完全另一條路。

裝之前有幾個認知要先校正，而且都查得出處。GitHub 上那個兩千多星的倉庫是說明書，不是原始碼，作者本人明白說過不打算開源；「100+ 工具」是目標句，完成清單上數得到的是 68 項；「每週發佈更新」同樣是目標句，實際紀錄是 22 個月 28 次發版，最新版本停在 2026 年 1 月。本文給的是認識用的導覽；實際跑起來的效果與穩定度，要裝了才知道，但這幾件事在按下下載之前就能確認，也值得先知道。

倉庫是說明書不是原始碼，這是作者自己的決定

很多人循著 GitHub 連結找到 DevHub，會自然以為它是開源軟體。倉庫的內容很明確：30 個檔案裡沒有任何原始碼，13 份 Markdown 文件涵蓋四種語言的 README、中英文對照的更新日誌、隱私政策、服務條款與回饋說明，9 張圖片素材是七張官方截圖加上標誌與示意圖，其餘是 GitHub issue 範本與 CI 設定，Swift 檔案一個都沒有，連 LICENSE 授權檔也不存在。這個倉庫的角色是官方網站的替身：首頁、說明、條款都在，程式不在。GitHub 把它的語言標成 Swift，指的是 App 本身，跟倉庫裡有沒有程式碼是兩回事。

有人當面問過這件事。2025 年 12 月，使用者在 issue 裡許願開源，理由是開放原始碼能讓更多人幫忙加工具，作者親自回覆：「已經有很多開源專案了，目前我沒有打算把這個專案開源。」所以閉源在這裡是明確的決定，既非過渡狀態也非疏忽。安裝管道也幾乎只剩 Mac App Store：28 個版本發佈裡，只有 2024 年 3 月的首版 v1.11.0 附過一個 DMG，其後 27 版都沒有安裝資產，想裝最新版只有商店一個入口。

不過倉庫本身並非擺設，它在實務上同時是文件入口（四語 README 加官方截圖），是更新日誌（中英對照的 CHANGELOG，每版條目齊全），也是支援管道（issue 範本做了中英兩套，bug 回報要填桌面環境與系統版本，回饋頁提供 Email 與社群帳號）。從工程習慣看，作者把「社群往來」留在 GitHub、把「產品」留在商店，分工是清楚的。只是對使用者來說，這種分工有個實際後果：你在 GitHub 給的星與許願，影響的是作者的優先順序，影響不到程式碼本身，因為能動程式碼的只有作者一人。

文件本身倒是有一定水準。README 的問答段把幾個關鍵答案寫死了：支援平台只有 macOS 14 以上、定位是離線本機工具、適合不想依賴線上工具的工作流程、與網頁工具的差別在本地執行與單一入口。這些自述與隱私政策、服務條款三份文件互相咬合，內容沒有互相矛盾的地方，對個人專案來說算是扎實的文件品質。

這件事怎麼影響你的判斷？假設你在意的是「工具會不會把我貼進去的東西送出去」，開源工具你可以翻程式碼自己確認；DevHub 你只能讀它的隱私政策。政策標註的生效日是 2024 年 3 月，原文宣稱它是離線本機應用，不會主動蒐集、儲存或傳輸可識別個人或敏感的資訊，快取只存在裝置上；同一段也寫明「可能使用第三方服務，僅限提供功能所需」，權限類請求（相機、照片）只為了對應的功能。這些是官方宣稱，閉源讓你無法驗證行為層，誠實的說法就是：信任要建立在別的地方。

實際能倚賴的兩根柱子都算牢固。一根是 App Store 本身的機制：上架要過 Apple 審核、跑在系統沙盒裡、更新與退款都由商店體系處理，亂來的成本比自架官網散佈安裝檔高得多。另一根是作者的身分：jaywcjlove（Kenny Wang），蘇州的全端開發者，GitHub 上九千四百多人追蹤、兩百多個公開倉庫，同時是那份十一萬六千星、專門收集優質 Mac 軟體的 awesome-mac 清單的維護者。他在 Mac 工具圈是熟面孔，資歷經得起查；從商店的開發者頁面還能看到，DevHub 之外他也上架了 Swift 教學與 RSS 閱讀器，同樣是自家的小型 Mac 工具。這不是原始碼等級的保證，但對一個免費小工具來說，是合理可查的信任基礎。

把兩種信任模型攤開看會更明白。開源工具鏈的假設是「程式碼公開，任何人都能檢查」，你可以自己驗證，代價是要有看得懂的人；商店 App 的假設是「平台代替你審核」，Apple 審核加沙盒加統一更新管道，代價是你看不到內部。DevHub 選了第二條路，而且選得很徹底，連發佈管道都不留 GitHub 側載後門，唯一例外是 2024 年那個首版 DMG。對一般使用者，第二條路的實際體驗反而簡單：安裝、更新、退款都有單一管道；對堅持要能驗證的人，這條路天生不成立。知道自己在哪一邊，判斷就簡單了。

68 個工具是完成數，100+ 是目標數

README 裡「收錄超過 100 個工具」的句子寫的是企圖心，原文的動詞是 aiming to curate，正在朝那個規模努力。往下捲到完成清單，中英文版的勾選項目各是 68 項，這才是裝起來會看到的數量。以一個工具箱來說 68 個仍然夠肥，但如果你是被「100+」吸引來的，先知道基數。最後一個加入的工具是 Timestamp 時間戳轉換，出現在 2026 年 1 月的 v2.2.0，這也是清單目前的最新成員。

這 68 個工具的組成分佈，大致可以分成幾堆。處理文字與編碼的最多：Base64、Unicode、ASCII、HTML 編解碼、大小寫轉換、字數統計、文字比對、摩斯電碼都在。應付資料格式的有一批：JSON 排整齊、HTML 轉 Markdown、JWT 解析、URL 解析與編解碼、Prettier 格式化，還有一個內建的 CodeMirror 文字編輯器。跟圖像有關的包含條碼產生器與四種 QR 產生器（一般、Wi-Fi、事件、名片）、EXIF 查看器、ICO 轉換器、圖片轉 Base64、圖片加浮水印、圖片顏色提取、隱私模糊。系統與安全類有 chmod 權限計算器、crontab 排程產生器、隨機埠號、密碼產生器、RSA 金鑰產生、雜湊產生器、Basic Auth 產生器、SSL 憑證管理。另外有幾個帶生活味的：溫度轉換、世界時間、生命倒數、亂數假文。對前後端與維運工程師來說，日常會用到的轉換大概都摸得到一角。

以圖像相關的就有 14 個：條碼產生器、四種 QR 產生與讀取工具、EXIF 查看器、ICO 轉換器、圖片轉 Base64、圖片加浮水印、顏色提取、隱私模糊、App 圖示產生、背景填充與圖片文字辨識。四種 QR 各有用途：一般版什麼都能編，Wi-Fi 版把網路名稱與密碼編進去讓訪客掃了就連上，事件版帶行事曆資訊，名片版直接打包聯絡資訊，對門市、活動主辦這類要大量產 QR 的場景特別省事。

舉個具體情境：審計一段後端回應時，把 JWT 貼進解析器看內容與過期時間、把回應本體丟進 JSON 排版、把簽章拿去雜湊工具重算一次比對，這幾件事在網頁工具站要開好幾個分頁，在 DevHub 是同一個視窗裡的幾次切換。

官方文件列的使用情境也印證這個組成邏輯：把 JSON、HTML、URL、Base64、JWT 這類貼來貼去的東西快速排整齊與檢查、生 QR 碼與條碼、抽圖片的 EXIF 與顏色、給圖片加水印或做隱私模糊、生密碼與雜湊與 RSA 金鑰。這些工作的共通點是「單次都很小、頻率很高、內容常見但不能外流」，剛好都是網頁工具站最讓人不放心的那一類。

Pin

官方截圖裡的 Home 畫面交代了它的組織方式：左側是搜尋框加完整工具清單，常用工具可以加星收藏，主畫面用格狀卡片陳列全部工具，右上角可切換檢視方式。對 68 個工具的量體來說，搜尋與收藏是必要配備，因為多數人真正每天用的就那五六個，其餘的偶爾上場。

「離線」兩個字在這裡要拆開看。多數工具純本機就能跑，這符合定位；但清單裡有 API Request 與 NPM Stat 這種本質上就要對外連線的工具，一個讓你直接發 HTTP 請求看回應，一個幫你查 npm 套件的下載統計。官方截圖裡的 API Request 畫面就示範了送請求、收回應的完整流程，參數、表頭、回應分區清楚。所以離線指的是「App 不會把你的資料主動送去誰的伺服器」，而不是「這個 App 永遠不連網」，兩件事分開算就沒有矛盾。反過來說，你拿它處理的 JWT、內部 JSON 這類敏感內容，只要不動用對外查詢類工具，路徑就真的只在本機，這正是它相對於網頁工具站的根本差異。

Pin

再往深一層看資料路徑：JSON 排版、雜湊、編解碼這類工具是純計算，輸入輸出都發生在應用程式記憶體裡，處理完關掉視窗就沒了；會留下的是設定類資料（收藏、偏好），存在本機的應用程式容器裡；真正會離開電腦的，只有你主動發出的那些請求。對「貼進去的東西去了哪」這個問題，答案因此分三層，用一句「絕對安全」帶過反而看不出重點。

權限面也值得看：QR 讀取需要相機、圖片工具需要照片存取，政策明寫權限只為對應功能所用，檔案進入的方式以使用者主動拖放為主。這些是政策與截圖看得到的邊界，實際行為層在閉源條件下無法再往下驗，界線就畫在這裡。

有一個整合點對進階使用者很有感：URL Scheme。DevHub 註冊了 devhub:// 開頭的網址，任何工具都能被一條連結喚起，官方文件示範的用法包括：寫進網頁當超連結（例如 devhub://qrCodeEventGenerator 直達事件 QR 產生器）、貼進終端機的 open 指令、或掛進 Raycast 這類啟動器直接跳到指定工具。對每天在終端機與啟動器之間穿梭的人，這比滑選單找工具快，也讓工具箱從「打開來用的 App」變成「工作流裡隨時可呼叫的零件」。

範圍邊界也要先講清楚，免得期待錯方向。官方文件自己定位它「目標是取代散落各處的網頁工具與臨時工具站」，編輯器或 IDE 不在範圍：沒有資料庫客戶端、沒有終端機、沒有專案管理等重型功能，每一項都是幾秒鐘內完成的小活。另外有幾件事，官方資料回答不了：工具的輸出品質、極端輸入下的穩定度、多國語系在實際介面的完成度，這些都要裝了才知道；它與同類工具的功能對稱比較，官方文件也給不了答案，這裡不硬下結論。

每週更新停在目標句，發版紀錄是 22 個月 28 次

先把這個專案的年紀講清楚：倉庫建立於 2024 年 2 月，第一個版本 2024 年 3 月上架，當年 3 月到 11 月累積九次發版後進入第一次長假，2025 年 4 月復工。它不是做了十年磨出來的老工具，是一個個人專案在兩年多裡起伏的紀錄，讀接下來的節奏數字時，這個背景要先放在心裡。

跟同期的活躍開源工具相比，DevHub 在高峰期確實夠拚（2025 年 8 月一個月 6 次），但整體分佈是長短差距極大的脈衝式節奏。這種節奏對個人專案來說正常，對想把它納入工作流程的團隊就要斟酌。

作者在 README 開頭就寫，他給自己立了個大膽的目標：每週發佈更新。從 2024 年 3 月首次發版到 2026 年 1 月最後一版，實際節奏是另一個故事：22 個月裡 28 次發版，平均一個月約 1.3 次，跟「每週」差一個量級。而且節奏不是平穩的，是鋸齒狀：2024 年 3 月開局連發兩版，年底斷了四個多月；2025 年 4 月回來一次擠四版，7 月起重啟衝刺，8 月一個月 6 版是全程高峰，9 月 3 版；11 月的大改版把版本號推到 2.0、加入 macOS 26 支援，接著幾天又補了兩版；2026 年 1 月 6 日的 v2.2.0 是最後一次發版，到今天超過九個月沒有新版本。倉庫本身的活動也停在 2026 年 4 月，那幾筆提交只動了文件與 CI 設定。

維護減速的痕跡在 issue 區看得到對照。活躍期作者是會接單的：摩斯電碼加標點的許願，2025 年 5 月隨 v1.38.1 修完結案；Unicode 轉換格式的建議也在討論後關閉。2025 年 5 月到 10 月之間回報的問題則是另一種樣子：JSON 工具按鈕標題不顯示，作者當天回覆「下一個版本優化這個」；JSON 搜尋取代的許願得到「下一版會加」的承諾；還原指令閃退，作者當天重現了錯誤；圖片轉 Base64 的輸出截斷，回報者在留言裡分析到輸出被統一轉成 PNG 格式的現象。回應都在、態度健康，問題是承諾停在回覆裡：後續版本的更新日誌裡沒有指名這些修復的條目，這幾個 issue 到今天全部還開著。

更新日誌的內容也透露這個專案的重心在哪。最後幾版的內容是：v2.1.0 在修編輯器載入效能與側邊欄樣式，v2.1.1 修 ICO 轉換器與檔案拖放，v2.2.0 加了 Timestamp 工具、修多語系顯示，也修了「付費解鎖驗證錯誤」。最後這條值得停下來看一眼：連贊助解鎖的驗證邏輯都出過 bug，代表這套商業機制跟工具本身一樣在磨合，而它現在停在沒有人修的狀態。整體看，後期更新多在做效能與修錯，新工具的加入速度明顯放慢，與其說是棄坑，更像一個人維護的業餘專案回到了自然的節奏。

要不要因為停更就扣分？我的判斷是分兩層。離線工具的好處是已經寫好的功能不會因為停止維護就失效，68 個工具明天打開還是 68 個，這跟依賴雲端服務的工具有本質差異，後者說關就關。但「每週更新」這句話不能當成維護承諾來做決策：如果你要的是一個活躍修 bug 的專案，現況會讓你失望；如果你要的是一個裝了就穩定可用的工具集合，停更的傷害是漸進的，而且在免費 App 的世界裡，作者休耕幾個月再回鍋也常有前例。把它當靜態工具箱評估，別把它當訂閱制服務期待。

免費有次數概念，贊助解鎖有明確價目

DevHub 免費下載，但條款寫明免費版有使用次數的概念：超過一定用量會出現贊助提示，部分實用功能會上鎖，贊助後提示消失、功能解鎖。這是個人維護專案常見的打賞式商業模式，方向比塞廣告或拿資料變現體面，但「某些功能要付費」是真的，界線畫在哪裡官方文件沒有公佈，要裝了才知道。對輕度使用者這個設計幾乎無感，對每天開著用的人則遲早會撞到，所以把它理解成「免費試用＋你自己決定何時付費」會比「完全免費」更接近實情。條款裡的措辭也值得看一眼：作者把贊助描述成「偶爾請我喝杯咖啡」的支援，退款則明寫不由開發者經手，要走 Apple 客服的管道。

台灣商店頁列出的內購項目有六檔，價目很透明：

從 NT$90 到 NT$990，最貴的反而是單次贊助檔，小額的 Backer 與 Sponsor 像訂閱制的價格帶，不過商店頁沒有標明各檔是訂閱還是一次買斷，付款前看清楚 App 內頁的說明；商店另外註明部分內購項目可隨家人共享。還有一個數字要有正確解讀：台灣與美國商店的評分都是零則，該解讀成還沒有人留下評分，對判斷好壞沒有參考值，真正的社群訊號要看 GitHub 那兩千多星與 issue 的互動品質。

這六檔的結構也看得出設計意圖：One-off Donation 給不想被訂閱綁住的人一次付清，四個 Backer 與 Sponsor 檔位照預算分層，像月費制的贊助牆。對照開源生態，這是打賞式支持搬進 App Store 的樣子：不付錢也能用大部分功能，付錢買的是解除次數限制，以及支持作者繼續維護這件事。

次數怎麼算是另一個實務問題：條款只說超過一定限制，沒有公佈數字，也沒有說明是按工具別還是總量計。對照同類打賞制 App 的常見做法，輕度使用者通常碰不到牆，重度使用者會在幾週內碰到，DevHub 的實際界線只能裝了才知道。

跟同類選擇擺在一起看會更清楚它的位置。如果你要的是完全開源、可自架的線上工具箱，極速箱開發者工具箱那一類網頁方案更對味；若只是要免安裝的免費線上工具，黑點工具那種大集合也可以，如果你常測 API 介面，專門的LLM API 測試工具在單一用途上會做得更深。DevHub 的差異化就一句話：原生 Mac App、開箱即用、處理在本機，代價是閉源與單一平臺。

每天貼 JSON 的人裝，要開源保證的人繞過

適合裝的人輪廓很具體：Mac 上每天有零碎轉換工作的開發者，尤其是會把公司內部的 JSON、帶 token 的 JWT、客戶資料相關的字串貼進工具的人。這些東西本來就不該經過來路不明的網頁工具站，離線處理對隱私敏感的工作是實際的好處，行銷話術講不出這一條。維運與後端工程師的 chmod 計算、crontab 排程、埠號挑選這類低頻但查了就要用的東西，收在同一個 App 裡也順；重度鍵盤派加上會用 Raycast 的人，URL Scheme 會讓它從又一個 App 變成工作流裡的基礎設施。

想先繞過的，多半是這幾種情況：需要開源保證的人，作者已經明說不開源，這條路不通；不在 macOS 生態的人，它只有 Mac 版、系統要求 macOS 14 以上；把「每週更新」當採購理由的人，現況是九個多月沒發版，拿目標句當承諾會誤判。另外如果你要的是單一用途的深度工具，例如順手的 Markdown 編輯器，MarkText 這類專注的編輯器會比工具箱裡的附屬功能做得更深。

還有一個離線工具特有的問題值得先想：如果專案真的就此停更會怎樣？已安裝的 App 不會消失，商店的購買紀錄也允許重新下載，資料都在本機，沒有伺服器關閉的風險。最壞情況是 bug 永遠不修、新系統的相容性有一天出問題，屆時換工具，損失的是習慣。把這個底線想清楚，免費裝來試用的決策壓力會小很多。

想知道適不適合自己，成本最低的驗證就一步：從 App Store 裝免費版，用你每天做最多次的那件事當測試，例如把一段貼來的 JSON 排整齊。兩個觀察點：一是注意贊助提示在你用了多少次之後出現、被鎖的功能你有沒有真的用到，這決定你要不要付那 NT$90；二是開著用個幾天看順不順手，工具箱的價值在肌肉記憶，三天不順手就刪，沒有沈沒成本。看見贊助提示出現在你需要的功能上、而且那個功能確實救了你的時間，再付費不遲；要是免費額度怎麼用都夠，那它就是一個白撿的離線工具箱。