FRAMEWORK · 一个框架
库存诊断产品
一个框架，三种产出
这套产品要解决一件事：库存为什么说不清高在哪。
视频是切片，公众号是串联，报告是交付。这一页不是愿景，是能落地的产品蓝图。
所有模块可独立运行，也可链式串联。数据源是真实电商流水（UCI Online Retail，54 万行），
交付格式是麦肯锡风格 A4 报告（六页一页一结论）。
五段流水线：从一张底表到三个动作建议。
每个模块可独立复用，也可链式串联。模块间用标准 Excel/CSV 接口对接。
1
底表（SKU 级原始数据）
SKU 编码 · 商品名 · 月销 · 30 天销 · 未动销天数 · 销售额。来自 ERP 或 WMS 导出。
INPUT
↓
2
规则引擎（Python run_rules.py）
七条规则：缺货风险 / 死货 / 主力款 / 长尾 / 干净 / 打架 / 人工。一条 SKU 可入多张清单。
CORE
↓
3
四张清单（Excel 分类落盘）
缺货风险 / 死货 / 主力款 / 长尾。去重总数 = 有问题 SKU，干净总数 = 正常 SKU。
OUTPUT
↓
4
诊断报告（六页 A4）
封面 → 执行摘要（三句话）→ 总账 KPI → 问题清单 → 动作建议 → 假设边界。
DELIVER
↓
5
动作建议（谁做·多久·验收）
清死货 30 天 / 改备货天数 45 天 / 统一两套数下季度。每条可验证可追责。
ACTION
依赖关系：模块 1 → 2 是数据清洗，2 → 3 是规则分类，3 → 4 是报告生成，4 → 5 是动作建议。
规则打架是第 3 个模块的异常分支：SKU 同时入"死货"和"主力款"——就是最该有人拍板的地方。
每个模块的输入 / 输出 / 交付格式，一眼看清。
不写抽象概念，每个模块都有明确的文件格式、数字规模、下游消费者。
模块
输入
输出
数字规模（3000 SKU 示例）
① 底表
ERP / WMS 导出
sku_table.csv / .xlsx
3000 行 · 10 列 · 54 万流水聚合
② 规则引擎
sku_table.csv
七类分类结果 + numbers.json
缺货 1248 · 死货 366 · 主力 901 · 长尾 1501 · 去重 2662 · 干净 338 · 打架 34 · 人工 7
③ 四张清单
run_rules.py 结果
lists.xlsx（四张清单 sheet + 规则打架 sheet）
缺货 1246 行 · 死货 354 行 · 主力 900 行 · 长尾 1500 行
④ 诊断报告
run_rules.py + 汇总数字
diagnostics.html（六页 A4）
TOTAL 297 万 · DEAD 83 万(28%) · TOP5 51.2%
⑤ 动作建议
诊断结论 + 行业对标
报告第 5 页 + 执行清单
3 个动作 · 清死货 30 天 / 改备货 45 天 / 统一口径下季度
核心观察：模块 ② 规则引擎的输出（numbers.json）是模块 ④ 诊断报告的唯一数字来源。
报告里写的每一个数字（297 万、83 万、28%、51.2%）都能追溯到 run_rules.py 的实算结果。
客户拿到的不是一堆文件，是四层交付。
老板看执行摘要、执行层看完整清单、数据团队看底表、管理层看六页报告。各取所需。
六页诊断报告（A4）
HTML · PDF 可导出 · 麦肯锡风格
核心
一页一个结论、一页一个动作。封面 → 执行摘要 → 总账 KPI → 问题清单 → 动作建议 → 假设边界。老板看完这一页就能拍板。
四张清单（SKU 级）
Excel · 原始数据级
执行层
缺货风险 1246 行 / 死货 354 行 / 主力款 900 行 / 长尾 1500 行。给执行层逐个 SKU 去清、去备、去下架。
规则打架清单
Excel · 34 行（3000 SKU 示例）
执行层
同一个 SKU 同时入"死货"和"主力款"——这就是最该有人拍板的地方。不需要 100% 自动化，需要人看。
基础能力
销量 / 可售 / 在途的定义、ERP 和 WMS 两套数的差异点、谁是最终责任人。签字后作为后续口径统一的依据。
对外输出
把六页报告讲成 121 秒的口播视频 + 完整文稿。适合分享给老板、转发给公众号、作为公开演示。
什么时候用这套产品？三种典型场景。
不是所有公司都需要，判断标准只有一个：老板能不能在执行摘要那一页看到自己的问题。
场景 ① · 库存压不住了，老板要个说法
季度末盘点前，老板突然问"为什么账上躺着这么多钱"。你拿出一份脱敏样例，三句话说清楚：钱压在哪、浪费在哪、先动哪。
→ 适合：季度 / 年度复盘、董事会前的库存盘点
场景 ② · ERP 和 WMS 两套数对不上，拍板不了
采购说要备 3000 万，计划员算出 1800 万，销售拍板 2500 万。规则引擎把 13 个差 > 30% 的 SKU 列出来，老板一看就知道问题在口径。
→ 适合：两套系统并存、部门数据打架、备货决策卡住时
场景 ③ · 想做内容输出，但不知道讲什么
34 个规则打架的 SKU 就是 34 集短视频素材。每一条都可以讲一个"为什么 AI 分不出来、需要人拍板"的真实故事。
→ 适合：自媒体 / 公众号 / 案例拆解内容生产
不适合的场景
① 只有几十个 SKU 的小公司（不需要规则引擎，人手动分就行）
② 没有 ERP/WMS 系统（底表数据都没有）
③ 老板不接受"假设与边界"（只想听完美答案）
→ 这三类公司，不要硬套，直接放弃
两种看法，一个产品。
产品是一条流水线，报告是这条流水线的最终交付物。你可以只看报告（最直观），也可以看产品架构（最底层）。
PRODUCT · 底层架构
产品架构 · 设计思路
五段流水线、模块拆解、数据流、交付物清单、适用场景。适合想深入了解这套产品怎么搭起来的人。
→ 返回产品板块