1. 课程导入与冲突认知
在运筹优化与数学规划的实际应用中，建模者最常遇到的困境往往不是“模型算不出来”，而是“模型算出来的结果不可用”——求解器返回 infeasible（不可行），或者虽然可行却与业务现实严重背离。这类问题的根源，绝大多数指向同一个对象：约束冲突。本章作为全课程的导入，先建立对约束冲突的准确定义与分类认知，再给出诊断与修复的整体流程框架，最后说明学习路径与实战项目的组织方式。
一、什么是约束冲突
约束冲突，指优化模型中若干约束条件在可行域上无法同时满足，导致可行域为空集（∅）的情形。用标准形式描述：给定决策变量向量 x，约束集合 S = {g_i(x) ≤ 0, i = 1..m} 与 h_j(x) = 0, j = 1..p，若不存在任何 x 使全部约束成立，则称该模型不可行，冲突即存在于约束之间。
需要区分两个容易混淆的概念。不可行（infeasible）是模型层面的判定结果，求解器能明确报告；冲突（conflict）是导致不可行的约束子集及其矛盾结构，求解器未必直接给出，需要诊断才能定位。一个不可行模型可能包含多个相互独立的冲突，也可能只有一个最小冲突集（IIS，Irreducible Infeasible Set）。诊断的目标，就是把“不可行”这个笼统结论，还原为“哪几条约束、以什么方式、为什么矛盾”的具体结构。
冲突的典型表现可分为三类。第一类是硬性数值矛盾，例如同时要求 x ≥ 10 与 x ≤ 5，或产能上限 800 件而订单需求合计 1200 件。第二类是逻辑耦合矛盾，单条约束各自合理，组合后却互斥，例如“若开启产线A则必须开启产线B”与“A、B不得同时开启”两条逻辑约束并存。第三类是隐性尺度矛盾，常由单位不一致、量纲错配或系数精度问题引起，例如需求量以“吨”录入而产能以“千克”建模，表面数值都合理，可行域却被压缩为空。
二、冲突的业务影响
约束冲突在业务侧的代价常被低估。最直接的影响是决策延迟：排产、路径规划、资源分配等模型一旦不可行，计划部门只能退回手工调整，原本分钟级的求解退化为小时级的人工试错。其次是决策质量下降：为让模型“跑通”，建模者常临时放宽某条约束，若放宽的恰是安全库存或合规上限，得到的可行解可能带来库存风险或违规风险。第三是模型可信度受损：业务方多次看到“模型又算不出来了”，会逐渐绕过模型直接决策，优化系统的价值被架空。
因此，冲突诊断不只是技术排障，更是保障优化系统可持续运行的基础能力。一个成熟的建模团队，应把冲突诊断纳入模型交付的标准环节，而不是等业务方报错后再被动响应。
三、诊断与修复的整体流程框架
本课程采用的流程框架可概括为“定位—归因—修复—验证”四个阶段，下图给出其结构与各阶段的关键动作和产出。
四个阶段中，定位是技术核心。主流求解器（如 Gurobi、CPLEX、SCIP）均提供 IIS 计算接口，例如 Gurobi 的 computeIIS() 可在模型不可行时返回一个不可约冲突集。IIS 的价值在于“不可约”：去掉其中任意一条约束，剩余集合即可行，因此每条约束都是矛盾的必要组成，归因时不会浪费精力在无关约束上。但需注意，一个模型可能存在多个 IIS，求解器通常只返回其中一个，定位阶段应结合业务知识判断是否还有其他冲突区域。
归因阶段要把约束清单翻译成业务语言。以排产模型为例，若 IIS 包含“订单需求合计 ≥ 1200”与“产线日产能 ≤ 800”两条，归因结论不是“这两条约束矛盾”，而是“当期订单总量超出可用产能，需确认是否有外协产能或订单可延期”。这一步的产出应能直接交给业务方讨论。
修复阶段有三条路径：改数据（修正录入错误、更新产能参数）、改约束（调整上下界、拆分约束、引入软约束并设置惩罚权重）、改结构（增加外协变量、放宽时间窗、调整目标函数与约束的优先级）。软约束是常用手段，通过引入松弛变量 s ≥ 0 将硬约束 g(x) ≤ b 改写为 g(x) ≤ b + s，并在目标中最小化 s 的加权和，使模型在冲突时给出“最小违约”的可行解，而非直接不可行。
验证阶段不能只看求解状态变为 OPTIMAL，还要检查修复后的解在业务上是否可接受，并对同类模型做回归测试，防止同一冲突在其他数据集上复发。
四、学习路径与实战项目
本课程后续章节按“认知—工具—方法—实战”递进组织。认知部分建立冲突分类与可行域直觉；工具部分覆盖主流求解器的 IIS 接口、日志解读与建模语言（如 Pyomo、Gurobi Python API）中的诊断写法；方法部分深入最小冲突集计算、软约束建模、多目标取舍与冲突预防的建模规范；实战部分以一个含产能、库存、运输多环节的排产优化模型为载体，完整走一遍从不可行到可用的诊断修复过程。
实战项目的建议组织方式：准备一份故意包含冲突的排产模型（示例参数：3 条产线、日产能分别 300/280/220 件，5 个订单需求合计 1050 件，另设安全库存下限与运输能力上限），先让模型返回不可行，再按本课程流程逐步定位 IIS、归因到具体业务规则、选择修复路径并验证。读者应记录每一步的约束清单变化与求解状态，形成自己的诊断日志。这套日志本身就是后续排查同类问题的可复用资产。