Rust 编译错误，到底该不该被“自动修复”？

最近一年，越来越多的人开始用 LLM 来“辅助写 Rust”。

常见使用方式很简单：
编译报错 → 把错误贴给模型 → 让它给修改建议。

一开始看起来很顺畅，但在真实工程里跑一段时间后，你会发现一个不太对劲的现象：

很多 Rust 错误，一旦被“自动修复”，反而更难维护了。

一、Rust 的编译错误，和其他语言不一样

在不少语言中，编译错误通常意味着：

少写了一个参数

类型不匹配

API 用错

这些错误的修复，本质是局部调整。

但 Rust 里有一大类错误，性质完全不同，比如：

借用规则不成立

生命周期关系无法证明

Send / Sync 能力缺失

不变量在当前结构下无法同时满足

这类错误并不是“写错了”，而是：

当前程序结构，在 Rust 的模型里不被允许存在。

这是一次裁决，不是一个“待优化点”。

二、LLM 在 Rust 错误上的典型行为

如果你经常用模型处理 Rust 报错，大概率见过这些建议：

“用 Arc<Mutex> 包一下”

“加一层 clone()”

“这里可以用 unsafe 绕过去”

这些建议很多时候能编译通过，但问题在于：

编译通过 ≠ 语义成立。

模型并不知道你原本想维护的不变量是什么，它只是在把“拒绝”变成“可行路径”。

三、这不是“模型不够聪明”，而是职责错位

需要明确一点：

LLM 的强项是 生成与重组，
而 Rust 的安全性来自 拒绝与不可协商。

当你让模型“尽量帮我想办法通过编译”，你实际上是在要求它：

替 Rust 做裁决。

但 Rust 的裁决是基于一整套语义模型，而不是“经验写法”。

四、一个工程化的反问：建议权该不该自动放行？

于是我给自己提了一个问题：

在 Rust 场景下，
“给建议”这件事，是否应该默认被允许？

答案很快变得清晰：

在裁决未完成前，任何建议都是危险的

特别是 workaround、模式迁移、unsafe 引导

这不是“谨慎”，而是职责隔离。

五、最小化的工程实验：Adjudication Gate

基于这个判断，我做了一个非常克制的小实验：

Rust Adjudication Gate

它不做这些事：

❌ 不生成代码

❌ 不解释 Rust 教学

❌ 不替代 Copilot

它只做一件事：

在裁决不完整或不明确时，阻止任何建议输出。

核心规则只有一句：

Before a Rust rejection is fully adjudicated, no suggestions are allowed.

六、裁决优先，而不是“体验优先”

这个 Gate 的存在，本质上是在强调一件事：

有些 Rust 错误，就应该停下来

而不是马上“想办法绕过去”

如果工具在每次拒绝后都急于给出替代路径，那么：

所有权模型会被逐步架空

unsafe 的心理门槛会被不断降低

Rust 的“约束感”会变成“建议感”

这对小 demo 可能没问题，对长期维护的工程却是灾难。

七、写在最后

Rust 的难，不在于语法，而在于它不允许你含糊其辞。

如果 AI 工具无法尊重这种“不允许”，
那么它越聪明，反而越危险。

有时候，一个合格的工具，不是告诉你怎么做，
而是明确地告诉你：

这里，不能继续了。

项目地址（最小概念实现）

Rust Adjudication Gate
👉 https://github.com/yuer-dsl/rust-adjudication-gate