必须约束输出格式、维护上下文状态、设计分层路由逻辑，否则无法实现结构化意图识别与可靠客服响应。默认自由文本输出无法提取intent_id和置信度，易导致业务逻辑中断或错误执行；需用system prompt强制json格式、temperature≤0.1、传入完整messages数组，并结合redis管理对话状态及设置confidence
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
直接调用 DeepSeek 的 API 就能跑起来一个可用的客服机器人，不需要训练模型、不用搭 NLP 流水线，但必须处理好三个关键点：意图识别格式约束、上下文维护方式、以及回复生成的路由逻辑。
为什么不能直接把用户消息丢给 deepseek-v4-chat？
因为默认输出是自由文本，客服系统需要结构化结果才能做后续动作（比如跳转工单、查物流、触发留资）。如果让模型自己“发挥”，它可能编造订单号、乱给解决方案，甚至绕过敏感词过滤。
- 典型错误现象：
{"choices":[{"message":{"content":"您好！请问有什么可以帮您？"}}]}—— 看似正常，但无法提取意图 ID，也没置信度，没法做兜底判断 - 正确做法：用
system角色强约束输出为 JSON，且只含intent_id、confidence、reason三个字段 - 参数差异：
temperature必须设为0.1或更低，否则模型会“抖机灵”加解释性文字 - 示例 prompt 结构：
{
"model": "deepseek-v4-chat",
"messages": [
{
"role": "system",
"content": "你是一个电商客服意图分类器。仅输出标准JSON，字段：intent_id（整数）、confidence（0.0–1.0）、reason（≤15字）。禁止换行、注释、额外说明。"
},
{
"role": "user",
"content": "我昨天下的单还没发货，能催一下吗？"
}
],
"temperature": 0.1,
"response_format": {"type": "json_object"}
}
如何维持多轮对话状态而不崩？
微信、企业微信、网页聊天都是无状态 HTTP 请求，每次请求进来时，后端必须能还原出“这是第几轮、上一句问了什么、槽位填到哪了”。DeepSeek 本身不存状态，这事得你管。
One API key for 70+ AI models. Route to GPT, Claude, Gemini, Qwen, Deepseek, Grok and more
下载
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
- 常见错误现象：用户说“我的订单”，机器人回“哪个订单？”，用户答“123456”，机器人却答“抱歉没理解”，因为第二轮没把第一轮的上下文传进去
- 必须传
messages数组，而不是单条prompt；每轮追加{"role": "user", "content": "..."}和上一轮的{"role": "assistant", "content": "..."} - 性能影响：上下文太长会拖慢响应、推高 token 消耗；建议限制最多保留最近 5 轮（约 800 tokens），更早的摘要压缩进
system提示词 - 存储方案：Redis 是最常用选择，key 用
session:{user_id}，value 存序列化的 messages 列表
自动回复该用规则还是大模型生成？
全靠 DeepSeek 生成每句话，成本高、延迟大、不可控；全用 if-else 匹配，又覆盖不了长尾问题。真实项目里，90% 的流量走轻量层，剩下 10% 才进大模型。
- 高频确定性问题（如“怎么退货”“发票怎么开”）：本地缓存 QA 对，按
intent_id直接查，响应压在 80ms 内 - 中低置信度（
confidence ）或复合意图（如“我要退货，顺便查下新订单物流”）：才把完整上下文交给 DeepSeek 做生成式回复 - 容易踩的坑：没设人工兜底阈值，导致模型胡说八道还发给了用户；或者把所有
intent_id == 3（物流查询）都走生成，其实知识库早有标准话术 - 推荐结构：
if intent_id in [1, 2, 5, 7] and confidence >= 0.85: return qa_cache[intent_id]; else: call_deepseek_for_generation()
微信/企业微信接入时最常漏掉的一件事
不是 API Key 配错，也不是消息加解密失败——而是没校验 timestamp 和 nonce，导致重放攻击或消息乱序。微信回调不保证实时性，同一 session 可能收到延迟 3 秒的旧消息，如果直接塞进上下文队列，会污染对话状态。
- 必须检查回调参数里的
timestamp是否在当前时间 ± 5 分钟内，超时直接丢弃 -
nonce要进 Redis 做去重（setex 300 秒），防止同一消息被重复消费 - 企业微信还要注意
msg_signature校验，漏掉这步，回调会被微信拒绝，但日志里只报 403，不提示具体原因 - 这个环节不出错，前面所有意图识别和生成逻辑才有意义；一但上下文错乱，用户会觉得“机器人记性特别差”
