最近一年，Rust + AI 成了一个很微妙的组合。
一边是 Rust 越来越火，
一边是 Copilot / ChatGPT/gemini/豆包 几乎人手一个。
很多人已经形成固定流程：
编译报错 → 把错误丢给 AI → 复制建议 → 再编译
直到某一天，你发现代码虽然能跑了，但你已经不太敢动它了。
一、Rust 报错，真的“该被立刻修掉”吗？
在 JavaScript / Python 里，报错通常意味着：
- API 用错
- 参数不对
- 拼写问题
但在 Rust 里，很多错误是这种：
- borrow checker 不通过
- 生命周期无法证明
- Send / Sync 约束失败
- 不变量在当前结构下互相冲突
这种错误本质上不是“写错了”，而是：
你当前的设计，在 Rust 的规则下不成立。
这是一次裁决，不是一次“待优化”。
二、AI 在 Rust 场景下的“惯性行为”
如果你经常用 AI 修 Rust，大概率见过这些套路：
- “这里可以
clone()一下” - “包一层
Arc<Mutex<T>>” - “用
unsafe绕过去”
问题是：
AI 不知道你想保护什么。
它的目标只有一个：
让代码通过编译。
而 Rust 的目标是：
拒绝破坏不变量的代码存在。
这两者，天生冲突。
三、真正的问题：建议权是不是给早了？
于是我开始反思一个问题：
AI 给“建议”这件事，是否应该默认发生？
在 Rust 场景下，答案越来越清晰：
- 在“裁决未完成”前，建议是有害的
- 尤其是 workaround / 模式迁移 / unsafe 引导
因为这些建议，本质是在替 Rust 下判决。
四、一个很克制的小工具思路：先关门，再说话
基于这个判断，我做了一个极小的工程实验：
Rust Adjudication Gate
它不做这些事：
- ❌ 不教 Rust
- ❌ 不生成代码
- ❌ 不帮你“想办法通过编译”
它只做一件事：
在 Rust 的拒绝尚未被明确裁决之前，阻止一切建议输出。
一句话原则：
Before adjudication, no suggestion.
五、这对日常开发有什么用？
这个 Gate 带来的变化很直观：
- 你会被迫先回答：
“这里到底冲突的是什么不变量？” - 你会更早意识到：
“是不是设计本身该改，而不是补丁。” - AI 不再“抢着表现”，而是被限制在裁决完成之后。
这不是反 AI，而是给 AI 定职责边界。
六、为什么这比“更聪明的提示词”重要？
很多人第一反应是：
“那我写个更严格的 prompt 不就好了？”
问题在于：
- Prompt 是软约束
- 工程 Gate 是硬约束
Rust 的安全来自硬拒绝，
那配套工具也必须有“敢闭嘴”的能力。
七、写在最后
Rust 的价值，不在于它能让你写出多炫的代码，
而在于它不允许你在关键问题上糊过去。
如果 AI 工具无法尊重这种“不允许”，
那它越聪明，风险反而越大。
有时候，最好的辅助不是告诉你怎么做，
而是明确地说一句：
这里，不该继续。
项目地址（最小概念验证）
Rust Adjudication Gate
👉 github.com/yuer-dsl/ru…
