Claude 糟糕的 Electron Mac 應用程式原來是「內部傑作」

Claude 糟糕的 Electron Mac 應用程式原來是「內部傑作」

Anthropic 在 2024 年 10 月發佈了首個適用於 MacOS 的 Claude 「桌面」應用程式版本——這是一個讓用戶介面（UI）設計師感到失望的 Electron 笨重產品。當它推出時，我寫道：

「另一方面，ChatGPT 的原生 Mac 應用程式，是一個真正的原生 Mac 應用程式。它看起來像 Mac 應用程式，感覺也像 Mac 應用程式，因為它確實就是一個 Mac 應用程式。自從它在 5 月推出以來我就一直很喜歡它，而且它還在不斷改進。我越來越多地將它作為我回答問題的首選資源。」

我曾問過 Claude：「開發原生 Mac 應用程式的最佳方法是什麼？如果目標是獲得出色的 Mac 體驗，應該使用哪些框架和開發工具？」Claude 的回答首先假設這是在 SwiftUI 和 AppKit 之間做出的決定。也許 Anthropic 的 Mac 工程師在開發這個 Electron 垃圾應用程式之前，應該先問問 Claude 同一個問題。

今年 3 月，在連結到 Anthropic 宣佈 Claude Code 和 Claude Cowork 可以控制你的 Mac 以完成代理任務的消息時，我回到了同一個問題：

「Claude Mac 客戶端本身仍然是一個懶惰的 Electron 笨重產品。如果 Claude Code 真的那麼好，我不明白為什麼他們不透過使用它來製作一個哪怕只有一半水準的原生 Mac 應用程式來證明這一點。」

我不是唯一一個思考這個問題的人。Drew Breunig 在今年 2 月寫了《為什麼 Claude 是一個 Electron 應用程式？》：

「從表面上看，這種能力應該會讓 Electron 的優勢變得過時！與其編寫一個網頁應用程式並將其發佈到每個平台，我們應該編寫一個規範和測試套件，並使用編碼代理（coding agents）將原生代碼發佈到每個平台。如果這種能力是真實存在並被採用的，用戶就能從服務於廣大市場的小型、專注團隊中獲得敏捷、高效的原生應用程式。」

「但我們仍然依賴 Electron。即使是 AI 編碼工具的領導者之一 Anthropic，雖然不斷發佈閃亮的代理編碼成就，但在 Claude 桌面應用程式中仍然使用 Electron。而且它是一個緩慢、多錯誤且臃腫的應用程式。」

「那麼，為什麼我們還在使用 Electron，而不擁抱代理驅動、規範驅動開發的未來呢？」

「一方面，編碼代理在開發的前 90% 階段非常出色。但最後的一小部分——解決所有邊緣情況並在進入現實世界後持續提供支援——仍然很困難、乏味，並且需要大量的代理引導。[...] 目前，Electron 仍然有其意義。編碼代理很神奇。但開發的最後一哩路和支援範圍仍然是一個真正的擔憂。」

我同意 Breunig 的觀點，直到他接受「編碼代理在最後 10% 階段感到吃力」作為選擇 Electron 創建 Mac 應用程式的理由。很多人——無論是個人還是團隊——都在使用 Claude Code 來創建出色的全新原生 Mac 應用程式。僅在我的朋友中，Glenn Fleishman、Lex Friedman 和 Jason Snellman 在最近幾個月都使用了不僅僅是普通的 AI 編碼助手，而是專門使用了 Claude Code，來創建真正的原生 Mac 應用程式，這些程式符合他們自己對「Mac 風格」的高標準，而這些標準是透過數十年的專業 Mac 挑剔眼光磨練出來的。我懷疑，如果要把在 Claude Code 協助下製作的具有 Mac 風格的應用程式列成一份詳盡清單，那將會非常長。

最後 10% 的掙扎與 AI 編碼無關。這是所有軟件工程的本質。有一個著名的諺語，維基百科稱之為「九九定律」（Ninety-Ninety Rule），歸功於 Bell Labs 的 Tom Cargill：

「前 90% 的代碼佔用了前 90% 的開發時間。剩下的 10% 代碼則佔用了另外 90% 的開發時間。」

Cargill 這個數學上的幽默公式之所以能引起共鳴，是因為它不僅解釋了為什麼最後 10% 消耗了一半的時間，還解釋了為什麼軟件項目往往比預期花費多一倍的時間。無論代碼是人類編寫的、AI 生成的，還是兩者混合的，這個普遍真理都適用。

Breunig 在一篇後記中更接近真相，他連結到了討論他文章的 Hacker News 討論串。該討論串中評分最高的評論來自在 Anthropic 的 Claude Code 團隊工作的 Boris Cherny。Cherny 寫道：

「我是來自 Claude Code 團隊的 Boris。」

「一些開發該應用程式的工程師當年曾從事過 Electron 的工作，因此更傾向於非原生構建。這也是一種很好的代碼共享方式，因此我們可以保證網頁版和桌面版的功能具有相同的外觀和感覺。最後，Claude 非常擅長這一點。」

「話雖如此，工程就是權衡取捨，這在未來可能會改變！」

我會將「保證網頁版和桌面版的功能具有相同的外觀和感覺」這句話重新表述為：保證 Mac 應用程式受到網頁限制的束縛，並與 Mac 原生框架提供的廣泛慣用原生功能隔絕。Electron 保證了一個應用程式在所有平台上感覺都同樣錯誤。但更相關的細節是這句話：「一些開發該應用程式的工程師當年曾從事過 Electron 的工作，因此更傾向於非原生構建。」所以，並不是 Claude 以某種方式偏好 Electron，而是 Anthropic 的「一些工程師」偏好它。

這裡的「一些」承載了很大的份量，因為「一些工程師」中包括了 Felix Rieseberg，他目前是 Anthropic 的 Claude Cowork 和 Claude Code 桌面版的工程主管，此前曾是 MacOS 和 Windows 版 Claude 應用程式的工程主管。Rieseberg 不僅僅是「當年從事過 Electron 的工作」。他是負責創建 Electron 的主要人員之一，至今仍是 Electron 項目行政工作小組的三名成員之一，該小組「監督整個治理和項目」。他簡直就是寫了關於 Electron 的教科書的人。

Felix Rieseberg 顯然就是「為什麼 Claude 是一個 Electron 應用程式」這個問題的答案。這就像是在納悶為什麼一棟建築裡所有的螺絲都是被錘進牆裡的，然後發現負責監督施工的人創辦並共同擁有了全球最大的錘子製造廠。Windows 使用十字螺絲，Linux 使用內六角螺絲，而 MacOS 則需要星形螺絲（當然）——但錘子對所有螺絲的作用都是一樣的。那就是 Electron。那是 Rieseberg 的心血結晶。

事實證明，Rieseberg 不僅參與了將 Claude 打造為 Electron 應用程式。根據他的個人主頁和 LinkedIn 檔案，在加入 Anthropic 之前，他在 Notion 擔任了兩年多的桌面團隊工程經理，Notion 的 Mac 客戶端是一個巨大的 518 MB Electron 應用程式，且以非原生體驗著稱。在 Notion 之前，Rieseberg 於 2016 年至 2021 年期間「在 Slack 擔任高級首席工程師和工程經理，在那裡我支持了一支由出色的 C++ 工程師組成的團隊，構建了跨平台桌面框架 Electron——以及 Slack 適用於 MacOS、Windows 和 Linux 的桌面應用程式」。

發現同一個人——一位 Electron 的高級維護者——領導了 Slack、Notion 以及現在 Claude 的桌面客戶端團隊，就像發現是同一個人——他的家族生意是蒸餾廠——掌舵了鐵達尼號、駕駛了興登堡號，然後又擔任了 Amelia Earhart 的航空管制員。

值得指出的是，Notion 或許已經意識到了他們的錯誤。Apple 在上個月的 WWDC 平台國情咨文技術演講中顯著地介紹了 Notion，並表示：「以前使用跨平台或網頁技術的應用程式（如 Notion）正在將其用戶介面遷移到 SwiftUI，因為他們希望獲得其他技術無法提供的效能水平和 UI 一致性。」這發生在 Rieseberg 離開前往 Anthropic 的僅僅一年後。也許 Claude 最終也會尋求洗掉 Claude 應用程式身上的 Electron 臭味。不過，我懷疑 Electron 的代碼庫就像樹液一樣——黏糊、骯髒，而且等待的時間越長就越難洗掉。