用 Claude 做呆滞账分析：一横一纵，三个数据库放一起让他跑

上篇讲了用 Cloud Code Agent 做呆滞账分析，这篇是番外篇，讲我在这个过程里的收获，以及我具体是怎么做的。以后有机会我再深度展开。

第一步是准备上下文。这个上下文我迭代了好几次，终于找到一个很棒的方式：准备两个板块的数据。

第一个板块是呆滞账。我导出的不是一个时点的呆滞账，而是各个节点的呆滞账，包括这几个半年度：

我们公司用 SAP，各个节点都有很强的数据库，所以这个导出很方便。有了这个，他首先能分析呆滞账的结构，以及呆滞账趋势的对比。我们工厂有三个分工厂，所以三个分工厂之间交叉的呆滞账分析也能做出来。

第二个板块是采购数据，我把 2023 年 1 月 1 号到 2026 年 6 月 30 号整个区间的采购数据都导出来了。

有了采购数据，又有了呆滞数据，就有了一个交叉对比：采购端口和呆滞端口的对比。这个对比有什么用？我可以很清晰地知道，如果这三年半里他没有采购过这个东西，却依然有呆滞，那只证明一件事——这已经成了旧账、老账，甚至是销售人员自己都摸不清楚的账。销售人员可能以为以后还会有货、还会跟这个客户合作，但这是真的还是假的？我觉得是假的，就是呆滞在那里了。换一个业务员可能又不一样。所以我用这种方式，能用数据证据去证明这批货就是呆滞住了。

除了这两个板块，我还会放第三个数据库——SAP 里的 MB51，物料的出入库。我们公司有一个仓库，从 SAP 成立之初到现在的所有出入库都在里面。它有用的点在于：呆滞要产生清理，清理就会留痕，留痕就会有移动代码，而这些移动代码能看出来呆滞账到底是怎么处理的——是一种运动式的集中处理，还是稀释在每个月里处理。这个结论 AI 是真的能分析出来的。这也是一个抓取的点。

所以这种分析其实分多轮，最后他分析出来了。我最想说的是：把这三个庞大的数据库放在一起，让 AI 不断做同比例分析、分工厂分析。这就像我原来的审计体系，一横一纵：

这里再叠一个前提：横只能在有效数据的维度上横，所以最好是通用品。我最近审的都是通用品，但原理一样，一横一纵是个很好的方式。

分析是第一步，而且已经特别快，半天就能分析到位，出来就是一份非常优质的报告。有了分析之后会产生一些异常问题，接下来第二步才是跟现场对接。后面我会再做一个固定资产的分析来分享。大家可以举一反三。

最后说一下结果。第一，我能看出呆滞账的结构、历年的变化趋势，以及各个厂区的处理方式。第二，我能看出每条呆滞背后的原因——是单次采购过量、还是长期积压形成的老账。这次找出了 119 个物料、接近 10 万的库存需要处理。

这两个结果给我很大的信心：这种方式真的有用，真的能梳理出东西来。为什么结果重要？因为我们公司仓库员和计划员一直在跟销售对接，销售一直说这些货能卖出去，导致积压越来越深。销售员有时候其实更谨慎，但仓库员想要让仓库清爽，两边的思路本来就不一样。这份报表的意义就在于，用扎实的数据跟所有人说：这批货，该清理了。