周六下午，两个小时都花在了一个比赛页面上。
麦当劳办了一场程序员创意开发大赛。
我挑的题目很小，帮人点一顿饭。
不是推荐一个汉堡。
是把热量、价格和下单串成一条线。
听上去不难。
这次开发我没开新项目，也没写后端。
从需求拆解到接口联调，全在 WorkBuddy 里推进。
它不替我想产品，只帮我把每一步落成文件。
剩下的活，都在接口返回里。
大赛活动页，WorkBuddy 与麦当劳联合命题
一 从一顿不敢点的饭开始
想法来自一次真实的窘境。
训练日想吃麦当劳，又怕蛋白质不够，钠也超标。
打开点餐页，只看到套餐名和价格。
热量要另开一个页面查，优惠券还得自己算。
几件事散在四个地方。
我干脆把它做成一个助手。
输入一句话，它把营养账和价格账一起办了。
项目叫 McFit Coach。
形态很轻，一个技能加一个远程接口，没有自建后端。
这类活对 AI编程 来说不算难，难的是边界。
我最开始只想做推荐。
后来发现，推荐完了还得算价，算完价还得下单。
少一环，用户就得多开一个应用。
所以它得会查，会算，也会问。
比如你说想减脂，它会先把预算问清。
热量上限多少，蛋白质想补到几克，钠能接受到什么水平。
这三个数一变，推荐结果就完全不同。
不说清楚，它给的方案跟随便点一个没区别。
菜单还是实时的，早市和夜市的品不一样。
同一家店，十点和十一点看到的选项可能完全不同。
它能做的事不少。
看当前时间，分辨早市和夜市。
把接口返回的营养数据建成索引，方便反复查。
查附近门店，默认北京，也能在对话里换城市。
拆套餐，去酱，把可乐换成无糖，都在同一轮里完成。
在热量和蛋白质还有钠的预算下，筛出几组候选。
把门店券和账户券一起算，得出实际到手价。
用户点头之后，才创建订单。
还有一个规划中的能力，用历史订单做一张体检卡。
这些动作全发生在一次 AI对话 里。
没有按钮，没有表单，用户只说一句想吃什么。
它不是一个只会聊天的 AI工具。
菜单和券还有订单，都得它自己去拿。
差一步，就退回聊天框。
这就是分界线。
第一句提示词，先建一个空项目
二 一个入口文件，三个角色
架构里有三个角色。
技能负责编排，接口负责数据，本地脚本负责算。
入口是 SKILL.md，大写，放在项目根目录。
触发条件和调用顺序，还有几条安全规则，全写在里面。
目录里还留着一份接口实测记录。
哪次返回了什么，改过哪一行，都写下来。
第二句提示词，把规划书交给它拆
这里得先划两条边界。
营养数据和价格以官方实时接口为准。
输出不构成医疗建议，也不替人做决定。
创建订单是真实写操作，技能不会自己点。
它可能出错，所以每一步都要能回看。
项目最初被拆成八块。
认时段，解营养，选门店，拉菜单。
拆套餐，解组合，算价格，下单。
第八块是体检卡，先留着。
拆完我没有让它一次写很多代码。
而是按真实接口的顺序，一段一段落。
每轮联调确认的约束，当场记进文档。
举个让我改稿的例子。
规划书里写着，薯条可以换成玉米杯。
真去调套餐详情才发现，替换只能发生在同一轮的候选项里。
板烧三件套的小食轮，压根没有玉米杯。
产品设想得给接口返回让路。
凭常识猜替换关系，一定翻车。
添加自定义模型
三 配置这一段最容易翻车
名字要一模一样，差一个后缀都报错。
连通性测试
测试通过，再让它读一遍说明文件。
这一步能把模型故障和代码故障分开。
省下的排查时间，比配置本身值钱。
测的时候别只看它回了一句话。
要看它能不能稳定回，超时和报错也得试。
开放平台登录
登录进去，第一件事是找凭证。
控制台的 Token
凭证别写进仓库，也别出现在截图里。
管理连接器
选流式协议
点自定义配置，填四行就够。
服务名随便起，地址是官方那一串，鉴权写 Bearer 加凭证。
保存之后还有一步，很多人漏掉。
要手动启用这个连接器。
不启用，技能里一个工具都调不到。
手动启用连接器
四 一次真实下单，闭环才算完
它一共用到十个工具。
看时间，查营养，找门店，拉菜单。
拆套餐，查门店券，查账户券。
算价，下单，读历史订单。
顺序不能乱。
菜单和价格跟着门店走，套餐明细又跟着菜单走。
只有候选定了，券和算价才有意义。
下单必须放最后，等用户确认再触发。
营养接口返回的格式有点怪。
不是 JSON，是一段 TOON 文本。
首行给字段名，下面一行一条记录。
看起来像 CSV，但不能直接按逗号切。
有的字段是空值，有的描述里自带逗号。
所以先存一份真实样本，再围着样本写解析。
价格单位也埋过坑。
菜单接口给的是元，算价接口给的是分。
展示的时候忘了除以一百，一单便宜了一百倍。
组合求解也没全丢给远程。
先在本地把主餐和小食还有饮品枚举一遍。
按预算筛出前几名，只对这几组调算价。
这样网络请求少，也不容易撞上限流。
更重要的是，算法能离线测。
改一次筛选逻辑，不用等接口。
不过本地只负责缩小范围。
最终价格和券能不能用，商品还在不在，都以接口为准。
有一次我少传了门店编码，它照样返回菜单。
价格看着正常，门店却是上一家的。
这种错不会报错，只会悄悄算错。
所以现在每次联调，我都把门店编码打出来核一遍。
接口还会返回空值，直接拿去做加法会崩。
解析器里先垫一层默认值，比事后补一遍更省事。
宁可多花半小时核对接口，也别凭商品名猜规则。
门店推荐
营养和价格都摊开
第二屏看细节。
确认后建单
支付链接
扫码就能付。
手机端支付页
扫完码能看到商品已经进了购物车。
核对一遍，付掉，这一单才算真的走完。
整条链路跑通那天，我盯着页面看了很久。
让我意外的不是它能下单。
是它把每一步都说得清。
为什么推荐这个套餐，热量多少，券省了几块。
写这套东西花的时间，大半不在写代码。
在把每个接口的边界摸清楚。
价格单位是元还是分，替换能不能跨轮，写操作要不要二次确认。
这些事文档里不一定写，返回里一定有。
真正的门槛不在模型有多强。
在于你愿不愿意为一次点餐，把账算到分。
