有人用 Claude 写了一个完整的 Linux 桌面——从 Wayland 合成器到 Swift 框架，全是 AI 生成的

目录

• 53 MB 的 .deb，和一个「我一个人 + Claude」的故事
• Wayland 合成器：5700 行 C，自己写了个 X11 服务器
• Flutter 框架的 Swift 移植——没有 Dart VM，没有 Flutter 运行时
• 源码探查：CLAUDE.md 里写了什么
• 它真的能用吗？——Chrome、VS Code、Blender 都在跑
• 一个人，半年，和一个问题

---

53 MB 的 .deb，和一个「我一个人 + Claude」的故事

昨天 Phoronix 上出现了一篇值得注意的报道——不是又一款 Linux 发行版，也不是 GNOME 的新版本。而是一个叫 Starling 的项目，它声称自己是一个完整的 Linux 桌面环境，而且它的代码几乎全部由 Claude 生成。

项目的唯一开发者（一个不愿透露真实姓名的人）给 Phoronix 发了一封邮件，描述了他的技术栈。我读完第一反应是——等一下，这六件事全是同一件事？

这个项目包含了：

• 一个自己的 Wayland 合成器，C 语言实现，5700 行
• 一个内嵌的 X11 服务器，支持 DRI3/Present，让老旧 X11 应用也能跑
• 一个 Flutter 框架的完整 Swift 移植——没有 Dart VM，没有 Flutter 运行时
• 一个完整的桌面 shell：窗口管理器、Dock、Launchpad、Spaces
• 五个第一方应用：设置、文件管理器、终端、计算器、应用商店
• 一个 53 MB 的 .deb 包，可以直接装在 Ubuntu 26.04 上

而这一切，按照开发者的说法，是在过去半年里「大部分通过 Claude 编写」的。

---

Wayland 合成器：5700 行 C，自己写了个 X11 服务器

Starling 的 Wayland 合成器不是那种「基于 wlroots 的封装」。它直接从底层写起，用 C 实现了以下协议：

xdg-shell、linux-dmabuf（零拷贝导入）、viewporter、fractional-scale-v1、pointer-constraints、relative-pointer、text-input-v3、presentation-time、primary-selection、idle-inhibit、cursor-shape-v1、xdg-decoration、xdg-activation、xdg-output、wlr-data-control

一共 16 个协议扩展。其中 linux-dmabuf 意味着 GPU 客户端可以直接零拷贝合成帧，不需要经过 CPU 中转。

但最让我挑眉的是这个：内嵌的 X11 服务器。Starling 不是通过 XWayland 跑 X11 应用——它自己写了一个 X11 服务器，支持 DRI3/Present。这意味着像 Zoom、WeChat 这些还在用 X11 的老应用，不需要额外的 XWayland 层就能跑。

开发者甚至在 CLAUDE.md 里写了一句：「Do not touch unless asked」——X11 服务器部分不要碰，除非被问到。显然，这部分是 Claude 写的，而且开发者不想让 Claude 再碰它。

---

Flutter 框架的 Swift 移植——没有 Dart VM，没有 Flutter 运行时

这是 Starling 最有趣的技术决策。

Flutter 的 UI 框架是 Dart 写的，运行在 Dart VM 上。Starling 的做法是：把这个框架的全部 Dart 代码移植到了 Swift。没有 Dart VM，没有 Flutter 运行时。只有 Flutter 引擎的 C 核心（skia/impeller 渲染引擎），加上一个 Swift 写的框架层。

这意味着什么？Starling 的桌面 shell 和所有第一方应用都是原生 Swift 二进制，但底层渲染走的是 Flutter 的 Skia/Impeller 管线。界面的响应式布局、组件树、状态管理——这些概念来自 Flutter 但用 Swift 重新实现了一遍。

这个移植的代码放在 sdk/ 目录下，是一个叫 FlutterSwift 的 SwiftPM 包。它还包含了 137 个测试文件。

从架构上看，这有点像把 Flutter 的「引擎和框架」分离——引擎还是 C++，框架从 Dart 换成了 Swift。开发者解释说，Flutter 的 embedder API 是一道「画得很好的接口」，让桌面 shell 可以自己提供 surface、输入和 vsync，而不需要 fork 渲染器。

---

源码探查：CLAUDE.md 里写了什么

既然这是个 AI 写的项目，我很好奇 CLAUDE.md 里写了什么。这个文件是 Claude Code 的项目指南——相当于告诉 AI「这是我们的项目，这是规则，别乱改」。

我克隆了 GitHub 仓库（starling-build/starling），读到 CLAUDE.md 的内容。它不是一个简短的提示词，而是一个完整的项目开发指南，包含了：

• 代码布局：sdk/、shell/、apps/、build/ 每个目录的职责
• 构建流程：Swift 编译、引擎 C++ 重编译、.deb 打包
• 运行方式：开发模式（root）vs 真实会话（无特权用户）的区别
• 已知陷阱清单：记录了开发过程中踩过的坑，包括「不要用 print() 调试——通过管道是块缓冲的，要用 write(2, …)」

这个文件最让我注意的是「Traps that have cost real time」章节。里面记录了 7 个具体的陷阱，每个都附带了实际调试经验：

1. ColoredBox 即使 alpha=0 也会 hit-test——用 SizedBox + Listener(behavior: .translucent) 替代
2. 注册 onDoubleTap 会杀死 DRM embedder 上的单击和双击——需手动检测
3. 子框架的增量编译不总是感知到 sdk/ 的变化——修改后需要手动清理缓存
4. 一个 C 回调如果 Swift 侧没有注册，会静默失败——看起来像渲染 bug 但实际上是回调未连接
5. 开发模式以 root 运行，掩盖了真实会话中的权限问题——Teams 在 root 下正常，在用户模式下崩溃
6. 一个 session-bus 的名称不是你声明了就你的——需要屏蔽竞争的服务
7. WASM 相关的技术债务

这些陷阱不是 AI 写的——它们是人类开发者在使用 AI 生成的代码时，逐条记录下来的。这说明了一个事实：Claude 写了大部分代码，但人仍然在调试、测试、记录。

---

它真的能用吗？——Chrome、VS Code、Blender 都在跑

根据 README 里的「What works」表格，以下第三方应用可以在 Starling 上作为原生 Wayland 客户端正常渲染：

• Chrome、VS Code、Slack、Discord、Teams、Telegram
• IntelliJ IDEA、GIMP、Blender（EEVEE 视口通过 linux-dmabuf）
• GNOME Web、GNOME Text Editor
• 覆盖了 Chromium/Electron、Qt6、GTK3、GTK4、JetBrains Runtime、Blender 的 GHOST

GPU 客户端走 linux-dmabuf 零拷贝，软件客户端走 wl_shm——两条路径都是活的。

已知限制也列得很诚实：

• 缩放实际上固定在 2.0，分数缩放会产生模糊文字
• 没有屏幕锁和屏保
• 没有通知服务
• 没有显示模式选择（只取连接器的首选模式）
• 应用商店只有 10 个条目

但这些限制对于一个 v0.2 版本来说，完全合理。毕竟这是一个一个人在半年内用 AI 写出来的东西。

---

一个人，半年，和一个问题

Starling 让我想的最多的问题不是「AI 能不能写桌面环境」（显然能），而是「一个人 + AI 能做多少事」。

六个月前，一个 Linux 桌面环境是几十个人干几年的工程。GNOME、KDE、XFCE——哪个不是几百号贡献者、十年以上的积累。现在，一个人用 Claude 写了一个能跑 Chrome、VS Code、Blender 的桌面，体积 53 MB。

这个项目的代码质量如何？从 CLAUDE.md 的陷阱清单来看，开发者花了不少时间在调试和修复 AI 生成的 bug 上。但考虑到这是一整个桌面环境，这种程度的调试量并不惊人。

从另一个角度看，Starling 的架构选择（Swift + Flutter 引擎 + 自写 Wayland 合成器）其实相当激进。它没有用任何现成的桌面组件——没有 wlroots、没有 GTK、没有 Qt。所有东西都是从头写的或者从 Flutter 移植的。这种「不依赖任何现有桌面基础设施」的路线，在传统开发中几乎不可能在半年内完成。AI 让它变得可能了。

当然，v0.2 距离日常使用还很远。但 Starling 提出的问题比它本身更有趣：当一个人 + AI 可以写一个桌面环境时，「一个人能做什么」的定义正在被重写。