用 AI 写 Rust 真的能让那些害怕借用检查器的人入坑吗

很多人说 Rust 学习曲线陡峭，尤其是那个让人头大的 Borrow Checker，但实际上在公司内部推行 Rust 的时候，AI 扮演的角色比想象中大得多。以前新同事上手 Rust，最崩溃的阶段就是跟编译器死磕，一个简单的变量所有权问题能卡住半天，这种挫败感直接导致很多人在尝试阶段就放弃了。但现在配合 Claude 3.5 或者 GPT-4o，这种“编译器折磨”被极大地稀释了。

我观察到团队里几个从 Go 和 Java 转过来的开发，他们现在的模式是：先写一个大致的逻辑，被编译器报一堆 Error 之后，直接把报错信息和代码丢给 AI。AI 不仅能快速给出修复方案，最关键的是它能用人话解释为什么这里需要 &mut 而不是 &，或者为什么这里得用 Arc<Mutex<T>>。这种实时的、针对具体代码的“一对一辅导”，实际上把 Rust 的入门门槛给拉低了。

当然，AI 带来的加速也是双刃剑，容易产生一种“我懂了”的错觉。有些同事直接复制 AI 给的 unwrap() 方案，虽然代码跑通了，但完全丧失了 Rust 追求的内存安全和鲁棒性。在实际落地中，我们发现最有效的实操方式是要求开发在提交 PR 时，必须在注释里写清楚 AI 修改该内存所有权逻辑的底层原因，否则不予通过。

从工程效率来看，AI 确实缩短了从零到能写出可运行 Rust 代码的周期。以前一个功能模块的迁移可能需要两周的摸索期，现在一周就能出 Demo。但要真正达到进阶水平，依然得去啃那本《The Rust Programming Language》，AI 只能帮你跨过门槛，不能替你思考内存布局。