AI 电商智能客服助手：Coze 全流程实战

关键词：Coze、智能客服、RAG、工作流、数据库、智能体编排、批处理

写在前面

本项目是大模型应用开发在「电商客服」场景下的完整落地案例。通过 Coze 平台的 Bot、知识库、数据库、工作流和 API/SDK，我们会把一套 7×24 小时智能客服系统从零到一搭建起来。

全文围绕五个核心模块展开：智能问答、订单查询、售后处理、智能体编排、批处理运营。读完可以掌握：怎么用 RAG 解决客服答非所问、怎么用数据库让 Bot 查订单、怎么用工作流处理售后、怎么把多个模块串成统一入口，以及怎么用 Python SDK 做批量运营。

[一、项目背景：为什么用 AI 改造电商客服？](#一、项目背景：为什么用 AI 改造电商客服？)
二、系统架构：四层模型设计
[三、模块一：智能问答（知识库 + RAG）](#三、模块一：智能问答（知识库 + RAG）)
[四、模块二：订单查询（数据库 + 工作流）](#四、模块二：订单查询（数据库 + 工作流）)
[五、模块三：售后处理（条件分支 + 多轮对话）](#五、模块三：售后处理（条件分支 + 多轮对话）)
[六、模块四：智能体编排（统一入口 + 意图识别）](#六、模块四：智能体编排（统一入口 + 意图识别）)
七、模块五：批处理模块（自动化运营）
八、实战路线图与关键配置
常见问题
写在最后

一、项目背景：为什么用 AI 改造电商客服？

电商客服每天面对大量重复性问题：商品规格、价格库存、订单状态、物流进度、退换货政策、优惠活动。传统人工客服的痛点很集中：

痛点	具体表现
重复性问题占比高	60% 以上咨询集中在商品、物流、售后政策
响应时间不稳定	高峰期排队严重，夜间服务能力弱
人工成本持续上涨	培训、排班、离职交接都是开销
数据沉淀困难	聊天记录分散，难以反哺产品和运营

AI 智能客服的价值不是替代人工，而是把重复、标准化的问题自动化，让人工客服专注处理复杂、情绪化、高客单的 case。

本项目基于 Coze 平台 搭建一套 AI 电商智能客服助手，覆盖售前咨询、订单查询、物流跟踪、售后处理、营销推荐五大场景，核心目标四句话：

7×24 小时在线：降低夜间和高峰期的服务真空。
知识库精准回答：减少话术错误和口径不一致。
私有数据可查询：订单、物流、售后状态实时可查。
复杂问题能转人工：情绪激烈或超出能力边界时平滑交接。

二、系统架构：四层模型设计

整体架构可以抽象成四层：

复制代码

┌─────────────────────────────────────────┐
│           用户感知层                     │
│  微信小程序客服 │ 网页聊天窗 │ 飞书机器人  │
├─────────────────────────────────────────┤
│           应用层                         │
│  会话管理 │ 意图识别 │ 工单流转 │ 转人工   │
├─────────────────────────────────────────┤
│           平台能力层                     │
│  Coze Bot │ 知识库 RAG │ 数据库 │ 工作流  │
├─────────────────────────────────────────┤
│           数据层                         │
│  商品知识库 │ FAQ 库 │ 订单库 │ 会话日志  │
└─────────────────────────────────────────┘

（上图：四层架构，从下往上依次为数据层、平台能力层、应用层、用户感知层）

用户感知层：微信小程序客服、网页聊天窗、飞书机器人等渠道。
应用层：会话状态管理、意图路由、工单流转、人工转接。
平台能力层：Coze Bot 做对话理解，知识库做检索，数据库做持久化，工作流做复杂流程编排。
数据层：商品知识库、FAQ、订单数据、售后工单、会话日志。

三、模块一：智能问答（知识库 + RAG）

3.1 为什么智能客服总是答非所问？

很多"智能客服"给人留下印象不是聪明，而是"聪明地胡说"。根因通常不是大模型不够强，而是 模型没有拿到正确的上下文。大模型训练时的知识是通用的、过时的，对具体商品的参数、当前活动规则、售后政策一无所知。

解决思路是 RAG（检索增强生成）：先从结构化知识库里检索出相关片段，再把片段和用户问题一起塞进 prompt，让模型基于已知信息回答。

（上图：RAG 流程：用户提问 → 知识库检索 → 召回相关片段 → 大模型生成回答）

3.2 知识库准备

知识库不是把商品详情页整段复制进去。一个好的片段应该满足：主题单一、信息完整、长度适中（300-500 字）。

以无线蓝牙耳机为例：

标题	内容	来源
无线蓝牙耳机 Pro 续航	单次充电可使用 8 小时，配合充电盒总续航可达 30 小时。	产品详情页
无线蓝牙耳机 Pro 规格	蓝牙 5.3，重量 45g，可选颜色为黑色和白色。	产品详情页
退换货政策	自签收之日起 7 天内，商品未拆封使用可申请无理由退货。	售后政策文档
新用户优惠	新用户可领取满 199 减 20 优惠券，有效期 7 天。	活动规则

3.3 FAQ 与知识库配合

FAQ：高频、标准、答案固定的问题。例如"多久发货""支持 7 天无理由退货吗"。
知识库：长尾、细节多、需要组合信息回答的问题。例如"这款耳机和上一代有什么区别"。

建议让 Bot 先走 FAQ 精确匹配，未命中再走知识库 RAG。

3.4 Coze 配置要点

配置项	建议值	说明
知识库召回数量	3-5 条	太少信息不够，太多噪声大
相似度阈值	0.75 以上	低于阈值宁可不回答
FAQ 匹配方式	关键词 + 语义	提高命中率
回复风格	亲切、简洁、准确	避免过度营销和冗长

提示词示例：

text 复制代码

你是某电商平台的智能客服助手，擅长回答商品咨询、售后政策和优惠活动问题。

回答规则：
1. 优先使用知识库中的信息回答，不要编造参数或规则。
2. 如果用户问题与 FAQ 完全匹配，直接返回 FAQ 中的标准回复。
3. 如果知识库中没有相关信息，礼貌告知用户，并询问是否需要转接人工客服。
4. 回复控制在 100 字以内，语气亲切自然。

兜底话术：

无法回答时："抱歉，这个问题我暂时无法准确回答，为您转接人工客服好吗？"
用户要求人工时："好的，马上为您安排人工客服，请稍等。"
遇到敏感投诉时："非常理解您的心情，已为您优先接入人工客服处理。"

四、模块二：订单查询（数据库 + 工作流）

4.1 为什么订单查询是刚需？

"我的订单到哪了"在电商客服高频问题里稳居前三。这类问题频率极高、答案固定，是最适合被自动化的场景之一。

4.2 数据表设计

最简单的订单表包含这些字段：

字段	类型	说明
id	Integer	主键
order_no	String	订单号
user_id	Integer	用户 ID
status	String	订单状态
total_amount	Float	订单金额
express_company	String	快递公司
express_no	String	快递单号
created_at	DateTime	创建时间

订单数据通常通过 定时同步 或 实时同步 从商家系统写入 Coze 数据库。

4.3 工作流设计

复制代码

开始
  │
  ▼
获取 user_id（从会话变量或用户输入解析）
  │
  ▼
数据库节点：查询用户最近一笔订单
  │
  ▼
判断节点：是否找到订单？
  │ 是                │ 否
  ▼                   ▼
返回订单详情      引导用户补充手机号/订单号

（上图：订单查询工作流：身份识别 → 数据库查询 → 物流查询 → 返回结果）

数据库节点 SQL：

sql 复制代码

SELECT order_no, status, total_amount, express_company, express_no
FROM orders
WHERE user_id = {{user_id}}
ORDER BY created_at DESC
LIMIT 1;

4.4 物流查询

插件方式：Coze 插件市场有现成的「快递查询」插件，适合快速验证原型。
自定义 API 方式：用 HTTP 请求节点或自定义插件调用自有物流接口，更灵活。

物流查询失败时，只返回订单状态和快递单号，不要把接口超时直接暴露给用户。

4.5 隐私保护

必须确保用户只能查自己的订单。SQL 查询必须带 WHERE user_id = ?，不允许跨用户查询。

五、模块三：售后处理（条件分支 + 多轮对话）

5.1 售后为什么最难自动化？

相比售前咨询和订单查询，售后涉及更多业务规则、用户情绪和分支判断。用户说"我要退货"，Bot 不能直接说"好的"，而是要先确认：

这个订单符不符合退货条件？
是退款、退货还是换货？
退货原因是什么？
有没有商品照片作为凭证？
处理结果和工单号怎么反馈？

售后模块的核心不是"对话多自然"，而是 流程严谨、状态清晰、兜底到位。

5.2 数据设计

售后工单表：

字段	类型	说明
id	Integer	主键
ticket_no	String	工单号
order_id	Integer	关联订单 ID
user_id	Integer	用户 ID
type	String	refund / return / exchange
reason	String	售后原因
status	String	工单状态
images	String	凭证图片链接，逗号分隔
created_at	DateTime	创建时间

工单状态流转：

复制代码

pending（待处理）
   │
   ▼
approved（已同意） ── rejected（已拒绝）
   │
   ▼
waiting_ship（待用户退货）
   │
   ▼
received（已收货）
   │
   ▼
refunding（退款中）
   │
   ▼
completed（已完成）

5.3 工作流设计

复制代码

开始
  │
  ▼
获取订单信息
  │
  ▼
判断节点：是否满足售后条件？
  │ 是                │ 否
  ▼                   ▼
询问售后原因      告知不符合条件原因
  │
  ▼
询问期望处理方式（退款/退货/换货）
  │
  ▼
收集凭证图片（可选）
  │
  ▼
数据库节点：写入 tickets 表
  │
  ▼
返回工单号和预计处理时间

售后资格判断规则：

订单状态为「已签收」或「已完成」。
自签收时间起不超过 7 天（无理由退货）。
商品类目支持退换货。

数据库写入 SQL：

sql 复制代码

INSERT INTO tickets (ticket_no, order_id, user_id, type, reason, status, images)
VALUES ({{ticket_no}}, {{order_id}}, {{user_id}}, {{type}}, {{reason}}, 'pending', {{images}});

5.4 多轮对话设计

轮次	Bot 提问	用户回答	工作流状态
1	"请问您想办理退款、退货还是换货？"	"退货"	收集 type
2	"请问退货原因是什么？"	"尺寸不合适"	收集 reason
3	"请上传商品照片（可选）。"	$图片$ / "跳过"	收集 images
4	"已为您生成工单 T20240815001，预计 1-2 个工作日处理。"	---	写入数据库

用户中途离开时，用会话变量保存已收集信息，超时后再重置。

六、模块四：智能体编排（统一入口 + 意图识别）

6.1 为什么需要编排？

用户不会按模块来提问。同一场会话里，用户可能先问"耳机续航多久"，接着问"我刚下单的什么时候发货"，然后又说"收到货发现不合适想退"。

编排层的作用就是做一个"总指挥"：听懂用户当前想做什么，把请求路由到对应的工作流，并在模块之间传递必要的上下文。

（上图：智能体编排架构：用户输入 → 意图识别 → 路由到不同工作流 → 统一回复）

6.2 意图识别

建议 规则路由兜底 + 语义路由主判：

意图	关键词	对应工作流
商品咨询	商品、价格、规格、颜色、库存	智能问答
订单查询	订单、发货、物流、快递	订单查询
售后处理	退货、退款、换货、售后	售后处理
营销推荐	优惠券、推荐、搭配、活动	营销推荐
转人工	人工、客服、投诉、找人工	人工转接

6.3 单 Bot 还是多 Agent？

单 Bot + 多工作流：结构简单，调试成本低，适合场景相对集中的项目。
多 Agent 协作：每个 Agent 专注一个领域，适合复杂业务、需要专业分工的场景。

本项目建议先用 单 Bot + 多工作流。

6.4 主 Bot 提示词

text 复制代码

你是某电商平台的智能客服助手，负责接待用户咨询。

你的职责：
1. 识别用户意图，调用对应工作流。
2. 保持礼貌、专业、简洁的回复风格。
3. 复杂问题或用户明确要求时，转接人工客服。

意图路由规则：
- 商品、价格、规格、售后政策 → 调用「智能问答」工作流
- 订单、发货、物流、快递 → 调用「订单查询」工作流
- 退货、退款、换货 → 调用「售后处理」工作流
- 优惠券、推荐、搭配 → 调用「营销推荐」工作流
- 人工、投诉、找客服 → 触发「人工转接」

上下文变量：
- user_id：当前用户 ID
- last_order：最近一次查询的订单
- session_history：最近 5 轮对话

重要约束：
- 不要在一个回复里同时调用多个工作流，除非用户明确问了多个问题。
- 如果用户意图不清晰，先澄清再路由。

6.5 上下文管理

需要维护三类上下文：

用户身份：会话开始时确定 user_id，后续订单查询、售后申请都基于这个 ID。
业务中间状态：售后处理工作流里，当前已收集到"退货原因"但还没收到"凭证图片"，这个状态要保存。
最近查询缓存：用户刚查过订单，接着又问"快递到哪了"，直接用缓存的订单信息查询物流。

6.6 人工转接

以下情况应该主动或被动转人工：

用户主动要求："找人工""转客服""我要投诉"。
连续未命中：连续 3 次以上提问都没有命中任何工作流或知识库。
强烈负面情绪：出现"假货""骗子""差评""举报"等词语，或连续否定、语气激烈。

转接时要生成会话摘要，把摘要推送给人工客服系统，并告知用户预计等待时间。

七、模块五：批处理模块（自动化运营）

7.1 为什么需要批处理？

智能客服 Bot 上线只是第一步。真正让它越用越聪明的，是背后的运营闭环：商品更新、活动上线、订单状态变化、会话日志分析。这些工作靠人工在 Coze 后台一个个点效率太低，批处理模块就是把重复运营动作自动化。

7.2 批量导入 FAQ

把 FAQ 整理成 CSV：

csv 复制代码

category,question,answer,keywords
物流,多久发货？,付款后 48 小时内发货，节假日顺延。,发货，多久
售后,支持 7 天无理由退货吗？,支持，未拆封使用可 7 天无理由退货。,退货，7天
优惠,有没有优惠券？,新用户可领满 199 减 20 优惠券。,优惠券，活动

导入脚本要点：去重、重试、日志、分批。

7.3 批量导入知识库

文档切分策略：按标题切分、按段落切分、按固定长度切分。每段 300-500 字为宜。导入前校验空内容、重复内容、关键信息缺失。

7.4 批量同步订单状态

定时同步：每天晚上把当天有变化的订单推送到 Coze 数据库。
实时同步：商家系统状态变更时，通过 Webhook 实时调用 Coze API 更新。

同步失败要记录日志、重试、告警。

7.5 批量分析会话日志

通过批量分析可以回答：

用户最常问的前 10 个问题是什么？
哪些问题 Bot 回答不了，需要转人工？
用户在什么场景下情绪最负面？
哪些商品的知识库内容明显不足？

分析维度：

维度	说明
意图分布	售前/订单/售后/推荐的占比
未解决率	触发兜底话术或转人工的会话比例
高频问题	出现次数最多的用户问题
情绪分布	正面、中性、负面的会话占比

分析结果反哺：高频问题补充进 FAQ，知识库缺失的内容补充商品详情，未解决率高的意图优化工作流或提示词。

7.6 批处理常见坑点

坑点	说明	应对
API 限流	Coze API 有调用频率限制	控制并发、加入延时、分批处理
重复导入	同一文档多次导入会造成冗余	导入前查询已有文档或按名称去重
数据不一致	同步失败导致 Coze 数据库与业务系统不一致	记录同步日志、失败重试、告警
大批量超时	一次性导入太多数据容易超时	拆成小批次，每批 50-100 条
隐私合规	会话日志可能包含敏感信息	分析前脱敏，避免泄露用户隐私

八、实战路线图与关键配置

8.1 落地顺序

建议按以下顺序落地，每个模块在 Coze 里单独跑通后再整合：

智能问答模块：先跑通知识库和 FAQ，让 Bot 能回答常见问题。
订单查询模块：接入订单数据库，实现"我的订单"查询。
售后处理模块：用工作流实现退货、退款、换货申请。
智能体编排：把前三个模块串起来，实现统一入口和意图路由。
批处理模块：用 Python SDK 批量维护数据和生成分析报表。

8.2 Bot 调用骨架

下面是一段用 Coze Python SDK 调用客服 Bot 的骨架代码：

python 复制代码

from cozepy import Coze, TokenAuth, Message

# 1. 使用 PAT（个人访问令牌）鉴权
client = Coze(auth=TokenAuth("your_pat_token"))

# 2. 指定 Bot ID 和用户标识
bot_id = "your_ecommerce_customer_service_bot_id"
user_id = "user_13800138000"

# 3. 发起对话，模拟用户咨询商品续航
response = client.chat.completions.create(
    bot_id=bot_id,
    user_id=user_id,
    additional_messages=[
        Message.build_user_question_text("这款耳机续航多久？")
    ],
)

# 4. 打印 Bot 回复
print(response.content)

# 实际工程中，这里还需要：
# - 把 user_id 和 open_id 做映射，识别用户身份
# - 把每次对话记录到 session_logs 表，用于后续分析
# - 对回复内容做敏感词和幻觉校验

8.3 关键配置汇总

配置项	建议值	说明
知识库召回数量	3-5 条	平衡信息量和噪声
相似度阈值	≥ 0.75	低于阈值宁可不回答
FAQ 匹配方式	关键词 + 语义	提高命中率
订单查询默认规则	返回最近一笔订单	大多数用户只关心最新订单
售后有效期	7 天	无理由退货期限
工单号生成	日期 + 序号	如 T20240815001
批量操作批次大小	50-100 条	避免 API 超时和限流

常见问题

Q1：AI 客服会不会回答错误导致客诉？

A：知识库和 FAQ 要定期更新，对不确定的问题设置兜底话术并引导转人工，不要硬答。

Q2：已有订单系统，数据怎么同步到 Coze？

A：可以通过 Coze API 或数据库插件定期同步，也可以直接让 Coze 查询外部数据库。

Q3：人工客服怎么接管？

A：在 Bot 中设置转人工触发条件，比如关键词、情绪识别、连续未命中知识库等，转接时携带会话摘要。

Q4：意图识别不准怎么办？

A：先用关键词规则兜底，再补充语义示例。对于高频误识别的句子，加入提示词的反例说明。

Q5：批量导入时遇到 API 限流怎么办？

A：控制并发、加入延时、拆小批次，记录失败项并重试。

写在最后

AI 电商智能客服助手是一个把大模型能力真正落到业务里的项目。它覆盖了 RAG、数据库查询、工作流编排、意图路由、批处理运营等核心技术点，也真实还原了电商客服的痛点和解决路径。

做这个项目时，最重要的心得有三条：

不要一上来就做全功能 Bot。先让每个模块单独跑通，再整合，调试成本会低很多。
安全兜底比回答准确率更重要。不会的问题诚实说不会，情绪激烈的用户及时转人工，比"硬答"更能赢得信任。
上线只是开始，运营才是核心。用会话日志驱动知识库和 FAQ 的持续优化，智能客服才会越用越聪明。

#Coze #智能客服 #RAG #工作流 #数据库 #智能体编排 #批处理

外部数据库。

Q3：人工客服怎么接管？

A：在 Bot 中设置转人工触发条件，比如关键词、情绪识别、连续未命中知识库等，转接时携带会话摘要。

Q4：意图识别不准怎么办？

A：先用关键词规则兜底，再补充语义示例。对于高频误识别的句子，加入提示词的反例说明。

Q5：批量导入时遇到 API 限流怎么办？

A：控制并发、加入延时、拆小批次，记录失败项并重试。

写在最后

做这个项目时，最重要的心得有三条：

不要一上来就做全功能 Bot。先让每个模块单独跑通，再整合，调试成本会低很多。
安全兜底比回答准确率更重要。不会的问题诚实说不会，情绪激烈的用户及时转人工，比"硬答"更能赢得信任。
上线只是开始，运营才是核心。用会话日志驱动知识库和 FAQ 的持续优化，智能客服才会越用越聪明。

#Coze #智能客服 #RAG #工作流 #数据库 #智能体编排 #批处理

AI 电商智能客服助手：Coze 全流程实战