从一份营业日报和一位 AI 同事开始，不需要先打通所有系统。
先用门店已有的营业日报：评分、当日评价条数、实收和目标日均。不要求一开始就连接所有系统。
按岗位选同事，比如经营评价助手。它读哪些数据、能做什么、不能做什么，都写在“能力与数据”里。
用店长自己的话问就行。助手把它拆成可核实的问题，列出原始评价、原因假设和还缺的记录。
你确认要共享的标题、提要和证据引用，它才成为一宗团队事项。个人对话不会自动共享。
CaiHub 是面向连锁餐饮的 AI 运营与标准执行系统：整合数据、分析、整改与验收，帮助门店执行标准、改善经营结果。
按各产品的公开定位归类，仅用于说明 CaiHub 的方向。
每位 AI 同事有岗位、有依据、有边界。它们在后台同时工作，需要你拍板的时候才来找你。
AI 同事读完四家店的营业日报，把异常整理成可核实的提要，再交给你审批。数字取自日报，评价原文为示例文本。
评分 4.5，实收 ¥13,600，达成 42%。数字取自门店营业日报，评价原文为示例文本。
日报-D店-1026.xlsx评价原文、营业日报、出餐记录和排班各自标明来源与接入状态。缺的记录写清楚，不让 AI 补造事实。
先用营业日报和点评，再按试点需要接 POS、出餐、排班和采购报价。不要求一开始就连接所有系统。
置顶、标为未读、指派、暂不处理、归档。每一宗事项都留着证据、批准、执行和验收的记录。
AI 同事按时汇报发现，讲清下一步，再问你要不要做。批准不等于已经执行，执行要另留凭证。
好的，已发给陈师傅，等他接单。
店长看本店，主管看本部门，总部看跨店汇总。个人对话不默认共享，越权的动作需要审批。
说一句“每天早上看一遍日报”，就排进本周的检查表。每次检查的结果都回到同一宗事项里。
评价、营业日报、出餐和排班散在不同地方。每条记录都保留来源和时间，也不默认它们已经接通。
看见的人、判断的人、批准的人往往不是同一个。提要、依据和理由放进同一宗事项，交接不靠转述。
AI 起草，人来拍板。批准之后还要接单、执行、留凭证、验收，一句“已完成”不能代替执行凭证。
以餐饮经营闭环为目标的 AI 系统架构：从门店数据到可验证的改善，每一层都留下记录。这是设计稿，各层的实现状态见下方“能力边界”。
采集→清洗→规则校验→人工复核→可信事实表
异常触发→创建任务→状态持久化→消息订阅→重试与恢复
飞书 / 企微任务→店长确认→现场执行→执行回执
独立 Review→结果证据→效果验证→决策记忆→持续优化
经营数据分析、异常发现、整改跟踪。
菜品识别、出品质检、标准合规检查。
AI 产品的竞争，不是单个模型的智能程度，而是数据 × Harness × 业务流程的系统能力。
CaiHub 的差异化，不在于用了多少 Agent 或多强的模型，而在于能否把数据、任务、执行与验收组织成一个可持续改善餐饮经营结果的闭环。
对照原型里的七步闭环 ↗选一个岗位，看它的 AI 同事会汇报什么、准备什么、等你批准什么。
把点评统计和日报异常整理成可核实的提要：现象是什么、还缺什么证据、建议先查哪一件。不自动判定责任。
每个判断都要回到一条记录。下面是本轮原型实际用到的数据，以及还没有接入的部分。
营业日报已接入 · 示例数据 · 2026-10-26四家门店的评分、当日好评与中差评、实收、目标日均和本月达成率。只读，不回写任何系统。在原型里查看两份离线原型都可以直接打开操作。界面里的数据为示例。
客户工作台今天：经营报四店营业日报的 KPI 和本期关注，下一步能直接进入同一宗事项。打开原型 ↗
客户工作台我的助手个人准备空间：提问、查证、预览要交给团队的核实提要。打开原型 ↗
客户工作台团队事项同一宗事项里放着证据、核实方案、审批、执行凭证和验收结果。打开原型 ↗
客户工作台能力与数据哪些能体验、哪些是示例、哪些还没接入，在这里写清楚。打开原型 ↗
产品方向与能力边界 · 第 1 帧让 AI 融入每一个餐饮岗位让个人得到支持，让组织把事情做成。打开原型 ↗
第 5 帧从一句问题，走到一次验收七个步骤分别说明知道了什么、谁接手、怎样退出。打开原型 ↗
第 6 帧个人获得支持，组织完成接力两个回路之间，靠一份由用户确认的结构化事项连接。打开原型 ↗
第 10 帧界面能演示，能力仍须逐项证明当前交付和未来承诺分开写，每项都列出下一份必要证据。打开原型 ↗现在还没有真实客户的证言。下面这些问题，要靠 3–5 家门店的真实任务来回答。
这件事，是不是比以前更容易做成了？
从发现异常到有人接单，中间要等多久？
AI 整理出的数字，第三方能不能独立复算出同样的结果？
新增的填报、审核和纠错，会不会把省下的时间又吃掉？
没执行、没改善、覆盖不全的情况，能不能如实留下来？
哪些规则应该留在单店，哪些需要总部确认？
我在个人助手里说的话，会不会被别人看到？
AI 或数据不够的时候，人工补位花了多久、补了什么？
第二家店能不能沿用同一套口径和流程？
先验证流程能不能在真实约束下跑通，再评估经营效果。门店提供真实的营业日报和评价记录，我们一起记录查证、派活、等待和人工整理各花了多久。
试点的成功阈值要事前约定；使用行为、工作负担和经营效果分开记录。3–5 家店不自动构成因果研究，统计效力与对照条件另行估算。
把本店的异常查清楚，确认后交给对的人。典型的问题是：“最近出餐慢，应该先查什么？”
个人助手给予支持，团队视图接住交接。原型里的角色切换只是演示，完整的四岗位权限尚待工程实现。
扩展靠同一套“证据—判断—行动—验收”结构承接，而不是不断增加新的入口。
第一阶段
要点
后续候选
要点
后续候选
要点
3–5 家门店是后续流程试点的范围，不代表已有客户，也不代表统计上显著的效果。
套餐、定价、获客与毛利尚待验证，不在演示站里给出商业结论。
还没有。本轮是两份离线原型：四家店的营业日报 KPI 是内嵌的示例数据，评价正文是示例文本，POS、出餐和排班都还没有接入。真实接入需要获授权的接口、覆盖率、稳定标识和统一口径。
不会。AI 同事负责整理、起草和提醒；加人、改价、对外回复、对外发布这类真实动作，都要由有权限的人批准。批准也不等于已经执行，执行要另外留下凭证。
默认看不到。只有你确认共享的标题、提要和证据引用会进入团队事项。品牌总部也不默认查看个人的原始对话。
不能承诺。演示里只展示可比较的观察；“观察到改善”不等于因果有效。经营效果要靠真实试点、同口径对照和执行凭证来评估。
能复算的数字用确定性计算，AI 只帮忙整理和解释，不补造缺失的事实。比如“出餐慢主题占比 4/20 = 20%”，分母是这次的评价样本，不能说成全部顾客的投诉率。
不用。先追溯几宗真实事件，从营业日报和评价开始，再按要检验的假设补数据，不要求一开始就连接所有 ERP。
店长看本店；品牌总部看跨店汇总，并能下钻到单店；越权的价格和资金事项需要总部批准。原型里的角色切换只是演示，不等于生产权限。
3–5 家门店，分四步：补基线、按岗位做真实任务、人工补位并留痕、按证据复盘。成功阈值事前约定，驳回、没执行、无改善、覆盖不全这些反例同样保留。