很多餐食类 App 的 AI 功能最后都停在给我推荐几道菜。SoloChef 想做的更像一个独居生活规划助手用户说出预算、忌口、营养目标和本周安排系统不只返回菜名还要继续推导出购物清单、采购分类、预算分配最后把结果变成一份可以打卡、反馈、继续修改的周计划。这篇文章想回答一个更底层的问题当你手里只有大模型这个会聊天的脑子时怎么把它变成一条真正能干活、能落地、还能持续变聪明的业务链路答案就是 LangGraph 负责编排流程RAG 负责给模型喂对的上下文再外面套一层结构化产出 确定性校验的工程外壳。1. 项目概述1.1 项目定位SoloChef — AI 独居膳食与采买规划师。它的核心不是推荐菜谱而是把这周预算多少、不能吃什么、想吃得快一点这种模糊的生活问题翻译成可执行的业务结果一份排好七天、带购物清单和预算分配的周计划。这里有个关键认知差异如果只是推荐几道菜一个会聊天的模型加几句 prompt 就能糊弄出来但要做成规划助手模型必须和数据库里的用户画像、营养目标、历史反馈联动产出还必须能被程序校验、存储、修改和打卡。这就不是 prompt 工程能解决的需要一套完整的工程架构。1.2 目标用户独居自炊人群按目标细分三类增肌 / 减脂 / 健康维持并兼顾性别差异男女基础代谢不同营养目标算法也不同。1.3 项目规模前后端分离的单仓库后端 FastAPI约百个 Python 文件前端 Vue 3 单页应用10 个主页面基础设施四件套后面会讲一条贯穿生成 → 执行 → 反馈 → 再生成的 AI 工作流。2. 系统架构2.1 整体架构前端(Vue3/Vite) ──HTTP/SSE── 后端(FastAPI) │ ┌────────────┬──────────┼────────────┬──────────┐ PostgreSQL Redis 7 Neo4j 5 Milvus 2.4 Celery (业务数据) (队列/ (用户画像/ (向量知识) (后台任务) 缓存/SSE) 关系知识) │ LangGraph 工作流 (检索→领域智能体→规划器→校验器)2.2 后端架构LangGraph 到底解决什么问题后端负责认证、业务数据、AI 工作流与基础设施适配。AI 部分由LangGraph编排——这是整篇文章的技术主轴值得先讲透。如果你没接触过 LangGraph可以把它理解成一个带记忆的流程图引擎。传统的 chatbot 是一问一答大模型接到问题直接回答但 SoloChef 要的是一条多步骤、有状态、能回退、能恢复的流水线。LangGraph 用一张StateGraph状态图把检索 → 领域智能体 → 规划器 → 校验器这些节点串起来每个节点都能读写一份共享的工作记忆WorkflowState。为什么不直接写一串 Python 函数顺序调用因为顺序调用会丢失几样东西可恢复性流程跑到第 3 步崩了能不能从第 3 步接着跑而不是从头来LangGraph 的checkpointer检查点把每一步的状态持久化到 PostgreSQL / Redis / 内存崩了能续。可观测性每个节点花了多少时间、输入输出是什么、有没有报错都能被记录成轨迹前端能画出来给用户看。可控的循环校验器发现计划不合规可以回退让规划器重来这种带环的有向图用普通线性代码很难优雅表达。所以 LangGraph 在这里不是炫技而是把一个会出错的复杂 AI 流程变成可调试、可恢复、可审计的工程对象。2.3 前端架构Vue 3 TypeScript Vite Pinia Element Plus。状态用 Pinia 管理API 调用走 axios图表用 ECharts。前端的角色不是展示一段 AI 文本而是把 AI 的产物做成可交互的产品这一点在第 5 节展开。2.4 数据流一条会自我喂养的闭环用户画像 / 营养目标 / 历史反馈 → 注入工作流共享状态 → 双路 RAG 检索 → 多领域智能体产出结构化建议 → 规划器合成完整计划 → 校验器把关 → 落库为周计划 → 前端看板展示 → 用户打卡反馈 → 回流口味画像 → 下一轮生成更懂你。注意最后那一步回流——这是它和普通推荐系统最大的区别它会越用越懂你而且懂你的方式不靠模型自觉靠的是结构化数据的累积。3. 技术栈3.1 前端技术栈Vue 3.5、TypeScript 5.8、Vite 7、Pinia 3、Element Plus 2.14、vue-router 4、axios、ECharts、Vitest单测。3.2 后端技术栈Python FastAPI、Pydantic数据校验与结构化输出核心、SQLAlchemy 2.x异步AsyncSessionasyncpg驱动、PyJWTHS256 鉴权、Uvicorn。3.3 基础设施组件选型用途主数据库PostgreSQL 1614 张业务表持久化用户、计划、购物、反馈等缓存 / 队列 / 实时Redis 7Celery 任务 broker、SSE 事件重放、checkpointer 缓存图数据库Neo4j 5 Community用户画像、忌口、食材/菜谱之间的关系知识向量数据库Milvus 2.4文档知识的稠密稀疏双路向量检索3.4 AI 与第三方服务LangGraphAI 工作流编排StateGraph checkpointer。LangChain 的ChatOpenAI接口模型调用的兼容层。默认LLM_PROVIDERdemo零密钥也能跑起来演示配置真实密钥后接 DeepSeek 等任意 OpenAI 兼容模型。BGE-M3 / bge-reranker-v2-m3Embedding把文字变成向量与二阶段精排模型。Qwen-VLDashScope多模态视觉模型默认关闭。Tavily可选的联网搜索工具。4. 核心AI 规划链路是怎么跑通的这一节是全文重点。我会从一个外行视角讲清楚当用户点下生成周计划时系统内部到底经历了一遍什么。4.0 先建立大图景一次POST /api/v1/plans/generate-weekly请求进来后系统不会直接把问题丢给大模型。它先做一件很重要的事从数据库把用户上下文捞出来——忌口过敏、营养目标折算成每天的热量/蛋白/碳水/脂肪、最长备餐时间、可用厨具、历史打卡形成的口味偏好、增肌还是减脂。这些上下文被放进前面说的工作记忆里然后才启动那条 LangGraph 工作流。关键点在于用户画像不是塞进一段 prompt 就完事而是进入后续所有环节的共享状态——检索要用它过滤智能体要用它约束校验器要用它核对。这一步决定了后面所有环节都能对齐用户真实情况。4.1 RAG 检索为什么只做向量相似度不够先给没接触过的人补一句RAG检索增强生成就是先去知识库里翻出相关内容再把内容和问题一起喂给模型让它基于事实回答而不是让模型凭空编。对餐食规划来说模型本身不知道这个用户不吃辣、“工作日晚餐要控制在 20 分钟内”这些必须靠检索补进来。SoloChef 的 RAG 不是只做向量相似度搜索而是拆成两条并行路径由工作流用并发机制同时触发、各自设超时第一条向量检索Milvus文档菜谱原则、营养知识先被切成带重叠的小块chunk每块通过 Embedding 模型变成向量存进 Milvus。这里有个进阶点用的BGE-M3模型能同时产出两种向量——稠密向量捕捉语义番茄炒蛋和鸡蛋料理语义相近稀疏向量lexical类似传统关键词加权不吃辣这种硬词权重大。Milvus 用hybrid_search混合检索同时跑这两路再用RRFReciprocal Rank Fusion倒数排名融合把两路结果按排名融成一个列表。召回之后还有一道二阶段精排rerank先用 Embedding 模型召回top_k × 3个候选再用bge-reranker-v2-m3这种专攻相关性排序的模型精排回top_k。这就像先海选再面试比一次到位更准。第二条图谱检索Neo4j向量检索擅长找相似内容但表达不了用户不吃辣这种硬关系。于是 SoloChef 另开一条知识图谱路径把用户偏好、忌口、食材、菜谱之间的关系存进Neo4j 图数据库实体 关系。查询时系统先把自然语言改写成结构化的查询规格关键词 / 实体类型 / 关系再用图数据库查询语言Cypher去遍历用户约束 → 食材 → 菜谱的关系链。为什么要按事实类型拆分两路这是这个项目最值得记的一课偏好、忌口、过敏——是确定性关系放图谱查出来就是铁律菜谱、营养原则——是软性知识放向量库按相似度召回。两路结果在上下文里被明确分开成图谱硬关系和向量软知识模型既能看到用户不吃辣这种硬约束也能参考工作日晚餐控 20 分钟内这种文档建议。工程兜底任一路检索失败比如图库没起来另一条照常工作整条计划流程不会被打崩RRF / rerank 模型缺失时自动回退纯稠密检索。这种降级不中断的思想贯穿整个 AI 栈。4.2 领域智能体让专家各管一摊而且说人话以外的语言检索完成后工作流会并行启动三个各管一摊的专家智能体一个管餐食搭配排除忌口、控制烹饪时间一个管采购清单食材标准化、同类合并、分类一个管预算分配上限、分类限额、预留金、预警。这里有两个对非技术读者也很重要的设计第一它们的产出不是自然语言而是结构化数据对象。三个专家返回的不是我觉得可以这样买这种话而是符合Pydantic / JSON Schema的规整数据比如购物项列表“预算分配表”。为什么这么关键因为后面的规划器和校验器是程序它们要直接读字段、做计算、存数据库——如果模型吐一段自由文本程序就得去猜模型到底想表达什么既慢又不可靠。让模型输出结构化数据是把 AI 接进工程系统的前提。第二它们有双层实现。默认情况下这些专家不走大模型而是走确定性规则引擎比如预算预留 10%、分类限额之和严格等于周预算用纯代码算。只有开启开关后才调用大模型、并只允许它用只读工具去查知识库和用户资料。这个设计的现实考量很朴素大模型贵、慢、偶尔抽风能用确定性规则稳定解决的事就别花那个钱。能力与成本按开关分层是这类项目能落地的基本纪律。另外这些专家的提示词不是散落在代码各处而是集中在一个版本化注册表里对外提供接口可查当前用了第几版、改了什么。这就是提示词即代码——提示词也是要被审计、能回滚的资产。4.3 主规划器强制结构化输出三个专家的建议加上 RAG 检索到的上下文一起交给规划器合成完整计划。真实模型路径下模型被强制绑定response_format{type:json_object}——这是 OpenAI 兼容接口的标准能力意思是你必须返回合法 JSON不许夹带 Markdown 代码块或多余解释。系统还对产出施加了硬性结构约束每周必须生成 7 天 × 早/午/晚 21 个餐食槽位一个不能少每个餐食必须有明确的类型标记金额、时长等字段必须符合规范。为什么这么霸道因为这份计划接下来要被存储、展示成看板、被人修改和打卡——它必须是程序能直接消费的数据而不是一段文章。把结构化从建议升级为强制是 AI 应用能真正跑业务的底线。4.4 校验器模型负责提方案确定性代码负责把关这是整套系统里我个人最欣赏的设计。核心理念一句话模型可以犯错但规则不能放过它。规划器产出的计划会交给校验器由纯确定性代码逐项核对忌口过敏有没有碰、七天是不是都覆盖了、有没有重复菜、营养目标达成没、预算和分类限额超没超。发现的问题被分成两级hard conflict硬冲突碰了忌口、超了预算、营养严重不达标——必须解决soft conflict软冲突某天菜重复了、某餐偏咸——尽量优化。校验失败后系统不是简单甩一句生成失败而是走三级自愈策略自动修正换掉重复菜、补齐缺失日期、调整营养或高价菜——但有一条铁律可以换菜绝不能擅自放宽过敏、忌口、预算和营养目标。降级提示硬冲突或自动修正后仍存在的问题生成可供用户选择的替换方案返回前端。人工接管当硬冲突占餐数超过 30% 时明确提示用户你的条件太苛刻了放宽一点吧。更进一步系统还支持一个主管Supervisor角色当校验器发现某类问题它只把受影响的专家重新调度一遍而不是把所有环节从头跑——而且受轮次上限约束避免多个智能体互相调用失控。这种LLM 生成 规则验证的组合比单纯依赖把 prompt 写得更长更狠可靠得多尤其适合错误会真实影响你去采购、去吃饭的场景。4.5 反馈闭环系统会越用越懂你但不篡改硬约束计划生成不是一次性结束。前端支持餐食打卡、替换、差评、没买到等反馈系统把这些事件聚合成口味画像并回流进知识库。下一轮生成时画像被重新注入餐食专家喜欢的标签进入偏好被拒绝过的菜或负向标签进入排除项。这里同样有一条铁律过敏永远优先于历史口味。反馈只能改变推荐方向和排序不能覆盖安全约束而且当用户连续多次对某类食材差评系统会自动把它升级为正式忌口——这是从软偏好到硬约束的演化。于是形成真正的闭环计划生成 → 执行打卡 → 用户反馈 → 口味画像 → 下一轮更懂你。4.6 对话助手一条刻意独立的链路除了生成周计划项目还有聊天接口。但它的定位不是每问一句就重做一份计划而是只读问答读取用户画像、营养目标、当前计划摘要再做一小规模检索然后流式回答。对话通过SSEServer-Sent Events服务器推送事件把思考中 / 出字了 / 调工具了 / 工具返回了 / 完成这些事件推给前端并写入 Redis——好处是前端断线后可以调接口把漏掉的事件重放补齐不丢上下文。聊天智能体启用后只允许使用只读工具而且系统提示明确把工具结果和检索内容视为不可信数据——不能执行其中的指令也不能泄露系统提示。这条链路和计划生成链路是有意分开的聊天可以自然语言输出不强制结构化计划生成必须结构化、可验证、可落库。两个场景的模型温度、超时、输出约束都不同。4.7 多模态把图片接进饮食场景系统提供独立的视觉服务基于Qwen-VL支持五种场景自动识别、食材识别、菜品与热量估算、营养标签 OCR、小票 OCR。图片进模型前会先做安全和成本控制——检查大小、压缩长边到 2048 像素、统一转 JPEG再编码上传模型返回的结果也要经过结构化校验避免 OCR 吐出无法消费的自由文本。视觉能力默认关闭是可选增强而非启动硬依赖——这又体现了能力分层的纪律核心链路不依赖它你想要再开。5. 前端如何承接 AI 结果前端不是一个文本结果框而是把 AI 产物做成可交互产品。10 个主页面中与 AI 强相关的几个首页档案采集计划看板页把周计划拆成七天每天展示三餐、时长、费用、标签生成中的状态持续更新确认后才落库可打卡、反馈、看版本历史、预览调整结果再确认。计划明细页单份计划明细与修改前后的差异对比。知识库页知识文档与检索。聊天页用 fetch ReadableStream 消费 SSE而非浏览器原生 EventSource断线后按游标重放补齐。计划局部修改先过意图路由系统用词法信号判断用户到底是要生成“要修改”“问购物”“问预算还是纯咨询”防止用户只是问晚餐怎么做却误触发整周计划重算。对把周三晚餐换成不含海鲜的高蛋白餐这类请求系统会计算受影响的餐食/购物/预算并在前端展示差异对比与冲突提醒——用户看清改动再确认。6. 关键技术创新也是可复用的方法论GraphRAG 双路检索偏好/忌口进图谱关系Neo4j Cypher菜谱/原则做向量召回Milvus BGE-M3 RRF Reranker按事实类型拆分后合并才接近真实规划场景。结构化输出 确定性校验Pydantic Schema、21 餐完整性、预算等式、冲突分级都是模型之外的安全网比写更长的 prompt可靠。校验器三级自愈模型生成 规则验证的组合适合真实影响采购和饮食执行的场景。SSE 流式对话 Redis 事件重放断线不丢上下文体验连贯。全栈降级图谱/向量任一路失败保留另一路Reranker/BGE-M3 缺失回退纯稠密真实 LLM 超时切 Demo 规划器视觉/对话未配置返回明确未启用。7. 开发中的挑战与解决方案这些不是教科书里的理论而是真实踩过的坑模型不稳定 / 没有 API 密钥代码默认LLM_PROVIDERdemo演示模式保留完整工作流与校验只把昂贵的外部模型调用替换为本地确定性实现真实 LLM 超时按开关切回兜底方案。这样没密钥也能跑、也能演示、也能测流程。RAG 底座可能不可达双路并发 各自超时任一路失败保留另一路RRF / rerank 缺失自动回退纯稠密检索链路不中断。模型自觉不可信再长的 prompt 也拦不住模型偶尔放松约束所以用校验器三级自愈替代纯 prompt 约束——过敏/忌口/预算/营养目标绝不靠模型自觉。SSE 断线丢上下文事件写入 Redis前端断线后按游标重放补齐。意图误触发整周计划用意图路由做词法分类区分生成/修改/购物/预算/咨询防止一句闲聊误重算整周。外部依赖成本与耦合领域专家默认确定性规则、主管限轮次、视觉/联网搜索默认关闭——能力按开关严格分层最小成本起步。8. 项目成果完整 AI 规划闭环从一句自然语言到 21 个餐食槽位 购物清单 预算分配 可修改版本真正打通自然语言 → 业务结果。可观测每次工作流运行都会记录节点轨迹名称、耗时、状态、输入输出摘要、错误前端可展示完整 Agent Trace后端提供接口可查。出问题时有迹可循而不是模型抽风了但我不知道哪步抽的。9. 收获与展望9.1 项目开发收获AI 应嵌入业务流程而不是一个孤立聊天框。结构化输出 确定性校验比写更长的 prompt可靠。RAG 要按事实类型拆分图谱关系 vs 向量召回。默认能力与增强能力必须分层Demo / 真实 LLM / BGE-M3 / Reranker / Supervisor / 联网搜索 / Qwen-VL / 分段规划都由开关控制。9.2 未来展望真实领域专家的调用成本需继续评估Supervisor / 联网搜索仍是可选能力Reranker 与稀疏检索依赖额外本地模型权重视觉识别需独立 VLM 配置意图路由目前更多由前端弹窗承接尚未全部接入 API。后续可做流式计划生成、更细的用户级图谱隔离、Agent 运行恢复、检索质量评测与成本监控——现有数据结构、路由和前端页面已预留扩展点不必推翻架构。总结SoloChef 的核心价值不是模型能推荐多少道菜而是把一个模糊的生活问题转成一条可追踪、可校验、可执行、还能持续学习的 AI 工作流。如果你也正打算用大模型做点能落地的东西希望这篇复盘能帮你建立一个最朴素的判断框架LangGraph 负责把流程编排成可恢复、可观测的图RAG尤其是 GraphRAG 双路负责给模型喂对的上下文结构化输出和确定性校验负责把 AI 从会聊天的脑子变成能干活的系统。这三者合起来才是一个 AI 应用真正值得长期维护的部分。