从设计到落地——一个预测系统的组织协同与工程实践
这是“天枢系统”系列博客的第五篇，也是最后一篇。前四篇分别讨论了系统设计原则、数据清洗、预测模型和库存计划；这一篇不再讲算法，聊聊系统落地时会遇到的组织、流程和人的问题。 0. 算法不是最难的部分 前四篇把天枢系统的核心逻辑讲完了：数据清洗、物料分层、模型竞赛、库存计划。这些都有标准答案——公式是公开的，算法是成熟的，代码是可以写的。 但系统落地时，卡住项目的往往不是算法。 计划员不信任系
从预测到补货——一个库存计划引擎的设计逻辑
这是“天枢系统”系列博客的第四篇。前三篇分别讨论了系统设计原则、数据清洗和预测模型；这一篇进入预测的下游，聊聊库存计划的核心逻辑：安全库存怎么算、订货点为什么不是拍脑袋、长尾产品的库存策略该怎么定。 0. 预测之后，问题才刚刚开始 预测回答了“未来卖多少”，但库存计划要回答的是另外三个问题： 备多少：除了预测值，还要额外多备多少安全库存？ 何时补货：库存降到什么水平就该下采
9 种模型同台竞技——一个供应链预测系统的模型设计哲学
这是“天枢系统”系列博客的第三篇。前两篇分别从系统设计原则和数据清洗的角度，回答了“数据从哪来、如何变干净”；这一篇进入预测的核心，聊聊为什么需要 9 种模型、它们如何“模拟考试”，以及那个最重要的铁律：一个好预测必须同时满足准确度高和没有系统性偏差。 0. 为什么预测是有用的？ 在进入模型之前，先回答一个更根本的问题：预测到底有什么用？ 答案可以从以下几个层面来理解。 0.1 决策的前提
数据清洗不是技术活——一个供应链预测系统的数据治理实践
这是“天枢系统”系列博客的第二篇。第一篇《我做了一套预测系统，但它还没上线——聊聊数据工作的第一性原理》讨论了系统设计的底层哲学；本篇聚焦数据层，聊一聊数据清洗的本质、方法和实践。 0. 数据清洗的本质：理解业务 很多人把数据清洗看作技术活——写几行 SQL，用统计方法识别异常值，然后删除或替换。 但在日常实践中，我发现数据清洗的本质不是技术，而是理解业务。 为什么？ 因为“异常”的含义
我做了一套预测系统，但它还没上线——聊聊数据工作的第一性原理
李家麒 / 2026年7月我做了一套销售预测与库存计划系统，取名叫“天枢”。它目前还没有上线，代码躺在我的 SQL Server 里，存储过程跑得通，模型竞赛的结果也不错，但离真正接入企业的 ERP、让计划员每周用它来下需求单据（预测单及采购申请单），还有一段路要走。一、为什么做它？ 一个优秀的计划员很难培养出来。计划工作不是简单的“看看上个月卖了多少，这个月大概也卖这么多”，更不是来单了