你有没有遇到过这样的情况：明明手机上流畅的聊天应用，一转到电脑上就变得卡顿、耗电，甚至需要重启？这并非偶然，而是许多 AI 公司的桌面应用共同的「秘密」——它们用的还是十年前的 Electron 技术。当 AI 被吹捧为能「解决编程」时，为什么连自己的产品都改不掉这种老式架构？

一个日常的卡顿问题

普通用户可能只觉得「电脑变慢了」，但背后往往是个技术选择问题。Electron 是一个基于 Web 技术（HTML、CSS、JavaScript）的框架，用于开发跨平台桌面应用。它让开发者用一套代码同时支持 Windows、Mac 和 Linux，像 VS Code、Slack、Discord 等知名应用都依赖它。许多知名应用 都选择了这条路径，但代价是每个 Electron 应用都自带一个 Chromium 浏览器引擎，导致最小体积几百 MB、内存占用高、启动慢。用户抱怨「电脑变卡」时，往往就是这些应用在后台默默吃掉资源。

为什么 AI 公司还在用 Electron？

当 AI 编码代理技术能快速生成代码时，按理说应该能轻松移植到原生平台（如用 Swift 写 Mac 版、用 Qt 写跨平台版）。但现实并非如此。Claude 的桌面应用依然用 Electron，团队成员 Boris Cherney 在 Hacker News 讨论 中直接解释：工程师熟悉 Electron 技术栈，能保证 Web 和桌面端功能一致，而且 Claude 对 Web 开发更熟练。这听起来像「用惯了锤子，看什么都像钉子」——但技术选择从来不是非黑即白。

AI 编码代理的「最后 10%」难题

AI 在「前 90%」开发中确实高效：写基础代码、生成测试用例、甚至移植简单功能。但「最后 10%」的边缘情况却成了拦路虎。Anthropic 曾用 AI 团队花 2 万美元开发 Rust 版 C 编译器，项目详情 显示它能通过大部分测试，却「因稳定性问题难以实用」。一位开发者吐槽：「代码并非免费，你仍需为审查、QA 和维护付费」。AI 能快速生成代码，但真实世界的复杂场景（如不同操作系统的小细节、用户意外操作）仍需人类把关。

宣传与实践的差距

AI 公司一边宣称「编程已解决」，一边却用着低效的 Electron 架构。OpenAI 的浏览器应用发布四个月后仍仅支持 macOS；Anthropic 的 Claude 桌面版被用户抱怨「卡顿、耗电、占用资源」。这种矛盾让开发者质疑：如果 AI 真能轻松跨平台移植，为什么连自己的产品都改不了？一位用户直言：「看行动而非听言辞」。技术宣传和实际产品间的落差，成了行业最讽刺的注脚。

替代方案：Tauri 和原生开发的困境

有人提议用 Tauri（基于 Rust 的跨平台框架）替代 Electron，它用系统自带的 Web 视图减少资源占用。但现实很骨感：Tauri 在 Linux 上的 Web 视图支持不完善；原生开发（如 Swift 写 Mac 版、Qt 写跨平台版）又面临多平台维护成本。一位开发者用 Claude 成功将 Markdown 渲染库从 JS 移植到 Rust+Swift，但承认「需要手动调整大量细节」。AI 能加速开发，但无法消除平台差异的复杂性。

未来会改变吗？

技术选择往往取决于权衡。Electron 的「一次开发，多端部署」优势在早期阶段无可替代；但随着 AI 能力提升，未来或许会有变化。一位开发者提到：「当 RAM 价格飙升时，软件效率会重新被重视」。当前 AI 公司更关注快速迭代和功能覆盖，而非极致性能。但用户不会永远容忍卡顿——当 AI 能真正处理「最后 10%」的难题时，原生应用可能成为新标准。毕竟，没人希望自己的 AI 助手，自己却是个「老式」的卡顿应用。