这两年，AI 越来越多地出现在系统的“决策链路”中。
不论是运维调度、风控判断，还是资源分配、策略选择，
我们都在尝试把一部分判断交给模型。
但在一次又一次的系统设计讨论中，我发现一个问题经常被忽略：
当 AI 开始参与决策时，这个系统还能不能“停下来”？
一、工程系统中，“停下来”从来不是次要能力
在传统工程系统中，我们非常清楚：
任何自动化系统，都必须有停止条件
任何闭环，都必须能被外部打断
任何策略执行，都必须能被否决
这是工程安全的基本常识。
但当 AI 被引入后，这些常识往往被性能、效率、智能光环掩盖了。
二、AI 决策链路中的一个危险变化
在很多 AI 系统中，决策链路逐渐变成这样：
状态感知
→ 模型推理
→ 决策建议
→ 执行
表面上，人类仍然“在环”。
但实际上：
系统默认执行模型结论
人类更多是在“追认”结果
拒绝反而需要额外成本
当“不执行”变成异常路径时，
系统就已经失去了真正的控制能力。
三、Human-in-the-loop 并不等于“可以否决”
很多系统强调 Human-in-the-loop。
但在实际工程中，这往往意味着：
人类只负责确认
否决需要解释
否决会被视为低效
这并不是否决机制，而只是一个流程节点。
真正的否决，必须满足一个条件：
它可以在不解释理由的情况下直接生效。
四、为什么 AI 越稳定，系统反而越脆弱
这是一个反直觉但真实的现象：
模型越稳定 → 越少被质疑
系统越顺畅 → 人类越退出
决策越成功 → 否决越不被使用
久而久之，“停机能力”在系统中退化了。
等到真正需要停的时候，
你会发现系统已经没有“停”的设计。
五、从系统设计角度重新理解“可控 AI”
所谓可控 AI，并不是限制 AI 能力，
而是重新划清边界：
AI 负责分析和解释
决策执行前，必须经过一个独立的否决层
这个否决层不依赖 AI 自己的判断
这是一个系统架构选择，而不是模型问题。
结语
在引入 AI 决策之前，
工程师真正需要回答的问题，不是：
“模型够不够聪明？”
而是：
“当我想按下停止键时，这个系统真的会停吗？”
相关的工程案例与可控 AI 判例，
已整理为公开仓库：
https://github.com/yuer-dsl/controllable-ai-casebook