先谈几个实际场景。不少用户常困惑：能否让AI根据“我最近在控糖，冰箱里有鸡胸肉、西兰花和鸡蛋”这类日常描述，直接给出能落地的菜谱，而不是只回复一句“建议低糖饮食”这种毫无执行力的空话？正是这个差异——究竟是泛泛推荐，还是精准落地——直接决定了你构建的Dify工作流是否真正好用。

要让工作流实现这一目标，关键在于：Dify必须准确理解用户的口味倾向、饮食限制与现有食材，而不是简单将用户输入原样抛给大模型，指望它自行“猜测”出结果。接下来，我们逐步将这个能力集成进去。

配置口味与健康偏好识别节点

在Dify工作区新建应用，点击“添加节点”，选择【参数提取器】。然后在提示词框粘贴一段控制力极强的指令：

你是一个严格的饮食意图解析器。请从用户输入中精确提取：①明确提到的口味偏好（如“不要辣”“喜欢酸甜”“清淡”）；②健康目标或限制（如“控糖”“乳糖不耐”“减脂期”“孕妇饮食”）；③过敏源或拒绝食材（如“不吃香菜”“对花生过敏”）。只输出JSON格式，字段为taste_preference、health_constraint、allergy_a void，值为空字符串或具体关键词。禁止解释、补充、猜测。

必须警惕的是：【一定关闭“允许模型自由发挥”开关】。否则这个节点会自行编造不存在的限制，比如把“今天想吃点暖和的”误判为“需高热量”，后续推荐直接跑偏，完全没法用。

接入魔搭MCP“今天吃什么”服务

魔搭这边提供了两种接入方式，看你的使用场景挑。

方法一：直接调用（推荐新手）
在节点库搜索“HTTP请求”，拖入工作流，配置URL为：https://mcpcdn.modelscope.cn/v1/agents/today-eat-what/invoke，请求方式选POST，Body填JSON：
{“ingredients”: “{{上一节点输出.ingredients}}”, “constraints”: “{{参数提取器输出.health_constraint}},{{参数提取器输出.allergy_a void}}”}

方法二：绑定API密钥（适合高频调用）
前往魔搭MCP广场，找到“今天吃什么”服务，点击“获取凭证”，复制API Key。回到Dify，在刚才那个HTTP节点的Headers中添加：
Authorization: Bearer 【你的API Key】

需要留意的是，魔搭服务返回的是结构化菜谱数据——包含名称、步骤、时长、难度，不是纯文本。所以后续节点必须能解析JSON数组，否则接不住、更没法用。

构建三层过滤式推荐逻辑

光拿到菜谱列表还不够，得做精加工。推荐逻辑分三步走。

第一步：剔除硬冲突菜谱
这一步更像了个安检员——把不合胃口的选项筛掉。添加【代码节点】，语言选Python，输入过滤代码：
```python
recipes = input['recipes'] # 假设上游返回字典列表
filtered = [r for r in recipes if not any(ing in r.get('allergens', []) for ing in input.get('allergy_a void', '').split('，'))]
return {'filtered_recipes': filtered}
```
通过遍历所有菜谱里的过敏源字段，跟用户明确拒绝的食材做比对，把硬冲突的直接剔除。

第二步：按健康目标加权排序
剩下那些虽然不冲突，但未必符合你的健康诉求。在代码节点后接一个【LLM节点】，提示词要切换到营养师视角：“你是一名注册营养师。请根据用户健康目标‘{{参数提取器输出.health_constraint}}’，对以下菜谱按适配度0–5分打分，仅输出JSON数组，每个元素含name和score字段。”输入就用上一步生成的 filtered_recipes。

第三步：注入口味偏好润色
到这里，技术上的“可吃”和“健康”都解决了，但缺少一点烟火气。把LLM打分结果再传入一个新LLM节点，这次让角色切换成“米其林三星主厨”，说话带烟火气那种。提示词设定为：“请用口语化中文介绍前三名菜谱，每道强调1个符合用户口味偏好的细节（如‘酸甜口正合你意’‘全程不放辣椒，清爽到底’）。”这一步，才是“懂吃”的关键所在。