
昨天我失眠了今天火气有点大那么大的厂怎么做了这么一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、制作过程下面我是最初的提示词我测了很多模型都是用这一段开始的。提示词目前群聊接力的时候可以选择平台管理中的模型也可以对这些模型预先配置系统提示词和角色提示词这样已经可以通过系统提示词来个性化聊天了。但是通过平台配置里面绑定角色比较有局限性——这样一个平台就只能是一个角色。 我希望换另外一种设置**角色里面选模型**然后群聊开始的时候我可以直接选平台也可以直接选角色。角色的管理还是在系统设置的角色管理中进行。 为了实现上面的需求角色功能需要升级 - 除了可以设置提示词之外还得能**选择平台和模型** - 另外还能**设置头像** - 如果设置了头像群聊的时候就显示自定义头像如果没有设置头像就用对应模型平台的 logo 作为头像 我的需求大概是这样。说说你的这个需求的理解不急着写代码然后来看看它们的回复。第一轮看起来都是高手如果单纯看这一轮的回答看起来各个都是高手说的头头是道。阿里● 我来梳理一下你的需求确保理解正确 当前架构 平台 (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 } --- 我的理解 简单来说就是把角色从平台的附属配置中独立出来让角色成为一级实体 - 角色可以跨平台绑定任意模型 - 同一个平台的不同模型可以对应不同角色 - 群聊时可以直接选人角色而不是先选平台再接受固定角色 这样理解对吗有没有遗漏或偏差的地方这里理解是没太大问题的。接下来它还查看了代码结构然后提出了改动方案并询问了我很多问题。关键设计问题 在开始实现之前有几个设计点需要确认 1. 角色与平台的关系 - 一个角色绑定一个模型来自某个平台 - 还是绑定一个平台使用该平台的 selectedModel 2. 群聊创建流程 - 如果用户选择角色是单选还是多选 - 如果多选角色每个角色各自带模型那底层平台怎么处理 3. 兼容性问题 - 现有的群聊会话基于平台需要继续可用 - 现有的角色没有平台/模型字段需要兼容 请确认一下你期望的群聊启动流程是怎样的 - 方案 A选平台多选→ 用平台绑定的角色 - 方案 B选角色多选→ 每个角色带一个模型 - 方案 C两者并存用户可切换 好的方案 C用户可以选择选平台或选角色两种方式。 让我再确认一些细节 需要确认的细节 1. 角色与模型的关系 - 一个角色绑定 一个模型即绑定一个平台 该平台的某个模型 - 例如资深程序员 角色可以绑定 阿里云百炼 → qwen3.5-plus 2. 群聊创建界面 期望的交互是 [ 选择平台 (多选) ] —— 或者 —— [ 选择角色 (多选) ] ↓ ↓ 用平台的 selectedModel 用角色绑定的模型 - 如果选角色多选比如选了 3 个角色每个角色各自用自己的模型对吗 - 这样底层其实还是对应多个平台可能重复 3. 会话保存 - 选平台创建的会话 → session.platformIds[] - 选角色创建的会话 → 需要新增 session.roleIds[]还是直接转换为 platformIds 4. 头像显示 - 如果角色设置了 avatar → 显示角色头像 - 如果没设置 → 显示该角色绑定模型的平台 logo这个前期细节真的拉满了先不说问题是否精准至少它在努力地提问确认细节。说实话看到这里我感觉它能把这件事情能干成。接下来就是根据自己的方案开始干活了◻ 更新角色管理 UI添加平台选择、模型选择和头像设置 ◻ 更新 Role 类型定义添加 avatar、platformId、modelId 字段 ◻ 更新聊天 API 支持角色模式 ◻ 更新群聊创建 UI支持选择平台和选择角色两种模式 ◻ 更新消息组件支持角色头像显示 火山好的我来梳理一下对这个需求的理解 核心变化从平台绑定角色 → 角色绑定平台模型 之前的架构 - 平台Platform是主体在平台配置里绑定角色 - 局限性一个平台只能对应一个角色 新的架构 - 角色Role是主体在角色配置里选择平台和模型 - 一个平台/模型可以被多个角色复用 - 群聊时可以选择 - 直接选平台用平台的默认配置 - 直接选角色用角色绑定的平台模型提示词头像 角色功能升级点 1. 角色配置增加字段 - 绑定的平台Platform - 绑定的模型Model - 自定义头像Avatar 2. 头像显示逻辑 - 角色有自定义头像 → 显示角色头像 - 角色无头像 → fallback 到平台的 logo 我的理解对吗 有几个问题想确认一下 1. 群聊时选择平台的场景还保留吗还是只选择角色 2. 之前平台管理里的系统提示词配置是保留还是移到角色里 3. 单聊single-chat功能是否也需要同步调整 这个理解也没毛病向我提了三个问题问题不是太精准但是至少提了三个问题。我回答了他的问题接下来他就开始干活了更新 Role 类型定义… (58s · ↑ 337 tokens · thinking with high effort) ⎿ ◼ 更新 Role 类型定义 ◻ 更新 roles store ◻ 更新角色管理页面 ◻ 更新群聊创建页面 ◻ 更新聊天消息显示腾讯我来理解一下你的需求看看说得对不对 当前状态 平台配置 - 平台 → 模型 → 系统提示词/角色提示词 - 一个平台只能绑定一个角色 群聊接力时 - 选择平台 → 使用该平台配置的模型和提示词 --- 你期望的新状态 角色变成独立配置单元 - 提示词已有 - 平台 模型新增 - 头像新增 群聊接力时 - 可以选平台 → 用平台配置的模型 - 也可以选角色 → 用角色配置的模型 提示词 头像 头像逻辑 - 有自定义头像 → 显示自定义头像 - 没有自定义头像 → 用对应模型平台的 logo --- 几个确认问题 1. 角色管理的位置目前系统设置里已经有角色管理功能吗还是需要新增 2. 平台的角色配置原来的平台绑定角色还要保留吗还是完全改成角色里选平台这种模式 3. 模型选择角色里选的模型跟平台管理里的模型是什么关系是直接引用平台管理里的模型还是角色可以独 立配置模型参数 4. 多平台模型如果一个角色支持多个模型比如同时支持 GPT-4 和 Claude还是只能选一个 你希望先讨论哪部分还是我直接去看一下现有代码再讨论 这个理解也没毛病。而且同样也提出了问题。它提出了4个问题。第一个问题就非常犀利这也是最后他能成功去掉这个冗余的关键。后面几个问题只能说问到点了但是从提问方式来看对这个业务理解不够深入。我回答了它的问题之后它又问了我另外三个问题几个确认问题 1. 群聊会话的参与者选择你希望用什么样的 UI比如 - 一个列表同时显示平台和角色用户多选 - 还是分成两个 Tab选择平台 和 选择角色 2. 头像上传自定义头像怎么处理 - 用户输入 URL - 还是支持本地上传图片 3. 角色选模型角色选模型时模型的列表从哪里来 - 从选中平台的 models 字段读取 - 还是角色可以自由填写模型名 你觉得这个改造方向对吗这几个问题就实际了很多。而且它还提到了模型从哪里来我说了从平台里来。可惜最后开发完成它没有把平台列表显示出来也就选不了模型了。下面是它的开发计划 升级角色管理 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的代码已经发出来了https://github.com/JarvisPMS/codingplan有兴趣的可以git下来玩一玩