差评冒出来之前，让值班群先响起来——本地生活服务的差评自动预警系统
一、业务痛点：差评的伤害不在出现，而在发现太晚
做过本地生活服务平台运营的人都熟悉这个场景：一家合作门店在周五晚高峰出了餐品问题，顾客当晚在平台留了差评，但商家和平台侧的对接人周一早上才看到。这期间又有三桌顾客遇到了同样的问题，又多了三条差评。门店评分从4.6掉到4.2,周订单量下滑近两成——而这一切本可以在第一条差评出现后的十分钟内被拦截。
作为管理者，我总结过这类问题的三个共性：
- 响应链路太长：差评分散在平台后台、商家后台、多个客服群，依赖人工巡检，巡检频率决定了响应上限。
- 严重程度无法分级：一条“口味偏咸”和一条“吃出异物”需要完全不同的处理流程，但人工浏览时它们只是两条都需要看完的文本。
- 责任边界模糊：谁先看到、谁上报、谁联系商家，没有系统化记录，事后复盘时永远说不清“我们到底几点知道的”。
这三个问题的本质是：差评处理还是人肉流程，而它的产生速度和严重程度分布，已经超出了人肉巡检的能力边界。这正是AI应用最适合切入的地方——不需要替换人，只需要把“发现和分级”这一环自动化。
二、架构设计：一条四段式流水线
我们给团队定的架构原则是：每个环节职责单一、可独立替换、全程留痕。整体分为四层：
┌─────────────────────────────────────────────┐
│ 数据接入层:平台评价API / 商家后台 / 客服工单 │
│ ↓ 定时拉取 + Webhook 推送 │
│ 分析层: │
│ ① 快模型初筛(廉价): 是否负面 / 是否需升级 │
│ ② 强模型精判(贵但准): 严重度分级 + 归因分类 │
│ ↓ 结构化输出(JSON) │
│ 决策层:规则引擎 │
│ 阈值判断 / 同店聚合 / 升级路由 │
│ ↓ │
│ 通知层: │
│ 轻度→企业微信群卡片 │
│ 重度→值班人电话 + 商家对接人 + 自动工单 │
└─────────────────────────────────────────────┘几个关键设计决策：
为什么用两层模型而不是一个？ 全量评价里差评占比不高，如果每条都过强模型，成本不可控。快模型先过滤掉80%的无风险内容，只有疑似负面的才升级到强模型做严重度判断。这个分层思路在直播弹幕过滤等场景已被反复验证。
为什么决策层用规则引擎而不是让大模型直接决定？ 严重度分级交给模型，但“什么级别触发什么动作”必须是团队可配置、可审计的规则。模型输出判断，规则输出动作——这样管理者能随时调整响应策略，不用改代码。
为什么所有环节走统一AI API网关？ 这是本方案维护成本控制的核心，下一节展开。
三、关键实现步骤
实施清单(建议三周节奏):
第1周 · 打通数据
□ 接入平台评价API,建立增量拉取任务
□ 定义评价数据结构(店ID/时间/星级/文本/图片标记)
□ 建立原始数据落库(审计需要,不可跳过)
第2周 · 接入分析能力
□ 通过统一AI网关配置两个模型端点(快模型/强模型)
□ 编写初筛Prompt:输出 {is_negative, confidence}
□ 编写精判Prompt:输出 {severity: 1-4级,
issue_type: 食品安全/服务态度/出餐速度/环境/其他,
suggested_reply_tone}
□ 强制JSON Schema输出,解析失败自动重试一次
第3周 · 决策与通知
□ 规则引擎:4级→电话+自动工单;3级→群内@值班;
同店2小时内≥2条3级→自动升级为门店级事件
□ 企业微信通知卡片:含严重度、归因、原文、建议回复
□ 日报推送:当日差评分布、响应时长统计
□ 灰度上线:先并行人工巡检一周,对比漏报率四、为什么统一AI API网关能显著降低维护成本
这个方案要长期跑下去，最大的隐性成本不是token费用，而是接入层的维护。直接讲三条经验：
第一，模型会换，代码不该跟着改。 差评分析这类任务，模型每半年就有更好的选择。如果代码里硬编码了某家SDK,每次换模型都是一次全链路回归测试。走统一网关后，应用只面对一套稳定的API协议，换模型变成网关后台改一个路由配置，开发者可以在同一个应用里并行调用多家模型做A/B对比，选定后切流量即可，业务代码零改动。
第二，密钥和权限集中管理，风险才收得住。 独立开发者和小团队最常见的翻车方式，就是把API Key散落在各个脚本、各台服务器甚至前端代码里。网关模式下一套密钥统一管理，团队成员各自持有网关密钥而非模型原始密钥，可以按人设额度、设过期时间。人员变动时回收一个网关密钥就够了，不用全局换钥。
第三，成本和调用可观测，管理者才有抓手。 差评预警是长跑型应用，快慢模型的调用比例、单条分析成本、失败率，这些数据不收集就是黑盒。统一网关天然提供调用日志和费用统计，月底看账单时能精确到“这个功能花了多少钱”，而不是一笔糊涂账。配合额度上限，也不会出现某个循环bug一夜烧光预算的事故。
一句话总结：网关把“接模型”从每个开发者的重复劳动，收敛成团队级的一次性基建。对小团队来说，这几乎是用工程纪律换人力成本的唯一划算买卖。
五、上线后的运转方式
系统跑起来之后，管理者的日常动作变成三个：
- 每天看日报：差评总量、严重度分布、平均响应时长，异常波动追根因；
- 每周调规则：哪些4级其实是一级？哪些店反复出现同类问题？据此调整分级Prompt和阈值；
- 每月复盘升级事件：每一起升级到电话通知的事件，都完整回放“差评产生→系统识别→人工介入”的时间线，持续压缩响应时间。
差评本身不可怕，可怕的是组织对它的感知速度跟不上它的传播速度。把感知这一环交给系统，把处置这一环留给人，人和机器各干擅长的事——这就是这套预警系统给团队带来的最实在的改变。
如果你也准备动手搭自己的AI应用，从统一网关开始会让后面每一步都轻松很多。可以在 https://api.thistoken.ai/register 注册，把多家模型收敛到一个入口，先跑通最小闭环，再逐步叠加分层和规则——这套差评预警的架构，同样适用于客服工单、社交媒体舆情等任何“发现要快、判断要准”的场景。
---
本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。