设计一套稳定好用的AI美食推荐提示词，本质上是在构建一个可控的对话协议。无论是调用OpenAI接口还是使用本地模型，仅靠一句“给我推荐个菜”远远不够。我们需要把用户模糊的意图转化成结构化的指令，让模型理解角色、任务、约束条件和输出格式。接下来会分别从菜谱生成、食材替换和烹饪技巧三个高频场景出发，给出可直接复用的对话模板，并说明背后的设计逻辑。
菜谱生成的提示词模板设计
让AI生成菜谱时，最容易遇到的问题就是输出过于自由，菜名、用量、步骤经常脱离实际。解决思路是为模型设定一个明确的角色和输出骨架。通常可以要求模型扮演一位专业厨师，并且在提示词中固定JSON或Markdown格式，避免模型随意发挥。例如下面这个模板：
你是一名资深中餐厨师，擅长根据现有食材和口味偏好设计家常菜谱。请严格按照以下格式给出回答，不要添加任何额外说明：
【菜名】
（菜的名称）
【所需食材】
- 食材1：用量
- 食材2：用量
【烹饪步骤】
1. 步骤1
2. 步骤2
...
现在，用户家里有{用户食材}，想要一道{口味偏好}的菜，请生成菜谱。
模板中用花括号标记了占位变量，实际应用时替换为用户输入。格式约束的好处是，哪怕模型偶尔发挥失常，输出仍然具有可解析性，方便后续做前端展示或二次处理。如果要生成西餐或烘焙食谱，只需调整角色描述和格式中的字段即可，比如增加“烘焙温度”“烤制时间”等。
另一个提升稳定性的技巧是使用示例引导。在提示词最后附上一段符合格式的完整菜谱示例，模型会强烈倾向于模仿该示例的结构和语气。比如：
示例输出： 【菜名】 番茄炒蛋 【所需食材】 - 番茄：2个 - 鸡蛋：3个 - 小葱：1根 - 盐：适量 - 糖：少许 - 食用油：2勺 【烹饪步骤】 1. 番茄切块，鸡蛋打散加少许盐搅匀。 2. 锅中倒油烧热，倒入蛋液炒至凝固盛出。 3. 锅中再加少许油，放入番茄块炒出汁，加糖和盐调味。 4. 倒回鸡蛋翻炒均匀，撒上葱花即可。
示例不仅能规范格式，还能隐含菜谱的风格信息，比如描述是偏详细叙事还是简洁步骤。测试表明，一个严谨的示例往往比大段文字描述更有效。此外，在系统提示中可以补充：“如果用户提供的食材不足或搭配不合理，请礼貌地建议补充必要的辅料”，这样模型就能具备一定的纠错能力。
智能食材替换的对话策略
食材替换是美食推荐中非常实用的功能，但它的难点在于，模型需要理解食材的烹饪特性而不是简单地做同义词映射。例如“牛奶”可以用“豆浆”替代吗？得看具体场景：做甜品时大多可以，但做奶油浓汤时豆浆的脂肪含量低，效果会差。因此提示词必须引导模型基于烹饪原理给出替换建议。
一种有效的做法是要求模型在回答时显式输出替换原因和可能的影响。例如模板如下：
你是一名精通分子料理与营养学的厨师。当用户询问“{原食材}可以用什么替代”时，请按以下结构回答：
1. 推荐首选替代食材及其用量调整（如有）。
2. 简述替代原理（例如风味相似、质地接近、过敏原规避等）。
3. 说明替代后菜品质感或口味的可能变化。
如果没有任何合适的替代食材，请诚实告知并建议修改整道菜的方案。
用户正在制作{菜名}，想替换其中的{原食材}。
这个模板把“食材替换”这个开放问题拆成了三个固定回答点，既控制了输出结构，又强迫模型进行推理。在实际测试中，模型会开始比较食材的含水量、蛋白质结构、酸碱度等，给出的建议也更专业。如果想进一步缩小范围，可以加上约束：“请优先推荐常见家用食材”，这样就不会出现“牦牛奶酪”等冷门答案。
对于有饮食禁忌的用户，替换提示词可以和用户画像结合。比如在系统提示里加入：“用户为素食者，所有替换建议不得包含肉、禽、鱼、虾及其制品”。还可以用少量样本学习的方式，给出几个正确的替换范例，模型就能快速理解素食替换的边界。例如：“鸡蛋 → 亚麻籽粉+水（烘焙用）”、“吉利丁 → 琼脂”。这种示例既教会模型替换关系，也教会了它输出说明的粒度。
烹饪技巧问答的提示词优化
烹饪技巧类问题往往是“为什么我炒的肉总是老？”“怎么让青菜保持翠绿？”这种经验型问题，它们没有标准答案，但模型容易给出教科书式的废话。要让回答真正有用，提示词需要引导模型从原理和操作细节两个层面同时作答。
一个高价值的模板会要求模型扮演厨房导师，输出分为“原因分析”和“实操纠正”两部分：
你是一位有20年灶台经验的厨师长，擅长用通俗语言解释烹饪科学。当用户提出一个烹饪失败问题，请按以下方式回答：
【问题诊断】用一两句话指出最可能的核心原因。
【原理简释】用生活化比喻解释背后的物理或化学原理。
【具体改进】给出3条以内、可立刻执行的操作建议，每条不超过30字，并使用要点列表。
如果问题可能存在安全隐患（如油温过高起火），请先输出安全提醒。
用户的问题：{用户问题}
这个模板的价值在于“生活化比喻”和“可执行建议”。例如解释“勾芡原理”时，模型可能会说“就像给食材穿上一层薄薄的毛衣，锁住水分”，这比直接说“淀粉糊化”更容易让普通用户接受。而操作建议严格控制条数和字数，避免了长篇大论，方便用户在灶台边快速扫一眼。
另一个容易被忽视的优化点是温度参数。在实际API调用中，将temperature设定在0.3-0.5之间比较合适。高温会导致烹饪建议中出现虚构的步骤（比如“在油锅里加一勺小苏打”），而0温度又会使回答过于死板。经过对比实验，0.4的温度既能保证技巧描述具有一定创造性，又不会偏离实际烹饪常识。另外，如果用户的问题涉及到精确数值（如油温几成热），可以在提示词里要求模型使用量化描述，比如“油温约160℃（六成热），木筷插入冒密集小泡”。
综合来看，三个场景的模板背后共享同一种设计思路：显式角色+结构化输出+领域约束。只要掌握了这些原则，就能快速扩展到烘焙、饮品调制甚至餐桌布置等更多美食推荐微场景中。建议开发者将模板做成配置文件，根据用户意图动态组装system和user消息，这样一套代码就能覆盖绝大多数AI美食交互需求。