终端里的客服草稿：MiMo V2.6 Pro 中文回复并排审阅

MiMo V2.6 Pro 接手退款催办草稿

写客服自动化时，我最怕的不是句子生硬，而是模型替业务承诺。我会把工单事实放进固定输入，再让模型只负责组织语言。这次围绕 MiMo V2.6 Pro 和 Claude Sonnet 5.5 做并排审阅，问题很具体：面对着急退款的中文用户，哪种草稿更适合接进人工审核队列？

先划清边界：下文是用于设计评测的示意草稿，不是两款模型的实测输出，也没有延迟、价格或胜率数据。它展示的是比较方法，不能拿来证明某个模型已经胜出。

同一张退款工单，同一套事实约束

工单内容是：“订单取消三天了，钱怎么还没退？你们是不是不想退？”后台只确认订单已取消、退款申请已提交，尚未收到支付渠道的到账回执。这里的“三天”来自用户描述，不能自动解释成三个工作日。

我会在提示词里要求：使用简体中文，先回应焦虑，再说明已知状态，最后给出下一步；不得编造到账日期、退款金额或已经升级处理的记录；缺少信息时，只索取完成核查所必需的字段。两边使用相同输入和输出上限，并记录请求参数，避免把提示词差异误认为模型差异。

MiMo V2.6 Pro 与 Claude Sonnet 5.5 的并排审阅样张

左栏，MiMo V2.6 Pro 待验证的目标草稿：“等了三天还没收到退款，确实会让人着急。目前订单已取消，退款申请也已提交，但我们还没有收到支付渠道的到账回执，因此暂时无法确认到账时间。请提供订单编号，方便进一步核查。”

右栏，Claude Sonnet 5.5 待验证的目标草稿：“理解您想尽快确认退款进度。目前能确认订单已取消、退款申请已提交，但尚未收到支付渠道的到账回执，所以暂时不能承诺具体到账日期。请提供订单编号，以便核查后续状态。”

把它们放进编辑器的左右分栏，差异就容易看见：左栏更口语化，右栏更克制；两边都保留了未知状态，也没有把“提交申请”写成“退款成功”。但这些只是样张的文本差异，不是模型能力结论。如果工单上下文已经带着订单编号，两段末句都应删除，不能让用户重复提供。

终端评测先拦承诺，再看中文语气

实际接入时，我会把输入、原始输出和人工修改稿分别落盘，再用终端查看差异。第一轮检查是否捏造日期、金额和处理动作；第二轮检查是否遗漏关键状态；最后才比较客气程度、句子长度和修改量。单纯统计礼貌词没有意义，多写几句道歉也不等于更能解决问题。

样本还要覆盖重复催问、情绪激烈、信息不足和已经到账却未更新状态等情况。每条分别记录事实错误、越权承诺、无效追问，以及审核者实际修改的内容。若要比较耗时，也应把重试和人工返工算进去，而不只盯着首个响应。

Fluxo 让同一份评测脚本切换模型

这类脚本可以通过 Fluxo 保持接入一致：一个密钥和一个基础地址 https://api.fluxorelay.com，即可访问 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等系列。这里不需要为每个候选重写客户端，但仍要检查各模型的参数支持和返回字段。

Fluxo 可配合 Claude Code、Codex、Gemini CLI 和任何 OpenAI SDK 使用，按实际 token 计费，缓存读取和写入也计入，没有月费。评测账本因此应同时记录输入、输出与缓存用量。邀请的人付费后，邀请者还能获得推荐分成，但这不应影响选型判断。

如果你也想复用这套工单评测，可以创建一个 Fluxo 账户，从脱敏样本开始；需要帮助时，登录后在联系页面留言即可。

MiMo V2.6 Pro 的明确结论：先做草稿，不做自动发送

我的结论是：可以把 MiMo V2.6 Pro 放入中文客服草稿候选，但目前不能宣称它优于 Claude Sonnet 5.5，更不该仅凭流畅程度上线自动发送。先用真实脱敏工单验证事实边界和人工修改成本，再决定默认模型。对退款回复而言，少一句虚构承诺，比多一句漂亮安慰重要。