1.1 1.1 从工单到模型：建模循环

1.1 从工单到模型：建模循环

本节摘要：建模循环是把业务诉求翻译成数学问题的标准流程：问题结构化、假设建立、模型构建、验证与修正。本节以一张真实的补货工单为例，展示"决策变量—目标—约束—数据"四要素表如何把含混的需求钉死，并给出一份可以直接抄走的提问清单。

学习目标

阅读完本节，你应当能够：

1. 把一句业务描述改写成四要素表；
2. 区分决策变量、外生参数与噪声来源；
3. 用提问清单在半小时内完成问题结构化。

一张含混的工单

门店运营负责人的原话是这样的："最近缺货投诉多，仓库又压了太多钱，帮我搞个补货策略。"这句话里有两个互相打架的目标（少缺货 vs 少压库存），没有时间范围，没有说明哪些商品，也没有给数据口径。直接开始写代码的人通常一周后会被反问"这不是我想要的东西"。

问题结构化的产出是一张四要素表：决策变量（我们能控制什么）、目标（好坏怎么度量）、约束（什么做不到）、数据（拿什么算）。对这张工单，我的第一版表格如下。

注意目标一栏的"加权"两个字：两个目标打架时必须有人给出权重，这就是业务决策，不是数学能替答的。建模者此时应该把问题抛回去——"一次缺货等于多少库存成本？"——并把答案记为参数，后面做敏感性分析时专门扫它。

假设清单：写下来才算数

假设只有在白纸黑字写下之后才能被检查。补货工单的假设草稿：

• 日销量近似独立同分布，周内无趋势（可用历史数据检验）；
• 采购提前期服从经验分布，不受订货量影响；
• 不考虑商品间的替代效应。

每条假设后面标注"如果错了会怎样"。比如第一条错了（销量有趋势），那么按平稳分布算的安全库存会系统性偏低。这个"假设—后果"对照表就是 1.3 节敏感性分析的雏形。

下面这段代码把四要素表落到最小可算的模型：单商品、报童式框架，先模拟现状，再扫订货量找成本最低点。实际跑通它是理解"模型是假设的可执行版本"的最快方式。

import numpy as np

rng = np.random.default_rng(42)

# ---- 工单数据：单商品补货 ----
mu, sigma = 40.0, 12.0        # 提前期内需求的均值与标准差（件）
hold_cost = 0.8               # 单位库存每周持有成本（元）
stockout_cost = 6.0           # 单位缺货惩罚（元）
n_days = 2000                 # 模拟营业日数

demand = rng.normal(mu, sigma, n_days)  # 日需求（假设一：平稳）

def total_cost(order_up_to):
    """订到 order_up_to 水平的长期平均日成本"""
    inventory = order_up_to
    cost = 0.0
    for d in demand:
        inventory -= d
        if inventory < 0:                    # 缺货部分计惩罚
            cost += -inventory * stockout_cost
            inventory = 0.0
        else:                                # 剩余部分计持有
            cost += inventory * hold_cost
        inventory = order_up_to              # 每日补足到目标水位（简化）
    return cost / n_days

levels = np.arange(30, 91, 5)
costs = [total_cost(q) for q in levels]
best = levels[int(np.argmin(costs))]
print(f"最优补货水位: {best} 件, 平均日成本 {min(costs):.1f} 元")
​

运行结果：最优补货水位约 55～60 件。把 stockout_cost 从 6 改成 2 再跑一遍，最优水位会明显下降——这就是目标权重驱动决策的直接证据，也解释了为什么权重要由业务方拍板。

提问清单与常见偏差

我自己的结构化提问清单，按顺序问：

1. 这个建议落地时，谁在什么时刻做什么动作？（钉死决策变量）
2. 好坏用哪个数字衡量，谁负责读这个数字？（钉死目标与验收人）
3. 有哪些物理或制度上的硬限制？（钉死约束）
4. 历史数据口径与未来使用场景一致吗？（钉死数据）

第三问常常漏掉"制度约束"：比如门店规定周五必须盘点，任何要求周五到货的策略都会被一线抵触，这类约束不进模型就会在落地时被推翻。

⚠️ 常见坑：把"预测销量"当成建模目标。预测只是中间产物，目标永远是决策（订多少、何时订）。盯住决策，才不会被"预测误差又降了 0.3"这类无关进展带偏。

💡 关键直觉：四要素表里最值钱的一栏是"数据"。决策变量和目标往往业务方张口就来，而数据口径的坑（含税与否、退货是否剔除）要到跑数时才爆炸。结构化阶段就把数据字典过一遍，是性价比最高的动作。

把循环跑第二圈

值得强调：建模循环的产出不只是模型，还有"第二圈"的素材。第一圈交付补货水位后，门店执行了两周，实际缺货次数与库存数据回流——这些是检验假设一的直接证据。若周内销量显著有趋势，假设一被证伪，回到假设清单修正，模型升级为带趋势项的版本。没有回流的模型是死模型，有回流的模型才叫闭环。工程团队常犯的错是把交付当终点，殊不知交付恰是收集验证数据的开始。把"上线后第几周回收流数据、由谁回收、触发重估的条件是什么"写进交付文档，是资深建模者与新手的分水岭。这个观念在 1.3 节会发展成完整的验证纪律，在第 8 章进一步升级为可信建模的四件套。

顺带说一句工具选择：这一节的模拟用纯 Python 循环完全够用，若把日数加到十万级，向量化（把整个需求序列一次性比较、累加）能快两个数量级——但先把逻辑写对，再谈性能，顺序不能反。

本节要点回顾

• 四要素表：决策变量、目标、约束、数据，一张表钉死问题边界；
• 假设要成文：每条假设旁边写"错了会怎样"，为敏感性分析铺路；
• 权重是业务决策：多目标必须显式加权并留给敏感性扫描；
• 模型即假设的可执行版本：改一个参数重跑，比争论假设对错更高效；
• 盯决策不盯预测：建模的交付物是一个动作建议，不是一个数字。