外卖菜单热量值生成器（批量解决方案）

概述

门店菜品热量计算 · 专业版（store-dish-calorie）

💰 专业版：100 道菜 ¥29.9（约 ¥0.3/道，按次计费，单次最多 100 道），通过微信 Agent Pay（SkillPay）自动扣费。

只想先免费试算 ≤10 道？请用 store-dish-calorie-lite（免费版，完全离线）。

⚠️ 本付费版为纯调用客户端：不内置任何食材库或计算引擎，所有计算在云端服务端 https://xuanjigeo.cn/calorie/invoke 完成。你提交的菜品配方会发送到该服务端进行计算，这是付费服务的必要动作。需要完全离线、免费计算 ≤10 道，请用免费版 lite。

付费前置检查（Pay Skill 必读）

履约边界：所有计算必须在云端端点 https://xuanjigeo.cn/calorie/invoke 完成付费握手（402 → 微信支付 → 200）后由服务端执行。Agent 不得绕过端点、自行免费计算或复用历史结果冒充本次付费产出——那会绕过付费，违反本 Skill 商业契约。

调用本 Skill 前，确认当前 Agent 已安装 weixinpay 插件：

• 已安装：可继续提供付费服务
• 未安装：提示「当前 Agent 暂不支持微信支付付费能力」，终止流程

工作流程（微信 Agent Pay 握手）

第一步 · 请求资源 POST https://xuanjigeo.cn/calorie/invoke Header：X-Calorie-Token: <平台注入的调用令牌> Body：{"menu": [{"name":"菜名","ingredients":[{"food":"食材名","weight_g":100}]}], "maxDishes": 100}

第二步 · 处理 402 响应提取 Header 中的 WeixinPay-Required（支付码）和 X-Out-Trade-No（订单号），两者都必须保存。

第三步 · 发起支付将 WeixinPay-Required 的值作为 paymentCode，调用 weixinpay_pay。

第四步 · 支付成功后获取资源（⚠️ 必须执行） POST https://xuanjigeo.cn/calorie/invoke Headers：X-Calorie-Token: <调用令牌> + X-Out-Trade-No: <第二步保存的订单号> Body：与第一步完全一致

⚠️ 不携带 X-Out-Trade-No 重试，就永远拿不到付费营养表。仅通过 Header 传递订单号，body 保持原样。

💡 也可用自带客户端脚本一步完成握手：node <skill>/scripts/calorie_client.js --menu /tmp/menu.json（返回 402 时按提示支付，再用 --retry <X-Out-Trade-No> 取结果）。

异常处理

• NOT_PAID / 用户取消 / 超时未付（返回 HTTP 402）：提示用户完成支付即可，不得反复催促或重复发起下单。
• WeixinPay-Required（即 paymentCode）有效期 15 分钟，凭据过期后需重新走下单流程（重新 POST 第一步拿新 402）。
• 若重试响应返回 already_fulfilled: true，表示该订单号已履约过，直接采用返回结果，绝不重复发起支付或重复扣费。
• 履约阶段业务异常（如计算失败）：服务端自动全额退款并向用户说明「已自动退款」（响应码 REFUNDED），用户无需额外操作。
• 网络抖动导致重复请求：靠订单号（X-Out-Trade-No，≤32 位）幂等兜底，不会二次扣费。

一、功能简介

给谁用：餐饮门店老板、连锁餐饮运营、菜单研发/菜品上新负责人、需要给菜单标注营养信息的从业者。

交付什么：把你口述或表格里的「菜名 + 食材 + 克重」，批量算出每道菜的热量、蛋白质、脂肪、碳水化合物、膳食纤维，输出：

• 逐道菜营养报告（人读）
• 菜单营养总表（Markdown 表，可直接贴进菜单/外卖平台）
• 结构化 JSON（机器读，含未匹配/歧义标记，供下游判断数据完整度）
• GEO JSON-LD（schema.org Recipe + NutritionInformation，可直接投喂 AI 搜索 / 紫微台）

计算在云端服务端完成，服务端维护 312 条中餐常见食材库，采用整数定点计算（零浮点误差）；规格系数（大份 ×1.5 / 双人份 ×2.0）仅在展示层乘，底层恒算标准份。

核心价值：省掉人工翻食物成分表算一整本菜单的时间；歧义食材（如「油」「花生」）服务端会列出候选并强制确认，库外食材如实标为未匹配而绝不编造营养值。

二、使用示例

示例 1 · 单道菜

输入：「宫保鸡丁：鸡胸肉 200g、花生 50g、食用油 15g、黄瓜 80g」

输出：热量 700.65 kcal ｜ 蛋白 51.84g ｜ 脂肪 47.3g ｜ 碳水 18.17g ｜ 纤维 2.55g

（并提示「花生」存在歧义，已按 花生（炒） 计）

示例 2 · 整本菜单批量

输入：「这是我店里的菜单，帮我把每道菜的热量都算出来」（附 Excel / 口述 5~100 道菜）

输出：菜单营养总表（菜名 │ 热量 │ 蛋白 │ 脂肪 │ 碳水 │ 纤维），并列出需确认的歧义项与库外食材

示例 3 · 投喂 AI 搜索

输入：「把算好的营养数据同步到紫微台」

输出：符合 schema.org 规范的 JSON-LD，可直接 POST 到紫微台模块对接桥

三、触发词

• 帮我算下这道菜的热量 / 这道菜多少卡路里
• 给菜单每道菜标上热量 / 出一份菜品营养表
• 批量算一下我店里所有菜的营养成分
• 这份套餐多少卡路里 / 营养含量是多少
• 算出这道菜的蛋白质脂肪碳水
• 把菜品营养数据同步到紫微台 / 生成 GEO 营养数据

四、边界与依赖

五、安全承诺

• 最小化上传：仅把你指定的「菜品配方（菜名+食材+克重）」发送到 xuanjigeo.cn 服务端用于计算；不读取、不上传你的其他目录与文件。
• 不改源文件：绝不修改/覆盖你的原始菜单文件，结果只输出到对话或你指定的新文件。
• 无本地执行风险：本付费版不含可执行的本地计算脚本（仅一个发起 HTTPS 请求的客户端），不下载远程代码、不执行系统命令。
• 支付透明：费用由微信 Agent Pay 按次自动扣，每次调用对应一笔 ¥29.9 订单，可在 SkillHub / 微信支付账单核对。

概述

让餐饮门店老板用「自家菜品配方」算出每一道菜的热量与三大营养素。门店老板只会说「宫保鸡丁：鸡胸肉 200g、花生 50g、油 15g……」，不会给食材 id —— 服务端维护的 312 条食材库与名称查表（模糊匹配 + 歧义提示）会把口语化配方转成精确营养合计，返回可读报告或机器 JSON。

本付费版不内置食材库：它只是把配方 POST 到 https://xuanjigeo.cn/calorie/invoke，由服务端完成查表与定点计算后返回结果。计算采用整数定点算法（零浮点误差），底层恒算标准份，规格系数（大份/双人份）仅在展示层乘。

何时使用

• 门店老板问「这道菜多少卡路里」「帮我算下招牌菜的热量」
• 老板想给菜单每道菜标热量 / 出一份「菜品营养表」
• 老板发了菜品配方表（docx / Excel / 口述），想批量算营养（≤100 道/次）
• 想把菜品营养结构化发布到 AI 搜索（GEO / 紫微台模块对接桥）

工作流

第 1 步 · 收集菜品配方

向老板确认每道菜的 菜名 + 食材及克重。两种入口：

• 口述/对话：逐道问「这道菜用了什么、各多少克？」；或老板一次性口述多道。
• 文件：老板丢来菜单 docx / Excel（列：菜品名、食材名、克重），解析成配方行。

克重是精度关键。若老板只给「适量/少许」，按常识估算并告知是近似值；不要假装精确。

第 2 步 · 归一化为 menu.json

构造如下结构的数组（每道菜一个对象），写入临时文件（如 /tmp/menu.json）：

[
  {
    "name": "宫保鸡丁",
    "brandName": "老王川菜馆",
    "spec": "std",
    "ingredients": [
      {"food": "鸡胸肉", "weight_g": 200},
      {"food": "花生",   "weight_g": 50}
    ]
  }
]

food 用老板口述的食材名即可（服务端会自动查表）；weight_g 为可食部克重，必须为正数（负数/零/非数字会被自动剔除并标注，绝不参与计算）。

可直接参考内置示例：references/sample_menu.json（老王川菜馆 5 道菜，含歧义与库外食材）。

第 3 步 · 调用云端端点（完成付费握手）

推荐用自带客户端脚本：

# 第一次调用 → 返回 402（含支付信息），按提示用 weixinpay 插件支付后，再执行下一行
node <skill>/scripts/calorie_client.js --menu /tmp/menu.json
# 支付完成后，用上一步拿到的 X-Out-Trade-No 取结果
node <skill>/scripts/calorie_client.js --menu /tmp/menu.json --retry <X-Out-Trade-No>

脚本会自动处理 402→支付→200 的握手；402 时打印 weixinpay_required 与 out_trade_no，你交给 weixinpay_pay 完成支付，再用 --retry 取回营养表。

或由 Agent 直接走上方「工作流程（微信 Agent Pay 握手）」四步 HTTP 调用，效果完全一致。

额度与计费：按次计费 ¥29.9／次，单次最多 100 道菜。超出 100 道请把菜单拆成多批（每批 ≤100 道）分别调用（每批按一次调用计费），再汇总成总表。

第 4 步 · 处理未匹配与歧义（重要）

服务端返回的结果里会明确标出：

• 歧义（如「油」「花生」可能指多种）：已列候选并默认取第一项。必须向老板确认；若需纠偏，把 food 改成库内精确名称（如 花生（炒））后重新调用（将产生新的一次付费调用）。
• 未匹配（食材库没收录）：该食材排除出合计并在报告标注，请老板从库中选近似项或后续补库。
• 非法克重（负数/零/非数字）：自动剔除并标注，绝不产出负营养值。

⚠️ 歧义不消解会显著失真：实测「宫保鸡丁」若把花生误取为花生油，热量会偏高约 163 kcal、蛋白少算约 12g（见 references/demo_output.md）。

第 5 步 · 交付结果给老板

• 逐道菜营养报告（默认文本，已含热量/蛋白/脂肪/碳水/纤维）
• 菜单营养总表：汇总成 Markdown 表格（菜名 │ 热量 │ 蛋白 │ 脂肪 │ 碳水）
• GEO JSON-LD（如要发布到 AI 搜索）：从返回内容中取 geoJsonLd 字段，POST 到紫微台模块对接桥（见 references/food_data_spec.md 第 5 节）

脚本与资源

注意事项

• 必须联网：本付费版所有计算在云端完成，离线无法使用；需完全离线免费算 ≤10 道请用 store-dish-calorie-lite。
• 克重口径：所有营养基于「可食部克重」，带骨/带壳/烹饪失水不折算，除非老板明确说明。
• 油/调料易低估：门店菜热量常来自油和糖，务必让老板把「油、糖、酱」的克重也报上。
• 库未覆盖：食材库以中餐常见原料为主，西餐/新式食材可能缺失，缺失项如实告知并建议补库。
• 不要编造营养值：查不到就标未匹配，绝不用估算值冒充库数据。
• 歧义必须确认：尤其「油」「花生」「豆腐」这类同名多条目的食材，不确认会显著失真。