# 零售 AI 落地体检报告 · 交付说明书

>一个可交付、可报价、有名字的产品。
> 定位：不是咨询、不是培训、不是 POC。**是 7 天出结论的诊断报告，结论是「你能做什么、不能做什么、先补哪一格」。**

---

## 一、这个产品解决什么问题

零售企业想上 AI，卡在一个具体问题上：

> **「我们到底能做什么？现在的数据够不够？」**

常见的错误做法是：先买套系统 / 上个模型，跑三个月发现算不出来，原因是某张表某个字段是空的。
**而这个错误本可以在第3 天被一张体检表拦住。**

我的判断依据（全部来自真实项目，可核）：
- 德莉玛 33,178 张历史订单 → 型号 98.6%、厚度 96.9%、尺寸 27.0%、**订单日期只有 2 单有值（0.0%）**
- 一个 `spec` 列被当成「尺寸」用了很久，实际它装的是颜色与配置
- 客户档案有 387 条、订单侧有 302 个客户名，看起来都能用，实际**要先验证两套编码能不能 join**

**所以产品化的理由很简单：这些坑我踩过了，脚本能自动查。**

---

## 二、交付物清单（客户拿到什么）

| # | 交付物 | 格式 | 说明 |
|---|---|---|---|
| 1 | **体检报告（主交付物）** | HTML + PDF，18~25 页 | 5 大节，见下|
| 2 | **原始数据 JSON** | JSON | 每个比例都带分子分母，客户可复核 |
| 3 | **可复现诊断脚本** | `audit.py` | 客户可自己重跑，换库也能跑 |
| 4 | **补数据清单** | Excel/CSV | 缺哪一列、缺多少、补完能解锁哪个能力 |
| 5 | **30 天验证计划建议** | 一页纸 | 建议先做哪1~2 个场景、怎么验收 |

### 报告的5 大节

| 节 | 内容 | 为什么客户要买这一节 |
|---|---|---|
| 一、**数据资产盘点** | 有几张表、多少行、哪张是订单/客户/商品（**自动识别，不认表名**） | 很多客户自己都说不清库里有什么 |
| 二、**字段完整度** | 按业务问题列：时间/金额/数量/客户/商品/手机/地区，每个都给「有值/总数 = %」+ 判定 | **这是客户最缺的** —— 字段存在 ≠ 有数据 |
| 三、**客户跨表关联** | 客户表和订单表能不能 join 上、匹配率多少、用的是哪一列 | **最容易被漏、最致命**。两边都 100% 有值也可能一套都 join 不上 |
| 四、**能力可算性** | 8~10 项能力逐项判「能 / 不能」，每项写清依据与「补什么能做」 | 客户真正要买的是这张表 —— 他要的是「能做什么」不是「有多少数据」 |
| 五、**结论与30 天建议** | 一句总体判断 + 分批建议 | 拿到就能开会 |

---

## 三、7 天排期（每天都有可交付物）

| 天 | 做什么 | 当天产出 |
|---|---|---|
| D0 | 客户给只读库副本 + 一句「现在最想回答什么问题」 | 副本校验通过 |
| D1 | 跑 `audit.py`，出初版结果 | **初版体检报告（当天就给，让客户看到方向）** |
| D2~D3 | 人工核对脚本判定的每一项（**自动结论要人过一遍**） | 修订版 + 疑问清单 |
| D4~D5 | 补数据清单 + 30 天验证计划 | 两份表 |
| D6~D7 | 出终版报告 + 一次 90 分钟汇报会（线上） | 终版报告 + 汇报纪要 |

**我的原则：初版当天给，不藏着。** 客户第1 天就知道「能做什么」，这7 天才有意义。

---

## 四、报价

| 档| 含什么 | 报价 |
|---|---|---|
| **基础版** | 脚本跑批 + 报告 + 补数据清单 | **￥1.5万** |
| **标准版**（推荐） | 基础版 + 人工核对 + 30 天验证计划 + 90 分钟汇报 + 2 周答疑 | **￥3万** |
| **陪跑版** | 标准版 + 30 天内协助补数据 + 第一个场景落地 | **￥6万起** |

**报价口径说明（写进合同的那句话）**：
> 本服务交付的是**诊断报告与建议**，不含系统开发、不含数据治理实施、不承诺「做完就能上AI」。
> 报告结论以体检当日的数据状态为准；客户在报告后新增/修改数据导致结论变化的，不在服务范围内。

**为什么敢这么报**：
- 基础版几乎是纯脚本 + 人工核对，**成本极低**（我实测 19 张表的库跑完只要几秒）
- 标准版定价 3 万，对应客户「先搞清能不能做」的决策价值 —— **省下的是「上完系统才发现数据不够」的三个月**
- 陪跑版 6 万起，是因为要真的动手补数据 / 落地场景，**这部分才是重头**

---

## 五、我明确不做的（写进合同）

这一节比报价单更重要。**说清不做什么，比承诺做什么更能建立信任。**

| 不做 | 为什么 |
|---|---|
| ❌ 不做系统开发 | 诊断归诊断，开发归开发。混在一起会变成无限定工单 |
| ❌ 不承诺「AI 一定能带来多少增长」 | 数据都不可算的时候，任何增长率都是编的 |
| ❌ 不替客户改数据 | 只读原则。生产库的写入权必须留在客户 IT 手里 |
| ❌ 不在体检里夹带培训 | 想学可以另约，但不该塞进诊断里凑时长 |
| ❌ 不给「行业平均值」当benchmark | 零售没有可信的公开均值。拿不出来就不给，不编 |

---

## 六、怎么跑（客户侧操作）

```bash
# 1. 在客户服务器上做只读副本（唯一需要客户配合的动作）
cp /path/to/prod.db /tmp/audit_ro.db

# 2. 跑体检（只读，不连生产库，不写任何东西）
python3 audit.py /tmp/audit_ro.db --json /tmp/audit_result.json

# 3. 出报告
python3 audit.py /tmp/audit_result.json --render --json /tmp/体检报告.md
```

**依赖**：Python 3.9+ 标准库，**零第三方依赖**（不需要装任何东西）。
**输入**：任意一个 SQLite 库。MySQL/PG 版另出一份适配脚本（工作量 1~2 小时）。

---

## 七、这个产品为什么是我能卖而别人不行的

| 别人怎么做 | 我这边|
|---|---|
| 「我们做了 20 个零售 AI 项目」 | 报告里每个数字都能追到库里的哪一列 |
| 现场看一眼表结构就出方案 | **脚本跑一遍，全部完整度现算** |
| 给一份「数字化转型建议书」 | 给一张「8 项能力逐项能不能做」的表|
| 报告里的数字没法复核 | 客户拿 `audit.py` 能自己重跑 |
| 不说自己踩过什么坑 | **报告里直接写「这一项我判错过，原因是…」** |

最后一条是关键：**一份承认自己会犯错的报告，比一份永远正确的报告可信。**

---

## 八、这个产品是怎么长出来的

它不是我拍脑袋设计的，是从 40 篇复盘里长出来的：

| 产品要素 | 来自哪篇复盘 |
|---|---|
| 字段完整度表（时间/金额/数量/客户/商品） | 31 篇 · 定价引擎的四命中率 |
| 「字段存在 ≠ 有数据」这条判断 | 31 篇 · spec 列 97% 是空的 |
| 客户跨表关联检查 | 28 篇 · 302 个客户名的编码问题 |
| 软空值集合（否/无/未知…） | 28 篇 · 把 spec 当尺寸算错的那次 |
| 「缺数据」vs「数据脏」要分开说 | 33 篇 · 方法论到位 ≠ 数据到位 |
| 补数据清单优先于功能建议 | 32 篇 · 先还债再谈迁移 |

**复盘 → 产品，是这些内容唯一能变成收入的方式。** 只写成文章，读者不会付钱。