餐饮小程序的推荐菜单改造 - 一周上线，每月省下两万元
写在前面
独立开发者小林接了一个活：给一家连锁轻食品牌（12家门店）的小程序加“智能推荐菜单”功能。客户的要求很朴素——用户打开小程序，看到的不再是固定排序的菜品列表，而是“猜你想吃”。客户给的预算有限，工期两周。
这个案例记录了小林团队（2人）如何在7个工作日内交付，以及为什么这次架构选型让后续维护几乎“零成本”。如果你也是接定制项目的独立开发者或小团队，这篇的思路可以直接搬走。
业务痛点：推荐菜单为什么一直做不起来
接手前，客户的小程序已经有“热销榜”，但数据很平庸：菜单点击转化长期停在个位数。痛点集中在三处：
- 千人一面。所有人看到同一份热销榜，减脂用户看到炸鸡，晚餐用户看到沙拉，错配严重。
- 冷启动难。新用户没有行为数据，传统协同过滤直接失效，只能退回固定列表。
- 维护黑洞。客户此前找过一家外包做过基于规则的标签推荐（“辣度偏好”“时段加权”），上线三个月后规则膨胀到两百多条，外包跑路后没人敢动，推荐准确率反而不如热销榜。
对小林团队来说，还有第四个痛点：工期。两周内从零搭推荐系统，如果自己接多家模型、管理各自的SDK和密钥，光是联调和鉴权调试就要吃掉一半时间。
架构设计：轻量三层 + 统一AI网关
最终架构刻意做减法，只有三层：
第一层：特征采集（小程序端 + 轻后端）
只采三类信号，不贪多：
- 显式：用户首次进入时的3个选择题（口味、忌口、场景：一人食/聚餐/减脂）
- 隐式：近30天点击、加购、下单的品类与价格带
- 上下文：当前时段、门店、天气（天气对轻食/热食选择影响显著）
第二层：推荐服务（一个云函数搞定）
核心思路是“规则粗筛 + LLM精排”：
- 用简单规则从全量菜单中筛出30~50个候选（排除忌口、匹配时段和价格带）；
- 把用户画像摘要 + 候选菜品列表（含价格、标签、毛利率）拼成Prompt，交给LLM做精排和推荐理由生成；
- 返回Top 10，每道菜附带一句个性化推荐语（“下午茶时间，这份低卡酸奶碗很适合你”）。
第三层：统一AI网关
所有模型调用走同一个网关，后端只维护一个Base URL、一个Key。这是整个项目工期被压缩到7天的关键，下面细说。
关键实现步骤与核心代码
流程清单（实际排期）：
- [ ] Day 1：特征字段定义，与客户小程序打通埋点
- [ ] Day 2：规则粗筛逻辑（纯代码，可单测）
- [ ] Day 3：Prompt模板设计 + 网关接入
- [ ] Day 4：精排结果解析、异常降级（LLM超时则退回热销榜）
- [ ] Day 5：AB开关与门店维度配置
- [ ] Day 6-7：联调、压测、灰度上线
核心精排调用（Node.js，已脱敏简化）：
const CANDIDATES = await ruleFilter(userCtx); // 规则粗筛：30~50个候选
const prompt = `你是餐饮推荐专家。基于用户画像为候选菜品排序，返回JSON。
用户画像：${JSON.stringify({
口味: userCtx.taste,
忌口: userCtx.taboo,
场景: userCtx.scene,
历史偏好: userCtx.recentCats, // 近30天品类偏好
当前时段: userCtx.timeSlot,
天气: userCtx.weather,
})}
候选菜品（id/名称/标签/价格/毛利率）：
${CANDIDATES.map(c => `${c.id}|${c.name}|${c.tags}|${c.price}|${c.margin}`).join('\n')}
要求：返回10个，格式 {"list":[{"id":"...","reason":"20字内推荐理由"}]}，兼顾用户偏好与毛利。`;
const res = await fetch(`${GATEWAY_URL}/v1/chat/completions`, {
method: 'POST',
headers: { Authorization: `Bearer ${GATEWAY_KEY}` },
body: JSON.stringify({
model: MODEL_NAME, // 网关路由，切换模型只改这一处
messages: [{ role: 'user', content: prompt }],
response_format: { type: 'json_object' },
timeout_ms: 3000,
}),
});
// 解析失败或超时 → 降级返回热销榜，保证小程序永远有菜单可展示注意两个工程细节：降级路径必须先写，LLM不可用时退回热销榜，推荐是增强不是依赖；Prompt里带毛利率，让推荐在用户体验和客户营收之间取得平衡——这一点让客户验收时非常满意。
为什么统一AI网关能省下真金白银
算一笔维护账。如果直连三家模型厂商，你需要：三套SDK、三个Key的管理与轮换、三套限流重试逻辑、三次计费对账。以小林团队过往经验，每次模型升级或接口变更，平均要花1~2天人肉适配；一年下来这类适配发生5~8次，就是一周以上的纯维护工时。
统一网关之后：
- 一个Key、一个接口对接所有模型，接入从原来预估的2天压到半天；
- 模型切换（比如精排从大模型换到更便宜的中档模型）只改一个字符串，成本敏感期他们把单次调用成本降了约60%；
- 网关侧统一处理超时、重试、多Key轮询，后端代码里不再有散落的容逻辑；
- 调用日志集中可查，客户问“推荐为什么不准”时能分钟级回放当时的请求。
这次项目总投入约14人天。对比客户之前那套规则推荐系统（外包报价约8万、上线3个月即失修），这次交付费用不到一半，且后续每月维护投入估算从外包时代的“不敢估算”变成约2人天/月——这就是架构层面省下的钱。
上线之后
灰度两周的对照数据（客户自有埋点，未经我方加工）：开启推荐的门店，菜单点击转化高于纯热销榜的对照门店，且新用户（冷启动人群）提升最明显——因为画像题+LLM让新用户第一次打开就拿到“像被懂了”的菜单。
对小林团队来说更有价值的是：这套“规则粗筛+LLM精排+统一网关”的模板，后来被复用到了奶茶店套餐推荐和生鲜小程序的搭配推荐，每次只需改特征字段和Prompt,新项目交付周期稳定在5天以内。
写给同样在做AI落地的小团队
推荐系统听起来是大厂专属，但把“算法”外包给LLM、把“工程”收敛到网关之后，两个人的团队也做得动。如果你的项目也要接多家模型、被Key管理和接口适配拖慢节奏，可以试试统一AI API网关，注册就能拿到统一接入的Key，把时间省下来做真正差异化的部分：https://api.thistoken.ai/register
---
想直接跑通示例？访问 https://api.thistoken.ai/register 注册 ThisToken.AI，获取 API Key 后即可开始。