0
餐厅差评处理是AI最容易翻车的地方。一个顾客提到过敏反应,AI要是自动回复了,品牌面对的不是公关危机,是法律事故。要是漏掉持续投诉的模式,顾客默默流失,管理层还蒙在鼓里。
这套开源的差评分拣工作流,是QSR AI Ops Pack的参考实现。完整JSON文件放在GitHub上,链接在文末。这篇重点讲分类逻辑——什么情况下AI可以起草回复,什么情况下必须叫人。
五轴标签分类
每条差评进来,先打五个独立标签,AI才能动笔:
• 严重词——有没有必须人工介入的表述?
• 服务词——是不是运营投诉,有标准应对剧本?
• 优先级——多快必须回复?
• 负责人——组织里谁背锅?
• 姿态——如果允许AI起草,用什么语气?
严重词这条轴,任何AI步骤都不能覆盖。这是整个工作流的安全底线。
严重词:什么情况下立刻升人工
严重词清单故意收得很窄。只抓那些"AI乱回不如不回"的场景:
• 过敏/过敏反应
• 生病/食物中毒/医院/急诊
• 法律/律师/诉讼/起诉
• 带具体金额的退款纠纷
• 监管提及(卫生部门、检查员)
• 歧视指控
• 店内受伤
一旦触发严重词,工作流做四件事:转人工收件箱、附单行摘要和原文、不生成公开回复、记录决策留痕。
服务词:AI可以起草的情况
非严重投诉,工作流从服务词清单里挑姿态:
• 等餐时间 → 承认+具体改进细节
• 订单准确性 → 道歉+邀请站内信订单号
• 温度/新鲜度 → 承认+强调备餐标准
• 员工行为 → 承认+转总经理,公开不提细节
• 清洁问题 → 承认+说明检查频率,不承诺具体
AI按对应剧本起草,不是自由发挥。这就是"经理30秒能发"和"得全重写"的区别。
优先级和负责人
优先级不只是回多快,还决定进哪个队列:
• P0(有严重词):进法务+品牌收件箱
• P1(运营投诉,近期到店):进门店总经理队列
• P2(旧差评,轻微):进品牌回复队列
• P3(好评但提了问题):进品牌队列,发感谢变体
负责人标签映射到具体的人。工作流配置里填好邮箱或PagerDuty,标签直接决定谁被叫醒。
姿态:AI的笔能写到哪
姿态标签约束AI的措辞边界:
• 道歉型——承认失误,不提补偿,留给人跟进
• 澄清型——纠正事实错误,语气克制
• 感谢型——正面评价,简短致谢
• 静默型——只记录,不回复(用于疑似刷评或已离线解决)
姿态和严重词是联锁的。严重词触发时,姿态只能是"静默",AI没有动笔许可。
技术实现:n8n节点拆解
工作流用n8n搭建,核心就三个节点:
• 触发器——监听Google Reviews或Yelp的webhook
• 分类器——并行跑五个标签的判断逻辑,用Code节点写正则匹配
• 路由——Switch节点按标签组合分流,严重词走人工分支,其余进AI草稿分支
AI草稿分支接的是OpenAI GPT-4,但prompt被锁死了:只能引用服务词对应的剧本片段,不能临场发挥。输出用Zod schema校验,格式不对就重试,重试三次失败转人工。
整个工作流的状态写进Airtable,方便品牌事后审计——哪天哪条评论、打了什么标签、谁处理的、花了多久。
为什么不用端到端AI
很多人问:为什么不让AI自己判断严重词、自己写回复?
因为分类错误和生成错误是两种风险。分类错了,AI可能把食物中毒当成普通投诉;生成错了,AI可能在道歉里承诺具体赔偿金额。前者是漏报,后者是误报,但后果都归品牌买单。
把工作流拆成"分类→路由→生成"三段,每段都有明确的失败模式:分类器看不懂就标"不确定"转人工,生成器越界就schema校验失败转人工。没有黑箱决策。
怎么用
GitHub仓库里有完整JSON,导入n8n就能跑。需要改的地方:webhook地址、OpenAI API key、Airtable base ID、严重词/服务词清单里的品牌特定表述。
建议先跑一周影子模式——分类结果不进实际队列,只比对人工判断和机器判断的差异。调准阈值再切生产。
链接:https://github.com/IgorGanapolsky/qsr-ai-preview/blob/main/workflows/n8n/qsr-review-triage-desk.json