1. 先说结论为什么“做个选择”这事也能交给AI熟悉我的读者都知道我平时挺愿意折腾工具的但一到中午十一点半整个人就跟被按了暂停键一样。外卖平台刷三遍微信群问一圈“吃啥”最后回一句“随便”再陷入新一轮沉默。这种状态持续了大半年直到我把豆包的 Seed-2.1-pro-0915 这个模型版本拉来做了一个叫「今天吃啥」的小工具才算真正把这个纠结症给治了。这事本质上不是“做个网页推荐菜名”那么简单。我的目标是让AI在每天中午之前根据我给的当天条件——比如“昨晚吃太油”“下午要开会”“预算20块”“不想吃米饭”——综合给我一个推荐结果并且说清楚为什么推荐它。就这么一个需求我从提示词、API调用到落地成日常使用来回折腾了差不多三周。现在我可以负责任地说中午点菜这件事花在决策上的时间从之前的十几分钟降到了现在的十几秒。如果你也有“打开外卖App半小时最后闭眼随便点”的毛病或者你是那种一到饭点就被同事集体“点菜”的人这篇内容应该对你有用。我会把整套东西拆开讲清楚从设计思路、提示词怎么写、怎么接到自己常用的工作流到实测里踩过的坑和调优记录。有没有编程基础都能跟上核心逻辑懂了用网页版直接套提示词也行。2. 整体设计把“随便”变成“有条件的选择”很多人一听“用AI点菜”第一反应是“这不就是随机推荐吗掷骰子也能干”。实际上真不是。随机数只能给结果给不了理由更没法理解你“今天不想吃辣”“昨天刚吃过火锅”这种极其日常的约束条件。我要做的不是“随机”而是“在条件约束下做决策”。2.1 点餐纠结的真正成本先把问题量化一下。假设你中午有30分钟休息时间来回路上和吃饭大概用25分钟那么真正留给你“想吃什么”的时间只有5分钟。但这5分钟里你要面对的是几十个品类、上千家店铺、满减规则、配送时长、评价好坏还有你自己根本说不清的身体状态。信息一多大脑的决策系统就开始罢工最后要么选个吃腻了的要么干脆不吃了。我在设计这个工具时第一个核心思路就是帮大脑减负把“从海量商品里选一个”这个开放问题转换成“在少数几个条件里找一个最优解”的闭合问题。比如说“两个人、不吃辣、预算30元左右、离公司步行10分钟内、主食吃面”——这五个条件一摆可选范围瞬间缩小到个位数。AI要做的不是替你创造选项而是帮你从这些选项里挑一个最合适的再告诉你它为什么这么选。2.2 为什么选豆包 Seed-2.1-pro-0915 而不是自己写规则老实说我一开始是想自己写一套规则脚本的搞个菜品类目表配上几个条件分支搓个本地小网页。写到一半就放弃了。原因是规则脚本没法处理模糊信息。比如“想吃点暖和的”——这怎么用if-else表达“暖”可以是热汤面、麻辣烫、粥、小火锅甚至是一碗刚出锅的盖浇饭。规则能覆盖的只有精确条件而人日常说话绝大多数是模糊条件。豆包 Seed-2.1-pro-0915 这个版本的好处是它对中文口语的意图理解明显比我之前用的几个模型版本更稳。你给它一句“今天不想吃太咸的下午还得见客户”它不会把“太咸”理解成字面的“盐放多了”而是能把它转成“口味清淡、无重盐、适合商务场合”的约束条件。另外0915这版在输出结构化内容时格式保持得很好方便我把它接到后续的自动化流程里。选择词这个模型本质上是选“能听懂人话的语义处理器”而不是选“搜索引擎”。2.3 三种落地方式网页版、API、智能体同一个需求可以有不同的用法我也都试过落地方式适合人群优点缺点网页版提示词不写代码零门槛、即开即用需要手动输入、手动复制结果官方API封装脚本有一点编程基础可定制、可接通知推送需要申请密钥、处理调用逻辑智能体/工作流平台想打包分享可加按钮、可多人使用平台绑定、部署成本略高我日常主力用的是第二种API封装成脚本原因是它可以让我在电脑上一行命令就拿到推荐结果还能顺手发到手机通知里。但如果你是纯小白建议先用第一种把下面的提示词复制到豆包网页版里效果一样不差。第三种是我后来给团队弄的进阶版放到第4章细说。3. 实操过程从提示词到能用中间改了四版3.1 第一版提示词翻车现场我的第一版提示词特别简单基本就是你是一个点餐助手。请根据我的要求推荐一个午餐。结果可想而知。它给我推荐了“红烧肉、米饭、例汤”理由是“荤素搭配”。看起来没毛病但完全不是我想要的——因为我根本没告诉它任何条件。这就暴露了一个问题大模型再聪明也猜不到你嘴里的“随便”到底是什么意思。我不写约束它就只能输出“最通用答案”而“最通用答案”往往就是最无聊的答案。3.2 第二版提示词把条件结构化成清单吃了亏之后我换了个思路——不给自由对话把输入强行拆成几个字段。就像填表一样请根据以下信息推荐午餐 - 人数[你填] - 忌口/不吃[你填] - 口味倾向[你填] - 预算范围[你填] - 位置范围[你填] - 今日特殊情况[你填] 要求 1. 给出1个主推方案和2个备选方案 2. 每个方案说明推荐理由理由要与输入条件对应 3. 如果条件互相矛盾主动指出并给出折中建议这一版的效果立竿见影。因为字段逼着我必须把“我今天不想吃啥”这种模糊念头变成“不吃芹菜、不吃生冷”这类具体约束。当约束明确后AI的推荐质量一下子从“能看”变成了“可用”。这里有个很重要的经验想让大模型输出靠谱你给它的结构化信息越多它发挥得越稳定。不要让它猜你的意思你要把意思拆给它。3.3 第三版提示词加入决策逻辑和输出格式第二版虽然可用但结果还是有点“飘”。有时候它推荐的理由一听就是编的“因为牛肉富含蛋白质适合运动后食用”可我压根没运动。于是第三版我做了两个改动一是要求它给出决策过程二是把推荐结果改成固定格式。最终版提示词我直接放出来这一版我已经稳定用了三周你是一位熟悉本地餐饮的午餐顾问擅长在有限条件下快速给出决策建议。 【今日条件】 - 人数2人 - 预算人均25-35元 - 位置公司步行15分钟内 - 口味限制不吃辣、不吃生冷 - 忌口其中一人忌花生 - 今日状态昨晚吃了火锅今天想吃清爽点 - 你已知的常去餐厅张姐拌面、老王黄焖鸡、阿香米线、蔡先生快餐、楼下轻食沙拉 【决策规则】 1. 先从上一步的常去餐厅里筛选如果全部不满足再用通用知识补充但要标注“非日常清单” 2. 排除违背口味限制和忌口的选项 3. 综合“今天状态”给出倾向性建议不要平均主义 4. 如果有多个候选排序后选第一个作为主推 【输出格式】 主推餐厅名 / 菜品名 预估价格xx元 为什么是它用一句话解释必须直接关联上面的限制条件 备选1xx原因 备选2xx原因 今日不建议xx原因注意看这个提示词的设计逻辑第一步是规划候选池第二步是硬性排除第三步是结合当天状态做软性排序最后用固定格式输出。这样的好处是结果可控、可解释。它不再是“算命先生”而是“有限条件下的逻辑推演器”。3.4 第四步封装成脚本接到日常通知提示词稳定后我做了第二件重要的事把整个流程接到脚本里。因为我实在不想每天中午打开网页、粘贴条件、复制结果。我用豆包的API写了一个Python小脚本放到自己电脑上每天早上十点半自动跑一次然后把推荐结果推到微信告警群里。下面是一个简化版的调用示例如果你有API权限可以直接参考import requests import json # 配置区 API_URL https://your-doubao-api-endpoint/v1/chat/completions API_KEY your-api-key MODEL Seed-2.1-pro-0915 # 每日条件可以结合日历、天气、会议安排动态生成 conditions { 人数: 2, 预算: 人均25-35元, 位置: 公司步行15分钟内, 口味限制: 不吃辣、不吃生冷, 忌口: 忌花生, 今日状态: 昨晚吃了火锅今天想吃清爽点, 常去餐厅: [张姐拌面, 老王黄焖鸡, 阿香米线, 蔡先生快餐, 楼下轻食沙拉] } prompt f 你是一位熟悉本地餐饮的午餐顾问擅长在有限条件下快速给出决策建议。 【今日条件】 {json.dumps(conditions, ensure_asciiFalse, indent2)} 【决策规则】 1. 先从常去餐厅筛选全部不满足再用通用知识补充但标注非日常清单 2. 排除违背口味限制和忌口的选项 3. 综合今日状态给出倾向性建议 4. 排序后选第一个作为主推 【输出格式】 主推餐厅名 / 菜品名 预估价格xx元 为什么是它一句话必须关联限制条件 备选1xx原因 备选2xx原因 今日不建议xx原因 payload { model: MODEL, messages: [ {role: system, content: 你是懂餐饮、懂本地生活、说话干脆的顾问。}, {role: user, content: prompt} ], temperature: 0.4, top_p: 0.7 } r requests.post(API_URL, headers{ Authorization: fBearer {API_KEY}, Content-Type: application/json }, jsonpayload) if r.status_code 200: result r.json()[choices][0][message][content] print(result) # 这里可以再接推送逻辑比如发到企业微信/钉钉/Telegram else: print(f调用失败: {r.status_code} {r.text})这里有几个参数值得解释。temperature控制输出的随机性我设在0.4既不会每次都一样又不至于天马行空。如果调成0.1基本每次都会选同一个常去餐厅调到1.0以上你可能会在周一收到“法式鹅肝配松露”这种离谱答案。固定提示词的同时把温度压到合理区间才是“既能稳定推荐又不至于无聊”的关键。我把脚本放在服务器上配合cron定时任务周一到周五每天10:30执行一次。消息发到群里的效果基本就是“今天主推张姐拌面人均22元因为清爽不辣、避开花生、步行8分钟到店。备选1阿香米线备选2楼下轻食沙拉。”4. 实测记录与调优过程什么输入最影响结果这个东西到底是不是我在自嗨我用数据说话。从我把脚本跑起来到现在一共21个工作日统计了一下推荐情况和我的采纳率。4.1 三周实测数据指标数据实际执行次数19次有两天忘记配条件主推方案被采纳14次备选方案被采纳3次完全推翻自己点2次推荐理由让人满意的次数16次说实话这个采纳率有点超出我的预期。我原以为能有一半就不错了。后来回看那2次完全推翻的case发现问题不在模型在我输入的条件。有一天我写“今日状态一般”这个描述太模糊了AI也没办法从“一般”里读出“我想吃点热乎的”。还有一次我忘了填忌口结果它推荐了带花生的菜品。吃一堑长一智现在我的脚本里对必填字段做了校验条件缺失就直接提醒绝不带着残缺信息去问AI。4.2 调优过程哪些信息对结果影响最大通过反复改输入条件我大概摸清楚了各个字段对结果质量的影响权重。按影响从高到低排忌口和口味限制——这是硬约束模型对这个最敏感。只要写了“不吃辣”它在推理时会重点避开所有涉辣菜品。今日状态——这个字段决定了推荐的风格倾向。比如“开会下午需要清醒”会把选项推向“清淡、高蛋白、不犯困”“昨晚火锅太油”会偏向“爽口、解腻”。常去餐厅清单——这算是外挂数据。给了这个列表之后推荐结果明显更贴近真实生活而不是给出一个你根本没听过的店名。你相当于在给模型建立一个“本地知识库”。预算——这个是软条件影响有但要让位给前三个。位置——模型对“步行15分钟”这种空间概念只能估算不能太较真。有一个特别值得说的发现“今日状态”这个字段写得越具体、越场景化推荐质量越高。相比“今天想吃好的”“今天下午有两场会中午想吃个不容易困的”会让AI瞬间明白应该是“低油高蛋白适量碳水”的方向。这个其实就是AI提示词的核心逻辑你给模型的上下文越接近真实场景它越能调取对应的常识。4.3 团队版从一人用到多人用用了一周后部门几个同事看我从“中午吃啥”这个永恒话题里消失了就问我咋做到的。我顺手把这套提示词丢给他们让他们自己在豆包网页版里跑。结果反馈很有意思大家单独用的时候推荐结果都挺准的但办公室有一个新问题——每人推荐的不一样午饭搭子还是凑不到一起。于是我花了一个下午弄了一个“团队版”。思路其实很简单把所有参与人的姓名和条件汇总成一个数组让AI推荐一个“满足大多数人、可以拼桌吃饭”的方案。比如三人的条件分别是“不吃辣”“预算30以内”“下午有会”那么提示词里就多了一条规则先把所有人约束求交集交集为空时允许部分人妥协但要明确标注谁妥协了什么。这个版本在团队里用了两周几乎是零差评。因为它本质上解决的不只是“吃什么”而是“几个人能不能吃上同一顿饭”。这里我顺手埋了一个扩展点如果你有公司周边的完整餐厅列表完全可以喂给模型让它做“多人套餐选择”体验会比我们自己翻外卖评价高效得多。5. 常见问题与排查技巧实测踩坑实录这一章写给想复现但你大概率会遇到问题的人。我在整个搭建和日常使用中遇到过的几个典型问题都列在这里直接照方抓药就行。5.1 提示词不生效推荐结果答非所问表现你明明写了“不吃辣”它推荐的菜品里还是带辣椒。排查顺序是这样的先检查你的提示词里是否混入了和条件冲突的指令。比如前面写“不吃辣”后面又写“推荐几个你觉得好吃的”这时候模型会优先响应后面的开放式指令导致前面积累的约束被稀释。检查语气。如果你在提示词末尾加了一句“随便吧”模型很可能把“随便”当作最高优先级于是开始放飞。建议把约束条件放最后、输出要求放次后或者像我的模板一样用“决策规则”硬性隔开告诉模型“先看规则再看普通语句”。5.2 推荐结果总是一成不变表现连续一周都推荐同一家哪怕你换了好几次“今日状态”。原因通常在两个地方。一是temperature太低低于0.2时模型几乎总是选概率最高的那个也就是你常去餐厅里权重最高的。二是你每次都填了同一个“常去餐厅清单”但没告诉模型“连续超过3次推荐同一家时要换一家”。我的解决办法是在提示词里加一条“排除最近3天已推荐的选项”然后把temperature调到0.5左右。这样既保持稳定又保留变数。如果使用网页版而不是API你可以在对话里补一句“上次推荐过的不再推荐”效果类似。5.3 API调用报错最常见的那种如果你的脚本偶尔报错大概率是这三个原因报错特征原因解决办法401/403API密钥配置错误或权限不足检查密钥是否带空格、是否过有效期429触发频率限制或额度耗尽降低请求频率或者改用异步处理跑批量任务时做好休眠请求超时提示词太长或输出内容太多简化输出格式限制字数比如在提示词里写“总体控制在150字以内”我一开始用脚本批量测试多种条件组合时就碰到过429。后来改成在每次请求之间加time.sleep(1)就解决了。这种问题看起来低级但真能卡你半天。5.4 推荐理由太“能编”表现推荐理由写得头头是道但跟你的实际条件没有关系。比如“适合运动后食用”“富含膳食纤维”一看就是在背营养学课本。这是提示词约束不够严导致的。我加了“推荐理由必须逐一对应输入的限制条件”之后基本就杜绝了。举个例子它会说“因为张姐拌面步行8分钟可达且不辣、不含花生符合你的忌口要求”这种具体的话不再是泛泛的营养学知识。5.5 补充一个“人话”技巧让AI先复述条件如果推荐结果依然飘还有一个终极大招在决策规则里加一条“先把我给的条件复述一遍再开始推荐”。别看这招笨实测极有用。因为它强迫模型走一遍注意力机制把关键信息重新聚焦相当于你考试时先把题干抄一遍再答题正确率自然就上来了。6. 后续扩展思路这套逻辑还能用到哪“今天吃啥”只是我拿来试手的一个场景但底层这套“约束条件下的决策推荐”逻辑完全可以平移到其他日常选择里。我目前已经在试的方向有两个简单聊聊你可以怎么参照。6.1 接入“本地门店清单”做大模型本地知识库你可以把自己常去的那十几家店整理成结构化数据包括店名、距离、人均、招牌菜、口味标签、避坑事项。不要给模型一个纯文字列表而是给出JSON格式的数据比如[ { name: 张姐拌面, distance_km: 0.6, avg_price: 22, tags: [面食, 清淡, 有空调], special: 花生酱拌面, avoid: 高峰期需要排队15分钟 }, { name: 阿香米线, distance_km: 0.9, avg_price: 26, tags: [米线, 热食, 出餐快], special: 番茄米线, avoid: 座位少建议错峰 } ]你会发现喂给模型这种“半结构化”的数据它能在推荐理由里直接引用可信度立刻不同。这和用豆包搭建知识库文件的思路是一样的——不要给它一大堆网页抓下来的杂文先清洗成字段分明的数据。6.2 结合日历和会议安排更进一步把日历信息合并进“今日状态”这个字段。比如通过每日日程同步检测到下午14点有客户会议自动在条件里追加“下午有会避免重口味和易犯困食物”。如果你用的是API这些都可以写成定时任务自动读取。配合推送到群里的动作整个体验就是还没到饭点通知已经告诉你今天吃什么好了。6.3 关于“自动下单”我的看法有人问过我能不能让AI直接帮我把外卖下单了我的答案是技术上可以但我强烈不建议至少现阶段不要。一个简单的道理如果你的口味输入少了一个“忌口”AI推荐的菜里正好有你过敏的食材而你又把下单流程做得太顺滑那问题就不是“点错菜”而是“吃出问题”了。决策建议可以交给AI最终确认一定要留给自己或人工环节。我把这套工具定性为“决策辅助”不是“决策替代”。最后再分享一个小技巧如果你完全不想写脚本只想用豆包网页版体验这个思路我有一个更省事的用法把第3.3节那套提示词存成一个文本文件然后每次要决策时直接复制进对话。别嫌麻烦实际用下来填几个字段的时间不会超过30秒比你在外卖App上翻十几分钟快多了。我个人现在反而是越来越依赖“给AI设定条件”这个过程本身。因为以前我纠结“吃什么”本质上是不知道自己想要什么现在被迫给AI写条件反而强制我花30秒想清楚自己的真实需求忌口是什么、预算多少、今天想吃什么风格的。想清楚这些之后选择就自然出现了。豆包 Seed-2.1-pro-0915 帮我的不是“替我选择”而是“逼我把需求想明白”这一点是我当初没想到的额外收获。
AI帮你决定今天吃啥：提示词设计与API实践全解析
1. 先说结论为什么“做个选择”这事也能交给AI熟悉我的读者都知道我平时挺愿意折腾工具的但一到中午十一点半整个人就跟被按了暂停键一样。外卖平台刷三遍微信群问一圈“吃啥”最后回一句“随便”再陷入新一轮沉默。这种状态持续了大半年直到我把豆包的 Seed-2.1-pro-0915 这个模型版本拉来做了一个叫「今天吃啥」的小工具才算真正把这个纠结症给治了。这事本质上不是“做个网页推荐菜名”那么简单。我的目标是让AI在每天中午之前根据我给的当天条件——比如“昨晚吃太油”“下午要开会”“预算20块”“不想吃米饭”——综合给我一个推荐结果并且说清楚为什么推荐它。就这么一个需求我从提示词、API调用到落地成日常使用来回折腾了差不多三周。现在我可以负责任地说中午点菜这件事花在决策上的时间从之前的十几分钟降到了现在的十几秒。如果你也有“打开外卖App半小时最后闭眼随便点”的毛病或者你是那种一到饭点就被同事集体“点菜”的人这篇内容应该对你有用。我会把整套东西拆开讲清楚从设计思路、提示词怎么写、怎么接到自己常用的工作流到实测里踩过的坑和调优记录。有没有编程基础都能跟上核心逻辑懂了用网页版直接套提示词也行。2. 整体设计把“随便”变成“有条件的选择”很多人一听“用AI点菜”第一反应是“这不就是随机推荐吗掷骰子也能干”。实际上真不是。随机数只能给结果给不了理由更没法理解你“今天不想吃辣”“昨天刚吃过火锅”这种极其日常的约束条件。我要做的不是“随机”而是“在条件约束下做决策”。2.1 点餐纠结的真正成本先把问题量化一下。假设你中午有30分钟休息时间来回路上和吃饭大概用25分钟那么真正留给你“想吃什么”的时间只有5分钟。但这5分钟里你要面对的是几十个品类、上千家店铺、满减规则、配送时长、评价好坏还有你自己根本说不清的身体状态。信息一多大脑的决策系统就开始罢工最后要么选个吃腻了的要么干脆不吃了。我在设计这个工具时第一个核心思路就是帮大脑减负把“从海量商品里选一个”这个开放问题转换成“在少数几个条件里找一个最优解”的闭合问题。比如说“两个人、不吃辣、预算30元左右、离公司步行10分钟内、主食吃面”——这五个条件一摆可选范围瞬间缩小到个位数。AI要做的不是替你创造选项而是帮你从这些选项里挑一个最合适的再告诉你它为什么这么选。2.2 为什么选豆包 Seed-2.1-pro-0915 而不是自己写规则老实说我一开始是想自己写一套规则脚本的搞个菜品类目表配上几个条件分支搓个本地小网页。写到一半就放弃了。原因是规则脚本没法处理模糊信息。比如“想吃点暖和的”——这怎么用if-else表达“暖”可以是热汤面、麻辣烫、粥、小火锅甚至是一碗刚出锅的盖浇饭。规则能覆盖的只有精确条件而人日常说话绝大多数是模糊条件。豆包 Seed-2.1-pro-0915 这个版本的好处是它对中文口语的意图理解明显比我之前用的几个模型版本更稳。你给它一句“今天不想吃太咸的下午还得见客户”它不会把“太咸”理解成字面的“盐放多了”而是能把它转成“口味清淡、无重盐、适合商务场合”的约束条件。另外0915这版在输出结构化内容时格式保持得很好方便我把它接到后续的自动化流程里。选择词这个模型本质上是选“能听懂人话的语义处理器”而不是选“搜索引擎”。2.3 三种落地方式网页版、API、智能体同一个需求可以有不同的用法我也都试过落地方式适合人群优点缺点网页版提示词不写代码零门槛、即开即用需要手动输入、手动复制结果官方API封装脚本有一点编程基础可定制、可接通知推送需要申请密钥、处理调用逻辑智能体/工作流平台想打包分享可加按钮、可多人使用平台绑定、部署成本略高我日常主力用的是第二种API封装成脚本原因是它可以让我在电脑上一行命令就拿到推荐结果还能顺手发到手机通知里。但如果你是纯小白建议先用第一种把下面的提示词复制到豆包网页版里效果一样不差。第三种是我后来给团队弄的进阶版放到第4章细说。3. 实操过程从提示词到能用中间改了四版3.1 第一版提示词翻车现场我的第一版提示词特别简单基本就是你是一个点餐助手。请根据我的要求推荐一个午餐。结果可想而知。它给我推荐了“红烧肉、米饭、例汤”理由是“荤素搭配”。看起来没毛病但完全不是我想要的——因为我根本没告诉它任何条件。这就暴露了一个问题大模型再聪明也猜不到你嘴里的“随便”到底是什么意思。我不写约束它就只能输出“最通用答案”而“最通用答案”往往就是最无聊的答案。3.2 第二版提示词把条件结构化成清单吃了亏之后我换了个思路——不给自由对话把输入强行拆成几个字段。就像填表一样请根据以下信息推荐午餐 - 人数[你填] - 忌口/不吃[你填] - 口味倾向[你填] - 预算范围[你填] - 位置范围[你填] - 今日特殊情况[你填] 要求 1. 给出1个主推方案和2个备选方案 2. 每个方案说明推荐理由理由要与输入条件对应 3. 如果条件互相矛盾主动指出并给出折中建议这一版的效果立竿见影。因为字段逼着我必须把“我今天不想吃啥”这种模糊念头变成“不吃芹菜、不吃生冷”这类具体约束。当约束明确后AI的推荐质量一下子从“能看”变成了“可用”。这里有个很重要的经验想让大模型输出靠谱你给它的结构化信息越多它发挥得越稳定。不要让它猜你的意思你要把意思拆给它。3.3 第三版提示词加入决策逻辑和输出格式第二版虽然可用但结果还是有点“飘”。有时候它推荐的理由一听就是编的“因为牛肉富含蛋白质适合运动后食用”可我压根没运动。于是第三版我做了两个改动一是要求它给出决策过程二是把推荐结果改成固定格式。最终版提示词我直接放出来这一版我已经稳定用了三周你是一位熟悉本地餐饮的午餐顾问擅长在有限条件下快速给出决策建议。 【今日条件】 - 人数2人 - 预算人均25-35元 - 位置公司步行15分钟内 - 口味限制不吃辣、不吃生冷 - 忌口其中一人忌花生 - 今日状态昨晚吃了火锅今天想吃清爽点 - 你已知的常去餐厅张姐拌面、老王黄焖鸡、阿香米线、蔡先生快餐、楼下轻食沙拉 【决策规则】 1. 先从上一步的常去餐厅里筛选如果全部不满足再用通用知识补充但要标注“非日常清单” 2. 排除违背口味限制和忌口的选项 3. 综合“今天状态”给出倾向性建议不要平均主义 4. 如果有多个候选排序后选第一个作为主推 【输出格式】 主推餐厅名 / 菜品名 预估价格xx元 为什么是它用一句话解释必须直接关联上面的限制条件 备选1xx原因 备选2xx原因 今日不建议xx原因注意看这个提示词的设计逻辑第一步是规划候选池第二步是硬性排除第三步是结合当天状态做软性排序最后用固定格式输出。这样的好处是结果可控、可解释。它不再是“算命先生”而是“有限条件下的逻辑推演器”。3.4 第四步封装成脚本接到日常通知提示词稳定后我做了第二件重要的事把整个流程接到脚本里。因为我实在不想每天中午打开网页、粘贴条件、复制结果。我用豆包的API写了一个Python小脚本放到自己电脑上每天早上十点半自动跑一次然后把推荐结果推到微信告警群里。下面是一个简化版的调用示例如果你有API权限可以直接参考import requests import json # 配置区 API_URL https://your-doubao-api-endpoint/v1/chat/completions API_KEY your-api-key MODEL Seed-2.1-pro-0915 # 每日条件可以结合日历、天气、会议安排动态生成 conditions { 人数: 2, 预算: 人均25-35元, 位置: 公司步行15分钟内, 口味限制: 不吃辣、不吃生冷, 忌口: 忌花生, 今日状态: 昨晚吃了火锅今天想吃清爽点, 常去餐厅: [张姐拌面, 老王黄焖鸡, 阿香米线, 蔡先生快餐, 楼下轻食沙拉] } prompt f 你是一位熟悉本地餐饮的午餐顾问擅长在有限条件下快速给出决策建议。 【今日条件】 {json.dumps(conditions, ensure_asciiFalse, indent2)} 【决策规则】 1. 先从常去餐厅筛选全部不满足再用通用知识补充但标注非日常清单 2. 排除违背口味限制和忌口的选项 3. 综合今日状态给出倾向性建议 4. 排序后选第一个作为主推 【输出格式】 主推餐厅名 / 菜品名 预估价格xx元 为什么是它一句话必须关联限制条件 备选1xx原因 备选2xx原因 今日不建议xx原因 payload { model: MODEL, messages: [ {role: system, content: 你是懂餐饮、懂本地生活、说话干脆的顾问。}, {role: user, content: prompt} ], temperature: 0.4, top_p: 0.7 } r requests.post(API_URL, headers{ Authorization: fBearer {API_KEY}, Content-Type: application/json }, jsonpayload) if r.status_code 200: result r.json()[choices][0][message][content] print(result) # 这里可以再接推送逻辑比如发到企业微信/钉钉/Telegram else: print(f调用失败: {r.status_code} {r.text})这里有几个参数值得解释。temperature控制输出的随机性我设在0.4既不会每次都一样又不至于天马行空。如果调成0.1基本每次都会选同一个常去餐厅调到1.0以上你可能会在周一收到“法式鹅肝配松露”这种离谱答案。固定提示词的同时把温度压到合理区间才是“既能稳定推荐又不至于无聊”的关键。我把脚本放在服务器上配合cron定时任务周一到周五每天10:30执行一次。消息发到群里的效果基本就是“今天主推张姐拌面人均22元因为清爽不辣、避开花生、步行8分钟到店。备选1阿香米线备选2楼下轻食沙拉。”4. 实测记录与调优过程什么输入最影响结果这个东西到底是不是我在自嗨我用数据说话。从我把脚本跑起来到现在一共21个工作日统计了一下推荐情况和我的采纳率。4.1 三周实测数据指标数据实际执行次数19次有两天忘记配条件主推方案被采纳14次备选方案被采纳3次完全推翻自己点2次推荐理由让人满意的次数16次说实话这个采纳率有点超出我的预期。我原以为能有一半就不错了。后来回看那2次完全推翻的case发现问题不在模型在我输入的条件。有一天我写“今日状态一般”这个描述太模糊了AI也没办法从“一般”里读出“我想吃点热乎的”。还有一次我忘了填忌口结果它推荐了带花生的菜品。吃一堑长一智现在我的脚本里对必填字段做了校验条件缺失就直接提醒绝不带着残缺信息去问AI。4.2 调优过程哪些信息对结果影响最大通过反复改输入条件我大概摸清楚了各个字段对结果质量的影响权重。按影响从高到低排忌口和口味限制——这是硬约束模型对这个最敏感。只要写了“不吃辣”它在推理时会重点避开所有涉辣菜品。今日状态——这个字段决定了推荐的风格倾向。比如“开会下午需要清醒”会把选项推向“清淡、高蛋白、不犯困”“昨晚火锅太油”会偏向“爽口、解腻”。常去餐厅清单——这算是外挂数据。给了这个列表之后推荐结果明显更贴近真实生活而不是给出一个你根本没听过的店名。你相当于在给模型建立一个“本地知识库”。预算——这个是软条件影响有但要让位给前三个。位置——模型对“步行15分钟”这种空间概念只能估算不能太较真。有一个特别值得说的发现“今日状态”这个字段写得越具体、越场景化推荐质量越高。相比“今天想吃好的”“今天下午有两场会中午想吃个不容易困的”会让AI瞬间明白应该是“低油高蛋白适量碳水”的方向。这个其实就是AI提示词的核心逻辑你给模型的上下文越接近真实场景它越能调取对应的常识。4.3 团队版从一人用到多人用用了一周后部门几个同事看我从“中午吃啥”这个永恒话题里消失了就问我咋做到的。我顺手把这套提示词丢给他们让他们自己在豆包网页版里跑。结果反馈很有意思大家单独用的时候推荐结果都挺准的但办公室有一个新问题——每人推荐的不一样午饭搭子还是凑不到一起。于是我花了一个下午弄了一个“团队版”。思路其实很简单把所有参与人的姓名和条件汇总成一个数组让AI推荐一个“满足大多数人、可以拼桌吃饭”的方案。比如三人的条件分别是“不吃辣”“预算30以内”“下午有会”那么提示词里就多了一条规则先把所有人约束求交集交集为空时允许部分人妥协但要明确标注谁妥协了什么。这个版本在团队里用了两周几乎是零差评。因为它本质上解决的不只是“吃什么”而是“几个人能不能吃上同一顿饭”。这里我顺手埋了一个扩展点如果你有公司周边的完整餐厅列表完全可以喂给模型让它做“多人套餐选择”体验会比我们自己翻外卖评价高效得多。5. 常见问题与排查技巧实测踩坑实录这一章写给想复现但你大概率会遇到问题的人。我在整个搭建和日常使用中遇到过的几个典型问题都列在这里直接照方抓药就行。5.1 提示词不生效推荐结果答非所问表现你明明写了“不吃辣”它推荐的菜品里还是带辣椒。排查顺序是这样的先检查你的提示词里是否混入了和条件冲突的指令。比如前面写“不吃辣”后面又写“推荐几个你觉得好吃的”这时候模型会优先响应后面的开放式指令导致前面积累的约束被稀释。检查语气。如果你在提示词末尾加了一句“随便吧”模型很可能把“随便”当作最高优先级于是开始放飞。建议把约束条件放最后、输出要求放次后或者像我的模板一样用“决策规则”硬性隔开告诉模型“先看规则再看普通语句”。5.2 推荐结果总是一成不变表现连续一周都推荐同一家哪怕你换了好几次“今日状态”。原因通常在两个地方。一是temperature太低低于0.2时模型几乎总是选概率最高的那个也就是你常去餐厅里权重最高的。二是你每次都填了同一个“常去餐厅清单”但没告诉模型“连续超过3次推荐同一家时要换一家”。我的解决办法是在提示词里加一条“排除最近3天已推荐的选项”然后把temperature调到0.5左右。这样既保持稳定又保留变数。如果使用网页版而不是API你可以在对话里补一句“上次推荐过的不再推荐”效果类似。5.3 API调用报错最常见的那种如果你的脚本偶尔报错大概率是这三个原因报错特征原因解决办法401/403API密钥配置错误或权限不足检查密钥是否带空格、是否过有效期429触发频率限制或额度耗尽降低请求频率或者改用异步处理跑批量任务时做好休眠请求超时提示词太长或输出内容太多简化输出格式限制字数比如在提示词里写“总体控制在150字以内”我一开始用脚本批量测试多种条件组合时就碰到过429。后来改成在每次请求之间加time.sleep(1)就解决了。这种问题看起来低级但真能卡你半天。5.4 推荐理由太“能编”表现推荐理由写得头头是道但跟你的实际条件没有关系。比如“适合运动后食用”“富含膳食纤维”一看就是在背营养学课本。这是提示词约束不够严导致的。我加了“推荐理由必须逐一对应输入的限制条件”之后基本就杜绝了。举个例子它会说“因为张姐拌面步行8分钟可达且不辣、不含花生符合你的忌口要求”这种具体的话不再是泛泛的营养学知识。5.5 补充一个“人话”技巧让AI先复述条件如果推荐结果依然飘还有一个终极大招在决策规则里加一条“先把我给的条件复述一遍再开始推荐”。别看这招笨实测极有用。因为它强迫模型走一遍注意力机制把关键信息重新聚焦相当于你考试时先把题干抄一遍再答题正确率自然就上来了。6. 后续扩展思路这套逻辑还能用到哪“今天吃啥”只是我拿来试手的一个场景但底层这套“约束条件下的决策推荐”逻辑完全可以平移到其他日常选择里。我目前已经在试的方向有两个简单聊聊你可以怎么参照。6.1 接入“本地门店清单”做大模型本地知识库你可以把自己常去的那十几家店整理成结构化数据包括店名、距离、人均、招牌菜、口味标签、避坑事项。不要给模型一个纯文字列表而是给出JSON格式的数据比如[ { name: 张姐拌面, distance_km: 0.6, avg_price: 22, tags: [面食, 清淡, 有空调], special: 花生酱拌面, avoid: 高峰期需要排队15分钟 }, { name: 阿香米线, distance_km: 0.9, avg_price: 26, tags: [米线, 热食, 出餐快], special: 番茄米线, avoid: 座位少建议错峰 } ]你会发现喂给模型这种“半结构化”的数据它能在推荐理由里直接引用可信度立刻不同。这和用豆包搭建知识库文件的思路是一样的——不要给它一大堆网页抓下来的杂文先清洗成字段分明的数据。6.2 结合日历和会议安排更进一步把日历信息合并进“今日状态”这个字段。比如通过每日日程同步检测到下午14点有客户会议自动在条件里追加“下午有会避免重口味和易犯困食物”。如果你用的是API这些都可以写成定时任务自动读取。配合推送到群里的动作整个体验就是还没到饭点通知已经告诉你今天吃什么好了。6.3 关于“自动下单”我的看法有人问过我能不能让AI直接帮我把外卖下单了我的答案是技术上可以但我强烈不建议至少现阶段不要。一个简单的道理如果你的口味输入少了一个“忌口”AI推荐的菜里正好有你过敏的食材而你又把下单流程做得太顺滑那问题就不是“点错菜”而是“吃出问题”了。决策建议可以交给AI最终确认一定要留给自己或人工环节。我把这套工具定性为“决策辅助”不是“决策替代”。最后再分享一个小技巧如果你完全不想写脚本只想用豆包网页版体验这个思路我有一个更省事的用法把第3.3节那套提示词存成一个文本文件然后每次要决策时直接复制进对话。别嫌麻烦实际用下来填几个字段的时间不会超过30秒比你在外卖App上翻十几分钟快多了。我个人现在反而是越来越依赖“给AI设定条件”这个过程本身。因为以前我纠结“吃什么”本质上是不知道自己想要什么现在被迫给AI写条件反而强制我花30秒想清楚自己的真实需求忌口是什么、预算多少、今天想吃什么风格的。想清楚这些之后选择就自然出现了。豆包 Seed-2.1-pro-0915 帮我的不是“替我选择”而是“逼我把需求想明白”这一点是我当初没想到的额外收获。
查询的入门经典)
