把 Xing4.0-29B-Intent 接入工单分流前，真正需要先定死的不是提示词写得多漂亮，而是两件事：一张归并过、互不重叠的意图标签表，和一个单独的兜底类。模型只能在你给的候选集合里选，标签集碎、定义含糊、没有兜底出口，输出就会落到没人负责的类上。可以先做的动作是：把现有话术归并到二十个以内，给每个标签写一句可判定定义加两条反例，单独设兜底类并写清触发条件，再用边界样本跑一轮混淆矩阵看哪两类互相吞并。这些都能通过配置文件、推理日志和混淆矩阵表格核对。

意图分类落地前先定死标签集与兜底类：标签归并到二十个以内并写可判定定义，每个标签配两条反例；单独设兜底类并写触发条件，让模型有地方输出“说不清”；用边界样本跑混淆矩阵查出互相吞并的类别再返工。判断是否做对，看日志里每条输出是否都有明确归属和人工接手路径；标签边界模糊或兜底缺失时，分流会退回人工全量处理。

把现有业务话术归并成不超过二十个意图标签

标签越加越碎的根因通常是按业务话术逐条建类，而不是按处理动作建类。归并规则建议按“谁处理、处理动作是否相同”来切：同一个承接团队、同一套处理流程的说法，先合成一个意图，再看量级是否真的需要拆。二十个是建议上限，不是硬指标；超过这个数，标注一致性通常先崩，而不是模型效果先崩。

同义说法合并的具体例子：用户说“发票开错了”“抬头写错”“税号填错”，如果都走同一个财务修改流程，就合并成“发票信息修改”一个标签；“我要退款”“钱什么时候退”“退款没到账”里，前两个属于退款申请，第三个属于退款进度查询，处理动作不同，不该合并。归并时先用日志里的原始话术做频次统计，不要凭记忆拍脑袋。

合并前后的标签对照可以做成表格，放在标注规范同一个文件里，方便标注人和模型对齐：

合并前（话术级）          合并后（动作级）
发票开错 / 抬头错 / 税号错  -> 发票信息修改
退款申请 / 想退款          -> 退款申请
退款没到账 / 钱什么时候退  -> 退款进度查询
登录不上 / 密码忘了 / 收不到验证码 -> 账号登录异常
改手机号 / 换绑定邮箱      -> 账号信息变更
（其余话术按同一规则继续归并，上限建议 20 类）

对照表要作为配置的单一来源：标签 ID、中文名、承接团队三列必须齐全。模型输出的标签 ID 与这张表对不上时，直接判为无效输出，不要靠后处理猜。验证方式是抽一批历史工单，用这张表人工回标，看有多少工单找不到合适标签——找不到的比例高，说明归并漏了动作，而不是模型不行。

给每个标签写一句可判定的定义和两条反例

定义要写成“当用户……时，归入本类”的句式，主语是用户诉求，谓语是可观察的动作或对象，避免“涉及退款相关的问题”这种同义反复。模板可以直接用：当用户明确提出【动作】，且对象是【业务对象】时，归入【标签名】；若只是询问进度或政策，归入对应查询类。

每个标签至少配两条反例，反例要写“看起来像但不属于”的句子。例如“退款申请”的正例是“这个订单我不想要了，帮我退掉”“申请退款”，反例是“我上周申请的退款到哪了”（属于退款进度查询）、“退款要扣手续费吗”（属于退款政策咨询）。“账号登录异常”的正例是“密码输对了还是登不上”“收不到短信验证码”，反例是“我想换个手机号绑定”（属于账号信息变更）、“帮我注销账号”（属于账号注销）。

容易混的两类要在规范里单独写一段区分说明，例如“退款申请”与“退款进度查询”：前者必须包含发起或确认退款的意图，后者只问时间、状态、到账情况，不产生新的退款动作。区分说明写成一句话判据，标注人和模型提示词里引用同一句，不要各写一版。

单独设一个兜底类并写清触发条件

兜底类的描述文本建议直接写成：当用户诉求无法明确对应到任何一个已定义意图，或同时涉及多个意图且无法判断主诉求，或信息不足以判断时，输出 OTHER。关键是让“说不清”成为一个合法输出，而不是让模型在最近的类别上硬凑。

兜底类与最接近类别的区分写法要落到判据上：如果用户提到了某个业务对象但没提出任何动作，例如只发来一串订单号或一句“在吗”，归入 OTHER 而不是最接近的查询类；如果用户诉求同时命中两类且分不出主次，也归 OTHER，不要按关键词优先级硬分。触发条件可以写成三条并列：无匹配意图、多意图冲突、关键信息缺失。

兜底后的人工接手规则必须一起定：OTHER 输出进入人工待分配队列，由值班人按原文重新归类，并把这次误判记录成候选新标签或候选反例。建议给 OTHER 设一个观察指标——OTHER 占比长期偏高说明标签集覆盖不足，偏低则要抽查是否模型在硬归类。这两条都只能靠日志统计确认，不要凭感觉调。

用边界样本跑一轮看哪两类互相吞并

边界样本不需要多，建议每个标签准备若干条“像又不完全像”的句子，结构上至少包含：本类典型句、跨类易混句、信息缺失句、多意图混合句。样本来源优先用历史工单里标注人争议过的条目，这类句子最能暴露边界问题。

跑完后整理成混淆矩阵表格，行是人工标注的真实标签，列是模型输出标签，对角线是正确项，非对角线的较大数值就是吞并信号。例如“退款进度查询”被大量判成“退款申请”，说明两者的定义判据没起作用，而不是模型能力问题。读矩阵时先看非对角线的集中位置，再看 OTHER 这一列和这一行：OTHER 列偏大说明兜底太松，OTHER 行偏大说明标签覆盖不足。

真实\预测     退款申请  退款进度  OTHER
退款申请        18        2       0
退款进度         7       11       2
OTHER            1        1       9
（示例结构，实际数值以本地跑出的矩阵为准）

发现吞并后的返工动作按顺序做：先改定义判据而不是加标签，把两类的区分说明补成一句可判定的条件；再给被吞并的一方补两条反例；然后重跑同一批边界样本，看非对角线是否收敛。只有在改完定义和反例后仍然分不开时，才考虑把两类合并成一个标签，交给同一个团队处理。每次返工都要把改动记进标签配置的变更记录，避免多人同时改出两个版本。