为什么我又离开了 Rust 与 Bevy

前几天，我重新打开了一个已经搁置大约两年的项目：Ethertum，一款用 Rust 和 Bevy 开发的体素沙盒游戏。

重新开始时，我颇为兴奋；大约十个小时之后，我又决定放下它。

这并不是因为我不喜欢 Rust，也不是突然不想做游戏了。恰恰相反，我仍然很喜欢 Rust 的设计理念，也一直惦记着这个曾经亲手写了很久的项目。但这一次尝试让我更加确定：一个工具再漂亮，如果每次修改都很难迅速得到反馈，它就很难成为我当下做游戏的理想工具。

1我为什么喜欢 Rust

Rust 很容易让有底层开发经验的人心动。它追求接近 C/C++ 的运行性能，又试图在编译期解决许多内存与并发安全问题；所有权、借用、类型系统，以及不依赖垃圾回收器的内存管理，构成了一种很有吸引力的秩序感。

我喜欢这种严谨、克制、强调正确性的设计。再加上 Cargo 与相对统一的工具链，整个开发环境显得现代、干净、强壮。Bevy 则用 ECS 组织游戏世界，纯代码驱动，仿佛可以把整个游戏构建在一套清晰而优雅的模型之上。

我以前做过 C++ 图形和引擎相关的探索，后来也在 Rust + Bevy 上花过不少时间。Ethertum 曾承载着许多想法：自由变化的体素世界、探索、建造，以及逐渐丰富的模拟和玩法。可惜当时的开发节奏越来越慢，我最终把它搁置了。

不过，欣赏一门语言的设计，与使用它时感到顺手，是两回事。我这次又重新体会到了这种落差。

2PhotoCraft 和 AI 让我想再试一次

最近我看到 PhotoCraft，以及同一系列用 Rust 开发的创作软件。图层、蒙版、PSD、GPU 画布，许多复杂功能都在一个看上去相当完整的编辑器界面里逐步成形。它目前仍处于早期 alpha，离全面取代 Photoshop 还有很长的路，但展示出来的进展已经足以让我惊讶。¹

另一件事是 AI。我手头有很多 AI 编程额度，而今天的 Coding Agent 已经能快速阅读项目、生成模块、修改代码。我忍不住想：过去靠自己手写了很久却难以推进的东西，现在是不是可以交给 AI，大幅缩短开发时间？

我甚至不一定要继续做那种高度写实、规模庞大的沙盒。也许可以把目标收缩，尝试更复古、更纯粹的游戏风格，把注意力放回玩法和体验。Ethertum 的老代码和旧构想正好是一个起点。

这番想象很有诱惑力：Rust 的性能与工程美感、Bevy 的 ECS，再加上几乎随时可以帮忙写代码的 AI，似乎正好组成了一套梦寐以求的工作流。

但其中有个我忽略的问题：PhotoCraft 证明了 Rust 能支撑复杂桌面软件，却不意味着 Bevy 的游戏开发迭代也一样顺畅。 PhotoCraft 的桌面界面主要使用 egui/eframe，GPU 画布采用 wgpu，它甚至不是一个 Bevy 项目。¹

更重要的是，AI 生成代码的速度，并不是游戏开发的全部速度。

3十个小时之后，我又停了下来

重新打开 Ethertum，最熟悉的挫折几乎立刻回来了：迭代实在太慢。

游戏开发不是只要代码通过编译，就能知道结果好不好。人物的移动速度、跳跃手感、画面的尺度、界面的布局、一个交互有没有趣，都需要运行游戏，亲自试过才知道。

我想要的循环是：

想到一个点子 → 改动 → 运行 → 试玩 → 再改。

而现实变成了：

想到一个点子 → AI 修改大量代码 → 编译 → 解决编译或配置问题 → 等待 → 终于运行 → 发现仍要继续调整。

这次甚至出现过编译等待五个小时还没顺利完成的情况。更令人沮丧的是，切换 IDE、改动项目和编译配置之后，构建缓存不能按预期复用，又开始重复编译。时间就这样耗在与工具链周旋的过程中。

我知道，这不代表所有 Rust 项目都会编译五小时。第一次构建、依赖规模、编译配置、目标平台、缓存失效，都可能影响时间；Bevy 官方也提供动态链接等优化建议。² 我不想把自己这次的极端体验冒充客观的普遍结论。

但对于实际开发的人，问题也很简单：不管是什么原因，只要每次试错都需要等很久，我的创作欲望就会被消耗。

刚开始，我可能想尝试五种参数、三种界面布局；经历漫长的编译之后，却只想先把眼前这一个版本跑通。开发的节奏从自由实验变成了尽量少改、尽量不要破坏当前状态。

3.1AI 生成得越快，等待越显眼

过去手写代码时，编码本身占据了大量时间。现在 AI 可以几分钟内产出几百行乃至更多代码，但它不能自动保证代码正确，也不能替我完成最终的手感判断。写代码变快后，编译、运行和验证反倒成了更突出的瓶颈。

AI 修改了大量文件，项目却迟迟不能运行；等到终于看到效果，发现需要调整的地方还有很多。改动越多，问题越难定位，下一次试验的成本也越高。

这次我还让 AI 改过 UI。结果并不好看：很普通，甚至像廉价的网页，完全没有我期待的游戏气质。而 UI 恰恰是一种需要不断观察、尝试、推翻重来的东西。如果改一个布局都要付出漫长的构建成本，精细打磨就很难持续。

有点讽刺的是，我的 AI 额度变多了，真正能完成的有效迭代却没有同步增加。 能生成更多代码，不等于离一款更好玩的游戏更近。

4Rust 写起来也没有我想象中顺手

如果只是编译慢，我也许还会愿意继续折腾工具链。但另一项阻力从来没有消失：对我而言，Rust 本身的编写体验并不轻松。

所有权、借用与生命周期的约束当然有价值，能够阻止一类错误。但在实际写游戏时，我常常需要先考虑数据如何归属、哪些地方允许同时访问、对象应该怎样组织，才能把本来想做的功能写出来。Bevy 的 ECS 又增加了一套关于实体、组件、资源、系统和查询的思考方式。

这些不是糟糕的设计。只是对于我熟悉的编程习惯，它们有时会成为额外的心理负担。

更有意思的是，我甚至觉得 C++ 比 Rust 更简单、更流畅。这不是在讨论两门语言客观上的难度，更不是说 C++ 在安全性上更优秀。我只是对 C++ 的表达方式更熟悉：想好数据与行为的关系，就能很快写出来、动手验证。Rust 往往要求我先调整表达方式，再去实现行为。

AI 可以帮助写过编译器这一关，但它没有让我完全摆脱理解、维护和调试这套代码的成本。于是问题并非只在编译速度：编写时不够顺手，加上验证时等待太久，两种阻力叠加在一起，才最终让我又一次选择离开。

5我更在意的，已经不是代码有多漂亮

过去我很容易迷恋技术方案的优雅：性能、内存占用、抽象成本、安全性、架构是否纯粹。这些指标依然重要，但对于现在想做游戏的我而言，还有一种效率更加直接：

今天想到一个玩法，今天能不能玩到？觉得某个交互有点别扭，能不能马上试试另一种方案？一个 UI 看着不对劲，我能不能轻松改上十遍？

这些问题没有漂亮的 Benchmark，却直接决定着游戏能不能持续向前生长。

Rust 和 Bevy 也不是完全没有改善方案。例如 Bevy 0.17 已经开始集成基于 subsecond 的实验性 Rust Hotpatching，允许部分代码在不重启程序的情况下更新。³ 但热更新不等于完全绕开编译，也不能假定所有类型的改动、所有构建环境都能获得成熟稳定的即时反馈。

当然，Unity 也会让我累。C# 编译、域重载、资源导入、Prefab 和场景调试，都有让人烦躁的时候。但以我现在的经验，用自己更熟悉的语言和工具把一个玩法迅速跑起来，仍然比追求技术栈的形式美感更重要。

我原本想用充足的 AI 额度弥补过去的遗憾，却重新意识到：代码生成只是开发流程的一部分。真正让游戏变得有趣的，是不断试玩、修改、否定，再尝试。

6我不讨厌 Rust，只是现在不想再等了

Ethertum 被我放下过一次，如今又放下了一次。说不遗憾当然是假的。那里面有过去的我写下的代码，也有一直没有真正实现的想法。

但这并不意味着我彻底放弃 Rust 或 Bevy。也许未来编译、热更新和 AI 自动化验证更加成熟，也许某一天我又遇到一个特别适合它们的项目，我还会回来。

至少这一次，我想把精力从工具链重新转向游戏本身。

我依然喜欢 Rust 的严谨与优雅，但比起写出一套漂亮的代码，我更想尽快做出能玩的东西。

游戏不会因为它的底层代码足够优雅就自动变得有趣。它终究需要一次又一次地运行、观察和修改。而对现在的我来说，能够让这些尝试轻松发生的工具，比一套看上去完美的技术栈更珍贵。

注释

1. ArtCraft Team，PhotoCraft — GitHub README。项目的官方介绍，说明 Rust、egui/eframe、wgpu 技术栈和早期 alpha 状态，用于交代本文重新尝试 Rust 的契机。 ↩ ↩²

2. Bevy Project，Getting Started — Setup。官方开发文档介绍动态链接及其他减少开发期编译时间的方法与限制；本文的具体等待时长是个人经历，不是来自官方数据。 ↩

3. Bevy Project，Bevy 0.17 Release Notes。官方介绍基于 subsecond 的初步 Rust Hotpatching 集成。 ↩