企业官网建设流程全解析

你被AI客服气到过吗？最近“中消协点名AI客服”这个话题上了热搜，不少网友吐槽：找人工客服比解数学题还难，AI机器人翻来覆去就那几句车轱辘话，遇到问题只会“踢皮球”。作为开发者，我们一边是用户，吐槽体验差；另一边又是技术人，心里明白一个扎心事实：很多AI客服并不是“不智能”，而是压根没被设计好。

这篇文章不是单纯跟你一起骂产品经理，而是想从技术角度拆解AI客服背后的实现思路。我会先解释智能客服涉及的核心技术链路，然后重点分析提示词工程、RAG检索增强生成、模型微调这三层技术在客服场景下分别解决什么问题，再带大家动手写一个简单的AI客服Demo，最后给出工程落地时的排错思路和最佳实践。文章内容会比较贴合实际开发，适合正在做客服系统、对话机器人的后端或算法同学，也适合想入门AI应用的开发者。

1. 背景：为什么AI客服越智能，体验越离谱？

1.1 中消协点名事件的背后，是体验与成本的结构性矛盾

先说事件本身。中消协在投诉分析中点名了AI客服，提到的问题概括起来无非三类：

• 客服电话永远转不到人工，AI兜底能力不足；
• 在线机器人答非所问，理解不了复杂表述；
• 多次重复问题后又回到初始菜单，处理效率极低。

从企业视角看，AI客服的初衷是用机器替代重复性人力咨询，降低客服成本。这本身没有问题。问题出在“降本”和“增效”被简单等同起来：很多团队把客服机器人当成一个“关键词匹配器”，或者直接把一个大模型API塞进对话框，不做知识管理，不做兜底策略，就让机器人直接面向用户。

结果就是：技术投入花了不少，用户感知到的却是“被AI当猴耍”。

1.2 智能客服的真实技术定位

业内常说的智能客服，实际上是一个由多个模块组成的系统，而不只是一个聊天框。常见的分层是：

很多用户感知到的“奇葩回答”，往往不是大模型不够聪明，而是决策层和兜底层设计得太薄弱。只有把客服的会话流程、知识库检索、模型调用方式当成一个整体来建设，才有机会改善体验。

1.3 开发者应该关注的问题

在动手做客服AI之前，建议先搞清楚几个核心问题：

• 用户的问题以哪种类型为主？是查订单、问规则、报故障，还是闲聊？
• 已有的知识内容是否结构化？是散落在PDF、Word、网页里，还是已经沉淀为FAQ？
• 客服回复允许出现随机发挥，还是必须严格对照业务口径？
• 机器人无法解决时，如何让用户毫无障碍地转人工？

这些问题直接决定了你后续应该选“提示词工程”、“RAG检索”还是“模型微调”。接下来我们就进入这三个层级的技术拆解。

2. 三类核心技术拆解：提示词工程、RAG、模型微调

打开各种AI技术交流群，最常看到的提问是：“AI客服应该用提示词工程，还是RAG，还是微调？”

这其实是一个伪命题。这三者不是互斥关系，而是在不同粒度上解决不同问题。我们逐个拆开来看。

2.1 提示词工程（Prompt Engineering）

提示词工程是成本最低、见效最快的手段。它不改变模型参数，只是通过精心设计的输入指令，让模型按照预期的方式回答。

在客服场景里，提示词工程的核心工作包括：

• 定义角色，比如“你是XX银行的智能客服助手”；
• 定义回答边界，比如“只根据提供的信息回答，不知道就说不清楚”；
• 定义风格，比如“简洁、礼貌、口语化”；
• 定义输出格式，比如“先用一句话给出结论，再列出操作步骤”。

一个简单的Python调用示例：

# -*- coding: utf-8 -*- # 文件路径：prompt_demo.py # 说明：本示例演示如何通过提示词约束大模型的客服回答风格 from openai import OpenAI client = OpenAI( # 生产环境推荐从环境变量读取，不要硬编码 api_key="你的API_KEY", base_url="模型服务地址" ) system_prompt = """ 你是一个在线商城的AI客服助手。 请遵循以下规则： 1. 回答必须简洁，一般不超过200字。 2. 如果用户询问退换货规则，先给结论，再给操作步骤。 3. 如果信息不足，请告诉用户“需要转接人工客服进一步确认”，不要编造规则。 4. 禁止出现情绪化表达，禁止使用讽刺语气。 常见规则参考： - 七天无理由退换货：商品签收后7天内，不影响二次销售可申请。 - 生鲜类商品不支持七天无理由退货。 """ user_question = "我昨天买的苹果坏了，能退吗？" response = client.chat.completions.create( model="qwen-plus", # 示意模型名称，可按实际服务商修改 messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_question} ], temperature=0.3, max_tokens=500 ) print(response.choices[0].message.content)

这段代码的意图很明显：用户的问题本身信息不完整（没有说明生鲜还是普通商品），在系统提示词里加入了“信息不足时不要编造”的约束，模型就会倾向于询问商品类型或建议转人工，而不是乱答。

提示词工程适合以下场景：

• 回答格式要求明确；
• 业务规则相对简单；
• 模型已经具备一定通用知识；
• 团队希望快速验证客服效果。

它的局限也很明显：如果客服问题依赖大量实时业务数据、内部流程，或者上下文中要携带几百篇文档，这时候只靠提示词是装不下的。

2.2 RAG（检索增强生成）：让客服回答“有据可循”

RAG（Retrieval-Augmented Generation）是目前做企业级客服落地最常用的方案。它的思路非常朴素：先到知识库中检索与用户问题相关的内容片段，再把检索到的内容作为上下文，连同用户问题一起交给大模型生成回答。

用一张结构来表达：

用户问题 → 向量召回（或关键词召回）→ 得到Top K知识片段 ↓ 用户问题 + TopK片段 + 提示词模板 → LLM生成回答

RAG最大的价值在于：当客服系统回答“七天无理由退货需要满足什么条件”时，它不是凭空发挥，而是先从当前最新的售后政策文档里召回相关内容，再回答。这比让模型背诵培训资料靠谱得多。

一个最小化的Python实现可以采用以下步骤：

# -*- coding: utf-8 -*- # 文件路径：rag_mini_demo.py # 功能说明：简化版RAG客服问答流程 # 生产环境建议替换为向量数据库和正式的Embedding模型 from sentence_transformers import SentenceTransformer import numpy as np # 1. 准备知识库片段 knowledge_docs = [ "商品签收后7天内，不影响二次销售可申请七天无理由退货。", "生鲜、定制类商品不支持七天无理由退货。", "退货申请通过后，请在72小时内将商品寄回。", "退款将在商品入库质检通过后1-3个工作日内原路退回。", "如果商品存在质量问题，可申请运费险理赔。" ] # 2. 加载Embedding模型（实际项目可换成更小的中文模型） model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2') doc_embeddings = model.encode(knowledge_docs) def search_knowledge(question, top_k=3): """根据用户问题召回最相关的几个知识片段""" query_embedding = model.encode([question]) # 计算余弦相似度 scores = np.dot(doc_embeddings, query_embedding.T).flatten() top_indices = scores.argsort()[-top_k:][::-1] return [knowledge_docs[i] for i in top_indices] question = "我买的苹果坏了能退款吗" retrieved = search_knowledge(question) for i, doc in enumerate(retrieved): print(f"召回片段{i+1}: {doc}")

你会看到，单纯的关键词和语义召回能定位到“生鲜类不支持退货”“质量问题处理”等片段，但最终如何组织回答，还需要大模型加工。在真实工程里，RAG链路通常长这样：

为什么客服场景特别适合RAG？因为客服讲究“口径一致”。政策一变，只需要更新知识库，不需要改提示词，更不需要重训模型。这一点对于业务迭代频繁的客服系统极其重要。

2.3 模型微调（Fine-tuning）：让模型“精通某种说话方式”

模型微调指的是在已预训练模型的基础上，使用特定领域的数据进一步训练，让模型适应某种风格、格式或领域知识。

在客服场景里，微调并不适合用来“喂”大量规则文档（那是RAG干的事），它更适合解决这类问题：

• 希望模型的回答风格完全贴近品牌IP，比如“语气可爱”“喜欢用表情包”；
• 希望模型直接输出结构化字段，比如“{意图: 退换货, 商品类型: 生鲜}”；
• 希望模型能模仿历史优秀客服工单的回答逻辑。

要注意，微调的成本和风险都比RAG高。如果你只是想客服系统能查到最新售后政策，优先RAG；如果你希望机器人能在固定格式、专业话术上有明显提升，再考虑微调。

这里可以做一个判断口诀：知识不够用，就做RAG；风格不够像，就做微调；两者前提下的规则约束，再靠提示词优化。

3. 为什么AI客服会“把你当猴耍”？从技术实现找原因

用户吐槽AI客服，本质上是在吐槽系统在“某些环节出现了断裂”。我们从技术链路侧分析，通常会定位到四类问题。

3.1 问题一：语义理解停留在关键词匹配

很多早期的智能客服机器人，本质上就是一个关键词匹配器。用户说“我手机坏了想修”，如果知识库里只存了“手机维修”而没有“手机坏了”，匹配就可能失败。

现在的LLM客服在理解力上改善了很多，但一些自建客服系统仍然会把大模型结果粗暴地变成一个“黑盒”，没有对用户输入的拼写错误、口语省略、指代进行预处理。例如：

• “我上礼拜买的那个，就是蓝色的，能不能退了”；
• “我卡被吞了，咋办”；
• “我退款的钱呢？”

这些表达如果缺少上下文和意图中间层，回复很容易跑偏。

3.2 问题二：知识库不更新，模型还在背诵旧政策

这种情况在RAG系统中经常出现。知识库的更新没有和业务系统打通，售后政策改了，旧的PDF还放在文档库里。检索模块每次都能召回到旧版本内容，LLM再怎么强，也只能照着旧文档回答。

3.3 问题三：兜底设计缺失，转人工比登天还难

正常客服系统应该设计这样一个流程：机器人置信度低于阈值，或者用户连续两次表达“转人工”“投诉”时，立刻转人工。但很多产品为了降低人工成本，故意把转人工入口藏得很深，机器人识别到转人工意图后依然自动回复“您可以尝试描述一下您的问题”，这就是大家最反感的“踢皮球”。

3.4 问题四：评测体系缺位，上线前不知道回答有多差

不少团队上线AI客服前，只拿十几条测试用例跑了一遍就放出去了。没有建立自动化评测集，没有对回答内容进行安全、敏感性、事实一致性检测，结果线上各种翻车。

4. 实战案例：用“大模型+RAG+转人工兜底”搭建一个可用的客服机器人

4.1 项目中涉及哪些模块

为了让展示更贴近实际，这里不写一个玩具级“一问一答”脚本，而是把客服系统最核心的几个模块串一遍。

完整Demo模块包括：

• 一个基于FAQ的知识库加载器；
• 一个轻量级的语义检索函数；
• 一个调用大模型生成回答的封装；
• 一个区分“能回答”和“不能回答”的兜底逻辑。

为了便于演示环境差异，下面的代码会采用“接口示意+核心逻辑”的方式呈现，你可以在自己的项目中把模型服务替换成OpenAI兼容接口或本地Ollama服务。

4.2 项目结构

一个公司若只是做小流量客服，可以直接用Python写一个FastAPI服务；如果是大型系统，通常还会拆出知识库管理后台和会话服务。本文的演示结构如下：

ai_customer_service/ ├── app.py # FastAPI入口，提供HTTP接口 ├── knowledge_loader.py # 加载FAQ知识文档 ├── retriever.py # 向量检索模块 ├── llm_client.py # 大模型接口封装 ├── faqs.json # 示例知识库 └── requirements.txt

4.3 建立示例知识库

{ "faqs": [ { "id": "1001", "question": "如何申请七天无理由退货", "answer": "请在订单页点击申请售后，选择七天无理由退货，填写退货原因后等待审核。", "category": "售后" }, { "id": "1002", "question": "生鲜商品可以退款吗", "answer": "生鲜类商品不支持七天无理由退货，如果存在质量问题，请在签收后24小时内联系人工客服并上传照片。", "category": "售后" }, { "id": "1003", "question": "退款多久到账", "answer": "商品入库质检通过后，退款会在1-3个工作日内原路退回。", "category": "售后" }, { "id": "1004", "question": "怎么转人工客服", "answer": "您可以直接输入“转人工”，或者在工作时间拨打客服热线。", "category": "服务" } ] }

这个JSON结构只是一个极简示例。真实项目中的知识库往往有几十万条FAQ，而且需要支持多轮上下文、版本管理和定时更新。

4.4 实现知识库加载与检索

# -*- coding: utf-8 -*- # 文件路径：knowledge_loader.py import json import numpy as np class KnowledgeBase: def __init__(self, faq_path): with open(faq_path, "r", encoding="utf-8") as f: data = json.load(f) self.faqs = data["faqs"] def get_all_faqs(self): return self.faqs

# -*- coding: utf-8 -*- # 文件路径：retriever.py # 说明：真实项目可替换为向量数据库。此示例用句子相似度做演示。 from sentence_transformers import SentenceTransformer import numpy as np class Retriever: def __init__(self, kb): self.kb = kb self.model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2') docs = [] for faq in kb.get_all_faqs(): docs.append(faq["question"] + "。" + faq["answer"]) self.docs = docs self.doc_embeddings = self.model.encode(docs) def search(self, query, top_k=2): query_embedding = self.model.encode([query]) scores = np.dot(self.doc_embeddings, query_embedding.T).flatten() top_indices = scores.argsort()[-top_k:][::-1] results = [] for idx in top_indices: if scores[idx] < 0.3: continue results.append({ "faq": self.kb.get_all_faqs()[idx], "score": float(scores[idx]) }) return results

这里设置了一个0.3的相似度阈值，它的作用很重要：如果检索结果整体相似度都很低，说明知识库里可能没有能回答这个问题的内容，系统不应硬着头皮用无关内容生成回答。

4.5 封装大模型生成接口

# -*- coding: utf-8 -*- # 文件路径：llm_client.py from openai import OpenAI class LLMClient: def __init__(self): # 实际项目建议从配置中心/环境变量读取 self.client = OpenAI( api_key="你的API_KEY", base_url="你的模型服务地址" ) def generate(self, user_query, context_segments): context = "\n".join([f"- {seg}" for seg in context_segments]) prompt = f""" 你是一个电商AI客服助手。 请结合下面的参考资料回答用户问题。 如果参考资料不足以回答用户问题，请直接回答：非常抱歉，我需要转接人工客服为您处理。 参考资料： {context} 用户问题： {user_query} 请用中文友好、简洁地回答。 """ response = self.client.chat.completions.create( model="qwen-plus", messages=[ {"role": "system", "content": "你是一个客服助手，回答只依据参考资料。"}, {"role": "user", "content": prompt} ], temperature=0.2 ) return response.choices[0].message.content

到这里，可能会有人问：既然参考资料都已经把答案写得很清楚了，为什么还需要大模型生成？因为FAQ通常是一条标准答案，但用户的实际表达非常多样化。大模型负责把检索到的多段知识“组织”成一段自然流畅的回答，必要时还能补充一句引导性话术。

4.6 调度主逻辑：能答就答，不能答就转人工

# -*- coding: utf-8 -*- # 文件路径：service.py from knowledge_loader import KnowledgeBase from retriever import Retriever from llm_client import LLMClient class CustomerService: def __init__(self, faq_path): kb = KnowledgeBase(faq_path) self.retriever = Retriever(kb) self.llm = LLMClient() def handle(self, user_query): # 如果用户明确要转人工，直接转人工 if "转人工" in user_query or "人工" in user_query: return "好的，正在为您转接人工客服，请稍候。" # 检索知识库 candidates = self.retriever.search(user_query, top_k=2) # 没有高置信度的召回片段，说明知识库覆盖不到 if not candidates: return "非常抱歉，当前问题我无法直接回答，请转接人工客服处理，避免耽误您的时间。" context_segments = [c["faq"]["answer"] for c in candidates] answer = self.llm.generate(user_query, context_segments) return answer

注意这里的边界逻辑：如果用户都说了“转人工”，系统还非要搜知识库，然后就真的自动回答“转人工请拨打热线”，那就会形成死循环。比较稳妥的做法是：把“转人工”和“投诉”这类意图做最高优先级拦截，不做检索，直接走人工通道。

4.7 启动HTTP服务验证整体流程

# -*- coding: utf-8 -*- # 文件路径：app.py from fastapi import FastAPI from pydantic import BaseModel from service import CustomerService app = FastAPI() service = CustomerService("faqs.json") class QueryBody(BaseModel): question: str @app.post("/chat") def chat(body: QueryBody): answer = service.handle(body.question) return { "question": body.question, "answer": answer } # 启动命令： # uvicorn app:app --host 0.0.0.0 --port 8000

启动后，可以用下面的curl命令进行验证：

curl -X POST http://localhost:8000/chat \ -H "Content-Type: application/json" \ -d '{"question": "退款多快能到我卡里"}'

预期输出大概长这样：

{ "question": "退款多快能到我卡里", "answer": "商品入库质检通过后，退款会在1-3个工作日内原路退回。如果是信用卡支付，到账时间取决于银行处理速度。" }

上面的示例回答中，“如果是信用卡支付”这部分是模型结合上下文生成的补充。这个补充是否有事实依据，必须在真实系统里做二次校验，否则宁可删除。

5. 想让客服不再被吐槽？工程层面先解决这7个问题

5.1 转人工通道必须足够明显

这是所有AI客服最容易翻车的地方。好的兜底设计不是只让机器人说“您可以转人工”，而是真正把用户引导到可用的转人工入口。常见做法包括：

• 在聊天界面上直接放“转人工”按钮；
• 模型识别到“投诉、转人工、找领导”等强意图时直接转人工；
• 限制机器人连续回复次数，超过3轮无法解决就强制转人工；
• 情绪识别模块检测到用户负面情绪强烈时，优先转人工。

5.2 知识库要带版本管理和生效时间

售后政策、活动规则是有时效性的。做RAG客服时，最好给每个知识片段加上“生效开始时间”和“生效结束时间”，检索阶段就过滤掉已失效内容。否则你辛辛苦苦做了向量检索，召回的却是去年的旧规则，责任人反而更难解释。

5.3 回答要可溯源，而不是让大模型自由发挥

在金融、医疗、售后等高合规场景下，AI客服回答必须可追溯。建议在生成回答时，把召回的FAQ编号一并返回给前端或后端，界面可以展示“参考文档：售后政策V2.3”。这样一旦回答出了问题，能够快速定位是哪条知识片段导致的。

5.4 建立自动化评测集

上线前准备一套评测集，里面包含三类数据：

使用LLM作为评判员，把标准答案和模型答案一起发给评判模型打分会比较高效。这样可以发现大多数“胡言乱语”问题。

5.5 关注长尾问题和真实会话分析

很多团队只盯着模型本身，却不去分析历史会话里用户真正在问什么。实际上，客服系统的知识库迭代应该基于用户真实问题的聚类结果：

• 哪类问题占比最高？
• 哪些问题机器人解决率很低？
• 用户在转人工前平均和机器人纠缠了几轮？

如果发现自己80%的会话都是“查物流到哪了”“改地址”，那优先把这两个场景做成自助查询工具，比优化大模型提示词有效得多。

5.6 不要迷信一个大模型解决所有问题

客服系统本身就是多模型的协作场景：

• 小模型做意图识别和槽位抽取，速度快、成本低；
• 向量模型做语义召回；
• 大模型只负责最后一步生成回答；
• 规则引擎负责判断订单状态、会员等级等结构化数据。

5.7 监控、日志和会话回放一个都不能少

AI客服系统上线后，至少要记录以下日志：

• 用户输入原文；
• 检索到的知识片段ID；
• 模型最终输出的回答；
• 用户是否有后续投诉或转人工操作。

只有把这些日志串起来做会话回放，你才能定位“用户觉得被猴耍”最卡的那一个环节究竟是检索召回错、提示词约束失效、转人工失效，还是模型上下文没处理好。

6. 常见问题与排查思路

排查AI客服问题，最忌讳上来就换模型。建议把一次用户会话完整拆开看，按“输入理解→知识召回→答案生成→业务兜底”四段定位，是哪一层出了问题就修哪一层。

7. 最佳实践：面向生产环境的AI客服设计建议

再往前一步，如果把前面这些模块放到生产环境里，可以从下面几个方向继续深化。

7.1 会话状态设计

真实客服场景并不是一问一答，而是多轮对话。比如：

用户：我订单上写的地址错了 客服：请提供订单号 用户：2025010334534 客服：检测到您的订单预计明天发货，您希望改成什么地址？ 用户：改成北京市朝阳区XX路1号 客服：修改成功，稍后我发送确认短信。

这要求系统具备以下能力：

• 在对话中保存槽位信息（订单号、新地址）；
• 调用后端系统接口校验订单状态；
• 对操作类请求做双重确认。

这些并不是LLM单独能完成的，需要对接规则引擎和业务API。工具调用（Function Calling）也是这个链路中的关键环节。

7.2 数据隐私与权限

客服对话往往涉及用户姓名、电话、地址、订单号等敏感信息。在上传用户问题到外部大模型接口前，必须做脱敏处理，比如把手机号、地址替换成占位符，在回答返回后再替换回去。对安全性要求高的企业，建议私有化部署小参数模型。

7.3 评估指标不能只看“机器人解决率”

很多团队把“机器人解决率”作为核心指标，但如果系统只要看到用户不回复就算解决，这个指标会严重失真。更合理的评估维度包括：

• 用户主动评价的满意率；
• 转人工后用户是否重复描述过问题；
• 会话中用户是否表达了强烈负面情绪；
• 同一用户短期内是否反复进入咨询。

7.4 人机协同才是客服体验的最优解

AI客服和人工客服不是替代关系，而是协同关系。AI可以负责三件事：

• 接管高频重复问题；
• 在用户等待人工时先收集必要信息（订单号、问题类型）；
• 给人工坐席提供实时回复建议。

让人工负责复杂投诉、高情绪场景和无法标准化的操作。通过这种方式，企业既能降低成本，用户也不会有“被当猴耍”的感觉。

7.5 从小范围灰度开始

在客服这类强交互场景中，直接全量上线AI是一个高风险动作。比较稳妥的节奏是：

1. 先在夜间或低峰时段开启机器人；
2. 只开放覆盖“售后查询”和“物流查询”两个场景；
3. 每次回答设置“有帮助/没有帮助/转人工”按钮；
4. 每天分析对话日志，人工抽检20条回答质量；
5. 模型回答准确率达到阈值后再开放更多场景。

8. 总结与下一步学习建议

站在用户角度，中消协点名AI客服本质上是在提醒企业：不能把“有了AI客服”当成“做好AI客服”。站在开发者角度，这段话最终要翻译成一个个工程动作：把转人工设计清楚，把知识库管理起来，把回答可追溯，把评测体系建起来，然后再去谈大模型能力多强。

本文梳理了提示词工程、RAG和模型微调在客服场景中的分工，并给出了一个最小可运行的客服Demo代码。如果你准备在企业里真正落地一套AI客服，我建议先别急着微调模型或换更大的模型，而是从自己库里拉出来最近一个月的人工客服会话，认真分析到底哪些问题占用了80%的坐席时间。很多时候，先把FAQ整理成结构化知识库，再接入一套靠谱的检索链路，就已经能解决大半痛点。

如果要继续往下学，可以关注这几个方向：

• 向量数据库选型与索引调优，比如HNSW参数对召回延迟的影响；
• 切片策略优化：怎么把长文档切得既保语义又节省Token；
• 重排模型（Reranker）的使用，以及怎么构造训练数据；
• 用Function Calling把订单查询、物流接口接入对话流程；
• 搭建离线评测集，让客服效果在每次提示词改动后都能量化对比。

实际上，AI客服是一场“细节工程”，而不是单纯的“模型工程”。把用户从“被AI当猴耍”拉回来，靠的不是让AI变得更像人，而是让它更清楚地知道哪些问题该自己答、哪些问题必须交给人类。

如果你正在做相关项目，欢迎留言分享你遇到过的“AI客服神回复”，也可以把报错现象发出来，大家一起帮忙定位卡点。后续我会再写一篇关于客服场景中RAG召回优化与重排模型选型的详细实践，感兴趣的话可以先收藏本文备用。