想把 GPT-Live 这类实时语音模型直接替掉整段客服流程，通常先别做整体替换。更稳的做法是先做一份能力边界清单：把流程拆成可枚举的环节，逐项标注可自动、需人工、需规则兜底，把不适合自动化的环节提前挡在方案外。这样做的目的不是压缩模型的使用范围，而是让上线后需要返工的部分在方案阶段就暴露出来。判断一个环节能不能交给语音模型，看的是三件事：输入是否只来自公开知识或只读查询、输出是否会改变系统状态、失败后能否被下一轮对话纠正。这三件事里任意一件无法从配置、日志或页面行为确认，就先按需人工处理。

目标是用实时语音模型承接客服语音而不是替掉整段流程。可先做的动作是按询问、确认、办理、安抚拆环节，逐项标注可自动、需规则、需人工，再把涉及金额、身份核验、投诉升级的环节单列人工触发条件。验证方式是用一批脱敏的真实对话做离线走查，看每个环节在日志里是否留下可判断的输入与输出。任何环节若无法通过配置项、接口返回字段、页面状态或日志行确认结果，暂时按需人工处理，并记入存疑清单。

把客服流程拆成询问、确认、办理、安抚四类环节

拆解的目的不是把流程画得漂亮，而是让边界讨论落到具体环节上。可以先按用户想拿到的结果来分类，而不是按话术分类，因为同一句话在不同环节的风险完全不同。

判定某一段属于哪一类，看用户的最终诉求，而不是看开场第一句。用户说「你们这个怎么回事」可能落在安抚，也可能是询问进度；把同一通对话里出现的多个诉求分别归到不同环节，边界才不会被一句模糊提问带偏。

给每个环节标注能否交给语音模型处理

初版标注只落三种结果，先不要设中间态，否则清单会失去筛选作用：可自动、需规则、需人工。可自动指输入来自公开知识或只读查询，输出不改变系统状态，说错了下一轮能纠正；需规则指本来可自动，但需要金额上限、字段白名单、固定话术模板这类硬约束，规则外一律转人工；需人工指涉及资金变动、身份核验、合同或赔偿承诺、投诉升级。

• 标注必须写判断依据来源：配置项名称、接口返回字段、页面可见状态、日志行，四类里至少落到一类。
• 写不出依据来源的标注，视为未完成，先归到存疑项，不要直接写可自动。
• 存疑项单独记，不混进正式清单，避免上线前看起来边界已经划完。

存疑项记录模板（字段名按自己系统替换）
环境: 预发 / 生产只读
环节: 办理-修改收货地址
存疑原因: 修改后是否触发风控校验，现有日志看不出来
判断依据来源: 写接口返回中的风控状态字段（字段名待确认）
验证方式: 用测试单号走一次写接口，对照返回与页面状态
关闭条件: 能稳定复现，并据此写进规则或转人工清单

找出必须保留人工介入的触发条件

触发条件清单要写在路由之前，而不是写在提示词之后。提示词约束的是表达，触发条件约束的是「这句话该由谁来说」。可以先从下面这几类开始列，再按自家业务补充。

• 涉及金额：退款、赔付、改价、补发优惠券、运费争议。
• 身份核验：改绑手机号、查询他人订单、变更开票信息、修改实名信息。
• 投诉与升级：用户明确说投诉、找监管、找媒体、走法律途径。
• 承诺类措辞：保修期、时效保证、赔偿口径，模型无权对外承诺。
• 情绪与安全：辱骂、威胁、涉及自伤或人身安全的表达。
• 重复失败：同一问题在短时间反复提问，次数阈值由运营设定并写进配置。
• 技术侧兜底：识别置信度低、连续静音超时、断线重连后上下文缺失。
• 用户主动要求：明确说「转人工」时不要挽留。

# 通用兜底规则骨架，字段名与阈值按自己系统替换
handoff_rules:
  - id: amount_related
    match: [退款, 赔付, 改价, 补发优惠券]
    action: transfer_human
    reason: 涉及资金
  - id: identity
    match: [改绑定手机, 查询他人订单, 变更开票信息]
    action: transfer_human
    note: 先走身份核验流程，不由语音模型代答
  - id: low_asr
    when: 识别置信度低于运营设定阈值
    action: 重问一次，仍低于阈值则转人工

设计一次人机交接的观察口径

交接顺不顺畅，只有当它变成日志里的字段才可观察。建议按交接前、交接中、交接后三段记录状态变化，而不是只记一句「已转人工」。

• 交接前：模型是否说明转接原因，是否把已确认信息写入上下文，是否告知用户等待。
• 交接中：等待时长、是否播放等待提示、人工坐席接手时是否拿到完整上下文。
• 交接后：人工是否重复询问同一信息，用户是否重复陈述，是否出现二次转接，会话是被正常结束还是中途挂断。

交接观察记录表（每通含交接的会话一行）
会话ID | 环节 | 触发条件 | 交接前模型是否说明原因 | 上下文是否带过去 | 人工是否重复询问 | 是否二次转接 | 备注

观察口径确定后，先小范围跑一段，用记录表判断交接是策略问题还是配置问题。如果人工反复询问同一信息，通常先看上下文传递字段，而不是先改模型提示词。

用一批真实对话做上线前离线走查

离线走查的价值在于把边界外的情况在投入之前暴露出来。样本可以从历史会话里取，按询问、确认、办理、安抚四类分层，每一类都要有，并同时包含曾经转人工的会话和全程由人完成的会话。涉及手机号、地址、证件号、订单号的内容先脱敏再回放。

1. 逐条回放，按「用户输入 → 模型输出 → 是否触发规则 → 是否应转人工」四栏记录。
2. 结论只落三种：可直接自动、需加规则、转人工，不写「待观察」以外的模糊结论。
3. 把触发规则但实际没转的样本单独挑出来，这类通常是规则生效顺序或字段匹配问题。
4. 走查结束后核对存疑清单，能关闭的关闭，不能关闭的保留在需人工一侧。

不合格样本不要为了迁就模型而修改样本本身。先分清是识别问题还是策略问题：识别问题回看语音识别、打断与静音配置；策略问题回看提示词与触发规则；暂时定位不了的按需人工处理并写进存疑清单，不阻塞其他环节先上线。样本数量按环节覆盖来定，先保证每类环节都有可复现的样例，再考虑扩充总量。