人机协同国标给了可对照的条目：把它翻译成工单字段和验收动作
一、推荐性不等于不用管
《顾客联络服务 人工与智能客户服务协同要求》（GB/T 47746—2026）由国家市场监督管理总局与国家标准化管理委员会发布，是全国服务标准化技术委员会归口的推荐性国家标准，也是我国首个聚焦人工客服与智能客服协同机制的国家标准。推荐性意味着它不直接产生强制后果，但它确实改变了两件事。一是外部有了可主张的口径，消费者、监管沟通、平台争议里都能引用同一组说法；二是甲方在采购与验收时，第一次有了一份现成的条目清单，不必自己从零写”人机协同应该是什么样”。
标准正文的具体条款文字我们不做逐字引用，公开可读到的方向是清楚的：人工入口要清晰醒目、不能层层藏在菜单之后；转人工要支持关键词、菜单、按键、语音多种触发；智能客服交互失败达到设定阈值时自动转人工；人机切换时同步客户信息，消费者不必重复描述；价格、退款、赔偿等关键事项由人工最终确认；老年人、未成年人等特殊群体优先转接人工；企业落实客户信息分级安全保护；企业对 AI 答复承担主体责任。
据公开报道，有媒体对若干平台做过实测，人工入口依旧不好找。这类观察只说明现实与条目之间还有距离，它不是我们做设计的依据，也不构成对任何平台的定性。真正的成本在另一处：把每一条方向变成一个能测的字段。我们做客服系统改造时的习惯是把外部口径拆成四列——标准方向、工单或埋点字段、测试方法、判定值，其中最容易缺的是第三列，多数团队写了字段却没写测法，字段就变成了报表里一个没人核对的列。
二、入口清晰度：三项要能出报表
入口这件事最容易靠感觉判断，”我们自己用起来挺方便的”通常不算证据。要落的量有三个：入口在第几层菜单、几种触发方式分别是否生效、夜间与大促时段有没有人承接。
字段设计上，入口层级要记的是从任意落地页抵达人工入口的点击深度，这个值在不同渠道不一样，必须按渠道分别出数，不能只测一条路径；入口标识要记它在当前页面是否可见、是否被折叠；触发方式要按关键词、菜单、按键、语音四类分别记录触发次数、命中次数与成功转接次数；承接情况要记当班坐席量、排队长度、超时未接起次数与弃队次数，按时段切片。
测法上有三条固定动作。第一，四类触发方式各写一条脚本，在电话、网页、App、小程序四个渠道各跑一遍，逐条留路径截图，而不是只跑一次”看起来能用”的路径。第二，点击深度用真实用户入口作为起点，而不是从后台配置的逻辑视图数层数。第三，承接报表按时段切片看，重点是非工作时段，那里最能暴露”入口存在但没人接”这种情况。
实现中最常见的坑有两个。关键词触发常常只挂在机器人节点上，用户在菜单层或排队层输入的那句”转人工”根本不进判断；语音触发的识别结果与坐席侧的转接动作不同源，日志对不上，事后无法归因是哪一步没生效。这两类问题不是靠加埋点字段解决的，是要把触发判定与转接动作放进同一条链路里记录。
三、失败阈值：先把失败变成可计数的量
标准方向里”交互失败达到设定阈值应自动转人工”这一条，落地时的第一个问题不是阈值取多少，而是失败计什么。可计数的信号有四类：同一意图被反复澄清的次数、用户主动要求人工的词句命中、负面情绪与投诉意图的判定结果、单个会话的总轮次。四类信号各测一个方向，前三类是质量信号，最后一类是兜底信号。
阈值要按业务线分别设，不能全局一个数。账单查询类会话轮次天然短，几轮不收敛就该转；售后纠纷类天然长，用同一个数会把大量正常会话提前推给坐席，也会把真正卡住的会话淹没在里面。洹拓在项目里的做法是把阈值当成配置项管起来：写入配置中心、带版本号、改动走变更流程并留记录，同时明确改动的审批人。每次自动转人工都要落一个触发原因字段，记录是哪一类信号在哪一轮命中，否则事后无法区分用户主动要求与系统判定失败，两类问题的处置方式完全不同。
还要留一个反向指标。自动转人工之后，坐席判定为”没有必要转”的比例要能统计出来。只看转人工率会得出一个荒谬的结论：把阈值调到最低，转人工率最高，看起来最符合条目要求，实际是把成本整体推给了人工侧。判定值由我们自己设，但设完要能被复核。
四、切换不重复询问：传结构化对象，不要传整段记录
“切换时同步客户信息，消费者不必重复描述问题”这一条被引用的次数最多，被实现得最敷衍的次数也最多。最常见的做法是把整段聊天记录原样推给坐席窗口，等于把重复描述的责任换了个承担者，从消费者转移给坐席的阅读能力。
真正要传过去的是一组结构化对象：
- 会话上下文摘要：一句话诉求、涉及的产品或订单、消费者情绪状态标记
- 已核验的身份要素：核验了哪些项、用什么方式核验、核验发生在哪一次交互，明文证件号不在传输范围内
- 已提交的业务单号与附件：工单号、单据类型、附件标识，而不是附件原文的重复上传
- 当前流程节点：节点名、上一个完成的动作、待人工完成的动作
- 智能侧已尝试的处理方案与失败原因：这条决定了坐席要不要换一个方向
这里的关键工程约束是字段命名要在人机两侧共用一套数据字典。机器人写”订单号”，坐席系统写”业务流水”，两边就接不上。摘要由谁生成、生成规则是否随模型版本变化、原始会话留存多久、坐席是否有权回看原文，这几件事要在设计阶段一次性定下来，不要等到上线后再补权限。
五、关键事项人工确认与优先转接
价格、退款、赔偿等关键事项由人工最终确认，落到流程引擎里是一件很具体的事：把节点标成”必须人工签字”。要标的节点至少包括改价、退款、赔付、解约、对外承诺时限五类，标注方式是节点属性而不是流程注释——属性可以被引擎强制执行，注释只能靠人自觉。机器人节点在这五类上不允许直接触发资金或契约动作，只允许生成待人工处理的工单。
每一类确认动作要留下四个字段：动作发生时间、操作人身份、判定依据来源（引用哪一条规则或哪一份单据）、以及被确认内容的快照。快照这一项经常被省掉，省掉之后一旦客户对处理结果有异议，你无法还原坐席当时看到的金额与条款。
优先转接特殊群体这一条，落地的分寸在于识别依据要克制。主动说明优先于系统推断：在意图识别里给”用户自述需要人工帮助”这类表述一个高优先级入口，同时在坐席侧提供手工标记为需优先的动作。不建议让系统单凭操作速度、输入特征去推断年龄或群体归属，误判的代价是把不想被打扰的人推进一条更慢的队列，也让人工侧的接待量出现无法解释的波动。判断依据是什么、由谁给出，这个字段本身要记录。
六、答复可回溯到版本，以及四步自查
企业对 AI 答复承担主体责任，这句话的工程翻译只有一句：这条答复要能回溯到作出它时所用的那一版内容。落法是每条对外答复在日志里带三元组——模型标识、知识库版本、规则集版本。有了这三项，”这句话当时依据的是什么”才有确定答案；缺一项，责任边界就会变成一串无法核对的推测。这也是”答复改了但没有版本记录”这类事故的根源：知识库悄悄更新，前端行为变了，谁也说不清是哪一次改动造成的。
信息分级保护按三类分开处理：客户身份要素、支付相关信息、地址与联系方式。三类的访问范围、脱敏规则与访问留痕方式都不同，共用一套权限模型等于没有分级。留痕要记到人、到时间、到被访问的字段类别，而不是只记一条”查询了客户资料”。
标准方向、字段、测法、判定值四列对照，做成一张表交给服务商比自己写十段要求有效。下面是我们在项目里实际使用的形式，判定值一列是本方设定的口径示例，需要按业务线替换，不代表标准条文：
| 标准方向 | 工单或埋点字段 | 测试方法 | 判定值形式（本方口径） |
|---|---|---|---|
| 人工入口清晰醒目 | 入口点击深度、入口可见性标记 | 四渠道各跑一条真实路径并留截图 | 深度上限按渠道分别设定 |
| 多种转人工触发方式 | 触发类型、命中次数、成功转接次数 | 关键词、菜单、按键、语音各一条脚本 | 四类触发全部有转接成功记录 |
| 失败阈值自动转人工 | 重复澄清轮次、要求人工词句命中、会话总轮次、触发原因 | 构造不收敛会话观察是否自动转 | 阈值按业务线分设且版本化 |
| 切换同步客户信息 | 上下文摘要、已核验身份要素、业务单号、流程节点、已试方案 | 抽查转接后坐席首条消息内容 | 关键字段齐备且非原文堆叠 |
| 关键事项人工确认 | 节点人工签字标记、确认时间、操作人、依据来源、内容快照 | 尝试让机器人节点直接触发资金动作 | 直接触发被引擎拒绝且留记录 |
| 特殊群体优先转接 | 用户自述需人工标记、坐席手工优先标记、判定依据 | 模拟自述表述观察队列表现 | 依据来自主动说明而非系统推断 |
| 客户信息分级保护 | 字段分级标记、访问留痕（人、时间、字段类别） | 越权访问用例测试 | 越权被拦且可审计到人 |
| AI 答复主体责任 | 模型标识、知识库版本、规则集版本 | 抽一条争议答复回查三元组 | 三项齐备且能定位到具体版本 |
自查动作四步，不需要外部配合就能做完。第一步，按自己的业务复刻一条真实路径走通，从入口到人工接起到处理完成，全程截图留证。第二步，抽若干历史会话，用上表逐条重新判定，看有多少条能过——这一步通常比第一步更能暴露问题。第三步，把结果做成给服务商的验收表，明确哪些是本期必须改的、哪些纳入下一期。第四步，把阈值与节点配置纳入变更管理，指定审批人，让改配置这件事和改代码一样有记录可查。
四步做完，一份推荐性标准就从文本变成了自己系统里的一组可复核事实。这比把它贴在流程文档首页有用得多。