11月4日凌晨，北京、上海、杭州、南京、青岛、郑州、合肥、长沙等地的iPhone用户打开自带天气，看到11月13日一栏写着：最低-32℃，最高仍有18℃至23℃。一天温差接近50℃，个别城市更大。中国天气的回应很干脆：“最低气温-32℃？都散了散了~根本没有这样的温差”。界面新闻中国天气
几小时后，数据恢复。苹果客服给中新经纬的解释是“系统端口问题”，不是硬件故障；并否认了“定位跳到别的城市”的猜测——如果定位错了，前后几天的数据都该错，不会只错某一天。中新经纬
把各地截图放在一起，症状高度一致：错的不是整份预报，而是同一天、同一栏——最低气温。最高温仍是十几二十度，前后几天也正常。广东部分城市甚至跳出-30℃到-40℃的极端低温。共同点却一样：只有最低温这一栏离谱。这不是天气，是一个字段。广州日报
一种常见的实现方式是：日最低温由当天逐小时预报取最小值得到。24个数里混进一个坏值，取最小值的结果就会被它带偏，而取最大值几乎不受影响——这正好解释了“最低-32℃、最高22℃”这种自相矛盾的组合。坏值从哪来？上游用来标记“缺测”的特殊值没被过滤、网格或日期索引错位、一份坏数据进了缓存，都有可能。苹果没有公布根因，外部无法确认是哪一种。
但无论哪一种，问题都不在“苹果算错了天气”，而在“一个明显的错数，一路无人拦截”。苹果的预报模型，融合的是各国官方气象机构的原始观测数据。它负责融合、插值和分发，不负责在每个城市架设气象站。链条越长，接缝越多；每个环节只对自己的那段负责，错误却能顺着接口自动传到用户眼前。界面新闻
自动化让错误跑得更快。气象部门发布预报要经过审核和签发，天气App不用，数据到点就渲染。加几道校验——“最低温不能高于最高温”“北京11月不可能-32℃”“和前后两天差太多就报警”——成本很低。可校验的价值，恰恰在于它不出事的时候看不见，于是最容易在排期里让位给新功能。
考核指标也看不见这类错误。系统状态页能记录“服务中断”，却记录不了“数字是错的”。4月28日那次瘫痪持续了约3小时45分钟，有明确的起止时间。6月临安逼近50℃，则只能靠用户截图和气象局辟谣来发现。一个是可用性事故，一个是准确性事故。前者有明确的修复优先级，后者往往等上了热搜才被看见。界面新闻成都网络辟谣
于是就有了今年公开报道里的三次：4月服务瘫痪、6月高温误报、11月低温误报。症状不同，病根相同——一条层层转接、全自动、缺少最后一道常识校验的数据流水线；再加上每次都以“已修复、深表歉意”收尾，没有一份公开的根因报告。不写复盘的事故，几乎注定换个形式再来。
还有一层，是产品自己制造的错觉。10天预报越往后越不可靠，App却把它压成一个和明天一样笃定的数字。数字越精确，越容易被当真；越容易被当真，一个离谱的数字就越像末日预警。这次全网玩“重生囤物资”的梗，好笑，但也说明它真的唬住了不少人。
所以，-32℃不可怕，它已经被修好了。可怕的是修它的方式：改掉一个值，清掉一份缓存，等下一次换个方向再来。要让它不再反复，先得承认这条链需要一道真正的门，而不是每次都在门后道歉。
