1.1 客服工单分类场景与提示词的角色定位
我做了快两年客服工单自动化的项目，最开始那会儿，团队里很多人觉得“分类提示词”就是随便写一段话，把工单内容丢给模型，让它输出一个标签就完事了。真正上手才发现，远不是这么回事。客服工单分类这个场景本身有很强的特殊性：文本短、口语化严重、信息残缺、用户情绪混杂，很多时候客户投诉的内容跟真正的问题根因之间隔了三四层。提示词在这个场景里扮演的角色，更像是一个“翻译官”加“分诊台护士”，它要把客户那种带着情绪化的、不规范的表述，翻译成团队内部能理解的问题类别，同时判断这个问题该丢给哪个组、以什么优先级处理。
我在实际项目里踩过的坑是，一开始只关注“让模型输出标签”，忽略了模型对业务上下文的理解能力。同样一句“我的钱怎么还没到”，在退款场景、转账场景、账单异常场景下对应完全不同的分类结果。提示词要承担的不只是分类动作，还要把业务场景的隐含信息一并注入进去。你现在看到的很多工单分类提示词模板，看起来结构差不多，真正拉开效果差距的往往是提示词里那几句对业务语境的描述——客户是在什么产品路径下产生的这个问题、之前是否有过交互、当前服务承诺是什么。
还有一点我觉得特别关键，就是别把提示词当成一个孤立的“指令包”来看。它实际上嵌在整个客服工作流里，上游连着工单采集和清洗，下游连着分派、响应和质检。提示词写得再好，如果上游输入的工单文本带着大量无关转义字符、或者下游系统对接的标签体系跟提示词里定义的不一致，照样出问题。我一般跟团队说，提示词的角色定位要放在“场景—任务—系统”这三层关系里去理解，单拎出来讨论提示词本身，容易跑偏。
1.2 单标签分类、多标签分类与优先级分类的任务边界
这三个分类任务看着像是一回事，实际做起来差别很大，混在一起设计提示词是很容易翻车的。单标签分类的逻辑最直接，一张工单对应一个一级分类，比如“退款问题”“物流异常”“账号安全”。这种任务提示词好写，输出格式也简单，难点在于类别边界要划清楚，别出现一个工单同时能塞进两个类的情况。
多标签分类就麻烦多了。我接触过的客服场景里，一张工单经常同时涉及多个问题维度，比如客户说“我下单三天了还没发货，客服也不回我消息”，这里面既有物流时效问题，又有服务态度问题。多标签提示词的设计不只是让模型输出多个标签那么简单，还要考虑标签之间的组合约束、主次关系、甚至输出顺序的稳定性。我自己做多标签分类的时候，会在提示词里明确告诉模型：先判断主诉问题标签，再判断伴随问题标签，最多输出不超过三个，并且用固定分隔符隔开。
优先级分类是另一条线，它跟前面两类不是并列关系，而是叠加关系。很多团队会把优先级判断直接塞进分类提示词里一起做，我试过，效果不太稳。优先级判断依赖的信息维度跟问题分类不一样，它更看重客户情绪强度、是否涉及资金安全、是否有升级投诉的历史记录。我现在的做法是把优先级作为一个独立子任务，在提示词里单独给一段判定规则，输出格式上加一个优先级字段，跟分类标签并列。这样提示词结构清晰一些，调试的时候也方便定位到底是分类错了还是优先级判错了。
1.3 分类体系、标签字典与业务规则的前置梳理
这一块是我认为整个提示词项目里最容易被低估的环节。很多团队上来就写提示词，写到一半发现标签体系还没定清楚，来回改，效率特别低。我的经验是，写提示词之前，先把分类体系、标签字典和业务规则这三样东西盘清楚。分类体系决定的是标签的层级结构，是一级分类加二级分类，还是扁平化的一层标签；标签字典定义的是每个标签的名称、含义、典型示例和排除条件；业务规则则是标签之间的互斥、包含、组合关系，以及特殊场景下的强制判定逻辑。
我遇到过一个典型的坑：标签字典里“退款进度咨询”和“退款失败”这两个标签，名字看着能区分，实际标注的时候经常混淆。后来在字典里补了一段边界说明——“客户询问退款到账时间但未表示退款失败”归入进度咨询，“客户明确表示退款未成功或金额不对”归入退款失败。这段说明写进提示词之后，分类一致性明显提升。标签字典不是给模型看的，是给写提示词的人和标注团队看的，但它最终会以“标签定义”的形式进入提示词，所以前期梳理越细，后面提示词越省事。
业务规则这块，我建议单独列一个规则清单，别跟标签定义混在一起。比如“涉及资金安全的工单优先级不得低于P2”“同一客户24小时内重复提交的同类工单自动归入投诉升级类”，这类规则需要在提示词里用明确的判定语句表达出来，不能指望模型自己从标签定义里推导。我自己习惯把业务规则整理成“条件—动作”的格式，写提示词的时候直接翻译成判定逻辑，减少歧义。
1.4 提示词效果评估指标与常见失败类型
评估提示词效果，不能只看准确率一个数。我在项目里一般会同时盯几个指标：整体准确率、单标签准确率、多标签场景下的召回率和精确率、优先级判断的混淆矩阵、还有输出格式的合规率。这几个指标反映的问题不一样。整体准确率高但单标签准确率低，说明长尾类别被头部类别淹没了；多标签召回率高但精确率低，说明模型倾向于多打标签来“保底”，这种在客服场景里会导致分派到错误的处理组，增加流转成本。
常见的失败类型我总结了几种。一种是“标签漂移”，模型输出的标签名称跟字典里定义的不完全一致，比如字典里是“物流延迟”，模型输出“物流延误”，看起来意思一样，但系统对接的时候匹配不上。这种问题在提示词里加一段“输出必须严格使用以下标签名称”的约束就能缓解大部分。另一种是“过度分类”，多标签场景下模型给一张简单工单打了四五个标签，实际只有一个主诉问题，这种需要靠少样本示例和标签数量上限约束来控制。
还有一类失败比较隐蔽，就是“置信度虚高”。模型对某个分类给出很高的置信度，但实际判断是错的。这种情况在边界案例上特别常见。我在提示词里会要求模型在输出标签的同时，附带一个简短的判定理由，不一定要求它输出数值化的置信度，但理由本身能帮我快速判断这个分类是靠得住的还是靠猜的。评估的时候，我会把“有理由且理由合理”作为一个辅助指标，跟准确率一起看。另外，格式错误、输出截断、标签组合违反业务规则这些，都属于工程层面的失败，需要在提示词结构设计和后处理环节一起解决，不能全指望模型自觉。
2.1 角色设定、任务指令与输出格式约束
我见过不少提示词开头就写一句“你是一个客服工单分类助手”，然后就没了。这种角色设定基本等于没写。真正有用的角色设定，得让模型知道它站在什么位置上看这些工单。我后来改成了这种写法：“你是一名在电商平台客服一线工作了五年的资深分诊员，熟悉退款、物流、账号、投诉四大类问题的判别标准，你的职责是把用户提交的工单准确归入对应的处理队列。”这么写的好处是，模型输出的语气和判断倾向会往“有经验的从业者”那边靠，碰到模糊描述时更倾向于给出贴近业务实际的判断，而不是按字面意思硬套。
任务指令这块，核心原则是“拆开写、别打包”。一个提示词里塞进去分类、优先级、情绪识别、回复建议，模型很容易顾此失彼。我现在的做法是把主任务写成一句明确的指令，比如“请判断这张工单属于下列哪一个一级分类”，然后在下面用编号列表把判断步骤拆出来——先识别客户主诉的核心动作，再匹配类别定义，最后核对边界条件。步骤拆得越细，模型跑偏的概率越低。有个小细节，指令里最好加上“如果信息不足以判断，输出‘待人工复核’而不是猜测”，这句话能挡掉相当一部分强行分类的误判。
输出格式约束我是吃过亏的。早期没加格式约束，模型有时候输出“该工单属于退款问题”，有时候输出“分类：退款问题”，还有时候在标签后面加一段解释。系统解析的时候简直是灾难。后来我在提示词末尾加了一段固定格式要求：第一行输出标签名称，第二行输出不超过二十字的判定依据，多余内容不要。格式约束越机械越好，别给模型发挥空间，否则每次输出都长得不一样，后处理逻辑得写一堆兼容代码，维护成本特别高。
2.2 工单文本输入规范与上下文信息组织
工单文本本身质量参差不齐，这一点做过的都懂。客户可能是凌晨三点用手机打的一段话，错别字、语音转文字的错误、夹杂着表情包、中间还穿插着订单号。我的经验是，别指望模型能自动过滤这些噪声，输入侧得先做一轮清洗。我在提示词里会明确告诉模型“输入文本已去除特殊字符和无关符号，但可能保留少量语音转写误差”，这种前置说明能让模型在遇到错别字时保持合理的容错，而不是把“退宽”这种明显是“退款”打错的词当成另一个问题。
上下文信息怎么组织，这个事我摸索了很久。早期我只把工单正文丢进去，效果一直上不去。后来加了几个关键字段：工单来源渠道（App、网页、电话转写）、客户历史工单次数、是否有订单号关联、提交时间。这些信息不需要模型去解析，而是作为一个独立的“上下文区块”放在工单正文前面，用简单的键值对格式排列。比如“渠道：App在线｜历史工单：3次｜关联订单：是”。这些字段对分类判断的影响很直接——来自电话转写的工单通常信息完整度低，模型会倾向于输出低置信度标签；历史工单次数多的客户，主诉往往是升级投诉而不是首次咨询。
还有一个容易被忽略的点是输入文本的长度控制。客服工单有时候特别短，“退款”两个字就提交了，有时候又特别长，客户把过去一周的遭遇从头到尾写了一遍，两千多字。我的处理方式是在提示词里加一句“优先关注以下内容：客户的核心诉求、涉及的产品或订单操作、明确表达的时间节点”。这句话相当于给模型一个注意力锚点，让它从长文本里先抓这几类信息，而不是平均用力。对于极短文本，我会在预处理阶段触发一个补全逻辑，把订单关联信息拼进去，否则模型只能靠猜。
2.3 标签定义、判定标准与边界案例说明
标签定义写得好不好，直接决定了提示词的下限。我以前写标签定义就写一句“退款问题：客户关于退款相关的问题”，结果模型把“我想问下优惠券能不能退”也归进来了，其实那属于营销工具问题。后来我把每个标签的定义改成三段式：第一句说这个标签覆盖什么，第二句说典型场景长什么样，第三句说哪些情况不算。三段式写下来，标签的轮廓就清楚了。举个例子，“退款问题”的定义会写成——覆盖客户关于退款申请、退款进度、退款金额的咨询和投诉；典型场景包括“申请退款后迟迟不到账”“退款金额跟预期不符”；不包含优惠券退还、积分退回、运费退还的咨询，这些归入各自对应类目。
判定标准我一般会拆成“必须满足”和“可以辅助判断”两组条件。必须满足的条件是硬门槛，比如“物流延迟”标签要求客户明确提到了订单未按时送达，没有这句话就不打这个标签。辅助条件则是加分项，比如客户提到了具体的延迟天数、表达了催促意图，这些条件用来在多个候选标签之间做倾向性排序。这么区分的好处是提示词执行起来有确定性，不会出现模棱两可的情况。我现在的提示词里每个标签都会带这两组条件，模型照着匹配，结果稳定很多。
边界案例说明是最花时间但回报最高的部分。我会从历史工单里挑出那些标注团队吵过架的样本，把争议点和最终判定结论写进提示词。比如有一组边界案例是“客户说退款已经收到了但金额少了两块钱”，这到底算退款问题还是算金额争议。我们最后的判定规则是：只要涉及退款到账后的金额比对，归入金额争议类，退款问题类只处理退款流程本身的状态查询。这条规则配上两三个真实脱敏案例写进提示词之后，同类工单的分类准确率提升了差不多十五个百分点。边界案例不用多，一个标签配两三个最典型的就够，写太多反而稀释了重点。
2.4 少样本示例、反例与置信度表达设计
少样本示例的挑选有个原则我一直在用：每个标签至少配两个正例，一个典型表达，一个变体表达。典型表达是那种一眼就能看出类别的工单，变体表达是措辞不太标准但实质相同的。比如“账号被盗”这个标签，典型例子是“我的账号登录不上了，提示密码错误，但我没改过密码”，变体例子是“好像有人在用我的号下单，我自己没操作过”。两个例子一起给，模型对标签的理解会更有弹性，不会死抠字面。
反例我觉得比正例还重要。正例告诉模型“什么算”，反例告诉模型“什么不算”。我一般会在容易混淆的标签对之间放反例。比如“退款问题”下面放一条反例：“客户问优惠券能不能退，这是营销工具问题，不是退款问题。”反例不需要多，关键是选那些模型最容易误判的。我习惯把上一轮测试中错得最多的前三个案例改写成反例，塞进下一版提示词的少样本区块里。这种迭代方式很土，但确实管用。
置信度表达这块，我不太喜欢让模型直接输出一个百分比数字，因为那个数字基本没有校准过，看着精确实际上没参考价值。我改成让模型输出一个三档的判定强度描述——高、中、低。高的定义是“工单内容明确匹配标签的必须条件，没有歧义”；中的定义是“匹配主要条件，但存在少量信息缺失”；低的定义是“只能部分匹配，需要人工确认”。同时在输出里附一句判定理由，理由不用长，把匹配到的关键信息点出来就行。这样人工复核的同事拿到结果，扫一眼理由和强度就能决定要不要重判，比看一个孤零零的置信度数字有用得多。
2.5 分类提示词的稳定性、可解释性与安全约束
稳定性问题我在项目里踩过最狠的一次坑是，同一个提示词，上午跑和下午跑，同一批工单的分类结果不一致。排查了半天发现是模型版本在后台做了小升级。从那以后我养成了一个习惯，提示词里凡是涉及判定规则的部分，尽量用确定性语句，少用“通常”“一般”“建议”这种弹性词。弹性词一多，模型每次执行的尺度就会飘。另外标签名称和输出格式这些关键元素，我会在提示词里重复出现两次，开头提一次，结尾再强调一次，实测对输出稳定性的帮助挺明显。
可解释性方面，我一直坚持一个做法：分类结果必须带判定依据。依据的写法有讲究，不能是“因为工单内容符合退款问题的定义”这种废话，得把工单里触发判定的原话摘出来。比如“客户提及‘申请退款五天未到账’，匹配退款进度咨询的典型场景”。这种依据对人工复核和误判归因的价值很大。我们团队每周会抽一批低置信度结果做复盘，判定依据写得清不清楚，直接决定了复盘效率。有些依据写得含糊的，得重新翻原文看，十分钟能搞定的复盘拖成半小时。
安全约束这块，客服场景有几个红线我每次写提示词都会加进去。一个是不能输出客户隐私信息，工单里出现的手机号、身份证号、银行卡号，模型在判定依据里不能复述。另一个是涉及资金安全、人身安全的关键词，比如“被骗了”“要报警”“人身威胁”，不管分类结果是什么，优先级字段必须标红。还有一条是模型不能对客户诉求做合理性判断，只做分类，不做对错评价。这几条约束我会单独放在提示词末尾一个叫“硬性约束”的区块里，用否定句式写清楚——“不得输出……”“不得评价……”。否定句式在约束场景下比正面表述更管用，模型对“不得”的遵守度明显高于“请注意避免”。
3.1 客服工单自动分类提示词模板的通用结构
模板这个东西，我的理解是它得先能跑起来，再谈跑得稳。我手里这套通用模板是改了十几版留下来的，骨架其实不复杂，从上到下分五个区块：角色与任务、分类体系说明、输入区、输出格式、硬性约束。每个区块之间用明显的分隔符隔开，我习惯用三个等号加区块名称，模型读到这种结构信号会自觉按顺序执行。没见过哪个模型因为区块分得清楚反而搞混的，倒是有不少因为提示词从头到尾一段顺下来、模型分不清哪是规则哪是示例而翻车的。
为什么要把角色和任务放在最前面，分类体系说明紧随其后？我试过把标签定义放最前面、角色设定放后面，效果差了一截。模型对开头的内容注意力权重更高，先告诉它“你是谁、要干什么”，它后面读标签定义的时候会带着任务视角去理解。角色设定别写太虚，“资深客服分诊员”这种描述我一般会补上一句具体的工作背景，比如“每天处理两百张以上工单，熟悉退款、物流、账号、投诉四大类的判别边界”，给模型一个具象的锚点。
分类体系说明区块我建议写得“笨”一点。所谓笨，就是每个标签都老老实实把名称、定义、典型场景、排除项列清楚，不要试图用一段话概括所有标签。多标签分类的场景下，标签之间的关系也得在这个区块里说清楚，哪些标签可以共存、哪些互斥、有没有主次之分。我见过有人把标签定义写得特别精炼，结果模型在边界上反复横跳，后来把定义展开成条目式，准确率马上就上来了。模板不怕长，怕的是歧义。
输出格式区块我现在的写法是给一个完整的输出示例，把每一行的内容要求都标出来，包括标签名称怎么排列、多个标签之间用什么符号分隔、判定依据写在第几行、置信度档位放在哪里。示例比描述管用，模型照着抄格式的准确率远高于听描述。硬性约束区块放在最后，用否定句把红线列出来，比如“不得输出客户手机号”“不得对客户诉求做合理性评价”“不得输出标签列表之外的任何分类名称”。这五个区块摆在一起，就是一个能直接套用的完整模板。
3.2 自动分类模板中的变量槽位与批量处理设计
变量槽位这事，我踩过一个挺蠢的坑。早期我在提示词里直接手写工单文本，每来一张新工单就改一次提示词内容，效率低不说，改着改着就把别的地方碰坏了。后来我把所有会变的部分抽成占位符，用双花括号包起来，比如{{工单正文}}、{{渠道信息}}、{{历史工单次数}}、{{关联订单状态}}，模板本体不动，跑批的时候用脚本把变量填进去。这么一改，提示词从“每次重写”变成了“一次维护、反复调用”，团队里其他人接手也方便，不用理解整段提示词，只要知道每个槽位填什么就行。
槽位设计有个细节值得说，就是别把太多信息塞进一个槽位。我一开始图省事，把渠道、历史次数、订单状态全拼在{{上下文信息}}这一个槽位里，结果模型有时候把上下文里的数字当成工单正文的一部分去解析，判断依据写得莫名其妙。后来拆成三个独立槽位，每个槽位前面带一个固定的字段标签，比如“渠道：{{渠道}}｜历史工单：{{次数}}｜关联订单：{{订单状态}}”，模型对结构化键值对的解析稳定性明显好于混在一段自然语言里。
批量处理的设计得单独拎出来讲。单条工单跑一次提示词，成本和延迟都扛不住，我现在的做法是把十到二十张工单打包成一批，用编号分隔，提示词里明确要求“按工单编号顺序逐条输出分类结果，每条结果以‘工单编号：’开头”。批量处理最容易出的问题是错位，也就是模型把第三张工单的标签安到了第四张头上。我的应对办法是在每张工单正文前后都加上明确的边界标记，比如“【工单开始 #003】……【工单结束 #003】”，同时在输出格式里要求模型复述编号。编号对应上了，后续解析脚本才能放心跑。批大小也不是越大越好，我实测下来十五张左右是一个比较稳的区间，再大模型对靠后工单的注意力会衰减。
3.3 客服工单多标签分类提示词优化的判定链与冲突消解
多标签分类比单标签难的地方在于，模型得同时做两件事：判断有哪些标签命中，以及判断这些标签之间是什么关系。我早期写的多标签提示词就是简单罗列一句“请选出所有适用的标签”，结果模型要么只挑一个最显眼的，要么把擦边的全打上，两个极端都出现过。后来我把判定过程拆成一条链：第一步识别客户主诉的核心动作，第二步匹配主诉对应的必选标签，第三步扫描工单里是否还包含次要诉求，第四步对次要诉求做标签匹配，第五步检查标签组合有没有冲突。这五步写进提示词之后，模型输出的标签数量和准确度都往合理区间靠了。
判定链里最关键的是第三步和第五步。第三步解决“漏标”问题，很多工单客户会在一段话里塞两三个诉求，比如“退款一直没到账，而且客服电话打不通”，主诉是退款进度，次要诉求是服务渠道投诉。没有第三步的引导，模型很容易只输出退款标签就收工了。第五步解决“乱标”问题，有些标签天然互斥，比如“物流延迟”和“已签收异常”在同一个订单上不可能同时成立，提示词里得把这类互斥关系列清楚，让模型在输出前做一次自检。
冲突消解我一般会写一套优先级规则进提示词。规则的形式是“当A标签和B标签同时命中时，优先保留A，B作为附加标签输出但标注为次要”。打个比方，一张工单既涉及退款金额争议又涉及客服态度投诉，我的规则是退款类标签作为主标签，投诉类作为附加标签，因为退款是客户的核心诉求，投诉是衍生情绪。这套规则不是拍脑袋定的，是从历史工单的标注共识里提炼出来的。规则写进提示词的时候我会配上两三个具体的冲突案例，模型看了案例再执行规则，比光看规则条文靠谱得多。
还有一类冲突比较隐蔽，就是标签语义重叠。比如“退款进度咨询”和“退款失败求助”，一张工单里客户说“申请退款好几天了也没动静，是不是失败了”，这两个标签其实都沾边。我的处理方式是在标签定义阶段就把边界划清楚——进度咨询只覆盖“等待中”的状态查询，失败求助要求客户明确表达了“退款被拒”或“退款操作报错”的信息。提示词里把这条边界写成判定条件，模型碰到模糊表述时会倾向归入更保守的那个标签，而不是两个都打上。多标签分类的原则我始终把握一条：宁可少打一个真标签，也别多打一个假标签，前者人工复核能补，后者会污染下游的处理队列。
3.4 多标签输出格式、标签组合约束与召回率精确率平衡
多标签的输出格式比单标签麻烦，因为得考虑标签之间的排列和层级。我现在的格式设计是这样的：第一行输出主标签，以“主标签：”开头；第二行开始输出附加标签，每个附加标签一行，以“附加标签：”开头；附加标签全部输出完之后，另起一行写“判定依据：”，把每个标签对应的关键原文摘录列出来；最后一行写整体置信度档位。这个格式看起来啰嗦，但它有一个好处——下游解析脚本可以按行首关键词直接切分，不用做复杂的文本匹配。格式设计的核心原则是让机器好读，不是让人好读，人要看的是渲染之后的界面。
标签组合约束我一般会写成两类规则放进提示词。一类是互斥规则，就是前面说的A和B不能同时出现；另一类是伴随规则，意思是打了A标签就必须同时检查B标签是否也该打上。伴随规则的典型场景是“退款问题”和“金额争议”，客户提到退款金额不对的时候，这两个标签通常要成对出现，只打一个说明模型漏了信息。提示词里我会把伴随规则写成“若命中X标签，必须检查Y标签的判定条件是否满足，满足则一并输出”。这类规则不用多，挑业务上关联最紧密的五六对写进去就够了，写太多模型记不住，反而增加执行负担。
召回率和精确率的平衡，在多标签场景下基本是一个调参问题。我的经验是把平衡点交给提示词里的阈值描述来控制。比如提示词里写“只有当工单内容明确匹配标签的必须条件时才输出该标签”，这是在拉精确率；写“若工单内容部分匹配标签条件且无明确否定信息，可以输出该标签并标注低置信度”，这是在拉召回率。两个版本的提示词跑同一批测试集，召回率能差出十来个点。实际项目里我会准备两套阈值描述，一套偏保守用于自动处理队列，一套偏激进用于人工辅助队列，按业务场景选用。
说个具体的数字感受一下。我们之前一个多标签分类任务，初始版本的召回率大概七成出头，精确率倒是挺高，但漏标太多导致人工补标的工作量很大。后来在提示词里加了“次要诉求扫描”步骤和“部分匹配可输出低置信度标签”的规则，召回率拉到了八成五左右，精确率掉了不到三个点。这个交换比在客服场景下是划算的，因为漏标的代价是客户诉求被忽略、工单在队列之间踢皮球，误标的代价只是人工复核时多看一眼。不同业务对这两个指标的偏好不一样，提示词里的阈值描述得跟着业务走，没有一个万能配方。
3.5 面向不同工单类型的模板变体与复用策略
一套模板打天下这种事我没干成过。电商客服和SaaS客服的工单形态差太多了，前者短、碎、情绪浓，后者长、结构化、技术描述多。硬用一套模板，要么电商工单的分类过度复杂，要么SaaS工单的标签覆盖不够。我的做法是维护一个模板基座，把角色设定、输出格式、硬性约束这些跨场景通用的部分固定在基座里，标签体系和判定链按工单类型做变体。基座不动，变体只改中间的分类体系说明和少样本示例区块。
变体的粒度我控制在“业务线”这一层。比如电商业务线一套变体，覆盖退款、物流、商品、账号四个大类；金融业务线一套变体，覆盖账单、还款、风控、账户安全四个大类。每条业务线的变体里，标签定义和边界案例都是独立维护的，互不干扰。这么做的维护成本比想象中低，因为基座部分占了模板七成的篇幅，变体部分只占三成，改起来工作量可控。而且基座升级的时候，所有变体自动受益，不用逐个去改。
复用策略里有一个容易被忽略的点是少样本示例的复用。同一类标签在不同业务线下的典型表达其实有大量重叠，比如“退款”这个动作在电商和在线教育场景下的客户措辞高度相似，都是“申请退款”“退款没到账”“退款被拒”这几类。我的做法是建一个示例池，按标签名称索引，新业务线的变体直接从池子里拉取匹配的示例，再补两三个业务特有的例子进去。示例池里的例子都做过脱敏处理，标注了适用场景和表达变体类型，复用的时候一眼就能看出哪些能直接搬、哪些得改写。
模板变体的版本管理也得说一句。我的习惯是每个变体文件开头写一个变更记录区块，记录版本号、修改人、修改日期、改了什么、为什么改。这个习惯是被坑出来的，有一次两个同事同时改同一个变体的标签定义，没留记录，合并的时候冲突了，跑出来的结果两边对不上，排查了大半天。从那以后变体文件都带版本头，改动必须留痕。模板这东西是团队资产，不是个人草稿，复用策略里版本管理这一环省不得。
4.1 测试集构建、标注一致性与提示词对比实验
测试集这事我吃过亏。最开始随便抽了五十张工单当测试集，跑出来准确率九成多，兴冲冲上线，结果第一周就被现实打脸——真实工单里长尾问题太多了，测试集里根本没见过。后来我给自己定了个规矩：测试集必须覆盖每个标签至少三十条样本，边界案例和歧义案例单独拉一个子集，占比不低于两成。这个子集是从历史工单里人工挑出来的，专门用来考验提示词在模糊地带的表现。
标注一致性比样本数量更要命。我让三个客服主管背对背标同一批两百张工单，标完之后对答案，发现“退款进度咨询”和“退款失败求助”这两个标签三个人给出了三种不同的划分方式。这事不能怪标注的人，问题出在标签定义本身就有歧义。我把那批有分歧的工单摊开逐条过，重新把两个标签的判定边界写清楚，再让三个人标一遍，一致性系数从零点七出头拉到了零点九以上。标注一致性不达标，后面所有对比实验的数据都是废的。
对比实验的设计我走过两个极端。早期改一版提示词就跑一次全量测试，跑完看总准确率涨了还是跌了，涨了就上线，跌了就回退，粗暴得很。后来发现总准确率这个指标太钝了，一个标签涨十个点、另一个标签跌八个点，总数字看起来不痛不痒，实际上把下游某个处理队列搅得鸡飞狗跳。现在的做法是按标签分组看指标，每个标签单独算精确率和召回率，哪几个标签波动超过三个点就拉出来单练。另外我会固定一组“回归测试样本”，每次改提示词必须跑这组样本，确保之前修好的case没被改坏。
还有个细节值得讲——对照实验里我会同时跑一版“空提示词”作为基线。就是只给模型工单文本，不给任何分类指令，看它自发把工单归成什么类别。这个基线有时候特别有意思，模型在没有引导的情况下会发明一些人类没定义过的类别名，那些类别名反而暴露出我们标签体系里覆盖不到的维度。有一回基线跑出来一个“催促类”标签，我们分类体系里确实没有对应的，但客户确实在催回复。这个发现直接促成了一次标签体系扩充。
4.2 自动分类结果监控、误判归因与人工复核机制
上线不是终点，是睁着眼睛开车的起点。我现在的监控面板上固定盯四个数：整体准确率七日滚动均值、低置信度输出占比、人工复核推翻率、单工单平均分类耗时。低置信度占比这个数特别灵敏，提示词被人不小心改坏一版，准确率可能还没掉下来，低置信度占比先飙上去，像煤矿里的金丝雀。推翻率我设的告警线是百分之八，连续三天超过这条线就说明模型的行为和人工判断在系统性偏离，得回去查提示词了。
误判归因我一般分五类来记：标签定义歧义导致的误判、边界案例模型没见过导致的误判、工单文本本身信息不足、多标签冲突规则没覆盖到、模型输出格式跑偏导致解析失败。每类归因对应不同的修法。定义歧义就改标签定义，边界案例没见过就往少样本示例里加，信息不足就考虑在输入槽位里补上下文，冲突规则没覆盖就补规则。格式跑偏最麻烦，通常是模型注意力被长工单带走了，得在输出格式约束里加更硬的锚点。
人工复核机制我设计了两条通道。一条是低置信度自动转人工，模型标了低置信度的工单不直接进自动处理队列，先给人工看一眼再走。另一条是随机抽样复核，每天从高置信度结果里随机抽百分之五出来人工检查。第二条通道刚开始被团队骂得挺惨——高置信度还有什么好查的。后来真查出问题了，有些高置信度结果里藏着系统性偏差，模型在某一类工单上集体自信地标错。抽样复核不能省，它是发现集体性误判的唯一手段。
复核结果不是看完就扔，我会把复核人改过的标签和模型原始输出做逐条对比，按标签维度统计修正方向。某个标签连续两周被人工从A改到B的次数超过阈值，那就说明提示词里A和B的边界已经在实际工单分布面前失效了，得重新校准。这套机制跑顺之后，我们团队养成了一个习惯：每周一上午看复核报表，雷打不动。报表上能看出很多模型自己不会告诉你的东西。
4.3 多标签分类提示词的版本管理与优化闭环
版本管理这块我现在的做法可能看着有点土，但管用——每个提示词版本存三个文件：完整的提示词文本、对应的测试报告、变更说明。文件名带版本号和日期，比如multi_label_v2.3_20240615，丢在一个共享目录里，按业务线分文件夹。不用上一堆花哨的版本管理工具，共享目录加命名规范就能解决八成问题。
变更说明文件我要求写清楚三件事：改之前是什么状态、改了什么、预期影响哪些标签。这第三条是强制要写的，写不出来说明改提示词的人自己都没想明白这次改动的目标是什么。我见过太多“觉得这么写更好”就顺手改了，跑出来指标跌了也说不清是哪句话导致的。把预期影响写下来，跑完测试直接对答案，对了总结经验，错了积累教训，没有白改的版本。
优化闭环的节奏我们磨合了小半年才定下来。两条线并行跑：一条是“响应式优化”，线上监控告警了、复核推翻率超标了、业务方反馈某个标签最近乱套了，触发即时排查和修复；另一条是“周期性优化”，每个季度把全部标签拉出来过一遍指标，再挑出表现最差的三个标签做专项调优。响应式保稳定，周期性保提升，两条线不能互相挤占时间。
回滚机制必须提前设计好。我的触发条件是：新版本全量上线后四十八小时内，如果整体准确率相对基线跌超过两个点，或者任何一个标签的召回率跌超过五个点，自动回滚到上一版，不需要开会讨论。这个规则是我硬拍下来的，有一回上线之后指标跌得不明显但持续阴跌，团队犹豫了两天才决定回滚，那两天里下游的投诉队列积压了不少工单。从那以后我坚持回滚要设自动触发条件，把决策从“商量商量”变成“规则执行”。
优化闭环里还有一个容易被跳过的步骤——归档。旧版本的提示词、测试报告、误判归因记录全部打包存档，标注好停用日期和停用原因。这事平时没人愿意干，觉得浪费时间。我经历过一次，半年前一个版本的表现数据要拿来对比，结果发现当时的测试集样本被覆盖了，报告只剩一个总数，细项指标全丢了。从那以后归档流程写进了团队的操作手册，谁改版本谁负责归档，跑不掉。
4.4 与工单系统、知识库和客服流程的集成落地
集成这件事我最大的教训是别把提示词当成一个孤立服务来设计。早期我们在实验室里跑得挺好，一接进工单系统就各种水土不服。工单系统里的文本格式和测试集里完全两码事，各种换行符、系统自动追加的模板话术、客户上传图片后OCR识别出来的乱码文字混在一起，模型读得一头雾水。后来我在提示词前面加了一个预处理层，先做文本清洗再塞进变量槽位，分类准确率立刻稳住了。
和工单系统的对接方式我们试过三种。同步调用最简单，工单创建时实时调一次分类接口，结果直接写回工单字段，缺点是模型响应慢的时候会拖累工单创建流程。异步消息队列那套更稳，工单创建后扔进队列，分类结果出来之后回写，延迟高了点但不影响前端体验。跑批处理适合历史工单清洗，每天晚上跑一次全量重分类，把结果和之前的做比对，找出哪些工单的标签需要人工确认。三种方式我们现在都用，按场景选。
知识库的联动是个容易被低估的点。分类结果出来之后，自动从知识库拉取对应标签的标准回复话术和常见解决方案，推送到客服工作台。这个联动做通了，客服处理工单的平均时长能降不少。反过来，知识库里的解决方案更新了，也要触发提示词的检查——有些解决方案变了就意味着标签定义可能需要跟着调。我见过标签定义还按老方案写的，模型分类分得挺准，推给客服的话术全是过时的，客户体验更差。
嵌入客服流程的时候得想清楚模型输出在流程里的位置。我的原则是：高置信度结果直接进自动化处理分支，中置信度结果先进人工辅助分支、客服确认后放行，低置信度结果直接转人工分诊。三条分支的阈值不是拍脑袋定的，是从历史工单里跑出来的——把模型输出和人工判断做交叉对比，找到每条分支上收益和风险最平衡的那个点。这套分流逻辑跑顺了之后，客服团队的工作重心从“判断工单是什么类别”转到了“处理工单本身”，这是自动分类真正产生价值的地方。
4.5 提示词资产沉淀、团队协作与合规治理
资产沉淀这事我踩过最蠢的坑是把提示词存在自己的聊天记录里。换台电脑、清理一次缓存，半年的迭代积累说没就没了。现在团队所有提示词统一存在一个内部知识库里，每份提示词有唯一编号、当前版本号、负责人标签、关联的业务线。新同事入职，给他开知识库权限，三天能上手改提示词，不用跟着我屁股后面问“这版和上版的区别到底在哪”。
团队协作的分工我们磨合出一套模式：我负责基座模板和判定链逻辑的维护，两个业务线的运营同学各自负责自己那条线变体的标签定义和示例池，测试集的标注由客服主管轮值完成。每周三下午开半小时的碰头会，同步这周改了啥、测试结果怎么样、下周打算动哪里。会不用长，但得固定，不然改提示词这件事很容易被日常业务冲掉。
示例池的维护得单独立规矩。所有进入示例池的案例必须脱敏，手机号、订单号、客户姓名、地址全部替换成占位符。脱敏脚本跑完之后还得人工过一眼，有些文本里嵌着客户自己写的银行卡号或者身份证号，脚本不一定能拣干净。我要求每个示例入库前必须双人复核脱敏结果，签字确认。这条规矩被团队吐槽过繁琐，直到有一次业务方拿着一个示例案例来找我们，说案例里的客户他认识。那次之后没人抱怨复核流程了。
合规治理还有一块是权限管控。提示词文件不是谁都能下载的，下载动作记日志，变更权限给到具体的人而不是整个团队。模型调用的输入输出日志保留周期按公司数据合规要求走，一般不少于三个月。涉及客户敏感信息的工单，走单独的脱敏处理流程，脱敏后的文本才进入模型调用环节。这些事平时看起来是负担，真出事的时候是保命的东西。提示词资产是团队最值钱的积累之一，治理规则得跟着资产一起长出来，不能等出了问题再补。
说到最后我想强调一句，测试、上线和迭代这三件事在客服工单分类这个场景里是一个咬着一个的环，没有哪一步能单独拎出来做好。测试集建得再漂亮，上线之后没人盯监控一样翻车，监控盯得再紧，版本管理乱七八糟一样没法持续优化。这套东西跟提示词本身的设计一样，需要反复调、反复磨合，没有一步到位的办法。
