大模型实测系列继续， 同样的开发场景，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个大章节，事无巨细：
- 数据模型变更
- 废弃平台上的角色绑定
- 角色管理页面升级（设置页）
- 群聊创建页面改造
- 群聊接力核心逻辑改造
- 消息显示组件改造
- 会话列表页面适配
- 聊天页面适配
- 文件图片上传
- 实现顺序（建议分步）
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 没法给我广告费！🤣
只能说，能传播简单的事实也是一种福报吧！
