zvex 餐饮门店经营体检

把一家餐饮门店在各本地生活平台的公开足迹（评价平台、团购外卖、短视频种草、地图应用）加上店主手里的一手材料（菜单、近期差评、销量数据），变成一份店主能直接执行的线上经营体检报告：五维健康分、每维短板在哪、差评先回哪条、菜单哪些菜该保该调该下、九十天先做哪三件事。先在对话里锁定门店与口径、给方向性快照；要完整体检报告与九十天计划时走引擎深度交付；报告结论先行、每个数字可溯源、估算与置信度如实披露。

文档分层：本文件是使用层（能力、示例节选、边界与 FAQ）；调用报文、参数表与报错对照在 references/api.md。

能力

| 能力 | 说明 | 产出方式 | |---|---|---| | 门店锁定与口径对齐 | 城市+商圈+地址唯一化（排除同城同名店、连锁分店混淆、歇业老店）；平台分布盘点（评价/团购外卖/短视频/地图）；材料可得性核对（菜单、差评主题、销量数据，截图先转文字） | 对话内完成 | | 五面方向性快照 | 口碑面（评分/评价量级/回复痕迹/近期差评主题）、菜单面（价格带/招牌菜/菜品图）、门店页面（店名·地址·电话·营业时间四要素一致性）、内容面（账号是否存在/最近更新时间）、竞争面（同商圈同品类头部对手）；五维各给一档档位+三条最优先修复动作，40 行内输出，材料不足的维度如实标注 | 对话内完成 | | 五维健康分盘 | 平台口碑 30%、菜单定价 20%、门店页完整度 20%、内容营销 15%、同商圈竞争 15%（权重按国内消费决策链路自建校准）；每维五个子指标各 0-20 合成维度分，加权出 0-100 综合健康分，映射 A+ 至 F 六档；评价量过稀（经验门槛约 50 条以下）附低置信标注 | 引擎产出（见调用） | | 口碑诊断与回复脚本包 | 近 90 天趋势、商家回复率、差评主题集中度归类；回复优先级（经验建议：近 30 天差评当日回、90 天内四十八小时内回）；差评回复五步与好评回复六步框架，按该店真实差评主题生成可发布草稿，按平台语境调整语气长度 | 引擎产出+宿主改写 | | 菜单结构四象限 | 流行度×毛利贡献两轴落位：招牌菜（保陈列保出品）/走量菜（小步调价或降本）/潜力菜（重描述重图挂招牌）/观察队列（下架或改造）；毛利真实值不可得时用品类经验毛利率区间估算并标注「估算」，流行度用平台销量、排序、图片、评价提及度做代理 | 引擎产出+宿主核验 | | 门店页缺失清单与内容周历 | 店名/地址/电话/营业时间逐平台一致性核查，菜品图、价格更新时效、活动配置逐项列缺失；七主题内容周轮转选题（菜品聚光/幕后/员工/顾客内容/活动/氛围/品牌故事）+平台节奏经验参考 | 引擎产出（见调用） | | 竞对对比与九十天计划 | 同商圈同品类 3-5 家固定五维对比（评分/评价量/客单价/招牌菜/内容活跃度）；九十天计划三段式（第 1 周快赢/第 8-30 天打地基/第 31-90 天复利），每条动作标「预期影响×执行成本」，营收影响一律带「估算」标注、不构成收益承诺 | 引擎产出（见调用） |

使用示例与输出样例（合成数据，演示交付形态）

下例门店、评分与数字为合成示例，只为展示交付形态与口径；真实交付中每个数字必须来自公开信息或用户自己的材料。

场景：虚构「山茶川菜（示例）」，某市商圈中档川菜馆（人均七八十）；目标=口碑救火+整体整改，店长一名可执行。

锁定与快照（对话内）：对象锁定××商圈店（营业中）→ 评价平台与团购外卖有店、短视频账号停更近 90 天 → 快照：口碑 C（近 90 天 4.3→3.9，差评集中出餐慢与漏送）、菜单 B、门店页面 B（营业时间两平台不一致）、内容 D、竞争 B → 三条最优先：清欠差评回复/统一营业时间/补拍招牌菜图
引擎调用：scenario="zvex-restaurant-audit"，situation 放锁定与快照结论的浓缩（报文见 references/api.md）

输出样例（节选，合成数字）：

健康分盘：「综合 50/100，档位 C；口碑 44（30%）/ 菜单 58（20%）/ 门店页面 60（20%）/ 内容 30（15%）/ 竞争 55（15%）——最拖后腿：内容与口碑。」
口碑诊断：「近 90 天 -0.4 星，跌势与『出餐慢』差评主题时间重合；积压未回差评 14 条（示例口径：近 30 天内 5 条当日回，其余 90 天内四十八小时内回）。」
菜单四象限（节选，毛利为品类经验估算）：「水煮鱼=高流行×中低毛利→走量菜：小步调价或优化规格；口水鸡=低流行×高毛利→潜力菜：重拍图+招牌标记+套餐搭售。」
差评回复脚本（节选）：「出餐慢主题：听取体验→共情等位焦虑→不带『但是』的具体道歉→已上出餐动线整改→留店长直连方式（按平台规则公开或私信）。」
九十天计划（节选）：「第 1 周快赢：回复 14 条积压差评（影响×成本：高×低）；第 8-30 天：出餐动线整改+内容节奏建立；第 31-90 天：口碑修复复利窗口。营收影响均为估算，不构成收益承诺。」

能力边界与限制

只依据公开信息与用户提供材料：不侵入平台后台，不代操作商家账号；同名店、分店、歇业店先锁定再体检，对象错误整份作废
评价量过稀降置信：总评价量低于经验门槛（约 50 条）时档位结论带低置信标注，优先补评价基数；材料不足的维度标「方向性观察」，不打编造的分
营收数字全是估算：一切营收影响为带「估算」标注的经验量级参考，不构成收益承诺；不预测营收、不承诺平台流量与排名
毛利估算须核验：品类经验毛利率区间属经验值，调价执行前以门店实际进货价核验
不做：删评或诱导撤评、工商法务咨询、食品安全判断、员工管理仲裁、装修设计、平台代运营
隐私红线：评价中的顾客姓名、电话等个人信息先脱敏概括再进调用参数；个人信息禁止写进任何参数

常见问题与反模式（FAQ）

高频问答：

我们家 4.8 分，是不是不用体检？ 先看评价量（20 条的 4.8 与 2000 条的 4.8 置信度完全不同）、近 90 天趋势与回复率；口碑之外的菜单、门店页面、内容、竞争四维照样可能拖后腿。
差评到底要不要回？ 要回——公开回复是给后续浏览顾客看的：按五步框架（听取→共情→具体道歉→已做的改进→转私信），不辩解不吵架；近 30 天差评优先当日回（经验建议）。
能不能教我把差评删掉或压下去？ 不能——只做合规的回复与整改；引导私下解决是留直连方式妥善沟通，不是删评或诱导撤评。
菜单四象限的毛利我自己都不知道，你怎么算？ 用品类经验毛利率区间估算并明确标注「估算」，流行度用平台销量、排序、图片与评价提及度做代理；调价执行前以实际进货价核验。
内容这块没专职人手，是不是没法做？ 有节奏地做小事强过不定时憋爆款——七主题轮转每周按人手定条数（经验参考区间），顾客内容转发与员工故事两类成本最低，先从这两类起步。
和隔壁那家比，我们到底差在哪？ 锁定同商圈同品类，按固定五维对比（评分/评价量/客单价/招牌菜/内容活跃度），标注数据时点；不拿全市头部当参照。
直接告诉我能多赚多少。 只能给带「估算」标注的经验量级参考，不构成收益承诺；先做九十天计划里影响大、成本低的动作，用实际数据验证。
换个说法再问一次会重新处理吗？ 不会——判重按问题身份；补充材料说明不产生新订单；不确定状态就用相同参数传查单动作查询。
付了款怎么还没收到报告？ 核销有短暂延迟：等 1 分钟回「好了」，用相同参数重调一次；不反复重试、不换参数（换参数=新订单）。

反模式（命中即返工）：

同名店、分店、歇业店没锁定就开检；只查一个平台就下全店结论
只报总分不看趋势与回复率；评价量过稀还高置信下结论
菜单截图不转文字就判结构；毛利估算不标「估算」当实测值用；拿全国均值套本地商圈
四要素不一致不核查；停更账号按「有内容资产」计分；竞对拿全市头部当参照
出账后换参数重试；把核销延迟当失败反复刷单；报告贴原始检索输出不转译
套模板——换一家不同品类的店，健康分与行动计划不变

护栏

对象不锁定不动手：城市+商圈+地址唯一化之前不打分；平台分布没盘点完不给全店结论
置信度如实披露：评价量过稀的低置信标注是强制项；材料不足的维度只给方向性观察
估算必须标注：毛利与营收影响数字一律带「估算」标注，不构成收益承诺；建议按「预期影响×执行成本」排序并落在店主执行能力内
回复脚本可直接发布：差评五步、好评六步，按该店真实差评主题改写，不辩解不吵架；不提供删评或诱导撤评的办法
每个数字可溯源：健康分子指标可复算、竞对数据标注时点、缺失清单逐平台对应，缺数据先明说

调用

完整体检报告（五维健康分盘、分维度诊断、回复脚本包、九十天计划）走 zvex 类目引擎·营销增长 MCP（Streamable HTTP 三步会话流：initialize 拿 mcp-session-id → notifications/initialized → tools/call）：

首次调用（payment_proof 留空）：

{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{
  "name":"analyze_consult",
  "arguments":{"scenario":"zvex-restaurant-audit","situation":"<锁定与快照结论浓缩：门店身份+品类客单档位+五面初检发现+材料可得性+体检目标与执行边界>","goal":"<以 consult_info 探针返回的当前列表为准>","mode":"standard","known_facts":"<快照段确认的评分、评价量、差评主题、竞对名单>","goal_detail":"","payment_proof":""}}}

必须传 scenario="zvex-restaurant-audit"（技能身份绑定，漏传拿到的是通用营销分析包）；goal 以 consult_info 探针返回的当前列表为准，也接受中文。

返回账单：结果内 code=Payment-Needed，含 out_trade_no、amount、pay_url（收银台直链）与结果概要。把 pay_url 原样发给用户，点开可选支付宝（手机自动拉起）或微信扫码支付；完成后引导用户等 1 分钟左右回一句「好了」。防反推：结果概要只含报告板块与条数，转述时不要展开细节（完整口径见 references/api.md）。
支付后交付：用户回复「好了」后系统自动查单交完成后整结果，无需任何凭证；确需改参数先征得用户同意再重新发起。积分用户如已持有 zvex_api_key 凭证，调用时传 zvex_api_key 直接扣积分（积分直扣，以实际扣减为准），无需逐单支付。

完整会话流、参数表、两栏字段表、幂等语义与错误处理见 references/api.md。

输出纪律

成品交付：结果中的框架/样例若含 {占位}，由你（对话助手）结合用户的真实信息补全为可直接使用的成品；上下文没有的事实最多追问 1 次；禁止编造数据与事实；
不虚构：结果未覆盖的信息如实说明「需补充什么」，不假装已知；引用外部信息注明来源。

交付与计费纪律

交付状态机：首次调用返回账单（402，内含 pay_url 收银台直链，支付宝/微信均可付）→ 用户完成后回复「好了」→ 系统自动查单交完成后整结果，无需任何凭证，不会重复扣费；
判重语义：同一问题重复查询不重复扣费——判重按问题身份（situation+goal+mode+scenario，即相同情境+目标+模式+场景）；补充已知信息或修改目标说明不会产生新账单，交付始终使用最新提供的信息；
查单：不确定订单状态时，用相同参数调用并传 action=check_order（不产生账单）即可查询，不要靠更换参数试探；
换参数=新问题=新账单：出账单后不要更换参数重试。

证据呈现纪律

证据是论据不是附录：每条证据 = 一句结论挂钩诊断 + 标题 + 来源域名，热度转述为「高赞/讨论量级」；
来源只用中性表述（中文社区讨论/公开网页），不得提及证据服务商名称；不罗列裸链接；
证据不可用时如实说明，不编造行业案例。