企业官网建设流程全解析

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封装成脚本，原因是它可以让我在电脑上一行命令就拿到推荐结果，还能顺手发到手机通知里。但如果你是纯小白，建议先用第一种，把下面的提示词复制到豆包网页版里，效果一样不差。第三种是我后来给团队弄的进阶版，放到第4章细说。

3. 实操过程：从提示词到能用，中间改了四版

3.1 第一版提示词：翻车现场

我的第一版提示词特别简单，基本就是：

你是一个点餐助手。请根据我的要求推荐一个午餐。

结果可想而知。它给我推荐了“红烧肉、米饭、例汤”，理由是“荤素搭配”。看起来没毛病，但完全不是我想要的——因为我根本没告诉它任何条件。这就暴露了一个问题：大模型再聪明，也猜不到你嘴里的“随便”到底是什么意思。我不写约束，它就只能输出“最通用答案”，而“最通用答案”往往就是最无聊的答案。

3.2 第二版提示词：把条件结构化成清单

吃了亏之后，我换了个思路——不给自由对话，把输入强行拆成几个字段。就像填表一样：

请根据以下信息推荐午餐： - 人数：[你填] - 忌口/不吃：[你填] - 口味倾向：[你填] - 预算范围：[你填] - 位置范围：[你填] - 今日特殊情况：[你填] 要求： 1. 给出1个主推方案和2个备选方案 2. 每个方案说明推荐理由，理由要与输入条件对应 3. 如果条件互相矛盾，主动指出并给出折中建议

这一版的效果立竿见影。因为字段逼着我必须把“我今天不想吃啥”这种模糊念头，变成“不吃芹菜、不吃生冷”这类具体约束。当约束明确后，AI的推荐质量一下子从“能看”变成了“可用”。这里有个很重要的经验：想让大模型输出靠谱，你给它的结构化信息越多，它发挥得越稳定。不要让它猜你的意思，你要把意思拆给它。

3.3 第三版提示词：加入决策逻辑和输出格式

第二版虽然可用，但结果还是有点“飘”。有时候它推荐的理由一听就是编的，“因为牛肉富含蛋白质，适合运动后食用”，可我压根没运动。于是第三版我做了两个改动：一是要求它给出决策过程，二是把推荐结果改成固定格式。

最终版提示词我直接放出来，这一版我已经稳定用了三周：

你是一位熟悉本地餐饮的午餐顾问，擅长在有限条件下快速给出决策建议。 【今日条件】 - 人数：2人 - 预算：人均25-35元 - 位置：公司步行15分钟内 - 口味限制：不吃辣、不吃生冷 - 忌口：其中一人忌花生 - 今日状态：昨晚吃了火锅，今天想吃清爽点 - 你已知的常去餐厅：张姐拌面、老王黄焖鸡、阿香米线、蔡先生快餐、楼下轻食沙拉 【决策规则】 1. 先从上一步的常去餐厅里筛选，如果全部不满足再用通用知识补充，但要标注“非日常清单” 2. 排除违背口味限制和忌口的选项 3. 综合“今天状态”给出倾向性建议，不要平均主义 4. 如果有多个候选，排序后选第一个作为主推 【输出格式】 主推：餐厅名 / 菜品名 预估价格：xx元 为什么是它：用一句话解释，必须直接关联上面的限制条件 备选1：xx（原因） 备选2：xx（原因） 今日不建议：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_ascii=False, indent=2)} 【决策规则】 1. 先从常去餐厅筛选，全部不满足再用通用知识补充，但标注"非日常清单" 2. 排除违背口味限制和忌口的选项 3. 综合今日状态给出倾向性建议 4. 排序后选第一个作为主推 【输出格式】 主推：餐厅名 / 菜品名 预估价格：xx元 为什么是它：一句话，必须关联限制条件 备选1：xx（原因） 备选2：xx（原因） 今日不建议：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": f"Bearer {API_KEY}", "Content-Type": "application/json" }, json=payload) 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 三周实测数据

说实话，这个采纳率有点超出我的预期。我原以为能有一半就不错了。后来回看那2次完全推翻的case，发现问题不在模型，在我输入的条件。有一天我写“今日状态：一般”，这个描述太模糊了，AI也没办法从“一般”里读出“我想吃点热乎的”。还有一次我忘了填忌口，结果它推荐了带花生的菜品。吃一堑长一智，现在我的脚本里对必填字段做了校验，条件缺失就直接提醒，绝不带着残缺信息去问AI。

4.2 调优过程：哪些信息对结果影响最大

通过反复改输入条件，我大概摸清楚了各个字段对结果质量的影响权重。按影响从高到低排：

1. 忌口和口味限制——这是硬约束，模型对这个最敏感。只要写了“不吃辣”，它在推理时会重点避开所有涉辣菜品。
2. 今日状态——这个字段决定了推荐的风格倾向。比如“开会下午需要清醒”会把选项推向“清淡、高蛋白、不犯困”；“昨晚火锅太油”会偏向“爽口、解腻”。
3. 常去餐厅清单——这算是外挂数据。给了这个列表之后，推荐结果明显更贴近真实生活，而不是给出一个你根本没听过的店名。你相当于在给模型建立一个“本地知识库”。
4. 预算——这个是软条件，影响有，但要让位给前三个。
5. 位置——模型对“步行15分钟”这种空间概念只能估算，不能太较真。

有一个特别值得说的发现：“今日状态”这个字段写得越具体、越场景化，推荐质量越高。相比“今天想吃好的”，“今天下午有两场会，中午想吃个不容易困的”会让AI瞬间明白应该是“低油高蛋白适量碳水”的方向。这个其实就是AI提示词的核心逻辑：你给模型的上下文越接近真实场景，它越能调取对应的常识。

4.3 团队版：从一人用到多人用

用了一周后，部门几个同事看我从“中午吃啥”这个永恒话题里消失了，就问我咋做到的。我顺手把这套提示词丢给他们，让他们自己在豆包网页版里跑。结果反馈很有意思：大家单独用的时候，推荐结果都挺准的，但办公室有一个新问题——每人推荐的不一样，午饭搭子还是凑不到一起。

于是我花了一个下午，弄了一个“团队版”。思路其实很简单：把所有参与人的姓名和条件汇总成一个数组，让AI推荐一个“满足大多数人、可以拼桌吃饭”的方案。比如三人的条件分别是“不吃辣”“预算30以内”“下午有会”，那么提示词里就多了一条规则：先把所有人约束求交集，交集为空时允许部分人妥协，但要明确标注谁妥协了什么。

这个版本在团队里用了两周，几乎是零差评。因为它本质上解决的不只是“吃什么”，而是“几个人能不能吃上同一顿饭”。这里我顺手埋了一个扩展点：如果你有公司周边的完整餐厅列表，完全可以喂给模型，让它做“多人套餐选择”，体验会比我们自己翻外卖评价高效得多。

5. 常见问题与排查技巧：实测踩坑实录

这一章写给想复现但你大概率会遇到问题的人。我在整个搭建和日常使用中，遇到过的几个典型问题都列在这里，直接照方抓药就行。

5.1 提示词不生效，推荐结果答非所问

表现：你明明写了“不吃辣”，它推荐的菜品里还是带辣椒。

排查顺序是这样的：

1. 先检查你的提示词里是否混入了和条件冲突的指令。比如前面写“不吃辣”，后面又写“推荐几个你觉得好吃的”，这时候模型会优先响应后面的开放式指令，导致前面积累的约束被稀释。
2. 检查语气。如果你在提示词末尾加了一句“随便吧”，模型很可能把“随便”当作最高优先级，于是开始放飞。
3. 建议把约束条件放最后、输出要求放次后，或者像我的模板一样，用“决策规则”硬性隔开，告诉模型“先看规则再看普通语句”。

5.2 推荐结果总是一成不变

表现：连续一周都推荐同一家，哪怕你换了好几次“今日状态”。

原因通常在两个地方。一是temperature太低，低于0.2时模型几乎总是选概率最高的那个，也就是你常去餐厅里权重最高的。二是你每次都填了同一个“常去餐厅清单”，但没告诉模型“连续超过3次推荐同一家时要换一家”。

我的解决办法是：在提示词里加一条“排除最近3天已推荐的选项”，然后把temperature调到0.5左右。这样既保持稳定，又保留变数。如果使用网页版而不是API，你可以在对话里补一句“上次推荐过的不再推荐”，效果类似。

5.3 API调用报错，最常见的那种

如果你的脚本偶尔报错，大概率是这三个原因：

我一开始用脚本批量测试多种条件组合时，就碰到过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 帮我的不是“替我选择”，而是“逼我把需求想明白”，这一点是我当初没想到的额外收获。