為什麼 Claude 桌面版依然選擇 Electron？筆者的深度閱讀與思考

本篇文章更新時間：2026/02/22
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。

為什麼 Claude 桌面版依然是 Electron？從 AI 寫程式的極限談起

從一篇由 Why is Claude an Electron App? 引發的思考

編輯前言：這篇文章點破了一個許多人心中的疑惑：既然 AI 寫程式已經這麼強，為什麼像 Claude 這樣的頂尖團隊，桌面版依然使用笨重的 Electron？原文以清晰的案例帶我們看到 AI 在「開發最後一哩路」上的限制。

核心觀點 (Key Takeaways)

• AI 雖能快速生成跨平台程式碼，但仍卡在最後 10% 的複雜維護與邊界情境。
• Electron 的最大價值依然是：一套程式碼、全平台通行，壓低維護成本。
• 原生開發的 bug 面積與支援負擔會隨平台數量倍增，即使 AI 協助也難完全消化。

深入解析

作者以一句話開場，既尖銳又諷刺：

Claude 花了兩萬美元讓 agent swarm 寫出一個「有點像 C 編譯器」的東西，但桌面版 Claude 卻是個 Electron app。

這其實凸顯了一個關鍵：AI 寫程式很強，但還不夠強到改變開發者的產品選擇。

Electron 的矛盾：又香又胖

Electron 的吸引力在於：

• 一套前端技術（HTML/CSS/JS）就能跨 Windows / Mac / Linux
• 可以重用既有的網頁程式碼
• 小團隊也能快速推出桌面 App

缺點同樣老生常談：

• 每個 App 就是一個小型瀏覽器，體積至少幾百 MB
• 效能不佳、記憶體占用高
• 與作業系統的整合度不如原生 App

但作者點出關鍵：這些缺點很少真正被解決，因為 Electron 的優勢實在太香，讓團隊不太有動機花時間在每個 OS 做深度最佳化。

那 AI 不就能解決這些問題？

理論上，AI 的出現應該會讓原生 App 變得更容易：

• 有明確規格（spec）與測試套件
• Agents 就能輸出跨平台、跨語言的原生程式碼

看起來我們應該能：
寫一次規格 → AI 自動產生 Mac、Windows、Linux 的原生 App

但現實卻不是這樣。

真正的瓶頸：AI 卡在「最後一哩路」

作者引述 Anthropic 在 Rust 製作 C 編譯器的經驗：

「我努力想修，但沒辦法完全成功。新功能和修 bug 會不斷破壞原本能動的東西。」

這句話直接講穿現況：
AI 很擅長寫出 90% 的程式碼，但剩下的 10% —— 也就是所有邊界條件、怪異情境、相依性問題 —— 依然需要大量人力介入。

而這 10% 往往才是最花時間的。

更麻煩的是：平台越多，地雷越多

若用 AI 生成三套原生 App（Mac / Windows / Linux），意味著：

• bug 乘以三
• 支援成本乘以三
• 測試覆蓋面積乘以三

相較之下：
Electron 只有一套程式碼，風險與維護成本立刻下降。

這也是為什麼：
即便 Anthropic 是 AI 寫程式的領頭羊，也依然選擇 Electron，而不是大膽跳進「AI 產生原生 App」的世界。

筆者心得與啟發

這篇文章讓我再次意識到：
AI 的強項在於「快速產生可能可行的結果」，但軟體開發真正昂貴的不是產生程式碼，而是讓它能在真實世界穩定運作。

更具體的反思：

• 如果產品是高迭代、高支援需求，那 Electron 目前仍是務實的選擇。
• AI 可以加速開發，但還不足以壓低「維護成本」這個最現實的瓶頸。
• 原生 App 的未來或許會被 AI 改寫，但不是現在。

對開發者來說，這篇文章其實提醒了我們：
AI 並不能替你做產品決策。技術可以進步，但複雜系統的穩定性、支援需求，以及那個永遠痛苦的最後 10%，仍然需要人類的判斷。

或許五年、十年後，AI 真的能跨過這個門檻。但目前為止，Electron 的勝利依然來自它的實用，而不是它的優雅。