售后 Agent 先问清产品型号，再检索维修手册怎么做

售后 Agent 定制开发，第一步常常不是换更强的模型，而是确认客户问的是哪台产品。用户说“机器亮红灯”，系统若拿相近型号的手册回答，内容可能引用正确，却用在了错误设备上。

一种可落地的流程是：识别型号是否足够明确，必要时追问；把确认后的型号和手册版本传入检索；只用匹配资料生成答复；涉及风险操作或依据不足时转给售后。下面使用虚构的 A100、A100 Pro 演示，不对应真实产品、故障代码或维修结论。

先把“型号”从自由文本变成业务字段

不要只让模型在提示词里“注意区分型号”。项目应有一张受维护的产品标识表，包含标准型号、用户常用叫法、铭牌位置、有效手册及停售后的资料负责人。输入“A一百”可以产生候选，但不能因为字符串相似就自动选成 A100 Pro。

把产品名称和设备身份分开存储。型号说明采用哪套资料，序列号可能关联生产批次、升级状态和保修记录。第一期没有序列号查询接口，可以请用户从铭牌填写；不能把没有接入的后台能力写成“系统自动识别”。图片识别也只能提供候选，模糊照片必须允许重新拍摄或人工确认。

例如两个演示型号都可能被口头称作“A100系列”，但 A100 手册版本为 M1，A100 Pro 为 P2。系统接到“这个系列怎么复位”，应先问“铭牌上是否包含 Pro”，而不是把两种复位步骤都列出来让客户猜。

给每次会话一个明确状态

状态	已知信息	允许发生的动作
待澄清	只有系列名或模糊描述	询问型号、提供铭牌定位说明
已确认	用户确认标准型号，资料版本有效	检索该型号对应的资料
依据不足	型号明确，但未找到适用说明	说明缺少依据，生成售后工单草案
需要人工	问题属于风险操作或资料冲突	只收集必要信息，转售后人员

状态应由业务代码或可审计规则维护。提示词可以帮助提问，但不能自行把“用户大概说的是”提升为已确认。再次上传铭牌后如果产品身份变化，应清理旧检索上下文；否则前一轮的 A100 片段仍可能混入 Pro 的答案。

用两份合成手册演示检索约束

准备两条完全虚构的资料：A100-M1写“指示灯含义参见第4节”，A100-Pro-P2写“指示灯含义参见第7节”。这里故意不填真实维修动作，演练只核对来源选择。给每段资料保存型号、版本、页码和生效状态。

然后逐项测试四种输入：只说系列名、明确写A100、明确写A100 Pro、型号明确但问题超出手册。第一种应澄清，第二与第三种必须引用各自资料，第四种应说明没有依据。若用户问题没有产生所需的型号字段，检索阶段不应默认搜索所有型号再让模型自行筛选。

下载型号澄清与来源核对表。表里的期望行为是演示规则，不是某个平台已测得的结果。导入自己的测试记录后，再填写实际回答、命中片段和人工判定。原始型号、标准型号和资料版本都要保留，方便追查错误发生在识别还是检索。

最容易漏掉的三个失败分支

第一，用户会在会话中改口：“刚才看错了，是Pro。”这必须触发重新路由，而不是继续沿用已经检索的片段。可以把产品身份变化记成单独事件，并要求新的回答使用新版本引用。

第二，资料里可能有旧型号的附件。仅按文件名过滤不足以说明正文没有混入别的产品；整理知识源时要核对附件归属，必要时把跨型号章节拆开。资料无法拆清时就不适合自动给出具体操作步骤。

第三，转人工时只发送“AI答不上来”会让用户重说一遍。工单应包含已确认型号、用户原话、已问过的信息、找到的资料版本和没有回答的原因。联系方式放在业务系统里，分析日志尽量只留工单标识。

怎样验收这项定制

采购方可以提供几组容易混淆的真实型号，但使用脱敏资料建立隔离测试环境。验收不只看最终答对几题，还要核对是否漏问型号、是否跨型号引用、是否把缺资料写成确定结论、转人工是否保留上下文。把正常、改口、冲突和无依据分别统计，不能用大量简单问题掩盖边界失败。

如果要接入工单系统，先约定创建的是草案还是正式工单；对用户的产品绑定信息做服务端核对。MCP的官方工具规范描述了工具与外部系统的连接及人工参与建议，但不会替企业定义售后权限。这些权限仍需落实在业务接口上。

把型号误判单独列为验收问题

统计时不要把“最终有人接手”当成前面的型号选择已经正确。一次会话先给错型号步骤、后来才转人工，仍应记为错误路由。测试记录应保留首次识别值、用户确认值、最终检索范围及纠正时点。如果某个产品别名经常被误识别，先修改别名映射或追问方式，再考虑调整模型。新增型号上线时也要补同名近似题，而不是只上传新手册就结束。

想先梳理兜底策略，可看现有客服兜底文章；资料准备从文档处理场景开始。若你的产品型号、资料版本与工单流程已经明确，可以携带一组脱敏问答到定制咨询，先评估型号路由和人工交接这一段，不必一开始承诺覆盖所有售后问题。