含随机工期调度问题中undomove致score差异的处理方法

首先明确求解器对shadow variable的强制规则：

A shadow variable is in essence the result of a formula/algo based on at least 1 planning variable (and maybe some problem properties). The same planning variables state should always deliver the exact same shadow variable state.
即shadow variable本质上是基于至少1个planning variable（可结合部分问题属性）经公式或算法计算得到的结果，相同的planning variable状态必须始终对应完全一致的shadow variable状态。

该类问题的核心矛盾是：含随机工期的项目调度问题中，工期为随机变量，即便作业的开始时间在执行move、undomove操作前后保持一致，实时计算得到的作业结束时间也会产生差异。作业的开始时间、结束时间均属于shadow variable，这种计算偏差会直接导致undomove操作后的score与move操作前的score不一致，破坏求解器的状态一致性假设。

可按以下方案落地处理：

• 优先将随机采样逻辑从shadow variable计算链路中完全剥离。不要在shadow variable更新、score计算环节实时生成随机工期值，在单轮求解启动前就为所有作业预先生成固定的工期样本，单轮求解全程所有计算环节都复用这组固定样本值，全程禁止触发新的随机数生成。这种处理下，只要planning variable状态一致，输入的工期参数固定，计算得到的结束时间、score就会完全一致，天然满足shadow variable的一致性要求。如果需要优化调度方案在随机场景下的鲁棒性，可以通过多轮求解加载不同预生成样本集的方式实现，单轮求解内部必须保持所有输入参数固定。
• 调整shadow variable的定义边界，将随机扰动项从shadow variable计算逻辑中拆分出去。shadow variable仅存储基于确定参数（如工期期望值、标称工期值）计算得到的基准开始/结束时间，随机工期带来的时间偏差放到score计算层独立处理。处理时需要为每个move操作做完整快照：执行move时，将当前操作用到的所有随机工期值、计算得到的score一并存入undo快照，执行undomove操作时直接读取快照中存储的原始状态与得分，不触发重新计算，从流程上避免重算带来的数值偏差。
• 增加一致性校验兜底逻辑。如果业务场景必须在计算过程中保留随机逻辑，就关闭求解器默认的增量score计算强依赖，每次undomove操作完成后，先对全量planning variable做哈希校验，若当前planning variable集合的哈希值与move操作前的哈希值完全一致，直接用move前缓存的score覆盖当前重算得到的偏差值，避免score不一致导致求解器搜索方向错乱、出现循环搜索等问题。

核心注意事项：绝对不要在shadow variable更新方法、score计算方法中嵌入无缓存的实时随机数调用。随机数生成本身是带状态偏移的逻辑，一旦计算链路混入无快照的实时随机采样，无论怎么调整增量计算规则，都无法满足「相同planning variable状态对应相同shadow variable状态、相同score」的基础要求，这是所有处理逻辑的前提。

内容的提问来源于stack exchange，提问作者Jian Xiong