为什么做这个项目

我认为 Rust 是当前 AI 时代非常有价值的编程语言：它有很好的性能和稳定性，能让我们做出的应用以很高的质量交付给用户。但 Rust 的编译速度和 target 目录占用，一直非常困扰我。

target 占用磁盘是当下 AI 时代非常严峻的问题，尤其在多个 worktree 上开发时，它已经是最让人头疼的事情。我为此买了 2T 的硬盘都还不够，每天都受这件事困扰。我不断寻找各类工具，kache、mdx 等都试过，但都没有真正解决我的问题。

而我是那种不受约束的人，我觉得我可以解决这个问题。既然大家都基于 Cargo，我就直接从 Cargo 本身下手，按照我的设想，结合 AI 时代的特点改造了它。

它遵循我的产品设计方式：约定优于配置（Convention over Configuration），来自 DHH 的设计思想。我认为开发者在使用 Cargo 时，本就不应该操心这种事情。kache、mdx 这类工具都需要一些繁琐的配置，我不这么做，我提供的是开箱即用：你只需要安装，它会直接替换掉你电脑上的 cargo，并提供一套适合绝大多数场景的默认配置和调优。

当然，这些改动非常激进，我不期望它们会被上游 Cargo 接受，也没有太多精力去推动这件事。上游往往要考虑得更全面，比如各种平台上的支持，而我只考虑 macOS、Linux 和 Windows 的开发支持。所以我没有那么多顾虑，可以更放手地去解决我真实遇到的问题。

目前我已经在四台电脑上实际使用：两台 Linux、一台 macOS、一台 Windows。Windows 试得比较少，但在 Linux 和 macOS 上已经连续用了 5 天，我再也没有清理过 target 目录，磁盘也再没有占满过，如下面的截图。从这个结果来看，target 目录占用的问题已经解决了。

剩下的就是编译速度，相比 Go 这类语言还是会慢一些。但我们慢一点，用户用起来更快，相当于我们先辛苦点，把好的结果留给用户。而且这个 fork 在这方面也有帮助：不再需要删掉整个 target 目录，就不会从头编译，之前编译的结果都还留着可以复用，编译其实还更快了。

看看有哪些改动和实测数据。

这一路我在 X 上的记录

• 9月17日Rust 最迫切需要解决的问题是 target 目录磁盘占用问题。
• 10月8日Rust 的编译速度和构建产物占用，已成为 AI 时代的严重瓶颈。
• 10月8日不过 Rust 这些缺点，也不是换其他语言的理由，不然只会陷入新的问题里面。
• 10月11日清理了一下 Windows 硬盘，发现之前 zed 和 gpui-kit 加起来占用了 800G。
• 10月11日重新安装 Omarchy 到 NVMe 的 SSD 盘上，跑了几个 cargo 任务，系统 load 飙到 1000 以上了。
• 10月11日打满 I/O 的原因：某个项目 60 个测试二进制，一次构建光写它们就近 47 GB。
• 10月22日在 NSH 上试用 LayerFS：新 worktree 跑完 22 项测试，14.09s 变成 0.669s。
• 10月29日huacnlee/cargo 第一次发布：把 target 强制放一起并跟 worktree 共享，减少空间占用，也提升编译速度。
• 10月29日对比原版 cargo 和 huacnlee/cargo 的差异，worktree 越多越明显。
• 11月3日第二次优化：控制 target 无限增长，专为 AI 开发、多项目多 worktree 设计；我的 MacBook 上也一直没删过。
• 11月3日已经 4 天没有清理 target 了。以前 gpui-kit 一个项目几天就到 100 GB，现在每个项目都控制下来了。
• 11月4日今天是第 5 天：电脑打满了 worktree，自动化 AI 开发，根本没遇到磁盘问题。不再全新编译，电脑也不卡了。