家庭做饭场景长期存在一个痛点：“今天吃什么”的决策成本高，买菜容易漏买、重复买。而市面上多数美食类产品只解决“看菜谱”这一环，菜谱、一周菜单、采购清单、营养数据彼此割裂，用户看完菜谱仍要手动记菜名、列清单。恰饭清单的立项就是为解决这一问题：面向家庭自炊、合租做饭人群，把“按周/按天排菜 → 自动汇总去重生成采购清单 → 买回来勾选、按步骤烹饪 → 记录实际食用与热量营养”串成一条闭环，让家庭饮食计划从凭记忆变成可执行的清单，降低决策与采购成本，同时为需要控热量、控营养（含忌口、过敏）的人群提供数据支撑。饮食健康与生鲜到家是近年持续增长的民生赛道，行业里普遍缺少把“菜谱—计划—采购—营养”打通的工具，这正是本项目的切入点。
项目由微信小程序、运营管理后台两部分组成，并通过 MCP 协议对外输出 AI 能力。
小程序端：微信一键登录与资料补全、菜谱浏览与关键词/语义搜索、菜谱详情与收藏、周计划按天按餐次选菜、采购清单整周/单日自动汇总生成与购买勾选、热量目标与已吃记录、营养分析与趋势、家庭群组的创建/邀请码加入/成员角色与选菜购物车实时同步（WebSocket）、我的菜谱与食材等自建数据管理、AI 饮食助手。
运营后台：菜谱/食材/营养/单位等基础数据维护与步骤拖拽排序、菜谱 AI 生成（异步任务 + AI 封面）、业务数据看板、小红书链接一键转菜谱草稿，以及支持真流式输出（SSE）与工具调用过程展示的 AI 助手，可直接问答“平台有多少菜谱”“哪些菜谱缺向量”。
核心闭环为：浏览或智能发现菜谱 → 加入某天某餐 → 生成采购清单 → 采购勾选 → 标记实际食用 → 查看热量与营养分析。
我负责项目中 AI 能力从 0 到 1 的架构设计与落地，并承担后端业务接口与运营后台开发。功能上，
我把 AI 从“只能回答”做到“能改数据”：用户用自然语言即可完成“查菜谱 → 选菜加入某天某餐 → 换餐 / 清空计划 → 生成采购清单”的闭环，落地 10 个 Agent 工具（用户侧 7 + 运营侧 3），回复中直接给出可确认的操作卡片。
技术栈：Java 17、Spring Boot 3.5、MyBatis、MySQL 8、Redis 8（RediSearch）、Spring AI + Spring AI Alibaba、MCP Java SDK、SSE、uni-app、Vue 3 + Element Plus，配套 Python + FastAPI + ONNX 本地向量服务。
亮点与难点：
① 多供应商运行时路由——不用官方 Starter（模型编译期写死），改用工厂 + 协议抽象族按数据库配置在运行时构造实例，后台改配置即可切换 5 类模型协议；
② 向量检索不引入专用向量库，用 Redis 8 内置 RediSearch（HNSW/512 维/COSINE）实现菜谱语义检索与标签过滤，并解决中文分词失效（改字符切分 + TAG 索引）；
③ 对话式写库的安全——AI 输出是不可信输入、删计划不可逆，于是设计“登记-确认”二次确认：写工具只登记不落库，令牌单次消费、绑定登记人、执行参数只取服务端已解析值，用户点确认才写库；
④ 运营侧 text-to-SQL 四层防护：主体限制 → 白名单校验（默认拒绝、禁 select *）→ 只读连接 + 超时 + 限行 → 全链路审计；
⑤ 修复框架级疑难：模型失败被包装成正常回复、限流计数随会话持久化致会话瘫痪；
⑥ 对话页接口单次拉取 604KB → 0.3KB。
评论