麦当劳套餐规划委员会

安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install mcd-agent-gourmet
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 mcd-agent-gourmet。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

麦当劳套餐规划委员会帮助用户根据预算、口味偏好、糖分和冰量选择、营养限制、门店营业情况以及点餐渠道，构建和对比完整的中国内地麦当劳套餐。它支持到店取餐、得来速（Drive-Thru）和欢聚送（外送）工作流，同时使用官方 MCP 数据来验证菜单、套餐详情、优惠券和最终价格。
此 Openclaw 技能严格遵循只读原则：它不创建订单、不领取优惠券、不兑换积分、不进行支付，也不存储敏感的账户信息。相反，它会生成一份经过验证的套餐候选对比简报，解释各项权衡，并让用户通过官方麦当劳渠道做出最终选择。

应用场景

在特定预算（例如 35 元人民币以下的套餐）内对比完整的麦当劳套餐。
按严格的饮食或口味限制过滤套餐，包括无辣要求、指定的饮料类型、糖度、冰量、配菜及排除项。
在确认用户的城市和位置后，查找附近的取餐或得来速门店。
使用选定的私有收货地址参考，检查支持外送的门店和菜单。
在声称任何优惠之前，验证套餐是否可以使用特定的门店和渠道兼容优惠券。
审查个人优惠券，并确定它们当前是处于活动中、即将生效、已过期，还是仍需渠道或门店验证。
按价格、钠含量、热量、蛋白质和偏好契合度对比候选方案，且不会凭空捏造健康评分。
检查积分、套餐优惠券目录和兑换详情，无需兑换积分或完成购买。
在更改套餐单品、加糖选项、冰量、酱料、配料或其他受支持的定制内容后，重新计算官方价格。

工作原理

理解用户的请求并提取预算、套餐份数、口味偏好、排除项、营养限制、位置和目标渠道。
确认履约场景：到店取餐、得来速或外送。对于到店取餐和得来速，识别用户选择的门店；对于外送，解析私有地址参考，然后获取匹配的门店和营业代码。
查询符合条件的门店，并在适用的情况下显示门店名称、地址、营业状态以及可用的预约或履约选项。
使用 query-meals 加载当前菜单，然后使用 query-meal-detail 检查每个选定的套餐，以验证实际产品、数量、可选替换项以及支持的修改内容。
保留明确的用户选择，例如加糖或无糖饮料，以及标准、少冰、去冰或多冰。绝不静默替换请求的选项或推断不可用的定制项。
使用 list-nutrition-foods 匹配营养数据。未知值将保持未知，且移除食材会使原始营养值失效，除非重新计算官方数据。
仅在相关时查询门店优惠券。在内部将优惠券标识符与当前门店、渠道和套餐上下文进行匹配；不领取优惠券，也不将优惠券名称视为折扣证明。
使用当前的套餐选择、产品代码、轮次和组合单品列表，为每个完整的候选方案独立运行 calculate-price。在每次相关修改后重新计算。
按照验证后的价格、钠含量、营养上下文和偏好契合度，对一小组合适的候选方案进行排名。硬性限制会淘汰候选方案；软性偏好指导点餐，且不会在用户不知情的情况下被放宽。
提供包含套餐详情、当前总价、预算差额、已知营养、未满足的限制、优惠券状态以及每项推荐理由的对比表。
在用户选择方案之前，重新陈述门店、渠道、单品、数量、定制项和价格。任何后续更改都会使先前的选择失效，并需要一个新的验证周期。

配置指南

将技能安装或放置到 Openclaw 技能工作空间中，并确保其 scripts、gourmet、references 和固定测试文件（fixture）完好无损。
仅在私有客户端或本地环境中配置官方 MCP 连接和凭据。绝不要将令牌粘贴到公共页面、Issue、聊天日志或应用程序日志中。
先使用离线演示来了解工作流并验证本地方案：
python3 scripts/demo.py
python3 scripts/demo.py --budget 35 --taste spicy --side fries --json
在加载门店菜单之前，按城市和关键词搜索取餐或得来速门店：
python3 scripts/demo.py --search-stores --city Nanjing --keyword Xinjiekou
python3 scripts/demo.py --search-stores --city Nanjing --keyword Xinjiekou --channel drive
加载当前门店菜单并可选地对比选定的套餐代码：
python3 scripts/demo.py --list-meals --store-code STORE_CODE
python3 scripts/demo.py --live --store-code STORE_CODE --meal-code MEAL_CODE --expand --sugar zero --ice none
使用本地方案进行实时、只读的定价和优惠券匹配：
python3 scripts/demo.py --live --plan local/my-plan.json
python3 scripts/demo.py --list-coupons --plan scripts/fixtures/plan.json
python3 scripts/demo.py --list-coupons --store-code STORE_CODE --channel delivery --business-code BUSINESS_CODE
对于外送，请先查询脱敏的地址参考，然后选择外送门店。不要将原始地址放入方案或日志中：
python3 scripts/demo.py --addresses
python3 scripts/demo.py --delivery-stores --address-ref ADDRESS_REFERENCE
仅在请求时查询账户信息：
python3 scripts/demo.py --member
python3 scripts/demo.py --my-coupons --json
python3 scripts/demo.py --points-products
python3 scripts/demo.py --points-detail SPU_ID
查阅 references/mcp-capabilities.md 和 references/validation.md 以了解支持的 MCP 工具、实现状态、限制和验证范围。该集成不支持点餐、领取优惠券、积分兑换、支付或抽奖。

数据架构

核心请求与履约上下文
字段 用途
budget 用作硬性对比边界的用户指定花费上限。
taste 偏好或排除项，例如辣或不辣；明确的排除项优先。
sugar 和 ice 饮料定制选项，在支持时严格按请求保留。
channel pickup（到店）、drive（得来速）或 delivery（外送）。
storeCode 官方门店查询所选择或返回的门店。
beType 和 orderType 官方履约上下文：到店取餐使用 1,1；得来速使用 5,1；外送使用 2,2。
beCode 官方查询返回时得来速和外送必需的字段；不为到店取餐伪造。
addressId 用于解析符合条件的外送门店的私有收货地址参考。
套餐与定价记录
query-meals 返回所选履约上下文的当前菜单。
query-meal-detail 提供套餐轮次、实际产品、数量、可选选项、selectedKey、可选的 unselectedKey、supportModify 以及饮料的 modification 值。
calculate-price 在适用时消耗 items[].productCode、roundList[].round、comboItemList 和经过验证的优惠券标识符。
权威的应付金额是返回的整数 price；绝不通过人工算术重新计算价格。
候选记录包括完整的单品列表、数量、定制项、门店上下文、定价时间戳、优惠券结果、已知营养、未知字段以及对比理由。
优惠券与账户数据
query-store-coupons 提供当前门店、渠道、营业代码和套餐上下文可用的优惠券。仅凭优惠券名称不能证明资格或优惠。
query-my-coupons 支持分页，每页最多 200 条记录，共 5 页。结果保留官方的启用状态、日期文本、有效期窗口以及门店或渠道验证状态。
query-my-account 仅返回积分数据；不推断缺失的会员等级字段。
积分目录和产品详情与可应用于当前订单的优惠券是分开的。该技能不兑换积分。
本地文件与模块
scripts/demo.py：离线测试文件演示和可选的实时只读工作流。
scripts/fixtures/plan.json：本地方案数据示例。
local/my-plan.json：建议存放用户自有方案的位置，保持私密。
gourmet/core.py：完整套餐构建和硬性限制验证。
gourmet/mcp.py：MCP 协议集成和只读工具白名单。
gourmet/live.py：套餐构建、官方价格验证和精确营养匹配。
references/mcp-capabilities.md：功能与实现参考。
references/validation.md：限制、测试和测得的验证范围。
敏感令牌、原始地址、优惠券代码、会员记录和个人标识符不会存储在对比输出中。更改门店、渠道、地址、预算、偏好或套餐会使先前的优惠券、价格和选择结论失效。

高级特性

官方 MCP 只读工具白名单可防止订单创建、优惠券领取、积分兑换、支付和其他副作用。
上下文感知的履约建模强制执行不同的到店取餐、得来速和外送参数，而不是猜测渠道代码。
精确的定制映射仅在当前菜单返回时支持糖度、冰量、酱料、配料、辣度、规格、玩具和其他选项。
对每个候选方案进行独立的官方重新定价，可防止不准确的手动计算折扣或套餐总额。
优惠券匹配在内存中结合了门店、渠道、营业代码、套餐兼容性和经过验证的优惠券标识符。
分页优惠券分析检查页码、总数和日期窗口一致性，同时清晰标记不完整的结果。
离线测试文件演示支持在无令牌或无网络访问的情况下进行确定性开发，包括优惠券过期和套餐对比场景。
结构化 JSON 输出可通过 --json 获取，用于下游自动化和测试。
可以使用 --energy-limit 、 --protein-min 、 --freshness-minutes --max-response-mb 对热量、蛋白质、新鲜度和响应大小施加明确的边界。
对比逻辑保留平局情况，区分硬性限制与软性偏好，并避免诸如通用健康评分、保证最低价或完整菜单枚举等不受支持的声明。
在保留普通食物偏好之前需要获得用户同意，并且敏感凭据、地址、优惠券代码和原始会员数据将从持久化偏好存储中排除。

name: mcd-agent-gourmet description: 麦门点餐议事会。用户想按预算和口味比较完整的麦当劳餐单，或问“我的券快过期了吗”“这顿能用哪张券”时使用。先确认门店与到店/配送，保留有糖无糖和冰量偏好；分清券包、时段和门店适用性，再使用官方 MCP 核价。只查询核价，不领券不下单。 description_zh: 按预算、糖和冰量偏好比较完整麦当劳餐单，区分到店、外带、得来速和配送，查询适用券与积分；使用官方 MCP 核价，不下单。
description_en: Compare complete McDonald’s China meals by budget and preferences, verify customization and channel-specific coupons, and inspect points through the official MCP. Read-only, no ordering.
version: 0.3.2
author: Polaris-Smart LAB
display_name: 麦门点餐议事会
agent_created: true

点餐议事会

先帮用户选一顿完整的饭，再讨论省钱、口味和营养数据。不要要求用户说出“多 Agent”这样的实现术语。

执行边界
只调用查询与核价工具；本 Skill 不执行 create-order、领券、积分兑换、支付。
Token 仅在客户端私有配置或本机环境；不让用户粘贴到公开网页、Issue 或日志。
不自动使用仓库示例门店代替用户选择；先确认到店、得来速或麦乐送；到店先问城市/位置，再通过 query-nearby-stores 列出门店供选择。
用户明确预算、主食/小食/饮料份数、排除项。“不吃辣”是硬约束，“想吃辣”可作为软偏好。
营养指标上限须来自用户；不要把固定阈值描述为普遍健康标准。
先理解一句话，再少问必要的问题

例如“35 元，不辣，有糖可乐去冰，带走”或“35 元，不辣，无糖可乐去冰，带走”：提取预算、不辣硬约束、用户指定的可乐糖类和去冰、到店外带意图。只补问缺失的城市/地标和门店，不要求用户填写长表或复制商品 ID。可记住普通饮食偏好，但先征得用户同意；不要存 Token、地址、券码或会员原始数据。

有糖可乐、无糖可乐是平等的口味选项，向用户并列展示。用户未指定时不默认无糖；明确指定有糖时不得因为营养排序自行换成无糖，反之亦然。用户只说“可乐”而当前有多个选项时，展示可选项供选择；当前门店缺少指定选项时说明缺货或未确认，不能擅自替换。宣传与示例应同时体现两种选择，不将无糖描述成更高级的口味。

推荐顺序：先给最多三份值得比较的方案和一句取舍，再允许展开全部候选。没有合适方案时说清阻碍；只提出调整建议，不能替用户增加预算、换店、换饮料或放宽排除项。能量、蛋白质、钠用于连续比较，未知不归零，不打无依据的健康分。

履约场景必须先确定
到店（pickup）：beType=1, orderType=1，不得带 beCode。堂食和外带都在到店链路；具体可选取餐方式从核价的 takeWayList 展示，不能自造 takeWayCode。本 Skill 不下单，只把用户选择带到餐单。
得来速（drive）：beType=5, orderType=1，用相应门店查询返回的 storeCode + beCode。
麦乐送（delivery）：先按用户意图查询 delivery-query-addresses，只在当前私有对话展示选择所需信息，避免重复完整门牌和电话；用户选地址后用 delivery-query-stores(beType=2, addressId=...) 获取成对编码。菜单、券、详情、核价全程使用 beType=2, orderType=2, storeCode, beCode。
地址为空时引导用户在官方应用添加。本版本不写地址、不下单。切换渠道/门店/地址后，旧券适用结论、旧报价和旧选择均失效。外卖应展示配送、包装、餐具费用，缺失为未知，不能拿到店餐价冒充送到家总价。
企业团餐有独立的 beType=6、助餐服务和活动规则，本程序尚未接通，不能套用个人点餐流程。
事实采集：协调器负责
按上面的履约场景查询门店；到店/得来速位置搜索使用 searchType=2，同时提供 city 与 keyword。展示店名、地址、营业状态；支持预约时完整展示服务端预约选项，不省略日期时段。本程序只核价即时餐单。
query-meals：使用当前履约上下文，读取这家店当次菜单。原样例套餐缺失时停止并让用户选其他套餐，不能暗中替代。
query-meal-detail：确认套餐每一轮的实际商品与数量。仅从可选项中替换。supportModify=true 时标注“可特调”；只有用户问特调或已经提出冰量/配料要求时，才展开对应选项。
无糖/含糖是餐品选择；冰量通过当前饮料的 modification 映射。支持标准、少冰、去冰、多冰取决于该饮料当次选项。
使用当次 selectedKey；未选项若有 unselectedKey 也须提交。不把同 code 的不同冰量误当成同一选项。
去酱/去菜按官方完整配料名称匹配，不凭“不要酱”猜测多种酱中的哪一个。特调后重新核价；去除配料后原标准营养值不再适用，标未知。
小/中/大杯、辣度分级、额外酱、玩具：只有当前菜单或特调提供明确选项时才能确认；否则明确未支持。不能把无糖等同于无甜味、把“不辣”当作过敏安全判断。
list-nutrition-foods：按具体餐品名称和份量匹配。缺失为未知。标准份量相加不是实际制作的精确测量。
用户需要用券时才调用 query-store-coupons：仅查看当前可用券，不自动领取。用券要拿到有效且成对的 couponId/couponCode，且该券要由官方核价验证；不要凭券名减钱。只向用户展示券名称及适配候选，协调器在内存中解析标识；不要求普通用户提供券 ID。默认不带券。
calculate-price：每份完整候选独立核价，用 items[].productCode、roundList[].round 和 comboItemList 传套餐选择；应付来自返回的整数分 price。替换任何餐品后重新核价，不能手算差价。

最多比较少量有意义的候选；说清比较范围。接口错误立即停止当前链路，标明此前结果是否完整，绝不拿 fixture 充当实时结果。

三个比较角度

对同一份已核验事实包，按以下标准比较。事实包包含用户需求、门店、核价时间、完整明细、整数分总价、营养值与缺失项，不含凭证或券 ID。

价格较低：首先排除不满足完整餐单和硬性条件的方案，再选价格较低的候选。优惠券只有在原本要买的餐单上真的减少支出才有价值。
钠含量较少：程序在已知钠数据中排序，另展示能量与蛋白质供比较。不得把钠少或低热量说成“均衡”，不得把未知说成零。
更贴近口味：在硬性条件内优先用户偏好；偏好满足不了时说明，不偷偷放宽“不吃辣”等排除项。

这些是确定性的比较标准，不是三个独立模型。不要制造角色对话或争论；多个标准选中同一餐单时合并说明，不重复展示三份相同方案。

汇总与用户选择

用表格展示每份餐单：完整明细、当次整单价格、预算余量或超额、已知营养、未满足条件、比较理由。没有满足条件的候选时明确说明。

需要展开时给出“价格与钠”“口味与钠”的取舍候选：只有另一份在每个所选维度都不差且至少一个更好时才淘汰当前餐单。同值并列保留，另提供价格、钠、能量、蛋白质四维取舍，所有对应指标须完整。四维可能留下全部候选，不称其为唯一均衡最优。不编造健康评分，不声称穷举全部菜单。

用户选择前，复述门店、餐品、份数与价格。用户改变预算/偏好/餐单后，旧选择作废。记录选择不等于创建订单；后续购买由用户在官方渠道完成。

积分、券包与渠道核验

只有用户询问积分/券包时，才调用相应个人接口。query-my-account 返回积分数据，不是完整会员档案；没有会员等级字段就不能猜测等级。

“我的券快过期了吗”

只清点券时不查询积分或订单。使用 query-my-coupons，每页最多 200 条，最多 5 页；核对页码、总数与分页期间的一致性。不完整时明确标记，不能当作全部券。可运行 python3 scripts/demo.py --my-coupons 复用确定性分析；--json 提供全部脱敏明细。

分别说明四件事：官方 enable 当前状态、有效日期、从 datetimeText 本地解析的时间窗口、门店/渠道是否核验。enable=1 也不等于特定订单可用。日期与时段原文保留；无法完整解释星期或特殊限制时标待核验。用北京时间，明确午夜不改成当天结束，纯日期不编造精确截止；“24 小时内”不说成“今天”，距离关闭时长不说成连续可用时长。

早餐开窗前可以说“05:00 开始，目前尚未进入窗口”；今天窗口关闭但明天仍有窗口时，不能说券已过期。显示本地解析依据与官方原文，字段冲突不猜测。分钟末点按包含该分钟解释，遇到边界时仍以官方渠道为准。

同名券仅分组浏览，每张分别保留日期与规则，不称可叠加；已结束的券单列，不催促用户处理。先突出最多三张相关的临期券，并提供其余明细。提醒“本来不需要买就不必为了用券消费”。公开演示使用 python3 scripts/demo.py --coupon-demo 的构造数据，不分享用户真实余额或券包截图。

“这顿能用哪张”

先确认本次餐品需求、门店与到店/外带/配送意图。可运行 --my-coupons --store-code 门店编码，配送/得来速同时携带正确的 --channel 与 --business-code。程序仅在内存中用成对券标识匹配门店返回；同名不作身份匹配。未出现在该店返回中不能说整张券作废。到店查询尚不能单独证明外带资格，取餐方式仍看核价的 takeWayList。

之后复用原有 --list-coupons 与按名称核价流程：只给原本想买且适配的餐单用券，保留糖、冰量和预算条件；名称有歧义时停止，不让普通用户查券码。只有 calculate-price 才能确认应付与实际优惠；没有成功核价时不得报告节省金额。券包清点不会自动核价或下单。

query-my-coupons 展示拥有的券；分页不完整要说明。它不校验门店/渠道。
available-coupons 只是可领取券目录，不表示已经领取。
mall-points-products 按用户兴趣查餐品券、实物或活动；不同类目不混用。CLI 当前只查询餐品券。
用户选择商品后 mall-product-detail 展示 SKU、积分、兑换现金、核销时额外现金、有效期；购买须知 note 原文展示，不拆成自动价格/资格校验规则。
必须区分“积分换券”与“券能在这次订单用”。积分不按固定比例直接当现金。不得承诺所有积分券都支持外带或配送：拥有券后，按目标 storeCode + beType + orderType + beCode(如需) 重新 query-store-coupons，商品匹配后才 calculate-price。未兑换商品的渠道资格标“尚未核验”，不能为了验证先花掉积分。
本版本不领取、不兑换、不支付、不抽奖。用户要购买时转到官方渠道；不要报告没有执行的交易成功。

详见 references/mcp-capabilities.md 的完整能力与实现状态。订单复购、活动等可作为后续扩展，不冒充本版本已接入。

本地程序

python3 scripts/demo.py：历史快照演示，零 Token，不联网。
python3 scripts/demo.py --list-coupons --plan scripts/fixtures/plan.json：只查询券名称与匹配候选，不领券、不输出券 ID。
python3 scripts/demo.py --live --plan local/my-plan.json：用户选定门店和候选后真实核价。
python3 scripts/demo.py --budget 35 --taste spicy --side fries --json：结构化比较结果。
python3 scripts/demo.py --search-stores --city 南京 --keyword 新街口：按地点搜索到店门店；--channel drive 查询得来速。
python3 scripts/demo.py --list-meals --store-code 门店编码：当前菜单；--meal-code 编码 选择最多三种套餐，不再限定原样例。
python3 scripts/demo.py --live --store-code 门店编码 --meal-code 套餐编码 --expand --sugar zero --ice none：枚举已识别小食×饮料组合，最多 12 份；每份重新官方核价。用当前官方特调 key 处理去冰。数字编码由协调器从工具结果带入，不让普通用户查 ID。
python3 scripts/demo.py --live --plan local/my-plan.json --omit 麦香鸡酱：只对实际存在该配料的套餐执行去除特调，不沿用标准营养总数。
python3 scripts/demo.py --member、--points-products、--points-detail SPU_ID：分别查询积分券包、餐品券目录、商品详情；互斥，不保存结果。
python3 scripts/demo.py --addresses → --delivery-stores --address-ref 引用：显式查询脱敏地址再选择配送店；地址引用与具体地址绑定，地址变动后拒绝继续。
python3 scripts/demo.py --list-coupons --store-code 门店编码 --channel delivery --business-code 成对业务编码：按配送场景查券；实时核价使用同样上下文。

--energy-limit、--protein-min、--freshness-minutes 和 --max-response-mb 提供显式边界。 gourmet/core.py：完整餐单与硬性条件校验。
gourmet/mcp.py：协议与只读工具白名单。
gourmet/live.py：套餐构造、官方核价、精确名称营养匹配。

限制与实测范围见 references/validation.md。不保证最低价，不构成营养或医疗建议。

LION 支付前筛选
快速总结