告别古法 SQL 分析：把时间还给分析本身

做供应链分析的人，时间都去哪了？我认真盘过自己典型的一天：老板早上问”上周各仓的缺货率怎么变了”，我知道答案在哪几张表里，但把这几张表 join 起来、对上口径、跑出来、核对完，两个小时没了。真正看数字、想原因、给建议的时间，二十分钟。

我管前面那两个小时叫”古法 SQL”：表名靠背，口径靠问，代码靠复制上次的，结果对不对全靠人品。这个系列前面十二篇讲的全是分析方法，这一篇讲讲让这些方法真正跑得动的地基。方法再漂亮，一天只有两个小时的分析预算，什么都白搭。

效率的真相：瓶颈不在写 SQL，在”想起来”

很多人对分析效率的理解停留在”SQL 写得快不快”。我自己的时间账盘下来，写 SQL 本身只占小头，大头在三件事：想明白该用哪张表（问三个人、翻五个聊天记录）、回忆这个指标的口径（WMAPE 的分母到底含不含缺货日）、核对结果对不对（跑完和上周的对不上，再花一小时发现是分区字段用错了）。

三件事的共同点是：它们不是计算问题，是记忆问题。而记忆恰恰是系统该干、人不该干的活。

我们的解法：四件套知识库

解法土得掉渣，就是写文档。但按一个特定的结构写，写成四份各司其职的活文档：

表概览回答”做某个场景要用哪些表”。准确率测算要用预测表、出库表、商品维表、仓店关系表，一页映射表，不用问人。

DDL 手册回答”这张表怎么用”。字段、分区、取数要点、和谁 join 要注意什么，每张表一节，新表来了就追加。

指标口径回答”这个数到底怎么算”。WMAPE、偏差率、有效缺货率、箱转件，每个口径写清公式、边界和 NULL 处理。口径只在这里定义，全团队引用同一个版本。

场景模板回答”这类分析一般怎么做”。不是给 SQL（每个公司数仓不同，SQL 抄不走），是给结构：取什么数、按什么粒度、注意哪些坑。

四件套旁边配了一条铁律：唯一权威来源，禁止另存副本。 以前每个方向文件夹里都躺着一份”表结构参考”，三个月之后五份文档五个版本，谁都不知道哪份对。知识腐烂的速度比积累快，副本是腐烂的加速器。现在所有方向共享一套，改了立刻全局生效。

AI 进来之后，四件套变成了杠杆

知识库本来是写给人看的，大模型来了之后，它的角色变了：它是给 AI 的上下文。

现在我的取数流程是这样的：把问题、相关那几节知识库、输出要求一起扔给 AI，它按 DDL 手册里的表结构、按口径文档里的定义生成取数逻辑，我审一遍再跑。表记不记得、口径对不对、分区用没用错，这三个原来的时间黑洞，全部被知识库+AI 接住了。省下来的时间干什么？干系列前十二篇写的那些事：看数字、想结构、做实验设计。

这里有个经验想单独说：AI 取数最大的问题不是不会写，是口径漂移。 你不给它约束，它会”自由发挥”出一个看起来合理、实际口径不对的算法，而且错得理直气壮。知识库四件套的真正作用，是把 AI 的自由度限制在正确的范围内，这其实就是第 02 篇那句”锚点是约束不是目标”在数据工作里的翻版。同一个道理，管预测管用，管 AI 也管用。

现在行业里管这个叫上下文工程，概念很热，做法就是这么朴素：把组织的隐性知识变成结构化的、唯一权威的、AI 可读的文档。text-to-SQL 工具满大街都是，但没有知识库托底的 text-to-SQL，只是更快地制造错误答案。

一个诚实的边界

这套东西不是银弹。知识库的维护本身是成本，我们的约定是谁用出新表新口径谁负责回写，写不进去的领域知识（比如”这个仓的数据每周三都有问题”这种土经验）依然存在于老员工的脑子里。AI 也没有让分析本身变容易，判断”这个问题值不值得挖、结论敢不敢信”，仍然全是人的活。

但它改变了一件事的分配：以前分析能力是”会不会写 SQL”筛选出来的，现在这个门槛塌了，真正的分水岭变成了”会不会问问题、信不信数字”。我一直认为这才是分析师这个岗位本来该有的样子。

这个系列从预测写到库存，从仿真写到归因，最后落到这篇地基。所有方法的尽头，是让做分析的人把时间花在分析上。

附录：知识库四件套与 AI 取数规约速查表

四件套结构

AI 取数三段式输入：① 业务问题；② 知识库相关章节（场景映射 + DDL 节 + 口径节）；③ 输出要求（粒度、时间窗、空值处理）。

人工审核点（AI 最容易错的四处）：分区字段是否和 FROM 表一致；单位换算（箱转件）方向与 NULL/0 保护；编码映射（老仓改码）是否应用；口径是否自由发挥。

时间账（改造前后对比，DEMO 量级）

供应链实战系列 · 第 13 篇 · 卷六「效率篇」｜ 上篇：不同商品角色不同命 ｜ 全系列正文完