巨无霸 4 件套吃完了,我让腾讯WorkBuddy 算了一笔营养账

武汉主理人-中杯可乐多加冰

21964人浏览 · 2026-10-17 19:35:06

武汉主理人-中杯可乐多加冰 · 2026-10-17 19:35:06 发布

最近这段时间,我一直在琢磨一件事。

我平时写代码算得很细 —— SQL 走没走索引、接口 P99 多少、缓存命中率掉没掉,这些我都盯得死死的。但唯独有一件事我一直是糊涂账:我每天到底吃进去了啥。

我点麦当劳点 5 年了,巨无霸 4 件套(巨无霸 + 大薯 + 中可乐 + 麦乐鸡)是基本款,板烧鸡腿堡套餐是夜宵款,麦乐鸡是加班款。但这些到底补了多少蛋白、多少热量、多少钠,我从来没算过。

正好 10 月底赶上 1024 程序员节,麦当劳把自家 MCP 服务 M-China/mcd-mcp-server 开放出来做活动。GitHub trending 上一眼就看到了 M-China/mcd-developer-innovation-challenge。我装了两个月的腾讯WorkBuddy 还在工位上立着,顺手就拉它来干这件事。

参赛入口：https://github.com/M-China/mcd-developer-innovation-challenge
csdn活动页链接：https://builderx.csdn.net/activity-site/m-code/pages

这篇文章就是这段过程的复盘——一次不算小的"AI 协作工程实验",以及我最终怎么把这个工具装进我每周吃麦当劳的习惯里。

在这里插入图片描述

一、装 MCP,我撞了 3 次墙

1.1 第一面墙:地址写错了

首先要申请麦当劳MCP，这里直接去 open.mcd.cn/mcp 申请 Token,30 秒就成功。

在这里插入图片描述

然后去腾讯WorkBuddy 把 MCP 接上。打开 → 左侧"专家·技能·连接器" → 右上角"自定义连接器":

在这里插入图片描述

弹窗出来,让我手填 mcpServers JSON:

在这里插入图片描述

我心急直接保存,结果 401 报错。翻 log 翻了 10 分钟才发现——腾讯WorkBuddy 弹窗里默认填的 url 是 https://mcp.mcd.cn,这个地址是错的,要改成 https://open.mcd.cn/mcp。Token 那里也得把 YOUR_MCP_TOKEN 替换成自己的。这俩忘一个就 401,排查起来很费时间。

1.2 第二面墙:信任确认弹窗

改完 url + 填上真实 Token + 保存。回列表点"启用",首次会弹个"信任确认":

在这里插入图片描述

点信任,通了。但我没敢信——接通了不代表链路真通,只是"配置层面没拒绝"。我让腾讯WorkBuddy 自己跑 probe 验通:

在这里插入图片描述

probe 撞了一个 fetch failed,调用路径一致,判断是网络抖动,重试就过了。

1.3 装完了,我开始想用它做什么

装完链路通了,3 个想法冒出来。

盯着那 35 个 tool 看了半小时,我把它们在脑子里分了 3 堆——数据类(list-nutrition-foods 160 款餐品营养表、order-list 我的历史订单、query-meals 实时菜单)、计算类(calculate-price 实时计价)、推荐类(recommend-meals 智能推荐)。

第一想法:我每天点单,平台只告诉我"热量 920 大卡",但 920 大卡够不够、跟昨天比缺什么、补哪个单品能"救回来",没人告诉我。
第二想法:麦当劳营养页面上是"单品营养",但我一顿是 4 件套 5 件套,跨单品累加,加完还可能跨天汇总看趋势——这事儿 MCP 本身没现成接口,得我自己接。

所以我的创意特别朴素:做一个叫 mcd-dev-diet 的小工具,跑在 Node + TypeScript 上,接腾讯WorkBuddy 调麦当劳 MCP。3 件事——

mcd-dev-diet 干 3 件事

一顿够不够:拉今天这一单的每件单品,按 6 维营养(蛋白/脂肪/碳水/钠/纤维/糖)分别算"达标率",告诉用户"这顿蛋白只到目标的 60%"。
加啥就齐:基于缺口 + 已点清单,推荐"补足度 × 性价比"最高的单品组合,典型:鲜蔬杯 + 玉米杯,不到 10 块补完纤维和维生素缺口。
月度回顾:跑过去 30 天订单,告诉用户"老是不达标的是哪几项"——蛋白常年只到目标的 70%?那不是这一顿的事,是点单习惯的事。

写到这里我才意识到:这不是个"工具",这是个程序员版的"麦当劳花呗账单"——只不过花呗告诉你"花了多少",它告诉你"吃了多少、缺多少、怎么补"。

二、跟腾讯WorkBuddy 一起做的过程 —— 3 天,3 轮迭代

2.1 第一轮:它不是上来就开干,是先问 3 个问题

我给腾讯WorkBuddy 第一句 prompt 很短:

帮我做个 Skill,输入是今天吃了什么(订单 JSON 或手输),
输出是这顿的营养盘点(热量/蛋白/脂肪/钠/钙/蔬菜) + 还能加点啥让这顿更平衡。
约束:必须调 mcd-mcp-server,不能用估算,所有数据要从 MCP 拿。
最后给我可运行的代码 + 怎么用。

它没立刻开干,先问了我 3 个问题:

“营养目标用哪份标准?WHO、还是《中国居民膳食指南》、还是《程序员外卖场景》?”
“菜单价格是按门店实时价还是按平均价?不同门店差价挺大。”
“输出是 CLI 一句话,还是要一个能保存到 Notion 的 markdown 报告?”

我答:膳食指南、实时价(用 list-stores 拿当前门店)、先 CLI 后再说。然后它就开干了。

22 分钟里它把整个比赛仓库都读了。这种主动选型省下了我至少三天的技术调研——我没问 monorepo,它主动建议;我没问 TypeScript strict,它主动建议。

在这里插入图片描述

然后它没急着上代码。先把工程结构列了 5 个核心模块 —— 每一块都先讲清楚"这块最容易踩什么坑"再动手:

mcd-dev-diet/
├── src/
│   ├── mcp_client.ts       # MCP 客户端封装
│   ├── nutrition.ts        # 累加 + 营养查询
│   ├── recommender.ts      # 补缺推荐逻辑
│   ├── targets.ts          # 目标值常量
│   └── cli.ts              # CLI 入口
├── tests/
│   └── smoke.test.ts
├── workbuddy.md            # Skill 描述文件
└── README.md

我印象最深的是它写 nutrition.ts 时自己加的注释:

在这里插入图片描述

核心一: 营养累加(含三级匹配与单位归一 —— 查不到就明确标 UNKNOWN,绝不估)。

这句话挺戳我的。程序员写业务逻辑最常见的两难:拿不到数据时,是"装作有"硬填一个数,还是"承认没有"打 UNKNOWN 让上层决策。腾讯WorkBuddy 一上来就选了后者,这个倾向比"AI 写得快"更值钱。

2.2 第二轮:撞上中文 key,撞上 SKU 克数

调 list-nutrition-foods,腾讯WorkBuddy 30 秒给我写了 client。我跑了一下,数据是返回了,但取 item.calories 一直是 undefined。

log 看了几遍,翻了两层 JSON,才发现——MCP 返回的字段是中文 key:

{
  "id": "big-mac-001",
  "名称": "巨无霸",
  "热量": 500,
  "蛋白质": 27,
  "脂肪": 28,
  "碳水化合物": 46,
  "钠": 780,
  "份量_g": 220
}

我之前给腾讯WorkBuddy 写 demo 用的 calories、protein,它顺着我的命名习惯写了,没核对 MCP 真实字段。改完类型定义,通了。

这个其实是 MCP 设计上的一个细节——它不像 REST API 那样给你 snake_case 英文 key,而是按麦当劳内部菜品库的字段直出,字段名是中文。腾讯WorkBuddy 第一次写的时候不知道这个,我觉得是合理的,毕竟文档没明确写。

撞上 SKU 克数

累加函数第一版腾讯WorkBuddy 给得很简洁。我塞今天中午的订单跑——巨无霸 1 个 + 大薯 1 份 + 中可乐 1 杯 + 麦乐鸡 6 块。跑出来热量 920 千卡。

我愣了一下:巨无霸一个就 500,大薯 320,中可乐 200,加起来 1020 起步啊,920 怎么算的?

翻逻辑。它累加时只用了 qty 当倍数,没按克数算。但麦当劳的 SKU 是按克数卖的——巨无霸 220g,麦乐鸡 4 块才 72g,差别大。大薯的"1 份"其实是 145g,中可乐的"1 杯"是 473ml(密度按 1 算),这些都要查表。

我加了个份量映射表:

// src/nutrition.ts 里的 SKU 映射表(节选)
// 份量映射:SKU -> 实际克重(用于累加时校准)
const SKU_WEIGHT: Record<string, number> = {
  "big_mac": 220,             // 巨无霸 1 个
  "large_fries": 145,         // 大薯 1 份
  "medium_coke": 473,         // 中可乐(按 ml)
  "mc_chicken_6pc": 108,      // 麦乐鸡 6 块
  "mc_chicken_4pc": 72,       // 麦乐鸡 4 块
  "salad_shanghai": 250,      // 鲜蔬杯
  "corn_cup": 80,             // 玉米杯
  "fillet_o_fish": 145,       // 麦香鱼
};

丑,但能用。再跑——这次 1024 千卡,跟手算对上了。

在这里插入图片描述

这一轮最让我意外的是腾讯WorkBuddy 自检脚本的去重 bug。跑完累加后它说"两处失败,先看营养库的重复行是不是真的重复"——翻 log,发现小杯玉米杯和纯牛奶(盒装) 真的在库里写了两次,不是断言写错。它的 debug 思路跟我一样:先怀疑数据,再改代码。它还把"只去重完全相同的行"也写进了自检,不让这个 bug 再回来。

接着调 order-list,顺手拉出过去 3 个月的订单 JSON。

我看了一眼——巨无霸 4 件套我点了 17 次,麦辣鸡腿堡套餐点了 9 次,板烧鸡腿堡套餐 5 次,剩下就是各种单点的小食和饮料。

腾讯WorkBuddy 马上跟进:“要不要顺便做个’月度回顾’功能?把过去 30 天的订单都过一遍,告诉你哪几项’老是不达标’?”

我心想这不就是"麦当劳版花呗账单"嘛,加。于是这个 Skill 从一个单餐工具,变成了一个"算我吃了啥"的小系统。

在这里插入图片描述

2.3 第三轮:评分曲线 + 推荐过滤

评分函数:软阈值比硬阈值温和

“这顿够不够"怎么算?我本来想:用硬阈值,蛋白 < 30g 算"不够”,钠 > 1500mg 算"爆"。

腾讯WorkBuddy 给的是评分函数——不是"过线就 0 分",而是越接近"蛋白 30g / 脂肪 ≤70g / 钠 ≤1500mg"分越高。它给的代码:

// src/nutrition.ts 评分函数
function scoreMeal(n: Nutrition): number {
  // 越接近目标值分越高,6 维加权平均
  const w = { protein: 0.25, fat: 0.15, sodium: 0.10,
              calcium: 0.20, veg: 0.25, calories: 0.05 };
  return (
      bell(n.protein, 30, 30) * w.protein
    + bell(n.fat, 50, 70)     * w.fat      // 50g 最佳,70g 上限
    + bell(n.sodium, 800, 1500) * w.sodium
    + bell(n.calcium, 800, 400) * w.calcium
    + bell(n.veg, 300, 100)    * w.veg
    + bell(n.calories, 1800, 2400) * w.calories
  );
}

// bell(x, peak, edge) = max(0, 1 - |x - peak| / |edge - peak|)

为啥这个思路巧?硬阈值会让你"没解"——你蛋白 28g,差 2g,完了,“不够”。

软评分告诉你"再补点啥就及格了"。对,补 ¥9 的鲜蔬杯就行。它不会告诉你"你吃的这顿不行",只会告诉你"再加一点点就完美了"——这种反馈对人温和很多。

补缺推荐:第一版推了个巨无霸

“还能加点啥”。腾讯WorkBuddy 第一版:在菜单里搜含目标营养素的产品,按"补足度"排序。我跑了一下,推荐:“加个巨无霸套餐补充蛋白。”

我心想——我刚点的就是巨无霸啊。

反馈给它,它加了个"已点清单"过滤,改成"缺口补足度 × 性价比"排序。再跑——推荐"加鲜蔬杯 + 玉米杯,共 ¥9.5,补纤维 8g、维 C 30mg"。这回对了。

// src/recommender.ts 补缺推荐核心逻辑
function recommend(current: Order, all: MenuItem[]): MenuItem[] {
  const have = aggregate(current);
  const gaps = computeGaps(have, TARGETS);
  return all
    .filter(x => !current.items.includes(x.id))   // 排除已点
    .map(x => ({
      item: x,
      score: gapCoverage(x, gaps) / x.price        // 补缺 / 价格
    }))
    .sort((a, b) => b.score - a.score)
    .slice(0, 3);
}

鲜蔬杯 ¥6.5 补蔬菜,玉米杯 ¥3 补纤维——一共不到 10 块,这顿的"营养账"就齐了。

这一轮还有个我没想到的翻车:菜单拉取时我给 cli.ts 传 --items,腾讯WorkBuddy 发现两个问题(菜单空 + 实时价空)指向同一个根因——--items 没有历史订单,门店就丢了,导致后续全空。它没修两次,而是加了一条兜底:没给门店时自动从历史订单推导,复用已有逻辑,用户不用手敲门店码。

接着它用真实询价重建本地兜底价表,发现批量询价返回为空,看原始返回——单次 124 个商品太多,分批(每批 20)拉。再组合验证 --items + --demo,门店自动推导生效,候选池 74 个、实时价 ¥11.50。最后撞了一个 demo 模式读真实缓存的 bug——三天的活,到这里算是把 demo 和真实路径彻底分开了。

这一轮最让我意外的,不是它修了多少 bug,而是它的修 bug 节奏——先编译 → 跑 → 翻车 → 看原始 → 降级 → 验证 → 再翻车 → 再修。这跟带过的老工程师一个节奏,不是 LLM 一把梭。

三、跑了一周,有点上头

mcd-dev-diet · 作品简介

Node 20 + TypeScript strict,接腾讯WorkBuddy v5.8.2 调 M-China/mcd-mcp-server(35 个 tool)。5 个核心模块:mcp_client.ts(MCP 客户端封装 + Bearer Token 缓存)/ nutrition.ts(6 维营养累加 + 缺口分析)/ recommender.ts(补缺推荐 + 已点过滤)/ targets.ts(目标值常量,基于《中国居民膳食指南》)/ cli.ts(CLI 入口 + 月度回顾)。

代码 12 个文件,加起来 800 行左右,腾讯WorkBuddy 写了 9 个,我改了 3 个。那 3 个都是"业务决策"——份量映射、推荐排序权重、目标值上下限,这些它没我的领域判断。

实际跑了一周,效果是这样: