推荐菜单上线两周就被店主关掉 - 餐饮小程序智能推荐的三个失败样本和一条正确路径
先说翻车，再说怎么救
去年帮几个开小吃店的朋友做过菜单推荐，也看过不少独立开发者接的同类单子。有个共同现象：智能推荐功能上线时惊艳，两周后店主主动要求关掉。原因不是模型不行，而是实现方式从第一天起就埋了雷。
失败样本一：把推荐当成“猜你喜欢”的炫技。开发者直接调大模型，把用户随手点过的两三个菜喂进去，让模型生成一段两百字的推荐文案。结果用户在饭点打开小程序，等了八秒看到一段文绉绉的“匠心之选”，直接退出。餐饮场景里，用户要的是三秒内看到五个菜名和价格，不是散文。
失败样本二：推荐和点餐流程脱节。推荐位单独做了一页，用户看完推荐还得自己回菜单页搜索下单。转化路径多一步，推荐再准也白搭。有个店的推荐点击率其实不错，但推荐位到下单的转化几乎为零，店主一看数据就失去了耐心。
失败样本三：接了五家模型供应商，密钥和调用逻辑散落在代码各处。今天A家降价切A家，明天A家限流切B家，每次切换都要改代码、重新发版。一个人维护三个餐饮小程序的客户，光应付模型接口变更就占掉一半时间，最后算下来时薪不如接普通外包。
这三个样本对应三条正确路径：推荐要贴着点餐动线做、场景要窄要快、模型调用要收敛到统一网关。
业务痛点到底是什么
回到餐饮场景本身，店主关心的问题其实很朴素：
- 客人不知道吃什么，翻菜单五分钟不下单，高峰期占着桌子；
- 新菜没人点，老三样点腻了客人就不来了；
- 午市和晚市、工作日和周末的客群不同，同一张菜单不该用同一套推荐。
技术侧的约束同样明确：饭点并发集中、用户等待容忍度低（三秒是红线）、小程序包体和后端成本都要控。所以推荐系统的目标不是“千人千面的精准”，而是“在正确的位置、用可接受的速度，给出比静态排序更好的菜单顺序”。
架构设计：小而分层的方案
给独立开发者和小团队的建议是三层结构，不要上来就搞特征平台和向量数据库全家桶：
第一层：规则层（常驻缓存）。按时段、天气、菜品标签做基础排序。午市推套餐和快手菜，晚市推小食和酒水，下雨天推汤类。这一层不依赖模型，响应零延迟，是兜底。
第二层：模型层（异步预计算）。不要在用户请求时实时调模型。用定时任务在非高峰时段预生成推荐结果：把门店菜品数据、近七天脱敏后的点餐统计（只留菜品的聚合热度，不含个人信息）、用户的历史订单品类偏好，喂给模型生成结构化推荐列表，存入数据库。用户请求时直接读库，延迟可控在毫秒级。
第三层：反馈层。记录推荐位的曝光和点击，作为下一轮预计算的输入。没有反馈的推荐会越推越偏，这是很多项目烂尾的真正原因。
关键实现步骤
- 菜品数据结构化：每个菜打上品类、口味、辣度、出餐速度、毛利标签，这是推荐的原材料；
- 搭规则层兜底排序，先上线跑通，保证没有模型也能用；
- 写预计算任务，定时组装上下文调用模型，解析结果校验后入库；
- 推荐位嵌入点餐首页和购物车页，用户点推荐菜直接加购，砍掉跳转；
- 埋曝光和点击事件，回流到预计算输入；
- 配置降级策略：模型调用失败时静默回退规则层，用户无感知。
预计算任务的核心调用逻辑大致是这样：
def precompute_recommendations(shop_id):
dishes = get_dishes_with_tags(shop_id)
stats = get_anonymous_aggregate_stats(shop_id, days=7)
context = build_prompt(dishes, stats, time_slot="dinner")
result = gateway.chat(
model="gpt-4o-mini", # 推荐任务用小模型即可，成本和速度都合适
messages=context,
response_format="json",
fallback_model="claude-3-5-haiku",
timeout=10,
)
items = validate_and_filter(result, dishes) # 校验模型没编造不存在的菜
save_recommendations(shop_id, items)为什么统一AI API网关能省下大半维护成本
注意上面代码里没有出现任何供应商的密钥、域名和 SDK，只有一个 gateway。这正是针对失败样本三的解药。
直连各家模型 API 意味着：每家一套认证方式、一套错误码、一套 SDK 版本。模型供应商调价、限流、下线旧版本是常态，五家供应商就是五份随时会变的依赖。散落在业务代码里的调用点越多，每次变更的排查和修改成本越高——对一个人维护多个客户项目的开发者来说，这种成本是乘法不是加法。
统一网关把差异收敛到一处：业务代码只对接一个稳定接口，换模型、加备用模型、调整超时和降级策略，都只是网关侧的配置变更，不用碰业务代码、不用重新发版。密钥集中管理而不是硬编码在代码里，也给多客户、多环境的项目省掉了不少安全麻烦。此外，网关的统一日志能看清每个客户项目的调用量和成本，月底对账不用翻五家后台。
对餐饮这种利润敏感的场景，还有个实际好处：推荐这类非关键任务可以指定便宜的小模型，并在网关配置降级链，主模型抖动时自动切备用，店主和用户都不会察觉。
收尾
智能推荐菜单不需要大团队和重架构，它需要的是克制：窄场景、预计算、贴动线、有反馈，再把模型调用的杂活交给一层网关去统一消化。如果你正在找这样一个统一入口，把多家模型的调用、降级和密钥管理收进一处，可以看看 https://api.thistoken.ai/register，注册后几分钟就能跑通第一个请求。
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。