一個郵件客戶端先選了協定：czlmail 與 Claude 協作出來的介面，是一次誠實的功能取捨

先從一個細節看起：czlmail 不是 IMAP 客戶端。這句話聽起來平淡，但在郵件軟體的世界裡，選擇 JMAP 而非 IMAP，等於一齣戲還沒開演就先選定了一種敘事腔調。這是開發者 woodchen 在 V2EX 分享的作品，用 Claude 寫成，以 Wails 打包，開源於 GitHub，協議是 AGPL-3.0。基礎功能參照 Bulwark，涵蓋郵件、日曆、通訊錄與 WebDAV 檔案，另外加了自訂項目，例如模板透過 WebDAV 同步、系統級通知，還接入 AI 與 MCP 支援。Mac 尚未測試，開發者自己也說明了。

協定是一種排版

多數人對郵件客戶端的期待，是被 Gmail 或 Outlook 養出來的：一開就該能用，任何帳號都該登得進去。czlmail 偏偏挑了 JMAP，這個由 Fastmail 主推、以 JSON 為基礎的現代協定，而且明言「配合 Stalwart 使用」。這個組合透露出一種很具體的設計判斷：它一開始就假設使用者自架伺服器，假設你願意經營自己的郵件基礎設施。

換句話說，czlmail 的介面不是為「所有人」設計的，是為某一種人設計的：那種會自己裝 Stalwart、會在意 JMAP 比 IMAP 的同步模型乾淨多少的人。這種取捨在商業軟體裡幾乎看不到，因為商業軟體要的是最大安裝量。自用轉開源的作品反而能誠實，誠實到把「Mac 還沒測試」直接寫進分享貼文裡。

JMAP 的選擇也決定了介面的手感。IMAP 客戶端往往要處理資料夾同步的各種邊角狀態，JMAP 把狀態放在伺服器端統一管理，客戶端拿到的是結構完整的資料。這反映在功能清單上：郵件、日曆、通訊錄、WebDAV 檔案並列，四個區塊用同一套帳號邏輯貫穿。這是協定層的整齊，往上浮到介面層，就是功能之間不需要各自為政。

用 Claude 寫，寫的是什麼

開發者說這個客戶端是「用 Claude 寫的」。這句話放在幾年前會像玩笑，現在已經是一種可辨認的開發路徑。與我們先前觀察過的開發者嫌官方 App 難用、用 Claude 重寫選單列工具的情形類似，AI 協作開發正在把「一個人維護一個完整客戶端」的門檻壓低。差別在於那次是重寫一個小工具的介面，這次是從協定層往上蓋一整套郵件、日曆與檔案的組合。

這種開發方式對設計的影響很實際。傳統上，一個開源郵件客戶端最常見的死法是功能做到一半：核心收信完成，日曆永遠是「計畫中」。AI 協作讓功能面的覆蓋速度變快，於是 czlmail 可以一口氣把模板同步、系統通知、AI 接入與 MCP 支援都做出來。當然，速度換來的另一面是打磨程度：Mac 版還沒測試，這句話本身就是產品狀態的一部分。

MCP 的接入值得多看一眼。把一個本地郵件客戶端接上模型上下文協定，意味著郵件資料可以被 AI 讀取與操作，搜尋、摘要、分類都有想像空間。但也因為郵件是最私密的資料類型之一，這個功能最終落在「便利」與「暴露」之間的哪一點，要看後續的權限設計怎麼做。目前的分享裡還看不到細節，這是觀察它下一步的線索。

AGPL 是一種表態

授權條款也是設計。czlmail 選 AGPL-3.0，而不是更寬鬆的 MIT 或 Apache。對一個配合自架伺服器使用的工具來說，這個選擇說得很清楚：你可以用，可以改，但如果你把它包成網路服務提供給別人，你也得開源。這與 Stalwart 生態的氣味相合，自架、開放、可審計，一整套價值觀從伺服器端一路貫到客戶端。

對照主流郵件服務，差異就更明顯。Gmail 的設計目標是讓你離不開它的介面與生態；czlmail 加 Stalwart 的組合，目標是讓你可以隨時離開任何一家廠商。這不代表前者不好用，前者通常更好用。但在資料主權這件事上，兩種軟體給的承諾完全不同，而 AGPL 把後者的承諾寫進了法律條文裡。

一個還沒長完的東西

czlmail 目前是一個進行中的作品。功能清單比多數個人專案齊全，跨平臺狀態比多數個人專案誠實。它的價值未必在於立刻成為某人的日常工具，而在於示範了一條路徑：一個人，一個 AI 協作夥伴，一套自架伺服器，就能把「自己的郵件自己管」這件事做出一個可用的形狀。郵件是二十世紀的技術，JMAP 是這個技術為數不多的重新設計嘗試，而 czlmail 站在這個嘗試的使用者那一側。它值不值得裝，取決於你信不信 JMAP 的未來；它值不值得看，答案是肯定的。