昨天我失眠了，今天火气有点大！
那么大的厂，怎么做了这么一tuo。
拿出来的时候精美的，一锤就碎了！
本来这篇文章的标题应该是《全TM辣鸡，浪费生命》！
但是我想想还是算了，我成长了。
我对不起 GLM5，如果它是"若至"，它们就是"滞涨"了。
好吧好吧，这些厂也没有在我面前吹过牛逼，只是浪费了我一天一夜的时间而已。
😐我就原谅他们了！
我就开头骂一句，后面我就好好写了，让大家知道一下这三家在编程领域的真实水平。
今天不看基准，基准毫无意义！
我的测试场景，请直接参考《Claude Opus4.6 实战记录，欢迎对标和超越！》这一篇。
文章有一点点长，大概 10000个字符！
我会先从测试环境说起，然后看一下测试结果，分享一下过程，分析一下bug，对比一下速度和tokens消耗情况。
1、测试环境
先简单说一下测试环境和测试对象。
我的测试工具为 Claude Code，通过 CCSwitch 切换！
使用的模型分别是：
- 阿里百炼的
qwen3.5-plus - 火山方舟的
Doubao-Seed-2.0-Code - 腾讯混元的
tc-code-latest
选择原则，就是他们自家的最新模型，或者最新的编程模型。
测试基于同样的一个 Base 项目，然后用同样的工具，同样的提示词：
不同文件夹下面是不同的模型升级后的项目。
2、直接上菜
所有测试我已经跑完了。
我们先来看结果，用同样的命令启动：
这是 Base 项目。
没改之前，角色管理是这样的：
然后我们来看看，修改完成之后是什么样的。
我们的评判标准还是一样的：首先看能不能用，然后看好不好用，最后看全不全面。
能不能用？
下面，我们就打开网页，进行验证了。
阿里：
能正常启动，角色管理布局有点崩，也没有看到头像区域。
当点击编辑或者添加角色：
💥直接崩了， 我们先不管错误是什么，反正就是错了。
核心功能的第一步，就不可用。
火山：
启动正常，布局正常，可以看到一个头像区域，目前用一个机器人图标填充。
当点击编辑或者添加角色：
💥也直接崩了，而且错误一模一样。
如果我不是用端口号来区分，我都以为启动了同一个服务。
很显然，这个是没法用的。
腾讯：
启动正常，显示基本正常。头像部分用了一个小人占位。
点击添加或者编辑：
卧槽卧槽卧槽，居然有一个正常的！！！ 我现在标准很低，能正常点开这个页面就很开心了。
补充一张截图：
腾讯的模型居然还考虑到了这一点，也算是惊喜了。
但是，它这个系统还是不太能用。
角色编辑和角色添加里无法拉取角色列表和模型，导致角色是一个空壳。这样群聊就完全搞不起来。
好不好用
没法用，谈不上好用。
全不全面
没法用，谈不上全不全面。
3、制作过程
下面我是最初的提示词，我测了很多模型，都是用这一段开始的。
提示词：
markdown
目前群聊接力的时候可以选择平台管理中的模型，也可以对这些模型预先配置系统提示词和角色提示词，这样已经可以通过系统提示词来个性化聊天了。但是通过平台配置里面绑定角色比较有局限性------这样一个平台就只能是一个角色。
我希望换另外一种设置：**角色里面选模型**，然后群聊开始的时候，我可以直接选平台，也可以直接选角色。角色的管理还是在系统设置的"角色管理"中进行。
为了实现上面的需求，角色功能需要升级：
- 除了可以设置提示词之外，还得能**选择平台和模型**
- 另外还能**设置头像**
- 如果设置了头像，群聊的时候就显示自定义头像；如果没有设置头像，就用对应模型平台的 logo 作为头像
我的需求大概是这样。说说你的这个需求的理解，不急着写代码然后来看看它们的回复。
第一轮：看起来都是高手！
如果单纯看这一轮的回答，看起来各个都是高手，说的头头是道。
阿里：
yaml
● 我来梳理一下你的需求，确保理解正确：
当前架构
平台 (Platform)
└── 绑定模型 (Models)
└── 可配置系统提示词/角色提示词
└── 群聊时：选平台 → 用该平台的固定角色
问题：一个平台只能对应一个角色，不够灵活。
---
新架构
角色 (Character) ← 核心实体
├── 提示词 (Prompt)
├── 头像 (Avatar) [可选]
└── 绑定的模型 (Selected Model from a Platform)
└── 模型来自某个平台
群聊启动时：
├── 方式 A：直接选平台（保持原有逻辑）
└── 方式 B：选角色（角色自带模型）
---
需要改动的地方
1. 角色管理（系统设置 → 角色管理）
- 新增字段：
- platform_id / model_id：选择模型
- avatar_url：自定义头像
- UI 上需要添加模型选择器和头像上传/输入框
2. 群聊启动界面
- 选择方式二选一：
- 选平台（现有逻辑）
- 选角色（新逻辑，选中后自动使用该角色绑定的模型）
3. 群聊头像显示逻辑
if (角色有 avatar) {
显示角色自定义头像
} else {
显示模型所属平台的 logo
}
---
我的理解
简单来说，就是把"角色"从平台的附属配置中独立出来，让角色成为一级实体：
- 角色可以跨平台绑定任意模型
- 同一个平台的不同模型可以对应不同角色
- 群聊时可以直接选人（角色），而不是先选平台再接受固定角色
这样理解对吗？有没有遗漏或偏差的地方？这里理解是没太大问题的。
接下来它还查看了代码结构，然后提出了改动方案，并询问了我很多问题。
markdown
关键设计问题
在开始实现之前，有几个设计点需要确认：
1. 角色与平台的关系：
- 一个角色绑定一个模型（来自某个平台）？
- 还是绑定一个平台（使用该平台的 selectedModel）？
2. 群聊创建流程：
- 如果用户选择"角色"，是单选还是多选？
- 如果多选角色，每个角色各自带模型，那底层平台怎么处理？
3. 兼容性问题：
- 现有的群聊会话（基于平台）需要继续可用
- 现有的角色（没有平台/模型字段）需要兼容
请确认一下：你期望的群聊启动流程是怎样的？
- 方案 A：选平台（多选）→ 用平台绑定的角色
- 方案 B：选角色（多选）→ 每个角色带一个模型
- 方案 C：两者并存，用户可切换
好的，方案 C：用户可以选择"选平台"或"选角色"两种方式。
让我再确认一些细节：
需要确认的细节
1. 角色与模型的关系
- 一个角色绑定 一个模型（即绑定一个平台 + 该平台的某个模型）？
- 例如："资深程序员" 角色可以绑定 "阿里云百炼 → qwen3.5-plus"
2. 群聊创建界面
期望的交互是：
[ 选择平台 (多选) ] ------ 或者 ------ [ 选择角色 (多选) ]
↓ ↓
用平台的 selectedModel 用角色绑定的模型
- 如果选角色（多选），比如选了 3 个角色，每个角色各自用自己的模型，对吗？
- 这样底层其实还是对应多个平台（可能重复）
3. 会话保存
- 选平台创建的会话 → session.platformIds[]
- 选角色创建的会话 → 需要新增 session.roleIds[]？还是直接转换为 platformIds？
4. 头像显示
- 如果角色设置了 avatar → 显示角色头像
- 如果没设置 → 显示该角色绑定模型的平台 logo这个前期细节真的拉满了，先不说问题是否精准，至少它在努力地提问，确认细节。
说实话，看到这里，我感觉它能把这件事情能干成。
接下来就是根据自己的方案开始干活了：
swift
◻ 更新角色管理 UI，添加平台选择、模型选择和头像设置
◻ 更新 Role 类型定义，添加 avatar、platformId、modelId 字段
◻ 更新聊天 API 支持角色模式
◻ 更新群聊创建 UI，支持选择平台和选择角色两种模式
◻ 更新消息组件支持角色头像显示
火山：
markdown
好的，我来梳理一下对这个需求的理解：
核心变化：从"平台绑定角色" → "角色绑定平台+模型"
之前的架构：
- 平台（Platform）是主体，在平台配置里绑定角色
- 局限性：一个平台只能对应一个角色
新的架构：
- 角色（Role）是主体，在角色配置里选择平台和模型
- 一个平台/模型可以被多个角色复用
- 群聊时可以选择：
- 直接选平台（用平台的默认配置）
- 直接选角色（用角色绑定的平台+模型+提示词+头像）
角色功能升级点
1. 角色配置增加字段：
- 绑定的平台（Platform）
- 绑定的模型（Model）
- 自定义头像（Avatar）
2. 头像显示逻辑：
- 角色有自定义头像 → 显示角色头像
- 角色无头像 → fallback 到平台的 logo
我的理解对吗？
有几个问题想确认一下：
1. 群聊时选择"平台"的场景还保留吗？还是只选择角色？
2. 之前"平台管理"里的系统提示词配置，是保留还是移到角色里？
3. 单聊（single-chat）功能是否也需要同步调整？
这个理解也没毛病，向我提了三个问题，问题不是太精准，但是至少提了三个问题。
我回答了他的问题，接下来他就开始干活了：
csharp
更新 Role 类型定义... (58s · ↑ 337 tokens · thinking with high effort)
⎿ ◼ 更新 Role 类型定义
◻ 更新 roles store
◻ 更新角色管理页面
◻ 更新群聊创建页面
◻ 更新聊天消息显示腾讯：
yaml
我来理解一下你的需求，看看说得对不对：
当前状态
平台配置：
- 平台 → 模型 → 系统提示词/角色提示词
- 一个平台只能绑定一个角色
群聊接力时：
- 选择平台 → 使用该平台配置的模型和提示词
---
你期望的新状态
角色变成独立配置单元：
- 提示词（已有）
- 平台 + 模型（新增）
- 头像（新增）
群聊接力时：
- 可以选平台 → 用平台配置的模型
- 也可以选角色 → 用角色配置的模型 + 提示词 + 头像
头像逻辑：
- 有自定义头像 → 显示自定义头像
- 没有自定义头像 → 用对应模型平台的 logo
---
几个确认问题
1. 角色管理的位置：目前系统设置里已经有"角色管理"功能吗？还是需要新增？
2. 平台的角色配置：原来的"平台绑定角色"还要保留吗？还是完全改成"角色里选平台"这种模式？
3. 模型选择：角色里选的模型，跟平台管理里的模型是什么关系？是直接引用平台管理里的模型，还是角色可以独
立配置模型参数？
4. 多平台模型：如果一个角色支持多个模型（比如同时支持 GPT-4 和 Claude），还是只能选一个？
你希望先讨论哪部分，还是我直接去看一下现有代码再讨论？
这个理解也没毛病。而且同样也提出了问题。
它提出了4个问题。
第一个问题，就非常犀利，这也是最后他能成功去掉这个冗余的关键。
后面几个问题，只能说问到点了，但是从提问方式来看，对这个业务理解不够深入。
我回答了它的问题之后，它又问了我另外三个问题：
markdown
几个确认问题
1. 群聊会话的参与者选择：你希望用什么样的 UI？比如：
- 一个列表同时显示平台和角色，用户多选？
- 还是分成两个 Tab，"选择平台" 和 "选择角色"？
2. 头像上传：自定义头像怎么处理？
- 用户输入 URL？
- 还是支持本地上传图片？
3. 角色选模型：角色选模型时，模型的列表从哪里来？
- 从选中平台的 models 字段读取？
- 还是角色可以自由填写模型名？
你觉得这个改造方向对吗？这几个问题就实际了很多。而且它还提到了模型从哪里来，我说了从平台里来。
可惜，最后开发完成，它没有把平台列表显示出来，也就选不了模型了。
下面是它的开发计划：
scss
升级角色管理 API... (1m 35s · ↑ 1.8k tokens · thinking)
⎿ ✔ 升级 Role 类型定义
◼ 升级角色管理 API
◻ 改造角色管理页面
◻ 改造群聊创建页面
◻ 更新聊天消息显示三个模型的理解都看完了，单纯看理解部分都问题不大，可能是我已经说得很清楚了。
差别主要在于阅读系统原有代码之后，给出的理解和提问，这部分就不是太精准和全面。
第二轮，都没有做详细方案
我上面列出来的都是理解和提问部分。
实际上有一个重要的环节，我没有贴出来，就是完整的开发计划。
这部分非常关键，细节决定成败。
开始写代码之前，一定要完整理解这个项目，并且制定详细的计划。
它们做的都不是很好，计划非常短，大概就是一屏到两屏之间。
大概只有 Opus4.6 五分之一不到。
Opus4.6做了10个章节：
细节非常丰富，所以最后一次过，没有任何运行错误和逻辑bug。
第三轮，结果全拉了！
胜负不在战时，而在战前。
从上面的设计方案基本就知道结果了。
虽然第一轮都像模像样，但是第二轮已经漏出底裤，第三轮，就是全部裸奔了。
下面我们来深入分析一下，它们到底写了个啥。
我会让Opus来做分享，重点分享它们的需求完成度，代码质量问题，以及为什么点击创建功能出错。
先看阿里百炼
需求完成度：
存在的问题：
创建出错原因：
创建角色（POST）时 API 路由忽略了新增字段，是最核心的 bug ！
再看一下火山的情况。
需求完成度：
存在的问题：
创建出错原因：
但由于创建时就没有保存新增字段，编辑时加载的表单数据就是空的，形成恶性循环。
最后看一下腾讯的情况。
需求完成度：
存在的问题：
从上面 review 看，基本上都存在一个或者多个严重的 bug。
看来，它们写的不是代码，是 bug。
我以后不比谁厉害了，比谁的bug多。
谁干好，这个问题已经没什么好比了，半斤八两。
下面来看看一些能比的，比比使用时间和 tokens 消耗情况。
4、时间对比
在测试的同时，我也大概记录一下时间。
阿里：
阿里开发完成，到开始安装依赖包的时候，大概是消耗了26分钟左右。 我测试的时间大概是在下午5点左右。
火山：
火山开发完成，到开始安装依赖包的时候，大概是消耗了 14 分钟左右。我的测试时间大概是在晚上 11 点多。
腾讯：
腾讯这个构建完成，到可以测试的时间是 30 分钟。测试时间是在晚上零点多。
测到腾讯已经半夜了，直接导致我失眠了。
从我的测试来看，火山明显要快很多，腾讯和阿里比较慢。
我记得最早测试方舟这个套餐的时候写一个博客都要很久，现在速度好像提上来了。
腾讯和阿里可能还在提产能，速度不太行。
当然，也可能受时间段和高峰期的影响，仅供参考。
5、消耗对比
除了记录时间，我也留意了消耗情况。
具体数据如下。
阿里：
消耗了 9%，它这个用量是按调用次数算的。
火山：
消耗了 33%，好像不是按次数算的。
后期消耗增长巨快，估计是上下文大了，tokens 消耗很快。但是相对而言它的开发速度也很快。
腾讯：
用了 6.8%，看起来它的统计方式和阿里一致，是按次数计算的。
从用量来说，火山消耗比较快，我估计用不了多久 5 小时配额就用完了。阿里和腾讯因为按次数算的所以比较耐用，即便是入门款基本也用不完。
最后简单说几句！
为了测试它们的实力，我干到了半夜，后来躺在床上一直睡不着。
我陷入了沉思：我为什么要浪费这时间！
看它们写代码，真的一个头两个大。
我一个月花40或200。
是找它们写代码的，不是写 bug 的呀。
是找它们来干活的，不是给它们擦屁股的呀。
是找它们来节省时间，不是浪费时间的啊。
最后，我反思。
它们考不好，可能是我这题太难了，怪我！
它们写代码不好，可能是打开方式不对，肯定是的。
兄弟们，我自罚一杯。
接下来，我不找茬了，主打吹牛逼~。~
Base的代码已经发出来了：
有兴趣的可以git下来玩一玩！