建模与求解的完整流程

快速开始提供可执行入口。本章解释一次求解中的对象、依赖与结果流，不要求先把小模型拆成多个业务上下文。

1. 从输入到业务方案

一次求解包含输入冻结、数据检查、表达式构建、模型组装、后端执行和结果映射。模型构建完成不代表已求解，求解调用返回也不代表已经有可读取的可行方案。

阶段	输入	输出
输入准备	业务记录、场景参数	本次运行使用的确定数据
表达构建	数据、业务索引	变量和中间值
模型组装	表达、规则和目标	具有完整变量域和约束的模型
转换与执行	模型、后端能力和配置	求解状态、解、界及诊断信息
结果映射	已确认的解、业务索引	业务方案和指标

2. 例子：两种产品共享工时

概述、概念与集合

生产上下文分配一个班次的工时。产品集合 $I=\{A,B\}$，工时预算为 $H=8$ 小时。单位工时 $a_A=2,a_B=3$ 小时/件，单位收益 $r_A=3,r_B=4$ 元/件。这里不考虑需求上限、库存或跨期转移。

变量

$x_i\in {\mathbb{Z}}_{\ge 0}$ 是产品 $i$ 的产量，单位件，$\mathrm{\forall }i\in I$。由工时得到有效上界 $x_A\le 4,x_B\le 2$。不需要辅助变量或额外筛选谓词。

中间值

已用工时 $U$ 和总收益 $R$ 各自表达一个业务指标：

$$U=2x_A+3x_B,R=3x_A+4x_B.$$

断言、约束与目标

单位工时为正、预算非负是数据断言。资源约束与收益目标为：

$$\text{s.t.}U\le 8,maxR.$$

枚举 $x_B=0,1,2$，相应最佳 $x_A=4,2,1$，收益为 12、10、11，因此 $(4,0)$ 是最优方案。

3. 先建身份，再建依赖

先建立稳定产品索引与变量，再定义 $U,R$，最后建立引用它们的约束和目标。表达式存在于宿主程序中，不意味着它引用的变量已加入待求解模型；模型组装必须确保依赖完整。

业务标识如“产品 A”与后端列号不同。结果映射应保留本次运行的变量到业务实体关系，而不是假定第一个数永远属于 A。集合排序变化时尤其如此。

中间值可以被多条约束和多个报告指标复用；模型也不能仅靠名字相同就认定两个符号是同一个对象。关于注册与转换的职责，见类编译器架构。

4. 输入断言与求解约束

如果 $a_A$ 缺失，不能默认成零再求解；这属于输入不完整。如果 $H=0$，本例允许零产量，是合法业务实例。如果业务还要求至少生产一件，而 $H=0$，则得到真实不可行模型。

这种区分决定错误应该在输入准备、建模还是求解结果中报告。数据断言检查已知事实，求解约束限制未知决策，两者不能互相替代。

5. 配置、执行与结果读取

选择能处理整数线性模型的后端，设置本次运行的时间限制和结果需求。不要把表达式可构造等同于任意后端都能处理，也不要把后端配置直接混进业务约束定义。

执行返回后先读取状态，确认是否存在可行解，再映射 $x_A,x_B$，由同一份参数计算 $U,R$。无可行解时，不能把空结果或默认零值转换成“生产零件”的业务方案。

业务报告同时保留状态和指标。例如“收益 11，存在可行解，尚未证明最优”与“最优收益 11”不是同一句话。详细解释见理解求解结果。

6. 生命周期与复用

复用的是规则定义和组件，而不是不加区分地复用上一轮变量实例。新场景应建立自己的输入与绑定；warm start 是向后端提供候选解信息，不是跳过新模型可行性判断。

模型规模扩大后，可以把工时指标交给资源上下文、收益交给经营上下文，由应用组装。阅读DDD 架构了解职责拆分；阅读滚动优化了解业务数据变化后的更新。