Restaurant BI / Daily Agent
From daily reports to trusted operational intelligence.
从餐饮日报自动化到可信经营事实：截图/Excel → 校验 → Production Gate → 多门店事实层 → Dashboard → AI 经营分析；全部指标为工程产物统计（非业务 KPI），能力逐项标注 VERIFIED / PARTIAL / PLANNED。
我的角色 AI Product Manager / Product Builder
THE PROBLEM / 问题
遇到了什么问题
数据散在截图 / Excel / 群聊，缺少统一的结构化入口 业务日期容易被系统日期覆盖，污染历史数据 空值、零值、公式错误、未适用字段容易被混成一个数字 同一门店同一天可能重复导入，报表口径不一致，结论难以追溯到原始数据 AI 直接建立在未经校验的数据上，会把识别错误放大成经营建议 日报即使有建议，没有负责人、时间、目标与次日反馈，就没有形成执行闭环
先看看项目背景
Restaurant Daily Agent：把餐饮门店的日报截图 / Excel 转换为可校验、可追溯的经营事实，再生成日报、周报、Dashboard 与 AI 诊断的经营数据工作流。真实项目时间 2026.05 – 2026.08（V2 为本地四门店快照），持续验证中。核心叙事不是「我做了一个餐饮 Dashboard」，而是从自动生成日报，逐步演化为可信经营事实 → 数据校验 → Production Gate → 多门店 BI → AI-assisted operational analysis 的产品实验。Mars 的角色：Product Design（定义「日报输入 → 经营决策支持」的产品演化）、Data Modeling（V1 字段映射 / V2 六类事实表 / 指标字典 / 空值与公式错误语义）、Workflow Design（watcher / 日期治理 / staging / audit / production commit）、AI / Agent Design（AI 诊断置于结构化事实之后，保留人工复核与门禁）、BI / Dashboard（周报融合看板 / Dashboard V2 本地构建与 acceptance）、Engineering Coordination（仓库内 Python、测试、脚本与文档的实现与协调）。技术只是产品验证和实现手段，不是案例重心。
THE APPROACH / 方案
我怎么拆解它
Product Question：Can AI turn daily restaurant data into trusted operational decisions rather than another dashboard? V1 假设：Existing Report → Structured Data → Daily Report → Weekly Report。把门店已有截图/Excel 转成固定结构，自动生成日报/周报并推送，减少重复整理。 V2 假设（升级）：Raw Data → Trusted Facts → Validation → Production Gate → Dashboard → AI Analysis。在 AI 判断之前必须先建立可信事实层，否则 AI 结论不可信。项目假设从「自动做日报」升级为「AI 判断之前必须先建立可信事实」。
THE WALK / 流程
一步步，怎么走
- V1 · Single-store Daily Agent — 截图/Excel → 标准 Excel → 日报/周报 → 推送与历史沉淀 · VERIFIED
- Business Date Governance — 业务日期与处理日期分离、重复导入与污染防护 · VERIFIED / PARTIAL
- Facts Layer — 日期维度、事实表（V1 单店 / V2 六类事实表）· VERIFIED
- Weekly Dashboard — 自然周周报 + 缺失日期提示 + 融合看板 · VERIFIED（本地产物）
- V2 · Multi-store Data Model — 四门店 schema、事实表、语义层 · VERIFIED（本地快照）
- Staging / Audit — 批次、来源、MD5、OCR confidence、审计模式与生产模式分离 · VERIFIED
- Production Gate — 只提交 PASS / WARNING，阻断 REVIEW_REQUIRED · VERIFIED
- Dashboard V2 — 正式构建器 + 静态 acceptance · VERIFIED（静态）/ PARTIAL（浏览器运行态）
- Decision / Action Loop — FACT → INSIGHT → DECISION → ACTION → RESULT · PLANNED / NEXT
THE STRUCTURE / 架构
让系统站得住
- Screenshot / Excel（门店现有日报）
- Intake — 本地目录 watcher / 人工截图来源（微信入口仅历史文件路径，未形成稳定 API · PARTIAL）
- Staging — 批次 / 来源 / MD5 / OCR confidence / review reason
- Validation — 日期 / 门店 / schema / 键 / 数值 / NULL-FORMULA / 来源冲突
- Production Gate — 只提交 PASS / WARNING，阻断 REVIEW_REQUIRED
- Fact Layer — 六类事实表（store / zone / package / promotion / review / product）+ 来源 lineage
- BI / Dashboard — Dashboard V2（本地构建 + 静态 acceptance）
- AI Analysis — AI diagnosis / AI-assisted operational analysis，位于可信事实层之后，HUMAN REVIEW 保留 · PARTIAL
- Action / Feedback — 尚未形成生产闭环 · PARTIAL / NEXT
THE NUMBERS / 指标
数字说到哪，就停在哪
指标、描述与来源按原始资料保留。TBD 代表尚未提供；模拟数据、规划中与工程产物统计不转换为业务成效。
- Daily Facts 记录
- 68 行
- 日报结构化产物
- 49 个
- 周报融合产物
- 6 组
- V2 四门店快照
- 4 门店 · 458 records · 300 metrics
- 单店历史序列
- 52 行
- 门禁阻断验证
- 4 / 4 门店
单店事实表沉淀行数 · P0 仓库审计 · 工程产物统计（非业务 KPI）· 业务日期 2026-06-01 ~ 2026-08-17
自动生成的结构化日报 JSON 产物 · P0 仓库审计 · 工程产物统计（非业务 KPI）
自然周周报 HTML/PNG + 基础周报 Dashboard · P0 仓库审计 · 工程产物统计（非业务 KPI）
四门店事实层 / Dashboard V2 本地快照规模 · P0 仓库审计 · 本地快照统计（非业务 KPI）· 最新业务日期 2026-08-19
便宜坊马连道门店历史数据序列 · P0 仓库审计 · 工程产物统计（非业务 KPI）· 2026-05-24 ~ 2026-07-16
Production Gate 生效的直接证据（产品机制，非业务 KPI）· 2026-08-20 审计批次：4 门店全部 REVIEW_REQUIRED，未进入生产事实
THE RECEIPTS / 证据
把证据摆上来
- daily_facts 68 行，业务日期 2026-06-01 ~ 2026-08-17 — VERIFIED（产物统计）· Source: P0 仓库审计 · daily_facts 事实表产物统计（工程产物统计，非业务 KPI）
- 日报结构化 JSON 产物 49 个 — VERIFIED（产物统计）· Source: P0 仓库审计 · 日报结构化 JSON 产物清点（工程产物统计，非业务 KPI）
- 周报融合 HTML/PNG 产物 6 组 — VERIFIED（本地产物）· Source: P0 仓库审计 · 自然周周报产物清点（工程产物统计，非业务 KPI）
- 四门店 V2 快照：4 门店 / 458 条 production records / 300 行 metrics，最新业务日期 2026-08-19 — VERIFIED（本地快照统计）· Source: P0 仓库审计 · V2 多门店 Dashboard 本地静态快照统计（工程产物统计，非业务 KPI）
- 单店历史序列 52 行（2026-05-24 ~ 2026-07-16）— VERIFIED（产物统计）· Source: P0 仓库审计 · store_history 产物统计（工程产物统计，非业务 KPI）
- Production commit（2026-08-18）：PASS · 4 门店，创建 0 / 未变化 102 / 冲突 0 / 阻断 0 — VERIFIED · Source: P0 仓库审计 · Production commit 运行记录（工程产物统计，非业务 KPI）
- 审计批次（2026-08-20）：4 门店全部 REVIEW_REQUIRED，未进入生产事实 — VERIFIED（门禁生效直接证据）· Source: P0 仓库审计 · OCR intake 审计模式运行记录（工程产物统计，非业务 KPI）
- 边界说明：以上均为工程产物统计（P0 仓库审计），不是业务 KPI；审计未提供 ROI、效率提升、收入增长、OCR 准确率、AI 诊断准确率的证据 · Source: RESTAURANT_BI_DAILY_AGENT_CASE_SOURCE_V1.md · Evidence Hierarchy 与 Anti-overclaim Statement
- 外部 Demo：便宜坊马连道日报（马连道销售Demo）页面可访问 — PARTIAL（页面可访问，不代表生产级发布）· 在线 Demo：https://dcn15px0ltnq.doubaoapps.com/app/app_4kdvcqjv319yh · Source: Source Package #2 · 秒搭 Demo 页面可访问性（P1，页面可访问 ≠ 生产级发布）
展开完整证据记录与能力边界（原文）
- 背景
- 餐饮门店每天产生日报截图与 Excel，但数据在进入经营判断之前存在多重不确定性。Restaurant Daily Agent 从单店日报自动化起步（2026.05），逐步演化为具备事实层、数据校验、Production Gate 与多门店 Dashboard 快照的经营数据工作流（V2 本地快照 2026.08），持续验证中。Mars 角色：AI Product Manager / Product Builder —— Product Design、Data Modeling、Workflow Design、AI / Agent Design、BI / Dashboard、Engineering Coordination。
- 问题
- 门店并不缺数据，真正的问题是数据在进入经营判断之前不可信：业务日期被系统日期覆盖、NULL 与零值与公式错误混同、重复导入与口径不一致、结论无法追溯到原始数据；AI 若直接建立在未校验数据上，会把识别错误放大成经营建议；没有负责人与次日反馈的「建议」也无法形成执行闭环。
- 证据
- 工程产物统计（P0 仓库审计，非业务 KPI）：daily_facts 68 行（2026-06-01 ~ 2026-08-17）、日报 JSON 49 个、周报产物 6 组、单店历史 52 行、四门店快照 458 records / 300 metrics（2026-08-19）。Production commit 2026-08-18：PASS · 4 门店（创建 0 / 未变化 102 / 冲突 0 / 阻断 0）。审计批次 2026-08-20：4 门店全部 REVIEW_REQUIRED，未进入生产事实。
- 假设
- Product Question：Can AI turn daily restaurant data into trusted operational decisions rather than another dashboard? V1：Existing Report → Structured Data → Daily Report → Weekly Report（减少重复整理）。V2 升级：Raw Data → Trusted Facts → Validation → Production Gate → Dashboard → AI Analysis（AI 判断之前必须先建立可信事实层，否则 AI 结论不可信）。
- 产品判断
- A 业务日期必须来自源日报（缺失表头日期直接失败，不得为补齐而伪造）；B NULL ≠ ZERO ≠ FORMULA ERROR（识别失败不伪装成 0）；C AI 不能成为事实源（事实表 / 校验 / 审计位于 AI 诊断之前）；D 先 Facts，再 Insight；E Audit Mode 与 Production Mode 分离（OCR intake 可只出审计报告、不写事实）；F Production Gate 阻断不确定数据（失败批次停在 staging / review，不包装成正常生产数据）；G Human-in-the-loop 不是失败，而是处理不确定性的产品机制。
- 能力与状态边界
- VERIFIED：V1 日报工作流、业务日期治理（规则与测试）、事实层（V1 / V2 六类事实表）、自然周周报、四门店数据模型与语义层 schema、来源 lineage（V2）、staging、审计模式、Production Gate、Dashboard V2 静态构建。PARTIAL：AI diagnosis（有代码与提示词，无准确率评测）、微信入口（仅历史文件路径，无稳定 API）、连续无人值守运行、外部 Dashboard 线上状态（Demo 页面可访问）。PLANNED：经营行动闭环（action ledger / next-day feedback，有 schema 设计、无完成产物）。
- 验证
- 以可复核的代码、测试与审计产物验证：Production commit（2026-08-18）4 门店全部 PASS；OCR intake 审计模式（2026-08-20）4 门店全部 REVIEW_REQUIRED、未写入生产事实——直接证明门禁能阻断不确定数据。当前边界：浏览器运行态、连续多批次 acceptance 与外部发布需单独验证。
- 结果
- 本项目可被可靠地描述为：从单店日报自动化演进到具备事实层、数据门禁、来源追踪和本地多门店 Dashboard 快照的 Restaurant Daily Agent 原型 / 工作流。目前不能描述为：已稳定微信群直连、全自动自治 Agent、完整行动闭环、线上多门店 SaaS 或已被业务指标证明有效。全部指标口径为工程产物统计，非业务 KPI。
- 变化
- What did not work（重要产品能力证明，完整保留）：① OCR / VLM 依赖外部模型、代理与配额，记录过连接失败与字段识别不完整；② 微信入口仅历史临时文件路径，未形成稳定 API intake；③ 旧 V1 lineage 不完整，早期解析路径存在把缺失值置为 0 的风险；④ AI diagnosis 缺少正式 evaluation dataset；⑤ action / feedback loop 尚未完成（无完成产物）；⑥ 部分 V2 pipeline 仍绑定具体批次与本地路径，通用化有限；⑦ 持续无人值守运行不成立；⑧ Dashboard 浏览器运行态与外部发布状态未独立确认；⑨ 工作区存在含硬编码凭证的未跟踪实验脚本（未公开，须轮换与脱敏）。
- 学到的
- Restaurant AI 的第一产品不是答案，而是可信经营事实；AI 应建立在事实层之后；人工复核是产品边界而非失败。Next Evolution（PLANNED，非已完成）：Unified Intake Contract、Human Review UI、Action Ledger、Next-day Feedback、AI Evaluation Dataset、Continuous Multi-store Acceptance、Production Runtime Verification。
THE TAKEAWAYS / 学到的
走过以后，留下什么
- Restaurant AI 的第一产品不是答案，而是可信经营事实
- 业务日期、字段语义、缺失值和来源追踪，比生成一段漂亮的 AI 建议更重要
- AI 应该建立在事实层之后
- Dashboard 不只是展示层，它也是「哪些数据可以相信」的界面——保留事实状态、来源与约束
- 人工复核不是失败，而是把不确定性挡在生产事实之前的产品边界
- 真正的终点不是 Insight，而是 Evidence → Decision → Action → Result → Learning
- 产品经理最有价值的能力：把模糊的「智能日报」拆成可验证的输入、事实、校验、证据、洞察与行动边界