freedakgmail
203 lines
7.2 KiB
Markdown
203 lines
7.2 KiB
Markdown
# 05 · 步骤四：AI协同模型设计与逻辑闭环验证
|
||
|
||
> 目标：在写代码前，用AI验证从战略指标到数据执行的全链路逻辑完整性，发现并修复断点。 `[Echo+Delta]`
|
||
>
|
||
> FDE角色：这是"先想清楚再动手"的关键步骤。Echo层定义业务逻辑闭环，Delta层用AI验证技术可行性。逻辑断点在这一步修复，成本远低于编码后返工。
|
||
|
||
## 1. 模型设计框架
|
||
|
||
### 1.1 三层模型映射
|
||
|
||
```
|
||
指挥层模型（战略→指标）
|
||
战略目标 → 核心指标 → 展示形式 → 预警规则
|
||
↓
|
||
本体层模型（数据→指标）
|
||
原始表 → 物化视图 → API字段 → 前端变量
|
||
↓
|
||
执行层模型（指标→任务→闭环）
|
||
指标偏差 → 预警触发 → 任务生成 → 执行反馈 → 效果检验
|
||
```
|
||
|
||
### 1.2 AI协同设计流程
|
||
|
||
```
|
||
1. 输入：指标体系 + 数据现状 + 岗位矩阵
|
||
2. AI生成：完整的数据模型设计草案
|
||
- 每个指标的计算公式
|
||
- 数据源映射
|
||
- 物化视图设计
|
||
- API设计
|
||
- 预警规则
|
||
- 任务模板
|
||
3. 人工审查：业务逻辑是否正确
|
||
4. AI验证：逻辑闭环是否完整
|
||
5. 输出：可执行的技术方案
|
||
```
|
||
|
||
## 2. 指标计算模型
|
||
|
||
### 2.1 核心指标公式
|
||
|
||
| 指标 | 公式 | 数据源 | 注意事项 |
|
||
|------|------|--------|---------|
|
||
| 营业收入 | `sum(consumption)` | bill_fact.consumption | — |
|
||
| 优惠 | `sum(discount_total)` | bill_fact.discount_total | — |
|
||
| 实收 | `sum(received_total)` | bill_fact.received_total | — |
|
||
| 客单价 | `sum(received) / sum(bill_count)` | bill_fact | 注意：不是avg(received_total) |
|
||
| 优惠率 | `avg(discount_total / consumption * 100)` | bill_fact | 逐单计算再平均 |
|
||
| 理论毛利率 | `sum(theoretical_profit) / sum(received) * 100` | bill_fact | — |
|
||
| 会员占比 | `sum(received) FILTER(member_id非空) / sum(received) * 100` | bill_fact | — |
|
||
| 食材成本率 | `sum(actual_food_cost) / sum(matched_received) * 100` | mv_store_operating_expense_monthly | 分母必须用matched口径 |
|
||
| 人工费率 | `sum(wage_expense) / sum(matched_received) * 100` | 同上 | 同上 |
|
||
| 贡献利润 | `sum(received) FILTER(has_expense) - food_cost - operating_expense` | 多表JOIN | FILTER vs COALESCE口径要统一 |
|
||
|
||
### 2.2 口径一致性规则
|
||
|
||
**核心原则**：同一指标在多个页面展示时，必须使用同一数据源和同一计算方式。
|
||
|
||
```sql
|
||
-- 正确：费用率分母统一为matched_received
|
||
sum(operating_expense) / sum(received) FILTER(WHERE has_expense) * 100
|
||
|
||
-- 错误：分母包含无费用门店
|
||
sum(operating_expense) / sum(received) * 100
|
||
```
|
||
|
||
**FILTER vs COALESCE**：
|
||
- `sum(x) FILTER(WHERE has_expense)` — 排除无费用门店的整行
|
||
- `sum(COALESCE(x, 0))` — 无费用门店的x视为0，但received仍计入分母
|
||
- 两者在计算金额时结果相同，但在计算比率时分母不同
|
||
|
||
## 3. 物化视图模型
|
||
|
||
### 3.1 设计原则
|
||
|
||
1. **预聚合到月度+门店粒度**：原始表千万级，API不能直接查
|
||
2. **一个视图服务多个API**：避免为每个API建一个视图
|
||
3. **字段命名统一**：`received`、`consumption`、`bill_count`在各视图中保持一致
|
||
4. **刷新机制明确**：每个视图有对应的刷新脚本
|
||
|
||
### 3.2 核心视图清单
|
||
|
||
| 视图 | 粒度 | 用途 | 关键字段 |
|
||
|------|------|------|---------|
|
||
| mv_store_risk_rating_monthly | 月×门店 | 门店评级 | risk_level, received, bill_count |
|
||
| mv_store_operating_expense_monthly | 月×门店 | 费用分析 | food_cost, wage, rent, utility |
|
||
| mv_store_platform_economics_monthly | 月×门店 | 平台经济性 | meituan_received, eleme_cost_rate |
|
||
| mv_bill_hourly | 月×门店×小时 | 客流分析 | bills, avg_guests |
|
||
| mv_overview_daily | 日 | 日度概览 | received, bill_count |
|
||
| mv_overview_monthly | 月 | 月度概览 | received, bill_count, avg_bill_value |
|
||
| mv_risk_anomaly | 月×门店×账单 | 异常账单 | anomaly_reason, consumption |
|
||
| mv_risk_cashier | 月×门店×收银员 | 收银员风险 | bill_count, anomaly_bills |
|
||
|
||
### 3.3 AI协同验证
|
||
|
||
```
|
||
AI Prompt示例：
|
||
"请检查以下物化视图设计是否覆盖了指标体系中的所有L0和L1指标。
|
||
指标体系：[附上指标体系文档]
|
||
物化视图清单：[附上视图清单]
|
||
输出：覆盖度矩阵 + 缺失指标 + 建议"
|
||
```
|
||
|
||
## 4. 逻辑闭环验证
|
||
|
||
### 4.1 闭环图
|
||
|
||
```
|
||
数据采集 → 物化视图 → API查询 → 前端展示 → 人工决策
|
||
↑ ↓
|
||
效果检验 ← 任务关闭 ← 执行反馈 ← 任务接收 ← 预警触发
|
||
```
|
||
|
||
### 4.2 AI验证清单
|
||
|
||
| 验证项 | 检查内容 | 方法 |
|
||
|--------|---------|------|
|
||
| 数据覆盖度 | 每个指标是否有数据源 | 指标→视图→表→字段 逐项追溯 |
|
||
| 计算正确性 | 公式是否正确 | 用已知数据验证计算结果 |
|
||
| 口径一致性 | 跨页面同一指标是否一致 | 对比不同API的返回值 |
|
||
| 预警完整性 | 每个预警是否有触发条件和任务模板 | 逐条检查预警规则 |
|
||
| 任务闭环 | 任务从生成到关闭是否有完整流程 | 模拟走一遍流程 |
|
||
| 权限正确性 | 各角色是否只看到应有数据 | 模拟不同角色登录验证 |
|
||
| 空状态处理 | 无数据时是否优雅降级 | 测试新月份/新门店场景 |
|
||
|
||
### 4.3 逻辑断点示例
|
||
|
||
**断点1**：预警"食材成本率>45%"已配置，但没有对应的任务模板
|
||
```
|
||
修复：添加任务模板"食材成本率超标整改"
|
||
```
|
||
|
||
**断点2**：任务"排班优化"已配置，但系统没有客流-人力匹配数据
|
||
```
|
||
修复：补充attendance_records解析逻辑，生成客流-人力匹配指标
|
||
```
|
||
|
||
**断点3**：店长能看到本店数据，但无法看到区域均值对标
|
||
```
|
||
修复：在/stores/:code API中增加区域均值字段
|
||
```
|
||
|
||
**断点4**：利润瀑布图的received包含无费用门店，导致费率偏低
|
||
```
|
||
修复：received改为FILTER(WHERE has_expense)口径
|
||
```
|
||
|
||
## 5. AI协同设计输出
|
||
|
||
### 5.1 技术方案文档
|
||
|
||
```
|
||
1. 数据模型设计
|
||
- 原始表ER图
|
||
- 物化视图清单和SQL
|
||
- 门店名映射表
|
||
|
||
2. API设计
|
||
- 路由清单
|
||
- 每个API的SQL查询
|
||
- 请求参数和响应格式
|
||
- 数据权限规则
|
||
|
||
3. 前端设计
|
||
- 页面清单
|
||
- 每个页面的组件布局
|
||
- 指标卡配置
|
||
- 图表配置
|
||
|
||
4. 预警与任务设计
|
||
- 预警规则清单
|
||
- 任务模板库
|
||
- 闭环健康度指标
|
||
```
|
||
|
||
### 5.2 验证报告
|
||
|
||
```
|
||
1. 覆盖度报告
|
||
- 指标覆盖率：X/Y
|
||
- 数据覆盖率：哪些指标有数据，哪些缺数据
|
||
|
||
2. 口径一致性报告
|
||
- 跨页面指标对比表
|
||
- 不一致项及修复方案
|
||
|
||
3. 闭环验证报告
|
||
- 预警→任务→执行→反馈 全链路测试结果
|
||
- 发现的断点及修复方案
|
||
|
||
4. 性能预估
|
||
- 各API预估响应时间
|
||
- 物化视图刷新耗时
|
||
```
|
||
|
||
## 6. 关键注意事项
|
||
|
||
1. **先验证再编码**：这一步的目的是在写代码前发现逻辑问题，避免返工
|
||
2. **AI是协同不是替代**：AI生成方案，人审查业务合理性
|
||
3. **闭环比单点重要**：一个指标算错了是bug，一个闭环断了是系统失效
|
||
4. **口径要从一开始统一**：后期修复口径不一致的成本远高于初期统一
|
||
5. **留出迭代空间**：第一版不需要覆盖所有指标，先跑通核心闭环
|