Rust 在 AI 时代：一个被误读的"优势"

有一种流行的推理：AI 会写代码之后，Rust 那套"难学、难写、开发慢"的劣势就被抹平了，剩下的全是"安全、快、省心"的优势——所以 AI 时代 Rust 会大占便宜。

这篇文档想说清楚一件事：这个推理漏掉了一笔账。Rust 的开发成本并没有消失，它只是从"人的时间"换成了"机器的 token"，而且换过去之后，被一种叫上下文复利的机制放大了数倍——放大的倍数还取决于一个大多数人没意识到的变量：你把一个会话开了多久。

一、先给 Rust 说句公道话

在拆迷思之前，得先承认 Rust 确实是一门优秀的语言，否则后面的讨论就成了打稻草人。

Rust 的核心价值，是把一整类 bug 消灭在编译期。

它的所有权（ownership）和借用检查（borrow checker）系统，让"内存越界、悬垂指针、数据竞争"这些在 C/C++ 里能藏十年、一上线就炸的问题，在代码还没跑起来之前就被编译器拦下。你写不出一个有数据竞争的 Rust 程序——不是因为你小心，而是因为编译器不允许它编译通过。

这带来一个非常实在的工程收益：Rust 是"开发时痛苦、运行时省心"的语言。

• 开发阶段：你要和借用检查器搏斗，一个生命周期标注能卡你半天，编译器像个不通人情的审稿人，把你的代码打回重写。
• 运行阶段：一旦编译通过，程序往往就很稳。没有 GC 停顿，没有内存泄漏，没有"线上跑三天崩一次"的玄学问题。性能接近 C，资源占用可预测。

它的适用场景也因此非常清晰：

• 操作系统、数据库、浏览器引擎、编译器这类"错了就是灾难"的底层系统
• 高并发、高吞吐、对延迟敏感的网络服务（网关、代理、消息中间件）
• 长时间运行、不能随便重启的基础设施
• WebAssembly、嵌入式等对资源和安全都有硬要求的场景

一句话总结 Rust 的传统账本：它用"开发期的额外投入"，换"运行期的额外安心"。 这笔交易在人类写代码的时代是划算的——因为运行期往往长达数年，而开发期只是一次性的、封顶的。

记住这句话，它是整篇文档的支点。

二、AI 来了，这笔账看起来被改写了

2024 年之后，一个很自然的推理开始流行：

"Rust 最大的成本是开发慢、学习曲线陡。可现在代码是 AI 写的，人不用一行行敲了。开发慢这个劣势，不就被 AI 抹平了吗？那 Rust 不就只剩下'安全 + 高性能'的纯优势了？"

这个推理的前半段是对的。AI 确实把"人写 Rust 很慢"这件事很大程度上解决了。 你不再需要花半年学会生命周期，你可以让 agent 去和借用检查器搏斗。从"人的认知负担"这个角度看，Rust 的门槛被大幅削平了。

但后半段——"所以 Rust 只剩优势"——犯了一个经典错误：它默认开发成本被消灭了，而实际上开发成本只是换了一种计价货币。

人写代码，成本计在"工时"上。 AI 写代码，成本计在"token"上。

而 token 是要花钱的，是按量计费的，是有预算上限的。当写代码的主体从人变成 AI，"Rust 开发慢"这句话并没有失效，它只是换了个说法——

从"Rust 开发慢"，变成了"Rust 开发费 token"。

慢，是人的时间维度上的贵。费 token，是机器的成本维度上的贵。它们是同一笔账的两种货币。

而真正的问题是：换成 token 计价之后，这笔账不但没变小，反而因为 AI 工作流的特殊机制，被放大了。

三、token 账单：Rust 为什么格外贵

3.1 第一层：它天生话多

这是最直观的一层，很多人能想到。

同样一个功能，Rust 写出来的代码，本身就比 Go、Python 长。

类型标注、生命周期参数、trait 实现、错误处理的枚举包装、Cargo.toml 里一长串依赖声明——这些都是实打实的字符，每一个都要变成 token 喂给模型，也要模型一个 token 一个 token 地生成出来。

有个粗略的对照实验（vibe-coding-lang-bench）：让 AI 用不同语言实现完全相同的功能，然后数代码的 token 量。结果是 Rust 的代码量约为 Python 的 1.4–1.5 倍。Go 没进这个实验，但 Go 以语法极简著称，静态代码量通常比 Python 还少，所以 Rust 相对 Go 的"话多"程度，大致也在 1.5 倍上下。

如果故事到这里就结束，那 Rust 不过是"贵 50%"，完全在可接受范围内，根本构不成什么迷思。

但真正的成本大头不在这一层。 静态代码量的差异只是冰山露出水面的那一角。

3.2 被忽略的事实：写代码是最便宜的环节

这里要先纠正一个几乎所有人都会犯的直觉错误。

我们下意识地把 AI 写代码想象成"打印"——输入需求，输出一坨代码，一次成型。 在这个想象里，成本就等于"生成的代码有多长"，也就是上面那 1.5 倍。

但真实的 agent 工作流根本不是打印，而是一个不断循环的调试过程：

写一段代码 → 编译 → 报错 → 读报错 → 改 → 再编译 → 又报错 → 再读 → 再改 → …… → 终于通过 → 跑测试 → 测试挂了 → 回去读代码 → 定位问题 → 改 → 再跑……

在这个循环里，"生成新代码"只占很小一部分动作。绝大多数动作是读和改：读文件、读报错、读测试结果、搜索代码、定位符号、修改某几行、再读一遍确认改对了。

有个工具（RTK）统计过一次典型的 30 分钟 AI 编程会话，把 token 花在哪做了个分解，结论很扎眼：

加起来，"读 + 搜 + 试错"占了整个会话的近七成。

顺带一提，这个事实也解释了为什么"让 AI 直接生成 AST、跳过源代码"这类减少层次的方案，节省的其实是最便宜的那部分——真正贵的是读和改，而读和改无论如何都省不掉。

3.3 第二层：Rust 把试错循环撑大了

回到前面那句话——Rust 是"开发时痛苦"的语言。那个"痛苦"，在人类时代体现为"程序员对着编译器皱眉"，在 AI 时代则原封不动地体现为"agent 在编译修复循环里反复打转"。

具体有两个放大器。

放大器一：编译报错又长又难修，而且会级联。

Go 的编译错误通常是一行：cannot use x (type A) as type B，agent 一眼看懂，改一处，过了。

Rust 的借用检查错误是"多行小说"：

error[E0502]: cannot borrow `self.items` as mutable because it is
              also borrowed as immutable
  --> src/handler.rs:42:9
   |
38 |     let name = &self.items[idx].name;
   |                 ---------------- immutable borrow occurs here
42 |         self.items.push(new_item);
   |         ^^^^^^^^^^^^^^^^^^^^^^^^ mutable borrow occurs here
43 |     }
   |     - immutable borrow might be used here...

十几行起步，还带 help: 建议和 note: 注释。这一整坨，每一次都要被读进上下文、被理解、被据此修改。

更麻烦的是，Rust 的错误会级联。你修好一个 move 错误，可能冒出三个新的 lifetime 错误；你为了让编译器闭嘴加一个 .clone()，又可能触发别处的借用冲突。于是"改一个错、build 一次、又冒出新错"的循环，在 Rust 里能转上十几二十轮，而在 Go 里往往一两轮就收敛。

有个真实项目的记录：一个 Rust 模块的构建，agent 跑了 29 轮编译错误循环，其中约 10 轮是纯粹的所有权/借用/生命周期问题——这类问题在 Go 里根本不存在，对应的 10 轮循环直接就是零。

这里要点出一个常被忽略的不对称：Go 的迭代轮次并不是 1。 Go 也有编译修复循环（declared and not used、类型不匹配），agent 写 Go 一样要迭代。只是 Go 的错误自解释、一轮可修，而 Rust 的错误会级联、不收敛。所以真正的差别不是"Rust 迭代多"，而是"Rust 的迭代不收敛"。

放大器二：改代码这个动作本身，在 Rust 里更容易失败。

agent 改代码常用"精确替换"——找到一段旧文本，换成新文本。Rust 的函数签名长、类型标注多、嵌套深，导致"要匹配的那段旧文本"又长又容易匹配错。一旦替换失败，agent 就得：读回文件拿到精确文本 → 重新构造替换 → 再试。一次失败的修改，等于三次工具调用的成本，却只换来零次进展。

在那个真实项目里，光是这种"改代码失败"就发生了 10 次以上；一个 1656 行的核心文件，就这样被反复地局部读取、又重新读取。

把两个放大器合起来：

Rust 不只是"每次说的话更多"（代码更长），它更致命的是"要说话的轮次更多"（试错循环更长）。

而"轮次更多"这件事，在 AI 的工作流里，代价远比"每次话多"要重。重多少，取决于会话有多长——这是下一章的主题。

四、倍数不是常数：它取决于你把会话开了多久

前面那个"1.5 倍"，很容易被当成一个固定的语言税率记下来。这是个误用。 Rust 相对 Go 的成本倍数，和"你在一个会话里连续干了多少轮"强相关，而且这个相关性比大多数人以为的要剧烈得多。

4.1 为什么倍数会随会话变长而上升

关键在于 AI agent 一个反直觉的工作方式：它没有"记忆"，每一次行动，都要把之前发生的一切重新读一遍。

你让 agent 改第 5 处代码时，它并不是"记得"前 4 处改了什么。它的实际工作方式是：把整个对话历史、所有读过的文件、所有编译报错、所有之前的修改——全部重新塞进上下文，再发给模型，然后模型在这个完整历史的末尾，续写出第 5 步。

于是：

• 第 1 次工具调用，发送 1 份上下文
• 第 2 次，发送 2 份累积的上下文
• 第 N 次，发送 N 次累积的上下文

把这些加起来是 1 + 2 + 3 + …… + N，结果不是 N，而是大约 N²/2。

成本随轮次按平方增长，不是线性增长。 这就是"上下文复利"。

现在看这个平方式对倍数意味着什么。会话总成本可以粗略拆成两块：一块是固定背景（系统提示、项目文档、初始读入的代码），它每轮都重发但不增长；另一块是累积增量（每轮新产生的代码、报错、修改），它随轮次线性堆积，因而总成本按平方增长。

• 会话很短时，固定背景占主导。这时候 Rust 和 Go 的差别，主要就体现在"轮次比"上，倍数接近线性，可能只有 1.5–2 倍。
• 会话很长时，累积增量的平方项彻底压过固定背景。这时候 Rust 的两个膨胀因子（每轮增量更大、总轮次更多）同时生效，倍数逼近它的上限——而"轮次"这个因子是被平方的。

结论：会话越长，Rust 相对 Go 的倍数越高。 短会话里你看到的是 1.5 倍，长会话里看到的是 8 倍，这不是矛盾，是同一个公式在不同区间的表现。

4.2 而现实中的开发习惯，恰恰是把会话开得很长

这里有个很实际的行为因素，它让"长会话"不是极端情况，而是默认情况。

一般人不会为一个小功能开一个新会话。

原因很简单：开新会话意味着要重新交代背景——项目结构、技术约定、之前做过的决策、踩过的坑。这个"重新交代"本身就很贵，而且人会觉得麻烦。所以绝大多数人的真实习惯是：

开一个会话，然后在里面不断追问、不断修复各类问题。从"帮我加个接口"，到"这个测试怎么挂了"，到"顺便把那个模块重构一下"，一路问下去，一个会话用一整天甚至好几天。

这个习惯在人类协作里是完全合理的——你不会每问同事一个问题就重新自我介绍一遍。但放到 AI 的计费机制下，它的后果是：

每一轮追问，都背着前面所有轮次的全部历史。 第 50 轮那句"帮我把这个函数改一下"，和第 1 轮同样的一句话，价格差了几十倍——因为前者要重发前 49 轮积累的所有代码、报错和修改记录。

于是形成一个很反直觉的现象：越往后，越贵，而且贵得越快。 一个会话的前 10 轮可能只花掉总成本的 5%，最后 10 轮却可能花掉 40%。

而 Rust 在这个模式下的处境格外糟：它的轮次本来就多（编译循环、改代码失败），每轮增量本来就大（代码长、报错长），这两个因子在长会话里被平方机制同时放大。你越是习惯"一个会话用到底"，Rust 的相对劣势就越大。

4.3 窗口大小：一个反直觉的影响

很多人以为，模型上下文窗口变大（从 128k 到 1M）会缓解这个问题——"窗口大了，装得下了，就不用反复重读了"。

实际情况恰好相反：窗口越大，复利越凶，Rust 与 Go 的倍数差距越大。

原因在于窗口大小决定了一个关键机制会不会触发——上下文压缩。

• 小窗口（如 128k）：会话跑几十轮就触顶了，系统被迫把前面的历史压缩成一份摘要，腾出空间继续。这个压缩相当于强制给复利踩了刹车——累积的历史被"清零"成摘要，平方项没法一路滚下去。代价是压缩有损，agent 对代码的记忆变模糊，需要重新读代码来补，这是另一笔开销。
• 大窗口（如 1M）：根本不会触顶，不需要压缩。于是复利一路毫无阻拦地滚下去，平方项完全主导，没有任何东西能拦住它。

换句话说，压缩虽然烦人，但它在客观上起到了"封顶"的作用。大窗口把这个封顶拆掉了。

再叠加 4.1 的结论：窗口越大，人们越倾向于把会话开得更长（"反正装得下"），也越倾向于一次性把更多文件读进上下文（固定背景本身也变大了）。这两个行为都让轮次更多、让平方项更主导。

所以在 1M 窗口的超长会话里，Rust 与 Go 的差距可以远远超过 10 倍。 具体能到多少，取决于代码的"借用密度"（见 4.4），而量化的模型放在下一章。

4.4 还有一个变量：代码本身的借用密度

必须说清楚一个边界：倍数高度依赖你在写什么样的 Rust。

• 写纯胶水代码、CRUD、HTTP 接口——借用检查器基本不添乱，轮次和 Go 差不多，倍数可能只有 2 倍出头。
• 写异步、并发、自引用数据结构——借用检查器全力开火，轮次暴涨，倍数轻松上到 10 倍以上。

这里有个相当讽刺的结论：Rust 越是用在它最擅长、最不可替代的地方（复杂系统编程），它的 token 税就越重。 它的优势场景，恰恰是它 AI 成本最高的场景。

五、深入分析：上下文复利的量化模型

这一章是前面结论的推导过程，自成一体。只想要结论的读者可以跳过它，直接看后面的迷思破解。

5.1 平方的来源

设一个会话里 agent 执行了 M 次工具调用，每次调用平均给上下文增加 δ 的增量，会话开始时的固定背景（系统提示、项目文档、初始代码）为 C₀。

由于每次调用都要重发全部累积历史，总输入成本是：

总成本 ≈ Σ(i=1..M) (C₀ + i·δ)  ≈  M·C₀ + δ·M²/2

主导项是 δ·M²/2。这就是"成本按轮次平方增长"的准确形式。

5.2 两个膨胀因子，一个进线性，一个进平方

Rust 相比 Go，同时膨胀了两个变量：

代入求和式，得到成本比：

成本比 ≈ k_δ × k_M²

• k_δ = 1.5、k_M = 1.5 → 1.5 × 2.25 ≈ 3.4 倍
• k_δ = 2、k_M = 2 → 2 × 4 = 8 倍
• k_δ = 2、k_M = 2.5 → 2 × 6.25 = 12.5 倍
• k_δ = 2、k_M = 3 → 2 × 9 = 18 倍

注意那个平方。 轮次多一倍，成本不是多一倍，是多到四倍。这就是为什么"Rust 试错循环长"的杀伤力远超"Rust 代码长"——前者被平方放大，后者只被线性放大。

这也点破了一个常见的算账错误：如果把各个成本因子简单相乘（静态代码量 × 编译迭代 × 上下文读取 × 重试），会重复计算 δ 类因子——"静态代码量"和"上下文读取"其实是同一根轴（都是单次调用的增量），不该相乘。正确的分解只有两根轴：δ 进线性，M 进平方。

5.3 倍数如何随会话长度变化

把 5.1 的公式写成比值形式：

成本比 = (M_R·C₀ + δ_R·M_R²/2) / (M_G·C₀ + δ_G·M_G²/2)

这个比值随 M 单调上升，两端有明确的渐近行为：

• M 很小（短会话）：C₀ 项主导，比值 ≈ M_R/M_G = k_M（退化为线性）
• M 很大（长会话）：δM²/2 项主导，比值 → k_δ × k_M²（平方上限）

以 k_δ = 2、k_M = 2.5 为例：短会话里你只会看到约 2.5 倍的差距，超长会话里会逼近 12.5 倍。同一个语言组合，同一个公式，倍数差 5 倍，唯一的变量是会话长度。

这正好对应 4.3 的结论：小窗口通过频繁压缩把 M 压在低位，比值停留在靠近 k_M 的区间；大窗口允许 M 一路增长，比值被推到 k_δ·k_M² 的上限。

5.4 隐藏账一：会话压缩的再获取成本

上下文窗口有上限。长项目跑着跑着历史塞满窗口，系统会把前面的对话压缩成摘要。

Rust 的 δ 膨胀 1.5–2 倍，意味着同样的工作量，Rust 会更早塞满窗口、更频繁地触发压缩。而每次压缩之后，agent 对代码的"记忆"变模糊，它得重新读代码、重新建立理解——这笔"再获取成本"和当初做调研一样贵，而且它重新读的还是那些被膨胀过的、更长的 Rust 代码。

这是第二重复利：不仅单个会话内成本按平方涨，跨会话的"重新理解"成本也在涨。它不在 5.2 的公式里，是额外乘上去的。对跨越多个会话的长项目，这一层能把 8 倍推到 10–12 倍。

5.5 隐藏账二：缓存压低绝对价格，但压不平比例

有人会问：现在都有 prompt 缓存了，重发的历史按大约一折计费，复利不就被化解了吗？

算一下会发现没有。缓存后的成本分两块：

• 缓存命中的历史部分：约 0.1 × δM²/2，比值仍是 k_δ·k_M²（0.1 是公因子，约掉了）
• 全价的新增部分：每轮新增 δ 按 1.0 计，即 Mδ，比值是 k_δ·k_M（线性）

两项谁主导？比较 0.05M² 与 M，临界点在 M ≈ 20。会话超过 20 次工具调用，缓存后的平方项依然主导，比值仍 ≈ k_δ·k_M²。

打个比方：你和邻居都办了同一张打折卡，你买 8 件、他买 1 件，打完折账单比例还是 8:1。

结论：缓存把绝对成本压低约 10 倍（这是好事），但几乎不改变 Rust 与 Go 的相对比例。 别指望缓存能救复利。

而且缓存还有个反作用：Rust 的"改代码失败"会更频繁地击穿缓存（每次失败修改都让缓存失效、需要按更高价重新写入），这反而给 Rust 额外加了一笔小税。

5.6 汇总：倍数区间

所以"10 倍"这个数是真实存在的，但它是尾部值，不是平均值。 把它当成 Rust 的默认税率会高估大多数场景；但反过来，拿"1.5 倍"（只算静态代码量）当默认值，又会严重低估真实的 agent 工作流。

诚实的中心答案是 3–8 倍，并且这个倍数会随着会话变长、窗口变大而继续上升。

5.7 一个必要的诚实声明

这套 k_δ·k_M² 模型加上单个项目的实证（29 轮编译循环、10+ 次改代码失败、1656 行的核心文件被反复局部读取）是有说服力的推理，但不是 benchmark。

前面提到的 vibe-coding-lang-bench 明确承认它没测到迭代成本——实验里的 agent 拥有完美上下文、零编译错误。也就是说，公开数据里恰恰缺的就是这个平方项。

要真正坐实这些倍数，需要有人拿同一个任务、同一个 agent，分别用 Rust 和 Go 跑一遍，测累积输入 token。目前还没人做过这么一份干净的测量。所以这些数字的正确定位是：方向确定、量级可信、精确值待测。

六、迷思破解：AI 没有让 Rust 占优势，它只是把成本换了个地方藏起来

现在可以正面回答开头那个推理了。

迷思： "AI 抹平了 Rust 开发慢的劣势，所以 AI 时代 Rust 大占优势。"

真相： AI 抹平的是"人的认知负担"，但没有抹平"开发成本"本身。开发成本从"人的工时"转移到了"机器的 token"，并且在转移过程中被上下文复利放大了 3–8 倍，在长会话、大窗口、借用密集的情形下可以到 10 倍以上。

Rust 那套"开发时痛苦"的特性——和借用检查器搏斗、冗长的报错、反复的编译修复——一点都没有消失。它只是从"程序员皱眉"变成了"agent 空转烧 token"。痛苦是守恒的，它换了个承受者，还顺便涨了价。

更深一层：Rust 的传统账本是"一次性开发投入，换长期运行省心"。 这笔账在人类时代划算，是因为开发投入是一次性的、封顶的。但在 AI 时代，开发投入变成了按 token 持续计费、且随会话长度平方增长的东西——它不再是一次性封顶的成本，而是一个会复利膨胀的成本。Rust 用来交换"运行省心"的那个筹码，本身变贵了，而且贵得不成比例。

所以正确的结论不是"AI 时代别用 Rust"，而是：

Rust 在 AI 时代的性价比，取决于你的"运行期安心"值不值那个被平方放大的"开发期 token"。

• 如果是操作系统、数据库、安全关键内核——运行期出一次事就是灾难，那几倍的 token 税完全值得付，Rust 仍不可替代。
• 如果是业务服务、API 网关、CRUD、快速迭代的 AI 应用——运行期没那么娇贵，而你需要频繁让 AI 改动、快速试错，那这笔平方税就付得冤枉。Go 这类"低熵、快编译、一轮收敛"的语言，综合成本要低得多。

七、如果还是要用 Rust：对抗复利的工程纪律

既然成本的平方项来自"轮次"，那么减少轮次，比减少单次输出量值钱得多——因为你压的是一个会被平方的量。

1. 批量修复，别一个一个来。 一次编译报 5 个错，就 5 个一起修完再 build，而不是修一个 build 一次。每省一轮，就省一次"全量上下文重发"。
2. 改大函数时，宁可整个文件重写，也别做精确替换。 精确替换一旦失败就是 3 倍成本（失败输出 + 读回 + 重试），整文件重写反而是一次调用、零失败率。
3. 别写一次性脚本。 用完即删的临时脚本是"全价买入、零残值"，是 token 效率最差的形态。一开始就写可复用的脚手架。
4. 把知识固化到磁盘。 调研结论写进文档、正确行为钉进测试。下个会话读一遍文档就拿到全部结论，跑一遍测试就完成验证，不用重新推导。这是对抗"跨会话再获取复利"的唯一正解。
5. 主动切会话，别一个会话用到底。 既然倍数随会话长度上升，那么在一个自然的工作节点（一个模块完成、测试通过）主动开新会话、把背景写成文档带过去，比在旧会话里继续追问要便宜。这违反直觉——开新会话要重述背景，看起来更贵——但重述背景是一次性的 C₀，而继续留在旧会话是在喂一个平方项。

还有一层值得点破：这个平方律对 Go 和 Rust 都成立，只是 Rust 的轮次基数更大，所以被平方放大得更狠。 换句话说，"对抗复利"的工程纪律在 Rust 项目上的边际收益远高于 Go——因为你在压一个会被平方的量。

这也反向说明了 Go 的真正优势：它不只是"每轮增量小"，而是"它让你不需要那么努力对抗轮次的平方"。 语言选型的本质，在这里变成了选一个轮次天然收敛、不需要靠工程纪律去硬压的底座。

结语：看清这笔账，不是为了否定 Rust

Rust 是一门伟大的语言，这一点 AI 时代没有改变，也不会改变。

改变的只是我们评估它的坐标系。过去我们问："人写它累不累？"——AI 回答了这个问题：人不写了，所以不累。于是很多人就此打住，得出"Rust 大占优势"的结论。

但真正该问的是下一个问题："机器写它、读它、改它、反复调试它，贵不贵？"

答案是：贵，而且因为上下文复利，贵得比直觉多得多——不是线性地贵，是平方地贵。而且会话开得越久、模型窗口越大，这个平方就越没有约束。

AI 没有消灭 Rust 的开发成本，它只是把这笔成本从"人看得见的工时"，搬到了"人容易忽略的 token 账单"里。而恰恰因为它被搬到了看不见的地方，才更容易被"Rust 大占优势"这种迷思所掩盖。

看清这笔账，不是为了否定 Rust，而是为了在该用它的地方毫不犹豫地用，在不该用它的地方——别为一个被平方放大的幻觉买单。