会员运营 · 马甲实战版
会员数据顾问·马甲实战版(majia-huiyuan)。当核心交付物是会员指标口径、RFM、复购/留存/流失公式、核销率、客单价、会员分层/分群、人群圈选、标签体系、CDP、OneID 身份打通、Cohort、CRM/私域数据分析、会员数仓(DIM/DWD/DWS/ADS)、SQL/DDL、字段词典、数据质量、会员看板或观远 BI 复刻时使用。用户提出召回、提频、防流失、流失预警、新客转化、渠道迁移(外卖↔堂食)、导购任务分派等会员运营动作时,动作背后的数据依据(圈谁/何时/力度/派给谁/怎么回收)由本 Skill 负责;动作的执行内容(朋友圈、群发、欢迎语、社群 SOP、企微操作)与私域整盘经营诊断走 majia-siyu——同一动作的两半,先数据后执行。全部数值为模拟数据,仅结构与口径可引用。 Skill: 会员运营 · 马甲实战版 Owner: maojiebc Summary: 会员数据顾问·马甲实战版(majia-huiyuan)。当核心交付物是会员指标口径、RFM、复购/留存/流失公式、核销率、客单价、会员分层/分群、人群圈选、标签体系、CDP、OneID 身份打通、Cohort、CRM/私域数据分析、会员数仓(DIM/DWD/DWS/ADS)、SQL/DDL、字段词典、数据质量、会员看板或观远 BI 复刻时使用。用户提出召回、提频、防流失、流失预警、新客转化、渠道迁移(外卖↔堂食)、导购任务分派等会员运营动作时,动作背后的数据依据(圈谁/何时/力度/派给谁/怎么回收)由本 Skill 负责;动作的执行内容(朋友圈、群发、欢迎语、社群 SOP、企微操作)与私域整盘经营诊断走 majia-siyu——同一动作的两半,先数据后执行。全部数值为模拟数据,仅结构与口径可引用。 Tags: agent-skill:1.4
Rank
62
Safety
84
Downloads
1.1k
Updated
Oct 11, 2026
Version
1.4.5
Source
CLAWHUB
About
What it does, and when to use it.
Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.
Avoid when
- Contract metadata is missing or unavailable for deterministic execution.
Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing
Public facts
Every fact links back to the source it came from.
- Vendor
- Clawhubvendor · observed Oct 11, 2026
- Protocol compatibility
- OpenClawcompatibility · observed Oct 11, 2026
- Adoption signal
- 1.1K downloadsadoption · observed Oct 11, 2026
- Latest release
- 1.4.5release · observed Sep 14, 2026
- Handshake status
- UNKNOWNsecurity
Install and run
Setup complexity: low.
clawhub skill install s171vv4g1xczzsxtgd1wg0626x83khts:majia-huiyuan- Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
- Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.
Contract: missing
curl -s "https://www.xpersona.co/api/v1/agents/clawhub-maojiebc-majia-huiyuan/snapshot"
Documentation
CLAWHUB
157,774 characters of source documentation, loaded on request.
Extracted files
5 files captured from the source.
SKILL.md
---
name: majia-huiyuan
description: "会员数据顾问·马甲实战版(majia-huiyuan)。当核心交付物是会员指标口径、RFM、复购/留存/流失公式、核销率、客单价、会员分层/分群、人群圈选、标签体系、CDP、OneID 身份打通、Cohort、CRM/私域数据分析、会员数仓(DIM/DWD/DWS/ADS)、SQL/DDL、字段词典、数据质量、会员看板或观远 BI 复刻时使用。用户提出召回、提频、防流失、流失预警、新客转化、渠道迁移(外卖↔堂食)、导购任务分派等会员运营动作时,动作背后的数据依据(圈谁/何时/力度/派给谁/怎么回收)由本 Skill 负责;动作的执行内容(朋友圈、群发、欢迎语、社群 SOP、企微操作)与私域整盘经营诊断走 majia-siyu——同一动作的两半,先数据后执行。全部数值为模拟数据,仅结构与口径可引用。"
license: MIT
metadata:
version: "1.4.5"
author: "超级马甲 / maojiebc"
homepage: https://github.com/maojiebc/majia-huiyuan
openclaw:
emoji: "🪪"
homepage: https://github.com/maojiebc/majia-huiyuan
---
# 会员运营 · 马甲实战版
你装上的是一套**开源会员运营家底**:一个可审计、可改造的连锁会员数据中台样板间 + 一座口径公式库 + 一份方法论实录。你的角色是**会员数据顾问**——用户大概率是业务或数据分析背景,不是工程师:先人话,后术语;每个结论给出处路径。SQL 是待验证参考实现,不能承诺“换表名即可生产”。
## 功能架构
一图看全:三大资产 → 五层数仓 → 会员数据顾问能干的十类活。

## 三大资产
> SkillHub 为文本精简包:保留结构定义、ETL 逻辑、看板文档、公式库与方法论正文;数据样本、原始 JSON 和图片请从 GitHub 完整版读取。
| 资产 | 位置 | 是什么 |
|---|---|---|
| **样板间** | `数据集/` `ETL/` `看板/` `清单/` | 咖啡连锁模拟中台:55 个逻辑数据集(DIM10/DWD16/DWS16/ADS8/DQC1/param4)、25 条 ETL、12 张角色看板。校正逻辑以 `ETL/逻辑SQL/` + `ETL/公共口径/` + `看板/页面文档/` 为准;原始 JSON 与页面 JSON 仅是 v1.4.0 workshop 历史快照 |
| **公式库** | `公式库/` | 10 册约 3100 行,蒸馏自真实履职(已脱敏):复购 / RFM(按最近来没来、来得勤不勤、花得多不多分层)/ 核销 / 留存流失的标准 SQL、通用字段词典、数据质量三态坑、DWD 宽表范式、39 生产 ETL 索引、任务与触达回收模型。总入口 `公式库/README.md`(路由表 + 5 条最易踩的坑) |
| **方法论实录** | `分享/区域运营的一天/README.md` | 获奖直播书面实录(34 页插画):区域运营痛点 → AI 跑五步人拍板 → 可信四件套 → 三案例(归因到人 / 会闭嘴 / 会多看一眼)→ 四类人落地 FAQ |
## 任务路由(用户要 X → 你做 Y)
常见问题可先读 [实战问题入口](公式库/实战问题入口.md):复购对账、门店读数、注册归因、员工激励、券核销、开业回收、召回与储值事件。它说明最少要什么数据、什么结果才算答到了问题。
| 用户要什么 | 你怎么干 |
|---|---|
| **问口径 / 公式**("复购怎么算""RFM 怎么分层""核销率口径") | 先查 `公式库/README.md` 路由表进对应分册拿标准 SQL;再对照 `ETL/逻辑SQL/` 里样板间的实际实现,两处一致时置信度最高。**必须提口径选项**(如复购跨天 vs 非跨天是两条曲线)。注意 RFM 有两套并存口径:公式库 02 册是高低二分 8 类(快速起步),样板间 ETL 是 5 分制 9 类(精细运营)——先问用户场景再选,不要混用 |
| **业务动作要数据依据**("做一次流失召回""新客怎么促二单""外卖客怎么拉到店""任务怎么派给导购") | 按"圈谁 → 何时 → 力度 → 派给谁 → 怎么回收"五件套作答:圈选条件出自 `dws_会员生命周期`(7 阶段状态机)/ `dws_会员RFM分层` / `dws_渠道迁移分析`(近 30 天 vs 前 60 天堂食外卖迁移);时机与力度阈值出自 `公式库/02` 的 R 阈值分级决策表(14/21/30/60 天四档对应不同券力度)+ `param_` 参数表;分派与回收模型出自 `公式库/10-task-and-touch-recovery.md`(任务池 NBA 模型)。**执行内容(话术/素材/社群 SOP)切 majia-siyu,明确告知用户** |
| **搭 CDP / 标签体系 / 身份打通** | OneID 样板 = `dim_会员身份桥`(手机号 Hash / OpenID / UnionID / 企微外部联系人 / 支付渠道五类身份 + 匹配置信度 + 匹配方式);身份合并优先级 SQL 在 `公式库/02` 开篇"顾客标识统一化";标签规则外置范式 = `param_` 参数表模式(阈值不硬编码进 SQL);Profile+Events 双层 = `dim_会员主档` + 六张 `dwd_` 事件表 |
| **从零设计会员数据体系** | 以 `清单/数据集清单.csv` 为蓝本,按 DIM→DWD→DWS→ADS 分阶段给**最小可用集**:先档案(会员主档/门店主档)+ 订单流水,再算汇总(RFM/生命周期),再上报表。绝不一次吐 55 张表 |
| **诊断现有体系缺什么** | 把 55 个逻辑数据集当 checklist,逐层对照用户已有的表,输出缺口清单 + 补齐优先级(优先补影响口径的 DIM 和 param) |
| **生成建表语句** | 用 `数据集/结构定义/*.md` 的字段与类型信息推 schema;需要取值样本时读取 GitHub 完整版的 `数据集/数据样本/*.csv`,翻译成用户的目标引擎方言(源是 Spark 3.4,MySQL/ClickHouse/PG 注意函数差异并主动提醒) |
| **规划看板体系** | 参照 12 张角色看板(`看板/页面文档/`):老板看驾驶舱、会员负责人看私域盘、店长看每日指挥台、加盟商看单店报告——按用户组织架构裁剪,每个角色一张 |
| **数据质量排障**("两套数对不上""AI 老搞混字ETL/公共口径/README.md
# v1.4.2 公共口径 这里放 25 条示范 ETL 共用的三条事实桥,以及第二刀抽出的时间规范。为让单条逻辑文档可独立阅读,当前核心 ETL 仍内嵌了等价实现,并由自动测试约束窗口、有效性、唯一性和 SCD2 去重保持一致;生产落地时应先物化公共口径,再让下游直接引用。 ## 事实桥 | 事实桥 | 输入 | 唯一性 | 用途 | |---|---|---|---| | `01_触达订单归因桥.sql` | 会员触达 + 已完成订单 | 每个订单最多命中一次最近有效触达 | 私域漏斗、高层驾驶舱、触达后关联销售 | | `02_券实例核销订单桥.sql` | 券实例事件 + 已完成订单 | 每个订单最多命中一个实际核销券实例 | 核销订单 GMV、优惠成本 | | `03_活动参与订单归因桥.sql` | 活动参与 + 已完成订单 | 每个订单最多命中一次最近有效活动参与 | 活动参与后归因 GMV | 共同约束: 1. 所有输入事实日期不得晚于同一个 `as_of_date`。 2. 归因只能发生在事件之后;默认滚动窗口为事件时间(含)至事件时间加 8×24 小时(不含),标记为 0–7 天,可由调度参数替换。 3. 使用 `ROW_NUMBER() OVER (PARTITION BY 订单ID ...) = 1` 强制订单级唯一性。**三种口径各自独立**:同一订单可以同时出现在触达桥、券桥和活动桥,但不能在同一条桥里出现两次。 4. 下游一律按订单发生日期汇总,不能把未来七天订单塞回触达日或参与日。 5. 这些桥只证明“时间窗口内关联”,不证明增量。没有随机对照或合格准实验时,只能叫“关联 GMV / 归因 GMV”,不能叫“贡献销售 / 增量 ROI”。 6. 券实例只有在核销日期落在发放日至失效日内、且不晚于 `as_of_date` 时才是有效核销;异常多券同单时按优惠金额降序、券 ID 升序只保留一张券承接订单 GMV。 7. `04_v1.4.1_业务验收.sql` 必须同时检查三条桥的订单唯一性和“归因 GMV ≤ 同期已完成订单 GMV”。只验收触达桥不算第一刀完成。 ## 时间规范 | 规范 | 粒度 | 约束 | |---|---|---| | `05_门店营业日历.sql` | 一门店 × 一个自然营业日 | 开业日至 `min(闭店日, as_of)` 每天一行,当天 0 单也保留。开闭店边界只取当前版本。 | | `06_门店月份骨架.sql` | 一门店 × 一个营业月份 | 开业月至 `min(闭店月, as_of 月)` 每月一行,零销售但有成本的月份必须留下。月份属性按 `维度命中日期` 走 SCD2。 | | `07_SCD2门店时点关联.sql` | 一条事实 × 一个门店版本 | 每个 `(门店ID, 事实日期)` 最多一个版本;重叠窗口按生效起始日、版本 ID 降序只留一行,`scd_rn = 1`。关联前后事实行数守恒。 | 时间规范额外约束: 1. 开闭店边界可以用当前版本;**日/月属性禁止用当前版本回写历史**,必须按事实日期做 SCD2。 2. 指挥台、门店日报、利润月汇总、新店爬坡、体验口碑都必须在关联后门店键不重复。 3. 同期群未走完整观察期的 `Mn`(不含 M0)必须输出空的留存人数和留存率。 4. `04_v1.4.1_业务验收.sql` 第 23–27 项检查门店日/门店月/新店爬坡/体验口碑唯一性,以及未完整观察月的空值。 ## 规则任务生成 | 规范 | 粒度 | 约束 | |---|---|---| | `08_规则任务生成.sql` | 一个会员 × 一条规则任务 | 九类圈选先 UNION ALL;营销任务挡近 7 日触达,负评修复豁免;再按 P0<P1<P2、预计价值降序只留一条。 | 任务生成额外约束: 1. 这是候选任务,不是 `dwd_会员经营任务` 的执行快照。`ads_会员经营任务池` 仍展示已分派任务。 2. `推荐原因` 必须在生成时写成带数字的人话;`预计价值` 冷启动用历史客单价,不是增量。 3. 防打扰查 `dwd_会员触达`,不查任务表。负评修复不参加防打扰,但参加仲裁。 4. 营销任务按会员 ID 数字尾号做 10% holdout(尾号 0);负评修复不进对照。触达后下单不能叫增量。 5. `04_v1.4.1_业务验收.sql` 第 28 项检查规则任务会员唯一。 6. 漏斗、高层驾驶舱、券效益、活动复盘的归因 CTE 必须使用与本目录相同的桥名:`bridge_触达订单归因` / `bridge_券核销订单` / `bridge_活动参与订单归因`。生产应先物化这三张桥,再让下游直接引用。 SQL 为 Spark 3.4 方言。文件中的 `DATE '2026-06-24'` 是本模拟快照的默认值,生产调度必须替换为同一批次的运行参数。
README.md
# majia-huiyuan · 会员运营家底(开源样板间) [](./SKILL.md) [](./LICENSE) [](https://skills.sh/maojiebc/majia-huiyuan) [](https://github.com/maojiebc/majia-huiyuan/releases) [](https://github.com/maojiebc/majia-huiyuan/actions/workflows/quality.yml) [](./AGENTS.md) [](#数据说明必读) > **会员运营 · 马甲实战版** — 一套**完整、可审计、可改造的**连锁会员数据参考体系。以一家虚构的咖啡连锁为例,从会员注册的第一行数据,到老板看的经营驾驶舱:**55 个逻辑数据集、25 条数据加工链、12 张看板,外加约 3100 行的实战公式库**,全部摊开。 > > 数据全部模拟生成,与任何真实企业无关。MIT 协议,个人用、公司用、商用,都随便。 <p align="center"> <img src="https://raw.githubusercontent.com/maojiebc/majia-huiyuan/main/docs/architecture.png" width="440" alt="majia-huiyuan v1.4.1 功能架构:三大资产 + 五层数仓 + 会员数据顾问十类活 + 与 majia-siyu(执行内容)及 majia-guanyuan(平台工具)的分工"/> </p> **谁适合看**:做会员、做私域的业务同学;做数据分析、数据建设的同学;想给自己公司从零搭一套会员数据体系的人。**不需要会写代码。** **AI 也适合看**:如果你是 AI Agent(WorkBuddy / Claude / Codex / Cursor …),你的入口在 [llms.txt](./llms.txt) 和 [AGENTS.md](./AGENTS.md);本仓库同时是一个可安装的 **Agent Skill**([SKILL.md](./SKILL.md)),装法见[下方](#-当-agent-skill-用)。 --- **你是谁,直接去哪里:** | 我想做的事 | 直接去 | |---|---| | 店长先看什么、新增怎么算、奖励怎么结 | [实战问题入口](公式库/实战问题入口.md) | | 找某个指标怎么算(复购率、RFM、核销率…) | [公式库/README.md](./公式库/README.md) → 按主题找分册 | | 看表结构 / 字段定义 / 数据长什么样 | [数据集/结构定义/](./数据集/结构定义/) + [数据集/数据样本/](./数据集/数据样本/) | | 理解某条 ETL 的加工逻辑和 SQL 口径 | [ETL/逻辑SQL/](./ETL/逻辑SQL/) 按表名找对应 md | | 搭观远 BI,理解原 workshop DAG / 布局 | [ETL/原始JSON/](./ETL/原始JSON/) + [数据集/原始JSON/](./数据集/原始JSON/) + [看板/页面JSON/](./看板/页面JSON/)(均为历史快照,不含 v1.4.1 字段修复;资源 ID 也不可移植) | | 用 AI 工具直接问会员数据问题 | [SKILL.md](./SKILL.md) 装成 Agent Skill,或把仓库地址扔给 AI | | 发布到 WorkBuddy 开放平台 | [workbuddy/README.md](./workbuddy/README.md) → 生成自包含单专家 ZIP,并先跑平台契约测试 | | 先看故事再翻表 | [分享/区域运营的一天/](./分享/区域运营的一天/README.md) | > **v1.4.5 可信边界:**`ETL/逻辑SQL/`、[`ETL/公共口径/`](./ETL/公共口径/) 与 `看板/页面文档/` 是当前校正后的参考口径;本次补充门店经营口径与实战问题入口,数仓参考逻辑沿用 v1.4.2,仍需用自家数据验证后再生产化。`*/原始JSON/` 和 `看板/页面JSON/` 是 2026-06-24 的 workshop 历史快照,保留用于审计原 DAG / 布局,**未同步改造成可直接导入包**,其中仍可能出现旧字段名。当前 SQL 定位是“待验证示例”,不是标准答案。未做 Spark 全量回放。 --- ## 这是什么 会员运营这行有块三不管地带:字段怎么定义、口径怎么算、看板怎么搭,做业务的嫌它是技术细节,做数据的嫌它是业务琐事,两边都懂的人当它是吃饭本事。结果就是,想学的人找不到一份能从头看到尾的完整参照。 这个仓库就是那份参照——一个"样板间"。 它是 2026 年 5 月在观远 BI 官方 workshop 实例上独立搭建的一套完整会员数据中台,虚构了一家咖啡连锁:**8 万会员、1200 家门店、141 个加盟商、74 个商品、129 万笔订单**。麻雀不大,五脏俱全:会员注册、订单、发券、积分、私域触达、投诉评价、加盟分账、门店成本,全链路的数据都有,而且是打通的。 毛坯房教不会人装修,样板间可以。你不一定照单全收,但每面墙长什么样、水电怎么走,这里都看得见。 本仓库会持续迭代,路线图见[下方](#路线图)。 ## 三分钟看懂:数据分五层 所有数据集按五层组织(这是数据行业的通用做法,名字唬人,事情简单): | 层 | 行话 | 人话 | 本库数量 | |---|---|---|---| | **DIM** | 维度层 | **档案柜**:会员档案、门店档案、商
公式库/README.md
# 餐饮零售 BI 公式实战库 > 蒸馏自两段连续的餐饮 BI 分析师履职(**餐饮连锁 A + 餐饮连锁 B**,均为多门店连锁餐饮品牌),覆盖**观远 BI / Guandata** 平台上的常用 ETL SQL、卡片表达式、时间宏;第 [10 册](10-task-and-touch-recovery.md)另以本仓库样板间的任务池实现为蓝本。所有品牌名、表名、密集业务字段已去敏,可自由复用。 门店问题先读 [实战问题入口](实战问题入口.md):注册归因、激励结算、核销排错、开业留客、日常读数与储值事件。口径仍由下面 10 册统一维护。 ## 路由表 | 我要算 / 处理 | 去 | |---|---| | 日期范围(T-1、本月、上月、近 N 天)、用餐时段、时间宏、跨月对齐 | [01-date-and-time.md](01-date-and-time.md) | | 新老客 / 会员属性 / 消费频次 / 复购 / 留存 / 流失 / **RFM 8 类 × 营销策略** / R 阈值多档分级 | [02-customer-and-membership.md](02-customer-and-membership.md) | | AC / ADS / ADT / AUD / Comp / TC_CRM% / NS_CRM% / 营收占比 | [03-revenue-kpi.md](03-revenue-kpi.md) | | 堂食 vs 外卖渠道分流 / 订单子渠道大 case / 门店生命周期 / StoreDate / 成长类型 / **多渠道评价 Pipeline** | [04-channel-and-store.md](04-channel-and-store.md) | | 核销率 / 折扣率 / 折扣分桶 / 首张券 / 30 天优惠订单比例 | [05-coupon-and-discount.md](05-coupon-and-discount.md) | | `regexp_extract` / `explode-split` / `collect_set-concat_ws` / 开窗排名 / 字段拆解 | [06-sql-utils.md](06-sql-utils.md) | | NULL / 空字符串 / 'null' 字面值三态 / 字段口径歧义 / 通用字段词典 | [07-data-quality-traps.md](07-data-quality-traps.md) | | **ETL 工程范式**(10-CTE DWD 宽表 / 轻节点重 SQL vs 重节点轻 SQL / 财务双源对账 / POS 归一化 / Cohort 网格)| [08-etl-engineering-patterns.md](08-etl-engineering-patterns.md) | | **39 个 V1 生产 ETL 索引清单**(按 11 个业务域分类 + 每 ETL 的节点/输入/输出/SQL 节点速查 + 复用决策表)| [09-etl-catalog.md](09-etl-catalog.md) | | **任务与触达回收**(白盒 NBA 任务池模型 / 九类任务×优先级×圈选依据 / 任务生成 SQL / 防打扰与仲裁 / 漏斗四率回收 / **差评客户挽回**)| [10-task-and-touch-recovery.md](10-task-and-touch-recovery.md) | ## 通用字段词典 ETL 输入表统一称作 `input1`(观远 SmartETL 默认入参名),其余字段命名约定如下。**本库所有 SQL 都使用这套约定,复用时按你方实际字段名重命名即可。** | 词典名 | 含义 | 等价别名(你可能遇到的) | |---|---|---| | `订单号` | 订单唯一 ID | `OrderKey` / `order_id` / `券包订单ID` | | `订单日期` | 业务日期 | `businessDate` / `report_date` | | `下单时间` | 含时分秒的下单时刻 | `OrderTime` / `create_time` | | `去税营业额` | 营收口径(剔税) | `去税营业额 NS` / `income_应收` / `NS` | | `含税营业额` | 营收口径(含税) | `含税营业额 GS` / `total` / `GS` | | `原价金额` | 折扣前金额 | `原价金额 ALA_Sales` / `ALA` / `original_price` | | `折扣金额` | 让利金额 | `Discount` | | `销量` | 商品件数 | `QTY` | | `订单产品` | 商品名字符串 | `Items` / `names` / `names_grill` | | `顾客标识` | 跨渠道统一顾客 ID(优先级:会员卡号 > 微信 openid > 支付宝 user_id > 云闪付 user_id) | — | | `会员卡号` | 会员 ID | `MemberShipID` / `dis_cardno` / `card_no` | | `是否会员` | 二值或三值标记 | `MemberType` / `IsMember` | | `门店编号` | 门店唯一 ID | `StoreID` / `store_code` | | `门店名称` | 门店中文名 | `store_name` / `SHOP_NAME` | | `分公司` | 区域分公司 | `注册所属分公司` / `归属分公司` | | `渠道ID` | 数字化渠道码(外卖、堂食、自取等) | `CHANNEL_ID` | | `来源类型` | 二级来源(微信/支付宝/拼单/POS 等) | `FromType` / `OrderSource` | | `业务渠道` | 一级归类(堂食/外卖) | `Channel` / `业务渠道划分` | | `StoreDate` | `CONCAT(门店编号, '_', 营业日期)`,作为门店×日的唯一键 | — | | `Comp` 标记 | 是否同店可比 | `IsComp` | | `TC` | 客流数 / 订单笔数 | — | ## 5 条最容易踩的坑(TL;DR) 1. **`COUNT(DISTINCT IF(cond, x, NULL))` 才正确,写 `IF(cond, x, 0)` 会把 0 也计数一个。** → 详见 [07](07-data-quality-traps.md#null-vs-0) 2. **顾客标识三态**:`NULL` / 空字符串 `''` / 字面量 `'null'` 必须**三个都判**,否则统计会漂。 → [07](07-data-quality-traps.md#三态判断) 3. **`COUNT(订单号)` 和 `COUNT(DISTINCT 订单号)` 不一样**:拼单订
分享/区域运营的一天/README.md
# 区域运营的一天 · 直播分享全记录(34 页插画版) > 2026 年 7 月 9 日,观远数据「对话 AI Hero」第一期直播,我把 AI 创新赛一等奖作品《区域运营的一天》从头到尾讲了一遍,线上 70 多人,讲了一个多小时。这份文档是那场直播的书面整理版:34 页插画板全部嵌入,讲述文字从直播逐字稿蒸馏而来,去掉了口水话,保留了当时真实讲的内容和现场问答。 > > 当时演示用的整套数据环境有 54 个数据集、25 条 ETL、12 张看板;v1.4.1 将误名参数表拆分后,当前仓库为 55 个逻辑数据集——看完这篇,回到 [仓库首页](../../README.md) 就能查看完整模拟中台。 --- ## 一、开场:这是一场什么分享  作品叫《区域运营的一天》。一句话:区域运营过去要花一上午干的巡店分析,让 AI 压缩到几分钟——不是做一张更快的报表,是把"发现问题、分析原因、推动行动"这条每天必走的动作链整个交给 AI 跑,人只做最后的拍板。  先交代我是谁:我不是数据分析师出身,是业务,在门店堆里泡了十几年的用户运营,做过到家、做过实体零售,现在在连锁餐饮负责会员体系。我自己搭过 BI 看板、导过数据集,但算不上专业人士——正因为不专业,这套东西对我这种人能跑通,对你大概率也能。  路线四站:先讲区域运营的一天有多烦(痛点),再讲 AI 接手之后的一天长什么样(方案),然后回答 AI 凭什么可信(底座),最后当场真跑三个问题(演示)。  直播时我说这不是汇报,是聊天,有疑问随时打断。落到这份文档:读到哪觉得不对,[提个 issue](https://github.com/maojiebc/majia-huiyuan/issues) 就是打断我。 ## 二、痛点:一上午是怎么被吃掉的  给主角取了个花名,花十六,区域督导,管几十家店,一年大部分时间在辖区里跑。他每天早上的活:翻三个看板——利润的、口碑的、会员的——找出哪家店红了;发现一家在亏,打电话问店长,店长说"隔壁店也这样";只好拉 Excel 人肉对口径,你说的口径是 A,他理解的是 B。一上午过去,只够看几家店。我们这行还有个背景:BI 权限往往下放不到一线督导,大家实际流转的还是企业微信里的本地 Excel。  我们之前也试过各种智能体、机器人,它们很勤奋,不断弹通知:这个指标跌了、那个数据负增长。但大部分是无效信息。预警一多,等于没有预警。  更要命的是误报比漏报贵。报警信息一旦出错,一线的人第一反应不是"数据有问题",是"AI 很蠢"——信任这个东西,错一次,你再想让他给第二次机会,很难。  演示环境 1200 家店里,P0 级严重亏损 103 条,集中在约 30 家门店,连着几个月失血。真正贵的不是亏损本身,是归因延迟:从"被报警"到"搞清为什么、谁去管",中间隔着的每一天都是钱。 ## 三、方案:AI 跑五步,人拍最后一板  现在花十六只问一句大白话:"今天哪些店要我管?为什么?谁去管?"不用把需求翻译成技术语言。顺带说个口径的老梗:顾客一天内下两单算不算复购?隔天下第二单才算?这种口径争议在我们早期吵了很久——大白话提问的前提,是口径已经有人钉死在表里(这正是本仓库[公式库](../../公式库/)管的事)。  AI 替他跑五步:**发现**(运营、利润、口碑、会员四路监控合成一张待办清单)、**归因**(异常出在房租、人工、客群还是口碑,沿数仓下钻排除)、**豁免**(寒暑假的学校店、爬坡期的新店,这些"不该报的"自动挡掉)、**派单**(每条异常带责任人、风险等级、建议动作)、**通知**(按区域经理分组生成日报)。  自动化的边界停在"发送"之前。日报生成好、推送模板备好,最后由人确认再发出。我试下来,不管多强的模型,最后的判断替代不了人——这也是每个经验丰富的业务、分析师真正的竞争力所在。 ## 四、底座:AI 凭什么可信  讲到这里通常会被问:这些判断,AI 凭什么?答案是它不凭感觉,它读的是一套业务看得懂、改得动、可对账的数据资产。  四件套。**参数表**:9 种店型乘 7 个参数的差异化阈值——商场店房租上限 28%、社区店 12%,判断标准从人脑和代码里搬进一张表;**归因清单**:四路异常合流成唯一出口,6115 行,每行带归因、责任人、建议动作,不再是两个地方查出两套结论;**对账自检**:九项检查每次重跑自动重跑,机器查机器;**护栏**:全量 103 条 P0 无一被豁免,"闭嘴"绝不闭出漏报。护栏这个思路是通用的——直播前一天我批量生成这些插画,就给流程加了一条"检查图里中文有没有乱码,有就重生成",做数、做图、做文案,都得有收尾那道检查。  给数据打标签、建多维数据集,是老概念,AI 时代反而绕不开:字段有没有注释、有没有歧义,直接决定 AI 读出来的是判断还是猜测。  这套 demo 我是从零建的,但落回真实企业不需要推倒重来——现有 BI 资产全保留,只做增量。不过我想多说一句"推倒重来的勇气":历史数据乱、字段没注释、前辈写的逻辑不敢碰,是每家的常态,我以前改一处报错就吓得回滚。现在 AI 能读全库,我第一次有了底气把 30 多条 ETL 理成十几条、把上千张没人打开的看板砍到几百张——推不推倒是选择,敢不敢推倒是能力。 ## 五、工具层:眼睛和手  我一开始以为 CLI 是给人看的说明书,后来才明白:它是给 AI 用的命令行,相当于 AI 的鼠标和界面。大模型是现成的大脑,缺的从来是眼睛和手——CLI 让 AI 看得懂你的数据资产(哪张是参数表、字段什么含义),也够得着(能查、能建、能跑)。  整个演示项目就是这么长出来的:我只提了一个朴素需求——"帮我模拟一家 1200 家店的咖啡连锁,把该有的底表都建了"。AI 生成了几十张表:会员、订单、积分、私域、加盟分账、门店成本,字段是真的(从我十几年业务经历里蒸馏的),数据是假的(全部模拟)。这套东西现在就躺在本仓库里。  ETL 也进化了:从在画布上拖节点,到一段 SQL 直接跑。说实话,AI 写的不少 SQL 已经超出我的阅读能力,我找专业伙伴看过,他说能看懂大半——我不跟 AI 抢功劳,我出的是业务需求,它出的是工程。  以前"把数据结构推倒重梳理"是个大
AionUi
Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!
activepieces
AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents
cherry-studio
AI productivity studio with smart chat, autonomous agents, and 300+ assistants.
CopilotKit
The Frontend for Agents & Generative UI. React + Angular
Machine-readable data
The same record, as JSON, for agents and crawlers.
{
"facts": [
{
"factKey": "vendor",
"category": "vendor",
"label": "Vendor",
"value": "Clawhub",
"href": "https://clawhub.ai/maojiebc/skills/majia-huiyuan",
"sourceUrl": "https://clawhub.ai/maojiebc/skills/majia-huiyuan",
"sourceType": "profile",
"confidence": "medium",
"observedAt": "2026-10-11T11:48:59.337Z",
"isPublic": true
},
{
"factKey": "protocols",
"category": "compatibility",
"label": "Protocol compatibility",
"value": "OpenClaw",
"href": "https://www.xpersona.co/api/v1/agents/clawhub-maojiebc-majia-huiyuan/contract",
"sourceUrl": "https://www.xpersona.co/api/v1/agents/clawhub-maojiebc-majia-huiyuan/contract",
"sourceType": "contract",
"confidence": "medium",
"observedAt": "2026-10-11T11:48:59.337Z",
"isPublic": true
},
{
"factKey": "traction",
"category": "adoption",
"label": "Adoption signal",
"value": "1.1K downloads",
"href": "https://clawhub.ai/maojiebc/majia-huiyuan",
"sourceUrl": "https://clawhub.ai/maojiebc/majia-huiyuan",
"sourceType": "profile",
"confidence": "medium",
"observedAt": "2026-10-11T11:48:59.337Z",
"isPublic": true
},
{
"factKey": "latest_release",
"category": "release",
"label": "Latest release",
"value": "1.4.5",
"href": "https://clawhub.ai/maojiebc/majia-huiyuan",
"sourceUrl": "https://clawhub.ai/maojiebc/majia-huiyuan",
"sourceType": "release",
"confidence": "medium",
"observedAt": "2026-09-14T04:22:43.927Z",
"isPublic": true
},
{
"factKey": "handshake_status",
"category": "security",
"label": "Handshake status",
"value": "UNKNOWN",
"href": "https://www.xpersona.co/api/v1/agents/clawhub-maojiebc-majia-huiyuan/trust",
"sourceUrl": "https://www.xpersona.co/api/v1/agents/clawhub-maojiebc-majia-huiyuan/trust",
"sourceType": "trust",
"confidence": "medium",
"observedAt": null,
"isPublic": true
}
],
"events": [
{
"eventType": "release",
"title": "Release 1.4.5",
"description": "补齐新增口径、券批次、激励费用与储值资金事件,增加实战问题入口;示例为模拟参考,SQL需按自家数据验证。",
"href": "https://clawhub.ai/maojiebc/majia-huiyuan",
"sourceUrl": "https://clawhub.ai/maojiebc/majia-huiyuan",
"sourceType": "release",
"confidence": "medium",
"observedAt": "2026-09-14T04:22:43.927Z",
"isPublic": true
}
]
}Record generated Oct 11, 2026.
