做客户沟通相关的系统最头疼的一件事就是你永远不知道下一条消息里藏着什么样的情绪炸弹。干了这些年我经手过的客服系统、销售辅助系统、售后工单系统加起来少说也有七八套每次开会都在掰扯同一个问题——话术模板够不够全、人效比够不够高、客户到底满不满意。直到我们把大模型真正接进沟通链路的每个环节才发现过去那些“规则引擎关键词匹配人工抽检”的老方案本质上都是在打地鼠。今天这篇就聊聊我最近落地的一个思路用智能预判、情感识别、自动闭环三个模块把客户沟通这件事从“被动响应”变成“带着预判进入对话”。这套东西不是某个单一功能点而是一条完整的链路改造。它适合已经在用大模型做客服或销售辅助、但觉得效果总是差一口气的团队也适合打算从零搭一套客户沟通智能系统的产品和技术同学。我会尽量讲清楚每个模块的设计逻辑、落地要点、实际踩过的坑以及一套可以直接参考的链路数据流。1. 项目定位与整体设计思路1.1 客户沟通全链路的痛点在哪里先拆一下“全链路”这个词。一次客户沟通从来不是从客服敲下第一句话开始的更不是从客户点了“转人工”那一刻开始的。我把链路拆成四段进线前、会话中、结束后、后续跟踪。进线前客户可能已经看过商品页、逛过社区、写过差评这些行为数据都在会话中客户会表达意图、释放情绪也会在某个节点变得不耐烦结束后我们会统计满意度、解决率但往往等客户打分不满意才去做补救后续跟踪更是靠运营手动筛选名单有的客户明明已经隔着屏幕发火了我们还在按一周前的计划发营销短信。传统方案的问题在于四段之间是断开的。关键词命中了“退款”就弹出一个退款话术根本不看客户是在什么情绪下说“退款”的工单流转靠人工判断优先级判断完还要等主管批满意度回访是系统自动发的发完就结束。整个链路没有记忆没有上下文传递更没有一个能够“基于当前状态预测下一步”的决策中枢。1.2 三个核心模块的定位与协作关系这套系统的核心逻辑是给沟通链路加一个“感知-决策-执行”的循环对应的就是标题里的三个词。智能预判负责的是进线前和会话早期的“感知预判”。它的输入不只是当前这轮对话还包括用户历史订单、历史工单、浏览轨迹、上轮会话的结论输出是一个结构化的预判结果客户进来大概率是为什么事、情绪基线是什么、紧急程度如何、更适合转人工还是自助解决。情感识别负责的是会话中的“动态感知”。客户的情绪是会变化的刚才还在正常咨询可能因为一句回复不对就炸了。情感识别模块持续抓取对话文本、语音特征输出每一轮或每几秒的情绪状态并给出趋势判断——是从平静向愤怒迁移还是已经缓和。自动闭环负责的是“决策执行”。它综合预判结果和情感状态决定下一步动作是让机器人继续应答、切换话术风格、自动升级人工、生成工单并打上优先级标签还是直接触发优惠券补偿、专门话术安抚以及事后是否进入回访名单。更重要的是闭环不只是“做一次动作”而是把动作的结果反馈回系统形成持续优化。这三者的关系是串联而且有依赖的。预判决定了开局策略情感识别在过程中修正策略闭环把策略落地并产生新数据新数据又重新喂给预判模型做下一轮优化。没有情感识别的闭环是盲目的没有预判的情感识别只能看到当下看不到趋势没有闭环的前两者则只是分析报告不具备生产力。1.3 为什么是大模型而不是传统方案我接触过不少团队一开始都想着用老办法升级关键词库扩充、IFTTT规则树、小样本意图分类模型。但这些方案有一个共同的死穴——泛化能力差且难以处理上下文。举个实际例子。客户说“你们这个灯用了一周就忽明忽暗的是不是质量问题啊”老方案可能匹配到“灯”“质量”就命中“质量投诉”意图给出道歉话术。但客户真正想要的可能是判断是否属于保修范围而这句话背后的情绪是“有点担心、但还没发火”。要把意图、情绪、需求、紧急程度四件事同时判断出来传统方案需要维护四套独立的规则规则之间还互相打架。大模型的价值在于三个点。第一它能在同一个上下文里同时完成意图分类、情绪识别、信息抽取、话术生成多个任务省去大量特征工程。第二它对语言变体的容忍度高客户用口语、方言味表达、隐含需求也能抓住要点。第三它可以输出结构化的中间结果比如JSON格式的意图、情绪标签、关键实体方便下游系统做决策而不是只生成一段话。当然大模型不是银弹。它会有幻觉会延迟会烧钱需要一套工程手段去约束。我们整套架构的很多设计本质上都是在“利用大模型的能力”和“限制大模型的自由度”之间找平衡。后面每个模块我都会说到这个点。2. 智能预判模块从被动应答到主动预判2.1 预判的本质是意图与需求的双重识别很多人把预判等同于意图识别我觉得不够。意图只是“客户来干什么”比如咨询物流、申请退款、投诉质量。但预判还要回答更深一层的问题客户的核心诉求是什么、这次接触的历史背景是什么、难度和风险有多大。我习惯把预判拆成四个维度意图类别客户此次接触的主要目标需要覆盖业务主要场景并允许一个会话包含多个意图。需求强度目标是否紧迫。同样是“咨询发货时间”刚下单就来问的客户通常强度低等了十天没发货再来问的强度极高。情绪基线进入会话时的情绪状态。这一项会被情感识别模块接手后续动态跟踪但开局就有一个基线很重要。服务策略综合前三点给出的动作建议比如“推荐自助方案”“转人工并置为高优先级”“触发安抚话术”。这四维输出最大的好处是让下游模块不用再做二次判断。人工客服接到会话时屏幕上已经能看到系统给出的预判卡片而不是打开工单单看历史记录自己猜。2.2 构建预判模型的两种路径我实际落地时对比过两条路各有取舍。第一条路是纯大模型推断。把用户画像、历史会话摘要、当前首轮消息拼进Prompt要求模型返回结构化JSON。优点是灵活性极高新增意图只需要改Prompt里的说明和示例缺点是需要做好输出约束否则模型会返回格式漂移的内容而且上下文太长时延迟和成本都会明显上升。第二条路是大模型加传统分类器结合。先用一个轻量意图分类模型做初筛只把置信度低的样本抛给大模型做二次判断。这样绝大多数会话走快路径解决了成本和延迟问题大模型只处理复杂边界情况。缺点是维护两套模型的成本高初筛模型需要持续标注迭代。我的建议是如果业务意图数量少、样本多、对实时性要求高优先走第二路如果业务变化快、意图边界模糊、团队没有专职算法同学第一路更容易起步。我目前选的是第一路配严格输出校验业务意图经常调整纯规则维护不现实。2.3 预判环节的典型Prompt与数据设计预判Prompt我打磨了很多轮核心思路是“给它看有限但关键的上下文并要求输出固定结构”。先给一段历史摘要而不是把所有历史明文都塞进去再给当前会话开场消息然后给出意图枚举表和输出格式说明最后给几个少样本示例。一段简化后的Prompt长这样你是客户沟通系统的预判引擎。请根据用户历史摘要与当前会话首条消息输出预判结果。 历史摘要 - 用户等级金牌会员 - 历史订单最近30天2笔其中1笔已签收1笔待发货 - 近期工单无 - 上轮会话结论客户咨询过优惠券使用规则已解决 当前首条消息 “我上周买的东西到底什么时候发货系统显示待发货好几天了再不发我就要退了。” 可选意图物流咨询 / 退款申请 / 投诉发货慢 / 活动咨询 / 其他 情绪可选平静 / 轻微不满 / 愤怒 / 焦虑 请只输出JSON { intent: 意图, demand_level: 1-5的整数, emotion_baseline: 情绪标签, strategy_suggestion: 一句话建议, reason: 不超过20字的判断理由 }这里有个很关键的实操细节reason字段。让模型输出判断理由不管是让人审阅还是排查问题都有巨大帮助。我们会把reason和最终客户反馈放在一起作为后续优化Prompt的依据。如果很多误判的reason都集中在某类描述上就能有的放矢地调Prompt。输出校验也值得一提。我们会限制用JSON Schema校验格式不对的直接进入一个低优先级重试队列而不是让下游解析崩溃。重试次数控制在一次两次失败就降级为默认策略并记录日志。2.4 预判模块的落地难点预判最大的坑是数据使用权衡。一开始我们想把全量历史工单明文都塞进Prompt以为信息越全越准结果延迟直接拉到四五秒成本翻了三倍效果反而变差因为无关历史干扰了模型判断。后来改成离线生成会话摘要每次只用摘要加少量关键标签效果稳定延迟降到一秒左右。第二个坑是意图枚举失衡。常见意图占九成长尾意图占一成。如果枚举表写得太细模型容易在长尾意图上乱猜。我的做法是分两级第一级只要是粗粒度意图第二级用策略规则细化不在模型层做细粒度区分。比如模型只输出“投诉”至于投诉的是质量还是物流交给下游用关键词和实体抽取补充。第三个坑是预判结果不能一成不变。客户进来第一句说是“咨询物流”聊着聊着变成了“要退款”如果预判结果始终锁死不更新模型就会变得很僵硬。所以预判模块要和情感识别模块一样在会话过程中做刷新只是刷新频率可以更低比如每五轮或触发特定信号时刷新一次。3. 情感识别模块让系统读懂客户情绪的潜台词3.1 情感识别不等于简单的情绪分类很多方案把情感识别做成一个标签分类器输出“正面/中性/负面”就完了。这在客户沟通场景里远远不够。客户说“你们效率真高啊”可以是真的表扬也可以是等了三天后的讽刺客户说“算了算了不麻烦你们了”可能意味着放弃也可能是暴怒前最后的克制。我落地时把情感识别拆成三个层次情绪标签、情绪强度、情绪趋势。情绪标签做细粒度区分平静、疑惑、期待、不满、焦虑、愤怒、失望。不需要太细七八个标签足够业务使用太细反而让下游决策难以收敛。情绪强度用1到5的数值表示同时输出朝向——同一个标签下的“轻微不满”和“极度愤怒”对应的处理策略完全不同。情绪趋势则用来判断情绪是恶化还是缓和这比单点情绪更重要。3.2 文本情感识别与语音特征的融合我们的会话主要走线上文字但也有电话渠道。电话渠道的通话录音会先转写为文本再做情感分析。纯文本丢失了大量信号——音量、语速、停顿、打断对方说话的次数这些在客户愤怒时都是非常明显的特征。实操中我们会在语音渠道做一层并行特征提取语速每分钟字数、音量均值与波动、平均停顿长度、抢话次数把这些数值作为额外特征交给大模型辅助判断。比如文本说“好的吧”看似无奈但未发火如果语速突然变快、音调上扬模型就更倾向判断为“即将爆发”。这套融合不需要太复杂的多模态模型可以用一个简单的特征拼接提示让模型在分析时参考这些量化指标效果提升很显著。文本端也有不少值得挖掘的信号。标点符号是其中一个——连续感叹号、问号数量、用户快速打字产生的错别字率都可能暗示情绪波动。把这类“表述特征”写进分析提示往往比硬加规则要灵活。3.3 情绪识别的评估指标与阈值设计情感识别是个概率判断问题必须设计清晰的使用阈值否则系统会在“要不要触发人工干预”这个决策上摇摆不定。我们定义了三个决策区绿色区情绪强度1到2系统正常应对按标准流程处理。黄色区情绪强度3或标签为不满、焦虑但强度不高。系统输出安抚话术并在后台标记要求人工在下一轮回复前注意是否要介入。红色区情绪强度4到5或标签为愤怒、失望且强度高。触发强提醒立即转人工或升级工单同时暂停机器人自主回复。这个阈值不是拍脑袋定的是复盘历史会话找出来的分界点。我们会抽样标注一批历史会话的人工处理结果看哪些被客户最终评价为“不满意”然后反推当时的情绪特征分布。阈值定好后还要持续监测误报率和漏报率阈值定太紧大量正常会话被误判为红色区人工被烦死阈值太松红色区漏报又会让投诉升级。情绪识别模块上线后我强烈建议保留一个“人工复核”通道。系统标红并不意味着直接干预客户而是给客服一个弹窗提醒——客服可以选择确认或推翻系统的判断。这些确认和推翻的结果就是最好的评测集至少能积累一两周再逐步放开自动触发。3.4 中文场景下的情感识别陷阱中文客户沟通有非常典型的表达习惯做情感识别时一定要处理否则准确率会很难看。第一是反讽。客户说“厉害厉害你们太厉害了”如果只看字面就是正面实际上很可能是强烈不满。要缓解反讽误判只能借助上下文。比如上文中客户已经两次投诉未解决再说“厉害厉害”基本可以判断为负面。所以情感识别不能只看当前一句至少要带着最近一个完整的话轮上下文进模型判断。第二是礼貌性克制。中年客户表达不满时往往很礼貌会说“麻烦您帮我看看”“耽误您时间了”情绪强度其实不低。单纯看礼貌用语会误判为平静。这种要关注事件本身是否涉及等待时间过长、反复沟通未解决等问题。第三是省略和口语碎片。客户可能发来一条消息只有三个字“那退款”没有主语没有情绪词。这时候没法只看这句话必须依赖预判模块的历史摘要和会话流程状态。所以我们把情感识别设计成会话级模块而不是独立的消息级模块。它接收的是会话片段、预判结果和当前策略返回的是对下一轮行动的综合性建议。4. 自动闭环模块从识别结果到行动落地4.1 闭环的关键不只是自动回复很多人一听自动闭环第一反应是“自动生成回复话术”。但闭环的价值远不止于此。闭环保底要在每个识别结果上都能跟到一个明确的业务动作动作执行完之后还要产生效果反馈让系统知道这个动作起到了什么作用。我把闭环拆成四个动作层话术层根据情绪状态切换回复话术包括安抚话术、解释话术、催单话术等。流程层触发具体业务流程比如生成退款工单、发起物流催办、创建售后单。策略层决策要不要转人工、要不要发放补偿、要不要进入回访名单。反馈层收集客户对处理结果的反馈比如满意度、是否重复进线形成指标回流。四层之间有关联也有冲突。比如客户愤怒时话术层可能想发优惠券安抚但策略层判定客户更在意解决问题本身发券反而显得敷衍。所以闭环模块需要一个统一的决策中心把所有动作都汇总到一个策略列表里再按优先级排序执行。4.2 自动回复生成与人机协同自动回复生成是闭环里最显眼的能力也是最容易翻车的能力。大模型生成话术确实快、确实自然但自由发挥的代价是可能说出不该说的话。比如承诺了不存在的赔付、给出了错误时效、甚至语气模仿没把控好客户会明显感觉到“对面是个机器人”。我的做法是把大模型的话术生成限制在一个事先定义好的“框架模板”内。模板规定段落的顺序先回应情绪、再明确问题、给出可执行的方案、最后留一个缓冲点。模型只负责往框架里填内容不负责决定说什么和以什么节奏说。这样既保留了语言的自然度又避免了超出业务边界。具体到人机协同系统并不会让机器人从头到尾独自应对高情绪客户。更稳妥的模式是机器人负责“开场信息收集和低风控任务”一旦情感识别标黄或标红就把会话转给人工同时把预判和情感分析结果以卡片形式呈现在客服工作台上。人工确认后系统继续在旁辅助实时给出话术建议、工单信息、补偿建议。这种“机器人扛前段人工接关键点系统做全程辅助”的模式上线阻力最小客户体验也最稳定。4.3 工单流转与外部系统对接自动闭环要真正产生业务价值必须和工单系统、CRM、订单系统打通。情感识别到“愤怒级别4”还不够更重要的是自动建一张优先级为P0的工单推送给对应负责人并在SLA超时前自动提醒。工单的内容也要自动填充。传统人工建单要手写问题描述、客户信息、关联订单号一次至少两分钟。自动闭环里模型从会话中抽取关键信息比如“订单号”“期望处理时限”“具体投诉点”直接生成结构化工单。我实测下来工单创建时间从平均三分半降到不到三十秒而且字段完整率比人工填写更高。这里要特别提醒和外部系统对接时责任边界必须写清楚。大模型给出的结构化信息需要走一层校验比如订单号是否符合格式、客户姓名是否匹配、产品名称是否存在于标准库内。校验不通过的字段标黄让人工快速确认而不是直接写进核心系统。任何一步自动化出问题都可能导致线上事故宁可多一步人工确认也不要让幻觉数据污染业务库。4.4 闭环效果的量化评估闭环做得好不好不能只看“这单解决没解决”要看一组能够反映长期效果的数据。我常用的核心指标有四个一次解决率客户在同一会话内问题得到解决的比例。重复进线率客户在解决后短时间内再次联系的比例。满意度均分会话结束后客户主动评价的平均分。情绪升级率会话中从低情绪级别升至红色区的比例。一环是这样用的一次解决率衡量结果重复进线率看“真解决”还是“假解决”满意度看客户主观感受情绪升级率看沟通质量。四个指标一起涨跌才能说明闭环真正在变好。如果只盯着满意度系统很容易变成讨好客户而不敢触碰问题如果只盯着解决率又容易把客户逼到投诉。这些指标上线后要按周做环比分析。我自己踩过的一个坑就是只看月度均值结果某周情绪升级率暴增两倍完全没有察觉。后来改成按天做监控发现异常及时看会话采样问题很快定位到话术模板里的一处措辞过于生硬导致的。5. 实操过程与核心环节实现5.1 一个投诉场景的完整链路演示用实际场景串一遍。假设某电商客户的订单已经“待发货”超过四天客户发来一句“你们到底发不发货不发货就退款别拖着我。”第一条消息进入系统后智能预判模块被触发。它读取离线生成的客户摘要和当前消息输出{ intent: 退款申请, demand_level: 4, emotion_baseline: 愤怒, strategy_suggestion: 优先安抚情绪确认发货时效若超时则开放退款通道并挽留, reason: 订单延迟且客户给出明确退款的最后通牒 }同时情感识别模块也在跑。这句话明确表达不满还存在“不发货就退款”的威胁性表述情绪强度判定为4属于红色区。两个模块的结果合并后自动闭环的响应策略是这样的机器人暂时不直接回答“能不能退款”而是先输出一段安抚话术说明正在查发货时效与此同时系统自动建一张P0工单推送给仓储侧核实发货时间如果仓储反馈确实超时系统触发“退款快捷通道小额补偿券”方案如果仓储反馈今天能发则话术调整为“已催发赔偿实际到账误差”。整个流程里客户没有等太久也没有被踢来踢去。系统把所有判断卡片都展示给人工客服客服在人机协同工作台里点一下“确认方案”后续动作就由系统自动完成。这就是闭环的完整路径。5.2 技术栈与模块接口设计这套系统不挑具体技术栈重点在接口设计。我用的方案是Python服务搭配异步框架三个模块各自独立部署通过消息队列串接事件流避免强耦合。以会话消息进入为起点各模块的事件流大致是这样消息到达 - 消息服务发布事件 事件订阅方 1. 预判模块接收用户摘要当前消息历史片段 2. 情感识别模块接收最近N轮文本语音特征 3. 两个模块各自发布结果事件 4. 闭环决策模块订阅双方结果得到最终策略 5. 策略执行器调用话术服务、工单服务、人工工作台推送服务 6. 执行结果回流到评估模块写入数据仓库模块间通信用的是JSON消息统一包含session_id、timestamp、payload字段。session_id贯穿全链路是后续复盘和指标统计的关键。每个模块必须保证幂等因为消息队列重新投递的时候不能产生重复工单或重复发券。模型调用环节我强烈建议包一层统一的模型网关。网关负责三件事请求超时控制、结果格式校验、降级逻辑。大模型调用偶尔会超时不能让它拖垮整条实时链路超时后网关直接返回一个默认策略比如“转人工并附上已获取的预判信息”保障会话不中断。5.3 上线节奏与灰度策略新系统不能一把梭直接全量上线我的经验是至少分三步走。第一步影子模式。系统跑在真实流量旁路所有预测结果只写入日志不干预任何会话。这一步持续一到两周主要用来验证数据流是否通畅、模型输出是否稳定、是否有明显误判。虽然不干预客户但模块之间的接口问题在这里都会暴露。第二步人工辅助模式。系统开始把预判和情感分析结果推送到客服工作台但客服可以选择不看。这一步的目的不是验证模型而是验证客服工作流程是否被打扰。如果推送卡片位置不合理、信息量过大客服会直接忽略甚至投诉系统打扰这些反馈要在这一步内解决。第三步半自动化模式。选择低风险场景开启自动闭环比如简单的物流咨询、订单查询。高风险场景仍然保持人工确认。等低风险场景稳定运行一段时间各项指标没有恶化再逐步扩大自动范围。灰度期间最好是按渠道或者按用户分层切流比如先只处理某个渠道的售前咨询不碰售后投诉。这样即使出现了最坏情况影响面也可控。我在一个项目里曾经急着全量放开结果某天晚高峰系统把大量中等情绪客户全部标红并转人工客服团队瞬间被打爆那次教训之后再没犯过同样的错。6. 常见问题与排查经验6.1 预判不准的常见原因预判结果跑偏我总结下来大部分原因不是模型能力不够而是输入信息不完整或者提示设计不当。一个高频问题是会话摘要过期。如果客户的订单状态变了、工单已经处理完但离线摘要没刷新模型就会基于过时信息判断。排查方法很简单在预判模块返回的reason里看判断依据是否引用了一条旧状态。这类问题要从摘要更新机制解决而不是调Prompt。第二个高频问题是意图枚举冲突。比如“我要退货”和“我要退款”业务上可能是两条链路但客户表达时常常混用。这时候强行让模型区分两个意图反而容易乱猜。我建议在枚举设计阶段就把业务相似意图合并把细分的动作交给下游规则减少模型层的判断负担。第三个问题是长文本截断不合理。有些历史会话特别长如果只取开头部分可能把最终处理结果漏掉。我的做法是摘要生成时就要求覆盖“事件背景-处理过程-最终结果”三段然后确保送入模型时包含最近两轮对话原文。截断过长导致的信息缺失要靠摘要结构来兜底。6.2 情感识别误判的排查情感识别误判最常见的是把“冷静的愤怒”判成中性。有些客户表达极其克制用词完全正常但句子里充满了“再一次”“还是”“又”这类带有积累感的词。比如“这是第三次找你们了”表面平静实际情绪值已经很高。如果你只做单句分类判断结果一定是中性。我们修复方式是在情感识别Prompt里显式加入“积累感”检测指令如果消息中包含表示重复、等待、先后多次尝试的表述即使字面情绪平淡也应上调情绪强度。这一步单独靠数据标注会慢很多用大模型的推理能力来补反而是最省力的路径。另一类是插科打诨式表达被误判为愤怒。有些客户喜欢用夸张语气“你们这是要上天啊”实际并没有很生气。这类判断必须回到会话上下文如果后续消息还提到具体问题并愿意沟通就不是愤怒如果不再回应、或开始大量使用短促否定才是真愤怒。情绪识别模块应该给出一个置信度提示让下游决策对低置信度的标签保持怀疑。6.3 成本与延迟的平衡成本问题是大模型落地的头号敌人。全量实时调用大模型会让人心惊肉跳。我的策略是分级调用绿色区轻量规则优先不调大模型黄色区调用小参数模型处理只有红色区或复杂越界场景才调用大模型做深度分析和生成。这个策略把整体月成本压到纯大模型方案的35%左右同时核心体验并没有劣化。延迟方面用户感知最明显的是首句回复速度。预判模块就算只要一秒钟放在客户发消息到机器人回复之间也会觉得慢。我们的做法是首句先用模板策略秒回预判和情感分析在后台跑等结果出来再调整后续话术。这样客户第一反应是“有人理我了”两秒内回复其实是对服务体验的一个巨大加分项。接口超时也要做分级。模型调用如果超过2秒系统不再等待直接走降级策略。这个降级策略在预判模块是使用默认意图和中性情绪在情感识别模块是维持上一轮判断在闭环决策模块是默认转人工复核而不是擅自决定一个高风险动作。6.4 数据安全与合规的底线客户沟通数据高度敏感涉及个人信息、订单信息、情绪状态任何一环出问题都是大事故。我们做这套系统时在数据安全上花了和模型优化同样多的力气。核心原则是“最小化使用”能脱敏的字段必须在进入模型前脱敏比如姓名、手机号、详细地址直接用占位符替换模型日志里不记录原文只记录经过脱敏的文本和结构化标签。模型服务的调用建议走内网网关禁止直接暴露公网接口。Prompt和模型的输入输出要定期审计尤其要防止通过Prompt注入获取系统提示词或诱导模型输出内部逻辑。客户会话数据的存储要有明确的保留周期超期自动清理不要因为“以后可能有用”就无限留存。合规不是上线前的补丁而是架构设计的一部分等到出问题再补就来不及了。在实际操作中我们还养成了一个习惯每次Prompt迭代都做一次脱敏自查保证不会把敏感字段拼进提示。这个习惯看起来慢但长期看是给自己省事否则任何一条敏感信息进了模型日志后期清洗成本远高于事先预防。7. 结尾分享一点自己的体会这套系统做下来我的最大体会是“别神化大模型也别小看工程”。大模型确实让智能预判、情感识别、自动闭环这些能力从“实验室功能”变成了“可落地系统”但真正决定成败的往往是那些不太性感的细节Prompt里的枚举表怎么设计、JSON输出怎么校验、工单字段要不要过一道确认、灰度上线分几步走。单独拿出任何一项都不难难的是把它们缝合成一条可靠的链路。再分享一个小技巧每次线上出现误判不要急着改模型先看reason字段和日志里的上下文。大多数问题都能定位到某个输入信息缺失或流程设计冲突改Prompt反而是最后的选择。还有给每个模块都留一个“人工纠正”的人口让客服能一键反馈系统判断错误这些反馈是持续优化最真实的数据来源。这套系统后续还能往更多方向扩展比如基于历史会话摘要做更长期的用户风险分、自动生成客服话术质量报告、把满意度预测嵌入到每次回复前。每一步都不需要推翻现有架构在现有闭环上增加新的观察维度和动作输出就行了。希望这篇分享能给正在做客户沟通智能化的团队一些实际参考少踩几个我踩过的坑。