小程序团餐忌口交接，先把每项要求对应到具体餐次、份数和用餐对象，再保留客户原话交厨房核实。AI可整理多轮沟通及后续更正；口味偏好不能替代客户明确的过敏声明，记录收到也不等于厨房已经确认能够提供。
团体订餐经常由一位联系人代多人沟通。有人想少辣，有人要求不放某食材，另有人主动说明食物过敏。几轮消息之后若只剩一行统一备注，既可能漏掉对象，也可能把普通偏好与需特别核实的声明混在一起。
客服先确认哪一天哪一餐、涉及几份及哪些具体要求。能用餐次内的必要代号对应，就不为整理一份交接表额外索取病史、证件等资料。联系人转述与本人明确表达分别保留，不根据不爱吃推断身体情况。
英国政府的餐饮过敏原指导强调让厨房知晓相关要求，并考虑交叉接触管理。这里借鉴前台与厨房的信息接续原则；具体原料、制作条件与能否承接，由实际供餐方核实，不由客服摘要决定。
知你AI助手可查询授权客户、历史会话和消息。千问办公完成当前通用MCP配置与授权后，定位本次小程序团餐咨询，读取初次要求及后续补充。厨房配方、原料和现场制作条件由负责岗位另外核实，不通过聊天推测。
提示词可写：“按每一餐整理需要供餐方确认的特殊要求，列日期餐次、必要对象代号、份数、食材原话、表达来源及后来更正。保留客户主动明确的过敏声明，不改写成普通不喜欢；含糊要求只列补问，不生成菜单、诊断或安全保证。”
同一联系人一次说两份，后来改为一份，要定位是否仍指同一餐、同一要求。未明确变化范围时先补问，不能把较晚一句覆盖整场活动。结果同时保留当前要求与更正依据，方便负责人员回查。
下图为MCP连接后台布局示意，交接表在AI客户端准备，不是点餐或过敏原检测页面。
以下客户、餐次和沟通全部虚拟。假定本次活动午餐总份数已由双方另行确认，以下只看需要特别交接的部分，不代表商家已经承接这些要求。
示例联系人甲先说：“午餐有一份少辣，另两份不要放花生。”后来其中一位用餐人明确补充：“我这一份是花生过敏，不是单纯不喜欢。”联系人随后又说：“刚才说的那两份不放花生，另一位不参加午餐了，现在只剩这位。”
| 当前餐次内代号 | 当前要求与份数 | 厨房接续重点 |
|---|---|---|
| 午餐甲 | 一份少辣，联系人转述 | 按实际口味安排核实 |
| 午餐乙 | 一份，保留本人花生过敏声明 | 原话交厨房，核实原料及制作条件后明确是否可承接 |
| 原另一份 | 联系人明确取消本餐该份 | 对应原记录更正，不误删午餐甲 |
这里不能算成一份少辣加两份不要花生，也不能把本人声明降成配料拿掉就行。是否能够满足，不由AI从菜单没有写花生作判断；厨房还需按实际资料与条件确认。
给厨房的交接草稿可以写：“本餐甲为一份少辣；乙本人明确表示花生过敏，请保留此要求核实实际承接条件。原转述两份不放花生中的另一份已取消本餐，当前乙仍保留。请分别回告可提供范围与尚需了解的信息，当前未向客户作适用保证。”
给联系人的答复可以写：“已按您的更正保留一份少辣和乙这份特殊要求，另一份本餐取消。乙本人说明的花生过敏已按原意交厨房核实，是否能够提供及具体安排，待负责人员确认后再向您说明。”
下图为客户端辅助交接流程，份数和原话均虚拟，不代表已完成食品安全审核。
知你AI助手帮助找齐表达与更正，千问办公把它们按同一餐组织。供餐负责人应分别说明哪些可以提供、哪些仍需核实或无法承接；不能因普通少辣已答可以，就把另一项特殊要求也一并标成确认。
客户已给清楚的内容不用从头再问，真正缺的部分集中补齐。先把一场活动的特殊要求完整接续，让前台记录与厨房掌握的内容一致。
不能推断，保留实际表达，必要时了解其具体要求。
不要弱化原声明，应原意交供餐负责人核实。
不能据此保证，原料与制作等实际条件需由厨房核实。
只更新明确指向的餐次与对象，范围不清先补问。
不会，本文准备交接草稿，正式确认与出餐按商家流程办理。
团餐特殊要求逐餐对应、逐项保留原话，后续更正不丢对象。用AI减少多轮整理工作，再让厨房按真实条件确认并由客服回告，让收到、核实和正式承接各自清楚。
如果团体订餐的特殊要求经常散在多轮咨询中，可了解知你AI助手官网，让AI辅助整理授权原话与交接缺项，再由供餐人员核实本次安排。
也可以扫码交流你的客服数据整理需求：
全渠道智能客服系统，聚合微信、小红书、抖音等平台咨询，支持自动回复与多客服协同。
知你AI助手官网 >AI 驱动的智能接待助手，基于知识库生成可确认的推荐回复，提升响应效率。
知你快回官网 >浏览器插件，为小红书、抖音、网页客服场景提供快捷话术库与 AI 自动回复。
