Claude 糟糕透顶的 Electron Mac 应用是一场“内幕交易”★ Claude’s Criminally Bad Electron Mac App Is an Inside Job

Anthropic 于 2024 年 10 月发布了 MacOS 版 Claude “桌面”应用的首个版本——这是一个毫无亮点且笨重的 Electron 应用，根本入不了 UI 设计师的法眼。它刚发布时我曾写道：

相比之下，ChatGPT 的原生 Mac 应用是一款真正的原生 Mac 应用。它看起来像 Mac 应用，用起来也像 Mac 应用，因为它确确实实就是一个 Mac 应用。自 5 月份推出以来，我就一直很喜欢它，而且它还在不断改进。我也越来越多地将其作为解答问题的首选工具。我曾问过 Claude：“开发原生 Mac 应用的最佳方式是什么？如果目标是提供卓越的 Mac 体验，应该使用哪些框架和开发工具？”Claude 的回答一开始就指出，这是在 SwiftUI 和 AppKit 之间做出的选择。也许 Anthropic 的 Mac 工程师在打造这个糟糕透顶的 Electron 应用之前，就应该先问问 Claude 这个同样的问题。

今年 3 月，在引用 Anthropic 宣布 Claude Code 和 Claude Cowork 可以接管你的 Mac 以完成智能体（agentic）任务的消息时，我又回到了同一个问题：

Claude 的 Mac 客户端本身仍然是一个敷衍的、笨重的 Electron 应用。如果 Claude Code 真有那么好，我真不明白他们为什么不直接用它来开发哪怕是一个勉强及格的原生 Mac 应用，以此来证明其实力。

思考这个问题的不止我一个。Drew Breunig 在今年 2 月写过一篇题为《为什么 Claude 是一个 Electron 应用？》的文章：

表面上看，这种能力应该会让 Electron 的优势荡然无存！我们不应该编写一个 Web 应用然后将其分发到各个平台，而应该编写一份规范和测试套件，并利用编程智能体（coding agents）将原生代码分发到各个平台。如果这种能力真实存在且被广泛采用，用户就能从服务于广阔市场的小型专注团队那里，获得响应迅速、性能极佳的原生应用。但我们仍然在依赖 Electron。即便是 Anthropic 这样在 AI 编程工具领域处于领先地位、不断发布令人炫目的智能体编程成果的公司，在其 Claude 桌面应用中使用的仍然是 Electron。而且这是一款缓慢、漏洞百出且臃肿的应用。那么，为什么我们还要继续使用 Electron，而不去拥抱由智能体驱动、规范主导的开发未来呢？原因之一是，编程智能体非常擅长处理前 90% 的开发工作。但剩下的那部分——也就是敲定所有边缘情况，并在面对真实世界后持续提供支持——依然困难、乏味，并且需要对智能体进行大量的引导与干预。[...] 就目前而言，Electron 仍然有其存在的意义。编程智能体固然神奇，但开发工作的“最后一公里”以及后续的支持维护范围依然是个切实的难题。

我同意 Breunig 的看法，但直到他将编程智能体在最后 10% 阶段的挣扎，当作选择 Electron 来创建 Mac 应用的借口时，我不敢苟同。许多人——无论是个人还是团队——都在使用 Claude Code 创建出色的新原生 Mac 应用。仅在我的朋友中，Glenn Fleishman、Lex Friedman 和 Jason Snellman 在最近几个月里，不仅使用了一般的 AI 编程助手，更是专门使用了 Claude Code，来创建真正的原生 Mac 应用，这些应用完全符合他们个人对于“纯正 Mac 味”（Mac-assedness）的极高标准——这可是他们几十年来作为名副其实的专业 Mac 死忠粉所淬炼出的挑剔眼光。我猜，如果要把在 Claude Code 辅助下开发出来的纯正 Mac 味应用汇编成一份完整的目录，那份名单肯定会非常长。

这最后 10% 的挣扎与 AI 编程毫无关系。这是所有软件工程的固有本性。有一句著名的格言，维基百科将其称为“九十-九十法则”（Ninety-Ninety Rule），出自贝尔实验室的 Tom Cargill：

前 90% 的代码占用了前 90% 的开发时间。剩下的 10% 的代码占用了另外 90% 的开发时间。

Cargill 这种充满数学幽默的表述引起了人们的共鸣，因为它不仅解释了为什么最后 10% 的代码会耗费一半的时间，还解释了为什么软件项目的实际耗时往往是预期的两倍。无论代码是人类编写的、AI 生成的，还是两者混合的，这一普遍真理都成立。

Breunig 在一篇文章的后记中更接近了事实真相，他链接到了讨论该文章的 Hacker News 帖子。该 HN 帖子中获赞最多的评论来自 Anthropic 公司 Claude Code 团队的 Boris Cherny。Cherny 写道：

我是 Claude Code 团队的 Boris。开发这款应用的一些工程师过去曾参与过 Electron 的开发，因此更倾向于非原生的构建方式。这也是一种很好的代码共享方式，可以确保 Web 端和桌面端的功能具有相同的外观和体验。最后，Claude 非常擅长处理这种架构。话虽如此，工程的核心就在于权衡，未来这种情况可能会有所改变！

我会把“确保 Web 端和桌面端的功能具有相同的外观和体验”这一保证，重新表述为：Mac 应用受到了 Web 技术的限制，并且无法使用 Mac 原生框架所提供的那些丰富且符合原生习惯的功能。Electron 倒是能保证一个应用在所有平台上的糟糕体验一模一样。但更相关的核心信息是这句话：“开发这款应用的一些工程师过去曾参与过 Electron 的开发，因此更倾向于非原生的构建方式。”所以，并不是 Claude 有多么偏爱 Electron，而是 Anthropic 的“一些工程师”偏爱它。

“一些”这个词在这里可是个严重的轻描淡写，因为“一些工程师”中包含了 Felix Rieseberg。他目前是 Anthropic 负责 Claude Cowork 和 Claude Code Desktop 的工程主管，此前也曾是 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 应用，并且因其非原生的体验而臭名昭著。1 在 Notion 之前，Rieseberg 在 2016 年至 2021 年期间“担任 Slack 的高级工程师和工程经理，在那里我支持了一支由优秀的 C++ 工程师组成的团队，他们致力于构建跨平台桌面框架 Electron——以及 macOS、Windows 和 Linux 上的 Slack 桌面应用。”2

发现某个人——一位高级 Electron 维护者——竟然先后领导了 Slack、Notion 以及现在 Claude 的桌面客户端团队，这就好比发现掌舵泰坦尼克号、驾驶兴登堡号，后来又给阿梅莉亚·埃尔哈特担任空中交通管制员的，居然是同一个人——而且他家还是开酿酒厂的。