当大模型遇上客服场景，技术选型、工作流设计、知识工程……每一步都是挑战。而测试开发，正从“质检员”走向“质量共建者”。
前言
在线客服工作重复性高，降本增效一直是客服工具的核心价值。随着大模型驱动的智能客服系统兴起，传统客服工具正在经历深度变革——产品能力提升、用户体验优化，同时搭建与运维成本大幅下降。
某电商SaaS服务商自大模型兴起之初便开始关注这一领域，经过近一年的探索，从“黑客马拉松”的灵感到稳定运行的AI客服系统，走出了一条从0到1的实践之路。
本文将从研发与测试开发的双重视角，回顾这一历程中的核心要点、关键决策，并重点补充测试开发在AI项目中的具体工作示例，希望能为同样在探索AI落地的同行提供一些参考。
一、从0到1的实践路径
1. 平台选型：从智能体平台到工程化
验证期：使用Dify这类智能体开发平台快速搭建MVP，验证PMF。迭代效率高、工具集成好。
成长期：采用“Dify + 工程化”混合架构。核心、高并发的流程（如知识召回）放在自研系统，非核心流程保留在平台。
成熟期：当性能、稳定性、可定制程度无法满足需求时，全面工程化。可利用工具（如Spring AI Alibaba Studio）将Dify上设计的逻辑导出为标准工程代码。
💡 经验：初期速度优先，后期稳定性和可控性优先。不要一开始就追求完美架构。
2. 模型选择：大脑不能随便选
- 选对模型 > 调优Prompt：花几天优化提示词，可能不如换一个模型直接解决问题。
- 评估能力：从人工验证逐步过渡到使用langfuse等评测工具。
- 谨慎更换模型：后期更换模型成本高（效果评估、提示词调整）。
- 输出越少，速度越快：能用常量就不用JSON。
3. Workflow vs Agent：先保守再激进
Agent具有高度自主性，但结果确定性、性能不占优势。项目初期选择Workflow，搭建稳定、可控的流程。从工作流入手，逐步解决效果、成本和可控性问题，再考虑引入Agent能力。
4. 工作流设计与迭代
V1.0：用一个模型处理所有事情（意图识别、问题改写、情绪识别等），快速上线。
降低成本：将意图识别的模型从GPT-4.1切换为Qwen，拆分节点；自行维护全局变量作为历史对话信息，缓解幻觉。
提升承接率：售前与售后分开流程（回复风格、所需知识不同），避免互相干扰。
意图识别+分发策略：宁可不答，不能答错。这种保守做法保证了准确性，但也带来了承接率瓶颈。后续需逐步拆分节点、优化意图识别。
5. 上下文工程：信息不是越多越好
- 信息获取：从静态到动态，从文本到视觉。多模态提取商品信息，实时查询库存/物流状态，历史对话挖掘QA对。
- 筛选提纯：根据入口场景定向检索（商品详情页只查该商品）；语义相关性过滤 + 权重加权。
- 信息组装：采用结构化XML方式组织知识，配合提示词定义知识优先级，显著减少幻觉。
6. 知识工程
- 商品知识：预学商品信息（多模态提取） + 实时查询（状态/库存）。
- 历史对话知识：后期才取得进展——将工程化切回Dify便于调试，按咨询维度分析历史对话，利用RAG去重、分类。
- 文档知识：chunk_size=600，chunk_overlap=100，平衡完整性与信息密度。
7. 评测与反馈
评测体系需覆盖：评测对象、数据集、指标、反馈优化机制。
- 评测对象：业务场景（不同入口）、流程（端到端/单节点）、知识质量。
- 评估指标：结合人工判断 + 评估器（相似度计算）。
- 评测数据集：上线前从历史对话提取+人工构造；上线后筛选Goodcase/Badcase入库。
- 反馈优化：构建“问题识别→根因分析→优化迭代”闭环。
二、测试开发在AI项目中的新角色与具体工作示例
在传统软件研发中，测试开发围绕确定性展开——预期输出明确，结果可复现。但AI项目（尤其是大模型驱动的Agent/Workflow）具有不确定性、开放性、场景多样性，测试开发的职责发生了本质变化：从“找Bug”到“质量共建”，从“用例执行”到“评测体系设计”。
以下是测试开发在AI客服项目中可以承担的具体工作示例：
示例1：构建AI评测数据集
背景：模型更换或提示词调整后，如何快速评估效果变化？需要一套高质量、可复用的评测数据集。
工作内容：
- 从线上历史对话中抽取典型场景（售前咨询、售后纠纷、闲聊、边界情况等），人工标注正确答案。
- 构造对抗性样本：如包含错别字、口语化表达、多轮指代消解等问题。
- 建立版本化数据集管理：每次评测使用同一版本数据集，保证对比公平性。
# 伪代码示例：评测数据集结构
test_set = [
{
"input": "这个商品有运费险吗？",
"context": {"page": "商品详情", "user_history": []},
"expected": "运费险说明：部分商品赠送，具体以订单为准...",
"tags": ["售后", "物流政策"]
},
# 更多用例...
]
示例2：自动化评测工具开发
背景：人工评测效率低，无法覆盖大规模回归场景。
工作内容：
- 开发离线评测脚本，批量运行测试集，调用AI客服接口获取回复。
- 集成多种评估器：
- 语义相似度（如BERTScore、BLEURT）对比回复与标准答案。
- 关键词命中率：确保核心信息（如退货期限、价格）不丢失。
- 格式校验：JSON结构、必填字段等。
- 生成评测报告：准确率、召回率、Badcase聚类分析。
# 伪代码示例
def evaluate(test_set, model_api):
results = []
for case in test_set:
response = model_api.chat(case["input"], case["context"])
score = semantic_similarity(response, case["expected"])
results.append({"case": case["input"], "score": score, "response": response})
return aggregate_report(results)
示例3：Badcase闭环流程的工程落地
背景：线上出现Badcase（答错、幻觉、拒答等），需要快速定位根因并推动修复。
工作内容：
- 搭建Badcase追踪系统：运营/客服标记Badcase后，自动录入数据库。
- 设计根因分析辅助工具：
- 重现对话上下文，对比召回的知识片段。
- 标注问题类型（意图识别错误、知识缺失、上下文过长等）。
- 建立优化闭环看板：每个Badcase关联到具体的模型版本/知识库版本/流程版本，修复后自动回归验证。
示例4：Prompt版本管理与测试
背景：提示词频繁迭代，不同版本之间效果差异大，回滚困难。
工作内容：
- 建立Prompt仓库（Git + Dify API），每次变更提交MR，触发自动化评测。
- 设计Prompt测试用例：覆盖边界条件、敏感词、多语言等。
- 对比不同Prompt版本的输出稳定性：相同输入多次调用，检查结果一致性（避免随机性过大）。
示例5：上下文工程的质量验证
背景：信息过载导致幻觉，信息不足导致答非所问。上下文的“信噪比”需要量化验证。
工作内容：
- 开发上下文检查工具：输入一个对话，输出实际送入模型的知识片段列表。
- 验证定向检索准确性：从商品详情页进线，检查召回的知识是否只包含该商品（而非全店）。
- 测试结构化组装效果：对比相同内容用纯文本 vs XML格式，模型的幻觉率变化。
示例6：知识库质量巡检
背景：商家上传的文档质量参差不齐，图片信息可能存在错误（如规格图与文字矛盾）。
工作内容：
- 编写自动化脚本，定期扫描向量数据库中的知识片段：
- 检测重复片段、空片段。
- 校验商品规格与多模态提取结果的一致性（如颜色、尺寸枚举值对比）。
- 模拟用户咨询覆盖：对每个商品，自动生成常见问题（如“有红色吗？”“包邮吗？”），验证回答是否正确引用知识源。
示例7：性能与稳定性测试
背景：智能体平台（如Dify）的Python代码节点可能耗时40-100ms，实时性无法接受。
工作内容：
- 压测核心链路的P99延迟：知识检索→模型调用→结果解析。
- 对比自研工程化与平台方案的耗时差异，给出迁移阈值建议。
- 测试模型并发下的Token消耗与限流策略。
三、总结与展望
AI客服的落地，不仅是技术栈的升级，更是研发模式与思维方式的深度变革。对于测试开发而言，这是挑战也是机遇：
- 从被动验证到主动共建：测试开发不再是最后一道关卡，而是深度参与评测体系、数据建设、工具开发。
- 从单一技能到复合能力：需要理解大模型特性、Prompt工程、RAG原理，同时保持工程化思维。
- 从用例执行到质量闭环：建立“评测→优化→再评测”的自动化循环，让质量可度量、可演进。
未来，我们将重点聚焦：
- 从Workflow到Agent协同：引入自主性能力，应对更复杂场景。
- 深挖历史对话与商品知识：让沉淀的数据成为AI进化的驱动力。
- 构建AI原生协作体系：Prompt评审、指标对齐、产研测共同迭代。
宁可不答，不能答错——这是AI客服的底线，也是测试开发守护质量的原则。
AI浪潮之下，智能客服的演进没有终点。希望本文能为正在探索AI落地的同行提供一些可落地的思路，尤其是测试开发伙伴们，让我们在AI质量保障的新战场上，创造更大的价值。
