周五下午四点，月度经营会快结束了。
投影上写着一个很大的数字：下月销售额预计 1,280 万元。
分析师刚讲完模型误差，业务负责人把水杯放回桌上，问了一句：
“凭什么？”
这三个字不太像一个技术问题。可会议室里真正想问的，往往不是模型用了什么算法，而是：假期怎么算的，促销算没算，仓库有没有货，最后如果只做到 1,100 万，究竟是预测错了，还是业务条件变了？
分析师看着那一页 PPT，忽然发现自己交出的是一个结果，不是一套可以被复核的判断。
一个孤零零的预测数字，很像酒店门口报时的钟。它可以很准，也可以很漂亮，但备货、排班和预算不能只靠它转动。业务需要知道数字下面压着哪些假设，以及哪一条假设变化时，计划也要跟着变。
文中的销售额、日期和误差数值都用于说明方法，不对应某家真实公司的经营结果。
预测不是答案，是一组带条件的判断
不少预测汇报有一个熟悉的顺序：
- 展示历史曲线；
- 介绍模型；
- 给出下月数字；
- 报一个误差指标。
流程没错，问题是业务决定通常发生在第四步之后。
要不要多备货？客服排多少人？预算按保守情形还是冲刺情形下发？如果预测只有一个点，所有人只好把这个点当作承诺。等实际结果偏离时，大家再回来追问模型。
预测领域会区分点预测和预测区间。点预测给出一个代表值；预测区间则描述在既定模型与假设下，未来结果可能落入的范围。区间不是推卸责任，恰恰是在说明：我们知道多少，还有多少不知道。
不过，只给区间仍然不够。
“下月在 1,150 万到 1,360 万之间”听起来比 1,280 万诚实，但如果业务不知道区间为什么这么宽，也不知道促销取消后该看哪一版，它依然很难用于行动。
所以，我更愿意把预测复核写成四项：
- 数据口径：到底在预测什么；
- 季节基线：历史里的“正常”从哪里来；
- 经营条件：哪些未来输入已经确认，哪些只是设想；
- 不确定性与动作：结果落到不同位置时，团队准备做什么。
这四项不负责让模型突然变聪明。它们负责让预测从分析师的电脑里走出来，变成业务可以质疑、修正和使用的东西。
第一项：先把预测对象写成一句不会误解的话
“预测下月销售”通常不够。
销售可以指下单金额、支付金额、发货金额或确认收入；可以含税，也可以不含税；可以按自然月，也可以按财务月；可以按订单发生日，也可以按收入确认日。
口径差一个词，数字可能还长得很像，使用方式却已经不同。
分析师最好在第一页就写清五件事：
| 字段 | 要回答的问题 | 示例 |
|---|---|---|
| 预测对象 | 预测的业务量是什么 | 已支付且未全额退款的含税订单金额 |
| 时间范围 | 从哪天到哪天 | 8 月 1 日至 8 月 31 日 |
| 时间粒度 | 日、周还是月 | 日预测汇总到月 |
| 数据截止 | 使用了哪一刻之前的数据 | 7 月 28 日 24:00 前入仓数据 |
| 版本标识 | 这是哪一版假设 | v1，7 月 29 日生成 |
这张表看着朴素，却能挡住很多事后争论。
比如，7 月最后两天的数据还没完全入仓，预测使用的历史销量会偏低；又比如，财务想看确认收入，运营却按支付金额准备促销。两边都叫“销售预测”，会后却各自带走了不同的数字。
还要把模型输入的可用时间写出来。
如果训练历史里使用了“月末最终库存”，而做下月预测时只能拿到“当前可售库存”，这两个字段在名字上相近，时间含义却不同。更糟的是，某些特征只有结果发生后才能确定。把未来信息偷偷带回训练集，离线评估会很好看，真实预测则会像一把纸伞，晴天挺漂亮，下雨就露馅。
第一项复核的结论应该能压缩成一句话：
我们在某个数据截止点，用当时真实可得的信息，预测一个边界明确的业务量。
这句话说不清，后面的模型精度暂时不用急着谈。
