一、背景与建设目标企业食堂通常已经具备订餐、结算和订单管理系统但员工查询个人消费记录、了解热门菜品或分析饮食健康情况时仍需进入多个页面逐项筛选。传统报表能够提供数据却难以理解“我昨天吃了什么”“中午有哪些好吃的”“我这周吃得健康吗”等自然语言问题。基于Dify建设“员工用餐智能助手”可以在不改造原有订单系统核心业务逻辑的前提下将大语言模型、业务接口和数据处理规则编排成对话式应用为员工提供以下能力查询指定时间段内的消费金额、订单及菜品明细查询指定时间段内销量排名前十的热门菜品根据实际用餐记录生成健康用餐提示支持上午、中午、下午、晚上、今天、昨天、前天、本周、上周、本月、上月及自定义时间段等自然语言表达。本场景中的“员工消费”仅指食堂有效订单产生的消费不涉及充值、退款、补贴发放等账户资金流水。二、Dify平台及主要功能Dify是面向大语言模型应用的开源开发平台集成了可视化工作流、模型管理、知识检索、Agent、工具调用和运行监控等能力可用于将大模型快速接入实际业务系统。Dify官方项目1. 可视化流程编排Dify可以通过节点连接的方式构建Chatflow或Workflow。常用节点包括大模型、条件分支、参数提取、HTTP请求、代码执行、模板转换、变量聚合和结果输出等。Dify官方文档索引员工用餐助手适合采用Chatflow因为它不仅需要执行一次查询还要支持上下文连续对话。例如员工先问“我昨天吃了什么”随后继续问“这些吃得健康吗”系统应能够复用上一轮的查询条件和消费记录。2. 多模型接入Dify能够统一管理不同模型服务应用流程与具体模型相对解耦。本项目可以使用企业已经部署的qwen3.6-27b-test完成业务意图识别、时间语义理解以及健康提示生成。后续更换模型时通常只需调整模型节点配置和提示词不必重写整个应用。3. 外部业务系统集成HTTP请求节点可以调用企业内部订单查询接口代码节点可以完成时间校验、JSON解析、数组过滤、金额汇总和格式转换。Dify也支持工具插件用于封装更复杂或需要重复使用的系统能力。HTTP请求等节点说明这种方式可以形成清晰的职责边界订单系统负责提供真实、完整、权限受控的数据SQL和接口负责基础查询及数据库侧聚合Dify负责理解问题、编排调用、整理数据和生成自然语言答案大模型不直接连接数据库也不自行编造业务数据。4. 发布与运行监控Dify应用可发布为对话页面也可通过API、嵌入式页面等方式接入企业门户、移动办公平台或食堂应用。平台同时提供运行历史和日志可检查节点输入输出、执行耗时和异常信息便于定位时间解析错误、接口超时或提示词偏差。应用发布与监控能力三、员工用餐智能助手技术方案整体流程可设计为“用户提问 → 大模型识别意图与时间 → 生产规则校验 → 场景分流 → 调用业务接口 → 数据整理 → 生成商务化答案”。1. 意图与时间识别大模型首先将用户问题转换为结构化参数例如{intent:DETAIL,startTime:2026-08-22 00:00:00,endTime:2026-08-22 23:59:59}意图可划分为DETAIL消费金额及订单明细HOT热门菜品HEALTH健康用餐提示UNSUPPORTED非支持场景。如果用户未指定时间默认查询当天允许查询的最早时间限制为当前日期向前3个月。大模型负责理解自然语言代码节点负责校验日期格式、起止顺序、时区和最大查询范围避免仅依赖模型判断导致“昨天的开始时间晚于当前时间”等边界错误。2. 数据接口设计生产环境建议封装两个业务接口。消费明细接口POST /api/canteen/consumption-details主要参数包括customerId、startTime和endTime。接口返回订单records每条订单记录中嵌套菜品明细query_1_child_1Records。数据以订单日志表和订单明细日志表为主例如t_canteen_order_extend_log订单扩展日志t_canteen_order_item_extend_log订单明细扩展日志菜品名称等主数据使用非Log主数据表。不需要关联t_customer员工身份由登录系统鉴权后将customerId注入接口参数禁止直接采用大模型生成的员工编号。菜品展示优先使用orderProductName缺失时可使用masterProductName。消费明细SQL只负责查询有效数据包含必要的is_delete条件并按消费时间倒序排列。Dify负责汇总消费金额、计算有效订单数以及截取最近20笔记录。热门菜品接口POST /api/canteen/hot-dishes热门菜品统计由一条SQL直接完成基于t_canteen_order_item_extend_log汇总销量关联必要的菜品主数据返回销量前十、当前销售价格等信息。排名、分组和TOP10均在数据库侧完成不再交由Dify二次统计以确保结果准确并降低大模型上下文消耗。四、实际使用案例案例一查询个人消费员工提问“我昨天吃了什么”系统识别为DETAIL生成昨天的起止时间调用消费明细接口。Dify遍历订单和嵌套明细汇总消费金额并按时间倒序返回最近20笔昨日累计消费38.50元共2笔有效订单。12:16一号食堂番茄牛腩×1、时蔬×122.50元08:03早餐档口鸡蛋×1、豆浆×116.00元回答必须来自接口中的订单和菜品字段不能把“5号窗口”等档口信息误识别为菜品名称。案例二查询热门菜品员工提问“中午有哪些好吃的”系统识别为HOT将“中午”转换为企业配置的午餐时间段调用热门菜品接口返回销量前十及当前价格。回答可表述为今日午餐时段销量较高的菜品包括红烧排骨销量86份当前价格18元番茄炒蛋销量72份当前价格8元。“好吃”属于主观判断因此系统应明确这是依据销量形成的热门推荐而不是虚构用户评分。案例三健康用餐提示员工提问“我中午吃得健康吗”系统复用消费明细接口获得真实菜品及营养字段由大模型从热量、盐或钠、糖、脂肪、蛋白质、膳食纤维等维度生成提示。当数据缺失时必须明确说明营养字段缺失不代表摄入量为零没有糖数据时不得输出具体糖克数钠单位不明确时不得直接换算为盐部分菜品缺少营养数据时只能分析已经记录的部分。最终提示应包括数据基础、主要观察、改善建议和使用边界并声明其不能替代医生或专业营养师意见。五、生产环境关键控制一是数据安全。接口采用Bearer Token等方式鉴权密钥存放在Dify环境变量中员工身份由统一认证系统传入并在服务端实施数据权限校验。二是结果可信。金额、销量、价格和订单数量均通过确定性代码或SQL计算大模型只负责意图理解和语言组织不承担关键数值运算。三是异常处理。应覆盖无消费记录、接口超时、返回结构异常、日期越界、营养数据缺失和不支持场景并提供统一、专业的提示。四是可观测性。记录应用版本、调用耗时、接口状态和错误节点但对员工编号、Token及消费明细等敏感信息进行脱敏。五是持续优化。通过Dify运行日志分析用户真实问题逐步补充时间表达、同义问法和异常测试用例同时对金额准确率、意图识别率、接口成功率和健康提示合规率进行评估。六、总结Dify在员工用餐与员工消费场景中的核心价值不是替代现有订单系统而是在业务数据与员工之间增加一层可编排、可对话、可监控的智能交互能力。通过“业务系统保证数据真实性、规则代码保证计算确定性、大模型提升语言理解和表达体验”的分层设计可以较低成本实现消费查询、热门菜品推荐和健康用餐提示并为后续接入满意度反馈、菜单问答及个性化用餐服务提供统一的智能应用基础。
