企业官网建设流程全解析

做了几年APS（高级排程与计划系统）的实施和研发，我最大的体会是：排产调度看起来是个“排顺序”的活，真正落地时却全是约束和性能的博弈。生产现场的交期、设备、工装、人员、物料，每一项都是约束；车间主任一句“这张急单插进去”，就是一次重排。早期我用传统的排程软件和规则引擎做过不少项目，遇到大规模订单和频繁插单时，求解速度慢、解质量差的痛点非常突出。后来转向OptaPlanner这个开源的约束求解引擎，才真正把“排得出”和“排得好”这两个问题分开解决。

OptaPlanner目前是红帽主导的Apache License 2.0开源项目，在JVM生态里做APS选型时几乎绕不开它。它最大的特点是内置禁忌搜索、模拟退火、Late Acceptance等元启发式算法，并且实现了高效的增量评分机制。但真正决定一个排程系统能不能落地、能不能在几分钟内给出可执行排产方案的，往往不是算法本身，而是两件事：怎么把排程顺序建模建模成可求解的结构，以及怎么设计“移动（Move）”让求解器高效地搜索解空间。这篇文章我把OptaPlanner的链式结构（Chained）建模和移动优化这块最核心的实践拆开来讲，其中也包括我们对“越急越优先”“插单重排”这类APS通病的处理方式。内容适合正在做APS选型的技术负责人，也适合打算用OptaPlanner实现车间排产、配送调度、服务排程的开发者参考。

1. APS排程为什么需要OptaPlanner这类求解器

1.1 排产调度的难点到底在哪

APS排程之所以难，不在于“排出来”，而在于“约束多、变化快、目标还互相打架”。一个典型的离散制造车间，工单要经过下料、机加、热处理、装配等多道工序，每道工序可能有多台可用设备；设备有加工能力差异、有工艺切换的工装准备时间；物料有到料时间；订单有交期、有优先级；更麻烦的是，现场经常出现设备故障、急单插入、原材料晚到。这些因素叠在一起，排程问题从数学上看就是典型的NP-Hard问题。

我自己接触过的很多企业，早期都用Excel或者ERP自带的简单排程功能，本质上是人工按交期先后或设备负载粗略排一个甘特图。车间规模小、订单变化慢的时候还能对付，一旦订单上千、设备上百，靠人工去逐条匹配约束几乎不可能。另一个常见的做法是用规则引擎（比如Drools）写排程逻辑：先把订单按优先级排序，再逐个寻找最早可用设备。这种算法在学术上叫贪婪构造启发式，优点是快，缺点是没有回头路，经常出现前面排得很舒服、后面所有单子全部积压的尴尬局面。

这里的核心矛盾是：排程问题需要的是“先有可行解，再不断优化解”的求解能力，而不是简单的if-else规则判断。规则只能表达怎么做，无法在庞大的解空间中搜索并判断哪个方案更好。这就是OptaPlanner这类约束求解器存在的价值。它把一个排程问题抽象成规划实体（PlanningEntity）、问题事实（ProblemFact）和评分约束（Constraints），然后用启发式算法构造初始解，再用元启发式算法在解空间里不断迭代改进。

注意，求解器和规则引擎不是替代关系。实践中我经常把两者搭配使用：规则引擎处理各种异常分支和业务校验，求解器负责真正复杂的顺序优化。后者解决“哪个方案更优”，前者解决“哪些方案合法”。

1.2 从“合法排程”到“优化排程”：OptaPlanner的求解思路

OptaPlanner求解排程问题，流程大致分三步：建模、初始化、局部搜索。建模阶段定义排程变量，比如工单在哪台设备上加工、在设备上的先后顺序是什么；初始化阶段用构造启发式算法快速生成一个合法的初始排产方案，常用策略有First Fit、Cheapest Insertion等；局部搜索阶段则通过一系列的“移动”不断变更方案，再根据评分来判断变更后的方案比之前好还是差，最终在终止条件到达时返回当前找到的最优解。

理解这个流程的关键，在于理解“移动”的含义。在离散优化里，一次移动就是从一个解跳到相邻的另一个解。例如在排程问题中，把一个工单从设备A挪到设备B，就是一种移动；交换两条链路上的两个工单，是另一种移动。OptaPlanner的局部搜索每走一步，都会做三件事：执行移动、评估新解得分、决定是否接受新解。如果没有增量评分机制，每评估一个方案都要把整个排程从头计算一遍，计算量是灾难性的。OptaPlanner的增量评分通过变量监听器（VariableListener）维护中间结果，只重新计算被移动影响的那部分，这也是它能支撑百万级解空间的原因。

从工程角度看，OptaPlanner还给了开发者一个巨大的便利：它不要求你实现这些优化算法，你只需要写清楚约束、选择合理的移动策略、调整好参数，其余交给框架。但这也意味着，如果建模不好或移动策略设计粗糙，再好的算法也发挥不出效果。这就是为什么我认为链式结构和移动优化才是OptaPlanner实践中的分水岭。

2. 链式结构：让顺序依赖变得自然的建模方案

2.1 为什么不用“下一个是谁”而用链式建模

先看一个最常见的APS场景：给同一台设备上的多个工单排加工顺序。很多人第一反应是定义一个工单的前后关系，比如给每个工单设置一个“下一道工单”的变量，通过前驱后继表示顺序。这个想法在数据模型上没错，但在OptaPlanner里如果这么建模，会掉进一个巨大的陷阱。

假设有3个工单A、B、C要排到底是谁在谁前，你在A上设一个变量指向B，B指向C，如果A同时被赋值为C，就会形成环A→C→A，产生非法解。为了防止这种情况，必须写很重的约束去惩罚环，还得处理多个头尾节点，模型复杂度和求解性能同步恶化。这个问题的本质是：顺序关系是一个全局结构，用普通的赋值变量表达它，很难保证结构的合法性与完整性。

OptaPlanner给出的解法是链式结构（Chained）建模，它的设计思路和数据结构里的结构体链式存储一脉相承。每个排程实体有一个“前驱指针”指向它前面的实体，链的头部是一个特殊的锚点（Anchor），锚点本身不会被移动，只作为固定起点存在。工单A的previousStandstill指向锚点或另一张工单，工单B的previousStandstill指向A，这样整条链自然形成生产顺序，链的方向是从锚点到尾部，尾部是最后加工的工单。因为每个实体只能有一个前驱，所以永远不会出现分叉；因为指针不会指回自己，所以环也不会出现。这个结构天然合法。

我在实际项目里最喜欢用链式结构的场景是设备排程和运输路线规划，两者有一个共同点：解的核心是一串有先后顺序的对象。快递配送中，车辆是锚点，客户点是链上的节点；车间里，设备是锚点，工单是链上的节点。同一辆车、同一台设备永远只能在一个位置、加工一个工单，链式结构把这个硬约束从评分层面下沉到了模型层面，极大减少了无效解的搜索空间。

有一点容易混淆：链式结构中的“链”是求解过程中不断变化的一部分，而“锚点”是问题事实，求解器不会修改锚点上的变量。锚点更像是链表里的哑节点（dummy head），只为了统一处理链头指向。

2.2 用OptaPlanner实现链式排程的核心配置

在OptaPlanner里启用链式结构，只需要在排序变量上指定graphType为CHAINED。下面是我在车间工单排序项目里实际使用过的一个简化模型，可以和你们的业务对接后直接改。

public class WorkOrder { @PlanningId private Long id; private int priority; private int processingMinutes; private LocalDateTime releaseTime; private LocalDateTime dueTime; @PlanningVariable( graphType = PlanningVariableGraphType.CHAINED, valueRangeProviderRefs = {"machineRange", "workOrderRange"} ) private Object previousStandstill; @AnchorShadowVariable(sourceVariableName = "previousStandstill") private Machine machine; @ShadowVariable(variableListenerClass = WorkOrderStartTimeListener.class, sourceVariableName = "previousStandstill") private Integer positionIndex; ... }

先说lastPreviousStandstill这个变量。类型用Object是最省事的做法，因为前驱可以是锚点Machine，也可以是另一个WorkOrder。valueRangeProviderRefs里同时声明了两个取值来源：machineRange提供锚点集合，workOrderRange提供可排的其他工单集合。这样求解器才能知道“我可以把这张工单放在哪台设备上，也可以跟在哪张工单后面”。

接着是machine这个影子变量。它用@AnchorShadowVariable注解，会自动从previousStandstill顺着链头一路找到锚点。这个字段不是让求解器去修改的，而是让约束评估时直接知道“这张工单最终落在哪台设备上”，省去每次在评分里递归追链的开销。在做设备负载均衡约束时，这个影子变量能大幅减少计算量。

再往下是我额外加的positionIndex影子变量。它由WorkOrderStartTimeListener维护，用来记录每张工单在当前链上的序号。为什么要这样一个变量？因为APS场景经常要表达“某张紧急工单必须在某张工单之前完成”这类顺序约束。如果只靠评分函数从头遍历链来判断，每次评分代价都很高；维护positionIndex后，约束可以直接比较两个工单的序号，响应速度完全不同。

构造初始解和搜索阶段，OptaPlanner会自动处理链的插入和打断。例如把一个工单从链的中间位置挪走，原链会自动把它的前驱和后继拼接起来；把一个工单插到另一个工单后面，它原有的后继会断开。这些操作在底层被封装成了链式结构专用的移动，不需要我们在业务代码里手工维护指针。正是这个特性让链式结构对比手写链表实现优雅得多——你负责定义解的长相，框架负责维持结构的合法性。

2.3 “越急越优先”在链式排程里的落法

“越急越优先”是APS排产调度里遇到最多的业务需求，但也是听起来简单、落地复杂的需求。简单在于，谁都能三天交期里看出来哪张单子更急；复杂在于，“急”是一个相对的优先级还是绝对的硬约束？插单以后是只调急单的位置，还是把整条线上的顺序推倒重排？

随便举个例子：某条产线上已经有10个工单在排队，突然进来一个交期只有24小时的加急工单，同时它需要的前序工序还没做完。这时候如果只是把工单强行插到链头，可能让后面所有工单延误，整体损失更大。如果完全不插队，又满足不了急单要求。这里必须建立多层级评分体系。

OptaPlanner的评分支持多级惩罚，比如HardMediumSoftScore，这与APS业务天然契合。硬约束表示绝对不能违反的物理限制，如设备不可能同时加工两张工单，这是100%要满足的。中等约束对应交期违约、优先级违约，业务上希望尽量满足但偶尔也可以商量；软约束对应成本、均衡负载、客户满意度等，属于优化指标。优先级和交期都可以落成中等约束的惩罚项，但惩罚系数要按紧急程度做差异化处理。

factory.forEach(WorkOrder.class) .filter(order -> order.getMachine() != null) .penalize( HardMediumSoftScore.ONE_MEDIUM, order -> { LocalDateTime completionTime = order.getStartTime() .plusMinutes(order.getProcessingMinutes()); if (completionTime.isAfter(order.getDueTime())) { // 每延误一分钟，惩罚随优先级线性放大 long overdueMinutes = ChronoUnit.MINUTES.between(order.getDueTime(), completionTime); return (int) (overdueMinutes * (1 + order.getPriority() * 0.5)); } return 0; }) .asConstraint("dueTimeAndPriority");

这段约束表达了一个很实用的策略：交期违约是扣分项，但优先级越高的工单，同样延误一分钟被扣的分越多。也就是说，求解器在搜索时会倾向于优先满足高优先级工单的交期，必要时才牺牲低优先级工单，这比单纯给工单“排序”再固定下来科学得多——因为它把“怎么调整顺序最优”留给了搜索算法，而不是拍脑袋决定。

插单重排是另一个链式结构的优势场景。订单插入后，由于链式结构中每个实体都有且仅有一个前驱，新工单只需要选择某个位置插入，调整的是局部链段。配合重规划（Replanning）能力，可以锁定已经确认执行的工单，只放开受影响时间窗内的工单参与搜索，把“插一张急单”的求解时间从半小时级别压缩到几分钟级别。这个细节在后面的重规划部分会细讲。

实操中要特别注意：不要用优先级直接给工单在链上排固定位置，例如硬约束“优先级为1的工单必须在优先级为5的前面”。这样虽然直观，但牺牲了求解自由度，往往导致低优先级工单被无限期阻塞。优先级更应该体现在评分权重的差异上，让算法自己权衡“插谁、插在哪”的综合代价。

3. 移动优化：提升求解性能的核心手段

3.1 内置移动类型与选择器配置

在OptaPlanner里，局部搜索的质量和效率，很大程度上取决于移动选择器（MoveSelector）的设计。移动选择器决定每一步搜索考虑哪些候选移动、按什么顺序考虑、是否接受这个移动。内置的移动类型已经覆盖了大量常见场景，但要用好它们，必须先知道它们各自的脾气。

ChangeMove是最基础的移动，作用是把一个实体（比如一张工单）从一个位置移动到另一个位置。在链式结构中，它表现为把工单从其当前链上摘下来，再插入到另一条链的某个位置，或者提前/延后到同一条链的其他位置。ChangeMove能快速把一个陷入瓶颈的工单迁移到负载较低的资源上，是资源均衡的主力。

SwapMove是交换两个实体的位置。当两个工单分别卡在两条链的不同位置时，直接交换二者位置可能同时缓解两处瓶颈。它的特点是变化幅度大，搜索早期能快速打破僵局。但在搜索后期，如果两个实体性质差异很大（例如一个高优先级急单和一个低优先级补料单），频繁Swap反而容易破坏已经收敛的局部优质解。

TailChainSwapMove是链式结构里非常特殊且好用的移动，它把链的一段尾部整体交换到另一个位置。这个移动在VRP路线中特别高效：一辆车把最后几个客户点丢给另一辆车，避免一边满载一边空驶。对应到APS，就是把一串顺序连续的工序整体从一台设备搬到另一台设备，保持它们内部顺序不变。这个移动能减少“整体搬迁”时的搜索步数，一步到位完成结构性调整。

实际配置时，我会给这些移动设置不同的选择概率。经验值通常是ChangeMove占大头，约60%到70%；SwapMove占20%到30%；TailChainSwapMove占10%左右。根据问题的规模要动态调整：链越长，TailChainSwapMove的收益越明显。示例配置如下：

<localSearch> <unionMoveSelector> <changeMoveSelector> <selectionProbability>0.6</selectionProbability> </changeMoveSelector> <swapMoveSelector> <selectionProbability>0.3</selectionProbability> </swapMoveSelector> <tailChainSwapMoveSelector> <selectionProbability>0.1</selectionProbability> </tailChainSwapMoveSelector> </unionMoveSelector> </localSearch>

这里必须先说明一个常见误区：“移动优化”指的是Move层面的选择与自定义，不是移动端App的性能优化。搜索热词里把“移动端性能优化”和OptaPlanner的“移动优化”混为一谈的不少，实际上它俩差了十万八千里。本文讨论的是求解器内部如何设计高效的邻域搜索算子。

配置选择器时还要重点关心一个参数：随机性。默认情况下，OptaPlanner从一个解出发生成候选移动集合，选择器决定从集合里抽取哪些移动进行评估。如果每次生成的候选移动都局限在很小的局部区域，搜索会陷入局部最优；如果完全随机乱跳，又很难收敛。解决这个问题的方法是为选择器设置合理的随机种子（randomSeed），并用不同的选择策略组合：集中的子选择器用来精细挖掘，跳变的子选择器用来跳出局部最优。

3.2 定制移动：当内置移动表达不了业务结构时

不是所有业务都能靠内置移动完美表达。我在一个半导体封装车间的项目里遇到过这类需求：某类产品有固定的工艺路线，必须连续经过清洗、贴片、固化三道工序，且三道工序不能被打断。用内置ChangeMove时，求解器经常把这三道工序拆散，然后靠约束拼命扣分，搜索效率极低。要打破这个局面，最直接的办法是定制移动。

实现自定义移动有两种常见方式：实现Move接口，或者实现MoveIteratorFactory。Move接口的核心是doMove（执行移动）和undoMove（回滚移动）。回到刚才的三工序连续加工需求，我可以设计一个“工序簇移动（ClusterMove）”：把这三道工序打包为一个整体，整体插入到新设备或新位置。只需要定义以下核心逻辑：

public class ClusterMove implements Move<PlanSolution> { private final List<WorkOrder> clusterOrders; private final Object destination; private final Map<WorkOrder, Object> originalPositionMap; public ClusterMove(List<WorkOrder> clusterOrders, Object destination) { this.clusterOrders = clusterOrders; this.destination = destination; } @Override public boolean isMoveDoable(PlanSolution solution) { return destination != null && !clusterOrders.isEmpty(); } @Override public ClusterMove doMove(PlanSolution solution) { originalPositionMap = new LinkedHashMap<>(); for (WorkOrder order : clusterOrders) { originalPositionMap.put(order, order.getPreviousStandstill()); } // 将整个簇从原链摘下，再插入destination后面 // 这里要处理簇内顺序不变、簇间前驱后继的指针重连 ... return this; } @Override public ClusterMove undoMove(PlanSolution solution) { // 恢复originalPositionMap中记录的原前驱关系 return new ClusterMove(clusterOrders, null); } }

看完这个骨架，你们可能察觉到，自定义Move方法不算难，真正需要注意的坑全在细节里。第一，执行doMove之后原对象引用被修改，undoMove不能靠重新new对象实现，而是必须反向恢复原引用，否则解的状态会错乱。第二，getPlanningEntities和getPlanningValues两个方法要返回被移动的实体集合和变量值集合，它们是增量评分跟踪变更范围的依据，漏掉任何一环都会导致评分不准还不报错，排查起来很痛苦。

另一个我常用的定制方式是通过MoveIteratorFactory动态生成移动集合。它和Move接口的区别是，前者在每轮搜索开始时生成一批候选移动，后者是单次移动逐个生成。在链式重排场景中，MoveIteratorFactory可以提前把“当前所有可插入的位置”枚举出来，让选择器从中抽取，避免每步都做大量重复判断。对于有上千张工单的大规模排程，这个差异非常明显。

3.3 调参心得：步数、接受准则与终止条件

OptaPlanner的默认参数已经能跑通很多问题，但想获得实际可用的排程质量，我几乎每次都要调整三个大方向：接受准则、终止条件、选择器过滤。

接受准则决定新解会不会被采纳。OptaPlanner内置了Late Acceptance、Simulated Annealing、Tabu Search等策略。我的个人体会是，APS类型的排序问题最适合从Late Acceptance入手，它在保留一定记忆性的同时又不太容易震荡。与模拟退火相比，Late Acceptance的参数少很多，主要就是设置一个滞后后的比较窗口（Late Acceptance Size），默认值通常是100到200。窗口太小时几乎退化成贪心算法，很容易卡在局部最优；窗口太大则接受差解太多，收敛缓慢。我一般在100左右起步，根据求解日志的分数曲线微调。

终止条件直接决定了排程系统能在多长时间内返回结果。APS是业务系统，用户不可能等上个小时。对于接单重排，我们通常设置两类终止条件：最多运行时间和最大未改善步数。两个条件只要满足一个就停止，保证最坏情况也有解返回，同时在解长时间不提升时尽早收手。示例如下：

<termination> <terminationCompositionStyle>OR</terminationCompositionStyle> <unimprovedStepCountLimit>2000</unimprovedStepCountLimit> <secondsSpentLimit>120</secondsSpentLimit> </termination>

观察求解质量时有一个很实用的技巧：打开求解日志中的BEST_SCORE和STEP_SCORE。BEST_SCORE是最佳解的分数，STEP_SCORE是当前步解的分数。如果BEST_SCORE长时间不动，而STEP_SCORE还在大幅波动，说明移动选择器里的多样性不足，搜索在一个次优区域反复横跳；如果BEST_SCORE在稳定上升但偶尔会下降，这通常是接受了差解，在爬出局部最优的过程中，属于正常现象，不必要惊慌。

调参最忌讳一上来就追求最优参数。我建议先在缩小版的数据集上跑通全流程，用几百条工单验证模型和移动的正确性，再逐步放大数据集，按BEST_SCORE曲线的变化调整选择器概率和接受准则。直接拿几十万工单生产数据调参，一轮就跑几小时，效率极低且无法分辨是模型问题还是参数问题。

4. 常见问题与排查技巧实录

4.1 链式结构调整后评分异常怎么排查

链式结构引入了一个独有的问题：一次变更会沿链传播，影响范围往往比想象中大。举一个我实际遇到过的场景：A工单在链中间，把它从链上摘下来，它后面的B、C、D工单的开始时间全部要提前；把它插到另一台设备的链头，那台设备上的所有后续工单都要顺延。如果约束里引用了开始时间，那么这些联动变化必须全部纳入评分重算，少算一个，评分就悄悄出错。

这一类问题非常隐蔽，因为OptaPlanner本身不报错，解也是合法的，但约束得分明显不符合业务常识。我的排查步骤是有顺序的。首先在构造初始解完成时打印一个基准评分，手动把工单顺序导出成甘特图，用业务直觉确认初始解合理。接下来逐步放大数据量，对比每一步的BEST_SCORE变化是否平缓；如果某一步骤分数剧烈跳变，就锁定那个步前的移动类型，复现后单独评估。

造成这种异常的头号原因，是影子变量没有实现增量更新。我见过不少项目为了省事，在约束里实时遍历整条链计算当前工单的开始时间，结果一次链变更触发几十次整链遍历，评分计算量爆炸，而且遍历链的代码一旦写错，影响还会被增量传播机制放大。解决办法是严格按照影子变量的思路，用VariableListener为每个工单维护开始时间、结束时间、位置序号等派生数据，让框架在链变更时自动触发增量更新。可能有些读者觉得这个方案绕，但它其实是OptaPlanner官方推荐的做法，越是复杂链越要依赖影子变量。

4.2 求解卡住不动或者收敛太慢

我在多个项目里都遇到过同一个现象：求解器跑了一两个小时，BEST_SCORE曲线纹丝不动，但STEP_SCORE还在不断变化，说明它一直在搜索但找不到更优解。这时候最常见的根因不是算法参数差，而是移动选择器太单一或者候选移动范围太窄。

第一种情况是只有ChangeMove，没有SwapMove。ChangeMove适合做局部微调，但有些最优解需要把两张工单互换位置才能到达，而单独用ChangeMove需要先移走A再移走B，中间状态的评分比当前解更差，被接受准则拒绝，搜索就绕不过这座山。补救办法就是加入SwapMove和TailChainSwapMove，让跨越“坏中间态”一步完成。

第二种情况是选择器里没有加装实体过滤。链式子结构里，有些工单本身因为工艺约束不能轻易移动，例如上一道工序还没完成，就把它参与ChangeMove，只会产生大量“非法尝试”，浪费计算资源。这时用就近选择器（Nearby Selection）或按实体类型过滤，把候选限制在可移动集合内，能明显提高单步效率。

第三种情况是求解规模真的太大。排产系统里几十万工单直接进求解器，即使模型和移动都对，搜索空间也让算法无从下手。我的处理思路是分治：先按产品族或工艺路线把订单拆分到几个子问题，分子求解后再合并。这里有个前提，分治策略不能完全打破约束之间的关联，否则子问题最优解合并后全局不一定最优。实践中先保证“可行”，再慢慢缩小子问题之间的耦合度。

4.3 插单重排太慢，如何利用重规划机制

插单是APS系统避不开的功能。业务侧的期望是，业务员录入一张加急单，点击重排，系统在一两分钟内给出新的生产计划，并且只能把已发布执行的工单尽量保留。如果每次插单都全量重算，不仅慢，还会惹怒车间——明明已经做了一半的工单，系统却说改成另一个方案，现场根本不接受。

我用的方案是OptaPlanner的重规划（Replanning）能力，核心思想是：把已经固化执行的变量通过实体过滤或者变量固定锁住。在链式模型里，通常会把已经开工或即将开工的几张工单的previousStandstill从求解变量中剔除，不再允许移动；只对后续未开始的工单开放移动。这样求解器搜到的所有新解都天然保住了已发布的现场计划，而且搜索范围大幅缩小，性能效果立竿见影。

具体到代码上，可以先把可重排部分单独摘出来构建一个子Solution，也可以在原Solution上通过过滤链上实体的可规划状态来达成。需要注意的是，插单重排要小心处理优先级极高工单的“穿透”效果：如果锁死了已开工工单的位置，但一张优先级极高的急单刚好需要插到锁死区域之前，系统会直接判为不可行。针对这个场景，我倾向于把锁死范围设置成软锁，即已开工工单默认固定，但允许高优先级重排解开第一个已开工工单的锁。这里没有万能的配置方法，必须结合企业实际流程来决定锁哪几道工序。

最后再分享一个小技巧。我在做链式模型时习惯把锚点的ID设计成有业务意义的编号，比如设备编号A01、B02，这样求解日志里看到链结构就能一目了然，不用再对照主数据表查设备名称。排查问题时，这类小习惯能省下大量时间。OptaPlanner的链式结构本身不难，难的其实是它放大出来的业务理解和建模功底，这也是我始终建议团队里最懂生产流程的人来主导建模的原因。