我用 WorkBuddy 做麦当劳 Skill：一次报名走错入口、两次撞题之后的参赛复盘

我最近参加了一个基于麦当劳 MCP 开发 Skill 的活动。

麦当劳程序员创意开发大赛

一开始，我以为这是一件很简单的事：拿到 MCP Token，在 WorkBuddy 里接入服务，告诉 AI“帮我做一个麦当劳点餐 Skill”，然后把代码提交到 GitHub。

真正做下来才发现，代码并不是最难的部分。

难的是读懂规则、搞清楚 MCP、WorkBuddy 和 Skill 分别在做什么；难的是把“一个看起来有趣的点子”变成真正有用户价值的流程；更难的是，在近 700 份参赛申请里，判断自己的作品是不是又一个“合理但重复”的答案。

这篇文章想记录一个技术小白的参赛过程：我如何从活动规则出发让 AI 帮我做 Skill；第一次为什么没有真正报名成功；以及在“多人点餐”和“MBTI 点餐”两次撞题之后，我开始重新思考：当 AI Coding 降低开发门槛后，我们做出来的作品到底应该带来什么？

01 一开始，我连“提交到哪里”都弄错了

先说我踩过的第一个坑。

我的作品代码和文档最初放在自己的 GitHub 仓库里。这个动作本身没有问题——参赛项目本来就需要使用自己的公开仓库来承载项目内容。

但我把“报名”也理解成了在自己的仓库里提交，第二天检查结果才发现：我没有到麦当劳官方活动仓库的 Issue 区发起参赛申请。

也就是说，我完成了“上传作品”，却没有完成“报名”。

这件事没有收到明确的失败提示。后来我才明白：我根本没有进入官方仓库的报名校验流程，自然也等不到失败通知。

正确的关系其实是这样的：

自己的公开 GitHub 仓库
  └─ 放 Skill 源码、README、MCP 集成说明等项目文件

麦当劳官方活动仓库
  └─ 在 Issue 区按指定格式提交“参赛申请”

活动要求项目仓库公开可访问，并包含 README.md、MCP_INTEGRATION.md、不可修改的 CONTEST_DECLARATION.md 和项目主体内容；报名则需要在官方活动仓库按规定格式提交 Issue。

这个错误让我意识到：AI 可以帮我生成文件、写代码，甚至写报名文案，但它无法替我理解“这个链接到底是作品仓库，还是报名入口”。

仓库搞错了

02 小白如何读懂一份 Skill 比赛规则

活动页里通常有很多信息，但我后来发现，最值得先做的是把内容分成三类。

第一类是“能力边界”。

例如麦当劳 MCP 提供的是门店、菜单、餐品详情、优惠、价格试算、订单等能力。它像一组可调用的工具，并不等于一个已经完成的点餐助手。

第二类是“创意示例”。

活动中出现的点餐助手、省钱助手、活动推荐助手，只是示例，不是唯一方向。小白很容易把它们理解成“我只能在这几个题目里选一个”，于是大家自然会做出高度相似的项目。

第三类才是“硬性规则”。

包括仓库公开、文件名、报名 Issue 格式、项目创建时间、参赛声明文件等。这些内容不够酷，却最容易造成报名失败。

我给自己总结了一套简单的读规则方法：

先问：活动提供了什么能力？
再问：哪些只是示例？
最后问：哪些文件、格式、入口是不能错的？

读完规则后，我没有马上让 AI 写代码，而是先让 WorkBuddy 做一件更基础的事：

请检查已连接的 mcd-mcp，列出当前可用的真实工具、
关键参数，以及哪些操作会修改账户或创建订单。
本阶段只做只读查询，不要下单、领券、增加地址或修改账户。

这一步很重要。

因为 Skill 不是一句“帮我点餐”的提示词。它需要明确知道：

• 什么时候查询门店；
• 什么时候查询菜单；
• 什么时候计算价格；
• 什么情况下可以用优惠券；
• 什么情况下必须等用户确认；
• 下单失败、餐品售罄、优惠不可用时怎么办。

MCP 是能力接口，Skill 是使用这些能力的“行为说明书”，WorkBuddy 则是帮助我连接、编写和调试这一整套流程的环境。

03 第一个方向：多人点餐协调员

我最开始选择的是“多人点餐协调员”。

这个想法很自然：朋友或同事一起吃麦当劳时，总会出现“随便”“我都行”“不要辣”“我只喝饮料”“你们决定”的对话。于是我想让 Skill 做一件事：

把混乱的多人偏好整理成一份可确认、可试算、可下单的订单方案。

它的流程大致是：

收集人数、地点、就餐方式和每个人偏好
  ↓
查询真实门店和菜单
  ↓
为每个人匹配候选餐品
  ↓
处理忌口、共享小食、预算冲突
  ↓
试算价格与优惠
  ↓
展示确认单
  ↓
用户明确确认后才创建订单

从功能上说，这个 Skill 没有问题；从用户价值上说，它也确实解决了“谁来做决定”的小麻烦。

但当我继续浏览参赛作品时，发现“多人点餐”“拼单”“套餐推荐”“约束条件点餐”等主题已经很多。

这不是谁抄了谁，而是因为大家面对同一组 MCP 工具时，很容易走到同一个合理答案：菜单、优惠和订单能力最直观，自然就会想到点餐推荐。

这也是我第一次意识到：“能做”不等于“值得做”，更不等于“有辨识度”。

已提交成功

04 第二个方向：根据 MBTI 点餐

后来我尝试了一个更有趣的方向：根据 MBTI 做“16 型麦友饭局”。

我的设想不是“你是 ENFP，所以你必须吃什么”。这种做法既不科学，也容易变成一轮就结束的娱乐测试。

我更希望把 MBTI 变成一个多人沟通的入口。

例如：

• E / I：偏向共享小食和互动，还是更喜欢完整、稳定的个人餐；
• S / N：倾向经典款，还是愿意尝试新品、限定或新组合；
• T / F：优先考虑价格、营养和效率，还是优先照顾每个人的体验；
• J / P：喜欢迅速敲定套餐，还是愿意保留调整和随机惊喜。

真正决定推荐结果的，仍然是用户明确表达的偏好、忌口、预算，以及 MCP 返回的实时菜单和价格。

我已经让 WorkBuddy 完成并提交了这个方向。但在提交时，系统提示存在类似 Skill。

这一次让我更清楚地认识到：换一个更有趣的输入标签，并不天然意味着作品就独特了。

“MBTI + 点餐”有传播性，但如果最终只是“给某种人格推荐一个汉堡”，它仍然只是推荐器的另一层包装。

更有价值的方向应该是：MBTI 只是帮助一群人更快说清自己的点餐偏好，Skill 真正解决的是多人饭局里的协调与共识。

已成功提交

05 看了近 700 份作品后，我开始重新理解“重复”

截至我查看时，官方仓库显示约 697 个 Issue，开放 Issue 约 693 个。官方 Issue 列表

数量多并不可怕，可怕的是我们容易把“重复”简单理解为创意不够。

实际上，重复往往有三个原因：

1. MCP 的可见能力有限，大家都会优先想到菜单、优惠、活动和订单；
2. 大模型擅长给出“合理的默认答案”，而默认答案往往相似；
3. 我们太早从“功能”出发，而没有从一个具体用户在具体时刻的困难出发。

后来我给自己增加了四个问题。做任何 Skill 前，都先问：

1. 用户会在什么时刻主动打开它？
2. 他原来是怎么解决这个问题的？
3. MCP 能替他完成哪一个真实动作？
4. 不用这个 Skill，和用了它，结果有什么可感知的区别？

比如“多人点餐”不应该只描述为“推荐餐品”。

它可以进一步被定义成：

当所有人都说“随便”、但每个人又都有一点要求时，帮助发起人把一场无法推进的群聊变成一张能下单的确认单。

这才是一个相对清晰的任务闭环。

提醒有相似的skill

06 谁的 Skill 最好用？

活动排名会参考公开 Star，但 Star 更接近传播和曝光，并不完全等同于一个 Skill 是否真正好用。官方排名说明

在我看来，一个好用的 Skill 至少有四个标准：

所以，最好的 Skill 未必是名字最酷、功能最多的那个。

它更可能是一个能把高频、具体、原本需要反复沟通的任务，稳定推进到下一步的工具。

07 AI Coding 降低门槛后，我们还要带来什么价值？

这次参赛最大的收获，不是学会了怎样让 AI 生成一个 Skill。

而是开始理解：AI Coding 降低的是“把想法写成代码”的门槛，但没有降低下面这些能力的门槛：

• 找到值得解决的问题；
• 判断什么是功能，什么是真正的用户价值；
• 设计 AI 不能越过的确认边界；
• 让真实工具在真实场景里稳定工作；
• 把一次性的想法整理成别人能看懂、能复用、能验证的项目。

以前我会问：“我能不能做出一个 Skill？”

现在我更愿意问：“如果这个 Skill 消失了，用户会不会真的觉得少了什么？”

如果答案是否定的，那它可能只是一次漂亮的生成。

如果答案是肯定的，那么即使它不是比赛中最炫目的项目，它也可能是一个真正有价值的开始。