name: mcd-meal-pairing description: 麦当劳配餐决策 Skill（McPair / 麦麦配）。当用户问「吃什么」「帮我配一份」「预算多少怎么点」「控卡怎么点」「忌口怎么选」「这券怎么用最划算」「我们几个人一起点」时使用。本 Skill 不靠模型猜测商品与价格：先调麦当劳 MCP 取门店真实在售菜单、营养表、券与点餐史，再由确定性求解器枚举组合、算到手价与热量，最后给出三档方案并解释取舍。适用于单人配餐、多人拼单、优惠券诊断。

McPair · 麦麦配

不推荐套餐，只做最优配对。 你说一句「随便」，它算完上千种搭配，给你三档方案，并告诉你为什么不是另外那些。

铁律

1. 不猜价格，不猜热量。 所有金额与营养数值只能来自 MCP 工具返回或 scripts/pair.py 的计算结果。接口没给的，就说「这个我查不到」，不要估。
2. 不虚构 SKU。 只能推荐本次 query-meals 返回过的商品。名字必须逐字照抄，不能写成你以为的简称。
3. 不下单。 本 Skill 只做决策。把商品清单和到手价交给用户，让用户自己在官方渠道确认下单。
4. 不隐瞒不确定性。 dataStatus.issues 里每一条都要在回复里说清楚（用了离线数据、券没取到、套餐构成是推断的），不能当作没看见。
5. 脚本失败就停下。 如果 pair.py 返回 ok: false，把 error 原样告诉用户。绝对不要因为脚本挂了就自己心算一个方案——那正是本项目要消灭的行为。

执行流程

第 0 步：判断场景

只有一个人吃，就 solo。提到两个人以上共同吃一单，才切 squad。 「我和朋友各点各的」仍是 solo，不要自作主张合并。

第 1 步：取数

先 now-time-info 拿准当前时间（券的可用性完全依赖它），再并行取以下数据。

门店未知时先 query-nearby-stores（beType=1 到店自取 / 5 得来速；searchType=1 收藏门店，2 按城市+关键词搜索）。

• 到店自取：orderType=1, beType=1，不传 beCode
• 麦乐送：orderType=2, beType=2，必传 beCode
• 得来速：orderType=1, beType=5，必传 beCode

order-list 拿不到不要报错，画像为空是正常状态，等于「第一次来」。此时不要编造口味，直接按中性口味配。

query-meals 的返回是三层结构，注意 meals 是 map 不是数组：

data.categories[]        → 分类名（饮品 / 鸡肉汉堡 / 小食甜品 …）
data.categories[].meals[] → { code, tags }   ← tags 里有「套餐」「单品」
data.meals.{code}        → { name, currentPrice, originalPrice }  ← 价格是字符串
data.frequent            → 我的常点

把 query-meals 的原始 data 整块塞进 payload 的 menu 字段即可，解析交给脚本。不要自己拍平、不要自己改字段名、不要四舍五入价格——脚本已经处理了 map 结构、字符串价格、套餐标签和周边过滤。

另外两个接口的返回格式不一样，别搞混

query-my-coupons 返回长这样，原样当字符串传，脚本用正则解析：

## 11.9元麦辣鸡腿堡
- **优惠**: ¥11.9 (用券价格)
- **有效期**: 2026-10-19 10:30-2026-10-23 23:59 周一、二、三、四、五 10:30-23:59
- **标签**: 到店专用、外送专用

不要自己从这段文本里抄价格——抄错一位，整单就错了。交给脚本解析，解析不出来它会记进 issues。

第 2 步：组 payload

构造一个 JSON 对象。除 menus/constraints 外都可以省略。

{
  "mode": "solo",
  "now": "2026-10-19 12:30",
  "channel": "到店",
  "constraints": {
    "budget": 40,
    "kcalCap": 600,
    "proteinMin": 0,
    "avoid": ["spicy", "beef"],
    "needDrink": false
  },
  "store": {"storeCode": "1950064", "storeName": "麦当劳北京和平街北口餐厅"},
  "menu": { "categories": [...], "meals": {...} },
  "nutrition": [ ... list-nutrition-foods 的返回 ... ],
  "coupons": "## 11.9元麦辣鸡腿堡\n- **优惠**: ¥11.9 (用券价格)\n- **有效期**: ...",
  "orders": { "list": [ ... order-list 的 data.list ... ] }
}

squad 模式把 constraints 换成 budget + members：

{
  "mode": "squad",
  "budget": 100,
  "now": "2026-10-19 12:30",
  "members": [
    {"name": "小明", "kcalCap": 600, "avoid": ["spicy"], "budget": 34,
     "taste": "chicken", "spiceTolerance": 0.15},
    {"name": "小美", "taste": "beef", "budget": 40},
    {"name": "老王", "taste": "chicken", "spiceTolerance": 0.9, "budget": 40}
  ],
  "store": {...}, "menu": {...}, "nutrition": [...], "coupons": [...]
}

成员字段全部来自用户亲口说的内容，没说就留空：

没有提到的不要编。 编了就等于替用户决定，而他并没有说过。

avoid 可选值：beef chicken fish pork spicy fried dessert。 用户说「不吃牛肉」写 beef，说「不吃辣」写 spicy——不要说「不吃辣」就顺手把 beef 也加上。

第 3 步：计算

cd <本 Skill 根目录>
echo '<payload JSON>' | python scripts/pair.py

只想验证安装是否成功、或没有 Token 时：

python scripts/pair.py --demo

脚本输出一个 JSON 对象，ok 为 true 才算成功。所有数字以它为准。 如果 dataStatus.issues 非空，说明部分数据缺失或为推断值，渲染时必须转述。

第 4 步：渲染

按下面的结构输出，不要一次性倒出全部字段。

solo 模板

从 {stats.enumerated} 种搭配里筛出 {stats.passed} 组可行。（可选，一句话）

{profile.labels 用「 / 」连接}（置信度 {profile.confidence}）
{profile.surprise —— 有就放在这里，这是最容易被记住的一句话}

**方案一 · {tiers[0].label}** ¥{tiers[0].netPrice}
  {items 名称，用「 + 」连接}
  {tiers[0].kcal} kcal · 蛋白 {tiers[0].protein} g
  {rationale 第一条，或券的信息}

**方案二 · {tiers[1].label}** …（同上）

**方案三 · {tiers[2].label}** …（同上）

{如果有 couponNotes，用两三行转述最要紧的那条}

三条硬要求：

• 每套方案必须写清 几件商品 + 到手价 + 热量
• 券必须写清 能不能用、为什么
• tierSpread 小于 5 时，把 spreadNote 说出来：「三档只差 ¥x，不是没算开，是约束把空间压窄了」

squad 模板

{party} 人拼单 · 预算池 ¥{budget}
最公平的一单 ¥{options[0].netPrice}

{购物车：名称 ×份数，用「、」连接}

  {member.name}  ¥{member.pay}  满意度 {member.score}（{member.kcal} kcal）
    {member.notes 逐条列出，没有就省略这一行}

最不满意的是 {min score 的成员}（{score}）——这是 max-min 解：它不追求总分最高，
只保证最不满意的人不被牺牲。

拼单绝对不要说「已为你们优化到最优」。 目标是 max-min，不是总和最优。正确说法是「最不满意的是小美（0.77），这套方案保证这个数被抬到最高」。

成员问「凭什么我少吃了」时，直接引用该成员的 notes，不要重新组织语言——那是引擎算出来的让步，不是话术。

第 5 步：接住追问

追问时沿用上一轮的约束，只改用户指定的那一项。

数据陷阱清单

这些都是真实踩过的，别重复踩：

边界

• 拼单 2–5 人。6 人以上枚举空间过宽，建议拆单。
• 满意度是显式加权模型（口味 45% / 热量贴合 30% / 配餐完整度 25%），不是学习出来的。不要包装成「AI 懂你」。
• 营养表覆盖不到的新品会被排除，不会用估算值顶上。dataStatus.issues 会说明。
• 套餐构成若由名称推断，热量是累加估算值，nutrientSource 会是 composed，需要说明。
• 不计算配送费与满减，外送只影响券的可用性判断。
• 券的时段限制以 now 为准。默认用真实当前时间，不要自己假设「现在是中午」。

输出格式约定

• 价格保留 1 位小数，前缀 ¥
• 热量取整，单位 kcal；蛋白取整，单位 g
• 商品名逐字照抄接口返回，包括括号和引号（如 "堡" 你欢乐套餐、【美汁源】"多汁柠柠"）
• 不写「大约」「左右」——数值是算出来的，不是估的；如果不确定，就说不确定在哪

McPair · 麦麦配

不推荐套餐，只做最优配对。

你说一句「40 块以内，随便」，它在门店实时菜单上枚举 1881 种搭配，剪枝出 1326 组可行解，给你三档方案——并告诉你为什么不是另外那些。

这个项目里，LLM 不参与算钱。价格、热量、用券全部由确定性代码算出，每个数字都能追溯到某一次 MCP 工具返回。

→ 打开输出预览页　三个真实场景的完整输出——预算 40、减脂 600 大卡、三人拼单 100 元。打开即看，不需要 Token、不需要安装。

它到底算出了什么

三档方案之外，它会说三句别的推荐说不出的话：

关于预算 —— 「预算从 ¥40 加到 ¥48，均衡档的主餐不会变。再往上加钱，只会让你多一份小食或甜品，换不到更好的主餐。」

关于券 —— 「当前时刻你的 6 张券一张都用不了。最近可用：巧克力味厚松饼猪柳蛋套餐，10-18 05:00，约 10.1 小时后。」

关于你 —— 「2 张券指向你几乎不点的品类——券不是没用，是没发对人。」

还有被淘汰的那些，为什么不选：

精选超值随心配 ¥13.9 · 461 kcal —— 各项指标被同价位方案全面压制

麦麦脆汁鸡1块 ¥24.9 · 495 kcal —— 口味契合比均衡档低 27%

「为什么不是那些」比「为什么是这个」更难回答，也更有用。

它解决的问题

让模型直接推荐套餐，几乎必然出现三个问题：

1. 价格靠编。 模型报一个「大约 35 元」，实际到手 42 元。
2. 热量靠猜。 「这套大概 800 大卡」，营养表里其实是 1,140。
3. 券当不存在。 用户手里 6 张券，推荐里一张都没用上，也说不出为什么。

这个 Skill 的做法是：把「说话」和「算账」拆开。

模型理解「帮我配个 40 以内的、不要辣」之后，就不再参与计算。所有金额与热量来自门店接口与求解器的真实运算，可复现、可对账。

它能回答的七个问题

还有个开场白是别人给不了的：

「你 7 单里 0 单牛肉——你可能以为自己是巨无霸党，但数据不是这么说的。」

这句不是话术，是从 order-list 的真实订单里算出来的，还带置信度（0.52，样本少时会直说「有 48% 的可能我判断错了」）。

目标用户

不适合谁（写清楚边界，比夸大适用范围更可信）：

• 只想最快下一单、完全不在意价格与搭配的人——用官方「我的常点」更快。
• 6 人以上的团餐——枚举空间过宽，本 Skill 会直接建议拆单。
• 需要下单、支付、配送的人——本 Skill 只做决策，不下单。商品清单与到手价交给你，下单请走官方渠道。

安装

前置条件：麦当劳 MCP Token（从 麦当劳 MCP 控制台 申请）。

1. 装 Skill

git clone https://github.com/paraboy-s/mcd-meal-pairing ~/.workbuddy/skills/mcd-meal-pairing

Windows 对应 %USERPROFILE%\.workbuddy\skills\mcd-meal-pairing。

2. 配 MCP

WorkBuddy → 左侧【专家·技能·连接器】→【连接器】→ 右上角【自定义连接器】→【配置 MCP】：

{
  "mcpServers": {
    "mcd-mcp": {
      "type": "streamablehttp",
      "url": "https://mcp.mcd.cn",
      "headers": { "Authorization": "Bearer YOUR_MCP_TOKEN" }
    }
  }
}

把 YOUR_MCP_TOKEN 换成实际 Token，保存并启用。

3. 开始用

直接在对话框里说人话：

我中午想吃麦当劳，40 块以内，不要辣

Skill 会自动取门店菜单、营养表、你的券和点餐史，算完给你三档方案。

不用 Token 也能先验证

cd ~/.workbuddy/skills/mcd-meal-pairing
python scripts/pair.py --demo

输出（真实结果，非示意图 —— 完整 JSON 见 预览页）：

枚举 1881 种搭配 → 1326 组可行

  省钱档  ¥14.9   582 kcal   人气经典随心配
  均衡档  ¥34.5   827 kcal   板烧鸡腿堡三件套（原价 ¥48，让利 ¥13.5）
  放纵档  ¥39.5   920 kcal   板烧鸡腿堡三件套 + 圆筒冰淇淋

品味指纹  鸡肉党 / 不碰辣 · 置信度 0.52 · 7 单里 0 单牛肉
反事实    预算加到 ¥48，均衡档主餐不变
券诊断    6 张券当前一张都用不了，最近可用在 10.1 小时后

--demo 用的是 fixtures/ 里固化的真实接口截面（2026-10-17 18:57），零依赖、零 Token。

品味指纹不是玄学

输出里那句「鸡肉党 / 不碰辣」，背后是 9 个可复算的数字。taste_engine 把每件商品按名字归类（板烧→鸡肉、麦辣→辣+炸、圆筒→甜品），再按时间衰减加权（半衰期 180 天，越近的订单权重越高），压成 9 维向量：

两个让它站得住的设计：

• 带置信度。13 件商品 / (13 + 12) = 0.52，输出会直说「有 48% 的可能我判断错了」。低置信度时画像只做软加权，不当硬约束。
• 它真的改变结果。口味权重随档位变化（省钱 0.10 / 均衡 0.25 / 放纵 0.45）。消融实验：关掉品味引擎，40 个场景的主餐口味契合从 0.55 掉到 0.05。

点餐史来自使用者本人账号的 order-list，只在内存中参与计算，不写盘、不上传。

它怎么算的

用户一句话
    ↓  LLM：只做意图理解
{ budget: 40, avoid: ["spicy"], kcalCap: null }
    ↓
query-meals ── 门店在售 90+ SKU 与真实价
list-nutrition-foods ── 158 条营养
query-my-coupons ── 6 张券的时段与渠道
order-list ── 历史订单 → 品味指纹
    ↓
scripts/pair.py（确定性求解，LLM 不介入）
    硬约束剪枝 → 帕累托非支配排序 → 三档选优 → 券最优抵扣
    ↓
结构化 JSON（每个数字可追溯到某次计算）
    ↓  LLM：只做渲染
三档方案 + 淘汰理由 + 反事实 + 券诊断

六个引擎

三个真实场景

① 控卡 + 要饮品

我在减脂，600 大卡以内，还要带杯饮料

Skill 会把 kcalCap: 600, needDrink: true 交给引擎。若可行空间被压得很窄，它会直说而不是硬凑差异：

三档只差 ¥3.1——不是没算开，而是你的约束把可行空间压窄了，再往上加钱也换不到明显更好的组合。

② 忌口

不吃辣，也不要牛肉，预算 45

avoid: ["spicy", "beef"]。引擎按蛋白类型和辣度做硬否决，不靠模型理解「不要辣」是什么意思。

③ 多人拼单

我们三个人一起吃，预算 100

三个人诉求互斥时（一个控卡、一个不吃辣、一个只想吃炸鸡），不存在让所有人同时最优的解。Skill 用 max-min 求「最不满意的那个人尽量不惨」的解，并把每个人的让步摆到台面上：

最不满意的是小美（0.77）——这是 max-min 解：它不追求总分最高，只保证最不满意的人不被牺牲。

小美：最想要的「巨无霸」这单没点上，比个人最优让了 0.23

拼单最容易吵架的地方，被提前说出来了。

评估

40 个场景（预算 × 热量上限 × 忌口 × 饮品约束），与三个典型基线对比：

基线只看单个套餐，无法组合小食与饮品，所以热量贴合天然吃亏。 不是刻意设弱，而是「只做套餐推荐」这个范式的天花板。

消融实验（每次只关一个引擎）

关掉品味引擎，口味契合从 0.55 掉到 0.05——推荐退化成一个不看人的优化器。这就是画像的必要性证据。

拼单的公平性

21 个多人场景：

19/21 个场景里，公平解与效率解是同一单——公平通常不花钱。 只在 2/21 个「预算紧到必须有人让步」的场景分离，max-min 把短板抬高 +0.06，代价是总分 −0.06。

这不是「我们的方案更好」，而是「目标函数换了，取舍就变了」。

接入层的可信度

菜单接口不返回商品角色（汉堡 / 小食 / 饮品 / 甜品），这层只能从名称推断。 推断规则有多准，用人工标注的 81 个真实 SKU 回归：

这个数字写在测试里，准确率跌破 95% 会直接挂 CI。误差范围被写下来，而不是靠「看起来还行」。

项目结构

SKILL.md                  ← 智能体执行指令（本 Skill 的核心）
scripts/
  pair.py                 ← 唯一计算入口：stdin JSON → stdout JSON
src/
  ingest.py               接入层：把 MCP 返回拍平（含周边过滤、角色推断）
  classify.py             名称 → 角色 / 蛋白 / 辣度 推断规则
  data.py                 目录与营养解析（含别名归一、套餐构成推断）
  taste_engine.py         品味指纹
  solver_engine.py        组合求解
  coupon_engine.py        券引擎
  explain_engine.py       解释引擎
  squad_engine.py         拼单 max-min
  guard_engine.py         护栏
  view.py                 输出结构
fixtures/                 真实接口截面数据（--demo 用）
tests/                    56 个单测
eval/                     基准与消融
assets/                   首屏图（hero / pipeline，纯 SVG）
docs/                     输出预览页（GitHub Pages 托管）

可用命令

python scripts/pair.py --demo              # 无需 Token 跑一份示例
python scripts/pair.py --demo --mode squad # 拼单示例
python -m unittest discover -s tests       # 56 个测试
python -m eval.benchmark                   # 基线对比 + 消融
python -m eval.squad_benchmark             # 拼单公平性

已知边界

• 拼单建议 2–5 人，6 人以上枚举空间过宽，建议拆单。
• 满意度是显式加权模型（口味 45% / 热量贴合 30% / 配餐完整度 25%），不是学习出来的。不包装成「AI 懂你」。
• 营养表覆盖不到的新品会被排除，不用估算值顶上。
• 套餐构成若由名称推断，热量是累加估算值，输出里标 composed。
• 不计算配送费与满减；外送只影响券的可用性。
• 菜单接口会混入周边商品（帽子、徽章、毛绒玩具），已在接入层过滤。

赛事文件

关于

本项目为「麦当劳程序员创意开发大赛」参赛作品，由参赛者独立开发，非麦当劳官方产品。 餐品信息、价格及供应状态以麦当劳官方渠道的实时结果为准；输出仅供参考，不构成营养或医疗建议。

它不会替你下单——只做决策，下单请走官方渠道。

如果这个项目让你少算过一次账，或者让你觉得「原来推荐还能这么写」， 点一个 Star 就是最好的支持。Star 是这个比赛唯一的排名依据，也是我继续把它做完的理由。