生成式AI实战：从需求拆解到批量生成电商客服话术全流程

先交代个背景：这个《生成式人工智能实战》系列前四篇，我们聊过环境搭建、模型基础选型、文本生成任务的调参思路，还有多模态模型在图片理解上的坑。不少读者反馈说前面的内容偏“单点”，看完之后能跑通Demo，但一到真实业务场景，还是不知道怎么把模型能力串成一条完整的生产链路。所以这一篇我把它定位成“端到端实战”——从需求拆解、技术选型、代码实现到评估上线，完整走一遍，看看生成式人工智能到底怎么在真实项目里落地。适合两类人看：一是已经跑通API调试、想往业务落地方向走的开发者，二是正在做技术方案选型、需要给团队一个可执行路径的产品或技术负责人。这篇不聊概念，不贴宣传话术，全部是实操中的选择和取舍。

我选的实战场景是“电商客服话术批量生成系统”。之所以挑这个，不是因为技术最炫，而是它足够典型：有明确的输入输出结构，有上下文约束，有风格要求，还要能批量处理、能评估质量、能接进现有工作流。这些都是生成式人工智能在实际业务里最常见的诉求。如果这个场景你能完整拿下来，换成写邮件、写周报、写营销文案，思路是通用的。

1. 实战项目设计：先想清楚“生成什么”和“谁来用”

1.1 业务需求拆解：话术系统不只是“让AI写句话”

很多人在做这类系统时，第一个念头就是要找个厉害的模型，然后赶紧接上API开始生成。但我负责任地讲，这一步往迈得越急，后面返工越狠。真实业务流程里，一个客服话术需要满足非常结构化的约束，不能由着模型自由发挥。

我们先拆一下需求。以电商售后场景为例，一条合格的客服话术至少包含这几个要素：

• 客户问题类型识别：退款、换货、物流延迟、商品破损、价保规则、发票开具，不同类型对应完全不同的应答策略。
• 情感基调控制：客户语气激烈时，话术要先共情再给方案，不能一上来就摆规则。
• 业务规则注入：例如退款时效是48小时、某些类目不支持无理由退换，这些信息必须嵌入生成结果，模型编造规则是绝对不能接受的。
• 渠道适配：同一问题，在旺旺上的回答可以长一些，在短信通知里就必须压缩到几十字。
• 合规红线：不能承诺做不到的事情，不能出现绝对化用语，不能泄露其他客户信息。

所以说，所谓“话术批量生成”，本质上是把“问题分析—策略匹配—内容生成—规则校验”这一连串动作自动化。AI生成只是中间的一环，而不是全部。想清楚这一点，后面所有技术选择都会顺理成章。

1.2 为什么选择“文本生成+知识库检索”的组合方案

前几篇我们反复强调过一个观点：不要指望一个模型记住你所有的业务规则，它做不到，也不该靠它做到。模型的能力在于语言组织和逻辑表达，而业务知识应该外置。这正是检索增强生成（RAG）的核心思想。

简单解释一下RAG的工作方式：拿到用户问题之后，先从你维护的知识库（售后政策、产品说明、工单记录等）里检索出相关片段，把这些片段和原始问题一起拼进提示词，再交给模型生成回复。好处立竿见影：

• 规则更新不需要重新训练模型，改知识库文档就行；
• 模型不会“凭空编造”，因为答案素材是你给的；
• 每次生成都有可追溯的引用来源，出了问题能倒查。

我见过不少团队在这上面走弯路，直接把几千条业务规则全文塞进提示词。结果有两个：一是超出上下文窗口被截断，二是模型被海量信息干扰，反而抓不住重点。正确做法是把规则拆分成小块文档，用向量检索先筛出最相关的三五条，再让模型回答。实测下来，这种方式不仅成本低，效果也稳定得多。

1.3 明确技术边界：哪些模块必须自己做，哪些交给服务商

开始写代码之前，先划清楚技术边界，这能帮你省下大量的试错时间。整体架构我拆成四层：

• 展示层：一个简单的管理后台，运营人员批量导入客户问题，查看生成结果，手动微调后导出。
• 处理层：负责数据清洗、问题分类、批量调度和结果评估，这部分逻辑必须自己写。
• 生成层：调用大模型API，负责最终的文本生成。
• 知识层：向量数据库，用来存储和检索业务规则、历史优质话术。

这里我要重点强调一句：不要把精力浪费在“自己训练一个基础模型”上。除非你的场景极度垂直、数据量极大、预算充足到可以忽略成本，否则使用成熟的商用API或开源模型服务，都是性价比更高的选择。生成式人工智能的实战功夫，在于怎么把通用模型塑造成适合你业务的专业助手，而不是从零造轮子。

2. 技术选型与关键参数：决定生成质量的隐藏细节

2.1 模型选择的三个维度：质量、成本、可控性

现在市面上的大模型API越来越多，选型成了一个新的难题。我在几个项目里实测下来，建议从三个维度做评估：

质量维度，不是看公开榜单的分数，而是拿你自己的业务数据做测试集，对比不同模型在你这些具体问题上的表现。公开榜单一测的是通用泛化能力，跟你的客服场景未必正相关。我一直留着一份50条左右的实测样本集，覆盖高频问题、复杂问题和边界问题，每次换模型先跑一遍这份样本。

成本维度，不要只看单次调用的单价，要算综合成本，包括模型输出不稳定导致的后期人工修改成本。有些便宜模型看似节省，但生成结果有一半不能用，人力来回改反而更贵。

可控性维度，也就是系统稳定性和服务可用性，包括API响应速度、并发上限、限流策略、敏感内容审核机制。这往往是被忽视的一点，但真实生产环境里，一个下午的接口不稳定就足够让整个业务方失去耐心。

2.2 提示词工程：把“人话需求”翻译成“模型指令”

很多人写提示词，就是把业务需求原样丢给模型，比如“帮我给客户写个退款回复”。这种做法不能说错，但离“可用”还有十万八千里。实战中我的提示词模板基本遵循以下结构：

• 角色设定：你是某电商平台的售后客服，处理用户的退款申请。
• 任务描述：基于以下客户问题、业务规则和对话背景，生成一条回复话术。
• 输入数据：客户问题原文、检索到的业务规则片段、客户情绪标签。
• 输出要求：字数控制在100字以内，先共情再给方案，引用具体规则编号，禁止承诺超出规则的内容。
• 格式示例：给出一到两个高质量范本，比十句抽象描述都管用。

这里要特别强调“少样本示例”的作用。大模型的指令遵循能力虽然越来越强，但在格式控制上，给示例比给描述稳定得多。我每次设计提示词，都会先手动写两到三个不同场景下的标准答案放进模板，效果提升非常明显。这属于投入产出比最高的优化手段，没有之一。

2.3 关键参数调节术：温度、Top-p、max_tokens怎么配

提示词之外，API里的几个参数对结果影响也很大。这部分经常被忽略，但恰恰是区分“调通”和“调好”的分水岭。

温度（temperature）控制的是随机性。客服话术这种偏事实性的任务，温度建议设在0.2到0.4之间。温度过高，模型会开始“发挥”，编造折扣信息、虚构退换货政策，这在客服场景是事故级别的错误；温度过低，回复会显得死板，但安全第一。我在批量生成场景里常用0.3，算是质量与稳定性的均衡点。

Top-p（核采样）作用和温度类似，控制候选词的范围。实操中我一般保持默认或把它和温度当一个组合来调。如果温度已经调到0.3还不稳定，可以把Top-p从0.9拉到0.8试试，但两条曲线同时动容易失控，建议一次只调一个。

max_tokens要按需设置。客服话术短文场景，100到200就够。设置得太长，模型会在结尾不断追加废话，既浪费token又影响解析；设置得太短，又会导致回复戛然而止。先看业务需要的最长字数，留出两到三倍余量，这样比较稳。

还有一个容易踩的坑：API返回的格式解析。现在很多模型支持JSON结构化输出，建议直接开启，让返回结果里带上“话术内容”“引用规则”“风险提示”这些字段。千万不要让模型输出纯文本再自己写正则去扣，那种做法在真实生产环境里会把你整疯掉。

3. 实操过程全记录：从输入到输出的完整实现

3.1 环境准备与依赖清单

正式开始之前，先把环境准备好。我用的是Python 3.10，核心依赖就三个：调用API的官方SDK、做向量检索的库、轻量级的Web框架。如果只是命令行跑通流程，连Web框架都可以先不装。

这里多提一句，向量数据库的选择要慎重。小规模验证阶段用轻量方案就够，但一旦数据量上来，检索速度会断崖式下跌。我个人的经验是：项目起步求快，先用最基础的工具验证链路跑不跑得通；确认可行之后，再按数据规模决定是否引入重型的向量库。很多团队第一个错就是把架构设计得过于复杂，结果连Demo都跑不顺畅。

用到的核心配置如下：

# 大模型API配置 MODEL_NAME = "your-model-name" API_KEY = "your-api-key" API_BASE = "https://your-api-endpoint" # 生成参数配置 GENERATION_CONFIG = { "temperature": 0.3, "top_p": 0.9, "max_tokens": 500, "response_format": {"type": "json_object"}, # 开启结构化输出 }

整体代码结构我习惯分四个模块：数据预处理、知识库检索、提示词组装、生成与评估。这样每块都能单独测试，出问题也好定位。

3.2 数据准备：构造第一批“种子数据”

数据是生成式AI项目最容易被忽视的环节。很多项目跑起来效果差，不是模型不行，是喂给模型的数据不行。客服话术项目需要准备的数据有这几类：

客户问题样本：从历史工单里挑出200到500条覆盖各场景的真实问题。没有历史数据的情况下，可以先凭业务经验人工构造。每条问题尽量标注场景标签，例如“物流”“质量”“退款”，方便后面做批量评估。

业务规则文档：把客服手册里的规则拆成一条条独立的文档片段，每条以“适用场景+规则内容+常见禁忌”的结构整理。比如“七天无理由退货：商品保持完好，不影响二次销售。禁忌：不得承诺超出法规的退换期限。”

优质话术样例：从历史应答里挑出客户满意度高的回复，人工加工成标准范本，作为少样本示例使用。这部分量不用大，每个场景准备3至5条即可。

数据质量直接决定最终生成质量，我见过太多人在这上面贪快图省事，随便丢几篇文档进去，结果生成的话术连基本的业务逻辑都对不上。这个环节一定要投入足够的时间。

3.3 知识库检索：让模型“带着答案说话”

数据备好之后，先把业务规则文档做向量化，用文本嵌入模型把每一条规则转成向量，存入向量库。这个步骤本身不复杂，真正要用心的是两个细节：

文本切分策略。规则文档要按语义完整性来切，不能简单按固定字数硬切。比如“退款时效说明”和“退款申请条件”是两个不同的主题，如果硬切到同一个片段里，检索时就会互相干扰。我实际操作中会先按标题或段落边界做粗切分，再对超长段落做二次切分。

检索Top-K的选择。给模型喂几条规则片段最合适？我实测下来，3到5条是比较合理的区间。只给1条，覆盖面不够；给超过5条，模型容易被冗余信息干扰，反而不利于精准回答。这个值跟你知识库的质量有关系，建议在自己数据上做几组对比测试再定。

检索过程有一个经验技巧：如果客户问题本身很短，只有十几个字，直接拿它做检索向量效果往往不好。我会先让模型把问题做一次扩展重写，补充完整语义之后再去做检索，命中率能提升不少。比如“怎么还不发货”改写为“用户咨询订单超过48小时未更新物流信息，询问发货进展及预计送达时间”，再进行向量检索，命中结果会精确非常多。

3.4 核心实现：组装提示词并调用模型

检索到相关规则后，下一步就是按模板拼提示词。以下是我在实际项目中使用的提示词模板结构：

def build_prompt(question, rules, examples, sentiment): system_prompt = ( "你是一名电商平台的资深客服，负责处理售后咨询。\n" "你的回答需要符合以下要求：\n" "1. 语气礼貌、专业，先共情后解释。\n" "2. 必须严格依据提供的业务规则回答问题，不得编造。\n" "3. 回答控制在100字以内，条理清晰。\n" "4. 输出JSON格式，包含reply、rule_ids两个字段。\n" ) user_content = f"客户问题：{question}\n客户情绪：{sentiment}\n" user_content += "相关业务规则：\n" for rule in rules: user_content += f"- [{rule['id']}] {rule['content']}\n" user_content += "参考话术示例：\n" for ex in examples: user_content += f"- {ex}\n" user_content += "请根据以上信息生成客服回复。\n" return system_prompt, user_content

这个模板的精髓在于：通过结构化字段把“问题—规则—示例”单独分开，模型就能清楚地知道什么素材是生成依据，什么格式是输出要求。如果你把规则和问题混在一起写，模型往往把握不住优先级，生成的内容质量就不可控了。

调用模型时，把温度、Top-p这些参数配置好，然后把上面的system_prompt和user_content传给API。返回结果直接按JSON解析，拿reply字段作为最终话术。整个过程没有魔法，关键就是你把准备工作做得多细致。

3.5 批量调度与容错：生产环境的真实考验

单条生成跑通后，接下来是批量场景。假设业务方一次性导入500条客户问题，你不能简单说“循环调用500次API”，那样大概率会踩到限流和数据异常两个坑。

我常用的做法是加一个批量调度层，核心逻辑包括：

分批执行。每批10到20条请求并发，批次之间留出间隔，避免触发API限流。具体的并发数，取决于你所使用服务的限制说明，建议从低到高慢慢加压测试，找到那个既快又稳的阈值。

自动重试与退避。网络抖动和上游超时是常事，对失败的请求做指数退避重试。比如第一次失败等2秒，第二次等4秒，最多尝试3次。很多莫名其妙的问题，重试一次就好了。

结果缓存与幂等。同一问题文本如果之前生成过，直接从缓存里取，不重复调用API。这不仅省钱，也保证同一问题在不同批次里的回复一致，避免运营人员发现相同问题前后答案不一样。

异常隔离。某一条数据格式异常导致解析失败，不应该中断整个批次。把这类失败单独记录下来，生成一份失败列表，最后统一处理。

我见过不少团队在Demo阶段一切正常，一上批量就各种超时和乱码，核心问题就是缺了这层容错设计。生成式AI项目跑进生产环境，拼的不是模型调得多好，而是工程细节做得多扎实。

3.6 质量评估：不要凭感觉判断“好不好”

生成完500条话术，怎么评估质量？拍脑袋看几条、觉得“还可以”，这种评估方式在开发阶段凑合能用，但没法支撑上线决策。实战中我至少会做三道检查：

第一道：格式合规检查。程序自动校验每条输出是否符合JSON格式、长度是否在限制内、是否包含必需字段。这一步即使最简单，也能筛掉大量低级问题。

第二道：规则引用检查。把生成结果里引用的规则编号，跟检索阶段返回的规则做比对，确认模型引用了正确的规则。这里可以设置一个规则：生成内容涉及的规则必须是知识库中存在的规则，凡是出现规则库之外的数字编号或条款，直接标记为高风险。

第三道：内容质量人工抽检。抽检比例不用太高，10%到20%即可，但抽样要分散到各个场景。人工检查登录时重点看：逻辑是否通顺、规则是否用对、语气是否恰当、是否存在过度承诺。

三道检查做完，把通过率统计出来，你就有了一个可以量化对比的基准线。这不仅能帮你评估本次生成的质量，也方便你做后续调优时进行A/B对照。我建议团队花半天时间把评估流程固化下来，后面每一次调整提示词、换模型，都用同一套评估方案复测，这才是科学的调优方式。

4. 踩坑记录与排查指南：哪些问题真的会咬人

4.1 明明规则写得很清楚，模型还是“自由发挥”

这是我在几个项目里反复遇到的情况：业务规则白纸黑字写着“生鲜类商品不支持七天无理由退货”，模型生成的回复居然是“生鲜类商品支持七天无理由退货”。起初我以为是模型理解能力不够，后来排查发现根因在检索环节——相关规则根本没被检索出来，模型没看到这条素材，只能凭自身记忆作答。

解决思路有两个方向。第一，优化检索环节，确保生鲜类相关问题一定能命中对应的规则片段，这里就需要你在测试时把这类场景的检索结果单独打印出来检查。第二，在提示词里加一句强约束：“你只能依据提供的业务规则作答，如果规则中没有相关信息，请明确说明‘该问题需要人工核实’，不得自行推断。”后一句话能明显降低模型编造的概率。

4.2 批量生成时的“答非所问”

有一次测试时，我发现同批次里连续几十条回复的内容高度雷同，都是泛泛的安抚话术，没有针对具体问题。检查之后定位到根因：上下文管理出错了。我维护的是一个共享的历史记录对象，线程之间相互覆盖，导致模型看到的问题串了。排查方法很简单，把API请求的入参日志打出来，逐条核对客户问题是否与生成结果对得上。

这个问题提醒我一点：在批量场景中，每个线程必须使用完全独立的上下文对象，绝对不能共享任何可变状态。还要给每一条请求分配唯一的请求ID，从输入到最终输出全链路追踪，排查问题时能直接按ID定位。

4.3 模型“幻觉”出的承诺，怎么拦下来

生成内容里偶尔会出现“我们将在24小时内为您补发”这类过度承诺，但实际业务规则是48小时。这种问题靠提示词约束很难完全避免，毕竟模型本质是在做概率预测，偶发性的越界无法根治。我采取的措施是双保险：

第一层，生成阶段靠强约束提示词，尽量压低概率。第二层，生成之后增加一道规则校验程序，用正则把“X小时内/天内”“X元补贴”“免费退换”这类风险表述全部扫出来，命中就标记为需要人工复审。这种“AI生成+程序校验+人工兜底”的三角结构，是我现在处理高合规需求场景的标准配置。不要把安全责任全押在模型身上，工程手段一定要兜住底。

4.4 常见问题排查速查表

最后再分享一个我在这个项目中体会很深的事情。整个系统跑通之后，最大的瓶颈其实不在模型层，而在知识库维护上——业务规则一变更、新品类的售后政策一更新，知识库里对应的文档就要同步刷新。后来我给运营团队做了一个上传文档直接覆盖向量库的功能，让他们自己维护知识内容，整个系统才真正脱离“演示品”的状态。生成式人工智能的实战，拼的是把你手里的每一条业务逻辑都梳理得足够清晰，模型只是那个最后替你说话的人。