SBrainCO/docs/智脑实施方法论/01-总体框架与八步工作法.md

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	Echo	指标体系、驾驶舱原型	行业指标模板
二	03-步骤二-数据现状与本体层构建.md	Echo+Delta	数据溯源、物化视图	本体设计模式
三	04-步骤三-中层访谈与执行层准备.md	Echo	岗位-指标矩阵、任务模板	行业任务模板库
四	05-步骤四-AI协同模型设计与逻辑闭环.md	Echo+Delta	模型设计、闭环验证	闭环验证Checklist
五	06-步骤五-AI协同本体层构建.md	Delta(AI为主)	数据层代码	物化视图SQL模板
六	07-步骤六-AI协同后端API构建与验证.md	Delta(AI为主)	API层代码	API路由模板
七	08-步骤七-AI协同前端UIUX设计与实现.md	Delta(AI为主)	前端界面	页面组件模板
八	09-步骤八-数据驱动闭环优化.md	Echo+Delta	优化闭环	行业诊断模型

技术参考

文件	内容
10-技术参考-项目概述与架构.md	技术架构、数据流、部署拓扑
11-技术参考-部署与运维.md	部署脚本、FRP隧道、PM2
12-技术参考-调试排查手册.md	问题分类、排查流程、案例
13-技术参考-通用方法论与避坑指南.md	核心原则、风险清单、Checklist
14-技术参考-数据溯源与API全量清单.md	逐页面→API→SQL→字段映射
15-技术参考-指标口径一致性分析.md	跨页面口径对比、问题清单

6. 规模化度量（中国适配版）

硅谷FDE用"人月成本递减"衡量规模化。中国连锁经营企业更现实的度量方式：

指标	定义	目标	中国适配说明
首次交付周期	从访谈到第一个可用版本	<4周	老板耐心有限，超4周信任崩塌
同类客户交付周期	第二个同类客户	<2周	本体层和模板复用后应大幅缩短
AI代码占比	AI生成的代码占总代码比例	>70%	降低对稀缺工程人才的依赖
客户自助率	客户独立完成的数据操作占比	逐月提升	中国连锁经营IT能力弱，需渐进式
闭环运转率	月度闭环实际执行率	>80%	闭环转起来才是真落地
沉淀复用率	可复用资产占项目总产出	>40%	没有沉淀就没有规模化

6.1 中国连锁经营企业的规模化路径

阶段一（单店验证）：1个客户，4周交付，大量踩坑
    ↓ 沉淀：字段映射、物化视图SQL、页面模板
阶段二（同品牌复制）：同品牌不同月份，1周交付，验证稳定性
    ↓ 沉淀：数据校验脚本、异常规则库
阶段三（同品类复制）：同品类不同品牌（如餐饮A→餐饮B），2周交付，适配字段名和业务规则
    ↓ 沉淀：品类本体模板、指标体系模板
阶段四（跨品类扩展）：不同品类（餐饮→零售→服务→教培），3周交付，适配本体层
    ↓ 沉淀：连锁经营通用本体设计模式

关键：每个阶段的沉淀质量决定下一阶段的速度。如果做完一个客户没有沉淀出可复用资产，下一个客户又从头开始，那就是传统外包，不是FDE。