为什么 Claude 是 Electron 应用？

Source: Hacker News

如果代码是免费的，为什么所有应用都不是原生的？

编码代理的现状可以用这个事实来概括。

Claude 在一个代理群上花了 2 万美元，实现（大致）用 Rust 编写的 C 编译器，但桌面版 Claude 是一个 Electron 应用。

如果你不熟悉，Electron 是一个使用网页技术——HTML、CSS 和 JavaScript——来构建桌面应用的框架。它让你只需构建一次桌面应用，就能在 Windows、macOS 和 Linux 上运行，并且允许开发者复用已有的 Web 应用代码。许多你每天可能使用的应用都是用 Electron 构建的：Slack、Discord、VS Code、Teams、Notion 等（维基百科列表）。

Electron 的缺点

• 体积：每个应用都自带 Chromium 引擎，最小体积通常在几百兆字节。
• 性能：Electron 应用可能会感觉卡顿或响应迟缓。
• 集成度：它们与操作系统特定功能的集成度不高。

这些问题可以通过巧妙的开发和平台特定代码来缓解，但很少有人这么做。单一代码库、跨平台覆盖以及熟悉的网页技术带来的好处，往往让许多团队认为这些缺点是可以接受的。

编码代理的前景

当给定明确的规范和测试套件时，编码代理在跨平台、跨语言实现方面表现出色（示例文章）。理论上，这可以让 Electron 的优势变得多余：我们不必编写一个 Web 应用，而是编写一个规范，让代理为每个平台生成原生代码，从而交付快速、性能优秀的应用，且团队规模小而专注。

为什么我们仍在使用 Electron

即使是 AI 辅助编码的领军企业 Anthropic，仍然把 Claude 作为 Electron 桌面应用发布——慢、易出错且臃肿。原因包括：

1. “最后 10 %”问题——代理在前 90 % 的开发上表现出色，但处理边缘情况、打磨细节以及持续维护仍然困难、繁琐，需要大量人工指导。
2. 真实世界的复杂性——当软件投入真实使用后，会出现混乱且意料之外的场景，需要人工决策，而这些是代理无法完全自动化的。
3. 支持范围——制作三个独立的原生应用（macOS、Windows、Linux）会使 bug 修复和支持工作量增加三倍。Electron 的单一包装层减轻了许多平台特有的怪癖。

Anthropic 的基于 Rust 的 C 编译器展示了这一挑战：

The resulting compiler has nearly reached the limits of Opus’s abilities. I tried (hard!) to fix several of the above limitations but wasn’t fully successful. New features and bug‑fixes frequently broke existing functionality.
The compiler is impressive given the time and team size, but it is largely unusable. That last mile is hard.

（译：该编译器的表现几乎已经触及 Opus 能力的上限。我努力（非常努力！）修复上述几个限制，但并未完全成功。新功能和 bug 修复经常破坏已有功能。考虑到开发时间和团队规模，这个编译器已经相当令人印象深刻，但基本上不可用。最后那一段路很难。）

结论

一个完善的测试套件和规范可以让 Claude 桌面版完全原生化，但打磨最后 10 % 的工作量以及随之而来的维护负担仍然相当大。就目前而言，Electron 仍然有其意义：它能够快速实现跨平台交付，而编码代理则承担了大部分开发工作。开发的“最后一英里”以及扩大的支持范围让 Electron 在可预见的未来仍然是相关的选择。