我见过不少团队对“AI-First 客服”有种不切实际的浪漫想象：把工单丢给大模型，它就像一个永不加班、永不请假的超级客服，语气礼貌，还能顺便把知识库也写了。

现实更像什么？更像你把餐厅前台全换成自助点餐机，然后第三天发现：机器并不是“不会累”，它只是“不会背锅”。一旦用户问出菜单上没有的菜，或者要退菜、改价、走投诉流程，它就开始装死。

这个标题来自一篇 Medium 故事（“We Fired 40% of Support. The AI Quit on Day 3.”）。原文我这里直接打不开（被 Cloudflare 拦了），但光从标题和那句副标题“AI-first 客服的隐藏运营成本”就够我们把工程账算一遍了：AI 客服失败，通常不是技术不够炫，而是系统不够像“客服系统”。

如果你正在做 AI客服，或者更准确地说，你在做客户支持自动化，这里先把话说狠一点：别急着裁人，先把系统改成“可以随时撤回”的样子。

下面这篇就聊一件很朴素的事：你要的不是“AI 替代客服”，你要的是“AI 帮客服把脏活累活干掉”，而且随时能撤回。

先把锅找对：AI客服到底在干什么活？

客服不是聊天，它更像“带权限的流程引擎”，只不过入口是一段自然语言。

一个工单背后通常有四类工作：

  1. 识别意图：这是 bug？咨询？退款？投诉？账号被盗？
  2. 取证与定位：查日志、查订单、看账号状态、问关键问题补全信息。
  3. 做决策：退不退款？赔不赔？走哪条 SOP？要不要升级？
  4. 执行动作：改状态、重置、补发、退费、封禁、提工单给工程师。

大模型擅长的是第 1 和第 2 的一部分（尤其是“把话说顺”），第 3 和第 4 如果不加限制，就会变成“一个很会说话的实习生，拿着你家的总钥匙”。

“第三天就崩”的五个隐藏成本

我把常见翻车点浓缩成五条，你可以当成 AI-First 客服的体检表。

1) 长尾问题比你想的长得多

人类客服最强的能力不是背答案，是“猜测你真正的问题，然后把路问出来”。而 AI 一旦离开知识库覆盖范围，就容易：

  • 说得很像那么回事，但其实答非所问
  • 问题问不对，越问越偏
  • 把“不确定”伪装成“确定”

客服场景里，长尾不是 20%，经常是 80%。你把 40% 客服裁掉，剩下的 60% 立刻被长尾淹没，这时候 AI 的“平均水平”意义不大，你会被最糟糕的那 1% 体验拖垮。

2) SLA 是硬的，模型是软的

支持团队的指标是硬指标：首次响应、解决时长、升级率、CSAT。

模型的行为是软的：同一句话今天这样答，明天可能换个说法；同一个边界条件，遇到不同上下文就犹豫。

当你把 SLA 压在一个“概率型系统”身上，又没准备回退策略，第三天不崩才怪。

3) 权限与风控不是“加一句提示词”能解决的

“请不要退款”这句话对模型来说只是文字，对用户来说是钱。

客服动作里最危险的是这几类：

  • 退款/赔付/赠送额度
  • 账号安全（重置、绑定、解锁）
  • 合同与合规（隐私、数据导出、删除）
  • 处理愤怒用户（升级、安抚、赔偿承诺）

如果 AI 能直接执行这些动作，你不是在做自动化，你是在做“自动闯祸”。

4) 知识回流断了，AI 反而越用越笨

很多团队忽略一件事：客服系统的知识库不是写出来的，是“被逼出来的”。

人类客服每天都在把新问题变成 SOP：这次怎么解决，下次怎么更快。

你裁掉太多客服，或者让 AI 直接闭环不留痕，知识回流就断了。结果就是：

  • 新问题没有人总结
  • SOP 没有人更新
  • AI 永远在用旧答案应付新世界

然后你会发现，AI 不仅没省心，还开始反复制造“二次咨询”和“升级工单”。

5) 没有可观测性，就没有责任边界

传统客服翻车，你能追问：谁回的？看了哪些信息？按了哪个按钮？

AI 翻车，如果你没有把输入、检索、提示词、输出、决策、执行、回退全链路打点，那现场会变成大型甩锅运动会：

  • 产品说“是模型幻觉”
  • 工程说“是知识库没覆盖”
  • 运营说“是用户表达不清”
  • 老板说“那就全回滚”

这就是“第三天回滚”的真实技术原因：你不是不想修，是不知道从哪修。

别 AI-First，试试 AI-Assisted：一个更容易活下来的架构

我更推荐把 AI 放到“辅助位”，先让它当三样东西：

  1. 分流员：帮你把工单分级、打标签、路由到正确队列
  2. 检索员：从知识库、历史工单里找出相关内容
  3. 起草员：把回复写成“人话”，并把引用来源贴出来

真正的“决策”和“执行”，按风险做分层：

  • 低风险：允许自动发回复（例如 FAQ、状态说明）
  • 中风险：AI 起草，人类一键确认
  • 高风险：强制升级到人工，并且给出 AI 的定位建议

这听起来保守，但它有一个现实好处：你永远有退路。

实战：用 80 行 Python 写一个“能回退”的工单路由器

不接任何大模型 API，先把“流程骨架”搭出来：能分级、能兜底、能留痕。模型以后怎么换都行，骨架不换。

无论你用的是 Zendesk、Freshdesk、Intercom，还是自研工单系统，这个骨架都通用：先路由，再生成，再审批，再执行。

把下面这段存成 support_router.py 跑一下：

import json
import re
from dataclasses import dataclass
from datetime import datetime


@dataclass(frozen=True)
class Ticket:
    id: str
    subject: str
    body: str


HIGH_RISK_PATTERNS = [
    r"refund|chargeback|退款|退费|赔偿",
    r"hack|hacked|breach|账号被盗|被盗|泄露",
    r"lawsuit|legal|gdpr|隐私|合规|律师函",
]


def risk_level(text: str) -> str:
    text = text.lower()
    for p in HIGH_RISK_PATTERNS:
        if re.search(p, text):
            return "high"
    if "angry" in text or "投诉" in text or "差评" in text:
        return "medium"
    return "low"


def decide_action(ticket: Ticket) -> dict:
    text = f"{ticket.subject}\n{ticket.body}"
    risk = risk_level(text)

    if risk == "high":
        return {"route": "human", "priority": "p0", "reason": "high_risk_policy"}
    if risk == "medium":
        return {"route": "human_review", "priority": "p1", "reason": "needs_empathy_or_policy"}
    return {"route": "auto_reply", "priority": "p2", "reason": "low_risk_faq"}


def main():
    tickets = [
        Ticket("T-1001", "Can't login", "I forgot my password. Please help."),
        Ticket("T-1002", "Refund request", "I want a refund. You charged me twice."),
        Ticket("T-1003", "账号被盗了", "昨天半夜有人改了我邮箱，现在登录不上。"),
        Ticket("T-1004", "你们服务太烂了", "我已经投诉了，还没人回。"),
    ]

    for t in tickets:
        decision = decide_action(t)
        log = {
            "ts": datetime.utcnow().isoformat() + "Z",
            "ticket_id": t.id,
            "decision": decision,
        }
        print(json.dumps(log, ensure_ascii=False))


if __name__ == "__main__":
    main()

你会得到类似这样的输出：

{"ts":"2025-12-25T00:00:00Z","ticket_id":"T-1002","decision":{"route":"human","priority":"p0","reason":"high_risk_policy"}}

这段代码看起来很“原始”，但它解决了一个关键问题：先把风险兜住。之后你把 risk_level() 换成“LLM + 结构化输出 + 校验”，也还是同一个架构。

下一步再往上叠：

  • auto_reply：接 RAG 检索，生成带引用的草稿回复
  • human_review：把草稿推到客服工作台，一键通过/修改/退回
  • human：直接升级，并把“模型为什么判高风险”写清楚

这套东西怎么上线才不吓人

我建议按“胆子”从小到大来：

  1. 先做分流，不做自动回复：只打标签、分队列、建议优先级
  2. 再做起草，强制人工确认：AI 写回复，人类点发送
  3. 最后才放开低风险自动回复：并且必须能一键回滚到人工

同时把三类指标绑死：

  • 体验指标：CSAT、升级率、复开率（同一问题二次咨询）
  • 效率指标：首次响应、解决时长、每单人类触达次数
  • 安全指标：高风险漏检率、错误动作次数、合规事件数

如果你做不到“今天开、明天关”的开关，那你就别让它自动发任何一句话。

常见坑：别让 AI 当“客服经理”

最后说几个特别容易踩的坑，都是我见过的真实事故类型：

  • 把“省人”当成目标：结果工单没少，升级更多，反而把工程师拖下水当客服
  • 让 AI 直接承诺赔偿/退款：用户截图一转发，法律和公关一起进场
  • RAG 不做权限隔离：把别人的订单信息检索出来，那叫“AI 帮你泄露隐私”
  • 没有离线评估集：上线只能靠用户当小白鼠，第三天被迫回滚很正常
  • 没有回退策略：模型一抽风，团队只能连夜全量关停

AI 最擅长的是“写得像”，客服最怕的是“错得像对”。你得让它在错之前就停下来。

三行结论 + 下一步清单

三行结论：

  1. AI-First 客服最贵的不是模型费，是运营与风险成本。
  2. 先把“分级、兜底、留痕、回退”做出来，再谈自动化。
  3. 把 AI 放在辅助位，你才有资格让它逐步上位。

下一步清单（照着做，不花哨）：

  • 列出高风险意图清单：退款/安全/合规/投诉，先全部强制人工
  • 做一个可回滚的开关：按渠道、按队列、按用户分群逐步放量
  • 建 200 条离线评估集：从历史工单抽样，覆盖长尾和极端情绪
  • 给每次回复打引用：没有来源的回答，一律降级为“建议升级人工”

觉得这篇文章有用吗？

如果你刚好也在折腾 AI客服，这里给你一份“行动指南”，别客气，照着抄：

  1. 点赞：点一下赞，相当于告诉我“这个方向值得继续挖”
  2. 转发：把链接甩给正在喊“全员 AI客服”的同事，救他也救你
  3. 收藏：先放进收藏夹，下次要写方案/做评审时能直接翻出来当论据
  4. 关注：关注梦兽编程，后面我会继续更新 AI 工程化落地的坑与解法
  5. 留言：你们的客服场景最难的是什么？把关键词丢评论区，我来写下一篇

小小技术指引（不同场景怎么做）

  • 收藏：桌面浏览器按 Command+D（macOS）或 Ctrl+D（Windows/Linux）；手机用浏览器菜单里的“添加到书签/收藏”
  • 转发：复制地址栏链接发到群里；如果你们用飞书/Slack，把链接丢进对应的 support/ops 频道，顺手 @ 相关负责人
  • 关注：用站点的 RSS（如果你在用阅读器）或直接在首页点关注入口；不想错过更新就别只靠“想起来再来看”