同一道差评回复题，10 款国产模型里最高拿了 0.98 均分，最低只有 0.43——差距不是文笔，而是最低分那款把整段思考过程原样输出给了顾客。这次模型实测围绕差评回复这个具体场景展开，翻车方式值得每个接客服类需求的人看一眼。

数据采集于 2026 年 10 月中旬的一次单轮跑批，环境为 Python 3.11 + openai SDK 1.x（另用标准库 asyncio 做并发）。所有分数对应采集当天的线上版本，厂商静默更新权重后数字会漂，复现时以你自己的跑批结果为准。

这次测了什么：一条差评、六条硬约束

任务设定很具体：扮演连锁餐饮品牌的客服总监，回复一条大众点评差评。差评原文混合了可核查事实（等了 40 分钟、餐位费没提前告知）和主观判断（「后厨绝对是摆烂」），还埋了一个正反馈支点（「招牌酸菜鱼倒是不错」）。门店核查事实和顾客口述有出入——系统记录是 38 分钟，不是 40 分钟。

难点在六条硬约束：不超过 180 字且公开可见；等待时间只能认「38 分钟超标」，认了「40 分钟」就造成事实认定混乱；餐位费致歉但免除不需要；「后厨摆烂」不得回应，回应即抬杠；「酸菜鱼不错」必须接住；补偿上限是「下次到店免餐位费」，不许给霸王餐。这六条各自卡住一个维度，裁判模型 gpt-5.6-sol（非参赛款）按七维各打 0-1 分。

评测流水线怎么搭

整个流水线分四段：构造带核查事实的提示词、并发调用 10 款模型、对原始输出做长度与 <think> 标记的机械校验、裁判七维打分后汇总。坑在这里：思考链外泄不是裁判主观扣分，机械校验一抓一个准，所以校验环节必须放在裁判打分之前。

核心脚本框架如下，断点续跑靠 outputs 目录里以模型名命名的 JSON 缓存，跑挂了重跑会跳过已有结果：

import os, json, asyncio
from openai import AsyncOpenAI

client = AsyncOpenAI(
    api_key=os.environ["SILVAMUX_API_KEY"],
    base_url="https://www.silvamux.com/api/v1",
)

MODELS = [
    "deepseek-v4-pro", "glm-5.2", "kimi-k2.6", "qwen3.6-plus",
    "glm-5.3-flash", "qwen3.5-flash", "glm-5.3", "kimi-k3",
    "minimax-m2.7", "minimax-m3",
]

async def run_one(model, prompt):
    cache = f"outputs/{model}.json"
    if os.path.exists(cache):          # 断点续跑
        return json.load(open(cache))
    resp = await client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        temperature=0.7,
    )
    out = {"model": model,
           "text": resp.choices[0].message.content,
           "usage": resp.model_dump()["usage"]}
    json.dump(out, open(cache, "w"), ensure_ascii=False)
    return out

async def main(prompt):
    return await asyncio.gather(
        *[run_one(m, prompt) for m in MODELS])

调用名照抄模型广场详情页的稳定 alias，别按展示名自行拼接。温度固定 0.7，全部走兼容端点，已有 OpenAI SDK 代码只改 base_url 和 api_key 两处即可迁移。裁判打分同样走这个端点，把差评原文、六条约束、模型原文一起塞进 system 提示词，要求返回 JSON 格式的七维分数。

排名结果：头部挤成一团，尾部断崖

模型	受众契合	合规	事实性	格式	语言	说服力	选材	均分	耗时
DeepSeek-V4-Pro	0.96	0.98	1.00	1.00	0.96	0.95	1.00	0.98	19.08s
GLM-5.2	0.96	0.98	1.00	1.00	0.94	0.93	0.99	0.97	15.26s
Kimi-K2.6	0.95	0.96	0.98	0.99	0.93	0.89	0.98	0.95	26.62s
Qwen3.6-Plus	0.94	0.89	0.98	1.00	0.96	0.91	0.98	0.95	47.08s
GLM-5.3-Flash	0.90	0.84	0.76	0.95	0.87	0.85	0.93	0.87	72.07s
Qwen3.5-Flash	0.90	0.88	0.78	0.98	0.84	0.88	0.82	0.87	42.48s
GLM-5.3	0.87	0.95	0.76	0.82	0.84	0.86	0.83	0.85	56.5s
Kimi K3	0.84	0.76	0.67	0.62	0.84	0.83	0.80	0.77	74.84s
MiniMax-M2.7	0.68	0.48	0.88	0.20	0.72	0.62	0.42	0.57	9.08s
MiniMax-M3	0.38	0.76	0.72	0.05	0.42	0.48	0.18	0.43	30.64s

前四名挤在 0.95 到 0.98 之间，基本是同一档。第 5 到第 7 名掉到 0.85 一档，主要失血在事实性——0.76 到 0.78 这个区间说明「不认 40 分钟」这条约束开始守不住了。第 9、10 名是断崖：格式维度 0.20 和 0.05，原因下面细说。

高分范本与翻车现场：一好一坏对照着看

DeepSeek-V4-Pro 为什么拿 0.98

裁判给事实性 1.00 的理由是：准确表述「首菜用时38分钟」「超过25分钟标准」及菜单右下角标注、未口头提示等核查事实，未误认 40 分钟。说服力 0.95 的理由是既明确认错又提供适度补偿，并以「认可招牌酸菜鱼」承接正反馈。看原文（DeepSeek-V4-Pro）：

非常抱歉给您带来不愉快的用餐体验。您反馈的等餐问题，我们核查系统记录：首菜用时38分钟，确实超过我们25分钟的出餐标准，这点是我们没做好，向您诚恳致歉。餐位费在菜单右下角有标注，但服务员未做到口头提示，也是我们服务疏忽，抱歉。很开心您认可招牌酸菜鱼，谢谢这份鼓励。为表歉意，下次到店可为您免去餐位费。希望还能有机会让您看到改进。

六条约束一条不落：认 38 不认 40，餐位费致歉不免除，没碰「后厨摆烂」，接住了酸菜鱼，补偿卡在免餐位费，字数在限内。说白了，这不是文笔赢的，是约束遵循赢的。GLM-5.2 的 0.97 几乎是同款打法，只是语言维度 0.94 略低。

MiniMax-M3 为什么只有 0.43

最低分的失分不在文案本身，在交付形态。裁判给格式 0.05 的理由：作品包含篇幅巨大的 <think> 分析，整体远超「不超过180字」的硬性要求，也不是一条可直接公开发布的纯回复。原文开头是这样的（MiniMax-M3）：

Let me analyze this carefully:

The review says:

1. Waited 40 minutes for first dish, urged 3 times
2. Service attitude OK but kitchen “摆烂” (slacking)
3. 3 yuan per person table fee, not told in advance
4. The signature 酸菜鱼 was actually good though

Facts from store check:

• Saturday night, full house
• That table waited 25 min (system record)
• First dish took 38 min (over standard of 25 m…（后文省略）

整段英文思考链裸露在正文里。更麻烦的是裁判在合规维度还点名「主厨的看家功夫」带有无依据的宣传意味，且公开暴露内部推理不妥——MiniMax-M2.7 同样把思考链当回复输出，节选里能看到它在逐条复述六条约束，合规直接掉到 0.48。M3 的受众契合 0.38 和选材 0.18 说明最终正文部分也偏得厉害。如果这类输出直接进了发布队列，等于把内部话术标准贴到大众评论区。

为什么思考链会吃掉 0.5 的均分：MiniMax 两款的失分机理

推理链外泄进输出窗口

两款 MiniMax 的共同死法是 <think> 标记出现在 message.content 里，而其余 8 款没有这个现象。更可能的解释是：这两款模型在本次调用的链路上把推理内容直接拼进了正文通道，而其他模型要么推理在独立字段返回、要么本次任务没触发深度推理。约束越复杂，思考链越长，「180 字上限」这种输出长度预算就被推理过程整个吃掉——M3 的事实性其实有 0.72，说明它想明白了，只是没把想明白的部分和想的过程分开。

长约束清单下的事实漂移

中段三名（GLM-5.3-Flash 0.76、Qwen3.5-Flash 0.78、GLM-5.3 0.76）的事实性失分呈现另一个模式：约束清单有六条，提示词里「不认 40 分钟」排第二位。从 GLM-5.3-Flash 的节选能看出它开头用「等了半个多小时」做了软化处理——这类模糊化表述回避了 38 与 40 的取舍，裁判按未准确认事实扣分。头部四款则全部逐字写了「38分钟」。推断是：约束条数增多后，指令遵循从「逐条执行」衰减为「大意执行」，位于清单中段的数值型约束最先被牺牲。裁判模型本身也有偏好——它对精确数值表述的奖励可能高于人类顾客的实际感知，这点要留个心眼。

这份排名的适用边界

单次采样与单一裁判

每个模型只跑了一次，temperature 固定 0.7。0.95 和 0.98 之间的分差完全可能在第二次跑批里互换。补洞做法：关键选型至少跑三轮取中位数，并补一组不同温度的对照。裁判只有 gpt-5.6-sol 一款，没有交叉验证，换一个裁判维度权重可能变化——补洞做法是加一个不同家族的裁判取均值。

单任务不能外推成能力结论

这是一条差评回复题，七维是围绕这个任务设计的。MiniMax-M3 在别的任务上未必翻车，DeepSeek-V4-Pro 也不代表它在代码或长文上同样强。另外分数只对应采集当天的线上版本，厂商静默更新后必须重跑。七维等权求均分也掩盖了维度重要性——对差评回复这个场景，合规和事实性的权重理应高于语言分，若按业务加权重算，Qwen3.6-Plus（合规 0.89）和 Kimi-K2.6 的位次可能变动。补洞做法：拿到原始七维分数后按自己的业务权重重算一次。

选型建议与常见问题

从分数结构看建议很直接：生产环境的差评回复，格式分低于 0.9 的款直接出局——MiniMax-M2.7 和 M3 的思考链外泄意味着上线路前必须加机械过滤层。头部四款里，GLM-5.2 耗时 15.26s 最短且七维无短板，适合批量场景；对事实精确度要求最高（比如涉及赔付认定）时，DeepSeek-V4-Pro 的事实性 1.00 和选材 1.00 更稳。中段三款慎用的原因是事实性 0.76 一档——「38 还是 40」这种数字一旦写错，公开回复就是二次事故。

常见问题

Q1：MiniMax 两款把 输出出来，脚本层能兜底吗？

能兜一部分：落盘后用正则剥掉 <think>...</think> 再送裁判，格式分会回升，但 M3 合规维度的「主厨的看家功夫」这类宣传性表述剥不掉，选材 0.18 也说明正文质量本身有问题。兜底只救形态，救不了内容。

Q2：断点续跑的 outputs 缓存，换了提示词版本要不要分目录？

要。缓存按模型名命名意味着改一版提示词后旧结果仍会被复用，裁判拿到的是旧 prompt 的输出。按 prompt 版本号建子目录，例如 outputs/v2/，这是这套脚本最容易踩的坑。

Q3：裁判为什么给「等了半个多小时」这种软化表述扣事实分？

因为约束第 2 条要求认「38 分钟超标」这个有系统记录的事实，「半个多小时」既没认 38 也没认 40，属于回避事实认定。在公开回复里这确实比精确认错弱——顾客看到的是含糊，不是诚意。

环境说明：本篇示例代码在千木SilvaMux的 OpenAI 兼容端点上跑通，认证读 SILVAMUX_API_KEY 环境变量，10 款模型的调用名均取自模型广场详情页（deepseek-v4-pro、glm-5.2、kimi-k2.6、qwen3.6-plus 等），排查问题时每个响应都带 X-Request-Id 头可回溯。