freedakgmail
312 lines
18 KiB
Markdown
312 lines
18 KiB
Markdown
# 01 · 总体框架与八步工作法
|
||
|
||
## 1. 核心理念
|
||
|
||
玄谋智脑不是一套技术系统，而是一套**以经营战略为起点、以数据闭环为终点的企业管理方法论**。
|
||
|
||
### 1.1 借鉴FDE精神，适配中国国情
|
||
|
||
本框架借鉴 **FDE（Forward Deployed Engineer，前线部署工程）** 的核心理念，但并非照搬硅谷模式。中国连锁经营企业的现实是：预算有限（十万到百万级，非硅谷六七位数美元）、数字化基础薄弱、人员流动大、利润薄。需要做适配性改造。
|
||
|
||
> "中国FDE不是照搬硅谷岗位，而是企业在AI落地中，为模型能力与业务结果之间补上的一段责任。" —— 《FDE落地中国白皮书》
|
||
|
||
**借鉴什么**：
|
||
- 前线嵌入：深入业务现场，不闭门造车
|
||
- 先跑通再优化：两周交付最小可用，而非半年画大饼
|
||
- 双向沉淀：面向客户留能力，面向平台留模板
|
||
- 结果负责：对业务结果负责，而非对"系统上线"负责
|
||
|
||
**不照搬什么**：
|
||
- 硅谷高客单价人海模式（中国连锁经营企业支撑不起）
|
||
- 全能FDE单人角色（中国更现实的是"AI+业务人员"组合）
|
||
- 重型工程底座（中国连锁经营IT基础设施简单，不需要Kubernetes级部署）
|
||
- Palantir式政府/金融级合规要求
|
||
|
||
### 1.2 中国适配：AI作为"虚拟FDE"
|
||
|
||
中国连锁经营企业的现实解法——用AI替代部分FDE职能，降低对人力的依赖：
|
||
|
||
| FDE职能 | 硅谷做法 | 中国适配做法 |
|
||
|---------|---------|-------------|
|
||
| 场景发现（Echo） | 行业专家驻场数周 | 老板/中层访谈 + AI整理提纲和指标草案 |
|
||
| 快速原型（Delta） | 工程师现场写代码 | AI生成SQL/API/前端代码，人审查验证 |
|
||
| 数据对接 | FDE手动打通系统 | AI辅助编写导入脚本和映射逻辑 |
|
||
| 持续迭代 | FDE长期驻场 | AI协同月度诊断 + 远程迭代 |
|
||
| 知识沉淀 | FDE带回经验形成产品 | AI辅助沉淀为文档/模板/Checklist |
|
||
|
||
**核心思路**：AI承担Delta层80%的代码工作，人聚焦Echo层的业务判断和组织推动。这样即使预算有限，也能实现FDE式的深度交付。
|
||
|
||
### 1.3 Echo + Delta 双角色模型
|
||
|
||
借鉴Palantir的FDE实践，将部署团队分为两层角色，但在中国语境下重新定义：
|
||
|
||
| 角色 | 定位 | 硅谷原版 | 中国适配 |
|
||
|------|------|---------|---------|
|
||
| **Echo**（该做什么） | 场景发现者、需求翻译者 | 退役军官/行业专家全职驻场 | 老板+中层访谈，AI辅助整理，业务人员兼职 |
|
||
| **Delta**（怎么做出来） | 快速构建者、现场交付者 | 工程师现场写代码 | AI生成代码为主，技术人员审查验证为辅 |
|
||
|
||
**关键原则**：AI让Delta变便宜（代码生成、自动化测试），Echo更稀缺（识别高价值场景、理解行业、推动组织采纳）。在中国连锁经营企业，Echo层的核心是**老板本人的经营智慧和中层的管理经验**，而非外部专家。
|
||
|
||
### 1.4 总体循环
|
||
|
||
```
|
||
老板战略 → 指标体系 → 数据本体 → 执行闭环 → AI协同构建 → 持续优化
|
||
↑ |
|
||
└────────────────── 反馈与优化 ←──────────────────────────┘
|
||
|
||
FDE双向沉淀：
|
||
面向客户：业务经验 → AI知识库 → 工作流 → 应用能力
|
||
面向平台：行业场景 → 系统接口 → 测试方法 → 产品组件
|
||
↕ 共同载体：本体层（结构化业务知识图谱）
|
||
```
|
||
|
||
## 2. 八步工作法
|
||
|
||
> 每一步都标注FDE角色（Echo/Delta）和沉淀产出（面向客户/面向平台）。
|
||
|
||
### 步骤一：老板访谈与指挥层构建 `[Echo主导]`
|
||
> 从经营战略出发，定义"老板要看什么、管什么、决策什么"
|
||
|
||
- FDE嵌入现场，访谈老板近期经营战略和目标（带提纲和示例）
|
||
- 将模糊战略翻译为可量化指标（"我想看门店效率"→"日均产出/坪效/人效"）
|
||
- 形成智脑指标体系（指挥层）
|
||
- **面向客户沉淀**：指标体系文档、老板驾驶舱原型
|
||
- **面向平台沉淀**：行业指标模板（可复用于同类连锁经营企业）
|
||
|
||
### 步骤二：数据现状与本体层构建 `[Echo+Delta]`
|
||
> 摸清家底，建立从数据到指标的映射——本体层是FDE双向沉淀的核心载体
|
||
|
||
- FDE深入客户数据现场，了解现有系统和数据情况
|
||
- 针对指标体系的数据要求，盘点数据覆盖度
|
||
- 构建智脑本体层（数据模型、物化视图、映射关系）
|
||
- **面向客户沉淀**：数据溯源文档、物化视图体系、数据质量报告
|
||
- **面向平台沉淀**：本体设计模式（门店-账单-费用-考勤的通用关系模型）
|
||
|
||
### 步骤三：中层访谈与执行层准备 `[Echo主导]`
|
||
> 明确"谁来做、做到什么程度、如何考核"——FDE不只是技术交付，更是组织流程改造
|
||
|
||
- FDE嵌入中层（区域经理、店长）工作现场，明确职权范围
|
||
- 将指标体系拆解到岗位级执行动作
|
||
- 准备智脑执行层（任务模板、考核标准、预警规则）
|
||
- **面向客户沉淀**：岗位-指标矩阵、任务闭环规则
|
||
- **面向平台沉淀**：行业任务模板库（预警→任务→验收的标准流程）
|
||
|
||
### 步骤四：AI协同模型设计与逻辑闭环验证 `[Echo+Delta]`
|
||
> 在写代码前，先用AI验证业务逻辑的完整性——FDE的"先想清楚再动手"
|
||
|
||
- AI协同设计各层次的数据模型和业务逻辑
|
||
- 验证"指标→数据→分析→预警→任务→执行→反馈"闭环
|
||
- 发现逻辑断点并修复
|
||
- **面向客户沉淀**：模型设计文档、闭环验证报告
|
||
- **面向平台沉淀**：闭环验证Checklist（可复用于同类项目）
|
||
|
||
### 步骤五：AI协同本体层构建 `[Delta主导]`
|
||
> AI参与数据层代码编写和验证——Delta层成本被AI大幅压缩
|
||
|
||
- AI协同编写物化视图SQL
|
||
- AI协同编写数据导入脚本
|
||
- AI协同验证数据质量
|
||
- **面向客户沉淀**：可运行的数据层
|
||
- **面向平台沉淀**：物化视图SQL模板、数据校验脚本库
|
||
|
||
### 步骤六：AI协同后端API构建与验证 `[Delta主导]`
|
||
> AI参与API开发，逐个验证——快速交付能用的代码，不追求完美架构
|
||
|
||
- AI协同编写后端路由和SQL查询
|
||
- curl + psql 双向验证每个API
|
||
- 修复SQL陷阱（schema、列名、日期格式）
|
||
- **面向客户沉淀**：可运行的API层
|
||
- **面向平台沉淀**：API路由模板、SQL查询模式库
|
||
|
||
### 步骤七：AI协同前端UIUX设计与实现 `[Delta主导]`
|
||
> AI参与页面设计，参考典型页面模板——先交付能用的，再迭代好用的
|
||
|
||
- AI协同设计页面布局和交互
|
||
- 基于组件规范实现前端页面
|
||
- 联调API，处理空状态和加载状态
|
||
- **面向客户沉淀**：可用的前端界面
|
||
- **面向平台沉淀**：页面组件模板、行业Dashboard布局模板
|
||
|
||
### 步骤八：数据驱动闭环优化 `[Echo+Delta]`
|
||
> 上线不是终点，而是优化的起点——FDE持续驻场，把"不确定的机会"变成"可重复的流程"
|
||
|
||
```
|
||
数据采集 → 分析（基于模型）→ 发现问题 → 改进方案（AI协同）
|
||
→ 实施 → 反馈 → 检验 → 优化 → 再循环
|
||
```
|
||
|
||
- 基于模型分析数据，发现经营问题
|
||
- AI协同生成改进方案
|
||
- 落地实施，跟踪反馈
|
||
- 检验效果，优化模型和参数
|
||
- **面向客户沉淀**：持续运转的闭环机制、最佳实践库
|
||
- **面向平台沉淀**：行业诊断模型、参数调优经验、可复制的改进方案模板
|
||
|
||
## 3. 三层架构与FDE本体层
|
||
|
||
```
|
||
┌─────────────────────────────────────────┐
|
||
│ 指挥层（老板） │
|
||
│ - 战略目标 → 指标体系 │
|
||
│ - 老板驾驶舱、总部驾驶舱 │
|
||
│ - 关注：趋势、风险、机会 │
|
||
│ - FDE角色：Echo发现场景、翻译需求 │
|
||
├─────────────────────────────────────────┤
|
||
│ 本体层（数据+模型） │
|
||
│ - 原始数据 → 物化视图 → 指标计算 │
|
||
│ - 数据溯源、口径一致性 │
|
||
│ - 关注：数据质量、覆盖度、准确性 │
|
||
│ - FDE角色：双向沉淀的核心载体 │
|
||
│ - 本体 = 结构化业务知识图谱 │
|
||
│ 面向客户：业务经验→AI知识库→工作流 │
|
||
│ 面向平台：行业场景→产品组件→复用能力 │
|
||
├─────────────────────────────────────────┤
|
||
│ 执行层（中层+一线） │
|
||
│ - 指标 → 任务 → 执行 → 反馈 │
|
||
│ - 门店工作台、任务闭环 │
|
||
│ - 关注：可执行、可考核、可追踪 │
|
||
│ - FDE角色：嵌入现场、改造流程、推动采纳 │
|
||
└─────────────────────────────────────────┘
|
||
```
|
||
|
||
### 3.1 本体层的FDE价值
|
||
|
||
本体层不是简单的数据库设计，而是**从多个客户现场踩坑中提炼出来的通用业务知识结构**：
|
||
|
||
- 第一个客户：花大量时间理解"门店-账单-费用-考勤"的关系，成本高
|
||
- 第二个客户：本体层已稳定，只需适配新字段名和业务规则
|
||
- 第十个客户：本体层成为行业模板，交付成本显著下降
|
||
|
||
> **规模化的核心度量**：如果第一个客户需要10人月，第十个同类客户仍然需要10人月，模式就没有跑通。
|
||
|
||
### 3.2 中国连锁经营企业的本体层特点
|
||
|
||
与硅谷FDE面向政府/金融的本体层不同，中国连锁经营企业的本体层有其特殊性：
|
||
|
||
| 维度 | 硅谷FDE本体 | 中国连锁经营本体 |
|
||
|------|-----------|----------------|
|
||
| 数据源 | 多系统、高复杂度 | 收银+考勤+薪资+库存，3-5个Excel/CSV |
|
||
| 数据质量 | 有ETL管道，相对干净 | 原始数据脏，列名无含义（c001~c200） |
|
||
| 变更频率 | 低（制度稳定） | 高（门店开关、商品调整、人员流动） |
|
||
| 映射复杂度 | 系统间ID对接 | 门店名不一致（"双安店"vs"双安总店"） |
|
||
| 本体核心 | 权限+流程+合规 | 门店+账单+费用+考勤+库存的关系模型 |
|
||
|
||
**连锁经营本体的核心资产**（跨品类通用：餐饮/零售/服务/教培）：
|
||
1. 字段映射文档（c001=门店名，c114=实收...）——这是最宝贵的踩坑沉淀
|
||
2. 门店名映射表——每个新客户都要重新建，但模式可复用
|
||
3. 物化视图SQL模板——结构相同，表名和字段名适配即可
|
||
4. 异常判断规则——"有消费无实收"等行业特定规则
|
||
5. **门店-商品-供应链关系模型**——餐饮有BOM，零售有SKU，教培有课包，结构相似
|
||
|
||
## 4. AI协同模式与FDE角色分工
|
||
|
||
AI不是替代人，而是全程协同伙伴。FDE模式下，AI让Delta变便宜，Echo更稀缺：
|
||
|
||
| 阶段 | FDE角色 | AI角色（Delta增强） | 人的角色（Echo主导） | 双向沉淀 |
|
||
|------|---------|-------------------|-------------------|---------|
|
||
| 老板访谈 | Echo | 整理提纲、记录要点、生成指标体系草案 | 引导访谈、确认战略方向、翻译模糊需求 | 行业指标模板 |
|
||
| 数据调研 | Echo+Delta | 分析数据质量、生成溯源文档、编写SQL | 确认数据含义、验证业务逻辑 | 本体设计模式 |
|
||
| 中层访谈 | Echo | 设计岗位-指标矩阵、生成任务模板 | 确认职权范围、考核标准、推动组织采纳 | 行业任务模板库 |
|
||
| 模型设计 | Echo+Delta | 设计数据模型、验证逻辑闭环 | 审查业务合理性、决策取舍 | 闭环验证Checklist |
|
||
| 本体构建 | Delta | 编写SQL和脚本、验证数据 | 审查代码、验证结果 | 物化视图SQL模板 |
|
||
| API构建 | Delta | 编写路由和查询、排查错误 | 验证API返回、确认业务逻辑 | API路由模板 |
|
||
| 前端实现 | Delta | 编写页面代码、设计交互 | 审查UI/UX、验证用户体验 | 页面组件模板 |
|
||
| 闭环优化 | Echo+Delta | 分析数据、生成改进方案 | 决策方案、推动实施、验收结果 | 行业诊断模型 |
|
||
|
||
### 4.1 "先跑通再优化"原则
|
||
|
||
```
|
||
传统交付：需求分析(1月) → 架构设计(1月) → 开发(3月) → 测试(1月) → 上线
|
||
FDE交付：现场嵌入(1周) → 最小可用(2周) → 真实反馈(1周) → 快速迭代(持续)
|
||
|
||
关键差异：
|
||
- 传统：追求完美架构，上线时需求已变
|
||
- FDE：先交付能用的，在真实反馈中迭代
|
||
- AI加持：Delta层（代码编写）成本大幅压缩，原型可在数小时内生成
|
||
```
|
||
|
||
**中国连锁经营企业的特殊考量**：
|
||
- 老板耐心有限：两周看不到东西就会失去信任，所以第一版必须快速可见
|
||
- 数据基础差：不要等数据完美了再开始，用现有脏数据先跑通，边用边治
|
||
- 人员能力参差：第一版必须"傻瓜式"操作，不能要求店长学习复杂流程
|
||
- 利润薄：每一步都要能算清ROI，老板才会继续投入
|
||
|
||
### 4.2 "从最小痛点开始"原则
|
||
|
||
不要上来做"大一统"方案。选一个最小痛点，两周内跑通：
|
||
|
||
| 选择标准 | 示例 |
|
||
|---------|------|
|
||
| 业务痛点足够明确 | "13家门店亏损，不知道为什么亏" |
|
||
| 数据虽然不完美但够用 | bill_records有168万条，覆盖94家门店 |
|
||
| 效果可以量化 | 亏损门店数从13降到8 |
|
||
| 老板关心 | 直接关联L0战略指标 |
|
||
| 不依赖组织变革 | 不需要先改考核制度才能跑 |
|
||
|
||
**中国连锁经营企业的典型最小痛点**：
|
||
1. **门店亏损诊断**：数据现成（账单+费用），老板最关心，两周可见
|
||
2. **成本异动监控**：数据现成（账单+成本），痛点明确，容易量化
|
||
3. **异常交易监控**：数据现成（账单/订单），风险可控，见效快
|
||
4. **人效分析**：数据现成（考勤+营收），人力成本是连锁经营第二大成本
|
||
|
||
**不建议作为起点的场景**：
|
||
- 智能排班（需要考勤数据质量高+店长配合）
|
||
- 会员精准营销（需要会员数据积累+营销预算）
|
||
- 供应链优化（需要跨系统数据+供应商配合）
|
||
|
||
跑通一个场景后，再复制到下一个——先铺石子路，再修高速公路。
|
||
|
||
## 5. 文档体系导航
|
||
|
||
### 方法论主体（八步）
|
||
|
||
| 步骤 | 文件 | FDE角色 | 核心输出 | 平台沉淀 |
|
||
|------|------|---------|---------|---------|
|
||
| 一 | [02-步骤一-老板访谈与指挥层构建.md](02-步骤一-老板访谈与指挥层构建.md) | Echo | 指标体系、驾驶舱原型 | 行业指标模板 |
|
||
| 二 | [03-步骤二-数据现状与本体层构建.md](03-步骤二-数据现状与本体层构建.md) | Echo+Delta | 数据溯源、物化视图 | 本体设计模式 |
|
||
| 三 | [04-步骤三-中层访谈与执行层准备.md](04-步骤三-中层访谈与执行层准备.md) | Echo | 岗位-指标矩阵、任务模板 | 行业任务模板库 |
|
||
| 四 | [05-步骤四-AI协同模型设计与逻辑闭环.md](05-步骤四-AI协同模型设计与逻辑闭环.md) | Echo+Delta | 模型设计、闭环验证 | 闭环验证Checklist |
|
||
| 五 | [06-步骤五-AI协同本体层构建.md](06-步骤五-AI协同本体层构建.md) | Delta(AI为主) | 数据层代码 | 物化视图SQL模板 |
|
||
| 六 | [07-步骤六-AI协同后端API构建与验证.md](07-步骤六-AI协同后端API构建与验证.md) | Delta(AI为主) | API层代码 | API路由模板 |
|
||
| 七 | [08-步骤七-AI协同前端UIUX设计与实现.md](08-步骤七-AI协同前端UIUX设计与实现.md) | Delta(AI为主) | 前端界面 | 页面组件模板 |
|
||
| 八 | [09-步骤八-数据驱动闭环优化.md](09-步骤八-数据驱动闭环优化.md) | Echo+Delta | 优化闭环 | 行业诊断模型 |
|
||
|
||
### 技术参考
|
||
|
||
| 文件 | 内容 |
|
||
|------|------|
|
||
| [10-技术参考-项目概述与架构.md](10-技术参考-项目概述与架构.md) | 技术架构、数据流、部署拓扑 |
|
||
| [11-技术参考-部署与运维.md](11-技术参考-部署与运维.md) | 部署脚本、FRP隧道、PM2 |
|
||
| [12-技术参考-调试排查手册.md](12-技术参考-调试排查手册.md) | 问题分类、排查流程、案例 |
|
||
| [13-技术参考-通用方法论与避坑指南.md](13-技术参考-通用方法论与避坑指南.md) | 核心原则、风险清单、Checklist |
|
||
| [14-技术参考-数据溯源与API全量清单.md](14-技术参考-数据溯源与API全量清单.md) | 逐页面→API→SQL→字段映射 |
|
||
| [15-技术参考-指标口径一致性分析.md](15-技术参考-指标口径一致性分析.md) | 跨页面口径对比、问题清单 |
|
||
|
||
## 6. 规模化度量（中国适配版）
|
||
|
||
硅谷FDE用"人月成本递减"衡量规模化。中国连锁经营企业更现实的度量方式：
|
||
|
||
| 指标 | 定义 | 目标 | 中国适配说明 |
|
||
|------|------|------|-------------|
|
||
| 首次交付周期 | 从访谈到第一个可用版本 | <4周 | 老板耐心有限，超4周信任崩塌 |
|
||
| 同类客户交付周期 | 第二个同类客户 | <2周 | 本体层和模板复用后应大幅缩短 |
|
||
| AI代码占比 | AI生成的代码占总代码比例 | >70% | 降低对稀缺工程人才的依赖 |
|
||
| 客户自助率 | 客户独立完成的数据操作占比 | 逐月提升 | 中国连锁经营IT能力弱，需渐进式 |
|
||
| 闭环运转率 | 月度闭环实际执行率 | >80% | 闭环转起来才是真落地 |
|
||
| 沉淀复用率 | 可复用资产占项目总产出 | >40% | 没有沉淀就没有规模化 |
|
||
|
||
### 6.1 中国连锁经营企业的规模化路径
|
||
|
||
```
|
||
阶段一（单店验证）：1个客户，4周交付，大量踩坑
|
||
↓ 沉淀：字段映射、物化视图SQL、页面模板
|
||
阶段二（同品牌复制）：同品牌不同月份，1周交付，验证稳定性
|
||
↓ 沉淀：数据校验脚本、异常规则库
|
||
阶段三（同品类复制）：同品类不同品牌（如餐饮A→餐饮B），2周交付，适配字段名和业务规则
|
||
↓ 沉淀：品类本体模板、指标体系模板
|
||
阶段四（跨品类扩展）：不同品类（餐饮→零售→服务→教培），3周交付，适配本体层
|
||
↓ 沉淀：连锁经营通用本体设计模式
|
||
```
|
||
|
||
**关键**：每个阶段的沉淀质量决定下一阶段的速度。如果做完一个客户没有沉淀出可复用资产，下一个客户又从头开始，那就是传统外包，不是FDE。
|