山鹰与立邦的排产内核

APS（Advanced Planning and Scheduling，高级计划排程）不是一种东西，是一类问题的统称。落到这两个客户身上，题面差得很远：

造纸厂的物理过程很短，但每个名词都会在后面反复出现，先认一遍：

门幅

客户要的成品卷宽度，单位 mm，比如 1900、2500。不是机器的宽度。

幅宽

纸机能出的总宽度，比如 5450 mm、8650 mm。一台机一个档。

排刀组合

一次下刀里并排的那几个门幅，例如 1700+1800+1950。总宽必须落在允许区间内。

套

这组刀切一遍出一套。1700+1800+1950 × 21 套 = 这三个门幅各出 21 件。

边料

一组刀没占满的那点宽度，直接是废纸。

配棍 / 配码

计划员把一天的门幅需求凑成若干组合 + 套数的这件事。人工做一次 15 分钟到半天。

以 PM15 这台 5450 机为例：一组刀里最多 3 个门幅，总宽必须落在 5400–5450 之间——50 mm 的窗口。多了切不下，少了浪费太多，客户不认。

直觉是：门幅越大，一组里放的片数越少，选择越少，应该越好算才对。真实情况正相反，而且原因不止一个。把两台机分开看，就清楚了。

在 5450 这种窄机上：大门幅的"搭档"几乎不存在

把案例里 25 个门幅逐个数一遍——它能出现在多少个合法组合里：

所以"大门幅组合太多"这句话，在这台机上是反的：不是太多，是只剩两三个。看一眼 2500 的处境就明白：

在 8650 这种宽机上：反过来，组合是真的爆炸

PM17 是 8650 mm、每组最多 7 刀。这时候"组合太多了"就是字面意思：

3800 万 vs 5847，差了四个数量级。如果用人的思路（或者一段贪心脚本）在 3800 万种搭配里试，试一辈子也试不完；先用幅宽窗口把不可能的剪掉、再把剩下的交给整数规划求解器，问题一下子就小了。反过来说，凡是走"逐个门幅找搭档、一路试凑"这条路的做法，碰上 7 刀都会卡住。

第三个坑，也是最致命的：目标函数选错

就算算得动，还有一个陷阱。如果直接让求解器"交付件数最多"，它会得出一个数字更漂亮、但客户当场翻脸的方案：

为什么最大化件数天然歧视大门幅？因为一套刀里放三片小的能交 3 件，放两片大的只交 2 件；而且每塞进一片大门幅，就要吃掉两片稀缺的小料。求解器忠实地执行了"件数最多"，就一定会把大门幅饿死。错的不是求解器，是没人告诉它公平也算目标。

整条链路就一句话：把 Excel 需求读进来，枚举出所有合法组合，用两阶段求解定套数，再公平拆回客户，最后导回客户现有的上传模板。

两阶段到底在权衡什么

阶段 A 算出来的 16%，是这批需求在物理上能做到的公平极限——再高就无解了。但如果直接拿 16% 当硬下限去配，总交付只剩 382 件；把下限松到 11%，总交付回到 442 件。5 个百分点的公平，换 60 件的交付。

下面这条曲线是把公平下限从 0% 逐格扫到 16%、每一格都完整求一次解得到的，它就是这个问题的全部可选项：

为什么不能写成一个加权目标

最自然的想法是把公平也变成一项分数，和交付加在一起调权重。问题在于这两者需要一个"兑换率"——一件货，值几个百分点的公平？这个数在业务上根本不存在，而且调不出中间地带：公平权重稍低，求解器立刻回到 485 件那种"7 个门幅为 0"的解；稍高，交付就崩。字典序回避了这个问题：它不需要给公平定价，只需要规定谁先问。

但阶段 B 内部的三个次目标是加权的，因为它们之间的兑换率是真实存在的：每交付 1 件记 10000 分，每多用一个组合扣 100 分，每 1 mm·套边料扣 1 分。换算过来就是——多交 1 件货，值得多换 100 次刀、或者多浪费 10000 mm 边料。所以后三项其实只决定"交付件数打平时选哪个方案"，永远不会为了省边料去少交一件货。这正是客户的原话：重要的是生产完那一刻到底交多少。

还有几个必须处理的现实

• 算不出来怎么办。阶段 A 要是连一个可行解都没拿到，就退化成"不设公平下限"的纯交付模式，至少给出一版能用的方案，并在解释里写明降级了；阶段 B 要是超时没解，返回锁定的组合 + 一句为什么。永远返回方案，不返回报错。
• 人锁了组合之后。计划员锁定的组合先从需求里扣掉（它已经交付的那部分算进满足率的分子），剩下的余量才进模型。所以重算不会推翻人的决定，也不会把人已经给出去的货重复计算。
• 时限要给够。5450 机 4 秒就能拿到最优。8650 机交付量很快就满了，但组合数对时限敏感：阶段 B 给 6 秒是 33 个组合，10 秒 24 个，≥14 秒才稳定在 22 个——差的那 11 次换刀是实打实的停机时间。所以宽幅机台的时限不设低于 20 秒。
• 下限 5 个点是参数，不是定论。fairness_slack_pct 摆在界面上，计划员可以当场拉动看曲线上的另一个点。真正该由客户决定的事，不该焊死在代码里。

拆回客户这一步，同样是公平题

配出来的是"这个门幅能出 8 件"，但这 8 件背后可能站着 5 个客户。规则是客户自己给的：不是绝对平均，是按需求占比——需求 9:6:1 就尽量按 9:6:1 缩放；小门幅占比高的客户可以多匀一点；全是大门幅的客户，先单独给它配一版再跟大表合并。这一层是个毫秒级的线性规划，目标是"各客户满足率的最小值最大"。

输出不是一张算法报表，而是一张销售可以直接拿去跟客户谈的表：客户 × 门幅 × （要多少 / 能给多少 / 缺多少）。

四个页面

技术栈：Python FastAPI + Google OR-Tools CP-SAT + Vue 3，求解跑在独立 worker 里（免得长任务卡住页面），方案按版本存 PostgreSQL。一期只做配棍 + 分配 + Excel 进出，纸机的月/周品种计划不碰——那是多部门开会定的事。

立邦泉州是涂料厂，题面完全不同：几百张工单，两条产线，每张单该去哪条线、排第几位。难点在"换色洗机"——上一单做白色、下一单做深色，中间要洗机，洗多久取决于从哪个颜色切到哪个颜色（一张切换代价矩阵）。所以顺序本身就是钱。

怎么评分：硬 / 中 / 软，三层字典序

三层是字典序比较：先比硬的，硬的一样才比中的。跟山鹰的"先公平再总量"是同一个思路——有些东西不能被另一些东西买走。

怎么搜：Late Acceptance

解空间大到没法穷举，于是用局部搜索：随机挪一张单、换两张单、把一段倒过来、把同类的一整块搬走，每动一次算分。关键在"接不接受这一步"——只跟 50 步以前的自己比（Late Acceptance），比那时候好就接受。这样它敢走下坡路，翻得过小山头，又不会像模拟退火那样要调一堆参数。连续一万步没进步，就回到历史最优、砸掉 12 张单重排（ILS 重启）。两条线 190 张单，3 秒收敛。

真正值钱的不是算法，是让人敢用

立邦两轮验收踩出来的这套设计，在山鹰项目里被原样搬了过来：

• 先证明底账没算错，再给建议。系统敢改开单量之前，先把现有口径逐行对到 102/102。到山鹰就是：先复现计划员现在的配棍结果，再谈优化。
• 任何数字都能问"为什么"。规则触发链路、约束分解到单张工单、还有反事实解释（"这张单挪到别的班会怎样"）。验收时评价最高的就是这条。
• KPI 卡自带对照，而且是真对照。曾经有个"班次超产能"指标恒为 0，被验收抓出来是假校验——一个永远显示 0 的指标，会让人误以为已经校验过了。也别臆造对照组：叫"现状模拟"结果里面没有现状逻辑，被追问一次，全部对比数字都会被怀疑。
• 人机分工要明确。默认只让人钉"哪台机、哪天、哪个班"，班内顺序交给求解器——人掌握系统不知道的信息（客户在催、今天缺人），系统强在组合优化；让人去拖分钟级的时刻，是在跟求解器抢它擅长的事。
• 每一手当场报代价。改完弹一句"洗机 +1.0 h · 迟交 +2 张"。山鹰版就是"交付 −3 件 · 边料 +200 mm"。
• 改数据和改排法要分账。补录主数据、订正产线状态改的是输入，不能算进"人工调整的净影响"；否则"洗机少了 1 小时"说不清是数据终于填对了，还是排法真的变好了——这两件事该找谁改，完全不同。

山鹰的配棍内核是从零写的（立邦仓库里没有任何一维下料的代码），但外面那一圈——规则引擎、人工调整语义、评审台账、回测方法——直接搬，省掉约 40% 的工作量。

选求解器的逻辑也不一样。配棍是"选哪些组合、各切几套"的整数规划，变量清清楚楚，用 CP-SAT 能证明最优；排序是"几百张单的排列"，没法证明最优，只能用局部搜索找一个足够好的。同一个项目组，两种问题，两把工具。