為什麼我們不做桌面應用

當檔案不能離開私有網路時，下一個要求往往是「有沒有 Windows 或 macOS 安裝程式」。這種形態我們刻意放棄。桌面 GUI 會是第二套 UI 程式碼庫；一旦那棵樹和 /api/v1/ 分叉，「這個應用程式」與 API 之間的功能漂移幾乎不可避免。

約束是邊界，不是外殼

「位元組留在這裡」由你自己運行的 pdfx-server 就滿足了，並不特別依賴 WinForms 或 Electron 這種形態。Compose 加 pdfx（本機執行，或用 --cloud 對準你的 base URL），讓瀏覽器、REST、MCP 與 CLI 共享同一份操作目錄。

怎麼把這套堆疊立起來寫在 自架：Compose 用 task docker:build／task docker:up（API 在 :8080，入口網站在 :3000），本機開發則在入口網站旁邊跑原生的 task pdfx:dev。想要一道固定閘門就設定 SECURITY_CUSTOMGLOBALAPIKEY。本文只回答一個問題：這套堆疊為什麼不包成桌面產品。

不帶 --cloud 的本機 pdfx，在持有檔案的機器上執行 pdf-core。這已經涵蓋從不需要 GUI 的離線批次工作。雲端模式則用在同一個 CLI 要以和 curl 相同的 multipart 契約，打向你的自架或代管 API base 的時候。

桌面分叉要付出什麼代價

消費級套件最佳化的是畫布編輯、視覺化比對與應用程式商店的安裝體驗。維持那套介面，意味著在 Agent 已經在呼叫的 OpenAPI 契約之外，於 GUI 裡把每個新 op（合併旗標、OCR 模式、清理預設值）再實作一遍。

外掛與商店通路會放大支援負擔，卻不會改善 MCP 或 Idempotency-Key 的行為。每一次商店審核週期與作業系統權限提示，花掉的時間都不會落到 /v1/openapi.json 上。一旦桌面那棵樹上線了 API 沒有的合併選項（或反過來），自動化與演示就會悄悄對不上。

OCR 是個具體例子，說明重複為什麼會傷人。目前伺服器路徑回傳 Markdown（text/markdown），並區分 Auto 與 Force 兩種模式（Force 用 ocrType=force-ocr）。如果某個桌面 UI 還在承諾「帶隱藏文字層的可搜尋 PDF」，那是在描述另一條管線，等於說謊。只保留一份 op 定義，就能避開這種分裂。

一份目錄、四種用戶端、零第二套 UI

產品對同一批 op 已經有四種把手：入口網站表單、打到 /api/v1/… 的 curl、/mcp 上的 MCP，以及本機或雲端模式的 pdfx。合併 就是具體例子：依上傳順序把 PDF 合起來，不把頁面光柵化成影像，無論你是按下「處理」，還是 POST 多個 fileInput 部分。

桌面版會是第五種把手，還帶著一條獨立的發版列車。我們在意的失敗模式不是「少了一個系統匣圖示」，而是「演示頁面還能用，而依賴同一個 op 的腳本已經悄悄退步了」。

我們沒有在聲稱什麼

跳過桌面版，並不會在瀏覽器裡變出 Acrobat 等級的互動式編輯。表單工具加 HTTP 工作仍然是產品本身。線上編輯畫布、視覺化比對與消費級簽名介面，都刻意留在範圍之外。需要私有部署，就把 Compose 拉起來，讓用戶端指向你的 API base；需要像素級的編輯器，請用為這件事而生的套件，不要等 PDF123 推出一個 .exe。

代管的 PDF123 依然是快速的匿名路徑，自架則是同一套工具箱搬到防火牆之後。兩條路徑都不是第三套、會各自漂移的桌面版。與純瀏覽器轉換器的對比見 為什麼要自架 PDF 工具箱。買到什麼、要維運什麼，見 自架實際買到什麼。四種非桌面用戶端怎麼保持一致，見 同一操作，四種用戶端。