在很多 AI 项目中，“决策”这个词被使用得越来越随意：
选股决策、调度决策、审批决策、策略决策……
但如果从工程角度审视，一个非常基础的问题长期被忽略了：
同一份输入，在不同时间、不同会话中多次执行，结果是否一致？
如果答案是否定的，那么这个系统在工程意义上，并不具备决策资格。
一、这是一个系统工程问题，不是模型能力问题
在实践中，这类不一致通常会被解释为：
- 模型有随机性
- 推理路径不同
- 上下文略有差异
- 市场本身不确定
但这些解释，本质上都是在回避系统责任边界。
在工程语境中，所谓“决策”至少意味着：
- 可复现（replayable）
- 可审计（auditable）
- 可归责（accountable）
如果同一输入多次运行结果不同，这三点同时失效。
二、建议系统可以不确定，决策系统不可以
这里有一个经常被混淆的概念：
- 建议系统：
给出参考意见，允许不稳定性 - 决策系统：
输出结果直接进入执行链路，不允许摇摆
工程上，两者的界线非常清楚：
建议可以“差不多”，决策必须“一模一样”。
一旦系统参与真实执行流程（交易、审批、调度），
非确定性就不再是“模型特性”，而是系统缺陷。
三、如何在工程上判定“这个问题是否被解决”？
这个问题并不需要复杂指标，可以给出一个严格而清晰的判定条件：
在结构化、规范化后的相同输入下，系统在任意重复执行中，必须给出完全一致的输出结果。
这里的“一致”不仅包括集合一致，还包括：
- 排序一致
- 阈值判断一致
- 拒绝条件一致（例如是否 NO-GO）
如果做不到这一点，系统只能被定义为“辅助建议系统”。
四、这个问题是否真的能解决？
答案是：能，而且必须能。
但要明确的是：
- 不是靠更大的模型
- 不是靠更复杂的推理
- 也不是靠多次采样取平均
真正可行的工程路径只有一条：
将“裁决”本身形式化，并严格限制模型在裁决阶段的行为边界。
当裁决流程被完全形式化后：
- 模型只参与语义编译
- 裁决逻辑由确定性规则完成
- 非确定性不会进入最终输出
结果自然唯一。
五、为什么这个问题长期没有被正面解决？
原因并不在技术，而在目标函数。
大多数系统追求的是：
- 表现更好
- 看起来更智能
- 用户体验更顺滑
而不是：
- 是否可担责
- 是否可回放
- 是否可审计
一旦把“责任”作为前置条件，
大量看似合理的 AI 行为都会被工程上直接禁止。
六、结语
决策系统与建议系统之间，没有中间态。
判断标准只有一个：
同一份输入，是否在任何时候都产生同一个结果。
在满足这一条件之前，
任何系统都不应被称为“决策系统”。
写在最后
这不是对 AI 的否定，
而是对系统工程边界的重新确认。
真正的智能系统，
首先要做到的是：
不摇摆。
