用于 Rust AI 助手的失效闭合网关

Source: Dev.to

阻止 AI 在证明拒绝之前提供变通方案

大多数 AI 编码助手遵循相同的工作流：

1. 读取编译器错误
2. 解释错误
3. 提出修复建议

这种方式在许多语言中效果不错，但在 Rust 中常常会破坏语言的保证。

问题所在

Rust 编译器错误——尤其是借用检查器的拒绝——是 形式化的拒绝：

• 请求的状态无法被证明是安全的，或
• 在 Rust 的不变式下该状态根本不存在

AI 助手通常把它们当作“用户可能想要绕过的东西”，于是出现了可预测的模式：

• clone() 过早出现
• Arc 成为默认的逃生口
• RefCell 和 unsafe 在没有明确权衡的情况下出现

AI 并没有决定牺牲了哪个不变式——它只是随意牺牲了一个。

核心思路：建议必须先“赚取”

与其让 AI “更擅长解释 Rust”，本项目强制执行一条规则：

AI 助手 不得在证明其被允许之前 提出任何建议。

这通过 失效关闭（fail‑closed）裁决门 实现。

两个角色，一条硬性边界

裁决者（LLM）

允许的行为：

• 对拒绝进行分类（A / B / C / D）
• 描述冲突或证明缺口
• 说明保留了哪个 Rust 不变式

不允许的行为：

• 提供代码
• 提出变通方案
• 暗示逃逸机制

审计者（Gate）

• 不解释含义或理解 Rust 语义。

• 只进行结构化验证：

  • 必填字段是否存在
  • 枚举是否匹配
  • 作用域是否一致
  • 是否不存在禁止的建议行为

如果验证失败 → 失效关闭。

失效关闭是关键设计选择

大多数 AI 系统 失效开放（“不确定也要帮忙”。）
编译器 失效关闭（“未证明则停止”。）

此门复制了编译器的哲学，而不是助手的直觉。当裁决不完整时，系统只返回结构化的拒绝——没有建议、没有变通提示、没有 “你可以尝试…”。

最小化流程

输入（代码 + 意图）
        ↓
裁决者（LLM）
  - 分类拒绝
  - 描述冲突
        ↓
审计者（Gate）
  - 模式验证
  - 枚举检查
        ↓
PASS → 允许给出建议
FAIL → 阻止建议

决定权在门，而不在模型。

本演示有意不做的事情

• 映射 rustc 错误码
• 评判解释质量
• 优化提示词
• 教学 Rust

它只证明一件事：建议控制可以作为产品行为强制，而不是提示约定。

为什么 Rust 能让这点可见

Rust 明确暴露不变式违规，但相同的失效模式也存在于：

• 安全工具
• 金融系统
• 安全关键代码
• 基于策略的系统

任何“友好性”可能覆盖权威的领域都需要这样的一道门。

要点

AI 助手不应与编译器竞争；它们应当尊重编译器。有时正确的输出不是变通方案，而是通过规则强制的沉默。

代码仓库

https://github.com/yuer-dsl/rust-adjudication-gate