GLM5实战测试，挑战Opus4.6 ！

严刑拷打国产模型系列开始了！ 第一个被架起来的是智谱 GLM5。

上次被我骂“弱智”之后，这次似乎发奋图强了。

有些方面好像做的比 Opus4.6 还好，但是深入分析还是发现不少问题！

情况是这样，我正在开发一个大模型测试平台，专门用来测试主流的 CodingPlan 是否好用。为了增加娱乐性或者说复杂性，我设计了一个 AI 群聊的功能。把所有 AI 拉到一个群里，然后基于上下文对特定主题进行讨论。

开发这个功能的时候，一不小心用上了 GLM5，导致功能一直无法推进，把我气炸了，就专门写了一篇吐槽的文章《全TM辣鸡，最后还得 Claude Opus 搽屁股！》没想到……引起了很多人的共鸣。

骂完之后，我就冷静下来了。

决定在这个真实的开发环境中抽出一个环节作为考题。来“烤一烤”国产模型的能力。

这样测试的话，有充分的上下文，有一定复杂性，测出来的结果也比较有意义。

让我们看看，国产模型是真的牛逼到国际水平了，还是单纯吹牛逼吹到国际水平了。

这次的开发的核心需求是：

升级 AI 群聊功能，从只能平台群聊，升级为角色群聊。可以单独管理角色，每个角色可以设置头像，名称，选择 API 平台和具体 AI 模型，大幅度提升测试的灵活性和可玩性。

这个测试会涉及数据结构的调整，多个功能页面的修改，冗余功能的处理。非常考验模型的分析能力，编码能力，以及全局把握能力。

然后我们的评判标准也很简单易懂：首先是能不能用，其次是好不好用，最后修改是否全面！

第一次看到这里可能有点蒙，不清楚我在聊什么具体的功能。

那么可以看上一篇《Claude Opus4.6 实战记录，欢迎对标和超越！》

这里非常清楚的介绍了：

1. 我开发的系统是什么？
2. 当前已经有哪些功能？
3. 要升级的功能是什么？
4. Opus4.6 的实战表现！

今天重点是来看一下智谱 GLM5 的表现，以 Opus4.6 为参考系。

我的测试目录大概是这样的：

我创建了一个 Base 文件，里面放了基础代码。

然后让不同的模型在这个基础上进行升级，目前 Opus4.6 和三家国产模型已经全部测试完毕了。

下面，我就先从能不能用开始，然后讲好不好用，最后讲全不全面，最后分享下开发过程。

1、能不能用？

首先，我们把系统启动起来：

启动成功，没问题

然后来看一下启动后的页面：

页面显示正常！

接下来看一下核心功能。

我们这次的升级主要是涉及到了角色管理和群聊功能。

系统设置->角色管理：

这个显示没有任何问题。

这里需要注意一个细节，开发前角色管理在右边，开发完成之后，角色管理来到了左边。

可能是 GLM 角色这个功能会更加常用所以提到了左边。

Opus4.6开发的时候没有动这个位置，它只专注于修改这个功能。

然后我测试了增删改查没有任何问题。

设置头像，选择平台，联动模型列表，选择模型，设置头像，这些功能也全部正常。

然后看一下群聊这个核心功能：

核心功能测试没有问题。群聊创建界面已经添加了角色选择，而且能够正常选择我们配置好的角色，也能正常在群聊中进行对话。

但是这里有一个问题：

我先不说，你们可以看一下这张截图，猜一猜问题在哪里。这个问题我在细节部分揭晓。

总的来说，能不能用这部分是过关的。

核心功能全部可以正常使用，没有任何运行出错或者异常的地方。这一点值得表扬，也算是扛住这次的考验。

其实做到这一步是不简单的，你们后面看到 MiniMax 和 Kimi 就知道了。

2、好不好用？

说完能不能用，我们来看好不好用。

这里有两个细节，我是要表扬 GLM5 的。

第一个是角色编辑功能：

这里的头像选择部分，体验做的很好，预设了一些 emoji 和图标，让我选择起来非常方便。这个体验应该是优于 Opus4.6，Opus 是给了我一个输入 emoji 的框框，虽然自由度大了，便携性弱了一些。

另外在创建群聊对话，选择角色的时候，排列方式应该也是优于 Opus4.6，Opus4.6 采用了列表方式，而 GLM5 采用了类似“药丸”的效果，一行可以放两个，节省了空间。

大概就是这些吧。还是比较好用的。能做到这一步已经不错了。

3、全不全面？

上面两点都表现不错，初看好像比 Opus4.6 还厉害呢。

但是……重点来了！

我们都说细节决定成败，GLM5有几个细节没有处理好。

修改了不应该修改的功能

你们仔细看这张图：

我的群聊有两种模型，这次开发想要升级的是接力模式。GLM5 直接把我的广播模式也改掉了。

另外，两种模式下面，选择角色功能，都把系统提示词选项去掉了，这样是不行的。我需要系统提示词来约束整个对话。

应该修改的没有改

如果上面那个只是自我发挥无伤大雅。

那么下面这个问题，就比较严重了：

我明明选择了角色，但是它显示的还是平台。logo 和名字都不对。

虽然功能全部正常，但是这可是我们的核心功能啊，你显示不对，也是一个大问题。用户只会看显示，不会管你逻辑对不对。

其实这也是一个重要的考点，用来判断模型思考问题是否全面。

这一项要扣大分。

可以修改的没有改

魔鬼在细节啊。通过分析细节，可以看出两个人的差别，也能看出两个模型的巨大差别。

隐藏考点来了：

从系统设计的角度来说，当我们升级了角色功能之后，平台配置中的角色设置最好是去掉。

因为平台管理只负责设置和平台相关的内容，比如 API 协议，模型，参数等。不应该和角色绑定了。

我们升级了角色功能，就是为了解耦，我们可以在角色中绑定平台。

聪明的模型，应该能想到这个深度关联，建议去掉这个冗余配置。

Opus4.6 在设计的时候就想到了，而 GLM5 一直没有意识到这个问题。

4、开发过程

因为大家都喜欢看结果，所以我先给了结果。但是，大家也都明白，过程决定结果。其实最重要的是过程！

所以，最重要的我放在最后。给那些能看到最后的人。

首先，我的提示词是这样的：

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

GLM5 的回答如下：

## 我的理解
​
### 核心变化：从"平台绑定角色"变成"角色选择平台/模型"
​
**现状问题**：平台 → 角色（一对一，不灵活）
​
**目标**：角色 → 平台+模型（多对多，灵活）
​
### 角色管理升级
​
| 属性       | 说明                      |
| ---------- | ------------------------- |
| 名称       | 角色名称                  |
| 系统提示词 | 已有                      |
| 角色提示词 | 已有                      |
| **平台**   | 新增 - 选择哪个平台       |
| **模型**   | 新增 - 选择平台的哪个模型 |
| **头像**   | 新增 - 自定义头像（可选） |
​
### 群聊启动流程
​
两种入口：
​
1. **选平台** → 使用平台默认模型，不带角色提示词（和现在一样）
2. **选角色** → 自动使用角色绑定的平台+模型+提示词
​
### 头像显示优先级
​
```
角色有自定义头像？ → 显示自定义头像
        ↓ 否
显示角色绑定平台的 logo
```
​
---
​
## 

需要澄清的点：

需要澄清的点
​
1. 角色是否必须绑定平台？还是说角色可以只设提示词，平台/模型留空，然后在群聊时再选？
​
2. 平台和角色的关系：选平台时，是否还能叠加一个角色（只用角色的提示词，但用选的平台）？还是说"选平台"和"选角色"是两条完全独立的路径？
​
3. 头像来源：平台的 logo 现在有存吗？还是需要新增？
​
你觉得我的理解对吗？

我的回答：

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

其实从第一轮对话的澄清点，就能看出来一些问题了，GLM5 似乎有点抓不到重点。

模范生Opus4.6 是这样的：

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

它非常清晰的意识到了哪些问题是关键问题，必须要理清楚，才能继续。

Opus 提出了 5 个问题，每个都很关键。

GLM5 只提出了 3 个问题，少而且有充数的嫌疑。

第一个问题就把我搞蒙了！

第二个问题是对的，应该问。

第三个问就不应该问，有没有存你自己不会看么？浪费一个宝贵的提问机会！

执行计划上的差异也很大。

下面是 GLM5 的计划列表：

下面是 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

Opus4.6 还在计划的最后告诉自己“每完成一步可以验证，避免一次性改太多出问题。”。

详细去看他们的计划文档可以发现，GLM5 只写了粗略的 5 个章节，Opus4.6 整整写了 10 个章节，所有细节一清二楚。

所以最后的结果是，它这次的功能升级几乎没有任何漏洞。而 GLM5 小问题不少。

一句话：和“聪明人”打交道，就是省心！

5、简单总结一下

GLM5显然不是“弱智”，它其实已经具备了一定的工程能力。

他可以实现80~90%的功能，但是细节有待提升，全局的思考能力还是比较弱。

如果 Opus 是“高级工程师”的话，它可以拿个“中级工程师” 了，就是刚升上来的那种，还的历练历练。

当然，比起来“某些”初级工程师，它又好了很多，它至少把这活干完了，能用。

下一轮的 Kimi 和 MiniMax 才叫精彩绝伦！