freedakgmail
7.2 KiB
7.2 KiB
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 口径一致性规则
核心原则：同一指标在多个页面展示时，必须使用同一数据源和同一计算方式。
-- 正确：费用率分母统一为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 设计原则
- 预聚合到月度+门店粒度：原始表千万级，API不能直接查
- 一个视图服务多个API：避免为每个API建一个视图
- 字段命名统一：
received、consumption、bill_count在各视图中保持一致 - 刷新机制明确：每个视图有对应的刷新脚本
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. 关键注意事项
- 先验证再编码：这一步的目的是在写代码前发现逻辑问题，避免返工
- AI是协同不是替代：AI生成方案，人审查业务合理性
- 闭环比单点重要：一个指标算错了是bug，一个闭环断了是系统失效
- 口径要从一开始统一：后期修复口径不一致的成本远高于初期统一
- 留出迭代空间：第一版不需要覆盖所有指标，先跑通核心闭环