Rust + LLM 的一个危险误区：把编译拒绝当成“建议生成入口”

在越来越多的开发场景中，大模型已经成为程序员的“第二输入法”。
尤其是在 Rust 这种规则密集型语言中，LLM 被大量用于解释编译错误、给出修复建议。

但这里存在一个被系统性忽略的工程风险：

Rust 的编译拒绝，不应该被自动转译为“改写建议”。

这不是体验问题，而是语义边界问题。

一、Rust 编译错误的真实角色

在很多语言中，编译错误是：

• 语法提示

• 类型不匹配提示

• 教学性反馈

但在 Rust 中，大量错误并不属于这一类。

例如：

• borrow checker 拒绝

• 生命周期不可证明

• Send / Sync 能力不成立

• 不满足并发或别名不变量

这些错误的本质是：

当前程序状态，在 Rust 的语义模型中不被允许存在。

这是裁决（adjudication），不是建议请求。

二、LLM 在 Rust 上的典型失败模式

当前主流 LLM 在处理 Rust 错误时，普遍存在一个倾向：

试图“帮助用户绕过拒绝”，而不是尊重拒绝本身。

常见表现包括：

• 将 borrow checker 拒绝解释为“写法问题”

• 给出 Arc<Mutex<T>> / RefCell<T> 作为默认修复

• 在语义尚未成立时，引导使用 unsafe

从用户视角看，这是“友好”；
从工程视角看，这是裁决语义被污染。

三、为什么这是工程风险，而不是使用习惯问题

关键问题不在于“建议是否能通过编译”。

而在于：

LLM 把 NO（非法状态）转译成了 MAYBE（工程权衡）。

这会带来三类长期后果假象：

1. 抽象被延迟重建
   用户不再回到所有权模型本身，而是快速引入逃逸容器。

2. 错误被“合理化”
   原本应当被重新建模的问题，被视为“Rust 太严格”。

3. unsafe 使用被正常化
   从“语义边界工具”变成“解决问题的选项”。

这不是 Rust 的设计初衷。

四、设计原则：把“放行权”从模型手中剥离

基于上述问题，我构建了一个极小的工程实验：
Rust Adjudication Gate

它不是 Rust 助手，不是 Copilot，也不生成代码。

它只做一件事：

在裁决完成之前，禁止任何建议输出。

核心原则只有一句：

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

五、最小可审计的 Gate 逻辑

系统并不理解 Rust 全语义，只做结构裁决：

• A / B / C 类拒绝

  • 表示状态非法 / 不变量冲突 / 能力不成立

  • ❌ 禁止任何 workaround、模式或代码建议

• D 类拒绝

  • 表示实现不完整、信息缺失

  • ✅ 允许补充性建议

一旦裁决不完整、矛盾或被污染：

• 直接 Fail-Close

• 清空建议输出

• 只返回结构化拒绝原因

这是一种编译器式防御设计。

六、为什么这是“反直觉但正确”的 AI 设计

当前很多 AI 工具的目标是：

“更聪明地回答”

但在 Rust 场景下，更重要的是：

“更严格地拒绝”

当模型被允许在任何情况下给建议，它就不可避免地会：

• 弱化语言的约束信号

• 把规范问题变成经验问题

• 把宪法级规则降级为“最佳实践”

而 Rust 的价值，恰恰建立在不可协商性之上。

七、结语

Rust 的编译错误不是对话邀请，而是边界声明。

如果 AI 工具无法区分这两者，那么它带来的并不是生产力提升，而是长期工程质量的侵蚀。

不是所有错误都应该被“解决”，
有些错误存在的意义，就是阻止你继续错下去。

相关仓库（概念性最小实现）

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