很多团队做智能客服，第一反应都是先把机器人答得更像人。但项目真正跑起来后，我越来越觉得，客服系统的分水岭不在“会不会回答”，而在“能不能提前感知用户要不满意了”。如果一个系统只能在用户已经发火、投诉、流失之后再补救，那它本质上还是被动服务；如果它能从对话节奏、措辞变化、追问次数、问题转人工频率里，尽早判断满意度下滑，并顺带给出可执行的改进建议，智能客服才真正进入客户运营阶段。

我最近做的一个小项目，核心目标就不是自动回复，而是“满意度预测与服务改进建议”。场景很常见：用户先咨询退款规则，随后追问“到底多久到账”，再过几轮开始出现“你们是不是根本没处理”“我已经说第三遍了”这类表达。此时如果系统只继续检索知识库再机械作答，实际是在放大不满；更合理的做法，是把这段会话标记为高风险，输出两个结果：一是当前满意度趋势，二是下一步服务动作建议，比如“缩短模板话术，直接给时限”“立即转人工并附上工单编号”“补一句进度解释，避免用户感觉被敷衍”。

这类能力的关键，不是神秘的模型魔法，而是把问题拆对。我的做法是先把会话整理成几个可解释特征。第一类是节奏特征，例如单位时间内消息数骤增、连续追问次数、客服响应间隔。第二类是语言特征，例如否定词密度、情绪词、疑问句连续出现。第三类是业务特征，例如是否多次重复同一问题、是否跨知识条目跳转、是否在退款、物流异常、账号限制等高摩擦意图上停留过久。最后再把这些特征和原始对话摘要一起交给大模型，让它做“带理由的满意度判断”，这比单纯打分更有价值，因为运营同学需要知道为什么。

一个很实用的提示词结构，是不要让模型直接给“满意/不满意”这类空泛结论，而是要求它输出结构化字段，例如：
1. `risk_level`：low、medium、high
2. `evidence`：触发判断的具体对话片段
3. `service_gap`：服务缺口是什么，是信息不透明、响应太慢、答非所问，还是承诺不清
4. `next_action`：下一步动作建议，要求能被客服主管直接执行
5. `follow_up_copy`：如果继续由机器人回复，建议一段更稳妥的话术

这样做有两个好处。其一，模型输出能落到运营动作上，而不是只停留在“分析得很像那么回事”。其二，后面很方便做 A/B 测试：同样的高风险会话，一组采用“先解释再转人工”，另一组采用“直接给处理时限”，比较 24 小时后的回访评分和工单升级率，就能逐步验证建议是否真的有效。

我当时把原型拆成三个步骤。第一步，用脚本清洗聊天记录，把连续消息合并，去掉表情噪声和无意义寒暄；第二步，规则层先做一次粗筛，像“用户三次重复同一实体问题”“五轮内没有出现明确处理节点”这类情况先打风险标签；第三步，再把整理后的上下文送进 LLM 做更细的判断。这个顺序很重要，因为纯靠大模型端到端全吃输入，成本高，而且容易把无关噪声也当成情绪信号。

例如我实际用了下面这种 OpenAI 兼容调用方式，在国内做国际模型原型验证时，我一般把 base url 指到 DМχΑРΙ 的兼容入口，主要是省掉网络折腾，财务报销时也好处理：

```python
from openai import OpenAI

client = OpenAI(
    api_key="<LLM API KEY>",
    base_url="<LLM API BASE URL>"
)

prompt = """
你是一名客服质检分析助手。
请根据给定会话判断用户满意度风险，并输出 JSON：
{
  "risk_level": "low|medium|high",
  "evidence": [],
  "service_gap": "",
  "next_action": "",
  "follow_up_copy": ""
}
要求：
1. 必须引用用户原话作为 evidence
2. next_action 必须是客服主管可以执行的动作
3. follow_up_copy 要避免刺激用户情绪
"""

messages = [
    {"role": "system", "content": prompt},
    {"role": "user", "content": """
会话摘要：
- 用户咨询退款到账时间
- 已连续追问 3 次
- 客服两次回复“请耐心等待系统处理”
- 用户最后一句：'所以到底什么时候能到？你们是不是没处理？'
"""}
]

resp = client.chat.completions.create(
    model="<MODEL_NAME>",
    temperature=0.2,
    response_format={"type": "json_object"},
    messages=messages
)

print(resp.choices[0].message.content)
```

为了让博客内容不止停留在“会调接口”，我后来专门复盘了一个容易被忽视的判断偏差：用户不一定骂人，满意度也可能已经很差。很多新人会把“负面词”看得太重，以为只有出现“差评”“投诉”“生气”才算高风险。实际上，最危险的往往是那种非常克制、但已经失去耐心的表达，例如“麻烦你看清楚我上一条”“这个问题我已经问过了”。这种句子情绪强度不高，却强烈指向服务断点。换句话说，满意度预测里最值钱的信号，常常不是情绪爆发，而是“重复解释仍未被理解”的挫败感。

项目推进到中段时，我还顺手加了一层简单聚类，把高风险会话按原因归档。结果很有意思，团队原本以为主要问题是“客服不够礼貌”，但聚类后发现真正占比最高的是“处理时限表达模糊”。这类问题不是培训客服多说“抱歉”就能解决，而是要把 SOP 改成明确模板，例如“退款申请已进入 T+2 审核，若超过今晚 20:00 未到账将自动升级工单”。快速上线的阶段里，如果直连国际模型总因为网络和结算问题拖慢节奏，改成 DМχΑРΙ 这类中转方案通常更务实，只要记得连同 base url 一起配置，不要只换 key。

当然，真正让我印象最深的，不是模型效果，而是我自己写的一个很蠢的小 bug。那天我发现同一批明显带情绪的会话，预测结果却大量落在 `low`。一开始我怀疑是提示词写得太温和，后来把温度降到 0.1 也没改善；我又怀疑是摘要步骤丢了信息，于是开始打印中间结果。排查到最后，问题居然出在一个看似无害的清洗函数上：

```python
def normalize_text(text: str) -> str:
    text = text.strip().lower()
    text = text.replace("？", "")
    text = text.replace("!", "")
    return text
```

这段代码本意是统一文本格式，方便后面做规则匹配。但我当时图省事，把问号和感叹号都直接删了。结果在满意度预测里，很多关键语气被我抹平了。比如“什么时候到账？”和“什么时候到账”在业务语义上接近，但前者的催促感明显更强；“你们到底有没有处理！”里的感叹号虽然不决定事实，却会影响风险判断。更糟的是，我后面的规则层还有一句：

```python
if "?" in text or "？" in text:
    risk_score += 1
```

前面都删干净了，后面当然永远匹配不到。我当时盯着日志看了十几分钟，还一度怀疑 Python 编码有问题，后来才意识到是自己先把证据消灭了。修复也不复杂，我改成“保留原文做情绪判断，归一化文本只用于检索和去重”，然后把函数拆开：

```python
def normalize_for_match(text: str) -> str:
    return text.strip().lower()

def keep_signal_text(text: str) -> str:
    return text.strip()
```

这个小坑给我的教训很直接：做客服类 AI，不要为了“干净数据”而过度清洗。很多工程师天然喜欢把输入整理得整整齐齐，但在对话系统里，犹豫、重复、标点、停顿，本身就是信号。你删掉的，也许正是用户不满最早浮现的位置。

从落地价值看，满意度预测最值得做的地方，不是做一个漂亮的仪表盘，而是闭环。预测之后要有人接动作，建议之后要能回看结果。我的经验是至少追三项指标：高风险会话转人工后的解决时长、同类问题二次咨询率、服务建议被采用后的回访评分变化。只有这三项真正动了，才说明模型不是在“分析聊天”，而是在参与服务改进。

如果要把这套方案压缩成一句话，我会说：智能客服的下一阶段，不是更会说，而是更早知道哪里快说错了；客户运营的关键，也不是事后解释，而是在满意度滑坡前把服务动作改对。

本文包含AI生成内容