假设检验这件事，第一步不是算，是把「我猜是这样」写成一句能被数据否掉的话。 PodPhone 的题面看着是「新机好不好卖」， 真正要答的是「哪一周必须开工」——后者才能用手头的数算出来。 手头全部信息只有四条。承认信息只有这么多，是分析的起点，也是不乱下结论的底线。
第 4 章讲怎么把结论讲给别人听。第 5 章换一个场景：结论还没有，只有一堆互相矛盾的说法。 这一章的故事是给 PodPhone 供手机皮肤。 书里用 Excel 算，这里用标准库算，几步加减乘除，数都对得上。
一、题面：赶不上的发布会
PodPhone 要出新机，找上门来买新机型的皮肤。皮肤是贴在机身外面的那层膜，型号不对就贴不上。 这门生意的时间窗口很窄：发布会之前货必须铺到渠道，发布会之后热度一周比一周低。 做晚了，赶上热度尾巴，只能打折清货；做早了，新机推迟，货压在仓库里，一分钱不值。
所以这道题的核心不是「新机好不好卖」，是「哪一周必须开工」。换一个问法，题目就从猜变成了算。
二、手头的全部信息就四条
| 信息 | 内容 | 来源 | 确定性 |
|---|---|---|---|
| 发布日期 | 第 39 周发布 | 泄露的备忘录 | 未确认 |
| 同行分析 | 市场份额 22%，覆盖 8 款机型 | 电肤公司 | 待校验 |
| 销量曲线 | 首周最高，每周衰减约 12% | 上一代机型 | 较可靠 |
| 产能与备货 | 一周 4 万片，首发备货 12 万片 | 工厂、渠道 | 明确 |
四条信息里，只有两条是硬的（产能、备货），一条是别人的估计（备忘录），一条是同行的话（电肤）。 信息的「确定性」这一列，比内容那一列更该先看。拿未确认的日期去做精确计算，算得再准也是空的。
三、把大问题换成小问题
「新机会不会成功」这个问题，四条信息答不了。它需要市场规模、竞品价格、渠道意愿，一样都没有。 「哪一周必须开工」这个问题，四条信息够了：发布日期减去生产周期，再减去铺货周期。 这不是偷懒，是分析里最常见的动作：把答不了的问题换成一个答得了的问题，然后诚实地说清换了什么。
换完之后还要交代一句：这个答案的前提是「第 39 周发布」。前提一变，答案跟着变。
四、倒排工期怎么算
发布周 39，生产周期 6 周，铺货 2 周，所以第 31 周必须开工。今天是第 24 周，还剩 7 周准备。 另一条路是顺推：备货 12 万片，一周 4 万片，生产要 3 周，加铺货 2 周，一共 5 周。 8 周和 5 周之间差 3 周，这 3 周就是缓冲。缓冲不是浪费，是留给「发布推迟」这种事用的。
倒排和顺推都要算一遍：倒排告诉你 deadline，顺推告诉你现实要多久。 两个数差得太多，说明有一头在吹牛。
五、已知信息这四个字要当真
「已知信息」的意思是：你能用的就这些，别的都得标成假设。 很多人在这里翻车，不是因为算错，是因为偷偷用了一条自己没意识到的假设——比如默认「新机会准时发布」。 把假设摆到台面上有个好处：以后结论错了，能查出是哪条假设错了，而不是全盘否定自己。
下一篇要做的事，就是拿这些信息去检验几条互相冲突的说法。 检验的前提，是先把说法写成能判对错的句子。
六、动手 Demo：已知信息：能钉死的只有一个日期
把四条信息摊开，倒排一遍、顺推一遍，看看差在哪儿。 这段代码全部是加减乘除，没有任何统计——这一节的重点本来就不在统计。
WEEK_PUB = 39 # 备忘录写的发布周
LEAD_PROD = 6 # 生产周期（周）
LEAD_SHIP = 2 # 铺货周期（周）
TODAY = 24
CAP, NEED = 4.0, 12.0 # 一周 4 万片，备货 12 万片
must = WEEK_PUB - LEAD_PROD - LEAD_SHIP
print("必须开工：第 %d 周" % must)
print("今天第 %d 周，还剩 %d 周准备" % (TODAY, must - TODAY))
weeks = NEED / CAP
print("备货 12 万片，一周 4 万片，生产要 %.1f 周" % weeks)
print("顺推：开工到上架 %.1f 周" % (weeks + LEAD_SHIP))
print("倒排：一共给 %d 周" % (LEAD_PROD + LEAD_SHIP))
print("缓冲 %.1f 周" % ((LEAD_PROD + LEAD_SHIP) - (weeks + LEAD_SHIP)))
for wk in (39, 41, 43, 45):
print("若第 %d 周发布，则第 %d 周必须开工" % (wk, wk - LEAD_PROD - LEAD_SHIP))
实跑输出：
--------------------------------------------------------------------
已知信息：能钉死的只有一个日期
--------------------------------------------------------------------
① 这道题问的是「什么时候开工」
--------------------------------------------------------------------
PodPhone 要出一款新手机，找上门来买新机型的皮肤。
皮肤这种东西赶不上发布会，就一文不值；做早了堆在仓库，也一文不值。
所以真正要答的问题不是「新机好不好卖」，是「哪一周必须开工」。
② 倒排工期：把不确定的一头钉死
--------------------------------------------------------------------
| 项目 | 周数 | 这条有多确定 |
|---|---|---|
| 备忘录写的发布周 | 第 39 周 | 未确认 |
| 减生产周期 | 6 周 | 工厂给的 |
| 减铺货周期 | 2 周 | 渠道给的 |
| 必须开工的周 | 第 31 周 | 算出来的 |
| 今天 | 第 24 周 | 确定的 |
| 剩下的准备时间 | 7 周 | 算出来的 |
六行里两行是别人给的估计（生产周期、铺货周期），一行是没确认的日期，三行是算出来的。
③ 手头全部信息，一共就这么几条
--------------------------------------------------------------------
① 备忘录：新机计划第 39 周发布（没写「预计」，写的是「发布」）。
② 电肤公司自己的分析：市场份额 22%，覆盖 3 个品牌、8 款机型，同比增长 40%。
③ 上一代机型的销量曲线：发布首周最高，之后每周衰减约 12%。
④ 工厂产能：一周最多 4 万片；渠道要求首发备货不低于 12 万片。
这四条就是全部。没有历史同类项目的完整档案，也没有内部人脉。
④ 产能和备货对得上吗
--------------------------------------------------------------------
备货 12 万片，按一周 4 万片算，光生产就要 3.0 周。
加上铺货 2 周，从开工到上架一共 5.0 周——和倒排出来的 8 周差 3.0 周。
! 多出来的 3.0 周是缓冲。缓冲不是浪费，是给「发布推迟」这种事留的余量。
⑤ 这一节的结论
--------------------------------------------------------------------
手头的信息不够回答「新机会不会成功」，但足够回答「最晚哪周开工」。
分析方法的第一动作，经常是把一个大问题换成一个能用现有信息回答的小问题。
最后那个循环值得记住：发布周每推一周，开工周就跟着推一周，两者是硬绑定。 倒排出的缓冲是 3 周，正好够一次「推迟四周」里的前三周。这就是缓冲的真实用途，不是给拖延留的。
30 秒实验
- 如果工厂产能降到一周 3 万片，缓冲还剩几周？还够不够一次推迟？
- 把「每周衰减 12%」代进去，第 8 周的销量是首周的百分之几？这个数决定了晚一周的代价。
- 想一想：这一篇里哪条信息最不可靠？如果它错了，结论会怎么变？
常见误区
- 拿未确认的日期做精确计算：算到小数点后两位，前提本身却是「听说」。
- 只倒排不顺推：倒排给出 deadline，顺推才知道现实能不能做到，两个都要算。
- 把缓冲当浪费：缓冲是拿来吸收推迟的，砍掉缓冲等于把风险全扛在自己身上。
- 偷偷加假设：默认「会准时发布」却不写出来，结论错了也查不到原因。
自测三问（点开对答案）
1. 为什么把问题从「好不好卖」换成「哪周开工」？ —— 因为后者能用现有四条信息算出来。答不了的问题换成答得了的问题，并诚实交代换了什么。 2. 倒排和顺推分别给什么？ —— 倒排给 deadline（最晚哪周开工），顺推给现实工期。两者之差就是缓冲。 3. 为什么要把「发布周 39」标成未确认？ —— 因为它来自泄露的备忘录。标出来才能在结论出错时追到源头。信息摊开了，接下来是拿它去检验别人的说法。下一篇看电肤交来的那份分析经不经得起加一遍。
- ☐ （本篇完，下一篇 5.2 分析与机密备忘录）