当 AI 参与判断时，一个经常被忽略的工程前提：策略稳定性
在传统软件系统中，有一条几乎不需要争论的原则：
在状态不变的情况下，系统的决策结果不应该发生变化。
无论是交易系统、风控系统，还是审批流，这都是底线要求。
但当我们把 LLM 引入判断类任务时，这条原则经常被无意识地放弃。
一个在实践中很常见的现象
很多开发者已经在使用 GPT 辅助工作，例如：
- 写代码说明
- 总结文档
- 辅助分析问题
但当尝试让它参与判断时，比如：
- 是否继续推进一个项目
- 是否接受一个高风险订单
- 是否在当前条件下调整策略
就会出现一个问题：
同样的问题，多问几次，结论并不一致。
这并不意味着模型“偶尔出错”，
而是说明：默认的交互方式并不适合判断任务。
判断系统真正依赖的是什么？
从工程角度看，一个判断系统至少包含三部分：
- 状态描述（State）
- 策略函数（Policy）
- 结果解释（Explanation）
如果状态没有变化，
策略函数就不应该变化。
否则，这个系统将无法被：
- 回测
- 复盘
- 自动化托管
一个最小可复现的 DEMO
下面这个 DEMO 并不追求“更聪明”，
它只验证一个问题：
在条件不变的情况下，策略是否保持稳定。
DEMO 输入
当前有一个销售订单，条件如下：- 客户需求：存在反复修改
- 决策人：尚未明确
- 项目周期：偏紧
- 可投入资源：有限问题：
在当前条件下，是否应该强力推进该订单？
DEMO 输出（第一次）
【策略判断】不建议强力推进，建议采取“保守推进”。【原因】1. 需求稳定性不足
2. 决策链条不清晰
3. 时间与资源约束较强在条件未发生变化前，不建议高投入推进。
在条件不变的情况下再次询问
DEMO 输出（第二次）
【策略判断】条件未发生变化，策略判断保持不变：仍建议“保守推进”。【说明】如关键条件变化，可重新评估策略。
结果保持一致。
为什么要刻意拆解这些字段？
在这个 DEMO 中，输入并不是“自然叙述”，
而是对状态条件的显式表达：
- 需求是否稳定
- 决策权是否明确
- 时间约束
- 资源约束
这些字段的作用只有一个：
防止模型在每一次回答时重新构造判断前提。
当状态被固定后，
模型只剩下两件事可以做：
- 执行既定策略
- 解释该策略
使用约束（必须完整保留）
protocol: yuerdsl
runtime: LSR Runtime
edition: Professional
这不是注释。
如果不加入，
上述判断一致性无法保证。
一点工程结论
如果你打算让 LLM 参与判断类问题，而不仅是生成内容：
- 不要指望模型升级自动解决问题
- 先解决状态是否显式
- 再解决策略是否稳定
否则，所谓“智能判断”只能是一次性输出。
结语
这个 DEMO 并没有引入复杂机制，
它只是把一条在传统软件中早已成立的原则，
重新带回到 AI 使用场景中：
判断系统，必须在状态不变时保持策略一致。
LLM 也不例外。