MiniMax和kimi都是人才，“吊打”Opus4.6

大模型实测系列继续， 同样的开发场景，Opus已经做过了，GLM5 也测过了！

接下来就是国产“三巨头”中的 Kimi 和 MiniMax 了。

看完它们的测试结果，只能说一句“都是人才” ，轻松“吊打” Opus4.6 。

因为前段时间老刷到它们，都在说这两个模型很厉害，我就入坑了。

买完之后用了几次，我对他们的敬仰，犹如滔滔江水，绵绵不绝。

真的是如鲠在喉，如坐针毡，如芒刺背~ 不吐不快！

我们先来看看它们“看起来”有多厉害吧。

这是 Kimi 的：

Kimi K2.5 是 Kimi 迄今最智能的模型，在 Agent、代码、视觉理解及一系列通用智能任务上取得开源 SOTA 表现。同时 Kimi K2.5 也是 Kimi 迄今最全能的模型，原生的多模态架构设计，同时支持视觉与文本输入、思考与非思考模式、对话与 Agent 任务。

这是 MiniMax：

编码与智能体领域 SOTA，M2.5 达到了行业第一档模型的水平，在多语言相关的任务 Multi-SWE-Bench 上，M2.5 达到了行业最好的水平。

这些信息都是官网的数据和描述，我一个字都没有改。

SOTA！SOTA！ SOTA！ 的呼声不绝于耳！（SOTA == “最牛逼的意思！”）

一会儿刷榜大模型竞技场，一会儿霸榜openrouter，一会儿是OpenClaw的推荐模型。

真的是太强了，给我的感觉是Opus4.6给他们提携都不配。

但事实真的如此么？ 显然不是啦！

发新产品吹点牛，也是免不了的，情理之中。

但是这里面有多少水分，就是我们应该要关心的问题了。

因为真的要用，和看起来很好，是完全两个东西。

如果水分太大，就变诈骗了。

从宣传力度来看，感觉最厉害的是 MiniMax，然后是 Kimi，接下来是 GLM。

然后从官方给的基准来看是这样的：

这是难得的大家都提供了的基准数据，这个基准叫 SWE-Bench Verified，专门用来测试编程能力的。

当然官方不会把这几个放在一起，做这样一张图，这张图是我根据他们的数据做的。

从数据来看最厉害的国产模型是 MiniMax。

好的，那就开捶吧！

铺垫这么多，你们应该知道接下来的故事有多精彩了。

今天就让大家看看它们到底有多牛逼吧！！！

下面我们就按一贯的标准来看一下。

先从能不能用开始，然后讲好不好用，最后讲全不全面，然后看一下开发过程。

1、能不能用？

先来看MiniMax吧。

这个国产模型中编程最厉害的（它们自己说的）。

根据我们上几期同样的编程场景和同样的提示词，代码已经写完了。

我们先把服务启动起来：

然后打开网页：

💥Game Over！ 一秒钟结束战斗，绝顶高手。

500错误，做过开发的都很熟悉。

没做过开发也可以理解为这是250 x 2 = 500。

Opus4.6看到这种表现，直接就跪了：“在写bug 方面，小弟自叹不如！”

其实，我们已经看过Opus的表现，它做这一题的时候非常无趣，一次过，没有任何波澜。

它开发完成之后，还会做可用性检查，只要交给你了，十有八九可以正常使用。

MiniMax这种表现，不给0分都对不起它！

再来回顾一下官方的基准数据：

官方说 M2.5 是编码与智能体领域 SOTA！

M2.5 的编程能力只比 Opus4.6 差 0.7 分。

(仔细看，官方的描述和数据就是矛盾的！)

真的是什么牛都敢吹！

各位可以自己对比下Opus表现的《Claude Opus4.6 实战记录，欢迎对标和超越！》

看完Minmax M2.5的表现。

再来看一下Kimi K2.5的表现吧

同样先启动服务器：

服务器启动成功！

打开首页：

没问题，Game Start！ 不过，这仅仅是开始。

启动没问题，我们来看一下功能：

角色部分界面已经更新，看起来都挺好的，该加的好像也加了。

但是……功能有 bug！

添加角色的时候选择了平台，添加完成之后，平台和模型信息根本就写入“数据库”。

另外，角色编辑功能点了没有任何反应。

而群聊接力功能，必须要正常绑定平台和模型的角色，才能继续。

因为角色和平台数据录入失败，又无法修改，所以角色群聊这个核心功能没办法用。

启动成功了，但是核心功能没法用。给个友情分 50 分吧。

闯关失败！！Game Over！

其实刚开始我看到Kimi这个表现，感觉有点拉跨！

但是一看MiniMax，突然觉得Kimi好像也还可以啊~~

奇怪的对比效果！

2、好不好用？

我真的不知道，评判好不好的前提是“能用”！

（这个章节本来要写很多的）

3、全不全面？

我也不知道，因为用不了，怎么评判做的全不全面。

只能说写 BUG 方面很全面。

（这个章节本来要写很多的）

4、开发过程

结果已经很清楚了，我们再来研究一下过程。上面我们轻松点，这里就得稍微仔细点看了。

这是我的需求：

目前群聊接力的时候可以选择平台管理中的模型，也可以对这些模型预先配置系统提示词和角色提示词，这样已经可以通过系统提示词来个性化聊天了。但是通过平台配置里面绑定角色比较有局限性——这样一个平台就只能是一个角色。
​
我希望换另外一种设置：**角色里面选模型**，然后群聊开始的时候，我可以直接选平台，也可以直接选角色。角色的管理还是在系统设置的"角色管理"中进行。
​
为了实现上面的需求，角色功能需要升级：
​
- 除了可以设置提示词之外，还得能**选择平台和模型**
- 另外还能**设置头像**
- 如果设置了头像，群聊的时候就显示自定义头像；如果没有设置头像，就用对应模型平台的 logo 作为头像
​
​
​
我的需求大概是这样。说说你的这个需求的理解，不急着写代码

测试 Opus 和 GLM5 都是一模一样的提示词。先从讨论开始！

MiniMax的回答：

我来理解一下你的需求：
​
## 当前状态
​
```
平台管理 → 绑定角色 → 配置模型
群聊接力时选择平台/模型
```
​
问题：一个平台只能绑定一个角色，不够灵活。
​
## 你想要的升级
​
```
角色管理 → 包含：提示词 + 平台/模型 + 头像
群聊接力时：可以选择平台（快速选），也可以选择角色（完整配置）
```
​
## 核心变化
​
| 功能           | 现状                 | 升级后                       |
| -------------- | -------------------- | ---------------------------- |
| 角色与平台关系 | 平台绑定角色（1对1） | 角色自主选择平台（1对多）    |
| 头像           | 无                   | 可选，有则用，无则用平台logo |
| 群聊选择       | 只能选平台           | 平台 OR 角色都可以           |
​
## 我的理解
​
你希望**角色变成一个"完整配置包"**：
​
- 角色 = 提示词 + 平台/模型 + 头像
- 这样群聊时可以直接选角色（预设好的），也可以单独选平台（快速模式）
​
**一个问题确认：**
​
一个角色是否可以支持多个平台/模型组合？还是一个角色对应一个具体的平台+模型？
​
举例：角色"小助手"，是否可以是：
​
- A. 只能绑定一个平台+模型（如 MiniMax）
- B. 可以同时支持多个平台（如 同时支持 MiniMax 和 OpenAI）

这个回答整体看没啥问题，核心需求理解基本是正确的。

然后他提出了一个问题让我确认。这个问题提的也没毛病，确实该问。

单看这一步没任何问题，但是比较一下 Opus 和 GLM5，差距就来了。

Opus4.6 问了 5 个问题：

三、待确认的问题
​
1. 角色与平台的关系：一个角色绑定一个平台+一个模型，对吗？还是说一个角色可以绑定多个平台？（我理解应该是一对一：一个角色 = 一个人格 + 一个特定的平台/模型）
​
2. 群聊中混合选择：是否允许同一个群聊里既选了几个"裸平台"，又选了几个"角色"？比如群里有"角色A（用 GPT-4o）"+"角色B（用 Claude）"+"裸的 Gemini 平台"？
​
3. 同模型多角色：是否允许同一个模型被多个角色使用？比如"严谨学者"和"搞笑段子手"都绑定 GPT-4o，在同一个群聊里同时出现？
​
4. 头像格式：自定义头像是上传图片文件，还是选择预设图标/emoji，还是都支持？
​
5. 平台上原有的 defaultRoleId 字段：是否要废弃掉？既然角色不再绑定在平台上，平台配置表单里的"默认角色"选择器是不是可以移除了？
​
需要我帮你把这些问题整理成一个更清晰的**待办清单**吗？这样后续跟进会更方便。

GLM5 问了 3 个问题：

1.正常来说角色肯定得绑定平台才能使用啊，否则你调用什么？
2.平台和角色关系，就是每个角色依赖一个平台啊。
3.可以上传图片文件，也可以选择预设图标/emoji。没有图片时可以用默认头像或表情。

Opus4.6的问题，全部都是关键问题，没有一个是多余的。

它已经完全理解了这个需求，并且知道实现这个需求有哪些分支，并且觉得有必要让用户选择之后再继续。

看似在让你选择，其实它是在给你标准答案！

接下来是他的具体计划：

# 角色功能升级计划
​
## 背景
​
当前系统中，角色(Role)只包含名称和提示词内容，平台可以绑定一个默认角色。用户希望在群聊时可以直接选择角色，而不是只能选择平台。
​
## 需求
​
1. **角色升级**：角色可以绑定平台 + 模型，可以设置自定义头像
2. **群聊选择**：可以直接选平台，也可以直接选角色
3. **头像显示**：有自定义头像显示自定义图片，没有则显示对应平台的 logo
4. **移除冗余**：移除平台的 defaultRoleId 配置
​
## 实现方案
.....

M2.5大概是分了 3 个大章节。前面两个章节是背景和需求…

各位请注意，现在已经到开发环节了，虚头巴脑的东西占了两个章节。

另外一个就是实现方案了，实现方案分成了5个小点！

这一步，我也给个对比参考吧。

Opus4.6 的开发计划分了10个大章节，事无巨细：

1. 数据模型变更
2. 废弃平台上的角色绑定
3. 角色管理页面升级（设置页）
4. 群聊创建页面改造
5. 群聊接力核心逻辑改造
6. 消息显示组件改造
7. 会话列表页面适配
8. 聊天页面适配
9. 文件图片上传
10. 实现顺序（建议分步）

GLM 是分了五个大章节。

他们无一例外，都是从“数据结构升级”开始的，没有人在开发阶段还用两个大章节介绍需求的，这两个章节把其实也就几句话。

这已经完全到写代码的阶段了啊，需求早就分析清楚了呀。

然后就是执行 Plan 的部分：

这部分突然就变成英文了，也不知道为什么，为了看起来专业？还是训练数据是英文的？

Opus4.6 这个外来的和尚，可是一直保持中文沟通哦。

作为对比，下面是 Opus4.6 的开发计划：

步骤	内容	涉及文件
Step 1	数据模型变更 + 迁移	types.ts, store/roles.ts, roles.json
Step 2	废弃平台角色绑定	platform-form.tsx, prompt-builder.ts
Step 3	头像上传 API	新建 api/upload/avatar/route.ts
Step 4	角色管理页面升级	settings/page.tsx
Step 5	群聊创建页面改造	chat/page.tsx, api/chat/route.ts
Step 6	接力核心逻辑改造	api/chat/[sessionId]/route.ts, prompt-builder.ts
Step 7	消息显示组件改造	chat-message.tsx
Step 8	聊天页面 + 会话列表适配	chat/[sessionId]/page.tsx, chat/page.tsx

“每完成一步可以验证，避免一次性改太多出问题。” 这是 Opus 的原话。

如果 MiniMax 能记住这句话，就不会开发完，访问首页就报错了。

所以从过程到结果，其实MiniMax 是全程不怎么在线！

除了那个英文的执行计划，看起来很专业。

接下来有没有人好奇，MiniMax 如果能跑起来是什么样子的？

首先让老师傅 Opus 来诊断一波问题：

再让GPT5.4 做一下 review：

除了第一个问题，是我允许的。其他全是问题！

也许你看不懂这些错误是什么，但是你应该可以看出来，这里有很多问题。

为了给他搽屁股，分析它的排泄物，把我 Claude 配额都用完了！

我觉得已经没有必要去测试跑起来的样子了。

……

好吧，我还是忍不住，把首页修好了。

然后去测试角色功能，然后……

添加角色 Error，修改角色 Error ！

这根本不是做开发，这就是专业写BUG。

由于 MiniMax 过于优秀，我已经不想再去分析 Kimi 了。

本来以为，再弱也能和 Opus 过几招，没想到这个结果。

现在再回过头去看一下开头的基准分数和他们的自我评价…

《全TM辣鸡，最后还得 Claude Opus 搽屁股！》这个标题的含金量还在上升。

最后，谁都不要吹牛逼，论实战，Claude Opus4.6 碾压所有对手，完全是不同级别的存在！

哎，太可惜了，Claude 没法给我广告费！🤣

只能说，能传播简单的事实也是一种福报吧！