把 Grok Voice 3.0 接进客服语音链路，第一件要定的事不是音色或延迟，而是回答权限：哪些问题模型可以凭已有话术直接答，哪些必须先查业务库再组织语言，哪些一句话都不能自己下结论、必须转人工。判断标准很朴素——只要答案依赖某个具体用户的实时数据，或者一旦说错就构成承诺、报价、法律表态，就不该交给模型自由生成。接入前建议先把这三类问题列成清单，写进系统提示词和前置路由，再用日志验证模型是否真的照做。

语音客服里，模型只负责“把已确认的事实说清楚”。订单、账单、账户状态、物流这类依赖实时数据的问题，必须先查库、查到再答，查不到就明确说未查到；投诉、法律、退款争议、人身安全等触发词命中后直接转人工。涉及金额、日期、承诺的句子在输出前做一层可记录的校验与改写，转人工时由系统写入结构化交接字段。所有规则都要能在日志、配置和通话回放中复核，而不是只写在提示词里。

列出必须先查库再回答的问题类型

做法是把语音链路拆成“识别意图 → 判定是否查库 → 查询 → 用查询结果拼回答”。凡是下面四类问题，都不要让 Grok Voice 3.0 凭上下文自由作答，而是先走一次查询，把结果作为事实片段注入回答。查询失败或返回空时，回答话术固定为“这边没有查到对应记录”，不要用推测填补。

• 订单类：判断依据是问题里是否出现订单号、下单手机号、收货人、商品名加“买了/什么时候到/能不能改”。命中即按订单号或手机号查订单状态、支付状态、是否已发货。
• 账单类：判断依据是账单金额、扣费原因、发票、分期、退款到账时间。必须查账单流水和退款单，不能按常见规则口头解释。
• 账户状态类：判断依据是登录异常、封禁、实名、会员有效期、绑定手机变更。必须查账户表当前状态，模型不得根据“用户说自己是老用户”推断权益。
• 物流类：判断依据是运单号、承运商、配送进度、改地址。必须走物流查询接口，返回空就说明暂无轨迹，不得编造“正在派送”。

在配置上，建议用一层意图路由把这些实体先抽出来，查询成功才允许进入回答生成：

{
  "route": "query_first",
  "intents": ["order_status", "bill_detail", "account_state", "logistics"],
  "required_slots": {
    "order_status": ["order_id|phone"],
    "bill_detail": ["account_id|phone"],
    "account_state": ["account_id|phone"],
    "logistics": ["tracking_no|order_id"]
  },
  "on_missing_slot": "ask_once_then_handoff",
  "on_query_empty": "reply_not_found_no_guess"
}

这段配置是通用骨架，槽位名和字段要换成你自己系统的叫法。验证方式很直接：在日志里看每次通话是否产生了查询记录，以及模型回答里的关键事实是否来自查询结果而不是模型自述。

列出必须转人工的触发词与情境

触发词的作用是给模型划一条不能越过的线。建议按四类建清单，匹配方式用“关键词 + 正则 + 语义判定”三层：关键词负责快，正则负责金额、时间、证件号这类模式，语义判定兜住换了说法的表达。任何一层命中即标记，不要只依赖模型自己判断“要不要转”。

• 投诉类：投诉、曝光、12315、消协、找媒体、你们骗人、要举报。
• 法律类：起诉、律师、法院、报警、追究责任、合同违约。
• 退款争议类：必须退、全额退、不同意方案、已经申请多次、退款多久没到且情绪激烈。
• 人身安全类：受伤、过敏、漏电、起火、孩子误食、威胁自伤。

命中后是立即转接还是先安抚再转接，选择依据看风险等级和等待时长：人身安全、法律、明确投诉倾向的，建议立即转接并播放固定安抚语，不做任何解释性承诺；退款争议但用户情绪尚可控的，可以先复述诉求、说明正在转接，再进入排队。所有触发都要写日志，记录命中词、匹配层、转接时间点，便于回放复核。

给涉及金额与承诺的回复加一层校验

模型最容易出问题的地方，是把“可能”“通常”说成确定承诺。建议在语音输出前加一道文本校验：先识别金额、日期、期限、承诺类用语，再决定放行、改写还是拦截。规则要配置化，并且每次命中都留记录，做到可复核。

checks:
  - name: money_claim
    match: "(\\d+[\\.\\d]*\\s*(元|块|人民币))|退款|赔付|补偿"
    action: require_source   # 必须带上查询结果字段
    on_missing: rewrite_to_neutral
  - name: date_claim
    match: "(今天|明天|\\d+个工作日|马上|立刻|一定)"
    action: require_source
    on_missing: rewrite_to_neutral
  - name: promise_words
    match: "(保证|承诺|肯定|百分百|包退|包赔)"
    action: block
    log: true
rewrite_to_neutral: "具体到账时间以系统记录为准，这边帮您再确认"

规则设计上有两点要注意：一是拦截不要静默，命中后必须写日志，包含通话 ID、原句、命中规则、最终输出；二是改写话术要短，语音里说太长用户会以为你在绕。验证方式是抽样回放通话，检查是否还有未经查询就出现的金额和时间。

设计一次转人工的交接内容

用户最反感的是转过去之后还要从头再讲一遍。交接内容建议由系统结构化写入工单，而不是让模型临场总结。 mínimo 需要四个字段：已确认事实、用户诉求、已做过的动作、未解决的问题。其中身份信息、订单号、查询结果、通话录音链接、触发词命中记录，必须由系统写入；模型最多负责把用户诉求整理成一句话，并且要允许人工修改。

{
  "call_id": "system",
  "caller_verified": "system",
  "confirmed_facts": ["system: 订单状态=已发货", "system: 退款单=处理中"],
  "user_request": "model_draft: 用户希望今天内确认退款到账时间",
  "actions_done": ["system: 已查询账单", "system: 已发送短信"],
  "open_issue": "system: 退款到账时间无法在语音端确认",
  "trigger_hit": "system: refund_dispute",
  "recording_url": "system"
}

交接模板要能在客服工作台直接看到，字段为空时明确显示“未获取”，不要留空让坐席猜。验证方式：随机抽几通转接电话，看坐席是否需要再次询问订单号或身份信息。

用十通模拟电话压测边界

规则写完不等于生效，建议用十通模拟电话专门压边界。脚本设计方法是：四通覆盖必须先查库的四类问题（订单、账单、账户、物流），其中两通故意不给订单号、制造查询为空；三通覆盖四类触发词，包含一个换说法绕关键词的投诉；两通测金额与承诺，比如用户追问“你就说今天能不能退”；一通测多人信息混说，比如报别人的手机号查订单。

每通电话记录三项：是否越界回答、是否漏触发转人工、回答中的关键事实是否来自查询。用一张简单表格维护即可：

• 通话编号、场景类型、用户原话要点
• 模型是否查库、查询结果、最终回答摘要
• 是否命中触发词、是否转人工、交接字段是否完整
• 问题归类：越界承诺 / 编造事实 / 漏转接 / 交接缺失

压测后不要只改提示词。优先级建议是：漏触发转人工的，先补触发词和匹配层；编造事实的，收紧查询前置和空结果话术；越界承诺的，加校验规则；交接缺失的，改系统写入逻辑。每改一轮，用同样十通脚本再跑一遍，对照日志确认行为确实变了。规则清单和触发词表建议纳入版本管理，改动留痕，避免上线后没人说得清哪条规则在生效。