BEEHIVE STRATEGY 蜜雪通 AI 化 页码1 / 1 章节 已用0:00 进度预算+0.0 分钟
BEEHIVE STRATEGY · 提案 · 2026

蜜雪通 AI 化

从「问得到数」到「问题被解决」—— 把没人负责的那段路，变成可验收的闭环
提案方Beehive Strategy 蜂启咨询
汇报对象蜜雪通 AI 化项目评审组
时长60 分钟（含问答 5 分钟）
配套现场演示 + 五条可检验承诺
执行摘要EXHIBIT 11.5 min

三个结论，一个建议

01

贵司不缺系统，缺的是系统之间那一层

观远答得准，蜜雪通管得深 —— 中间那段编排，今天没有人认领。

02

延迟不在分析，在路耗

一个经营问题 9 天，真正在分析的不到 2 天；其余耗在等排期、找口径、搬数据、走审批。

03

蜜雪通有 API —— 闭环才在物理上可能

有回写通道，结论才能变成工单并被追到关闭；这件事同时改了成本结构。

建议 · 先定靶，再定价

花 10 个工作日，用贵司真实工单把延迟与年化算成唯一的一行数字。 靶定住了，范围与价格才有得谈 —— 在那之前我们不报价，也不建议贵司做决定。

SO WHAT贵司今天不需要做一个决定 —— 只需要同意做一次测量。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 结论基于前期资料与 Beehive 同类项目经验；第 10 个工作日以贵司数据复核
02
证据预告0.5 min

先别听我们说 —— 先看它跑起来

华南区运营群 · 企微
@经营助手　华南区上周杯量同比 −8.4%，为什么？
① 暴雨 3 天，影响 62 家门店 → −5.1pp ② 其中 18 家同时缺货 2 天 → −2.0pp ③ 竞品在 12 个商圈做买一送一 → −1.3pp 建议：优先补这 18 家的货，预计挽回 3.6pp
口径版本 v2026.08.3SQL 可展开

这不是设计稿

零售智脑茶饮场景库的真实输出：7 年数据，26 个问题全跑通。

PART 05 现场跑一遍

用贵司的真实场景当场跑；网络不配合就讲每一格的对应关系。

现在就可以出题

提一个贵司真实问题，我们用同构场景跑同一问。

SO WHAT架构图谁都会画，跑得起来的只有一种 —— 先把信用提前支取。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 零售智脑茶饮场景库真实输出；门店数与口径为示例数据，非蜜雪通实际数据
03
我们是谁EXHIBIT 21.5 min

15 年，四个阶段 —— 最后一步是亲手砍掉自己的生意

2010–2015
数据分析服务
Google Analytics ／ 营销 ／ 社交媒体分析
学到：客户要的是即时洞察，不是月报
2015–2020
CRM 与数据打通
App 分析 ／ CRM ／ 数据仓库
学到：看板采用率只有 10–30%，业务团队仍回 Excel
2020–2025
数据转型与 BI 实施
口径治理 ／ 看板交付 ／ 报表自动化
学到：70–85% 的项目没交付价值，TCO 是水下冰山
2025
停卖「数据活儿」
改卖答案：AI 对话式经营分析
不再建看板，把答案送进团队已经在用的 IM
今天香港为基地，大湾区与内地交付 · FDE 模式 第三方认可Marketing Magazine 营销卓越大奖 2012／2013／2014（数据营销 · 数字营销 · 移动营销 · 整合媒体）· ICT Award 2012 TVB ／ PCM 专访
SO WHAT我们不是从 AI 热潮里长出来的公司，是从 15 年失败的看板项目里长出来的。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: Beehive Strategy 公司沿革与公开获奖记录；采用率与项目失败率为行业公开研究区间，非承诺值
04
交付记录EXHIBIT 41.5 min

15 年、六个行业、50+ 品牌 —— AI 阶段的边界，我们如实标注

金融 · 保险

AXA
Manulife 宏利
Zurich 苏黎世
ING
MSIG
Schroders 施罗德
HKBEA 东亚银行
HKIoD 董事学会

零售 · 消费品牌

Nike
New Balance
Timberland
Lee Jeans
KFC
Chow Sang Sang 周生生
Mabelle
Stuart Weitzman
Kapok
Strawberry.net

科技 · 电信 · 媒体

HKT
HKBN 香港宽频
SmarTone
Now TV
Viu
Apple Daily
ELLE
PR Newswire
Hotmob
DTV Asia

地产 · 酒店 · 文旅

Swire 太古
Sino 信和
New World 新世界
Regal 富豪
Landmark East
LCX
Ocean Park 海洋公园
West Kowloon 西九
HKTB 旅发局

物流 · 贸易 · 招聘

FedEx
Jebsen 捷成
Li & Fung 利丰
TDC 贸发局
Hong Kong Airlines
JobsDB
Maxim Recruitment
AnyMind

公营 · 教育 · 非营利

HKUST 科大
VTC
YCIS 耀中
HKMU 都会大学
HKAF 艺术节
Greenpeace 绿色和平
WWF 世界自然基金会
YCCC
TNC

2025– · AI 阶段的交付，分档标注

已部署 Uni-China（建華）香港鲜肉零售网络
POC Manulife HK 审计 · Bar Pacific ERP 接入
方案 HKMU ｜ HKIoD ｜ 腾讯智慧零售 ｜ SOGO

我们不会做的事

拿别家客户的数据来讲贵司的故事。能点名的都是已授权或已进入公开流程的。

SO WHAT15 年说明我们进得去大公司、守得住合规；AI 阶段的交付边界，我们主动标出来。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 品牌清单取自 Beehive 过往服务记录（ Clients 目录，共 60+ 家）；AI 阶段按实际进展分档，未成交不列为已交付
05
四道断层EXHIBIT 51.5 min

贵司在项目背景里写下这四道断层 —— 我们一字不改放在这里

断层一 · 查数难

经营人员需逐系统、逐报表查找数据，流程繁琐、操作复杂，大量时间耗在「找数据」而不是「用数据」，高频问题反复人工查询。

断层二 · 分析与执行脱节

分析结论靠人记、工单靠人建，从「发现问题」到「解决问题」链条长、易遗漏、难追踪。

断层三 · 不闭环

能力分散、需跳转外部工具；计划执行与效果反馈数据未完全回流，经营经验沉淀在个人，难以规模化复用。

断层四 · 不安全

既有系统多仅做前端入口权限拦截，接口层缺少权限校验 —— 「人来操作」时代够用，一旦由 AI 代操作即为越权漏洞。

SO WHAT这四条不是我们归纳的，是贵司自己写的 —— 它们是同一条链上的四个断点，补一个不够。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 逐字引自贵司《蜜雪通 AI 化项目介绍与背景方案》§1.2「当前痛点：数据到行动之间的四道断层」
06
现状与目标EXHIBIT 61.5 min

终点贵司已经画好了 —— 我们交付的是从起点到终点的那条路

维度现状（贵司原话）目标（贵司原话）
查数逐系统逐报表翻找，依赖固定报表与记忆路径自然语言秒级问答，口径与 BI 页面一致
报告人工取数整理撰写，耗时且口径不统一一句话触发，分钟级异步生成，模板统一、结论有据
异常处置靠人逐店排查、人工建单跟进异常自动定位并生成建单建议，人工确认后直达工单执行流
经验沉淀优秀方法在个人脑中，难复制异常判断与报告模板资产化，可维护、可回归
安全前端入口权限拦截，接口层缺少鉴权权限下沉到接口层、前后端一致，AI 不越权、动作全留痕

右边这一列，就是我们今天要承诺的验收项

贵司已经把验收标准写进材料了 —— 我们不需要另发明一套，只需要把每一项变成可测的数字。

SO WHAT贵司写给自己的目标，就是我们签字的验收表 —— 这能省掉一整轮「什么叫成功」的谈判。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 现状 / 目标两列逐字引自贵司背景方案 §2.4「目标基线：从现状到目标的可感知变化」
07
断层现场EXHIBIT 72.0 min

从「发现问题」到「解决问题」—— 中间那一段没有人负责

  1. Day 1　经营顾问巡店发现异常，群里问一句：这 62 家店怎么了？
  2. Day 3　拿到一张表 —— 口径和上周那份对不上。
  3. Day 6　自己拼 Excel，缺的那一段还得再找人要。
  4. Day 8　有结论了，要走审批才能发到 62 家店。
  5. Day 9　门店收到一条没有上下文的通知。
0 2 5 7 10 一个经营问题从被提出到被执行：9 天 +2 天 T1 取数 +2 天 T2 口径对齐 +3 天 T3 归因分析 +2 天 T4 决策执行 9 天 合计

这 9 天里，真正在「分析」的不超过 2 天

其余全是 等排期 · 找口径 · 对数字 · 搬数据 · 走审批 —— 正是贵司写的「链条长、易遗漏、难追踪」。

SO WHAT问题不在人不够努力，也不在系统不够好 —— 是系统之间那一段没人负责。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 场景为基于贵司四类角色工作流与同类连锁经验的示意还原，非蜜雪通内部实录；天数待第 10 个工作日实测
08
能力边界EXHIBIT 81.5 min

贵司不缺系统 —— 缺的是系统之间那一层

能力覆盖：我们不争 T1，争的是 T2–T4 承接后 观远现状 T1 指标问数 78 分 85 分 T2 多源事实拼接 88 分 42 分 T3 工单闭环执行 90 分 25 分 T4 企微内交付 92 分 55 分 T5 权限与审计 86 分 70 分 T1 观远 85 < 我方 78 —— 这一格属于它；T2–T4 是它的产品边界之外

观远已经很强的那一格

T1 指标问数：观远 85 分，比我们做得好。这一格属于它，我们不碰。

贵司原话，我们完全同意

「查数能力已有雏形，但尚非系统原生 —— 体验割裂、不可编排、难以在系统内扩展为业务闭环。」

今天没人负责的那几格

T2 多源事实拼接 · T3 工单闭环 · T4 工作台内交付 —— 散落在几个系统和几个人之间。

SO WHAT我们不和观远争同一格 —— 「问数」这格已经填满了，「闭环」这格还空着，而它只能长在蜜雪通里。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 中间卡引自贵司背景方案 §1.1；能力评分为 Beehive 内部对同类项目自建评测集的相对打分，非第三方基准
09
三个 AgentEXHIBIT 121.5 min

三个 Agent 各占一格：右下角那格我们故意空着

三个 Agent 各占一格：右下角那格故意空着 Agent ① 问数（读 · 受控口径） · 只走已登记口径，SQL 编译期注入行级策略 · 答不上来就说答不上来，不生成近似值 · 每条答案附 SQL 与口径版本 Agent ③ 闭环（写 · 受控动作） · 只写白名单动作：建单 / 派单 / 改状态 · 写前二次校验，写后留痕可回滚 · 金额与权限类动作一律人工确认 Agent ② SOP 值守（读 · 开放文本） · SOP 版本库 + 执行证据逐条比对 · 偏差分级：提示 / 限期 / 升级 · 答案必须带 SOP 条款引用 右下格：我们不做 · 开放生成 + 自动写入 = 幻觉直达生产系统 · 这一格空着，是设计，不是缺口 只读 可写回 开放生成 受控口径

右下格为什么空着

开放生成 + 自动写入 = 幻觉直达生产系统。这一格空着，是设计，不是缺口。

SO WHAT我们不做的那一格，比我们做的三格更能说明专业度。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 能力边界为 Beehive 自主设计约束，非行业强制标准
10
数据源EXHIBIT 151.5 min

数据源只有观远 BI 一个 —— 我们不打算建第二个

数据只有一个口（观远）；蜜雪通是执行通道，不是第二个口 L1 · 观远 BI —— 唯一数据源与唯一口径 业绩 / 巡检 / 工单等已治理数据集，任何数字都回这里查 L2 · 蜜雪通 —— 执行与交付通道 工单读写最小集（白名单 + 评审）+ 门户嵌入 —— 不存口径、不落数 L3 · 业务系统 ERP / POS / WMS / CRM —— 已汇聚进集团数仓，经观远治理，不再直连 L4 · 协同与文档 企微会话 / 会议纪要 / 邮件 —— 决策上下文 L5 · 外部环境 天气 / 外卖平台 / 商圈客流 —— 归因的外生变量

口径层 · 观远 BI（唯一）

贵司的硬门槛写得很清楚：数据源仅观远、口径统一可溯源、不新建数仓、不重复治理。我们照做。

执行通道 · 蜜雪通 MCP

蜜雪通开放的不是数据源，是工单读写最小集（白名单 + 需求评审）—— 让结论变成工单并追到关闭。

我们自建的是编排层，不是数据层

明细与口径都回观远查；我们做的是「问数 → 报告 → 建单 → 回流」的编排、留痕与评测。

SO WHAT口径只有一处，事实可以来自五处 —— 但必须有且只有一个地方能写回去，而且每一笔都留痕。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 对齐贵司背景方案 §3.1 数据要求：数据源仅观远 BI，口径统一可溯源，不新建数据仓库
11
模型与安全EXHIBIT 171.5 min

不是选一个模型 —— 是按数据密级分流

模型调用按数据密级分流：不是选一个模型，是选一条路 高敏 · 经营事实 门店销售 / 加盟商分成 / 成本 / 未公开指标 中 · 已脱敏指标 区域汇总 / 对外口径 / 已发布报表 低 · 公共知识 SOP 条款 / 制度文档 / 培训材料 自建治理与路由层 · 部署于贵司 VPC 密级标签由服务端强制写入，前端改不了 按团队与 Agent 设配额上限，触顶前告警 每请求计量、归因、留痕，可导审计 策略强制 · 越界即拒 私有化后端 · 数据不出内网 TCE 专有云 VPC · 混元私有化 密级 高 / 中 → 仅内网 云端后端 · 境内合规 腾讯云 TokenHub MaaS（广州站点）· 混元 / DeepSeek / GLM / Kim 密级 低 → 可云端 路由规则写成策略、由网关在每个请求上强制执行 —— 越界请求直接拒绝并告警，不依赖人工自觉

越权数据从未进入模型上下文

行级策略在 SQL 编译期注入 —— 这是可测的，不是承诺。

SO WHAT路由规则写成策略、由网关在每个请求上强制执行 —— 不依赖人工自觉。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 腾讯云 TokenHub（MaaS）为腾讯云产品，Beehive 不转售；私有化与路由层由 Beehive 在贵司 VPC 内建设并移交
12
路线图EXHIBIT 191.5 min

35 周，三道门：API 对接前置，SOP Agent 与问数并行

35 周排期：API 对接前置，SOP Agent 与问数并行 W0 W4 W8 W12 W16 W20 W24 W28 W32 门 ① 数据定案 门 ② M1 达标 门 ③ 推广决策 P0 · 基线评估 蜜雪通 API 对接与鉴权 M1 · 问数链路（含多源） M2 · SOP Agent M2 · 闭环建单与回写 M3 · 推广与托管移交

门 ① 在第 6 周 —— 这是最晚的止损点

口径与数据源没定案，不进 M1；此时贵司投入可核、可停。

SO WHAT排期的关键不是 35 周，是第 6 周就有一个能叫停的点。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 排期为同类项目经验推演，最终以 SOW 与贵司资源到位时间为准
13
现场演示2.0 min

这不是架构图 —— 现在就跑给你看

零售智脑 · 茶饮场景库

7 年历史数据，26 个 CEO 常见问题全部跑通：杯量归因 · 缺货预警 · 加盟商对标 · SOP 偏差扫描。

现场三段（建议顺序）

① 群里问一个归因问题 → 看三条归因 + 建议
② 展开 SQL 与口径版本 → 看它怎么被质疑
③ 让结论变成一张工单 → 看最后一百米

跑不动时的兜底

网络不给面子，就翻下一页 —— 讲每一格在蜜雪的对应位置，不讲架构图。

请评委现在出题

现场可以提一个贵司真实问题，我们用 demo 数据跑同构的那一问。

SO WHATDemo 不是为了证明我们聪明，是为了证明这件事今天就能跑。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 零售智脑为 Beehive 自建演示环境，数据为茶饮行业示例数据，非蜜雪通数据
14
同构案例EXHIBIT 201.5 min

Uni-China（建華）：和蜜雪同构的香港项目

哪里同构

多层级门店网络 + 加盟/自营混合 + 强 SOP 约束 + 生鲜时效 —— 和蜜雪的门店结构是同一类问题。

机制一 · 口径登记

多套口径收敛到一处、版本可追溯。群里争的不再是谁对，是哪个版本。

机制二 · IM 内交付

答案带 SQL 与口径版本，可在群里被质疑、被展开、被转发。不另开一个门户。

机制三 · 越权拦截

行级策略在 SQL 编译期注入 —— 越权数据从未进入模型上下文，可测，不是承诺。

关于数字：我们主动不在这里给

实测处理耗时（部署前/后）在 NDA 之后单独提供。第 10 个工作日我们会给你你自己的 before / after —— 那个数字你才会信，我们也才敢让它进验收表。

SO WHAT案例的价值在机制被验证过，不在数字好看 —— 连举证方式都交给贵司定。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 机制描述基于 Beehive FDE 方法；本页不含任何未实测的效果数字
15
替代方案EXHIBIT 211.5 min

四条路都摆出来：包括「什么都不做」

选项做不到什么代价 / 风险
① 什么都不做9 天延迟继续；一线继续拼 Excel；SOP 继续靠抽查 每年累积，没有终点
② 观远扩展范围跨域拼装与执行回写不在其产品边界内 周期与条件由对方定
③ 自建团队需同时招齐数据 + 后端 + 算法；SOP 语义没人写 6–9 个月成型，试错自担
④ 我们承接闭环不碰 T1 问数，不替代观远 10 个工作日先测，不达预期可停

把「什么都不做」放进表里，因为它是真正的对手

其余三条在争第二名。而它在多数评审会上赢，不是因为对，是因为它没有必须今天就回答的问题。

SO WHAT我们替贵司把三个替代方案都写了 —— 包括对自己不利的那一栏。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 选项对比基于公开产品边界与同类项目经验；观远部分以公开资料为准
16
下一步EXHIBIT 221.5 min

三步：先测，再定，再建

第一步 · 10 个工作日

给 NDA + 数据集目录 + 口径文档。
产出：贵司真实的延迟天数与年化区间，一行数。

第二步 · 定范围

基于第一步的数，定做不做、做哪几格、验收线写在哪。

第三步 · 才谈怎么建

排期、编制、费用 —— 都在数字出来之后谈。

今天只需要贵司回答三件事

① 蜜雪通 API 的接口人和开放时间表 ｜ ② 谁能签 NDA 并给数据集目录 ｜ ③ 90 天后谁来判定这件事成不成

SO WHAT今天不谈价格。先花 10 个工作日把移动的靶钉成数字，再决定要不要建。
BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用
Source: 三步推进为 Beehive 建议流程；第一步交付物与判定人以 SOW 约定
17
BEEHIVE STRATEGY

把移动的靶，钉成数字

10 个工作日，贵司会拿到一个属于自己的数字 —— 到那时再决定要不要建。谢谢。
联系人Kenneth Kwok · Founder
邮箱kenkwok@beehivestrategy.com
基地香港 · 大湾区 · 内地交付
下一步NDA + 数据集目录 + 口径文档

问答

BEEHIVE STRATEGY · 机密 · 仅供蜜雪通 AI 化项目评审使用19

演讲者讲稿


30 分钟 · 精简版