AI+餐饮应用落地教程：从点餐问答到后厨排班

知识分享

2026-10-27 19:00

19 阅读

AI+餐饮应用并不一定要买一套昂贵系统，最常见的落地方式是：用门店已有的菜单、价格、营业时间等数据，接一个大模型 API，做成能回答顾客问题、辅助店员查信息的小工具。
本文按零基础也能照做的方式，从服务器准备讲到接口调用、提示词配置和上线验证，适合想先做小范围试点的餐饮门店或建站人员。

先想清楚要解决哪个具体问题

餐饮场景里可做的事情很多，但第一版建议只选一个高频、低风险的场景，例如：

顾客问“有没有不辣的”“几点关门”“能不能外带”，由工具给出统一回答。
店员查某道菜的配料、过敏原、做法说明。
老板把每日流水文字描述丢给模型，生成简单的经营小结。

不建议第一版就做自动下单、自动改价或直接对接收银系统，这类操作涉及资金和库存，出错成本高。
先用“只读问答”跑通链路，再考虑扩展。

需要提前准备的资料包括：结构化菜单（菜名、价格、辣度、是否含某类过敏原）、营业时间、门店地址、常见问题清单。
资料越结构化，回答越稳定。

服务器与运行环境准备

一台 1 核 2G 的普通云服务器就够跑通接口调用，因为计算主要在大模型服务商那边。
以常见的 Linux 系统为例，登录后先确认 Python 版本：

python3 --version

建议使用 Python 3.9 及以上版本。
如果没有 pip，按系统包管理器安装，例如 Ubuntu/Debian：

sudo apt update
sudo apt install -y python3-pip

创建独立目录和虚拟环境，避免污染系统环境：

mkdir -p /opt/ai-canyin && cd /opt/ai-canyin
python3 -m venv venv
source venv/bin/activate
pip install requests

如果使用宝塔面板，也可以在“网站”里新建一个 Python 项目，把运行目录指向 /opt/ai-canyin，虚拟环境路径填 /opt/ai-canyin/venv。
两种方式选一种即可。

密钥不要写进代码。 用环境变量保存：

export AI_API_KEY="你的密钥"

生产环境建议写入服务配置文件或使用面板的环境变量功能，并限制文件权限为 600。

调用大模型接口的最小可用脚本

下面是一个通用思路的示例，接口地址和请求字段要以你所选服务商的文档为准，不同厂商的路径和参数名可能不同：

import os
import requests

API_KEY = os.environ["AI_API_KEY"]
URL = "https://api.example-provider.com/v1/chat/completions"

menu_text = """
招牌牛肉面 28元 微辣
番茄鸡蛋面 22元 不辣
酸辣粉 18元 中辣 含花生
营业时间 10:00-21:30
"""

payload = {
    "model": "你的模型名称",
    "messages": [
        {"role": "system", "content": "你是门店点餐助手，只根据给定菜单回答，不确定就说不知道，不要编造价格。"},
        {"role": "user", "content": f"菜单信息：\n{menu_text}\n\n顾客问题：有不辣的主食吗？"}
    ],
    "temperature": 0.2
}

resp = requests.post(URL, json=payload,
                     headers={"Authorization": f"Bearer {API_KEY}"},
                     timeout=20)
print(resp.status_code)
print(resp.json())

几个要点：

temperature 调低（如 0.1～0.3），让回答更稳定，减少自由发挥。
必须设置 timeout，否则接口卡住会拖死整个服务。
系统提示词里明确“只根据菜单回答、不编造价格”，这是餐饮场景最重要的约束。

先在本机运行，确认能返回正常内容，再考虑接入网页或小程序。

提示词与数据怎么组织更稳

把菜单直接整段塞进去，菜少时没问题；
菜多时容易超长且回答跑偏。
更稳的做法是：

把菜单整理成 JSON 或表格，按菜名检索出相关几条，再交给模型。
在提示词中固定输出格式，例如“先回答能不能，再列菜名和价格”。
对价格、营业时间这类关键信息，回答后由程序再校验一次，避免模型改数字。

一个简单的配置片段示例：

{
  "system_prompt": "你是门店助手，只使用提供的菜单数据回答；价格必须原样输出；无法确认时回答“请咨询店员”。",
  "max_tokens": 300,
  "temperature": 0.2
}

常见报错与避坑

返回 401：密钥错误或没有正确加 Bearer 前缀，检查环境变量是否真的加载。
返回 429：请求频率或额度超限，加退避重试，不要死循环。
返回超时：检查 timeout 设置和服务器出网是否正常，可用 curl -I 接口地址 测试连通性。
回答编造菜品：多为提示词约束不足或菜单数据没传全，先补数据再调提示词。
成本失控：限制单次 max_tokens，对输入长度做截断，并记录每次调用量。

另外，顾客输入属于外部内容，不要让模型把用户输入当成系统指令执行；
对外服务前建议加敏感词过滤和人工兜底入口。

上线前怎么验证效果

准备 20～30 条真实顾客会问的问题，逐条跑一遍，记录回答是否正确、是否编造、响应时间是否可接受。
重点检查价格、营业时间、过敏原三类信息，这三类出错影响最大。

验证通过后，先用店员内部试用一周，再对顾客开放。
上线后保留日志（问题、回答、耗时），方便后续优化提示词和补充菜单数据。

如果只是验证想法，也可以先在本地电脑跑通脚本，确认回答质量后再迁到服务器，能省掉不少环境排查时间。

AI库存预测配置：从数据准备到预测结果验证的完整流程

AI智能点餐配置实操：从零搭建扫码点餐系统