基于麦当劳 MCP 做了一个"看人下菜"的配餐 Agent：场合决定组合，而不只是文案

先说结果：项目从一个念头到通过比赛官方校验，只用了一个下午。这篇文章不讲比赛，讲这个下午里的几个工程决策——它们比"用了什么工具"更值得聊。

决策一：不碰红海，先看赛道再选题

动手之前先把已有作品翻了一遍：省钱/领券类已经一大堆，热量计算类也有好几个。这些方向再做就是第 N 个同类工具，Star 不会自己长出来。

最终选了一个结构上不同的方向：把"给谁吃、为什么请"做成配餐引擎的一等输入。给恋人过生日和给老板道歉，配餐逻辑应该完全不同——庆生必须含甜品、道歉强制单人份、加班慰问必配热饮。这些不是文案修饰，是组合筛选的硬约束（不满足直接淘汰）。

决策二：价格只信一个来源

配餐引擎在本地跑（纯 Python 标准库、零依赖），但它不定价——所有金额必须来自麦当劳 MCP 的 calculate-price 实时返回。上线当天做了三次真实核价（¥96.40 / ¥58.80 / ¥44.90），与本地预排 100% 一致。中途还发现一个细节：菜单现价已含促销，核价接口返回"原价 + 优惠拆分"（一杯奶铁 ¥21 自动减到 ¥13.9），预排和核价天然对得上。

这条红线的价值在评审时能看到：方案里任何一个数字都能追溯到一次真实接口调用，不是模型编的。

决策三：文案也要有测试

AI 写祝福语最容易翻车的是编造——"还记得去年我们一起吃过"这种共同记忆，用户一眼看穿。所以我写了 30 条红线规则：禁止编造事实、禁止超范围承诺（"吃了就开心"）、禁止身材评价、对上级禁用"兄弟"类称呼、非 MCP 返回的价格一律拦截。规则命中必须重写。开发过程中它真的拦过一次我自己写的文案——规则没有被放宽，改的是文案。

最终回归测试 335 条断言，全绿。

决策四：让评审不配 Token 也能玩

所有菜品、价格、营养数据来自麦当劳中国官方 MCP 实时返回，快照内嵌进一个单文件演示页——零依赖、无外部资源、手机能打开。切场合、拖预算、勾忌口，方案实时重排。

决策五：给 Agent 立规矩——下单前必须有确认闸门

配餐 Agent 最危险的能力是 create-order：模型一旦理解错了用户意图，就是真金白银的订单。所以工作流里写死了一条：任何金额展示之后、任何下单调用之前，必须复述订单明细并等待用户逐字确认，模型没有"替用户做决定"的权限。类似地，auto-bind-coupons（自动领券）会修改用户账户状态，属于未经允许的副作用，整个 Skill 明确不调用它。

这个闸门在测试里是一条断言：确认环节不存在时，下单链路不可达。

踩坑清单（评审可复核）

• 门店搜索关键词传全称（"某某大学某某校区"）会报 internal_error，短地标词才正常
• query-meals 没有餐段参数，要传 reservationDate 才能取到目标餐段的菜单
• calculate-price 的 items 必须是对象数组且字段名固定，写成字符串直接报"缺少参数"
• 营养表覆盖不了所有 SKU，缺项一律标"热量未知"，合计用 >= N kcal，绝不按 0 算

以上项目已开源，包含完整的 MCP 接入文档、参数坑清单和 335 条回归测试：

仓库地址：https://github.com/qimuzhenxingchen/mcscene