第一次小组会议从选题讨论到技术路线确定我们为什么做“AI 点餐助手”前言第一次组会对整个项目来说非常关键。因为第一次会议不仅决定“我们做什么”更决定“我们为什么这样做”以及“后面怎么落地”。这次会议中我们围绕两个核心问题展开了讨论项目选题到底是什么技术路线应该怎么定经过讨论我们最终确定了项目方向——菜单翻译官AI 点餐助手。它的目标不是简单把菜单翻译出来而是希望帮助用户完成从菜单识别、语义理解、风险判断到个性化推荐和现场点单表达的完整过程。这个方向也成为了我们开题 PPT 的主要成果。一、第一次组会我们先解决了“做什么”的问题项目刚开始时大家的想法其实很多。有同学想做校园场景有同学想做生活服务类应用也有人希望能结合 AI 做出更有创新性的项目。但我觉得小组项目最忌讳的一点就是想法很多方向不清。所以在第一次组会上我先带着大家统一了一个思路我们要做的不是一个简单拼功能的作业而是一个有明确场景、有真实痛点、也有技术亮点的项目。于是我们围绕以下几个问题做了讨论用户真实会遇到什么问题这些问题是不是高频、具体、值得解决AI 在这个场景中到底能提供什么价值以我们现在的能力和周期能不能做出原型正是在这个框架下我们逐步收敛出了最终的项目方向。二、为什么选“菜单翻译官——AI 点餐助手”这个题目我们最后确定的选题是菜单翻译官——AI 点餐助手这个选题来源于一个很真实的生活场景在出境旅游、留学、国际商务等就餐环境中用户经常会遇到“看不懂菜单、不敢随便点、怕点错”的问题。PPT 里也明确提到菜单不仅包含菜名还涉及做法、口味、分量、食材和文化语境单纯的逐词翻译很难支撑用户做出有效判断。也就是说用户真正需要的不是一个只会“翻译文字”的工具而是一个能够帮助他看懂菜单理解菜品判断风险快速筛选最终开口点单的智能助手。因此我们一致认为这个项目的价值不应该停留在“翻译菜单”这一步而应该升级为一个围绕真实点餐场景设计的AI 辅助决策系统。PPT 中对项目的定位也非常明确它提供的是“菜单翻译 风险提示 个性化推荐 点单表达”的一体化支持。三、第一次会议中确定下来的核心功能选题定下来之后我们没有停留在概念层面而是继续讨论这个系统到底应该具备哪些功能1. 菜单识别与结构化提取这是整个系统的入口。用户可以拍照上传菜单也可以从相册中导入图片系统对菜单中的文字区域进行识别并提取菜名、价格、描述等信息。PPT 中也强调了系统要支持复杂背景、艺术字体和竖排文字这说明我们的目标并不是只处理“干净截图”而是尽量贴近真实餐厅场景。2. 风险信息提示这是我们讨论中非常重要的一点。因为点餐不只是“想吃什么”有时更重要的是“能不能吃”。比如用户可能关注是否含花生、虾、乳制品、麸质等过敏原是否生食是否含酒精辣度高不高是否符合清真、低卡、无辣等限制PPT 中提到系统会将过敏原、辣度、生食、酒精等信息前置展示并做标签化提示。这样用户在浏览菜单结果时不需要再次检索或自己判断就能直接做出更安全的选择。3. 个性化推荐如果系统只是把菜单识别出来用户仍然要自己在大量菜品中做选择这个决策成本其实并没有真正降低。因此我们在第一次会议中提出系统还需要根据用户偏好做动态重排。PPT 里也提到推荐页会结合用户设置的口味倾向、食材偏好和饮食限制进行推荐并给出推荐理由。比如偏好清淡的用户优先推荐低油低辣菜品不吃辣的用户系统自动避开刺激性菜品海鲜过敏用户自动标注相关风险肉类偏好用户优先展示对应本地特色菜这意味着系统从“信息展示”进一步走向了“辅助决策”。4. 点单表达辅助这是我们组会中一致认为最有亮点的一部分。因为用户真正的难点不仅是“看懂菜单”还有“怎么把菜点出来”。PPT 中明确提到系统会提供菜名标准发音和场景化点餐短句帮助用户从“知道点什么”走到“真正点出来”。这一点非常重要因为它让产品从一个识别翻译工具升级为一个真正面向现实场景的点餐执行助手。四、第一次会议里我们也把产品页面结构梳理清楚了为了让项目不只停留在想法阶段我们在第一次会议中还初步确定了页面结构这其实也是一次非常重要的推进。首页智能菜单识别中心首页主要承担入口功能包括拍照识别相册上传历史记录查看这样的设计非常贴近真实使用场景用户既可以现场拍菜单也可以提前上传菜单做研究还可以从历史记录中快速回看之前识别过的内容。推荐页AI 智能点餐助手推荐页主要负责体现系统的智能能力。根据 PPT推荐逻辑主要基于两类信息用户所在国家/城市对应当地特色菜推荐用户口味偏好与饮食限制对菜单进行个性化筛选此外每一条推荐还会附带“推荐理由”提升系统的可解释性让用户知道系统为什么这样推荐。收藏页我的美食记忆库收藏页看起来是个常规功能但实际上对产品长期价值很重要。它能把用户感兴趣的菜品沉淀下来形成可复用的个人菜单记忆库。PPT 中也提到可按国家、地区和菜品类型做分类查看。:contentReference[oaicite:10]{index10}我的页面个人饮食档案这一页主要负责用户画像的管理包括口味倾向食材偏好饮食限制过敏原设置这部分虽然不是最“炫技”的模块但却是整个推荐与风险提示逻辑成立的基础。没有用户画像系统很难真正做到智能推荐。五、第一次会议中最重要的部分技术路线怎么选如果说前面的讨论解决的是“做什么”那技术讨论解决的就是“怎么做”。在这次会议中我们不仅列出了技术栈还重点讨论了为什么选它而不是选别的方案。我觉得这部分很关键因为一个项目真正的成熟往往体现在它是否有一套清晰的技术取舍逻辑。六、技术选型与对比讨论下面这部分是我根据我们组会讨论整理出来的技术对比分析。1. 前端为什么选择 Flutter而不是原生 Android 或 uni-app我们前端最后选择的是Flutter Dart。PPT 中给出的理由是Flutter 能通过响应式布局实现更好的多端适配同时支持围绕“拍照识别与菜品翻译”这个核心场景构建一个操作简单、响应快速的移动应用。为什么不优先考虑原生 Android原生 Android 的优势是生态成熟、系统能力调用更直接但它的问题也很明显开发周期更长UI 构建和跨平台复用能力较弱如果后面想扩展到 iOS需要额外付出较大成本对于我们这种课程项目来说原生 Android 更适合做深度平台优化但不适合快速产出一个可展示的跨端原型。为什么不优先考虑 uni-app 或小程序方案uni-app 和小程序开发门槛相对低适合快速做业务页面但我们这个项目的重点并不只是表单和展示而是图像上传与交互AI 识别结果展示多页面状态联动后续可能接入语音播放和更复杂的动态交互在这种场景下Flutter 的界面一致性、性能表现和组件控制能力会更强更适合做“像 App 一样”的产品原型。所以我们为什么选 Flutter因为它在我们当前阶段实现了一个比较好的平衡开发效率高界面效果统一跨平台能力强适合做移动端原型展示这对于课程项目来说是非常现实的选择。2. 后端为什么选择 FastAPI而不是 Django 或 Spring BootPPT 中写得很清楚后端主要负责三件事请求处理AI 服务调度数据存储管理因此我们最终选择了FastAPI来搭建后端。因为它天然适合做轻量级、高性能的接口服务尤其适合图像上传、模型调用和结果返回这种场景。为什么不优先选 DjangoDjango 的优势在于“全家桶”能力很强适合管理后台、权限系统和传统 Web 业务开发。但我们当前项目的重点不是复杂后台而是提供 API对接 AI 推理流程快速迭代接口与前端 App 通信在这种情况下Django 反而显得有些“重”会带来额外的框架负担。为什么不选 Spring BootSpring Boot 确实在企业级开发中非常成熟适合大型系统和复杂业务架构。但对于我们这个阶段的项目来说Java 后端的开发与配置成本更高整体节奏不如 Python 技术栈轻便。而且我们的 AI 能力本身就主要依赖 Python 生态选择 FastAPI 可以让后端接口层和模型调用层保持同一语言体系开发和联调都会更顺畅。FastAPI 的优势在哪里异步支持好适合图片上传和模型调用与 Python AI 生态天然契合接口开发速度快文档自动生成便于团队协作联调所以对我们这种“AI 驱动型应用”来说FastAPI 比传统 Web 框架更适合。3. 菜单识别为什么要用 Qwen-VL而不是传统 OCR 翻译 API这一点是我们技术讨论中最核心的部分之一。PPT 中已经指出现有通用翻译工具大多停留在逐词翻译层面难以识别菜品类别、料理背景和适合人群。也就是说这个任务的难点从来都不只是“识别文字”而是“理解菜单”。因此我们最终选择了Qwen-VL作为菜单图片识别与语义理解模型。为什么不只用 OCR传统 OCR 的确可以解决“图片转文字”的问题但它有几个明显限制只能识别字面内容难以理解菜品语义无法很好处理跨文化菜名的隐含含义对复杂菜单的结构化能力有限很难直接完成“菜品解释 风险提取 推荐支撑”换句话说OCR 可以回答“上面写了什么”却很难回答“这到底是什么菜、适不适合我吃”。为什么不做“OCR 翻译 API”的组合这是一个可行方案但问题在于它依然是一个线性的浅层处理过程识别文本 → 直译输出这种方式对于普通文档翻译可能够用但菜单是一个高度依赖语境的场景。很多菜名如果只做字面翻译结果往往并不自然也无法给出用户真正关心的信息例如菜大概是什么口味是什么做法有哪些风险食材适合什么偏好的用户而大模型的价值就在这里它不只是“翻译”而是做语义解释、信息补全和结构化理解。所以 Qwen-VL 的意义是什么它让系统从“看见菜单文字”升级为“理解菜单内容”这也是我们项目和普通翻译工具的本质差异。4. 为什么加入 ChatTTS而不是只返回文字结果PPT 中写到项目不仅关注菜单理解还要提供点单表达能力因此我们计划使用ChatTTS来做点单表达语音生成。为什么不只展示文字如果系统只返回菜名翻译和说明用户确实能“看懂”但仍然可能不敢开口点。尤其在国外餐厅场景中很多用户即使看懂了也会卡在不知道菜名怎么念不知道如何组织表达不确定说出口对方能不能听懂为什么语音能力是必要的因为它补上了从“理解”到“表达”的最后一环。加入 ChatTTS 后系统未来不仅可以告诉用户“这是什么”还可以进一步提供标准发音参考场景化点餐语句播报更自然的跨语言点单辅助这使得我们的产品不再是单向信息工具而是更接近真实交易场景中的“助手”。5. 数据存储为什么选 MySQL而不是 MongoDB在数据层上我们选择了MySQL主要用来保存用户查询记录菜品识别结果收藏信息偏好设置相关元数据PPT 中也明确提到采用关系型数据库有利于提高查询效率并支持后续功能扩展。为什么不优先选 MongoDBMongoDB 对非结构化数据支持更灵活适合 schema 经常变化的场景。但我们这个项目虽然涉及 AI 结果真正需要长期保存和查询的数据其实还是比较结构化的比如用户 ID菜品名称风险标签偏好项收藏记录历史记录这些数据天然适合关系型建模。MySQL 的优势是什么结构清晰适合课程项目实现查询能力稳定与用户、收藏、偏好等关系模型匹配度高后续做统计分析也方便所以站在当前阶段来看MySQL 是一个更稳妥、更容易落地的选择。6. 为什么引入 LangGraph而不是直接一次调用大模型这是我们技术方案里最能体现“系统化思维”的地方。PPT 中提到我们不会把项目设计成单次模型调用而是采用LangGraph来构建一个多步骤的 AI 智能体工作流流程包括图片识别 → 信息提取 → 结果校验 → 语义理解 → 风险提示 → 推荐生成 → 点单表达同时它支持状态传递、校验—回退—重试以及后续扩展更多节点。:contentReference[oaicite:18]{index18}为什么不直接问一次大模型如果只是 Demo当然可以直接把图片和问题丢给模型让它返回一个答案。但这样做有几个问题结果稳定性差错误不容易定位很难做节点级校验不方便扩展推荐、历史、偏好等后续能力LangGraph 的价值在哪里它让整个系统变成一个“有流程、有状态、可扩展”的智能体系统而不是一个一次性问答程序。这意味着某个节点出错时可以回退或重试识别结果可以单独校验推荐和风险提示可以作为独立模块插入后续可以接入知识库、用户偏好、历史记录等能力对于一个希望真正“产品化”的 AI 应用来说这种设计明显比单次模型调用更合理。七、第一次会议的阶段性成果这次会议最直接的成果就是我们完成了开题汇报 PPT 的主要内容整理。PPT 中已经较完整地展示了项目背景与痛点分析项目定位与价值核心功能设计页面功能规划技术架构方案预期成果这说明我们第一次会议并不是停留在“想法交流”阶段而是真正形成了可以用于展示、汇报和继续推进的阶段性成果。