项目优化实践：如何让智能点餐系统推荐更快、交互更稳

在本项目中，系统最初已经具备菜单识别、菜品翻译、购物车、生成点单句、今日推荐和个性化推荐等功能。但在真实使用和答辩演示中，一个很明显的问题是：部分 AI 功能响应时间偏长，尤其是主链路推荐和今日推荐这类依赖大模型的功能。如果用户点击后等待太久，即使推荐结果准确，体验也会受到影响。

因此，我围绕“减少等待时间、提升接口稳定性、降低无效调用、保证演示可用”这几个目标，对项目进行了多处优化。

一、优化背景：为什么功能会变慢

项目中的慢主要不是单一原因造成的，而是多个环节叠加。

首先，推荐功能需要调用大模型。大模型需要读取菜单候选、用户输入、个人偏好、收藏菜品、购物车内容和推荐官 skill，这些上下文越多，prompt 越长，模型响应时间就越长。

其次，今日推荐曾经还会叠加位置和天气请求。如果每次刷新都重新获取位置、请求天气、生成候选菜，再调用模型，整个链路就会变得很重。

第三，部分推荐逻辑早期存在后端关键词初筛。虽然它看起来能提前缩小范围，但实际会带来额外逻辑复杂度，而且容易因为关键词匹配不到而走兜底逻辑，反而影响推荐质量和稳定性。

第四，语音生成也存在模型调用方式不匹配的问题。实时语音模型和 HTTP 非实时接口不是同一条链路，如果模型配置不正确，就可能出现“点单句生成成功，但语音没有生成”的情况。

二、模型层优化：统一使用更快的模型

为了提升响应速度，我将推荐相关模型统一调整为 qwen3.6-flash。

这个模型更适合当前项目中的高频交互场景，例如主链路推荐、今日推荐、点单句生成等。相比更大的模型，它的响应速度更快，答辩演示时等待时间更短。

主链路推荐不需要模型写长篇文章，而是需要在候选菜单中选择合适菜品，并输出推荐理由和标签。今日推荐也类似，核心是快速结合天气、收藏和个人偏好生成一个合理推荐。因此使用 flash 模型是比较合适的选择。

点单句文本生成也改为 qwen3.6-flash。点单句的目标是生成一句自然、礼貌、可直接使用的表达，不需要复杂推理，因此更快的模型可以明显改善体验。

三、主链路推荐优化：减少后端规则，把理解交给模型

主链路推荐原本会根据用户输入做关键词初筛，比如“清淡”“不辣”“想吃肉”“预算低”等。这个逻辑的问题是，用户表达方式很多，后端规则很难覆盖所有情况。

例如用户可能输入“今天想吃点不油腻的”，这和“清淡”意思接近，但关键词规则不一定能稳定识别。与其在后端写越来越多规则，不如把用户输入完整交给大模型理解。

因此我将主链路推荐调整为：后端不再根据用户输入做复杂初筛，而是把用户输入、候选菜单、个人推荐官 skill、用户偏好和购物车禁用项一起作为 prompt 输入给 Qwen。

这样做有两个好处。

第一，逻辑更简单，减少了后端规则判断带来的额外复杂度。

第二，推荐更灵活，模型可以直接理解自然语言需求，而不是被固定关键词限制。

为了避免 prompt 过长，我保留了候选菜单数量控制，只把有限数量的候选菜传给模型。这样既能让模型看到足够信息，又不会因为上下文过大拖慢速度。

四、今日推荐优化：去掉不必要 GPS，减少刷新成本

今日推荐最初设计中包含 GPS 定位逻辑，但在实际使用中，GPS 会增加权限、等待和失败风险。对于答辩演示来说，定位不稳定会直接影响功能展示。

因此我删除了前端 GPS 定位逻辑，改为后端基于高德接口获取较轻量的位置和天气信息。这样用户进入今日推荐页面时，不需要额外授权，也减少了前端等待。

同时，天气请求加入了缓存机制。短时间内多次刷新时，不需要重复请求外部天气接口。这样可以减少网络开销，也能降低因为第三方接口波动导致推荐失败的概率。

今日推荐现在的核心链路变成：读取个人推荐官 skill、读取收藏菜、读取天气信息、读取短期拒绝记忆，然后直接调用模型生成推荐。如果模型超时或失败，则使用本地兜底推荐，保证页面不会一直空白。

五、Reflexion 短期记忆优化：刷新不再是简单重试

今日推荐中一个很重要的体验问题是：用户点击刷新后，如果系统仍然推荐同一道菜，会让人感觉刷新没有生效。

因此我加入了短期 reflexion memory。刷新按钮不再只是重新请求，而是表达“这次推荐我不满意”。系统会把当前推荐菜加入短期拒绝记忆，下一次推荐时把这些菜作为禁止项告诉模型。

这样模型会明确知道：刚才推荐过的菜不要再推荐。

这部分记忆不会写入用户长期 skill 文件。原因是一次刷新只代表当前不满意，不代表用户长期不喜欢这道菜。长期 skill 用来记录稳定偏好，短期 reflexion memory 用来处理当前会话中的即时反馈，两者分开更合理。

六、接口稳定性优化：超时和兜底机制

AI 功能最大的问题之一是不确定性。模型接口可能慢，第三方天气接口可能失败，网络也可能波动。

为了保证答辩和实际使用稳定，我给今日推荐的大模型调用增加了较短超时。如果模型在指定时间内没有返回，系统不会一直等待，而是进入兜底逻辑。

兜底逻辑会根据收藏菜、个人偏好和本地候选生成一个可用推荐。这样即使大模型暂时不可用，用户仍然能看到结果。

这类优化的重点不是让每一次都完全依赖模型，而是保证功能在不稳定环境下仍然可用。

七、点单句与语音优化：区分文本模型和 TTS 模型

点单句功能分为两个阶段。

第一阶段是文本生成，也就是根据购物车内容生成一句自然点单表达。这个阶段使用 qwen3.6-flash，速度更快，适合生成短句。

第二阶段是语音生成，也就是把点单句转换成可播放音频。这里需要注意实时 TTS 和非实时 TTS 的区别。项目当前链路使用 HTTP 非实时接口，因此应该使用 HTTP 兼容的 TTS 模型。

之前如果误用 qwen3-tts-instruct-flash-realtime，就会出现只生成文本、不生成语音的问题。原因是 realtime 模型需要 WebSocket 实时语音链路，不能直接复用当前 HTTP 接口。

因此我将当前点单句语音链路调整为 HTTP 可用的 qwen3-tts-instruct-flash，并增加兼容处理。如果环境变量中误填了 realtime 模型，后端会自动转为 HTTP 兼容模型，避免语音生成失败。

八、前端体验优化：减少小屏设备布局问题

速度优化不只在后端。前端页面如果出现溢出、按钮挤压、文字显示不完整，也会影响用户对功能流畅性的感受。

因此我对首页进行了响应式调整。首页会根据手机屏幕宽度自动调整左右边距、上传卡片图标大小、标题字号、常用功能卡片高度和今日推荐入口按钮尺寸。

这样在小屏手机上，按钮不会挤压文字，功能卡片也不容易出现 overflow。对于答辩演示来说，这能减少现场因为设备尺寸不同导致的页面异常。

九、优化后的整体效果

经过这些优化后，项目的交互链路更加轻量。

主链路推荐减少了后端规则复杂度，把自然语言理解交给模型，同时控制候选数量，降低 prompt 压力。

今日推荐删除了前端 GPS 定位，加入天气缓存、模型超时和本地兜底，并通过短期 reflexion memory 避免重复推荐。

点单句生成使用更快的文本模型，语音生成修正为当前接口兼容的 TTS 模型，减少“有句子没语音”的情况。

前端首页则根据屏幕大小自适应，减少小屏设备布局问题。

整体来看，这些优化不是单纯“换一个更快的模型”，而是从模型、prompt、接口、缓存、兜底和前端布局多个层面共同降低等待时间，提高稳定性。

十、总结

本次优化的核心目标是让项目从“功能能跑”提升到“功能好用、演示稳定、响应更快”。

在 AI 项目中，性能优化不能只看模型本身。真正影响体验的是整条链路，包括是否有不必要的外部请求、prompt 是否过长、是否有超时机制、失败后是否能兜底、前端是否能稳定展示结果。

通过这次优化，项目中的推荐、点单句、语音和首页交互都变得更加适合真实使用，也更适合答辩展示。用户不需要长时间等待，也不容易遇到空白页、重复推荐、语音缺失或页面溢出等问题。最终系统从一个多功能原型，进一步变成了一个响应更快、链路更完整的智能点餐助手。