一、思考在完成 AI 问答页的基础搭建后我开始思考如果这个页面真的面向用户使用它应该像什么我觉得他的回答必须要更加专业可以在生活中可以真实可用。所以后续打磨我主要围绕两条线展开让回答更像餐饮顾问而不是普通聊天让用户能直接拿回答去点餐二、知识增强和回答结构化如果只是把用户问题直接扔给大模型回答很容易泛化像普通闲聊。但餐饮场景的价值在于“更具体、更贴上下文”。我在后端逐步补了一个轻量 RAG 链路后续接入知识库之后可以考虑加入向量化让这个功能更加专业主要思路是本地知识样本轻量 query rewrite中文关键词匹配标签加权意图分路检索去重与去噪排序检索日志落库知识样本覆盖的内容主要有四类菜品术语解释过敏原与风险提示点餐表达常见菜品知识这样一来AI 问答就不再只是“模型随便生成一段”而是会结合命中的知识结果来回答。因为是其他队友负责的知识库的构建所以需要这种开会后再进行接入目前知识本地的知识样本。三、点餐功能添加用户在真实场景里最容易卡住的不是知道这道菜有风险而是知道有风险之后怎么问店员不吃生食、少辣、过敏这句话怎么说去日本、韩国、英语环境下该怎么表达能不能直接播给店员听所以我后面专门把 ordering_phrase 做成了一个独立子能力。它不只是返回一句文本而是会生成一个结构化卡片大概包含目标语言简洁版表达礼貌版表达中文翻译发音辅助备注而且它支持多种场景询问是否含花生/奶/过敏原表达少辣表达不吃生食请求推荐更安全的菜明确想点某一道菜最后一点很重要。因为我后面发现用户意图不总是“帮我判断能不能吃”有时用户其实已经下定决心比如说不能吃生食但是坚定点刺身饭我就是想点刺身饭给我生成点单句这是给朋友点的如果系统一味只告诉用户“你不能吃”“不建议点”体验会很差。后来我调整了后端逻辑在“明确点单意图”场景下优先顺着用户的真实意图先给可用表达再补风险提醒而不是只做劝退。四、多语言和语音播放、收藏复用点餐表达一旦做出来自然就会走到下一步用户看得懂句子不代表用户敢开口说。所以我继续把多语言和 TTS 接了进去。目前支持的目标语言主要有后面开会讨论具体应该要支持多少语言比较好英语日语韩语语言来源也做了优先级判断用户问题文本里显式提到的语言页面显式选择的语言用户偏好语言默认回退到英语在语音这块前端不是只用本地 TTS而是已经和后端 TTS 接口打通后端负责调用云端 TTS 合成前端负责播放音频如果云端失败再回退本地 TTS如果都失败也不崩保留文本展示一旦点餐表达可用了另一个自然的问题就是用户有没有可能经常重复用同一类表达答案当然是会。比如我对花生过敏这种确认句我以后还会用我不吃生食这种表达会反复出现少辣、礼貌确认、请店员推荐安全选项这些都是高频句所以我把项目里原本只有雏形的收藏页逐步改成了“点餐表达收藏页”。收藏后用户可以本地持久化保存查看收藏内容复制 simple / polite 表达播放语音删除点击收藏可以在收藏页面看到。五、收获到目前为止这个 AI 问答模块已经基本具备了演示价值和继续扩展的结构基础。后续推进应该会是接入真实用户偏好接入真实菜单历史升级知识库和检索质量进一步打磨点餐表达翻译与语音体验目前前端比较不美观等开发差不多再打磨