用ChatGPT预测IT备件库存水平

简而言之： 把十二个月的出库记录连同日期、站点、物料号一起导出，补上供应商实际到货周期和每个物料的关键性分级，然后让ChatGPT运行代码来算再订货点，而不是用文字估一个出来。一个下午就能拿到分站点、站得住脚的再订货点。但它不会对"你还没遇到过的那次故障"发出任何预警。

备件库存是那种人人都靠记忆解决的问题。现场工程师知道分支办公室特别费电源模块；运维经理记得上次槟城有台交换机坏了、换新花了三周。两个人合起来维持着一套管用的心智模型——直到那个人休假、或者资产盘子翻倍、或者财务问起为什么有几百万的东西躺在货架上。

能取代这套心智模型的算术并不难，就是任何一本运营教科书都会讲的标准库存数学。真正卡住团队的是：数据躺在从没有人汇总过的出库导出里，而这套计算要按物料、按站点重复做一遍——这恰恰是那种永远排不进本周优先级的琐碎活。

这是ChatGPT的一个好用途，但有一个关键前提决定了产出到底值不值钱——下面会讲。

备件库存出问题的两种方式

它们的方向相反，这正是直觉处理不好它们的原因。

沉淀的资本。 为一个你已经不再服务的资产盘子买的备件、已经淘汰的型号、或者某个糟糕月份之后恐慌性下的单。它在损益表上看不见，在盘点时一目了然：整架整架十八个月没动过的元件，其中一些原厂已经不再支持了。

你恰好没有的那个件。 一个分支办公室瘫了，替换件在四天快递之外，而你卖出去的SLA是次工作日到场。这是昂贵的那一种失败——不是因为件本身贵，而是因为停机对客户的代价，以及它对你信誉的代价。

团队总会朝着"最近哪一种更疼"的方向过度修正。一次严重缺件，会带来接下来一整年的超量采购；一次盘点核销，会让库存一直吃紧到下一次停机。做这套算术的意义不在于精确本身——而在于让这个钟摆停下来。

该喂给模型什么——以及它到底在算什么

你实际需要哪些数据？

比多数人以为的要少，但形状必须对。

按物料、按站点、带日期的消耗历史。 至少十二个月，因为季节性和站点间差异在更短的窗口里是看不见的。数据源就是你的出库记录——每一次为某张工单或某个任务领用备件。数量和日期要紧，工单正文不要紧。

每个物料的供应商到货周期。 不是目录上的数字，而是你实际观测到的、从下单到件真的躺上货架的时间，如果你在亚洲跨境调件，还要包含清关。这是整件事里最少被记录的一个数字，也是最能改变答案的那个。

每个物料的关键性分级。 两到三级就够。一个坏了会让站点停摆的件，需要的服务水平和一个外观件不同；没有这个分级，模型会把笔记本充电器和核心交换机电源当成同一个问题。

站点上下文。 有哪些站点、每个站点大致多少设备、以及某个站点能否由附近的中心仓在SLA内覆盖。集中存放的件可以覆盖多个站点；要求四小时内到场的件不行。

输入就这些。值得注意的是里面没有：客户名称、工单描述、工程师姓名、价格。把它们去掉——它们增加风险，对计算毫无贡献。

为什么"让ChatGPT给个再订货点"是统计问题，不是提示词技巧

下面这个前提，决定了后面一切的质量。

再订货点等于"到货周期内的平均需求"，加上"按需求波动性和你想守住的服务水平确定的安全库存"。这是算术——而一个被要求用文字估它的语言模型，会产出一个看起来很像样、但并非任何计算结果的数字。它会"大致正确"到足以危险的程度。

解法是让模型去写代码并运行，而不是凭自己的印象作答。把CSV传上去，要求它按物料、按站点计算：到货周期窗口内的平均需求、该需求的标准差、给定服务水平下的安全库存、由此得到的再订货点，以及建议订货量。要求它输出中间数值而不只是结论，并说明它对你的数据做了哪些假设。

由此带来两件事，两件都要紧。你能核对过程——中间列让一个称职的人可以确认这套数学是真的算出来的，而不是叙述出来的。以及你能改一个假设、几秒内重跑，而真正的洞见就在这里：看着目标服务水平从95%移到99%时你的库存金额如何变化，比任何单一的推荐数字都更有用。

模型在算术之外真正体现价值的地方，是围着它的那些杂事：读懂你格式不一的物料描述并把等价件归组、发现某个站点三月份消耗翻了三倍、标出那些历史数据太少、算出来也没有意义的物料。

一个实际例子——十二个月出库数据变成分站点的再订货点

一家MSP用一个中心仓加两个区域中心仓，维护着三个国家、22个站点的硬件。出库导出大约4000行：日期、站点、物料号、数量、工单号。到货周期由采购单独提供一张表，服务经理用一个下午把物料打上三个关键性等级。

第一轮是诊断性的，不是处方性的。 按物料看消耗，会呈现出熟悉的形状：少数物料贡献了大部分动销，而一条长尾里的物料一年只动过一两次。长尾才是有用的发现——对这些物料而言，任何预测都没有意义，决策是一个政策问题（备一件当保险，还是接受那个到货周期），而不是一个计算问题。

再订货点这一轮只覆盖真正在动的物料。 对每一个：它自己到货周期内的平均需求、波动性、按其等级服务水平的安全库存、再订货点、订货量。通常有两个结果会让人意外：动得快的便宜件需要的缓冲比预期少，因为它们的需求很稳定；而个别动得慢的关键件需要的更多，因为长到货周期会把哪怕不大的波动也放大。

分站点看，会改变总量。 把22个站点的需求加总起来，数字看着挺舒服；一拆开，图景就变了，因为集中存放的件满足不了一天路程之外那个站点的四小时SLA。真正重要的产出不是"每个物料一个再订货点"，而是"每个物料放在哪里"的决定——而那个决定取决于你的服务承诺，不是你的消耗数据。

最后用库存金额对比收尾。 当前持有 vs 模型建议持有，按等级看。现实的结果不是一笔戏剧性的节省，而是一次再分配：从被过度缓冲的快动件里抽出资本，投到那几个一直被悄悄覆盖不足的关键件上。

AI辅助预测 vs 库存管理系统 vs 工程师直觉

多快能拿到一个站得住脚的数字 — AI辅助预测胜出。一个下午，对上一次系统实施，而且不需要引入任何新工具。
处理格式不一的物料描述和杂乱导出 — AI辅助预测明显胜出。把"PSU 650W"、"650w电源"和一个物料编码归成同一个物项，正是它擅长的。
解释一个数字为什么是这个数 — AI辅助预测胜出，前提是你让它把过程摊开。直觉没法向CFO解释自己，而多数系统只会显示一个阈值。
知道数据里没有的东西 — 工程师直觉胜出，而且这不是一个小类别：某个站点即将扩张、某个型号快到生命周期终点、某个供应商其实一直不太靠谱。
让库存日常保持准确 — 一套库存管理系统完胜。预测设定的是阈值；系统追踪的是余额与阈值的关系，并在你跨过去时告诉你。
不用靠人记着就能对结论采取行动 — 系统胜出。与库存移动挂钩的自动低库存告警，才是把一个算出来的再订货点变成一张真的下出去的订单的机制。

诚实的建议是把两者结合：用预测来定阈值，然后把这些阈值放进一个持续盯着库存水平的东西里。躺在表格里的再订货点，是一个没人会去看的数字。

预测会在哪里失效

四个地方，而知道它们，几乎就等于会用这套方法了。

没有历史的物料。 新硬件没有消耗记录，算术无从下手。用原厂的故障率指引和它所替代型号的表现来做参考，并把这些数字明确标注为估计值，而不是让它们和算出来的数字并排躺在同一列里。

接近生命周期终点的物料。 一个你正在退役的平台上的物料，需求会下降——但可获得性下降得更快，而"最后一次采购"的决定，是关于退役排期的判断，不是一次预测。

存在一个主导站点。 如果单个大站点贡献了大部分消耗，那么加总的统计量描述的只是那个站点，别的什么都不是。把它单独建模。

一个坏批次。 一次固件缺陷或一批次品会制造出一个需求尖峰，而那不是规律。把它留在历史里，它会抬高之后每一次的推荐值。要求它把离群值识别出来，然后有意识地决定要不要剔除——这是一个判断，而且应该是一个自觉做出的判断。

把这件事做对——运营数据、供应商条款，以及什么时候该让IT介入

三点实务问题。

清楚导出里都有什么。 出库记录通常带着工单号，而工单号可能牵出客户名称、站点地址，偶尔还有最终用户姓名。做预测你只需要日期、物料号、数量和一个站点标识。在文件离开你的环境之前把其余的都剥掉，使用商业版或企业版，并核对该档位当前的数据处理与训练条款，而不是想当然——消费者档位通常不同，条款也会变。

供应商条款是商业敏感信息。 到货周期和起订量隐含着你谈下来的地位。披露它并非灾难，但值得有意识地做决定，而不是看都不看就把采购表贴进去。用一个供应商代码替代供应商名称，你什么也没损失。

预测是小的那一半。 把库存放在对的地方、在中心仓之间调拨、把工程师实际消耗的和领出去的对上、并在告警变成停机之前把单下出去，才是运营上的工作——而这正是我们的AI+支持服务和托管IT支持所承担的。Brocent自2007年在北京创立以来一直在亚洲提供托管IT服务，总部位于新加坡，并自2016年起设有香港办公室。当这件事作为一项托管服务来运行、而不是作为一份你自己反复做的分析时是什么样子，我们在亚洲备件管理与硬件维保那篇里讲过。