AI Product / 2026.06 –

AI门店CEO · AI Store CEO Workbench

From daily reports to an AI store CEO: a multi-agent operating architecture for restaurants.

PLANNEDAgent / Skill 均为规划中原始状态：concept

面向茶饮 / 餐饮门店的 AI 经营督导工作台：从 AI 经营日报切入，演进为 CEO Agent 统筹 8 个职能子 Agent 的多智能体运营架构。五层架构 / 10 项 Skill / 8 张核心表 / V1–V6 价值递进路线；Agent 与 Skill 均为规划中，已落地三源文档体系 / 飞书同步脚本 / 系统全景白板；Metrics 仅限文档与工程产物事实。

我的角色 AI Product Manager / Product Builder

AI门店CEO · AI Store CEO Workbench · 原始封面 — 产品架构逻辑图（依据项目母文档绘制，非运行截图）：五层架构 × CEO Agent + 8 职能子 Agent；Agent / Skill 状态均为「规划中」

THE PROBLEM / 问题

遇到了什么问题

普通报表只回答「数字是多少」，不回答「昨天经营好不好、今天该做什么、谁来做」
异常的门店 / 渠道 / 时段 / 商品要靠人翻数字找，人工汇总占用店长与老板的时间
数据散在美团管家 / POS / 外卖平台 / 截图 / 群聊，难以进入统一判断
日报建议没有「具体动作 + 负责人 + 截止时间」，无法形成执行闭环
动作是否执行、是否有效，缺少追踪与效果复盘

先看看项目背景

AI门店CEO / AI门店督导工作台：面向茶饮 / 餐饮门店的 AI 经营督导工作台，不是普通报表工具。项目 2026.06 启动，从「AI 经营日报」切入，最终演进为「AI 门店 CEO 多智能体运营架构」——AI 负责分析、调度、督导与增长，人从「写日报的人」转变为「提供现场变化的传感器」。当前阶段：数据盘点 + 经营日报 V1 + 飞书协同验证（半自动，1–2 家门店 30–90 天数据试跑）。Mars 的角色：Product Design（V1–V6 价值递进路线）、Architecture Design（五层架构 / CEO Agent + 8 职能子 Agent）、Data Modeling（8 张核心数据表设计）、Knowledge System（三源文档体系 / 一个事实源 → 四个载体 / Wiki × Skill × Agent 知识复利机制）、Feishu Integration（PROJECT.md → 飞书同步脚本 / 系统全景白板）。

THE APPROACH / 方案

我怎么拆解它

Product Question: Can an AI store CEO turn daily data into a closed loop of "anomaly → action → review", rather than another report? 核心信念：经营管理的价值不在「知道数字」，而在「数字 → 异常 → 动作 → 复盘」的闭环速度。实现路径：确定性规则负责数字计算与异常判断（数据中台与规则层），AI 只负责解释、总结、建议与调度（AI CEO 调度层）；先以「数据分析官 + 门店督导官」两个 Agent 跑通最小闭环（异常 → 动作），其余 Agent 随阶段逐步开启。

THE WALK / 流程

一步步，怎么走

V1 · AI 经营日报 — 可信日报 + 异常 + 今日动作 · 当前阶段（半自动验证中）
V2 · 经营看板与模拟器 — 趋势可视化 + What-if 经营模拟 · PLANNED
V3 · AI 督导 Q&A 与门店知识库 — SOP / 经验沉淀，可对话查询 · PLANNED
V4 · 商品上下架视觉巡检 — 截图识别上下架与陈列异常 · PLANNED
V5 · AI 门店 CEO 多智能体系统 — CEO Agent 调度闭环 · PLANNED
V6 · 多门店复制与平台化 — 排名 / 健康评分 / 平台化 · PLANNED

THE STRUCTURE / 架构

让系统站得住

① 数据输入层 — 美团管家 / POS / 外卖平台 / 小程序 / 门店截图 / 库存损耗 / 排班 / 天气节假日 / 群反馈（现阶段人工导出为主，平台 API 合规后置）
② 数据中台与规则层 — 清洗对齐口径 → 经营事实表；所有数字计算走确定性规则，异常规则产出异常事件表
③ AI CEO 调度层 — CEO Agent 看全局 / 判优先级 / 分发任务 / 汇总复盘 + 8 个职能子 Agent + 10 项 Skill（AI 只解释，不算数）
④ 业务执行与交互层 — 飞书群推送 / 任务分发与回收 / SOP Q&A / 截图上传；人是「传感器 + 执行者」
⑤ 管理价值层 — 经营日报 / 看板 / 多门店排名 / 门店健康评分 / 动作效果复盘

THE NUMBERS / 指标

数字说到哪，就停在哪

指标、描述与来源按原始资料保留。TBD 代表尚未提供；模拟数据、规划中与工程产物统计不转换为业务成效。

职能子 Agent 架构设计: 8 个
Skill 能力规划: 10 项
核心数据表设计: 8 张
产品演进路线: V1 – V6 · 6 阶段
母文档版本迭代: v0.1 – v0.6 · 6 个版本
文档体系载体: 4 个

THE RECEIPTS / 证据

把证据摆上来

项目母文档（技术事实源 · revision 20）——定位 / 目标 / V1–V6 路线 / 五层架构 / CEO + 8 Agent / 10 Skill / 8 表 / 项目原则的完整体系 — VERIFIED（文档体系）
来源：Mars 授权来源（任务评论 7692398052753034451 + 决策点 7692398376230325231），2026-10-03 读取
查看证据原文 ↗
系统全景白板（五层架构 / CEO×8 子 Agent / 三源知识底座 / 知识复利流程 / 能力现状可视化）— VERIFIED（已落地）
来源：项目母文档（技术事实源 · revision 20，2026-10-03 读取） §9.5 系统全景白板（随项目演进更新）
查看证据原文 ↗
三源文档体系 + 飞书同步脚本（PROJECT.md → 飞书文档单向覆盖同步，doc token 存 .env 不入仓库）— VERIFIED（工程产物）
来源：项目母文档（技术事实源 · revision 20，2026-10-03 读取） §9 飞书同步方案 / §9.5 三源分工与同步脚本单一职责
当前阶段：数据盘点 + 经营日报 V1 + 飞书协同验证——1–2 家门店 / 30–90 天数据，半自动流程（人工导出 / 截图输入 → 自动分析 → 人工校验）— 当前阶段目标（进入 V2 标准：店长 / 老板认可「日报准、动作有用」）
来源：项目母文档（技术事实源 · revision 20，2026-10-03 读取） §3 当前阶段
边界声明：CEO Agent 与 8 个职能子 Agent、10 项 Skill 状态均为「规划中」；8 张核心数据表为字段初版草案 — PLANNED
来源：项目母文档（技术事实源 · revision 20，2026-10-03 读取） §6 各 Agent「当前状态：规划中」/ §7 Skill 状态列 / §8 字段草案声明
边界声明：母文档未提供任何经营效果 / ROI / 收入 / 效率指标；本案例 Metrics 仅限文档与工程产物事实，不含业务 KPI
来源：Anti-overclaim 边界（依据母文档全文核对：无任何落地经营数据）

原始来源

https://dcn15px0ltnq.feishu.cn/docx/Ns09dZkR9oT6qcxdfCpcVgHznSh https://www.feishu.cn/docx/DUQidYvz5or8L3xohMUcUE5Fneh

展开完整证据记录与能力边界（原文）

背景: AI门店CEO / AI门店督导工作台：面向茶饮 / 餐饮门店的 AI 经营督导工作台，2026.06 启动，从「AI 经营日报」切入，演进为「AI 门店 CEO 多智能体运营架构」。当前阶段：数据盘点 + 经营日报 V1 + 飞书协同验证（半自动）。Mars 角色：AI Product Manager / Product Builder —— Product Design（V1–V6 演进路线）、Architecture Design（五层架构 / CEO + 8 子 Agent）、Data Modeling（8 张核心表）、Knowledge System（三源体系 / 四载体 / Wiki × Skill × Agent）、Feishu Integration（同步脚本 / 系统全景白板）。
问题: 普通报表只回答「数字是多少」；门店真正需要的是「昨天好不好、哪里出了问题、今天做什么、谁来做、做完有没有效」。数据散在多源难以统一判断，异常靠人翻数字，建议没有负责人与截止时间就无法闭环，动作效果无法复盘。
证据: 母文档（技术事实源 revision 20）与系统全景白板（已落地）。文档与工程产物事实：8 个职能子 Agent 架构设计、10 项 Skill 规划、8 张核心数据表设计、V1–V6 六阶段路线、v0.1–v0.6 六个版本记录、四载体文档体系与飞书同步脚本。
假设: Product Question: Can an AI store CEO turn daily data into a closed loop of "anomaly → action → review", rather than another report? 核心假设：经营管理的价值在闭环速度而非数字本身；AI 的位置在确定性规则之后——只解释、总结、建议、调度。
产品判断: A 数字计算走确定性规则，AI 只解释不算数；B 先半自动验证价值再自动化（准确性达标前不追求全自动）；C 不直接依赖平台官方 API（合规与稳定性风险后置）；D 不做复杂 SaaS（无账号体系 / 计费 / 多租户）；E 数据合规获取 + 脱敏 + 最小授权；F 每个异常必须转成动作 + 负责人 + 复盘指标；G 先以「数据分析官 + 门店督导官」跑通最小闭环，其余 Agent 随阶段开启。
能力与状态边界: VERIFIED（已落地）：三源文档体系（PROJECT.md / AGENTS.md / SKILLS.md）、飞书同步脚本（PROJECT.md → 飞书文档单向覆盖，token 存 .env）、系统全景白板、四载体策略、Wiki 认知层目录与模板。PLANNED：CEO Agent + 8 个职能子 Agent（全部规划中）、10 项 Skill（全部规划中）、8 张核心数据表（字段初版草案）、日报 V1 模板（待办未完成）。
验证: 当前阶段实验设计：以 1–2 家门店、最近 30–90 天数据，跑通「人工导出 / 截图输入 → 自动分析 → 人工校验」的半自动流程，在飞书群协同验证日报的准确性与管理价值；进入 V2 的判断标准是店长 / 老板认可「日报准、动作有用」。
结果: 本项目当前可被可靠地描述为：已完成体系化产品架构设计（五层架构 / CEO + 8 子 Agent / 10 Skill / 8 表 / V1–V6 路线）与文档工程基础设施（三源体系 / 飞书同步 / 系统白板 / 知识复利机制）的 AI Product 规划阶段案例。不能描述为：已上线运行的多智能体系统、已验证的经营效果、已自动化的日报生产。Agent 与 Skill 状态均为「规划中」。
变化: 迭代路径：v0.1 建立母文档（定位 / 路线 / 架构 / Agent / Skill / 表 / 原则）→ v0.2–v0.4 四载体同步策略与 token 治理（真实 doc token 移入 .env 并加占位校验）→ v0.5 项目情报雷达自动化任务设计 → v0.6 知识复利机制（Wiki × Skill × Agent 认知层 + 脱敏纪律）。关键取舍：不做 SaaS、不依赖平台 API、不追求全自动——先把「半自动验证价值」做实。
学到的: 数字 → 异常 → 动作 → 复盘的闭环速度，是经营管理真正要优化的指标；Facts & Rules before AI 同样适用于门店：确定性规则算数，AI 只解释；多智能体不必一次建全——先以最小闭环（数据分析官 + 门店督导官）验证，再扩展；一个事实源 → 多个展示载体，让 AI / 老板 / 店长 / 客户各得其所。

THE TAKEAWAYS / 学到的

走过以后，留下什么

经营管理的价值不在「知道数字」，而在「数字 → 异常 → 动作 → 复盘」的闭环速度
数字计算走确定性规则，AI 只负责解释、总结和建议——指标、同环比、阈值由规则引擎算，大模型不算数
先半自动验证价值，再逐步自动化：准确性与管理价值未被验证前，不追求全自动
每个异常都要能转成动作、负责人和复盘指标——不产生「只报不管」的数字，闭环优先
数据通过合规导出 / 截图 / 授权方式获取，不记录账号密码、不绕过平台权限；客户经营数据脱敏与最小授权
一个事实源 → 四个载体：PROJECT.md 唯一事实源，飞书文档 / HTML 驾驶舱 / 白板各司其职，避免双源冲突