# AI-native ADS 层设计 · 推倒重来 vs 渐进治理的范式判断

> **来源**：2026-05-22 跑「会员经营任务池 OS」SuperApp demo（见 Part E）后，用户的根判断：「光数据治理没用，必须按适配 AI 的方式数据架构重搭一遍，要是在历史业务积累上做东西，估计全是阻碍」。这条心得不是 demo 期间凑出来的策略，是反复对照"新建底表一路畅通"和"历史宽表寸步难行"两种状态后蒸馏出来的范式判断。
>
> **何时读这里**：客户说"想给现有 BI 接 AI / 上 LLM / 做 AI 副驾" / "我们 ETL 治理做了一年还没出活" / "数据资产丰富但模型用不起来" / 评估"是该治理还是该重搭" / 跟客户做 BI 项目预算分配讨论。**这是 majia-guanyuan 哲学层文档，不是操作手册**——决定走哪条路，操作手册看 Part A-E。

---

## §1 现象层：demo 一路畅通 vs 历史包袱寸步难行

跑完 Part E SuperApp demo 后回头看 `ads_会员经营任务池`（32 字段），每个字段的设计本身就是 AI-native 的：

| 字段 | 设计选择 | LLM 视角的友好度 |
|------|----------|-----------------|
| `推荐动作` / `推荐权益` / `推荐原因` | **推荐结果预计算 + 落字符串** | 直接当 prompt 输入，不用临时拼 |
| `会员等级` / `人群标签` / `角色标签` | **低基数中文枚举** | LLM 一眼看懂"沉睡 / 流失 / 活跃" |
| `任务优先级` | **P0/P1/P2 标准化标签** | 优先级是推理输入，不用映射 |
| `任务生成时间` / `截止时间` / `失效时间` | **TIMESTAMP 标准格式** | LLM 自己脑补"今晚下班前""周末" |
| `门店名称` | **城市 + 地标 + 编号拼成完整字符串** | LLM 自动用"0783 店小张"做角色扮演 |
| `推荐权益 = "满 30 减 10"` | **直接落业务可读文案** | 短信"明天午饭前下单刚好" |

LLM 能输出「我是 0783 店小张，上回您点的那单还记得吧」不是 claude-opus-4-6 多神，是**这张表把它能做角色扮演的信号全部铺好了**。

### §1.1 反过来：历史业务积累的宽表会长什么样

设想同样要做这个工作台，但底表是 10 年餐饮 ERP 沉淀的：

| AI-native 版（demo 实际） | 传统业务积累版（典型客户现状） |
|----|----|
| `推荐动作 = "电话回访+召回券"` | `proc_act_type_v3 = 'P_CB_VCH'`（要查 dim_action_type 码表） |
| `人群标签 = "沉睡"` | `seg_id = 7`（要 LEFT JOIN dim_segment 取 seg_name） |
| `门店名称 = "上海CBD0769店"` | `store_code = 'S00769'`（要 JOIN dim_store 拼 `city + addr + store_no`） |
| `推荐权益 = "满30减10"` | `coupon_rule_json = '{"rule_type":3,"thresh":30,"discount":10}'`（LLM 还得 JSON.parse 业务规则） |
| 一张宽表 32 列 | 一个 view JOIN 11 张表，每张表都带历史 V2/V3 后缀 |

把这种 schema 喂给 LLM 写"老熟客闲聊"语气的话术？它根本看不懂 `P_CB_VCH` 是啥意思，看不懂 `seg_id=7` 对应什么人群，更看不懂 `rule_type=3` 是哪种营销规则。**所以不管 LLM 多强，输出都是空中楼阁。**

---

## §2 本质层：两种 schema 假设的根本差异

| 维度 | 传统 BI schema 假设 | AI-native ADS schema 假设 |
|------|---------------------|--------------------------|
| 消费者 | **人 + SQL** | **LLM + 人** |
| 字段命名 | 业务系统打孔保留原名 / V2/V3 后缀堆叠 | 语义自描述（中文 + 业务可读） |
| 维度取值 | enum code + ID 引用（节省空间） | 中文枚举落库（节省 LLM token + 跨字段对账） |
| 复合语义 | 拆字段 + JOIN 还原 | 直接拼好落库 |
| 推荐 / 标签字段 | 现场算 / 现场 JOIN 维表 | ETL 提前算好落库 |
| 时间字段 | epoch / yyyymmdd 数字 / 各种字符串格式并存 | 统一 `TIMESTAMP YYYY-MM-DD HH:mm:ss` |
| 优先级 / 排序 | 数字 1/2/3 + 注释含义 | 强约束取值（P0/P1/P2 / high/mid/low） |
| 行级权限 | 推断（按 user 关联多表 JOIN） | 字段冗余进表（门店 ID / 加盟商 ID 直接落 ADS） |
| 主要服务 | 月报 / 上下钻 / 交叉表 | LLM prompt / AI 应用 / 写回操作 |

**核心差异是消费者**。传统 BI 默认消费者是「写 SQL 的人」——他可以查码表、可以 JOIN、可以 parse JSON、可以现场拼字段；AI-native ADS 默认消费者是「LLM + 业务方」——LLM 的"现场计算能力"远不如 SQL 引擎，**所有该问的、能猜的、要算的东西都要提前 ETL 进去**，把 LLM 的思考留给"怎么说话给人听"那一段。

---

## §3 推倒重来 ≠ 重做 ODS / DWD

值得讲清楚的是：**不需要动 ODS / DWD**。需要重搭的是 ADS 层和它的字段命名 + 取值约束。

| 层 | 是否动 | 原因 |
|----|---|----|
| 业务系统 | 不动 | 一线该咋写还咋写，业务流程零干扰 |
| ODS / 缓冲层 | 不动 | 原始打孔合规 / 审计 / 数据血缘的源头 |
| DIM / 维度层 | **不动** | 维表本身的码值映射是企业级标准 |
| DWD / 明细汇总层 | **不动** | 已经做了清洗、维表打平、口径统一（按 Part D `restaurant-bi-formulas/08-etl-engineering-patterns.md` 的"10-CTE DWD 宽表底座"那套） |
| **ADS / 应用层** | **整层重建** | 这才是给 LLM + SuperApp + AI 副驾直接消费的层 |

这跟 [`restaurant-bi-formulas/08-etl-engineering-patterns.md`](https://github.com/maojiebc/majia-huiyuan/blob/main/公式库/08-etl-engineering-patterns.md) 的「10-CTE DWD 宽表底座 + 轻节点重 SQL 哲学」是**兼容互补**的——DWD 还是按宽表底座那套（财务双源对账 / POS 归一化 / 会员生命周期多输出 / Cohort 日期×门店网格都不动），**新建的是 DWD 之上、一对一面向某个 AI 应用场景的 AI-ready ADS 表**。

一个客户可能有 1 张 DWD 主宽表 + N 张 AI-native ADS（每个 AI 应用一张）：

```
dwd_会员主宽表（500 字段，覆盖全业务口径）
    ├── ads_会员经营任务池（32 字段，给"任务池 SuperApp"用，AI-native）
    ├── ads_会员私域驾驶舱（28 字段，给"会员副驾"用，AI-native）
    ├── ads_体验风险专题（22 字段，给"风险预警副驾"用，AI-native）
    └── ads_加盟商单店报告（45 字段，给"加盟商 PWA"用，AI-native）
```

每张 ADS 表是**一对一面向具体 AI 应用场景**设计的——这是和传统"通用宽表"最大的区别。

---

## §4 AI-native ADS 七条字段约束

蒸馏自 `ads_会员经营任务池` 实战，每条都有具体的 LLM 友好性原因：

### §4.1 维度全用中文枚举值

```
✗ 传统:        seg_id INT (1=活跃, 2=流失, 3=沉睡, ...)
✓ AI-native:   人群标签 STRING ("活跃" / "流失" / "沉睡")
```

**Why**：LLM 看 `seg_id=7` 不知道含义，看 `"沉睡"` 直接懂业务语境。**别担心 STRING 比 INT 慢** —— ADS 表本来就是 N 张小宽表，每张 < 100 万行，全表扫描照样秒级。

### §4.2 推荐 / 标签字段提前 ETL 算好

```
✗ 传统:        现场算 RFM 评分 / 现场 JOIN 推荐引擎
✓ AI-native:   推荐动作 STRING / 推荐权益 STRING / 推荐原因 STRING
```

**Why**：LLM 不擅长"先看数据再决定推荐什么"，但**非常擅长"基于推荐结果写话术"**。把 RFM / 推荐引擎跑完，把结果作为字符串字段落到 ADS 表里，LLM 接到这个就能写话术。

### §4.3 复合语义直接拼好

```
✗ 传统:        门店编号 + 维表 JOIN 拼名字
✓ AI-native:   门店名称 = "城市 + 地标 + 编号" 直接落库（"上海CBD0769店"）
```

**Why**：LLM 看到"上海CBD0769店"自动能拆出"我是 0769 店小张""上海 CBD 店"等多种角色扮演方式；看到 `store_code='S00769'` 则啥也做不了。

### §4.4 时间字段统一 `TIMESTAMP YYYY-MM-DD HH:mm:ss`

```
✗ 传统:        混合 (epoch / yyyymmdd / "2026/05/22" / "22-May-26")
✓ AI-native:   全部 TIMESTAMP "2026-05-22 14:30:00"
```

**Why**：LLM 看标准 TIMESTAMP 能脑补出"今晚下班前""周末""明天午饭前"这种自然时间锚点；epoch 数字它需要心算还容易错。

### §4.5 优先级 / 排序字段强约束取值

```
✗ 传统:        priority_level INT (1/2/3) + 注释含义
✓ AI-native:   任务优先级 STRING ("P0" / "P1" / "P2" / "P3")
```

**Why**：业务方和 LLM 都能直接读 P0 = 紧急；1/2/3 谁是高优都说不清。

### §4.6 数值字段提前算好

```
✗ 传统:        现场算 ROI / 净利率 / 折扣率
✓ AI-native:   预计价值 DOUBLE (已算好) / 折扣率 DOUBLE (已算好)
```

**Why**：LLM 算复杂业务计算容易错（特别是涉及多张表 JOIN 的），ETL 跑准确算法 + 落数值字段是 100% 准的。

### §4.7 行级权限字段冗余进表

```
✗ 传统:        靠 user_id → ... 多张关系表推断当前用户能看哪些行
✓ AI-native:   归属门店ID / 加盟商ID / 区域ID 全部冗余进 ADS 表
```

**Why**：SuperApp 拉数据时直接按权限字段过滤，LLM prompt 也不用拼复杂权限判断。冗余存储换的是简化推理。

---

## §5 完整命名公约模板

实际 ETL 写完，ADS 表的字段长这样（节选自 ads_会员经营任务池）：

```sql
-- ads_会员经营任务池 字段示例
任务ID            STRING       -- "T00012345"
任务优先级        STRING       -- "P0" / "P1" / "P2"
任务类型          STRING       -- "沉睡召回" / "流失预警" / "首单后二单" / "高价值维护"
任务来源          STRING       -- "规则生成" / "AI 推荐" / "手动指派"
会员ID            STRING       -- "M0064858"
会员等级          STRING       -- "普卡" / "银卡" / "金卡" / "黑卡"
会员城市          STRING       -- "上海" / "北京" / "深圳" ...
人群标签          STRING       -- "活跃" / "流失" / "沉睡" / "高价值"
门店名称          STRING       -- "上海CBD0769店"（城市+地标+编号拼好）
店型              STRING       -- "旗舰店" / "快取店" / "外卖店"
推荐动作          STRING       -- "电话回访+召回券" / "发二单券+推荐爆款"
推荐权益          STRING       -- "满30减10" / "沉睡唤醒 9 折"
推荐原因          STRING       -- "消费间隔接近流失阈值"
预计价值          DOUBLE       -- 84.5（提前算好，LLM 不算）
任务生成时间      TIMESTAMP    -- "2026-05-22 09:33:00"
任务截止时间      TIMESTAMP    -- "2026-05-26 09:33:00"
触达状态          STRING       -- "未触达" / "已触达" / "触达失败"
触达方式          STRING       -- "企微1V1" / "电话" / "短信"
转化阶段          STRING       -- "未触达" / "已触达未转化" / "已转化"
```

**核心特征**：
- 全部中文字段名（不需要 i18n，LLM 中文输出本来就强）
- 全部字符串枚举值（除了金额 / 时间）
- 复合字段提前拼好
- 时间字段统一格式
- 推荐字段是 ETL 算法的输出，不是 ADS 表的输入

---

## §6 客户视角的预算分配建议

### §6.1 旧叙事 vs 新叙事

| 旧叙事（渐进治理） | 新叙事（AI-native 重搭 ADS） |
|------|------|
| "我们 ETL 太多了，先做治理" | "我们要给业务方做 AI 副驾，先重搭 ADS" |
| 12 个月项目周期 | 3 个月项目周期 |
| 产出：删 30% 冗余 ETL / 修 50 个对账差异 / 字段命名规范文档 | 产出：3-5 个 AI 应用上线 / 业务方直接用 / ROI 可量化 |
| 高层视角："看不出价值变化" | 高层视角："业务方在用 AI 副驾发券，单量涨 8%" |
| 治理预算 100 万 | 重搭 ADS 50 万 + AI 应用 50 万（同样预算） |

### §6.2 推荐预算分配（同样 100 万）

```
旧分配:  治理 100% (100 万) → 价值产出: 删冗余 + 改命名 = 内部 PR 友好,业务无感知
新分配:
   - 治理 30% (30 万)  → 必要的脏数据清理 + 关键对账
   - 重搭 ADS 30% (30 万)  → 3-5 张 AI-native ADS 表
   - AI 应用 40% (40 万)   → 3-5 个 SuperApp(任务池 / 副驾 / PWA)
   → 价值产出: 业务方天天在用,可量化 ROI
```

**关键判断**：**治理预算的一半挪去重搭 ADS + 上 AI 应用，产出比直接治理高一个数量级**——治理只清"脏数据"，重搭才换"schema 假设"。

---

## §7 与 majia-guanyuan 既有 Part 的关系

| Part | 关系 |
|------|------|
| **Part A 数据查询与卡片创建** | 跟 AI-native ADS 正交——不管 ADS 是什么形态都能查 |
| **Part B ETL 治理与写入** | **正交补充**：Part B 是 ETL 操作手册（怎么写 / 怎么治），本文是 **要不要治 vs 要不要重搭** 的判断 |
| **Part B-17 全链路重写方法论** | **同源**：B-17 是"把一条 SmartETL 链改写成 SQL 版"，本文是"为什么要重搭一整层 ADS"——后者是前者的战略升级版 |
| **Part C 自定义图表 / Part C-12 HTML 看板** | 互补——AI-native ADS 让 Part C 的图表参数（颜色 / 标签 / 推荐文案）也可以直接读 ADS 字段 |
| **Part D V7 Page/Card 发布流水线** | 正交 |
| **Part E SuperApp 开放应用** | **强依赖**：SuperApp 能跑顺的前提是 ADS 是 AI-native。本文是 Part E 的"前置假设"——读完 Part E 再回来读本文最有体感 |
| **restaurant-bi-formulas（餐饮 BI 公式实战库，已迁至 [majia-huiyuan](https://github.com/maojiebc/majia-huiyuan)）** | **兼容**：餐饮库的"10-CTE DWD 宽表底座"作为 DWD 层不动；本文新建的是 DWD 之上的 ADS 层 |

---

## §8 反模式 · 不要做这些

| 反模式 | 为什么不行 | 替代 |
|--------|-----------|------|
| 把 enum code 落 ADS 表（如 `seg_id=7`） | LLM 看不懂码值 | 中文枚举落库（`人群标签="沉睡"`） |
| ADS 表设计成"通用宽表"覆盖所有场景 | 字段语义打架 / LLM token 浪费 | 一对一面向 AI 应用场景，每个应用一张 ADS |
| 时间字段保留 epoch / 8 位数字格式 | LLM 心算容易错 | 统一 `TIMESTAMP YYYY-MM-DD HH:mm:ss` |
| 推荐字段让 LLM 现场算（"你看下这个会员的 RFM..."） | LLM 算业务逻辑不稳 | ETL 算法跑完 + 字符串字段落库 |
| 行级权限靠 JOIN 推断 | SuperApp / LLM 拼权限判断超复杂 | 权限字段冗余进 ADS 表 |
| 跳过 DWD 直接从 ODS 建 ADS | 错过维表打平 / 口径统一 / 双源对账 | 走 DWD → ADS 两步 |
| 把"治理预算"全部砸在 ETL 治理上 | 治理只清脏数据，不换 schema 假设 | 治理 30% + 重搭 ADS 30% + AI 应用 40% |
| **把 SuperApp 当目标，跳过 ADS 重搭** | 历史宽表喂给 LLM 出不来好结果，demo 永远做不通 | **先重搭 ADS 再做 SuperApp** |

---

## §9 何时回到这份文档

| 触发场景 | 跳到 |
|----------|------|
| 客户问"我们 ETL 治理做了一年还没出活" | §6 预算分配 + 全文核心叙事 |
| 客户问"我们底表 schema 看起来不太适合 LLM" | §4 七条字段约束 |
| 评估"是治理还是重搭" | §3 ADS 层重建 + §2 schema 假设差异 |
| 客户问"重搭 ADS 不会破坏现有报表吧" | §3 强调 ODS/DIM/DWD 不动 |
| Part E SuperApp demo 跑得不顺 | §1 反过来看 ADS 是不是 AI-native |
| 跟客户提案怎么写"AI-native 数据底座" | §5 完整命名公约模板 + §6 预算分配 |
