上海客服小组周五上线前的双语草稿实测

上海客服小组的周五上线任务

上周，我们在上海一个跨境 SaaS 客服小组里做了一次限时实测。目标很具体：让模型根据中文客户工单生成英文回复草稿，同时保留订单状态、退款规则和技术步骤；遇到英文客户来信时，再生成中文内部摘要，方便一线客服快速判断优先级。

测试安排在周五上线前完成。我们准备了 60 条脱敏工单，覆盖登录失败、重复扣款、发票修改、接口报错、账号停用和退款申请六类场景。其中 30 条来自中文客户，30 条来自英文客户。每条工单都附带一份内部处理规则，但规则中的产品名、时间限制和金额不能被模型改写。

60 条工单里的准确性和遗漏情况

Qwen3.7 Plus 的第一轮表现比较稳定。它能识别中英文混合文本，也能把客户描述拆成问题、背景和请求。对于退款类工单，它通常会先确认付款状态，再说明处理时限，避免直接承诺退款。技术类工单则会保留接口路径、错误代码和复现步骤，中文摘要也足够短，适合客服在工单列表中快速浏览。

我们把回复分成“可以直接发送”“需要轻微修改”和“必须重写”三档。60 条草稿中，38 条可以直接发送，17 条只需要调整称呼、时间或语气，5 条需要重写。需要重写的案例主要集中在上下文不完整的工单：客户只写了“还是不行”，却没有提供账号、时间或错误信息。模型会提出合理的追问，但客服仍需检查是否符合团队的标准模板。

• 中译英客服草稿：专业术语保留较好，语句自然度达到可编辑状态。
• 英译中内部摘要：能压缩冗长背景，通常不会遗漏客户的明确诉求。
• 规则执行：对退款时限和人工审核条件较敏感，但仍需要在提示词中重复关键限制。
• 异常工单：输入信息不足时会主动追问，少数情况下会把推测写得过于确定。

语气、上下文和实际处理速度

客服主管最关心的不是单句翻译，而是草稿能否保持品牌语气。我们在提示词里加入了三条要求：先承认客户遇到的问题，再给出下一步；不使用夸张道歉；不能暗示尚未确认的结果。经过这组约束后，英文回复不再显得生硬，中文摘要也没有出现面向客户的客套话。

每条工单只保留最近 12 轮对话，并把产品规则放在单独的上下文区。这样做能减少旧信息干扰，也能控制输入长度。在内部测试环境中，普通工单大多在几秒内返回，长对话的延迟更明显。对客服来说，这个速度足够支持“打开工单、检查草稿、发送回复”的工作节奏，但不适合把模型直接放进实时聊天窗口，等待时间仍需要前端提示。

我们还把模型输出限制为三个字段：客户意图、内部摘要、待发送回复。固定结构让客服更容易检查，也方便后端记录人工修改内容。上线前应加入敏感字段遮蔽、金额校验和人工发送按钮，避免草稿生成流程绕过现有审核。

按量使用成本和接入方式

这次测试没有为低频客服场景购买固定套餐，而是按实际调用量计算。对于每天几百条工单的团队，按量方式更容易先验证节省的人工时间，再决定是否扩大范围。我们通过 RelayVano 调用 Qwen3.7 Plus，使用兼容 OpenAI 的 SDK 接入现有服务，API base 设置为 https://api.relayvano.com。开发团队也可以把同一套调用方式接入 Claude Code、Codex 或 Gemini CLI。

接入时建议把模型参数、提示词版本和人工修改结果一起记录。这样一周后可以计算三个真实指标：每条工单节省多少分钟、草稿被修改的比例，以及因事实错误造成的返工次数。单看生成速度容易得出片面的结论，客服团队更需要关注最终发送前的检查成本。

周五上线后的范围和明确推荐

这次实测表明，Qwen3.7 Plus 适合承担双语客服的第一版草稿工作，尤其适合规则清楚、问题类型重复、必须保留上下文细节的工单。它不能替代客服判断，也不应该自动发送涉及退款、账号安全或法律承诺的回复。我们建议先覆盖邮件和异步工单，把人工审核保留在发送按钮之前，再根据修改率扩展到更多场景。

如果你的团队需要在中英文之间快速整理客服信息，我推荐使用 Qwen3.7 Plus，并通过 RelayVano 以按量方式接入，先用一周真实工单验证准确率和节省时间。准备好开始测试后，可以注册 RelayVano，使用现有的 OpenAI 兼容客户端连接 API，并从 20 到 50 条内部工单的小批量试运行开始。